Hi, On 2023-09-17 13:31, Helmut Grohne wrote: > Hi Aurelien, > > On Fri, Sep 15, 2023 at 12:02:35AM +0200, Aurelien Jarno wrote: > > Answering for the glibc package. > > Thanks. > > > On 2023-09-12 20:15, Helmut Grohne wrote: > > > Once the Priority:required set only has that exception set left > > > unconverted, I will prepare patches for the entire exception set and > > > upload it coherently in one dinstall window. > > > > > > That exception set is: > > > * base-files > > > * bash > > > * coreutils maybe > > > * dash > > > * libc6 > > > * util-linux > > > > Do you mean you plan to upload source+binaries for all the above > > packages and for all architectures? How do you plan to handle ports > > architectures? > > My initial idea was doing source-only uploads and letting buildds > perform all of the builds. Of course that leaves the possibility of > buildds producing their packages "late" for the next dinstall. If that > happens, the relevant architecture will fail debootstrap unstable. That > is unfortunate, but it does happen occasionally and I think it is a > reasonable risk to accept here. Once all relevant builds are done, > debootstrap will work again. There are a number of things I can do to > minimize the risk. For one thing, I can ask DSA when the cronjob for > updating buildd chroots happens and align the uploads closely after such > a cronjob. For another, I can coordinate with the buildd people and ask > for help (e.g. prioritizing builds) on their side. Then I can mail > d-devel and announce a concrete point in time asking developers to not > upload packages on that particular day (e.g. using the delayed queue) to > temporarily reduce the buildd load. Quite probably, debootstrap will > temporarily break on some architectures. I hope that this is acceptable > and that minimizing the downsides is good enough. > > Does that answer your question?
Yes, it does. So while it is important to minimize as much as possible the time where all those packages are not in sync, it can be slightly more than a single dinstall, maybe it's something to mention. Another alternative might be to ask the ftpmasters to skip a dinstall. Even skipping the push to the mirrors without skipping the dinstall might be enough. To answer your questions: - It's indeed possible to prioritize builds to minimize the out-of-sync time as much as possible, but it might not be guaranteed on all architectures to be within a single dinstall. - For buildd administrated by DSA, the cronjob to generate chroots is setup to run at 22:13 UTC every Wednesdays and Sundays. > > > * Do you readily see any flaw in the proposed transition already? > > > > I haven't looked at the details besides the changes you described above. > > Thank you. We'll get into details once there are patches. > > Unfortunately, testing patches right now is difficult, because this work > depends on all other (required) packages having been converted, which in > turn is blocked in buildds being merged. Hoping that this is less work > if done later, I've prioritized other matters for now and reach out to > you now as a means of informing and gathering consent. Thanks for doing that. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
