Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
Sven Luther
Now that we have a solution for the ramdisk generation tool mess, we can go
ahead, and outline a plan for bringing 2.6.13 to sid, and then go ahead and do
the same with 2.6.14 shortly after that, while 2.6.12 is safely in etch.
As mentioned in :
...
the plan for solving the ramdisk issues is done in three stages, current svn
2.6.13 packages implement stage 1, i have patches for both initrd-tools and
initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go
ahead and upload those nextly (if it could be in by monday, that would be
nice). I will work on the last stage, the kernel-package patch, this WE, and
do an NMU since Manoj is unavailable for the next times and asked us to do so.
Once the fixed kernel-package is in the archive, we can then follow up and
upload 2.6.13-2 to experimental, which will allow us to fine test all this and
confirm that it works well, and then after some time, upload -3 to unstable,
which will allow for more widespread testing, but see below.
On a separate issue, current 2.6.13-1 had some serious build issue, which are
not yet all fixed in svn, but the current svn status is :
Building : alpha powerpc i386 amd64 sparc
Broken but being worked on : s390 m68k
Broken but not being worked on yet : hppa ia64
No information : arm
Not in the common package : mips mipsel
So, an upload of -2 will work on at least 5 arches out of 10, so this is a
call for hppa, ia64, arm, s390 and m68k porter to fix these issues, hopefully
for the -2 timeframe, but at least for the -3 timeframe.
The other issue is that 2.6.14 is scheduled for release in the not so distant
future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
depending on status of newly introduced breakage in .14 and such.
Ok, so now a tentative timeline for things to happen :
Monday, october 17 : last call for upload of fixed yaird, initrd-tools,
initramfs-tools, kernel-package.
Wednesday, october 19 : last call for the -2 upload, any arches not fixed by
then will have to wait for -3.
Tuesday, october 25 : upload of -3 into sid, hopefully with all arches
fixed, but this will be up to the porters.
The alternative track is to drop -3, and start working on .14, and make a
.14-1 upload to experimental somewhen in the week 43, the one of monday ocober
24. In any case, we don't intend to move .13 to etch.
Comments ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastian Blank
> the plan for solving the ramdisk issues is done in three stages, current svn
> 2.6.13 packages implement stage 1, i have patches for both initrd-tools and
> initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go
> ahead and upload those nextly (if it could be in by monday, that would be
> nice). I will work on the last stage, the kernel-package patch, this WE, and
> do an NMU since Manoj is unavailable for the next times and asked us to do so.
initramfs-tools waits for mklibs.
> Broken but being worked on : s390
Broken gcc or inline assembly, the IBM people expect the later. Hope
that I get a fix from them at monday.
> The other issue is that 2.6.14 is scheduled for release in the not so distant
> future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> depending on status of newly introduced breakage in .14 and such.
I vote for the later.
Bastian
--
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9
Sven Luther
> On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> > the plan for solving the ramdisk issues is done in three stages, current svn
> > 2.6.13 packages implement stage 1, i have patches for both initrd-tools and
> > initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go
> > ahead and upload those nextly (if it could be in by monday, that would be
> > nice). I will work on the last stage, the kernel-package patch, this WE, and
> > do an NMU since Manoj is unavailable for the next times and asked us to do so.
>
> initramfs-tools waits for mklibs.
Well, we can go ahead with yaird for now, what is the mklibs issue ? Or can
mklibs be disabled for now ?
> > Broken but being worked on : s390
>
> Broken gcc or inline assembly, the IBM people expect the later. Hope
> that I get a fix from them at monday.
Ok, as said, if not, it can wait for -3.
> > The other issue is that 2.6.14 is scheduled for release in the not so distant
> > future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> > depending on status of newly introduced breakage in .14 and such.
>
> I vote for the later.
Hehe, but this does suppose we create now another branch and start porting the
patches and configs, i see nobody volunteering to do that.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-bo...@lists.debian.org
Horms
> On Sat, Oct 15, 2005 at 01:07:38PM +0200, Bastian Blank wrote:
> > On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> > > the plan for solving the ramdisk issues is done in three stages, current svn
> > > 2.6.13 packages implement stage 1, i have patches for both initrd-tools and
> > > initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go
> > > ahead and upload those nextly (if it could be in by monday, that would be
> > > nice). I will work on the last stage, the kernel-package patch, this WE, and
> > > do an NMU since Manoj is unavailable for the next times and asked us to do so.
> >
> > initramfs-tools waits for mklibs.
>
> Well, we can go ahead with yaird for now, what is the mklibs issue ? Or can
> mklibs be disabled for now ?
>
> > > Broken but being worked on : s390
> >
> > Broken gcc or inline assembly, the IBM people expect the later. Hope
> > that I get a fix from them at monday.
>
> Ok, as said, if not, it can wait for -3.
>
> > > The other issue is that 2.6.14 is scheduled for release in the not so distant
> > > future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> > > depending on status of newly introduced breakage in .14 and such.
> >
> > I vote for the later.
>
> Hehe, but this does suppose we create now another branch and start porting the
> patches and configs, i see nobody volunteering to do that.
I vote for not creating another breach. I vote for moving to .14
(or some -rc variant thereof). Its unlikelty to make much difference
on the initrd front and saves duplication of effort that is inherent
in the more branches approach.
--
Horms
maximilian attems
On Sat, 15 Oct 2005, Bastian Blank wrote:
> > The other issue is that 2.6.14 is scheduled for release in the not so distant
> > future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> > depending on status of newly introduced breakage in .14 and such.
>
> I vote for the later.
>
> Bastian
i agree 2.6.14 will happen pretty soon.
btw svenl what happened with all the powerpc patches,
didn't see a lot of them merged upstream, maybe i'm mistaken?
please push them through benh to -mm so that they
can be merged in the first 2 weeks.
--
maks
Sven Luther
> > > > The other issue is that 2.6.14 is scheduled for release in the not so distant
> > > > future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> > > > depending on status of newly introduced breakage in .14 and such.
> > >
> > > I vote for the later.
> >
> > Hehe, but this does suppose we create now another branch and start porting the
> > patches and configs, i see nobody volunteering to do that.
>
> I vote for not creating another breach. I vote for moving to .14
> (or some -rc variant thereof). Its unlikelty to make much difference
> on the initrd front and saves duplication of effort that is inherent
> in the more branches approach.
Well, but are we really ready to lose the relative stability of the 2.6.13
packages now and redo all the patch triaging and config file fixing ? I am
perosnally strongly in favour of going with 2.6.14-rc4 (in a 2.6.13.99-1
package), but we need at least to rework on the patches to do that. I will not
be able to do that, except for powerpc, and i see nobody prepared to do it,
unless you and waldi just volunteered to do this before monday :)
Friendly,
Sven Luther
Sven Luther
> [snipping the cc list ]
>
> On Sat, 15 Oct 2005, Bastian Blank wrote:
>
> > > The other issue is that 2.6.14 is scheduled for release in the not so distant
> > > future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> > > depending on status of newly introduced breakage in .14 and such.
> >
> > I vote for the later.
> >
> > Bastian
>
> i agree 2.6.14 will happen pretty soon.
>
> btw svenl what happened with all the powerpc patches,
> didn't see a lot of them merged upstream, maybe i'm mistaken?
I was busy in the post-2.6.13 patch pushing period, so ...
> please push them through benh to -mm so that they
> can be merged in the first 2 weeks.
ok, will do, but it may be possible that i will again be busy in the
post-2.6.14 patch pushing period, but then i hope that some of the patches,
like the serial one, will be fixed by others, maybe already for 2.6.14, we
will see.
On another side, many of those patches where for breakage introduced by
upstream, which i reported and should already have been in 2.6.13, so ...
Friendly,
Sven Luther
Sven Luther
>
> Now that we have a solution for the ramdisk generation tool mess, we can go
> ahead, and outline a plan for bringing 2.6.13 to sid, and then go ahead and do
> the same with 2.6.14 shortly after that, while 2.6.12 is safely in etch.
Oh well, i had a quick look at the needed code in the postinsts, but i have to
admit that i will not be able to do this, perl being like chinese to me :/
The code is :
my $ramdisk = '/usr/sbin/mkinitrd'; # Tool to create initial ram fs.
$ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig;
my $ret = system("$ramdisk " .
($mkimage ? "-m '$mkimage' " : "") .
"-o $initrd_path.new $modules_base/$version");
Well, i understand this, but i don't know how to do what is needed, namely :
1) depending on $version, default to /usr/sbin/mkinitrd (for pre-2.6.13
kernels) or mkinitramfs or yaird. Maybe initramfs for now.
2) parse the ramdisk option and put the space-separated entries in some kind
of list.
3) for each element in the list, check if :
3.1) it is an executable binary that exists.
3.2) calling it with --supported-host-version=`uname -r`
--supported-target-version=$version and check the return value is 0.
and eliminate all entries which don't verify the above.
4) Take the first in the list and use it to build the ramdisk.
5) if the list is empty, fail and inform the user.
I would be extremely grateful if someone could take the time and implement
this ASAP, as we need this to upload 2.6.13-2 and finish the support.
Mattia Dongili
It's not entirely clear to me but the following might help. I'm missing
some bits but if you can give me more insight I'll fix the wrong stuff
(sorry I never played seriously with initrd :) )
#!/usr/bin/perl
use strict;
chomp (my $unamedashr = `uname -r`);
#
# is lexical comparison enough ?? <---------
# 2.6.13-rc1 will result in being greater than 2.6.13
#
my $ramdisk = '/usr/sbin/initramfs' if ($unamedashr lt "2.6.13");
$ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig;
# points 2) 3) of your list
my @ramdisklist =
grep {
-x and
system ("$_ --supported-host-version=$unamedashr 1>/dev/null 2>&1") == 0
}
(split (/ /, $ramdisk));
# point 4) and 5)
defined ($ramdisk = shift @ramdisklist)
|| die "Dear user I failed to find an usable tool to create initial ram fs";
my $ret = system("$ramdisk " .
($mkimage ? "-m '$mkimage' " : "") .
"-o $initrd_path.new $modules_base/$version");
--
mattia
:wq!
Sven Luther
> On Sat, Oct 15, 2005 at 08:36:11PM +0200, Sven Luther wrote:
> > I would be extremely grateful if someone could take the time and implement
> > this ASAP, as we need this to upload 2.6.13-2 and finish the support.
>
> It's not entirely clear to me but the following might help. I'm missing
> some bits but if you can give me more insight I'll fix the wrong stuff
> (sorry I never played seriously with initrd :) )
Thanks Mattia, i am extremely thankful for your help. Let's me go over this
proposed code with you to see if i understood well, and add places where it
did not work out.
> #!/usr/bin/perl
> use strict;
>
> chomp (my $unamedashr = `uname -r`);
We get the kernel version.
> #
> # is lexical comparison enough ?? <---------
> # 2.6.13-rc1 will result in being greater than 2.6.13
We need to use dpkg --compare-versions here, so probably :
> #
> my $ramdisk = '/usr/sbin/initramfs' if ($unamedashr lt "2.6.13");
my $ramdisk = '/usr/sbin/mkinitramfs' if (system ("dpkg --compare-versions $unamedashr lt 2.6.13 1>/dev/null 2>&1") == 0)
or something such, but i suppose that this line is precedded by a more generic :
my $ramdisk = '/usr/sbin/mkinitrd', right ?
> $ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig;
Does this one not cut at the first space ? I was told to use split instead, or
something such.
>
> # points 2) 3) of your list
> my @ramdisklist =
> grep {
> -x and
> system ("$_ --supported-host-version=$unamedashr 1>/dev/null 2>&1") == 0
> }
> (split (/ /, $ramdisk));
Ok, so we try -x and the call, over the space separadet ramdisk list.
>
> # point 4) and 5)
> defined ($ramdisk = shift @ramdisklist)
> || die "Dear user I failed to find an usable tool to create initial ram fs";
We redefine ramdisk to the first element of the list, and die if it is empty.
> my $ret = system("$ramdisk " .
> ($mkimage ? "-m '$mkimage' " : "") .
> "-o $initrd_path.new $modules_base/$version");
And we do the ramdisk call, as normal.
This sounds very nice and very near what i wanted to do, so again, i express
my extreme thanks for you jumping in. So if the first line change is ok, and
the ramdisk = "$1" ... thingy indeed pulls in space also, we have something
which can be uploaded.
Sven Luther
>
> Now that we have a solution for the ramdisk generation tool mess, we can go
> ahead, and outline a plan for bringing 2.6.13 to sid, and then go ahead and do
> the same with 2.6.14 shortly after that, while 2.6.12 is safely in etch.
Ok, thanks to Mattia Dongili i have created a tentative new kernel-package
which i uploaded here :
http://people.debian.org/~luther/ramdisk
together with the fixed initrd-tools and initramfs-tools (Jonas, can you send
me the fixed yaird, so i can put it there also ?).
I am not 100% sure of the kernel-package fix, so i added the kernel-package
diff there also (and attached it here), and i would like inspection of it as
much as possible, as well as testing with real kernels in all possible
situations.
To test, you need to install the new kernel-package, and rebuild linux-2.6,
and then install the yaird | initrd-tools | initramfs-tools, and then install
the resulting kernel image and see if it is ok, and play a bit with the
ramdisk= entries in /etc/kernel-img.conf.
It would be nice also to see how this would react with older kernels.
Also, the current patch is not checking the case of not-supporting the
--supported-(host|target)-version stuff, so this either needs to be added as a
check or better yet, have kernel-package add an explicit conflict to
kernel-package generated kernel images.
So, i would appreciate comments on this, and if someone with more perl
experience could look this over, and maybe partially take over for the next
2/3 days, as i will not have much time for debian until wednesday myself.
Friendly,
Sven Luther
Mattia Dongili
> On Sat, Oct 15, 2005 at 10:16:48PM +0200, Mattia Dongili wrote:
> > On Sat, Oct 15, 2005 at 08:36:11PM +0200, Sven Luther wrote:
> > > I would be extremely grateful if someone could take the time and implement
> > > this ASAP, as we need this to upload 2.6.13-2 and finish the support.
> >
> > It's not entirely clear to me but the following might help. I'm missing
> > some bits but if you can give me more insight I'll fix the wrong stuff
> > (sorry I never played seriously with initrd :) )
>
> Thanks Mattia, i am extremely thankful for your help. Let's me go over this
> proposed code with you to see if i understood well, and add places where it
> did not work out.
>
> > #!/usr/bin/perl
> > use strict;
> >
> > chomp (my $unamedashr = `uname -r`);
>
> We get the kernel version.
>
> > #
> > # is lexical comparison enough ?? <---------
> > # 2.6.13-rc1 will result in being greater than 2.6.13
>
> We need to use dpkg --compare-versions here, so probably :
>
> > #
> > my $ramdisk = '/usr/sbin/initramfs' if ($unamedashr lt "2.6.13");
>
> my $ramdisk = '/usr/sbin/mkinitramfs' if (system ("dpkg --compare-versions $unamedashr lt 2.6.13 1>/dev/null 2>&1") == 0)
right
> or something such, but i suppose that this line is precedded by a more generic :
> my $ramdisk = '/usr/sbin/mkinitrd', right ?
>
> > $ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig;
>
> Does this one not cut at the first space ? I was told to use split instead, or
> something such.
Aaah! I see the point now. I was missing the usefullness of that
statement in fact!
Yes, the above regex assigns to $ramdisk only the first element in a
space separated list.
We might rework it this way (I'm borrowing your comments to the code)
then:
#!/usr/bin/perl
use strict;
# We get the kernel version.
chomp (my $unamedashr = `uname -r`);
# slurp the ramdisk option if present or default 'initramfs' for kernels
# prior 2.6.13 or default to 'mkinitrd' if none of the previous apply
my $ramdiskopts = (/ramdisk\s*=\s*(.+)/ig ? "$1" :
(system("dpkg --compare-versions $unamedashr lt 2.6.13 1>/dev/null 2>&1") == 0 ?
"/usr/sbin/initramfs" : "/usr/sbin/mkinitrd"));
# Ok, so we try -x and the call, over the space separadet ramdisk list.
# The remaining list won't have those items failing the tests.
my @ramdisklist =
grep {
-x and
system ("$_ --supported-host-version=$unamedashr 1>/dev/null 2>&1") == 0
}
split (/ /, $ramdiskopts);
# We define ramdisk to the first element of the list, and die if it is empty.
defined (my $ramdisk = shift @ramdisklist)
|| die "Dear user I failed to find an usable tool to create inital ram fs";
# And we do the ramdisk call, as normal.
my $ret = system("$ramdisk " .
($mkimage ? "-m '$mkimage' " : "") .
"-o $initrd_path.new $modules_base/$version");
> This sounds very nice and very near what i wanted to do, so again, i express
> my extreme thanks for you jumping in. So if the first line change is ok, and
> the ramdisk = "$1" ... thingy indeed pulls in space also, we have something
> which can be uploaded.
Take a look at the above corrected version, it should do what you want
now :)
Oh, I'm sorry for the code style, it could be made clearer by separating
some statements, but... you know perl is not for clean code ;)
--
mattia
:wq!
Sven Luther
> # slurp the ramdisk option if present or default 'initramfs' for kernels
> # prior 2.6.13 or default to 'mkinitrd' if none of the previous apply
> my $ramdiskopts = (/ramdisk\s*=\s*(.+)/ig ? "$1" :
> (system("dpkg --compare-versions $unamedashr lt 2.6.13 1>/dev/null 2>&1") == 0 ?
> "/usr/sbin/initramfs" : "/usr/sbin/mkinitrd"));
Oh, and btw, it should be mkinitramfs for >= 2.6.13, and mkinitrd in other
cases, so i need a ge instead of lt, right ?
Sven Luther
> On Sun, Oct 16, 2005 at 08:18:02AM +0200, Sven Luther wrote:
> > On Sat, Oct 15, 2005 at 10:16:48PM +0200, Mattia Dongili wrote:
> > We need to use dpkg --compare-versions here, so probably :
> >
> > > #
> > > my $ramdisk = '/usr/sbin/initramfs' if ($unamedashr lt "2.6.13");
> >
> > my $ramdisk = '/usr/sbin/mkinitramfs' if (system ("dpkg --compare-versions $unamedashr lt 2.6.13 1>/dev/null 2>&1") == 0)
>
> right
Ok.
> > or something such, but i suppose that this line is precedded by a more generic :
> > my $ramdisk = '/usr/sbin/mkinitrd', right ?
> >
> > > $ramdisk = "$1" if /ramdisk\s*=\s*(\S+)/ig;
> >
> > Does this one not cut at the first space ? I was told to use split instead, or
> > something such.
>
> Aaah! I see the point now. I was missing the usefullness of that
> statement in fact!
> Yes, the above regex assigns to $ramdisk only the first element in a
> space separated list.
Indeed.
This seems nicer in fact than my solution.
> > This sounds very nice and very near what i wanted to do, so again, i express
> > my extreme thanks for you jumping in. So if the first line change is ok, and
> > the ramdisk = "$1" ... thingy indeed pulls in space also, we have something
> > which can be uploaded.
>
> Take a look at the above corrected version, it should do what you want
> now :)
> Oh, I'm sorry for the code style, it could be made clearer by separating
> some statements, but... you know perl is not for clean code ;)
No problem, the code needs to be split in three and sprinkled all over the
postinst and co files anyway :)
Mattia Dongili
> On Sun, Oct 16, 2005 at 12:35:29PM +0200, Mattia Dongili wrote:
> > # slurp the ramdisk option if present or default 'initramfs' for kernels
> > # prior 2.6.13 or default to 'mkinitrd' if none of the previous apply
> > my $ramdiskopts = (/ramdisk\s*=\s*(.+)/ig ? "$1" :
> > (system("dpkg --compare-versions $unamedashr lt 2.6.13 1>/dev/null 2>&1") == 0 ?
> > "/usr/sbin/initramfs" : "/usr/sbin/mkinitrd"));
>
> Oh, and btw, it should be mkinitramfs for >= 2.6.13, and mkinitrd in other
> cases, so i need a ge instead of lt, right ?
Ah, yes. sorry. Or you could swap
"/usr/sbin/mkinitrd" : "/usr/sbin/initramfs"
--
mattia
:wq!
Sven Luther
Here is a quick sunday evening update on the status of things concerning
the ramdisk generation tools migration :
- a fixed yaird and initrd-tools has been uploaded, but probably missed
dinstall, will be in unstable by monday's run.
- i (temporarily while Manoj is unavailable) imported kernel-package 9.008
into svn, and Thanks to Mattia Dongili was able to implement a tentative
solution. There is still a bit of work, see below.
- i created a kernel/releases/trunk/linux-2.6-2.6.14-rc4 branch, and
compiled it for powerpc with the above kernel-package. Not sure if the
kernel-img.conf parsing worked fine, but the default choice was ok.
- i tested all three patched ramdisk generation tools against a suitable set
of scenarios, and they worked just fine :
2.6 host, 2.4 kernel -> initrd-tools OK initramfs-tools NOK yaird NOK.
2.6 host, 2.6.8 kernel -> initrd-tools OK initramfs-tools NOK yaird OK.
2.6 host, 2.6.12 kernel -> initrd-tools OK initramfs-tools OK yaird OK.
2.6 host, 2.6.14-rc4 kernel -> initrd-tools NOK initramfs-tools OK yaird OK.
2.4 host, 2.4 kernel -> initrd-tools OK initramfs-tools NOK yaird NOK.
2.4 host, 2.6.8 kernel -> initrd-tools OK initramfs-tools NOK yaird NOK.
2.4 host, 2.6.12 kernel -> initrd-tools OK initramfs-tools OK yaird NOK.
2.4 host, 2.6.14-rc4 kernel -> initrd-tools NOK initramfs-tools OK yaird NOK.
- i added a conflict with non-fixed versions of the ramdisk generation tools
to linux-2.6 2.6.13 and 2.6.14-rc4 :
initramfs-tools (<< 0.31), yaird (<< 0.0.11-5), initrd-tools (<< 0.1.83)
Things still needing work :
- initramfs-tools needs to be uploaded, it seems to wait for mklibs in NEW,
but i was able to build it just fine, no idea what is going on here.
- initrd-tools and initramfs-tools may need a cleaning up of their patches
comparable to what was done with yaird. The current solution works though,
but a second set of (shell expert) eyes going over it with regard to the
yaird solution would be welcome.
- kernel-package needs to be uploaded, but before that :
o manpage and other documentation need to be changed to reflect these
modifications.
o kernel-package should add a conflict line to the generated kernel
images, this is not needed for official images, since we override
that, but it needed for self-built images. The line is :
Conflicts: initramfs-tools (<< 0.31), yaird (<< 0.0.11-5), initrd-tools (<< 0.1.83)
- in general the messages implemented in all these fixes i wrote need to be
checked for style and english :)
- we need extensive testing of this new setup in any number of cases. I did
so on powerpc, to some extent, but only with a 2.6.12 host and a
2.6.14-rc4 target. We need to see also what happens with 2.4.7 and 2.6.8
kernels, both as host and target.
Once that is done, the ramdisk migration should be complete, and we can upload
either 2.6.13-2 and/or 2.6.13+2.6.14-rc4-1 to experimental, and let people
test it some, and then, after a suitable time, preferably at around the 2.6.14
release, we can upload it to unsatble.
Like said, i created the 2.6.14-rc4 branch, to test some patches, and it went
surprisingly well for powerpc, so it may well be possible to forget about
2.6.13 and go with this one directly, especially if we want to try to upload
2.6.14 soonishly after its upstream release. it seems amd64 and powerpc did
ok, not sure about the other arches, so porters should work on it.
Also, i will not have much time for this during at least the first half of
next week, so i would appreciate if someone else would take over from this
point for the remaining issues.
Bastian Blank
> - initramfs-tools needs to be uploaded, it seems to wait for mklibs in NEW,
> but i was able to build it just fine, no idea what is going on here.
This is fixed since yesterday.
Bastian
--
It is undignified for a woman to play servant to a man who is not hers.
-- Spock, "Amok Time", stardate 3372.7
Sven Luther
> On Mon, Oct 17, 2005 at 12:52:09AM +0200, Sven Luther wrote:
> > - initramfs-tools needs to be uploaded, it seems to wait for mklibs in NEW,
> > but i was able to build it just fine, no idea what is going on here.
>
> This is fixed since yesterday.
Over cool :)
I had a quick look at the yaird diff, but it uses getopt vs getopts (or
vice-versa), and this would mean changing initramfs-tools (and initrd-tools)
beyond what i am confortable dealing with in a hurry, so your call.
Also, like said, i would appreciate a review of my user-message and man page
changes, for style and english.
Jonas Smedegaard
Hash: SHA1
On Mon, 17 Oct 2005 09:23:57 +0200
Sven Luther <sven....@wanadoo.fr> wrote:
> I had a quick look at the yaird diff, but it uses getopt vs getopts
> (or vice-versa), and this would mean changing initramfs-tools (and
> initrd-tools) beyond what i am confortable dealing with in a hurry,
> so your call.
Switched mkinitrd and mkinitramfs in SVN to using GNU getopts now.
I have tested only lightly (which has bitten me in the past with
similar hacking on lessdisks) so please test more before releasing the
code.
Jeff: I noticed that you allow the -r option but seem to not actually
do anything about it - contrary to what's documented in the manpage.
Also, I noticed some unquoted strings - would you mind me going over it
and tighten up - or perhaps rather do it yourself?
- - Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDU3VQn7DbMsAkQLgRAjbTAKCMIUyNoMHP9HVQgjzSuR6wplc4qQCghOex
w3OzvBwAcD1QCFPIrAtKnnU=
=Y6tC
-----END PGP SIGNATURE-----
Maximilian Attems
> On Mon, 17 Oct 2005 09:23:57 +0200
> Sven Luther <sven....@wanadoo.fr> wrote:
>
> > I had a quick look at the yaird diff, but it uses getopt vs getopts
> > (or vice-versa), and this would mean changing initramfs-tools (and
> > initrd-tools) beyond what i am confortable dealing with in a hurry,
> > so your call.
>
> Switched mkinitrd and mkinitramfs in SVN to using GNU getopts now.
>
> I have tested only lightly (which has bitten me in the past with
> similar hacking on lessdisks) so please test more before releasing the
> code.
>
>
> Jeff: I noticed that you allow the -r option but seem to not actually
> do anything about it - contrary to what's documented in the manpage.
hmm that might well be my mistake.
i did the manpage.
> Also, I noticed some unquoted strings - would you mind me going over it
> and tighten up - or perhaps rather do it yourself?
no we wouldn't mind. :)
or if not please provide pointers.
--
maks