Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 31, 2008 at 08:01:43PM +0100, maximilian attems wrote: >On Wed, 31 Dec 2008, Jonas Smedegaard wrote: > >> 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. > >any initramfs generator has to add relevant firmware to the initramfs >out of the box without user intervention and load it on boot. yaird >doesn't do that. I obviously disagree, since I closed the bugreport. This is the wrong place to discuss details of each individual bug. Please elaborate at that specific bugreport. - 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) iEYEARECAAYFAklc33AACgkQn7DbMsAkQLhfuACgpRmHtMcpv5l7mRm6jE00w87D z/8AnjwpwX4c+9wblRPvjPbbQhyN19zw =kJih -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
-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 (d...@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. >
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
[final summary is at the end] * Jonas Smedegaard (d...@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? 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? 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?) 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 * cmdline - ignores any of the boot passed arguments even critical ones like root, rootfs or rootdelay * missing debian arch support - for example s390 * UUID, Label - apparently only works for some fs * missing firmware - several scsi drivers need firmware inside initramfs no loader on initramfs nor any mechanism to add it * missing cryptsetup support see #336599 * no dmraid support * no usplash support * 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 * dead upstream - 24 debian revsion is resolved now? For which issue do you need more information from maks but he refused to give them to you? 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. => 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. Cheers, Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
On Wed, 31 Dec 2008, Jonas Smedegaard wrote: > 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. any initramfs generator has to add relevant firmware to the initramfs out of the box without user intervention and load it on boot. yaird doesn't do that. it feel really 90ish to combine drivers *and* firmware. request_firmware() has been in linux-2.6 since long. modprobe gives the relevant firmware output since lenny version at least. > Max consistently clutter this metabug with FUD but refuse to discuss > details at each relevant bugreport. > > There are still outstanding issues, but I disagree that those are > release-critical (as I did a year ago). there has been no progress since yaird 0.0.13 otherwise you'd be happy to list it. happy vacations maks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 31, 2008 at 02:01:17PM +0100, Andreas Barth wrote: >* Jonas Smedegaard (d...@jones.dk) [081230 15:13]: >> On Tue, Dec 30, 2008 at 08:27:44AM +0100, maximilian attems wrote: >> >On Sun, 28 Dec 2008, Jonas Smedegaard wrote: >> > >> >> Do the release team still consider yaird too buggy for release >> >> with Lenny? >> > >> >there has been no progress nor any new release since last >> >evaluation. the worst failure is still the lack of firmware loading >> >in initramfs. >> >> Thanks for your opinion, Max. >> >> What is the opinion of the release team? > >Do you have any comments on the comments from Maximilian? 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. Max consistently clutter this metabug with FUD but refuse to discuss details at each relevant bugreport. There are still outstanding issues, but I disagree that those are release-critical (as I did a year ago). The issues originally contained in this metabug was cloned at bugs 457459-457468. - 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) iEYEARECAAYFAklbtPAACgkQn7DbMsAkQLi5fgCeJ2QeUjkAscIwT+bbeN7Rhme9 V7IAn2xp6ZsO4mJZ8P6qbvrI6YLfcURq =miwg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
* Sven Luther ([EMAIL PROTECTED]) [071223 10:13]: > On Sun, Dec 23, 2007 at 09:55:41AM +0100, Andreas Barth wrote: > > * Sven Luther ([EMAIL PROTECTED]) [071222 19:41]: > > > Andreas, face it, Max speaks as a strong supporter of initramfs-tools, > > > the concurent of yaird, and has shown real antagonism and agressivity > > > toward yaird since the begining of the initrd->initramfs migration. > > > > Please avoid dragging this discussion from technical issues into > > personal issues and speculations. This doesn't help, and this is the > > last mail of this kind which will get any answer from me. > > Why ? It was already at the non technical level. And as said, the > current sad remainders of the kernel team have proven they cannot > distinguish technical issues from personal ones. Nobody before started with throwing shit on other people and refering to old things that happened ages before and have no relevance to the current discussion. End of discussion to me. Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
* Sven Luther ([EMAIL PROTECTED]) [071222 19:41]: > Andreas, face it, Max speaks as a strong supporter of initramfs-tools, > the concurent of yaird, and has shown real antagonism and agressivity > toward yaird since the begining of the initrd->initramfs migration. Please avoid dragging this discussion from technical issues into personal issues and speculations. This doesn't help, and this is the last mail of this kind which will get any answer from me. I've discussed this with a long-term kernel team member, and he agrees that yaird is not keeping up for quite some time, and is a significant source of bug reports for the kernel team. It also is true that maks is opposing yaird, but that is for good technical resons which is fair and accepted behaviour. This all shouldn't prevent the yaird team to get back to speed, and keep up with the kernel. But as there doesn't seem any use case where we definitly need yaird, I think the kernel team can ask for this significant source of bug reports to be marked as seriously broken. It is the responsibility of the yaird team to fix that. And "fix that" really involves "getting to speed", which is more than just fixing individual bugs, but e.g. pre-activly fixing things not filled yet, or getting back an active upstream. Debian isn't the reservoir for outdated broken software. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457177: [Yaird-devel] Bug#457177: Bug#457177: keep yaird out of Testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Dec 22, 2007 at 01:59:31PM +0100, Andreas Barth wrote: >severity 457177 serious >thanks > >* Jonas Smedegaard ([EMAIL PROTECTED]) [071221 19:54]: >> On Fri, Dec 21, 2007 at 08:11:21PM +0100, maximilian attems wrote: >> >i hate myself inflated bugs, but if you had have a look at >> >the cited points you'd agree on the severity. >> >> We do not (in this bugreport) have a dispute over severity of those bugs >> that you listed. I did not even comment on them (as you seem well aware) >> but instead requested that you refer to the bugreports, as discussing >> severity of each bug is best done at those other bugreports. >> >> Our disagreement here is on severity of *this* bug, which I interpret as >> a metabug claiming that "this package generally have too many too severe >> bugs". Please correct me if I somehow misunderstood the nature of the >> bug raised with this bugreport. > > >Unfortunatly, I have to agree from a release team POV (i.e. speaking >with my Release Manager hat on) with maks on the general status of the >package, especially as maks spoke with his kernel arch maintainer hat >on (so his remarks shouldn't be lightly waived away). Waive away? this bugreport is about accumulation of bugs together raising severity of the package in generalm right? I requested to separate specifics, by referring to bugreports related to the issues raised (or, obviously, file bugreports if not reported already). There are several reasons for this request: * Original bugreporters of each issue, and participants in discussions surrounding each bug, are included in this renewed discussion - but only in the parts of the discussion relevant to them * It is easier (for me, at least) to keep track at the various parts of the discussion if not muddled together. >One might discuss about the adequate severity of the individual bugs, >but they together makes this package RC buggy. (Perhaps even some of the >individual bugs make it - we can discuss that at the individual bug >reports if wanted.) Yes, please do! >But there are some cases like "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" which are *not* fixed by adjusting to the current kernel, but >we expect some flexibility and robustness as long term strategy. I shall fork this as a separate bugreport, and comment on it there. >This isn't a final opinion on yaird, but please don't lower the severity >of this bug report until either this bug is fixed also in the opinion >of the bug reporter, or someone from the release team agrees to lowering >the severity. I shall respect your judgement representing the release team. - Jonas - -- Jonas Smedegaard <[EMAIL PROTECTED]> http://www.jones.dk/~jonas/ IT-guide dr. Jones<[EMAIL PROTECTED]> http://dr.jones.dk/+45 40843136 Debian GNU/Linux<[EMAIL PROTECTED]> http://www.debian.org/ GnuPG(1024D/C02440B8): 9A98 C6EB C098 9ED0 3085 ECA9 9FB0 DB32 C024 40B8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHbSicn7DbMsAkQLgRAnYeAKCkOBaJj6tdI4OHoUPhCYRl9rWg8QCcCan4 Wlw0pbMueKXN6wVAgtqO0F8= =jlO/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
