[Pkg-gnupg-maint] Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails

[Stephen Kitt]

Hi Werner,

On Sun, 22 Dec 2013 16:21:45 +0100, Werner Koch <wk at gnupg.org> wrote:
> On Sun, 22 Dec 2013 00:30, skitt at debian.org said:
> > Windows-specific bugs in Debian packages, given that it's reasonable for
> > maintainers (and upstreams) to not care about that platform. In this
> > particular case the fix is easy enough, so I was hoping you would merge it
> 
> The thing is that for 13 years I am releasing Windows versions with each
> GnuPG 1.x release.  I also did this with the latest 1.4.16 and
> experienced no problem.  Well, I may have not updated the toolchain for
> several months which is the reason that I have not run into this bug.

The toolchain in Debian stable hasn't changed so there shouldn't be any
trouble there.

> So, if I now update the toolchain I will run into this bug push a fix
> for it and if hopefully not too early again, I do another release and
> find out that the toolchain has another bug and the whole thing starts
> again.  The problem is the instability of mingw stuff - it might be
> worth to think about maintaining a stable (ie. all bugs known) toolchain
> package and a bleeding-edge package.  Windows is indeed important and
> we somehow need to find a way to isolate us from these regressions.
> 
> This particular case might not be too troublesome but we have seen
> stealth bugs in the past which took long to be detected (unsigned long
> printf format) and for years is was not easy to figure out whether a
> workaround was required or not.

The target for the changes which cause this bug is the next stable release of
Debian, not the current one. So from my point of view it's reasonable to have
toolchain changes from one major release of Debian to the next; I am
nevertheless going to the trouble of making sure that I identify the impact
on all the downstream users I know of (other Debian packages, but also
projects such as vlc, ekiga, and now gpg4win) and when necessary help these
users cope with the changes.

MinGW-w64 is changing, but for a while now all the changes I've seen have
been improvements, and there are enough users for bugs to be caught before
they make their way into a stable release; for instance Fedora run regular
full-archive rebuilds on all their supported Windows packages, and the
results of those rebuilds are fed directly to the MinGW-w64 developers. This
particular bug is caused by an improvement to the toolchain, not by a
regression in MinGW-64 or anywhere else: in Debian unstable, gcc-mingw-w64 now
includes libgomp, which causes the gnupg build to fail because of a bug in
libgcrypt (well, an outdated triplet check) in some code which wasn't used up
till now.

Incidentally when necessary I do maintain a stable toolchain alongside an
unstable toolchain; the latter goes to experimental, where interested users
can test it (and there are interested users). The packages that target Debian
stable following the normal release process are indeed stable, and once a
particular Debian version is released they stay that way.

Would it be helpful at all if I got the gnupg tests running on Windows
targets? I believe that may be more fruitful in the long run than debating
the merits of various packaging approaches... In particular it would
hopefully avoid the introduction of new stealth bugs such as the one you
mention.

Regards,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20131231/da7d2dd3/attachment.sig>