Re: glibc and UNACCEPTs
Anthony Towns wrote: Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead of experimental [...] Would anyone like to contribute their thoughts, so we can do an air crash style failure analysis to work out how we can avoid this class of problem in future, given the safety net that caught us this time is going away? Is there any sensible reason for ever uploading a package in unstable with a higher version than in experimental? If not, such uploads can simply be forbidden altogether. Gerardo
Re: glibc and UNACCEPTs
On Wed, Sep 06, 2006 at 10:34:31AM +0200, BALLABIO GERARDO wrote: Is there any sensible reason for ever uploading a package in unstable with a higher version than in experimental? If not, such uploads can simply be forbidden altogether. The documented and preferred way to remove packages from experimental is to upload a package to unstable that supersedes it... -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: glibc and UNACCEPTs
From: Wouter Verhelst,,, [mailto:[EMAIL PROTECTED] Is there any sensible reason for ever uploading a package in unstable with a higher version than in experimental? If not, such uploads can simply be forbidden altogether. The documented and preferred way to remove packages from experimental is to upload a package to unstable that supersedes it... Umm. I guess that automatically sending a request for confirmation would be a better course of action then ;-) People remove packages from experimental only once in a while, thus always asking for confirmation shouldn't be too much of a hassle, and actually may be desirable. At least for those like me who redefine rm as rm -i in their .bashrc. Gerardo
Re: glibc and UNACCEPTs
Hello, BALLABIO GERARDO schrieb: People remove packages from experimental only once in a while, thus always asking for confirmation shouldn't be too much of a hassle, and actually may be desirable. At least for those like me who redefine rm as rm -i in their .bashrc. Maybe it would help to ask for the .changes file to contain all the changelog entries for uploads that went to experimental plus the most recent one? The big difficulty here is that you'd effectively have to unpack the source and look into debian/changelog whether there have been uploads to experimental from that branch of packaging. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Gustavo Noronha Silva [EMAIL PROTECTED] writes: That would be good to be add in cdbs. I think we might want to have it more flexible to allow it to work for CDDs too but I liked it very much :-D It does not look right to me, though.. what about buildds? And what about people forgetting an exported variable saying yes? I much rather the manual solution, or a solution for dak that detects that the target distribution changed and requests a confirmation by signed email, for instance. I dunno if it's right to do that on DAK itself. I think that it can be done by the development scripts. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Hello! On Tue, 22 Aug 2006 20:51:56 +0200, David Nusinow wrote: On Tue, Aug 22, 2006 at 03:30:07PM -0400, Joey Hess wrote: Drew Parsons wrote: Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. '2:' is not any worse than '1:', so I don't see why this is any worse than any other bug that upload could have introduced. Upload again with a new epoch, problem solved. This is what I'd consider the appropriate fix. Just do another upload straight away and you don't even need to bother an ftpmaster. It's what I would have done if I'd been awake. Well, the problem is that with my daily `apt-get update apt-get upgrade` I got (again) the xserver-xorg from unstable, ending up with some X.Org packages from unstable and some from experimental, which AFAIK isn't a good thing :-( = [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg xserver-xorg: Installed: 1:7.0.23 Candidate: 1:7.0.23 Version table: *** 1:7.0.23 0 990 http://ftp.ch.debian.org unstable/main Packages 100 /var/lib/dpkg/status 1:7.0.22 0 500 http://ftp.ch.debian.org testing/main Packages [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-core xserver-xorg-core: Installed: 2:1.0.2-10 Candidate: 2:1.0.2-10 Version table: *** 2:1.0.2-10 0 990 http://ftp.ch.debian.org unstable/main Packages 100 /var/lib/dpkg/status 1:1.1.1-2 0 1 http://ftp.ch.debian.org experimental/main Packages 1:1.0.2-9 0 500 http://ftp.ch.debian.org testing/main Packages [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-input-mouse xserver-xorg-input-mouse: Installed: 1:1.1.1-2 Candidate: 1:1.1.1-2 Version table: *** 1:1.1.1-2 0 1 http://ftp.ch.debian.org experimental/main Packages 100 /var/lib/dpkg/status 1:1.0.4-3 0 500 http://ftp.ch.debian.org testing/main Packages 990 http://ftp.ch.debian.org unstable/main Packages [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-video-v4l xserver-xorg-video-v4l: Installed: 0.1.1-1 Candidate: 0.1.1-1 Version table: *** 0.1.1-1 0 1 http://ftp.ch.debian.org experimental/main Packages 100 /var/lib/dpkg/status 0.0.1.5-1 0 500 http://ftp.ch.debian.org testing/main Packages 990 http://ftp.ch.debian.org unstable/main Packages [EMAIL PROTECTED]:~$ = I don't think it's my fault (not having preserved xserver-xorg-core From an upgrade), but in case of just disregard this post. If it's not my fault, however, I think we need a new package in experimental... Thx, bye, Gismo / Luca pgpsSVCYsxZT2.pgp Description: PGP signature
Re: glibc and UNACCEPTs
On Thu, 2006-08-24 at 16:51 +0200, Luca Capello wrote: If it's not my fault, however, I think we need a new package in experimental... Already uploaded. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Re: glibc and UNACCEPTs
Em Tue, 22 Aug 2006 23:47:09 -0300 Otavio Salvador [EMAIL PROTECTED] escreveu: Drew Parsons [EMAIL PROTECTED] writes: e.g. build: test_stable patch build-stamp instead of build: patch build-stamp That would be good to be add in cdbs. I think we might want to have it more flexible to allow it to work for CDDs too but I liked it very much :-D It does not look right to me, though.. what about buildds? And what about people forgetting an exported variable saying yes? I much rather the manual solution, or a solution for dak that detects that the target distribution changed and requests a confirmation by signed email, for instance. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] http://people.debian.org/~kov/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
The Dear Project Leader wrote: Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead of experimental, and on the request of the release managers, I UNACCEPTed it, given it was a major accidental change to a rather core library just as that library should've been frozen. ... The 2.3.999.2-10 upload (with signatures removed) is available on ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their thoughts, so we can do an air crash style failure analysis to work out how we can avoid this class of problem in future, given the safety net that caught us this time is going away? Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. I can think of only a handful of reasonable changes we could make to reduce these occurances: 1) [technical] Alter dput/dupload to explicitly ask whether to proceed if the distro from the preceding changelog entry changes (e.g. experimental-unstable) 2) [technical] Remove the single point of failure by adding a Distribution: field to debian/control, say. The package will be rejected if the two fields in control and changelog do not match. 3) [policy] Manual processing by ftp-masters when changing distro. Their decision is automatic rejection by default unless there is a changelog entry explicitly stating the distro change is occurs. This need only apply for uploads to unstable (or stable), not for uploads to experimental. 4) [human engineering] For team-supported packages, require that another member of your team verify the package (with special attention to the distro field in debian/changelog) before uploading. It would be nice to see 1) done. A Previous-Distribution: field in .changes filled in during a dpkg-buildpackage run might help to facilitate it. dpkg-buildpackage could check and reject for 2) at build time. Perhaps 2) could be combined with 1) (dput/dupload make two separate checks) Unless 2) is practical to implement, then 3) is a very good idea, in my opinion, since it removes the single point of failure. No longer will there be just one single field to be miswritten. Manpower-wise, however, I don't know if it would make too much burden on the ftp-masters. Really 4) should be done in any case, but I can understand it could get annoying at times. Thanks for listening, Drew p.s. the old xserver-xorg 1:1.0.2-9 packages can still be found in testing, or you can grab the new video drivers from experimental. The full working set of X11R7.1 packages will all be in unstable soon (in the next week or so), pending adjustments in versioned depends of the video drivers. signature.asc Description: This is a digitally signed message part
Re: glibc and UNACCEPTs
* Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]: 2) [technical] Remove the single point of failure by adding a Distribution: field to debian/control, say. The package will be rejected if the two fields in control and changelog do not match. or just make dpkg-buildpackage fail if that happens (or rather dpkg-genchanges), which isn't too hard to achive actually. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
* Drew Parsons wrote: 3) [policy] Manual processing by ftp-masters when changing distro. The distribution wasn't changed. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
We have stated: 3) [policy] Manual processing by ftp-masters when changing distro. Their decision is automatic rejection by default unless there is a changelog entry explicitly stating the distro change is occurs. This need only apply for uploads to unstable (or stable), not for uploads to experimental. ... Unless 2) is practical to implement, then 3) is a very good idea, in my opinion, since it removes the single point of failure. No longer will there be just one single field to be miswritten. Manpower-wise, however, I don't know if it would make too much burden on the ftp-masters. Another thought on the QUEUE processing line, if asking ftp-masters to perform these manual checks is too burdensome, then an alternative is 3.b) Delay any such transitioning packages, to provide time for the maintainer (or the team) to realise the mistake and fill out a .commands file cancelling the upload. What would be a reasonable time frame, 4 hours? 12 ? 24 ? Drew p.s. Andreas, I'm glad you like Option 2). Yes, I mentioned dpkg-buildpackage in the comments underneath :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Tue, Aug 22, 2006 at 11:12:44AM +0200, Norbert Tretkowski wrote: * Drew Parsons wrote: 3) [policy] Manual processing by ftp-masters when changing distro. The distribution wasn't changed. The version of the uploaded xorg-server package was higher than the version in experimental, and it was targetted at unstable. Addtionally, the prior Debian revision was in the experimental distribution. So I believe this counts as changing distro, unless you mean some sublte semantics I missed. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: glibc and UNACCEPTs
Norbert wrote: * Drew Parsons wrote: 3) [policy] Manual processing by ftp-masters when changing distro. The distribution wasn't changed. It was in the case of the xserver-xorg upload. 1:1.1.1-2 had been sent to experimental, 1:1.1.1-3 was sent to unstable. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Drew Parsons a écrit : The Dear Project Leader wrote: Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead of experimental, and on the request of the release managers, I UNACCEPTed it, given it was a major accidental change to a rather core library just as that library should've been frozen. ... The 2.3.999.2-10 upload (with signatures removed) is available on ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their thoughts, so we can do an air crash style failure analysis to work out how we can avoid this class of problem in future, given the safety net that caught us this time is going away? Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. I can think of only a handful of reasonable changes we could make to reduce these occurances: 1) [technical] Alter dput/dupload to explicitly ask whether to proceed if the distro from the preceding changelog entry changes (e.g. experimental-unstable) 2) [technical] Remove the single point of failure by adding a Distribution: field to debian/control, say. The package will be rejected if the two fields in control and changelog do not match. 3) [policy] Manual processing by ftp-masters when changing distro. Their decision is automatic rejection by default unless there is a changelog entry explicitly stating the distro change is occurs. This need only apply for uploads to unstable (or stable), not for uploads to experimental. 4) [human engineering] For team-supported packages, require that another member of your team verify the package (with special attention to the distro field in debian/changelog) before uploading. It would be nice to see 1) done. A Previous-Distribution: field in .changes filled in during a dpkg-buildpackage run might help to facilitate it. dpkg-buildpackage could check and reject for 2) at build time. Perhaps 2) could be combined with 1) (dput/dupload make two separate checks) Denis Barbier has added that to the clean rule of the experimental glibc: # Do not accidentally upload into unstable dpkg-parsechangelog | grep ^Distribution: | grep -q -v unstable Works nicely. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Tue, Aug 22, 2006 at 11:08:49AM +0200, Andreas Barth wrote: * Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]: 2) [technical] Remove the single point of failure by adding a Distribution: field to debian/control, say. The package will be rejected if the two fields in control and changelog do not match. or just make dpkg-buildpackage fail if that happens (or rather dpkg-genchanges), which isn't too hard to achive actually. Yes, I added the following lines in debian/rules # Do not accidentally upload into unstable dpkg-parsechangelog | grep ^Distribution: | grep -q -v unstable for that purpose in the glibc experimental branch. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Drew Parsons wrote: Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. '2:' is not any worse than '1:', so I don't see why this is any worse than any other bug that upload could have introduced. Upload again with a new epoch, problem solved. -- see shy jo signature.asc Description: Digital signature
Re: glibc and UNACCEPTs
On Tue, Aug 22, 2006 at 03:30:07PM -0400, Joey Hess wrote: Drew Parsons wrote: Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. '2:' is not any worse than '1:', so I don't see why this is any worse than any other bug that upload could have introduced. Upload again with a new epoch, problem solved. This is what I'd consider the appropriate fix. Just do another upload straight away and you don't even need to bother an ftpmaster. It's what I would have done if I'd been awake. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Tue, Aug 22, 2006 at 06:42:46PM +1000, Drew Parsons wrote: The Dear Project Leader wrote: Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead of experimental, and on the request of the release managers, I UNACCEPTed it, given it was a major accidental change to a rather core library just as that library should've been frozen. ... The 2.3.999.2-10 upload (with signatures removed) is available on ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their thoughts, so we can do an air crash style failure analysis to work out how we can avoid this class of problem in future, given the safety net that caught us this time is going away? Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. Crap. Sorry everyone. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Denis Barbier wrote: On Tue, Aug 22, 2006 at 11:08:49AM +0200, Andreas Barth wrote: * Drew Parsons ([EMAIL PROTECTED]) [060822 11:04]: 2) [technical] Remove the single point of failure by adding a Distribution: field to debian/control, say. The package will be rejected if the two fields in control and changelog do not match. or just make dpkg-buildpackage fail if that happens (or rather dpkg-genchanges), which isn't too hard to achive actually. Yes, I added the following lines in debian/rules # Do not accidentally upload into unstable dpkg-parsechangelog | grep ^Distribution: | grep -q -v unstable for that purpose in the glibc experimental branch. Your version requires this line to be deleted for unstable and then added again for any future experimental work. I prepared an alternative snippet by which the test can remain, and switched off by an explicit extra variable saying simply yes. This is an extra make rule to go in debian/rules (or xsfmb.mk, for the XSF): # Before building, check we're not making an accidental upload to unstable .PHONY: test_stable test_stable: @if [ x$(UPLOAD_TO_UNSTABLE) != xyes ] \ [ -n `dpkg-parsechangelog | grep ^Distribution: | grep -q -v unstable` ]; \ then \ echo POSSIBLE MISLOAD TO UNSTABLE!; \ echo You have set the distribution to 'unstable' in debian/changelog; \ echo but have not set UPLOAD_TO_UNSTABLE=yes in debian/rules; \ echo Please fix this before proceeding.; \ exit 1; \ fi It would be applied when building: e.g. build: test_stable patch build-stamp instead of build: patch build-stamp Unstable uploads would then be permitted by placing UPLOAD_TO_UNSTABLE=yes in debian/rules. It would, of course require the 'yes' to be replaced by 'no' and vice versa, as you go between unstable and experimental. Since we don't always have ongoing versions developed in experimental, it may not be worth the bother. But there it is if anyone wants it. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Drew Parsons [EMAIL PROTECTED] writes: e.g. build: test_stable patch build-stamp instead of build: patch build-stamp That would be good to be add in cdbs. I think we might want to have it more flexible to allow it to work for CDDs too but I liked it very much :-D -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Hi, On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote: The 2.3.999.2-10 upload (with signatures removed) is available on ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their thoughts, so we can do an air crash style failure analysis to work out how we can avoid this class of problem in future, given the safety net that caught us this time is going away? One possibility would be to have packages which obviously transition from experimental to unstable (old version in experimental higher than old version in unstable, new version in unstable higher than old version in experimental) to be put into NEW for manual processing. That would mean more work for the ftp-masters/ftp-assistants though, so not sure. One thing we can do to prevent things like that is to make sure none of our tools overwrite the Distribution: in .changes; the sbuild package in unstable used to do that a while back I think, pbuilder is hopefully fine. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote: The reason I'm pointing this out at length is to emphasise that as we improve the archive software this will become not just awkward to do, but *impossible*. Is it really an improvement then? :-) I don't know the internals of dak at all, but honestly; this safety net just proved itself very useful... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On 10741 March 1977, Michael Banck wrote: That would mean more work for the ftp-masters/ftp-assistants though, so not sure. Doesnt sound like much work from that, so should be ok. -- bye Joerg mrvn Anyone with a cdrw/dvdrw drive up for some crazy experiments? Ever noticed how the color changes when you burn something on a CD/DVD? Are there ways to control it? I want ISOPAINT: Paint pictures into an iso image visible after its burned to cd/dvd. doogie interesting idea doogie how long have you been off your medication? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Wed, 2006-08-09 at 12:46 +0200, Michael Banck wrote: Hi, On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote: The 2.3.999.2-10 upload (with signatures removed) is available on ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their thoughts, so we can do an air crash style failure analysis to work out how we can avoid this class of problem in future, given the safety net that caught us this time is going away? One possibility would be to have packages which obviously transition from experimental to unstable (old version in experimental higher than old version in unstable, new version in unstable higher than old version in experimental) to be put into NEW for manual processing. You could use the same criteria to automatically quarantine the upload and email the maintainer saying Upload transitions between distributions. Do $FOO if you really meant it. $FOO could be reply to this email or upload .command file to take the upload out of quarantine etc. There is no ftp-master/-assistant involvement this way. Ian. -- Ian Campbell Current Noise: Obituary - Insane Keep this and all chemicals out of the reach of children. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Wed, Aug 09, 2006 at 12:50:38PM +0200, Steinar H. Gunderson wrote: On Wed, Aug 09, 2006 at 08:14:56PM +1000, Anthony Towns wrote: The reason I'm pointing this out at length is to emphasise that as we improve the archive software this will become not just awkward to do, but *impossible*. Is it really an improvement then? :-) I don't know the internals of dak at all, but honestly; this safety net just proved itself very useful... It worked because I was awake at 4:20am localtime, on IRC to notice, and willing to do something about it... While that's more common than is probably good, it's not something I like to see the release depend on... Due to the craptacular nature of the process of doing UNACCEPTs (and the way it hurts buildds, confuses dak's internal structures, potentially confuses the BTS -- bugs closed on upload don't get reopened, etc), it's pretty rare that anyone is willing to do it too. The other side of the tradeoff is: - losing the accepted queue entirely -- packages that are accepted go straight into the pool, removing one area for bugs to occur entirely - removing the need to do in-queue autobuilding -- again removing code that has had bugs, but also removing the need to run apt-ftparchive twice for every package uploaded, thus reducing the load on ftp-master - allowing us to run the pulse more often than daily so that packages can be developed and deployed more rapidly, getting bugs found and fixed faster. this is particularly relevant for d-i, and has been for years now. So yeah, it's an improvement. Cheers, aj signature.asc Description: Digital signature
Re: glibc and UNACCEPTs
Hello, Anthony Towns wrote: It worked because I was awake at 4:20am localtime, on IRC to notice, and willing to do something about it... While that's more common than is probably good, it's not something I like to see the release depend on... Well, if you hadn't been awake, the maintainers would have had to upload a package with an ugly version number (or even an epoch), which would not be the end of the world. Due to the craptacular nature of the process of doing UNACCEPTs (and the way it hurts buildds, confuses dak's internal structures, potentially confuses the BTS -- bugs closed on upload don't get reopened, etc), it's pretty rare that anyone is willing to do it too. If this is becoming ftpmaster policy, please document the reasons for it. I can agree that certain things should not be done because of limitations in scripts; however policy has a tendency to be interpreted the other way 'round in retrospect, so that the policy of not doing UNACCEPTs was there first, and that it is therefore not desirable to implement the feature in the scripts because, well, such a feature would be against the policy anyway. - losing the accepted queue entirely -- packages that are accepted go straight into the pool, removing one area for bugs to occur entirely Well, I can see the need for queue support in the archive software nevertheless, specifically for security, so I'm not sure you can reduce the complexity of the system by allowing queue-less archives. It will add more complexity to mirror handling at least. - allowing us to run the pulse more often than daily so that packages can be developed and deployed more rapidly, getting bugs found and fixed faster. this is particularly relevant for d-i, and has been for years now. I'm not sure it scales that well if you apply it to the entire archive, due to the overhead of the mirror pulse. It might make sense to have mini-pulses for parts of the archive, such as d-i. Simon signature.asc Description: OpenPGP digital signature
Re: glibc and UNACCEPTs
On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote: Well, if you hadn't been awake, the maintainers would have had to upload a package with an ugly version number (or even an epoch), which would not be the end of the world. Not everyone agrees with that :) Due to the craptacular nature of the process of doing UNACCEPTs (and the way it hurts buildds, confuses dak's internal structures, potentially confuses the BTS -- bugs closed on upload don't get reopened, etc), it's pretty rare that anyone is willing to do it too. If this is becoming ftpmaster policy, please document the reasons for it. I'm sorry, I'm not going to debate the merits of UNACCEPTing. Since the accepted queues have been in place, it's happened about four times -- less than once a year. We've regretted every single one of those, at least in part. The paragraph you quoted documents the reasons, in any case. I can agree that certain things should not be done because of limitations in scripts; The scripts do not handle UNACCEPTs, they're purely manual work, that's easy to do wrong, and routinely leaves things broken even when no mistakes are made. - losing the accepted queue entirely -- packages that are accepted go straight into the pool, removing one area for bugs to occur entirely Well, I can see the need for queue support in the archive software [...] Yes, we have a range of queues -- unchecked, holding, new, byhand, p-u-new, embargoed, unembargoed, unchecked-disembargo, proposed-updates, done and reject. accepted is just one of them, though, thanks to the UNACCEPT issue, it's one that does collect problematic bugs. - allowing us to run the pulse more often than daily so that packages can be developed and deployed more rapidly, getting bugs found and fixed faster. this is particularly relevant for d-i, and has been for years now. I'm not sure it scales that well if you apply it to the entire archive, due to the overhead of the mirror pulse. It might make sense to have mini-pulses for parts of the archive, such as d-i. There are difficulties, certainly, but nothing that can't be handled. None of this really helps avoid the problem though... Cheers, aj signature.asc Description: Digital signature
Re: glibc and UNACCEPTs
On Thu, 2006-08-10 at 01:15 +1000, Anthony Towns wrote: On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote: Well, if you hadn't been awake, the maintainers would have had to upload a package with an ugly version number (or even an epoch), which would not be the end of the world. Not everyone agrees with that :) Could you specify why a reupload with a higher version number would be the end of the world, or at least, a more serious problem than the one it would try to solve? Another upload is a way to fix bugs in your package which works very well, and I don't see why it wouldn't work in this case? Thijs signature.asc Description: This is a digitally signed message part
Re: glibc and UNACCEPTs
Anthony Towns aj@azure.humbug.org.au writes: Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead of experimental, and on the request of the release managers, I UNACCEPTed it, given it was a major accidental change to a rather core library just as that library should've been frozen. I'm confused by this; it sounds as if what you're saying is that if an important package is about to be frozen, no uploads for it should happen. Doesn't that just mean that it already *is* frozen? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Wed, Aug 09, 2006 at 09:43:06AM -0700, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead of experimental, and on the request of the release managers, I UNACCEPTed it, given it was a major accidental change to a rather core library just as that library should've been frozen. I'm confused by this; it sounds as if what you're saying is that if an important package is about to be frozen, no uploads for it should happen. Doesn't that just mean that it already *is* frozen? No, there have been incremental updates to glibc_2.3.6-* over the past weeks fine-tuning things in preperation for the freeze. In contrast, glibc_2.3.999.2-* is a whole new upstream version, dropping support for 2.4 kernels. We definetely do not want to have this in etch, and having to deal with glibc issues entirely through testing-proposed-updates during the freeze would very annoying. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Anthony Towns wrote: On Wed, Aug 09, 2006 at 04:59:13PM +0200, Simon Richter wrote: Well, if you hadn't been awake, the maintainers would have had to upload a package with an ugly version number (or even an epoch), which would not be the end of the world. Not everyone agrees with that :) If UNACCEPT has only been used once per year then that's one added epoch per year from now on. While glibc is not a package I'd really like to see an epoch on, the fact is that there are nearly 2000 binary packages in the archive with an epoch, so any more added due to the loss of UNACCEPT is a drop in the bucket. I'm sorry, I'm not going to debate the merits of UNACCEPTing. Since the accepted queues have been in place, it's happened about four times -- less than once a year. We've regretted every single one of those, at least in part. Are you counting the time we almost removed all of d-i from the archive by accident and put it back before dinstall as an UNACCEPT? :-) (In Porto Alegre.) -- see shy jo signature.asc Description: Digital signature
Re: glibc and UNACCEPTs
Simon Richter wrote: I'm not sure it scales that well if you apply it to the entire archive, due to the overhead of the mirror pulse. It might make sense to have mini-pulses for parts of the archive, such as d-i. That doesn't work very well unless it can be very targeted; the parts of the archive that most often need to be updated to avoid blocking d-i development for a day or two are packages in base (like glibc..) and not d-i itself. -- see shy jo signature.asc Description: Digital signature
Re: glibc and UNACCEPTs
Anthony Towns writes (glibc and UNACCEPTs): ... how we can avoid this class of problem in future, given the safety net that caught us this time is going away? Ideally, there would be some automatic checks that could spot `probably erroneous' uploads, and which you would mention in your .changes file if you were violating them. Elsewhere in this thread it has been pointed out that that upload would have pushed unstable across experimental's version number, which is probably a reasonable thing to require confirmation of intent for. Other possibilities for `yellow flags' include: * any upload shortly before the relevant freeze * `unexpected version number jumps; something in the package could specify what an `expected' jump was for each distribution something like: Normally-No-Change: unstable ?=.?=.?+1* and then uploading 2.3.999 would require an explict request since 999 is more than 1 greater than 6 (from 2.3.6-19, the old version in the archive). Each maintainer could set the `safety catch' appropriately eg by setting Normally-No-Change: unstable ?=.?=.?= when you settle on the upstream version for etch. * package is on `extra care' list maintained by ftpmasters and perhaps people can think of more. To make this work reasonably, you'd have to be able to resign the .changes with additional acknowledgements of the yellow flags (`yes, I really mean this) and reupload it, with the same version numbers of the underlying files. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
