buildd dependency problems?
I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due to various dependencies: https://buildd.debian.org/status/package.php?p=resiprocatesuite=sid and it appears these dependencies have been unavailable for a long time. The bottom line is that urgent fixes in the package are not propagating to testing at all because of these other packages on the least used architectures To avoid causing delays for users who want the fixes in testing, I'm tempted to just change Architecture: any and cut out those other platforms. I had a brief look here: http://www.debian.org/devel/buildd/ and I notice it encourages people to make their package portable, which is great for packages people maintain themselves but I couldn't find any guidance about the situation I have now. If I do cut support for those other architectures, is there any way I can be automatically notified when the dependencies do become available? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e7c784.2000...@pocock.com.au
Re: buildd dependency problems?
Daniel Pocock, le Thu 18 Jul 2013 12:46:28 +0200, a écrit : To avoid causing delays for users who want the fixes in testing, I'm tempted to just change Architecture: any and cut out those other platforms. I'd say there is no need for this. If *your* package is supposed to work on all platforms, then any is right. If some dependency is not available any more for a long term, then you can probably ask for an arch-specific removal of the outdated binaries. Whenever the dependencies get back, things will get rebuilt without any manual change. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718105410.gp5...@type.bordeaux.inria.fr
Re: buildd dependency problems?
On Thu, Jul 18, 2013 at 12:46:28PM +0200, Daniel Pocock wrote: I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due to various dependencies: https://buildd.debian.org/status/package.php?p=resiprocatesuite=sid I see it built immediately on kfreebsd-*, what's the problem? It has never worked on sparc nor hurd-i386, which is also ok (besides not being available for those arches). To avoid causing delays for users who want the fixes in testing, I'm tempted to just change Architecture: any and cut out those other platforms. Architecture: any would cause this issue only in case of regressions: if your package built there successfully in the past. It never did on sparc nor hurd, so such architectures won't drag you down. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130718163012.ga8...@angband.pl
Re: buildd dependency problems?
On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote: I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due to various dependencies: https://buildd.debian.org/status/package.php?p=resiprocatesuite=sid and it appears these dependencies have been unavailable for a long time. The bottom line is that urgent fixes in the package are not propagating to testing at all because of these other packages on the least used architectures I was tempted to reply with simply codswallop, but that seemed unhelpful so I'll expand on how you're mistaken. It's a little more difficult than it might have been to check the situation now, as there have been three uploads of resiprocate since you sent the mail to which I'm replying. However, one can still easily look at the grep-excuses output for the previous upload: 24 days old (needed 10 days) out of date on armel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.8-2) out of date on kfreebsd-amd64: libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.5-4) out of date on kfreebsd-i386: libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.5-4) out of date on mips: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) out of date on mipsel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.8-2) out of date on powerpc: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) out of date on s390: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) out of date on s390x: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) resiprocate (source) has new bugs! Updating resiprocate introduces new bugs: #713634, #713865 Of the architectures you suggested were blocking urgent fixes, neither hurd-i386 nor sparc appear in that list - both because the failures are not regressions and because hurd isn't a release architecture. Indeed, the above output clearly indicates that the actual problems were the build failures on eight previously supported architectures. (and the two RC bugs which were still open despite apparently having been fixed.) Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374180299.4738.13.ca...@jacala.jungle.funky-badger.org
Re: buildd dependency problems?
On 18/07/13 22:44, Adam D. Barratt wrote: On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote: I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due to various dependencies: https://buildd.debian.org/status/package.php?p=resiprocatesuite=sid and it appears these dependencies have been unavailable for a long time. The bottom line is that urgent fixes in the package are not propagating to testing at all because of these other packages on the least used architectures I was tempted to reply with simply codswallop, but that seemed unhelpful so I'll expand on how you're mistaken. It's a little more difficult than it might have been to check the situation now, as there have been three uploads of resiprocate since you sent the mail to which I'm replying. However, one can still easily look at the grep-excuses output for the previous upload: 24 days old (needed 10 days) out of date on armel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.8-2) out of date on kfreebsd-amd64: libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.5-4) out of date on kfreebsd-i386: libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.5-4) out of date on mips: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) out of date on mipsel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.8-2) out of date on powerpc: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) out of date on s390: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) out of date on s390x: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2) resiprocate (source) has new bugs! Updating resiprocate introduces new bugs: #713634, #713865 Of the architectures you suggested were blocking urgent fixes, neither hurd-i386 nor sparc appear in that list - both because the failures are not regressions and because hurd isn't a release architecture. Ok, I had simply been looking at the buildd status page and trying to get it into shape (things are looking better after today's third upload). Given the long list of failures I hadn't been comparing the items on the different lists one by one. Maybe the buildd status could differentiate the blocking failures? Or is there another way I can view all of that in one place? Indeed, the above output clearly indicates that the actual problems were the build failures on eight previously supported architectures. (and the two RC bugs which were still open despite apparently having been fixed.) The quality of the code has actually improved, but so have the test cases and they are catching bugs that were there before, especially on big endian. Various upstream issues have been found in big endian and other non-Intel architectures - obviously all the upstream team are very grateful to Debian for providing a platform where we could make these improvements. On the other hand, we've simultaneously fixed some unrelated issues on the most popular architectures too -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e85719.5010...@pocock.com.au
Re: buildd dependency problems?
On Thu, 2013-07-18 at 22:59 +0200, Daniel Pocock wrote: On 18/07/13 22:44, Adam D. Barratt wrote: On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote: I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due to various dependencies: https://buildd.debian.org/status/package.php?p=resiprocatesuite=sid [...] Of the architectures you suggested were blocking urgent fixes, neither hurd-i386 nor sparc appear in that list - both because the failures are not regressions and because hurd isn't a release architecture. Ok, I had simply been looking at the buildd status page and trying to get it into shape (things are looking better after today's third upload). Given the long list of failures I hadn't been comparing the items on the different lists one by one. It could just be me, but your mail read as if you were suggesting that the build failures on the four architectures you mentioned were the only things blocking testing transition, rather than the eight affected in total. Maybe the buildd status could differentiate the blocking failures? Or is there another way I can view all of that in one place? The buildd status pages do clearly indicate whether the failure is a regression (uncompiled versus out-of-date). In terms of whether the architecture is a release architecture, that's not something the buildd system should need to know about; it's not something that changes very often though, and the excuses output will indicate whether it's an issue (you'll note that there's no mention of hurd-i386 anywhere in the excuses). Indeed, the above output clearly indicates that the actual problems were the build failures on eight previously supported architectures. (and the two RC bugs which were still open despite apparently having been fixed.) The quality of the code has actually improved, but so have the test cases and they are catching bugs that were there before, especially on big endian. That's good, and we like bugs being fixed. :-) It also points to 100% more issues than your original mail suggested, however. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1374181966.4738.19.ca...@jacala.jungle.funky-badger.org
