[Pkg-gnupg-maint] packaging dirmngr from 2.1.0

[Daniel Kahn Gillmor]

Hi Chuck--

On 10/07/2014 03:53 PM, C Peters wrote:

> I'll try it out tomorrow, that is if my incompetency at git and other
> distractions don't get in the way. ;  I really do need to learn how to
> use git, and bzr, and get a better workflow going.  Any suggestions for
> getting up to speed with git?

https://wiki.debian.org/Teams/GnuPG

http://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028769.html

> The build depends should have a minor adjustment, gnupg2 needs
> libgpg-error-dev >=1.15 and not 1.13.

thanks, i've just pushed a series of changes to the debian experimental
branch which include that update.

The head of the gnupg2 experimental branch is now at:

d3a356ee3cf09bf7f0e152ccdf3b07625fc292b3

And i'm feeling OK with it as far as an experimental package goes.

> I built packages for Ubuntu 14,04 and they are on Launchpad, but I
> should probably hold off telling anyone about them until you have
> uploaded to experimental and I merge the changes.

how are you doing your packaging work?  I'd be happy to collaborate.  If
you are using git, it should be relatively easy for us to share
packaging changesets.

If you're not using git, can i encourage you to do so? :)

>  One thing I
> enabled was gpgtar and used help2man to make a man page.

Again, patches welcome :)  but i confess i'm not happy with the help2man
output for these gnupg tools.  help2man seems to muddle the synopsis
with the tool description for both kbxutil.1 and gpgtar.1 when i try to
make them.

interestingly, it looks like tools/gpg-zip is a simple script which
provides the same interface as gpgtar, and *does* have documentation in
doc/gpg-zip.1 (built from doc/tools.texi).  Is there a good reason to
ship gpgtar instead of gpg-zip?  currently, we ship neither in gnupg2,
but we ship the script gpg-zip in gnupg (1.4.18), and it appears to be
byte-for-byte identical except for the version number with the gpg-zip
from 2.1.0.

Another utility that might be worth including in a future release:

 * g13 (encrypted file system container, Werner suggested back in 2012
that this wasn't really ready for wider distribution)


Notes: after a build, i did the following to look for other possible
binaries that we aren't shipping:

diff -u <(cat debian/*.install | sort) \
        <(find debian/tmp -type f -perm -u+x | sort)

and a similar check for manpages:

 diff -u <(cat debian/*.manpages | sort) \
         <(find debian/tmp | grep '\.[0-9]' | sort)

> I also
> had to disable the genkey1024.test test because the build was timing
> out on Launchpad.  I suspect it is an issue with entropy.  Do you have
> any issues like that using Debian's build systems?

I'm not seeing that problem on the debian buildds for the 2.0.x branch.
 I haven't submitted any of the 2.1.x branch to the debian buildd's
because i'm hoping to get feedback from folks here before sending an
experimental package to the archive, though maybe i shouldn't wait much
longer.

> I broke RTMP, an adobe library, in the curl packages to work around
> the dependency issue with libgnutls and that breaks gnash, a GPL flash
> player and I am not sure what else yet.  A big part of the problem is
> Debian is using the old GnuTLS for libgnutls-dev and some packages
> haven't made the change to libgnutls28-dev for the 3.2 branch.

I can't follow this paragraph, sorry.  perhaps i need more sleep :)

debian jessie and sid already ship gnutls28-dev, which is what's needed
for the build of 2.1.0, and libcurl4-gnutls-dev already depends on it.
I don't know how RTMP is connected to this at all!

	--dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20141008/1a9bb597/attachment-0001.sig>