Re: [gentoo-dev] baselayout-2 stablisation plans
On Fri, 2007-08-24 at 00:33 +0200, Natanael Copa wrote:
I mentioned to the vserver list that i was interested to convert the
scripts to POSIX. First he said that he was not against it until he
realized he could no longer use arrays.
http://www.paul.sladen.org/vserver/archives/200708/0025.html
Does anyone have any suggestion to do dynamic variables cleanly without
using arrays?
Well, you can still use arrays provided that /bin/sh is still bash. Of course,
this does mean Linux only systems and also rules out embedded.
net.lo ships with this function
# Credit to David Leverton for this function which handily maps a bash
# array structure to positional parameters so existing configs work :)
# We'll deprecate arrays at some point though.
_get_array() {
if [ -n ${BASH} ] ; then
case $(declare -p $1 2/dev/null) in
declare -a *)
echo set -- \[EMAIL PROTECTED]
return
;;
esac
fi
echo eval set -- \\$$1\
}
Which means you can then do this
eval $(_get_array config_${IFVAR})
With IFVAR as eth0 that will convert the bash array config_eth0 to positional
parameters
Here's how both can now be defined. The former is bash only, the latter is all
shells.
config_eth0=( 1.2.3.4/24 5.6.7.8 netmask 255.255.255.0 )
config_eth0='1.2.3.4/24' '5.6.7.8 netmask 255.255.255.0'
If you pay attention to the quoting, you'll have no issues.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Friday 24 August 2007, Roy Marples wrote: case $(declare -p $1 2/dev/null) in /me stabs excessive quoting -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] baselayout-2 stablisation plans
Regarding init scripts. Init scripts should now be strictly bourne or POSIX shell. ie, no bashisms. bash init scripts will work, but ONLY if /bin/sh is bash. Shells as /bin/sh that I've tested and found to be working are bash dash busybox zsh FreeBSD sh Also, as there's no bashisms, that also means no bash arrays. I presume that this is hitting the /etc/init.d/util-vserver startup scripts /usr/lib/util-vserver/functions: line 778: `pkgmgmt.guessStyle': not a valid identifier Where to log a bug? What's the simplest way to temporarily workaround this? Cheers Ed W -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Thu, 2007-08-23 at 13:33 +0100, Ed W wrote: Regarding init scripts. Init scripts should now be strictly bourne or POSIX shell. ie, no bashisms. bash init scripts will work, but ONLY if /bin/sh is bash. Shells as /bin/sh that I've tested and found to be working are bash dash busybox zsh FreeBSD sh Also, as there's no bashisms, that also means no bash arrays. I presume that this is hitting the /etc/init.d/util-vserver startup scripts /usr/lib/util-vserver/functions: line 778: `pkgmgmt.guessStyle': not a valid identifier Where to log a bug? What's the simplest way to temporarily workaround this? Log a bug at http://bugs.gentoo.org The easiest fix is to change the . to _ in the function names. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Thu, 2007-08-23 at 14:17 +0100, Roy Marples wrote:
On Thu, 2007-08-23 at 13:33 +0100, Ed W wrote:
Regarding init scripts.
Init scripts should now be strictly bourne or POSIX shell. ie, no
bashisms. bash init scripts will work, but ONLY if /bin/sh is bash.
Shells as /bin/sh that I've tested and found to be working are
bash
dash
busybox
zsh
FreeBSD sh
Also, as there's no bashisms, that also means no bash arrays.
I presume that this is hitting the /etc/init.d/util-vserver startup scripts
/usr/lib/util-vserver/functions: line 778: `pkgmgmt.guessStyle': not a
valid identifier
Where to log a bug? What's the simplest way to temporarily workaround this?
Log a bug at http://bugs.gentoo.org
The easiest fix is to change the . to _ in the function names.
The util-vserver scripts are very bashish using arrays and every
function is declared as:
function funcname()
{
...
}
Those needs to be redeclared as:
funcname() {
...
}
I mentioned to the vserver list that i was interested to convert the
scripts to POSIX. First he said that he was not against it until he
realized he could no longer use arrays.
http://www.paul.sladen.org/vserver/archives/200708/0025.html
Does anyone have any suggestion to do dynamic variables cleanly without
using arrays?
Natanael Copa
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples escribió: On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote: We'll definitely want the same version stable across the board. I'll be sure to work with Roy and you to ensure we come to an agreement on what to use and that we're all on the same page. Fair enough. Should I open a bug (when the time comes) just requesting the blessing of the arch teams or just unmask it anyway? Note that the following arch's have been tested by people other than me amd64 arm ppc ppc64 sparc (fbsd only i think so far) x86 In alpha is under testing by Tobias Klausman (B|ackbird) but, a part from the net.eth0 lost link issue, seems to be sane AFAIK. We will be ready very soon. Thanks. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On 7/21/07, Roy Marples [EMAIL PROTECTED] wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. Hi! Just an issue I thought a long while ago... What about adding USE flags for all optional networking components... So that they installed without manually merging them one by one? Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Saturday 21 July 2007 16:36:03 Roy Marples wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. Well, that's about it. It's been a fun journey making baselayout-2 and we're almost at the end of this road :) Thanks Roy Hereby a friendly reminder that gcc-config should be keyworded as well, current gcc-config isn’t compatible with baselayout-2. According to Mike gcc-config-1.4.0 is compatible with baselayout-2. (doesn’t work on my system, but I haven’t investigated yet). -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote: 4) What baselayout will be used in the next release? (Maybe that's more of a releng question.) Whichever is stable around September(ish) time frame will be what we use, unless it is requested that we use something different. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote: 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when the first arches might be stabilizing 2.x? No. If the RC's prove stable and no serious regressions are reported for a month then we'll probably release a final 2.0.0 and get arch teams to mark stable a week later, or right away if no last minute changes have been made. What'd really be nice is if it goes stable for all arches (or at least all of the ones that matter, subjectively) either in time or after the next release. Otherwise, there's going to be some more complications from users who install from media containing old baselayout-1.x and have to deal with the new 2.x right away. I guess we'll see. /me pokes wolf31o2. ;) We'll definitely want the same version stable across the board. I'll be sure to work with Roy and you to ensure we come to an agreement on what to use and that we're all on the same page. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] baselayout-2 stablisation plans
On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote: We'll definitely want the same version stable across the board. I'll be sure to work with Roy and you to ensure we come to an agreement on what to use and that we're all on the same page. Fair enough. Should I open a bug (when the time comes) just requesting the blessing of the arch teams or just unmask it anyway? Note that the following arch's have been tested by people other than me amd64 arm ppc ppc64 sparc (fbsd only i think so far) x86 I did compile test it on a s390 a few months ago, but I seem to have lost my account there now. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Monday 23 July 2007, Roy Marples wrote: On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote: We'll definitely want the same version stable across the board. I'll be sure to work with Roy and you to ensure we come to an agreement on what to use and that we're all on the same page. Fair enough. Should I open a bug (when the time comes) just requesting the blessing of the arch teams or just unmask it anyway? open a bug, package.mask it, and let arch teams test it by filling out KEYWORDS ... once everyone is on board, unmask it I did compile test it on a s390 a few months ago, but I seem to have lost my account there now. that's cause you smell like poop. oh and we formatted those boxes. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] baselayout-2 stablisation plans
On Mon, 2007-07-23 at 22:24 +0100, Roy Marples wrote: On Mon, 2007-07-23 at 13:30 -0700, Chris Gianelloni wrote: We'll definitely want the same version stable across the board. I'll be sure to work with Roy and you to ensure we come to an agreement on what to use and that we're all on the same page. Fair enough. Should I open a bug (when the time comes) just requesting the blessing of the arch teams or just unmask it anyway? Well, the best for us is if it is already stable in the tree before we snapshot, as that means it was tested and stabilized prior to our snapshot and likely has more QA done on it before we even start the release. If we can do that, then Release Engineering will be set and we'll love you long time. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote: Roy Marples wrote: I don't actually know how to set those up or what the migration path would be. Maybe devzero and strerror could document this as I understand they do this. I manage systems with a single RAID 0 stripe (not dmraid) managed by device-mapper. When upgrading baselayout, we also have to upgrade to a recent device-mapper version which provides the device-mapper init script. Then we must run: # rc-update add device-mapper boot If we don't, we get an unbootable system. Probably a good idea to add that to the ebuild output too? Roy I added that ages ago. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. You should find someone from the GDP to write some user migration docs. The two things that spring to mind are having to use init scripts for device-mapper and crypto fs stuff (I can see lots of unbootable systems for those who don't realise this...) and having to compile the new splashutils *after* baselayout to keep fbsplash working. Thanks for all your work on baselayout-2! Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 12:15 -0400, Daniel Drake wrote: Roy Marples wrote: This is just a heads up for getting baselayout-2 stable. Next week I plan to put baselayout-2.0.0_rc1 into the tree without any keywords and it will be removed from package.mask (keeping the current alphas masked though). Arch teams will then be pinged on a bug to keyword baselayout-2. You should find someone from the GDP to write some user migration docs. Good idea. Any volunteers? The two things that spring to mind are having to use init scripts for device-mapper and crypto fs stuff (I can see lots of unbootable systems for those who don't realise this...) and having to compile the new splashutils *after* baselayout to keep fbsplash working. I don't actually know how to set those up or what the migration path would be. Maybe devzero and strerror could document this as I understand they do this. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: I don't actually know how to set those up or what the migration path would be. Maybe devzero and strerror could document this as I understand they do this. I manage systems with a single RAID 0 stripe (not dmraid) managed by device-mapper. When upgrading baselayout, we also have to upgrade to a recent device-mapper version which provides the device-mapper init script. Then we must run: # rc-update add device-mapper boot If we don't, we get an unbootable system. Daniel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote: Roy Marples wrote: I don't actually know how to set those up or what the migration path would be. Maybe devzero and strerror could document this as I understand they do this. I manage systems with a single RAID 0 stripe (not dmraid) managed by device-mapper. When upgrading baselayout, we also have to upgrade to a recent device-mapper version which provides the device-mapper init script. Then we must run: # rc-update add device-mapper boot If we don't, we get an unbootable system. Probably a good idea to add that to the ebuild output too? Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples kirjoitti: On Sat, 2007-07-21 at 12:45 -0400, Daniel Drake wrote: Roy Marples wrote: I don't actually know how to set those up or what the migration path would be. Maybe devzero and strerror could document this as I understand they do this. I manage systems with a single RAID 0 stripe (not dmraid) managed by device-mapper. When upgrading baselayout, we also have to upgrade to a recent device-mapper version which provides the device-mapper init script. Then we must run: # rc-update add device-mapper boot If we don't, we get an unbootable system. Probably a good idea to add that to the ebuild output too? Roy Yes. That coupled with the ~arch Portage elog output at the end of emerge will go a long a way to notifying users. If we would even have news on that of that... Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-2 stablisation plans
On 7/21/07, Roy Marples [EMAIL PROTECTED] wrote: Now there are, as usual, some daemons and init scripts that probably won't work. For those that don't, I have either fixed or there's patches in our bugzilla. Here's a rough summary. About the nscd issue we discussed on irc on friday (i.e. daemon not playing nice with parallel startup), your patch worked. It stayed on my work laptop, though, so I can't file a bug right now. But I'll do so monday morning. Oh, and by the way, baselayout-2 is great stuff, thanks ! Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote: (GDP): you give us the info, we'll document it for you. Or I will at least. Well, the changes are as outlined in my first email. The user changes are mainly a few variables in the /etc/conf.d/* files that baselayout ships. For example a few have been removed and a few have been added, and a few have changed. From our perspective, /etc/conf.d/* is quite well documented, so GDP could easily diff the files to see what has changed. Of equal concern to me, however are a few issues: 1) How will stabilization work? Is it a forced upgrade from stable 1.x to 2.x, or can it be slotted? It cannot be slotted in any way or form. Also, the daemon state data is non transferable as the format has changed in baselayout-2. This is the data that records how a daemon was started by s-s-d so we can check if it's running or not. However, most end users won't be concerned by this. I've tested the ebuilds for upgrading and downgrading quite extensively, with the following notes. baselayout-1 *requires* bash. As such /bin/sh should point to bash before downgrading. If the /etc/init.d files are not immediately updated by etc-update or other means then errors will happen. What errors and how severe entirely depend on the scripts the user has in /etc/init.d 2) It will be completely unmanageable to have more than one set of baselayout instructions in the handbook other docs, so there definitely is a need for the migration doc. That's your call. 3) How long will 1.x be kept stable? (This affects how long the old instructions are in the handbooks etc.) Good question. We normally keep at least one major revision prior to the current stable in the tree. They can stay in the tree indefinitely I suppose, but the GDP should only follow the current stable. Maybe archive the handbook? 4) What baselayout will be used in the next release? (Maybe that's more of a releng question.) baselayout team just makes baselayout releases. If you mean the LiveCD then ask releng. 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when the first arches might be stabilizing 2.x? No. If the RC's prove stable and no serious regressions are reported for a month then we'll probably release a final 2.0.0 and get arch teams to mark stable a week later, or right away if no last minute changes have been made. This is all from the GDP's perspective, almost none of it is of interest to me as a user; I expect this sh** to work just as well as baselayout-1.x when I hit the upgrade myself. :) In theory it should just work. Especially as Gentoo/FreeBSD has been running it as our standard baselayout for around 6 months now. So hopefully this should be a very smooth release. Documenting this will be a major arsepain--er, effort--since baselayout 1.x directions are already mixed in so well with pretty much every doc we have. I'm not at all looking forward to fixing the docs when the time comes, but I will do it provided I get to borrow your brain for a good long time. :) Most of the documentation should still apply. I've tried to be as compatible as possible - the one possible exception being networking as baselayout-1 used bash arrays extensively. But we still support that if /bin/sh is bash, which it is by default for Gentoo/Linux Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Saturday 21 July 2007, Roy Marples wrote: On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote: From our perspective, /etc/conf.d/* is quite well documented, so GDP could easily diff the files to see what has changed. Of equal concern to me, however are a few issues: 1) How will stabilization work? Is it a forced upgrade from stable 1.x to 2.x, or can it be slotted? It cannot be slotted in any way or form. Also, the daemon state data is non transferable as the format has changed in baselayout-2. This is the data that records how a daemon was started by s-s-d so we can check if it's running or not. However, most end users won't be concerned by this. I've tested the ebuilds for upgrading and downgrading quite extensively, with the following notes. baselayout-1 *requires* bash. As such /bin/sh should point to bash before downgrading. If the /etc/init.d files are not immediately updated by etc-update or other means then errors will happen. What errors and how severe entirely depend on the scripts the user has in /etc/init.d i really think this bash vs POSIX issue is getting way more emphasis than it should. i'd make the claim the majority of people out there dont even know about /bin/sh, bash, dash, and friends, so most people out there will have /bin/sh pointing to bash and as such, none of these things will be an issue for them. anyone who has tried to switch /bin/sh to point to something else has already seen their system blow up. or they're using baselayout-2 and so they're aware of the issues. in other words, you want to put info in there about POSIX shell and changing your conf.d files, great ... but dont emphasize it like it's doomsday and all hell's gonna break loose when you upgrade. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 15:28 -0400, Mike Frysinger wrote: i really think this bash vs POSIX issue is getting way more emphasis than it should. i'd make the claim the majority of people out there dont even know about /bin/sh, bash, dash, and friends, so most people out there will have /bin/sh pointing to bash and as such, none of these things will be an issue for them. anyone who has tried to switch /bin/sh to point to something else has already seen their system blow up. or they're using baselayout-2 and so they're aware of the issues. in other words, you want to put info in there about POSIX shell and changing your conf.d files, great ... but dont emphasize it like it's doomsday and all hell's gonna break loose when you upgrade. True enough, but now I've said it I'll sleep better tonight knowing that I've at least warned some people who think wow - baselayout-2 supports *faster* shells like busybox. I'll rock with my -fomg-optimized flags. IE ricers who then bitch that their box is broke if they downgrade. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Hi! [... baselayout-2 is on the horizon ...] Is there a common bug to report snags to? I've hit one: /etc/init.d/net.eth0 used to be a symlink to net.lo. After installing, it was gone (I figure it went with baselayout-1). Luckily, I have direct console access, otherwise the machine would have been gone after the reboot. Definitely something to yell about during merging. Regards, Tobias PS: If said bug exists, I'll gladly re-report there, but my cursory search didn't turn up anything. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote: Is there a common bug to report snags to? I've hit one: /etc/init.d/net.eth0 used to be a symlink to net.lo. After installing, it was gone (I figure it went with baselayout-1). Luckily, I have direct console access, otherwise the machine would have been gone after the reboot. Definitely something to yell about during merging. We don't ship with net.eth0 because there is no guarantee an interface called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just ship that. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote: On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote: Is there a common bug to report snags to? I've hit one: /etc/init.d/net.eth0 used to be a symlink to net.lo. After installing, it was gone (I figure it went with baselayout-1). Luckily, I have direct console access, otherwise the machine would have been gone after the reboot. Definitely something to yell about during merging. We don't ship with net.eth0 because there is no guarantee an interface called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just ship that. One very good idea would be to get udev to create any net links that do not exist to net.lo Then we truly have plug and play :) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Saturday 21 July 2007, Roy Marples wrote: On Sat, 2007-07-21 at 21:28 +0100, Roy Marples wrote: On Sat, 2007-07-21 at 22:22 +0200, Tobias Klausmann wrote: Is there a common bug to report snags to? I've hit one: /etc/init.d/net.eth0 used to be a symlink to net.lo. After installing, it was gone (I figure it went with baselayout-1). Luckily, I have direct console access, otherwise the machine would have been gone after the reboot. Definitely something to yell about during merging. We don't ship with net.eth0 because there is no guarantee an interface called eth0 exists. net.lo (net.lo0 in *BSDs) always exists so we just ship that. One very good idea would be to get udev to create any net links that do not exist to net.lo Then we truly have plug and play :) indeed, that'd be sleeky and sexy ... go file a bug ;) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] baselayout-2 stablisation plans
Denis Dupeyron a écrit : About the nscd issue we discussed on irc on friday (i.e. daemon not playing nice with parallel startup), your patch worked. It stayed on my work laptop, though, so I can't file a bug right now. But I'll do so monday morning. I'll add mine about the dhcdbd patch you gave me 2 weeks ago. Works great. Oh, and by the way, baselayout-2 is great stuff, thanks ! +1 on that as well. Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote: indeed, that'd be sleeky and sexy ... go file a bug ;) Let bug #186156 [1] be henceforth known as the sleeky and sexy bug! [1] http://bugs.gentoo.org/show_bug.cgi?id=186156 Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roy Marples wrote: On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote: indeed, that'd be sleeky and sexy ... go file a bug ;) Let bug #186156 [1] be henceforth known as the sleeky and sexy bug! [1] http://bugs.gentoo.org/show_bug.cgi?id=186156 Thanks As you wish! [1] :) [1] http://bugs.gentoo.org/show_activity.cgi?id=186156 - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGooZEtbrAj05h3oQRApS1AKCU0vyw+Oka3yPc4bByDHxPyQEDFwCgpzIL F8ot8iOS1irR5UlcvDgpxFY= =Ydgn -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: On Sat, 2007-07-21 at 11:48 -0700, Josh Saddler wrote: (GDP): you give us the info, we'll document it for you. Or I will at least. Well, the changes are as outlined in my first email. The user changes are mainly a few variables in the /etc/conf.d/* files that baselayout ships. For example a few have been removed and a few have been added, and a few have changed. Yeah, I planned on doing some heavy reading of the new stuff, but I hope I can get you all alone (heh heh heh) for awhile to go over questions that will surely pop up. In case things like new networking configs aren't intuitive, or whatever. 3) How long will 1.x be kept stable? (This affects how long the old instructions are in the handbooks etc.) Good question. We normally keep at least one major revision prior to the current stable in the tree. They can stay in the tree indefinitely I suppose, but the GDP should only follow the current stable. Maybe archive the handbook? Archiving the handbook isn't possible. The only thing we archive for historical purposes are the networkless handbooks, in /doc/en/handbook/2006.0/, 2006.1/, etc. I'm thinking that if baselayout-2 is the way of the future, then as soon as it's stabled for all arches (see below for a bit more) then we should pretty much just document that exclusively in all handbooks docs. That's where a migration guide will be so crucial. Since the thing can't be slotted, and it's a forced upgrade (short of masking, but BAH to those users that do it), I don't think we need to document two completely different systems if they're both stable. 5) Do you have a rough estimate (month, 3 weeks, 5 weeks, what?) on when the first arches might be stabilizing 2.x? No. If the RC's prove stable and no serious regressions are reported for a month then we'll probably release a final 2.0.0 and get arch teams to mark stable a week later, or right away if no last minute changes have been made. What'd really be nice is if it goes stable for all arches (or at least all of the ones that matter, subjectively) either in time or after the next release. Otherwise, there's going to be some more complications from users who install from media containing old baselayout-1.x and have to deal with the new 2.x right away. I guess we'll see. /me pokes wolf31o2. ;) Most of the documentation should still apply. I've tried to be as compatible as possible - the one possible exception being networking as baselayout-1 used bash arrays extensively. But we still support that if /bin/sh is bash, which it is by default for Gentoo/Linux Yeah. Though I still don't know the whole story, I anticipate that updating the networking configs will be the biggest headache. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-2 stablisation plans
On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote: Archiving the handbook isn't possible. Why? Unless I'm missing something, it should be fairly trivial. What'd really be nice is if it goes stable for all arches (or at least all of the ones that matter, subjectively) either in time or after the next release. That's kinda the plan. When the base system team was 4 people, we all agreed that we just make it stable as it was mostly script based and needed to be done at the same time. I'd like to treat baselayout-2 the same, but as we're mostly C based it's up to the arch teams to decide. Most of the documentation should still apply. I've tried to be as compatible as possible - the one possible exception being networking as baselayout-1 used bash arrays extensively. But we still support that if /bin/sh is bash, which it is by default for Gentoo/Linux Yeah. Though I still don't know the whole story, I anticipate that updating the networking configs will be the biggest headache. Only for non bash /bin/sh - like FreeBSD. But we don't have a handbook for that yet so it's no worry :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: On Sat, 2007-07-21 at 17:25 -0700, Josh Saddler wrote: Archiving the handbook isn't possible. Why? Unless I'm missing something, it should be fairly trivial. It ain't. It's an old issue. Current networked (requires a net connection to install) handbooks go to /doc/en/handbook/. Networkless (needs no net connection, only a liveCD of some sort) goes to /doc/en/handbook/release_number/, like /2007.0/. Whenever there's a new release, we can archive the networkless versions because we just add a new dir for the latest version number. But everything in /doc/en/handbook/ (networked) gets overwritten with the stuff for the new release. No way we can archive anything but the networkless handbooks. Besides, that's mostly what you'd want anyway -- if you do the much more up-to-date networked install, you're going to pull in all the new stuff like baselayout-2 anyway, so you wouldn't want the old directions. That's the theory, at least. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] baselayout-2 stablisation plans
Roy Marples wrote: 4) What baselayout will be used in the next release? (Maybe that's more of a releng question.) baselayout team just makes baselayout releases. If you mean the LiveCD then ask releng. It'll be whatever version of baselayout is stable at the time we take the initial release snapshot. However, if baselayout-2 will go stable a week after we take the initial snapshot, it would probably be incorporated. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
