Source: dupload
Version: 2.13.0
Severity: normal
the latest version of dupload breaks buildd-uploader from the src:sbuild package:
Feb 28 14:35:42 buildd-uploader[42155]: 2 jobs to upload in upload: dde-calendar_5.14.13-1_alpha.changes searchandrescue_1.7.0+dfsg-1_alpha.changes
Use of uninitialized value $u in substitution (s///) at /usr/share/perl5/Buildd/Uploader.pm line 254.
Use of uninitialized value $u in unlink at /usr/share/perl5/Buildd/Uploader.pm line 255.
Use of uninitialized value $u in concatenation (.) or string at /usr/share/perl5/Buildd/Uploader.pm line 256.
Use of uninitialized value $u in concatenation (.) or string at /usr/share/perl5/Buildd/Uploader.pm line 257.
Feb 28 14:35:44 buildd-uploader[42155]: dupload exit status 25/0
Feb 28 14:35:44 buildd-uploader[42155]: Removed due to upload errors.
I have not investigated the problem in detail yet. However, downgrading dupload
to 2.11.2 fixes the problem for me.
I have not investigated the problem in detail yet. However, downgrading dupload
to 2.11.2 fixes the problem for me.
I'd assume this is due to the new OpenPGP multi-backend support, which
makes the openpgp-hook require explicit keyrings options.
I suppose buildd might be failing like this if dupload exited with a failure? (Which I think deserves its own bug report, to handle that
more gracefully.)
Before the upload I coordinated with Aurelien Jarno to make sure this
time around the buildds had the required config changes:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/44cb84d9f0a85d29c82e63f2e8ad1eb9b92530cc
But, I guess the instance you are reporting for might be independent
from DSA?
The default debian hosts configured in the shipped conffile contain
the required changes so if you are using a custom one, then that might
need to be adapted? Otherwise it would be nice to know what's going
wrong.
I improved the error reporting on git, and will be adding a NEWS entry because this fallout I guess was unexpected.
Hello,
this issue still persists and I assume an entry needs to be added for dports:
Hi Aurelien,
On Fri, 2025-03-14 at 13:58 +0100, Aurelien Jarno wrote:
On 2025-03-14 09:48, John Paul Adrian Glaubitz wrote:
Hello,
this issue still persists and I assume an entry needs to be added for dports:
That is not linked with debian-ports, just that you need to reconfigure
the build daemons.
You need to update the dupload.conf to point to
~buildd/.gnupg/pubring.gpg and enforce the old keyring format in ~buildd/.gnupg/gpg.conf. This is the purpose of the following puppet commits:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/d4e099680d3bd964b0837849b68728ec3ce7b52e
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/44cb84d9f0a85d29c82e63f2e8ad1eb9b92530cc
Then you also need to convert the gnupg keyring to the old format. You
can do that with the following command:
gpg --export > ~/.gnupg/pubring.gpg && mv ~/.gnupg/pubring.kbx ~/.gnupg/pubring.kbx.disabled
OK, thanks for the instructions. I will perform this transition once I have the time for touch all buildds at once and also can coordinate the change with Michael Cree for imago.
Is there any particular reason why we should stick with he old GPG format?
On 2025-03-14 09:48, John Paul Adrian Glaubitz wrote:
Hello,
this issue still persists and I assume an entry needs to be added for dports:
That is not linked with debian-ports, just that you need to reconfigure
the build daemons.
You need to update the dupload.conf to point to
~buildd/.gnupg/pubring.gpg and enforce the old keyring format in ~buildd/.gnupg/gpg.conf. This is the purpose of the following puppet
commits:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/d4e099680d3bd964b0837849b68728ec3ce7b52e
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/44cb84d9f0a85d29c82e63f2e8ad1eb9b92530cc
Then you also need to convert the gnupg keyring to the old format. You
can do that with the following command:
gpg --export > ~/.gnupg/pubring.gpg && mv ~/.gnupg/pubring.kbx ~/.gnupg/pubring.kbx.disabled
is there a way to just turn these checks off globally?
I have observed that even old versions of dupload now randomly try to
verify the signature which means I'm being spammed with failure mails.
I'm not sure why this happens despite dupload not being upgraded but
in any case I just want to turn these checks off.
I have seen that there is an environment variable called DUPLOAD_SKIP_HOOKS but there doesn't seem to be an option which I can just add to /etc/dupload.conf
or ~/.dupload.conf.
On Sat, 2025-03-01 at 14:58 +0100, Guillem Jover wrote:
I suppose buildd might be failing like this if dupload exited with a
failure? (Which I think deserves its own bug report, to handle that
more gracefully.)
Before the upload I coordinated with Aurelien Jarno to make sure this
time around the buildds had the required config changes:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/44cb84d9f0a85d29c82e63f2e8ad1eb9b92530cc
But, I guess the instance you are reporting for might be independent
from DSA?
The DSA-maintained instances are only building the packages for the release >architectures. Debian Ports packages are built on separate machines and >therefore such configuration changes would have to be applied there as well:
https://salsa.debian.org/debian-ports-team/dsa-puppet
The default debian hosts configured in the shipped conffile contain
the required changes so if you are using a custom one, then that might
need to be adapted? Otherwise it would be nice to know what's going
wrong.
Not sure what you mean with "default Debian hosts"?
I improved the error reporting on git, and will be adding a NEWS entry
because this fallout I guess was unexpected.
Yes, breaking changes should be communicated in the NEWS file and I suggest >that the required configuration changes are added to the default configuration >files of the src:sbuild package which also contains the buildd binary package.
Ah, sorry, I assumed this was all handled as part of the same
dsa-puppet repo that Aurelien fixed. The changes that were done for the
main buildds were to make sure the GnuPG pubring was in OpenPGP format instead of the GnuPG specific keybox format (which is not portable), and then those specific commits:
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/d4e099680d3bd964b0837849b68728ec3ce7b52e
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/commit/44cb84d9f0a85d29c82e63f2e8ad1eb9b92530cc
This was done in stages, introducing the new keyring support in
dupload 2.12.0, the buildd setup updated, then 2.13.0 uploaded which
then required the keyrings support. Given that the keyrings settings
are optional it could be done even with the old version, then you
should be safe to upgrade dupload.
The default debian hosts configured in the shipped conffile contain
the required changes so if you are using a custom one, then that might need to be adapted? Otherwise it would be nice to know what's going wrong.
Not sure what you mean with "default Debian hosts"?
As I was not sure how this was being used I just tried to give enough information to try to track this down. With "default Debian hosts"
I meant the stuff present in /etc/dupload.conf. But from your
explanation I assume this just needs the same treatment as the
official buildds.
I improved the error reporting on git, and will be adding a NEWS entry because this fallout I guess was unexpected.
Yes, breaking changes should be communicated in the NEWS file and I suggest that the required configuration changes are added to the default configuration
files of the src:sbuild package which also contains the buildd binary package.
I'm not sure the needed changes can be automated. In this case the
buildds need to add their own OpenPGP certificates into a keyring that dupload can use, because those certificates are not present in any of
the official keyrings from the debian-keyring package.
(I've created an MR to use the new canonical name for the upload hosts,
but that should not change anything related to this issue <https://salsa.debian.org/debian/sbuild/-/merge_requests/152>. I'll
also file a report about the Perl warnings.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:30:15 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,058 |
| Messages: | 6,416,623 |