[Yaird-devel] Bug#457177: Bug#457177: Bug#457177: keep yaird out of Testing

Thu Jan 1 07:11:18 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Dec 31, 2008 at 11:14:48PM +0100, Andreas Barth wrote:
>[final summary is at the end]
>
>* Jonas Smedegaard (dr at jones.dk) [081231 19:00]:
>> There has been progress.
>> 
>> The issue he is specifically referring to above was cloned as 
>> bug#457463. It was closed with the upload of yaird 0.0.13-1 5 months 
>> ago.
>
>
>Looking at the package archive shows:
>     yaird |      yaird |   0.0.13-3 |      unstable | hppa, ia64, mips, mipsel, s390
>     yaird |      yaird |   0.0.13-5 |      unstable | source, alpha, amd64, arm, armel, i386, powerpc, sparc
>
>However, version 0.0.13-5 was uploaded on 29. Aug 2008. Why is this
>package not uptodate on 5 architectures? What did you do to resolve
>this problem?

Because those 5 architectures is currently unsupported so the package is 
no longer built for those architectures.

>Also, why are you discussing that now (as of end of December)? Was
>there any progress since the upload of the package in August which I
>missed?

Is it somehow inappropriate to ping the release team once a year?

What frequency is more suitable?

>Also, why should we accept this package into Lenny at this late stage
>of the release process? What advantages would our users get by another
>boot loader? (i.e. what can yaird do what other packages can't, and
>how does that help our users?)

Yaird is not a boot loader but a ramdisk generator, like 
initramfs-tools.

A general benefit of having an alternative ramdisk generator installed 
in addition to the default one is for backup use in the minor cases of 
the default one failing to generate a usable ramdisk.

A specific benefit of using yaird as default ramdisk generator and 
initramfs-tools only as backup is that yaird detect more problems at 
ramdisk build time rather than at runtime (i.e. linux-image postinstall 
fails rather than next boot).  This is especially useful for remotely 
managed computers.

Another benefit of yaird is its much smaller size. Initramfs-tools can 
also produce relatively small images but less supported and less 
reliably.

>Which of the initial issue (as of maks report):

>* overheating - none of the acpi modules lands on initramfs
>  for some boxes it is *really* critical to load them earliest

Fixed.

Please discuss details at bug#457459 rather than here.

>* cmdline - ignores any of the boot passed arguments
>  even critical ones like root, rootfs or rootdelay

Considered non-bug: yaird use static rootfs by design, so makes little 
sense support changing at runtime. Yaird handles waiting for devices 
much better than initramfs-tools (again related to using static devices 
by design ) so is believed to not need the cludgy rootdelay option.

Please discuss details at bug#457460 rather than here.

>* missing debian arch support - for example s390 

Yaird never claimed to support this, which has since been explicitly 
documented.

Please discuss details at bug#457461 rather than here.

>* UUID, Label - apparently only works for some fs

not fixed.

Please discuss details at bug#457462 rather than here.

>* missing firmware - several scsi drivers need firmware inside initramfs
>  no loader on initramfs nor any mechanism to add it

Yaird never claimed to support this, which has since been explicitly 
documented.

Please discuss details at bug#457463 rather than here.

>* missing cryptsetup support see #336599

Yaird never claimed to support this, which has since been explicitly 
documented.

Please discuss details at bug#457464 rather than here.

>* no dmraid support

Yaird never claimed to support this.

Please discuss details at bug#457465 rather than here.

>* no usplash support

Yaird never claimed to support this.

Please discuss details at bug#457466 rather than here.

>* brutal hardcoding - breaks ony every new linux image
>  either due to /proc, /sys or /boot/config hardcoded parsing
>  see #443821 for the latest 2.6.23 variation

bogus as a general claim.

fixed for specific issue.

>* dead upstream - 24 debian revsion

fixed.

>is resolved now?

Almost all if you ask me, almost none if you ask Max. It depends on how 
you count.

I do not claim that yaird is a replacement for initramfs-tools. It is 
fundamentally different. It does not make sense to judge yaird as a 
general-purpose ramdisk generator, which it isn't.

>For which issue do you need more information from maks but he refused 
>to give them to you?

None.

(I did not say that Max refuse to discuss at all)

>Looking at the following changelog entries:
>  * Document limited support for firmware loading and encrypted disks
>    (requires manual editing config files). Closes: bug#457463, #457464.
>  * Add patch 2001 to disable INPUT, as a temporary workaround for
>    recent kernels flagging more aggressively drivers offering buttons,
>    until yaird gets support for more hardware or learns to suppress
>    irrelevant button devices. Closes: bug#461997.  Add NEWS enry.
>  * Semi-auto-update debian/control to apply above cdbs-related changes:
>    DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes fakeroot debian/rules clean
>  * Add patch 1023 to only bail on encrypted root device with keyfiles
>    (ignore non-root encrypted devices with keyfiles). This closes:
>    bug#460818, thanks to Lubomir Host.
>  * Add patch 1024 to load all available thermal modules. Closes:
>    Bug#457459, thanks to maximilian attems.
>
>they don't sound to me like it really should be. Documenting not
>working stuff is of course better than nothing, but it is *not*
>resolving the issue. Especially closing serious bug reports like
>"missing firmware: no way to initiate some SCSI drivers" #457463 with
>"it's documented it doesn't work" is not acceptable.

yaboot also does not work on amd64 - because it is a tool designed for 
specific architectures.

Yaird also does not solve hunger in Africa, which is a serious issue.

You *will* get disappointed if you expect yaird to work the same as 
initrd-tools or initramfs-tools.

Yaird never promised to support loading firmware, so it cannot be a 
serious issue that it does not. Only if the package claimed to provide 
initramfs-tools could you rightfully argue that any and all features of 
that other ramdisk generator should be supported in yaird too.

>=> Summary: As things currently look to me, there are multiple reasons
>why yaird shouldn't be part of Lenny, and I'm surprised why you're
>trying to discuss that at the current moment, instead of fixing the
>open issues.

Should Abiword not be part of Lenny - as it does not match all features 
of OpenOffice.org?

Should Abiword not be in Lenny, because it has many outstanding (but 
non-critical) bugreports open?

Or why is it that the release team judge yaird as unfit for release?!?

If the reason is that the kernel team (through Max) consider the tool 
unfit as default tool for official Linux images, how is it then possible 
to ship such tool *without* it wrongly being considered for default 
official use?  Debian also ship boot loeaders not used by the installer 
team...

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklcbJYACgkQn7DbMsAkQLiCiACdFFdB95Q9yaWRPenFtXi4pHxy
71kAn0X/b/0vi64h4A5x9XoVJsaG3Ukg
=Ijno
-----END PGP SIGNATURE-----