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

[Cyril Brulebois]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20220305/c6e2a647/attachment.sig>