Re: mandatory source uploads
On Mon, 08 Jul 2019 11:57:45 +0200, Thomas Goirand wrote: > So if I understand correctly, I can just rebuild everything and do > source-only uploads, and the Debian infra will be smart enough to > understand how to build? Great, I'll try then! :) As long as you don't hit #865304 (taken from /topic in #debian-ftp) or some of the other similar bugs which affect arch:all (?) uploads; then dak moves package to NEW which are simply waiting for their dependencies to be built. (Sorry if this is a bit vague, I don't remember the exact details but there is a well-known problem in this area.) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: mandatory source uploads
Quoting Samuel Thibault (2019-07-08 12:01:01) > Thomas Goirand, le lun. 08 juil. 2019 11:57:45 +0200, a ecrit: > > So if I understand correctly, I can just rebuild everything and do > > source-only uploads, and the Debian infra will be smart enough to > > understand how to build? > Yes. Only the dependency loops pose problem. wanna-build is currently not able to break build dependency cycles by itself even if build profile annotation (i.e or similar) would theoretically allow it to do so. Maybe this is a good time to either: - teach wanna-build how to schedule profile built binary packages (which will *not* end up in the archive) to break dependency cycles - allow developers to annotate uploads with a specific build profile that the source package is supposed to be built with (maybe in the .changes file?) -- again the result should not end up in unstable but be used to break dependency cycles with hard version constraints Thanks! cheers, josch signature.asc Description: signature
Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)
Am Mo., 8. Juli 2019 um 09:14 Uhr schrieb Thomas Goirand : > > On 7/8/19 12:34 AM, Scott Kitterman wrote: > > As long as your build-depends are properly versioned, why can't you just > > upload all the source and let wanna-build sort it out? > > > > Scott K > > This means that I have to baby-sit the Debian archive and upload > everything in the correct order, waiting for the previous upload to be > accepted and online. But why? If the build dependencies are tightened enough so that builds are run in order anyway, this issue shouldn't occur. If a dependency isn't built in the correct version yet, the package will just wait with its build until the dependency does become available. > BTW, one very important thing: are the buildds configured to use > incoming at least? If so, that probably could be bearable. AFAIK they indeed do that. > [] Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: mandatory source uploads
Thomas Goirand, le lun. 08 juil. 2019 11:57:45 +0200, a ecrit: > So if I understand correctly, I can just rebuild everything and do > source-only uploads, and the Debian infra will be smart enough to > understand how to build? Yes. Only the dependency loops pose problem. Samuel
Re: mandatory source uploads
On 7/8/19 9:38 AM, Philipp Kern wrote: > On 2019-07-08 09:14, Thomas Goirand wrote: >> On 7/8/19 12:34 AM, Scott Kitterman wrote: >>> As long as your build-depends are properly versioned, why can't you just >>> upload all the source and let wanna-build sort it out? > [...] >> This means that I have to baby-sit the Debian archive and upload >> everything in the correct order, waiting for the previous upload to be >> accepted and online. > > Not really. wanna-build will only schedule the build if the build > dependency is satisfiable. So if you encode everything correctly there > (which might be hard, c.f. circular build dependencies), wanna-build > will schedule in the correct order by itself. > >> BTW, one very important thing: are the buildds configured to use >> incoming at least? If so, that probably could be bearable. > > And of course buildds use incoming and so does wanna-build. > > Kind regards > Philipp Kern Thanks Philipp, for the advice. So if I understand correctly, I can just rebuild everything and do source-only uploads, and the Debian infra will be smart enough to understand how to build? Great, I'll try then! :) Cheers, Thomas Goirand (zigo)
Re: mandatory source uploads
On 2019-07-08 09:14, Thomas Goirand wrote: On 7/8/19 12:34 AM, Scott Kitterman wrote: As long as your build-depends are properly versioned, why can't you just upload all the source and let wanna-build sort it out? [...] This means that I have to baby-sit the Debian archive and upload everything in the correct order, waiting for the previous upload to be accepted and online. Not really. wanna-build will only schedule the build if the build dependency is satisfiable. So if you encode everything correctly there (which might be hard, c.f. circular build dependencies), wanna-build will schedule in the correct order by itself. BTW, one very important thing: are the buildds configured to use incoming at least? If so, that probably could be bearable. And of course buildds use incoming and so does wanna-build. Kind regards Philipp Kern
Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)
On 7/8/19 12:34 AM, Scott Kitterman wrote: > As long as your build-depends are properly versioned, why can't you just > upload all the source and let wanna-build sort it out? > > Scott K This means that I have to baby-sit the Debian archive and upload everything in the correct order, waiting for the previous upload to be accepted and online. BTW, one very important thing: are the buildds configured to use incoming at least? If so, that probably could be bearable. > That'd assume that there are no circular dependencies. On 7/8/19 8:27 AM, Philipp Kern wrote: The very small amount of circular (build-)dependency is probably not the issue, as using the older version should be fine. The thing I'm expecting is build failure with non-matching versions (OpenStack upstream CI is built to work with everything from the same release). > I take it that > they are all arch:all? (Because otherwise wanna-build would already > need to figure it out for you to build on other architectures.) Most (if not all) is in Python, so yes, arch:all. Cheers, Thomas Goirand (zigo)
Re: mandatory source uploads
On 2019-07-08 00:34, Scott Kitterman wrote: On Sunday, July 7, 2019 6:30:58 PM EDT Thomas Goirand wrote: On 7/7/19 3:16 PM, Holger Levsen wrote: > Hi, > > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: >> Shortly before the end of the 6th July, we released Debian 10, "buster". > > *yay* *yay* & *yay*! > >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is about to >> begin. From now on, we will no longer allow binaries uploaded by >> maintainers to migrate to testing. This means that you will need to do >> source-only uploads if you want them to reach bullseye. >> >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? A: Yes (preferably with other changes, not just a version >> bump). >> >> Q: I needed to do a binary upload because my upload went to the NEW >> queue, >> >> do I need to do a new (source-only) upload for it to reach bullseye? >> >> A: Yes. We also suggest going through NEW in experimental instead of >> unstable>> >> where possible, to avoid disruption in unstable. > > whh, that's *totally* awesome news! loving it. I don't. I don't fee happy of this at all, and here's why. I have 150 OpenStack packages waiting in Experimental, built for the OpenStack Stein release. OF COURSE, they all are inter-dependent, and to build a given package, you probably need the latest version of another one. So, instead of preparing them all (build them all for Unstable and upload at once, using sbuild and --extra-package when needed), it means that I'll have to build them one by one, upload, wait for the next dak run to have a new package in, then go to the next. With the amount of package, this probably can take 3 weeks to a month instead of a single week like I planned. Also, the result, it's *less nice* for Sid/Bullseye users, because the transition will be super long if I do this way. The other alternative is to build all like I planned, upload all to Unstable, then rebuild all again, and do a 2nd upload (source only this time). There, I'm also loosing a lot of time for no valid technical reason, which isn't nice at all either. I feel like I'm going to be doing all of this during all of debcamp / debconf, which isn't fun at all, I had planned for other stuffs to do there. Advice on what's the best way would be welcome. I also very much would prefer if this wasn't announced just like this, without giving any amount of time to prepare for the thing and discuss it. That's not the first time the release team does this way, and that's really not the best way to do things. (If I missed the discussion, then IMO it wasn't advertised enough, which has the same effect.) I very much salute the source-only enforcement, but I really don't think this was thought through completely. As long as your build-depends are properly versioned, why can't you just upload all the source and let wanna-build sort it out? That'd assume that there are no circular dependencies. I take it that they are all arch:all? (Because otherwise wanna-build would already need to figure it out for you to build on other architectures.) Kind regards Philipp Kern
Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)
On Sunday, July 7, 2019 6:30:58 PM EDT Thomas Goirand wrote: > On 7/7/19 3:16 PM, Holger Levsen wrote: > > Hi, > > > > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: > >> Shortly before the end of the 6th July, we released Debian 10, "buster". > > > > *yay* *yay* & *yay*! > > > >> No binary maintainer uploads for bullseye > >> = > >> > >> The release of buster also means the bullseye release cycle is about to > >> begin. From now on, we will no longer allow binaries uploaded by > >> maintainers to migrate to testing. This means that you will need to do > >> source-only uploads if you want them to reach bullseye. > >> > >> Q: I already did a binary upload, do I need to do a new (source-only) > >> upload? A: Yes (preferably with other changes, not just a version > >> bump). > >> > >> Q: I needed to do a binary upload because my upload went to the NEW > >> queue, > >> > >> do I need to do a new (source-only) upload for it to reach bullseye? > >> > >> A: Yes. We also suggest going through NEW in experimental instead of > >> unstable>> > >> where possible, to avoid disruption in unstable. > > > > whh, that's *totally* awesome news! loving it. > > I don't. I don't fee happy of this at all, and here's why. > > I have 150 OpenStack packages waiting in Experimental, built for the > OpenStack Stein release. OF COURSE, they all are inter-dependent, and to > build a given package, you probably need the latest version of another one. > > So, instead of preparing them all (build them all for Unstable and > upload at once, using sbuild and --extra-package when needed), it means > that I'll have to build them one by one, upload, wait for the next dak > run to have a new package in, then go to the next. With the amount of > package, this probably can take 3 weeks to a month instead of a single > week like I planned. > > Also, the result, it's *less nice* for Sid/Bullseye users, because the > transition will be super long if I do this way. > > The other alternative is to build all like I planned, upload all to > Unstable, then rebuild all again, and do a 2nd upload (source only this > time). There, I'm also loosing a lot of time for no valid technical > reason, which isn't nice at all either. I feel like I'm going to be > doing all of this during all of debcamp / debconf, which isn't fun at > all, I had planned for other stuffs to do there. > > Advice on what's the best way would be welcome. > > I also very much would prefer if this wasn't announced just like this, > without giving any amount of time to prepare for the thing and discuss > it. That's not the first time the release team does this way, and that's > really not the best way to do things. (If I missed the discussion, then > IMO it wasn't advertised enough, which has the same effect.) > > I very much salute the source-only enforcement, but I really don't think > this was thought through completely. As long as your build-depends are properly versioned, why can't you just upload all the source and let wanna-build sort it out? Scott K
Re: mandatory source uploads (was: Bits from the Release Team: ride like the wind, Bullseye!)
On 7/7/19 3:16 PM, Holger Levsen wrote: > Hi, > > On Sun, Jul 07, 2019 at 02:47:00AM +0100, Jonathan Wiltshire wrote: >> Shortly before the end of the 6th July, we released Debian 10, "buster". > > *yay* *yay* & *yay*! > >> No binary maintainer uploads for bullseye >> = >> >> The release of buster also means the bullseye release cycle is about to >> begin. >> From now on, we will no longer allow binaries uploaded by maintainers to >> migrate to testing. This means that you will need to do source-only uploads >> if >> you want them to reach bullseye. >> >> >> Q: I already did a binary upload, do I need to do a new (source-only) >> upload? >> A: Yes (preferably with other changes, not just a version bump). >> >> Q: I needed to do a binary upload because my upload went to the NEW queue, >> do I need to do a new (source-only) upload for it to reach bullseye? >> A: Yes. We also suggest going through NEW in experimental instead of >> unstable >> where possible, to avoid disruption in unstable. > > whh, that's *totally* awesome news! loving it. I don't. I don't fee happy of this at all, and here's why. I have 150 OpenStack packages waiting in Experimental, built for the OpenStack Stein release. OF COURSE, they all are inter-dependent, and to build a given package, you probably need the latest version of another one. So, instead of preparing them all (build them all for Unstable and upload at once, using sbuild and --extra-package when needed), it means that I'll have to build them one by one, upload, wait for the next dak run to have a new package in, then go to the next. With the amount of package, this probably can take 3 weeks to a month instead of a single week like I planned. Also, the result, it's *less nice* for Sid/Bullseye users, because the transition will be super long if I do this way. The other alternative is to build all like I planned, upload all to Unstable, then rebuild all again, and do a 2nd upload (source only this time). There, I'm also loosing a lot of time for no valid technical reason, which isn't nice at all either. I feel like I'm going to be doing all of this during all of debcamp / debconf, which isn't fun at all, I had planned for other stuffs to do there. Advice on what's the best way would be welcome. I also very much would prefer if this wasn't announced just like this, without giving any amount of time to prepare for the thing and discuss it. That's not the first time the release team does this way, and that's really not the best way to do things. (If I missed the discussion, then IMO it wasn't advertised enough, which has the same effect.) I very much salute the source-only enforcement, but I really don't think this was thought through completely. Cheers, Thomas Goirand (zigo)
