Bug#1006800: debian-installer: kernel mismatch for bookworm and sid installer. New release needed?

[Jisook Moon]

Please remove my email from the mailing list thank you.

On Sat, Mar 5, 2022 at 9:46 AM Cyril Brulebois <kibi at debian.org> wrote:

> Roland Clobus <rclobus at rclobus.nl> (2022-03-05):
> > On 05/03/2022 12:40, Cyril Brulebois wrote:
> > > We could, and should, release a new d-i and possibly an Alpha 1 at some
> > > point, but I don't have a specific timeline for that.
> >
> > Understood. I assume that an Alpha 1 release will be made somewhere
> > near the release date of bookworm.
>
> In the past I've tried to have an Alpha 1 released after a few months
> into the new release cycle, then aim for something like a release every
> 1-2 months.
>
> But the archive can disagree from time to time, and lately, I'm rather
> busy with other things…
>
> > Indeed. A new debian-installer upload would need to happen in
> > lock-step with every new ABI in src:linux, to guarantee a consistent
> > state of d-i. This could mean quite some work on your side.
>
> Uploading more often could be doable; the current approach has been to
> upload whenever we were getting close to wanting a new release of the
> installer, following up with 1-2 more uploads if things didn't work out
> immediately.
>
> > I'm looking at possible solutions here (that's why I've added the
> > rb-general mailing list):
> > * (Manually) do official releases of debian-installer more often
>
> Doable, as stated above.
>
> >   (as I wrote, openQA will soon have some tests that detect when the
> >   kernel version got out-of-sync)
>
> Well, I do follow kernel uploads and ABI bumps closely, so that's a
> problem that's already solved (git says since 2013).
>
> FWIW we're seeing mutiple hours to multiple days of delay for some
> architectures (we need the *-signed packages to get processed).
>
> > * Automatically release git snapshots to deb.d.o instead of d-i.d.o
>
> Uploading untested stuff to the archive, automatically? No, thanks.
>
> > * Extend snapshot.d.o and/or snapshot.notset.fr to cover d-i.d.o in
> >   addition to deb.d.o
>
> Maybe avoidable if we go for more frequent uploads.
>
> > * No changes, and accept that older images cannot be recreated (this
> >   option is not preferred by me)
> > * Other ...
> >
> > > How long do you need to go back / how long do you need to keep a given
> > > build? Maybe we could just keep (some) builds for a longer while there,
> > > but that's at 90 days already.
> >
> > Looking at https://d-i.debian.org/daily-images/amd64/, the current
> > history I can see is about 15 days.
>
> Right, ISTR that was around 30 days, glanced at the graph before hitting
> the sack and didn't check thoroughly: we indeed clean more frequently
> than showed on the graph.
>
> > While investigating reproducible issues I personally tend to pick some
> > timestamp and work on that for a longer period of time. 90 days would
> > suffice completely for my purpose.
>
> At the moment, daily-images is 42G, 6.8G of it being amd64. If we
> estimate a ×6 in size for just that architecture, that's nearly doubling
> that size, and it's only covering that one architecture. The machine is
> shared across various services, but has 121G free at the moment, so we
> could probably try something like that (maybe some middleground like 45
> days for starters) if that helped in the very short term? Or would you
> need to look at more architectures immediately?
>
>
> Cheers,
> --
> Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20220305/106f2583/attachment.htm>