Dear Maintainer,
I am encountering a regression or an outdated strictness in reprepro
when processing source packages built for Debian Trixie/unstable.
Starting recently, Lintian now tags Priority:
optional in the Source stanza as redundant (see:
redundant-priority-optional-field). Consequently, some packages
(specifically libnice) have begun dropping this field from their
debian/control source headers.
I am using reprepro as a backend for a mini-buildd system and when the
daemon has built the packages, it uploads them to the incoming queue to
be included in the repository managed by reprepro.
Problem: When reprepro processes a .dsc file that lacks an explicit
Priority field in the metadata block, it fails with the following errors:
Plaintext
```
E: ? reprepro.. (stderr): Could not check validity of signature with
'[FINGERPRINT]' in 'package.dsc' as public key missing!
E: ? reprepro.. (stderr): No priority for 'package', skipping.
```
Observations:
* The "public key missing" error is a red herring; the key is present
in the keyring, but reprepro appears to abort metadata extraction
when the Priority field is missing, leading to a failure in the
signature-to-package association logic.
* The same package, when signed with the same key but containing
Priority: optional, is accepted without issue.
* As Debian moves toward making this field optional/redundant for
Source stanzas, reprepro should be updated to provide a sensible
default (likely optional) if the field is absent in the .dsc, rather
than aborting the import.
Steps to reproduce:
* Build a source package where the Source stanza in debian/control
lacks a Priority field.
* Attempt to include this package in a repository using reprepro
include or via mini-buildd.
* reprepro will reject the package with "No priority for [package],
skipping."
mini-buildd has a bug [1] that requests checking for that field, but it
seems to be superseded by the debian policy change [2]
The Policy says it's not strictly mandatory for the .dsc, but reprepro uses a
stricter internal v alidation schema. When reprepro encounters a source
package without a priority, it doesn't know what to put in the Priority: field
of the Sources index it is generating, so it crashes.
* Field Definition: Debian Policy 5.6.7 (Priority)
* Source Package Control File (.dsc): Debian Policy 5.4
* Binary Package Control File: Debian Policy 5.3
Please consider updating the parser to treat a missing Priority field
in the Source block as optional to align with the current Debian Policy
transition.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106857
[2] https://lintian.debian.org/tags/redundant-priority-optional-field.html
Hi! I think this is a duplicate of #1110733, you might want to merge them. (And IMO this does not look like a bug in reprepro, so should probably be closed, or perhaps the error message be improved to explain the actual problem.) With dpkg-dev >= 1.22.13 in trixie/forky/sid, all generated artifacts should contain a filled priority value. So I'm assuming you are trying to build new sources packages in an old environment? (Which to me would indicate a problem with the build setup, and not with reprepro.) As mentioned above, the field nor the values should be absent from the generated .dsc, nor .changes, nor .deb files. I think the report still makes sense, as long as it is not intended to make mini-buildd check debian/control, instead of the expected artifacts being generated. The .dsc is not supposed to have an actual Priority field, it conveys that information in the Package-List, and the priority value is mandatory, although it could previously be "-" (with older dpkg-genchanges version) if there was no value in debian/control. IMO, reprepro seems fine as it is, because packages built with older tooling that end up with no priority are missing information that is expected by various tools. Thanks, Guillem
Thanks. Correct, it was a backport of libnice 0.1.23 to trixie, but that one has dpkg-dev 1.22.21. I'll have another look at it and re-trigger the port to double check the logs with this information. Maybe re-generating the chroots is in order here.
I had a look at the linked bug, there it generated the source package on a bookworm system. In my case, that would mean the system that does the upload *to* the mini-buildd builder. I am generating the source package on a sid machine with sbuild. The dpkg-dev packages are up to date (1.22.21), outside the chroot even 1.23.3 W: libnice source: orig-tarball-missing-upstream-signature libnice_0.1.23.orig.tar.gz W: libnice source: recommended-field (in section for source) Priority [debian/control:1]
Sorry,
reply/reply-all confusion, forwarding feedback.
I reverted the Priority field commit in libnice, it still triggers the
GPG key (i.e. parsing) error:
```
Jan 13 09:28:39 debian-builder02 schroot[742371]:
[mini-buildd-bookworm-amd64-5e1490b1-896d-4fb6-af22-dfd7c324f993
chroot] (mini-buildd->root) Running command: "apt-get --purge -o
DPkg::Options::=--force-confold -o
DPkg::Options::=--refuse-remove-essential -o
APT::Install-Recommends=false -o Dpkg::Use-Pty=false -q -y install
aptitude"
Jan 13 09:28:40 debian-builder02 schroot[742369]:
pam_unix(schroot:session): session closed for user root
Jan 13 09:28:40 debian-builder02 schroot[742374]:
pam_unix(schroot:session): session opened for user root(uid=0) by
(uid=113)
Jan 13 09:28:40 debian-builder02 schroot[742376]:
[mini-buildd-bookworm-amd64-5e1490b1-896d-4fb6-af22-dfd7c324f993
chroot] (mini-buildd->root) Running command: "aptitude -y
--without-recommends -o Dpkg::Options::=--force-confold -o
Aptitude::CmdLine::Ignore-Trust-Violations=false -o
Aptitude::ProblemResolver::StepScore=100 -o
Aptitude::ProblemResolver::SolutionCost=safety, priority,
non-default-versions -o
Aptitude::ProblemResolver::Hints::KeepDummy=reject
sbuild-build-depends-lintian-dummy :UNINST -o
Aptitude::ProblemResolver::Keep-All-Level=55000 -o
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install
sbuild-build-depends-lintian-dummy:amd64"
Jan 13 09:28:44 debian-builder02 mini-buildd[46550]: I: Finished
thread <Build(libnice/0.1.23-1~televic13+4/20260113:082243:560816/amd64,
started 140341940315840)> [mini_buildd.threads(threads.py:64)]
Jan 13 09:28:44 debian-builder02 mini-buildd[46550]: I: FTP:
'libnice_0.1.23-1~televic13+4_mini-buildd-buildresult_amd64.changes'
uploaded to 'ftp://debian-builder02.televic.com:8067'.
[mini_buildd.changes(changes.py:81)]
Jan 13 09:28:48 debian-builder02 mini-buildd[46550]: E: ? reprepro..
(stderr): Could not check validity of signature with
'827CFD74BA468152A041F3A07A6A4F175995A65B' in
'/var/lib/mini-buildd/var/events/libnice/0.1.23-1~televic13+4/20260113:082243:560816/source
amd64 all/libnice_0.1.23-1~televic13+4.dsc' as public key missing!
[mini_buildd.call(call.py:104)]
Jan 13 09:28:48 debian-builder02 mini-buildd[46550]: E: ? reprepro..
(stderr): No priority for 'libnice', skipping.
[mini_buildd.call(call.py:104)]
Jan 13 09:28:48 debian-builder02 mini-buildd[46550]: E: ? reprepro..
(stderr): There have been errors! [mini_buildd.call(call.py:104)]
Jan 13 09:29:08 debian-builder02 mini-buildd[46550]: I: API call
'status' by user 'AnonymousUser' from '::ffff:127.0.0.1'
[mini_buildd.views(views.py:303)]
```
The tools on the (build) host (though not relevant here) are:
```
tlv@debian-builder02:~$ dpkg -l |grep reprepro
ii reprepro 5.4.6+really5.3.2-1
amd64 Debian package repository producer
tlv@debian-builder02:~$ dpkg -l |grep dpkg-dev
ii dpkg-dev 1.22.21
all Debian package development tools
```
attached is also the build log, which also contains the correct
tooling dpkg-dev I think.
confirmed again with a webkit backport to trixie that had the Standards-Version updated to 4.7.3 (and Priority field removed).