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 TestEnvCo
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_
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
_
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
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
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
Greeting
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 se
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:
>
>
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
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_
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
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 (#81709
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
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 versio
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.
A
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 t
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 e
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 1
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
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 emai
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_
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/.
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 applicati
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
* 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
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 testin
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
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
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 fr
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
30 matches
Mail list logo
