Re: [pkg-go] gcsfuse -- fuse file system for Google Cloud Storage

[Michael Stapelberg]

I’m a bit pressed on time, so short reply: See
https://qa.debian.org/developer.php?login=stapelberg%40debian.org for which
packages are in Debian and which ones are in NEW.

Currently, all further packages are blocked on golang-golang-x-sys getting
accepted.

paultag, can you help with that? :)

On Mon, Jun 22, 2015 at 3:34 AM, Aaron Jacobs jaco...@google.com wrote:

 Hi Michael,

 Any progress with the remaining packages? Feel free to ignore my
 philosophical
 questions/suggestions if they're not relevant or helpful.

 Aaron

 On Mon, Jun 15, 2015 at 8:32 AM, Aaron Jacobs jaco...@google.com wrote:
  On Fri, Jun 12, 2015 at 5:02 PM, Michael Stapelberg
  stapelb...@debian.org wrote:
  The Debian policy is to not ship copies of libraries in packages. For C,
  that works quite well, since library authors are generally aware of
 SONAMEs
  and when they need to bump them. For Go, package paths are supposed to
 never
  break backwards compatibility, and it seems like most of the community
  agrees. We haven’t had a single case of backwards compatibility
 breakage yet
  (that I know of).
 
  I agree it's the convention to never break backwards compatibility, but
 it does
  happen from time to time. I will sheepishly raise my hand and say that
 I've
  done it, and will probably do it again, for code that I own where other
 code I
  own is the primary or sole user.
 
  In such a case, would bumping a major semantic version number (in the
 form of a
  git tag) help you? I guess this would be the analog of C library
 versions, but
  I don't actually know how Debian deals with the problem of dependent A
 needing
  version 1 and dependent B needing version 2, even for C libraries.
 
 
  On Mon, Jun 15, 2015 at 7:13 AM, Michael Stapelberg
  stapelb...@debian.org  golang-github-jacobsa-oglematchers is in
  Debian
  golang-github-jacobsa-reqtrace is in Debian
  golang-goprotobuf was updated in Debian
 
  golang-github-jacobsa-oglemock is in the NEW queue
  golang-github-jacobsa-ogletest is in the NEW queue
  golang-google-appengine is in the NEW queue
  golang-golang-x-oauth2 is in the NEW queue
 
  Great! Thank you. :-)
 
 
  Looking at remaining dependencies, you could save me a lot of headaches
 if
  you could split out github.com/googlecloudplatform/gcsfuse/timeutil
 into a
  separate repository. Otherwise, we have circular dependencies
  (github.com/googlecloudplatform/gcsfuse depends on
 github.com/jacobsa/fuse,
  which depends on github.com/googlecloudplatform/gcsfuse/timeutil).
 
  Also, either doing the same with github.com/jacobsa/gcloud/syncutil or
  inlining the (github.com/jacobsa/fuse/fsutil).AnonymousFile call in
  github.com/jacobsa/gcloud/gcs/tools/gcsthroughput/gcsthroughput.go
 would
  help as well.
 
  I had been feeling guilty I hadn't done this anyway; thanks for the
 push. Done:
 
  https://github.com/jacobsa/timeutil
  https://github.com/jacobsa/syncutil




-- 
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] gcsfuse -- fuse file system for Google Cloud Storage

[Michael Stapelberg]

I take that back — actually, building even the leaf packages with tests
enabled requires having x/net :). I’ve pinged tincho who last touched that
repository.

On Thu, Jun 11, 2015 at 4:28 PM, Michael Stapelberg stapelb...@debian.org
wrote:

 I’ve spent a bit of time analyzing the dependencies and came up with the
 graph you can find attached. There are two leaf packages that can be
 immediately tackled, the rest will require tackling the
 golang.org/x/net/context packaging situation first.

 On Thu, Jun 11, 2015 at 4:43 AM, Aaron Jacobs jaco...@google.com wrote:

 On Thu, Jun 11, 2015 at 6:11 PM, Michael Stapelberg
 stapelb...@debian.org wrote:
  I’ve uploaded oglematchers now. Will take a look at the rest later/this
  weekend.

 Cool, thank you!




 --
 Best regards,
 Michael




-- 
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] Packaging a Go binary

[Michael Stapelberg]

I think you should try to convince upstream to make their software work
with the HEAD version of all their dependencies, or, if they refuse to do
that, fork the dependencies in question and take over maintenance. Pushing
that burden to the user (what they are doing right now) doesn’t sound like
the best way to me.

On Wed, Jun 3, 2015 at 10:21 AM, Onur Aslan o...@onur.im wrote:

 I have a similar question.

 I found a nice software written in go: gogs[1]. It is a lightweight
 gitlab alternative. It was very useful for me and I decided to make a
 Debian package. And soon I realised gogs have tons of external
 dependencies[2]. It seems author is maintaining few modules in different
 repositories for only this project.

 And another issue is gogs is not working well with recent commit of one
 (or more) of its dependencies. For example it's acting weird if you use
 latest version of github.com/mattn/go-sqlite3. As in stated in .gopmfile
 it depends on github.com/mattn/go-sqlite3 = commit:e28cd440fa.

 Even if I make standalone packages for dependencies, gogs will most
 likely fail to build or run. Therefore I followed a different path. I
 wrote a simple script to clone and checkout required commit for all
 external dependencies and create proper directory structure for `go
 build` and created a source tarball from this. I know it is not proper
 way and it is not gonna work in Debian but I believe it's only way to
 build this software.

 So question is; is it even possible to release a Debian package for this
 project or should I just give up?


 1: https://github.com/gogits/gogs
 2: https://github.com/gogits/gogs/blob/master/.gopmfile


 On 2015-06-02, Michael Stapelberg wrote:
  For the record: I’ll be replying on the thread to pkg-go-maintainers:
 
 http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20150601/000276.html




-- 
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] RFS: Update for golang-go-systemd

[Michael Stapelberg]

On Thu, Aug 13, 2015 at 7:48 AM, Potter, Tim (Cloud Services)
timothy.pot...@hp.com wrote:
 OK - good idea.  I’ve done the rename and pushed to alioth.  I did a rebuild 
 and it was all fine
 but please double check!  Luckily there are no reverse dependencies on this 
 package yet.

There are none in Debian, but there might be in derivatives of Debian,
or in private installations. Further, the package made it to jessie
(see https://packages.debian.org/jessie/golang-go-systemd-dev), so we
want to ensure there is a good upgrade path.

Hence, can you please add the appropriate Breaks/Replaces and
transitional packages? See
https://anonscm.debian.org/cgit/pkg-go/packages/golang-go.net.git/commit/?id=189085288e608ca2720b32d551227d330a561123
for an example.



 Thanks,

 Tim.

 On 13 Aug 2015, at 3:11 pm, Michael Stapelberg stapelb...@debian.org wrote:

 I think before uploading, we should take the opportunity to make the
 package comply with our new naming scheme. Once you’ve done that I’m
 happy to take a look at it.

 On Thu, Aug 13, 2015 at 5:40 AM, Potter, Tim (Cloud Services)
 timothy.pot...@hp.com wrote:
 Hi everyone.  I noticed a while ago that a tag was made for v3 (yay) and 
 Tianon has even
 packaged it up.  It hasn’t been uploaded though - is there anything holding 
 it up?


 Tim.

 On 9 Jun 2015, at 10:50 am, Potter, Tim (Cloud Services) 
 timothy.pot...@hp.com wrote:

 I submitted a github issue asking if they would be so kind as to make 
 another snapshot.  No response yet - I’ve got an email address to try out 
 before saying this hasn’t worked.


 Tim.

 On 9 Jun 2015, at 5:54 am, Tianon Gravi admwig...@gmail.com wrote:

 Yeah, it's been my experience that upstream's usually pretty
 responsive with these kinds of requests (which is what makes me think
 they're worth at least poking before we go head-first into a
 snapshot).

 ♥,
 - Tianon
 4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


 On 8 June 2015 at 12:52, Michael Stapelberg stapelb...@debian.org wrote:
 That sure would be nice. Depending on the urgency, I’d be okay with
 uploading a snapshot if upstream doesn’t reply quickly, though.

 On Mon, Jun 8, 2015 at 9:40 PM, Tianon Gravi admwig...@gmail.com wrote:

 Oh jeez, my response must've been from my phone before I configured it
 to reply-all by default:

 Why not ask upstream to tag a v3 instead of packaging a snapshot?

 ♥,
 - Tianon
 4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


 On 8 June 2015 at 12:29, Michael Stapelberg stapelb...@debian.org 
 wrote:
 Sorry for the late reply. This all sounds good to me, please go ahead.

 On Mon, Jun 1, 2015 at 8:01 AM, Potter, Tim (Cloud Services)
 timothy.pot...@hp.com wrote:

 Hi everyone.  I’d like to propose an update to the golang-go-systemd
 package, to pull in files from the unit directory require for fleet.
 Here’s
 a debdiff between the version in Debian and my changes:

 debdiff /var/cache/apt/archives/golang-go-systemd-dev_2-1_all.deb
 /Source/pkg-go/build-area/golang-go-systemd-dev_2~git20150505-1_all.deb
 [The following lists of changes regard files as different if they have
 different names, permissions or owners.]

 Files in second .deb but not in first
 -
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/activation/packetconns.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/activation/packetconns_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/daemon/sdnotify.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/machine1/dbus.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/machine1/dbus_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/deserialize.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/deserialize_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/escape.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/escape_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/option.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/option_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/serialize.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/serialize_test.go

 Control files: lines which differ (wdiff format)
 
 Built-Using: golang (= [-2:1.2.1-2),-] {+2:1.4.2-3),+} golang-dbus (=
 [-1-1)-] {+2-1)+}
 Installed-Size: [-120-] {+137+}
 Version: [-2-1-] {+2~git20150505-1+}

 As you can see files are only added so this should be a change that
 does
 not break any existing packages.

 Please let me know if this is OK and I can push the updates to the
 pkg-go/packages repo.


 Tim

Re: [pkg-go] RFS: Update for golang-go-systemd

[Michael Stapelberg]

I think before uploading, we should take the opportunity to make the
package comply with our new naming scheme. Once you’ve done that I’m
happy to take a look at it.

On Thu, Aug 13, 2015 at 5:40 AM, Potter, Tim (Cloud Services)
timothy.pot...@hp.com wrote:
 Hi everyone.  I noticed a while ago that a tag was made for v3 (yay) and 
 Tianon has even
 packaged it up.  It hasn’t been uploaded though - is there anything holding 
 it up?


 Tim.

 On 9 Jun 2015, at 10:50 am, Potter, Tim (Cloud Services) 
 timothy.pot...@hp.com wrote:

 I submitted a github issue asking if they would be so kind as to make 
 another snapshot.  No response yet - I’ve got an email address to try out 
 before saying this hasn’t worked.


 Tim.

 On 9 Jun 2015, at 5:54 am, Tianon Gravi admwig...@gmail.com wrote:

 Yeah, it's been my experience that upstream's usually pretty
 responsive with these kinds of requests (which is what makes me think
 they're worth at least poking before we go head-first into a
 snapshot).

 ♥,
 - Tianon
 4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


 On 8 June 2015 at 12:52, Michael Stapelberg stapelb...@debian.org wrote:
 That sure would be nice. Depending on the urgency, I’d be okay with
 uploading a snapshot if upstream doesn’t reply quickly, though.

 On Mon, Jun 8, 2015 at 9:40 PM, Tianon Gravi admwig...@gmail.com wrote:

 Oh jeez, my response must've been from my phone before I configured it
 to reply-all by default:

 Why not ask upstream to tag a v3 instead of packaging a snapshot?

 ♥,
 - Tianon
 4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4


 On 8 June 2015 at 12:29, Michael Stapelberg stapelb...@debian.org wrote:
 Sorry for the late reply. This all sounds good to me, please go ahead.

 On Mon, Jun 1, 2015 at 8:01 AM, Potter, Tim (Cloud Services)
 timothy.pot...@hp.com wrote:

 Hi everyone.  I’d like to propose an update to the golang-go-systemd
 package, to pull in files from the unit directory require for fleet.
 Here’s
 a debdiff between the version in Debian and my changes:

 debdiff /var/cache/apt/archives/golang-go-systemd-dev_2-1_all.deb
 /Source/pkg-go/build-area/golang-go-systemd-dev_2~git20150505-1_all.deb
 [The following lists of changes regard files as different if they have
 different names, permissions or owners.]

 Files in second .deb but not in first
 -
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/activation/packetconns.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/activation/packetconns_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/daemon/sdnotify.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/machine1/dbus.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/machine1/dbus_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/deserialize.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/deserialize_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/escape.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/escape_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/option.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/option_test.go
 -rw-r--r--  root/root
 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/serialize.go
 -rw-r--r--  root/root

 /usr/share/gocode/src/github.com/coreos/go-systemd/unit/serialize_test.go

 Control files: lines which differ (wdiff format)
 
 Built-Using: golang (= [-2:1.2.1-2),-] {+2:1.4.2-3),+} golang-dbus (=
 [-1-1)-] {+2-1)+}
 Installed-Size: [-120-] {+137+}
 Version: [-2-1-] {+2~git20150505-1+}

 As you can see files are only added so this should be a change that
 does
 not break any existing packages.

 Please let me know if this is OK and I can push the updates to the
 pkg-go/packages repo.


 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




 --
 Best regards,
 Michael




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




-- 
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] Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests

[Michael Stapelberg]

Aaron, could you take a look at this problem please? It seems to me
like this is a shortcoming of your tests, unrelated to Debian.

On Fri, Aug 21, 2015 at 8:44 PM, Chris Lamb la...@debian.org wrote:
 Source: golang-github-jacobsa-ratelimit
 Version: 0.0~git20150723.0.2ca5e0c-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-jacobsa-ratelimit's testsuite appears to use method
 timing/benchmarking in such
 a way that it will non-deterministically FTBFS:

   throttle_test.go:
 expected := smallerRateHz * (float64(perCaseDuration) /
 float64(time.Second))

 For example:

   [..]
 go test -v github.com/jacobsa/ratelimit
   === RUN TestThrottle
   [--] Running tests from ThrottleTest
   [ RUN  ] ThrottleTest.IntegrationTest
   throttle_test.go:202:
   Expected: greater than 135, and less than 165
   Actual:   88
   Test case 0. expected: 150.00

   throttle_test.go:202:
   Expected: greater than 180, and less than 220.03
   Actual:   138
   Test case 1. expected: 200.00

   throttle_test.go:202:
   Expected: greater than 180, and less than 220.03
   Actual:   163
   Test case 2. expected: 200.00

   [  FAILED  ] ThrottleTest.IntegrationTest (6.031585896s)
   [--] Finished with tests from ThrottleTest
   [--] Running tests from ThrottledReaderTest
   [ RUN  ] ThrottledReaderTest.CallsThrottle
   [   OK ] ThrottledReaderTest.CallsThrottle
   [ RUN  ] ThrottledReaderTest.ThrottleReturnsError
   [   OK ] ThrottledReaderTest.ThrottleReturnsError
   [ RUN  ] ThrottledReaderTest.CallsWrapped
   [   OK ] ThrottledReaderTest.CallsWrapped
   [ RUN  ] ThrottledReaderTest.WrappedReturnsError
   [   OK ] ThrottledReaderTest.WrappedReturnsError
   [ RUN  ] ThrottledReaderTest.WrappedReturnsEOF
   [   OK ] ThrottledReaderTest.WrappedReturnsEOF
   [ RUN  ] ThrottledReaderTest.WrappedReturnsFullRead
   [   OK ] ThrottledReaderTest.WrappedReturnsFullRead
   [ RUN  ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain
   [   OK ] ThrottledReaderTest.WrappedReturnsShortRead_CallsAgain
   [ RUN  ]
   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError
   [   OK ]
   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsError
   [ RUN  ]
   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF
   [   OK ]
   ThrottledReaderTest.WrappedReturnsShortRead_SecondReturnsEOF
   [ RUN  ]
   ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull
   [   OK ]
   ThrottledReaderTest.WrappedReturnsShortRead_SecondSucceedsInFull
   [ RUN  ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity
   [   OK ] ThrottledReaderTest.ReadSizeIsAboveThrottleCapacity
   [--] Finished with tests from ThrottledReaderTest
   [--] Running tests from TokenBucketTest
   [ RUN  ] TokenBucketTest.CarefulAccounting
   [   OK ] TokenBucketTest.CarefulAccounting
   [--] Finished with tests from TokenBucketTest
   --- FAIL: TestThrottle (6.03s)
   === RUN TestThrottledReader
   --- PASS: TestThrottledReader (0.00s)
   === RUN TestTokenBucket
   --- PASS: TestTokenBucket (0.00s)
   FAIL
   exit status 1
   FAILgithub.com/jacobsa/ratelimit6.074s
   dh_auto_test: go test -v github.com/jacobsa/ratelimit returned exit
   code 1
   debian/rules:6: recipe for target 'build' failed
   make: *** [build] Error 1
   dpkg-buildpackage: error: debian/rules build gave error exit status 2

   [..]

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

 
 https://reproducible.debian.net/logs/unstable/amd64/golang-github-jacobsa-ratelimit_0.0~git20150723.0.2ca5e0c-1.build2.log.gz


 Regards,

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

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



-- 
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] Bug#793518: Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.

[Michael Stapelberg]

Chris, thanks for the explanation, that makes sense! I totally missed the
fact that there were not-yet-uploaded changes in git.

Tim, I just tried packaging the new upstream snapshot, and the fix you got
upstream to merge was indeed not enough. My first guess is that exampleStr
requires section1 and section2 to be serialized in order, but Dict.format()
does not sort the keys when iterating over the map.

It’s surprising that this hasn’t caused issues elsewhere yet.

So, yes, if you could work with upstream on a proper solution and then we
could just package a new upstream snapshot, that’d be great.

On Tue, Jul 28, 2015 at 3:02 AM, Potter, Tim (Cloud Services) 
timothy.pot...@hp.com wrote:

 On 28 Jul 2015, at 6:35 am, solo-debianb...@goeswhere.com wrote:
 
  On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote:
  control: tags -1 + unreproducible
 
  Chris, was this an issue on your end? Or am I misinterpreting something?
 
 
  The problem seems to have gone away.  I was running local builds in
  response to errors on the reproducible-builds builder.  Their builder
  has rebuilt sucessfully since then, and I have also just rebuilt
  sucessfully.  Perhaps it was fixed by dependency changes?
 
  Proof I'm not mad: my build log from local:
  https://paste.debian.net/286717/

 Hi everyone.  I think this bug is due to this test  relying on the
 ordering of keys retrieved from
 a hash being the same as they were inserted.  This seems to work most of
 the time (at
 least on amd64) but occasionally the keys come out in a different order
 and the test breaks.

 I could disable the test so things work and work with upstream for a
 proper fix.  Would that
 help out some?


 Tim.




-- 
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] gcsfuse -- fuse file system for Google Cloud Storage

