Hi Raphaël,
Raphaël Halimi <raphael.halimi@gmail.com> (2019-06-29):
> I don't mean to rush you, but […]
Hrm.
> My current workaround is to add a hook in base-installer.d (because it
> has to be done just before apt gets configured) to replace
> /usr/lib/apt-setup/generators/60local with a version including a line
> to install gnupg before "apt-key add" is called (patch included).
>
> (the modification can also be done manually during the base system
> installation phase, but it is error-prone, has to be done very quickly
> at the right moment, and of course completely defeats the purpose of
> an unattended installation)
>
> I noticed that gnupg used to be Priority: important, whereas it's now
> Priority: optional.
>
> If installing gnupg is what it takes to fix the bug, IMHO it should be
> done; anyway, with this patch, it would be installed only if a local
> repository with a GnuPG key is used at all.
Well, I proposed doing so a while ago but that didn't happen. Looking at
the current gnupg package, it's not about installing just a single,
extra package:
Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= 2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< 2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= 2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< 2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2)
I'm also not sure what part of dirmngr and/or gpg-agent are going to
stay around running, after calling “apt-key add” with gnupg installed.
Testing that was conceivable a couple of weeks/months back; a few days
before an archive freeze, not so much.
Plus, we've got a MR against apt-setup now, see #851774. It's also come
late and nobody reviewed it yet. Plus, the other, serious bug report was
marked as buster-ignore by a release team member, so there's no *need*
to fix this before buster.
> I hope this fix (or another one of your own choice) will make it to
> d-i before release.
All in all, it looks like we're instead going to consider the MR at the
beginning of the bullseye release cycle, and backport the fix to buster
if it proves to be working fine.
Letting the other bug and Moritz know through cc.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature