Re: [pkg-go] pkg-go will migrate to salsa.debian.org on 2018-04-02
On ചൊവ്വ 03 ഏപ്രിൽ 2018 09:46 രാവിലെ, Alexandre Viau wrote: > On 2018-04-02 12:27 PM, Alexandre Viau wrote:> I am starting the > migration now. > > The migration was completed. > Thanks! > There are leftover packages with permissions issues in > git.debian.org:/git/pkg-go/packages: > > - golang-github-kelseyhightower-envconfig-dev.git Pushed to salsa and send mr for rewriter. https://salsa.debian.org/salsa/AliothRewriter/merge_requests/252 I could not move it packages-migrated-to-salsa because of permission errors. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#894277: gitaly is not configured and not starting with a custom configuration
Package: gitaly Version: 0.91.0+debian-1 Severity: grave Control: forwarded -1 https://gitlab.com/gitlab-org/gitaly/issues/1119 Control: affects -1 gitlab This breaks gitlab. signature.asc Description: OpenPGP digital 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
[pkg-go] gitlab-workhorse on salsa is moved to go-team/packages from ruby-team
Hi, Initially this was the only gitlab dependency using go and I thought it better to have it under ruby team so its easier to manage. Now golang-gitaly-proto, gitaly and their dependencies are already under go team and it is natural to move gitlab-workhorse there. Please update your local repos. Thanks Praveen signature.asc Description: OpenPGP digital 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] Bug#894131: Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.
On ചൊവ്വ 27 മാർച്ച് 2018 06:21 വൈകു, Martín Ferrari wrote: >> What exactly in Debian policy is preventing us shipping Alertmanager >> built as intended by upstream? > > I don't remember which section in the Policy that is. But those > generated files are not source code, and therefore there is a > requirement to (re)build them from source. It is the same as i was > shipping a pre-compiled .so file. Hi Martin, We had this debate with handlebars templates and I'm happy to share good news about handlebars now. I know you moved to mustache based templates, handlebars is in main now. This has that debate https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#893171: it is just an older version of grpc I think
Control: retitle -1 Update golang-google-grpc-dev to new upstream release Control: reassign -1 golang-google-grpc-dev Control: found -1 1.6.0-3 Correcting bug meta data. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#893171: Support non git packages
Package: dh-make-golang Version: 0.0~git20180129.37f630a-1+b1 severity: wishlist I'm trying to update gitaly to new upstream version. I got src/gitlab.com/gitlab-org/gitaly/internal/rubyserver/balancer/balancer.go:24:2: cannot find package "google.golang.org/grpc/resolver" in any of: /<>/gitaly-0.88.0+debian/obj-x86_64-linux-gnu/src/gitlab.com/gitlab-org/gitaly/vendor/google.golang.org/grpc/resolver (vendor tree) /usr/lib/go-1.10/src/google.golang.org/grpc/resolver (from $GOROOT) /<>/gitaly-0.88.0+debian/obj-x86_64-linux-gnu/src/google.golang.org/grpc/resolver (from $GOPATH) So I try to package it. $ dh-make-golang google.golang.org/grpc/resolver 2018/03/17 05:52:13 Downloading "google.golang.org/grpc/resolver/..." 2018/03/17 05:52:21 Could not create a tarball of the upstream source: Not a git repository, dh-make-golang currently only supports git I think I will keep the vendored files for now. signature.asc Description: OpenPGP digital 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] Getting a new list for actual discussions
On 2018, ജനുവരി 29 9:11:17 AM IST, Alexandre Viauwrote: >Hello, > >This list is pretty spammy. How do you guys keep up with actual >discussions? Do you use filters? > >I personally missed out on discussions because I didn't see the >messages. > >I was wondering if pkg-go would be interested in getting a new list >maybe, and leave this one for bugs/ftpmasters message? >Hopefully we get a lists.debian.org list but I don't think that is >happening, as we don't seem to fit their requirements. A discussion only list would fit their requirements. Or even a combined one. They don't want to host maintainer-only lists. So it would be a good thing to have a discussion only list there. >So, maybe a new list on the newly announced alioth lists >infrastructure? > >Any ideas, comments? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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#886816: Removing golang-go.uber-zap or zap
On 2018, ജനുവരി 29 9:00:58 AM IST, Alexandre Viauwrote: >Hello, > >I have uploaded a duplicate of src:zap as src:golang-go.uber-zap. > >I don't know why I missed src:zap. Probably because it didn't follow >the >pkg-go naming guidelines, but even then, dh-make-golang should have >told >me because it uses XS-Go-Import-Path. > >Anyways. We should remove one of the two packages. > >The next version of influxdb will require zap. > >We should open a RM bug to ftpmasters. > >Which one do you suggest removing? > >Since src:golang-go.uber-zap follows pkg-go naming guidelines, I >suggest >that we remove src:zap. > >Do you have any objections? > >I will open a bug as soon as you confirm. I'm okay with, we should update all reverse build dependencies accordingly. >Cheers, ___ 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] Comments regarding zap_1.5.0+git20170802.3.e68420e-1_amd64.changes
On ബുധന് 06 സെപ്റ്റംബര് 2017 05:15 വൈകു, Shengjing Zhu wrote: > (not from ftp-master, just team member of pkg-go, and not cc ftp-master) > > Why ship this /usr/bin/zap-readme? I don't think this is a useful > binary for users. ok, We can remove it from next upload. > the readme binary is generate from > https://github.com/uber-go/zap/blob/master/internal/readme/readme.go > which is in an internal directory. > And after looked at the code roughly, I think this is used by library > mantainer, not users, which is to generate the > https://github.com/uber-go/zap/blob/master/README.md my main motivation was to get the library part for gitaly, so did not dig deeper about the binary. Thanks for looking deeper. signature.asc Description: OpenPGP digital 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] Comments regarding zap_1.5.0+git20170802.3.e68420e-1_amd64.changes
On ശനി 02 സെപ്റ്റംബര് 2017 12:57 വൈകു, Luca Falavigna wrote: > Hi, > > /usr/bin/readme is too generic to be placed under a location defined in PATH. > Would it be possible to use a more specialized name, such as zap-readme? > done. > Cheers, > Luca > > > > ___ > Pkg-go-maintainers mailing list > Pkg-go-maintainers@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#872015: convert import path to url for homepage and source
package: dh-golang version: 1.22 severity: wishlist example package go.uber.org/atomic. Same for Source in copyright. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#872016: use licensecheck to autodetect license
package: dh-golang version: 1.22 severity: wishlist example package go.uber.org/atomic signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#871983: cache the downloaded files
On Sun, 13 Aug 2017 11:59:05 +0530 Pirate Praveen <prav...@onenetbeyond.org> wrote:> Would it also be possible to not clone the entire history? > I think git clone --depth 1 would be enough to generate the orig tar ball and determine the version. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#871983: cache the downloaded files
package: dh-make-golang severity: wishlist currently dh-make-golang downloads/clones repos every time it is run. It would be better to allow caching as an option so you can reuse the already downloaded copies. This is useful when you don't have a fast internet connection (my personal case, I have to run dh-make-golang on a server after sshing). Would it also be possible to not clone the entire history? signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#871902: Bug#871902: Bug#871902: add golang support to dh-make
On ശനി 12 ആഗസ്റ്റ് 2017 06:06 വൈകു, Shengjing Zhu wrote: > > Hi, > > I think we have dh-make-golang already, please see the following > links for reference. > > https://packages.debian.org/sid/dh-make-golang > https://github.com/debian/dh-make-golang > https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html > Thanks! I will try this. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#871902: add golang support to dh-make
package: dh-make, dh-golang severity: wishlist Currently we have to use dh-make to create a generic debian directory and edit rules to add golang support. We also need to edit control file to add dependency on golang. Both of these could be automated. It would be nice to have direct support for this in dh-make (like python) or have a new command dh-make-go (like dh-make-ruby) so we can automate creation of rules and control files correctly. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#835661: Pending fixes for bugs in the prometheus package
On Mon, 14 Nov 2016 01:34:24 + pkg-go-maintainers@lists.alioth.debian.org wrote: > Commit message: > > Replace libjs-handlebars with libjs-mustache. Closes: #835661. Great to see prometheus remaining in main by removing dependency on libjs-handlebars. Any blockers to this upload? I'd like to reupload the libjs-handlebars package in experimental to unstable once you upload prometheus without libjs-handlebars dependency. This will allow me to move ruby-handlebars-assets to contrib from non-free as node-handlebars provided by libjs-handlebars source package currently in experimental provides source code for ruby-handlebars-assets. signature.asc Description: OpenPGP digital 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
[pkg-go] help fixing gitlab-workhorse build failure on s390x
[cc me on replies from s390 list] gitlab-workhorse is blocking gitlab 8.12.3 migration to testing for sometime now. I fixed two issues with powerpc build but this issue seems hard to crack. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843148 for details Any help fixing this issue would be great. signature.asc Description: OpenPGP digital 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] Need help fixing raven-go with gccgo
[Adding GCC Maintainers (please cc me on replies)] On Wednesday 02 November 2016 04:01 PM, Pirate Praveen wrote: > Can some one who knows golang well, respond to this question from > upstream https://github.com/getsentry/raven-go/issues/112 signature.asc Description: OpenPGP digital 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] Need help fixing raven-go with gccgo
[Adding GCC Maintainers (please cc me on replies)] On Wednesday 02 November 2016 04:01 PM, Pirate Praveen wrote: > Can some one who knows golang well, respond to this question from > upstream https://github.com/getsentry/raven-go/issues/112 signature.asc Description: OpenPGP digital 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] Need help fixing raven-go with gccgo
On Wednesday 02 November 2016 01:00 PM, Pirate Praveen wrote: > Can someone here help with this package? Details here > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842897 Can some one who knows golang well, respond to this question from upstream https://github.com/getsentry/raven-go/issues/112 signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#842897: Bug#842897: Bug#842897: fix test failure with gccgo
Control: forwarded -1 https://github.com/getsentry/raven-go/issues/112 On Wednesday 02 November 2016 02:55 PM, Michael Hudson-Doyle wrote: > This looks like an upstream problem, have you reported in there? It > looks like a test depending on details of the function names you get > from runtime.Stack or similar, probably just skipping it when running > with gccgo would be fine. Just reported it. I'll try if I can disable it (I don't know much of go). signature.asc Description: OpenPGP digital 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
[pkg-go] Need help fixing raven-go with gccgo
Hi, Can someone here help with this package? Details here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842897 I need this package for gitlab-workhorse (and in turn gitlab). Thanks Praveen signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#842897: fix test failure with gccgo
package: golang-raven-go version: 0.0~git20150721.0.74c334d-1 severity: important Need this to make gitlab-workhorse buildable again on powerpc https://buildd.debian.org/status/package.php?p=gitlab-workhorse go test -v -p 1 github.com/getsentry/raven-go === RUN TestPacketJSON --- PASS: TestPacketJSON (0.07s) === RUN TestPacketInit --- PASS: TestPacketInit (0.00s) === RUN TestSetDSN --- PASS: TestSetDSN (0.00s) === RUN TestUnmarshalTag --- PASS: TestUnmarshalTag (0.00s) === RUN TestUnmarshalTags --- PASS: TestUnmarshalTags (0.00s) === RUN TestMarshalTimestamp --- PASS: TestMarshalTimestamp (0.00s) === RUN TestUnmarshalTimestamp --- PASS: TestUnmarshalTimestamp (0.00s) === RUN TestNewException --- PASS: TestNewException (0.00s) === RUN TestNewHttp --- PASS: TestNewHttp (0.00s) === RUN TestSanitizeQuery --- PASS: TestSanitizeQuery (0.00s) === RUN TestFunctionName --- FAIL: TestFunctionName (0.04s) stacktrace_test.go:30: incorrect package; got github_com_getsentry_raven_go, want github.com/getsentry/raven-go stacktrace_test.go:33: incorrect function; got $thunk15, want tRunner stacktrace_test.go:30: incorrect package; got , want runtime stacktrace_test.go:33: incorrect function; got kickoff, want goexit === RUN TestStacktrace --- FAIL: TestStacktrace (0.00s) stacktrace_test.go:58: incorrect Module: raven stacktrace_test.go:73: expected InApp to be true stacktrace_test.go:77: incorrect Culprit: === RUN TestNewStacktrace_outOfBounds --- PASS: TestNewStacktrace_outOfBounds (0.00s) FAIL signature.asc Description: OpenPGP digital 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-github-dgrijalva-jwt-go_3.0.0-3_source.changes ACCEPTED into unstable
On Tuesday 25 October 2016 06:10 PM, Martín Ferrari wrote: > Hi, > > On 25/10/16 06:57, Pirate Praveen wrote: >> On Wednesday 12 October 2016 08:19 PM, Martín Ferrari wrote: >>> I need to check with upstream if they are breaking API compatibility for >>> good, and in that case will need to create a new package with a API >>> version embedded. >> >> What do you think the best here now? I have to fix >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841617 (it needs >> golang-github-dgrijalva-jwt-go 3.0). >> >> Can I create a new package golang-github-dgrijalva-jwt-go3? > > I filed a bug upstream (https://github.com/dgrijalva/jwt-go/issues/176) > and the upstream author said he plans to keep fixing bugs for 2.x, so > I'd say that having a different package makes sense. > > Two things would need to happen, though: the new package will have to > use a different import path, and dependencies will have to be patched to > use it. Upstream mentioned gopkg.in, so maybe he will switch to that at > some point, but for now, we will have to do it the hackish way. > > The same should probably be done to the v2 package too. > > Also, we should probably discuss with the team the version naming > scheme, since it is possible this will happen more often in the future. > What do you folks think? golang-fooN, golang-foo-vN? > I chose -vN as that seems the way gopkg.in suggests. I have made changes in master-v3 branch. Can you check it? signature.asc Description: OpenPGP digital 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-github-dgrijalva-jwt-go_3.0.0-3_source.changes ACCEPTED into unstable
On Wednesday 12 October 2016 08:19 PM, Martín Ferrari wrote: > I need to check with upstream if they are breaking API compatibility for > good, and in that case will need to create a new package with a API > version embedded. What do you think the best here now? I have to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841617 (it needs golang-github-dgrijalva-jwt-go 3.0). Can I create a new package golang-github-dgrijalva-jwt-go3? signature.asc Description: OpenPGP digital 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] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
On 2016, ഒക്ടോബർ 12 8:24:57 PM IST, "Martín Ferrari"wrote: > >> Done. To test compilation with gccgo, I temporarily replaced the >build >> dependency on golang-any with gccgo-6, but the build fails on amd64: >> >> dh build --buildsystem=golang --with=golang >> dh_testdir -O--buildsystem=golang >> dh_update_autotools_config -O--buildsystem=golang >> dh_auto_configure -O--buildsystem=golang >> dh_auto_build -O--buildsystem=golang >>go install -v -p 1 >> dh_auto_build: go install -v -p 1 failed to to execute: No such >file >or directory >> debian/rules:4: recipe for target 'build' failed >> make: *** [build] Error 2 >> dpkg-buildpackage: error: debian/rules build gave error exit status >2 >> >> Is this a bug in dh-golang or gccgo-6? > >No, it is that golang-any provides the symlink only on non-golang >architectures.. I don't know of any easy way to test this nowadays, >except for manyally creating a link from /usr/bin/go to gccgo-6 Last upload of gccgo-6 included this via alternatives. So no special handling required. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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-dgrijalva-jwt-go_3.0.0-3_source.changes ACCEPTED into unstable
On ചൊവ്വ 11 ഒക്ടോബര് 2016 10:36 വൈകു, Martín Ferrari wrote: > OK, please do the same with both libraries, and revert any other changes > you have done. Reverted both packages to previous versions. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#839597: Bug#839597: Bug#839597: update golang-github-dgrijalva-jwt-go to new upstream release
On Tue, 4 Oct 2016 13:52:48 +0200 Martín Ferrariwrote: > I will take a look at your changes, but I would be interested in seeing > which failures you are getting with gcc-go and on which architecture. I got this test failure on amd64. I ran # dpkg -r --force-all golang-go # ln -s /usr/bin/go-6 /usr/bin/go I have filed #840190 so the symlink step can be avoided. All tests passed with golang-go. I also uploaded golang-github-dgrijalva-jwt-go to experimental. Test log below. Ruby testing libraries are more friendly as they print the failed tests at the end, here we have to go through all tests manually to find failed tests. Failed tests: --- FAIL: TestCopyAndDecodeAlwaysReturnsACopy (0.00s) utility_test.go:85: autorest: CopyAndDecode failed to return a valid copy of the data - There are more failures, but does not print which tests failed. Full log: go test -v -p 1 github.com/Azure/go-autorest/autorest github.com/Azure/go-autorest/autorest/azure github.com/Azure/go-autorest/autorest/azure/example github.com/Azure/go-autorest/autorest/date github.com/Azure/go-autorest/autorest/mocks github.com/Azure/go-autorest/autorest/to github.com/Azure/go-autorest/autorest/validation === RUN TestResponseHasStatusCode --- PASS: TestResponseHasStatusCode (0.00s) === RUN TestResponseHasStatusCodeNotPresent --- PASS: TestResponseHasStatusCodeNotPresent (0.00s) === RUN TestNewPollingRequestDoesNotReturnARequestWhenLocationHeaderIsMissing --- PASS: TestNewPollingRequestDoesNotReturnARequestWhenLocationHeaderIsMissing (0.00s) === RUN TestNewPollingRequestReturnsAnErrorWhenPrepareFails --- PASS: TestNewPollingRequestReturnsAnErrorWhenPrepareFails (0.00s) === RUN TestNewPollingRequestDoesNotReturnARequestWhenPrepareFails --- PASS: TestNewPollingRequestDoesNotReturnARequestWhenPrepareFails (0.00s) === RUN TestNewPollingRequestReturnsAGetRequest --- PASS: TestNewPollingRequestReturnsAGetRequest (0.00s) === RUN TestNewPollingRequestProvidesTheURL --- PASS: TestNewPollingRequestProvidesTheURL (0.00s) === RUN TestGetLocation --- PASS: TestGetLocation (0.00s) === RUN TestGetLocationReturnsEmptyStringForMissingLocation --- PASS: TestGetLocationReturnsEmptyStringForMissingLocation (0.00s) === RUN TestGetRetryAfter --- PASS: TestGetRetryAfter (0.00s) === RUN TestGetRetryAfterReturnsDefaultDelayIfRetryHeaderIsMissing --- PASS: TestGetRetryAfterReturnsDefaultDelayIfRetryHeaderIsMissing (0.00s) === RUN TestGetRetryAfterReturnsDefaultDelayIfRetryHeaderIsMalformed --- PASS: TestGetRetryAfterReturnsDefaultDelayIfRetryHeaderIsMalformed (0.00s) === RUN TestLoggingInspectorWithInspection --- PASS: TestLoggingInspectorWithInspection (0.00s) === RUN TestLoggingInspectorWithInspectionEmitsErrors --- PASS: TestLoggingInspectorWithInspectionEmitsErrors (0.00s) === RUN TestLoggingInspectorWithInspectionRestoresBody --- PASS: TestLoggingInspectorWithInspectionRestoresBody (0.00s) === RUN TestLoggingInspectorByInspecting --- PASS: TestLoggingInspectorByInspecting (0.01s) === RUN TestLoggingInspectorByInspectingEmitsErrors --- PASS: TestLoggingInspectorByInspectingEmitsErrors (0.00s) === RUN TestLoggingInspectorByInspectingRestoresBody --- PASS: TestLoggingInspectorByInspectingRestoresBody (0.00s) === RUN TestNewClientWithUserAgent --- PASS: TestNewClientWithUserAgent (0.00s) === RUN TestClientSenderReturnsHttpClientByDefault --- PASS: TestClientSenderReturnsHttpClientByDefault (0.00s) === RUN TestClientSenderReturnsSetSender --- PASS: TestClientSenderReturnsSetSender (0.00s) === RUN TestClientDoInvokesSender --- PASS: TestClientDoInvokesSender (0.00s) === RUN TestClientDoSetsUserAgent --- PASS: TestClientDoSetsUserAgent (0.00s) === RUN TestClientDoSetsAuthorization --- PASS: TestClientDoSetsAuthorization (0.00s) === RUN TestClientDoInvokesRequestInspector --- PASS: TestClientDoInvokesRequestInspector (0.00s) === RUN TestClientDoInvokesResponseInspector --- PASS: TestClientDoInvokesResponseInspector (0.00s) === RUN TestClientDoReturnsErrorIfPrepareFails --- PASS: TestClientDoReturnsErrorIfPrepareFails (0.00s) === RUN TestClientDoDoesNotSendIfPrepareFails --- PASS: TestClientDoDoesNotSendIfPrepareFails (0.00s) === RUN TestClientAuthorizerReturnsNullAuthorizerByDefault --- PASS: TestClientAuthorizerReturnsNullAuthorizerByDefault (0.00s) === RUN TestClientAuthorizerReturnsSetAuthorizer --- PASS: TestClientAuthorizerReturnsSetAuthorizer (0.00s) === RUN TestClientWithAuthorizer --- PASS: TestClientWithAuthorizer (0.00s) === RUN TestClientWithInspection --- PASS: TestClientWithInspection (0.00s) === RUN TestClientWithInspectionSetsDefault --- PASS: TestClientWithInspectionSetsDefault (0.00s) === RUN TestClientByInspecting --- PASS: TestClientByInspecting (0.00s) === RUN TestClientByInspectingSetsDefault --- PASS: TestClientByInspectingSetsDefault (0.00s) === RUN TestNewErrorWithError_AssignsPackageType --- PASS:
[pkg-go] Bug#839597: Bug#839597: update golang-github-dgrijalva-jwt-go to new upstream release
On Mon, 3 Oct 2016 00:08:48 +0200 Martín Ferrariwrote: > I don't usually work with this package, but be careful when updating > this as 3.0 has breaking changes that might affect rdependencies: > > https://github.com/dgrijalva/jwt-go/blob/master/VERSION_HISTORY.md I have prepared the update at https://git.fosscommunity.in/praveen/golang-github-dgrijalva-jwt-go (I have also requested membership at pkg-go on alioth) I have also updated its reverse dependency here https://git.fosscommunity.in/praveen/golang-github-azure-go-autorest Though the second package's tests are failing with gccgo-6. I don't know any go, so if one of you can check it, that would be great. May be we can ignore these failures. Please review and upload if it is good enough. signature.asc Description: OpenPGP digital 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
[pkg-go] Bug#835661: Bug#835661: drop dependency on libjs-handlebars
On 2016, ആഗസ്റ്റ് 29 8:40:00 AM IST, "Martín Ferrari" <tin...@debian.org> wrote: >Hi, > >On 28/08/16 08:33, Pirate Praveen wrote: > >> libjs-handlebars is missing source (see >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830986 and >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978). I'm >planning >> to drop this package (other option is to keep in non-free) soon. >> >> if you can help keep it in main by generating handlebars.js from its >> source, that would be another option (but this would require >packaging >> grunt or mimicking grunt using other tools in main). > >I understand your pain, but possibly this could be reproduced with some >commands in debian/rules, using browserify? I took a brief look today, >but did not seem to find all the scripts for building the source >completely, but surely there is way.. I will try to help with this. Thanks. >Having said all this, I think the serious severity is not correct. This >package is not yet removed from main, so I don't see any reason for >this >bug to be RC (yet). libjs-handlebars cannot be released in main in the current form, so I think the severity is correct. Even if libjs-handlebars is moved to non-free, prometheus will have to be moved to contrib. ___ 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#835661: drop dependency on libjs-handlebars
package: prometheus version: 1.0.1+ds-1 severity: serious libjs-handlebars is missing source (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830986 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978). I'm planning to drop this package (other option is to keep in non-free) soon. if you can help keep it in main by generating handlebars.js from its source, that would be another option (but this would require packaging grunt or mimicking grunt using other tools in main). signature.asc Description: OpenPGP digital 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