[Pkg-uml-devel] Re: [Pkg-uml-commit] r81 - in trunk/src/rootstrap: . debian modules

[Mattia Dongili]

On Tue, May 23, 2006 9:10 am, Stefano Melchior said:
> On Mon, May 22, 2006 at 08:49:47PM +0200, Mattia Dongili wrote:
> Mattia,
[...]
>> > @@ -1,3 +1,15 @@
>> > +rootstrap (0.3.21-2) unstable; urgency=low
>>
>> If we're taking over roostrap completely (are we?) I'd release a new
>> shiny 0.3.22, agree?
> I would only add some changes, not to provide a fully working release,
> that is why I intentionally left 0.3.21-2 release

well, changes to upstream related code seem pretty relevant (at least as
bugfixes and improvement toward 2.6 support), it's not just a packaging
fix/improvement.

[...]
>> [1]: by the way are we really sure it works with old (2.4 series) UMLs?
>
> rootstrap requires 'linux', thus user-mode-linux in general, why do you
> need to prevent a release to be used, since the last working rootstrap is
> in oldstable (woody). The changes that we submitted are supported from
> woody to the upcoming etch.

but we are not going to upload a newer rootstrap neither in Woody nor in
Sarge, our target is Etch and I personally didn't test _any_ uml package
with _any_ 2.2 or 2.4 kernel (woody's and sarge's defaults), did you?

>> > +  * uml-utilities fix assures network to work with u-m-l 2.6 serie
>> (Closes: #304461)
>>
>> if this was really an uml-utilites bug it should be closed differently
>> (not by a roostrap upload at least).
>
> in this case, why did the bug summitted an uml-utilites bug on rootstrap?

don't know, bugs aren't always submitted to the right package :)
Anyway, I thought you intended that an uml-utilities fix made roostrap
working again, so wasn't this an uml-utilities bug?

[...]
>>
>> > +                       mknod $TARGET/dev/ubd$i b 98 $[$i * 16];
>>
>> and as said Sven, you're still testing for /dev/udb[01234567] and
>> creating $TARGET/dev/ubd[01234567]
>>
>> > +               fi
>> >	done
>> > fi
>>
>> no "else" here? What happens if /dev/ubd exists and is a directory?
>> The rest of the file also re-does:
>>
>> for i in 0 1 2 3 4 5 6 7; do mknod $TARGET/dev/ubd$i b 98 $[$i * 16];
>> done
>> ...
>> chroot $TARGET /bin/sh -c 'cd /dev && ./MAKEDEV ubd'
>>
>> Isn't it a bit redundant? :)
> I should have written
>
>  mknod /dev/ubd$i b 98 $[$i * 16];
>
> in case you haven't got ubd dev on host, required by rootstrap!
> if you have:
> /dev/ubd/[0-7] you have ysed devfs, so you don't need to create any host

but we don't want to use host's /dev as (among other problems) it's
read-only. See commit r82 for a fix.

> ubd dev; otherwise if you have not got any /dev/ubd[0-7] (on host), you
> need them (defs=nomount) to create filesystem.

DevFS has been dropped upstream (can't remember if it's for 2.6.17 or it
already has) and it has always been considered broken by design, so I
don't think we need to support it in any way.
And we're launching UML with devfs=nomount already.

> I was wondering if you make rootstrap work with a mirror different from
> cdrom/mounted *.iso.

using a mirror.

> Can you

Can I? :)
With current svn I can successfully create a sarge root_fs and boot it (if
I install udev+module-init-tools).

-- 
mattia
:wq!