Bug#680455: pptp-linux: pptp stops receiving packets when bandwidth spike

[Michael Hudson-Doyle]

Package: pptp-linux
Version: 1.7.2-6
Severity: normal

Dear Maintainer,

Hi.  I am reporting this bug in Debian as a favour to some Ubuntu-using
friends.  While I work for Canonical I do not work on Ubuntu directly and
so apologies if I'm doing this wrong :-)

The bug is https://bugs.launchpad.net/ubuntu/+source/pptp-linux/+bug/681617
and the links therein indicate that upstream does not care any more.  My
friend indicated that the patch helped their problem, so it seems reasonable
to ask for the patch to be included in Debian.  I'll attach the debdiff
I used.

Cheers,
mwh

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-26-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pptp-linux depends on:
ii  binutils  2.22-6ubuntu1
ii  libc6 2.15-0ubuntu10
ii  ppp   2.4.5-5ubuntu1

pptp-linux recommends no packages.

pptp-linux suggests no packages.

-- no debconf information
diff -u pptp-linux-1.7.2/pptp.c pptp-linux-1.7.2/pptp.c
--- pptp-linux-1.7.2/pptp.c
+++ pptp-linux-1.7.2/pptp.c
@@ -79,6 +79,7 @@
 int disable_buffer = 0;
 int test_type = 0;
 int test_rate = 100;
+int missing_window = MISSING_WINDOW;
 
 struct in_addr get_ip_address(char *name);
 int open_callmgr(struct in_addr inetaddr, char *phonenr, int argc,char **argv,char **envp, int pty_fd, int gre_fd);
@@ -116,13 +117,14 @@
   --timeout secs	Time to wait for reordered packets (0.01 to 10 secs)\n
 	  --nobuffer		Disable packet buffering and reordering completely\n
 	  --idle-wait		Time to wait before sending echo request\n
-  --max-echo-wait		Time to wait before giving up on lack of reply\n
+  --max-echo-wait   Time to wait before giving up on lack of reply\n
   --logstring name	Use name instead of 'anon' in syslog messages\n
   --localbind addr	Bind to specified IP address instead of wildcard\n
   --loglevel level	Sets the debugging level (0=low, 1=default, 2=high)\n
   --test-type type	Damage the packet stream by reordering\n
-  --test-rate n		Do the test every n packets\n,
-
+  --test-rate n   yDo the test every n packets\n
+  --missing-window n  Activate 'missing window' validation and set tolerance to n packages (300=default, 6000=recommended)\n,
+
 version, progname, progname);
 log(%s called with wrong arguments, program not started., progname);
 exit(1);
@@ -212,6 +214,7 @@
 	{version, 0, 0, 0},
 	{test-type, 1, 0, 0},
 	{test-rate, 1, 0, 0},
+	{missing-window, 1, 0, 0},
 {0, 0, 0, 0}
 };
 int option_index = 0;
@@ -290,7 +293,21 @@
 		test_type = atoi(optarg);
 		} else if (option_index == 14) { /* --test-rate */
 		test_rate = atoi(optarg);
-}
+		} else if (option_index == 15) { /* --missing window */
+		int x = atoi(optarg);
+		if (x = 0) {
+fprintf(stderr, --missing-window must be integer greater than zero\n);
+log(--missing-window must be integer greater than zero\n);
+exit(2);
+		} else if (x  300) {
+fprintf(stderr, --missing-window is set very low: default=300, recommended=6000 - proceeding anyway\n);
+log(--missing-window is set very low: default=300, recommended=6000 - proceeding anyway\n);
+		} else {
+fprintf(stderr, --missing-window validation is active and set to: %d\n, x);
+log(--missing-window validation is active and set to: %d\n, x);
+missing_window = x;
+		}
+		}
 break;
 case '?': /* unrecognised option */
 /* fall through */
diff -u pptp-linux-1.7.2/debian/changelog pptp-linux-1.7.2/debian/changelog
--- pptp-linux-1.7.2/debian/changelog
+++ pptp-linux-1.7.2/debian/changelog
@@ -1,3 +1,9 @@
+pptp-linux (1.7.2-6ubuntu1) precise; urgency=low
+
+  * Include adj_missing_window.patch from bug #681617
+
+ -- Michael Hudson-Doyle michael.hud...@linaro.org  Wed, 04 Jul 2012 10:29:36 +1200
+
 pptp-linux (1.7.2-6) unstable; urgency=low
 
   * Now depends on binutils. Closes: #587506.
only in patch2:
unchanged:
--- pptp-linux-1.7.2.orig/pqueue.h
+++ pptp-linux-1.7.2/pqueue.h
@@ -9,7 +9,10 @@
 extern int packet_timeout_usecs;
 
 /* assume packet is bad/spoofed if it's more than this many seqs ahead */
