Discussion:
Bug#942087: dpkg-source and dpkg-genchanges disagree how .dsc should be named if version ends with +b1
Add Reply
Ansgar
2019-10-10 06:30:02 UTC
Reply
Permalink
Package: dpkg
Version: 1.18.25
Severity: normal

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-***@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
Guillem Jover
2019-10-10 07:50:03 UTC
Reply
Permalink
Control: reassign -1 dpkg-dev/1.18.25
Post by Ansgar
Package: dpkg
Version: 1.18.25
Severity: normal
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-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
|
+---
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.
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
Ansgar
2019-10-10 08:00:01 UTC
Reply
Permalink
Post by Guillem Jover
Post by Ansgar
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
[...]
Post by Guillem Jover
Post by Ansgar
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.
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?
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
Guillem Jover
2019-10-12 03:50:02 UTC
Reply
Permalink
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
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
[...]
Post by Guillem Jover
Post by Ansgar
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.
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?
It should generate a new *source* package, it is not binary-only.
dpkg-source does do so.
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.
Post by Ansgar
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).
- dpkg-source should refuse to generate source packages using
binNMU version numbers (that trigger the heuristic that other parts
of dpkg use), or
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. :/
Post by Ansgar
- 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.
Same as the previous point.

Thanks,
Guillem
Ansgar
2019-10-12 07:40:02 UTC
Reply
Permalink
Post by Guillem Jover
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
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
[...]
Post by Guillem Jover
Post by Ansgar
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.
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?
It should generate a new *source* package, it is not binary-only.
dpkg-source does do so.
Why should it generate a new source?
Because sourceful uploads need a new source package.
Post by Guillem Jover
This is using the version suffix
for binNMUs, using this convention for something that is not a binNMU
seems just wrong.
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
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.
(I don't care about using ".b1" instead of "+b1".)
Post by Guillem Jover
Post by Ansgar
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).
- dpkg-source should refuse to generate source packages using
binNMU version numbers (that trigger the heuristic that other parts
of dpkg use), or
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.
So using "+b1" should be supported?
Post by Guillem Jover
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. :/
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
Holger Levsen
2019-10-12 10:10:01 UTC
Reply
Permalink
Post by Ansgar
Post by Guillem Jover
Why should it generate a new source?
Because sourceful uploads need a new source package.
[...]
Post by Ansgar
Post by Guillem Jover
This is using the version suffix
for binNMUs, using this convention for something that is not a binNMU
seems just wrong.
I agree with this.
Post by Ansgar
(I don't care about using ".b1" instead of "+b1".)
So how about using .s1 or +s1 instead, to make it clear this no binNMU?

Or am I misunderstanding something?
--
cheers,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Guillem Jover
2019-10-12 13:00:02 UTC
Reply
Permalink
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
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
[...]
Post by Guillem Jover
Post by Ansgar
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.
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?
It should generate a new *source* package, it is not binary-only.
dpkg-source does do so.
Why should it generate a new source?
Because sourceful uploads need a new source package.
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?
Post by Ansgar
Post by Guillem Jover
This is using the version suffix
for binNMUs, using this convention for something that is not a binNMU
seems just wrong.
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
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.
(I don't care about using ".b1" instead of "+b1".)
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.
Post by Ansgar
Post by Guillem Jover
Post by Ansgar
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).
- dpkg-source should refuse to generate source packages using
binNMU version numbers (that trigger the heuristic that other parts
of dpkg use), or
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.
So using "+b1" should be supported?
Post by Guillem Jover
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. :/
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.
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

Loading...