[pkg-go] Bug#819638: Bug#819638: golang-github-armon-gomdb: FTBFS: panic: runtime error: cgo argument has Go pointer to Go pointer
On 6 Apr 2016, at 4:07 PM, Potter, Tim (HPE Linux Support) wrote: > > On 31 Mar 2016, at 11:14 PM, Chris Lamb wrote: > > [...] > >>dh_auto_test -O--buildsystem=golang >> go test -v github.com/armon/gomdb >> === RUN TestEnvOpen >> --- PASS: TestEnvOpen (0.00s) >> === RUN TestEnvCopy >> --- PASS: TestEnvCopy (0.00s) >> env_test.go:67: Env path: /tmp/mdb_test840057194 >> === RUN TestTest1 >> --- FAIL: TestTest1 (0.00s) >> panic: runtime error: cgo argument has Go pointer to Go pointer [recovered] >> panic: runtime error: cgo argument has Go pointer to Go pointer > > This appears to be something to do with how cgo rewrites calls to C functions > in Go 1.6: > > https://github.com/golang/go/issues/14210 See also the comments here: https://github.com/hashicorp/consul-migrate/issues/1 Tim. signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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#819638: Bug#819638: golang-github-armon-gomdb: FTBFS: panic: runtime error: cgo argument has Go pointer to Go pointer
On 31 Mar 2016, at 11:14 PM, Chris Lamb wrote: [...] > dh_auto_test -O--buildsystem=golang > go test -v github.com/armon/gomdb > === RUN TestEnvOpen > --- PASS: TestEnvOpen (0.00s) > === RUN TestEnvCopy > --- PASS: TestEnvCopy (0.00s) > env_test.go:67: Env path: /tmp/mdb_test840057194 > === RUN TestTest1 > --- FAIL: TestTest1 (0.00s) > panic: runtime error: cgo argument has Go pointer to Go pointer [recovered] > panic: runtime error: cgo argument has Go pointer to Go pointer This appears to be something to do with how cgo rewrites calls to C functions in Go 1.6: https://github.com/golang/go/issues/14210 I don't fully understand it yet but hopefully I can figure out a fix shortly. A bigger problem is that now this package could only be runnable under one of Go 1.5 or Go 1.6. Tim. signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] golang-github-digitalocean-godo is marked for autoremoval from testing
golang-github-digitalocean-godo 0.9.0-1 is marked for autoremoval from testing on 2016-04-29 It (build-)depends on packages with these RC bugs: 789991: golang-gocheck: FTBFS: Test failures including FixtureS.TestPanicOnSetUpSuite, FixtureS.TestPanicOnSetUpTest ___ 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] golang-yaml.v2_0.0+git20160301.0.a83829b-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 05 Apr 2016 18:59:30 -0400 Source: golang-yaml.v2 Binary: golang-yaml.v2-dev Architecture: source all Version: 0.0+git20160301.0.a83829b-1 Distribution: unstable Urgency: medium Maintainer: Debian Go Packaging Team Changed-By: Tim Potter Description: golang-yaml.v2-dev - YAML support for the Go language Changes: golang-yaml.v2 (0.0+git20160301.0.a83829b-1) unstable; urgency=medium . * Update to latest upstream commit to pull in fixes for golang-1.6 * Upgrade to latest standards version in d/control Checksums-Sha1: e9083651995c051ec05fcfb17758ee971dd649bf 2229 golang-yaml.v2_0.0+git20160301.0.a83829b-1.dsc 492276a02d9f448e579acb244d169296f9b2d39e 52916 golang-yaml.v2_0.0+git20160301.0.a83829b.orig.tar.xz 1ab3e7a890d9b3f3b56117257e820d3e53360dd1 3116 golang-yaml.v2_0.0+git20160301.0.a83829b-1.debian.tar.xz 7f1c576840a5409efee1c131e87ecefc0f336f0c 52292 golang-yaml.v2-dev_0.0+git20160301.0.a83829b-1_all.deb Checksums-Sha256: 8afa9b25b6f7701c298c1d292dd35abc8ba36fe55eab5f708269c2928b814b57 2229 golang-yaml.v2_0.0+git20160301.0.a83829b-1.dsc be8a3f1cc18b709fb47650ac43697ce0e32d57d766c205c6f3de2afc5f926b80 52916 golang-yaml.v2_0.0+git20160301.0.a83829b.orig.tar.xz 9ee5c902b32f6dc559d6c8b82557a2c0c91a5b7ba8a4f4d5e023df0a02331d47 3116 golang-yaml.v2_0.0+git20160301.0.a83829b-1.debian.tar.xz 2ce11c71569c7aa2344be4be7f382d80ca64472f25e11e0020bae072e55a4ad1 52292 golang-yaml.v2-dev_0.0+git20160301.0.a83829b-1_all.deb Files: 9f81946520e013ad4b263117b236ae73 2229 devel extra golang-yaml.v2_0.0+git20160301.0.a83829b-1.dsc 55f847ed13b4f0be1c0ee780df65fabc 52916 devel extra golang-yaml.v2_0.0+git20160301.0.a83829b.orig.tar.xz 253e2ffb095cef2cf6c1dcb3f32ef19e 3116 devel extra golang-yaml.v2_0.0+git20160301.0.a83829b-1.debian.tar.xz 6cbd8349a17bb505f5397cea84235f99 52292 devel extra golang-yaml.v2-dev_0.0+git20160301.0.a83829b-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXBHTlAAoJEHtYWzCAfCqH60AP/2c5olVAsaFSlNgH3e+YkP0s tfH2O3nwJjsU6p0N99tVW3rh6DLBXOikV8JHN1tvbSx3R9csi/dE1ddI/JZkjO2P JzSugjKkbwVWFHCqCp/eOOccYPhiQKa86H8Ez2Eiu6YbHrOJXLvtpygc8V9fZxsA viRe1n8B5YJc3/A0CZ4PippIeqrNLIX3FYO76794u7++LB3W3HcTOP2A0zbzTWeq BaXdzm17Dw0GQAOLYUiFoXbCXPE6ztmoRcMQyGVayHuXzOhSDdobVfoW0o0fXpt+ ZUQhfdd5fCA+dJxeF/AyoilZdGdQ58Cpr/1IrJMIz8dijA3dn5eLEonS//j4jP7w mpNFKymup87x4DJLruiygfXAhRl9f2ra5xTJ7erdQVuwPvcSv7M3jqV0N6ckigap S7EYAIVF0RCuDtTEbblTybONiPi9PdIXvVVZ/Z2vRJWydaGTc4kLulG1BO7+fmjN HvFPy7WQXekHAf5vGuufAzQbmOng0P0AmGVM/IP6Xp2LSfKHhI5lAugJlWSmuZgG Bs/QyI+J+2tZogcZ7hbc+SSHGfFuE9BzAxoqYFucBynALlz9YSj+hYBdh3gqlohh KTW7vTwwtDbwrbYNPrtqNJwIkl+y6kUh37+Sc3ZAxgrkR5WdQH6NzygYPbvnakey RF4xgkoo/oslfQQTuA6B =1ip4 -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ 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] etcd_2.3.1+dfsg-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 06 Apr 2016 12:40:12 +1000 Source: etcd Binary: etcd golang-etcd-server-dev Architecture: source amd64 all Version: 2.3.1+dfsg-1 Distribution: unstable Urgency: medium Maintainer: pkg-go Changed-By: Dmitry Smirnov Description: etcd - highly-available key value store -- daemon golang-etcd-server-dev - highly-available key value store -- source Changes: etcd (2.3.1+dfsg-1) unstable; urgency=medium . * New upstream release [April 2016]. * Removed obsolete "rakyll2cheggaaa.patch". * Standards-Version: 3.9.7. * Fix "readlink" invocation in the init.d script. * rules: correction to build with gogoprotobuf 0.2. * Build-Depends: - golang-etcd-dev | golang-github-coreos-go-etcd-dev + golang-github-bgentry-speakeasy-dev + golang-github-codegangsta-cli-dev (>= 0.0~git20151221~) + golang-github-coreos-gexpect-dev + golang-github-gogo-protobuf-dev (>= 0.2~) + gogoprotobuf + golang-github-mattn-go-runewidth-dev + golang-github-olekukonko-tablewriter-dev + golang-github-xiang90-probing-dev Checksums-Sha1: 128c9974474d0bad72bdffbc6cf31b9ba15700ab 3812 etcd_2.3.1+dfsg-1.dsc e8cf0aee3c0e100fde8cb8a1ff409407a8dfab6f 553264 etcd_2.3.1+dfsg.orig.tar.xz 36f779e46850c7cf8c16dc90128d82779d253084 12272 etcd_2.3.1+dfsg-1.debian.tar.xz e3f3f3722f1350ef7a05bead06c8e7232b3bb642 1482916 etcd-dbgsym_2.3.1+dfsg-1_amd64.deb d3fef01106fe3eed7d27240c6da3546f5423ca44 5801440 etcd_2.3.1+dfsg-1_amd64.deb 54497678032e9843cf93528575abdb788f432128 437910 golang-etcd-server-dev_2.3.1+dfsg-1_all.deb Checksums-Sha256: 7668e490be8c595f98899e205873f335212392741d8ce9d70460c5b9b7671145 3812 etcd_2.3.1+dfsg-1.dsc 23f8e3e2899b5d5d70059669135f37592abadea6353728565e85becaa8d5ca84 553264 etcd_2.3.1+dfsg.orig.tar.xz d2a36010b8b291d122ed3b3b3bfc923099002615a47f377f36633ca0a5ef11b6 12272 etcd_2.3.1+dfsg-1.debian.tar.xz c60b13aafa9aac9f29490089aa7660b9b6ceaf55d8147c9981998218aa559050 1482916 etcd-dbgsym_2.3.1+dfsg-1_amd64.deb cad6fbd3551f49a9712ac512ace1d25aea4ed78c4669fb8d6f3c57b414c4f6c0 5801440 etcd_2.3.1+dfsg-1_amd64.deb c5f0679dee1bc578f513aba907f861097786a71093c3b15fa1a48a3cacc9a267 437910 golang-etcd-server-dev_2.3.1+dfsg-1_all.deb Files: dd1b1218656a6c0ac0b805b81bab11e5 3812 devel extra etcd_2.3.1+dfsg-1.dsc c3f2166ac17063b64125dbc073a13a61 553264 devel extra etcd_2.3.1+dfsg.orig.tar.xz 5a93a546804734468e0d9f512517996e 12272 devel extra etcd_2.3.1+dfsg-1.debian.tar.xz f3f8dc51cab8bd681e0ad1baaa839902 1482916 debug extra etcd-dbgsym_2.3.1+dfsg-1_amd64.deb 0edf532d33922fd83c0d41370b828792 5801440 devel extra etcd_2.3.1+dfsg-1_amd64.deb 407e4084ff2797597bf6a36937a2dbd7 437910 devel extra golang-etcd-server-dev_2.3.1+dfsg-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXBH8bAAoJEFK2u9lTlo0bLGAP/3kPDoqfnAmqfe/ZC4DlhY2I GUKh4BskXhUpwj7j0B4Eh7N+WWGBUzIGoRM9RtgGaU7X43EU+/tgY07rK8m3zZTJ g2WfEVbHXcMRougc/XlDDEXb9i63h5uAu4+26NYqjLO3esVlZBZPQD4A3fvH3imQ aA7g+HMo9WJiJPEwEHij9sm1iyXeYSB5IA9Ga9+M+ss/T/J4wShOR49CSX2kWWdr lFxqAlNjU5FB9m12+SKEJX5ErTA06NzjZ7BfHr0drdMGVN3Aa7XzOXtVRCEZx8m6 SFYRe9pecYEgx0TH4QVLXta9rFTy6RgpOAqjAf91lbIm4BGAYiBGXHu+p4zkf2aU XnMojfl8X9tS4XIAOxjYUih4ohyw1PN0xa5Sk4PHx56e4i0VzRSYneiQFFPhlOs4 GOatyJ16PUnxqizP/jycmyc8O6BDhVB6e3bFQ8+vq3iAXqKZ0kclsSw20MCuj+b1 GVp3MkcfYZvccevIwMPuMbNhLkOozshYV7z1dAeslAwBltv/jDVxGAYqqrt/b1NL n1YBVyUzYAwqyq/1Uo/B3heK+4kjOwpaNoSoz2Vx3/1M31McFqtfTaxjN7sUxwCL Wg8RE0LTz1ifQKEvlTqg58JpPqsJ6b3dPWOOYWNz0olg8wPuvXajtZmgpSk8pxJG szPYuRuUvMh+/F5DeeYI =Ybo+ -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ 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] Processing of etcd_2.3.1+dfsg-1_amd64.changes
etcd_2.3.1+dfsg-1_amd64.changes uploaded successfully to localhost along with the files: etcd_2.3.1+dfsg-1.dsc etcd_2.3.1+dfsg.orig.tar.xz etcd_2.3.1+dfsg-1.debian.tar.xz etcd-dbgsym_2.3.1+dfsg-1_amd64.deb etcd_2.3.1+dfsg-1_amd64.deb golang-etcd-server-dev_2.3.1+dfsg-1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
On Tuesday, 5 April 2016 10:41:04 PM AEST Paul Tagliamonte wrote: > | Backports are packages taken from the next Debian release (called > | "testing"), adjusted and recompiled for usage on Debian stable. > > So my confusion here is that you don't want to see them in Stable, but > you do want to see them in testing (and backports). This isn't what > testing is for, of course :) I'm not comfortable with this idea. It requires a lot more work as well. I just entertain possibility if we have to drop golang apps from next stable. After all even if not in next stable we might have some good ideas for next stable+1... > I don't see anything inherent about Go that makes it unsupportable. You are certainly more optimistic than I am. :) > I *do* see more software being developed in a way that makes it nearly > impossible for Debian to distribute. But I'm not talking about distribution. We can distribute but security support is very difficult. Maybe we should just give up on it... > This, however, is a much bigger conversation. True... -- Regards, Dmitry Smirnov. --- Lies are the social equivalent of toxic waste: Everyone is potentially harmed by their spread. -- Sam Harris signature.asc Description: This is a digitally signed message part. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
On Wed, Apr 06, 2016 at 12:37:10PM +1000, Dmitry Smirnov wrote: > I feel your pain. Over last 9 months I've invested even greater effort to > packaging of containers related Golang software. > > Yet we can provide anything we want to users of stable releases through > official backports: > > http://backports.debian.org/ | Backports are packages taken from the next Debian release (called | "testing"), adjusted and recompiled for usage on Debian stable. So my confusion here is that you don't want to see them in Stable, but you do want to see them in testing (and backports). This isn't what testing is for, of course :) This, to me, feels like more of a systemic issue than this small side conversation. I don't see anything inherent about Go that makes it unsupportable. I *do* see more software being developed in a way that makes it nearly impossible for Debian to distribute. This, however, is a much bigger conversation. Cheers, Paul signature.asc Description: PGP signature ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
On Tuesday, 5 April 2016 10:08:04 PM AEST Peter Colberg wrote: > On Wed, Apr 06, 2016 at 09:24:20AM +1000, Dmitry Smirnov wrote: > > Unless we can exclude Golang from security support I think we should not > > ship any Golang applications with next stable release. > > I really hope not, that would be a real shame. I know. :( > All the work that we did together on acmetool (#817091) would have > been for nothing. Nope. Even installing manually from "testing" provides significant advantages and added value comparing to installing from outside of Debian repositories. > The only reason I went through the trouble of > packaging all these Go modules is to have acmetool in the stretch > release so it can be used on stable servers. I feel your pain. Over last 9 months I've invested even greater effort to packaging of containers related Golang software. Yet we can provide anything we want to users of stable releases through official backports: http://backports.debian.org/ -- Regards, Dmitry Smirnov. --- The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part. ___ 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] Processing of golang-yaml.v2_0.0+git20160301.0.a83829b-1_amd64.changes
golang-yaml.v2_0.0+git20160301.0.a83829b-1_amd64.changes uploaded successfully to localhost along with the files: golang-yaml.v2_0.0+git20160301.0.a83829b-1.dsc golang-yaml.v2_0.0+git20160301.0.a83829b.orig.tar.xz golang-yaml.v2_0.0+git20160301.0.a83829b-1.debian.tar.xz golang-yaml.v2-dev_0.0+git20160301.0.a83829b-1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] RFS: update to golang-github-davecgh-go-spew package
I've updated this package to the latest version to pull in new features and fixed tests. A review and upload would be much appreciated! Thanks, Tim. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
On Wed, Apr 06, 2016 at 09:24:20AM +1000, Dmitry Smirnov wrote: > Unless we can exclude Golang from security support I think we should not ship > any Golang applications with next stable release. I really hope not, that would be a real shame. All the work that we did together on acmetool (#817091) would have been for nothing. The only reason I went through the trouble of packaging all these Go modules is to have acmetool in the stretch release so it can be used on stable servers. Peter ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
On Tuesday, 5 April 2016 8:06:32 PM AEST Paul Tagliamonte wrote: > But you see, that's not my point. Really, in reality, *semantically*, > we're shipping a release *less than* 0.0. To say we're shipping something > semantically *newer* 0.0 is wrong. ~ means before, like an RC. + means > after, like fixing a broken already uploaded non-free release to main > with +dfsg. What you are saying about semantic significance of '~' and '+' makes sense. But I'm thinking about slightly different example. Suppose we have upstream releases "1.0" and "1.1-rc1" (tagged or just to be tagged). Debian package can express version greater than 1.0 as something like "1.0+git20150505" or as "1.1~git20150505" (assuming that "1.1~rc1" is not tagged upstream). Both versions express idea of version somwhere in between 1.0 and 1.1. Neither version is "wrong". Both approaches are (more or less) equally correct. When upstream have no higher version tagged using "1.0+" appears to be more appropriate. When there are no tags whatsoever I tend to agree that "0~" seems to be better that "0+" but I don't have a strong preference. I hope that difference between "~" and "+" in version numbers make sence in context but not as an absolute thing. > Anyway, I realize you don't like this because it doesn't git tag right, > but I'm going to keep saying + is less correct than ~. You'll likely > have to live with this fact of life. No worries. :) > I hope you can empathize with my love of expressing things semantically, > and I hope you can also understand this wasn't me going around claiming > anyone is a bad developer for doing this. Understood. I want to make it clear that I've never implied bad intentions on your side. I merely feel that calling a legitimate (but perhaps not ideal) versioning scheme as "wrong" is too strong. > I *am* saying it's semantically wrong, and I'll continue to complain about > this by bitching to the list once in a while. I have no problem with that. :) -- Regards, Dmitry Smirnov. --- "All government, of course, is against liberty. -- H. L. Mencken signature.asc Description: This is a digitally signed message part. ___ 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-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
On Wed, Apr 06, 2016 at 09:52:57AM +1000, Dmitry Smirnov wrote:
> Change as simple as 's{~}{+}' should fix it. :)
"fix". I'm aware of how to make dak accept it and make it sort above it
using the dpkg version compare. Thanks for that tip, Dmitry.
> > I wonder what happens when they release version 0.0, now.
>
> If ever. ;)
But you see, that's not my point. Really, in reality, *semantically*,
we're shipping a release *less than* 0.0. To say we're shipping something
semantically *newer* 0.0 is wrong. ~ means before, like an RC. + means
after, like fixing a broken already uploaded non-free release to main
with +dfsg.
Anyway, I realize you don't like this because it doesn't git tag right,
but I'm going to keep saying + is less correct than ~. You'll likely
have to live with this fact of life.
I hope you can empathize with my love of expressing things semantically,
and I hope you can also understand this wasn't me going around claiming
anyone is a bad developer for doing this.
I *am* saying it's semantically wrong, and I'll continue to complain about
this by bitching to the list once in a while.
Paul
signature.asc
Description: PGP signature
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
On Tuesday, 5 April 2016 7:44:22 PM AEST Paul Tagliamonte wrote:
> The version in sid is funny, and we need to break our version to sort
> greater than.
Change as simple as 's{~}{+}' should fix it. :)
> I wonder what happens when they release version 0.0, now.
If ever. ;)
> 1:0.0, I guess.
As an option. Or we could ask upstream to tag 0.0.1 (or 0.1.0 or 1.0.0) as
they might naturally do if they choose to use semantic versioning.
--
Cheers,
Dmitry Smirnov.
---
Sometimes people don't want to hear the truth because they don't want their
illusions destroyed.
-- Friedrich Nietzsche
signature.asc
Description: This is a digitally signed message part.
___
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-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
On Wed, Apr 06, 2016 at 09:42:11AM +1000, Dmitry Smirnov wrote: > On Tuesday, 5 April 2016 7:24:45 PM AEST Paul Tagliamonte wrote: > > Sigh. Someone uploaded a version that's silly. We'll have to damage this > > package accordingly. > > There is no need to blame for that. I feel that "damage" is too strong to > describe change in versioning scheme. Mistake is minor and easy to correct. > No harm is done. I didn't blame anyone. I didn't even look up the last uploader. Hell, I uploaded it, if there's blame, it's on me. The version in sid is funny, and we need to break our version to sort greater than. I wonder what happens when they release version 0.0, now. 1:0.0, I guess. Cheers, Paul signature.asc Description: PGP signature ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
On Tuesday, 5 April 2016 7:24:45 PM AEST Paul Tagliamonte wrote: > Sigh. Someone uploaded a version that's silly. We'll have to damage this > package accordingly. There is no need to blame for that. I feel that "damage" is too strong to describe change in versioning scheme. Mistake is minor and easy to correct. No harm is done. -- Cheers, Dmitry Smirnov. --- It has been said that democracy is the worst form of government except all the others that have been tried. -- Winston Churchill signature.asc Description: This is a digitally signed message part. ___ 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-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
Wrong email, re-sending -- Forwarded message -- From: Paul Tagliamonte To: Cc: Debian Go Packaging Team , Tim Potter , paul...@debian.org Date: Tue, 5 Apr 2016 19:21:16 -0400 Subject: Re: golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED On Tue, Apr 05, 2016 at 11:19:57PM +, Debian FTP Masters wrote: > Version check failed: > Your upload included the source package golang-yaml.v2, version > 0.0~git20160301.0.a83829b-1, > however testing already has version 0.0+git20150627.7ad95dd-1. > Uploads to unstable must have a higher version than present in testing. Sigh. Someone uploaded a version that's silly. We'll have to damage this package accordingly. Paul signature.asc Description: PGP signature ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
On Tuesday, 5 April 2016 9:27:27 AM AEST Florian Weimer wrote: > we need to discuss how we can support applications written in Go for > stretch. > > The most radical approach would be not to ship any Go applications in > stretch, only the basic Go language implementations. This is probably > not desirable. Alternatively we could explicitly disclaim security support for Golang applications. IMHO Golang community abused almost as much as possible with static linking, embedding resources to executables, not using versioning and breaking API at any time, etc. Even if we find effective technical solution to detect dependency chains there is a problem of re-building ever growing number of all packages indirectly depending on vulnerable package. Golang is just too young, unstable and fragile. I have a feeling that few upstream projects take security concerns seriously. Many upstream projects have no concept of "stable" releases so I doubt it is practical to offer any kind of security support for Golang when too many projects introduce new dependencies with almost every new versioned release while old release is abandoned as soon as new one becomes available. Unless we can exclude Golang from security support I think we should not ship any Golang applications with next stable release. Unfortunately if we exclude Golang binaries from release Debian will not be competitive in the enterprise sector: industry is rapidly developing Golang tools for container solutions and they are crucial for Debian success. To some extent we can compensate for absence of Golang binaries in stable release if we continue developing in "testing" and make selected apps available through stretch-backports suite. > One approach would be to ship applications as source code only (just > like libraries), and compile them locally upon installation. This is > what Emacs and Common Lisp implementations already do. With the > growth of Go compilation and link times, this seems less and less > attractive, though. This is a possible solution but with Golang it is not practical as building some packages takes too much time and resources. Also we still need to build packages on build servers to have tests coverage and build logs. Unfortunately shipping Golang applications in sources only (no binaries) is not an option... -- All the best, Dmitry Smirnov. --- Good luck happens when preparedness meets opportunity. signature.asc Description: This is a digitally signed message part. ___ 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] golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes REJECTED
Version check failed: Your upload included the source package golang-yaml.v2, version 0.0~git20160301.0.a83829b-1, however testing already has version 0.0+git20150627.7ad95dd-1. Uploads to unstable must have a higher version than present in testing. === 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. ___ 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] Processing of golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes
golang-yaml.v2_0.0~git20160301.0.a83829b-1_amd64.changes uploaded successfully to localhost along with the files: golang-yaml.v2_0.0~git20160301.0.a83829b-1.dsc golang-yaml.v2_0.0~git20160301.0.a83829b.orig.tar.xz golang-yaml.v2_0.0~git20160301.0.a83829b-1.debian.tar.xz golang-yaml.v2-dev_0.0~git20160301.0.a83829b-1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
https://sources.debian.net/src/dh-golang/1.12/script/dh_golang/#L121
is where Built-Using is added (generated from the code above that
line)
https://sources.debian.net/src/dh-golang/1.12/lib/Debian/Debhelper/Buildsystem/golang.pm/#L144
is where dh-golang currently invokes "go list" (on "DH_GOPKG/..."
which is set from XS-Go-Import-Path or "DH_GOLANG_BUILDPKG" which is
set in d/rules)
http://dave.cheney.net/2014/09/14/go-list-your-swiss-army-knife is a
good overview of what "go list" is capable of ("Who depends on what?"
is the interesting section which talks about -f '{{ .Imports }}' and
-f '{{ .Deps }}')
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
On 5 April 2016 at 15:05, Paul Tagliamonte wrote:
> Love this idea, I wonder if the Import-Path XS header could help resolve
> packages in a proof of concept
>
> On Apr 5, 2016 5:54 PM, "Tianon Gravi" wrote:
>>
>> On 5 April 2016 at 14:47, Florian Weimer wrote:
>> > We currently need these intermediate dependencies to discover all the
>> > affected applications. So perhaps dh_golang needs to construct the
>> > transitive closure, instead of listing just immediate build
>> > dependencies. If we don't want to put this information into the
>> > Packages file, maybe we can keep it in the separate debuginfo
>> > packages.
>>
>> It _should_ be possible to adjust dh_golang to use "go list" in order
>> to determine the exact full set of Go packages which the application
>> code depends on, and then use _that_ list to cross-reference the files
>> in /usr/share/gocode to get the real list of packages for Built-Using
>> ( haven't verified whether it's feasible for dh_golang to do this, but
>> it's pretty similar to how it's currently using "go list" to gather
>> the list of packages to actually build).
>>
>> ♥,
>> - 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
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
Love this idea, I wonder if the Import-Path XS header could help resolve packages in a proof of concept On Apr 5, 2016 5:54 PM, "Tianon Gravi" wrote: > On 5 April 2016 at 14:47, Florian Weimer wrote: > > We currently need these intermediate dependencies to discover all the > > affected applications. So perhaps dh_golang needs to construct the > > transitive closure, instead of listing just immediate build > > dependencies. If we don't want to put this information into the > > Packages file, maybe we can keep it in the separate debuginfo > > packages. > > It _should_ be possible to adjust dh_golang to use "go list" in order > to determine the exact full set of Go packages which the application > code depends on, and then use _that_ list to cross-reference the files > in /usr/share/gocode to get the real list of packages for Built-Using > ( haven't verified whether it's feasible for dh_golang to do this, but > it's pretty similar to how it's currently using "go list" to gather > the list of packages to actually build). > > ♥, > - 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 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
On 5 April 2016 at 14:47, Florian Weimer wrote: > We currently need these intermediate dependencies to discover all the > affected applications. So perhaps dh_golang needs to construct the > transitive closure, instead of listing just immediate build > dependencies. If we don't want to put this information into the > Packages file, maybe we can keep it in the separate debuginfo > packages. It _should_ be possible to adjust dh_golang to use "go list" in order to determine the exact full set of Go packages which the application code depends on, and then use _that_ list to cross-reference the files in /usr/share/gocode to get the real list of packages for Built-Using ( haven't verified whether it's feasible for dh_golang to do this, but it's pretty similar to how it's currently using "go list" to gather the list of packages to actually build). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Security support for packages written in Go
* Martín Ferrari: >> The alternative is to rebuild reverse dependencies as needed. I can >> see two challenges with that. Right now, the Built-Using field only >> records the source versions of the *direct* dependencies (based on the >> dh_golang manual page and a few examples I looked at). If a critical >> update happens farther down the dependency chain, a tool based on >> Built-Using will not mark the top-level package as a rebuild >> candidate. When performing the rebuild, it is possible to compensate >> for that by rebuilding everything that has an outdated Go source >> package in its Build-Using field, iteratively, until we reach a >> fixpoint. But this does not currently work because the -dev packages >> do not contain Built-Using information. > > Actually, I had not noticed this before. I have been including the > built-using field in control files, assuming it will end in the binary > package too. Maybe we can try to fix this? > > Alternatively, the built-using field could include the closure of all > transitive dependencies, although that might explode in size... > > In any case, we need to take into account that a security fix in a > library usually will not require security uploads to intermediate > dependencies. We currently need these intermediate dependencies to discover all the affected applications. So perhaps dh_golang needs to construct the transitive closure, instead of listing just immediate build dependencies. If we don't want to put this information into the Packages file, maybe we can keep it in the separate debuginfo packages. >> It does not seem possible to determine rebuild candidates based on >> Built-Using alone, building the transitive closure after the fact. It >> may have changed between the original application build and subsequent >> library builds. > > What if we build the transitive closure and discarded any arch:all > binaries from the rebuild? Anything is possible with dak support. But it's better not to count on it and rebuild only what we actually need to ship. >> Unrelated to all that, we cannot currently perform binNMUs in the >> security archive because it does not contain a completely copy of the >> main archive. I'm not sure if there are good approaches to deal with >> this yet. > > So this would be an argument for keeping the status quo and just > rebuilding applications manually with a sourceful upload? Then we absolutely have to minimize what we rebuild. Keeping the status quo is barely acceptable for this aspect, but there is no status quo to keep for the discovery of packages which need rebuilding. We just don't have that capability right now. ___ 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] golang-github-ogier-pflag 0.0~git20160129.0.45c278a-1 MIGRATED to testing
FYI: The status of the golang-github-ogier-pflag source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 0.0~git20160129.0.45c278a-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more 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
[pkg-go] docker-registry 2.3.1~ds1-1 MIGRATED to testing
FYI: The status of the docker-registry source package in Debian's testing distribution has changed. Previous version: 2.1.1~ds1-4 Current version: 2.3.1~ds1-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more 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
[pkg-go] notary 0.1~ds1-1 MIGRATED to testing
FYI: The status of the notary source package in Debian's testing distribution has changed. Previous version: 0.0~git20150801.0.8e8122e-2 Current version: 0.1~ds1-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more 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
Re: [pkg-go] Security support for packages written in Go
Hi Florian, On 05/04/16 09:27, Florian Weimer wrote: > we need to discuss how we can support applications written in Go for > stretch. Thanks for bringing this up for discussion. Coincidentally, a few days ago we were discussing the implementation of autopkgtest to deal with issues that stem from static linking too (in particular, libraries that break builds of reverse dependencies, but are not discovered in a timely fashion, if ever) > The most radical approach would be not to ship any Go applications in > stretch, only the basic Go language implementations. This is probably > not desirable. Highly not desirable :-) > One approach would be to ship applications as source code only (just > like libraries), and compile them locally upon installation. This is > what Emacs and Common Lisp implementations already do. With the > growth of Go compilation and link times, this seems less and less > attractive, though. Yes, specially on slow architectures, where just running the tests for libraries can take many minutes a piece. > The alternative is to rebuild reverse dependencies as needed. I can > see two challenges with that. Right now, the Built-Using field only > records the source versions of the *direct* dependencies (based on the > dh_golang manual page and a few examples I looked at). If a critical > update happens farther down the dependency chain, a tool based on > Built-Using will not mark the top-level package as a rebuild > candidate. When performing the rebuild, it is possible to compensate > for that by rebuilding everything that has an outdated Go source > package in its Build-Using field, iteratively, until we reach a > fixpoint. But this does not currently work because the -dev packages > do not contain Built-Using information. Actually, I had not noticed this before. I have been including the built-using field in control files, assuming it will end in the binary package too. Maybe we can try to fix this? Alternatively, the built-using field could include the closure of all transitive dependencies, although that might explode in size... In any case, we need to take into account that a security fix in a library usually will not require security uploads to intermediate dependencies. > It does not seem possible to determine rebuild candidates based on > Built-Using alone, building the transitive closure after the fact. It > may have changed between the original application build and subsequent > library builds. What if we build the transitive closure and discarded any arch:all binaries from the rebuild? > Unrelated to all that, we cannot currently perform binNMUs in the > security archive because it does not contain a completely copy of the > main archive. I'm not sure if there are good approaches to deal with > this yet. So this would be an argument for keeping the status quo and just rebuilding applications manually with a sourceful upload? As a final note, I would like to point out that maybe not only golang libraries need to be taken into account. For example, prometheus -as it is compiled upstream- embeds javascript libraries into the binary. I have removed that in the Debian package, to have run-time 'linking' of javascript libraries, but that could be happening in other packages. -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
[pkg-go] Security support for packages written in Go
Hi, we need to discuss how we can support applications written in Go for stretch. The most radical approach would be not to ship any Go applications in stretch, only the basic Go language implementations. This is probably not desirable. So we need something to deal with the static linking issue. The current state seems to be that -dev packages do not contain object code. This means that they can be built in any admissible order (as determined by their (versioned) build dependencies), without altering the end result, which simplifies matters somewhat (but see below). One approach would be to ship applications as source code only (just like libraries), and compile them locally upon installation. This is what Emacs and Common Lisp implementations already do. With the growth of Go compilation and link times, this seems less and less attractive, though. The alternative is to rebuild reverse dependencies as needed. I can see two challenges with that. Right now, the Built-Using field only records the source versions of the *direct* dependencies (based on the dh_golang manual page and a few examples I looked at). If a critical update happens farther down the dependency chain, a tool based on Built-Using will not mark the top-level package as a rebuild candidate. When performing the rebuild, it is possible to compensate for that by rebuilding everything that has an outdated Go source package in its Build-Using field, iteratively, until we reach a fixpoint. But this does not currently work because the -dev packages do not contain Built-Using information. But this requires that the source package version changes as a result of the rebuild. I'm not sure if this is what happens. Ideally, we want to do this with binNMUs, not sourceful uploads. We may also need some build ordering optimization to avoid redundant rebuilds. This means that the fact that the -dev packages contain no object files is of little practical consequence: The optimization would have to order the builds in the same way as if they did contain object code. But maybe the optimization is not needed. It does not seem possible to determine rebuild candidates based on Built-Using alone, building the transitive closure after the fact. It may have changed between the original application build and subsequent library builds. Unrelated to all that, we cannot currently perform binNMUs in the security archive because it does not contain a completely copy of the main archive. I'm not sure if there are good approaches to deal with this yet. Comments? Florian ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