[Michael Stapelberg]

On Tue, Jul 28, 2015 at 1:09 AM, Aaron Jacobs jaco...@google.com wrote:

 On Mon, Jul 27, 2015 at 4:45 PM, Michael Stapelberg
 stapelb...@debian.org wrote:
  As I tried to explain before, we cannot use your vendored copies, and the
  tarballs we’ll create of your source code will not even contain the
 vendor/
  directory.

 Sorry, I had totally forgotten that you said this.

 Please forgive me if you've already answered the following, but I can't
 find it
 above: what is the convention for dealing with backwards-incompatible
 changes
 in Go libraries? If the library author tags with semantic versions and
 bumps a


The Go community’s stanza is you should never do backwards-incompatible
changes, AIUI. Personally, I’d publish a new library under a different
import path.


 major version, are you able to cope with that, even if there are some
 binaries
 that need the old version and some that need the new?


I think we’d most likely have to patch packages which have not yet been
updated.




  FWIW, the only blocker currently to get gcsfuse uploaded is
  https://github.com/GoogleCloudPlatform/gcsfuse/issues/93

 Cool. I've switched to codegangsta/cli itself, so I believe this shouldn't
 be
 an issue anymore. Tagged v0.4.0 for you to work from.


Indeed. Currently, when building, I get:

# github.com/googlecloudplatform/gcsfuse/fs
src/github.com/googlecloudplatform/gcsfuse/fs/fs.go:203: cannot use fs
(type *fileSystem) as type fuseutil.FileSystem in argument to
fuseutil.NewFileSystemServer:
*fileSystem does not implement fuseutil.FileSystem (wrong type for
CreateFile method)
have CreateFile(context.Context, *fuseops.CreateFileOp) error
want CreateFile(*fuseops.CreateFileOp) error

I might be able to take a look at that later this evening, but if you
happen to know what the issue is, that might save me some time. I’m
guessing one of the dependencies was changed in a backwards-incompatible
way :).

-- 
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] Changing dh-golang to work with Go shared libraries

[Michael Stapelberg]

Sorry for the late reply.

On Fri, Jun 19, 2015 at 12:16 AM, Michael Hudson-Doyle
michael.hud...@canonical.com wrote:
 On 19 June 2015 at 08:24, Michael Stapelberg stapelb...@debian.org wrote:
 Thanks.

 The overall approach looks good to me,

 Very glad to hear that :-)

 but the patches still contain a fair
 number of TODOs — I assume you’ll address them before sending them for a
 merge?

 Oh yes, sorry, I actually meant to fix some of those before sending
 the patches (the ones asking if changes are still necessary) but
 clearly forgot. I'll certainly get those cleaned up before sending a
 patch in for merging.

 For this one:

 +# XXX Could do some consistency checks here e.g
 +# 1) make sure there is a devpkg if there is a libpkg
 +# 2) make sure devpkg depends on libpkg
 +# 3) make sure libpkg has Provides: ${golang:Provides}
 +# Maybe this is more in the realm of lintian.

 I'd welcome your input -- do you think it makes sense to check those
 things here?  If so, I'll add the checks, if not, I'll just delete the
 comment :-)

I think having this in lintian makes more sense, because then the
mechanism to override a false-positive is crystal clear to people, and
we don’t need to invent our own mechanism.


 Also, I think it’d be prudent to upload the next version of dh-golang to
 experimental first so that people can actually try out the shared library
 mode and send some feedback based on real-life usage before we upload
 dh-golang to unstable and hence commit to maintaining that feature.

 Oh yes, definitely. We'd also need golang-shared-dev (or whatever that
 ends up being called) in experimental too, and that's not going to
 happen for a little while...

 Cheers,
 mwh

 On Tue, Jun 16, 2015 at 5:02 AM, Michael Hudson-Doyle
 michael.hud...@canonical.com wrote:

 Hi,

 Some of you have already seen and commented on my proposal on how to
 change dh-golang to build and link against Go shared libraries, coming
 (on amd64 at least) in Go 1.5:

 https://docs.google.com/document/d/1IOlBWWgcDeB9PfRORENESYj8iJt4W2EwsbYcpg4akBE/edit#heading=h.j590j9v4qbxg.
 I've just made some small edits to it around the name of the shared
 objects that are built.

 I'm attaching two patches that implement the scheme described in the
 doc. I've not tested them super extensively but they do seem to work
 (with a go package from my branch at
 https://github.com/mwhudson/go/tree/ubuntu-vivid, ignore the branch
 name, it builds fine on sid).

 I'd be most interested in any comments anyone has.

 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




 --
 Best regards,
 Michael



-- 
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] dh-golang : DH_GOLANG_INSTALL_EXTRA_EXTENSIONS option

[Michael Stapelberg]

Thanks! I’ve merged the patch and taken the liberty to make the code a
bit faster by using a hash, see
http://anonscm.debian.org/cgit/collab-maint/dh-golang.git/

Can you confirm that this works as expected for you? Once I hear back
from you, I’ll prepare a new dh-golang release.

On Fri, Jul 31, 2015 at 4:02 PM, Alexandre Viau
alexan...@alexandreviau.net wrote:
 Hi,

 On 31/07/15 03:59 AM, Michael Stapelberg wrote:
 Your patch still adds an extra option. Can you remove that part
 please?

 Also, while you’re at it, install .s files as well? :)


 This one should work like you wanted!

 --
 Alexandre Viau
 alexan...@alexandreviau.net



-- 
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] dh-golang : DH_GOLANG_INSTALL_EXTRA_EXTENSIONS option

[Michael Stapelberg]

Thanks for confirming. I uploaded dh-golang 1.9.

On Mon, Aug 3, 2015 at 8:05 PM, Alexandre Viau
alexan...@alexandreviau.net wrote:
 Hello Michael,

 On Mon, Aug 3, 2015 at 1:45 PM, Michael Stapelberg
 stapelb...@debian.org wrote:
 Can you confirm that this works as expected for you? Once I hear back
 from you, I’ll prepare a new dh-golang release.

 Works fine for me!

 --
 Alexandre Viau
 alexan...@alexandreviau.net



-- 
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] Bug#793518: Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.

[Michael Stapelberg]

On Thu, Jul 30, 2015 at 6:05 AM, Potter, Tim (Cloud Services) 
timothy.pot...@hp.com wrote:

 On 28 Jul 2015, at 5:14 pm, Michael Stapelberg stapelb...@debian.org
 wrote:
 
  So, yes, if you could work with upstream on a proper solution and then
 we could just package a new upstream snapshot, that’d be great.

 I’ve just posted two pull requests on the upstream project.  One to fix the
 occasional test failures, and another to fix another instances of relying
 on the ordering of hash keys.

 If someone can give me upload access (since I’m only a DM) I’ll upload
 the package if/when upstream accepts my patches.  Otherwise I’ll just
 pester people on the list for an update.  (-:


Once upstream accepts your patches, please update the packaging git
repository and let me know, I’ll gladly sponsor this upload.

I’m also open to granting you DM upload privileges on individual packages,
but I’d like to have a few more interactions with you before that :).


-- 
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] gcsfuse -- fuse file system for Google Cloud Storage

[Michael Stapelberg]

I get exactly the same build failure when trying to package gcsfuse v0.5.0.

On Tue, Jul 28, 2015 at 12:22 PM, Aaron Jacobs jaco...@google.com wrote:
 On Tue, Jul 28, 2015 at 6:05 PM, Michael Stapelberg
 stapelb...@debian.org wrote:
 Indeed. Currently, when building, I get:

 # github.com/googlecloudplatform/gcsfuse/fs
 src/github.com/googlecloudplatform/gcsfuse/fs/fs.go:203: cannot use fs (type
 *fileSystem) as type fuseutil.FileSystem in argument to
 fuseutil.NewFileSystemServer:
 *fileSystem does not implement fuseutil.FileSystem (wrong type for
 CreateFile method)
 have CreateFile(context.Context, *fuseops.CreateFileOp) error
 want CreateFile(*fuseops.CreateFileOp) error

 I might be able to take a look at that later this evening, but if you happen
 to know what the issue is, that might save me some time. I’m guessing one of
 the dependencies was changed in a backwards-incompatible way :).

 That's right, sorry. :-) It wasn't a problem due to vendoring, but I guess
 you've got a version skew when building without vendor/. If you're trying to
 use jacobsa/fuse from HEAD, you want gcsfuse v0.5.0. Sorry to make you chase 
 it.



-- 
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] dh-golang : DH_GOLANG_INSTALL_EXTRA_EXTENSIONS option

[Michael Stapelberg]

Instead of adding this via a new setting, why not make dh-golang install
these files by default?

I think installing everything one can legitimately call program source code
is fair game. The tricky part is identifying files which are necessary for
test cases.

The reason why dh-golang doesn’t just install all files is because that
might generate lintian warnings about extra LICENSE files, extra README
files not being marked as docs, random non-executable shell scripts, etc.

That said, I’m not very happy with the current need to specify the
install_all option in many cases, and any improvements over that (using
more introspection? using a blacklist instead of a whitelist?) are very
welcome.

On Wed, Jul 29, 2015 at 10:53 PM, Alexandre Viau 
alexan...@alexandreviau.net wrote:

 Hello,

 This is new dh-golang feature should allow to include more files to the
 install in an easier way. It should be useful, for example, with cgo
 projects.

 DH_GOLANG_INSTALL_EXTRA_EXTENSIONS := .cgo,.h,.c

 Will include all files with .cgo, .h and .c extensions.

 I have had this issue (not just with cgo projects) a couple times last
 week so I thought this would be useful.

 I have never done perl before, feel free to comment on the code.

 --
 Alexandre Viau
 alexan...@alexandreviau.net

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




-- 
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] dh-golang : DH_GOLANG_INSTALL_EXTRA_EXTENSIONS option

[Michael Stapelberg]

I think the go tools do not cover files that are referenced by test code,
e.g.:

func TestFoo(t *testing.T) {
  f, err := os.Open(my_test_resource.txt)
  if err != nil {
t.Fatalf(Could not open file: %v, err)
  }
  // …
}

Did I miss something?

On Thu, Jul 30, 2015 at 2:41 AM, Michael Hudson-Doyle 
michael.hud...@canonical.com wrote:

 I guess you could ask go by invoking 'go list -json ./...' and looking
 for the various *Files fields. The imports/deps calculations won't
 work of course because the point of the copy is to get files to where
 they _do_ work, but that just means that there are DepsErrors fields
 in the json -- the command still completes and gives the needed
 information afaics.

 Cheers,
 mwh

 On 30 July 2015 at 19:10, Michael Stapelberg stapelb...@debian.org
 wrote:
  Instead of adding this via a new setting, why not make dh-golang install
  these files by default?
 
  I think installing everything one can legitimately call program source
 code
  is fair game. The tricky part is identifying files which are necessary
 for
  test cases.
 
  The reason why dh-golang doesn’t just install all files is because that
  might generate lintian warnings about extra LICENSE files, extra README
  files not being marked as docs, random non-executable shell scripts, etc.
 
  That said, I’m not very happy with the current need to specify the
  install_all option in many cases, and any improvements over that (using
 more
  introspection? using a blacklist instead of a whitelist?) are very
 welcome.
 
  On Wed, Jul 29, 2015 at 10:53 PM, Alexandre Viau
  alexan...@alexandreviau.net wrote:
 
  Hello,
 
  This is new dh-golang feature should allow to include more files to the
  install in an easier way. It should be useful, for example, with cgo
  projects.
 
  DH_GOLANG_INSTALL_EXTRA_EXTENSIONS := .cgo,.h,.c
 
  Will include all files with .cgo, .h and .c extensions.
 
  I have had this issue (not just with cgo projects) a couple times last
  week so I thought this would be useful.
 
  I have never done perl before, feel free to comment on the code.
 
  --
  Alexandre Viau
  alexan...@alexandreviau.net
 
  ___
  Pkg-go-maintainers mailing list
  Pkg-go-maintainers@lists.alioth.debian.org
 
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
 
 
 
 
  --
  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




-- 
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] Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.

[Michael Stapelberg]

control: tags -1 + unreproducible

I can’t reproduce this. Using gbp buildpackage --git-pbuilder, the package
builds fine. Additionally, clicking “build2” on
https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-github-glacjay-goini.html
(which your bug report pointed me to) results in a build log that tells me
everything is okay.

Chris, was this an issue on your end? Or am I misinterpreting something?

On Fri, Jul 24, 2015 at 9:31 PM, Chris West (Faux) 
solo-debianb...@goeswhere.com wrote:

 Source: golang-github-glacjay-goini
 Version: 0.0~git20141123-1
 Severity: serious
 Tags: sid
 Justification: fails to build from source
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: ftbfs

 Dear Maintainer,

 The package fails to build:

 === RUN TestString
 --- FAIL: TestString (0.00s)
 ini_test.go:167: Dict cannot be stringified as expected.
 FAIL
 exit status 1
 FAILgithub.com/glacjay/goini0.012s
 dh_auto_test: go test -v github.com/glacjay/goini returned exit code 1

 Full build log:

 https://reproducible.debian.net/rb-pkg/unstable/amd64/golang-github-glacjay-goini.html

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

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

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




-- 
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] Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.

[Michael Stapelberg]

Actually, my bad, the commit I referenced is already in the package in the
form of a patch.

In your https://paste.debian.net/286717/, I don’t see any mention of the
patch, though…? Does your build environment not apply patches? When running
gbp buildpackage --git-pbuilder, I see:

[…]
dpkg-source: warning: extracting unsigned source package
(golang-github-glacjay-goini_0.0~git20141123-1.dsc)
dpkg-source: info: extracting golang-github-glacjay-goini in
golang-github-glacjay-goini-0.0~git20141123
dpkg-source: info: unpacking
golang-github-glacjay-goini_0.0~git20141123.orig.tar.gz
dpkg-source: info: unpacking
golang-github-glacjay-goini_0.0~git20141123-1.debian.tar.xz
dpkg-source: info: applying 0001-fix-test-nondeterminism.patch
I: Building the package


On Mon, Jul 27, 2015 at 10:39 PM, Michael Stapelberg stapelb...@debian.org
wrote:

 Turns out that test is flaky. The problem was fixed upstream in
 https://github.com/glacjay/goini/commit/5352bdc2ac2ddf2b5d27447c95bfe9588a8e09e9,
 I’ll package a new snapshot.

 On Mon, Jul 27, 2015 at 10:35 PM, solo-debianb...@goeswhere.com wrote:

 On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote:
  control: tags -1 + unreproducible
 
  Chris, was this an issue on your end? Or am I misinterpreting something?
 

 The problem seems to have gone away.  I was running local builds in
 response to errors on the reproducible-builds builder.  Their builder
 has rebuilt sucessfully since then, and I have also just rebuilt
 sucessfully.  Perhaps it was fixed by dependency changes?

 Proof I'm not mad: my build log from local:
 https://paste.debian.net/286717/




 --
 Best regards,
 Michael




-- 
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] Bug#793518: Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.

[Michael Stapelberg]

Turns out that test is flaky. The problem was fixed upstream in
https://github.com/glacjay/goini/commit/5352bdc2ac2ddf2b5d27447c95bfe9588a8e09e9,
I’ll package a new snapshot.

On Mon, Jul 27, 2015 at 10:35 PM, solo-debianb...@goeswhere.com wrote:

 On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote:
  control: tags -1 + unreproducible
 
  Chris, was this an issue on your end? Or am I misinterpreting something?
 

 The problem seems to have gone away.  I was running local builds in
 response to errors on the reproducible-builds builder.  Their builder
 has rebuilt sucessfully since then, and I have also just rebuilt
 sucessfully.  Perhaps it was fixed by dependency changes?

 Proof I'm not mad: my build log from local:
 https://paste.debian.net/286717/




-- 
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] gcsfuse -- fuse file system for Google Cloud Storage

[Michael Stapelberg]

As I tried to explain before, we cannot use your vendored copies, and the
tarballs we’ll create of your source code will not even contain the vendor/
directory.

FWIW, the only blocker currently to get gcsfuse uploaded is
https://github.com/GoogleCloudPlatform/gcsfuse/issues/93

On Mon, Jul 27, 2015 at 1:24 AM, Aaron Jacobs jaco...@google.com wrote:

 Hi Michael,

 On Fri, Jun 12, 2015 at 9:12 AM, Aaron Jacobs jaco...@google.com wrote:
  Question: what would the situation look like if gcsfuse instead
 'vendored' its
  dependencies, so that the exact version it depends on was included in
 its git
  repo and it was built with a tool like godep (
 https://github.com/tools/godep)
  or nut (https://github.com/jingweno/nut)?

 I'm resurrecting the question above, because as of commit 2eb17b6, gcsfuse
 has
 its dependencies vendored. (For the standard reason: it makes it much much
 easier to get a reproducible build, insulates against
 backwards-incompatible
 API changes, etc.) How does Debian generally treat such project? I
 apologize if
 this causes a bunch of extra work.

 Aaron




-- 
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] golang-golang-x-tools_0.0~git20150716.0.87156cb+dfsg1-1_amd64.changes REJECTED

[Michael Stapelberg]

Thanks for the quick reply!

I copypasted this from
http://sources.debian.net/src/gnome-user-docs/3.16.1-1/debian/copyright/?hl=6#L6,
perhaps you want to file a bug against that package, then :).

I’ll reupload golang-golang-x-tools in a minute with the fixed
debian/copyright.

On Fri, Jul 24, 2015 at 6:00 PM, Thorsten Alteholz 
ftpmas...@ftp-master.debian.org wrote:


 Hi Michael,

 unfortunately I have to reject your package.

 Please add the full license text of CC-BY-3.0 to your debian/copyright.

 Thanks!
  Thorsten

 ===

 Please feel free to respond to this email if you don't understand why
 your files were rejected, or if you upload new files which address our
 concerns.




-- 
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] Bug#792704: Bug#792704: etcd: Allow etcd configuration with systemd unit file

[Michael Stapelberg]

Why is not good enough to use systemd’s ways to override specific keys of a
service file? I.e., use “systemctl edit etcd” and specify e.g. Environment=
ETCD_DATA_DIR=/my/path/to/etcd

