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
