Re: Streamlining d-i releases

[Cyril Brulebois]

(Dropping -cd@ and -release@ — and letting them know via bcc —, that's
probably less interesting for them at this point.)

Joerg Jaspert  (2023-04-10):
> I prepared a little script. Now need a SSH key to allow.

Attached.

> Usage is simple, you MUST supply a version, you CAN supply a source and
> a dest suite. Space seperated. It checks amd64s installer in that suite,
> and if the version directory exists, it calls dak copy-installer on it.

LGTM, thanks!

Out of curiosity, what happens if there's one or more missing builds at
some point? Can copy-installer be called several times? A quick glance
at dak/copy_installer.py suggests that check_architecture() does the
right thing (i.e. detect and skip things that exist already).

It seems what matters is the existence of the relevant directories on the
filesystem, which is likely to have happened by the time buildd.debian.org
shows an Installed state (via scripts/debian/byhand-di, called from
daklib/archive.py) but I haven't seen any logs to about auto-byhand so I'm
not entirely sure about the timings.


(In passing The error message has “${SOURCE}s dir” which could get an
apostrophe or lose an s.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


id_rsa.pub
Description: application/vnd.exstream-package


signature.asc
Description: PGP signature

Re: Streamlining d-i releases

[Joerg Jaspert]

On 16829 March 1977, Cyril Brulebois wrote:

I put SSH trigger into the room, instead of sudo. You supply the 
version
on the ssh cmdline, and if that exists in unstable, a copy-installer 
is

run with that version.

That looks very good to me, thanks!
Could even be extended to have source and target suite selectable 
too.

I think we only released the installer via tpu once, at least that I
could confirm by checking my sent box:


I prepared a little script. Now need a SSH key to allow.
Usage is simple, you MUST supply a version, you CAN supply a source and
a dest suite. Space seperated.
It checks amd64s installer in that suite, and if the version directory
exists, it calls dak copy-installer on it.

--
bye, Joerg

Re: Streamlining d-i releases

[Cyril Brulebois]

Joerg Jaspert  (2023-04-09):
> > I realize that getting a sudo line on fasolo would mean increasing the
> > security risks quite a bunch for a limited gain. Since we already have
> > a mechanism to trigger changes in the archive via release team access,
> > that is /srv/release.debian.org/www/proposed-updates/*_comments (which
> > we can edit from coccia); maybe something similar could be done to
> > trigger dak copy-installer?
> 
> I put SSH trigger into the room, instead of sudo. You supply the version
> on the ssh cmdline, and if that exists in unstable, a copy-installer is
> run with that version.

That looks very good to me, thanks!

> Could even be extended to have source and target suite selectable too.

I think we only released the installer via tpu once, at least that I
could confirm by checking my sent box:

dak copy-installer 20220917 -s bookworm-proposed-updates

but it could indeed be nice to be able to specify at least the source
suite, just in case we encounter some blocking bug in unstable again in
the future.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Streamlining d-i releases

[Joerg Jaspert]

On 16824 March 1977, Cyril Brulebois wrote:


I realize that getting a sudo line on fasolo would mean increasing the
security risks quite a bunch for a limited gain. Since we already have
a mechanism to trigger changes in the archive via release team access,
that is /srv/release.debian.org/www/proposed-updates/*_comments (which
we can edit from coccia); maybe something similar could be done to
trigger dak copy-installer?


I put SSH trigger into the room, instead of sudo. You supply the version
on the ssh cmdline, and if that exists in unstable, a copy-installer is
run with that version. Could even be extended to have source and target
suite selectable too.

--
bye, Joerg

Streamlining d-i releases

[Cyril Brulebois]

Hi ftp team,

As you know, publishing a Debian Installer release involves a bunch of
steps across various parts of the infrastructure, spanning across many
teams:
 - debian-boot (many udebs + src:debian-installer upload)
 - ftpmaster (dak copy-installer)
 - debian-release (udebs + src:debian-installer migration)
 - debian-cd (image builds)
 - debian-www (debian.org/devel/debian-installer)

I'm able to prepare website updates via the webwml repository and to
trigger a partial rebuild of the website to publish the announce (via
an update-part sudo entry on wolkenstein).

Via debian-release I'm also able to hint (via unblock, unblock-udeb,
and urgent) udeb packages into testing, then block the migration of
udeb-producing packages for a few hours or days, which lets me upload
src:debian-installer on my own timing. I'm also able to hint it into
testing once it's built everywhere.

Since we have many moving parts, and since regressions or worries can
come up at any time, I don't think we would be able to come up with
some kind of schedule to coordinate with the ftp team, and I'm left
with having to poke you folks without advance warning. I really don't
like doing that, and depending on your availability, that might mean
several hours (all fine) or sometimes several days until the dak
copy-installer step happens. Once one factors in the other delays
(britney runs for package migration, dinstall runs to make changes
visible on mirrors, prior to the debian-installer upload, or after the
dak copy-installer step), this means the release process takes a very
while, including (sometimes very) long pauses…

I'd like to see if we could shorten it by getting some extra autonomy,
to shorten the udeb freeze (it affects a bunch of packages that aren't
under the installer team's umbrella, and outside freeze stages it has
already upset people enough to trigger an argument during what was
supposed to be a nice evening at DebConf…) and to keep the release
energy and motivation as high as possible.

I realize that getting a sudo line on fasolo would mean increasing the
security risks quite a bunch for a limited gain. Since we already have
a mechanism to trigger changes in the archive via release team access,
that is /srv/release.debian.org/www/proposed-updates/*_comments (which
we can edit from coccia); maybe something similar could be done to
trigger dak copy-installer?


(The other side I usually entirely delegate is building images, and I
sync/resync with Steve along the way, based on whether d-i looks good
or whether I encounter and fix/workaround roadblocks, but I plan on
learning that on my own as well to avoid putting pressure on Steve
all the time — got the gid already, lacking know-how at the moment,
and possibly access to secrets for the ultimate signing.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature