Bug#793606: always builds on all architectures
On Sun, Jul 26, 2015 at 04:16:44PM +0200, Stephan Sürken wrote: In your setup mini-buildd does not find any builder for the your arch (to eventually run sbuild on) in the first place. Well, it shouldn't do that. It is clear from the meta information in the .dsc that the package is not for armhf. I'm fine with this being a wishlist item though. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793606: always builds on all architectures
severity #793606 wishlist retitle #793606 please don't upload build requests to archs that don't need build thanks Hi Stephan, On Sun, Jul 26, 2015 at 11:04:45AM +0200, Stephan Sürken wrote: Fwiw, currently, mini-buildd just uploads build requests to all builders and completely relies on sbuild. This *is* a nice solution, as sbuild knows best, and no extra/duplicated code/dsc knowledge at all is needed in mini-buildd. So it is sbuild that does not honor the Architecture field? Should help me when returning to it ;). I guess it depends how simple it is to implement whether I am considering this... Done, thanks! Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793606: always builds on all architectures
On So, 2015-07-26 at 11:22 +0200, Marc Haber wrote: (...) On Sun, Jul 26, 2015 at 11:04:45AM +0200, Stephan Sürken wrote: Fwiw, currently, mini-buildd just uploads build requests to all builders and completely relies on sbuild. This *is* a nice solution, as sbuild knows best, and no extra/duplicated code/dsc knowledge at all is needed in mini-buildd. So it is sbuild that does not honor the Architecture field? No, sbuild would run fine and result with status skipped (which is a successful build). In your setup mini-buildd does not find any builder for the your arch (to eventually run sbuild on) in the first place. Htei, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793606: always builds on all architectures
Moin, On Sa, 2015-07-25 at 15:28 +0200, Marc Haber wrote: (...) my mini-buildd is configured to have architectures amd64, i386 and armhf. The armhf arch was just recently added so that I could poke locally built packages into the repository using direct reprepro calls and to be prepared to have mini-buildd actually build armhf packages. I do not yet have an armhf builder since my only armhf system is running jessie and does not have enough storage to support a sid chroot, and I would like to spare myself from backporting mini-buildd to jessie. ftra, I am always doing ports for jessie (via Debian Backports) or even wheezy (via my own repo). When mini-buildd builds a package now, the build fails because there is no armhf builder. With one build failing like that, the packages resulting from the successful builds on i386 and amd64 are not uploaded to the archive. (...) I tried my package now with Architecture: amd64 in all binary (...) Despite this, mini-buildd attempted to build the package for i386 (successful) and armhf (failed, no builder available), and didn't upload the amd64 package to the archive. (...) I think that mini-buildd should honor the Architecture: field in uploaded packages and refrain from trying to build on arches that the packager doesn't want. hmm ok, for that special setup (having no builder at all for a required arch), it would be a nice to have. Fwiw, currently, mini-buildd just uploads build requests to all builders and completely relies on sbuild. This *is* a nice solution, as sbuild knows best, and no extra/duplicated code/dsc knowledge at all is needed in mini-buildd. As this case is already covered by confing the arch as optional, can we put that to wishlist and rename it to please don't upload build requests to archs that don't need build? Should help me when returning to it ;). I guess it depends how simple it is to implement whether I am considering this... Thx! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793606: always builds on all architectures
Source: mini-buildd Version: 1.0.7 Severity: normal Hi! my mini-buildd is configured to have architectures amd64, i386 and armhf. The armhf arch was just recently added so that I could poke locally built packages into the repository using direct reprepro calls and to be prepared to have mini-buildd actually build armhf packages. I do not yet have an armhf builder since my only armhf system is running jessie and does not have enough storage to support a sid chroot, and I would like to spare myself from backporting mini-buildd to jessie. When mini-buildd builds a package now, the build fails because there is no armhf builder. With one build failing like that, the packages resulting from the successful builds on i386 and amd64 are not uploaded to the archive. I tried my package now with Architecture: amd64 in all binary packages, which correctly resulted in Architecture: amd64 in the .dsc file. The _source.changes file that got uploaded to mini-buildd had Architecture: source. Despite this, mini-buildd attempted to build the package for i386 (successful) and armhf (failed, no builder available), and didn't upload the amd64 package to the archive. I think that mini-buildd should honor the Architecture: field in uploaded packages and refrain from trying to build on arches that the packager doesn't want. Setting armhf to optional in the repository settings is a remedy for the issue, but I still feel that the ultimate responsibility should be with the packager. Greetings Marc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
