Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
On Tue, 31 Dec 2013 00:25, sk...@debian.org said: The toolchain in Debian stable hasn't changed so there shouldn't be any trouble there. As it happens, I am sometimes ahead of stable ;-). Not always, though. Thanks for the long explanation. I have pushed the fix to 1.4 branch. 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 You mean the regression test suite? That is Unix only; thus running it on Windows would require some tweaking with Wine or remote execution on Windows (but we have no free ssh server for Windows). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
Hi Werner, On Sun, 22 Dec 2013 16:21:45 +0100, Werner Koch w...@gnupg.org wrote: On Sun, 22 Dec 2013 00:30, sk...@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 signature.asc Description: PGP signature
Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
On Sun, 22 Dec 2013 00:30, sk...@debian.org said: The problem is that we build gnupg for Windows in Debian so it can be used in the Windows-based installer. So we need to fix anything which causes the I know. 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. 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. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
Hi Werner, On Mon, 16 Dec 2013 20:53:11 +0100, Werner Koch w...@gnupg.org wrote: On Sat, 23 Nov 2013 15:36, sk...@debian.org said: I'm getting ready to upload a new version of gcc-mingw-w64 using gcc 4.8 and enabling libgomp. This causes the gpgv-win32 build to attempt How many regression must a hacker see before you call him a mingw developer? Yes, and how many API changes must my Emacs resist before it stops to apply the patches? The answer my friends, is lingering in your BTS. [Is Windows really worth the trouble] Indeed... The problem is that we build gnupg for Windows in Debian so it can be used in the Windows-based installer. So we need to fix anything which causes the Windows build to fail! I try to make sure I always provide a patch for 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 upstream as well. Regards, Stephen signature.asc Description: PGP signature
Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
On Sat, 23 Nov 2013 15:36, sk...@debian.org said: I'm getting ready to upload a new version of gcc-mingw-w64 using gcc 4.8 and enabling libgomp. This causes the gpgv-win32 build to attempt How many regression must a hacker see before you call him a mingw developer? Yes, and how many API changes must my Emacs resist before it stops to apply the patches? The answer my friends, is lingering in your BTS. [Is Windows really worth the trouble] Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730271: [Pkg-gnupg-maint] Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
Hi Stephen, On Sat, November 23, 2013 15:36, Stephen Kitt wrote: I'm getting ready to upload a new version of gcc-mingw-w64 using gcc 4.8 and enabling libgomp. This causes the gpgv-win32 build to attempt to build mpicalc.exe, which fails because the assembly code in libmpi doesn't use underscores as it should when targeting Windows. The attached patch fixes this; I'll be forwarding it upstream too. Thanks. Did this forwarding happen? I couldn't find it. Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730271: [Pkg-gnupg-maint] Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
Hi Thijs, On Thu, 12 Dec 2013 20:44:22 +0100, Thijs Kinkhorst th...@debian.org wrote: On Sat, November 23, 2013 15:36, Stephen Kitt wrote: I'm getting ready to upload a new version of gcc-mingw-w64 using gcc 4.8 and enabling libgomp. This causes the gpgv-win32 build to attempt to build mpicalc.exe, which fails because the assembly code in libmpi doesn't use underscores as it should when targeting Windows. The attached patch fixes this; I'll be forwarding it upstream too. Thanks. Did this forwarding happen? I couldn't find it. Oops, it slipped my mind, I've just sent it to gnupg-devel: http://lists.gnupg.org/pipermail/gnupg-devel/2013-December/028093.html Regards, Stephen signature.asc Description: PGP signature
Bug#730271: gnupg: Future FTBFS: gnupg attempts to build mpi on Windows and fails
Package: gnupg
Version: 1.4.15-1.1
Severity: normal
Tags: patch
Dear Maintainer,
I'm getting ready to upload a new version of gcc-mingw-w64 using gcc
4.8 and enabling libgomp. This causes the gpgv-win32 build to attempt
to build mpicalc.exe, which fails because the assembly code in libmpi
doesn't use underscores as it should when targeting Windows.
The attached patch fixes this; I'll be forwarding it upstream too.
Regards,
Stephen
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gnupg depends on:
ii gpgv 1.4.15-1.1
ii libbz2-1.01.0.6-5
ii libc6 2.17-93
ii libreadline6 6.2+dfsg-0.1
ii libusb-0.1-4 2:0.1.12-23.2
ii zlib1g1:1.2.8.dfsg-1
Versions of packages gnupg recommends:
ii gnupg-curl 1.4.15-1.1
ii libldap-2.4-2 2.4.31-1+nmu2+b1
Versions of packages gnupg suggests:
pn gnupg-doc none
ii imagemagick 8:6.7.7.10-6
ii libpcsclite1 1.8.10-1
-- no debconf information
Subject: Use underscores for linking on all mingw32 targets
From: Stephen Kitt sk...@debian.org
All MinGW targets require underscores when linking. This patch fixes
acinclude.m4 and the resulting configure so they don't limit the use
of underscores to the old mingw32msvc targets.
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -692,7 +692,7 @@
AC_DEFUN([GNUPG_SYS_SYMBOL_UNDERSCORE],
[tmp_do_check=no
case ${host} in
-*-mingw32msvc*)
+*-mingw32*)
ac_cv_sys_symbol_underscore=yes
;;
i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp)
--- a/configure
+++ b/configure
@@ -7314,7 +7314,7 @@
tmp_do_check=no
case ${host} in
-*-mingw32msvc*)
+*-mingw32*)
ac_cv_sys_symbol_underscore=yes
;;
i386-emx-os2 | i345686-pc-os2*emx | i386-pc-msdosdjgpp)