On Fri, Jul 17, 2015 at 4:27 PM, Eric Paris debianb...@parisplace.org
wrote:

 Package: etcd
 Version: 2.0.8-2
 Severity: wishlist

 Dear Maintainer,

 The systemd unit file hard codes a working dir and name. It does not have
 any mechanism for additional configuration. Personally I like the Fedora
 systemd unit file

 http://pkgs.fedoraproject.org/cgit/etcd.git/tree/etcd.service

 Which uses /etc/etcd/etcd.conf as the ENV file.

 The sysinit scripts use /etc/default/etcd but the ENV keys in that file
 are not the ENV keys which etcd pays attention to. But there should be some
 way, when using systemd to configure it.

 I got my instalation to work by just putting the Fedora .service file into
 /etc/systemd/system, but a reasonable default in /lib seems like a good
 idea.

 -- System Information:
 Debian Release: 8.1
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
 Architecture: amd64 (x86_64)

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

 Versions of packages etcd depends on:
 ii  adduser  3.113+nmu3
 ii  libc62.19-18

 etcd recommends no packages.

 etcd suggests no packages.

 -- Configuration Files:
 /etc/default/etcd changed [not included]
 /etc/init.d/etcd changed [not included]

 -- no debconf information

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




-- 
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] Need review - InfluxDB dependencies

[Michael Stapelberg]

I took a look at all of them and updated the whiteboard with the current
status. Comments are on the #debian-golang IRC channel.

On Sat, Jul 18, 2015 at 6:32 AM, Alexandre Viau alexan...@alexandreviau.net
 wrote:

 Hello, pkg-go!

 I have been working on packaging InfluxDB dependencies and I am done. I
 could successfully compile InfluxDB 0.9.1.

 I am now looking for sponsors.

 Here is a list of the non-uploaded dependencies for InfluxDB.

 [ source package ] | [ITP or version required ]

 - golang-bolt | ITP#781321
 - golang-gopkg-fatih-pool.v2 | ITP#792618
 - golang-github-peterh-liner | ITP#781275
 - golang-github-kimor79-gollectd | ITP#792638
 - golang-github-rakyll-statik | ITP#792634
 - golang-collectd | ITP#792638
 - golang-gogoprotobuf | (0.0~git20140719-2 - UNRELEASED)

 - golang-github-hashicorp-raft-boltdb | ITP#792754
   - golang-github-hashicorp-raft | ITP#792620
 - golang-github-armon-go-metrics |  ITP#792628
 - golang-github-hashicorp-go-msgpack | ITP#792640
   - golang-gopkg-mgo.v2 | ITP#732684
   - golang-gopkg-vmihailenco-msgpack.v2 | ITP#792641
 - golang-github-ugorji-go-msgpack | ITP#792643
 - golang-github-ugorji-go-codec | ITP#792455

 - github.com/bmizerany/pat | golang-github-bmizerany-pat | ITP#792613
   - golang-github-bmizerany-assert | ITP#785166

 - golang-github-davecgh-go-spew | ITP#792230

 I intend to keep an updated version of this tree on
 http://whiteboard.debian.net/influxdb.wb

 I you want to sponsor some uploads, just put your name next to the
 package name on the whiteboard and send me an e-mail so that we know who
 is reviewing what.

 All of the packages are available in pk-go on Alioth.

 As far as InfluxDB itself goes, I am not done yet but I intend to do
 that in the next few days.

 Thank you in advance,

 --
 Alexandre Viau
 alexan...@alexandreviau.net


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




-- 
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] Fixed golang-x-text package for go 1.5

[Michael Stapelberg]

On Mon, Oct 19, 2015 at 11:06 PM, Martin Packman <
martin.pack...@canonical.com> wrote:

> On 19/10/2015, Michael Stapelberg <stapelb...@debian.org> wrote:
> > This looks good to me. Can you push it to
> > https://anonscm.debian.org/cgit/pkg-go/packages/golang-x-text.git/ as
> well
> > please?
>
> I can't quite yet as I didn't have an alioth account, but anyone who's
> already got one can push my changes there, something like:
>

Can you create an alioth account please? You can get a guest account
without any trouble. Afterwards, please send a request to join pkg-go, and
then you can do the update yourself :).


>
> $ git clone -b debian/experimental
> https://git.launchpad.net/~gz/+git/golang-x-text
> $ cd golang-x-text
> $ git push git://anonscm.debian.org/pkg-go/packages/golang-x-text.git
> debian/experimental
>
> Or no doubt with shorter and fancier methods.
>
> Martin
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Fixed golang-x-text package for go 1.5

[Michael Stapelberg]

Accepted your join request. Welcome! :) Make sure to read
https://pkg-go.alioth.debian.org/

The next step is to contact the maintainer of the package and ask the
maintainer if they prefer to upload a new version themselves or if you may
do it yourself.

On Sat, Oct 24, 2015 at 12:05 AM, Martin Packman <
martin.pack...@canonical.com> wrote:

> On 22/10/2015, Michael Stapelberg <stapelb...@debian.org> wrote:
> >
> > Can you create an alioth account please? You can get a guest account
> > without any trouble. Afterwards, please send a request to join pkg-go,
> and
> > then you can do the update yourself :).
>
> Done, account is gz-guest. James Page already pushed the branch (with
> one more upstream revision, fixing the test failures so the debian
> patch could be dropped), what the next step after that?
>
> Martin
>



-- 
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] Usage of -git_revision option on dh-make-golang

[Michael Stapelberg]

Thanks for the feedback.

The problem with the repository at hand is that it’s using a light-weight
tag instead of an annotated tag:

$ cat .git/packed-refs
# pack-refs with: peeled fully-peeled
c7477ad8e330bef55bf1ebe300cf8aa67c492d1b refs/remotes/origin/master
46a638d98be2af4fa6de146b5d28a9d9904a3949 refs/tags/v0.1

$ git cat-file -t 46a638d98be2af4fa6de146b5d28a9d9904a3949
commit

The type of the tag should be “tag”, not “commit”, for an annotated tag.
Otherwise git-describe will not consider the tag. From git-tag(1):

Annotated tags are meant for release while lightweight tags are meant
for private or temporary object labels. For this reason, some git commands
for naming objects (like git describe) will ignore lightweight tags by
default.

See also
https://stackoverflow.com/questions/11514075/what-is-the-difference-between-an-annotated-and-unannotated-tag

I think you should file a bug upstream and ask them to create annotated
tags for this release and in the future. Then, merely using
--git_revision=v0.1 should work with dh-make-golang.

I suppose we should add some logic to detect this problem and emit a
warning message in dh-make-golang. Could you file an issue for that at
https://github.com/Debian/dh-make-golang please?

If anyone else has a different idea, I’m all ears :).

On Wed, Nov 4, 2015 at 8:28 AM, Potter, Tim (Converged Cloud) <
timothy.pot...@hpe.com> wrote:

> Hi Michael.  I’ve been using dh-make-golang a lot recently (thanks - it’s
> awesome!) but had a
> question about the -git_revision option.
>
> If I specify refs/tags/v0.1 then the package version is set to the git
> hash version string used
> when creating master snapshot packages.
>
> Would it be better to have a -version option to be able to set the package
> version number
> when using -git_revision?
>
> For example:
>
> root@b563bbeedb84:/# dh-make-golang -git_revision=refs/tags/v0.1
> github.com/codegangsta/negroni
> 2015/11/04 18:25:09 Downloading "github.com/codegangsta/negroni/..."
> 2015/11/04 18:25:14 Checking out git revision "refs/tags/v0.1"
> 2015/11/04 18:25:14 Determining upstream version number
> 2015/11/04 18:25:14 Package version is "0.0~git20140530.0.46a638d"
> 2015/11/04 18:25:14 Determining package type
> 2015/11/04 18:25:14 Determining dependencies
> [..]
>
> I need to go in and manually edit the d/changelog version number to be
> 0.1-1 whereas it
> would be nice if this were done using a command line option.
>
> Mind you not many packages I’ve seen have actual released versions.  I
> think I’ve recently
> uploaded about 10 and only two had releases.
>
> Thanks again for dh-make-golang!
>
>
> Tim.




-- 
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] Building golang-github-google-btree from its git repo

[Michael Stapelberg]

If building requires gbp options, you should ship a debian/gbp.conf which
sets them. I’m happy to amend the policy document to make this explicit,
but this was the intention all along.

Ideally, your GBP repository would look like any other repository in
pkg-go. That said, we haven’t quite standardized on a format yet I think.

On Mon, Oct 19, 2015 at 9:53 AM, Dmitry Smirnov <only...@debian.org> wrote:

> On Monday 19 October 2015 08:15:37 Michael Stapelberg wrote:
> > Dmitry, note that the pkg-go team policy states that packages must be
> > buildable using git-buildpackage:
> > https://pkg-go.alioth.debian.org/packaging.html
> >
> > So, even if you prefer not to use git-buildpackage, please at least
> verify
> > before pushing your repository that it can successfully be built using
> > git-buildpackage (without having to specify any options).
>
> Thanks, Michael, I'm aware that repositories should be buildable with GBP.
> For compatibility with GBP I maintain "upstream" and "pristine-tar"
> branches
> using "gbp import-orig" command at the cost of additional effort that
> frankly
> I find quite uncomfortable especially for packages with bundled Godeps that
> needs to be removed during repackaging of orig tar.
> I do not like upstream files mixed with packaging in "master" branch so I
> prefer to keep 'em separate. I'm sure this layout is buildable with GBP as
> I
> verified it myself and I know that other teams (i.e. KDE team) use even
> simpler repository layout without "upstream" branch at all.
> Policy do not say that repository layout should allow packages to be build
> using GBP's _default configuration_. If having upstream and debian
> packaging
> together in "master" were a requirement the I'd probably maintain all my
> packages in collab-maint.
> Having said that, I'm happy to use GBP repository layout if any
> contributing
> co-maintainer strongly prefers so. That's exactly how we maintain Etcd
> package but I do not wish to go through all inconvenience for packages
> that I
> maintain single-handedly... It's not that hard to build a package even
> using
> GBP as long as "upstream" (and optional "pristine-tar") branches exist.
>
> I think there are already too many maintainers who do not know to build a
> package without GBP... :(
>
> Personally I find GBP workflow limited and overly complex. I tried to use
> GBP
> in the past but ended up spending a lot more time to do the same job
> without
> obvious benefits.
>
> --
> Cheers,
>  Dmitry Smirnov.
>
> ---
>
> The more false we destroy the more room there will be for the true.
>  -- Robert G. Ingersoll, 1902
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Bug#801593: Bug#801593: Bug#801593: ratt does not find all reverse build dependencies

[Michael Stapelberg]

control: tags -1 + pending

Thanks. Committed
https://github.com/Debian/ratt/commit/20731fa3f65b04e4e030221f95d524baf83aa42d

On Mon, Oct 19, 2015 at 10:06 AM, Johannes Schauer <jo...@debian.org> wrote:

> Hi,
>
> Quoting Michael Stapelberg (2015-10-19 09:03:40)
> > Thanks for the clarification. The attached patch seems to work for me.
> Does
> > it look good to you as well?
>
> I do not speak go and I did not test that patch but as far as I can see it
> looks good to me. :)
>
> I also see that you implemented `apt-get indextargets` in case the local
> apt
> understands that - nice!
>
> Thanks!
>
> cheers, josch
>



-- 
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] Bug#801595: Bug#801595: Bug#801595: ratt calls sbuild in a way that uses the user's sbuildrc

[Michael Stapelberg]

control: tags -1 + pending

Done with
https://anonscm.debian.org/cgit/pkg-go/packages/ratt.git/commit/?id=5a92ae0253ef4261f26d56a11ebcf97d9e753967

On Wed, Oct 14, 2015 at 7:16 PM, Johannes Schauer <jo...@debian.org> wrote:

> Hi,
>
> Quoting Tianon Gravi (2015-10-14 19:10:34)
> > On 14 October 2015 at 10:06, Michael Stapelberg <stapelb...@debian.org>
> wrote:
> > > I’m a bit hesitant to do this. If a user specified custom settings in
> their
> > > ~/.sbuildrc, they are probably there for a reason and should be
> considered
> > > when using ratt, right?
> >
> > I'm not exactly a long-time user of sbuild, but I'd definitely be very
> > surprised if ratt _didn't_ use my ~/.sbuildrc when invoking sbuild. :)
>
> it'd be the other way round for me but I guess the best solution then is to
> pick one option and document it :)
>
> Thanks!
>
> cheers, josch
>



-- 
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] Bug#801593: Bug#801593: ratt does not find all reverse build dependencies

[Michael Stapelberg]

Ah, so dose-ceve operates on binary packages in the invocation that we’re
using.

Is there a way to make it work on source packages instead? I feel like that
would be a tad more efficient, as ratt would not need to extract all binary
packages and dose-ceve would not need to parse all the binary index files.

On Wed, Oct 14, 2015 at 7:30 PM, Johannes Schauer <jo...@debian.org> wrote:

> Quoting Michael Stapelberg (2015-10-14 19:24:34)
> > dh-make-golang actually does build-depend on golang-golang-x-tools-dev:
> >
> >
> https://anonscm.debian.org/cgit/pkg-go/packages/dh-make-golang.git/tree/debian/control?id=64d6a0f658cb9618af076935ba5c2f14315b74a0#n11
>
> yes, but we were talking about golang-golang-x-tools and not
> golang-golang-x-tools-dev. There is no dependency path from
> golang-golang-x-tools-dev to golang-golang-x-tools either.
>
> I also tried doing:
>
> $ apt-get build-dep dh-make-golang golang-github-aws-aws-sdk-go golint
>
> In a fresh debian unstable chroot. This did not install
> golang-golang-x-tools.
> This means that even apt thinks that neither of those source packages build
> depend on golang-golang-x-tools.
>
> Thanks!
>
> cheers, josch
>



-- 
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] Fixed golang-x-text package for go 1.5

[Michael Stapelberg]

This looks good to me. Can you push it to
https://anonscm.debian.org/cgit/pkg-go/packages/golang-x-text.git/ as well
please?

On Mon, Oct 19, 2015 at 12:44 PM, Martin Packman <
martin.pack...@canonical.com> wrote:

> I've pushed up packaging changes to fix golang-x-text for golang 1.5
> in experimental:
>
> https://code.launchpad.net/~gz/+git/golang-x-text
>
> If one of the debian go maintainers wants to review/adopt I would
> appreciate it, will help me fix the package in wily.
>
> Basically just new upstream snapshot and these debian/ changes:
>
> https://git.launchpad.net/~gz/+git/golang-x-text/commit/?id=d59ffbf
>
> I haven't chased down exactly why those test failures appeared, but
> they cause ftbfs on both experimental and wily and the patch to avoid
> is trivial.
>
> Martin
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Plans for uploading Go 1.5 to unstable?

[Michael Stapelberg]

On Thu, Oct 15, 2015 at 6:44 PM, Tianon Gravi  wrote:

> On 13 October 2015 at 16:43, Potter, Tim (Converged Cloud)
>  wrote:
> > Hi tianon.  I was curious what your plans were for uploading Go 1.5 to
> unstable.  Is there anything you can share?
>
> Go 1.5 has some minor breaking changes, so I've been waiting until I
> (or some other kind soul) has had the time to do a full ratt run on Go
> 1.5 and make sure all our packages either build/test successfully or
> that we have a plan/patches ready to fix the issues that are bound to
> come up.
>

FWIW, I don’t think that’s necessary for the compiler itself. Go adheres to
its Go 1 stability guarantee, and any package which breaks likely did
something wrong in the first place :). If this is the only thing that’s
holding back the upload, I’d recommend to just go ahead with the upload.


>
> To Michael's point about compiling Docker via gccgo -- as the
> maintainer of the build scripts for upstream, please don't do that for
> anything serious.  I've been working closely with IBM on that, and
> none of us are really thrilled with the results so far, but it's the
> only way we can get anything at all on some of their more interesting
> architectures like s390x.
>
> ♥,
> - 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
>



-- 
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] Bug#801596: Bug#801596: ratt hardcodes --dist=sid as sbuild argument

[Michael Stapelberg]

This was also reported as https://github.com/Debian/ratt/issues/1.

On Mon, Oct 12, 2015 at 1:23 PM, Johannes Schauer  wrote:

> Package: ratt
> Version: 0.0~git20150816.0.b060319-1
> Severity: wishlist
>
> Hi,
>
> ratt currently seems to unconditionally pass --dist=sid to sbuild. This
> is problematic because:
>
>  1. it requires a local chroot with the name "sid" but it might also be
> named "unstable" for example
>
>  2. it means that only a sid/unstable chroot can be used which makes
> ratt less useful to test in other environments or to be used outside
> of Debian (like Ubuntu)
>
> Maybe ratt should:
>
>  - have an option that lets pass arbitrary sbuild arguments
>  - have an option that lets one select the sbuild chroot
>  - use the Distribution value from the .changes file to choose the
>chroot
>

I’d prefer reading the .changes file. Just to clarify: you were listing 3
alternatives that would all satisfy you, right? I.e., once extracting the
distribution from .changes files is implemented, your use-cases are
covered, yes?


>
> Thanks!
>
> cheers, josch
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Bug#801596: Bug#801596: ratt hardcodes --dist=sid as sbuild argument

[Michael Stapelberg]

control: tags -1 + pending

Fixed with
https://github.com/Debian/ratt/commit/7b424109b0bea76eb6b5d2b0be6ae770391ed98b

On Mon, Oct 12, 2015 at 9:03 PM, Johannes Schauer <jo...@debian.org> wrote:

> Quoting Michael Stapelberg (2015-10-12 20:59:10)
> > > Maybe ratt should:
> > >
> > >  - have an option that lets pass arbitrary sbuild arguments
> > >  - have an option that lets one select the sbuild chroot
> > >  - use the Distribution value from the .changes file to choose the
> > >chroot
> > >
> >
> > I’d prefer reading the .changes file. Just to clarify: you were listing 3
> > alternatives that would all satisfy you, right? I.e., once extracting the
> > distribution from .changes files is implemented, your use-cases are
> > covered, yes?
>
> that would cover lots of cases, yes (including mine).
>
> It would require though that the user has a sbuild chroot with the same
> name
> (or at least alias). So maybe in addition an option to manually specify the
> chroot would be nice.
>
> But extracting the distribution from the .changes should suffice to close
> this
> bug, yes :)
>
> cheers, josch
>



-- 
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] RFS: a clutch of small go packages

[Michael Stapelberg]

