On Mon, Feb 27, 2006 at 08:46:49PM +0000, Stephen Gran wrote: > This one time, at band camp, friendly Sven Luther said: > > On Mon, Feb 27, 2006 at 03:43:17PM +0100, Jonas Smedegaard wrote: > > > On Mon, 27 Feb 2006 15:14:02 +0100 Sven Luther > > > <[EMAIL PROTECTED]> wrote: > > > > > > > #343427: linux-image-2.6.14-2-powerpc: Installation fails > > > > #345067: [powerpc] ide-generic is not built on powerpc, yaird > > > > tries to include it and fails > > > > > > Both relate to ide-generic. > > > > > > Difference between yaird and initramfs-tools in regards to this > > > issue is that yaird has builtin probing while initramfs-tools rely > > > on udev for extracting kernels own logic and/or implement > > > workarounds. > > > > What has that to do with anything ? > > Since both bugs are arguably kernel bugs (some modules on some platforms > can't work without also loading ide-generic, but the kernel provides no > mechanism to find that out), I think it has rather a lot to do with the > issue at hand.
Well, sure, but the maintainership of MIA is crap, and the debian maintainer is unwilling to be reasonable and leaves "unable to install kernel bugs" with patches open for months. We cannot consider such a package of enough quality enough to even consider it for etch unless something changes with the maintainership. This was my point, not some random technical babling about the difference between yaird and initramfs-tools (and yes, i was a fervent supporter of yaird, and strongly advocated making it the default previously, so i am aware of the technical issues). > > The question was "should yaird not be made the default" and i answered > > that this is probably not a good idea because the DD maintainer (you) > > doesn't seem able to fix bugs without consulting his upstream and that > > said upstream is MIA. > > An MIA upstream is indeed a serious problem. A maintainer being > unwilling to accept a bad hack to work around brokenness elsewhere is > less of an issue, at least IMHO. Well, the problem was introduced in a bad hack without any kind of understanding about the issue in the first place, the proposed problem is just desactivating the hack on powerpc, where we know we don't build the ide-generic module, so i doubt anyone can prove me it is *NEEDED* in any way. In erkelenz i disucssed this with jonas, told him let's look at this and convince ourself that it is no problem, and was only told that he would not do som, because he was not able to be sure that it would not break on some random user setup, and without getting his upstream approval. I wrote upstream immediately, but we got no feedback, this was over a month ago, and yaird remains broken. And to make things clear, if loading ide-generic on powerpc would ever be *NEEDED*, then the case of not building ide-generic would not work, and it has been working just fine. So, the issue is double, first the upstream maintainer is MIA, which is not nice, but second the debian maintainer is unable or unwilling to take his maitainer job seriously and at least consider looking at the patches that are submitted by the folk who have the hardware. This jonas clearly said (and so loudly that folk in Erkelenz asked us to leave the room) that he would not look at my patch without aproval from upstream, that he didn't really understand yaird enough to be sure that nothing else would break if he did that change (which just reverted a previously applied hacky patch that broke this), and was thus not even considering looking it over with me. In these conditions, it is unacceptable to make yaird the default (or probably even ship it with etch), if we don't get a change in maintainership, either jonas becoming more responsible, or someone co-maintaining it or taking it over, preferably someone with a clue and knowledgeable in perl. Friendly, Sven Luther > > Ever so friendly, > -- > ----------------------------------------------------------------- > | ,''`. Stephen Gran | > | : :' : [EMAIL PROTECTED] | > | `. `' Debian user, admin, and developer | > | `- http://www.debian.org | > ----------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