-#define MISSING_WINDOW 300
+/* default is NOT to check - command line override via '--missing-window n'*/
+/* default value is 300 - recommended is 6000 for high speed data rates*/
+#define MISSING_WINDOW -1
+extern int missing_window;
 
 /* Packet queue structure: linked list of packets received out-of-order */
 typedef struct pqueue {
only in patch2:
unchanged:
--- pptp-linux-1.7.2.orig/pptp_gre.c
+++ pptp-linux

Bug#706662: siege: coding error can lead to connections going to localhost rather than desired system

[Michael Hudson-Doyle]

Package: siege
Version: 2.70-4
Severity: important
Tags: upstream

Dear Maintainer,

This bug is still in the upstream 3.0.0 release.

This code from newsocket in sock.c:

  int herrno;
  struct sockaddr_in cli;
  struct hostent *hp;
...
  {
struct hostent hent;
char hbf[8192];
memset(hbf, '\0', sizeof hbf);
/* for systems using GNU libc */
if((gethostbyname_r(hostparam, hent, hbf, sizeof(hbf), hp, herrno)  0)){
  hp = NULL;
}
  }
  if(hp == NULL){ return -1; }
  memset((void*) cli, 0, sizeof(cli));
  memcpy(cli.sin_addr, hp-h_addr, hp-h_length);

invokes undefined behaviour because gethostbyname_r points hp at the 'hent'
automatic variable but hp is used after the execution of the scope that
declared it, in violation of section 6.2.4 of the C99 standard.

The particular undefined behaviour I see is that cli.sin_addr ends up being all
bits 0, and so the connection goes to localhost.

I've emailed the upstream author about this.

I admit that I have not verified that the bug manifests on Debian, only Ubuntu.
But the bug in the code is definitely there.

Cheers,
mwh

-- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 
'raring-proposed'), (500, 'raring'), (100, 'raring-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages siege depends on:
ii  libc62.17-0ubuntu5
ii  libssl1.0.0  1.0.1c-4ubuntu8

siege recommends no packages.

siege suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#706662: siege: coding error can lead to connections going to localhost rather than desired system

[Michael Hudson-Doyle]

Josue Abarca jmasli...@debian.org.gt writes:


 Hello Michael,

 thanks for reporting the problem, please, if possible, let me now if
 you get an answer from upstream (He is usually very responsive).

I got an answer indeed, and sent him the attached patch.  I can't find a
public bug tracker or version control so I'll let you know what he
thinks of it.

 I have tried to reproduce the bug, but it seems that in Debian Sid
 (using Amd64 architecture) cli.sin_addr is getting the right value.

Ah yes: for whatever reason I only see the bug when pointing siege at a
name from /etc/hosts or an IP address.  When the resolution happens via
actual DNS, it works fine.  Maybe that's what you're seeing, or maybe
the bug just doesn't happen on sid...

Cheers,
mwh

diff -ur siege-3.0.0-orig/src/sock.c siege-3.0.0/src/sock.c
--- siege-3.0.0-orig/src/sock.c	2013-03-26 03:12:18.0 +1300
+++ siege-3.0.0/src/sock.c	2013-05-06 09:01:08.656569799 +1200
@@ -82,10 +82,18 @@
   struct hostent *hp;
   char   hn[512];
   intport;
-#if defined(_AIX)
+#if defined(__GLIBC__)
+  struct hostent hent;
+  char hbf[8192];
+#elif defined(sun)
+# ifndef HAVE_GETIPNODEBYNAME
+  struct hostent hent;
+  char hbf[8192];
+# endif/*HAVE_GETIPNODEBYNAME*/
+#elif defined(_AIX)
   char *aixbuf;
   int  rc;
-#endif/*_AIX*/ 
+#endif/*_AIX*/
 
   C-encrypt  = (C-scheme == HTTPS) ? TRUE: FALSE;
   C-state= UNDEF;
@@ -121,8 +129,6 @@
 
 #if defined(__GLIBC__)
   {
-struct hostent hent;
-char hbf[8192]; 
 memset(hbf, '\0', sizeof hbf);
 /* for systems using GNU libc */
 if((gethostbyname_r(hostparam, hent, hbf, sizeof(hbf), hp, herrno)  0)){
@@ -134,8 +140,6 @@
   hp = getipnodebyname(hn, AF_INET, 0, herrno);
 # else /* default use gethostbyname_r*/
   {
-struct hostent hent;
-char hbf[8192]; 
 memset(hbf, '\0', sizeof hbf);
 hp = gethostbyname_r(hn, hent, hbf, sizeof(hbf), herrno); 
   }

Bug#706662: siege: coding error can lead to connections going to localhost rather than desired system

[Michael Hudson-Doyle]

Michael Hudson-Doyle michael.hud...@canonical.com writes:

 Josue Abarca jmasli...@debian.org.gt writes:


 Hello Michael,

 thanks for reporting the problem, please, if possible, let me now if
 you get an answer from upstream (He is usually very responsive).

 I got an answer indeed, and sent him the attached patch.  I can't find a
 public bug tracker or version control so I'll let you know what he
 thinks of it.

He's now applied the patch I sent him (see
http://www.joedog.org/pub/siege/beta/siege-3.0.1-beta3.tar.gz).  I don't
know if it's appropriate to include it as a distro patch for Debian or
if you want to wait for 3.0.1...

Cheers,
mwh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

[Michael Hudson-Doyle]

Package: libdpkg-perl
Version: 1.17.25ubuntu1
Severity: normal

Dear Maintainer,

I have been working on adding support to the native Go toolchain for shared
libraries.  Upstream git now produces shared libraries and dpkg-shlibdeps 
complains noisily when processing them:

dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
002884d8 R_X86_64_64   type.func(*launchpad.net/go-xdg/v0.XDGDir) 
[]string+0x0088
dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
002884f0 R_X86_64_64   type.func(*launchpad.net/go-xdg/v0.XDGDir) 
[]string+0x0090
dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
00288858 R_X86_64_64   type.func(*launchpad.net/go-xdg/v0.XDGDir) 
[]string
dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
00288940 R_X86_64_64   type.func(*launchpad.net/go-xdg/v0.XDGDir) 
[]string

I suppose a few regexp tweaks are required.

Cheers,
mwh


-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-16-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdpkg-perl depends on:
ii  dpkg  1.17.25ubuntu1
ii  libtimedate-perl  2.3000-2
ii  perl  5.20.2-2

Versions of packages libdpkg-perl recommends:
ii  bzip2   1.0.6-7
ii  libfile-fcntllock-perl  0.22-1build1
ii  xz-utils5.1.1alpha+20120614-2ubuntu2

Versions of packages libdpkg-perl suggests:
ii  binutils  2.25-5ubuntu7
pn  debian-keyringnone
ii  gcc [c-compiler]  4:4.9.2-2ubuntu2
ii  gcc-4.9 [c-compiler]  4.9.2-10ubuntu13
ii  gnupg 1.4.18-7ubuntu1
ii  gpgv  1.4.18-7ubuntu1
ii  patch 2.7.5-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

[Michael Hudson-Doyle]

On 20 May 2015 at 09:24, Guillem Jover guil...@debian.org wrote:
 Hi!

 On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
 Package: libdpkg-perl
 Version: 1.17.25ubuntu1
 Severity: normal

 I have been working on adding support to the native Go toolchain for shared
 libraries.

 Cool! I've long considered languages not supporting shared libraries
 to not be very compelling (to put it mildly :).

:-)

 Upstream git now produces shared libraries and dpkg-shlibdeps
 complains noisily when processing them:

 dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
 002884d8 R_X86_64_64   
 type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0088
 dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
 002884f0 R_X86_64_64   
 type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0090
 dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
 00288858 R_X86_64_64   
 type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
 dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
 00288940 R_X86_64_64   
 type.func(*launchpad.net/go-xdg/v0.XDGDir) []string

 I suppose a few regexp tweaks are required.

 This would imply changing the regexes to match on column basis or very
 strict amount of spaces, because there are valid cases where a version
 node or the visibility markers might or not be present, which seems a
 bit more flaky, although I doubt the objdump output format has changed
 for a long time, but we'd have to verify that.

Yeah, the patch I wrote yesterday (at
http://paste.ubuntu.com/11232233/) checks for the number of spaces
indicated by an absent version.  A bit fragile but I don't suppose
this is very likely to change.  Parsing the ELF would be better but
obviously a bunch of work (Go has a nice ELF library :-), doesn't
support versions though).

 In any case, there's several things that come to mind why on first
 thought this might seem like not an entirely good idea anyway (w/o
 having never actually looked deep into Go in any serious way):

   - Is the ABI (for each supported arch) specified as part of the
 language, or is it an implementation detail?

Oh very much an implementation detail at this point.

 + If the latter, it means this might allow linking incompatible
   objects, which is one of the reasons C++ does not specify the
   mangling rules.
   - Do the symbol names interop with GCC Go?

I don't know for sure about the names, but there is no chance of the
native toolchain and gccgo directly interoperating anyway: the native
toolchain does not follow the platform ABI.

   - How would this handle ABI changes in the future if the symbols are
 not mangled?

At least in the medium term, there is not going to be anywhere near as
much ABI stability over time with a Go library compared to a C or even
C++ library.  A new compiler version implies a new ABI version, for
example.

   - How would this handle interop with languages that do not support
 spaces? Can you specify to export to a specific language so that
 it gets symbols mangled for that? Or do you need something else
 like manually specifying the symbols in asm, or something like
 FFI?

Go and other code can not interoperate directly (see above comments
about not following ABI). There is a thing (cgo) that generates code
to support thunking between the two worlds, and you can make it
generate symbols that conform to C's expectations. Besides that, the
symbols that end up containing spaces are not the sort of things that
other languages want to access, it's mostly stuff like the data for a
type.

 On Mon, 2015-05-18 at 01:55:57 -0400, Guo Yixuan wrote:
 Package: libdpkg-perl
 Version: 1.17.25
 Followup-For: Bug #785344

 It seems that ELF symbol names can contain any characters, except \0.
 So a correct solution would be read ELF from perl, instead of using the
 output of objdump. (Unless objdump has a -0 option similar to xargs...)

 While it's true that those are allowed symbols, as I could not find
 anything stating otherwise in the ELF spec, I've to wonder about the
 wisdom of that choice? But when handling dpkg issues, my most
 conservative side comes afloat, so it might just be that talking here. :)

 And Implementing an ELF parser in perl, just to be able to support Go,
 does not seem very compelling, no.

 This discussion at golang provides some background:
   https://go-review.googlesource.com/19101

 It complains about a session expired and that I need to login, after
 ignoring the dialog, I cannot see anything there.

I think he means https://go-review.googlesource.com/#/c/10191/

Cheers,
mwh


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

[Michael Hudson-Doyle]

On 26 May 2015 at 21:07, Michael Hudson-Doyle
michael.hud...@canonical.com wrote:
 It would be nice if the unit test would cover versions longer than
 the normal space padding, and the visibility attributes.

 I'll try to do that tomorrow.

So it took a week longer than I hoped, but I'm attaching a patch with,
I think, pretty comprehensive tests.  The implementation is the same
as my previous patch (and the tests fail without the new
implementation). I'm not much of a perl programmer, so my perl is
probably as unidiomatic as it gets, but if you can make my test cases
pass I don't really care if you change everything else completely :-)

Cheers,
mwh
From e5a3fcb914a03ea0e448371ea3a271e33dc41c34 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle michael.hud...@canonical.com
Date: Thu, 4 Jun 2015 13:13:23 +1200
Subject: [PATCH] Support for spaces in symbols in Dpkg::Shlibs::Objdump.

---
 scripts/Dpkg/Shlibs/Objdump.pm  |  63 ++--
 scripts/Makefile.am |  18 -
 scripts/t/Dpkg_Shlibs.t |  35 -
 scripts/t/Dpkg_Shlibs/makespacesymc.pl  |  32 
 scripts/t/Dpkg_Shlibs/objdump.spacesyms | 127 
 scripts/t/Dpkg_Shlibs/spacesym.pl   |  19 +
 scripts/t/Dpkg_Shlibs/spacesyms.map |   7 ++
 7 files changed, 276 insertions(+), 25 deletions(-)
 create mode 100755 scripts/t/Dpkg_Shlibs/makespacesymc.pl
 create mode 100644 scripts/t/Dpkg_Shlibs/objdump.spacesyms
 create mode 100755 scripts/t/Dpkg_Shlibs/spacesym.pl
 create mode 100644 scripts/t/Dpkg_Shlibs/spacesyms.map

diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm
index c19c3fb..dd53a24 100644
--- a/scripts/Dpkg/Shlibs/Objdump.pm
+++ b/scripts/Dpkg/Shlibs/Objdump.pm
@@ -221,7 +221,7 @@ sub parse_objdump_output {
 	if ($section eq 'dynsym') {
 	$self-parse_dynamic_symbol($_);
 	} elsif ($section eq 'dynreloc') {
-	if (/^\S+\s+(\S+)\s+(\S+)\s*$/) {
+	if (/^\S+\s+(\S+)\s+(.+)$/) {
 		$self-{dynrelocs}{$2} = $1;
 	} else {
 		warning(g_(couldn't parse dynamic relocation record: %s), $_);
@@ -299,21 +299,36 @@ sub parse_objdump_output {
 sub parse_dynamic_symbol {
 my ($self, $line) = @_;
 my $vis_re = '(\.protected|\.hidden|\.internal|0x\S+)';
-if ($line =~ /^[0-9a-f]+ (.{7})\s+(\S+)\s+[0-9a-f]+(?:\s+(\S+))?(?:\s+$vis_re)?\s+(\S+)/) {
-
-	my ($flags, $sect, $ver, $vis, $name) = ($1, $2, $3, $4, $5);
-
-	# Special case if version is missing but extra visibility
-	# attribute replaces it in the match
-	if (defined($ver) and $ver =~ /^$vis_re$/) {
-	$vis = $ver;
-	$ver = '';
-	}
+if ($line =~ /^[0-9a-f]+ (.{7})\s+(\S+)\s+[0-9a-f]+(.+)$/) {
+
+	my ($flags, $sect, $rest) = ($1, $2, $3);
+my ($ver, $vis, $name);
+
+if ($rest =~ /^ {11}/) {
+# No version
+$rest =~ s/^\s+|\s+$//g;
+if ($rest =~ /^$vis_re\s+(\S.+)/) {
+$vis = $1;
+$name = $2;
+} else {
+$name = $rest;
+}
+} elsif ($rest =~ /(?:\s+(\S+))?(?:\s+$vis_re)?\s+(.+)/) {
+($ver, $vis, $name) = ($1, $2, $3);
+# Special case if version is missing but extra visibility
+# attribute replaces it in the match
+if (defined($ver) and $ver =~ /^$vis_re$/) {
+$vis = $ver;
+$ver = '';
+}
+}
 
-	# Cleanup visibility field
-	$vis =~ s/^\.// if defined($vis);
+if (defined($name)) {
+# Cleanup visibility field
+$vis =~ s/^\.// if defined($vis);
 
-	my $symbol = {
+# Register symbol
+my $symbol = {
 		name = $name,
 		version = $ver // '',
 		section = $sect,
@@ -328,16 +343,18 @@ sub parse_dynamic_symbol {
 		defined = $sect ne '*UND*'
 	};
 
-	# Handle hidden symbols
-	if (defined($ver) and $ver =~ /^\((.*)\)$/) {
-	$ver = $1;
-	$symbol-{version} = $1;
-	$symbol-{hidden} = 1;
-	}
+# Handle hidden symbols
+if (defined($ver) and $ver =~ /^\((.*)\)$/) {
+$ver = $1;
+$symbol-{version} = $1;
+$symbol-{hidden} = 1;
+}
+$self-add_dynamic_symbol($symbol);
+return;
+}
+}
 
-	# Register symbol
-	$self-add_dynamic_symbol($symbol);
-} elsif ($line =~ /^[0-9a-f]+ (.{7})\s+(\S+)\s+[0-9a-f]+/) {
+if ($line =~ /^[0-9a-f]+ (.{7})\s+(\S+)\s+[0-9a-f]+/) {
 	# Same start but no version and no symbol ... just ignore
 } elsif ($line =~ /^REG_G\d+\s+/) {
 	# Ignore some s390-specific output like
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index be164b7..ad3e0b9 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -313,7 +313,8 @@ test_data_objects = \
 	t/Dpkg_Shlibs/libobjdump.basictags-amd64.so \
 	t/Dpkg_Shlibs/libobjdump.basictags-i386.so \
 	t/Dpkg_Shlibs/libobjdump.basictags-mips.so \
-	t/Dpkg_Shlibs/libobjdump.patterns.so

Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

[Michael Hudson-Doyle]

On 26 May 2015 at 17:35, Guillem Jover guil...@debian.org wrote:
 Hi!

 On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote:
 On 20 May 2015 at 09:24, Guillem Jover guil...@debian.org wrote:
  On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
  Package: libdpkg-perl
  Version: 1.17.25ubuntu1
  Severity: normal

  Upstream git now produces shared libraries and dpkg-shlibdeps
  complains noisily when processing them:
 
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  002884d8 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0088
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  002884f0 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0090
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  00288858 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  00288940 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
 
  I suppose a few regexp tweaks are required.
 
  This would imply changing the regexes to match on column basis or very
  strict amount of spaces, because there are valid cases where a version
  node or the visibility markers might or not be present, which seems a
  bit more flaky, although I doubt the objdump output format has changed
  for a long time, but we'd have to verify that.

 Yeah, the patch I wrote yesterday (at
 http://paste.ubuntu.com/11232233/) checks for the number of spaces
 indicated by an absent version.  A bit fragile but I don't suppose
 this is very likely to change.  Parsing the ELF would be better but
 obviously a bunch of work (Go has a nice ELF library :-), doesn't
 support versions though).

 As mentioned above, we'd need to check if this has changed in the
 past, and if so how long ago.

Well, as I far as I understand the binutils code (not especially far),
this hasn't changed since 1999.  I got the number of spaces from this
line:


https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=ab010d46f4b76d7da9985adef366f4be62c561a4;hb=252b5132c753830d5fd56823373aed85f2a0db63#l811

(There is older history in the binutils git but it seems that master
does not have the older stuff in its history and it confuses me)

 W/o having checked deeply, I think the patch can be simplified, by
 just changing the regex to cover the different cases. But I'm still
 uncertain if it is a good idea, given that it has the potential to
 break existing stuff.

 It would be nice if the unit test would cover versions longer than
 the normal space padding, and the visibility attributes.

  In any case, there's several things that come to mind why on first
  thought this might seem like not an entirely good idea anyway (w/o
  having never actually looked deep into Go in any serious way):
 
- Is the ABI (for each supported arch) specified as part of the
  language, or is it an implementation detail?

 Oh very much an implementation detail at this point.

 Ok.

  + If the latter, it means this might allow linking incompatible
objects, which is one of the reasons C++ does not specify the
mangling rules.
- Do the symbol names interop with GCC Go?

 I don't know for sure about the names, but there is no chance of the
 native toolchain and gccgo directly interoperating anyway: the native
 toolchain does not follow the platform ABI.

 But if the symbols match then users might end up linking both, which
 might become run-time errors instead of link-time ones? This would not
 seem ideal. Or is there something else to guarantee no mixups?

- How would this handle ABI changes in the future if the symbols are
  not mangled?

 At least in the medium term, there is not going to be anywhere near as
 much ABI stability over time with a Go library compared to a C or even
 C++ library.  A new compiler version implies a new ABI version, for
 example.

 Hmm, so what would be the point of shared libraries then? If a new
 compiler version implies a new ABI version, then that will require
 rebuilding the world, with flag-day transitions, and automatic SOVERSION
 bumps or Conflicts or similar.

 I'm also not seeing how it could provide a stable ABI w/o some kind of
 mangling, or at lest some ABI namespaceing or tagging?

- How would this handle interop with languages that do not support
  spaces? Can you specify to export to a specific language so that
  it gets symbols mangled for that? Or do you need something else
  like manually specifying the symbols in asm, or something like
  FFI?

 Go and other code can not interoperate directly (see above comments
 about not following ABI). There is a thing (cgo) that generates code
 to support thunking between the two worlds, and you can make it
 generate symbols that conform to C's

Bug#785344: libdpkg-perl: Dpkg/Shlibs/Objdump.pm does not cope with spaces in symbol names

[Michael Hudson-Doyle]

Sorry for the truncated reply.

On 26 May 2015 at 17:35, Guillem Jover guil...@debian.org wrote:
 Hi!

 On Wed, 2015-05-20 at 09:49:22 +1200, Michael Hudson-Doyle wrote:
 On 20 May 2015 at 09:24, Guillem Jover guil...@debian.org wrote:
  On Fri, 2015-05-15 at 15:03:53 +1200, Michael Hudson-Doyle wrote:
  Package: libdpkg-perl
  Version: 1.17.25ubuntu1
  Severity: normal

  Upstream git now produces shared libraries and dpkg-shlibdeps
  complains noisily when processing them:
 
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  002884d8 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0088
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  002884f0 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string+0x0090
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  00288858 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
  dpkg-shlibdeps: warning: couldn't parse dynamic relocation record: 
  00288940 R_X86_64_64   
  type.func(*launchpad.net/go-xdg/v0.XDGDir) []string
 
  I suppose a few regexp tweaks are required.
 
  This would imply changing the regexes to match on column basis or very
  strict amount of spaces, because there are valid cases where a version
  node or the visibility markers might or not be present, which seems a
  bit more flaky, although I doubt the objdump output format has changed
  for a long time, but we'd have to verify that.

 Yeah, the patch I wrote yesterday (at
 http://paste.ubuntu.com/11232233/) checks for the number of spaces
 indicated by an absent version.  A bit fragile but I don't suppose
 this is very likely to change.  Parsing the ELF would be better but
 obviously a bunch of work (Go has a nice ELF library :-), doesn't
 support versions though).

 As mentioned above, we'd need to check if this has changed in the
 past, and if so how long ago.

Well, as I far as I understand the binutils code (not especially far),
this hasn't changed since 1999.  I got the number of spaces from this
line:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;hb=dab394de9e41de54df5e2310e081e1c550326f5b#l1582

and it was there in the initial import:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf.c;h=ab010d46f4b76d7da9985adef366f4be62c561a4;hb=252b5132c753830d5fd56823373aed85f2a0db63#l811

(There is older history in the binutils git but it seems that master
does not have the older stuff in its ancestry and it confuses me)

 W/o having checked deeply, I think the patch can be simplified, by
 just changing the regex to cover the different cases.

You can tell I'm not a perl natural because I replaced a regexp with
some logic :-)

 But I'm still
 uncertain if it is a good idea, given that it has the potential to
 break existing stuff.

Well yeah, that's the fear.  It would be possible to do something only
in the case of a Go shared library, but that sounds pretty horrible.

 It would be nice if the unit test would cover versions longer than
 the normal space padding, and the visibility attributes.

I'll try to do that tomorrow.

  In any case, there's several things that come to mind why on first
  thought this might seem like not an entirely good idea anyway (w/o
  having never actually looked deep into Go in any serious way):
 
- Is the ABI (for each supported arch) specified as part of the
  language, or is it an implementation detail?

 Oh very much an implementation detail at this point.

 Ok.

  + If the latter, it means this might allow linking incompatible
objects, which is one of the reasons C++ does not specify the
mangling rules.
- Do the symbol names interop with GCC Go?

 I don't know for sure about the names, but there is no chance of the
 native toolchain and gccgo directly interoperating anyway: the native
 toolchain does not follow the platform ABI.

 But if the symbols match then users might end up linking both, which
 might become run-time errors instead of link-time ones? This would not
 seem ideal. Or is there something else to guarantee no mixups?

I can't really see how you could have that happen without determined
effort.  The user is expected to use the go tool to create and link to
the shared libraries, and that uses different directory for gc stuff
and gccgo stuff (and the stuff includes the .so symlinks).

- How would this handle ABI changes in the future if the symbols are
  not mangled?

 At least in the medium term, there is not going to be anywhere near as
 much ABI stability over time with a Go library compared to a C or even
 C++ library.  A new compiler version implies a new ABI version, for
 example.

 Hmm, so what would be the point of shared libraries then?

Being able to distribute security fixes to a library by just updating
the library not all its rdeps and also size on disk

Bug#786869: golang-go.crypto-dev: fails to build with golang-go = 1.4

[Michael Hudson-Doyle]

Package: golang-go.crypto-dev
Version: 0.0~hg190-1
Severity: normal

Dear Maintainer,

The golang-go.crypto package fails to build with Go 1.4 (or newer) as is now
found in sid with errors of the form:

# testmain
missing Go type information for global symbol: 
code.google.com/p/go.crypto/curve25519.REDMASK51 size 8
missing Go type information for global symbol: 
code.google.com/p/go.crypto/curve25519._121666_213 size 8
missing Go type information for global symbol: 
code.google.com/p/go.crypto/curve25519._2P0 size 8
missing Go type information for global symbol: 
code.google.com/p/go.crypto/curve25519._2P1234 size 8

This was fixed upstream a while ago and applying these two patches:

https://github.com/golang/crypto/commit/20b2ab3f620101745124d791d5dfd30e1708723a
https://github.com/golang/crypto/commit/902e2dcb72d7cab5a9b4de3ee5e9abb73ef83973

makes the package build again.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-18-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786869: golang-go.crypto-dev: fails to build with golang-go = 1.4

[Michael Hudson-Doyle]

Here's a debdiff.
diff -Nru golang-go.crypto-0.0~hg190/debian/changelog 
golang-go.crypto-0.0~hg190/debian/changelog
--- golang-go.crypto-0.0~hg190/debian/changelog 2014-03-13 18:55:43.0 
+
+++ golang-go.crypto-0.0~hg190/debian/changelog 2015-05-26 09:59:03.0 
+
@@ -1,3 +1,9 @@
+golang-go.crypto (0.0~hg190-1ubuntu1) UNRELEASED; urgency=medium
+
+  * Add two patches to be compatible with go = 1.4 
+
+ -- Michael Hudson-Doyle michael.hud...@canonical.com  Tue, 26 May 2015 
21:57:38 +1200
+
 golang-go.crypto (0.0~hg190-1) unstable; urgency=low
 
   * Initial release. Closes: #740791
diff -Nru golang-go.crypto-0.0~hg190/debian/control 
golang-go.crypto-0.0~hg190/debian/control
diff -Nru 
golang-go.crypto-0.0~hg190/debian/patches/0001-curve25519-poly1305-mark-constants-as-RODATA.patch
 
golang-go.crypto-0.0~hg190/debian/patches/0001-curve25519-poly1305-mark-constants-as-RODATA.patch
--- 
golang-go.crypto-0.0~hg190/debian/patches/0001-curve25519-poly1305-mark-constants-as-RODATA.patch
   1970-01-01 00:00:00.0 +
+++ 
golang-go.crypto-0.0~hg190/debian/patches/0001-curve25519-poly1305-mark-constants-as-RODATA.patch
   2015-05-26 09:57:18.0 +
@@ -0,0 +1,111 @@
+From 20b2ab3f620101745124d791d5dfd30e1708723a Mon Sep 17 00:00:00 2001
+From: Ian Lance Taylor i...@golang.org
+Date: Tue, 7 Oct 2014 16:59:07 -0700
+Subject: [PATCH 1/2] curve25519, poly1305: mark constants as RODATA
+
+Fixes tests when using Go tip.  Without this the link steps
+fails with errors like:
+
+missing Go type information for global symbol: 
google3/third_party/golang/go_crypto/curve25519/curve25519.REDMASK51 size 8
+
+LGTM=agl
+R=agl
+CC=golang-codereviews
+https://golang.org/cl/156810043
+---
+ curve25519/const_amd64.s | 10 ++
+ poly1305/const_amd64.s   | 38 --
+ 2 files changed, 26 insertions(+), 22 deletions(-)
+
+diff --git a/curve25519/const_amd64.s b/curve25519/const_amd64.s
+index cc42087..f13803f 100644
+--- a/curve25519/const_amd64.s
 b/curve25519/const_amd64.s
+@@ -7,14 +7,16 @@
+ 
+ // +build amd64,!gccgo
+ 
++#include textflag.h
++
+ DATA ·REDMASK51(SB)/8, $0x0007
+-GLOBL ·REDMASK51(SB), $8
++GLOBL ·REDMASK51(SB), RODATA, $8
+ 
+ DATA ·_121666_213(SB)/8, $996687872
+-GLOBL ·_121666_213(SB), $8
++GLOBL ·_121666_213(SB), RODATA, $8
+ 
+ DATA ·_2P0(SB)/8, $0xFFFDA
+-GLOBL ·_2P0(SB), $8
++GLOBL ·_2P0(SB), RODATA, $8
+ 
+ DATA ·_2P1234(SB)/8, $0xE
+-GLOBL ·_2P1234(SB), $8
++GLOBL ·_2P1234(SB), RODATA, $8
+diff --git a/poly1305/const_amd64.s b/poly1305/const_amd64.s
+index e26ea67..132c6d1 100644
+--- a/poly1305/const_amd64.s
 b/poly1305/const_amd64.s
+@@ -7,39 +7,41 @@
+ 
+ // +build amd64,!gccgo
+ 
++#include textflag.h
++
+ DATA ·SCALE(SB)/8, $0x37F4
+-GLOBL ·SCALE(SB), $8
++GLOBL ·SCALE(SB), RODATA, $8
+ DATA ·TWO32(SB)/8, $0x41F0
+-GLOBL ·TWO32(SB), $8
++GLOBL ·TWO32(SB), RODATA, $8
+ DATA ·TWO64(SB)/8, $0x43F0
+-GLOBL ·TWO64(SB), $8
++GLOBL ·TWO64(SB), RODATA, $8
+ DATA ·TWO96(SB)/8, $0x45F0
+-GLOBL ·TWO96(SB), $8
++GLOBL ·TWO96(SB), RODATA, $8
+ DATA ·ALPHA32(SB)/8, $0x45E8
+-GLOBL ·ALPHA32(SB), $8
++GLOBL ·ALPHA32(SB), RODATA, $8
+ DATA ·ALPHA64(SB)/8, $0x47E8
+-GLOBL ·ALPHA64(SB), $8
++GLOBL ·ALPHA64(SB), RODATA, $8
+ DATA ·ALPHA96(SB)/8, $0x49E8
+-GLOBL ·ALPHA96(SB), $8
++GLOBL ·ALPHA96(SB), RODATA, $8
+ DATA ·ALPHA130(SB)/8, $0x4C08
+-GLOBL ·ALPHA130(SB), $8
++GLOBL ·ALPHA130(SB), RODATA, $8
+ DATA ·DOFFSET0(SB)/8, $0x4330
+-GLOBL ·DOFFSET0(SB), $8
++GLOBL ·DOFFSET0(SB), RODATA, $8
+ DATA ·DOFFSET1(SB)/8, $0x4530
+-GLOBL ·DOFFSET1(SB), $8
++GLOBL ·DOFFSET1(SB), RODATA, $8
+ DATA ·DOFFSET2(SB)/8, $0x4730
+-GLOBL ·DOFFSET2(SB), $8
++GLOBL ·DOFFSET2(SB), RODATA, $8
+ DATA ·DOFFSET3(SB)/8, $0x4930
+-GLOBL ·DOFFSET3(SB), $8
++GLOBL ·DOFFSET3(SB), RODATA, $8
+ DATA ·DOFFSET3MINUSTWO128(SB)/8, $0x492E
+-GLOBL ·DOFFSET3MINUSTWO128(SB), $8
++GLOBL ·DOFFSET3MINUSTWO128(SB), RODATA, $8
+ DATA ·HOFFSET0(SB)/8, $0x4331FFFB
+-GLOBL ·HOFFSET0(SB), $8
++GLOBL ·HOFFSET0(SB), RODATA, $8
+ DATA ·HOFFSET1(SB)/8, $0x4531FFFE
+-GLOBL ·HOFFSET1(SB), $8
++GLOBL ·HOFFSET1(SB), RODATA, $8
+ DATA ·HOFFSET2(SB)/8, $0x4731FFFE
+-GLOBL ·HOFFSET2(SB), $8
++GLOBL ·HOFFSET2(SB), RODATA, $8
+ DATA ·HOFFSET3(SB)/8, $0x4933FFFE
+-GLOBL ·HOFFSET3(SB), $8
++GLOBL ·HOFFSET3(SB), RODATA, $8
+ DATA ·ROUNDING(SB)/2, $0x137f
+-GLOBL ·ROUNDING(SB), $2
++GLOBL ·ROUNDING(SB), RODATA, $2
+-- 
+2.1.4
+
diff -Nru 
golang-go.crypto-0.0~hg190/debian/patches/0002-curve25519-poly1305-change-last-CL-to-build-with-Go-.patch
 
golang-go.crypto-0.0~hg190/debian/patches/0002-curve25519-poly1305-change-last-CL-to-build-with-Go-.patch
--- 
golang-go.crypto-0.0~hg190/debian/patches/0002-curve25519-poly1305-change-last-CL-to-build-with-Go-.patch
   1970-01-01 00:00

Bug#796761: golang-golang-x-tools: please upload a new snapshot

[Michael Hudson-Doyle]

Package: golang-golang-x-tools
Version: 1:0.0~git20150716.0.87156cb+dfsg1-3
Severity: important

Dear Maintainer,

Currently golang-golang-x-tools has tests that fail with Go 1.5. These have
been fixed in tip.

There are other tests that I think will fail on some builder unless -short is
passed to go test. But we'll see I guess.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-25-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#794815: [pkg-go] Bug#794815: FTBFS because go generate is missing a build dependency... and then some.

[Michael Hudson-Doyle]

On 7 August 2015 at 08:41, Hilko Bengen ben...@debian.org wrote:
 Source: golang-x-text
 Version: 0+git20150518.c93e7c9-1
 Severity: grave

 Beacuse dh-golang now executes go generate, the stringer binary is
 needed in building:

 ,
 | ...
 | src/golang.org/x/text/width/trieval.go
 | src/golang.org/x/text/width/width.go
 | src/golang.org/x/text/width/width.go:5: running stringer: exec: 
 stringer: executable file not found in $PATH
 | dh_auto_build: go generate -v golang.org/x/text golang.org/x/text/cases 
 golang.org/x/text/cldr golang.org/x/text/collate 
 golang.org/x/text/collate/build golang.org/x/text/collate/colltab 
 golang.org/x/text/display golang.org/x/text/encoding 
 golang.org/x/text/encoding/charmap golang.org/x/text/encoding/htmlindex 
 golang.org/x/text/encoding/ianaindex golang.org/x/text/encoding/internal 
 golang.org/x/text/encoding/internal/identifier 
 golang.org/x/text/encoding/japanese golang.org/x/text/encoding/korean 
 golang.org/x/text/encoding/simplifiedchinese 
 golang.org/x/text/encoding/traditionalchinese 
 golang.org/x/text/encoding/unicode golang.org/x/text/internal/colltab 
 golang.org/x/text/internal/gen golang.org/x/text/internal/testtext 
 golang.org/x/text/internal/triegen golang.org/x/text/internal/ucd 
 golang.org/x/text/language golang.org/x/text/runes golang.org/x/text/search 
 golang.org/x/text/transform golang.org/x/text/unicode/norm 
 golang.org/x/text/unicode/rangetable golang.org/x/text/width returned exit 
 code 1
 | make: *** [build] Error 1
 | debian/rules:9: recipe for target 'build' failed
 | dpkg-buildpackage: error: debian/rules build gave error exit status 2
 `

 I tried the patch below, but now the build fails with a different error:

 ,
 | ...
 | src/golang.org/x/text/width/width.go
 | stringer: checking package: transform.go:10:2: could not import 
 golang.org/x/text/transform (can't find import: golang.org/x/text/transform)
 | src/golang.org/x/text/width/width.go:5: running stringer: exit status 1
 | ...
 `

Hm, I think this is an argument against running go:generate at package
build time -- stringer, an absolutely canonical target for
go:generate, uses go/types which depends on the package dependencies
being already built, and if you run go generate before install then
they won't be. I guess you could run go install, go generate, and go
install again which would at least be less broken than the current
behaviour (it would also fix the ubuntu-snappy build I think). Or stop
running go:generate at package build time, I think it's at best a
marginal thing.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#794831: dh-golang: file copy in configure loses permissions

[Michael Hudson-Doyle]

Package: dh-golang
Version: 1.8
Severity: normal

Dear Maintainer,

ubuntu-snappy has a go:generate line like this at ./i18n/i18n.go:

//go:generate ../update-pot

This fails for two reasons: 1) the update-pot script isn't copied 2)
when you fix that by setting DH_GOLANG_INSTALL_ALL, ../update-pot has 
lost its x bit.

I think the fix is to just change the copy on line 118 of golang.pm to
cp, but I haven't tested that.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-25-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-golang depends on:
ii  debhelper 9.20150101ubuntu1
ii  dpkg  1.17.25ubuntu1
ii  libdpkg-perl  1.17.25ubuntu1
ii  perl  5.20.2-2

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793829:

[Michael Hudson-Doyle]

Here's a patch which fixes things in my testing.
diff -Nru gocode-20150303/debian/changelog gocode-20150303/debian/changelog
--- gocode-20150303/debian/changelog2015-05-27 21:25:48.0 +
+++ gocode-20150303/debian/changelog2015-07-27 22:58:17.0 +
@@ -1,3 +1,9 @@
+gocode (20150303-3) unstable; urgency=medium
+
+  * Fix packaging stuff.
+
+ -- Michael Hudson-Doyle mwhudson@glamdring  Mon, 27 Jul 2015 22:57:38 +
+
 gocode (20150303-2) unstable; urgency=medium
 
   * Remove vim-syntax-go from vim-gocomplete dependency list (Closes: #786891)
diff -Nru gocode-20150303/debian/gocode.install 
gocode-20150303/debian/gocode.install
--- gocode-20150303/debian/gocode.install   2014-06-22 19:39:07.0 
+
+++ gocode-20150303/debian/gocode.install   2015-07-27 22:56:48.0 
+
@@ -1 +1 @@
-gocode usr/bin
+usr/bin/gocode usr/bin
diff -Nru gocode-20150303/debian/rules gocode-20150303/debian/rules
--- gocode-20150303/debian/rules2015-04-03 20:32:22.0 +
+++ gocode-20150303/debian/rules2015-07-27 22:54:56.0 +
@@ -1,16 +1,12 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
-export GOPATH=`pwd`
 
 export DH_GOPKG := github.com/nsf/gocode
 
 %:
dh $@ --buildsystem=golang
 
-override_dh_auto_build:
-   go build -o gocode $(filter-out os_windows.go,$(wildcard *.go))
-
 override_dh_auto_clean:
dh_auto_clean
rm -f gocode

Bug#793829: gocode: fails to build with Go 1.5

[Michael Hudson-Doyle]

Source: gocode
Version: 20150303-2
Severity: normal

Dear Maintainer,

The package fails to build with Go 1.5 because debian/rules appears to think
make is shell and sets GOPATH to '`pwd`'. Go 1.5 is stricter about detecting
bogus GOPATH values and the build fails. The fix is to remove chunks of
debian/rules and have dh-golang do more of the work.

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793838: aptly: fails to build with Go 1.5

[Michael Hudson-Doyle]

Package: aptly
Version: 0.9.5-1
Severity: normal

Dear Maintainer,

The override_dh_auto_build rule in debian/rules sets GOPATH to a value
containing an empty component. Go 1.5 is pickier about malformed GOPATH
entries and complains. Simply deleting the first colon fixes the build.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#796806: [pkg-go] Bug#796806: Bug#796806: golang-check.v1: Non-determistically FTBFS due to unreliable timing in tests

[Michael Hudson-Doyle]

I also encountered this and filed an upstream bug fwiw:
https://github.com/go-check/check/issues/53

I've only ever seen this on a builder, never locally.

On 26 August 2015 at 08:52, Michael Stapelberg stapelb...@debian.org wrote:
 Bug #796400 was similar.

 lamby, can you explain how I can reproduce this failure locally? I’d
 like to better understand how you are testing this before I can do
 anything about fixing the issue.

 On Mon, Aug 24, 2015 at 9:45 AM, Chris Lamb la...@debian.org wrote:
 Source: golang-check.v1
 Version: 0.0+git20150729.11d3bc7-1
 Severity: serious
 Justification: fails to build from source
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: ftbfs
 X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

 Dear Maintainer,

 golang-check.v1's testsuite appears to use method timing/benchmarking in
 such
 a way that it will non-deterministically FTBFS:

   [..]

  dh_auto_test -O--buildsystem=golang
 go test -v gopkg.in/check.v1
   === RUN Test

   --
   FAIL: benchmark_test.go:39: BenchmarkS.TestBenchmark

   benchmark_test.go:59:
   c.Assert(output.value, Matches, expected)
   ... value string = PASS: check_test.go:144:
   FixtureHelper.Benchmark1\t  50\t261765 ns/op\n
   ... regex string = PASS: check_test\\.go:[0-9]+:
   FixtureHelper\\.Benchmark1\t *100\t *[12][0-9]{5} ns/op\n


   --
   FAIL: benchmark_test.go:62: BenchmarkS.TestBenchmarkBytes

   benchmark_test.go:74:
   c.Assert(output.value, Matches, expected)
   ... value string = PASS: check_test.go:151:
   FixtureHelper.Benchmark2\t  50\t346352 ns/op\t   2.96 MB/s\n
   ... regex string = PASS: check_test\\.go:[0-9]+:
   FixtureHelper\\.Benchmark2\t *100\t *[12][0-9]{5} ns/op\t
   *[4-9]\\.[0-9]{2} MB/s\n

   OOPS: 125 passed, 2 FAILED
   --- FAIL: Test (0.46s)
   FAIL
   exit status 1
   FAILgopkg.in/check.v1   0.469s
   dh_auto_test: go test -v gopkg.in/check.v1 returned exit code 1
   debian/rules:7: recipe for target 'build' failed
   make: *** [build] Error 1
   dpkg-buildpackage: error: debian/rules build gave error exit status 2

   [..]

 The full build log is attached or can be viewed here:

 
 https://reproducible.debian.net/logs/unstable/amd64/golang-check.v1_0.0+git20150729.11d3bc7-1.build1.log.gz


 Regards,

 --
   ,''`.
  : :'  : Chris Lamb
  `. `'`  la...@debian.org / chris-lamb.co.uk
`-

 ___
 Pkg-go-maintainers mailing list
 pkg-go-maintain...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



 --
 Best regards,
 Michael

 On Mon, Aug 24, 2015 at 6:45 PM, Chris Lamb la...@debian.org wrote:
 Source: golang-check.v1
 Version: 0.0+git20150729.11d3bc7-1
 Severity: serious
 Justification: fails to build from source
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: ftbfs
 X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

 Dear Maintainer,

 golang-check.v1's testsuite appears to use method timing/benchmarking in
 such
 a way that it will non-deterministically FTBFS:

   [..]

  dh_auto_test -O--buildsystem=golang
 go test -v gopkg.in/check.v1
   === RUN Test

   --
   FAIL: benchmark_test.go:39: BenchmarkS.TestBenchmark

   benchmark_test.go:59:
   c.Assert(output.value, Matches, expected)
   ... value string = PASS: check_test.go:144:
   FixtureHelper.Benchmark1\t  50\t261765 ns/op\n
   ... regex string = PASS: check_test\\.go:[0-9]+:
   FixtureHelper\\.Benchmark1\t *100\t *[12][0-9]{5} ns/op\n


   --
   FAIL: benchmark_test.go:62: BenchmarkS.TestBenchmarkBytes

   benchmark_test.go:74:
   c.Assert(output.value, Matches, expected)
   ... value string = PASS: check_test.go:151:
   FixtureHelper.Benchmark2\t  50\t346352 ns/op\t   2.96 MB/s\n
   ... regex string = PASS: check_test\\.go:[0-9]+:
   FixtureHelper\\.Benchmark2\t *100\t *[12][0-9]{5} ns/op\t
   *[4-9]\\.[0-9]{2} MB/s\n

   OOPS: 125 passed, 2 FAILED
   --- FAIL: Test (0.46s)
   FAIL
   exit status 1
   FAILgopkg.in/check.v1   0.469s
   dh_auto_test: go test -v gopkg.in/check.v1 returned exit code 1
   debian/rules:7: recipe for target 'build' failed
   make: *** [build] Error 1
   dpkg-buildpackage: error: debian/rules build gave error exit status 2

   [..]

 The full build log is attached or can be viewed here:

 
 https://reproducible.debian.net/logs/unstable/amd64/golang-check.v1_0.0+git20150729.11d3bc7-1.build1.log.gz


 Regards,

 --
   ,''`.
  : :'  : Chris Lamb
  `. `'`  la...@debian.org / chris-lamb.co.uk
`-

 ___
 Pkg-go-maintainers mailing list
 

Bug#784543: [pkg-golang-devel] Bug#784543: golang: test failures on arm64

[Michael Hudson-Doyle]

Hm, it bootstrapped fine using gccgo-5 in Ubuntu:
https://launchpadlibrarian.net/214911501/buildlog_ubuntu-wily-arm64.golang_2%3A1.5~rc1-0ubuntu1_BUILDING.txt.gz.
I don't know enough about sbuild to know what the issue is here
(aspcud- vs apt-based resolver?)

The "not found in multicast rib" failure is
https://github.com/golang/go/issues/11936 ("net:
TestIPv4MulticastListener fails on linux without
CONFIG_IP_MULTICAST"), it's a bug that it's not skipped if the kernel
you are using doesn't support multicast. (Which kernel/board are you
using?)

TestCloneNEWUSERAndRemapNoRootDisableSetgroups always fails for me in
a chroot. I should figure out why at some point...

Not sure about the gdb test, but I do know that one is a bit temperamental.

Cheers,
mwh

On 28 September 2015 at 21:56, Edmund Grimley Evans
 wrote:
> Control: found -1 1.5.1-1~exp1
>
> I tried golang_1.5.1-1~exp1 over the weekend.
>
> Firstly, I wasn't able to bootstrap it with gccgo-5, so I'm not sure
> that the "golang-go (>= 2:1.4.2-2~) | gccgo-5" in debian/control is
> correct.
>
> With golang installed, it built but there were some test failures,
> though I can't guarantee my set-up wasn't somehow to blame:
>
>
> --- FAIL: TestIPv4MulticastListener
> listen_test.go:556: 224.0.0.254 not found in multicast rib
>
> --- FAIL: TestGdbPython
> runtime-gdb_test.go:42: gdb version 7.9
> runtime-gdb_test.go:129: failed to load Go runtime support:
> warning: File "/usr/share/go/src/runtime/runtime-gdb.py" auto-loading
> has been declined by your `auto-load safe-path' set to
> "$debugdir:$datadir/auto-load:/tmp/golang/golang-1.5.1/src/runtime".
>
> --- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups
> exec_linux_test.go:53: Cmd failed with err fork/exec
> /usr/bin/whoami: operation not permitted, output:
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#807136: [pkg-golang-devel] Bug#807136: golang: FTBFS due to new binutils relocations

[Michael Hudson-Doyle]

This is fixed in 1.5.2 which got released the other day, so a simple
fix would be to just upload that :-)

On 6 December 2015 at 11:12, Eric Cooper  wrote:
> Package: golang
> Version: 2:1.5.1-4
> Severity: normal
> Tags: upstream patch
>
> Building golang fails with these errors:
>
> ...
> # cmd/trace
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> runtime/cgo(.text): unexpected relocation type 298
> runtime/cgo(.text): unexpected relocation type 298
> runtime/cgo(.text): unexpected relocation type 298
> # cmd/pprof
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> runtime/cgo(.text): unexpected relocation type 298
> runtime/cgo(.text): unexpected relocation type 298
> runtime/cgo(.text): unexpected relocation type 298
> # cmd/go
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> /build/golang-1.5.1/pkg/linux_amd64/runtime/cgo.a(_all.o): unknown 
> relocation type 42; compiled without -fpic?
> runtime/cgo(.text): unexpected relocation type 298
> runtime/cgo(.text): unexpected relocation type 298
> runtime/cgo(.text): unexpected relocation type 298
> debian/rules:62: recipe for target 'override_dh_auto_build-arch' failed
> make[1]: *** [override_dh_auto_build-arch] Error 2
> make[1]: Leaving directory '/build/golang-1.5.1'
> debian/rules:15: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> The problem is fixed upstream here:
>
> 
> https://github.com/golang/go/commit/914db9f060b1fd3eb1f74d48f3bd46a73d4ae9c7
>
> but that commit does not apply cleanly to the current Debian version.
> I've attached an equivalent patch that does, but I didn't manage to
> preserve the original author, date, etc.  Please use the original
> metadata from the github commit if you decide to apply this.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages golang depends on:
> ii  golang-doc  2:1.5.1-4
> ii  golang-go   2:1.5.1-4
> ii  golang-src  2:1.5.1-4
>
> golang recommends no packages.
>
> golang suggests no packages.
>
> -- no debconf information
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#807294: golang-go: contains some but not all race-enabled packages

[Michael Hudson-Doyle]

Package: golang-go
Version: 1.5.1-4
Severity: normal

Dear Maintainer,

As you can see on https://packages.debian.org/sid/amd64/golang-go/filelist
there are quite a few race-enabled package .a files included in the package.
They are there because of the race-testing ./run.bash does. I think it's a bit
silly that a subset of such packages are installed: either all of them should
be installed (this is what the 1.4 packaging did I think), or none of them.
apart from anything else, this means that if DEB_BUILD_OPTIONS=nocheck actually
worked (see bug 807290 ), the files included in the package would change
depending on whether DEB_BUILD_OPTIONS=nocheck was set or not, which seems like
a bad thing to me.

Happy to implement either option if given an opinion!

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-18-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#807290: golang: does not respect DEB_BUILD_OPTIONS=nocheck

[Michael Hudson-Doyle]

Source: golang
Version: 1.5.1-4
Severity: normal
Tags: patch

Dear Maintainer,

The package build always runs the tests, irrespective of DEB_BUILD_OPTIONS. 
Simple patch attached.

Cheers,
mwh

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-18-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff --git a/debian/rules b/debian/rules
index 268db73..ae235c7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,9 @@ RUN_TESTS := true
 ifeq (ppc64, $(DEB_HOST_ARCH_CPU))
 	RUN_TESTS := false
 endif
+ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
+	RUN_TESTS := false
+endif
 
 %:
 	+dh --parallel $(opt_no_act) $@

Bug#734357:

[Michael Hudson-Doyle]

A proper fix for this went upstream and will be in 1.6 fwiw

Bug#807303: golang: NEWUSER tests fail on ubuntu (or maybe just new kernel)

[Michael Hudson-Doyle]

Source: golang
Version: 1.5.1-4
Severity: normal
Tags: patch upstream

Dear Maintainer,

Tests fail in my sid chroot because, on the Ubuntu kernel at least, the tests
that try to create a new user namespace all fail in a chroot. I fixed this
upstream but it'd be nice to have this in the 1.5 packaging too so here's a
backport of the patch.

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-18-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff --git a/debian/patches/series b/debian/patches/series
index e7c92b7..e189b35 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 support-new-relocations.patch
+skip-userns-tests-when-chrooted.patch
diff --git a/debian/patches/skip-userns-tests-when-chrooted.patch b/debian/patches/skip-userns-tests-when-chrooted.patch
new file mode 100644
index 000..15bd724
--- /dev/null
+++ b/debian/patches/skip-userns-tests-when-chrooted.patch
@@ -0,0 +1,37 @@
+Description: skip tests that create a user namespace when chrooted
+Origin: https://go.googlesource.com/go/+/21efa7b2bc872958bcb252f5ab4dc52b2b0abeae
+Applied-Upstream: commit:21efa7b2bc872958bcb252f5ab4dc52b2b0abeae
+
+--- a/src/syscall/exec_linux_test.go
 b/src/syscall/exec_linux_test.go
+@@ -17,6 +17,17 @@
+ 	"testing"
+ )
+ 
++// Check if we are in a chroot by checking if the inode of / is
++// different from 2 (there is no better test available to non-root on
++// linux).
++func isChrooted(t *testing.T) bool {
++	root, err := os.Stat("/")
++	if err != nil {
++		t.Fatalf("cannot stat /: %v", err)
++	}
++	return root.Sys().(*syscall.Stat_t).Ino != 2
++}
++
+ func whoamiCmd(t *testing.T, uid, gid int, setgroups bool) *exec.Cmd {
+ 	if _, err := os.Stat("/proc/self/ns/user"); err != nil {
+ 		if os.IsNotExist(err) {
+@@ -24,6 +35,12 @@
+ 		}
+ 		t.Fatalf("Failed to stat /proc/self/ns/user: %v", err)
+ 	}
++	if isChrooted(t) {
++		// create_user_ns in the kernel (see
++		// https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/user_namespace.c)
++		// forbids the creation of user namespaces when chrooted.
++		t.Skip("cannot create user namespaces when chrooted")
++	}
+ 	cmd := exec.Command("whoami")
+ 	cmd.SysProcAttr = {
+ 		Cloneflags: syscall.CLONE_NEWUSER,

Bug#807299: golang: build-depends overly broad

[Michael Hudson-Doyle]

Source: golang
Version: 1.5.1-4
Severity: minor
Tags: patch

Dear Maintainer,

bison hasn't been needed for a long time I think... Some of the others are in 
build-essential.

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-18-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff --git a/debian/control b/debian/control
index 3b79800..3020ac2 100644
--- a/debian/control
+++ b/debian/control
@@ -7,13 +7,9 @@ Uploaders: Michael Stapelberg ,
Tianon Gravi 
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-golang/golang.git
 Vcs-Git: git://anonscm.debian.org/pkg-golang/golang.git
-Build-Depends: bison,
-   debhelper (>= 7.4.10),
-   ed,
+Build-Depends: debhelper (>= 7.4.10),
golang-go (>= 2:1.4.2-2~) | gccgo-5,
-   mawk | awk,
-   netbase,
-   perl
+   netbase
 Standards-Version: 3.9.6
 Homepage: https://golang.org
 

Bug#807294: golang-go: contains some but not all race-enabled packages

[Michael Hudson-Doyle]

Here's a patch that removes the race enabled packages, which I'm
planning to include in Ubuntu.

On 7 December 2015 at 20:13, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> Package: golang-go
> Version: 1.5.1-4
> Severity: normal
>
> Dear Maintainer,
>
> As you can see on https://packages.debian.org/sid/amd64/golang-go/filelist
> there are quite a few race-enabled package .a files included in the package.
> They are there because of the race-testing ./run.bash does. I think it's a bit
> silly that a subset of such packages are installed: either all of them should
> be installed (this is what the 1.4 packaging did I think), or none of them.
> apart from anything else, this means that if DEB_BUILD_OPTIONS=nocheck 
> actually
> worked (see bug 807290 ), the files included in the package would change
> depending on whether DEB_BUILD_OPTIONS=nocheck was set or not, which seems 
> like
> a bad thing to me.
>
> Happy to implement either option if given an opinion!
>
> Cheers,
> mwh
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.2.0-18-generic (SMP w/4 CPU cores)
> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=locale: Cannot set 
> LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
diff --git a/debian/rules b/debian/rules
index 268db73..5edcfd6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,10 @@ ifeq (true, $(RUN_TESTS))
 		export PATH="$(GOROOT)/bin:$$PATH"; \
 		eval "$$(go tool dist env)"; \
 		bash run.bash --no-rebuild;
+	# On linux/amd64 run.bash installs some race enabled standard library
+	# packages. Delete them again to avoid accidentally including them in
+	# the package.
+	rm -rf "$(GOROOT)/pkg/*_race"
 else
 	# skip the tests on platforms where they fail
 endif

Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

[Michael Hudson-Doyle]

Package: golang-src
Version: 1.5.1-4
Severity: normal

Dear Maintainer,

The files installed as /usr/share/go/src/runtime/race/*.syso are not built
during package build, but rather come directly from the Go source distribution.
To ensure that they are built from what they claim to be, in Ubuntu we do not
distribute these files in the golang-src package but rather build them in a
separate golang-race-detector-runtime package which golang-go Recommends:. It
would be nice if Debian could steal this work :-)

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#807294: golang-go: contains some but not all race-enabled packages

[Michael Hudson-Doyle]

And another one after I remember that make is not shell :/

On 9 December 2015 at 14:09, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> Here's a patch that removes the race enabled packages, which I'm
> planning to include in Ubuntu.
>
> On 7 December 2015 at 20:13, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> Package: golang-go
>> Version: 1.5.1-4
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> As you can see on https://packages.debian.org/sid/amd64/golang-go/filelist
>> there are quite a few race-enabled package .a files included in the package.
>> They are there because of the race-testing ./run.bash does. I think it's a 
>> bit
>> silly that a subset of such packages are installed: either all of them should
>> be installed (this is what the 1.4 packaging did I think), or none of them.
>> apart from anything else, this means that if DEB_BUILD_OPTIONS=nocheck 
>> actually
>> worked (see bug 807290 ), the files included in the package would 
>> change
>> depending on whether DEB_BUILD_OPTIONS=nocheck was set or not, which seems 
>> like
>> a bad thing to me.
>>
>> Happy to implement either option if given an opinion!
>>
>> Cheers,
>> mwh
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.2.0-18-generic (SMP w/4 CPU cores)
>> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=locale: Cannot set 
>> LC_CTYPE to default locale: No such file or directory
>> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
>> locale: Cannot set LC_ALL to default locale: No such file or directory
>> ANSI_X3.4-1968)
>> Shell: /bin/sh linked to /bin/dash
>> Init: unable to detect
diff --git a/debian/rules b/debian/rules
index 268db73..7093818 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,10 @@ ifeq (true, $(RUN_TESTS))
 		export PATH="$(GOROOT)/bin:$$PATH"; \
 		eval "$$(go tool dist env)"; \
 		bash run.bash --no-rebuild;
+	# On linux/amd64 run.bash installs some race enabled standard library
+	# packages. Delete them again to avoid accidentally including them in
+	# the package.
+	rm -rf "$(GOROOT)/pkg/linux_amd64_race/"
 else
 	# skip the tests on platforms where they fail
 endif

Bug#734357:

[Michael Hudson-Doyle]

FWIW, this bug is fixed properly upstream in git tip and will be part of 1.6.

Bug#784926:

[Michael Hudson-Doyle]

I don't think this bug is relevant any more with the changes in 1.5 packaging?

Bug#818415: [pkg-golang-devel] Bug#818415: Bug#818415: golang: move to per-Go-major version coinstallable packages

[Michael Hudson-Doyle]

Yay thanks for getting this done. Now we can look at 1.6.2, 1.7~beta1,
shipping the standard library as PIE...

On 3 June 2016 at 01:24, Tianon Gravi <admwig...@gmail.com> wrote:
> On 31 May 2016 17:12, "Michael Hudson-Doyle" <michael.hud...@canonical.com>
> wrote:
>> > All these tests succeeded as far as I can tell. So can someone either
>> > upload the new packages or tell me what else to test please? :)
>>
>> As there has been a deafening silence after this, I'm going to say
>> that if there is no more comment in the next 7 days, I'm going to
>> (fast-forward) merge the debian-sid-coinst branch of
>> pkg-golang/golang.git to debian-sid and get vorlon to upload it and
>> the master branch of pkg-golang/golang-defaults.git.
>
> We're accepted now!  You rock, Michael; thanks for your work on this, and
> sorry for my delay in reviewing it.
>
> - Tianon

Bug#827219: [pkg-go] Bug#827219: Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

On 15 June 2016 at 17:40, Dmitry Smirnov <only...@debian.org> wrote:
> On Wednesday, 15 June 2016 9:55:34 AM AEST Michael Hudson-Doyle wrote:
>> Where can I get docker.io_1.11.1~ds1.orig.tar.{bz2,gz,lzma,xz} ?
>
> ?? Is something wrong with "uscan"?
>
> You should be able to generate tarball by something like:
>
> uscan --destdir=. --compression xz --repack --download-current-version

Just unfamiliarity! Thanks for the tip.

Bug#827219: [pkg-go] Bug#827219: Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

On 15 June 2016 at 20:36, Dmitry Smirnov <only...@debian.org> wrote:
> On Wednesday, 15 June 2016 8:26:43 PM AEST Michael Hudson-Doyle wrote:
>> Ah, good point. Fix for that push to the bug-827219 branch, tested
>> with docker with reasonable-seeming results. Merge to master and
>> upload if it looks good to you?
>
> Yes, let's upload please. Unfortunately I don't have time to review code or
> do more extensive testing now... However providing that you respond to bugs
> so promptly I'm confident that you will rapidly fix whatever regressions is
> introduced (if any).  :))

OK, I've pushed to master, but I can't upload (my Debian Maintainer
application is stuck in the usual Debian limbo).

Cheers,
mwh

Bug#827219: [pkg-go] Bug#827219: Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

On 15 June 2016 at 19:57, Dmitry Smirnov <only...@debian.org> wrote:
> On Tuesday, 14 June 2016 4:19:59 PM AEST Michael Hudson-Doyle wrote:
>> Oh, sorry, I see that the failure is when building something that
>> depends on golang-google-cloud. I don't have time to test it now, but
>> I have pushed a proposed fix to
>> https://anonscm.debian.org/cgit/pkg-go/packages/dh-golang.git/log/?h=bug-82
>> 7219. I'd be interested to hear if it helps!
>
> It works better now but when I built docker.io/experimental "golang-google-
> cloud" appeared twice in "misc:Built-Using" so I think it needs de-
> duplication...

Ah, good point. Fix for that push to the bug-827219 branch, tested
with docker with reasonable-seeming results. Merge to master and
upload if it looks good to you?

Cheers,
mwh

Bug#827219: [pkg-go] Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

I guess it would be better to feed the source files rather than the
directory to dpkg-source.

On 14 June 2016 at 08:36, Dmitry Smirnov  wrote:
> Package: dh-golang
> Version: 1.17
> Severity: normal
> Control: affects -1 docker.io
>
> dh_golang invocation fails on "golang-google-cloud" as follows:
>
> 
> dpkg-query: no packages found matching 
> golang-google-cloud-compute-metadata-dev,
> dpkg-query -W failed with code 31488,  at /usr/bin/dh_golang line 72.
> 
>
> because it tries to process the following data:
>
> 
> golang-google-cloud-compute-metadata-dev, golang-google-cloud-dev: 
> /usr/share/gocode/src/google.golang.org/cloud
> golang-google-cloud-compute-metadata-dev: 
> /usr/share/gocode/src/google.golang.org/cloud/compute/metadata
> golang-google-cloud-compute-metadata-dev, golang-google-cloud-dev: 
> /usr/share/gocode/src/google.golang.org/cloud/internal
> 
>
> Assuming only one package per directory instead of a list.
>
> Also I wish troubleshooting could be improved to print command
> and/or the data (or possibly leave temporary file behind on abort).
>
> Thanks.
>
> --
> Regards,
>  Dmitry Smirnov
>  GPG key : 4096R/53968D1B
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#827219: [pkg-go] Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

While this bug report makes sense, I can't reproduce the problem. Does
it only fail on some version of golang-google-cloud in git that you
haven't pushed to alioth or something? I'll try to code up a fix but
it would be nice to test that it actually helps.

Bug#827219: [pkg-go] Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

Oh, sorry, I see that the failure is when building something that
depends on golang-google-cloud. I don't have time to test it now, but
I have pushed a proposed fix to
https://anonscm.debian.org/cgit/pkg-go/packages/dh-golang.git/log/?h=bug-827219.
I'd be interested to hear if it helps!

Bug#827226: [pkg-go] Bug#827226: incorrect preparation of build directory when pre-installed package is re-built

[Michael Hudson-Doyle]

On 14 June 2016 at 10:11, Dmitry Smirnov  wrote:
> Package: dh-golang
> Version: 1.17
> Severity: normal
>
> --buildsystem=golang does a nice job preparing build directory in
> `dh_auto_configure` by symlinking source packages from under
> "/usr/share/gocode/src" to directory specified with "--builddirectory"
> argument.
>
> However it works incorrectly when $(DH_GOPKG) package (i.e. current package
> to build) is pre-installed because in such case installed and new version of
> the package are merged in build directory.
>
> Suppose you are building a "golang-github-foo-bar" package which no longer
> provides "github.com/foo/bar/obsolete-feature". If previous version of the
> package is installed then dh_golang incorrectly symlink
> "/usr/share/gocode/src/github.com/foo/bar/obsolete-feature" into build
> directory.

Ah heh, yes I can see how this would be very confusing to debug.

> This problem should be easy to detect and avoid as dh_golang already knows
> which package not to link from $(DH_GOPKG) or XS-Go-Import-Path header.
> I suppose we just need to ignore/skip pre-installed package which is build.

Should be easy enough.

> Also it would be nice to produce a warning to notify maintainer about
> potential problem.

If the problem is fixed as you describe, I'm not sure what the point
of the warning would be?

Cheers,
mwh

> Arguably circular dependencies are not in scope of what dh_golang should be
> doing but there are cases when package can be re-built (staged) on
> maintainer's machine in presence of previous version of the same package.
> Correct handling of such situations would be useful.
>
> Thanks.
>
> --
> Regards,
>  Dmitry Smirnov
>  GPG key : 4096R/53968D1B
>
> ---
>
> Truth — Something somehow discreditable to someone.
> -- H. L. Mencken, 1949
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#818415: [pkg-golang-devel] Bug#818415: golang: move to per-Go-major version coinstallable packages

[Michael Hudson-Doyle]

> All these tests succeeded as far as I can tell. So can someone either
> upload the new packages or tell me what else to test please? :)

As there has been a deafening silence after this, I'm going to say
that if there is no more comment in the next 7 days, I'm going to
(fast-forward) merge the debian-sid-coinst branch of
pkg-golang/golang.git to debian-sid and get vorlon to upload it and
the master branch of pkg-golang/golang-defaults.git.

Bug#827219: [pkg-go] Bug#827219: dh-golang: Built-Using calculation crashes on "golang-google-cloud"

[Michael Hudson-Doyle]

On 15 June 2016 at 02:00, Dmitry Smirnov <only...@debian.org> wrote:
> Hi Michael,
>
> Thanks for looking into the problem.
>
> On Tuesday, 14 June 2016 3:45:35 PM AEST Michael Hudson-Doyle wrote:
>> While this bug report makes sense, I can't reproduce the problem. Does
>> it only fail on some version of golang-google-cloud in git that you
>> haven't pushed to alioth or something? I'll try to code up a fix but
>> it would be nice to test that it actually helps.
>
> Please try building docker.io from "experimental" branch.

Where can I get docker.io_1.11.1~ds1.orig.tar.{bz2,gz,lzma,xz} ?

Bug#827697: [pkg-go] Bug#827697: Bug#827697: golang-github-shirou-gopsutil: Please update to latest release

[Michael Hudson-Doyle]

Built-Using only makes sense for a package that ships binaries.

Bug#827928: [pkg-go] Bug#827928: golang-github-coreos-go-systemd-dev: circular dependency with golang-github-coreos-pkg-dev

[Michael Hudson-Doyle]

Indeed, I ran into this too:
http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160620/005631.html
and https://github.com/coreos/go-systemd/issues/183 and
https://github.com/coreos/pkg/issues/73. The good news is that
upstream seem to agree this is a problem...

On 23 June 2016 at 07:34, Bill Allombert  wrote:
> Package: golang-github-coreos-go-systemd-dev
> Version: 9-1
> Severity: important
>
> Hello Debian Go Packaging Team,
>
> There is a circular dependency between
> golang-github-coreos-go-systemd-dev and golang-github-coreos-pkg-dev:
>
> golang-github-coreos-go-systemd-dev :Depends: golang-github-coreos-pkg-dev
> golang-github-coreos-pkg-dev:Depends: 
> golang-github-coreos-go-systemd-dev
>
> Circular dependencies are known to cause problems during upgrade, so we
> should try to avoid them.
>
> See threads
> http://lists.debian.org/debian-devel/2005/06/msg02111.html
> http://lists.debian.org/debian-devel/2005/11/msg01101.html
>
> Cheers,
> --
> Bill. 
>
> Imagine a large red swirl here.
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#823014: [pkg-golang-devel] Bug#823014: golang: Package compiled stdlib for PIE build mode

[Michael Hudson-Doyle]

The change looks OK to me. Thanks for working on it!

I guess it would be good to get Tianon or Paul to look at it too
before pushing to master (we'll need one of them to upload it too, or
grant me the right to do it).

Cheers,
mwh

On 23 June 2016 at 12:01, Peter Colberg  wrote:
> Dear Debian Go compiler team,
>
> I have pushed commits for golang (pc/debian-sid) and golang-defaults
> (pc/master) that each add a package with the compiled Go stdlib for
> building position-independent executables.
>
> Please review the proposed changes before I push to master, and feel
> free to suggest a package name other than golang-X.Y-pie-dev.
>
> You can test PIE mode with the attached patch for acmetool, e.g.,
>
>   gbp clone https://anonscm.debian.org/git/letsencrypt/acmetool.git
>   cd acmetool && pristine-tar checkout acmetool_0.0.51.orig.tar.gz
>   git am acmetool-build-with-pie-and-bindnow-hardening-flags.patch
>
>   sbuild --extra-package=../golang-1.6-pie-dev_1.6.2-1_amd64.deb 
> --extra-package=../pkg-golang/golang-pie-dev_1.6.1+1_amd64.deb
>
> Note the absent lintian warnings hardening-no-pie/hardening-no-bindnow.
>
> Once PIE-mode stdlib is in the archive, I will adapt dh-golang to
> support DEB_BUILD_MAINT_OPTIONS = hardening=+all in debian/rules.
>
> Regards,
> Peter
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#776401: [pkg-golang-devel] Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

[Michael Hudson-Doyle]

On 4 February 2016 at 02:12, Hilko Bengen  wrote:
> * Tianon Gravi:
>
>> I'm not positive whether all were required for this to work, but given
>> that it _did_ work, I think this is in the realm of possible with the
>> changes of Go 1.5 and am inclined to close this bug as "fixed" --
>> thoughts? :)
>
> Unfortunately, it's not that easy. :-(
>
> Last time I checked, I was able to "go build" a package from $GOPATH,
> but not "go install" because "go install" wanted to install the
> cross-built standard library for the other architecture to $GOROOT, even
> if no CGO was involved. This is still the case with golang 2:1.5.3-1.

There is no getting around the fact that this is a consequence of the
way the golang packaging is done since 1.5.

I guess it could be fixed by going back to building lots of
golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
appealing, it would be nicer to allow the go install command to work
(which would also allow the user to use their choice of toolchain for
cgo, etc). But I don't know how to do that. Have a per-user overlayfs
over /usr/lib/go and set GOROOT to that? (not a serious suggestion!)

Cheers,
mwh

Bug#776401: [pkg-golang-devel] Bug#776401: Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

[Michael Hudson-Doyle]

On 12 February 2016 at 12:44, Tianon Gravi <admwig...@gmail.com> wrote:
> On 4 February 2016 at 16:56, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> I guess it could be fixed by going back to building lots of
>> golang-$GOOS-$GOARCH packages, but somehow that doesn't seem very
>> appealing, it would be nicer to allow the go install command to work
>> (which would also allow the user to use their choice of toolchain for
>> cgo, etc). But I don't know how to do that. Have a per-user overlayfs
>> over /usr/lib/go and set GOROOT to that? (not a serious suggestion!)
>
> IMO at this point, anything writing to GOROOT on "go install" ought to
> be considered an upstream bug. :(

I'm not sure I want to be the one that takes that one upstream.

> Any chance of tracking down what's causing those to try to go to
> GOROOT instead of GOPATH?

It's the standard library packages, GOARCH=arm go install runtime is
going to try to create $GOROOT/pkg/linux_arm/runtime.a.

Cheers,
mwh

Bug#807294: golang-go: contains some but not all race-enabled packages

[Michael Hudson-Doyle]

On 3 February 2016 at 19:02, Tianon Gravi  wrote:
>> + # On linux/amd64 run.bash installs some race enabled standard library
>> + # packages. Delete them again to avoid accidentally including them in
>> + # the package.
>> + rm -rf "$(GOROOT)/pkg/linux_amd64_race/"
>
> This seems like the most correct solution to me, but I'm a little
> confused about why we're hard-coding "linux_amd64" here -- shouldn't
> this be "$(GOOS)_$(GOARCH)" so that it's whatever architecture we
> build on?  Or perhaps "$(GOROOT)"/pkg/*_race/ ?

It's because the race detector is only supported on amd64 (and I
alternate between forgetting about and not caring about
Debian/kFreeBSD, I guess). GOOS and GOARCH are not defined in
debian/rules any more, but I guess we could shell out to go tool dist
env like the invocation of run.bash does. I tried to use the wildcard
at first but it's annoying because make is not shell. Attaching a new,
slightly cleaner, patch.

Cheers,
mwh
diff --git a/debian/rules b/debian/rules
index ae235c7..e7d994c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,13 @@ ifeq (true, $(RUN_TESTS))
 		export PATH="$(GOROOT)/bin:$$PATH"; \
 		eval "$$(go tool dist env)"; \
 		bash run.bash --no-rebuild;
+	# On linux/amd64 run.bash installs some race enabled standard library
+	# packages. Delete them again to avoid accidentally including them in
+	# the package.
+	set -ex; \
+		export PATH="$(GOROOT)/bin:$$PATH"; \
+		eval "$$(go tool dist env)"; \
+		rm -rf "$(GOROOT)/pkg/$${GOOS}_$${GOARCH}_race/"
 else
 	# skip the tests on platforms where they fail
 endif

Bug#734357: [pkg-golang-devel] Bug#734357:

[Michael Hudson-Doyle]

Well,

On 3 February 2016 at 20:41, Tianon Gravi <admwig...@gmail.com> wrote:
> On 15 December 2015 at 13:32, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> FWIW, this bug is fixed properly upstream in git tip and will be part of 1.6.
>
> Nice! :D
>
> The upstream fix applies cleanly against Go 1.5 -- do you think it's
> important enough to include now, or just wait for Go 1.6 to be GA
> (which will be soon anyways)?

TBH, I'm a bit vague about what problems exactly this bug actually
caused (even though I spent half a week fixing it!). So I guess that's
a shrug from me -- if it's not causing active problems and 1.6 is, as
you say, around the corner, I'd just as soon leave it out.

Cheers,
mwh

Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

[Michael Hudson-Doyle]

On 3 February 2016 at 19:08, Tianon Gravi <tia...@debian.org> wrote:
> On 8 December 2015 at 18:24, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> The files installed as /usr/share/go/src/runtime/race/*.syso are not built
>> during package build, but rather come directly from the Go source 
>> distribution.
>> To ensure that they are built from what they claim to be, in Ubuntu we do not
>> distribute these files in the golang-src package but rather build them in a
>> separate golang-race-detector-runtime package which golang-go Recommends:. It
>> would be nice if Debian could steal this work :-)
>
> I'm definitely keen on this one!

Yay.

> I think my issue with making it happen (last I looked into it) was
> that the files in question needed to come from a separate source (LLVM
> was it? [1]), and the exact versioning necessary was a little strange,
> and it was sources that already exist in the Debian archive for
> another package so I wasn't really clear on whether that's kosher or
> whether we should be talking to the existing package maintainer to
> keep things sane.  Am I remembering this correctly?

Yes, your memory is pretty accurate. The source in question is the
"compiler-rt" runtime libraries: http://compiler-rt.llvm.org/. The
compiler-rt source is copied into the gcc and llvm trees -- although
on checking, the copy in the gcc source lacks the go integration bits.
The one in llvm-toolchain appears to have everything (in fact it's a
multi orig source package, and one of the orig tarballs is the
compiler-rt stuff), so the golang-race-detector-runtime could be built
from the llvm-toolchain source package. The only question is around
versioning then -- I don't have any intuition as to how much
difference there is between the revisions go builds they're objects
from and the revision for the compiler-rt that's part of the current
llvm package at all. I've just wussed out of thinking about that so
far. I guess I could ask upstream...

Cheers,
mwh

>  I really
> should've made some notes after I spent some time playing with this,
> sorry. :(
>
> [1]: https://github.com/golang/go/tree/go1.6rc1/src/runtime/race#readme
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#776401: [pkg-golang-devel] Bug#776401: Bug#776401: Bug#776401: Bug#776401: [Pkg-golang-devel] Bug#776401: Bug#776401: src:golang: Set CGO_ENABLED for all platforms

[Michael Hudson-Doyle]

On 16 February 2016 at 11:13, Tianon Gravi <tia...@debian.org> wrote:
> On 11 February 2016 at 17:50, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> It's the standard library packages, GOARCH=arm go install runtime is
>> going to try to create $GOROOT/pkg/linux_arm/runtime.a.
>
> This still seems odd to me, especially since doing "GOARCH=arm go
> build -v my/own/package" clearly does build "runtime" for arm (since
> it doesn't exist already), but I suppose it doesn't save it anywhere?
> I would still expect that to go to GOPATH/pkg/linux_arm/... but am not
> necessarily surprised that it doesn't. :(

Totally random thought, but could multiarch help here? Something like
changing packaging so golang-go includes tools and a new golang-stdlib
package contains what's now in /usr/lib/go/pkg/$GOOS_$GOARCH, and then
you install golang-stdlib:armhf to get the GOARCH=arm stuff installed.
(Not sure how you'd do non-linux GOOS in this model though).

Otherwise, I'd be happy to ask golang-dev what they think about the
general problem.

Cheers,
mwh

Bug#818320: golang-golang-x-tools: FTBFS with go 1.6

[Michael Hudson-Doyle]

Source: golang-golang-x-tools
Version: 1:0.0~git20151026.0.0f9d71c-2
Severity: serious
Tags: patch
Justification: Policy 4.9

Dear Maintainer,

The version of golang/x/tools in the archive currently fails tests with Go 1.6 
and fails to build.

Updating to a new upstream snapshot should fix this.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-30-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#818320: golang-golang-x-tools: FTBFS with go 1.6

[Michael Hudson-Doyle]

There's a debdiff at
http://people.canonical.com/~mwh/golang-golang-x-tools_0.0~git20151026.0.0f9d71c-2_0.0~git20160315.0.f42ec61-1.diff
which is rather large, or you can grab the new stuff from
https://github.com/mwhudson/golang-go.tools (or you can approve my
request to join pkg-go on alioth :-p)

Cheers,
mwh

On 16 March 2016 at 10:51, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> Source: golang-golang-x-tools
> Version: 1:0.0~git20151026.0.0f9d71c-2
> Severity: serious
> Tags: patch
> Justification: Policy 4.9
>
> Dear Maintainer,
>
> The version of golang/x/tools in the archive currently fails tests with Go 
> 1.6 and fails to build.
>
> Updating to a new upstream snapshot should fix this.
>
> Cheers,
> mwh
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers wily-updates
>   APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
> (100, 'wily-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.2.0-30-generic (SMP w/4 CPU cores)
> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Bug#818551: [pkg-go] Bug#818551: golang-golang-x-tools: provides same file '/usr/bin/bundle' as ruby-bundler

[Michael Hudson-Doyle]

Oops, pushed a fix to git, will need Tianon or someone to upload.

On 18 March 2016 at 11:32, Sven Hartge  wrote:
> Package: golang-golang-x-tools
> Version: 1:0.0~git20160315.0.f42ec61-1
> Severity: serious
> Justification: Policy 10.1
>
> Hi!
>
> The subject says it all:
>
> The following packages will be upgraded:
>   golang-golang-x-tools
> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/14.8 MB of archives. After unpacking 15.9 MB will be used.
> Do you want to continue? [Y/n/?]
> (Reading database ... 746195 files and directories currently installed.)
> Preparing to unpack 
> .../golang-golang-x-tools_1%3a0.0~git20160315.0.f42ec61-1_amd64.deb ...
> Unpacking golang-golang-x-tools (1:0.0~git20160315.0.f42ec61-1) over 
> (1:0.0~git20151026.0.0f9d71c-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20160315.0.f42ec61-1_amd64.deb
>  (--unpack):
>  trying to overwrite '/usr/bin/bundle', which is also in package ruby-bundler 
> 1.11.2-1
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Processing triggers for man-db (2.7.5-1) ...
> Errors were encountered while processing:
>  
> /var/cache/apt/archives/golang-golang-x-tools_1%3a0.0~git20160315.0.f42ec61-1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Grüße,
> Sven
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (400, 'testing'), 
> (100, 'experimental'), (1, 'experimental-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.4.0-1-amd64 (SMP w/12 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages golang-golang-x-tools depends on:
> ii  golang-golang-x-tools-dev  1:0.0~git20160315.0.f42ec61-1
> ii  libc6  2.22-3
>
> golang-golang-x-tools recommends no packages.
>
> golang-golang-x-tools suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#818415: golang: move to per-Go-major version coinstallable packages

[Michael Hudson-Doyle]

Source: golang
Version: 2:1.6-1
Severity: wishlist

Dear Maintainer,

To make maintenance of Go easier in the future, it would be good to allow major
versions of Go to be co-installed (like gcc-4.9, gcc-5, etc). The plan goes
something like this:

 1) convert existing golang source package to golang-1.6 source package,
removing version independent things like the man pages and management of
/usr/bin/go, changed to install to version dependent paths (/usr/lib/go-1.6
etc)

 2) create a golang-defaults package that contains this version independent
stuff and links /usr/bin/go to the appropriate version

 3) update gccgo-5 and gccgo-6 packages to stop providing an alternative for
'go'.

The motivation for this is to allow us to upload pre-release versions of Go
without making them the default, to be more compatible with an externl
(possibly Google-hosted) archive that provides newer versions of Go and, if
necessary, to allow us to make newer versions of Go available to stable
releases without having to conflict with the version of Go in that release.

I have prepared packages for Ubuntu that implement this which can be found at

https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/log/?h=ubuntu-xenial-coinstallability-2

and

https://git.launchpad.net/~mwhudson/+git/golang-defaults

They're mostly appropriate for Debian, although not entirely. The changes
required are simple.

Cheers,
mwh

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-34-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#818651: [pkg-golang-devel] Bug#818651: golang: cannot use net package without CGO

[Michael Hudson-Doyle]

Hi,

On 19 March 2016 at 22:03, Ayke van Laethem  wrote:
> Package: golang
> Version: 2:1.6-1
> Severity: normal
>
> Dear Maintainer,
>
> Golang 1.3 (jessie) can build this file just fine without CGO, but golang 1.5
> and 1.6 throws an error:
>
> package main
>
> import (
> "fmt"
> "net"
> )
>
> func main() {
> fmt.Println("HostPort:", net.JoinHostPort("google.com", "80"))
> }
>
> To reproduce, compile this with the environment variable CGO_ENABLED=0. It
> fails with golang 1.5 (jessie-backports) and golang 1.6 (testing) but succeeds
> in golang 1.3 (jessie).

Well. It _succeeds_ in that it produces an executable without error in
jessie, but it does not actually _work_ in the sense that the
executable thus produced still uses cgo:

root@figurable-tamatha:~# CGO_ENABLED=0 go install  nocgo
root@figurable-tamatha:~# ldd gopath/bin/nocgo
linux-vdso.so.1 (0x7ffea37fb000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbbf1bcc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbbf1821000)
/lib64/ld-linux-x86-64.so.2 (0x55b2c0397000)

so I don't think reverting to the behaviour of the 1.3 packaging (even
if it were possible) would actually be a good idea :-)

This is all because Go <1.4 never rebuilt the standard library in the
usual course of things even when it arguably should, like here.

> The exact (but cryptic) error reported is:
>
> go install net: open /usr/lib/go/pkg/linux_amd64/net.a: permission denied
>
> Since Go 1.2 (according to the docs [1]) it should be possible to use the net
> package without CGO on some systems.
> My system is linux-amd64 (one with jessie and one with testing).

You can build the executable, but you have to use 'go build' and not
'go install'.

This is all reminiscent of the conversation after
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776401#27 although
it's a bit worse than that because the set up here really wants to
replace GOROOT/pkg/linux_amd64/net.a, not install another one.

Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

[Michael Hudson-Doyle]

Dmitry Vyukov ("Mr. Race Detector") said this:


The latest Go release _should_ work with llvm tip (where latest means
the latest in development, not the latest released). This is not
necessary true for the previous releases as interfaces may have
changed. There can also be temporal inconsistencies. Your best bet
would be the revision stored in src/runtime/race/README, as it is
versioned with Go source tree. Then you need some comprehensive
testing of race detector. Then the result should be usable.


So um. We could build the race detector from llvm-snapshot packaging
maybe? Or just packaging another copy of the source...

Cheers,
mwh

On 22 March 2016 at 15:00, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 3 February 2016 at 21:04, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> On 3 February 2016 at 19:08, Tianon Gravi <tia...@debian.org> wrote:
>>> On 8 December 2015 at 18:24, Michael Hudson-Doyle
>>> <michael.hud...@canonical.com> wrote:
>>>> The files installed as /usr/share/go/src/runtime/race/*.syso are not built
>>>> during package build, but rather come directly from the Go source 
>>>> distribution.
>>>> To ensure that they are built from what they claim to be, in Ubuntu we do 
>>>> not
>>>> distribute these files in the golang-src package but rather build them in a
>>>> separate golang-race-detector-runtime package which golang-go Recommends:. 
>>>> It
>>>> would be nice if Debian could steal this work :-)
>>>
>>> I'm definitely keen on this one!
>>
>> Yay.
>>
>>> I think my issue with making it happen (last I looked into it) was
>>> that the files in question needed to come from a separate source (LLVM
>>> was it? [1]), and the exact versioning necessary was a little strange,
>>> and it was sources that already exist in the Debian archive for
>>> another package so I wasn't really clear on whether that's kosher or
>>> whether we should be talking to the existing package maintainer to
>>> keep things sane.  Am I remembering this correctly?
>>
>> Yes, your memory is pretty accurate. The source in question is the
>> "compiler-rt" runtime libraries: http://compiler-rt.llvm.org/. The
>> compiler-rt source is copied into the gcc and llvm trees -- although
>> on checking, the copy in the gcc source lacks the go integration bits.
>> The one in llvm-toolchain appears to have everything (in fact it's a
>> multi orig source package, and one of the orig tarballs is the
>> compiler-rt stuff), so the golang-race-detector-runtime could be built
>> from the llvm-toolchain source package. The only question is around
>> versioning then -- I don't have any intuition as to how much
>> difference there is between the revisions go builds they're objects
>> from and the revision for the compiler-rt that's part of the current
>> llvm package at all. I've just wussed out of thinking about that so
>> far. I guess I could ask upstream...
>
> I've finally gotten around to asking on golang-dev:
> https://groups.google.com/d/msg/golang-dev/7tmyNA9Dx6s/j_j3b7SKBQAJ
>
> Cheers,
> mwh

Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

[Michael Hudson-Doyle]

On 3 February 2016 at 21:04, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 3 February 2016 at 19:08, Tianon Gravi <tia...@debian.org> wrote:
>> On 8 December 2015 at 18:24, Michael Hudson-Doyle
>> <michael.hud...@canonical.com> wrote:
>>> The files installed as /usr/share/go/src/runtime/race/*.syso are not built
>>> during package build, but rather come directly from the Go source 
>>> distribution.
>>> To ensure that they are built from what they claim to be, in Ubuntu we do 
>>> not
>>> distribute these files in the golang-src package but rather build them in a
>>> separate golang-race-detector-runtime package which golang-go Recommends:. 
>>> It
>>> would be nice if Debian could steal this work :-)
>>
>> I'm definitely keen on this one!
>
> Yay.
>
>> I think my issue with making it happen (last I looked into it) was
>> that the files in question needed to come from a separate source (LLVM
>> was it? [1]), and the exact versioning necessary was a little strange,
>> and it was sources that already exist in the Debian archive for
>> another package so I wasn't really clear on whether that's kosher or
>> whether we should be talking to the existing package maintainer to
>> keep things sane.  Am I remembering this correctly?
>
> Yes, your memory is pretty accurate. The source in question is the
> "compiler-rt" runtime libraries: http://compiler-rt.llvm.org/. The
> compiler-rt source is copied into the gcc and llvm trees -- although
> on checking, the copy in the gcc source lacks the go integration bits.
> The one in llvm-toolchain appears to have everything (in fact it's a
> multi orig source package, and one of the orig tarballs is the
> compiler-rt stuff), so the golang-race-detector-runtime could be built
> from the llvm-toolchain source package. The only question is around
> versioning then -- I don't have any intuition as to how much
> difference there is between the revisions go builds they're objects
> from and the revision for the compiler-rt that's part of the current
> llvm package at all. I've just wussed out of thinking about that so
> far. I guess I could ask upstream...

I've finally gotten around to asking on golang-dev:
https://groups.google.com/d/msg/golang-dev/7tmyNA9Dx6s/j_j3b7SKBQAJ

Cheers,
mwh

Bug#822395: [pkg-go] Bug#822395: Bug#822395: prometheus: FTBFS: cannot find package "golang.org/x/sys/unix"

[Michael Hudson-Doyle]

On 27 April 2016 at 05:42, Martín Ferrari  wrote:
> reassign 822395 golang-github-fsnotify-fsnotify-dev
> thanks
>
> On 24/04/16 02:24, Martin Michlmayr wrote:
>
>> This package fails to build in unstable:
>
>>> src/gopkg.in/fsnotify.v1/inotify.go:19:2: cannot find package 
>>> "golang.org/x/sys/unix" in any of:
>>>  /usr/lib/go/src/golang.org/x/sys/unix (from $GOROOT)
>>>  
>>> /<>/prometheus-0.18.0+ds/obj-x86_64-linux-gnu/src/golang.org/x/sys/unix
>>>  (from $GOPATH)
>
> This is actually a bug in fsnotify, introduced by me :) The dependency
> is present in build-depends, but not in the "binary" package.
>
> Will upload a fix asap.

Could/should dh_golang provide help for getting this right? It's kinda
similar to the work I did recently to make Built-Using more accurate
-- roughly speaking one needs the -dev package to Depend: on the
Debian packages corresponding to the Go packages reported by go list
-f '{{ .Imports }}' $DH_GOPKG/... I think?

(I'll try not to break the world so many times implementing the
feature this time :-p)

Cheers,
mwh

Bug#822668: Processed: cloning 822386, reassign -1 to dh-golang ..., severity of -1 is important

[Michael Hudson-Doyle]

On 26 April 2016 at 21:36, Ondřej Surý <ond...@debian.org> wrote:
> I am fine to do whatever you suggest, so just to make it right, I
> should:
>
> 1. remove dh-golang from Build-Depends

I guess this is not strictly necessary...

> 2. remove --with=golang from dh invocation

But once you've done this, you can and probably should do 1)

> 3. set 'misc:Built-Using=golang-github-abh-geoip-dev' by hand when on
> amd64

Yes. Unfortunately, as far as I know generating proper Built-Using
headers is more awkward than it should be. I think you want to do
something like:

 dpkg-query --showformat '${source:Package} (= ${source:Version}), '
--show golang-github-abh-geoip-dev >> debian/knot-resolver.substvars

(-buildmode=c-shared is supported on more architectures in Go 1.6, but
that's an entirely different thing :-)

Cheers,
mwh

> And that's it?
>
> Cheers,
> --
> Ondřej Surý <ond...@sury.org>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
>
> On Tue, Apr 26, 2016, at 11:29, Michael Hudson-Doyle wrote:
>> Hmm, that package just isn't going to work with the new way of
>> computing Built-Using in dh-golang. I don't want to change it back,
>> because it most ways the new way is better. Not sure what to suggest,
>> as there is only one golang-* build-dependency, maybe just do that by
>> hand?
>>
>> On 26 April 2016 at 21:12, Debian Bug Tracking System
>> <ow...@bugs.debian.org> wrote:
>> > Processing commands for cont...@bugs.debian.org:
>> >
>> >> clone 822386 -1
>> > Bug #822386 [knot-resolver] knot-resolver: FTBFS: can't load package: 
>> > package .: no buildable Go source files
>> > Bug 822386 cloned as bug 822668
>> >> reassign -1 dh-golang
>> > Bug #822668 [knot-resolver] knot-resolver: FTBFS: can't load package: 
>> > package .: no buildable Go source files
>> > Bug reassigned from package 'knot-resolver' to 'dh-golang'.
>> > No longer marked as found in versions 
>> > knot-resolver/1.0.0~beta3-31-g79a8440-1.
>> > Ignoring request to alter fixed versions of bug #822668 to the same values 
>> > previously set
>> >> retitle -1 dh-golang: makes packages FTBFS with 'no buildable Go source 
>> >> files'
>> > Bug #822668 [dh-golang] knot-resolver: FTBFS: can't load package: package 
>> > .: no buildable Go source files
>> > Changed Bug title to 'dh-golang: makes packages FTBFS with 'no buildable 
>> > Go source files'' from 'knot-resolver: FTBFS: can't load package: package 
>> > .: no buildable Go source files'.
>> >> severity -1 important
>> > Bug #822668 [dh-golang] dh-golang: makes packages FTBFS with 'no buildable 
>> > Go source files'
>> > Severity set to 'important' from 'serious'
>> >> thanks
>> > Stopping processing here.
>> >
>> > Please contact me if you need assistance.
>> > --
>> > 822386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822386
>> > 822668: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822668
>> > Debian Bug Tracking System
>> > Contact ow...@bugs.debian.org with problems
>> >

Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

I finally asked on golang-dev and Russ Cox pointed out the -pkgdir
argument to go install. This patch:

diff -Nru acmetool-0.0.49/debian/changelog acmetool-0.0.49/debian/changelog
--- acmetool-0.0.49/debian/changelog 2016-04-26 22:15:04.0 +1200
+++ acmetool-0.0.49/debian/changelog 2016-04-26 22:18:51.0 +1200
@@ -1,3 +1,9 @@
+acmetool (0.0.49-2) UNRELEASED; urgency=medium
+
+  * Everyone loves PIE
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Tue, 26 Apr
2016 22:18:34 +1200
+
 acmetool (0.0.49-1) unstable; urgency=medium

   * Initial release (Closes: #817091)
diff -Nru acmetool-0.0.49/debian/rules acmetool-0.0.49/debian/rules
--- acmetool-0.0.49/debian/rules 2016-04-26 22:15:04.0 +1200
+++ acmetool-0.0.49/debian/rules 2016-04-26 22:22:42.0 +1200
@@ -11,7 +11,7 @@
  dh $@ --buildsystem=golang --with=golang

 override_dh_auto_build:
- dh_auto_build -O--buildsystem=golang -- -ldflags "$(GO_LDFLAGS)"
+ dh_auto_build -O--buildsystem=golang -- -buildmode=pie
-pkgdir=$$(mktemp -d -p $(CURDIR)) -ldflags "$(GO_LDFLAGS)"

 override_dh_auto_install:
  dh_auto_install -O--buildsystem=golang

is obviously a bit of a hack but it seems to do approximately the right thing:

(master *)mwhudson@aeglos:/opt/opensource/deb/acmetool$ mkdir x
(master *)mwhudson@aeglos:/opt/opensource/deb/acmetool$ dpkg-deb -x
../acmetool_0.0.49-2_amd64.deb x
(master *)mwhudson@aeglos:/opt/opensource/deb/acmetool$
hardening-check x/usr/bin/acmetool
x/usr/bin/acmetool:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: no, not found!
 Immediate binding: no, not found!

(we could probably make dh-golang do something like this by default...)

Cheers,
mwh

On 19 April 2016 at 12:17, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> This is like the cross-compilation / CGO_ENABLED=0 situations:
>
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818651#10
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776401#27
>
> I still don't really know of a good answer. I've been meaning to ask
> upstream if they have any ideas about this, maybe I'll get around to
> this today :-)
>
> Cheers,
> mwh
>
> On 19 April 2016 at 07:06, Peter Colberg <pe...@colberg.org> wrote:
>> Package: dh-golang
>> Version: 1.15
>> Severity: normal
>>
>> Dear Debian Go team,
>>
>> In response to the lintian warning hardening-no-pie, I am trying to
>> build acmetool (#817091) as a position-independent executable (PIE).
>>
>> The Go compiler supports a -buildmode=pie since version 1.5.
>>
>> Building the package with this flag produces the following errror:
>>
>>   dpkg-buildpackage: source package acmetool
>>   dpkg-buildpackage: source version 0.0.49-1
>>   dpkg-buildpackage: source distribution unstable
>>dpkg-source --before-build acmetool-0.0.49
>>   dpkg-buildpackage: host architecture amd64
>>fakeroot debian/rules clean
>>   dh clean --buildsystem=golang --with=golang
>>  dh_testdir -O--buildsystem=golang
>>  dh_auto_clean -O--buildsystem=golang
>>  dh_clean -O--buildsystem=golang
>>dpkg-source -b acmetool-0.0.49
>>   dpkg-source: info: using source format '3.0 (quilt)'
>>   dpkg-source: info: building acmetool using existing 
>> ./acmetool_0.0.49.orig.tar.gz
>>   dpkg-source: info: building acmetool in acmetool_0.0.49-1.debian.tar.xz
>>   dpkg-source: info: building acmetool in acmetool_0.0.49-1.dsc
>>debian/rules build
>>   dh build --buildsystem=golang --with=golang
>>  dh_testdir -O--buildsystem=golang
>>  dh_update_autotools_config -O--buildsystem=golang
>>  dh_auto_configure -O--buildsystem=golang
>>  debian/rules override_dh_auto_build
>>   make[1]: Entering directory '/<>'
>>   dh_auto_build -O--buildsystem=golang -- -buildmode=pie -ldflags "-X 
>> github.com/hlandau/acme/hooks.DefaultPath=/etc/ac
>> +me
>>   go install -v -buildmode=pie -ldflags "-X 
>> github.com/hlandau/acme/hooks.DefaultPath=/etc/acme/hooks -X github
>> +.ci github.com/hlandau/acme/acmeapi/acmeendpoints 
>> github.com/hlandau/acme/acmeapi/acmeutils
>> +github.com/hlandau/acme/cmd/a/acme/redirector 
>> github.com/hlandau/acme/responder github.com/hlandau/acme/solver
>> +github.com/hlandau/acme/storage githu
>>   runtime/internal/sys
>>   go install runtime/internal/sys: mkdir /usr/lib/go/pkg/linux_amd64_shared: 
>> permission denied
>>   dh_auto_build: go install -v -buildmode=pie -ldflags -X 
>> github.com/hlandau/acme/hooks.DefaultPath=/etc/acme/hooks -X
>> +gicmeapi github.com/hla

Bug#818651: [pkg-golang-devel] Bug#818651: Bug#818651: golang: cannot use net package without CGO

[Michael Hudson-Doyle]

On 20 March 2016 at 21:08, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:

>
>> The exact (but cryptic) error reported is:
>>
>> go install net: open /usr/lib/go/pkg/linux_amd64/net.a: permission denied
>>
>> Since Go 1.2 (according to the docs [1]) it should be possible to use the net
>> package without CGO on some systems.
>> My system is linux-amd64 (one with jessie and one with testing).
>
> You can build the executable, but you have to use 'go build' and not
> 'go install'.
>
> This is all reminiscent of the conversation after
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776401#27 although
> it's a bit worse than that because the set up here really wants to
> replace GOROOT/pkg/linux_amd64/net.a, not install another one.

I finally mentioned this on the upstream list and Russ Cox pointed out
that you can use the -pkgdir argument to the go tool here, you can do
something like go install -pkgdir ~/.gopkgdir instead of plain go
install.

Cheers,
mwh

Bug#776401: [pkg-golang-devel] Bug#776401: src:golang: Set CGO_ENABLED for all platforms

[Michael Hudson-Doyle]

I finally mentioned this on the upstream list and Russ Cox pointed out
that you can use the -pkgdir argument to the go tool here, you can do
something like go install -pkgdir ~/.gopkgdir instead of plain go
install.

Cheers,
mwh

Bug#822746: [pkg-golang-devel] Bug#822746: golang: Add golang-any dependency package to install either golang-go or gccgo

[Michael Hudson-Doyle]

On 27 April 2016 at 17:57, Anthony Fok <f...@debian.org> wrote:
> On Wed, Apr 27, 2016 at 12:56 PM, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> On 27 April 2016 at 16:27, Anthony Fok <f...@debian.org> wrote:
>>> As per discussion at https://github.com/Debian/dh-make-golang/pull/36
>>> on GitHub, it was decided that a golang-any package should be created
>>> in src:golang instead, so for Go program-type packages that need it,
>>> a simple "Build-Depends: golang-any" suffices in providing the default
>>> Go compiler for each architecture.
>>
>> I've actually done this in Ubuntu as part of the work I did to create
>> separate coinstallable packages for each go major version -- the
>> golang-defaults package:
>>
>> https://launchpad.net/ubuntu/+source/golang-defaults
>>
>> creates such a golang-any package (the golang-go package this package
>> produces depends on gccgo on !golang arches but that's down to Ubuntu
>> delta that i want to get rid of). I want to do this work in Debian too
>> (in fact there is stuff on alioth that implements this stuff in a
>> (AFAICT) Debian-appropriate way:
>>
>> 
>> https://anonscm.debian.org/cgit/pkg-golang/golang.git/log/?h=debian-sid-coinst
>> https://anonscm.debian.org/cgit/pkg-golang/golang-defaults.git/
>
> Great work!  This mirrors the existing, time-tested gcc-defaults
> source package,

No kidding :-)

> and I think it is a more comprehensive, flexible and
> future-proof solution and should be the way forward.
>
> This also neatly avoids the kludge that I had to put into debian/rules
> in the patch for src:golang in order to get the package to build
> properly.

Yeah, I like how the golang packaging ends up.

>> I guess I'd like to fix that bug by uploading those changes. I think
>> Tianon was going to try to talk to paultag about this, not sure where
>> that's got to...
>
> Well, the discussion on GitHub happened back in January, and almost
> three months have passed until I finally found time to create a patch
> and filed a Debian bug report.  Obviously, a lot has happened in these
> three months during my hiatus, and I am glad you came up with this
> much-better solution.  :-)

FWIW, I've done a bunch of testing of this, and just posted my results
to bug 818415 which is sort of the master bug for the work I've been
doing. I guess I should add Closes: for this bug to the changelog too.

Bug#818415: [pkg-golang-devel] Bug#818415: golang: move to per-Go-major version coinstallable packages

[Michael Hudson-Doyle]

On 19 March 2016 at 10:52, Tianon Gravi <tia...@debian.org> wrote:
> On 16 March 2016 at 15:13, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> To make maintenance of Go easier in the future, it would be good to allow 
>> major
>> versions of Go to be co-installed (like gcc-4.9, gcc-5, etc). The plan goes
>> something like this:
>>
>>  1) convert existing golang source package to golang-1.6 source package,
>> removing version independent things like the man pages and management of
>> /usr/bin/go, changed to install to version dependent paths 
>> (/usr/lib/go-1.6
>> etc)
>>
>>  2) create a golang-defaults package that contains this version independent
>> stuff and links /usr/bin/go to the appropriate version
>>
>>  3) update gccgo-5 and gccgo-6 packages to stop providing an alternative for
>> 'go'.
>>
>> The motivation for this is to allow us to upload pre-release versions of Go
>> without making them the default, to be more compatible with an externl
>> (possibly Google-hosted) archive that provides newer versions of Go and, if
>> necessary, to allow us to make newer versions of Go available to stable
>> releases without having to conflict with the version of Go in that release.
>>
>> I have prepared packages for Ubuntu that implement this which can be found at
>>
>> https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/log/?h=ubuntu-xenial-coinstallability-2
>>
>> and
>>
>> https://git.launchpad.net/~mwhudson/+git/golang-defaults
>>
>> They're mostly appropriate for Debian, although not entirely. The changes
>> required are simple.
>
> You've done a lot of great work here, Michael! :D
>
> We've discussed this a bit here and there, but I'd like to formally
> say I've been swayed to be +1 on this -- the maintenance burden will
> be slightly higher, but it allows us to do other interesting things
> like put "Go tip" into a repo without breaking other unrelated things,
> or have backports of newer Go versions without causing as many
> potential rebuild oddities.
>
> I agree that where you've got those packages sitting now looks pretty
> good, and that moving forward makes sense!  Thanks for raising the
> discussion and moving it forward.

I've done a bunch of testing of my packages.

To prepare for the testing, I build the golang-defaults and golang-1.6
packages from the branches on alioth and put the resulting debs in a
directory, along with a passwordless gpg key. Then I ran
apt-ftparchive to make Packages and Releases files, signed the
Releases file with the gpg key. When I wanted to use this directory in
a container or chroot I copied the directory to /godebs, added the gpg
with apt-key add and ran

echo 'deb file:///godebs ./' > /etc/apt/sources.list.d/local-repo.list

The tests I did were:

1) make a sid schroot for sbuild, run the above steps, use sbuild to
   build the following list of packages both with the specially
   prepared sid schroot and a vanilla one:

golang-github-aws-aws-sdk-go
docker-swarm
influxdb
golang-github-unknwon-com
cadvisor
golang-github-revel-revel
runc

   The only non-trivial differences in the built debs and build logs
   appear to be the different versions of the go-related packages in
   Built-Using and the build environment.

2) Make a sid container, install golang, do the /godebs setup as
   above, run apt update/apt upgrade and read the output to check that
   there were no errors.

3) Make a jessie container, isntall all the golang packages, do the
   /godebs setup, edit /etc/apt/sources.list to s/jessie/testing/ and
   then ran apt update/apt dist-upgrade and read the output to look
   for errors.

All these tests succeeded as far as I can tell. So can someone either
upload the new packages or tell me what else to test please? :)

Cheers,
mwh

Bug#822668: Processed: cloning 822386, reassign -1 to dh-golang ..., severity of -1 is important

[Michael Hudson-Doyle]

On 27 April 2016 at 19:22, Michael Stapelberg <stapelb...@debian.org> wrote:
> Can you please explain why dh-golang can’t be made to figure out build
> dependencies in this particular case?

Because nothing in the packaging tells dh-golang anything about the Go
bits -- it doesn't set DH_GOPKG or Xs-Go-Import-Path or use the golang
dh buildsystem. I guess we could put back the
built-using-from-Build-Depends code and use both that *and* the go
list-using code I added...

Cheers,
mwh

> On Tue, Apr 26, 2016 at 11:56 AM, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>>
>> On 26 April 2016 at 21:36, Ondřej Surý <ond...@debian.org> wrote:
>> > I am fine to do whatever you suggest, so just to make it right, I
>> > should:
>> >
>> > 1. remove dh-golang from Build-Depends
>>
>> I guess this is not strictly necessary...
>>
>> > 2. remove --with=golang from dh invocation
>>
>> But once you've done this, you can and probably should do 1)
>>
>> > 3. set 'misc:Built-Using=golang-github-abh-geoip-dev' by hand when on
>> > amd64
>>
>> Yes. Unfortunately, as far as I know generating proper Built-Using
>> headers is more awkward than it should be. I think you want to do
>> something like:
>>
>>  dpkg-query --showformat '${source:Package} (= ${source:Version}), '
>> --show golang-github-abh-geoip-dev >> debian/knot-resolver.substvars
>>
>> (-buildmode=c-shared is supported on more architectures in Go 1.6, but
>> that's an entirely different thing :-)
>>
>> Cheers,
>> mwh
>>
>> > And that's it?
>> >
>> > Cheers,
>> > --
>> > Ondřej Surý <ond...@sury.org>
>> > Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
>> >
>> > On Tue, Apr 26, 2016, at 11:29, Michael Hudson-Doyle wrote:
>> >> Hmm, that package just isn't going to work with the new way of
>> >> computing Built-Using in dh-golang. I don't want to change it back,
>> >> because it most ways the new way is better. Not sure what to suggest,
>> >> as there is only one golang-* build-dependency, maybe just do that by
>> >> hand?
>> >>
>> >> On 26 April 2016 at 21:12, Debian Bug Tracking System
>> >> <ow...@bugs.debian.org> wrote:
>> >> > Processing commands for cont...@bugs.debian.org:
>> >> >
>> >> >> clone 822386 -1
>> >> > Bug #822386 [knot-resolver] knot-resolver: FTBFS: can't load package:
>> >> > package .: no buildable Go source files
>> >> > Bug 822386 cloned as bug 822668
>> >> >> reassign -1 dh-golang
>> >> > Bug #822668 [knot-resolver] knot-resolver: FTBFS: can't load package:
>> >> > package .: no buildable Go source files
>> >> > Bug reassigned from package 'knot-resolver' to 'dh-golang'.
>> >> > No longer marked as found in versions
>> >> > knot-resolver/1.0.0~beta3-31-g79a8440-1.
>> >> > Ignoring request to alter fixed versions of bug #822668 to the same
>> >> > values previously set
>> >> >> retitle -1 dh-golang: makes packages FTBFS with 'no buildable Go
>> >> >> source files'
>> >> > Bug #822668 [dh-golang] knot-resolver: FTBFS: can't load package:
>> >> > package .: no buildable Go source files
>> >> > Changed Bug title to 'dh-golang: makes packages FTBFS with 'no
>> >> > buildable Go source files'' from 'knot-resolver: FTBFS: can't load 
>> >> > package:
>> >> > package .: no buildable Go source files'.
>> >> >> severity -1 important
>> >> > Bug #822668 [dh-golang] dh-golang: makes packages FTBFS with 'no
>> >> > buildable Go source files'
>> >> > Severity set to 'important' from 'serious'
>> >> >> thanks
>> >> > Stopping processing here.
>> >> >
>> >> > Please contact me if you need assistance.
>> >> > --
>> >> > 822386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822386
>> >> > 822668: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822668
>> >> > Debian Bug Tracking System
>> >> > Contact ow...@bugs.debian.org with problems
>> >> >
>
>
>
>
> --
> Best regards,
> Michael

Bug#822746: [pkg-golang-devel] Bug#822746: golang: Add golang-any dependency package to install either golang-go or gccgo

[Michael Hudson-Doyle]

On 27 April 2016 at 16:27, Anthony Fok  wrote:
> Source: golang
> Severity: normal
> Tags: patch
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> In order to make Go packages available on as many architectures as
> possible, we can make these packages depend on gccgo on architectures
> where golang-go is not yet available.
>
> Initially, I suggested patching dh-make-golang to expand the
> Build-Depends field in the automatically generated debian/control
> template for Go programs (dh-make-golang -type program)like so:
>
> Build-Depends: golang-go [amd64 arm64 armel armhf i386 ppc64 ppc64el],
>gccgo [!amd64 !arm64 !armel !armhf !i386 !ppc64 !ppc64el]
>
> However, that would mean a massive effort in updating many such packages
> every time golang-go supports a new architecture.
>
> As per discussion at https://github.com/Debian/dh-make-golang/pull/36
> on GitHub, it was decided that a golang-any package should be created
> in src:golang instead, so for Go program-type packages that need it,
> a simple "Build-Depends: golang-any" suffices in providing the default
> Go compiler for each architecture.

I've actually done this in Ubuntu as part of the work I did to create
separate coinstallable packages for each go major version -- the
golang-defaults package:

https://launchpad.net/ubuntu/+source/golang-defaults

creates such a golang-any package (the golang-go package this package
produces depends on gccgo on !golang arches but that's down to Ubuntu
delta that i want to get rid of). I want to do this work in Debian too
(in fact there is stuff on alioth that implements this stuff in a
(AFAICT) Debian-appropriate way:


https://anonscm.debian.org/cgit/pkg-golang/golang.git/log/?h=debian-sid-coinst
https://anonscm.debian.org/cgit/pkg-golang/golang-defaults.git/

I guess I'd like to fix that bug by uploading those changes. I think
Tianon was going to try to talk to paultag about this, not sure where
that's got to...

Cheers,
mwh

Bug#822743: dh-golang: should assist in calculating -dev packages Depends:

[Michael Hudson-Doyle]

Package: dh-golang
Version: 1.12ubuntu1
Severity: wishlist

Dear Maintainer,

There was a bug recently where a golang-*-dev package missed a dependency in
Depends: to another golang-*-dev package, causing yet other packages to ftbfs.
But there's no reason to force maintainers to manually keep track of which
golang-*-dev packages their package depends on, go list & dpkg --search can and
should be used to put it in a substvar.

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-golang depends on:
ii  debhelper 9.20160115ubuntu3
ii  dpkg  1.18.4ubuntu1
ii  libdpkg-perl  1.18.4ubuntu1
ii  perl  5.22.1-9

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information

Bug#822395: [pkg-go] Bug#822395: Bug#822395: Bug#822395: prometheus: FTBFS: cannot find package "golang.org/x/sys/unix"

[Michael Hudson-Doyle]

On 27 April 2016 at 10:57, Tianon Gravi <tia...@debian.org> wrote:
> On 26 April 2016 at 15:46, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> Could/should dh_golang provide help for getting this right? It's kinda
>> similar to the work I did recently to make Built-Using more accurate
>> -- roughly speaking one needs the -dev package to Depend: on the
>> Debian packages corresponding to the Go packages reported by go list
>> -f '{{ .Imports }}' $DH_GOPKG/... I think?
>>
>> (I'll try not to break the world so many times implementing the
>> feature this time :-p)
>
> IMO that'd be awesome. :)

Filed bug 822743 for this.

Bug#821454: [pkg-golang-devel] Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

On 27 April 2016 at 04:53, Peter Colberg <pe...@colberg.org> wrote:
> Hi Michael,
>
> On Tue, Apr 26, 2016 at 10:29:51PM +1200, Michael Hudson-Doyle wrote:
>>  override_dh_auto_build:
>> - dh_auto_build -O--buildsystem=golang -- -ldflags "$(GO_LDFLAGS)"
>> + dh_auto_build -O--buildsystem=golang -- -buildmode=pie
>> -pkgdir=$$(mktemp -d -p $(CURDIR)) -ldflags "$(GO_LDFLAGS)"
>
> I am wondering if dh-golang could set -pkgdir by default.

That's a reasonable thing to wonder :-)

> Does it have to be a random path?

No.

> dh-golang could set a fixed path that is cleaned up with dh_auto_clean.

Yes, having it be cleaned up is obviously a requirement for a real
use... Probably just using a directory inside the builddir would make
most sense.

>> (we could probably make dh-golang do something like this by default...)
>
> Ideally dh-golang would support dpkg hardening flags such as
>
>   export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>
>   export DEB_BUILD_MAINT_OPTIONS = hardening=+pie

Yeah, that seems reasonable. I think only pie, bindnow and relro make
sense for Go.

> Another issue is that when using -buildmode=pie as above, the standard
> library is rebuilt, which increases compile time if enabled for every
> package.

If you use -pkgdir, the standard library is rebuilt whatever you do.
But yeah, that's not ideal. We could (presumably) symlink-mirror
$GOROOT/pkg into the gopkg directory before building to alleviate
this.

> golang-go should provide the -buildmode=pie variant of the
> standard and runtime libraries out of the box.

Yes, probably.

The performance and binary size hit of PIE on i386 in particular is
likely to be large. Do you care at all about that?

Cheers,
mwh

Bug#822751: [pkg-golang-devel] Bug#822751: Bug#822751: Lintian fixes for golang 1.6

[Michael Hudson-Doyle]

On 27 April 2016 at 20:13, Hilko Bengen  wrote:

> src/runtime/race/README explains hso race_*.syso have been generated, so
> perhaps the corresponding sources ought to be added as a patch.

I have a more comprehensive fix for this one in Ubuntu:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807455

Cheers,
mwh

Bug#821454: [pkg-golang-devel] Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

On 29 April 2016 at 12:40, Peter Colberg <pe...@colberg.org> wrote:
> Hi Michael,
>
> On Wed, Apr 27, 2016 at 01:35:30PM +1200, Michael Hudson-Doyle wrote:
>> I think only pie, bindnow and relro make sense for Go.
>
> I figured out how to link with BINDNOW and RELRO using -extldflags:
>
> # Pass hardening flags to linker
> GO_LDFLAGS += -extldflags=-Wl,-z,now,-z,relro

Ah yes, makes sense. TBH, I wonder about changing Go to always pass
those flags...

> # hardening-check acmetool
> acmetool:
>  Position Independent Executable: yes
>  Stack protected: no, not found!
>  Fortify Source functions: no, only unprotected functions found!
>  Read-only relocations: yes
>  Immediate binding: yes
>
>> If you use -pkgdir, the standard library is rebuilt whatever you do.
>
> I think -pkgdir is not needed at all for building with -buildmode=pie.

So long as we add the golang-std-pie-dev flag, yeah.

> I suggest the following path going forward:
>
>  * Ship the -buildmode=pie std library in a separate package
>golang-std-pie-dev as part of the golang source package.
>
>  * Extend dh-golang to translate the dpkg hardening flags into
>-buildmode=pie and -extldflags=-Wl,-z,now,-z,relro as needed.
>
> I am filing a separate bug to implement the first change.
>
> The second change need not happen right away; since it only affects
> packages that build executables, which are very few among the many
> golang packages, this can also be implemented on a case-by-case
> basis for now.

So we'll leave this bug for that bit?

>> The performance and binary size hit of PIE on i386 in particular is
>> likely to be large. Do you care at all about that?
>
> I noticed for amd64 that the size of the stripped acmetool executable
> increases from 10 to 15 MB, which is significant but not dramatic
> compared to the overall bloat of Go executables. The size of the
> compressed Debian package increases from 2.2 to 2.7 MB. (That is
> a compression ratio of 5:1 in both cases.)

That's not too bad. It will be better in Go 1.7!

> Is this not a general issue that affects all Debian packages compiled
> with hardening flags? Or do you potentially see Go-specific size and
> performance issues?

Well, I mentioned i386 for a reason: the PIE code gen for Go on 386 is
extremely stupid (I should know, I wrote it). For other architectures
it should not be nearly so bad. So if you care about performance at
all on 386, you might not want to build PIE there. But I'm not sure
anyone does any more?

Cheers,
mwh

Bug#821454: [pkg-golang-devel] Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

On 29 April 2016 at 13:17, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 29 April 2016 at 12:40, Peter Colberg <pe...@colberg.org> wrote:
>> Hi Michael,
>>
>> On Wed, Apr 27, 2016 at 01:35:30PM +1200, Michael Hudson-Doyle wrote:
>>> I think only pie, bindnow and relro make sense for Go.
>>
>> I figured out how to link with BINDNOW and RELRO using -extldflags:
>>
>> # Pass hardening flags to linker
>> GO_LDFLAGS += -extldflags=-Wl,-z,now,-z,relro
>
> Ah yes, makes sense. TBH, I wonder about changing Go to always pass
> those flags...

In fact, I'm pretty sure that not passing relro is just a bug:
https://github.com/golang/go/issues/15485

Cheers,
mwh

Bug#824806: [pkg-golang-devel] Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Michael Hudson-Doyle]

FWIW my impression is that this issue has been addressed upstream and will
be fixed in the 1.7 release, but maybe someone should check?

Bug#824806: [pkg-golang-devel] Bug#824806: Bug#824806: Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Michael Hudson-Doyle]

That upload does not contain the fix. Need to wait for 1.7.

Cheers,
mwh

On 23 May 2016 at 07:31, Geert Stappers <stapp...@stappers.it> wrote:
> On Sat, May 21, 2016 at 01:06:06AM -0400, Peter Colberg wrote:
>> According to https://github.com/golang/go/issues/13247 this issue
>> has been fixed in commit 5bbb98df0960f57dca73cb7640456608d4cc0917.
>
> Full commit URL is 
> https://github.com/golang/go/commit/5bbb98df0960f57dca73cb7640456608d4cc0917
> It says the commit is from 2016-02-09  ( Feb 9 )
>
>
> Section 'News' at https://tracker.debian.org/pkg/golang says
>   [2016-04-19] golang 2:1.6.1-2 MIGRATED to testing (Debian testing watch)
>   [2016-04-13] Accepted golang 2:1.6.1-2 (source) into unstable (Michael 
> Hudson-Doyle) (signed by: Tianon Gravi)
>   [2016-04-13] Accepted golang 2:1.6.1-1 (source) into unstable (Tianon Gravi)
>   [2016-03-06] golang 2:1.6-1 MIGRATED to testing (Debian testing watch)
>   [2016-03-01] Accepted golang 2:1.6-1 (source) into unstable (Tianon Gravi)
>
> Section 'action needed' says
>   [ ] A new upstream version is available: 1.6.2
>
>
> So I think it makes sense to rebuild the packages listed
> at  
> https://tests.reproducible-builds.org/issues/unstable/random_build_path_by_golang_compiler_issue.html
>
>
> @reproducible-builds-team thank you for add this BR to the issue.
>
>
> Cheers
> Geert Stappers
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#824080: debian-maintainers: Please add Michael Hudson-Doyle as a Debian Maintainer

[Michael Hudson-Doyle]

Package: debian-maintainers
Severity: normal

Hi,

Please add Michael Hudson-Doyle <michael.hud...@ubuntu.com> to the Debian
Maintainers' keyring.

The jetring changeset (add-80E627A0AB757E23) is attached.

Please note that michael.hud...@ubuntu.com is not the primary uid of the key.
Most of my packaging work so far has in fact been done using my
michael.hud...@canonical.com address (another uid on the key) but I am moving
all my packaging stuff over to my ubuntu.com address and intend to use that for
future Debian work too.

Cheers,
mwh


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-22-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Comment: Add Michael Hudson-Doyle <michael.hud...@ubuntu.com> as a Debian 
Maintainer
Date: Thu, 12 May 2016 00:03:06 +
Action: import
Recommended-By: 
  Tianon Gravi <tia...@debian.org>
Agreement: 
  https://lists.debian.org/debian-newmaint/2016/03/msg00019.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2016/03/msg00020.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFNdiiMBEACmryHONXHXK14xBBdLivtbVLTk0OGyahy0ROCEQhx2xtR4PrGJ
  KvxLWOvW/8c6uCLH09+LP3TDebWGIZZvjSBauaIhQHeSFa+CjpXRs+jeJjR0b+bi
  4PZxJZT/l/wwmLrwv7hWhhImWYCLnzKNuEoiHKiF800bi+e+YgxeinOaAvEbcFkq
  U4SUC/aJhCUERNNFukGhP/uyw6dtfrJdAJgmwtZTJd1LHWzi04BHv6WOO9hP3sq9
  hf4+gi7xzkoPUiTsVNUo7TPmO4WXG0672oONmYOHXvrC3VDnsE+tMQkIOprTjEeV
  51hBZKSGHOrAiTP8yjUbXKckXVmhpZeCI/BGH5D315/9yMl9Jgry06plb7NLku/8
  dRinoIrrtzVuf739JvtkXq0rwKPoDxhfg/t+3lKAQOQ3RMeyLe8VaiRU0Fodi/jc
  boD0IJh0SZIHmmdxMCKkex+vSgsclD45TUm/S5BbwTc+8D0xQEK317+Hd1597wpo
  HfLUJ7OmzA61LnBp3JXlVr133x+KMIfp2U1zZd0P/gCAW1F5kbtsYlPqyqplZdHE
  FZvYj+mDnY2MZvyTDXxASpY5297uhVQxaI+tMIOdoz6lmdFtPQx+EU2Z3GNjL8mB
  Czhskqv0rj+aAxo0jXnDxC4cJKQ5a2xegwIfMIoNR1+4MspzTEc2ddKAmQARAQAB
  tChNaWNoYWVsIEh1ZHNvbi1Eb3lsZSA8bWljYWhlbEBnbWFpbC5jb20+iQI6BBMB
  CAAkAhsDAh4BAheABQsJCAcDBRUKCQgLBRYCAwEABQJTXZKBAhkBAAoJEIDmJ6Cr
  dX4jnsQQAJ76N0fFSlGsG38fq3HIVblgMtrN9B/z5S5+ADiqmxUm0zfn3e+F0TRe
  BTsylCtOl5ErZAcx0GPb7sXSJ0U5b+mg2+CmjQkpP1c2DREbgEwe9LxPACZcQRp9
  vGxDKwLMqhtUI5A4u/VfDBc1sH5Gko5he5fVZdYk0JUw/ie8qiQYKJ3h7hfD8yUR
  rDqs2Ug00+tpXzrl70m+b7yjHxQrPCN2gWQB9Y1EAms/8lw2xsF1Ap7QwD4V6EK+
  vBeLPYB3FggqIrg5/m2xVBYJUHqIBTyuTqepIfBQaYtqUGNs2odgeG9pGlWBt5DD
  bidKkkd2YabXcK4QVcJBGClMYZzjEFuFVw0X77xPpqTjU4RvPm/JmI//JBXFFxJr
  jP29xicNVMgaOqYtKgTTPku4j471AdjM19d6pMvksFx/39Dg61deHBSc080zuC5A
  U40mLuPe1UpBu7qEPWDFAoqV91SdEgil3kc7cft77zKkCbmF2ylM5mxY0v496bIX
  0VbrF10qOhTnl/bKNPqOXj7Xk+8ZgTOUbDfli2xyQd8kwFW3kuteW/01wEe4Dz4r
  JE7aGZbpD0bccwL0dQu4a2w3kugUzklvT0DFwzIRgWXp52jJDgJA7HCHk+3tKIMO
  U/6Dtmfokfcmm6+O/PUc1XLJMECJSDUS0XxuDpxTfuJKiNPdYdUgiQI3BBMBCAAh
  BQJTXYojAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEIDmJ6CrdX4jqEgP
  /AnWuTpRMaHJCZYmLGMhqyeGMRbTodzZpk2P9NqYCrpZDWLPpRr6w9lRIPZ//EDQ
  x3nwWG4zSHqDk3SWh2+2zkB9AbAxRZEC8IK2J1NTsCMD3pDqDJw0CLFXecFig4MJ
  jn/2aMiy67bQ0Q3jGUT7U5FwaSwM5ns5wpFM/hYCWYUi0hYlYdCKFSUlQQBl87V7
  DxnvGZ8xKvqvUP0FusV3ljjvElu/h+ulBzvUb5HbXnC8GAymwWd9Mq3/vmCd9POx
  +2lyWSr7ef23YuXQaGdKo/s8KKbNd6DnkofAo6hBEuzQtC3HQjuUGV06VqwRVHbV
  I4HdsPijaV0HcoVfub731xcG8RXXHWQbTkXNdIsc/oME84zDJTrKm7wbNEXDnzZV
  2drF9aIj7FjulhS3KWwJo05iRKVoqQMN0iXaCjO1Mjfs8hqfrVhIcfi6d0hHfR59
  F2Tqx9AZFPfW6FWBQNmxpUWwGHzO0j2xQ2kd83CByFo5jhKYWz0b01+PjJ8ecXzx
  iqepOuTEflfv0rjVW8BuWUkYtGvFuYGTRkLIRCnFm3egVTHqew7+T1DsTYQdWgx9
  N5x9Zl/AtJnRoPy1STFzFD9zxve+onagRLk/fmiuWHvdjoBK5GrikkvXJ7GTgg0o
  iYj/wxjfdVzpZqpg1GGIW+M1TA4yujPUNs7Ia34vbTpHiQIcBBABAgAGBQJTZqRk
  AAoJEEXsUrCoJvU8mcMQALwiR6QOR82g6q/Y+OcnEdfKJha65g16Hp0qatecWt1t
  s/kB3dMU75C+aXaxIwW1gv2jxDlyeMctyhiwPKAiEM5qQT/NBwyxsHLlvu3SK27a
  2Qlwm5oE6kwu42j7q3jbklZdAFRnhlOYONfBoRjBNUSw/0l32pg0B448v3XV2Yeh
  pTCWdrc/D1faRYI0OqIGQirQ0zbADhJkykZFjoWcP99TMt9kMyNuNIHGqTEfks5u
  WZ93A5Rk9x9Lko+1IBRmtZAA3fxEZ3rKoIi917hIPftqit5wEz5XBjbf9GoHACGS
  X3uNduVYuXwYm0rS7oYzWDJE5pHPM8Z8nSrGr6f+vGsQqhVN1lb/XgYn9WC0OVOJ
  ZsIw+3fU0+YGEjYsDuscFmADxayU+c9qIp2CDE5Ufbc12/xK8EfEvR1C6RCNTHfZ
  0tM+PiOLq129h2MjpOWReQLH3ocM+65ahB/Cv0qV/nDTjWIQNbjKNrKzRxdPvcxZ
  qLmFORLufwiPbO7tsCCr1XKaniibaHSjzbghfY3HxBhddkiDOJJC5NN7kzTrBQZy
  oQJEX0cw7BreffGJqbh0WIDty54bc6DfNrj6RM9LZsXFmdnwVUhycCgmpa7iMS+0
  mJtcuyhnjtVGQOh3LAhT08O6eLKKgQ9MLmjTr0V9LyazDdeyCcjkI9iF7EfHvli3
  iQIcBBABCAAGBQJTZbNjAAoJEA3cV0U3jDnr1tUQAIjoey4pfzGkSFOeAc+2F/T1
  lPFbK3XQVLVfN1/VVjYbXFEsZ+ZK2JloDqiFzZRmvwjiow/fH3aDy5EQCU7VSg+A
  TpAIfOQ0hWDm9GwXwzND977qHfkII7lN6KoHa4Nlqf1xXBPo6AYwBs3Gz78c+dSD
  J9RdLPwbe7tS+YCN2aYH5qNj9QQXtycsxna4W/HYc0YEwk/r52l6wKDAzMGbK5ui
  Jgy8xJjrHW31sevOyi41dt81r6kvhzEpFEDwSKZJCr2aEodEggF02wO4xvB01Lmy
  rM+iiFisG/fmxBrJ1K+9cYBJVM/byn20QffO1yAFOPZogmqiMzzMS+Yy

Bug#824421: [pkg-golang-devel] Bug#824421: golang: FTBFS using gccgo

[Michael Hudson-Doyle]

This (I'm fairly sure) is because gccgo-5 no longer installs
/usr/bin/go. We should change this to b-d on golang-any when we upload
golang-defaults/golang-1.6.

Cheers,
mwh

Bug#818415: [pkg-golang-devel] Bug#818415: Bug#818415: golang: move to per-Go-major version coinstallable packages

[Michael Hudson-Doyle]

Tianon and I made a few changes so I redid my tests. They still pass.

I also attempted to test the golabg-any stuff by building a
golang-defaults package that did not consider amd64 to be a golang
architecture. This was less successful (golang-*-dev packages should
not Depend: on golang-go!, also I found a dh-golang bug I introduced)
but the golang-any package itself works fine AFAICT.

Cheers,
mwh

On 28 April 2016 at 12:36, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 19 March 2016 at 10:52, Tianon Gravi <tia...@debian.org> wrote:
>> On 16 March 2016 at 15:13, Michael Hudson-Doyle
>> <michael.hud...@canonical.com> wrote:
>>> To make maintenance of Go easier in the future, it would be good to allow 
>>> major
>>> versions of Go to be co-installed (like gcc-4.9, gcc-5, etc). The plan goes
>>> something like this:
>>>
>>>  1) convert existing golang source package to golang-1.6 source package,
>>> removing version independent things like the man pages and management of
>>> /usr/bin/go, changed to install to version dependent paths 
>>> (/usr/lib/go-1.6
>>> etc)
>>>
>>>  2) create a golang-defaults package that contains this version independent
>>> stuff and links /usr/bin/go to the appropriate version
>>>
>>>  3) update gccgo-5 and gccgo-6 packages to stop providing an alternative for
>>> 'go'.
>>>
>>> The motivation for this is to allow us to upload pre-release versions of Go
>>> without making them the default, to be more compatible with an externl
>>> (possibly Google-hosted) archive that provides newer versions of Go and, if
>>> necessary, to allow us to make newer versions of Go available to stable
>>> releases without having to conflict with the version of Go in that release.
>>>
>>> I have prepared packages for Ubuntu that implement this which can be found 
>>> at
>>>
>>> https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/log/?h=ubuntu-xenial-coinstallability-2
>>>
>>> and
>>>
>>> https://git.launchpad.net/~mwhudson/+git/golang-defaults
>>>
>>> They're mostly appropriate for Debian, although not entirely. The changes
>>> required are simple.
>>
>> You've done a lot of great work here, Michael! :D
>>
>> We've discussed this a bit here and there, but I'd like to formally
>> say I've been swayed to be +1 on this -- the maintenance burden will
>> be slightly higher, but it allows us to do other interesting things
>> like put "Go tip" into a repo without breaking other unrelated things,
>> or have backports of newer Go versions without causing as many
>> potential rebuild oddities.
>>
>> I agree that where you've got those packages sitting now looks pretty
>> good, and that moving forward makes sense!  Thanks for raising the
>> discussion and moving it forward.
>
> I've done a bunch of testing of my packages.
>
> To prepare for the testing, I build the golang-defaults and golang-1.6
> packages from the branches on alioth and put the resulting debs in a
> directory, along with a passwordless gpg key. Then I ran
> apt-ftparchive to make Packages and Releases files, signed the
> Releases file with the gpg key. When I wanted to use this directory in
> a container or chroot I copied the directory to /godebs, added the gpg
> with apt-key add and ran
>
> echo 'deb file:///godebs ./' > /etc/apt/sources.list.d/local-repo.list
>
> The tests I did were:
>
> 1) make a sid schroot for sbuild, run the above steps, use sbuild to
>build the following list of packages both with the specially
>prepared sid schroot and a vanilla one:
>
> golang-github-aws-aws-sdk-go
> docker-swarm
> influxdb
> golang-github-unknwon-com
> cadvisor
> golang-github-revel-revel
> runc
>
>The only non-trivial differences in the built debs and build logs
>appear to be the different versions of the go-related packages in
>Built-Using and the build environment.
>
> 2) Make a sid container, install golang, do the /godebs setup as
>above, run apt update/apt upgrade and read the output to check that
>there were no errors.
>
> 3) Make a jessie container, isntall all the golang packages, do the
>/godebs setup, edit /etc/apt/sources.list to s/jessie/testing/ and
>then ran apt update/apt dist-upgrade and read the output to look
>for errors.
>
> All these tests succeeded as far as I can tell. So can someone either
> upload the new packages or tell me what else to test please? :)
>
> Cheers,
> mwh
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#823136: dh-golang: dh_golang can fail when compiling with gccgo

[Michael Hudson-Doyle]

On 1 May 2016 at 22:41, Michael Hudson-Doyle <michael.hud...@ubuntu.com> wrote:
> Package: dh-golang
> Version: 1.12ubuntu1
> Severity: important
>
> Dear Maintainer,
>
> dh_golang can fail when compiling with gccgo because in this case it's 
> possible
> for go list to report no dependencies at all. Patch coming as soon as I get a
> bug number :-)
>
> Cheers,
> mwh
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers xenial-updates
>   APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
> 'xenial'), (100, 'xenial-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.4.0-21-generic (SMP w/4 CPU cores)
> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages dh-golang depends on:
> ii  debhelper 9.20160115ubuntu3
> ii  dpkg  1.18.4ubuntu1
> ii  libdpkg-perl  1.18.4ubuntu1
> ii  perl  5.22.1-9
>
> dh-golang recommends no packages.
>
> dh-golang suggests no packages.
>
> -- no debconf information
From 7cbd70481b99429e1da20b84c94df214ddacede5 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle <michael.hud...@canonical.com>
Date: Sun, 1 May 2016 22:50:00 +1200
Subject: [PATCH] Yet another corner case in dh_golang, this one only shows up
 with gccgo. (Closes: 823136)

---
 debian/changelog |  7 +++
 script/dh_golang | 19 ++-
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c943d98..b1d9f76 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dh-golang (1.17) UNRELEASED; urgency=medium
+
+  * Yet another corner case in dh_golang, this one only shows up with gccgo.
+(Closes: 823136)
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Sun, 01 May 2016 22:28:04 +1200
+
 dh-golang (1.16) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/script/dh_golang b/script/dh_golang
index d39523b..bcf5432 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -51,6 +51,10 @@ system("go list -f \"$tmpl\" @targets > $tmpdir/godeps") == 0
 system("sort -u $tmpdir/godeps | xargs go list -f '{{ .Dir }}' > $tmpdir/godirs") == 0
 or die "go list of dependencies failed with code $?, $!";
 
+# It's possible for a Go package to report no dependencies at all when compiling
+# with gccgo. Avoid calling dpkg-query --search with no arguments in this case.
+my $at_least_one;
+
 open(my $inp, "<", "$tmpdir/godirs");
 open(my $outp, ">", "$tmpdir/realgodirs");
 while (<$inp>) {
@@ -58,18 +62,23 @@ while (<$inp>) {
 my $realpath = realpath($_);
 # godirs will include the directories of the package being built, so exclude them.
 if ($realpath !~ /^\Q$bs->{cwd}\E/) {
+$at_least_one = 1;
 printf $outp "%s\n", $realpath;
 }
 }
 close($inp);
 close($outp);
 
-system("cat $tmpdir/realgodirs | xargs dpkg-query --search > $tmpdir/pkgs") == 0
-or die "dpkg-query --search failed with code $?, $!";
+my $built_using;
+
+if ($at_least_one) {
+system("cat $tmpdir/realgodirs | xargs dpkg-query --search > $tmpdir/pkgs") == 0
+or die "dpkg-query --search failed with code $?, $!";
 
-my $built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
-if ($? != 0) {
-die "dpkg-query -W failed with code $?, $!";
+$built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
+if ($? != 0) {
+die "dpkg-query -W failed with code $?, $!";
+}
 }
 
 # If there is an easier way to have a universal misc:Built-Using on all binary
-- 
2.7.4

Bug#823136: dh-golang: dh_golang can fail when compiling with gccgo

[Michael Hudson-Doyle]

Package: dh-golang
Version: 1.12ubuntu1
Severity: important

Dear Maintainer,

dh_golang can fail when compiling with gccgo because in this case it's possible
for go list to report no dependencies at all. Patch coming as soon as I get a
bug number :-)

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-golang depends on:
ii  debhelper 9.20160115ubuntu3
ii  dpkg  1.18.4ubuntu1
ii  libdpkg-perl  1.18.4ubuntu1
ii  perl  5.22.1-9

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information

Bug#822743: dh-golang: should assist in calculating -dev packages Depends:

[Michael Hudson-Doyle]

I've had a poke at this and there are some subtleties. Basically it
seems too inflexible.

1) If the Depends is entirely auto generated, that doesn't give the
maintainer anywhere to encode versioned Depends or alternatives.
2) At least in principle, you could get different results on different
architectures thanks to build tags, but -dev packages are _all.debs.

Not so much of a problem, but I'm also a bit unsure whether the
generated value should include TestImports or just Imports (probably
just Imports?).

Bug#823136: dh-golang: dh_golang can fail when compiling with gccgo

[Michael Hudson-Doyle]

Much simpler patch.

On 3 May 2016 at 09:02, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 3 May 2016 at 05:21, Tianon Gravi <admwig...@gmail.com> wrote:
>> On 1 May 2016 at 03:41, Michael Hudson-Doyle <michael.hud...@ubuntu.com> 
>> wrote:
>>> dh_golang can fail when compiling with gccgo because in this case it's 
>>> possible
>>> for go list to report no dependencies at all. Patch coming as soon as I get 
>>> a
>>> bug number :-)
>>
>> Couldn't this also be fixed by just adding "-r" to the "xargs" invocation?
>
> Ah TIL, yes. That would be easier :-)
>
> Cheers,
> mwh
From 7cbd70481b99429e1da20b84c94df214ddacede5 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle <michael.hud...@canonical.com>
Date: Sun, 1 May 2016 22:50:00 +1200
Subject: [PATCH] Yet another corner case in dh_golang, this one only shows up
 with gccgo. (Closes: 823136)

---
 debian/changelog |  7 +++
 script/dh_golang | 19 ++-
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c943d98..b1d9f76 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dh-golang (1.17) UNRELEASED; urgency=medium
+
+  * Yet another corner case in dh_golang, this one only shows up with gccgo.
+(Closes: 823136)
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Sun, 01 May 2016 22:28:04 +1200
+
 dh-golang (1.16) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/script/dh_golang b/script/dh_golang
index d39523b..bcf5432 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -51,6 +51,10 @@ system("go list -f \"$tmpl\" @targets > $tmpdir/godeps") == 0
 system("sort -u $tmpdir/godeps | xargs go list -f '{{ .Dir }}' > $tmpdir/godirs") == 0
 or die "go list of dependencies failed with code $?, $!";
 
+# It's possible for a Go package to report no dependencies at all when compiling
+# with gccgo. Avoid calling dpkg-query --search with no arguments in this case.
+my $at_least_one;
+
 open(my $inp, "<", "$tmpdir/godirs");
 open(my $outp, ">", "$tmpdir/realgodirs");
 while (<$inp>) {
@@ -58,18 +62,23 @@ while (<$inp>) {
 my $realpath = realpath($_);
 # godirs will include the directories of the package being built, so exclude them.
 if ($realpath !~ /^\Q$bs->{cwd}\E/) {
+$at_least_one = 1;
 printf $outp "%s\n", $realpath;
 }
 }
 close($inp);
 close($outp);
 
-system("cat $tmpdir/realgodirs | xargs dpkg-query --search > $tmpdir/pkgs") == 0
-or die "dpkg-query --search failed with code $?, $!";
+my $built_using;
+
+if ($at_least_one) {
+system("cat $tmpdir/realgodirs | xargs dpkg-query --search > $tmpdir/pkgs") == 0
+or die "dpkg-query --search failed with code $?, $!";
 
-my $built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
-if ($? != 0) {
-die "dpkg-query -W failed with code $?, $!";
+$built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
+if ($? != 0) {
+die "dpkg-query -W failed with code $?, $!";
+}
 }
 
 # If there is an easier way to have a universal misc:Built-Using on all binary
-- 
2.7.4

Bug#823136: dh-golang: dh_golang can fail when compiling with gccgo

[Michael Hudson-Doyle]

Grr, this patch!

On 3 May 2016 at 10:05, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> Much simpler patch.
>
> On 3 May 2016 at 09:02, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> On 3 May 2016 at 05:21, Tianon Gravi <admwig...@gmail.com> wrote:
>>> On 1 May 2016 at 03:41, Michael Hudson-Doyle <michael.hud...@ubuntu.com> 
>>> wrote:
>>>> dh_golang can fail when compiling with gccgo because in this case it's 
>>>> possible
>>>> for go list to report no dependencies at all. Patch coming as soon as I 
>>>> get a
>>>> bug number :-)
>>>
>>> Couldn't this also be fixed by just adding "-r" to the "xargs" invocation?
>>
>> Ah TIL, yes. That would be easier :-)
>>
>> Cheers,
>> mwh
From 1ac10deabc29d593fb4f9ed7136243cf2b523d95 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle <michael.hud...@canonical.com>
Date: Sun, 1 May 2016 22:50:00 +1200
Subject: [PATCH] Yet another corner case in dh_golang, this one only shows up
 with gccgo. (Closes: 823136)

---
 debian/changelog | 7 +++
 script/dh_golang | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c943d98..b1d9f76 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dh-golang (1.17) UNRELEASED; urgency=medium
+
+  * Yet another corner case in dh_golang, this one only shows up with gccgo.
+(Closes: 823136)
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Sun, 01 May 2016 22:28:04 +1200
+
 dh-golang (1.16) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/script/dh_golang b/script/dh_golang
index d39523b..391b2a9 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -64,10 +64,10 @@ while (<$inp>) {
 close($inp);
 close($outp);
 
-system("cat $tmpdir/realgodirs | xargs dpkg-query --search > $tmpdir/pkgs") == 0
+system("cat $tmpdir/realgodirs | xargs -r dpkg-query --search > $tmpdir/pkgs") == 0
 or die "dpkg-query --search failed with code $?, $!";
 
-my $built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
+my $built_using = `cut -d: -f1 $tmpdir/pkgs | sort -u | xargs -r dpkg-query -f='\${source:Package} (= \${source:Version}), ' -W`;
 if ($? != 0) {
 die "dpkg-query -W failed with code $?, $!";
 }
-- 
2.7.4

Bug#822743: dh-golang: should assist in calculating -dev packages Depends:

[Michael Hudson-Doyle]

On 3 May 2016 at 04:25, Tianon Gravi <admwig...@gmail.com> wrote:
> On 1 May 2016 at 21:27, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>> 1) If the Depends is entirely auto generated, that doesn't give the
>> maintainer anywhere to encode versioned Depends or alternatives.
>> 2) At least in principle, you could get different results on different
>> architectures thanks to build tags, but -dev packages are _all.debs.
>
> We could possibly combat this by looking at Build-Depends and stealing
> version constraints and alternatives from there if the package we need
> included exists in the Build-Depends, right?  (Complex, but
> theoretically possible?)

Hm, is there actually any case where Depends (or at least
golang-*-dev) and Build-Depends would differ? dh_golang could just
copy one to the other...

It also occurred to me looking at this that my Built-Using
computations should really only look at the dependencies of the main
packages. (Probably doesn't make much difference in practice though).

>> Not so much of a problem, but I'm also a bit unsure whether the
>> generated value should include TestImports or just Imports (probably
>> just Imports?).
>
> If we want to have automated "autopkgtests", then it needs to be both
> (which should be reasonably harmless). :)

Yeah, good point.

Cheers,
mwh

Bug#823136: dh-golang: dh_golang can fail when compiling with gccgo

[Michael Hudson-Doyle]

On 3 May 2016 at 05:21, Tianon Gravi <admwig...@gmail.com> wrote:
> On 1 May 2016 at 03:41, Michael Hudson-Doyle <michael.hud...@ubuntu.com> 
> wrote:
>> dh_golang can fail when compiling with gccgo because in this case it's 
>> possible
>> for go list to report no dependencies at all. Patch coming as soon as I get a
>> bug number :-)
>
> Couldn't this also be fixed by just adding "-r" to the "xargs" invocation?

Ah TIL, yes. That would be easier :-)

Cheers,
mwh

Bug#821000: dh-golang: matched no packages; no buildable Go source files

[Michael Hudson-Doyle]

Sure, I'll take a look. Some details would be nice...

On 15 April 2016 at 02:53, Michael Stapelberg <stapelb...@debian.org> wrote:
> Michael Hudson-Doyle, can you take a look at this please?
>
> Dmitry, can you please provide steps to reproduce?
>
> On Thu, Apr 14, 2016 at 2:46 PM, Dmitry Smirnov <only...@debian.org> wrote:
>>
>> Package: dh-golang
>> Version: 1.14
>> Severity: serious
>>
>> 1.14 is completely broken and unable to build golang packages any more,
>> failing with warning "matched no packages" and error "no buildable Go
>> source
>> files".
>>
>> --
>> Regards,
>>  Dmitry Smirnov
>>  GPG key : 4096R/53968D1B
>
>
>
>
> --
> Best regards,
> Michael

Bug#821000: [PATCH] Restore setting of GOPATH during build removed by mistake in 1.14.

[Michael Hudson-Doyle]

---
 Sorry about this.

 debian/changelog   | 6 ++
 lib/Debian/Debhelper/Buildsystem/golang.pm | 1 +
 2 files changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index e9dba09..dcd21e5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-golang (1.15) UNRELEASED; urgency=medium
+
+  * Restore setting of GOPATH during build removed by mistake in 1.14.
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Fri, 15 Apr 2016 
09:31:13 +1200
+
 dh-golang (1.14) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/lib/Debian/Debhelper/Buildsystem/golang.pm 
b/lib/Debian/Debhelper/Buildsystem/golang.pm
index fbdf510..4d73d99 100644
--- a/lib/Debian/Debhelper/Buildsystem/golang.pm
+++ b/lib/Debian/Debhelper/Buildsystem/golang.pm
@@ -161,6 +161,7 @@ sub get_targets {
 sub build {
 my $this = shift;
 
+$this->_set_gopath();
 if (exists($ENV{DH_GOLANG_GO_GENERATE}) && $ENV{DH_GOLANG_GO_GENERATE} == 
1) {
 $this->doit_in_builddir("go", "generate", "-v", @_, get_targets());
 }
-- 
2.5.0

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Hudson-Doyle]

New patch. Builds everything on Dmitry's list without any stderr from
dh_golang and the built-using headers produced look reasonable.

Cheers,
mwh

On 20 April 2016 at 11:13, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 20 April 2016 at 09:05, Dmitry Smirnov <only...@debian.org> wrote:
>> On Tuesday, 19 April 2016 12:02:10 PM AEST Michael Hudson-Doyle wrote:
>>> Are there any other packages you think would be particularly good to
>>> try to build?
>>
>> You can check the following packages, starting from top:
>
> Thanks for this list.
>
>> golang-github-aws-aws-sdk-go
>
> This manages to trigger an "Argument list too long" in my patch. New
> one coming in a little while.
>
> Cheers,
> mwh
>
>> docker-swarm
>> influxdb
>> golang-github-unknwon-com
>> cadvisor
>> golang-github-revel-revel
>> runc
>>
>> Thanks.
>>
>> --
>> Cheers,
>>  Dmitry Smirnov.
From 10cd725d7996c71b1ff4784e7d0894c21d3f9d6d Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle <michael.hud...@canonical.com>
Date: Tue, 19 Apr 2016 11:59:51 +1200
Subject: [PATCH] More dh_golang fixes

---
 debian/changelog | 15 +++
 script/dh_golang | 58 
 2 files changed, 48 insertions(+), 25 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a4b3689..451dd19 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+dh-golang (1.16) UNRELEASED; urgency=medium
+
+  * Make dh_golang more robust:
+- Initialize the buildsystem more correctly, so --builddirectory=_build
+  works (Closes: 821350)
+- Exit with an error if any of the 'go list' or 'dpkg-search' commands
+  fail.
+- Quote the current working directory in the regexp used to filter out
+  files from the build directory.
+- Store package / directory lists in files and use xargs to avoid
+  constructing over-long command lines.
+  * Also trim dh_golang's use statements. 
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Tue, 19 Apr 2016 11:42:26 +1200
+
 dh-golang (1.15) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/script/dh_golang b/script/dh_golang
index 5e1e71d..d39523b 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -9,14 +9,8 @@ dh_golang - Generates Built-Using substvar
 use strict;
 use Cwd qw(realpath);
 use Debian::Debhelper::Dh_Lib; # not in core
-use Dpkg; # not in core
-use Dpkg::Control; # not in core
-use Dpkg::Control::Info; # not in core
-use Dpkg::Deps; # not in core
-use Dpkg::Gettext; # not in core
-use Scalar::Util qw(blessed); # in core since v5.7.3
-use List::Util qw(first); # in core since v5.7.3
-use Debian::Debhelper::Buildsystem::golang;
+use Debian::Debhelper::Dh_Buildsystems; # not in core
+use File::Temp qw(tempdir);
 
 =head1 SYNOPSIS
 
@@ -35,34 +29,48 @@ The best way to invoke B is by using B.
 
 =cut
 
-init();
-
 
 # Generate misc:Built-Using substvar.
 
 
-my $bs = Debian::Debhelper::Buildsystem::golang->new();
+buildsystems_init();
+my $bs = load_buildsystem("golang");
 
-$bs->_set_dh_gopkg();
 $bs->_set_gopath();
 
 my @targets = $bs->get_targets();
 
-my $godeps = `go list -f '{{ range .Deps }}{{.}} {{ end }}' @targets`;
-$godeps =~ s/\n/ /g;
-my @godirs = split /\n/, `go list -f '{{ .Dir }}' $godeps`;
-my $realgodirs;
-my $cwd = $bs->{cwd};
-for my $godir (@godirs) {
-my $realpath = realpath($godir);
-# @godirs will include the directories of the package being built, so exclude them.
-if ($realpath !~ /^$bs->{cwd}/) {
-$realgodirs .= realpath($godir) . " ";
+my $tmpl = '{{ range .Deps }}{{.}}
+{{ end }}';
+
+my $tmpdir = tempdir("dh_golang_XXX", TMPDIR => 1, CLEANUP => 1);
+
+system("go list -f \"$tmpl\" @targets > $tmpdir/godeps") == 0
+or die "go list of targets failed with code $?, $!";
+
+system("sort -u $tmpdir/godeps | xargs go list -f '{{ .Dir }}' > $tmpdir/godirs") == 0
+or die "go list of dependencies failed with code $?, $!";
+
+open(my $inp, "<", "$tmpdir/godirs");
+open(my $outp, ">", "$tmpdir/realgodirs");
+while (<$inp>) {
+chomp;
+my $realpath = realpath($_);
+# godirs will include the directories of the package being built, so exclude them.
+if ($realpath !~ /^\Q$bs->{cwd}\E/) {
+printf $outp "%s\n", $realpath;
 }
 }
-my $pkgs = `dpkg-query --search $realgodirs | cut -d: -f1`;
-$pkgs =~ s/\n/ /g;
-my $built_using = `dpkg-query -f='\${source:Pack

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Hudson-Doyle]

On 20 April 2016 at 09:05, Dmitry Smirnov <only...@debian.org> wrote:
> On Tuesday, 19 April 2016 12:02:10 PM AEST Michael Hudson-Doyle wrote:
>> Are there any other packages you think would be particularly good to
>> try to build?
>
> You can check the following packages, starting from top:

Thanks for this list.

> golang-github-aws-aws-sdk-go

This manages to trigger an "Argument list too long" in my patch. New
one coming in a little while.

Cheers,
mwh

> docker-swarm
> influxdb
> golang-github-unknwon-com
> cadvisor
> golang-github-revel-revel
> runc
>
> Thanks.
>
> --
> Cheers,
>  Dmitry Smirnov.

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Hudson-Doyle]

The attached should fix this. I get this for rkt's Built-Using now:

 Built-Using: docker-registry (= 2.3.1~ds1-1), golang (= 2:1.6.1-2),
golang-context (= 0.0~git20140604.1.14f550f-1), golang-github-appc-cni
(= 0.2.0~rc0+dfsg-1), golang-github-appc-docker2aci (= 0.9.3+dfsg-1),
golang-github-appc-spec (= 0.7.4+dfsg-1),
golang-github-coreos-go-systemd (= 5-1),
golang-github-coreos-ioprogress (= 0.0~git20151023.0.4637e49-1),
golang-github-cznic-b (= 0.0~git20151027.0.01b13d7-1),
golang-github-cznic-bufs (= 0.0~git20140818.0.3dcccbd-1),
golang-github-cznic-fileutil (= 0.0~git20150708.0.1c9c88f-1),
golang-github-cznic-mathutil (= 0.0~git20150605.0.a804f0f-1),
golang-github-cznic-ql (= 1.0.2-1), golang-github-cznic-sortutil (=
0.0~git20150617.0.4c73428-1), golang-github-cznic-strutil (=
0.0~git20150430.0.1eb03e3-1), golang-github-cznic-zappy (=
0.0~git20160305.0.4f5e6ef-1), golang-github-dustin-go-humanize (=
0.0~git20151125.0.8929fe9-1), golang-github-google-btree (=
0.0~git20150413.0.cc6329d-1), golang-github-gorilla-mux (=
0.0~git20150814.0.f7b6aaa-1), golang-github-hashicorp-errwrap (=
0.0~git20141028.0.7554cd9-1), golang-github-pborman-uuid (=
0.0+git20150824.0.cccd189-1), golang-github-peterbourgon-diskv (=
2.0.0-1), golang-github-spf13-cobra (= 0.0~git20160117.0.8e91712-1),
golang-github-spf13-pflag (= 0.0~git20151218.0.7f60f83-2),
golang-go-semver (= 0.0~git20150304-1), golang-go.crypto (=
1:0.0~git20151201.0.7b85b09-2), golang-gocapability-dev (=
0.0~git20150506.1.66ef2aa-1), golang-golang-x-net-dev (=
1:0.0+git20160110.4fd4a9f-1), golang-google-grpc (=
0.0~git20151002.0.3e7b7e5-1), golang-goprotobuf (= 0.0~git20160330-1),
golang-speter-go-exp-math-dec-inf (= 0.0~git20140417.0.42ca6cd-2)

which looks at least plausible.

On 19 April 2016 at 10:28, Dmitry Smirnov <only...@debian.org> wrote:
> On Tuesday, 19 April 2016 10:19:56 AM AEST Michael Hudson-Doyle wrote:
>> Wow, I'm not sure that package gets much from using dh-golang at all?
>> But I think the problem is the " --builddirectory=_build" in the
>> default target, somehow that needs to get funnelled into the right
>> place. Will have a look.
>
> Thanks. We actually have many Golang packages with "--builddirectory=_build"
> so fixing that is very important.

Are there any other packages you think would be particularly good to
try to build?

Cheers,
mwh
From 5877dffe5bcb36a4afd724c31530d4f747f887d5 Mon Sep 17 00:00:00 2001
From: Michael Hudson-Doyle <michael.hud...@canonical.com>
Date: Tue, 19 Apr 2016 11:59:51 +1200
Subject: [PATCH] More dh_golang fixes

---
 debian/changelog | 13 +
 script/dh_golang | 30 --
 2 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a4b3689..0dcca6c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+dh-golang (1.16) UNRELEASED; urgency=medium
+
+  * Make dh_golang more robust:
+- Initialize the buildsystem more correctly, so --builddirectory=_build
+  works (Closes: 821350)
+- Exit with an error if any of the 'go list' or 'dpkg-search' commands
+  fail.
+- Quote the current working directory in the regexp used to filter out
+  files from the build directory.
+  * Also trim dh_golang's use statements. 
+
+ -- Michael Hudson-Doyle <michael.hud...@ubuntu.com>  Tue, 19 Apr 2016 11:42:26 +1200
+
 dh-golang (1.15) unstable; urgency=medium
 
   [ Michael Hudson-Doyle ]
diff --git a/script/dh_golang b/script/dh_golang
index 5e1e71d..b2c6d99 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -9,14 +9,7 @@ dh_golang - Generates Built-Using substvar
 use strict;
 use Cwd qw(realpath);
 use Debian::Debhelper::Dh_Lib; # not in core
-use Dpkg; # not in core
-use Dpkg::Control; # not in core
-use Dpkg::Control::Info; # not in core
-use Dpkg::Deps; # not in core
-use Dpkg::Gettext; # not in core
-use Scalar::Util qw(blessed); # in core since v5.7.3
-use List::Util qw(first); # in core since v5.7.3
-use Debian::Debhelper::Buildsystem::golang;
+use Debian::Debhelper::Dh_Buildsystems; # not in core
 
 =head1 SYNOPSIS
 
@@ -35,34 +28,43 @@ The best way to invoke B is by using B.
 
 =cut
 
-init();
-
 
 # Generate misc:Built-Using substvar.
 
 
-my $bs = Debian::Debhelper::Buildsystem::golang->new();
+buildsystems_init();
+my $bs = load_buildsystem("golang");
 
-$bs->_set_dh_gopkg();
 $bs->_set_gopath();
 
 my @targets = $bs->get_targets();
 
 my $godeps = `go list -f '{{ range .Deps }}{{.}} {{ end }}' @targets`;
+if ($? != 0) {
+die "go list of targets failed";
+}
 $godeps =~ s/\n/ /g;
 my @godirs = split /\n/, `go list -f '{{ .Dir }}' $godeps`;
+if ($? != 0) {
+die "go list of dependencies failed";
+}
 my $realgodirs;

Bug#821350: dh-golang: generates rubbish in Built-Using; errors on invocation

[Michael Hudson-Doyle]

Wow, I'm not sure that package gets much from using dh-golang at all?
But I think the problem is the " --builddirectory=_build" in the
default target, somehow that needs to get funnelled into the right
place. Will have a look.

On 19 April 2016 at 09:05, Michael Stapelberg  wrote:
> Michael, can you take a look at this issue please?
>
> On Mon, Apr 18, 2016 at 12:45 AM, Dmitry Smirnov  wrote:
>>
>> Package: dh-golang
>> Version: 1.15
>> Severity: serious
>>
>> Recent upload of "rkt" was rejected
>>
>> rkt_1.4.0+dfsg-1_amd64.deb: Built-Using refers to non-existing source
>> package apt (= 1.0.9.10)
>>
>> due to rubbish in Built-Using field:
>>
>> apt (= 1.0.9.10), apt (= 1.0.10.2), apt (= 1.2.10)
>>
>> Also invocation of dh-golang logged the following:
>>
>> 
>>dh_golang -O--buildsystem=golang -O--builddirectory=_build
>> can't load package: package github.com/coreos/rkt/api/v1alpha: cannot find
>> package "github.com/coreos/rkt/api/v1alpha" in any of:
>> /usr/lib/go/src/github.com/coreos/rkt/api/v1alpha (from $GOROOT)
>>
>> /build/rkt-1.4.0+dfsg/obj-x86_64-linux-gnu/src/github.com/coreos/rkt/api/v1alpha
>> (from $GOPATH)
>> can't load package: package github.com/coreos/rkt/rkt: cannot find package
>> "github.com/coreos/rkt/rkt" in any of:
>> /usr/lib/go/src/github.com/coreos/rkt/rkt (from $GOROOT)
>>
>> /build/rkt-1.4.0+dfsg/obj-x86_64-linux-gnu/src/github.com/coreos/rkt/rkt
>> (from $GOPATH)
>> can't load package: package .: no buildable Go source files in
>> /build/rkt-1.4.0+dfsg
>> can't load package: package .: no buildable Go source files in
>> /build/rkt-1.4.0+dfsg
>> dpkg-query: error: --search needs at least one file name pattern argument
>>
>> Use --help for help about querying packages.
>> 
>>
>> This is regression from "dh-golang" v1.12.
>>
>> Please investigate.
>>
>> --
>> All the best,
>>  Dmitry Smirnov
>>  GPG key : 4096R/53968D1B
>>
>> ---
>>
>> Truth never damages a cause that is just.
>> -- Mahatma Gandhi
>
>
>
>
> --
> Best regards,
> Michael

Bug#821454: [pkg-go] Bug#821454: dh-golang: Position-independent executables (PIE)

[Michael Hudson-Doyle]

This is like the cross-compilation / CGO_ENABLED=0 situations:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818651#10
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776401#27

I still don't really know of a good answer. I've been meaning to ask
upstream if they have any ideas about this, maybe I'll get around to
this today :-)

Cheers,
mwh

On 19 April 2016 at 07:06, Peter Colberg  wrote:
> Package: dh-golang
> Version: 1.15
> Severity: normal
>
> Dear Debian Go team,
>
> In response to the lintian warning hardening-no-pie, I am trying to
> build acmetool (#817091) as a position-independent executable (PIE).
>
> The Go compiler supports a -buildmode=pie since version 1.5.
>
> Building the package with this flag produces the following errror:
>
>   dpkg-buildpackage: source package acmetool
>   dpkg-buildpackage: source version 0.0.49-1
>   dpkg-buildpackage: source distribution unstable
>dpkg-source --before-build acmetool-0.0.49
>   dpkg-buildpackage: host architecture amd64
>fakeroot debian/rules clean
>   dh clean --buildsystem=golang --with=golang
>  dh_testdir -O--buildsystem=golang
>  dh_auto_clean -O--buildsystem=golang
>  dh_clean -O--buildsystem=golang
>dpkg-source -b acmetool-0.0.49
>   dpkg-source: info: using source format '3.0 (quilt)'
>   dpkg-source: info: building acmetool using existing 
> ./acmetool_0.0.49.orig.tar.gz
>   dpkg-source: info: building acmetool in acmetool_0.0.49-1.debian.tar.xz
>   dpkg-source: info: building acmetool in acmetool_0.0.49-1.dsc
>debian/rules build
>   dh build --buildsystem=golang --with=golang
>  dh_testdir -O--buildsystem=golang
>  dh_update_autotools_config -O--buildsystem=golang
>  dh_auto_configure -O--buildsystem=golang
>  debian/rules override_dh_auto_build
>   make[1]: Entering directory '/<>'
>   dh_auto_build -O--buildsystem=golang -- -buildmode=pie -ldflags "-X 
> github.com/hlandau/acme/hooks.DefaultPath=/etc/ac
> +me
>   go install -v -buildmode=pie -ldflags "-X 
> github.com/hlandau/acme/hooks.DefaultPath=/etc/acme/hooks -X github
> +.ci github.com/hlandau/acme/acmeapi/acmeendpoints 
> github.com/hlandau/acme/acmeapi/acmeutils
> +github.com/hlandau/acme/cmd/a/acme/redirector 
> github.com/hlandau/acme/responder github.com/hlandau/acme/solver
> +github.com/hlandau/acme/storage githu
>   runtime/internal/sys
>   go install runtime/internal/sys: mkdir /usr/lib/go/pkg/linux_amd64_shared: 
> permission denied
>   dh_auto_build: go install -v -buildmode=pie -ldflags -X 
> github.com/hlandau/acme/hooks.DefaultPath=/etc/acme/hooks -X
> +gicmeapi github.com/hlandau/acme/acmeapi/acmeendpoints 
> github.com/hlandau/acme/acmeapi/acmeutils
> +github.com/hlandau/acme/andau/acme/redirector 
> github.com/hlandau/acme/responder github.com/hlandau/acme/solver
> +github.com/hlandau/acme/storage
>   debian/rules:14: recipe for target 'override_dh_auto_build' failed
>   make[1]: *** [override_dh_auto_build] Error 1
>   make[1]: Leaving directory '/<>'
>   debian/rules:11: recipe for target 'build' failed
>   make: *** [build] Error 2
>   dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> Any ideas what is going wrong?
>
> It works fine if I compile from upstream:
>
>   git clone https://github.com/hlandau/acme github.com/hlandau/acme
>   cd github.com/hlandau/acme/cmd/acmetool
>   export GOPATH=$PWD
>   go get -v
>   go build -v -buildmode=pie
>
> Regards,
> Peter
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#832160: [pkg-golang-devel] Bug#832160: golang-defaults: Upgrading golang-go did not change /usr/lib/go dir to symlink (hence godoc fails)

[Michael Hudson-Doyle]

Hey,

Thanks, committed to master (I took out the rules change though as I'm
99.9% that doesn't do anything).

Cheers,
mwh

On 23 July 2016 at 12:21, Anthony Fok  wrote:
> Source: golang-defaults
> Version: 2:1.6.1+1
> Severity: normal
> Tags: patch
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I was on my way out and wanted to access Go documentation off-line,
> so I tried running godoc, and got the following error messages:
>
> $ godoc -http=:6060
> 2016/07/22 14:36:32 updateMetadata:
> open /usr/lib/go/doc: no such file or directory
> 2016/07/22 14:36:32 updateMetadata:
> open /usr/lib/go/doc: no such file or directory
>
> I initially suspects a bug with the golang-golang-x-tools package
> to which /usr/bin/godoc belongs, but it turns out that /usr/lib/go
> on my computer is an empty directory, whereas golang-go (from the new
> golang-defaults source package) contains /usr/lib/go as a symlink to
> /usr/lib/go-1.6.  This affects users like me who upgrade from
> pre-"golang-defaults" golang-go to the current golang-go.
>
> With the help of dpkg-maintscript-helper(1), this transition can be
> handled quite nicely.  The attached patch adds
> debian/golang-go.maintscript and modifies debian/rules to do so,
> and has been tested to work locally.
>
> Note: debian/golang-go.maintscript runs "#!/usr/bin/dh-exec" and thus
>   needs to have "chmod +x" set.
>
> Cheers,
>
> Anthony
>
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJXkrhJAAoJEOolALQSxZrPJdYQAJDaCeLpCKSbfaSKzOHQCKsb
> Z46QQXcN1PNvKOUJbzYPZZi7MglsPAZs+GsZ/nf92BpzV3ddFsCBc1WPT7B0T7eK
> 2zufp0Rv8hVM9ZtzBc1b2D5j+n7qlaxrdhVrx/rtNYQ4KyMB4DIs/ZtiJKPl/17A
> N/iGwL6YOvpvBHt6g/RwQLm1gwx1lfAw74owhlzpxkOQXByOxEeVb/Dc4Z2vvmfN
> rBPpFhaGMYDr0rUkTNjqEchMQ/w2cAsMERGeYC9uRg/WhxLDt+HCuC6verLJuIIz
> EDux6duMHqoMFIpBQk6yhnExxScT6q1ls4XaKIgs7PWQMBQSq8J4McrNnZEf84yb
> lNzHBE2aDxJe3dedSAW7MLDjZwfOErP8DjW0p5v56daUgYbACJHOtyWReXd4aY4J
> 2TChgtDqJFYwAfxI5SE+9CTnQO3dFgIKVFsGvmH8EDlVdm5K9rt0nneKXT7Vt+xj
> CwCmW7sJ5o29K7aqx2fd6dD56rNM9t+PBLbjKa7cFhPJd3Yxp4K/lFkS1ViuR683
> W+SXNPRAiCtcm30pfH66XZAvFqL35lUbfP9NxyeaGU7R3qB0UA9vOm21hENR+y1B
> dtARYI4+wm83zvyInXn1IqoAHHXJTUQ02rsAKkm6FeYyaevBQvaJwDz7ZxEUPMv+
> DVxmHlyBJ4IvKDMrdkxV
> =NyON
> -END PGP SIGNATURE-
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#827928: [pkg-go] Bug#827928: Bug#827928: golang-github-coreos-go-systemd-dev: circular dependency with golang-github-coreos-pkg-dev

[Michael Hudson-Doyle]

Thanks to upstream changes we can fix this by packaging
golang-github-coreos-pkg-capnslog separately from the rest of
golang-github-coreos-pkg. It's a bit of a hack, it'd be better to wait
until upstream splits out capnslog into a separate repo but that seems
to be taking a while. I'll do this in Ubuntu first an propose it for
fixing in Debian if it works out :-)

Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Michael Hudson-Doyle]

My instinct here is that 1.7 is coming so soon that this isn't worth
the effort. But I'm not opposed at all to someone else uploading it...

On 17 July 2016 at 00:52, Nicolas Braud-Santoni
 wrote:
> Ping?
>
> On Wed, Jul 06, 2016 at 08:05:32PM +0200, Nicolas Braud-Santoni wrote:
>>
>> Hi,
>>
>> I backported the upstream commit that solves the issue and tested it
>> (by building the package, then rebuilding the Go compiler and standard
>> library using the produced compiler).
>>
>> This would allow us to make progress on reproducible builds for all
>> Golang binary package now, rather than waiting for Golang 1.7 to land.
>>
>>
>> Would this be acceptable for inclusion?
>>
>>
>> Best,
>>
>>   nicoo

Bug#823014: [pkg-golang-devel] Bug#823014: Bug#823014: Bug#823014: golang: Package compiled stdlib for PIE build mode

[Michael Hudson-Doyle]

On 16 July 2016 at 15:40, Peter Colberg  wrote:
> On Fri, Jul 15, 2016 at 04:04:26PM -0700, Tianon Gravi wrote:
>> - the "Build-Profiles" bits -- I know we should be using
>> build-profiles more intelligently throughout src:golang-X.Y, but is
>> there something specific to PIE itself that makes it more
>> necessary/appropriate than in the normal case?
>
> It is not specific to PIE. When cross-compiling golang, the generated
> compiler cannot be executed on the host, so the stdlib with PIE mode
> cannot be built using that compiler.

Can we leave fixing the package to be cross-compilable to a separate
effort? It ought to be possible but seems indepedent.

> I have to admit that I did not look at the golang build process in
> detail yet. When finished, does it leave a stage1 compiler for the
> host that could be reused to cross-compile PIE stdlib?

I'm not entirely sure what the question means, but I think the answer
is "yes". The Go story for cross compilation is quite good, although
cgo makes things a bit awkward. We'll need some kind of GOARCH ->
triplet mapping somewhere I guess.

>> - "golang-X.Y-go.install" currently has "pkg/*_*
>> /usr/lib/go-X.Y/pkg/", which will still match
>> "pkg/linux_amd64_shared", and thus include these files _both_ in
>> "golang-1.6-std-pie" and "golang-1.6-go" -- I guess we need to fix
>> that by using "dh_exec" and passing through our GOOS and GOARCH values
>> instead of using globs?
>
> That was my first and preferred solution, but I could not make dh_exec
> pass GOARCH to the .install scripts, while DEB_HOST_MULTIARCH is passed
> just fine. So now override_dh_install-arch moves the PIE stdlib to the
> correct package after dh_install.

Yeah, we don't define GOARCH in rules directly any more. I guess you
could do something
override_dh_install:\n\t$(CURDIR)/debian/helpers/goenv.sh dh_install
but that seems a bit nutty.

Cheers,
mwh

Bug#829302: dh-golang: Respect "--parallel" and "--max-parallel" options

[Michael Hudson-Doyle]

On 9 July 2016 at 13:32, Dmitry Smirnov <only...@debian.org> wrote:
> On Friday, 8 July 2016 3:39:54 PM AEST Michael Hudson-Doyle wrote:
>> I haven't tried it properly, but does this not limit the parallelism
>> and slow builds by default?
>
> Yes it does. Parallel build should be explicitly enabled by "--parallel"
> passed to DH. I think we should make this change in order to make build
> system consistent.
> Most packages would build marginally slower by default.
> For few others it is not hard to add "--parallel" to "debian/rules".
>
> Arguably ignoring parallel build options is a bug. dh-golang should have
> respected debhelper options from very beginning so I'm not too concerned
> about behaviour change. After all there will be a note in changelog about it
> and if you think it is not enough then we can even add a NEWS file.
>
>
>> (I don't know how this works and
>> apparently have not got around to reading up on it in the week since
>> the bug was filed, so I'll ask a potentially silly question)
>
> Debhelper takes care of parsing "--parallel" and "--max-parallel" so we just
> need to take value returned by "get_parallel()" and convert it into
> parameters to "go build" and to "go test" (I've forgotten to include similar
> change to "test()" function).

Makes sense to me. Feel free to commit and upload as far as I'm concerned.

Cheers,
mwh

Bug#829302: dh-golang: Respect "--parallel" and "--max-parallel" options

[Michael Hudson-Doyle]

I haven't tried it properly, but does this not limit the parallelism
and slow builds by default? (I don't know how this works and
apparently have not got around to reading up on it in the week since
the bug was filed, so I'll ask a potentially silly question)

On 2 July 2016 at 22:37, Dmitry Smirnov  wrote:
> Package: dh-golang
> Version: 1.18
> Severity: wishlist
> Tags: patch
>
> Currently build is always parallel even in compat <= 9 mode because
> dh-golang ignores "--parallel" and "--max-parallel" options.
>
> Lack of support for parallel options is a practical problem because by
> default "go build" aggressively uses all CPU cores which can overuse
> resources on heavy packages. For example Kubernetes FTBFS on
> workstation with 8 cores and 32+ GiB of RAM due to lack of memory or
> (when there is enough RAM) it causes so much swapping during build
> that the whole system becomes nearly unusable.
>
> With Kubernetes and other packages it would be quite useful to be able
> to limit build to certain number of cores by using debhelper's
> "--max-parallel=N" option. The following patch does that:
>
> 
> --- lib/Debian/Debhelper/Buildsystem/golang.pm
> +++ lib/Debian/Debhelper/Buildsystem/golang.pm
> @@ -178,8 +178,9 @@
>  $this->_set_gopath();
>  if (exists($ENV{DH_GOLANG_GO_GENERATE}) && $ENV{DH_GOLANG_GO_GENERATE} 
> == 1) {
>  $this->doit_in_builddir("go", "generate", "-v", @_, get_targets());
>  }
> +unshift @_, ('-p',$this->get_parallel());
>  $this->doit_in_builddir("go", "install", "-v", @_, get_targets());
>  }
> 
>
> as well as it makes build respect "--parallel" option for DH consistency.
>
> --
> Best wishes,
>  Dmitry Smirnov
>  GPG key : 4096R/53968D1B
>
> ---
>
> What can be asserted without proof can be dismissed without proof.
> -- Christopher Hitchens, 2004

Bug#833470: [pkg-golang-devel] Bug#833470: golang-go: No reasonable default for GOPATH?

[Michael Hudson-Doyle]

On 5/08/2016 9:18 am, "Michael Stapelberg"  wrote:
>
> Upstream doesn’t prescribe a GOPATH, so I don’t think Debian should
either. It’d be a shame if Go behaved differently depending on which Linux
distribution one uses.
>
> If you’d like to see this changed, please lobby upstream :).

Specifically, upstream is talking about this issue here:

https://github.com/golang/go/issues/12488

Cheers,
mwh

> On Thu, Aug 4, 2016 at 10:19 PM, Dale Harris  wrote:
>>
>> Package: golang-go
>> Version: 2:1.6.1+1
>> Severity: minor
>>
>> This is more a question than a bug report. I'm wondering why there isn't
>> some reasonable default environment, like for $GOPATH, set up in
>> /etc/profile.d/ for Go? Just seems like that should be part of the
>> package.
>>
>>
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages golang-go depends on:
>> ii  golang-1.6-go  1.6.3-1
>> ii  golang-src 2:1.6.1+1
>>
>> golang-go recommends no packages.
>>
>> golang-go suggests no packages.
>>
>> -- no debconf information
>>
>> --
>> Dale Harris
>> rod...@maybe.org
>> rod...@gmail.com
>> /.-)
>>
>
>
>
> --
> Best regards,
> Michael
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#827697: [pkg-go] Bug#827697: Bug#827697: golang-github-shirou-gopsutil: Please update to latest release

[Michael Hudson-Doyle]

I suppose Built-Using on a -dev package lists source package versions
that the -dev package is known to build/pass tests with, which is
probably useful information. But it's not the information for which
policy says Built-Using is to be used:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using:

"Some binary packages incorporate parts of other packages when built
but do not have to depend on those packages. Examples include linking
with static libraries or incorporating source code from another
package during the build. In this case, the source packages of those
other packages are a required part of the complete source (the binary
package is not reproducible without them).

A Built-Using field must list the corresponding source package for any
such binary package incorporated during the build..."


On 20 June 2016 at 11:10, Martín Ferrari <tin...@tincho.org> wrote:
> On 20/06/16 00:06, Michael Hudson-Doyle wrote:
>> Built-Using only makes sense for a package that ships binaries.
>
> I really never knew if it should be present or not on -dev libraries..
> But we have it is most of our repos nowadays.
>
>
> --
> Martín Ferrari (Tincho)

Bug#834477: [pkg-golang-devel] Bug#834477: [golang] Please package new version 1.7

[Michael Hudson-Doyle]

I'd uploaded it to unstable before you sent this mail!

On 16 August 2016 at 14:48, Tim Sattarov  wrote:
> Package: golang
> Version: 2:1.6.1+1
> Severity: minor
>
> --- Please enter the report below this line. ---
>
> Hi, there is new version of Golang announced today:
> https://blog.golang.org/go1.7
> Can you please package it ?
> Thank you !
>
> --- System information. ---
> Architecture: amd64
> Kernel: Linux 4.6.0-1-amd64
>
> Debian Release: stretch/sid
> 500 testing mirror.csclub.uwaterloo.ca
> 500 testing cloudfront.debian.net
> 500 stable repository.spotify.com
> 500 stable repo.skype.com
> 500 stable packages.elastic.co
> 500 stable dl.google.com
> 500 stable cloudfront.debian.net
> 500 sid linux.dropbox.com
> 500 jessie packagecloud.io
> 100 unstable cloudfront.debian.net
>
> --- Package information. ---
> Depends (Version) | Installed
> =-+-===
> golang-1.6 | 1.6.3-1
> golang-doc (>= 2:1.6.1+1) | 2:1.6.1+1
> golang-go (>= 2:1.6.1+1) | 2:1.6.1+1
> golang-src (>= 2:1.6.1+1) | 2:1.6.1+1
>
>
> Package's Recommends field is empty.
>
> Package's Suggests field is empty.
>
> --
> Tim, the beardless keeper of keys and grounds @ AgileBits Inc.
> ~~~
> 1Password remembers all your passwords for you. It keeps your digital life 
> secure and always available, safe behind the one password that only you know.
> Create your 1Password account today at https://1password.com
>
>
>
> ___
> pkg-golang-devel mailing list
> pkg-golang-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel

Bug#851473: snapd fails to run when apparmor is enabled

[Michael Hudson-Doyle]

Hi,

I can reproduce this. It doesn't seem related to the /usr merge because
that was disabled with the stretch rc1 installer and it persists after
installing with that. Or maybe I'm just seeing the "failure to execute
snap-exec", I get this:

root@debian:~# hello.universe
execv failed: Permission denied
root@debian:~# journalctl | tail -n2
Jan 16 10:41:40 debian audit[600]: AVC apparmor="DENIED" operation="exec"
profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-exec"
pid=600 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0
ouid=0
Jan 16 10:41:40 debian kernel: audit: type=1400 audit(1484516500.606:8):
apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine"
name="/usr/lib/snapd/snap-exec" pid=600 comm="snap-confine"
requested_mask="x" denied_mask="x" fsuid=0 ouid=0


So, um. Needs an apparmor person I think?

Cheers,
mwh

On 15 January 2017 at 23:25, Stéphane Graber  wrote:

> Package: snapd
> Severity: important
> Version: 2.20-2
>
> Hello,
>
> On a clean stretch install, booted with apparmor enabled
> (security=apparmor apparmor=1), snapd fails to run due to apparmor
> failures.
>
> It appears to be caused by the fact that /lib is a symlink to /usr/lib,
> with the symlinks getting resolved and so failing because the apparmor
> profile only contains /lib paths.
>
> There is that and a failure to execute snap-exec if I remember correctly.
>
>
>
> It'd be great to have this fixed as snapd will very actively try to use
> apparmor if it's enabled in the kernel. To the point where disabling the
> apparmor profiles for snapd leads to another failure as snapd fails to
> manually change profile then.
>
> Stéphane
>