Thanks for your work on these packages!

On Tue, Aug 25, 2015 at 12:35 PM, Potter, Tim (Cloud Services)
timothy.pot...@hpe.com wrote:
 Hi everyone.  I’ve put together a couple of packages for review.  Hopefully 
 these
 are ready to go as they’re quite small.  Could someone please review and 
 upload?

 * golang-github-coreos-go-iptables

Uploaded, but I can’t push the tag…?

$ git push 
ssh://git.debian.org/git/pkg-go/packages/golang-github-coreos-go-iptables.git
--tags
Total 0 (delta 0), reused 0 (delta 0)
error: unable to create directory for refs/tags/debian/0.0_git20150805-1
remote: error: failed to lock refs/tags/debian/0.0_git20150805-1
To ssh://git.debian.org/git/pkg-go/packages/golang-github-coreos-go-iptables.git
 ! [remote rejected] debian/0.0_git20150805-1 -
debian/0.0_git20150805-1 (failed to lock)
error: failed to push some refs to
'ssh://git.debian.org/git/pkg-go/packages/golang-github-coreos-go-iptables.git'


 * golang-github-d2g-dhcp4

Same.

 * golang-github-d2g-dhcp4client (depends on dhcp4 package above)

Won’t be able to upload this yet before -dhcp4 gets accepted, so
please let me know once that has happened, and I can take another
look.


 Everything’s been pushed to alioth already.


 Thanks,

 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



-- 
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] May I upgrade golang-blackfriday, golang-testify, etc. to latest versions?

[Michael Stapelberg]

On Tue, Sep 8, 2015 at 8:53 AM, Anthony Fok  wrote:
> Hello all,
>
> I would like to package Hugo ( http://gohugo.io/ ) for Debian,
> and I am starting to package the various Go packages that
> Hugo depends on.
>
> One of the packages that need updating is golang-blackfriday
> because Hugo depends on some new features in the latest
> russross/blackfriday in git HEAD, and would not compile with
> the old release of blackfriday 1.2.
>
> Other packages that might need updating include golang-testify,
> golang-objx, etc.
>
> May I...
>
>   1. ... just go ahead and update them?  :-)

Yes.

>
>   2. Or should I first ask for permissions from the previous uploaders?

You should at least let them know, but team policy is that we don’t
have such strict ownership. The packages are team-maintained for a
reason.

>
>   3. Or should I create new packages like golang-github-russross-blackfriday
>   for the cutting-edge version, and leave golang-blackfriday
>   as the stable 1.2 version?

No, but you should rename the existing packages to the proper name.
See other recently uploaded packages for examples on how to do that
with regards to Breaks/Replaces if you’re unsure about that.

>
> Thank you for your advice!

Thank you for your contributions :).

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



-- 
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] May I upgrade golang-blackfriday, golang-testify, etc. to latest versions?

[Michael Stapelberg]

Yeah, https://github.com/Debian/ratt should be ready to use. Please
let me know of any issues you encounter.

On Tue, Sep 8, 2015 at 8:37 PM, Paul Tagliamonte <paul...@debian.org> wrote:
> On Tue, Sep 08, 2015 at 09:00:34AM +0200, Michael Stapelberg wrote:
>> >   1. ... just go ahead and update them?  :-)
>>
>> Yes.
>
> Yesish. Yes, you should absolutely update them, but you should also
> check all their reverse build dependencies to ensure that we don't cause
> FTBFSs. Yo, sECuRE - is RATT ready for team use?
>
>> >   2. Or should I first ask for permissions from the previous uploaders?
>>
>> You should at least let them know, but team policy is that we don’t
>> have such strict ownership. The packages are team-maintained for a
>> reason.
>
> Absolutely true. Just be careful of an upload before we know what might
> trigger FTBFSs -- upstreams in Goland seem to break API all the time, so
> we should be a bit careful in leau of versioning.
>
>> >   3. Or should I create new packages like 
>> > golang-github-russross-blackfriday
>> >   for the cutting-edge version, and leave golang-blackfriday
>> >   as the stable 1.2 version?
>>
>> No, but you should rename the existing packages to the proper name.
>> See other recently uploaded packages for examples on how to do that
>> with regards to Breaks/Replaces if you’re unsure about that.
>>
>> >
>> > Thank you for your advice!
>>
>> Thank you for your contributions :).
>
> +1!
>
> Cheers,
>Paul



-- 
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] gbp: how to import upstream tarball without tag?

[Michael Stapelberg]

I just use dh-make-golang to produce new upstream tarballs. See also
https://github.com/Debian/dh-make-golang/issues/14

On Wed, Sep 2, 2015 at 4:46 AM, Dmitry Smirnov  wrote:
> On Wednesday 02 September 2015 12:52:56 Martín Ferrari wrote:
>> There is a very well documented and tidy process for doing all this,
>> although it is probably way too complicated for most people. Still, it
>> is a good read to have an idea of how to do things:
>> http://blog.mycre.ws/articles/git-packaging-workflow-for-py-lmdb/
>
> Thank you for detailed replay and for all your hints. Indeed I find it too
> complicated. :( I merely cloned one of our packages' repository and managed
> to produce a release tarball from HEAD of upstream repository by using "dh-
> make-golang" which is a bit awkward yet a lot simpler than to configure git
> remote and fetch history of all upstream changes since beginning of time
> merely to generate tarball for "gbp import-orig"...
>
>
>> Another read: DEP-14, which documents some best-practices for debian/git
>> packaging: http://dep.debian.net/deps/dep14/
>
> IMHO this is too GBP-oriented approach. My favourite layout of debian package
> repositories is documented here:
>
> https://pkg-kde.alioth.debian.org/gitguidelines.html
>
> Unfortunately it does not answer the question how to easily produce orig.tar
> from tagless GitHub repositories...
>
> --
> Regards,
>  Dmitry Smirnov.
>
> ---
>
> Good luck happens when preparedness meets opportunity.
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
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] Bug#796806: Bug#796806: golang-check.v1: Non-determistically FTBFS due to unreliable timing in tests

[Michael Stapelberg]

Bug #796400 was similar.

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

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

 Dear Maintainer,

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

   [..]

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

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

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


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

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

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

   [..]

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

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


 Regards,

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

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



-- 
Best regards,
Michael

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

 Dear Maintainer,

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

   [..]

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

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

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


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

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

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

   [..]

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

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


 Regards,

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

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



-- 
Best regards,
Michael

___
Pkg-go-maintainers mailing list

Re: [pkg-go] Various problems with packages in the group

[Michael Stapelberg]

As a meta-point: I think we should change dh-make-golang to do the
right thing once we agree on these suggestions. At least the first
point you mention (repository creation) is already properly handled,
i.e. dh-make-golang gives you a setup-repository command to run.

On Sun, Sep 13, 2015 at 2:54 PM, Martín Ferrari  wrote:
> Hi all,
>
> This week I have spent a considerable amount of time tidying up the
> group's repositories.
>
> This was motivated initially because I wanted to work on pending bugs,
> uploads, etc. And a great tool to keep track of pending work is PET [1],
> which Michael set up a while ago, and the UDD Maintainer dashboard [2].
>
> For these tools to be useful, a few conventions need to be followed.
> These conventions are usually very useful for team maintenance, as there
> is much less guessing involved when working with a package that somebody
> else prepared.
>
> I've also found issues that hamper team work, even if they are not
> problematic for PET/UDD.
>
> So, here is a list of problems, and what I consider
> solutions/best-practices for them. I believe them to be more or less
> non-controversial across packaging teams, and I believe it would help a
> lot the team if we all use them.
>
> I learnt most of these guidelines in the pkg-perl group. Without a lot
> of person-power, they maintain over 3000 packages, with an impressible
> attention to detail, and they make it very easy for new contributors to
> join the group. I really trust what that group considers good practices :-)
>
> Comments and criticisms welcomed.
>
> The list:
>
> P: Many repositories had permission problems and missing hooks (which in
> turn means no KGB notifications nor PET updates), because they were
> created manually instead of using the setup-repository script. The
> permissions problem is particularly bothersome as it makes it impossible
> for anybody else to work on the package.
>
> S: Always create repositories running '/git/pkg-go/setup-repository
>  '

Agreed, I think this is a no-brainer.

>
>
> P: Packages missing upstream source or history. Although many groups
> tend not to include source, it is good to have consistency. I would
> argue that not having the source makes your life as a maintainer a lot
> more difficult, and with most people using git these days, having
> upstream's history can be a life saver.
>
> S: Instead of just importing debian/, start by adding upstream as a
> remote, and 'git checkout -b upstream' based on the tag you want to package.

Does this imply having a git history such as displayed in
https://anonscm.debian.org/cgit/pkg-go/packages/golang-uuid.git/log/?
I find that super-annoying for packages with active upstream
repositories, because I’m almost never interested in an individual
upstream commit, but rather at high-level changes that directly
correspond to uploads to Debian. I.e., I prefer seeing a single
“Imported upstream snapshot X” commit over seeing hundreds of
individual upstream commits.

>
>
> P: Missing tags for releases. This confuses PET and anybody working on
> your package: without the tag, you can never be sure what is the commit
> that matches what was uploaded.
>
> S: Always use debcommit -r, which will create the tag automatically,
> when the package is about to be uploaded.

Agreed. I think whenever this happens, it’s just a mistake such as
forgetting to push the tag or something similar.

>
>
> P: Having unfinished packages with 'upstream' distribution in
> debian/changelog, instead of 'UNRELEASED'. This is a convention
> originating in dch: when you start working on a new version of a
> package, dch will set the distribution to 'UNRELEASED', so there is no
> confusion with already-uploaded versions. This is also use by PET to
> differentiate work-in-progress packages, with packages that are ready to
> upload or already uploaded.
>
> S: Use dch to start a new version, and dch -r to mark it as finished and
> ready for upload/sponsoring. Packages that are marked like this but not
> tagged are usually candidates for sponsored uploads.

See also https://github.com/Debian/dh-make-golang/pull/16 — I wanted
to change the team policy document on that before accepting the PR,
but I think we all agree by now.

>
> [1] http://pet.debian.net/pkg-go/pet.cgi
>
> [2]
> https://udd.debian.org/dmd/?email1=pkg-go-maintainers%40lists.alioth.debian.org
>
> --
> --
> 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



-- 
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] Usage of Built-Using for dev packages

[Michael Stapelberg]

I’ve updated the policy in commit
https://anonscm.debian.org/cgit/pkg-go/website.git/commit/?id=98531f7af530cbb571429a680e86a57ab936e86f

On Fri, Sep 11, 2015 at 10:02 PM, Alexandre Viau
<alexan...@alexandreviau.net> wrote:
> Hello Michael,
>
> On 11/09/15 03:57 PM, Michael Stapelberg wrote:
>> That’s a fair point as well. Do you want to file a bug against the
>> package in question?
>
> I will.
>
> Should we also update our policy? We could state that tools should be
> shipped in -tools packages and that -dev packages should only contain
> the source.
>
> --
> Alexandre Viau
> alexan...@alexandreviau.net
>



-- 
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] RFS: golang-github-bitly-simplejson

[Michael Stapelberg]

