Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 via the filesystem. the point of this thread is to detect baselayout-1 vs openrc only. RC_VERSION is available in 0.5.0 However, for VServer it needs to be easily available without running anything, hence this discussion. if it's in the execution environment of the init.d script,nothing was run -mike You would have to ask the VServer team, but my understanding was they needed to detect version of OpenRC in a container from the host before the container is started. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 only. RC_VERSION is available in 0.5.0 However, for VServer it needs to be easily available without running anything, hence this discussion. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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. However, there was, or will be, a need to detect OpenRC version as well which that doesn't address. I don't know if that is needed right now though. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
Mike Frysinger wrote: the original discussion made it sound like /etc/openrc-version always existed independent of libexec That is incorrect. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 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 system ive ever seen. OpenRC works on systems other than Linux and uses the best hierarchy it can to match them all. i know why you use it, but that doesnt mean Gentoo (Linux) should rhetorical: Should Gentoo (FreeBSD)? that's for the Gentoo/BSD team to decide So you're now advocating the check being [ -f /etc/openrc-version -o -f /libexec/rc/version ] Way to go. Also, should Gentoo (Linux) never break with tradition even if somethings are better elsewhere? no, there is no "innovation" here nor any incentive to do so. i also personally dont believe in /usr/libexec/, so i'm not going to randomly be convinced by /libexec/ in the meantime. The "innovation" here being shell scripts and text files are not 32/64 bit dependent and thus don't belong in a directory clearly marked as such. Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have to move the version file in the ebuild as it just won't work when you pass LIBEXECDIR=/lib/rc to the make targets. if the make system doesnt have a way of controlling the root libexecdir path, sounds like the make system is limited and/or broken and in need of fixing Eh? I just told you it does. To keep the status quo with /libexec/rc vs /lib/rc I provide a make knob. Now you want to move 1 specific file out of /lib/rc (because it could be in /lib64 or /lib32 and not in /lib) and into /etc because of the /lib brokenness. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 specific dirs /proc (Linux) /sys (Linux-2.6) /libexec (the BSD family) Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 us to actually utilize /libexec/ which is not a Linux convention on any system ive ever seen. OpenRC works on systems other than Linux and uses the best hierarchy it can to match them all. i know why you use it, but that doesnt mean Gentoo (Linux) should rhetorical: Should Gentoo (FreeBSD)? Also, should Gentoo (Linux) never break with tradition even if somethings are better elsewhere? Note, I'm not pushing for Gentoo to use /libexec at all, but you'll have to move the version file in the ebuild as it just won't work when you pass LIBEXECDIR=/lib/rc to the make targets. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 system ive ever seen. OpenRC works on systems other than Linux and uses the best hierarchy it can to match them all. Linux has /usr/libexec and I see no reason why it cannot exist on / for when /usr is not available like other OS's do. Robin asked for an upstream decision of where to place the version file and in the OpenRC world the best place is /libexec as /etc is just meant for user configuration. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 can use bashisms if you so wish. Is "[[" a bashism or not? That's all I'm asking. What's a good way to test for POSIX compatibility so that the testing CAN actually be done. My testcase was 'bash --posix'. Testing under busybox's ash seems to work perfectly with "[[" as well. bash(1) only documents the --posix option to modify how bash starts up. It does not mention restricting bash extensions such as [[ IIRC vapier patched busybox to alias [[ to [, which is worse as you still have to quote correctly as if [ and you don't get the =~ operator from [[. But as you asked, here's what the good doc [1] has to say The following words may be recognized as reserved words on some implementations (when none of the characters are quoted), causing unspecified results: [[ ]] function select In other words, I won/t make any claims whether [[ ]] works in OpenRC. That doesn't answer if it's a bashism. I interpret that part of the document to simply be that it's implementation detail is not covered by the POSIX spec. If it's not in the spec, then it has to be an extension. Thus, if bash is extending it then it's a bashism. I'm all for going with something that will work more globally, IFF it can be easily tested for (on pure Gentoo Linux machines, which is what most developers are running, because they won't be bothered to test under G/FBSD or Prefix/OSX etc), vs. just going by what the specification says. The only available shell on Linux that doesn't do anything other than the POSIX spec is dash. However, even that shell is not entirely compliant (a few missing features last I looked). Just Do What The Fuck You Like, Just Don't Bug Me pretty much somes up my attitude right now. Why do I have this attiude? Well, bug #175783 is a very good example. It's over two years since I submitted replacement scripts and did more besides. It's just like the courier-imap fiasco when baselayout-1.12 was touted for stable, but this time I Just Don't Care. There hasn't been any release of the mysql-init-scripts in 2 years. It's not that anything contrary to your opinions has been done on that bug, it's more that I haven't have any specific need to fix that package yet. Other than the need to actually allow mysql to work on Gentoo/FreeBSD. Ah, you've already said that you don't want to run anything other than Linux. Fine, that's your choice, but please hand mysql over to someone who cares about Gentoo running on alternative OS's as you've just demonstrated you just don't care. Thanks Roy
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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 /libexec/rc/version ]] Wasn't the convention for init scripts to use only single square brackets, i.e. POSIX shell syntax? That was raised in the bug as well. My testing was with bash --posix, so if that doesn't implement POSIX correctly, then yes, we'd need to change. 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 can use bashisms if you so wish. However, on Gentoo FreeBSD systems, or Gentoo Embedded systems that predominately use busybox then the bashisms won't obviously work. So the question becomes, does the init script developer want to support non bash by default systems? Franky, I've given up on trying to enforce anything POSIX related over something else (like say GNU or implementation extensions over an accepted standard). I just don't care. I used to, but developer and user backlash (see the archives) was just too much for me and was one of the resaons why I retired from Gentoo. Just Do What The Fuck You Like, Just Don't Bug Me pretty much somes up my attitude right now. Why do I have this attiude? Well, bug #175783 is a very good example. It's over two years since I submitted replacement scripts and did more besides. It's just like the courier-imap fiasco when baselayout-1.12 was touted for stable, but this time I Just Don't Care. But as you asked, here's what the good doc [1] has to say The following words may be recognized as reserved words on some implementations (when none of the characters are quoted), causing unspecified results: [[ ]] function select In other words, I won/t make any claims whether [[ ]] works in OpenRC. Thanks Roy [1] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646)
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. Just to clarify - net.lo and friends, along with bash specific configs are NOT going away. They're just not actively being developed with new features, nor will they get priority for any fixes. However, net.lo nor the modules are installed by default (MKOLDNET=yes is required). So existing documentation works just fine. Also, writing documentation to support things like ADSL and PPP now entirely depends on upstream working with new stuff. For example, wpa_supplicant does not react by itself to hotplugged interfaces and the new OpenRC network script no longer supports per interface start/stops. This is a problem, and I've spent some time working on patches to wpa_supplicant for this, but upstream is not sure about the whole idea. If upstream doesn't ever want to slow down, wants to constantly stick in new features, try out new things, that's all well and good. More power to 'em. But I think that is ultimately not such a good thing for our users. Especially if it means constantly dropping support for features, sacrificing compatibility, etc. We're already having enough trouble trying to ensure future Portage compatibility via EAPIs, we should not add in a potential baselayout/OpenRC mess atop that. Development on OpenRC has slowed down a lot of late, mainly as most of my goals of where it should go have now been met. And with moving networking to a very simple script, future changes will only be on a per init script basis. As OpenRC just supplies enough init scripts to boot a basic system any future changes will be in the init scripts themselves and thus removed from OpenRC specific documentation. Of course that doesn't stop various upstreams that Gentoo uses from totally changing their user interface. Oh, yes . . . and there's the workload it would put on the GDP folks. We already have a helluva time running around chasing devs down and prying out straight answers about what to update in the existing documentation. We'd probably all quit if we had to do the same thing for every new openrc/baselayout release. You could always try writing the code instead ;) Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
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 will have the >> biggest re-spin to date - net.lo (net.eth0 etc) is considered >> deprecated. > > If future changes of this magnitude are still expected, I wonder if we > want to go stable with OpenRC anytime soon. I do not intend to hinder > fast progress and design changes in OpenRC in any way, but if its > design is not considered final, I suggest we do not make it the default > recommandation for our users. Let us be clear on one point - net.lo and friends are still somewhat supported upstream, just no future development will take place on them. The network script is just the preferred default as it makes my life a lot easier and places the support burden onto the maintainers of the various utils needed to be used directly. It's also a lot faster :) I don't expect any more userland changes before the move to OpenRC-1.0 There are two features on the cards - rc events [1] and feature removal for space limited embedded systems (basically dependecy is only used to order scripts on initial startup, reducing /sbin/rc and /sbin/runscript to shell stubs the aim on saving 75k on the binary size. > Marking it stable might also be contraproductive for upstream since > revised configurations need to stay supported a lot longer than they > would had they been used only by ~arch users. If there is a real drive to make OpenRC stable then I suggest that I roll openrc-0.5.0 out sometime this week and try to roll rc events into 0.6.0, the embedded stubs into 0.7.0 and we'll go from there. I know that Cardoe has been busy in RL of late and I've never pressed or been pressed into considering it stable. However, real bug reports and new feature implementations have slowed somewhat, so either it's Ready For Stable or no-ones using it. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
# 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 # eth0 is started and stopped. # You should note that we don't stop the network at system shutdown by default. # If you really need this, then set shutdown_network=YES # You can assign a default route #defaultroute="192.168.0.1" # Lastly, the interfaces variable pulls in virtual interfaces that cannot # be automatically detected. #interfaces="br0 bond0 vlan0" # You can also use files instead of variables here if you like: # /etc/ifconfig.eth0 is equivalent to ifconfig_eth0 # /etc/ip.eth0 is equivalent to ifconfig_eth0 # /etc/ifup.eth0 is equivalent to ifup_eth0 # /etc/ifdown.eth0 is equivalent to ifdown_eth0 # Any files found will automatically be put into the interfaces variable. # You don't need to escape variables in files, so use $int instead of \$int. # If you require DHCP, you should install dhcpcd and it to the boot or # default runlevel. # ifconfig under Linux is not that powerful and doesn't easily handle # multiple addresses # On the other hand, ip (iproute2) is quite powerful and is also supported #ip_eth0="192.168.0.10/24; 192.168.10.10/24" # Create a bonded interface #interfaces="bond0" #ifup_bond0="modprobe bonding; ifconfig \$int up; ifenslave \$int bge0" #ifconfig_bond0="192.168.0.10 netmask 255.255.255.0" #ifdown_bond0="rmmod bonding" # Create tap interface and a bridge interface. # We add the tap to the bridge. # An external program, like dhcpcd, will configure the IP on the bridge #interfaces="tun0 br0" #ifup_tun0="tunctl -t \$int" #ifdown_tun0="tunctl -d \$int" #ifup_br0="brctl addbr \$int; brctl add \$int eth1; brtctl add \$int eth2" #ifdown_br0="ifconfig \$int down; btctl delbr \$int" # Create VLAN #interfaces="eth0_2 eth0_3 eth0_4" #ifup_eth0="vconfig add \$int 2; vconfig add \$int 3; vconfig add \$int 4" #ifconfig_eth0_2="192.168.2.10 netmask 255.255.255.0" #ifconfig_eth0_3="192.168.3.10 netmask 255.255.255.0" #ifconfig_eth0_4="192.168.4.10 netmask 255.255.255.0" #ifdown_eth0="vconfig rem \$int.2; vconfig rem \$int.3; vconfig rem \$int.4" # Normally you would use wpa_supplicant to configure wireless, but you can # use iwconfig also #ifup_wlan0="iwconfig \$int key s:secretkey enc open essid foobar"
Re: [gentoo-dev] Baselayout 2 stabilisation todo
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 from vlans, to bridging, to bonding, to >> wireless (up to WEP) with a similar syntax to the BSD ifconfig. > > Also [1]'s missing, and I couldn't find it at http://roy.marples.name/. > Where should I be looking? > >> This decision is heavily influenced by NetBSD (disclaimer - I'm now a >> NetBSD dev). > > Congrats on becoming a NetBSD dev! 5:) Gah, posting just before bed! Anyway, attached and [1] was just a blog entry by me, not much more content than here. There's no project page as yet for ifconfig as it's display only right now. Thanks Roy [1] http://roy.marples.name/projects/self/blog/2009/04/19_ifconfig
Re: [gentoo-dev] Baselayout 2 stabilisation todo
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, so in summary any external daemons such as wpa_supplicant and PPP will be controlled fully by init scripts external to OpenRC. OpenRC may supply example init scripts, but not installed by default. Thanks Roy
Re: [gentoo-dev] Baselayout 2 stabilisation todo
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 OpenRC maintainers in Gentoo have >> always chosen to wait until OpenRC settles down a little bit. Now with >> the plan to drop support for certain features (ADSL and PPP support in >> the networking code), it's going to rewrite more Gentoo people to step >> up to develop and maintain this code. >> > rp-pppoe support should be removed because its scripts don't work well > under baselayout, but are you sure OpenRC mantainers also plan to drop > generic PPP support? I don't usually troll -dev anymore, but I feel urged to reply to this. 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 will have the biggest re-spin to date - net.lo (net.eth0 etc) is considered deprecated. Instead OpenRC now ships with network (provides net) which is a simple wrapper around calling ifconfig (or ip) and with the ability to run shell scripts. Attached is the new conf.d/net sample. You'll notice it's a lot smaller than the old one as it relies heavily on the user being able to read and understand man pages for userland tools requires to do the job. Now, the one weakness with this approach is that the Linux userland tools are quite frankly crap compared to the BSD counterparts. Why is there the need for many badly written tools to configure a network interface? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. However, work on this has stopped as a side product of this means I have to get some wpa_supplicant changes I have pushed upstream so it can start on any wireless interface - and when it appears (pcmcia, etc). 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. This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). FWIW, the only re-spin I have on my list is to remove dependencies from rc and runscript so that dependencies are only taken into account when rc is run and not for each script. Essentially, making rc and runscript light shell wrappers and removing a few tools so that it's smaller for space critical devices. Thanks Roy
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
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 least) one of the package manager's > development team with his constant not-so-subtle attacks. Quite > frankly, I'd prefer see Gentoo take control over the specification that > defines the most important single feature of Gentoo and remove the > non-Gentoo developers from its development. No offense, but you're not > a Gentoo developer any longer and you shouldn't have a say in how *we* > manage ourselves. You're more than welcome to contribute code, fork, or > whatever the hell you want. This is open source, after all, but that > doesn't mean you should be allowed to hold the position of power over > Gentoo that you've been granted. I would like to see Gentoo grow some balls and start banning people from -dev and other media used. I don't mean temporary bans, I mean for life. Yes, it's not nice. Yes, Gentoo should be open for all and encourage participation from all. However, some people have demonstrated time and time again over quite a number of years that they wont change no matter what. These people are posionous [1]. Whilst growing this set of balls, consider scrapping PMS I've yet to see any tangiable gain (from a user perspective) but plently of loss (developers, hair, temper). I'm leaving this list as I want no part in this any longer, so I won't read any replies. Thanks Roy [1] http://video.google.com/videoplay?docid=-4216011961522818645 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
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 obvious bug which *would* have been caught in automated testing. This is a clear demonstration that Foo sucks and you should use Bar! So which side of the coin landed here? Or is now Bad Good, Black White and hopefully you'll get run over at the next Zebra crossing? Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
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 those of us trying to play along at home, which one is this? > > http://tinyurl.com/4w4t69 Why the need for EAPI=1? A cursory glance shows nothing unusual. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
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 sometimes choose to ignore the question. How does it feel to be on the receiving end for a chance? Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
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 this thread with breaking news! A troll claims that future software packages may break! This reporter sure hopes that the developers in question actually tests packages before they commit. I, for one, welcome our new --as-needed Overlords. > Is Gentoo really that desperate to turn everyone into a ricer? Everyones ride should be pimped. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
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. > > > > No, we won't support that. However, we will bring back ip ranges for the > > last ocet like so > > 1.2.3.4-10/24 > > It looks to me as though you are intending to remove the capability to > set up complex network environments. No I'm not. I'm making it easy for simple configs AND complex ones. Just not through the same variable. > [1] But in my opinion, the baselayout-1 /etc/net.conf syntax is better than > that in baselayout-2. Though I have not yet migrated any of the systems > with complex networking to baselayout-2. Sadly, default scripts we ship have to work with shells other than bash. Of course, you're still welcome to use config_eth0 as a bash array as that still works and will for the foreseeable future. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
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 properties: > ${ext}.30/32 broadcast - scope host Correct as usual. However, the existing config_foo isn't going anyway anytime soon, so your power user config still works. However, it will be moving to the right place ifconfig_eth0 ip_addr_eth0 And we'll stop parsing it. You'll have to know the syntax for the module you're using. I'm going to trying to map between them which will make the code lighter and less error prone. > > An an example of a route with properties: > ${int}.192/27 dev bond0 mtu 1500 table internal scope link > (my normal mtu on the internal link is 9k, but part of the subnet runs > at 1500 for netbooting on dumb cards) You can do this with the BSD style syntax static_routes_bond0="int0 int192 defint" route_int0="${int}.0/8 dev bond0 table internal scope link" route_int192="${int}.192/27 dev bond0 mtu 1500 table internal scope link" route_defint="default via ${int}.2 bond0 table internal" Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
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're using hard lines you can read this thread > > http://thread.gmane.org/gmane.linux.gentoo.devel/45756/focus=45765 > > Do you plan to reimplement parsing of the complete ip syntax for > addresses and routes? Not at all. If I did then we're back to using newlines. Basically we need something like ipaddrs=address1 address2 address3 for addresses, and routes=dest gateway dest gateway dest gateway or routes=route1 route2 route3 route1=dest gateway route2=dest gateway route3=dest gateway for routes There will be no special ip or ifconfig parsing - it's a pita. especially trying to mange 2 variants of linux ifconfig onto iproute2 (and back) and trying to get the same style to work with BSD ifconfig. Been there, too much pain. So it's the simple route. Want anything more powerful, well we have the direct ifconfig_eth0= ip_eth0= directives. And if they don't work then use a pre-up. > > See my attached example from work, we use a lot of the various options > on stuff. No, we won't support that. However, we will bring back ip ranges for the last ocet like so 1.2.3.4-10/24 After seeing that I take it you'ed vote for the BSD named routing style? Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
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 > > default gw 1.2.3.1" > > If one choose to separate by lines, will tabs or spaces be allowed in > subsequent lines? Like: > > 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 > default gw 1.2.3.1" The point is to remove the hard newline, which you've kept in your examples. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] config_eth0 deprecated - new name?
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 simple. What's more is everyone understands it. With CIDR notation, this is possible. For routes, it's a little more tricky as there are two values in use. 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" "default gw 1.2.3.1") becomes 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 default gw 1.2.3.1" becomes address_eth0="1.2.3.4/24 5.6.7.8/16" routes_eth0="1.2.4.0/24 1.2.3.6 5.6.7.8 5.6.7.10 default 1.2.3.1" Or we could adopt the BSD routing notation and do this routes_eth0="route_foo route_bar" route_foo="1.2.4.0/24 1.2.3.6 metric 5" route_bar="default 1.2.3.1" Yes, I've used the same "routes_eth0" variable, but we can change it's syntax based on the existance of address_eth0/config_eth0. So what are peoples feelings on this? Are you happy with the names? address_eth0? addr_eth0? addresses_eth0? ipaddress_eth0? ipaddr_eth0? ipaddresses_ath0? routes_eth0? static_routes_eth0? Speak up, or I'll make a decision by myself which will probably be done over the weekend. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC & baselayout-2 meets Gentoo
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 mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
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
Re: [gentoo-dev] Testing to see if services have crashed on hardened
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 (!HARDENED || (HARDENED && euid=0) { > /* show if process is running or not */ > } Ideally I'd like a runtime catch rather than a define for this though, but that's probably the best idea thus far. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Testing to see if services have crashed on hardened
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 installed OpenRC in a > > prefix where this wouldn't apply, but we don't know that either. > > > > Ideas anyone? > > Is there a way to just have some fallback method which is less > functional, but just uses some pid file with a lock or something? Not all services use pidfiles. Also, some services re-fork and re-write their pidfiles and I'm not sure the lock would carry across in that instance. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Testing to see if services have crashed on hardened
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 it tests each reported service to ensure all daemons are up. This also works fine unprivileged on normal boxes - except for hardened where users can only see their own processes. This isn't really an easy answer, as we could have installed OpenRC in a prefix where this wouldn't apply, but we don't know that either. Ideas anyone? Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC & baselayout-2 meets Gentoo
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 in example config files and man pages that cover nearly every aspect on OpenRC and all it's commands. The nice thing about not being a Gentoo dev means I don't feel the urge to write a migration how to. However, here's a really good primer. 1) Install OpenRC 2) Review all updated files in /etc/conf.d/ and /etc/rc.conf [1] [2] 3) If using a "volume" such as LVM, you'll find an appropriate init script in /etc/init.d that you need to add to the boot runlevel. 4) Carry on as normal [3] Thanks Roy [1] The case of variable names has been changed from UPPER to lower. This is for a few reasons (removes confusion vs environment vars, looks nicer). However, *existing* UPPER case vars should still work. [2] Paludis users will need to ensure that the init scripts checkfs and checkroot are removed. I don't care whose "bug" this is, but neither side wants to fix it. [3] A reboot is currently needed as for some reason state data isn't migrated from baselayout-1. This is probably due to OpenRC being split from baselayout and the code is pretty much the same here. Maybe some plucky Gentoo ebuild dev can step up and fix it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
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 you remove those rose tinted specs of yours unless you are suggesting that a Gentoo dev has never committed a broken ebuild or eclass :) Devs make mistakes, only less than other people by virtue of spending more time working on similar stuff. Lastly, taking a quiz is no measure of being malicious or not. You would have to interact with the person to know if they are capable for that. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] OpenRC-0.1 released
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 outstanding bugs (probably a few) and making the install process easier for pkgsrc and ports (not that you guys are interested in that, but heh). I still have a long list of features I'd like in OpenRC, so it's not finished yet. It's just very useable right now and people have been clamoring for a release, so here it is. Go wild :) Remember, I retired from Gentoo. I won't be asking for keywords, or being made stable. That's up to you guys. To keep track of this being pushed into Gentoo portage, watch the action on bug #212696. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
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 > lesser than that of the full-fledged developer. This serves a couple > of purposes: > - Users might become more motivated to becoming a maintainer for > Gentoo, since it would require less time and effort from their end > - Might reduce the number of orphaned packages we have in the tree Adding user repos to layman isn't good enough? Plus, there's always sunrise. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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/name # to kill for runlevel 2 > > When doing so with OpenRC's main process, it could integrate smoothly > with normal system reboot and start prefixed init.d scripts. Yes, that should work fine if it ends up calling /sbin/init.d/name start and /sbin/init.d/name stop to start and stop it. You just have to somehow inject rc sysinit into the boot process to remove all state data. But a better way would be like so /my/prefix/sbin/rc-wrapper #/bin/sh case "$1" in start) /my/prefix/sbin/rc default;; stop) /my/prefix/sbin/rc single;; esac As you then get OpenRC handling the dependency order if you have >1 service. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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 >> > 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. >> >> I have OpenRC fully working in a prefixed non priviledged install on a > NetBSD >> box. > > Can you define how this is working? Do you just have NetBSD and install > OpenRC in /my/arbitrary/path, or do you have a full set of utilities > under /my/arbitrary/path with OpenRC as one of them? I did this in OpenRC source rm -rf /home/roy/pkg make PREFIX=/home/roy/pkg PKG_PREFIX=/usr/pkg install Create Gentoo style init script in /home/roy/pkg/etc/init.d for say boinc export PATH=$PATH:/home/roy/pkg/bin:/home/roy/pkg/sbin rc-update add boinc default rc default boinc started > >> The only question I have left is what mechanism resets service state, as > the >> prefixed state dir needs will presist between reboots which isn't > desirable. > > startprefix could maybe start some sort of process that lives on, > activated like keychain does, such that multiple startprefix invocations > do not start the system all the time -- if that is desired at all. In > a real scenario it may be just a hook from the host OS's start/stop > mechanism to tell OpenRC in what state it should run. > > If a service such as PostgreSQL is killed (maybe a reboot?) does OpenRC > then know it is not running any more? I guess it does, so that's good > enough, IMO. This needs to be done on startup rc sysinit rc default Which is pretty much what we do in Gentoo anyway. Just ensure that the sysinit runlevel only runs once, as it will remove all state when run again. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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. I have OpenRC fully working in a prefixed non priviledged install on a NetBSD box. The only question I have left is what mechanism resets service state, as the prefixed state dir needs will presist between reboots which isn't desirable. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
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 :) We can test to see if a service started daemon has crashed or not and report accordingly. The user can then restart the service if desired. This can be automated through scripts as well, but we don't automatically do this. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
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-s-daemon? > > I am using the busybox version 95% successfully with baselayout-2 for > example (just simple stuff mind). The only thing it's breaking on right > now is a --test option which doesn't seem to exist? > > I'm not that fussed, I'm just curious? s-s-d when used in an OpenRC service remembers how the daemon is started so it can poll to see if it's still running or not. We also use this ability to ensure the daemon really starts. A lot of daemons love to fork (and return success) before checking config and system for sanity, so sometimes it's needed. OpenRC variant also works better for finding daemons on the whole, especially if you upgrade an already running daemon. Plus, it supports more OS's than busybox - but to be fair, busybox only supports Linux. It's also missing chroot and env options from the upstream Debian version. It's also missing the Gentoo extras for PAM limits support and redirecting the daemons stdout/stderr to log files. It also requires the crappy use of oknodo. It fails to search for daemon arguments when stopping (important for say daemons using python without pidfiles) I'm not sure that busybox would take any patches to add much of the above as most would add more bloat for sure. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
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 start then bash again manually it looks nice, the environment is not > setup correctly the first time. Doesn't sound like an OpenRC issue as such as bash sets up it's own prompt. Also, OpenRC isn't responsible for setting up the environment. At most we suck in what's defined in /etc/profile.env > when rebooting, INIT stops with "no more processes left in this runlevel" > after "remounting /" Curious. A suggest you open a bug a http://bugs.marples.name against openrc so we can move the debugging off this list. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
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? It's actually been very stable and usable for a long time. It's not, and never will be a 100% drop in replacement for everything baselayout provides, but it's very very compatible. > Would it not make sense to start to snapshot some builds and push openrc > out for testing? (Seems like a gentoo job rather than an upstream is > the reason I ask here?) As Doug mentioned earlier, my git repo is available in an ebuild. Why haven't I done a snapshot or release yet? Well, I have one last feature to add basically. That feature is so it can be installed "prefixed" and still work perfectly - with the exception of not booting or shutting down the host system. I'll be doing this on my NetBSD box next week hopefully. But bugs are still being found and fixed - although at a slow rate :) Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Baselayout-2 progress?
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 out here? Roy: Is this intended to be a baselayout > replacement? How likely is this to be on-track to become a "gentoo > official" baselayout? Do you (try to) support busybox and vserver > environments? It's not a full baselayout competitor - instead it's reduced baselayout to providing key base files such as /etc/passwd. OpenRC is just the service management system. Yes Yes [1] A done deal [1] No [2] [1] The Gentoo Council and Gentoo base-system team know and approve of OpenRC. Mike Frysinger of the Gentoo base-system team also has commit access to the git repo. So it's very very likely. [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 don't and probably never will support vserver personally, but will work with Gentoo developers ensuring that at least one version works. In other words, I'll try and support it but it may break from time to time. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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. OpenRC now supports PREFIX=/home/roy/foo and PKG_PREFIX=/home/roy/bar. PREFIX is where OpenRC installs to (also respects DESTDIR). PKG_PREFIX is where packages install to if different. 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. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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)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 that provide what the host > > already does. > > Ok, the host will for instance do "net", so "need net" should indeed not > fail. However I could imagine that "need net" would just get satisfied > or something, like by a dummy. Correct. lu_zero wanted OpenRC to work out of the box in a vanilla fbsd jail, hence the keyword instead of dummy scripts. > > If OpenRC compiles and /bin/sh points to a POSIX shell it should work as > > it stands. > > Ok, then we already fail here. > /bin/sh is no way POSIX, it is just bourne, so that's where we come in > and simply use /usr/bin/env {sh,bash,posix-sh} or a full path to make > your assumption true. make SH=/usr/local/bin/bash now tweaks all the scripts accordingly. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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 that provide what the host already does. We current have nojail for FreeBSD jails, novps for VServer/OpenVZ systems and a few others. I would be trivial to add another no for prefix :) > I have to look more closely at what openrc does > these days, but for the (ancient) version of baselayout we have in > prefix now, I recall that: > a) most of it didn't compile on Darwin and Solaris It compiles and works on Linux/glibc/uclibc, FreeBSD-6 and NetBSD-4. So it stands a fair chance of working on Darwin for sure. I have no idea about Solaris, but it should work as it sports libkvm which we use to find processes. > b) hence we only use basically the functions.sh script (hacked up) > so what we need to have working is: > ${EPREFIX}/etc/init.d/postgresql start > and similar. > > And maybe even a sort of init-level stuff, such that one can start all > services in the Prefix and stop them as well. That basically gets quite > useful once Prefix goes "privileged" and you could start sshd, slapd, > apache2, etc, etc. on privileged ports, and you really would like those > to be started as well in some correct order (on e.g. Solaris). If OpenRC compiles and /bin/sh points to a POSIX shell it should work as it stands. At present there is no need for the default interpreter to be changed, but there may be the need for Prefix. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Google SOC 2008
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 disables the automatic running of services by rc itself, such as fsck, mounting and stuff as that's taken care of by the host OS. Running in Prefix is pretty much the same as a jail from OpenRC's perspective (correct me if I'm wrong) so all we would have to do is tell OpenRC that it's currently in a jail. Presently this is done only for FreeBSD by testing sysctl values. Maybe we could turn this into a compile option for Prefix. Also, we now support services in directories other than /etc/init.d, although this is currently hard coded to /usr/local/etc/init.d. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: flag-o-matic.eclass
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: stop using the bindnow-flags function ... > > simply drop it from your ebuild" >&2 > > This seems like something ewarn should do on its own. baselayout and portage have always echoed ewarn to stdout and not stderr. Warnings are NOT errors, so why use stderr? If it's an error, use eerror which DOES goto stderr. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Concerns about WIPE_TMP change
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 default and expect it to work just fine. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] How to force homedir on enewuser
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: -f6) == "/the/old/path" ]] ; then > eerror "please run usermod -m -d /new/path .." > die "moocow" > fi You should also ensure that ${ROOT} is / Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
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. Thus, it > > > can't be *that* bad. > > > > So what happens if a flaw is discovered in KDE 3.5.5 that allows root > > access? > > Then the one particular part of 3.5.5 that's affected gets fixed and > priority keyworded. Lets say that there's just 3.5.5 and 3.5.8 in the tree. 3.5.5 is keyworded stable mips 3.5.8 doesn't have the mips keyword because it's horribly broken on mips A security flaw is discovered in 3.5.5, the solution is to upgrade to 3.5.8. This flaw involves code that has radically changed from 3.5.5 to 3.5.8. For the sake of argument say it will take 1 month of time for anyone to create a patch for 3.5.5 that fixes the flaw OR makes 3.5.8 magically work on mips. During this month, what do you propose happens to the end user? The choices are 1) Carry on as we are, user is blissfully unaware of security flaw and doesn't have time to read GLSA's, etc has he's busy with real life thereby giving Gentoo the reputation of shipping insecure software. 2) Force the user to spend a few minutes adding 3.5.5 to a package.unmask, thereby acknowledging the security flaw but by his own choice keeping the highly insecure software. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
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 and insecure software, instead of having to add to /etc/portage/package.keywords or package.unmask Yes, this breaks their tree, but it's fixable from the users end as we can rest in the knowledge that mips users have acknowledged the security flaw by adding the package to the above mentioned files. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 right). they've weathered quite a long time and should be pretty much > unchanged, so there is no good reason to omit them. there is no overhead of > having them available and maintaining them. KV_* only makes sense when dealing with Linux version numbers are they're always numeric. The BSD's on the other hand include textual elemants too. uname -r on this machine is 7.0-RC1. luckily, baselayout-2 as it stands in portage only exports the KV_to_int function so that's the only one we should be dealing with. So, the question is, do we want to maintain one massive KV_to_int that has different code paths for uname -s output, or get function.sh to include an OS specific file we supply just for this one function? Or just put the function in modules-update and udev as they are the only two applications that use it. > if you want a cleaner interface for is_older_than, then we could hammer that > out, but if it's just a pass through to a C applet, then leaving it alone > makes sense. Currently it's neither as it's been integrated into the librc dependency code. Again, the only consumer of this function is now modules-update. > > > I also notice that the timezone of clock is gone, any alternative? > > > Also the network dependency of stopping/starting services when network > > > is unavailable/available is gone, any alternative? > > > > The timezone was variable was just a hack for the timezone ebuild to > > update /etc/localtime if it's not a symlink. I'm striving to remove all > > "Gentooisms" from it so that it really is platform neutral. > > you view the purpose of TIMEZONE incorrectly. it was a central script > parasable location to store the system timezone. every distribution out > there does it somehow. the way for OpenRC to do it is set the variable > in /etc/conf.d/clock. the fact that currently the timezone ebuild is the > only one using it is irrelevant. Then I suggest that conf.d/clock is the wrong place for it as if it was set there then it implies that `/etc/init.d/clock start` would change to that timezone, which is clearly not the case. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 > > the /etc/modules.autoload.d/ directory and converts it into the > > corresponding /etc/conf.d/modules file. > > I'll go with a conversion script in the ebuild I think. I've gone with a warning message instead as a converstion script will take a little while. It should suffice for the time being. Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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/modules file. I'll go with a conversion script in the ebuild I think. Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 help, or perhaps upstream have a list > where they can discuss it. One of the "deals" was that whilst Gentoo would likely use OpenRC it would still do the hosting. As Gentoo would be using it, it does pertain to Gentoo development. So either I host my own bug tracker (which I'm more than happy to do btw), or Gentoo can get one hosted ASAP. Maybe a mailing list a well (again, I can host this too). The next Council meeting is next week, so I'll ask them the status then. You'll not hear from me again on this list. > Warmest Regards in the New Year, Same to you :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 success. > > > > make[1]: *** [start-stop-daemon.o] Error 1 > > make[1]: *** Waiting for unfinished jobs > > make[1]: Leaving directory > > `/var/tmp/portage/sys-apps/openrc-/work/openrc-/src' > > >>> Source compiled. > > What version of gnu make? > What MAKEOPTS do you have set? > Does it work outside of the ebuild? Never mind, I have this fixed now. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 to sync with your changes. Because Gentoo/Linux isn't my primary development platform and no-one else volunteered to maintain ebuilds. They will be put back in place when I can boot into a Gentoo based platform to re-make the digests and Manifest. The fact that it's git is irrelevant here. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 unfinished jobs > make[1]: Leaving directory > `/var/tmp/portage/sys-apps/openrc-/work/openrc-/src' > >>> Source compiled. What version of gnu make? What MAKEOPTS do you have set? Does it work outside of the ebuild? Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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. 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 having to bump all the time. > > But it should be fairly smooth going. > > I am wondering about the blocker on baselayout < 2.0 in your git > overlay ebuild for baselayout-2. Is there some reason that the upgrade > path from baselayout-1 to -2 will not work for openrc? File ownership of a few things changed from baselayout -> openrc. Enough so that openrc is a self enclosed product, but relies on system files that baselayout supplies. A blocker is the only way I know of doing this so portage doesn't complain about overwriting files owned by another package. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available 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 adding digests :) I've removed them for now. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 this into portage > > soonish. > gcc: no input files > make[1]: *** [libeinfo.o] Error 1 > make[1]: Leaving directory Once either GNU Make optionally includes .depend by default OR FreeBSD make can specify an optional include in the Makefile I can avoid the trickery needed here. We now force a `make depend` which sould solve this. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 those functions back. Although we could trivially add is_older_than > > as a C applet built into rc. > > So who should take care of this? update-modules maintainer which would be vapier. I notified him on IRC about this a few months ago, but he never replied one way or the other. > > > How can I add a specific service dependency using this mechanism? The > > > modified service name is missing... > > > > They're supposed to belong in /etc/conf.d/$SVCNAME > > Maybe you could suggest better wording? > > > > I suppose we could also allow > > rc_$SVCNAME_$depend to work, for example > > > > rc_clock_need="modules" > > Oh... This is good, just document it... :) Done! re-emerge to test. > You did not reply regarding this one: > > > > Also the network dependency of stopping/starting services when network > > > is unavailable/available is gone, any alternative? It's not gone at all - just different. It's also no longer net specific, and applies to any service that can be multiplexed. But lets use net as the example as everyone understands that. With rc_depend_strict=YES (which is the default) If any services added to the current runlevel provide net then all those services will be used. If none found, then check the boot runlevel and use those. If none found then nothing provides net as such. With rc_depend_strict=NO we check the following and abort at the first match. Check if any started service provide net - if so use them. Check if any inactive services provide net - if so use them. Check if any coldplugged services provide net - if so use them. If nothing found then list ALL installed services that provide net. Hopefully that makes things a little more clear. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 exceptions of fstab and rc.conf > > are in conf.d and not some random dir :) > > Took me a while too... Some ChangeLog documentation should be available. > > Also I think this is a regression: > # update-modules > /sbin/update-modules: line 118: KV_to_int: command not found > /sbin/update-modules: line 118: KV_to_int: command not found > /sbin/update-modules: line 263: is_older_than: command not found 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 those functions back. Although we could trivially add is_older_than as a C applet built into rc. > And I think there is a circular dependency of: > openrc->init-module-tools->baselayout->openrc Quite possibly. I'm sure some bright spark can actually say what's wrong before it hits portage. > > I did not understand the comments in rc.conf regarding the external > dependency... > # It's possible to define extra dependencies for services like so > #rc_config="/etc/foo" > #rc_need="openvpn" > #rc_use="net.eth0" > #rc_after="clock" > #rc_before="local" > > How can I add a specific service dependency using this mechanism? The > modified service name is missing... They're supposed to belong in /etc/conf.d/$SVCNAME Maybe you could suggest better wording? I suppose we could also allow rc_$SVCNAME_$depend to work, for example rc_clock_need="modules" > I also notice that the timezone of clock is gone, any alternative? > Also the network dependency of stopping/starting services when network > is unavailable/available is gone, any alternative? The timezone was variable was just a hack for the timezone ebuild to update /etc/localtime if it's not a symlink. I'm striving to remove all "Gentooisms" from it so that it really is platform neutral. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 baselayout one as far as I can tell. > It took me some time to find /etc/conf.d/modules, but it's certainly > useful :). It also means all config files, with the exceptions of fstab and rc.conf are in conf.d and not some random dir :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: brltty not starting early enough
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 > > My goal is to have the braille display active as early is possible so > that if an error occurs during the boot process a blind person would > know about it. I can't start before /proc, /dev, and /sys are mounted > because brltty uses things in those filesystems. Can you think of any > possible reason that I would need to start before clock runs? If not, > I'll just use your first suggestion. > > Besides starting later than expected, will anything break if this goes > on a baselayout 1 system? depscan.sh may constantly complain about it You could do this depend() { if [ -z "$svcdir" ]; then before * fi after clock } But I would test to see what happens on baselayout-1 first. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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 > !!! Expected: 3602 Fixed -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: brltty not starting early enough
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 safe to change this to before checkroot'? 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 depend() { before * after clock } would also work. Note that you have to put the dependencies in that order, and it only works with baselayout-2. If you wanted it to start before clock you'll need to do this depend() { before * } AND add this to /etc/conf.d/clock RC_AFTER=brltty Again, baselayout-2 only. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
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
Re: [gentoo-dev] OpenRC available for testing.
Uh, forgot the link :) http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary -- [EMAIL PROTECTED] mailing list
[gentoo-dev] OpenRC available for testing.
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 having to bump all the time. But it should be fairly smooth going. As the code has been split, I cannot provide a downgrade path back to baselayout-1, so if you do downgrade you'll have to reboot the host. However, it should upgrade perfectly. 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 this into portage soonish. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: brltty not starting early enough
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/guidelines.html suggest starting the program very > early in the boot sequence. Ideally, I would like to be able to start brltty > as soon as /dev is set up either with udev, devfs, or static. > > There is a new version of brltty which hasn't been put into portage yet, > so I thought now would be a good time to ask about it. How should we > set this up on gentoo? Any suggestions would be appreciated. Just make a standard init script for it with this dependency block depend() { before checkfs } That way it will be run immediately after /dev, /proc and /sys have been brought up and the root fs checked. After that, brltty should launch. However, that doesn't work for baselayout-1 as it forces more services to start before hand, but should work as expected in newer versions. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 explaining so, instead of the user posting "Why?" and another silly debate starting. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 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 impossible to add a conservatory and > > > central heating because the green paint will catch fire and kill > > > everyone. > > > > Using your analogy you should then recognise that there is a strong > > dislike for pink and should seek a new colour that allows the building > > of said extensions. > > And what colour would that be? We've already ruled out purple, brown > and yellow, and no-one has yet found any other colour of paint. If there are no other colours then maybe you shouldn't install extensions that only work with pink to the detriment of all other colours of the spectrum. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 impossible to add a conservatory and central heating > because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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? > > > > I neither know, nor care. > > > > I just feel very strongly that the current proposal is wrong, and no > > requirements that you or others may have can possibly outweigh that. > > So you have no technical objections, no alternatives, no understanding > of why it's necessary and no actual reason to call it 'wrong'. Hard to have technical objections to the contents of a string :) Actual reasons were stated in the first email I posted in this thread to which to replied. I care not for alternatives, nor understanding as it's not my domain of expertise or knowledge. But I can smell a blatant hack that is just wrong to the bone like a lot of other people here. Just because you have a the only "solution" to a problem does not make it "right" by default. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 justify it. > > Alright, so where would you stick EAPI such that all the requirements > that've previously been described are met? I neither know, nor care. I just feel very strongly that the current proposal is wrong, and no requirements that you or others may have can possibly outweigh that. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 metadata? No. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 deal, then simply ensure that > > Thankyou for reading and understanding the GLEP before jumping in and > commenting. 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. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Good-bye
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 list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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: > > > > So to obtain EAPI from .ebuild you would always do > > > > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"` > > > > > > Doesn't work with current ebuilds, nor future ebuilds. No points! > > > > Works fine as long as the functions the ebuild has in global scope > > exist. Which would assuming that the ebuild was sourced in a portage > > environment. > > 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 deal, then simply ensure that 1) no functions are allowed in global scope or 2) eapi is a function and not a variable Thanks Roy PS - Merry Christmas everyone - I'm off to enjoy mine with my family now. I suggest everyone else does the same :) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 with current ebuilds, nor future ebuilds. No points! Works fine as long as the functions the ebuild has in global scope exist. Which would assuming that the ebuild was sourced in a portage environment. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)
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 from > infra tmrw), I've spent the last week or so on it. (I think the upstream > gitosis author is going to kill me, but meh, it had to be done to make > it work for Gentoo). Great! Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: PMS location (Was: Re: EAPI placement)
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 vanilla FreeBSD. man pages have been written for every userland tool and library function it provides. Init scripts now support a "template" system, based on Free/Net BSDs RC. Lots of Gentoo reported bugs have been fixed. Infact, the last of the planned changes have now been comitted to my local repo and I'll be itching to make a release soon into the New Year. Granted I'm waiting on Gentoo Infra to host it (the git repo) because that is what we agreed. However I'm probably going to end up going with someone else, or hosting myself, because it's now coming up to 2 months and nothings ready yet. Heck, my retirement bug [1] is still pending and I currently have full access to all my accounts on various boxes. So either I'm a very trustable guy that you really don't want to retire (tough, I have) or some people are slacking. [1] http://bugs.gentoo.org/show_bug.cgi?id=199318 Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
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 again and again that you cannot predict every aspect of the future. But then I'm sure you know this ;) File name suffixes historically describe the content structure of a file. .png means the content is a picture and it's structure is Portable Network Graphic. .ebuild means the content is instructions on how to install something and it's structure is bash. So to obtain EAPI from .ebuild you would always do EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"` Now say you wanted to move ebuilds into xml you would do EAPI=`xmlcmd_to_extract_node_value /root/eapi /path/to/ebuild.xml" In closing, EAPI describes features available, not content nor structure. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
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 > > Because this is more code for the same functionality. Also if at one > point somebody decides to add eclass_pkg_setup function to eclass he/she > will have to touch all ebuild and put this function into pkg_setup > there. BTW. Speaking about font.eclass we already have font_pkg_setup > there. So correct code will be: > > pkg_setup() { >font_pkg_setup >append_font_conf "path1" "path2" > } > > instead of on line > > FONT_CONF=( "path1" "path2" ) You could do the append_font_conf in any function I think. So there's only more code if there are no functions already. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
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 care about the storage format of FONT_CONF, whether it's a bash array or a standard string using IFS. That gives you the luxury of changing it as you like without having to change any ebuilds later. pkg_setup() { append_font_conf "path1" "path2" } Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
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, that does mean you cannot use : in PATH. I don't actually know if shells allow it to be escaped, but I do know that escaping does not work when IFS is concerned. You could also use the embedded newline approach that Donnie mentioned earlier, but you may or may not want to go there. It's it's fairly ugly code. But the good news is you can now escape anything into an item, and remian shell portable. Here's a code snippet FONT_CONF="conf1 conf2" SIFS="${IFS-y}" OIFS="${IFS}" IFS=" " for for conffile in ${FONT_CONF}; do done if [ "${SIFS}" = "y" ]; then unset IFS else IFS="${OIFS}" fi Oddly enough, you do need to quote variable assignment now as in my test even bash got it wrong. Probably a bug, but heh. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
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 litterally have any character in then, making things a little tricky. Here I see no reason why it cannot behave like $PATH and operate under the same constraints. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
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}; do > ... > done > > The problem with this doesn't work if path{1,2} contain spaces. The > solution I'm thinking about is to you arrays: > > FONT_CONF=("path1" "path2") > > for conffile in "[EMAIL PROTECTED]"; do > ... > done > > But is this good idea? Are there better? FONT_CONF=path1:path2 IFS=. for for conffile in ${FONT_CONF}; do done unset IFS Or if you want to be really picky about preserving IFS if you can't make it local in a function SIFS=${IFS-y} OIFS=${IFS} IFS=. for for conffile in ${FONT_CONF}; do done if [ "${SIFS}" = "y" ]; then unset IFS else IFS=${OIFS} fi That way you work the same way as the classic $PATH variable. But of course no one cares as it's Just Not Bash (tm) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 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 > > your view, your entitled to it, but it is not my view. Change a little > > bit here, a little bit there. Slowly does it. > > It's not a view. It's a simple fact. It's my considered opinion that it's a view. You are free to call it what you like. > > Yes, I know that a fair chunk of the tree will need a re-write, just > > in the same way that the init scripts got a re-write. It will take > > time, it will not happen magically over night. To think overwise is > > foolish :) > > How many lines of code are in baselayout? How many in the tree? > > Pushing for non-bash for ebuilds is pointless. The cost of using bash is > tiny; the cost of not using bash is huge. Size of baselayout compared to the tree is small vs huge. But unlike baselayout, the ebuilds themselves should be relatively easy as they don't normally use bash specific features [1]. The real work is in the eclasses which make extensive use of bash specific features, such as arrays. A quick look at the dir shows that there's probably a similar number of eclasses to the number of init scripts installed by ebuilds. [1] The one expection being ${var//foo/var} which is used a fair bit. It could also be argued that versionator should be used more which oddly enough should also reduce the use of this bashism. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 your view, your entitled to it, but it is not my view. Change a little bit here, a little bit there. Slowly does it. Yes, I know that a fair chunk of the tree will need a re-write, just in the same way that the init scripts got a re-write. It will take time, it will not happen magically over night. To think overwise is foolish :) But if the default shell remains bash but the PM had enough knobs on it so this could be changed (maybe per ebuild) in /etc then work *could* start. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 how cool it would be for starting a new port. 1) Install PM 2) Wang on a portage tree 3) emerge ready to go Obviously it's not quite that simple as portage requires python and pkgcore require python, paludis requires tr1-whatever libs - but that's the restriction of the PM used. Maybe one day Gentoo will have a PM that doesn't require any of that and is just written in C and sh, using POSIX libc where it can. But enough pipe dreaming :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 is not possible to change to > > a POSIX compliant shell then it can still use /bin/bash or wherever it's > > installed. > > So "have the installed scripts to not require bash" is another topic ? No, it's a valid topic. Either the profile could hook src_unpack or the ebuild could call a function to do this sed -e '1 s,^#!/bin/sh,#!/path/to/bash,' Either for all files in CONTENTS or all arguments passed. > > Ok then: > Given that we want to have the tree "more generic unix-able": > What is the benefit from having the tree being POSIX- but not > bourne-shell compatible, so one still needs bash on Solaris/AIX/HP-UX ? > Because I'd say those three are the biggest substitutes for "unix", > while I'd call *BSD and Linux just "unix derivates" (although with > enhancements)... The benefit is that we're not locked into any one toolset. This makes development of the tree more attractive to non Linux developers I would say. > > This also applies to the userland tools. If the ebuild or eclass *has* > > to use the GNU variants then it should either adjust $PATH so that it > > finds them first, or it prefixes them all with g, like it does on > > Gentoo/FreeBSD. > > > > None of this is technically challenging in itself, it's just that the > > key people who would have to do the work to make this possible have > > already given a flat out no. > > In the early prefix days I had some portage enhancement, providing a > wrapper-function around all coreutils/findutils/diffutils/grep/others, > trying to find a GNU implementation for them. And if not found, try to > map some args to the native ones ("xargs -r" fex - although didn't work > as shell-function). > But then we decided to always provide USERLAND=GNU in prefix and this > portage patch was thrown away. I dislike wrappers. The maintainers of revdep-rebuild say the same thing and I'm sure others would as well. An alternative would be to say have a list of ebuilds that don't require the GNU toolset (via an eclass or the ebuild itself) in a profile and slowly update the ebuilds and the lists when we can make them work with the desired userlands. If it requires gratuitous use of extensions then maybe the package itself should be patched upstream instead of us having to write overly complex ebuilds. Probably not the best idea for this, but workable. > > > More (generic) unix-able. > > > > Exactly so :) > > Not really as long as not being bourne shell compatible like autoconf's > configure. I won't trust to have a POSIX shell like /bin/ksh everywhere, > but /bin/sh only, which usually is just a bourne shell on "unix". As I said above, portage could change this. Think of it as an #ifdef :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 > time for me to chime in too, although I don't know what exactly POSIX-sh > standard defines. > Agreed, but (speaking for alt/prefix): > > Alt/prefix is designed to (mainly) work without superuser access on the > target machine, which may also be Solaris, AIX, HP-UX and the like. > /bin/sh on such a machine is not POSIX-shell, but old bourne-shell > (unfortunately with bugs often). > And it is _impossible_ to have sysadmins to get /bin/sh a POSIX-Shell > nor to have that bugs fixed. > > But yes, on most machines there is /bin/ksh, which IMHO is POSIX > compliant (maybe also with non-fixable bugs). > > Although I do not know yet for which _installed_ scripts it'd be really > useful to have them non-bash in alt/prefix, I appreciate the discussion. > > To see benefits for alt/prefix too, it _might_ require that discussion > going from requiring /bin/sh being POSIX-sh towards being > bourne-shell... 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 is not possible to change to a POSIX compliant shell then it can still use /bin/bash or wherever it's installed. This also applies to the userland tools. If the ebuild or eclass *has* to use the GNU variants then it should either adjust $PATH so that it finds them first, or it prefixes them all with g, like it does on Gentoo/FreeBSD. None of this is technically challenging in itself, it's just that the key people who would have to do the work to make this possible have already given a flat out no. > > > It seems to me that you actually mean "more FreeBSD-able" or something, > > > which is a high price to pay for a relatively small part of Gentoo as a > > > whole. > > > > More embeddable. > > More BSDable. > > More Linuxable - bash isn't the only linux shell, there are plently of > > others. > > More (generic) unix-able. Exactly so :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 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 platforms, where it would have been working fine if there > just were #!/bin/bash there. > > It seems to me that you actually mean "more FreeBSD-able" or something, > which is a high price to pay for a relatively small part of Gentoo as a > whole. Me again. If the shell isn't infact POSIX then you could always patch everything to change #!/bin/sh to #!/bin/bash and install bash or remove /bin/sh and link it to bash. As a lot of programs out there in the tree that are runtime (not ebuilds or init scripts) depend on /bin/sh being a POSIX shell. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 platforms, where it would have been working fine if there > just were #!/bin/bash there. > > It seems to me that you actually mean "more FreeBSD-able" or something, > which is a high price to pay for a relatively small part of Gentoo as a > whole. Another way of looking at it is that you're forcing specific tools on people, where I am asking people to use standard POSIX tools. I guess it's because I'm an Engineer and you probably aren't. If the tool isn't up to the job, then fix the tool. If the tool doesn't claim any standards compliance then feel free to change it. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and "portable"
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 portable as then then works across more than one shell. > The shell code you see in > configure can in a way be called "portable". Your POSIX compliant stuff > isn't. Sure it is - it should work on a shell that claims POSIX compliance. > In fact, by stating #!/bin/sh you actually make the code useless > on a number of platforms, where it would have been working fine if there > just were #!/bin/bash there. Then the issue is to fix their sh so it follows POSIX compliance. As soon as a dash, bb or FreeBSD sh issue is found where it deviates from POSIX but it works on bash a lot of people say "dash bug, therefore invalid > It seems to me that you actually mean "more FreeBSD-able" or something, > which is a high price to pay for a relatively small part of Gentoo as a > whole. More embeddable. More BSDable. More Linuxable - bash isn't the only linux shell, there are plently of others. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
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'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 using bashisms. > > So your approach to getting it your way is to hijack every thread that shows > use of bashisms until people start using your inferior workarounds? I don't see them as inferior. I see them as more portable and less confusing. Of course you are welcome to compare the code in question and state which is inferior and why it is so. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
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 using bashisms. Thanks Roy -- [EMAIL PROTECTED] mailing list