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 (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 (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)
