#1028523 dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges

#1028523#5
Date:
2023-01-12 10:29:53 UTC
From:
To:
I got a linitian error for my package (linuxinfo) that the upstream
signature is missing and should be put alongside the .orig.tar.xz
during the build.

This worked, the signature was included in the .changes file. However,
it is not included in the .dsc file.

No I need to inform dpkg-buildpackage how to add this, however, I
cannot find any option to do so.

(As a hot fix I can add the signature manually to the .dsc file)

#1028523#10
Date:
2023-01-13 20:05:21 UTC
From:
To:
Hi Helge,

Am 12.01.2023 um 11:29 schrieb Helge Kreutzmann:

I cannot reproduce this.  If I provide the upstream signature as
linuxinfo_4.1.2.orig.tar.xz.asc, it ends up in both the .changes and the
.dsc files.  The .changes file for linuxinfo 4.1.2-1 which you uploaded[1]
does not contain it.

Neither can I, but I do not really see the need for it.

Cheers,
       Sven


1. https://tracker.debian.org/news/1407992/accepted-linuxinfo-412-1-source-into-unstable/

#1028523#15
Date:
2023-01-13 20:16:33 UTC
From:
To:
Hello Sven,

Since we use source only uploads, I run:
dpkg-buildpackage --changes-option=-S

And I screwed up linuxinfo 4.1.2-1, thus I decided to also include the
signature and tried to do 4.1.2-2 (which failed) and manually added it
in 4.1.2-3 (which is now in the archive).

For now, I noticed down to add the asc file manually, but I don't
think this is a desirable solution.

Greetings

         Helge

#1028523#20
Date:
2023-01-13 20:36:47 UTC
From:
To:
Hello Helge,

Am 13.01.2023 um 21:16 schrieb Helge Kreutzmann:

I was a bit lazier and ran "dpkg-buildpackage -S", not even bothering to
build binaries.  But it does not really matter, as ultimately every tool
eventually runs "dpkg-source -b ." to create the .dsc file.  Here is
what I got with your command:

,----
| $ LANG=C dpkg-buildpackage -uc -us --changes-option=-S
| dpkg-buildpackage: info: source package linuxinfo
| dpkg-buildpackage: info: source version 4.1.2-3
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Helge Kreutzmann <debian@helgefjell.de>
|  dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
|  debian/rules clean
| dh clean
|    dh_clean
|  dpkg-source -b .
| dpkg-source: info: using source format '3.0 (quilt)'
| dpkg-source: info: verifying ./linuxinfo_4.1.2.orig.tar.xz.asc
| dpkg-source: info: building linuxinfo using existing ./linuxinfo_4.1.2.orig.tar.xz
| dpkg-source: info: building linuxinfo using existing ./linuxinfo_4.1.2.orig.tar.xz.asc
| dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.debian.tar.xz
| dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.dsc
| [...]
`----

As you can see, dpkg-source included the orig.tar.xz.asc file.

Can you please send a build log?

Cheers,
       Sven

#1028523#25
Date:
2023-01-13 20:50:58 UTC
From:
To:
Hello Sven,

Please find it attached.

As you can see, "linuxinfo_4.1.2.orig.tar.xz.asc" is contained in the
.dsc file, but not in the .changes file.

When I uploaded this (with -2) the archive rejected this.

I manually edited the .changes to add
"linuxinfo_4.1.2.orig.tar.xz.asc", and this worked.

Greetings

           Helge

#1028523#30
Date:
2023-01-13 21:14:24 UTC
From:
To:
Am 13.01.2023 um 21:50 schrieb Helge Kreutzmann:

This is the opposite of what you wrote in the original report (where the
.asc file was in the changes file and not in the .dsc), and is in fact
normal as you did not include the upstream sources (the default if
debian/changelog indicates that this is not the first debian revision).

Yes, because your .dsc file referenced the .asc file, but the changes
file did not include it, nor was the file already in the archive.

I guess could also have passed "-sa" to dpkg-buildpackage to include the
full sources again, but whatever worked for you.

Still I am unable to reproduce your original problem.

Cheers,
       Sven

#1028523#35
Date:
2023-01-15 07:41:39 UTC
From:
To:
Hello Sven,
sorry for my slow answer.

This was a mistake of mine, I probably failed to write it correctly. I
apologize.

So I understand, if I had included the full sources, then the .asc file
would have been included as well? And does this work? - I remember that
in the past I was told that the sources are already in the archive,
and hence cannot be uploaded again (but I might be wrong on this).

Then this two things should be documented:

1. .asc files are always (automatically) included if the upstream
   sources are included (either by default or by -sa)

2. .asc files cannot be included on their own, but rather require the
   corresponding upstream sources (which would make sense, indeed).
   [1]

Greetings

         Helge

  [1] If I'm right that the upstream source can only be uploaded once,
  then possibly a sentence that .asc files should only be included at
  Debian revision 1.

#1028523#40
Date:
2023-01-15 09:03:33 UTC
From:
To:
Hi,

There was a project decision to adopt usrmerge so no other tool warns
about it. dpkg's maintainer is unhappy with the project decision and
included this warning which sadly unsettles users.

Ansgar

#1028523#45
Date:
2023-01-15 09:07:08 UTC
From:
To:
Hello Ansgar,

Thanks for the information.

Hopefully this can be resolved without (eventually) reinstalling.

Greetings

               Helge

#1028523#50
Date:
2023-01-15 10:30:25 UTC
From:
To:
Hi Helge,

Am 15.01.2023 um 08:41 schrieb Helge Kreutzmann:

Thanks, now this makes sense.

Yes.

AFAIK you can include the upstream tarball again, as long as it is
identical to what is already in the archive - which is required anyway,
otherwise the hashsums in the .dsc would not match and the upload
rejected.

As long as they are present, yes.

Yes, there does not seem to be an option to only include the .asc file,
you need to edit the .changes file after the build as you did.

Cheers,
       Sven

#1028523#55
Date:
2023-01-15 16:19:41 UTC
From:
To:
Hmm, will look how to try to clarify this.

I started to add support for such option some time ago, but it seems I
didn't go further:

https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=pu/dpkg-genchanges-include-asc

Perhaps because then the semantics could be rather strange. Or maybe
focused the energy into better diagnostics both in dpkg and lintian. Or
maybe because it looked like adding instead a dpkg-modchanges would be
better. Cannot really recall why though. :)

I'll try to see whether I can come up with an option that is not too
confusing.

Thanks,
Guillem