• debian/* is licensed under GPL-2+, but upstream is MIT. Consider
using the same license to avoid headaches when shipping patches.

• The package does not build with gbp:

/tmp/golang-github-bitly-go-simplejson master $ gbp buildpackage
--git-builder='sbuild -v -As --dist=unstable'
gbp:error: upstream/0.5.0-alpha_git20150401 is not a valid treeish

On Fri, Sep 11, 2015 at 1:30 AM, Potter, Tim (Cloud Services)
 wrote:
> On 9 Sep 2015, at 2:07 pm, Paul Tagliamonte  wrote:
>>
>> On Wed, Sep 09, 2015 at 03:46:41AM +, Potter, Tim (Cloud Services) wrote:
>>> On 9 Sep 2015, at 1:34 pm, Paul Tagliamonte  wrote:

 On Wed, Sep 09, 2015 at 03:28:59AM +, Potter, Tim (Cloud Services) 
 wrote:
> Hi everyone.  This package is required for bugsnag and I’ve just finished 
> renaming
> it and testing against the new naming policy.
>
> Could someone please review and upload?

 Ah, your RFS was missing a -go :) -- package name is
 golang-github-bitly-go-simplejson for those at home -- as a result, your
 Vcs-* headers look a bit off :)
>>>
>>> Yes - sorry about that.  The extra -go is necessary.
>>>
>>> I've updated the Vcs-* fields now.
>>
>> Looks great. I spotted an issue where d/control claimed 0.4.3, source
>> was from 0.5.0. Tim's on the job, just noting it for the channel. After
>> that's clear, it looked good to me.
>
> I  investigated a bit and decided to rename the version number to 0.5.0-alpha 
> to
> reflect what’s in the code.  Good catch though.
>
> This should be ready for uploading now.
>
>
> Thanks!
>
> 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



-- 
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] Bug#798649: Bug#798649: golang-golang-x-net-dev: new upstream release?

[Michael Stapelberg]

I tried looking into this, but it’s not trivial.
https://github.com/golang/go/issues/10904 required a revert of some
commits (see 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-go.net.git/commit/?h=upstream=316f04ccdf09acb3d65aff39abb11ef287859815),
but is still unfixed. I think we’d need to either have go1.5 or patch
upstream again, just with a newer snapshot.

Tincho, why did you modify the upstream branch instead of shipping a
patch in debian/patches? I thought the upstream branch should contain
_unmodified_ upstream contents.

Also, could you take a stab at this bug please and package a new snapshot?

On Fri, Sep 11, 2015 at 3:00 PM, Dmitry Smirnov  wrote:
> Source: golang-golang-x-net-dev
> Version: 0.0+git20150226.3d87fd6-3
> Severity: wishlist
>
> I'm packaging "google.golang.org/grpc" which fails on missing files in
> "golang.org/x/net/trace" -- I think the latter was introduced upstream after
> 2015-02-26 hence I'm asking for new upstream release (or snapshot) of
> "golang-golang-x-net-dev" please.
>
> --
> All the best,
>  Dmitry Smirnov
>  GPG key : 4096R/53968D1B
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
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] Usage of Built-Using for dev packages

[Michael Stapelberg]

I agree that setting Built-Using on the -dev packages does not make
sense as long as they don’t contain binaries. golang-gogoprotobuf-dev
is an example where the -dev package does contain binaries.

As the vast majority of -dev packages does not actually contain
binaries, I’m happy to accept a pull request for dh-make-golang which
only adds Built-Using to programs (vs. libraries).

On Thu, Sep 10, 2015 at 11:09 PM, Alexandre Viau
 wrote:
> Hello team,
>
> During my NM process, I was asked to justify the use of Built-Using on
> golang dev packages.
>
> In the past, I was asked to add it to my golang dev packages by a
> sponsor from the team.
>
> I don't think that the intent of the Built-Using field described in the
> Debian policy fits with this kind of use. It says that "the source
> packages of those other packages are a required part of the complete
> source".  This is not the case for source code packages.
>
> However, I can see that it can be useful for archiving purposes. Its
> easier to see in what condition the package was built.
>
> If we choose that the Built-Using field does not make sense for source
> packages, we should reflect this in dh-make-golang.
>
> see:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using
>
> Have I missed anything? thoughts?
>
> Thanks,
>
> --
> Alexandre Viau
> alexan...@alexandreviau.net
>
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
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] RFS: a clutch of small go packages

[Michael Stapelberg]

Sorry for the late reply. While the resulting package looks good, I
have two comments:

1) In debian/control, you don’t list pkg-go as maintainer. Please make
pkg-go the maintainer and yourself an uploader.

2) In debian/copyright, you license the packaging (debian/*) as
GPL-2+, whereas upstream is licensed as MPL-2. For simplicity
(especially when shipping patches), we typically license packaging the
same as upstream. Could you change that please?

Note that both of these are things which dh-make-golang automatically
does for you. See
https://people.debian.org/~stapelberg//2015/07/27/dh-make-golang.html
for an introduction if you’re not yet familiar with the tool.

On Wed, Sep 9, 2015 at 5:14 AM, Potter, Tim (Cloud Services)
<timothy.pot...@hpe.com> wrote:
> [Resend as first try was bounced as spam]
>
>> On 27 Aug 2015, at 7:42 am, Potter, Tim (Cloud Services) 
>> <timothy.pot...@hpe.com> wrote:
>>
>> n 27 Aug 2015, at 2:26 am, Michael Stapelberg <stapelb...@debian.org> wrote:
>>>
>>> Thanks for your work on these packages!
>>>
>>> On Tue, Aug 25, 2015 at 12:35 PM, Potter, Tim (Cloud Services)
>>> <timothy.pot...@hpe.com> wrote:
>>>> Hi everyone.  I’ve put together a couple of packages for review.  
>>>> Hopefully these
>>>> are ready to go as they’re quite small.  Could someone please review and 
>>>> upload?
>>>>
>>>> * golang-github-coreos-go-iptables
>>>
>>> Uploaded, but I can’t push the tag…?
>>
>> Thanks Michael!  I've fixed up the permissions on this repos - sorry about 
>> that.
>>
>> Will let you know when it's safe to upload dhcp4client.
>
> Hi Michael.  The -dhcp4 package has made it to unstable.  Could you please 
> upload the -dhcp4client package?
>
>
> Thanks!
>
> Tim.



-- 
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] Bug#798725: golang-github-vbatts-tar-split: FTBFS: B-D favors nonexistent packages over real ones

[Michael Stapelberg]

On Sat, Sep 12, 2015 at 12:15 AM, Aaron M. Ucko  wrote:
> Source: golang-github-vbatts-tar-split
> Version: 0.9.7-1
> Severity: serious
> Justification: fails to build from source
>
> Automatic builds of golang-github-vbatts-tar-split have been failing
> because its build dependencies include
>
>   golang-github-codegangsta-cli-dev | golang-codegangsta-cli-dev
>
> and
>
>   golang-github-sirupsen-logrus-dev | golang-logrus-dev
>
> These terms are both technically satisfiable because
> golang-codegangsta-cli-dev and golang-logrus-dev both exist in the
> archive.  However, for the sake of reproducibility, the autobuilders
> only ever try the first option (modulo explicit architectural
> constraints), and consequently fail.  Please either remove the

Ugh :(. That is a serious downside for our renaming strategy.

> references to golang-github-*-dev or swap them to appear after the
> packages that are actually available.

I think the better fix is to actually upload
golang-github-codegangsta-cli-dev and
golang-github-sirupsen-logrus-dev.

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



-- 
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] Bug#800930: ITP: ratt -- Rebuild All The Things!

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: ratt
  Version : 0.0~git20150816.0.b060319-1
  Upstream Author : Michael Stapelberg
* URL : https://github.com/debian/ratt
* License : MIT
  Programming Lang: Go
  Description : Rebuild All The Things!

 ratt (“Rebuild All The Things!”) operates on a Debian .changes file of a
 just-built package, identifies all reverse-build-dependencies and rebuilds
 them with the .debs from the .changes file.
 .
 The intended use-case is, for example, to package a new snapshot of
 a Go library and verify that the new version does not break any other
 Go libraries/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

Re: [pkg-go] Fwd: Updating the pkg-go Team Maintenance policy

[Michael Stapelberg]

Dmitry, thanks for articulating your concerns. AFAICT, you are mostly
concerned about uploads of new versions.

Would you agree to a no-communication-necessary policy when it only covers
bugfixes/other package maintenance, for example mass-changes such as
getting rid of “Depends: golang-go” on all library packages?

On Tue, Jan 19, 2016 at 9:18 AM, Dmitry Smirnov <only...@debian.org> wrote:

> On Tue, 19 Jan 2016 08:51:22 AM Michael Stapelberg wrote:
> > Dmitry, can you please outline what it is that you dislike about the
> > suggestion?
>
> Too much freedom to upload without notifying those who are responsible for
> package. Lack of notion that Team upload is a rough equivalent to NMU hence
> notification is a must as well as delay (through DELAYED queue or other
> means).
> Alexandre wants to ensure that everyone can upload everything without
> talking
> but team maintenance should be more about communication.
> For example one might want to upload new upstream release of a package
> without telling Uploaders. But new release may not be uploaded for reason
> like when Uploaders (who presumably follow upstream development) are aware
> of
> regression or disruptive change in new release and prefer to wait for
> update.
> In number of cases upload can be held by known upstream bugs etc. Therefore
> one who wants to upload must communicate and not just do as (s)he pleased
> without even sending an email to those who migh be aware of specifics and
> situation.
>
> We are all here to help each other but let's not forget about importance of
> communication.
>
> --
> Cheers,
>  Dmitry Smirnov.
>
> ---
>
> Every decent man is ashamed of the government he lives under.
> -- H. L. Mencken
>



-- 
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] Fwd: Updating the pkg-go Team Maintenance policy

[Michael Stapelberg]

tincho, I think you are in agreement with the policy change that aviau
suggested. Have you read the patch (which you can find at
https://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160118/003015.html)
or were you referring to the discussion as a whole?

If your comment was in fact related to the patch, could you outline the
specific differences to the pkg-perl status quo that you dislike?

I haven’t committed anything yet (see
https://anonscm.debian.org/cgit/pkg-go/website.git/), so I’ll wait another
day to let you clarify things.

On Sun, Feb 7, 2016 at 5:55 AM, Martín Ferrari <tin...@tincho.org> wrote:

> On 04/02/16 18:57, Michael Stapelberg wrote:
> > I’m also in support of it.
> >
> > In case nobody else chimes in with an objection, I’ll commit it this
> > weekend.
>
> Sorry I am this late to the discussion, you probably have commited the
> new version by now.. Still I would like to voice my opinion for future
> iterations of the policy.
>
>
> I am sad to have missed this (I just kept saving the thread for when 'I
> had time' to properly read it), as I think this is an issue I always
> cared about, and hoped that it would move in a different direction from
> what the discussion went to.
>
> I started my life in Debian in the Perl group, and so it shaped my views
> pretty strongly. I always felt that was a very welcoming place, for
> newbies and old-timers, where work was always appreciated, and you did
> not feel alienated if you could not devote so much time sometimes (and I
> finally stopped working there at some point).
>
> It was very low-stress, and the group succeeds in maintaining an obscene
> number of packages with not so many active members. With many members
> staying for years, and old members are still friends. I don't remember
> any fight, just many calm technical discussions.
>
> A big part of all this "utopia" I am painting here - I believe - is that
> nobody "owned" a package. You only put your name in Uploaders before
> uploading, but you did not need to ask permission from anybody, because
> the owner was the group as a whole. So, instead of asking for
> permissions to fix bugs, you only discussed with the group bigger
> matters, like mass-commits, changes in tooling, etc.
>
> If you go away, most of the time nobody actually needs you to continue
> working. And I feel very relieved that I don't need to be committed for
> life to all the packages I have ever uploaded there.
>
> To address one concern about a more open policy; to avoid clashes, you
> never assume that nobody will touch the package unless you ask somehow.
> In that case, you would just leave a note in the changelog, asking other
> not to upload, and/or asking for help. For example, in this[1] commit.
>
>
>
> So, again, sorry for being this late to the conversation, but I hope we
> can discuss this approach for a next version.
>
> Tincho.
>
> [1]:
>
> https://anonscm.debian.org/cgit/pkg-perl/packages/libmemcached-libmemcached-perl.git/commit/?id=e780b94
>
> --
> 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
>



-- 
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] golang-github-jacobsa-ogletest: Bug#803320: TestGoldenFiles fails with Go 1.5

[Michael Stapelberg]

Dmitry, can you do the upload please?

On Sat, Feb 27, 2016 at 12:17 PM, Dmitry Smirnov  wrote:

> On Sun, 17 Jan 2016 06:51:59 PM Harlan Lieberman-Berg wrote:
> > Confirmed and pre-existing upstream bug referenced.
>
> Guys could someone please re-upload "jacobsa-ogletest" with tests disabled
> or
> something to avoid dropping the whole hierarchy of innocent packages from
> "testing"?
>
> Thanks.
>
> --
> Best wishes,
>  Dmitry Smirnov.
>
> ---
>
> It is a fine thing to be honest, but it is also very important to be right.
> -- Winston Churchill
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Hi Alexandre,

Alexandre Viau  writes:
> This was discussed in dh-make-golang's issue tracker (adding Michael to
> CC as he has expressed a friend of his would like to code this):
>  - https://github.com/Debian/dh-make-golang/issues/8

I’ve checked back with said friend, and his life is too busy to work on
this anytime soon. So, if anyone else wants to step in, that’d be
appreciated :).

-- 
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] RFC: Enhancements to dh-golang

[Michael Stapelberg]

I’m not opposed, please feel free to push your changes.

On Sat, May 14, 2016 at 3:50 PM, Martín Ferrari  wrote:

> Since nobody has voiced strong concerns about this, I will merge this
> change later today or tomorrow and upload.
>
> I wanted to wait for Michael S. to chime in, but I guess he's not
> strongly opposed either :-)
>
>
> On 08/05/16 05: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
> >
> >
> > * 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
> >
> >
> > * 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
> >
> >
> > Thoughts?
> >
>
>
> --
> Martín Ferrari (Tincho)
>



-- 
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] Bug#819472: Bug#819472: dh-make-golang: diff for NMU version 0.0~git20150913.0.1221041-1.1

[Michael Stapelberg]

I didn’t see this before pushing a new version.

Why did you not commit your changes to the collab-maint git repository? :(

On Thu, Apr 7, 2016 at 11:29 AM, Raphael Hertzog  wrote:

> Control: tags 819472 + patch
> Control: tags 819472 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for dh-make-golang (versioned as
> 0.0~git20150913.0.1221041-1.1) and just uploaded it.
>
> Regards.
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Bug#819472: Bug#819472: dh-make-golang: diff for NMU version 0.0~git20150913.0.1221041-1.1

[Michael Stapelberg]

On Thu, Apr 14, 2016 at 12:57 AM, Raphael Hertzog <hert...@debian.org>
wrote:

> Hi,
>
> On Thu, 14 Apr 2016, Michael Stapelberg wrote:
> > I didn’t see this before pushing a new version.
>
> What new version? The new version looks like my changes only.
>

I packaged a new upstream snapshot.


>
> > Why did you not commit your changes to the collab-maint git repository?
> :(
>
> Because it's not in collab-maint but in pkg-go which I am not part of...
>

Sorry, I confused this package with dh-golang. I’d encourage you to become
a member of pkg-go, though. It’s a quick procedure: you click the button on
alioth, we approve :).

Thanks!


>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>



-- 
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 Stapelberg]

Thanks for the patch, it’s now merged and uploaded.

I’d prefer if you could send such patches in a bug report instead of to
mailing lists which I don’t actively read :). In fact, I’d say it’s long
overdue to make this package team-maintained. The repository is already in
collab-maint, so if you want to make the necessary changes, please just go
ahead.

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
>  wrote:
> > On 13 April 2016 at 17:07, Tianon Gravi  wrote:
> >> On 12 April 2016 at 21:39, Michael Hudson-Doyle
> >>  wrote:
> >>> We could do it without 1) and the consequent re-uploading of every go
> >>> library by using 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] Fwd: Updating the pkg-go Team Maintenance policy

[Michael Stapelberg]

Thank you for your patience with this, the last few weeks have been very
busy for me.

I’ve applied the patch and updated the website, so the changes are live now.

Thanks!

On Fri, Feb 26, 2016 at 4:18 PM, Alexandre Viau  wrote:

> On 13/02/16 10:34 PM, Martín Ferrari wrote:
> > On 09/02/16 01:44, Alexandre Viau wrote:
> >> Hello,
> >>
> >> On 08/02/16 12:49 AM, Martín Ferrari wrote:
> >>> Although I presume this change might not be acceptable for some people,
> >>> I think the notes about changelog handling would be a good addition.
> >>
> >> +1, I agree with this change.
> >>
> >> Maybe we should apply the first patch right now and wait one more week
> >> for this one.
> >
> > Nobody else replied, but I am in favor of this idea.
>
> Two weeks have passed, it looks like everyone is also in favor of this
> patch.
>
> Michael, can we go ahead and apply Martin's patch?
>
> I have attached it to this mail.
>
> Thanks,
>
> --
> 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

Re: [pkg-go] Future of Packer in Debian

[Michael Stapelberg]

[+cc stender, who maintains this package]

Thanks for the offer to help. I think the best way to make others aware
that you’re willing to help would be to add you as an uploader.

Daniel, what do you think? Would you be amenable to Emmanuel helping out
with the package? If yes, could you add him as an uploader please?

On Sat, Jul 2, 2016 at 2:12 PM, Emmanuel Kasper  wrote:

> Hi Michael, Hi Go team
>
> I am currently working inside debian-cloud to create Cloud images for
> Vagrant using the 'packer' package that you maintain as a team.
> ( https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes )
> These cloud images have been very popular, nearly one million download
> in 18 months.
>
> Now there is slow but ongoing work to have this building being done by
> the debian-cd infrastructure.
>
> As we would be for the momment relying on the packer package to do this
> work, I am interested of course on having a packer package activately
> maintained, so if you need help here, just ping me.
> At the momment with the latest packer release already in stretch and 0
> open bugs in the BTS the situation looks more than fine :)
>
> Emmanuel
>
>
>
>
>
>
>
>
>
>
>
>


-- 
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] "use of internal package not allowed" running dh-make-golang

[Michael Stapelberg]

On Thu, Nov 17, 2016 at 7:41 AM, Martín Ferrari <tin...@tincho.org> wrote:

> Michael,
>
> On 17/11/16 08:20, Michael Stapelberg wrote:
> > Instead of creating additional scripts/tools, could we try to centralize
> > that functionality into either gbp import-orig itself, or dh-make-golang
> > please? https://github.com/Debian/dh-make-golang/issues/14 is related,
> > and paultag expressed some interest in this as well recently.
>
> That'd be great, but I don't really have the time now to dive into gbp
> or dh-make-golang to add this functionality.
>
> I uploaded my scripts to the shared repo because I think they might be
> useful for other people, no need to get upset about that!
>

I’m not upset :).


>
>
> > As for the issue itself, could you please file a bug
> > at https://github.com/Debian/dh-make-golang/issues so that the problem
> > is at least documented? Not sure when I’ll have time to look at it more
> > closely, but we should definitely try to solve it.
>
> I did not experience this bug, I can't file a report.
>

Sorry, should’ve been clearer: that was a question for Tim.


>
>
> --
> Martín Ferrari (Tincho)
>



-- 
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] "use of internal package not allowed" running dh-make-golang

[Michael Stapelberg]

Glad to hear it’s useful :).

On Fri, Nov 18, 2016 at 4:37 AM, Potter, Tim (HPE Linux Support) <
timothy.pot...@hpe.com> wrote:

> On 17 Nov 2016, at 6:20 PM, Michael Stapelberg <stapelb...@debian.org>
> wrote
>
> > As for the issue itself, could you please file a bug at
> https://github.com/Debian/dh-make-golang/issues so that the problem is at
> least documented? Not sure when I’ll have time to look at it more closely,
> but we should definitely try to solve it.
>
> https://github.com/Debian/dh-make-golang/issues/50
>
> BTW thanks for an awesome tool.  dh-make-golang is such a great timesaver
> and works
> perfectly 99% of the time.
>
>
> Tim.
>



-- 
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] Upload of dh-make-golang

[Michael Stapelberg]

No objections, no special tests necessary.

If things break, we get a good signal on what tests we need to add :).

Thanks for your work on this!

On Tue, Nov 29, 2016 at 6:11 PM, Dr. Tobias Quathamer 
wrote:

> Am 22.11.2016 um 13:36 schrieb Dr. Tobias Quathamer:
>
>> Hi all,
>>
>> I've prepared a new version of dh-make-golang, ready to upload to
>> unstable.
>>
>> I don't want to break this tool, so apart from the usual checks, is
>> there anything special to consider before uploading? Or can I just go
>> ahead?
>>
>> Regards,
>> Tobias
>>
>
> Hi Michael,
>
> any objections from your side?
>
> Regards,
> Tobias
>
>
>


-- 
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] Bug#855922: Bug#855922: containerd: 0.2.3 ds1-1 breaks docker 1.11 - unable to start containerd

[Michael Stapelberg]

With runc 1.0.0~rc2+git20161109.131.5137186-2, things indeed work again.
Thanks!

On Thu, Mar 30, 2017 at 5:26 AM, Potter, Tim <timothy.pot...@hpe.com> wrote:

> On 30 Mar 2017, at 3:54 AM, Michael Stapelberg <stapelb...@debian.org>
> wrote:
> >
> > Hi Tim,
> >
> > "Potter, Tim" <timothy.pot...@hpe.com> writes:
> >> Hi Ricardo.  Thanks for the bug report.  I messed up by uploading some
> of the Docker 1.13
> >> dependencies to unstable instead of experimental - my apologies.
> >>
> >> I've done a new upload with a Breaks line to avoid this bug occurring
> until I finish testing
> >> 1.13 and uploading to unstable.
> >
> > I’m still running into this issue (or a very similar one?) with:
> >
> > docker.io 1.13.0~ds1-2
> > runc 0.1.1+dfsg1-2+b1
> > containerd 0.2.3~git20161117.78.03e5862~ds1-2
> > golang-libnetwork 0.8.0~dev.2+git20161130.568.fd27f22-4
> >
> > I installed these packages from Debian unstable, but AFAICT, no newer
> > version is available in experimental.
> >
> > The symptom is:
> > $ docker run -t -i debian:sid /bin/bash
> > docker: Error response from daemon: containerd: container not started.
> >
> > In the journal, I can’t see any errors from containerd itself.
> >
> > Should docker be working in Debian at the moment? If not, is there a
> > workaround?
>
> Hi Michael.  I did an upload yesterday to unstable and things should be
> working again.
> Sorry about the mess in experimental vs unstable.  I was trying to keep
> both the old
> and new version working but failed miserably.
>
> Please let me know if you find any more brokenness.
>
>
> Tim.
>



-- 
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] Bug#857025: Bug#857025: golang-golang-x-tools FRBFS on armhf: golang.org/x/tools/refactor/satisfy [no test files]

[Michael Stapelberg]

control: owner -1 !

Hi,

Michael Hudson-Doyle  writes:
> and the failure is this:
>
> === RUN   TestImportSymlinks
> --- FAIL: TestImportSymlinks (0.03s)
> Which, frankly, is a very bizarre test to be arch dependent.

It’s not arch-dependent, it’s “just” flaky :).

This was fixed upstream:
https://github.com/golang/tools/commit/f60b69ed8cd7a29e91f87050ae23a29581a0f367

I’ll cherry-pick this fix into a new upload after having a look at #857024.

-- 
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] Bug#857291: ITP: golang-golang-x-debug -- debugging tools

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-golang-x-debug
  Version : 0.0~git20160621.0.fb50892-1
  Upstream Author : The Go Authors
* URL : https://golang.org/x/debug
* License : BSD-3-clause
  Programming Lang: Go
  Description : debugging tools

Package debug provides the portable interface to a program being debugged.

golang.org/x/debug is a dependency of cloud.google.com/go, which is a
dependency of upspin.

I know that the package description is very brief, but this is all that
upstream provides us with :|.

___
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#857282: ITP: golang-github-golang-geo -- S2 geometry library in Go

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-github-golang-geo
  Version : 0.0~git20170112.0.f819552-1
  Upstream Author : Google Inc.
* URL : https://github.com/golang/geo
* License : Apache-2.0
  Programming Lang: Go
  Description : S2 geometry library in Go

 S2 is a library for manipulating geometric shapes. Unlike many geometry
 libraries, S2 is primarily designed to work with spherical geometry, i.e.,
 shapes drawn on a sphere rather than on a planar 2D map. (In fact, the name S2
 is derived from the mathematical notation for the unit sphere.) This makes it
 especially suitable for working with geographic data.
 .
 The library consists of:
 * Basic representations of angles, intervals, latitude-longitude points, unit
   3D vectors, and conversions among them.
 * Various shapes over the unit sphere, such as spherical caps ("discs"),
   latitude-longitude rectangles, polylines, and polygons. These are
   collectively known as "regions".
 * Support for spatial indexing of collections of geometry, and algorithms for
   testing containment, finding nearby objects, finding intersections, etc.
 * A hierarchical decomposition of the sphere into regions called "cells". The
   hierarchy starts with the six faces of a projected cube and recursively
   subdivides them in a quadtree-like fashion.
 * The ability to approximate arbitrary regions as a collection of cells. This
   is useful for building inverted indexes that allow queries over arbitrarily
   shaped regions.  The implementations attempt to be precise both in terms of
   mathematical definitions (e.g. whether regions include their boundaries,
   representations of empty and full regions) and numerical accuracy (e.g.
   avoiding cancellation error).
 .
 Note that the intent of this library is to represent geometry as a
 mathematical abstraction. For example, although the unit sphere is
 obviously a useful approximation for the Earth's surface, functions that
 are specifically related to geography are not part of the core library
 (e.g. easting/northing conversions, ellipsoid approximations, geodetic
 vs. geocentric coordinates, etc).

github.com/golang/geo is a dependency of cloud.google.com/go, which is a
dependency of upspin.

___
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#857656: [PATCH] c/binaries: amend go whitelist to cover all errors

[Michael Stapelberg]

Package: lintian
Version: 2.5.51
Severity: normal
Tags: patch

Please consider merging the attached patch.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.27.90.20170124-2
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  file  1:5.29-3
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.22
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-5
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.22
pn  libperlio-gzip-perl  
ii  perl 5.24.1-1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-5
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.22
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information
>From a6a605806a0c52f723879eaf2f3ace92c46ec2b4 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg <stapelb...@debian.org>
Date: Mon, 13 Mar 2017 20:30:40 +0100
Subject: [PATCH 3/3] c/binaries: amend go whitelist to cover all errors

---
 checks/binaries.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/checks/binaries.pm b/checks/binaries.pm
index 5870dd9bd..a0d57bc83 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -586,11 +586,13 @@ sub run {
 }
 
 if ($arch_hardening->{'hardening-no-bindnow'}
+and not $built_with_golang
 and not exists($objdump->{'FLAGS_1'}{'NOW'})) {
 tag 'hardening-no-bindnow', $file;
 }
 
 if ($arch_hardening->{'hardening-no-pie'}
+and not $built_with_golang
 and $objdump->{'ELF-TYPE'} eq 'EXEC') {
 tag 'hardening-no-pie', $file;
 }
-- 
2.11.0

___
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#857655: [PATCH] c/binaries: fix go whitelist by moving variable

[Michael Stapelberg]

Package: lintian
Version: 2.5.51
Severity: normal
Tags: patch

Please consider merging the attached patch.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.27.90.20170124-2
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  file  1:5.29-3
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.30
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.22
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-5
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-1
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.22
pn  libperlio-gzip-perl  
ii  perl 5.24.1-1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-5
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.22
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information
>From 5e485d8396e2c3a041c5ecb8ec90f81579cf182a Mon Sep 17 00:00:00 2001
From: Michael Stapelberg <stapelb...@debian.org>
Date: Mon, 13 Mar 2017 20:30:24 +0100
Subject: [PATCH 2/3] c/binaries: fix go whitelist by moving variable

---
 checks/binaries.pm | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/checks/binaries.pm b/checks/binaries.pm
index 10edfc5f2..5870dd9bd 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -126,6 +126,13 @@ sub run {
 $arch_hardening = $HARDENING->value($arch)
   if $arch ne 'all';
 
+my $src = $group->get_source_processable;
+if (defined($src)) {
+$built_with_golang
+  = $src->info->relation('build-depends')
+  ->implies('golang-go | golang-any');
+}
+
 foreach my $file (sort keys %{$info->objdump_info}) {
 my $objdump = $info->objdump_info->{$file};
 my ($has_lfs, %unharded_functions, @hardened_functions);
@@ -273,13 +280,6 @@ sub run {
 tag 'package-name-doesnt-match-sonames', "@sonames"
   if @sonames && !$match_found;
 
-my $src = $group->get_source_processable;
-if (defined($src)) {
-$built_with_golang
-  = $src->info->relation('build-depends')
-  ->implies('golang-go | golang-any');
-}
-
 # process all files in package
 foreach my $file ($info->sorted_index) {
 my ($fileinfo, $objdump, $fname);
-- 
2.11.0

___
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] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Hi Osamu,

Sorry for the late reply, and thanks for looking into this! Replies
inline:

Osamu Aoki  writes:
> How should we explicitly specify such variables, I guess it should be
> through "opts=..." such as:
>
>  opts="mode=git, pretty=0.0~git%cd.%h, date=%Y%m%d%H%M"

Sounds good.

>
> But this "git log" needs to have local clone of git repository.
>
> I wonder if I can do without cloning first.

After reading the git protocol and searching on the web for a little
bit, my conclusion is that no, you cannot use “git log” without having a
clone of the repository.

Given that we are talking about repositories which do not use tags, we
could specify --depth=1 when cloning to get a shallow clone, i.e. only
the latest commit. That saves bandwidth and disk space, but has the
downside that we cannot do any additional validation, i.e. we can’t
detect if upstream ever starts using tags — unfortunately, that is a
plausible scenario, so I would suggest doing a full clone.

For GitHub, we can apply an optimization: the GitHub HTTP API exposes
repository details, such as:

1. The default_branch of the repo, in
   https://developer.github.com/v3/repos/#get

2. The latest commit of the branch, in
   https://developer.github.com/v3/repos/branches/#get-branch

For interactive use by individual developers, we could send these HTTP
requests unauthenticated. For a setup which does many uscan calls, we’d
need to create a GitHub account to get the higher rate limit. See
https://godoc.org/github.com/google/go-github/github#hdr-Rate_Limiting
for details.

> Adding support to the number of commits is complicated.  Let's be happy
> to use hash to be unique commit.  I do not think we upload more than 2
> Debian upstream tarball in a minute.

In a day, not in a minute. But regardless, you are probably right. I
asked in the pkg-go IRC channel to see whether people are okay with
removing that part from the version number, so barring any objections,
we can probably get that done within the next few days.

> As for "git describe" like nearest tag feature, it's a interesting
> thought but it may make things more complicate.  So unless someone
> strongly request with patch, I would like to skip it.

Agreed — if we get rid of the number of commits, we shouldn’t need git
describe, not even in dh-make-golang.

It seems like you have a good handle on implementing this in uscan. Do
you need any additional details? Do you prefer an external patch from
us over implementing this yourself? I’d be happy to give you feedback on
a proposed patch or git commit.

Thank you very much!

-- 
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] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

On Sun, Jul 30, 2017 at 6:10 AM, Osamu Aoki <os...@debian.org> wrote:

> Hi,
>
> (I switched my ISP.  No more osamua...@e01.itscom.net  Thanks for the
> reminder)
>
> On Sat, Jul 29, 2017 at 06:44:43PM +0200, Michael Stapelberg wrote:
> > Hi Osamu,
> >
> > Sorry for the late reply, and thanks for looking into this! Replies
> > inline:
>
> It's good time to make feature enhancements now.
>
> > Osamu Aoki <osamua...@e01.itscom.net> writes:
> > > How should we explicitly specify such variables, I guess it should be
> > > through "opts=..." such as:
> > >
> > >  opts="mode=git, pretty=0.0~git%cd.%h, date=%Y%m%d%H%M"
> >
> > Sounds good.
>
> I had to read the whole thread to recall what I was thinking ... OK ;-)
>
> > > But this "git log" needs to have local clone of git repository.
> > >
> > > I wonder if I can do without cloning first.
> >
> > After reading the git protocol and searching on the web for a little
> > bit, my conclusion is that no, you cannot use “git log” without having a
> > clone of the repository.
> >
> > Given that we are talking about repositories which do not use tags, we
> > could specify --depth=1 when cloning to get a shallow clone, i.e. only
> > the latest commit. That saves bandwidth and disk space, but has the
> > downside that we cannot do any additional validation, i.e. we can’t
> > detect if upstream ever starts using tags — unfortunately, that is a
> > plausible scenario, so I would suggest doing a full clone.
>
> OK with FULL clone.  (I need to rethink details though... I totally lost
> my memory on this topic)
>
> The thing to consider is what git local repository looks like and how
> you clone such remote tree. "upstream" branch used by git-buildpackage
> is not really the upstream git repository but its series of commits from
> the released upstream tarballs.  Maybe clone it into "upstream-git"
> branch...
>

Wouldn’t it be cleaner to not modify the local repository at all, i.e.
clone in a separate, temporary directory? Aside from a new orig tarball,
uscan doesn’t leave files behind usually, does it?


>
> > For GitHub, we can apply an optimization: the GitHub HTTP API exposes
> > repository details, such as:
> >
> > 1. The default_branch of the repo, in
> >https://developer.github.com/v3/repos/#get
> >
> > 2. The latest commit of the branch, in
> >https://developer.github.com/v3/repos/branches/#get-branch
> >
> > For interactive use by individual developers, we could send these HTTP
> > requests unauthenticated. For a setup which does many uscan calls, we’d
> > need to create a GitHub account to get the higher rate limit. See
> > https://godoc.org/github.com/google/go-github/github#hdr-Rate_Limiting
> > for details.
>
> (This optimization is a bit more work than I can do immediately.)
>

That’s fair. I’m happy to help with a patch for uscan to apply this
optimization, once the foundation for it is done.


>
> > > Adding support to the number of commits is complicated.  Let's be happy
> > > to use hash to be unique commit.  I do not think we upload more than 2
> > > Debian upstream tarball in a minute.
> >
> > In a day, not in a minute. But regardless, you are probably right. I
> > asked in the pkg-go IRC channel to see whether people are okay with
> > removing that part from the version number, so barring any objections,
> > we can probably get that done within the next few days.
>
> Why in a day?
>
> %cd is committer date and this format respects --date= option.
> --date option I suggested was %Y%m%d%H%M" which specified down to
> minutes;-)
> If you insist, I can add seconds ;-)
>

Ah, now I see where you’re coming from. We’re currently using day
granularity, and don’t want to change that, so we’re restricted to 1 upload
per day :).


>
> > > As for "git describe" like nearest tag feature, it's a interesting
> > > thought but it may make things more complicate.  So unless someone
> > > strongly request with patch, I would like to skip it.
> >
> > Agreed — if we get rid of the number of commits, we shouldn’t need git
> > describe, not even in dh-make-golang.
> >
> > It seems like you have a good handle on implementing this in uscan. Do
> > you need any additional details? Do you prefer an external patch from
> > us over implementing this yourself? I’d be happy to give you feedback on
> > a proposed patch or git commit.
>
> OK.  I guess this will be a nice project during My Debconf17 travel for
> me.


Sounds great! I can’t make it to this DebConf, but I wish you safe travels
and a great conference!

Thanks in advance,

-- 
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] heads-up: dh-golang will trim $GOPATH/src from paths for reproducibility

[Michael Stapelberg]

The dh-golang was a success as far as I can tell.

I also prepared a patch for the Go compiler which should take care of the
remaining bits. I’ll add to our Go 1.9 package once 1.9 was released. See
https://github.com/golang/go/issues/16860 for the corresponding upstream
tracking bug.

On Fri, Jul 28, 2017 at 9:36 AM, Michael Stapelberg <stapelb...@debian.org>
wrote:

> Hey,
>
> I just committed https://anonscm.debian.org/cgit/pkg-go/packages/dh-
> golang.git/commit/?id=254c2ad, which works fine in local tests. I intend
> to upload a new dh-golang version with that commit later today.
>
> In case something breaks, please let me know.
>
> I know that this isn’t sufficient to make Go programs build entirely
> reproducibly yet, but it’s a step in the right direction.
>
> I have a patch for the Go linker which should take care of the rest, and
> I’m talking with the folks in #debian-reproducible about getting it applied
> to our reproducible builds infrastructure :).
>
> --
> Best regards,
> Michael
>



-- 
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] Minutes for the DebConf17 BoF

[Michael Stapelberg]

Thanks for sending these out. Comments inline:

On Fri, Aug 11, 2017 at 10:01 PM, 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.
>
> 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.
>
> 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.
>
> 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.
>

This sounds very good.

I have come to appreciate the following properties of working with
git-buildpackage:

1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `gbp
buildpackage --git-export-dir=~/d/out/gocryptfs`. By using
--git-export-dir, my working copy always stays clean. By collecting the
output files per package, I can easily debdiff between versions. This point
is informational and shouldn’t have any bearing on a canonical workflow.

2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
(informational)

3. To import a new upstream version, I run `gbp import-orig --uscan`. This
of course only works with tagged releases until #811565 is fixed (hopefully
soon).

4. To update debian/changelog, I run `gbp dch -R --commit`. Note that this
goes against our current policy of editing debian/changelog with an
UNRELEASED entry — when using gbp-dch, the changelog is entirely
auto-generated from git (but you do have the option to amend it before
committing). Hence, I’d suggest we update that policy and start using
gbp-dch.

5. I use quilt for managing patches, and am reasonably happy with that,
i.e. I personally don’t see the need for anything more fancy than that,
especially given that we usually only carry very few patches per package.
Some of our packages use branches which only contain debian/, not the
upstream source. This breaks quilt and confuses me. I’d suggest we codify
that the branch must contain the upstream sources plus debian/.

Here are some more thoughts, not directly related to how I maintain my own
packages:

6. I have come to appreciate pristine-tar, as it is the only reliable way
(that I know of) to prepare uploads for packages which already have their
orig tarball in Debian. Whenever I come across a package which isn’t using
pristine-tar, the generated orig tarball will have a different checksum,
and my upload will be rejected. I’d suggest we codify that pristine-tar is
a requirement.

7. We don’t currently have a guideline with regards to branch naming,
especially when maintaining branches for multiple debian versions (e.g.
stretch, buster, stretch-backports, …). I’d suggest we adopt the
debian/ branch naming scheme, e.g. debian/buster is the default
branch, backports can be found in debian/stretch-backports, etc.

8. (Optional/best effort) I recently came to understand that dgit is
thought of as a universal approach for new users/maintainers to easily
contribute to packaging (you get the same style of git checkout of any
package in the archive). We should verify the above constraints still leave
us in a place where dgit works well — it will work for any package, but it
will work better for packages which are `dgit push`ed. I don’t yet know
what the requirements for that are.

Thoughts? :)


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

See point ③ above — I’m optimistic that we can use uscan for that 

Re: [pkg-go] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

On Wed, Aug 9, 2017 at 6:54 PM, Shengjing Zhu <i...@zhsj.me> wrote:

> Thanks for the comment.
>
> On Wed, Aug 9, 2017 at 10:54 PM, Michael Stapelberg
> <stapelb...@debian.org> wrote:
> > 1. I think that infrastructure which the pkg-go team critically and very
> > visibly depends on should eventually be hosted by DSA under debian.org.
> I
> > don’t see them hosting this special “workaround” service, when there
> already
> > is infrastructure in place to run uscan.
>
> Well it can be hosted by DSA, or even don't use web service. Maybe
> uscan can just call its cli tool.
>

As much as I’d like to see more Go code within Debian, I think it might be
best to stick with Perl for uscan :).


> I do hope someone can implement it in perl and bring it to uscan. But
> it's hard for me to hack 4k lines perl.
>

I can understand that, and I’m not asking you to work on uscan — Osamu
already seems to be on that.


>
> Anyway, it's an exploration for using API rather than `git clone` locally.
> And I intend to get it to support more Git services, maybe gopkg.in,
> gitlab, etc.
>
> PS, gopkg.in will point to some specific branch, and
> github.com///tags doesn't work well even I append a
> '?after=' suffix.
>
>
> >
> > 2. I have concerns regarding the scalability of such a service if we
> > actually adopted this approach: the GitHub quota permits 5000 requests
> per
> > hour (when authenticated). This sounds like a lot at first glance, but
> > consider that we already have 845 Go packages. Your code does 4 requests
> per
> > repository (IIUC), so already we are fairly close to reaching the limit,
> if
> > we don’t take any precautions.
>
> I haven't considered rate-limit, but do we check so frequently indeed?


I don’t actually know what the rate of uscan checks is behind the Debian
Package Tracker. I can imagine that other places do run uscan, too, though
(think Ubuntu, or other Debian derivatives). In fact, I’m working on a
dashboard myself which does run uscan fairly frequently.

-- 
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] Bug#811565: Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

On Thu, Aug 10, 2017 at 6:50 AM, Osamu Aoki <os...@debian.org> wrote:

> Hi,
>
>
> On Wed, Aug 09, 2017 at 07:54:05AM -0700, Michael Stapelberg wrote:
> > Thanks for sharing your tool!
>
> Thank you but I don't use go nor perl regulary :-(  I wish uscan was in
> Python.)
>
> But supporting github for go or other project is high on my list.
>
>
> > Hence, I think extending uscan is a much much more elegant route to
> achieve our
> > goal, and I’d like to ask people to hold off providing/using custom
> services as
> > a stop-gap measure. Thanks!
>
> I am thinking to add features to support use case for github for go as
> much as it can be as generic solution extendible by user.  (normally,
> this is the last thing on my list since uscan is already too
> complicated.  The last thing we need is project/site specific brute
> force work around.)
>
> If you explain in a plain english (or in patch) text what you wish!
> (Please don't send me complicated perl code. I am no perl speaker.  My
> perl skill is woose than my English one.)
>
> I know there is a bug report on uscan support of github which I should
> be working on.  :-)
>

The functionality in the tool is exactly what was already communicated in
the bug :).

If you need any help with that bug, just let me know.

Thanks!

-- 
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] Bug#811565: Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

On Thu, Aug 10, 2017 at 9:34 AM, Osamu Aoki <os...@debian.org> wrote:

> Hi,
>
> On Thu, Aug 10, 2017 at 08:19:20AM +0200, Michael Stapelberg wrote:
> > On Thu, Aug 10, 2017 at 6:50 AM, Osamu Aoki <os...@debian.org> wrote:
> >
> > The functionality in the tool is exactly what was already communicated
> in the
> > bug :).
> >
> > If you need any help with that bug, just let me know.
>
> #1: exact use case example URL.  (Project which hopefully exists after 4
> years.)
>

Here’s an example: https://github.com/Debian/dh-make-golang/. The
corresponding Debian binary package is
https://packages.debian.org/buster/dh-make-golang; there’s no debian/watch
file yet because of the current lack of support for git :).

Please let me know if you need anything else. Thanks!


>
> #2 Yes, I see ... but backticks  I think I need to do it slightly
> different
>
> backticks("git", "clone", "--quiet", "--bare", "--depth=1", $url,
> $dest);
>
> my $commit_data = backticks("git", "--git-dir=$dest", "log", "-1",
> "--date=format:%Y%m%d", "--format=%h %cd");
>
> chomp($commit_data);
> $commit_data =~ /^([0-9a-z]{7}) ([0-9]{8})$/m
> or die("Invalid git response: $commit_data");
> return ($1, $2);
>
> Thank
>
> Osamu
>
>


-- 
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] Bug#868937: ITP: golang-github-kurin-blazer -- A Golang library for Backblaze's B2.

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-github-kurin-blazer
  Version : 0.0~git20170711.0.612082e-1
  Upstream Author : Toby Burress
* URL : https://github.com/kurin/blazer
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for Backblaze's B2

 Blazer is a Golang client library for Backblaze's B2 object storage
 service.  It is designed for simple integration with existing applications
 that may already be using S3 and Google Cloud Storage, by exporting only
 a few standard Go types.
 .
 It implements and satisfies the B2 integration checklist
 (https://www.backblaze.com/b2/docs/integration_checklist.html),
 automatically handling error recovery, reauthentication, and other
 low-level aspects, making it suitable to upload very large files, or
 over multi-day time scales.

This is a dependency of newer versions of restic.

___
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#869376: Bug#869376: FTBFS: newer golang-github-stretchr-testify breaks tests

[Michael Stapelberg]

An upstream fix is now available at
https://github.com/ncw/rclone/commit/db6009126df98a0a35975ca2fb7271a8493e1e30

Do you want to apply it, or shall I go ahead?

On Sat, Jul 22, 2017 at 8:58 PM, Michael Stapelberg <stapelb...@debian.org>
wrote:

> Source: rclone
> Version: 1.36-1
> Severity: important
> Tags: upstream
>
> Thank you for maintaining rclone!
>
> I reported this upstream at https://github.com/ncw/rclone/issues/1550. If
> a new
> upstream release won’t happen soon anyway, please apply a patch to skip the
> faulty test.
>
> https://bugs.debian.org/851725 (random FTBFS) might be related, as it
> seems like
> the test is broken in rclone.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armel, mipsel, arm64
>
> Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Bug#869800: Bug#869800: Bug#869800: golang-github-aws-aws-sdk-go: Please update to >= 1.4.13

[Michael Stapelberg]

On Thu, Jul 27, 2017 at 6:23 AM, Martín Ferrari <tin...@tincho.org> wrote:

> On 27/07/17 14:05, Michael Stapelberg wrote:
> > It does break the API, as evinced by one build failure.
> >
> > I’m not aware of situations in the past where we created a new binary.
> > How would we name them? Is it worth the trouble?
>
> We had to do it once, for golang-github-dgrijalva-jwt-go-v3-dev
>
> Worth the trouble or not: depends on who gets to fix all the breakage
> left behind :)
>

Yes, I think this makes for a good rule of thumb: if fixes for the affected
packages are readily available, there’s little harm in uploading all
packages at once, and it means less work for ftp-master and less bloat in
the archive :).

If, however, fixes are more involved/not easily coordinated, we should go
the route of a new package.


>
> > Personally, I would just update the new version + the fixed affected
> > packages in one go, to reduce the breakage to a minimum.
>
> I would be OK with that.
>
> --
> Martín Ferrari (Tincho)
>



-- 
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] Bug#869800: golang-github-aws-aws-sdk-go: Please update to >= 1.4.13

[Michael Stapelberg]

Yeah, it definitely makes sense to bring up this issue with upstream. They
should indeed either commit to keeping their API stable, or use gopkg.in or
similar.

On Thu, Jul 27, 2017 at 6:49 AM, Shengjing Zhu <i...@zhsj.me> wrote:

> On Thu, Jul 27, 2017 at 9:23 PM, Martín Ferrari <tin...@tincho.org> wrote:
> > On 27/07/17 14:05, Michael Stapelberg wrote:
> >> It does break the API, as evinced by one build failure.
> >>
> >> I’m not aware of situations in the past where we created a new binary.
> >> How would we name them? Is it worth the trouble?
> >
> > We had to do it once, for golang-github-dgrijalva-jwt-go-v3-dev
> >
>
> It leaves the problem that, we need to fix the import path on every
> package that depends on it. Take this package for example, the import
> path need to be github.com/dgrijalva/jwt-go-v3
>
> /me just wondering why upstream don't use gopkg.in/xxx as the import
> path...when they has versioned api.
>
>
> --
> Best regards,
> Shengjing Zhu
>



-- 
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] Bug#869800: Bug#869800: Bug#869800: golang-github-aws-aws-sdk-go: Please update to >= 1.4.13

[Michael Stapelberg]

It does break the API, as evinced by one build failure.

I’m not aware of situations in the past where we created a new binary. How
would we name them? Is it worth the trouble?

Personally, I would just update the new version + the fixed affected
packages in one go, to reduce the breakage to a minimum.

On Thu, Jul 27, 2017 at 5:55 AM, Martín Ferrari  wrote:

> On 26/07/17 15:46, Shengjing Zhu wrote:
>
> > I have tested aws-sdk-go 1.4.22 in my local env and also tested it with
> > ratt. (I pick 1.4.22 since I hope we don't break too many things.)
>
> We need to know if this will introduce further regressions, or if it is
> API incompatible.. If it is, we would need a new binary package for the
> new API
>
> --
> 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
>



-- 
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] heads-up: dh-golang will trim $GOPATH/src from paths for reproducibility

[Michael Stapelberg]

Hey,

I just committed
https://anonscm.debian.org/cgit/pkg-go/packages/dh-golang.git/commit/?id=254c2ad,
which works fine in local tests. I intend to upload a new dh-golang version
with that commit later today.

In case something breaks, please let me know.

I know that this isn’t sufficient to make Go programs build entirely
reproducibly yet, but it’s a step in the right direction.

I have a patch for the Go linker which should take care of the rest, and
I’m talking with the folks in #debian-reproducible about getting it applied
to our reproducible builds infrastructure :).

-- 
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-go bof at debconf

[Michael Stapelberg]

Hangouts indeed no longer requires a plugin, it uses WebRTC.

I’d love to join, but can’t make the time: tomorrow evening is our local Go
meetup’s Go 1.9 release party.

Please circulate meeting minutes of significant discussion topics, I’ll
read up on it. Thanks!

On Tue, Aug 8, 2017 at 4:21 AM, Shengjing Zhu  wrote:

> On Tue, Aug 8, 2017 at 5:10 AM, Martín Ferrari  wrote:
> > Any suggestions about something that works reliably? I have been using
> > Google Hangouts for work, but it requires a proprietary chromium plugin.
>
> I think I didn't install any proprietary plugin, but I can use
> Hangouts in Chromium.
> So I vote for using Hangout.
>
> --
> Best regards,
> Shengjing Zhu
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
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] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Thanks for sharing your tool!

I also considered implementing such a tool, but ultimately decided against
it for a number of reasons:

1. I think that infrastructure which the pkg-go team critically and very
visibly depends on should eventually be hosted by DSA under debian.org. I
don’t see them hosting this special “workaround” service, when there
already is infrastructure in place to run uscan.

2. I have concerns regarding the scalability of such a service if we
actually adopted this approach: the GitHub quota permits 5000 requests per
hour (when authenticated). This sounds like a lot at first glance, but
consider that we already have 845 Go packages. Your code does 4 requests
per repository (IIUC), so already we are fairly close to reaching the
limit, if we don’t take any precautions.

Most likely, point ② could be addressed with some careful limiting on our
end, and changing the processing model from generating a response upon
end-user request to iterating through all Go packages in Debian and
querying GitHub in a rate-limited fashion. This significantly complicates
the program, though, to the point where we duplicate the logic behind the
Debian Package Tracker. Worse, it introduces accidental complexity, not
inherent complexity :).

Hence, I think extending uscan is a much much more elegant route to achieve
our goal, and I’d like to ask people to hold off providing/using custom
services as a stop-gap measure. Thanks!

On Wed, Aug 9, 2017 at 7:38 AM, Shengjing Zhu  wrote:

> Hi all,
>
> I spent some time playing around GitHub api, and results a small tool,
> https://github.com/zhsj/git-watch
>
> I didn't implement it in uscan. But it can work well with uscan.
>
> A demo service is at https://watch.zhsj.me/
>
> Take one of packages I maintained,
> https://tracker.debian.org/golang-github-xiaq-persistent
> https://watch.zhsj.me/github/xiaq/persistent is the watch url.
> And the following d/watch works fine,
>
> version=4
> opts="filenamemangle=s%(?:.*?)?([^/]*)\.tar\.gz%golang-githu
> b-xiaq-persistent-$1.tar.gz%"
> \
>   https://watch.zhsj.me/github/xiaq/persistent \
>   (?:.*?/)?([^/]*)\.tar\.gz
>
> This tool works both as web service and cli.
>
> I hope you find this tool useful.
>
> Yours,
> Shengjing Zhu
>



-- 
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] Minutes for the DebConf17 BoF

[Michael Stapelberg]

On Sun, Aug 20, 2017 at 2:30 PM, Martín Ferrari <tin...@tincho.org> wrote:
> Hi Mickael,
>
> I haven't yet got the time to write down properly my workflow, but I
> will still reply to some points. :)
>
> On 15/08/17 23:02, Michael Stapelberg wrote:
>
>> 1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `gbp
>> buildpackage --git-export-dir=~/d/out/gocryptfs`. By using
>> --git-export-dir, my working copy always stays clean. By collecting the
>> output files per package, I can easily debdiff between versions. This
>> point is informational and shouldn’t have any bearing on a canonical
>> workflow.
>
> Why do you need this? I use gbp with cowbuilder, and so the working copy
> is never touched. Looking at my gbp.conf, I see my default is to export
> to '../build-area', but probably that does not change much.

I use gbp with sbuild, and I do see different behavior with/without
exporting. Take for example the freeradius repository, where the build
fails without git-export-dir: https://paste.debian.net/982241/

>
>> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
>> <https://paste.debian.net/hidden/a48afca2/> (informational)
>
> Sadly, this has expired

Sorry about that. Here’s one that shouldn’t expire:
https://paste.debian.net/982242/

>
>> 4. To update debian/changelog, I run `gbp dch -R --commit`. Note that
>> this goes against our current policy of editing debian/changelog with an
>> UNRELEASED entry — when using gbp-dch, the changelog is entirely
>> auto-generated from git (but you do have the option to amend it before
>> committing). Hence, I’d suggest we update that policy and start using
>> gbp-dch.
>
> This is one of these things were we should decide on one way to do
> things, as it is incompatible with the other usual way, which is to
> change debian/changelog on every commit.
>
>> not the upstream source. This breaks quilt and confuses me. I’d suggest
>> we codify that the branch must contain the upstream sources plus debian/.
>
> +1
>
>> different checksum, and my upload will be rejected. I’d suggest we
>> codify that pristine-tar is a requirement.
>
> +1
>
>> 7. We don’t currently have a guideline with regards to branch naming,
>> especially when maintaining branches for multiple debian versions (e.g.
>> stretch, buster, stretch-backports, …). I’d suggest we adopt the
>> debian/ branch naming scheme, e.g. debian/buster is the default
>> branch, backports can be found in debian/stretch-backports, etc.
>
> I have adopted DEP-14, which is basically this, and makes it very
> pleasant to work with different distributions, specially since I have
> been doing a lot of backporting.
>
> One caveat: the default branch should (according to DEP-14) not be
> debian/buster, but debian/sid (or just master).

Thanks for the pointer, I wasn’t aware of DEP-14 yet. We should
definitely adopt it.

>
>> 8. (Optional/best effort) I recently came to understand that dgit is
>> thought of as a universal approach for new users/maintainers to easily
>> contribute to packaging (you get the same style of git checkout of any
>> package in the archive). We should verify the above constraints still
>> leave us in a place where dgit works well — it will work for any
>> package, but it will work better for packages which are `dgit push`ed. I
>> don’t yet know what the requirements for that are.
>
> Same here, I haven't checked it out yet
>
> --
> Martín Ferrari (Tincho)



-- 
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] Minutes for the DebConf17 BoF

[Michael Stapelberg]

On Sun, Aug 20, 2017 at 7:18 PM, Martín Ferrari  wrote:
> On 20/08/17 17:35, Martín Ferrari wrote:
>> So, my turn to describe workflows.
>
> Some things I forgot in my previous email:
>
> * I am not married to the idea of dch + debcommit, specially when I have
> merge conflicts. I understand the merits of git commit + gbp dch.
> * The export=WC option in gbp.conf is to make sure my uncommitted
> changes are taken into account when building, which allows me to
> experiment and test before committing.
>
> Some notes not about workflow, but about packaging strategies:
>
> 1. debian/control
>
> I wrap and sort all multi-entry fields, with a trailing comma at every
> line (to minimise diffs). I always did this by hand (or with my
> pkg-go-common-fixes script), but a friend just recommended the
> wrap-and-sort script from devscripts, and I think we should all use that
> with the same options.
>
> Even if this does not match what I am currently doing (indent after
> colon), I think it makes more sense:
>
> $ wrap-and-sort -st
>
> Add myself as Uploader for any package where I do some non-trivial
> amount of work. Although I think this usage of Uploaders is being
> challenged project-wise.

Strong +1. Let’s auto-format all things we can reasonably auto-format.
debian/control files are a good candidate for that :).

>
> Add Testsuite: autopkgtest-pkg-go to every package.
>
> 2. debian/rules
>
> Keep it as minimal as possible.
>
> To add extra needed files (for tests and the such) use
> DH_GOLANG_INSTALL_EXTRA, no manual copying and no DH_GOLANG_INSTALL_ALL.
>
> To avoid compilation and testing of some packages use DH_GOLANG_EXCLUDES.
>
> If I need to do something in the build directory, pass --builddirectory
> to dh, so it is a known location (as opposed to getting the weird path
> from debhelper)
>
> Gccgo has many quirks. One is that it does not use the vendor directory
> (I need to check if this is true with the latest version), so you might
> need to copy vendor into the builddirectory.

…hopefully only temporarily, though, right? Ideally, we wouldn’t have
any vendored source in our packages.

>
> For detecting gccgo, and doing special things:
>
> GCCGO  := $(strip $(shell go version | grep gccgo))
> ifneq ($(GCCGO),)
> ..
> endif
>
> Many programs include versions, build info, date, etc, through linker
> variables. To make it consistent and reproducible I use this:
>
> DEBVERS?= $(shell dpkg-parsechangelog -SVersion)
> VERSION?= $(shell echo '$(DEBVERS)' | sed 's/^[[:digit:]]*://;
> s/[-].*//')
> DEBDATE?= $(shell dpkg-parsechangelog -SDate)
> REV:= $(DEBVERS)
> BRANCH := debian/sid
> USER   := pkg-go-maintainers@lists.alioth.debian.org
> HOSTNAME   := debian
> BUILD_DATE := $(shell date --utc --date='$(DEBDATE)' +%Y%m%d-%H:%M:%S)
> GO_VERSION := $(shell go version | sed 's/go version \(\S*\).*/\1/')
> BUILDFLAGS := -ldflags \
>   " -X $(METAPKG)/version.Version=$(VERSION)\
> -X $(METAPKG)/version.Revision=$(REV)\
> -X $(METAPKG)/version.Branch=$(BRANCH)\
> -X $(METAPKG)/version.BuildUser=$(USER)\
> -X $(METAPKG)/version.BuildDate=$(BUILD_DATE)\
> -X $(METAPKG)/version.GoVersion=$(GO_VERSION)"

