On Fri, Sep 15, 2017 at 09:29:16PM +0200, Thomas Schmitt wrote: > - How to bring the original tarball's .sig file into the packaging ? Convert it to .asc and read dpkg-source(1). > - What happened to gpg so that it does not see my secret key ? Your .gnupg/private-keys-v1.d is empty and gpg doesn't read secring.gpg. > I booted up my backup of Sid before the dist-upgrade and verified that > the directory > .gnupg/private-keys-v1.d > is already empty but that > gpg --list-secret-keys > lists the GPG key which i also use for signing my upstream tarballs: > sec 1024D/ABC0A854 2010-03-30 > > Can it be too old for the new gpg binary ? Have you read https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring which you linked previously? > It is more confusing. The old Sid has file > ~/.gnupg/.gpg-v21-migrated > but its gpg --version says > gpg (GnuPG) 1.4.20 > It was probably upgraded a year ago: > $ ls -lc /usr/bin/gpg > -rwxr-xr-x 1 root root 1008632 Jul 3 2016 /usr/bin/gpg Check /usr/bin/gpg2 or whatever it was called in the old gnupg2 package? > The fact that it is not really >=2.1 but already has the marker file > would be a good explanation why the upgrade today did not change the > key storage method to the new one. That's what I've said. > > I guess you'll need to do the > > migration again (try deleting .gpg-v21-migrated?) > > And then > apt-get remove gpg > apt-get install gpg > ? > (With a backup of the .gnupg directory on the shelf ?) Surely you understand that installing or removing packages cannot have any effect on user files? And I guess the migration is done on the gpg invocation. > > So you don't even use a clean chroot? > > I use a dedicated Sid VM, as was advised to me two years ago. So you don't. This is a very bad idea, please fix your workflow ASAP. > In general, my libraries have few dependencies. So the risk to have > unreproducible success by local modifications is low. > The Sid is a vanilla Debian, even with Gnome and other things which > i got by asking for a default installation. Sure. So it's quite a long way from a clean minimal chroot we require our packages to be built in. And as long as you don't understand all the differences between that and your system please don't use custom VMs with GNOME or whatever to build your packages. Use pbuilder or sbuild. > The lintian error message is new to me. Where would i register or put > my .sig file on the level of debian/control or debian/rules ? You've already got an answer to that in dpkg-source(1). There is nothing to be changed in debian/control or debian/rules. > Next step: > $ debuild -b -us -uc > ... > W: libisofs-dbg: debug-package-should-be-priority-extra libisofs-dbg > > I just changed that because of policy 2.5. I assume this overrules lintian. > (I really try to obey. Even when the orders contradict.) Yes, the policy can be newer than lintian. Though you should just switch to https://wiki.debian.org/AutomaticDebugPackages. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature