[gentoo-dev] Re: Re: bash version in ebuilds/eclasses...non-compliance and what to do?
Fabian Groffen wrote: On 20-12-2008 05:35:25 +, Steve Long wrote: I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 requires at least that version (only unstable on mips as against 2.1.1-r2) It might be worth skipping to 3.2, since that would simplify regex handling. The only problem we have there is that bash-3.2.17 only comes in patches on top of 3.2. During bootstrap that's problematic, as gnu patch (or any other patch) might not be available, or simply b0rked. For that reason we bootstrap with a portage pre SVN revision 10460, which does not require =3.2.17. See http://bugs.gentoo.org/show_bug.cgi?id=229677#c11 on why PMS should require 3.2.17 over plain 3.2 if you decide to push the requirement update. Yeah, that sounds great. Believe me I ran into troubles with early 3.2 ;) which is why I'm deadset against unstable across the board. Regex handling within BASH is quite important eg on cygwin where process creation is expensive. While I'm happy keeping my scripts compatible across 3.x (they're not Gentoo-specific) ebuild syntax would be much more perl-like if we were on 3.2.17+ (and would thus hold less gotchas for people new to the format, as well as perhaps giving some old hands a bit of new shiny;) We can work around it by using a self-made pre-patched tarball, though. Indeed, and they can be pushed out to stages pretty painlessly. If metro is politically unacceptable, I'm sure releng could do it with catalyst; somehow I doubt it's as hard to bootstrap as perl, but please don't flame me if you have something to say; just _add_ something technical. Happy Holidays to all those whom I don't /ignore ;-)
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
On Wed, 24 Dec 2008 00:19:06 -0600 Jeremy Olexa darks...@gentoo.org wrote: Take a look for yourself and you will see why there has never been a table or anything created. (it is trivial - and you have the source on your computer already) It's even trivialler than you think. If it's an external program, it can't die. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
2008/12/23 Doug Goldstein car...@gentoo.org: Looks like people have been truly over-zealous when removing die statements from ebuilds lately. I've added back to HAL an assortment of die statements. I hope this hasn't happened in too many other ebuilds. Maybe then someone should take a look at bug #233184 and close it. -- Regards, Daniel
[gentoo-dev] List of ebuild functions that die/do not die
As it seems like noone else is doing something about it, i have started a list with some entries[1]. Please send me more functions and their place and error reports directly to me (via mail or irc). [1]: http://dev.gentoo.org/~tommy/ebuild-functions.txt -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] List of ebuild functions that die/do not die
On Wed, Dec 24, 2008 at 8:27 PM, Thomas Sachau to...@gentoo.org wrote: As it seems like noone else is doing something about it, i have started a list with some entries[1]. Please send me more functions and their place and error reports directly to me (via mail or irc). I thought that the rules for determination were pretty straightforward: commands that die: everything that is implemented as a function (ebuild.sh, eclasses, etc) commands that don't die: every external application (do*, cp, etc) -- ~Nirbheek Chauhan
Re: [gentoo-dev] List of ebuild functions that die/do not die
Nirbheek Chauhan wrote: On Wed, Dec 24, 2008 at 8:27 PM, Thomas Sachau to...@gentoo.org wrote: As it seems like noone else is doing something about it, i have started a list with some entries[1]. Please send me more functions and their place and error reports directly to me (via mail or irc). I thought that the rules for determination were pretty straightforward: commands that die: everything that is implemented as a function (ebuild.sh, eclasses, etc) commands that don't die: every external application (do*, cp, etc) Technically the rule is that eclasses shouldn't die. At least that's the latest version of the rules that I remember.
Re: [gentoo-dev] List of ebuild functions that die/do not die
On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein car...@gentoo.org wrote: Nirbheek Chauhan wrote: [snip] commands that die: everything that is implemented as a function (ebuild.sh, eclasses, etc) [snip] Technically the rule is that eclasses shouldn't die. At least that's the latest version of the rules that I remember. eclasses shouldn't die or functions inside eclasses shouldn't die? I meant the latter: s/(ebuild.sh/(inside ebuild.sh/ -- ~Nirbheek Chauhan
[gentoo-dev] Re: List of ebuild functions that die/do not die
Nirbheek Chauhan wrote: On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein car...@gentoo.org wrote: Nirbheek Chauhan wrote: [snip] commands that die: everything that is implemented as a function (ebuild.sh, eclasses, etc) [snip] Technically the rule is that eclasses shouldn't die. At least that's the latest version of the rules that I remember. eclasses shouldn't die or functions inside eclasses shouldn't die? I meant the latter: s/(ebuild.sh/(inside ebuild.sh/ The only technical reason not to allow an --or-die (or the equivalent) switch for everything is the issues with subshell die, for which I sent some script to test but didn't hear back about, but more cogently that old GNU heads think xargs is necessary as GNU find didn't implement -exec correctly (according to POSIX) until a couple of years ago. In BASH, one would use the equivalent loop (which will cope with any filename): while read -rd '' f; do foo --or-die $f; done (find .. -print0) I usually show newbs this: while read -rd ''; do arr+=($REPLY); done (find .. -print0) ..since it shows a bit more about read and gives the other usual requirement. This is compatible with the old broken GNU find as well as BSD, but -print0 is not required by POSIX. I'm sure I've used that in a function somewhere amongst one of the patches I filed with someone or the other. TBH a professional BASH scripter would sneer (I can think of several) at needing to wrap it in a function: it's like not knowing how to read a file line-by-line in POSIX sh. Put it this way: if you actually need the filenames, or some other information elsewhere in the script[1], chances are that the loop has more meat to it. I suppose you could pass directories and params for a find command/API function, eg: findE --or-die foo dirA/b dirC/d ! \( -type -l -o -name '*~' \) ..or the like, showing --or-die first for consistency but it could of course come anywhere. [1] /msg greybot faq disappear
[gentoo-dev] Removal of net-misc/udhcp will break systems
Not sure where to report this. net-misc/udhcp got masked recently with following notice: - net-misc/udhcp-0.9.9_pre20041216-r4 (masked by: package.mask) /usr/portage/profiles/package.mask: # Diego Pettenò flamee...@gentoo.org (23 Dec 2008) # Mask these for removal, busybox provides those already, and are # unmaintained. As requested by solar. This should NOT happen until Bug 205286 is resolved. The current Busybox in portage cannot be used as a replacement for udhcp, and dhcpcd is not reliable for many routers (reports broken MAC address), leaving us with no DHCP client on Gentoo.
Re: [gentoo-dev] Time to say goodbye
Thanks for all your great work over the years. Much appreciated. Best wishes for whatever you end up doing. -- Daniel Black dragonhe...@gentoo.org Gentoo Foundation