What does METAPKG resolve to? We should consider centralizing these
definitions somewhere.


-- 
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] Minutes for the DebConf17 BoF

[Michael Stapelberg]

On Sun, Aug 20, 2017 at 7:05 PM, Martín Ferrari <tin...@tincho.org> wrote:
> On 20/08/17 18:46, Michael Stapelberg wrote:
>
>> Side note, not meant to persuade anyone one way or the other: I just
>> realized why I never saw any appeal in that argument: I find git
>> packaging (or git in general?) too brittle and confusing to keep what
>> I consider are multiple projects in the same repository.
>
> Uhm.. I don't really have that feeling. Could you elaborate more?

I don’t want to derail this thread too much, so I’ll keep it brief:

Regarding repos being brittle: in the past, I’ve often found that when
messing up (e.g. when incorrectly importing a new upstream version, or
doing an incorrect merge of some sort), the easiest way to undo is to
delete the repository and start from scratch.

Regarding multiple projects being confusing: I find the history of git
repositories often not that easy to understand, even though I work
with git daily since over 9 years. When multiple branches are
involved, this becomes even harder. Before running any command in an
upstream-tracking git packaging repo, I need to stop and think about
how this affects the repo as a whole.

Maybe this gets easier over time, but I do like the mental simplicity
of having everything upstream-related nicely contained in a tarball.

