Bug#665969: nmu: apt_0.9.0
On Mon, Apr 16, 2012 at 09:47:21PM +0100, Adam D. Barratt wrote: On Mon, 2012-04-16 at 21:40 +0100, Adam D. Barratt wrote: On Mon, 2012-04-16 at 21:44 +0200, Michael Vogt wrote: Ok, thanks! Please let me know if there is anything I can do to help at this point. It looks like the binNMUs aren't going quite as smoothly as hoped. Sorry for that :/ Problems reported so far include: E: Method http has died unexpectedly! E: Sub-process http received signal 10. This is #669061 This appears to be Sparc only, right? We do had trouble with alignments in the hashsum calculations in the past, maybe that is re-occuring with the addition of sha512. and E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for adduser:amd64, aborting and this #669060 David fixed this one already (thanks David!), I uploaded 0.9.1 now with the fix included. Cheers, Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120417075909.GX3104@localhost
Bug#665969: nmu: apt_0.9.0
On 17.04.2012 08:59, Michael Vogt wrote: On Mon, Apr 16, 2012 at 09:47:21PM +0100, Adam D. Barratt wrote: On Mon, 2012-04-16 at 21:40 +0100, Adam D. Barratt wrote: E: Method http has died unexpectedly! E: Sub-process http received signal 10. This is #669061 This appears to be Sparc only, right? We do had trouble with alignments in the hashsum calculations in the past, maybe that is re-occuring with the addition of sha512. I think so, yes. I've asked for confirmation on IRC. and E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for adduser:amd64, aborting and this #669060 David fixed this one already (thanks David!), I uploaded 0.9.1 now with the fix included. Thanks for the quick turnaround. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cb14d205c23bf1f3025ff4217e0f2...@mail.adsl.funky-badger.org
Bug#665969: nmu: apt_0.9.0
On Tue, Apr 17, 2012 at 09:59:09AM +0200, Michael Vogt wrote: Problems reported so far include: E: Method http has died unexpectedly! E: Sub-process http received signal 10. This is #669061 This appears to be Sparc only, right? We do had trouble with alignments in the hashsum calculations in the past, maybe that is re-occuring with the addition of sha512. I've only seen it on sparc, but I didn't try this on many arches. I've been trying to reproduce this, and it seems to happen after the first write() call that writes the file in /var/cache/apt/archives/. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120417203350.ga27...@roeckx.be
Bug#665969: nmu: apt_0.9.0
On Tue, 2012-03-27 at 14:48 +0200, Michael Vogt wrote: We need to make sure that libept gets rebuild right after apt is ready to ensure that its updated for the new apt. Ideally we take the version in experimental that encodes the apt ABI version in its soname to ensure that its clear that while libept did not change ABI it indirectly did because of the libapt ABI break. Well, libept got re-uploaded, but with nothing in its build-depends that forced the new version of apt in to the chroots, so it just got rebuilt against apt 0.8 again - toolchain and similar packages like apt are always installed in buildd chroots, so they don't get automatically upgraded. I've poked a couple of the buildd admins about how they'd like to handle the upgrades. In the meantime, I'm not scheduling any more binNMUs. It looks like your python-apt upload is also FTBFS everywhere, with test suite failures - again, they got built against apt 0.8. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1334603644.18218.7.ca...@jacala.jungle.funky-badger.org
Bug#665969: nmu: apt_0.9.0
On Mon, Apr 16, 2012 at 08:14:04PM +0100, Adam D. Barratt wrote: On Tue, 2012-03-27 at 14:48 +0200, Michael Vogt wrote: We need to make sure that libept gets rebuild right after apt is ready to ensure that its updated for the new apt. Ideally we take the version in experimental that encodes the apt ABI version in its soname to ensure that its clear that while libept did not change ABI it indirectly did because of the libapt ABI break. Well, libept got re-uploaded, but with nothing in its build-depends that forced the new version of apt in to the chroots, so it just got rebuilt against apt 0.8 again - toolchain and similar packages like apt are always installed in buildd chroots, so they don't get automatically upgraded. I've poked a couple of the buildd admins about how they'd like to handle the upgrades. In the meantime, I'm not scheduling any more binNMUs. Oh, thanks! So what should I do? Upload libept with the updated build-dependency? Will that be fine? It looks like your python-apt upload is also FTBFS everywhere, with test suite failures - again, they got built against apt 0.8. Same for python-apt I assume? Just a updated build-dependency? Thanks, Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120416192326.GU3104@localhost
Bug#665969: nmu: apt_0.9.0
On Mon, 2012-04-16 at 21:23 +0200, Michael Vogt wrote: On Mon, Apr 16, 2012 at 08:14:04PM +0100, Adam D. Barratt wrote: On Tue, 2012-03-27 at 14:48 +0200, Michael Vogt wrote: We need to make sure that libept gets rebuild right after apt is ready [...] Well, libept got re-uploaded, but with nothing in its build-depends that forced the new version of apt in to the chroots, so it just got rebuilt against apt 0.8 again - toolchain and similar packages like apt are always installed in buildd chroots, so they don't get automatically upgraded. I've poked a couple of the buildd admins about how they'd like to handle the upgrades. In the meantime, I'm not scheduling any more binNMUs. Oh, thanks! So what should I do? Upload libept with the updated build-dependency? Will that be fine? No, we'll sort it out on the buildd side now that the uploads have happened. Hopefully there won't be any need for any further uploads. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1334605264.18218.8.ca...@jacala.jungle.funky-badger.org
Bug#665969: nmu: apt_0.9.0
On Mon, Apr 16, 2012 at 08:41:04PM +0100, Adam D. Barratt wrote: On Mon, 2012-04-16 at 21:23 +0200, Michael Vogt wrote: On Mon, Apr 16, 2012 at 08:14:04PM +0100, Adam D. Barratt wrote: On Tue, 2012-03-27 at 14:48 +0200, Michael Vogt wrote: We need to make sure that libept gets rebuild right after apt is ready [...] Well, libept got re-uploaded, but with nothing in its build-depends that forced the new version of apt in to the chroots, so it just got rebuilt against apt 0.8 again - toolchain and similar packages like apt are always installed in buildd chroots, so they don't get automatically upgraded. I've poked a couple of the buildd admins about how they'd like to handle the upgrades. In the meantime, I'm not scheduling any more binNMUs. Oh, thanks! So what should I do? Upload libept with the updated build-dependency? Will that be fine? No, we'll sort it out on the buildd side now that the uploads have happened. Hopefully there won't be any need for any further uploads. Ok, thanks! Please let me know if there is anything I can do to help at this point. Cheers, Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120416194403.GV3104@localhost
Bug#665969: nmu: apt_0.9.0
On Mon, 2012-04-16 at 21:44 +0200, Michael Vogt wrote: Ok, thanks! Please let me know if there is anything I can do to help at this point. It looks like the binNMUs aren't going quite as smoothly as hoped. Problems reported so far include: E: Method http has died unexpectedly! E: Sub-process http received signal 10. and E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for adduser:amd64, aborting Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1334608831.18218.10.ca...@jacala.jungle.funky-badger.org
Bug#665969: nmu: apt_0.9.0
On Mon, 2012-04-16 at 21:40 +0100, Adam D. Barratt wrote: On Mon, 2012-04-16 at 21:44 +0200, Michael Vogt wrote: Ok, thanks! Please let me know if there is anything I can do to help at this point. It looks like the binNMUs aren't going quite as smoothly as hoped. Problems reported so far include: E: Method http has died unexpectedly! E: Sub-process http received signal 10. This is #669061 and E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for adduser:amd64, aborting and this #669060 Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1334609241.18218.11.ca...@jacala.jungle.funky-badger.org
Bug#665969: nmu: apt_0.9.0
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal Please provide bin-NMUs for a coming apt ABI change (the apt version in experimental will hit unstable as 0.9.0). The version of apt in experimental includes multiarch support (among other changes) and now that dpkg in unstable supports that apt shold move to unstable as well. It also splits the library out of the main package properly which will make subsequent ABI breaks easier but that means that there will be binary-NEW processing needed after the initial apt upload. We need to make sure that libept gets rebuild right after apt is ready to ensure that its updated for the new apt. Ideally we take the version in experimental that encodes the apt ABI version in its soname to ensure that its clear that while libept did not change ABI it indirectly did because of the libapt ABI break. Cheers, Michael -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120327124832.GG11555@localhost
