Bug#1125005: reprepro fails to parse .dsc missing "Priority" field (now redundant per Debian Policy)
confirmed again with a webkit backport to trixie that had the Standards-Version updated to 4.7.3 (and Priority field removed). -- g. Marc GPG: 827C FD74 BA46 8152 A041 F3A0 7A6A 4F17 5995 A65B
Bug#1125005: reprepro fails to parse .dsc missing "Priority" field (now redundant per Debian Policy)
> 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.) 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. -- g. Marc GPG: 827C FD74 BA46 8152 A041 F3A0 7A6A 4F17 5995 A65B
Bug#1125005: reprepro fails to parse .dsc missing "Priority" field (now redundant per Debian Policy)
Hi! On Thu, 2026-01-08 at 10:11:59 +0100, Marc Leeman wrote: > Package: reprepro > Version: 5.4.6+really5.3.2-1 > Severity: normal 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.) > 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 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.) > Observations: > * 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. As mentioned above, the field nor the values should be absent from the generated .dsc, nor .changes, nor .deb files. > mini-buildd has a bug [1] that requests checking for that field, but it > seems to be superseded by the debian policy change [2] 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 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. 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. > * 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. 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
Bug#1125005: reprepro fails to parse .dsc missing "Priority" field (now redundant per Debian Policy)
Package: reprepro Version: 5.4.6+really5.3.2-1 Severity: normal 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 -- System Information: Debian Release: 13.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.25-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reprepro depends on: ii libarchive13t64 3.7.4-4 ii libbz2-1.0 1.0.8-6 ii libc62.41-12 ii libdb5.3t64 5.3.28+dfsg2-9 ii libgpg-error01.51-4 ii libgpgme11t641.24.2-3 ii liblzma5 5.8.1-1 ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1 ii zstd 1.5.7+dfsg-1 Versions of packages reprepro recommends: ii apt 3.0.3 Versions of packages reprepro suggests: ii gpg-agent2.4.7-21+b3 pn inoticoming ii lzip 1.25-3 ii pinentry-curses 1.3.1-2 -- no debconf information -- g. Marc GPG: 827C FD74 BA46 8152 A041 F3A0 7A6A 4F17 5995 A65B
