Re: debuild finds no secret key after dist-upgrade

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

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

Open questions are:

- How to bring the original tarball's .sig file into the packaging ?
  (dpkg-source(1) did not give me enlightenment yet. Possibly because
   it acts on a lower level than debuild and the ./debian files which
   i have learned to maintain.)

- What happened to gpg so that it does not see my secret key ?

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