>
>> When I need to find out something about upstream repositories, I
>> usually use the GitHub web interface, or my local gopath. I never use
>> the git packaging repos, regardless of whether they have history or
>> not.
>
> Heh, I hate the github web interface, can't compare to gitk, git log, etc :)
>
> Also, I don't even have a go path. To this day I get confused every time
> I try to build things by hand!
>
>
>> git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
>> git config --add remote.origin.push "+refs/tags/*:refs/tags/*"
>
> The problem with this is that you push all tags and branches, even if
> they are coming from upstream (I know, not relevant for you). I try to
> keep the alioth repo free from that.
>
>> But note that gbp recently gained “gbp push”:
>> https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=cbacdfb40ca35633da06e9e05497ac0fb56cc4f9
>> It’s included in 0.9.0~exp2, but I haven’t tried it out yet.
>> Hopefully, it makes both our extra setup steps unnecessary :).
>
> Oh, cool, I should try it!
>
>> Given that you _also_ maintain history in git, using gbp dch seems
>> like significantly cutting down the number of commands. Is there any
>> rationale behind your decision to not use gbp dch, or are you just
>> used to this way? :)
>
> Mostly historical reasons and muscle memory :)
>
>
> --
> 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



-- 
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] Minutes for the DebConf17 BoF

[Michael Stapelberg]

While we’re on the topic:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859867 discusses
making sbuild easier to install/use :)

On Sun, Aug 20, 2017 at 6:56 PM, Martín Ferrari <tin...@tincho.org> wrote:
> On 20/08/17 18:36, Michael Stapelberg wrote:
>> I use gbp with sbuild, and I do see different behavior with/without
>> exporting. Take for example the freeradius repository, where the build
>> fails without git-export-dir: https://paste.debian.net/982241/
>
> I guess the difference is with not having an export option at all, which
> I have never tried..
>
>>>> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
>>>> <https://paste.debian.net/hidden/a48afca2/> (informational)
>>>
>>> Sadly, this has expired
>>
>> Sorry about that. Here’s one that shouldn’t expire:
>> https://paste.debian.net/982242/
>
> Thanks, I like those sbuild options, I am saving this!
>
>
> --
> Martín Ferrari (Tincho)



-- 
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] Bug#862612: RM: golang-github-gosexy-gettext -- ROM; no rdeps, no update since 2013

[Michael Stapelberg]

Package: ftp.debian.org
Severity: normal

Working on Debian bug #860608, I stumbled upon
golang-github-gosexy-gettext. I considered fixing that package, but
realized that it has been last updated in 2013 and has no reverse
dependencies.

