For the Secure Boot support in Debian we automatically generate source packages that include the signatures (linux-signed-*) from files shipped in linux-image-amd64-signed-template below /usr/share/code-signing/linux-image-amd64-signed-template/source-template (plus detached signatures). With the first binNMU the changelog used 5.2.17+1+b1 as the version and this caused disagreement between different parts of dpkg. dpkg-source generates linux-signed-amd64_5.2.17+1+b1.dsc, but dpkg-genchanges strips the trailing +b1 from the version: +--- | [dpkg-source -b .] | dpkg-source: warning: unknown information field 'Rules-Requires-Root' in input data in general section of control info file | dpkg-source: info: using source format '3.0 (native)' | dpkg-source: info: building linux-signed-amd64 in linux-signed-amd64_5.2.17+1+b1.tar.xz | dpkg-source: info: building linux-signed-amd64 in linux-signed-amd64_5.2.17+1+b1.dsc | dpkg-genchanges: warning: unknown information field 'Rules-Requires-Root' in input data in general section of control info file | dpkg-genchanges: error: cannot read ../linux-signed-amd64_5.2.17+1.dsc: No such file or directory | Something went wrong, you can inspect the build to figure out what. The temporary directory is /tmp/codesignzg_o_do4 | Command '['dpkg-genchanges', '-S', '-DDistribution=sid', '-UCloses', '-O../linux-signed-amd64_5.2.17+1+b1_source.changes']' returned non-zero exit status 2 +--- The first changelog entry is +--- | linux-signed-amd64 (5.2.17+1+b1) sid; urgency=low | | * Sign kernel from linux 5.2.17-1+b1 | | * Binary-only non-maintainer upload for amd64; no source changes. | * build against perl 5.30.0 | | -- amd64 / i386 Build Daemon (x86-ubc-01) <buildd_amd64-x86-ubc-01@buildd.debian.org> Sun, 06 Oct 2019 15:07:42 +0000 +--- I'll suggest to work around this by mangling the version a bit more and use .b1 instead of +b1, but the disagreement seems to be a bug in dpkg. Ansgar
Control: reassign -1 dpkg-dev/1.18.25 It looks to me that the problem might actually be the missing binary-only=yes key/value in the changelog header though, which the original should have? Could you check whether that would completely fix this? Thanks, Guillem
Guillem Jover writes: [...] It should generate a new *source* package, it is not binary-only. dpkg-source does do so. But dpkg-genchanges seems to (still) use the heuristic stripping the +bX from versions instead of using the binary-only key (which is not present here). I think either: - dpkg-source should refuse to generate source packages using binNMU version numbers (that trigger the heuristic that other parts of dpkg use), or - dpkg-genchanges should be able to generate changes files for source packages that use versions ending in +bX (provided no binary-only is set); i.e. stop using heuristics and instead rely on the binary-only key. Ansgar
HI Guillaume - I dont' think this is for me....will call you in am DENISE OSHESKY | Systems Analyst III IT-Technical Support P.O. Box 3590, Honolulu, HI. 96811 Phone: (808) 544-5607 | Cell: (808) 954-5410 | Fax: (808) 532-4846 Denise.Oshesky@centralpacificbank.com | http://www.centralpacificbank.com It looks to me that the problem might actually be the missing binary-only=yes key/value in the changelog header though, which the original should have? Could you check whether that would completely fix this? Thanks, Guillem
Why should it generate a new source? This is using the version suffix for binNMUs, using this convention for something that is not a binNMU seems just wrong. This would still point at a problem with the version used. I'd rather stop using the heuristic because we have metadata for this, and they are Debian-centric things. But if the alernative is to allow packages that break the versioning convention for no apparent good reason, then I guess I might need to move this as a vendor-specific logic, and apply it everywhere. :/ Same as the previous point. Thanks, Guillem
Guillem Jover writes: Because sourceful uploads need a new source package. That's why I wrote the following: (I don't care about using ".b1" instead of "+b1".) So using "+b1" should be supported? So using "+b1" should not be supported? I reported the bug because dpkg seems undecided if it should support "+b1" or not. Whatever it decides, it should probably be consistent between differnt parts of itself. Ansgar
[...] I agree with this. So how about using .s1 or +s1 instead, to make it clear this no binNMU? Or am I misunderstanding something?------------------------------------------------------------------------------- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
That's kind of tautological no? :) Why does it need to be a sourceful upload? I'm probably missing something obvious, but when I checked yesterday the linux-signed-* source was just packaging bits, generated from the templates in the linux source, which I'm assuming do not change (except for its changelog) when a binNMU is triggered for the linux package? And then matching the type of upload of its parent source seems would make the most sense here? Ok, let me clarify the way I see this report. I have to agree using «.bN» would still seem wrong to me, as that's just working around the underlaying problem when reacting to a binNMU from the parent package with something in the child package which is a binNMU but not really. The combination of the binNMU versioning being used and the sourceful uploads is undefined behavior, and as such dpkg-dev fails in an undefined way. Should dpkg-dev fail more consistently and in a better way? Sure, but that still does not get rid of the problem that the versioning used here seems just wrong. It supportes +bN alright, as long as it is used for cases it was designed for. :) So for this bug, as I mentioned above, I guess I might end up making the +bN heuristic Debian-vendor specific, and apply it consistently, as I assume that if I removed the heuristic that would interpreted literally, as the case presented being fine. But ideally the heuristic should not be needed at all. My point is thar regardless of dpkg keeping and extending the heuristic or completely getting rid of it, the usage you present, w/ or w/o mangling seems still wrong? Thanks, Guillem
Hi, We are adding the git commit to our alpha and beta packages and this issue appears when the git commit hash start with +b dpkg-deb: construction du paquet « bc-flexisip-account-manager » dans « ../bc-flexisip-account-manager_2.0.0-0.beta.23+b427810_amd64.deb ». dpkg-genbuildinfo -O../bc-flexisip-account-manager_2.0.0-0.beta.23+b427810_amd64.buildinfo dpkg-genchanges -O../bc-flexisip-account-manager_2.0.0-0.beta.23+b427810_amd64.changes dpkg-genchanges: erreur: impossible de lire ../bc-flexisip-account-manager_2.0.0-0.beta.23.dsc: No such file or directory dpkg-buildpackage: erreur: le sous-processus dpkg-genchanges -O../bc-flexisip-account-manager_2.0.0-0.beta.23+b427810_amd64.changes a retourné l’état de sortie 255 Changing the commit hash works but solving this issue would prevent some failing pipelines on our side. Thanks for the awesome work :) ! Regards, edhelas
Hi! Given that +bN has (had) magic semantics, I'd encourage you to use a different versioning scheme. As an example uscan in its mode=git, when taking code from HEAD with no tags it will use the following pattern: $ git log --date=format:%Y%m%d --pretty=0.0~git%cd.%h Although that might not work great if you need to package multiple releases in a day, but prefixing the commit hash with something like git is probably more descriptive anyway. Or where «git describe» prefixes the commit hash with «g». You might also want to consider using «~» for pre-release stuff to sort earlier and avoid taking over the actual final version number. Thanks, Guillem