Re: [pkg-go] moving to salsa.debian.org

[Michael Hudson-Doyle]

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 still have 208 packages which don’t use a secure Vcs-* uri (but
>> >> rather git://). Will redirects work for them, too, or will we need to
>> >> upload a new version?
>> >
>> > I had not noticed this.The redirect won't work for these packages.
>> >
>> > I can selectively re-upload only these packages during the migration.
>>
>> I have modified my migration script to do that.
>>
>> However, if there are packages that have new un-uploaded upstream
>> versions, I will leave them behind, as I don't want to risk
>> automatically uploading new upstream versions. This means that there may
>> still be some manual work to do after the migration, but it should be
>> very minimal compared to what will be automated.
>>
>> Just to be clear:
>>  - Packages that use the git:// scheme in their vcs-git urls, and that
>> have uploaded modifications or upstream versions, will be left behind.
>>
>> I will produce a list of what was left behind, and the reason, so that
>> we can finish the work. I may have the time to fix it all by myself
>> during the migration.
>>
>> I'll send the migration email soon. So maybe we can migrate next monday,
>> or the one after that.
>>
>> Sorry for the delay, I had very few times in the past weeks due to
>> mid-semester.
>>
>> Cheers,
>>
>> --
>> Alexandre Viau
>> av...@debian.org
>>
>>
>
>
> --
> Best regards,
> Michael
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Accepted golang-github-go-redis-redis 6.9.2-2 (source) into unstable

[Michael Hudson-Doyle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 08 Mar 2018 16:00:20 +1300
Source: golang-github-go-redis-redis
Binary: golang-github-go-redis-redis-dev
Architecture: source
Version: 6.9.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 
<pkg-go-maintainers@lists.alioth.debian.org>
Changed-By: Michael Hudson-Doyle <mwhud...@debian.org>
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.
Checksums-Sha1:
 c3d6c2e3025fa1810154af83a4edefd08d8fe42a 2346 
golang-github-go-redis-redis_6.9.2-2.dsc
 9ec952312ddda3e7ede477d0bbd192d40caac843 3532 
golang-github-go-redis-redis_6.9.2-2.debian.tar.xz
Checksums-Sha256:
 1c15f58e150a5a839175202472065aceaae3e7ab8d59d7b1cc13f45fb5d076c7 2346 
golang-github-go-redis-redis_6.9.2-2.dsc
 6026ed1ae8811be18f55ac5eb6ed714f54e7b247c1f7a6f6ee998a6f0c8ece73 3532 
golang-github-go-redis-redis_6.9.2-2.debian.tar.xz
Files:
 d8e51a1d15d4fe15f6aeec09a8a312ce 2346 devel optional 
golang-github-go-redis-redis_6.9.2-2.dsc
 7a7275074d3623fa404b18d5ac4743d2 3532 devel optional 
golang-github-go-redis-redis_6.9.2-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJaoKg2AAoJEBHfQpTMo5iT3usP/37oiazyxcyqJRtmZL/CvXm9
S4dOdmOZRrLcZqotrZR23nHAsAFWfNNanQsb9jGMWzQj6BglyBVc5ABaI3aPRp0e
AcT8HLwaBGA3bWr3X66P2UtcOhagPdiMl4GzWgnkHMGOrgFhkT3RYisu3ZdZf+Sg
is79XRpv/bQWJbARiJ7NSiXzvhnwRrdxfLTvjML0CcPCssfvFrAnEBg0EWNjNyPS
GSJza7QZJ66rMFAGi8OkNylylEUAKy3+HEqtl+4efdDP9jLM6pN6Wjtza4OMEaQK
Vhlo2wDDBUHf1np5/rpqEbtJByk/63PQTMP5E1+aTtForC8iIxUPExQhhReuhPp/
WrhCdfg2COP3M2kQi7tODF4BZYXlYz/TOpTqGSFAnpjMifRM2Uh9ddSfgM7manyc
QmhHMFI5H7bbvTtNWBfr+rk6gw+qg1tMJdz/jswXqIAjIlfyjFvCBRa22x5RsMl/
AEfeRERHyQadxfLx6rX8UwR7sOLyPx9XBtGN7ED7ISfwvRdG+KqHm3EYGbr5h7ge
QlSBnsxO0sCF7SmE9n9PJOway0cWZ33GW2iqrora9yB+y+Vfx6/3+677uIsDNvV3
c6y/JJhkl/7kZYJWHEUE/mY6CYFfO18392aZd3UzhCMk84Nr6gRpkKKquJYM03NF
ar3gw3WfKNBClquWLa+7
=t+XI
-END PGP SIGNATURE-


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

Re: [pkg-go] moving to salsa.debian.org

[Michael Hudson-Doyle]

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 the
> > version of dh-make-golang that users are running (we’ve seen people run
> > very old versions). See
>
> I was going to say that my version of the tool does not have it, but
> then I realised it is there, but the help or the man say nothing about
> it.. Is there a reference somewhere?
>
> > Tincho, aviau, can you confirm that we’re good to go?
> > aviau, are you still up for coordinating and doing the next steps
> > (sending the announcement, migrating the repositories)?
>
> I have some things in mind that I think have not been resolved yet:
>
> * Have we decided on a naming scheme, including group name? What about
> the go compiler stuff? (I think it will make sense to join everytihng
> under one group)
>

The salsa group is now called "go-team" and I thought that's the one we
were going to stick with?

The go compiler stuff should be a subgroup of the go-team group, although I
don't think anything about that should block the package migration.


> * What about mailing list and maintainer address? I know the perl people
> solved this somehow, but I don't understand how :)
>

I don't know the answer to this bit.

Cheers,
mwh


> These two are important, because we should define them before changing
> all repos and mass-committing hundreds of changes.
>
> --
> Martín Ferrari (Tincho)
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] moving to salsa.debian.org

[Michael Hudson-Doyle]

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 in mind? I think it would be more
> confusing to be named “pkg-go” in the long run, especially as other teams
> dropped the pkg- prefix.
>
>
> Will the compiler team still exist? What name will it have?
>

I think it probably makes sense to have the golang-1.x and golang-defaults
packages under 'go-team' too, I don't know if the other Michael or Paul or
Tianon have other opinions.

Cheers,
mwh


> I too have just noticed that other teams have dropped the prefix. In that
> case, I tend to prefer go-team too.
>
> I can probably rename it (and the packages)  in the next few days.
>
> Please don't rename the team without also updating all repositories and
> uploading all packages, which I intend to do, if you give me the time.
>
> --
> Alexandre viauav...@debian.org
>
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Fwd: please consider naming the new section go, not golang

[Michael Hudson-Doyle]

-- 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 Nov 2017 10:25:41 +
From: pkg-go-maintainers-ow...@lists.alioth.debian.org
To: d...@debian.org

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
pkg-go-maintainers-ow...@lists.alioth.debian.org.




-- Forwarded message --
From: Matthias Klose 
To: 847...@bugs.debian.org, 847520-submit...@bugs.debian.org, Debian Go
Packaging Team 
Cc:
Bcc:
Date: Mon, 13 Nov 2017 11:15:32 +0100
Subject: please consider naming the new section go, not golang
Please could you consider using go as new tag name?  golang resembles too
much
to one particular implementation name.  For other languages we have python,
not
cpython, pypy, jython, we have java, not openjdk.

Matthias
--- Begin Message ---
Please could you consider using go as new tag name?  golang resembles too much
to one particular implementation name.  For other languages we have python, not
cpython, pypy, jython, we have java, not openjdk.

Matthias


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

[pkg-go] Bug#876862:

[Michael Hudson-Doyle]

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/listinfo/pkg-go-maintainers

[pkg-go] Bug#872807: Bug#872807: Bug#872807: dh-make-golang: Please find dependencies based on Homepage, too

[Michael Hudson-Doyle]

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...

Cheers,
mwh



> On Aug 21, 2017 9:12 AM, "Balint Reczey" 
> wrote:
>
>> Package: dh-make-golang
>> Version: 0.0~git20170703.0.5eaf198-2
>> Severity: wishlist
>>
>> Dead Maintainer,
>>
>> When looking for packaged build-dependencies the vendor's path
>> (github.com/onsi/ginkgo) is converted using the default go library
>> naming scheme
>> (to golang-github-onsi-ginkgo-dev) which package may not exist in
>> Debian but may exist under a different name
>> (golang-github-ginkgo-dev).
>>
>> In case the build-dependency does not exist in Debian as a package
>> following the
>> standard go naming scheme dh-make-golang could look for it under a
>> different name using the Homepage field of the packages:
>>
>> $ grep-dctrl -FHomepage github.com/onsi/ginkgo -sPackage \
>>  /var/lib/apt/lists/*Packages | sort | uniq
>> Package: golang-ginkgo-dev
>>
>> Cheers,
>> Balint
>>
>>
>> --
>> Balint Reczey
>> Debian & Ubuntu Developer
>>
>> ___
>> Pkg-go-maintainers mailing list
>> Pkg-go-maintainers@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-
>> go-maintainers
>>
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

[Michael Hudson-Doyle]

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
> --
>
> Alexandre Viau (aviau)
> Martín Ferrari (Tincho)
> Paul Tagliamonte (paultag)
> Sascha Steinbiss (satta)
>
> Test files
> --
>
> We discussed the issues raised about shipping test sources and fixtures
> in the -dev packages. It was pointed out that they are not really needed
> for autopkgtest or for reverse-dependencies, but that it will involve a
> lot of work to achieve, so we decided to keep them for now.
>

Makes sense tbh.


> Using -dev packages for development
> ---
>
> Due to the friction that can bring with upstreams, it was agreed to
> continue discouraging to use -dev packages for everyday golang development.
>

+1


> Outdated packages and binNMUs
> -
>
> Paultag proposed automating the detection of packages which have been
> compiled with old versions of libraries. He will implement a first
> version that just sends emails to remind of needed binNMUs, with the
> idea of some day automatically triggering wanna-build.
>
> He also indicated that he wants this automation to detect and warn about
> circular dependencies.
>

Sounds good.


> Git workflows
> -
>
> It was discussed about the problem of having so many different
> workflows, as it makes it difficult to work on packages prepared by
> other team members.
>
> The agreement was to find one standard and make it part of the team's
> policy and incorporate into dh-make-golang.
>
> To that end, it is requested that everyone sends an email to the mailing
> list describing their preferred workflow, and after a period of
> discussion we agree to a conclusion.
>

I think I /slightly/ prefer the upstream branch to be upstream's git
history not a series of imports of tarballs. But I'm not set on it, and gbp
doesn't really get on with this approach if you're just packaging a random
commit rather than a tag AFAICS.


> dh-make-golang
> --
>
> A few times people expressed the desire for dh-make-golang to grow an
> `--update` option, as most packages are trivial to update, but tedious
> to do so.
>

Oh yes please.  Although the ideas that would let gbp import-orig --uscan
work without upstream tarballs would also be fine.


> Satta requested an option to disable SSL verification for badly
> configured redirection sites.
>
> x/tools package
> ---
>
> We discussed the current breakage in x/tools, and agreed that it is a
> core package and that we should make it a shared responsibility to keep
> it in a good shape.
>

It is also a random bag of stuff, it's not really the best bit of factoring
from upstream :)


> gccgo support
> -
>
> We talked about the status of gccgo, paultag explained how mainline
> golang promises the compiler will always be buildable by gccgo, and how
> that makes bootstrapping and cross-building way simpler.
>
> We agreed on working towards making it a first-class citizen in the
> future, using golang-any by default, and only reverting to golang-go
> when needed.
>

Makes sense. Which gccgo arches are really being used today though? MIPS I
guess, but that really should get golang-go once we figure out how to do
that.


> API changes in upstream
> ---
>
> We ranted at length about upstreams, and noted that we need a system
> that provides early warning of API breakages. We discussed using ratt
> and autopkgtest for that purpose.
>

It would be good to have some automation and central resources around this
for sure.


> Aviau pointed out that he usually requests upstreams to make releases
> and that he is usually successful. Tincho pointed out the problems with
> meaningless releases and with upstreams releasing once and then
> forgetting to do it when needed.
>
> We discussed the possibility of changing "soname"s by renaming packages
> when we detect API incompatibilities, but concluded that in general it
> is too much work


Yeah, don't do this :)


> and that it makes more sense to try and fix
> reverse-dependencies by bugging upstream or patching them ourselves.
>




> Team collaboration
> --
>
> On the topic of team collaboration, we agreed to avoid using the DM ACL
> mechanism too much, and instead help active contributors to become DDs.
>

https://nm.debian.org/process/198 :)

(Although the bottleneck is me answering my DAM currently...)


> We also revisited the policy on team uploads, and concluded that we want
> to continue with avoiding hard ownership of packages and that by default
> everything is team-maintained.
>

+100, _especially_ for -dev packages.

Cheers,
mwh

Plan of action
> --
>
> There was some talk about things to do in the immediate future 

[pkg-go] Bug#822743: dh-golang: should assist in calculating -dev packages Depends:

[Michael Hudson-Doyle]

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, could someone please summarize the discussion and explain what it
> is?
>

The issue is making it easier to get the dependencies of golang-*-dev
packages correct. I think my most recent suggestion was that we sort
through the Build-Depends looking for packages that install files to
/usr/share/gocode and copy them all (completely with version and
architecture constraints, if present) to a golang:Depends substvar you
could use in the control file. Does that make sense?

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

Re: [pkg-go] golang-google-cloud is marked for autoremoval from testing

[Michael Hudson-Doyle]

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 Someone(tm) want to upload the flaky test fix? (I don't think I have
upload rights to this package). And then I guess we talk to the release
team to allow it to migrate? (which should be OK as the upload will fix an
RC bug?).

Cheers,
mwh

On 15 March 2017 at 17:39, Debian testing autoremoval watch <
nore...@release.debian.org> wrote:

> golang-google-cloud 0.5.0-1 is marked for autoremoval from testing on
> 2017-04-20
>
> It (build-)depends on packages with these RC bugs:
> 857024: golang-golang-x-tools: golang-golang-x-tools FRBFS on mips:
> unexpected fault address 0x56d03680
> 857025: golang-golang-x-tools: golang-golang-x-tools FRBFS on armhf:
> golang.org/x/tools/refactor/satisfy [no test files]
>
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Bug#857025: Bug#857025: golang-golang-x-tools FRBFS on armhf: golang.org/x/tools/refactor/satisfy [no test files]

[Michael Hudson-Doyle]

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=armhf=1%3A0.0~git20161028.0.b814a3b%2Bds-3%2Bb1=1488869926=0

and the failure is this:

=== RUN   TestImportSymlinks
--- FAIL: TestImportSymlinks (0.03s)
fix_test.go:889: results differ
GOT:
package p

import (
"fmt"
"x/apkg/mypkg"
)

var (
_ = fmt.Print
_ = mypkg.Foo
)

WANT:
package p

import (
"fmt"
"x/mypkg"
)

var (
_ = fmt.Print
_ = mypkg.Foo
)


Which, frankly, is a very bizarre test to be arch dependent.


On 7 March 2017 at 23:26, Adrian Bunk  wrote:

> Source: golang-golang-x-tools
> Version: 1:0.0~git20161028.0.b814a3b+ds-3
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=golang-
> golang-x-tools=armhf=1:0.0~git20161028.0.b814a3b+
> ds-3+b1=1488869926=0
>
> ...
> === RUN   TestDiff
> --- PASS: TestDiff (3.78s)
> PASS
> ok  golang.org/x/tools/refactor/rename  4.035s
> ?   golang.org/x/tools/refactor/satisfy [no test files]
> dh_auto_test: go test -v -p 1 -test.short golang.org/x/tools/benchmark/
> parse golang.org/x/tools/blog golang.org/x/tools/blog/atom
> golang.org/x/tools/cmd/benchcmp golang.org/x/tools/cmd/bundle
> golang.org/x/tools/cmd/callgraph golang.org/x/tools/cmd/digraph
> golang.org/x/tools/cmd/eg golang.org/x/tools/cmd/fiximports
> golang.org/x/tools/cmd/godex golang.org/x/tools/cmd/godoc
> golang.org/x/tools/cmd/goimports golang.org/x/tools/cmd/gomvpkg
> golang.org/x/tools/cmd/gorename golang.org/x/tools/cmd/gotype
> golang.org/x/tools/cmd/goyacc golang.org/x/tools/cmd/guru
> golang.org/x/tools/cmd/guru/serial golang.org/x/tools/cmd/html2article
> golang.org/x/tools/cmd/present golang.org/x/tools/cmd/ssadump
> golang.org/x/tools/cmd/stress golang.org/x/tools/cmd/stringer
> golang.org/x/tools/cmd/tip golang.org/x/tools/container/intsets
> golang.org/x/tools/cover golang.org/x/tools/go/ast/astutil
> golang.org/x/tools/go/buildutil golang.org/x/tools/go/callgraph
> golang.org/x/tools/go/callgraph/cha golang.org/x/tools/go/callgraph/rta
> golang.org/x/tools/go/callgraph/static golang.org/x/tools/go/
> gccgoexportdata golang.org/x/tools/go/gcexportdata golang.org/x/tools/go/
> gcimporter15 golang.org/x/tools/go/internal/gccgoimporter
> golang.org/x/tools/go/loader golang.org/x/tools/go/pointer
> golang.org/x/tools/go/ssa golang.org/x/tools/go/ssa/interp
> golang.org/x/tools/go/ssa/ssautil golang.org/x/tools/go/types/typeutil
> golang.org/x/tools/go/vcs golang.org/x/tools/godoc
> golang.org/x/tools/godoc/analysis golang.org/x/tools/godoc/redirect
> golang.org/x/tools/godoc/util golang.org/x/tools/godoc/vfs
> golang.org/x/tools/godoc/vfs/gatefs golang.org/x/tools/godoc/vfs/httpfs
> golang.org/x/tools/godoc/vfs/mapfs golang.org/x/tools/godoc/vfs/zipfs
> golang.org/x/tools/imports golang.org/x/tools/playground
> golang.org/x/tools/playground/socket golang.org/x/tools/present
> golang.org/x/tools/refactor/eg golang.org/x/tools/refactor/importgraph
> golang.org/x/tools/refactor/rename golang.org/x/tools/refactor/satisfy
> returned exit code 1
> debian/rules:50: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 1
> make[1]: Leaving directory '/«BUILDDIR»/golang-golang-x-
> tools-0.0~git20161028.0.b814a3b+ds'
> debian/rules:18: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 2
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Strange build failure on ppc64 only

[Michael Hudson-Doyle]

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-linux-gnu/src/github
> .com/google/stenographer/blockfile
> […]
>
> while all other supported archs are unaffected and build fine [2]. Any
> ideas? I can reproduce the issue on pizzetti.debian.org.
> The only thing that struck me as out of the ordinary is that the package
> in question uses C components and the ppc64 build seems to be missing
> support for cgo. At least /usr/lib/go-1.7/pkg/linux_ppc64/runtime/cgo.a
> seems to be missing? (Maybe I’m way off here…)
>

I think you're right.


> If that is indeed the problem I’d be happy to remove ppc64 from the list
> of supported archs.
>

Sounds sensible to me. FWIW, I think the ppc64 port is basically dead
upstream, so if you don't care about it, I don't think anyone else will
very much...

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

[pkg-go] Bug#848629: ITP: golang-gopkg-retry.v1 -- Simple retry mechanism for Go.

[Michael Hudson-Doyle]

Package: wnpp
Severity: wishlist
Owner: "Michael Hudson-Doyle" <michael.hud...@ubuntu.com>

* Package name: golang-gopkg-retry.v1
  Version : 0.0~git20161025.0.c09f6b8-1
  Upstream Author : Roger Peppe <rogpe...@gmail.com>
* URL : http://gopkg.in/retry.v1
* License : LGPLv3
  Programming Lang: Go
  Description : Simple retry mechanism for Go.

 Package retry provides a framework for retrying actions. It does not
 itself invoke the action to be retried, but is intended to be used in
 a retry loop.

This package is a new dependency of snapd in version 2.20.

This package will be maintained as part of the pkg-go team.

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

Re: [pkg-go] restic package

[Michael Hudson-Doyle]

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/restic/restic
>
> %:
> dh $@ --buildsystem=golang --with=golang
>
> override_dh_auto_build:
> go run build.go
>
> override_dh_auto_test:
> go run build.go --test
>
>
> On 2016-12-12 13:00+0100, Félix Sipma wrote:
> > Hi!
> >
> > I'm trying to package restic. The build seems to go well, but it fails
> at the
> > end, failing to find library files. I've tried to add this to
> > debian/restic.install:
> >
> >   src/restic usr/lib/go/src
> >
> > but it did not seem to work...
> >
> > Do you have any advice?
> >
> > Here is the build log:
> >
> >   dpkg-buildpackage
> >   -
> >
> >   dpkg-buildpackage: info: source package restic
> >   dpkg-buildpackage: info: source version 0.3.0-1
> >   dpkg-buildpackage: info: source distribution UNRELEASED
> >   dpkg-buildpackage: info: source changed by Félix Sipma <
> felix+deb...@gueux.org>
> >dpkg-source --before-build restic-0.3.0
> >   dpkg-buildpackage: info: 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_autoreconf_clean -O--buildsystem=golang
> >  dh_clean -O--buildsystem=golang
> >dpkg-source -b restic-0.3.0
> >   dpkg-source: info: using source format '3.0 (quilt)'
> >   dpkg-source: info: building restic using existing
> ./restic_0.3.0.orig.tar.gz
> >   dpkg-source: info: building restic in restic_0.3.0-1.debian.tar.xz
> >   dpkg-source: info: building restic in restic_0.3.0-1.dsc
> >debian/rules build
> >   dh build --buildsystem=golang --with=golang
> >  dh_testdir -O--buildsystem=golang
> >  dh_update_autotools_config -O--buildsystem=golang
> >  dh_autoreconf -O--buildsystem=golang
> >  dh_auto_configure -O--buildsystem=golang
> >  debian/rules override_dh_auto_build
> >   make[1]: Entering directory '/<>'
> >   go run build.go
> >   make[1]: Leaving directory '/<>'
> >  debian/rules override_dh_auto_test
> >   make[1]: Entering directory '/<>'
> >   go run build.go --test
> >   ok  restic  7.455s
> >   ok  restic/archiver 65.526s
> >   ok  restic/backend  1.198s
> >   ok  restic/backend/local1.365s
> >   ok  restic/backend/mem  1.125s
> >   ok  restic/backend/rest 0.023s
> >   ok  restic/backend/s3   0.006s
> >   ok  restic/backend/sftp 0.004s
> >   ok  restic/backend/test 0.868s
> >   ok  restic/checker  4.417s
> >   ok  restic/crypto   0.511s
> >   ?   restic/debug[no test files]
> >   ?   restic/errors   [no test files]
> >   ok  restic/filter   0.439s
> >   ?   restic/fs   [no test files]
> >   ok  restic/fuse 1.022s
> >   ok  restic/index59.633s
> >   ?   restic/list [no test files]
> >   ok  restic/location 0.005s
> >   ?   restic/mock [no test files]
> >   ok  restic/pack 0.020s
> >   ok  restic/pipe 0.028s
> >   ok  restic/repository   4.921s
> >   ?   restic/test [no test files]
> >   ok  restic/walk 1.254s
> >   ok  restic/worker   0.003s
> >   make[1]: Leaving directory '/<>'
> >fakeroot debian/rules binary
> >   dh binary --buildsystem=golang --with=golang
> >  dh_testroot -O--buildsystem=golang
> >  dh_prep -O--buildsystem=golang
> >  dh_auto_install -O--buildsystem=golang
> >   mkdir -p /<>/debian/restic/usr/share/gocode/src/gi
> thub.com/restic/restic
> >   cp -r -T src/github.com/restic/restic /<>/debian/
> restic/usr/share/gocode/src/github.com/restic/restic
> >  dh_install -O--buildsystem=golang
> >  dh_installdocs -O--buildsystem=golang
> >  dh_installchangelogs -O--buildsystem=golang
> >  dh_perl -O--buildsystem=golang
> >  dh_link -O--buildsystem=golang
> >  dh_strip_nondeterminism -O--buildsystem=golang
> >  dh_compress -O--buildsystem=golang
> >  dh_fixperms -O--buildsystem=golang
> >  dh_strip -O--buildsystem=golang
> >  dh_makeshlibs -O--buildsystem=golang
> >  dh_shlibdeps -O--buildsystem=golang
> >  dh_installdeb -O--buildsystem=golang
> >  dh_golang -O--buildsystem=golang
> >   can't load package: package restic: cannot find package "restic" in
> any of:
> >   /usr/lib/go-1.7/src/restic (from $GOROOT)
> >   /<>/obj-x86_64-linux-gnu/src/restic (from $GOPATH)
> >   can't load package: package restic/archiver: cannot find package
> "restic/archiver" in any of:
> >   

[pkg-go] Bug#843787: Bug#843787: Bug#843787: golang-github-jacobsa-crypto-dev: hash_64bit.go misses ppc64(el)

[Michael Hudson-Doyle]

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, Aaron M. Ucko <a...@alum.mit.edu> 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 failing:
>>
>>   obj-powerpc64le-linux-gnu/src/github.com/jacobsa/crypto/cmac/hash.go:97:
>> undefined: xorBlock
>>
>> The issue appears to be that the "// +build" setting in hash_64bit.go
>> misses these architectures.  Per https://golang.org/pkg/go/build/, it
>> looks like there's no generic tag you can use here.  Instead, I
>> suppose you'll just have to add ppc64 and ppc64le there, per
>> https://github.com/golang/go/issues/8654#user-content-c27.
>>
>> Could you please take a look?
>>
>> Thanks!
>>
>> --
>> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
>> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finge
>> r/?a...@monk.mit.edu
>>
>> ___
>> Pkg-go-maintainers mailing list
>> Pkg-go-maintainers@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-
>> go-maintainers
>>
>
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Bug#843787: Bug#843787: golang-github-jacobsa-crypto-dev: hash_64bit.go misses ppc64(el)

[Michael Hudson-Doyle]

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 failing:
>
>   obj-powerpc64le-linux-gnu/src/github.com/jacobsa/crypto/cmac/hash.go:97:
> undefined: xorBlock
>
> The issue appears to be that the "// +build" setting in hash_64bit.go
> misses these architectures.  Per https://golang.org/pkg/go/build/, it
> looks like there's no generic tag you can use here.  Instead, I
> suppose you'll just have to add ppc64 and ppc64le there, per
> https://github.com/golang/go/issues/8654#user-content-c27.
>
> Could you please take a look?
>
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/
> finger/?a...@monk.mit.edu
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Bug#842897: Bug#842897: fix test failure with gccgo

[Michael Hudson-Doyle]

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-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] golang-golang-x-tools not migrating to testing, why?

[Michael Hudson-Doyle]

On 2 November 2016 at 15:23, Martín Ferrari <tin...@tincho.org> 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 removed for
> 1.7.
> >>> gccgo-6 still has a version of the go tool based on 1.6 though, so
> >>> (unfortunately) the GOROOT hack that
> >>> 3852c129b5154b63e2b86ba5db13390096ba calls "uneeded" is, in fact,
> >>> needed for a little longer.
>
> Well, after a few tries, I am not being able to make this work again.
> Did this ever work for gccgo?
>

Hm, possibly not, I don't think it ever built on powerpc on Ubuntu.

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

Re: [pkg-go] Security support for packages written in Go

[Michael Hudson-Doyle]

On 12 October 2016 at 10:44, Moritz Mühlenhoff <j...@inutil.org> wrote:

> On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote:
> > On 9 July 2016 at 07:21, Moritz Muehlenhoff <j...@inutil.org> 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 and we can't
> support
> > >> >> the status quo for stretch.
> > >> >
> > >> > Perhaps I'm not the best person to speak on the matter as I've never
> > >> > touched any Golang tools except dh-golang. Situation with Golab
> > >> > libraries is not ideal (to say the least) but I understand that
> > >> > Golang is not the only language without concept of dynamic
> > >> > linking. As I recall someone mentioned Haskell as another example.
> > >> >
> > >> > It is my understanding that when vulnerability is fixed in Golang
> > >> > library it should be sufficient to NMU (re-build) all reverse
> > >> > dependencies.
> > >>
> > >> Part of the problem is that we currently lack a decent way to list all
> > >> these reverse dependencies.
> > >
> > > And there's also the much bigger problem that we can't actually rebuild
> > > packages on security.debian.org without a lot of manual work!
> > >
> > > The dak installation for security-master has a _lot_ of tech debt. One
> > > that particularly bites us here is that tarballs between
> security-master
> > > and ftp-master are separate. This e.g. requires that every package that
> > > is new on security-master needs to be build with "-sa" to include
> source
> > > and we can only issue binNMUs for packages which were at least once
> > > upload to jessie-security/stretch-security etc.
> >
> > That does sound unfortunate in the Go context.
> >
> > It is worth bearing in mind though, that you only need to rebuild the
> > binary-containing packages, so if the number of binary-containing
> > packages supported by the security team is tightly constrained, then
> > so is the number of (no-change source, I guess) uploads required to
> > handle any security update (e.g. in Ubuntu 16.04 there are only three
> > packages that contain Go binaries in main).
> >
> > The changes I'm making in Ubuntu to use shared libraries should in the
> > common case (i.e. the fix does not break ABI) make this better, but
> > worst case (where the fix breaks ABI) it will be worse as we might end
> > up having to rebuild the whole rdep tree.
>
> What's the status of that work, will that land in the stretch release?
>

I'm not planning on working on getting it into stretch myself.

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

Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}

[Michael Hudson-Doyle]

It could (and used to be!), but alternatives are pretty terrible for
toolchains/things that are often build-dependencies. Maybe we could have a
gccgo-go package or something that would provide the symlink (and conflict
with golang-go)?

Cheers,
mwh

On 11 October 2016 at 11:52, Peter Colberg <pe...@colberg.org> 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 and golang-go both installed on systems where both are
> > available). When you install golang-any on a system where it brings in
> > gccgo-6 it installs a symlink from /usr/bin/go to go-6. This is a bit of
> a
> > pain for the reasons you've noticed, but I'm not sure what to do about
> it.
>
> Do you think this can be solved by providing /usr/bin/go via alternatives?
>
> Peter
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}

[Michael Hudson-Doyle]

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 the license
> > needs to be in the repository, otherwise an exported tarball has no
> > license. He could also import the license in each file if he wanted to
> > make sure everyone is aware...
>
> I am hoping that ftp-master considers a Debian source package an
> inseparable unit. I will repack the orig tarballs otherwise. In the
> latest version of acmetool, the upstream author has gone as far as
> removing the existing license file in favour of the RILTS scheme.
>
> https://github.com/hlandau/acme/commit/a4d55ea51a8782633d7ca477d24c5d
> a9a5c6147b
>
> > Comments on the package (I only checked goutils):
>
> I applied the changes below to all three packages.
>
> > * Replace the golang-go build-dependency with golang-any, which brings
> > gccgo where golang-go is not available.
>
> Done. To test compilation with gccgo, I temporarily replaced the build
> dependency on golang-any with gccgo-6, but the build fails on amd64:
>
>   dh build --buildsystem=golang --with=golang
>  dh_testdir -O--buildsystem=golang
>  dh_update_autotools_config -O--buildsystem=golang
>  dh_auto_configure -O--buildsystem=golang
>  dh_auto_build -O--buildsystem=golang
>   go install -v -p 1
>   dh_auto_build: go install -v -p 1 failed to to execute: No such file or
> directory
>   debian/rules:4: recipe for target 'build' failed
>   make: *** [build] Error 2
>   dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> Is this a bug in dh-golang or gccgo-6?


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 and golang-go both installed on systems where both are
available). When you install golang-any on a system where it brings in
gccgo-6 it installs a symlink from /usr/bin/go to go-6. This is a bit of a
pain for the reasons you've noticed, but I'm not sure what to do about it.

Cheers,
mwh


>
> > * Drop the golang-go dependency in the binary package, as it is not
> > really needed.
>
> Done.
>
> > * The description is too vague, this package is actually only useful for
> > his other utilities, so I'd specify that more clearly.
>
> Done. I extended the description to mention acmetool.
>
> > * In debian/copyright you say it is Expat license, but then your patch
> > says it is MIT.
>
> Please take another look at upstream-license.patch: The description
> does not mention MIT at all; it is only used in the upstream filename.
>
> What is known as MIT license in the outside world, is considered
> ambiguous by Debian and more precisely referred to as the Expat
> license. Please see the license specification for debian/copyright:
>
> https://www.debian.org/doc/packaging-manuals/copyright-
> format/1.0/#license-specification
>
> “There are many versions of the MIT license. Please use Expat instead,
> when it matches.”
>
> > * The copyright info for clock/* does not reflect anything in the
> > repository.
>
> The author conveniently moved this to the bottom of clock/clock.go:
>
> // © 2015 Jonathan Boulle   Apache 2.0 License
>
> The debian/copyright stanza stems from golang-github-hlandau-degoutils,
> which
> as mentioned in the ITP bug is the predecessor of goutils and will be
> removed
> once the three new dependencies have been accepted. Since degoutils has
> been
> accepted by ftp-masters before, the debian/copyright stanza should be fine.
>
> > Seeing his replies, I am not sure it will be a pleasant upstream to work
> > with :(
>
> I was pondering seeking another maintainer or otherwise orphaning the
> package when the behaviour of the maintainer was blocking an important
> fix. I temporarily solved the issue by adding a patch that reverted to
> the older degoutils as a build dependency, but I thought long and hard
> whether it is worth it to continue maintaining acmetool.
>
> https://bugs.debian.org/833494
>
> Currently I believe it continues to be worth it. Apart from this one
> bug, acmetool has generally required the least amount of attention of
> the LE clients in Debian, since it is well designed and just works.
> acmetool uses a well thought-out and documented directory schema:
>
> https://github.com/hlandau/acme/blob/master/_doc/SCHEMA.md
>
> Peter
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Bug#827928: 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 :-)

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

Re: [pkg-go] go binary-only package

[Michael Hudson-Doyle]

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't
> know why yesterday it wasn't including the binaries in the .deb package, but
> now is working like a charm. Today I was messing it with cowbuilder and
> pbuilder stuff and it works. I'll take a closer look on how those tools work
> under the hood.
>
> Question: If some projects have their dependencies in the vendor dir, why
> dh-make-golang skip those? Does Debian packages never ship the deps in that
> way?

It is against debian policy:
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Cheers,
mwh

> Anyway, thanks for the interest.
>
> Regards,
> Erick Cardona
>
> 2016-07-19 16:24 GMT-05:00 Potter, Tim (HPE Linux Support)
> :
>>
>> On 20 Jul 2016, at 1:51 AM, Erick Cardona  wrote:
>> >
>> > Hi everyone,
>> >
>> >
>> > I'm currently packaging a go project for educational purposes. Now I'm
>> > able to build a package using the tools dh-make-golang and gbp(Awesome
>> > tools!!). I was able to build a binary-only package but manually. I was
>> > wondering if using gbp I could obtain a .deb which contains the binaries of
>> > the package? Like the docker-engine.deb which contains the binaries of
>> > docker.
>> >
>> > PS: I'm really new to packaging, but looking further to join the Debian
>> > community.
>>
>> Hi Erick.  The best way to make a new Debian package from a Go library is
>> with dh-make-golang
>> and gbp so you're on the right track there.
>>
>> Can you push what you've done so far to a git repo somewhere for review?
>> I'm happy to
>> take a look and give feedback.
>>
>>
>> Tim.
>
>
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[pkg-go] Any interest in these packages for Debian?

[Michael Hudson-Doyle]

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. However, if anyone knows a reason why any of these packages
would be useful in Debian, we're happy to do that (although I'll need a
sponsor for the first upload :-p). The packages are:

golang-github-altoros-gosigma
golang-github-dustin-go-humanize
golang-github-gabriel-samfira-sys
golang-github-gorilla-schema
golang-github-gosuri-uitable
golang-github-joyent-gocommon
golang-github-joyent-gomanta
golang-github-joyent-gosdc
golang-github-joyent-gosign
golang-github-mattn-go-runewidth
golang-gnuflag-dev (go-import-path: launchpad.net/gnuflag)
golang-gopkg-errgo.v1
golang-gopkg-goose.v1
golang-gopkg-macaroon.v1
golang-gopkg-natefinch-npipe.v2

They are all straightforward, library-only packages that
dh-make-golang handles fine.

While I'm on the subject, we are also packaging these slightly less
straightforward libraries, so same question for these:

github.com/ajstarks/svgo
google.golang.org/cloud
gopkg.in/macaroon-bakery.v1

Cheers,
mwh

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

Re: [pkg-go] Security support for packages written in Go

[Michael Hudson-Doyle]

On 13 July 2016 at 19:20, Moritz Mühlenhoff <j...@inutil.org> 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)
>> <timothy.pot...@hpe.com> wrote:
>> > On 7 Jul 2016, at 12:40 PM, Martín Ferrari <tin...@tincho.org> 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 really close and we can't 
>> >>> support
>> >>> the status quo for stretch.
>> >>
>> >> The discussion stalled at that point. AFAIK, there is no technical
>> >> solution for this. The best we could do is to have easier ways to track
>> >> dependency chains, but that does not change the fact that all golang
>> >> applications are still statically built, and so would require rebuilds
>> >> when security bugs are discovered and fixed.
>> >>
>> >> I understand this is problematic, but not sure we can do anything about
>> >> it at this point.
>> >
>> > Hi everyone.  I've done a small amount of research into the 
>> > buildmode=c-shared
>> > and the dynlink option and they look good on paper.  Has anyone examined 
>> > these
>> > options more seriously?
>>
>> Well, using them in Ubuntu was the reason Canonical paid me to
>> implement them, so yes... I'm am currently in the process of starting
>> to use these features in Ubuntu. My plan, such as it was, was to use
>> them in Ubuntu through the 16.10 cycle and then propose the changes to
>> Debian too, assuming they work out OK.
>
> What does the provide specifically? Dynamic linking similar to what we 
> currently
> have for library code written in C?

Yes. There are more details here:
https://docs.google.com/document/d/1IOlBWWgcDeB9PfRORENESYj8iJt4W2EwsbYcpg4akBE/edit

Cheers,
mwh

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

Re: [pkg-go] [pkg-golang-devel] Security support for packages written in Go

[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 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 from reverse build
>> dependencies. Then it should be possible to filter arch:any packages to bin-
>> NMU.
>>
>> Alternatively Built-Using field could be of help.
>
> We already discussed why this doesn't work with the present state of
> the metadata.

Do you mean the "B-U is only direct dependencies" problem? That's
fixed now. Was there something else?

Cheers,
mwh

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

Re: [pkg-go] Security support for packages written in Go

[Michael Hudson-Doyle]

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 and we can't support
>> >> the status quo for stretch.
>> >
>> > Perhaps I'm not the best person to speak on the matter as I've never
>> > touched any Golang tools except dh-golang. Situation with Golab
>> > libraries is not ideal (to say the least) but I understand that
>> > Golang is not the only language without concept of dynamic
>> > linking. As I recall someone mentioned Haskell as another example.
>> >
>> > It is my understanding that when vulnerability is fixed in Golang
>> > library it should be sufficient to NMU (re-build) all reverse
>> > dependencies.
>>
>> Part of the problem is that we currently lack a decent way to list all
>> these reverse dependencies.
>
> And there's also the much bigger problem that we can't actually rebuild
> packages on security.debian.org without a lot of manual work!
>
> The dak installation for security-master has a _lot_ of tech debt. One
> that particularly bites us here is that tarballs between security-master
> and ftp-master are separate. This e.g. requires that every package that
> is new on security-master needs to be build with "-sa" to include source
> and we can only issue binNMUs for packages which were at least once
> upload to jessie-security/stretch-security etc.

That does sound unfortunate in the Go context.

It is worth bearing in mind though, that you only need to rebuild the
binary-containing packages, so if the number of binary-containing
packages supported by the security team is tightly constrained, then
so is the number of (no-change source, I guess) uploads required to
handle any security update (e.g. in Ubuntu 16.04 there are only three
packages that contain Go binaries in main).

The changes I'm making in Ubuntu to use shared libraries should in the
common case (i.e. the fix does not break ABI) make this better, but
worst case (where the fix breaks ABI) it will be worse as we might end
up having to rebuild the whole rdep tree.

Cheers,
mwh

> And with that setup (and in addition to what Florian mentioned) I see
> no sane way that we can support Go applications in stretch. It's
> already difficult enough to support a distro of the size of Debian with
> volunteers only.

> As Haskell was mentioned; sure it has the same problem. But Go is a totally
> different ballpark: Go aims at system-level services which have a notable
> security surface (think of docker or kubernetes), while I can't remember
> any security vulnerability in an application written in Haskell in the
> archive in the 10+ years I'm in the Security Team.
>
> Cheers,
> Moritz
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

Re: [pkg-go] Security support for packages written in Go

[Michael Hudson-Doyle]

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 really close and we can't support
>>> the status quo for stretch.
>>
>> The discussion stalled at that point. AFAIK, there is no technical
>> solution for this. The best we could do is to have easier ways to track
>> dependency chains, but that does not change the fact that all golang
>> applications are still statically built, and so would require rebuilds
>> when security bugs are discovered and fixed.
>>
>> I understand this is problematic, but not sure we can do anything about
>> it at this point.
>
> Hi everyone.  I've done a small amount of research into the buildmode=c-shared
> and the dynlink option and they look good on paper.  Has anyone examined these
> options more seriously?

Well, using them in Ubuntu was the reason Canonical paid me to
implement them, so yes... I'm am currently in the process of starting
to use these features in Ubuntu. My plan, such as it was, was to use
them in Ubuntu through the 16.10 cycle and then propose the changes to
Debian too, assuming they work out OK.

> My guess would be that there might be a bunch of as yet undiscovered
> platform-specific bugs with this,

FWIW, I currently know of no platform specific bugs (if you use 1.7rc1
or the patches on 1.6.2 I have in Ubuntu). But I have been in this
position before :-)

> and it's probably too late at this stage to make
> such a major change to the golang package build process.

I would tend to agree that getting this stood up in time for stretch
isn't a great idea.

Cheers,
mwh

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

[pkg-go] 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

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

[pkg-go] Bug#828985: Bug#828985: golang-github-gosimple-slug: FTBFS: FAIL: TestSubstituteLang (0.00s) slug_test.go:155: 1. Substitute("o a o", map[string]string{"o":"no", "a":"or"}) = "no nor no"; wan

[Michael Hudson-Doyle]

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
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> golang-github-gosimple-slug fails to build from source in unstable/amd64:
>
>   [..]
>
>
>   
> **
>   ** Starting build   
> **
>   
> **
>
>Package:  golang-github-gosimple-slug
>Version:  1.0-1
>Build architecture:   amd64
>Date: Wed, 29 Jun 2016 15:55:39 +0200
>Hostname: 8d018f376876
>Uname:Linux 8d018f376876 4.5.0-2-amd64 #1 SMP Debian 
> 4.5.4-1 (2016-05-16) x86_64 GNU/Linux
>/etc/timezone:Africa/Johannesburg
>
>   
> **
>   ** Installing build dependencies
> **
>   
> **
>
>   dh_testdir
>   dh_testroot
>   dh_prep
>   dh_testdir
>   dh_testroot
>   dh_install
>   dh_installdocs
>   dh_installchangelogs
>   dh_compress
>   dh_fixperms
>   dh_installdeb
>   dh_gencontrol
>   dh_md5sums
>   dh_builddeb
>   dpkg-deb: building package 'golang-github-gosimple-slug-build-deps' in 
> '../golang-github-gosimple-slug-build-deps_1.0-1_all.deb'.
>
>   The package has been created.
>   Attention, the package has been created in the current directory,
>   not in ".." as indicated by the message above!
>   Selecting previously unselected package 
> golang-github-gosimple-slug-build-deps.
>   (Reading database ... 23075 files and directories currently installed.)
>   Preparing to unpack golang-github-gosimple-slug-build-deps_1.0-1_all.deb ...
>   Unpacking golang-github-gosimple-slug-build-deps (1.0-1) ...
>   Reading package lists...
>   Building dependency tree...
>   Reading state information...
>   Correcting dependencies... Done
>   The following additional packages will be installed:
> dh-golang golang-1.6-go golang-1.6-src 
> golang-github-rainycape-unidecode-dev
> golang-go golang-src
>   Suggested packages:
> bzr ca-certificates mercurial subversion
>   Recommended packages:
> pkg-config
>   The following NEW packages will be installed:
> dh-golang golang-1.6-go golang-1.6-src 
> golang-github-rainycape-unidecode-dev
> golang-go golang-src
>   0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
>   1 not fully installed or removed.
>   Need to get 26.8 MB of archives.
>   After this operation, 192 MB of additional disk space will be used.
>   Get:1 http://httpredir.debian.org/debian sid/main amd64 dh-golang all 1.18 
> [9278 B]
>   Get:2 http://httpredir.debian.org/debian sid/main amd64 golang-1.6-src 
> amd64 1.6.2-2 [6784 kB]
>   Get:3 http://httpredir.debian.org/debian sid/main amd64 golang-1.6-go amd64 
> 1.6.2-2 [19.7 MB]
>   Get:4 http://httpredir.debian.org/debian sid/main amd64 golang-src amd64 
> 2:1.6.1+1 [2974 B]
>   Get:5 http://httpredir.debian.org/debian sid/main amd64 golang-go amd64 
> 2:1.6.1+1 [21.9 kB]
>   Get:6 http://httpredir.debian.org/debian sid/main amd64 
> golang-github-rainycape-unidecode-dev all 0.0~git20150906.0.c9cf8cd-1 [267 kB]
>   Fetched 26.8 MB in 0s (108 MB/s)
>   Selecting previously unselected package dh-golang.
>   (Reading database ...
> (Reading database ... 5%
> (Reading database ... 10%
> (Reading database ... 15%
> (Reading database ... 20%
> (Reading database ... 25%
> (Reading database ... 30%
> (Reading database ... 35%
> (Reading database ... 40%
> (Reading database ... 45%
> (Reading database ... 50%
> (Reading database ... 55%
> (Reading database ... 60%
> (Reading database ... 65%
> (Reading database ... 70%
> (Reading database ... 75%
> (Reading database ... 80%
> (Reading database ... 85%
> (Reading database ... 90%
> (Reading database ... 95%
> (Reading database ... 100%
> (Reading database ... 23079 files and directories currently installed.)
>   Preparing to unpack .../dh-golang_1.18_all.deb ...
>   Unpacking dh-golang (1.18) ...
>   Selecting previously unselected package golang-1.6-src.
>   Preparing to unpack .../golang-1.6-src_1.6.2-2_amd64.deb ...
>   Unpacking golang-1.6-src (1.6.2-2) ...
>   Selecting previously unselected package golang-1.6-go.
>   Preparing to unpack .../golang-1.6-go_1.6.2-2_amd64.deb ...
>   Unpacking golang-1.6-go (1.6.2-2) ...
>   Selecting previously unselected package golang-src.
>   Preparing to unpack 

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

[Michael Hudson-Doyle]

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 wrote:
>> > I do not mind having full upstream history in "upstream"
>> > branch but not in "master"...
>> I don't really have any issue with having all the
>> commits, as it is pretty clear to me which ones belong to debian,
>
> I found it hard to believe. Looking at commit log [1], how many pages you
> need to skip to find packaging commits prior to merge of last upstream
> release to master? This is not the worst case as upstream is not too active
> but there are projects with thousands of commits between releases...
> All git GUIs are affected because those commits are obstructing.
> Besides depending on git GUI it may be not so clear which commits are
> related to packaging...
>
> [1]: 
> https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-shirou-gopsutil.git/log/
>
> --
> Regards,
>  Dmitry Smirnov.
>
> ---
>
> A creative man is motivated by the desire to achieve, not by the desire
> to beat others.
> -- Ayn Rand
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[pkg-go] Bug#827928: 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-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

Re: [pkg-go] build-dependency loop: golang-github-coreos-pkg and golang-github-coreos-go-systemd

[Michael Hudson-Doyle]

On 21 June 2016 at 17:57, Dmitry Smirnov <only...@debian.org> 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 the upstream situation
>> (github.com/coreos/pkg/capnslog/journald_formatter imports
>> github.com/coreos/go-systemd/journal,
>> github.com/coreos/go-systemd/journal and
>> github.com/coreos/go-systemd/sdjournal/journal import
>> github.com/coreos/pkg/dlopen) but it's not good for a distribution.
>> Does anyone have any ideas as to how we could fix it? I guess
>> github.com/coreos/pkg/dlopen could become its own package?
>
> Hi Michael,
>
> It would be great if you could discuss this matter with upstream...

https://github.com/coreos/go-systemd/issues/183

Cheers,
mwh

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

[pkg-go] build-dependency loop: golang-github-coreos-pkg and golang-github-coreos-go-systemd

[Michael Hudson-Doyle]

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/journal and
github.com/coreos/go-systemd/sdjournal/journal import
github.com/coreos/pkg/dlopen) but it's not good for a distribution.
Does anyone have any ideas as to how we could fix it? I guess
github.com/coreos/pkg/dlopen could become its own package?

Cheers,
mwh

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

[pkg-go] Bug#827697: 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)

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

[pkg-go] Bug#827697: 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.

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

[pkg-go] Bug#827219: 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

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

[pkg-go] Bug#827219: 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.

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

[pkg-go] Bug#827219: 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!

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

[pkg-go] Bug#827219: 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.

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

[pkg-go] Bug#827226: 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-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

Re: [pkg-go] RFS: new upstream snapshot golang-github-erikdubbelboer-gspt

[Michael Hudson-Doyle]

On 26 May 2016 at 06:34, Peter Colberg <pe...@colberg.org> 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-newmaint/2016/05/msg00036.html

Ah, same :-)

Cheers,
mwh

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

Re: [pkg-go] autopkgtest

[Michael Hudson-Doyle]

OK. Reload https://github.com/mwhudson/autodep8/compare/master...go-support
again?

Cheers,
mwh

On 22 May 2016 at 14:51, Martín Ferrari <tin...@tincho.org> 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
>> (or fail to build!) in DH_GOLANG_EXCLUDES. You could argue that such
>> packages are broken, but there are definitely a few in the archive.
>> Perhaps we should just patch those tests out (// +build ignore, I guess)
>> instead...
>
> Yes. I think that go packages should pass tests as installed. If they
> don't, we should fix them
>
>
> --
> Martín Ferrari (Tincho)
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

Re: [pkg-go] RFS: new upstream snapshot golang-github-erikdubbelboer-gspt

[Michael Hudson-Doyle]

On 25 May 2016 at 04:50, Peter Colberg <pe...@colberg.org> 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.

Thanks. Can you upload?

> Do you have lintian enabled in .sbuildrc?
>
> # ~/.sbuildrc
> $run_lintian = 1;
> $lintian_opts = ['-i', '-I', '--color=always'];

I do, but IIRC that doesn't run lintian on the dsc, just on the debs.
Maybe I do not RC...

Cheers,
mwh

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

Re: [pkg-go] RFS: new upstream snapshot golang-github-erikdubbelboer-gspt

[Michael Hudson-Doyle]

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 <pe...@colberg.org> wrote:
> Hi Michael,
>
> On Fri, May 20, 2016 at 09:11:30PM +1200, Michael Hudson-Doyle wrote:
>> 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
>> tag and upload pls?
>
> Thanks for investigating and fixing this test failure!
>
> Before the upload, could you apply these changes?
>
>  * add yourself to Uploaders field and run `wrap-and-sort`
>  * update Standards-Version to 3.9.8
>  * remove trailing space in first changelog entry (see `git log -p --color`)
>
> (The first two issues are flagged by lintian.)
>
> Regards,
> Peter

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

Re: [pkg-go] autopkgtest

[Michael Hudson-Doyle]

On 21/05/2016 7:33 am, "Martín Ferrari" <tin...@tincho.org> 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
>
> On 20/05/16 05:51, Michael Hudson-Doyle wrote:
>
> >> GOPATH=/usr/share/gocode go test -short $(perl
> >> -MDebian::Debhelper::Dh_Buildsystems -e 'buildsystems_init(); my $bs =
> >> load_buildsystem("golang"); print(join " ", $bs->get_targets(),
> >> "\n");')
> >
> > Oh, this doesn't quite work does it, because you want the influence of
> > the other variables that might be set in rules, like
> > DH_GOLANG_BUILDPKG & DH_GOLANG_EXCLUDES. Maybe just re-running the
> > package build in the autopkgest environment would be best, or at least
> > ./debian/rules build. It wouldn't even be very inefficient, because
> > the package has to be recompiled to be tested anyway.
>
> Actually, the idea is to test the *installed* package. So IMO the best
> is to just get the import-path and run go test with the GOPATH set as
> you suggest.
>
> I tried this locally and works perfectly.

It won't work for debian packages that have go packages that fail tests (or
fail to build!) in DH_GOLANG_EXCLUDES. You could argue that such packages
are broken, but there are definitely a few in the archive. Perhaps we
should just patch those tests out (// +build ignore, I guess) instead...

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

[pkg-go] RFS: new upstream snapshot golang-github-erikdubbelboer-gspt

[Michael Hudson-Doyle]

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
tag and upload pls?

Cheers,
mwh

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

Re: [pkg-go] autopkgtest

[Michael Hudson-Doyle]

On 20 May 2016 at 16:24, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> Somehow I don't have Martín's original mail...
>
> On 5 April 2016 at 15:40, Dmitry Smirnov <only...@debian.org> 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
>>> implement it. But I did not follow any of the details. Today I took a
>>> deeper look, and it seems that we would benefit tremendously from that!
>>
>> It is always nice to use all those lovely practices of Perl team. :)
>>
>>
>>> The idea of autopkgtest is to mark packages as having an automated
>>> post-build test suite, so the ci.debian.net project would pick them
>>> automatically (and also for our own testing).
>>>
>>> These tests would trigger each time the package or its dependencies are
>>> updated, and they consist of installing the package and its
>>> dependencies, and running a series of scripts to verify proper
>>> behaviour, run unit tests, etc. All executed using the installed package
>>> instead of a source tree.
>>
>> It seems that Autopkgtest could be useful to run test suites that require
>> root priviledges etc.
>
> True. But I'd also be pretty interested in just having the tests run
> when dependencies change (and on all architectures for the source
> packages that currently just make an _all dev package).
>
>>> Here is the description of how the pkg-perl did their integration,
>>> making most of the testing automatic:
>>> http://pkg-perl.alioth.debian.org/autopkgtest.html
>>
>> Nice. Thanks for this information.
>
> 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::Debhelper::Dh_Buildsystems -e 'buildsystems_init(); my $bs =
> load_buildsystem("golang"); print(join " ", $bs->get_targets(),
> "\n");')
>
>>> I think this would be a great asset for the team. What do you people think?
>
> Absolutely! Seems a patch to autodep8 is the first step?

Something like https://github.com/mwhudson/autodep8/compare/master...go-support
maybe?

I'll stop mailbombing you all now.

Cheers,
mwh

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

Re: [pkg-go] autopkgtest

[Michael Hudson-Doyle]

On 20 May 2016 at 16:24, Michael Hudson-Doyle
<michael.hud...@canonical.com> 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::Debhelper::Dh_Buildsystems -e 'buildsystems_init(); my $bs =
> load_buildsystem("golang"); print(join " ", $bs->get_targets(),
> "\n");')

Oh, this doesn't quite work does it, because you want the influence of
the other variables that might be set in rules, like
DH_GOLANG_BUILDPKG & DH_GOLANG_EXCLUDES. Maybe just re-running the
package build in the autopkgest environment would be best, or at least
./debian/rules build. It wouldn't even be very inefficient, because
the package has to be recompiled to be tested anyway.

Cheers,
mwh

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

Re: [pkg-go] RFC: Enhancements to dh-golang

[Michael Hudson-Doyle]

On 13 May 2016 at 00:52, Martín Ferrari <tin...@tincho.org> 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 :) AFAIK, the 'testdata'
> directory is not special in go, and many packages have other names
> (fixtures is a common one). I think it is a bad idea to add this.

'testdata' is a little special to the Go tool: it ignores such
directories entirely, and it does seem to be pretty commonly used in
the random subset of packages I have in my GOPATH today and

https://codesearch.debian.net/perpackage-results/testdata%20path%3Adebian%2Frules%20/2/page_0

certainly shows lots of lines that could be removed if this was added
(in fact, maybe they would now cause errors or misbehave, which is
perhaps an argument against this change without some compat stuff...)

Cheers,
mwh

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

Re: [pkg-go] RFC: Enhancements to dh-golang

[Michael Hudson-Doyle]

On 9 May 2016 at 13:23, Martín Ferrari <tin...@tincho.org> 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.

This seems to do the trick for me:

diff --git a/lib/Debian/Debhelper/Buildsystem/golang.pm
b/lib/Debian/Debhelper/Buildsystem/golang.pm
index 4d73d99..4fbf1d7 100644
--- a/lib/Debian/Debhelper/Buildsystem/golang.pm
+++ b/lib/Debian/Debhelper/Buildsystem/golang.pm
@@ -103,6 +103,8 @@ sub configure {
 my $name = substr($File::Find::name, 2);
 if ($install_all) {
 # All files will be installed
+} elsif ($File::Find::name =~ m%/testdata/%) {
+# testdata directories are always copied
 } else {
 my $dot = rindex($name, ".");
 return if $dot == -1;

(only lightly tested, but tested)

>>> override_dh_auto_install:
>>> dh_auto_install -O--buildsystem=golang -- --no-source
>>
>> Like Dmitry, I guess I'm only +0 on this.
>
> I see the point... I don't think it adds clutter, but I'd remove it if
> people are not too happy about it.

Certainly the implementation seems simple enough. Don't much care either way!

>> Hmmm. Can see the point, but it would be a lt of output in some
>> cases. DH_VERBOSE doesn't really support levels of verbosity does it?
>
> It is a lot of output, but currently, you have no way to see what is
> actually being included in the build, which I think is a problem. I
> thought of this when adding the first feature, because I had no way to
> easily see what was going on!
>
> About verbosity levels, not really. You have: normal, verbose, and quiet
> mode.
>
> Personally, I think this is valuable output, and one can just use
> DH_VERBOSE=0

I think I agree the information is worth the log spam. So +1 on this
for me -- we can always find some other way to moderate it later if we
feel the need...

Cheers,
mwh

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

[pkg-go] recording the go import path in a golang-*-dev binary package's control fields

[Michael Hudson-Doyle]

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 files into, which is not quite the same but sufficient
for what I was doing).

Would it not make sense for the -dev package to contain a
Go-Import-Path control field? Or record it some other way?

Cheers,
mwh

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

Re: [pkg-go] RFC: Enhancements to dh-golang

[Michael Hudson-Doyle]

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.
>
>
> * Export DH_GOLANG_INSTALL_EXTRA with a list of space-separated paths to
> copy to the build dir, for tests and other files not automatically
> installed.
>
> This means we can stop using the INSTALL_ALL=1+rm combo, which I think
> is pretty awkward. Instead, one would do (real example from the
> prometheus package):
>
> export DH_GOLANG_INSTALL_EXTRA := retrieval/discovery/fixtures \
> storage/local/fixtures config/testdata promql/testdata \
> retrieval/testdata

+1

(parenthetically, as I think I said on IRC, dh-golang should just copy
testdata by default)

> * Add --no-source and --no-binaries options to install target.
>
> This avoids the need to remove debian/prometheus/usr/share/gocode, and
> would go a long way to fix #814690, and I think is generally a good
> idea, to make it simple to split packages in binary and sources. Again,
> a real (and tested) example from prometheus:
>
> override_dh_auto_install:
> dh_auto_install -O--buildsystem=golang -- --no-source

Like Dmitry, I guess I'm only +0 on this.

> * Display a debug message when copying files to the build tree.
>
> A minor change, I think that when DH_VERBOSE is set, all the copy and
> symlink operations during preparation of the source tree should be
> printed. It looks like this:
>
> Copy retrieval/testdata/server.cer ->
> build/src/github.com/prometheus/prometheus/retrieval/testdata/server.cer
> Copy retrieval/testdata/client.cer ->
> build/src/github.com/prometheus/prometheus/retrieval/testdata/client.cer
> Symlink /usr/share/gocode/src/code.google.com -> 
> build/src/code.google.com
> Symlink /usr/share/gocode/src/github.com/asaskevich ->
> build/src/github.com/asaskevich

Hmmm. Can see the point, but it would be a lt of output in some
cases. DH_VERBOSE doesn't really support levels of verbosity does it?

Cheers,
mwh

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

Re: [pkg-go] RFS: golang-protobuf-extensions patch to disable failing test

[Michael Hudson-Doyle]

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 has not 
> been fixed at this stage.  I've even added a DEP3 header recording this info.
>
> Could someone please review and upload?  Thanks again!

Did this ever happen? I'm asking because upstream has now (finally)
disabled these tests so we should probably package a new upstream
snapshot instead/as well.

Cheers,
mwh

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

Re: [pkg-go] [PATCH] Compute Built-Using with go list, not Build-Depends

[Michael Hudson-Doyle]

On 15 April 2016 at 03:55, Martín Ferrari <tin...@tincho.org> 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
>> dependencies. Use go list and dpkg-query --search instead to find out which
>> (debian) packages installed the (go) packages that were actually used during
>> the build instead.
>>
>> As a bonus, this is shorter and arguably simpler that what it replaces.
>
> Just one comment. Shouldn't the build-using also include all
> build-dependencies, not only the golang ones?

No, I don't think so. Policy 7.8 says:

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 [56], including an
"exactly equal" ("=") version relation on the version that was used to
build that binary package[57].

By default, at least, go packages using cgo will dynamically link
against the C libraries and so get the appropriate runtime
dependencies via dpkg-makeshlibdeps. Packages that statically link
against C libraries will need to take further steps to get an accurate
Built-Using, but that's not something for dh-golang to worry over I
think.

Cheers,
mwh

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

Re: [pkg-go] [PATCH] Compute Built-Using with go list, not Build-Depends

[Michael Hudson-Doyle]

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 replace it, ala:
>
> (and I'm happy to actually commit and upload the fix if sECuRE gives ACK)

Yeah, that's the problem. I was testing with a package that set GOPATH in
rules :-( I sent the same fix to the bug, or at least tried to...

Cheers,
mwh

> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] [pkg-golang-devel] Security support for packages written in Go

[Michael Hudson-Doyle]

On 14 April 2016 at 19:16, Michael Stapelberg <stapelb...@debian.org> wrote:
> Thanks for the patch, it’s now merged and uploaded.

Awesome, thanks for that.

> I’d prefer if you could send such patches in a bug report instead of to
> mailing lists which I don’t actively read :).

Noted!

> In fact, I’d say it’s long overdue to make this package team-maintained.

Sounds sensible.

> The repository is already in
> collab-maint, so if you want to make the necessary changes, please just go
> ahead.

I don't think I can commit to collab-maint (I'm not a DD or even a DM yet).

Cheers,
mwh

> With regards to the original post, I think we have the same issue that the
> haskell packaging community has, since they have the same linking model.
> I’ve talked to Joachim Breitner (nomeata) about this a couple years ago and
> he mentioned they have some tooling which addresses 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 at 3:08 AM, Michael Hudson-Doyle
> <michael.hud...@canonical.com> wrote:
>>
>> On 13 April 2016 at 21:05, Michael Hudson-Doyle
>> <michael.hud...@canonical.com> wrote:
>> > On 13 April 2016 at 17:07, Tianon Gravi <admwig...@gmail.com> wrote:
>> >> On 12 April 2016 at 21:39, Michael Hudson-Doyle
>> >> <michael.hud...@canonical.com> 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 could be done as a fallback?
>> >>
>> >> I still asking dpkg about file/directory package ownership should be
>> >> our primary means of generating this field -- the metadata that dpkg
>> >> itself tracks about "which package provided
>> >> /usr/share/gocode/src/abc/xyz which I just compiled against" will
>> >> always be correct (due to the fact that it really is the single proper
>> >> source of truth for such information), where some arbitrary metadata
>> >> we add not only clutters up the package metadata as has been
>> >> discussed, but much more importantly will have a tendency to "drift"
>> >> from the truth, which is something that IMO we shouldn't tolerate for
>> >> a field whose primary purpose is knowing when it's necessary to
>> >> rebuild, especially for security fixes.  Even for really large
>> >> packages like Docker (to choose an example that I know off the top of
>> >> my head is reasonably hefty WRT deps) we're only talking about maybe
>> >> ~200 of these queries at the outside end, and only at build-time, and
>> >> only once per build, which IMO is in the realm of reasonable to avoid
>> >> yet again uploading a minor fix to every package (moving the metadata
>> >> over to the binary packages when we still haven't added the existing
>> >> source package metadata to all of them yet) with information that will
>> >> have a potential for drifting from the truth or for being too limited
>> >> (single package providing multiple namespaces after a repo move, for
>> >> example).
>> >
>> > Yes, all that seems fair. Something like this?
>> > http://paste.ubuntu.com/15806327/ -- it's pretty terrible perl, but
>> > it's actually arguably simpler than what dh_golang does already!
>>
>> FWIW, I sent a better version of this patch:
>>
>> http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160411/004304.html
>>
>> Cheers,
>> mwh
>
>
>
>
> --
> Best regards,
> Michael

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

Re: [pkg-go] [pkg-golang-devel] Security support for packages written in Go

[Michael Hudson-Doyle]

On 13 April 2016 at 21:05, Michael Hudson-Doyle
<michael.hud...@canonical.com> wrote:
> On 13 April 2016 at 17:07, Tianon Gravi <admwig...@gmail.com> wrote:
>> On 12 April 2016 at 21:39, Michael Hudson-Doyle
>> <michael.hud...@canonical.com> 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 could be done as a fallback?
>>
>> I still asking dpkg about file/directory package ownership should be
>> our primary means of generating this field -- the metadata that dpkg
>> itself tracks about "which package provided
>> /usr/share/gocode/src/abc/xyz which I just compiled against" will
>> always be correct (due to the fact that it really is the single proper
>> source of truth for such information), where some arbitrary metadata
>> we add not only clutters up the package metadata as has been
>> discussed, but much more importantly will have a tendency to "drift"
>> from the truth, which is something that IMO we shouldn't tolerate for
>> a field whose primary purpose is knowing when it's necessary to
>> rebuild, especially for security fixes.  Even for really large
>> packages like Docker (to choose an example that I know off the top of
>> my head is reasonably hefty WRT deps) we're only talking about maybe
>> ~200 of these queries at the outside end, and only at build-time, and
>> only once per build, which IMO is in the realm of reasonable to avoid
>> yet again uploading a minor fix to every package (moving the metadata
>> over to the binary packages when we still haven't added the existing
>> source package metadata to all of them yet) with information that will
>> have a potential for drifting from the truth or for being too limited
>> (single package providing multiple namespaces after a repo move, for
>> example).
>
> Yes, all that seems fair. Something like this?
> http://paste.ubuntu.com/15806327/ -- it's pretty terrible perl, but
> it's actually arguably simpler than what dh_golang does already!

FWIW, I sent a better version of this patch:
http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160411/004304.html

Cheers,
mwh

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

[pkg-go] [PATCH] Compute Built-Using with go list, not Build-Depends

[Michael Hudson-Doyle]

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
the build instead.

As a bonus, this is shorter and arguably simpler that what it replaces.
---
 lib/Debian/Debhelper/Buildsystem/golang.pm |  8 ++-
 script/dh_golang   | 99 --
 2 files changed, 30 insertions(+), 77 deletions(-)

diff --git a/lib/Debian/Debhelper/Buildsystem/golang.pm 
b/lib/Debian/Debhelper/Buildsystem/golang.pm
index bedafd0..fbdf510 100644
--- a/lib/Debian/Debhelper/Buildsystem/golang.pm
+++ b/lib/Debian/Debhelper/Buildsystem/golang.pm
@@ -35,6 +35,11 @@ sub _set_dh_gopkg {
 $ENV{DH_GOPKG} = $source->{"XS-Go-Import-Path"};
 }
 
+sub _set_gopath {
+my $this = shift;
+$ENV{GOPATH} = $this->{cwd} . '/' . $this->get_builddir();
+}
+
 sub _link_contents {
 my ($src, $dst) = @_;
 
@@ -156,7 +161,6 @@ sub get_targets {
 sub build {
 my $this = shift;
 
-$ENV{GOPATH} = $this->{cwd} . '/' . $this->get_builddir();
 if (exists($ENV{DH_GOLANG_GO_GENERATE}) && $ENV{DH_GOLANG_GO_GENERATE} == 
1) {
 $this->doit_in_builddir("go", "generate", "-v", @_, get_targets());
 }
@@ -166,7 +170,7 @@ sub build {
 sub test {
 my $this = shift;
 
-$ENV{GOPATH} = $this->{cwd} . '/' . $this->get_builddir();
+$this->_set_gopath();
 $this->doit_in_builddir("go", "test", "-v", @_, get_targets());
 }
 
diff --git a/script/dh_golang b/script/dh_golang
index fad7998..5e1e71d 100755
--- a/script/dh_golang
+++ b/script/dh_golang
@@ -7,6 +7,7 @@ dh_golang - Generates Built-Using substvar
 =cut
 
 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
@@ -15,6 +16,7 @@ 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;
 
 =head1 SYNOPSIS
 
@@ -23,14 +25,9 @@ B [S]
 =head1 DESCRIPTION
 
 B is a debhelper program which adds the misc:Built-Using substvar
-based on the Build-Dependencies of your packages. Every package starting with
-golang is queried for the precise version number.
-
-As an example, if you Build-Depend on golang-pq-dev, the resulting
-misc:Built-Using value (aside from the precise version number) will look like
-this:
-
-golang (= 2:1.1.1-1), golang-pq-dev (= 0.0~git20130606-1),
+based on the dependencies of the package being built. It uses go list to
+determine the packages imported and dpkg-query to find the source package and
+version that provided that package.
 
 =head1 NOTES
 
@@ -40,80 +37,32 @@ The best way to invoke B is by using B.
 
 init();
 
-# This code was copied from dpkg-checkbuilddeps, see
-# 
http://sources.debian.net/src/dpkg/1.18.1/scripts/dpkg-checkbuilddeps.pl/?hl=140#L140
-sub parse_status {
-my $status = shift;
-
-my $facts = Dpkg::Deps::KnownFacts->new();
-local $/ = '';
-open(my $status_fh, '<', $status)
-or syserr(g_('cannot open %s'), $status);
-while (<$status_fh>) {
-next unless /^Status: .*ok installed$/m;
-
-my ($package) = /^Package: (.*)$/m;
-my ($version) = /^Version: (.*)$/m;
-my ($arch) = /^Architecture: (.*)$/m;
-my ($multiarch) = /^Multi-Arch: (.*)$/m;
-$facts->add_installed_package($package, $version, $arch,
-  $multiarch);
-
-if (/^Provides: (.*)$/m) {
-my $provides = deps_parse($1, reduce_arch => 1, union => 1);
-next if not defined $provides;
-foreach (grep { $_->isa('Dpkg::Deps::Simple') }
- $provides->get_deps())
-{
-$facts->add_provided_package($_->{package},
-$_->{relation}, $_->{version},
-$package);
-}
-}
-}
-close $status_fh;
-
-return $facts;
-}
-
 
-# Generate misc:Built-Using substvar with the versions of all golang-*
-# build-dependency packages.
+# Generate misc:Built-Using substvar.
 
 
-my $built_using;
-
-my $control = Dpkg::Control::Info->new();
-my $source = $control->get_source();
-my $build_depends = $source->{"Build-Depends"};
-if (defined($build_depends) && $build_depends ne '') {
-my $facts;
-if ($Dpkg::VERSION >= 1.01) {
-$facts = parse_status($Dpkg::ADMINDIR . "/status");
-} else {
-$facts = parse_status($Dpkg::admindir . "/status");
-}
+my $bs = Debian::Debhelper::Buildsystem::golang->new();
 
-sub