As Go libraries are only packaged in Debian to enable packaging Go
programs for Debian, this package is currently useless. Instead of
investing more time and energy into maintaining it, please remove it
from Debian. If it turns out we need it again at some point in the
future, we can always re-upload.

Thanks!

___
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#862608: unblock: golang-github-hashicorp-go-msgpack/0.0~git20150518.0.fa3f638-2

[Michael Stapelberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-github-hashicorp-go-msgpack

This is part of the fix for Debian bug #860608: Go library packages
should not use the Built-Using tag at all, and a few packages are
still referencing a long-removed broken version of the golang package
via a Built-Using tag.

Hence, I uploaded a new version without the tag:

% debdiff 
golang-github-hashicorp-go-msgpack_0.0~git20150518.0.fa3f638-1_amd64.changes 
golang-github-hashicorp-go-msgpack_0.0~git20150518.0.fa3f638-2_amd64.changes
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

[-Built-Using: golang-1.7 (= 1.7.4-2)-]
Version: [-0.0~git20150518.0.fa3f638-1-] {+0.0~git20150518.0.fa3f638-2+}

unblock golang-github-hashicorp-go-msgpack/0.0~git20150518.0.fa3f638-2

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

___
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#862610: unblock: golang-pty/0.0~git20151007.0.f7ee69f-2

[Michael Stapelberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-pty

This is part of the fix for Debian bug #860608: Go library packages
should not use the Built-Using tag at all, and a few packages are
still referencing a long-removed broken version of the golang package
via a Built-Using tag.

Hence, I uploaded a new version without the tag:
% debdiff golang-pty_0.0\~git20151007.0.f7ee69f-1_amd64.changes 
golang-pty_0.0\~git20151007.0.f7ee69f-2_amd64.changes   
   
File lists identical (after any substitutions)

Control files of package golang-github-kr-pty-dev: lines which differ (wdiff 
format)

[-Built-Using: golang-1.7 (= 1.7.4-2)-]
Version: [-0.0~git20151007.0.f7ee69f-1-] {+0.0~git20151007.0.f7ee69f-2+}

Control files of package golang-pty-dev: lines which differ (wdiff format)
--
Version: [-0.0~git20151007.0.f7ee69f-1-] {+0.0~git20151007.0.f7ee69f-2+}

unblock golang-pty/0.0~git20151007.0.f7ee69f-2

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

___
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#862686: unblock: golang-github-armon-go-metrics/0.0~git20160307.0.f303b03-2

[Michael Stapelberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-github-armon-go-metrics

This is part of the fix for Debian bug #860608: Go library packages
should not use the Built-Using tag at all, and a few packages are
still referencing a long-removed broken version of the golang package
via a Built-Using tag.

Hence, I uploaded a new version without the tag:

% debdiff 
golang-github-armon-go-metrics_0.0~git20160307.0.f303b03-1_amd64.changes 
golang-github-armon-go-metrics_0.0~git20160307.0.f303b03-2_amd64.changes
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

[-Built-Using: golang-1.7 (= 1.7.4-2), golang-github-beorn7-perks (= 
0.0~git20160804.0.4c0e845-1), golang-github-datadog-datadog-go (= 
0.0~git20150930.0.b050cd8-2), golang-github-prometheus-client-golang (= 
0.8.0-1), golang-github-prometheus-client-model (= 
0.0.2+git20150212.12.fa8ad6f-2), golang-github-prometheus-common (= 
0+git20161002.85637ea-2), golang-goprotobuf (= 0.0~git20161116.0.224aaba-3), 
golang-procfs (= 0+git20161206.fcdb11c-1), golang-protobuf-extensions (= 
1.0.0-2)-]
Version: [-0.0~git20160307.0.f303b03-1-] {+0.0~git20160307.0.f303b03-2+}


unblock golang-github-armon-go-metrics/0.0~git20160307.0.f303b03-2

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

___
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#839108: Bug#839108: dh-golang: Please document behavior and variables used

[Michael Stapelberg]

On Wed, Jun 21, 2017 at 1:21 AM, Ian Campbell <i...@debian.org> wrote:

> On Wed, 2017-06-21 at 06:28 +0200, Guillem Jover wrote:
> > Hi!
> >
> > On Tue, 2017-06-20 at 09:49:26 +0200, Michael Stapelberg wrote:
> > > > > Guillem Jover <guil...@debian.org> writes:
> > > > Please document at least the variables from the environment that
> > > > directly affect the behavior such as GOPATH, DH_GOPKG,
> > > > DH_GOLANG_INSTALL_ALL, DH_GOLANG_INSTALL_EXTRA, DH_GOLANG_BUILDPKG,
> > > > DH_GOLANG_GO_GENERATE. And the field control field Go-Import-Path.
> > >
> > > What’s the correct place to document them? Stuffing this buildsystem
> > > related documentation into the dh_golang(1) manpage seems
> inappropriate,
> > > as that manpage should only document the dh_golang executable, right?
> >
> > Yeah, that was my initial reaction as well. And I'm not sure where
> > the buildsystem and sequence behavior is supposed to be documented, or
> > whether debhelper maintainers would recommend doing so, so I've CCed
> > them in case they have any input.
> >
> > OTOH, dh_golang(1p) already contains a brief note about the golang
> > buildsystem, so perhaps that man page is not such a bad idea after
> > all? Also because that's the entry point for the command, but yeah
> > as mentioned above I also see why it feels wrong.
>
> Are DH_GOLANG_* not as specific to dh_golang as the name would suggest?
>

They’re specific to the debhelper golang buildsystem
(/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm). Should they be
named differently?


>
> Ian.
>



-- 
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] Bug#822743: dh-golang: should assist in calculating -dev packages Depends:

[Michael Stapelberg]

Hi,

currently going through the bugs of dh-golang.

Is there anything that remains to be done here? If so, could someone
please summarize the discussion and explain what it is?

Thanks!

-- 
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] Bug#839108: dh-golang: Please document behavior and variables used

[Michael Stapelberg]

Hi Guillem,

Thanks for your report!

Guillem Jover  writes:
> Please document at least the variables from the environment that
> directly affect the behavior such as GOPATH, DH_GOPKG,
> DH_GOLANG_INSTALL_ALL, DH_GOLANG_INSTALL_EXTRA, DH_GOLANG_BUILDPKG,
> DH_GOLANG_GO_GENERATE. And the field control field Go-Import-Path.

What’s the correct place to document them? Stuffing this buildsystem
related documentation into the dh_golang(1) manpage seems inappropriate,
as that manpage should only document the dh_golang executable, right?

-- 
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] Bug#822668: Processed: cloning 822386, reassign -1 to dh-golang ..., severity of -1 is important

[Michael Stapelberg]

control: severity -1 wishlist
control: retitle -1 Make dh_golang work without --buildsystem golang

Hi,

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

> On 27 April 2016 at 19:22, Michael Stapelberg <stapelb...@debian.org> wrote:
>> Can you please explain why dh-golang can’t be made to figure out build
>> dependencies in this particular case?
>
> Because nothing in the packaging tells dh-golang anything about the Go
> bits -- it doesn't set DH_GOPKG or Xs-Go-Import-Path or use the golang
> dh buildsystem. I guess we could put back the
> built-using-from-Build-Depends code and use both that *and* the go
> list-using code I added...

So, if I understand correctly, the use-case here was to use only the
dh_golang binary (dh --with golang, responsible for adding the
misc:Built-Using substvar) without the rest of the debhelper golang
build system (dh --buildsystem golang).

The dh_golang binary currently overwrites GOPATH (by calling
load_buildsystem("golang")->_set_gopath()), then runs 'go list' to find
all packages, then proceeds to construct a Built-Using substvar.

We could introduce an environment variable which overrides the packages,
so that dh_golang can be used without --buildsystem golang (retitled the
bug accordingly).

Since knot-resolver does not contain any Go modules anymore (tinyweb has
been superseded by the HTTP/2 module as per the debian/changelog), I’ll
not spend any time on this theoretical exercise.

If anyone else has the same use-case and would actually like to see this
issue resolved, please speak up.

-- 
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] Bug#841074: dh-golang: Do not emit misc:Built-Using substvar for arch:all packages

[Michael Stapelberg]

control: tags -1 pending

Hi Guillem,

Guillem Jover  writes:
> This helper generates a misc:Built-Using substvar for all involved
> packages, but that seems wrong for packages that do not statically
> embed any Go modules when building, in case they are -dev packages
> that just include Go source code.
>
> Attached a patch that does that. Or is there any arch:all package
> which ends up embedding other modules, which would make this
> assumption wrong?

Sounds good, applied the patch.

-- 
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] Bug#876106: lists.debian.org: please create debian-go mailing list

[Michael Stapelberg]

Package: lists.debian.org
Severity: wishlist

Name: debian-go
Rationale: replacement for our current list on alioth
Category: Developers
Subscription Policy: open
Post Policy: open
Web Archive: yes
Short description: Debian Go Packaging Team
Long description:
We, the Debian Go Packaging Team, coordinate about packaging software and their
libraries written in the Go programming language.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

___
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#839108: Bug#839108: dh-golang: Please document behavior and variables used

[Michael Stapelberg]

Thanks for the hint, I wasn’t aware of that! I’ll document the
variables and upload a new version.

On Sat, Sep 23, 2017 at 12:08 PM, Shengjing Zhu <i...@zhsj.me> wrote:
> On Tue, 20 Jun 2017 09:49:26 +0200 Michael Stapelberg
> <stapelb...@debian.org> wrote:
>> Hi Guillem,
>>
>> Thanks for your report!
>>
>> Guillem Jover <guil...@debian.org> writes:
>> > Please document at least the variables from the environment that
>> > directly affect the behavior such as GOPATH, DH_GOPKG,
>> > DH_GOLANG_INSTALL_ALL, DH_GOLANG_INSTALL_EXTRA, DH_GOLANG_BUILDPKG,
>> > DH_GOLANG_GO_GENERATE. And the field control field Go-Import-Path.
>>
>> What’s the correct place to document them? Stuffing this buildsystem
>> related documentation into the dh_golang(1) manpage seems inappropriate,
>> as that manpage should only document the dh_golang executable, right?
>
> Add to man 3 Debian::Debhelper::Buildsystem::golang?
>
> If you add the docs to lib/Debian/Debhelper/Buildsystem/golang.pm, the
> auto generated manpage is
> man3/Debian::Debhelper::Buildsystem::golang.3pm.gz
>
> --
> Best regards,
> Shengjing Zhu
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
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] Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Michael Stapelberg]

Almost a month has passed. What’s the current status? The pkg-go group
is still eagerly waiting for this. If there is any way we can help,
please let us know.

On Mon, Sep 18, 2017 at 3:04 AM, Osamu Aoki  wrote:
> Hi,
>
> On Mon, Sep 18, 2017 at 01:20:22PM +0800, Shengjing Zhu wrote:
>> Hi,
>>
>> I want to know if it's still possible to support GitHub's commit via
>> different way, rather than do a `git clone`.
>>
>> I find GitHub has RSS feed for the commit, the url is like
>> https://github.com/Debian/dh-make-golang/commits/master.atom
>> So uscan can parse that xml feed, and get the commit data, id, and
>> finally forms the download link like
>> https://github.com/Debian/dh-make-golang/archive/71736daa55a06e466cdcc6c0347f5b9489471fe3.tar.gz,
>> and the version is 0.0~git.
>> Besides, the RSS feed url is not an API url, and will not have the API
>> rate problem.
>
> Good.
>
>> That's simpler than doing `git clone` locally, though the shortage is
>> site specific.
>> BTW, gitlab also provides such feed, the url format is like
>> https://gitlab.com/inkscape/inkscape/commits/master?format=atom
>
> I have been busy with other higher priority issues with devscripts
> lately.
>
> There are two types of git archives.  I don't want to make unorganized
> addition.  Please let me have some time on this.  It is living in my
> private git now.
>
> Osamu



-- 
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] [PATCH] dakweb: add /golang/import_paths query

[Michael Stapelberg]

Please keep me CC'ed, I’m not subscribed to debian-dak.

Please consider merging the following patch which you can find
attached to this email or at
https://github.com/stapelberg/dak/tree/golang. Thank you!

This query will replace a heuristic in dh-make-golang(1) and help us resolve
Go build dependencies into Debian build dependencies accurately.
---
 dakweb/dakwebserver.py   |  1 +
 dakweb/queries/golang.py | 52 
 2 files changed, 53 insertions(+)
 create mode 100644 dakweb/queries/golang.py

diff --git a/dakweb/dakwebserver.py b/dakweb/dakwebserver.py
index 0ddc10cf..bd6b62ff 100755
--- a/dakweb/dakwebserver.py
+++ b/dakweb/dakwebserver.py
@@ -45,6 +45,7 @@ from queries.archive import *
 from queries.madison import *
 from queries.source import *
 from queries.suite import *
+from queries.golang import *

 # Set up our initial database connection
 d = DBConn()
diff --git a/dakweb/queries/golang.py b/dakweb/queries/golang.py
new file mode 100644
index ..0c343424
--- /dev/null
+++ b/dakweb/queries/golang.py
@@ -0,0 +1,52 @@
+"""Golang related queries
+
+@contact: https://pkg-go.alioth.debian.org/
+@copyright: 2017 Michael Stapelberg <stapelb...@debian.org>
+@license: GNU General Public License version 2 or later
+"""
+
+import bottle
+import json
+
+from daklib.dbconn import DBConn, MetadataKey
+from dakweb.webregister import QueryRegister
+
+
+@bottle.route('/golang/import_paths')
+def import_paths():
+"""
+Returns a mapping of Go import path to Debian binary package name and
+corresponding Debian source package name.
+
+@rtype: dictionary
+@return: A list of dictionaries of
+ - binary
+ - source
+ - importpath
+"""
+
+s = DBConn().session()
+conn = s.connection()
+res = conn.execute("""
+SELECT
+binaries.package,
+source.source,
+source_metadata.value AS importpath
+FROM
+binaries LEFT JOIN
+source ON (binaries.source = source.id) LEFT JOIN
+source_metadata ON (source.id = source_metadata.src_id) LEFT JOIN
+metadata_keys ON (source_metadata.key_id = metadata_keys.key_id)
+WHERE
+metadata_keys.key = 'Go-Import-Path'
+GROUP BY
+binaries.package,
+source.source,
+source_metadata.value;
+""")
+out = [{'binary': res[0], 'source': res[1], 'importpath': res[2]}
for res in res]
+s.close()
+
+return json.dumps(out)
+
+QueryRegister().register_path('/golang/import_paths', import_paths)
-- 
2.14.2
From 50470f6ba177058fbc77a6652c5883322f78c4fb Mon Sep 17 00:00:00 2001
From: Michael Stapelberg <stapelb...@debian.org>
Date: Sun, 22 Oct 2017 18:32:04 +0200
Subject: [PATCH] dakweb: add /golang/import_paths query

This query will replace a heuristic in dh-make-golang(1) and help us resolve
Go build dependencies into Debian build dependencies accurately.
---
 dakweb/dakwebserver.py   |  1 +
 dakweb/queries/golang.py | 52 
 2 files changed, 53 insertions(+)
 create mode 100644 dakweb/queries/golang.py

diff --git a/dakweb/dakwebserver.py b/dakweb/dakwebserver.py
index 0ddc10cf..bd6b62ff 100755
--- a/dakweb/dakwebserver.py
+++ b/dakweb/dakwebserver.py
@@ -45,6 +45,7 @@ from queries.archive import *
 from queries.madison import *
 from queries.source import *
 from queries.suite import *
+from queries.golang import *
 
 # Set up our initial database connection
 d = DBConn()
diff --git a/dakweb/queries/golang.py b/dakweb/queries/golang.py
new file mode 100644
index ..0c343424
--- /dev/null
+++ b/dakweb/queries/golang.py
@@ -0,0 +1,52 @@
+"""Golang related queries
+
+@contact: https://pkg-go.alioth.debian.org/
+@copyright: 2017 Michael Stapelberg <stapelb...@debian.org>
+@license: GNU General Public License version 2 or later
+"""
+
+import bottle
+import json
+
+from daklib.dbconn import DBConn, MetadataKey
+from dakweb.webregister import QueryRegister
+
+
+@bottle.route('/golang/import_paths')
+def import_paths():
+"""
+Returns a mapping of Go import path to Debian binary package name and
+corresponding Debian source package name.
+
+@rtype: dictionary
+@return: A list of dictionaries of
+ - binary
+ - source
+ - importpath
+"""
+
+s = DBConn().session()
+conn = s.connection()
+res = conn.execute("""
+SELECT
+binaries.package,
+source.source,
+source_metadata.value AS importpath
+FROM
+binaries LEFT JOIN
+source ON (binaries.source = source.id) LEFT JOIN
+source_metadata ON (source.id = source_metadata.src_id) LEFT JOIN
+metadata_keys ON (source_metadata.key_id = metadata_keys.key_id)
+WHERE
+metadat

[pkg-go] Bug#879550: ITP: golang-github-russellhaering-goxmldsig -- Pure Go implementation of XML Digital Signatures

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-github-russellhaering-goxmldsig
  Version : 0.0~git20170911.b7efc62-1
  Upstream Author : Russell Haering
* URL : https://github.com/russellhaering/goxmldsig
* License : Apache-2.0
  Programming Lang: Go
  Description : Pure Go implementation of XML Digital Signatures

 XML Digital Signatures implemented in pure Go.

This is a build dependency of dex.

___
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#879547: ITP: golang-github-cockroachdb-cockroach-go -- Packages for go clients.

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-github-cockroachdb-cockroach-go
  Version : 0.0~git20170808.c806b48-1
  Upstream Author : CockroachDB
* URL : https://github.com/cockroachdb/cockroach-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Packages for go clients.

 testing Testing helpers for cockroach clients.

This is a build dependency for dex.

___
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#879549: ITP: golang-github-beevik-etree -- parse and generate XML easily in go

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg <stapelb...@debian.org>

* Package name: golang-github-beevik-etree
  Version : 1.0.0+git20171015.af219c0-1
  Upstream Author : Brett Vickers
* URL : https://github.com/beevik/etree
* License : BSD-2-clause
  Programming Lang: Go
  Description : parse and generate XML easily in go

 The etree package is a lightweight, pure go package that expresses XML in the
 form of an element tree. Its design was inspired by the Python ElementTree
 (http://docs.python.org/2/library/xml.etree.elementtree.html) module.

This is a build dependency of dex.

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