Package: apt Version: 2.9.19 Severity: minor Dear Maintainer,
There has been a change of behaviour regarding how the trusted.gpg.d directory gets dealt with since 2.9.19 when a non-standard Dir is configured. I have found a work-around, which is to set Dir::Etc::trustedparts to "/etc/apt/trusted.gpg.d" in our local config. Perhaps we should always have been setting that, but it seems that things worked without it pre-2.9.19 so I thought you might like to know that something had changed, given that you've just switched to Sequoia. When building test versions of Debian-Installer with the "branch2repo" pipeline that we use for building udebs on salsa, we create a repository using aptly containing the udebs. Later in the pipeline, we add that repository to the sources.list.udeb.local that is used within the D-I build process for collecting the udebs that will go into the images. We set APT_CONFIG to point at our local config, then use apt-get to do an update, then download the udebs we need. This is mostly done in a script called get-packages, with the bit that creates the local config being here: https://salsa.debian.org/installer-team/debian-installer/-/blob/20241227/build/util/get-packages?ref_type=tags#L83 This all worked until 2.9.19, at which point it stopped working in the case where we're adding the local aptly URL. You can see it failing here: https://salsa.debian.org/philh/cdebconf/-/jobs/6829946#L3465 (the error is on line 3465) for some reason, this only seems to be a problem when the local aptly repo is specified -- the sources line in question can be seen here: https://salsa.debian.org/philh/cdebconf/-/jobs/6829946#L3418 (on line 3418) It occurs to me that the distinguishing feature may be that this is using https, whereas the normal repo URL is http, and that this is using signed-by= in the line, whereas the deb.debian.org lines are relying on installed keys somehow. As mentioned at the outset, the problem can be fixed with this change to out local configuration: https://salsa.debian.org/philh/debian-installer/-/commit/10c77e7fe79d8349804126a7bd98305636f56984 but I'm left wondering why the change was needed, and whether the new behaviour is intentional. Cheers, Phil.
