Mike Frysinger wrote:
On Monday 08 June 2009 09:09:43 Roy Marples wrote:
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather
than having to figure out what's going on vi
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather than
having to figure out what's going on via the filesystem. the point of this
thread is to detect baselayout-1 vs openrc onl
Mike Frysinger wrote:
i didnt see any real discussion of /sbin/functions.sh ... i dont recall there
being a reason historically for not checking for this file to detect
baselayout-1 vs openrc, and no one has complained about its usage in mdadm ...
That works as a baselayout-1 vs openrc test.
H
Mike Frysinger wrote:
the original discussion made it sound like /etc/openrc-version always existed
independent of libexec
That is incorrect.
Thanks
Roy
Mike Frysinger wrote:
On Monday 08 June 2009 06:35:37 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing
Joe Peterson wrote:
Mike Frysinger wrote:
maybe, but since we arent going to use /libexec/ at this time, that means /etc
is the next best place
How about /usr/share/openrc/version?
The only dirs that are guaranteed to be available at boot are
/dev
/etc
/lib
/bin
/sbin
Plus these OS specifi
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires us to actually utilize /libexec/ which is not a Linux convention
on any s
Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
Roy: [[ or [?
Entirely depends on system.
OpenRC uses /bin/sh to process the actual init script. We rely on /bin/sh
claiming POSIX compat [1]. On Gentoo Linux systems, this is normally a link
to bash, so you
Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 12:02:44AM +0200, Ulrich Mueller wrote:
On Sun, 7 Jun 2009, Robin H Johnson wrote:
2. Right now, every init.d script that needs to detection should revbump
and change to the following:
[[ -f /lib/librc.so -o -f /etc/init.d/sysfs -o -f /libex
Josh Saddler wrote:
Also, if OpenRC/baselayout is dropping support for things like PPP or
ADSL[1], and will not guarantee a "stable" configuration (i.e. as
"final" as baselayout-1 has been, not needing constant user-side
updates)[2] . . . then we need to find some other solution for our users.
Robert Buchholz wrote:
> On Saturday 23 May 2009, Roy Marples wrote:
>> Basically as Doug said, each OpenRC version comes with a few big
>> chances. Well not massive as in "your box will break now", but just a
>> different spin on how things should work. OpenRC-0.5 w
# Assign static IP addresses and run custom scripts per interface.
# Seperate commands with ;
# Prefix with ! to run a shell script.
# Use \$int to represent the interface
#ifconfig_eth0="192.168.0.10 netmask 255.255.255.0"
# You also have ifup_eth0 and ifdown_eth0 to run other commands when
# et
Mike Auty wrote:
> Roy Marples wrote:
>> Attached is the new conf.d/net sample.
>
> Sorry, I missed those. Did lists.g.o remove them, or were they not
> attached?
>
>> As such, a side project I've started is a new ifconfig tool
>> [1] to handle everything f
Roy Marples wrote:
> One side effect of this is that daemons such was wpa_supplicant and PPP
> are now init scripts proper - this is good. The only downside is that
> you lose the ability to control each interface via init.d. Instead I
> propose you control this via ifconfig.
Uh, s
Alin Năstac wrote:
> Doug Goldstein wrote:
>> The only reason why OpenRC has not come up for stabilization by it's
>> maintainers is the fact that everytime there's a new version readied
>> for release, on the horizon there's new incompatible changes being
>> planned for the next version. The OpenR
On Thursday 19 June 2008 02:43:12 Chris Gianelloni wrote:
> Nope. What I see as a problem is that the primary author and current
> de facto maintainer is so much of an asshole that he was forcibly
> removed from the Gentoo project, which PMS is supposed to be written
> for, and has ostracized (at
On Friday 13 June 2008 02:13:19 David Leverton wrote:
> The pkgcore was (or should have been) highly obvious to anyone who had
> so much glanced at the offending code.
Good behaviour
Hey - I found this bug in your code.
Here's a patch!
Bad behaviour
Hey guys - stop using Foo as it has a highly ob
On Wednesday 11 June 2008 19:00:16 David Leverton wrote:
> On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> > David Leverton <[EMAIL PROTECTED]> wrote:
> > > Since at least one ebuild has already been modified specifically to
> > > work around the bug, I'd say it's pretty real.
> >
> > For tho
On Monday 09 June 2008 09:06:24 Ciaran McCreesh wrote:
> So how, specifically, is PMS "wrongly written", and why hasn't anyone
> who thinks so bothered to provide details?
Probably because you have such a long history of saying "it's broken" without
providing any details. Even when asked you some
On Saturday 31 May 2008 00:16:31 Ciaran McCreesh wrote:
> > Ok, then everything in the tree is covered and we can move to having
> > --as-needed as default.
>
> Is the next version of everything in the tree covered? Have you made
> sure that software isn't merely working by fluke?
We interupt thi
On Wednesday 23 April 2008 23:01:38 Graham Murray wrote:
> Roy Marples <[EMAIL PROTECTED]> writes:
> > On Wednesday 23 April 2008 21:46:18 Robin H. Johnson wrote:
> >> See my attached example from work, we use a lot of the various options
> >> on stuff.
> >
On Thursday 24 April 2008 00:01:01 Robin H. Johnson wrote:
> The problem in this is that you cannot set the properties for each
> address or route. Please don't take us back to the stoneage of writing
> the advanced networking configuration manually.
>
> As an example of an ip address line with pro
On Wednesday 23 April 2008 21:46:18 Robin H. Johnson wrote:
> On Wed, Apr 23, 2008 at 04:21:27PM +0100, Roy Marples wrote:
> > OK, it seems that hard lines in multipart configs seem to be an issue, so
> > I'm doing this now.
> >
> > For a summary of why we'
On Wednesday 23 April 2008 19:46:35 Joe Peterson wrote:
> Roy Marples wrote:
> > config_eth0="1.2.3.4 netmask 255.255.255.0
> > 5.6.7.8 netmask 255.255.0.0"
> > routes_eth0="1.2.4.0 netmask 255.255.255.0 gw 1.2.3.6
> > 5.6.7.9 gw 5.6.7.10
> > defa
OK, it seems that hard lines in multipart configs seem to be an issue, so I'm
doing this now.
For a summary of why we're using hard lines you can read this thread
http://thread.gmane.org/gmane.linux.gentoo.devel/45756/focus=45765
Basically, just using whitespace to seperate configs is nice and s
On Monday 24 March 2008 22:03:48 Mike Frysinger wrote:
> we're going to need to extend the syntax anyways to allow for
> per-version-per-module arguments. unless openrc does that now ... Roy ?
It now supports per module per kernel version arguments.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org ma
On Friday 21 March 2008 12:39:48 Natanael Copa wrote:
> /* pid 1 is most likely owned by root */
> hardened = pid_is_running(1);
> if (!hardened || (hardened && euid==0) {
OK, we'll go with that for the time being.
Thanks
Roy
--
gentoo-dev@lists.gentoo.org mailing list
On Friday 21 March 2008 10:44:12 Natanael Copa wrote:
> err... run rc-status as root?
>
> I mean if you are not supposed to see if a process is running or not as
> normal user, then hardned is doin it's job when does not allow rc-status
> to show this info to the unprivileged user.
>
> if (!HARDENE
On Friday 21 March 2008 10:37:11 Fabian Groffen wrote:
> Assuming you would use libkvm, on Darwin this means as unprivileged user
> (not using suid) you can't see any processes at all.
That's different from FreeBSD and NetBSD then.
>
> > This isn't really an easy answer, as we could have installe
Hi List.
I've just removed the code to check for euid when running services and instead
relying on permissions of the service state dir and testing errno. This is a
good thing, but it does have one side effect.
OpenRC can track daemons by how they were started. So every time you run
rc-status
On Thursday 20 March 2008 06:59:24 Josh Saddler wrote:
> I'll be working on the migration guide with Cardoe (and possibly Roy, if
> we can tag-team him into submission). As much of a pain as migration
> will be, we'll definitely need a howto. Fun, fun.
I already provide documentation with commands
On Monday 10 March 2008 05:21:51 Alec Warner wrote:
> Did freeBSD not care if you knew what you were doing? What happens if
> you totally screw up your package? What happens if you do something
> malicious?
Gentoo has a cvs-commit mailing list, so everyone knows if they care enough.
I suggest y
OK, this the only release post I'll make here :)
OpenRC-0.1 has been released. It successfully boots Gentoo/Linux,
Gentoo/FreeBSD, FreeBSD-7 and NetBSD-4. It works (for me) in an unprivileged
prefix as well. It's pretty much feature complete for a first release.
What's left is fixing any outsta
On Wednesday 05 March 2008 17:11:58 Anant Narayanan wrote:
> If it's not too late for this month's meeting, I'd like to discuss the
> possibility of including a new "post" in our developer base - the
> package maintainer.
>
> a) The requirements to become a package maintainer for Gentoo may be
> le
On Mon, 03 Mar 2008 16:50:49 +0100, Michael Haubenwallner
<[EMAIL PROTECTED]> wrote:
> For hpux fex this just is adding some symlinks:
> /sbin/init.d/name -> /my/prefix/sbin/init.d/distccd
> /sbin/rc3.d/S990name -> /sbin/init.d/name # to start in runlevel 3
> /sbin/rc2.d/K100name -> /sbin/init.d
On Mon, 3 Mar 2008 15:53:20 +0100, Fabian Groffen <[EMAIL PROTECTED]>
wrote:
> On 03-03-2008 13:36:25 +0000, Roy Marples wrote:
>> On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
>> > So the only thing left (aside from bug fixing) is to instruct OpenRC
>&g
On Thursday 28 February 2008 11:22:13 Roy Marples wrote:
> So the only thing left (aside from bug fixing) is to instruct OpenRC
> dependency
> code that it's in a prefix and to respect the noprefix keyword in services,
> or
> to provide dummy services.
This is now done.
On Saturday 01 March 2008 22:26:24 Ed W wrote:
> Hmm, all interesting stuff
>
> You mention in the notes also that openrc has some kind of "keepalive"
> function which can restart crashing services. Can point me towards how
> that works (assuming it needs some kind of config?)
No such function :)
On Friday 29 February 2008 23:23:34 Ed Wildgoose wrote:
> > [2] I use busybox as a shell and can support it when it's internal
> > start-stop-daemon applet disabled (as OpenRC has it's own variant).
>
> I guess I could just check it out instead of asking but What's
> missing from the busybox s
On Friday 29 February 2008 18:32:44 Stefan Hellermann wrote:
> I just tried openrc and I really like it! All the things changed from
> baselayout-2.0.0-rc6 are really good ideas! good work! Thanks!
:)
> Two small things happened here:
>
> After Login I the shell looks like:
> -bash-3.2#
> when I
On Friday 29 February 2008 16:15:51 Ed W wrote:
> On the other hand since there still isn't a masked ebuild in portage
> (and I seem some notes on my on Roy's site) then I have to assume that
> in fact we are still a good way away from calling it a replacement and
> starting to push it out to users
On Friday 29 February 2008 15:56:44 Ed W wrote:
> Alon Bar-Lev wrote:
> > Check out OpenRC it is baselayout successor and works great!
>
> Funnily enough I came across this earlier today for different reasons.
> However, I hadn't realised that it was a full baselayout competitor?
>
> Does Roy hang
On Wed, 27 Feb 2008 15:21:58 +0100, Fabian Groffen <[EMAIL PROTECTED]>
wrote:
> I'm not sure how far OpenRC actually can
> deal with unprivileged installs, so that are just things we have to find
> out along the way.
Provided you have permissions to start the configured programs, then it's
fine.
On Wednesday 27 February 2008 14:21:58 Fabian Groffen wrote:
> On 27-02-2008 13:56:51 +0000, Roy Marples wrote:
> > On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen <[EMAIL PROTECTED]>
> >
> > wrote:
> > > Well... that's great! But a jail or a (ch)r
On Wed, 27 Feb 2008 13:29:15 +0100, Fabian Groffen <[EMAIL PROTECTED]>
wrote:
> Well... that's great! But a jail or a (ch)root is in general not the
> same as a "prefix".
No, but it's the same kettle of fish as chroots, jails and vps systems -
basically
there is a need to disable dependencies th
On Wed, 27 Feb 2008 09:42:05 +0100, Fabian Groffen <[EMAIL PROTECTED]>
wrote:
> - baselayout porting to Prefix (mostly the start stop mechanisms)
What start stop mechanics do you mean?
OpenRC already has full FreeBSD jail support in services like do
depend() { keyword nojail; }
That effectively
On Monday 18 February 2008 21:20:52 Donnie Berkholz wrote:
> > @@ -614,7 +614,7 @@
> > # @DESCRIPTION:
> > # DEPRECATED - Gets the flags needed for "NOW" binding
> > bindnow-flags() {
> > - ewarn "QA: stop using the bindnow-flags function ... simply drop it
> > from your ebuild" + ewarn "QA: s
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
> In my opinion WIPE_TMP should be in the same state
> as RC_PARALLEL_STARTUP.
That's a fair point.
Luckily, the all the Gentoo init scripts that all my computers use are
now at the stage where we could easily flick parallel startup on by
On Fri, 2008-01-18 at 06:41 -0500, Mike Frysinger wrote:
> right, there is no way (by design) to force these settings on an already
> created user. if the old path really truly should not be the old value, you
> can do something like this in pkg_setup:
> if [[ $(egetent passwd user | cut -d: -f
On Wednesday 09 January 2008 18:16:24 Ciaran McCreesh wrote:
> On Wed, 09 Jan 2008 17:27:52 +
>
> Roy Marples <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
> > > 3.5.5 was good enough to be keyworded stable at one point.
On Wed, 2008-01-09 at 17:01 +, Ciaran McCreesh wrote:
> 3.5.5 was good enough to be keyworded stable at one point. Thus, it
> can't be *that* bad.
So what happens if a flaw is discovered in KDE 3.5.5 that allows root
access?
In your world you allow mips users to trivially install now flawed a
On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote:
> while is_older_than is negotiable, removing KV_* is not. those are pretty
> tight utility functions which duplication in $random-packages will only lead
> to problems (especially considering the history of making sure they were
> coded
On Thu, 2008-01-03 at 16:24 +, Roy Marples wrote:
> On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
> > it also means a deprecation notice needs to be added here and everywhere
> > else
> > that has changed. perhaps create a small script that takes
> >
On Thu, 2008-01-03 at 10:50 -0500, Mike Frysinger wrote:
> it also means a deprecation notice needs to be added here and everywhere else
> that has changed. perhaps create a small script that takes
> the /etc/modules.autoload.d/ directory and converts it into the
> corresponding /etc/conf.d/mod
On Thu, 2008-01-03 at 10:18 +, Richard Brown wrote:
> While this thread remains highly entertaining, I'm sure as a past
> gentoo developer Roy remembers that we don't generally use gentoo-dev
> to bug fix poorly written makefiles, we have a bugzilla where people
> interested in fixing it can he
On Thu, 2008-01-03 at 09:50 +, Roy Marples wrote:
> On Thu, 2008-01-03 at 10:58 +0200, Alon Bar-Lev wrote:
> > At: default.mk, the _SUBDIR loop is somehow incorrect, as it will not
> > pass subdir make result to rule.
> > So if rule fails the build still considered a suc
On Thu, 2008-01-03 at 12:02 +0200, Alon Bar-Lev wrote:
> On 1/3/08, Roy Marples <[EMAIL PROTECTED]> wrote:
> > I knew there was a reason for not adding digests :)
> > I've removed them for now.
>
> Why remove?!?!?!
> This way we cannot use layman in order
On Thu, 2008-01-03 at 10:58 +0200, Alon Bar-Lev wrote:
> At: default.mk, the _SUBDIR loop is somehow incorrect, as it will not
> pass subdir make result to rule.
> So if rule fails the build still considered a success.
>
> make[1]: *** [start-stop-daemon.o] Error 1
> make[1]: *** Waiting for unfi
On Wed, 2008-01-02 at 20:38 -0800, Nathan Smith wrote:
> On Tue, 01 Jan 2008 12:41:00 +
> Roy Marples <[EMAIL PROTECTED]> wrote:
>
> > Hi List
> >
> > 2008 is here and it's time for some change!
> >
> > OpenRC is now ready for testing.
On Thu, 2008-01-03 at 08:43 +0200, Alon Bar-Lev wrote:
> Again...
> !!! Digest verification failed:
> !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 3666
> !!! Expected: 3629
I knew there was a reason for not
On Wed, 2008-01-02 at 17:52 +0100, Santiago M. Mola wrote:
> On Jan 1, 2008 1:41 PM, Roy Marples <[EMAIL PROTECTED]> wrote:
> >
> > I'd appreciate a lot of testing, and just email this thread or me saying
> > that it works or there's a bug. Hopefully we can get
On Wed, 2008-01-02 at 17:15 +0200, Alon Bar-Lev wrote:
> On 1/2/08, Roy Marples <[EMAIL PROTECTED]> wrote:
> > Those functions were removed from functions.sh as only update-modules
> > still uses them. udev does use KV_to_int though. I don't really want to
> > add t
On Wed, 2008-01-02 at 16:39 +0200, Alon Bar-Lev wrote:
> On 1/1/08, Roy Marples <[EMAIL PROTECTED]> wrote:
> > > It took me some time to find /etc/conf.d/modules, but it's certainly
> > > useful :).
> >
> > It also means all config files, with the excep
On Tue, 2008-01-01 at 20:16 +0100, Thomas Pani wrote:
> Works fine here (x86). Having set both RC_{QUIET,VERBOSE}="no" it's a
> little more verbose than what I'm used to (especially udev loading
> madwifi) but that's early enough in the boot sequence not to bug me.
That's a udev issue, not a basel
On Tue, 2008-01-01 at 12:04 -0600, William Hubbs wrote:
> On Tue, Jan 01, 2008 at 05:19:39PM +0000, Roy Marples wrote:
> > Some scripts do run before checkroot, such as clock. clock should be the
> > first script started, so if you want it to go really early then
>
> M
On Tue, 2008-01-01 at 19:22 +0200, Alon Bar-Lev wrote:
> Thanks for adding digest, but:
>
> Calculating dependencies /!!! Digest verification failed:
> !!! /usr/portage/local/layman/openrc/sys-apps/openrc/openrc-.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 3629
> !!!
On Tue, 2008-01-01 at 11:11 -0600, William Hubbs wrote:
> On Tue, Jan 01, 2008 at 12:27:24PM +0000, Roy Marples wrote:
> > Just make a standard init script for it with this dependency block
> >
> > depend() {
> >before checkfs
> > }
>
> Would it be
On Tue, 2008-01-01 at 18:55 +0200, Alon Bar-Lev wrote:
> Thanks!
> Works!
>
> Roy, why didn't you digest and commit the files?
Dunno. Have now done so.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Uh, forgot the link :)
http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary
--
[EMAIL PROTECTED] mailing list
Hi List
2008 is here and it's time for some change!
OpenRC is now ready for testing. There are no ebuilds in the tree, but
some are available here [1] that offers a baselayout-2 shell that pulls
in openrc-. I'll just offer a git ebuild for the time being, so bugs
can be fixed fast without hav
On Mon, 2007-12-31 at 14:50 -0600, William Hubbs wrote:
> brltty is one of our accessibility packages. It is a program that
> drives a braille display which is one way a blind person can access the
> computer.
>
> The project's guidelines for linux distributions at
> http://www.mielke.cc/brltty
On Sat, 2007-12-29 at 23:20 +, Ciaran McCreesh wrote:
> On Sun, 30 Dec 2007 00:16:22 +0100
> Federico Ferri <[EMAIL PROTECTED]> wrote:
> > sorry if this has already suggested.
>
> It has. It solves nothing.
>
If it solves nothing you should at least post a link to the post you
made explaini
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 18:03:27 +
> Roy Marples <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote:
> > > Or to put it another way, you're objecting to painting the ho
On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote:
> Or to put it another way, you're objecting to painting the house pink
> rather than green because you don't like pink (because your last house
> was green too), ignoring that it's been demonstrated that when painted
> green, it's impossibl
On Thu, 2007-12-27 at 16:50 +, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 16:45:06 +
> Roy Marples <[EMAIL PROTECTED]> wrote:
> > > Alright, so where would you stick EAPI such that all the
> > > requirements that've previously been described are met
On Thu, 2007-12-27 at 16:32 +, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 15:04:52 +
> Roy Marples <[EMAIL PROTECTED]> wrote:
> > I understand that metadata in a file name is pure and simple hackery
> > that has no place here and the GLEP is a flimsy attempt to
On Thu, 2007-12-27 at 16:39 +0100, Jan Kundrát wrote:
> Roy Marples wrote:
> > I understand that metadata in a file name is pure and simple hackery
> > that has no place here and the GLEP is a flimsy attempt to justify it.
>
> Do you count "version" as metad
On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote:
> On 12/25/07, Roy Marples <[EMAIL PROTECTED]> wrote:
> > > Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
> > > 1 environment, or what?
> >
> > If it's that such a big dea
On Tue, 2007-12-25 at 15:51 +0800, Shyam Mani wrote:
> PS : Aam chahiye kya? :)
>
> Note : The above line means "Do you want a Mango?" in Hindi. If any of
> you *ever* meet Seemant, don't forget to ask him this :D
It's what he does with it that scares me o_O ;)
Roy
--
[EMAIL PROTECTED] mailing
On Tue, 2007-12-25 at 02:43 -0500, Ciaran McCreesh wrote:
> On Dec 25, 2007 2:38 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> > > On Dec 24, 2007 7:53 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> > &g
On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> On Dec 24, 2007 7:53 AM, Roy Marples <[EMAIL PROTECTED]> wrote:
> > So to obtain EAPI from .ebuild you would always do
> > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
>
> Doesn't work wi
On Mon, 2007-12-24 at 19:52 -0800, Robin H. Johnson wrote:
> The CVS stuff should have been locked out already, not sure how you
> tested that.
I didn't.
I assumed that as I had access to d.g.o, I had CVS access too.
My bad.
> The Git stuff is coming very shortly (probably as a Christmas gift fro
On Mon, 2007-12-24 at 21:39 +, Duncan wrote:
> Apparently, at present, pretty much the only one with access
> is the one who actually did the port, and he's hasn't done much with it
> since.
I beg to differ - I've down an awful lot with the code.
It now installs and works cleanly on a vanill
Just picked this particular email to reply with my thoughts on this
thread.
On Mon, 2007-12-24 at 10:52 +, Steve Long wrote:
> But they come under the scope of this discussion, since this is about the
> long-term future of *every* EAPI. So let's discuss them
Impossible. History has proven aga
On Thursday 13 December 2007 10:17:07 Peter Volkov wrote:
> В Чтв, 13/12/2007 в 09:41 +0000, Roy Marples пишет:
> > On Thursday 13 December 2007 09:18:45 Peter Volkov wrote:
> > > use arrays.
> >
> > Why not use a function in pkg_setup as suggested earlier
>
&g
On Thursday 13 December 2007 09:18:45 Peter Volkov wrote:
> 2. Modify ebuilds to use arrays.
>
> -FONT_CONF="path1 path2"
> +FONT_CONF=( "path1" "path2" )
Why not use a function in pkg_setup as suggested earlier and pass each path
component as $1, $2, etc. Then the ebuild itself doesn't actually
On Tuesday 11 December 2007 11:14:49 Peter Volkov wrote:
> > That way you work the same way as the classic $PATH variable.
>
> But this seems to fail if we have ':' inside path{1,2}. Is that true?
> For PATH the same question stands, but I think that ':' is used there
> for historical reasons.
Yes
On Tuesday 11 December 2007 08:44:51 Donnie Berkholz wrote:
> Roy solved a similar problem in baselayout-2 using hardcoded newlines,
> although it had the additional constraint of sh compatibility. It's
> worth considering code clarity between that and arrays.
Only because some commands could litt
On Tuesday 11 December 2007 08:17:12 Peter Volkov wrote:
> Some eclasses (kernel-2, font) use variable to pass space separated PATH
> to patch or fontconfig files from ebuild to eclass. In ebuild we use:
>
> FONT_CONF="path1 path2"
>
> Then eclasses use the variable:
>
> for conffile in ${FONT_CONF
On Tue, 2007-11-06 at 08:03 +, Ciaran McCreesh wrote:
> On Tue, 06 Nov 2007 07:40:20 +
> Roy Marples <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote:
> > > Except it won't, because ebuilds require bash regardless o
On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote:
> Except it won't, because ebuilds require bash regardless of which
> package manager is being used. If you want to change that you'll have to
> rewrite the entire tree.
Az once said near enough the same thing about baselayout. And that's
y
On Mon, 2007-11-05 at 16:21 -0400, Mike Frysinger wrote:
> we want the installed environment to be portable, not the build environment.
> i do not see any benefit from forcing the build environment to be pure POSIX
> compliant and i see many many detrimental problems.
Oh I don't know. Imagine h
On Mon, 2007-11-05 at 14:21 +0100, Michael Haubenwallner wrote:
> > Actually you missed the mark completely.
> > Nothing in the tree itself specifies what shell to use - instead it's
> > the package manager. So the PM on Gentoo/Linux/FreeBSD *could*
> > be /bin/sh and on the systems where /bin/sh
While I still have access to the [EMAIL PROTECTED] email, I'll respond here.
On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote:
> On Sat, 2007-11-03 at 00:47 +0000, Roy Marples wrote:
>
> As it seems too few people really accept your suggestion, I feel it's
>
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
> On 02-11-2007 17:35:08 +0000, Roy Marples wrote:
> > I don't see them as inferior.
> > I see them as more portable and less confusing.
>
> Please stop calling it "more portable". The shell code yo
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
> Please stop calling it "more portable". The shell code you see in
> configure can in a way be called "portable". Your POSIX compliant stuff
> isn't. In fact, by stating #!/bin/sh you actually make the code useless
> on a number of platfo
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote:
> On 02-11-2007 17:35:08 +0000, Roy Marples wrote:
> > I don't see them as inferior.
> > I see them as more portable and less confusing.
>
> Please stop calling it "more portable".
But is it more por
On Fri, 2007-11-02 at 18:17 +0100, Bo Ørsted Andresen wrote:
> On Friday 02 November 2007 17:52:13 Roy Marples wrote:
> > On Fri, 2007-11-02 at 17:30 +0100, Bo Ørsted Andresen wrote:
> > > Please explain why you hijack this thread to discuss POSIX vs. bash when
> > > it
On Fri, 2007-11-02 at 17:30 +0100, Bo Ørsted Andresen wrote:
> Please explain why you hijack this thread to discuss POSIX vs. bash when it's
> supposed to be about the API for ebuilds.
I dislike the gratuitous use of bash for no good reason - and in the
code he gave there is no good reason for us
1 - 100 of 393 matches
Mail list logo
