Thanks from me too!
On 12 March 2018 at 21:59, Michael Stapelberg wrote:
> Sounds good. Thank you for your work on this!
>
> On Sat, Mar 10, 2018 at 10:20 PM, Alexandre Viau wrote:
>
>> On 2018-03-01 11:16 AM, Alexandre Viau wrote:
>> > On 2018-03-01 11:04 AM, Michael Stapelberg wrote:
>> >> We
Changed-By: Michael Hudson-Doyle
Description:
golang-github-go-redis-redis-dev - Type safe Redis client for Go
Changes:
golang-github-go-redis-redis (6.9.2-2) unstable; urgency=medium
.
* d/patches/fix-build-on-32-bit-arch.patch: backport fix from upstream git.
* Add myself to uploaders
On 1 March 2018 at 10:12, Martín Ferrari wrote:
> Hi Michael,
>
> Thanks for moving this forward!
>
> On 27/02/18 21:10, Michael Stapelberg wrote:
>
> > dh-make-golang’s create-salsa-project subcommand now calls this logic
> > via an HTTP request, so that we can update the logic independent of th
On 6 February 2018 at 13:25, Alexandre Viau wrote:
> On 2018-02-04 02:50 PM, Michael Stapelberg wrote:
>
>
>
> On Sat, Jan 27, 2018 at 4:29 PM, Alexandre Viau wrote:
>
>> I don't think the advantages are worth renaming. It could create
>> confusion.
>>
> What confusion specifically do you have i
-- Forwarded message --
From: Matthias Klose
Date: 13 November 2017 at 23:39
Subject: Fwd: please consider naming the new section go, not golang
To: Michael Hudson
Forwarded Message
Subject: please consider naming the new section go, not golang
Date: Mon, 13
This is another of those "only happens on reproducible-builds" mysteries.
It builds fine for me.
Reducing severity to normal.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/li
On 22 August 2017 at 01:17, Paul R. Tagliamonte wrote:
> Why not use the import path I so lovingly put in the generated control
> file for times like these?
>
That's still missing from heaps of packages, isn't it? I know someone who
likes writing scripts to fix lots of golang packages at once...
On 12 August 2017 at 08:01, Martín Ferrari wrote:
> Pkg-go BoF meeting minutes
> ==
>
> On Tuesday, we had the first in-person meeting of the team. We met for 2
> hours to discuss our current issues and to plan for the future.
>
> People present
> --
>
> Alexan
Maybe it just makes sense for gb to (build-)depend on whichever
golang-1.X-go directly.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
On 20 June 2017 at 19:52, Michael Stapelberg wrote:
> Hi,
>
> currently going through the bugs of dh-golang.
>
> Is there anything that remains to be done here?
Well, nothing at all has been done so far :-) OTOH it's a feature request
so perhaps doing nothing is the right thing...
> If so, co
So the armhf failure here is a flaky test, now fixed upstream. For MIPS,
I'm not sure what's going on, honestly I'm surprised it's ever built there,
it's possible a few retries will make that work, or maybe we can just
remove the binaries on MIPS and stop building there (unless someone cares).
Does
The "no test files" thing is not the cause of the failure and the log link
is a 404 for me. This link works though:
https://buildd.debian.org/status/fetch.php?pkg=golang-golang-x-tools&arch=armhf&ver=1%3A0.0~git20161028.0.b814a3b%2Bds-3%2Bb1&stamp=1488869926&raw=0
and the failure is this:
=== R
On 29 January 2017 at 03:25, Sascha Steinbiss wrote:
> Hi all,
>
> I have noticed that the ppc64 build for a Go package I co-maintain failed
> [1] with the following error message:
>
> […]
> go build github.com/google/stenographer/blockfile: no buildable Go source
> files in /<>/obj-powerpc64-lin
Package: wnpp
Severity: wishlist
Owner: "Michael Hudson-Doyle"
* Package name: golang-gopkg-retry.v1
Version : 0.0~git20161025.0.c09f6b8-1
Upstream Author : Roger Peppe
* URL : http://gopkg.in/retry.v1
* License : LGPLv3
Programming Lang: Go
D
If the package doesn't build with "go install" but some other way, you're
going to be fighting dh_golang a bit I think.
On 13 December 2016 at 01:02, Félix Sipma wrote:
> I forgot to add the debian/rules:
>
> #!/usr/bin/make -f
>
> export DH_OPTIONS
>
> export DH_GOPKG := github.com/
That PR got merged, so an upstream update will fix this (I can't do that,
only a DM still :-p)
On 10 November 2016 at 08:06, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:
> I made a PR: https://github.com/jacobsa/crypto/pull/7
>
> On 10 November 2016 at 05:10,
I made a PR: https://github.com/jacobsa/crypto/pull/7
On 10 November 2016 at 05:10, Aaron M. Ucko wrote:
> Package: golang-github-jacobsa-crypto-dev
> Version: 0.0~git20160410.0.42daa9d-2
> Severity: important
>
> Builds of gocryptfs on ppc64el and the non-release architecure ppc64
> have been f
Go only works on z196, which is only one of the buildds, is that the
problem here?
sent from my phone, please excuse brevity
On 4 Nov 2016 23:48, "Pirate Praveen" wrote:
> [cc me on replies from s390 list]
>
> gitlab-workhorse is blocking gitlab 8.12.3 migration to testing for
> sometime now. I
This looks like an upstream problem, have you reported in there? It looks
like a test depending on details of the function names you get from
runtime.Stack or similar, probably just skipping it when running with gccgo
would be fine.
Cheers,
mwh
___
Pkg-g
On 2 November 2016 at 15:23, Martín Ferrari wrote:
> On 02/11/16 01:26, Martín Ferrari wrote:
> > On 02/11/16 00:05, Martín Ferrari wrote:
> >> On 01/11/16 21:44, Michael Hudson-Doyle wrote:
> >>
> >>> Go 1.6 did that too, but the special behaviour here was
On 2 November 2016 at 09:31, Tianon Gravi wrote:
> On 1 November 2016 at 11:28, Martín Ferrari wrote:
> > Now it is failing to build on gccgo arches [0], possibly due to some
> > tool still hardcoding the location for godoc. It would be great if
> > somebody can take a look, I have already spent
On 21 October 2016 at 12:06, Martín Ferrari wrote:
> Hi,
>
> On 29/09/16 03:44, Guillem Jover wrote:
>
> > It seems that many Go packages include an XS-Go-Import-Path field in
> > their control file, which AFAICT is only (?) used at build time from
> > inside the same source package.
>
> AFAIK, t
On 12 October 2016 at 10:44, Moritz Mühlenhoff wrote:
> On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote:
> > On 9 July 2016 at 07:21, Moritz Muehlenhoff wrote:
> > > Florian Weimer wrote:
> > >> > On Wednesday, 6 July 2016 9:59:3
wrote:
> On Mon, Oct 10, 2016 at 10:00:31AM +1300, Michael Hudson-Doyle wrote:
> > I don't know, but it's not surprising to me. The issue that is that
> gccgo-6
> > does not install /usr/bin/go, rather it installs /usr/bin/go-6 (so you
> can
> > have gccgo-6 an
On 8 October 2016 at 09:46, Peter Colberg wrote:
> Hi Martín,
>
> Thanks for the quick review.
>
> On Fri, Oct 07, 2016 at 12:51:14PM +0200, Martín Ferrari wrote:
> > It is indeed peculiar, and I wonder what ftp-master will think of it.
> > Tracking license info for each commit could be fine, but
I reported this upstream (a while ago) as
https://github.com/constabulary/gb/issues/607. It is still open,
unfortunately.
On 12 September 2016 at 10:30, Balint Reczey wrote:
> Source: gb
> Version: 0.4.2-1
> Severity: important
> User: bal...@balintreczey.hu
> Usertags: pie-bindnow-20160906
> Ju
This is what I have so far:
https://github.com/mwhudson/golang-github-coreos-pkg
https://github.com/mwhudson/golang-github-coreos-pkg-capnslog
Would love for someone else to take a look.
On 11 August 2016 at 11:43, Michael Hudson-Doyle
wrote:
> Thanks to upstream changes we can fix this
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 U
On 21 July 2016 at 07:39, Erick Cardona wrote:
> Hi Tim and thanks!
>
> I'm just using a random upstream repository(github) and trying to package it
> using the Debian tools. Actually dh-make-golang does all the magic and now
> I'm able to create the .deb with the binaries and sources in it. I don
Hi all,
We (as in Canonical) are in the process of packaging some Go libraries
in Ubuntu. We're doing this because they are dependencies of packages
that we do not intend to maintain in Debian, and so it doesn't seem
that there's much benefit to maintaining the dependencies in Debian
either. Howev
On 13 July 2016 at 19:20, Moritz Mühlenhoff wrote:
> On Mon, Jul 11, 2016 at 09:12:05AM +1200, Michael Hudson-Doyle wrote:
>> On 8 July 2016 at 20:03, Potter, Tim (HPE Linux Support)
>> wrote:
>> > On 7 Jul 2016, at 12:40 PM, Martín Ferrari wrote:
>> >
On 11 July 2016 at 19:22, Florian Weimer wrote:
> * Michael Hudson-Doyle:
>
>> On 10 July 2016 at 07:39, Florian Weimer wrote:
>>> * Dmitry Smirnov:
>>>
>>>> On Friday, 8 July 2016 8:53:20 AM AEST Florian Weimer wrote:
>>>>> Part of the p
On 9 July 2016 at 13:32, Dmitry Smirnov 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 explici
On 10 July 2016 at 07:39, Florian Weimer wrote:
> * Dmitry Smirnov:
>
>> On Friday, 8 July 2016 8:53:20 AM AEST Florian Weimer wrote:
>>> Part of the problem is that we currently lack a decent way to list all
>>> these reverse dependencies.
>>
>> We can get list of all source packages to re-build
On 9 July 2016 at 07:21, Moritz Muehlenhoff wrote:
> Florian Weimer wrote:
>> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
>> >> What's the current status? Is there technical progress compared to what
>> >> was
>> >> discussed in April? The freeze is coming really close an
On 8 July 2016 at 20:03, Potter, Tim (HPE Linux Support)
wrote:
> On 7 Jul 2016, at 12:40 PM, Martín Ferrari wrote:
>>
>> On 06/07/16 20:59, Moritz Mühlenhoff wrote:
>>
>>> What's the current status? Is there technical progress compared to what was
>>> discussed in April? The freeze is coming rea
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 Smirno
Seems like an upstream problem, I filed
https://github.com/gosimple/slug/issues/8
On 30 June 2016 at 02:28, Chris Lamb wrote:
> Source: golang-github-gosimple-slug
> Version: 1.0-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
Isolating the packaging changes is hardly difficult:
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-shirou-gopsutil.git/log/debian
On 24 June 2016 at 05:52, Dmitry Smirnov wrote:
> On Tuesday, 21 June 2016 6:32:46 PM AEST Martín Ferrari wrote:
>> On 20/06/16 05:11, Dmitry Smirnov w
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 20
On 21 June 2016 at 17:57, Dmitry Smirnov wrote:
> On Tuesday, 21 June 2016 5:02:19 PM AEST Michael Hudson-Doyle wrote:
>> Currently in sid golang-github-coreos-pkg and
>> golang-github-coreos-go-systemd Build-Depend on each other. This is an
>> accurate reflection of t
Hi all,
Currently in sid golang-github-coreos-pkg and
golang-github-coreos-go-systemd Build-Depend on each other. This is an
accurate reflection of the upstream situation
(github.com/coreos/pkg/capnslog/journald_formatter imports
github.com/coreos/go-systemd/journal,
github.com/coreos/go-systemd/j
:
> 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.
Built-Using only makes sense for a package that ships binaries.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
On 15 June 2016 at 20:36, Dmitry Smirnov 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
On 15 June 2016 at 19:57, Dmitry Smirnov 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 hav
On 15 June 2016 at 17:40, Dmitry Smirnov 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 gen
On 15 June 2016 at 02:00, Dmitry Smirnov 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 onl
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!
__
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.
_
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 "--buil
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:
On 26 May 2016 at 06:34, Peter Colberg wrote:
> On Wed, May 25, 2016 at 08:10:34PM +1200, Michael Hudson-Doyle wrote:
>> Thanks. Can you upload?
>
> Sorry, I don’t have upload privileges :-(.
>
> My application for DM is pending:
>
> https://lists.debian.org/debian-new
OK. Reload https://github.com/mwhudson/autodep8/compare/master...go-support
again?
Cheers,
mwh
On 22 May 2016 at 14:51, Martín Ferrari wrote:
> On 20/05/16 22:35, Michael Hudson-Doyle wrote:
>
>> It won't work for debian packages that have go packages that fail tests
>>
On 25 May 2016 at 04:50, Peter Colberg wrote:
> On Tue, May 24, 2016 at 11:12:24AM +1200, Michael Hudson-Doyle wrote:
>> Thanks for the feedback, all done in git. (I always forget that sbuild
>> doesn't run lintian on the source package!)
>
> Thanks for the updates.
Tha
Thanks for the feedback, all done in git. (I always forget that sbuild
doesn't run lintian on the source package!)
Cheers,
mwh
On 21 May 2016 at 15:56, Peter Colberg wrote:
> Hi Michael,
>
> On Fri, May 20, 2016 at 09:11:30PM +1200, Michael Hudson-Doyle wrote:
>> For
On 21/05/2016 7:33 am, "Martín Ferrari" wrote:
>
> On 20/05/16 05:24, Michael Hudson-Doyle wrote:
> > Somehow I don't have Martín's original mail...
>
> Here it is:
>
https://www.mail-archive.com/pkg-go-maintainers@lists.alioth.debian.org/msg03657.html
&g
Hi all,
For some reason or other, Ubuntu builds don't have a tty and debian
builds do. golang-github-erikdubbelboer-gspt failed tests in this
situation, so I fixed this upstream:
https://github.com/erikdubbelboer/gspt/pull/6
and pushed the new upstream snapshot to git.debian.org. Can someone
On 20 May 2016 at 16:24, Michael Hudson-Doyle
wrote:
> Somehow I don't have Martín's original mail...
>
> On 5 April 2016 at 15:40, Dmitry Smirnov wrote:
>> On Thursday, 31 March 2016 1:59:14 AM AEST Martín Ferrari wrote:
>>> So another approach was mentioned
On 20 May 2016 at 16:24, Michael Hudson-Doyle
wrote:
>
> Yeah, I didn't know this automatic test control file thing was
> possible! That's cool. I think a go one only needs to run something
> like:
>
> GOPATH=/usr/share/gocode go test -short $(perl
> -MDebian
Somehow I don't have Martín's original mail...
On 5 April 2016 at 15:40, Dmitry Smirnov wrote:
> On Thursday, 31 March 2016 1:59:14 AM AEST Martín Ferrari wrote:
>> So another approach was mentioned to me: autopkgtest.
>>
>> I know about that project for a while, as I saw pkg-perl people
>> imple
On 13 May 2016 at 00:52, Martín Ferrari wrote:
> On 11/05/16 03:57, Michael Hudson-Doyle wrote:
>
>> +} elsif ($File::Find::name =~ m%/testdata/%) {
>> +# testdata directories are always copied
>
> Ah yes, but that is cheating in my opinion
On 9 May 2016 at 13:23, Martín Ferrari wrote:
> On 09/05/16 02:12, Michael Hudson-Doyle wrote:
>
>> (parenthetically, as I think I said on IRC, dh-golang should just copy
>> testdata by default)
>
> I agree, but so far I don't know how to detect that programatically
Hi all,
I recently was trying to figure out from a binary package name (e.g.
golang-yaml.v2-dev) the import path corresponding for the package (in
this case, "gopkg.in/yaml.v2"). I couldn't find any easy way (what I
did in the end was look for the top most directories the package
installed .go fil
On 8 May 2016 at 16:31, Martín Ferrari wrote:
> Hi all,
>
> I have just pushed a branch (tincho_extensions) to dh-golang,
> implementing a few changes that I believe are beneficial for golang
> packaging. If there are no objections, I would like to merge this to
> master and release 0.17.
>
>
> *
On 5 April 2016 at 11:10, Potter, Tim (HPE Linux Support)
wrote:
> Hi again. I've made a small patch to golang-protobuf-extensions to allow it
> to be built under the version of Go currently in stretch. According to the
> github issue tracker it's a known problem with Go 1.5 and higher, but ha
On 27 April 2016 at 10:57, Tianon Gravi wrote:
> On 26 April 2016 at 15:46, Michael Hudson-Doyle
> 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
>> -- roughl
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/un
On 15 April 2016 at 03:55, Martín Ferrari wrote:
> On 14/04/16 01:43, Michael Hudson-Doyle wrote:
>> Built-Using for a binary is meant to include all packages that are included
>> in
>> the binary itself, but using Build-Depends only pulls in the direct
>> depende
On 15/04/2016 10:48 am, "Tianon Gravi" wrote:
>
> On 14 April 2016 at 15:46, Tianon Gravi wrote:
> > I think this block is why that latest upload is causing everything to
> > fail to build -- we removed GOPATH from "sub build", but didn't add
> > "_set_gopath" like we did down in "sub test" to re
es the issue in a
> sufficient way.
>
> I’d suggest to tackle the problem the same way for Go, and maybe share some
> tools if applicable. That said, I won’t have time or motivation to do any of
> the work required for this, so volunteers are very welcome.
>
> On Thu, Apr 14, 2016 a
On 13 April 2016 at 21:05, Michael Hudson-Doyle
wrote:
> On 13 April 2016 at 17:07, Tianon Gravi wrote:
>> On 12 April 2016 at 21:39, Michael Hudson-Doyle
>> wrote:
>>> We could do it without 1) and the consequent re-uploading of every go
>>> library by using
Built-Using for a binary is meant to include all packages that are included in
the binary itself, but using Build-Depends only pulls in the direct
dependencies. Use go list and dpkg-query --search instead to find out which
(debian) packages installed the (go) packages that were actually used during
On 13 April 2016 at 17:03, Florian Weimer wrote:
> * Michael Hudson-Doyle:
>
>> There is another approach to the static linking issue, which is to
>> start using dynamic linking instead. It's implemented upstream for
>> most architectures now (only mips64 le/be an
On 13 April 2016 at 17:07, Tianon Gravi wrote:
> On 12 April 2016 at 21:39, Michael Hudson-Doyle
> wrote:
>> We could do it without 1) and the consequent re-uploading of every go
>> library by using dpkg-query --search a lot, which would be slow I
>> guess, but maybe cou
Bit of a late reply, been busy.
On 5 April 2016 at 19:27, Florian Weimer wrote:
> Hi,
>
> we need to discuss how we can support applications written in Go for
> stretch.
>
> The most radical approach would be not to ship any Go applications in
> stretch, only the basic Go language implementations
ratt seems happy to me: http://paste.ubuntu.com/15622797/. So the
version needs fixing but then it's ready for upload I think (not by me
though, I don't have upload rights).
On 5 April 2016 at 12:22, Michael Hudson-Doyle
wrote:
> Oh, one thing you'll need to change: the curre
chael Hudson-Doyle
wrote:
> Hah, I was just doing exactly this. I was about to run ratt
> (https://people.debian.org/~stapelberg//2015/10/12/ratt.html) on my
> changes but I'll run it on yours instead and let you know how it goes
> :-)
>
> Cheers,
> mwh
>
> On 5 April
Hah, I was just doing exactly this. I was about to run ratt
(https://people.debian.org/~stapelberg//2015/10/12/ratt.html) on my
changes but I'll run it on yours instead and let you know how it goes
:-)
Cheers,
mwh
On 5 April 2016 at 10:27, Potter, Tim (HPE Linux Support)
wrote:
> Hi everyone. I
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 package
h :-p)
Cheers,
mwh
On 16 March 2016 at 10:51, Michael Hudson-Doyle
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 t
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.
Mostly away from email so please excuse lateness, brevity, top-posting etc.
1) for Ubuntu we're carrying a patch from IBM that contains their port to
s390x. I don't know if you guys want to pick that up too.
2) a change to debian/rules' clean target is needed: a generated file has
moved from src/
I don't think you can currently -- you need to pass -p 1 to the go
install command, but dh-golang doesn't let you do that currently.
Maybe it should!
Cheers,
mwh
On 13 November 2015 at 05:15, Dmitry Smirnov wrote:
> Hi team,
>
> My system cripples when I build heavy Golang application that produ
On 16 October 2015 at 06:40, Michael Stapelberg wrote:
>
>
> On Thu, Oct 15, 2015 at 6:44 PM, Tianon Gravi wrote:
>>
>> On 13 October 2015 at 16:43, Potter, Tim (Converged Cloud)
>> wrote:
>> > Hi tianon. I was curious what your plans were for uploading Go 1.5 to
>> > unstable. Is there anythi
If you're impatient, I'm pretty sure recent enough docker builds with
gccgo on arm64.
On 14 October 2015 at 12:43, Potter, Tim (Converged Cloud)
wrote:
> Hi tianon. I was curious what your plans were for uploading Go 1.5 to
> unstable. Is there anything you can share?
>
> I’m pretty keen on se
Hi there,
It was pointed out during the review of my Go 1.5 package for Ubuntu
that the current go packaging includes files for race detector support
that is not built from source included in the source package, so I
made a package that does build them from source (basically it turns
the instructi
I definitely would expect cgo to work by default.
On 7 October 2015 at 04:25, Tianon Gravi wrote:
> I put them in recommends because without them, trying to use cgo is likely
> to explode, but I'd be open to arguments against how common cgo really is in
> practice. :)
>
> - Tianon
>
> On Oct 5, 2
On 11 September 2015 at 11:00, Potter, Tim (Cloud Services)
wrote:
> On 10 Sep 2015, at 7:41 am, Michael Hudson-Doyle
> wrote:
>>
>> arm64 support is new in 1.5, which afaik isn't in debian yet. It can
>> be bootstrapped with gccgo, which is what we did for Ubuntu
arm64 support is new in 1.5, which afaik isn't in debian yet. It can
be bootstrapped with gccgo, which is what we did for Ubuntu:
https://launchpad.net/ubuntu/wily/+source/golang
(based on stuff that Tianon and Paul did).
Cheers,
mwh
On 9 September 2015 at 19:10, Potter, Tim (Cloud Services)
w
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 wrote:
> Bug #796400 was similar.
>
> lamby, can you explain how I can reproduce this failure l
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
Hi all,
I'm planning on uploading Go 1.5 rc 1 to Ubuntu wily soon (before
feature freeze, which is August 20). I'd like to avoid a gratuitous
delta with Debian, so I've based my work on
https://github.com/tianon/debian-golang/pull/1. The changes I've made
are in
https://github.com/mwhudson/go/com
On 7 August 2015 at 08:41, Hilko Bengen 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
On 3 August 2015 at 18:55, Michael Stapelberg wrote:
> Sorry for the late reply.
>
> On Fri, Jun 19, 2015 at 12:16 AM, Michael Hudson-Doyle
> wrote:
>> On 19 June 2015 at 08:24, Michael Stapelberg wrote:
>>> Thanks.
>>>
>>> The overall approach l
("Could not open file: %v", err)
> }
> // …
> }
>
> Did I miss something?
No indeed -- it would be an improvement on just collecting .go files,
but not a total solution.
Cheers,
mwh
> On Thu, Jul 30, 2015 at 2:41 AM, Michael Hudson-Doyle
> wrote:
>>
>> I guess
I guess you could ask go by invoking 'go list -json ./...' and looking
for the various *Files fields. The imports/deps calculations won't
work of course because the point of the copy is to get files to where
they _do_ work, but that just means that there are DepsErrors fields
in the json -- the com
+1,9 @@
+gocode (20150303-3) unstable; urgency=medium
+
+ * Fix packaging stuff.
+
+ -- Michael Hudson-Doyle 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/d
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
de
ore we upload
> dh-golang to unstable and hence commit to maintaining that feature.
Oh yes, definitely. We'd also need golang-shared-dev (or whatever that
ends up being called) in experimental too, and that's not going to
happen for a little while...
Cheers,
mwh
> On Tue, Jun 16, 2015 at
1 - 100 of 103 matches
Mail list logo
