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)
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)
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)
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: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)
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: 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: 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: 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)
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] 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] 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
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
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] 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] 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] 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 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 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
[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] 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
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] 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 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
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 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] 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 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] Google SOC 2008
On Mon, 3 Mar 2008 15:53:20 +0100, Fabian Groffen [EMAIL PROTECTED] wrote: On 03-03-2008 13:36:25 +, 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 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] 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 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] 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 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] 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] 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 Wednesday 27 February 2008 14:21:58 Fabian Groffen wrote:
On 27-02-2008 13:56:51 +, 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] 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 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] 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] 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 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: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 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: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 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 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] 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
[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] OpenRC available for testing.
Uh, forgot the link :) http://git.overlays.gentoo.org/gitweb/?p=dev/uberlord.git;a=summary -- [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] 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 +, 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 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 12:04 -0600, William Hubbs wrote:
On Tue, Jan 01, 2008 at 05:19:39PM +, 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 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] 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 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] 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 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: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 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 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 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] 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]
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] 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: 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: 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] 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 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] 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 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] 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
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 +, 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 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
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 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] More general interface to use flags
On Fri, 2007-11-02 at 11:38 -0400, Mike Frysinger wrote: wrong. the point of the discussion on the gentoo dev mailing list is to go over the exported API for *ebuilds*, not for the implementation. the implementation is already baked and really, Marijn shouldnt have sent it to the gentoo dev mailing list in the first place. your pointless POSIX conversions have no place in the discussion. However, I notice that you have no problem discussing the implementation of ebuild commits or are they special in some way? My POSIX conversations encourage the use of POSIX over non portable bash as that's something I try and encourage. And that is very pertinent to -dev. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
On Fri, 2007-11-02 at 10:59 -0400, Mike Frysinger wrote:
On Friday 02 November 2007, Roy Marples wrote:
On Fri, 2007-11-02 at 14:44 +0100, Marijn Schouten (hkBst) wrote:
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
Could be written as
irrelevant, thanks
My mail was relevant to the discussion, yours is just trolling and has
no place here.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
On Fri, 2007-11-02 at 15:27 +0100, Marijn Schouten (hkBst) wrote:
ifz() {
[[ $1 = 0 ]] echo $2 || echo $3
}
And that could be written as
[ $1 = 0 ] echo $2 || echo $3
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
On Fri, 2007-11-02 at 14:44 +0100, Marijn Schouten (hkBst) wrote:
[[ ${flag} = !* ]] { success=1 ; flag=${flag:1} }
Could be written as
[ ${flag#!} != ${flag} ] { success=1; flag=${flag#!}; }
string=$( (( ${success} == 0 )) echo ${string_success} || echo
${string_failure} )
[[ -n ${string} ]] echo ${string}
if [ ${success} = 0 ]; then
string=${string_success}
else
string=${string_failure}
fi
[ -n ${string} ] echo ${string}
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] More general interface to use flags
On Fri, 2007-11-02 at 11:58 -0400, Mike Frysinger wrote: and the answer is still the same. POSIX conversions are irrelevant until you can propose solutions for the things bash can do but POSIX cannot. you can only provide workarounds or hacks, so any further attempt on the topic is half way conversions that lead to ugly inconsistencies. Please point to the ugly inconsistent POSIX hacks in this thread? 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
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 +, 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] POSIX shell and portable
On Sat, 2007-11-03 at 01:19 +0100, Fabian Groffen wrote: On 02-11-2007 17:35:08 +, 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] Re: [gentoo-commits] gentoo-x86 commit in app-admin/webmin: ChangeLog webmin-1.370-r1.ebuild
On Tue, 2007-10-30 at 22:46 -0700, Donnie Berkholz wrote:
On 10:36 Tue 30 Oct , Roy Marples (uberlord) wrote:
1.1 app-admin/webmin/webmin-1.370-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-admin/webmin/webmin-1.370-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-admin/webmin/webmin-1.370-r1.ebuild?rev=1.1content-type=text/plain
(find . -name '*.cgi' ; find . -name '*.pl') | perl perlpath.pl
/usr/bin/perl -
Please don't tell me the -or find flag isn't POSIX so we can't use it...
cp -rp * ${D}/usr/libexec/webmin
Lots of quote stuff here, repoman should be catching that.
Sorry, I just bumped an ebuild to fix an init script.
I'll let the real maintainer do the development of the build :)
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
On Wed, 2007-10-31 at 11:40 -0400, Doug Goldstein wrote: When HAL evaluated the usage of libpci the following issues were identified: 1) increased memory usage, to the point that HAL was not usable on the OLPC project 2) ABI breakage between patch revisions (i.e. x.y.z and x.y.z+1 were not ABI compatible) 3) no shared library 4) the library calls exit() when it encounters an error in parsing it's own pci.ids file which would kill the whole app using it. There might have been more. I don't remember. Refer to ML discussions and refer to IRC logs with me. Begs the question why does HAL use libpci in the first place. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Opinions Wanted - Arrays again :)
On Thu, 2007-10-25 at 16:40 +0100, Roy Marples wrote: array=1.2.3.4 netmask 5.6.7.8; \* 'host.name' netmask 1.2.3.4 -I 'option; $FOO with spaces' Everyone who commented has agreed that this is the most readable, maintainable and documentable. As such I've comitted a patch for this into baselayout's svn and will appear in baselayout-2.0.0_rc6. I've not opted for another config format (either based on Debians or something else) as this doesn't rock the baselayout-2 boat that much as it's a fairly trivial patch. Once we have baselayout-2 stable then we can think about revisiting this for future versions if there is still a need. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Opinions Wanted - Arrays again :)
On Thu, 2007-10-25 at 23:13 -0700, Alec Warner wrote: Can I vote for none of the above? :) Sure you can - provided you come up with an alternative approach to the problem :) 1 * Yes, that appears to be every ones thought so far. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Opinions Wanted - Arrays again :)
On Thu, 2007-10-25 at 15:56 -0700, Donnie Berkholz wrote: On 22:49 Thu 25 Oct , Roy Marples wrote: On Thu, 2007-10-25 at 14:31 -0700, Donnie Berkholz wrote: Is there any way we could avoid these altogether, and instead use separate variables for each array element? Well, we could prefix with numbers array=1.2.3.4 netmask 5.6.7.8; \* 'host.name' netmask 1.2.3.4 -I 'option; $FOO with spaces' Would become 0_config_eth0=1.2.3.4 netmask 5.6.7.8; 1_config_eth0=\* 2_config_eth0='host.name' netmask 1.2.3.4 3_config_eth0=-I 'option; $FOO with spaces' I was hoping for some sort of meaningfully named separate variables, not an even messier fake array. I'm all ears for any other suggestions :) BTW, my example fails as shell does not allow numbers to prefix variable names. Would have to be something like a0_ a1_ Thanks Roy -- [EMAIL PROTECTED] mailing list
