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
