Re: debuild finds no secret key after dist-upgrade (original) (raw)

Hi,

thanks and apologies for the second nudge about "-us -uc". I got an installable package of libisofs now.

Open questions are:

Long story:

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 ?

Andrey Rahmatullin wrote:

So I suppose the gpg2 migration ran before you added the key to gpg1?

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

I surely did not install or copy gpg manually. My Jessie has 1.4.18. Other origins of a copy would not be plausible.

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.

Now i have no idea at all why my secret key is suddenly gone.

WHy are you saying they are gone if secring.gpg still exists?

"Unaccessible" then. Well, new ideas pop up already.

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 ?)

So you don't even use a clean chroot?

I use a dedicated Sid VM, as was advised to me two years ago. The advice included to run apt-get "update" and "dist-upgrade" before running the debian-specific commands for packaging.

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. The size of the upgrade gives hope that everything of interest got replaced by new versions.

debuild -S -us -uc (I already told you that).

Duh. "run all build commands with -us -uc" was indeed clear enough.

This still says E: libisofs changes: orig-tarball-missing-upstream-signature libisofs_1.4.8.orig.tar.gz but debuild now finishes with exit value 0.

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 ?

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.)

gcc warns about -Wimplicit-fallthrough . Something for me with my upstream hat on. I will investigate whether it needs a patch or even a new release.

$ cme check dpkg has no complaints to report.

lintian -I -E --color never --show-overrides | less You forget --pedantic.

$ lintian -I -E --color never --show-overrides --pedantic ... I: libisofs6: spelling-error-in-binary usr/lib/x86_64-linux-gnu/libisofs.so.6.84.0 consequtive consecutive The typo is old. So lintian learned new words.

Now checking whether the library links at run time:

dpkg -i libisofs6_1.4.8-1_amd64.deb

$ xorriso -version xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project. ... libisofs in use : 1.4.8 (min. 1.4.6)

That's a success. I already began to doubt ...

Have a nice day :)

Thomas

Reply to: