binary:golang-github-naoina-go-stringutil-dev is NEW.
source:golang-github-naoina-go-stringutil is NEW.
Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid)
golang-github-naoina-go-stringutil_0.0~git20150102.360db0d-1_amd64.changes
uploaded successfully to localhost
along with the files:
golang-github-naoina-go-stringutil_0.0~git20150102.360db0d-1.dsc
golang-github-naoina-go-stringutil_0.0~git20150102.360db0d.orig.tar.gz
golang-github-naoina-go-
On 30 July 2015 at 23:23, Michael Stapelberg wrote:
> 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)
> }
> // …
>
On 30/07/15 03:26 PM, Michael Stapelberg wrote:
> On Thu, Jul 30, 2015 at 3:02 PM, Alexandre Viau
> wrote:
>> We can extend the default list of installed extensions, but I'm not
>
> Can you send a patch for that please?
>
Here you go :)!
--
Alexandre Viau
alexan...@alexandreviau.net
From 7d03
On Thu, Jul 30, 2015 at 3:02 PM, Alexandre Viau
wrote:
>> I think the go tools do not cover files that are referenced by test code,
>> e.g.:
>
> Also, this does not to include files that are used in go:generate
> calls. For example, .proto files.
>
> Note that my proposed patch would also allow t
FYI: The status of the golang-collectd source package
in Debian's testing distribution has changed.
Previous version: (not in testing)
Current version: 0.0~git20150630-1
--
This email is automatically generated once a day. As the installation of
new packages into testing happens multiple t
FYI: The status of the golang-github-ugorji-go-msgpack source package
in Debian's testing distribution has changed.
Previous version: (not in testing)
Current version: 0.0~git20130605.792643-1
--
This email is automatically generated once a day. As the installation of
new packages into tes
FYI: The status of the golang-github-kimor79-gollectd source package
in Debian's testing distribution has changed.
Previous version: (not in testing)
Current version: 0.0~git20150616-1
--
This email is automatically generated once a day. As the installation of
new packages into testing hap
> I think the go tools do not cover files that are referenced by test code,
> e.g.:
Also, this does not to include files that are used in go:generate
calls. For example, .proto files.
Note that my proposed patch would also allow to specify a file name,
for example ``test.sh`` and it would be ins
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 Huds
I guess you could ask go by invoking 'go list -json ./...' and looking
for the various *Files fields. The imports/deps calculations won't
work of course because the point of the copy is to get files to where
they _do_ work, but that just means that there are DepsErrors fields
in the json -- the com
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 wrote:
> On Tue, Jul 28, 2015 at 6:05 PM, Michael Stapelberg
> wrote:
>> Indeed. Currently, when building, I get:
>>
>> # github.com/googlecloudplatform/gcsfuse/fs
>> src/gi
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 30 Jul 2015 09:37:23 +0200
Source: golang-check.v1
Binary: golang-check.v1-dev
Architecture: source all
Version: 0.0+git20150729.11d3bc7-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team
golang-check.v1_0.0+git20150729.11d3bc7-1_amd64.changes uploaded successfully
to localhost
along with the files:
golang-check.v1_0.0+git20150729.11d3bc7-1.dsc
golang-check.v1_0.0+git20150729.11d3bc7.orig.tar.bz2
golang-check.v1_0.0+git20150729.11d3bc7-1.debian.tar.xz
golang-check.v1-dev_0.
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
> 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.
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
16 matches
Mail list logo