On Sun, 2004-08-29 at 22:01 +0200, Goswin von Brederlow wrote: > I just noticed Scott James added a Cc to debian-devel so for those not > familiar with the bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241689) > some facts: > > 1. The bug is a FTBFS bug on amd64 > 2. The build fails because the file "essential-packages-list-amd64" is > missing (contens doesn't matter, also see compromise below) > 3. Other Debian ports already have their files (placeholders except > for hurd-i386): > > hurd-i386 darwin-powerpc freebsd-i386 openbsd-i386 darwin-i386 > netbsd-i386 s390x sh3eb sh4eb sh3 sh4 > 4. The bug is 149 days old > 5. Adding a placeholder file (also see compromise below) is all that > is needed to fix it but a correct and complete list is in the > bugreport too (as statement that it is identical to i386) > And once you agreed that this compromise was acceptable, a version got uploaded with this placeholder file (along with ones for a couple of other new ports we've picked up along the way). I hate to derail your tantrum, but you've already got want you wanted and would've got it significantly sooner had you stopped being so generally childish about things. > As per > http://www.nl.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-nmu > |5.11 Non-Maintainer Uploads (NMUs) > |... > |Another reason why NMUs are done is when a Debian developer needs to > |fix another developer's packages in order to address serious security > |problems or crippling bugs, especially during the freeze, or when the > |package maintainer is unable to release a fix in a timely fashion. > > I felt an NMU would be justified. The bug is cripling to the amd64 > port since everyone wanting to build a package relies on the > build-essential package and the bug wasn't fixed in a timely fashion. > No they don't: This package is NOT the definition of what packages are build-essential; the real definition is in the Debian Policy Manual. This package contains merely an informational list, which is all most people need. However, if this package and the manual disagree, the manual is correct. The build-essential package is informational only, it is not a required part of any build chain; the packages it details are and you can quite easily manually install those yourself. It is useful, of course, and you've had the instructions for adding the essential-packages-list-amd64 file for your amd64 archive for some time. All the derivatives have managed, I'm not quite sure why you can't. > Also note: > |18.104.22.168 When to do a source NMU if you are a porter > |... > |However, if you are a porter doing an NMU for `unstable', the above > |guidelines for porting should be followed, with two > |variations. Firstly, the acceptable waiting period -- the time > |between when the bug is submitted to the BTS and when it is OK to do > |an NMU - is seven days for porters working on the unstable > |distribution. This period can be shortened if the problem is critical > |and imposes hardship on the porting effort, at the discretion of the > |porter group. (Remember, none of this is Policy, just mutually agreed > |upon guidelines.) > > 149 days is certainly bigger than 7 days. > You are not a porter working on the unstable distribution; amd64 is not in the unstable distribution. This is the entire *point* here; the essential-packages-list files in build-essential reflect the current state of Debian unstable, so until amd64 is added to that distribution it won't have anything other than a placeholder file there. Had you bothered to spend more than two seconds looking at the package, you would've realised I've happily added these placeholder files in the past for all the various non-Linux ports; had your mail been a polite request to do the same or even asking whether you could be sponsored to do an upload of the same; I would've happily done so. > Sorry to step on your toes Scott by informing you of my plans to NMU > but build-essential is one of two packages still waiting for an amd64 > patch to be added and the other one has a general RC bug and is being > worked on. Please remember that NMUs are not an hostile act. > The NMU would've been invalid and would've had to been reverted. NMUs aren't hostile acts, as I've already stated in this discussion, I freely welcome them provided they fix valid bugs and fix them properly. You've misunderstood the purpose of the package and these files, and would've broken the policy outlined for them. > > If you're happy for the file to say that, then that's ok; I agree to > > this compromise. > > I never demanded any specific contents for the file. The bug was and > is only that the file is non-existant. > Bullshit. You indicated your intent (out of the blue) to NMU a package to fix a bug that's clearly about copying the content of the i386 file. > > That wasn't so hard now, was it? > > No it wasn't, was it? > > May I expect an upload with a placeholder file soon or do you want me > to continue preparing an NMU and getting it uploaded? > It's already uploaded and accepted. Had you simply requested this in the first place, I would've happily done so without any discussion. It doesn't close this bug because this bug is specifically asking for a complete content of this file, so will get closed when amd64 is added to the archive and build-essential updated to include its essential packages list. > > You'd find people a lot more willing to work with you if you offered > > more help and agreed to more compromises than you threaten with NMUs. > > > >> > Once amd64 has been added to sid, build-essential in sid will be updated > >> > to carry an essential-packages-list-amd64 file. > >> > >> Yeah, and amd64 can't be added to sid till it has build-essential and > >> it can't have build-essential till it is in sid and it can't be in sid > >> till it has build-essential..... > >> > > Who said that? Let me know and I'll go and apply appropriate percussive > > force to them. build-essential is *not* a policy package, it simply > > documents the current state of the archive. > > It is used to setup a buildd chroot for a buildd and having a buildd > was said to be required for sid inclusion. Through that a > build-essential package is required for sid inclusion. It is also > important to users and developers to be able to "apt-get install > build-essential" so uploads, backports and especially security fixes > can be made. > No, you need to install the packages outlined in the build-essential list, the build-essential package itself is informational. The fact it is useful from a dependency POV is simply convenient. You need "build essential packages" to set up a buildd, not "the build- essential package". Goswin, I find you childish, argumentative and unwilling to accept the possibility that *sometimes* you might actually not be right. Dealing with bug reports from you is like hitting my head against a brick wall, and I am unwilling to do it any further. If you wish to file bugs on any of my packages in future, or wish to contact me for whatever reason, I ask that you do it through a third party sponsor who is in the Debian keyring. I also ask that they take the time to listen to your requests and present them to me themselves, rather than simply copy-and-pasting yours. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Description: This is a digitally signed message part