.
--
Martín Ferrari (Tincho)
On 30/11/16 19:59, Martín Ferrari wrote:
> I was trying to solve this bug, but then I realised this package
> actually only contains pre-generated files, without source. And the
> upstream project is gone.
>
> It should be replaced with https://github.com/google/go-genproto
>
Control: tag -1 pending
Hello,
Bug #913580 in prometheus-nginx-vts-exporter reported by you has been fixed in
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/prometheus-nginx-v
Hi Lucas,
On 23/02/17 10:27, Lucas Nussbaum wrote:
> Source: golang-prometheus-client
This package has been removed from unstable and testing already. I only
need to remove it from backports now.
--
Martín Ferrari (Tincho)
Vincent, are you requesting an unblock exception for this package? There
are a bunch of other packages that are going to be removed from testing
if this does not migrate.
--
Martín Ferrari (Tincho)
. There is a report upstream of flakyness in this
test: https://github.com/golang/go/issues/18142
I will disable this test.
--
Martín Ferrari (Tincho)
Control: tag -1 pending
Hello,
Bug #906503 in prometheus-blackbox-exporter reported by you has been fixed in
the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/prometheus-blackbo
Control: tag -1 pending
Hello,
Bug #906359 in golang-github-hashicorp-go-sockaddr reported by you has been
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/golang-gith
ests, becasue the
installed package starts the daemon and then the tests fail when trying
to use the same port; but this is not a FTBFS: the build daemons do not
fail to build from source. I think you should lower the severity.
--
Martín Ferrari (Tincho)
oes not fail: I have
just checked again; so this bug is not RC. There are a few other go
packages that fail autopkgtests for the exact same reason, please do not
open FTBFS bugs without actually trying to build the package.
--
Martín Ferrari (Tincho)
tually be a flaky test?
I have not seen this error before, I can only imagine you had some old
process lying around, or somehow the port was still in use? Otherwise,
it must be some concurrency issue, but as I said, I have not been able
to reproduce this.
--
Martín Ferrari (Tincho)
n on tHE CPU, and none failed..
--
Martín Ferrari (Tincho)
pkgtest flag to request a clean
> netns be used?
This discussion is about a FTBFS bug, not about the CI system. ALso,
that would not solve the issue, as it is autopkgtest installing (and
therefore starting) prometheus.
--
Martín Ferrari (Tincho)
It took me a while to reproduce, as it seems to only happen with high
CPU contention. I will see if I can fix the bug, or disable it otherwise.
--
Martín Ferrari (Tincho)
Control: tag -1 pending
Hello,
Bug #902468 in golang-github-mwitkow-go-conntrack reported by you has been
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/golang-githu
ties, but if it is
not absolutely urgent, I would like to fix it. Also, it will be a good
opportunity to learn how to do uploads to stable :-)
--
Martín Ferrari (Tincho)
e is a PR pending to fix this, but it is not yet complete...
--
Martín Ferrari (Tincho)
ut this.. The version already
in buster works OK, I thought I needed to update to 3.0 (which I will do
anyway for sid), what would be preferred for stable-updates?
--
Martín Ferrari (Tincho)
Santiago,
On 06/01/2019 00:14, Santiago Vila wrote:
> I tried to build this package in buster but it failed:
I have investigated the issue. It seems to be due either to changes in
golang or in the x/tools package, I will do some more tests, and hope to
fix it soon.
--
Martín Ferrari (Tincho)
Control: tag -1 pending
Hello,
Bug #918434 in golint reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/golint/commit/4b93b44bb4c84c5d79a352f018ec
am working now with other breakage coming from
genproto, so maybe this can be fixed in a different -and less risky- way.
--
Martín Ferrari (Tincho)
s package for a bunch of other packages to be at risk of
autoremoval. I don't understand why...
--
Martín Ferrari (Tincho)
one (I really truly hope). If you want to complete it I am happy to back
> off and let you but I’m also happy to finish going through them. Just let me
> know!
Please continue then! Let me know if I can give you a hand. (Probably
easier on IRC)
--
Martín Ferrari (Tincho)
Daniel, et al.
I was preparing a fix for this by copying some support scripts from
other exporters when I noticed a couple of things, and wanted to check
with you before making any change.
This exporter is running with user postfix, while all the others use the
prometheus user. I understand that
Control: tag -1 pending
Hello,
Bug #921615 in prometheus reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/prometheus/commit/1cd743bc0012935842ad
Control: tag -1 pending
Hello,
Bug #921474 in mtail reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/mtail/commit/bb584b8a46f1bbce4fa458b93713a9
w naming standard, so we should
keep that one, but it would be good to create transitional packages and
to sync maintainer stuff.
--
Martín Ferrari (Tincho)
completely forgot to better explain this. The new upstream
release was not because of this bug, but since I had already prepared
it, and it included the fix to this bug, I just lumped all together.
Thanks for the report!
--
Martín Ferrari (Tincho)
ntain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
are failing, but I can't reproduce this in the porterbox.
--
Martín Ferrari (Tincho)
Adrian,
On 15/01/17 20:08, Adrian Bunk wrote:
> On Sun, Jan 15, 2017 at 07:40:57PM -0300, Martín Ferrari wrote:
> Looking at the error message "getsockopt: connection refused",
> it is possible that there might be different network related
> configuration or permissions o
OK, I've finally managed to reproduce the problem, by running the build
with low prioirty in a very CPU-starved environment. It is again a
timing issue when starting the test server.
Will produce a patch and upload ASAP.
--
Martín Ferrari (Tincho)
problem for me. Depending on feedback, I will upload this
> to sid in the next few days.
This seems to solve the problem for me, thank you very much! (And I hope
you can get this in for stretch!)
--
Martín Ferrari (Tincho)
es (not used directly by prometheus), and in the case of
the consul API because there is an API incompatibility with the package
present in Debian.
I will review this to see again if the vendoring can be removed. But I
disagree with the severity of this bug, the policy only marks this
requirement a
e archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
ostrm you can use one
> "{PKGNAME}.maintscript" file with "symlink_to_dir" line.
> See dpkg-maintscript-helper(1) for details.
Thanks for the tip, I did not know this!
--
Martín Ferrari (Tincho)
Pinging this bug so autorm will not remove the package while it migrates
to testing.
--
Martín Ferrari (Tincho)
he report. I am aware of this problem, I had to update the
prometheus-common library, but haven't got the chance yet to upgrade
prometheus, due to new dependencies. I hope to be able to fix this in
the following few days.
--
Martín Ferrari (Tincho)
memory: cannot allocate 4194304-byte block (2680815616
in use)
fatal error: out of memory
Yesterday I'd asked for a give back, since in the previous attempt the
tests timed out. I can't reproduce this on the abel porterbox, and it
seems to me like a problem of a very busy buildd more than any
y?
I will re-run the tests with /usr/bin/time on abel and see how much
memory do they take.
--
Martín Ferrari (Tincho)
On 28/01/17 16:24, Martín Ferrari wrote:
>> and the machines where prometheus failed have 4 GB RAM.
>
> abel too...
Now it fails on abel too.. I guess it was always too close to the limit,
and anything else running killed it.
>> "2680815616 in use", that is 2.6
hanks a lot!
[1]: https://buildd.debian.org/status/logs.php?pkg=prometheus&arch=armhf
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852959
--
Martín Ferrari (Tincho)
em to solve than daily broken
> compiles.
Also, I think this might be more about addressable user space, because
it is not the OOM killer, but the go runtime that kills the tests.
--
Martín Ferrari (Tincho)
On 31/01/17 13:01, Julien Cristau wrote:
> On 01/28/2017 08:24 PM, Martín Ferrari wrote:
>> On 28/01/17 16:10, Adrian Bunk wrote:
>>
>>> AFAIK the buildds are building one package at a time,
>>
>> Uhm, don't know about that, but I many times I have exper
tus 2
> FAIL github.com/prometheus/prometheus/storage/local 288.359s
> ...
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
On 12/11/16 10:38, Santiago Vila wrote:
> imports google.golang.org/cloud/internal: use of internal package not
> allowed
This looks like an older version of golang has been used. Can you
include the full build log?
Thanks
--
Martín Ferrari (Tincho)
investigate.
> (Maybe we need a versioned build-depends here?)
Evidently, it was not that..
--
Martín Ferrari (Tincho)
On 12/11/16 16:34, Martín Ferrari wrote:
Looking more into this, it seems the problem is golang's stupid rules
about canonical naming, which I tried to circumvent for compatibility
and now it is backfiring.
I will try to find a different solution now.
--
Martín Ferrari (Tincho)
Daniel,
On 15/11/16 18:46, Daniel Stender wrote:
> the new package golang-golang-x-oauth2-google-dev missed Breaks against the
> previous
> package revision:
Oh, I completely forgot that, thanks for spotting! Will fix asap.
--
Martín Ferrari (Tincho)
On 15/11/16 19:11, Martín Ferrari wrote:
> Daniel,
>
>
> On 15/11/16 18:46, Daniel Stender wrote:
>
>> the new package golang-golang-x-oauth2-google-dev missed Breaks against the
>> previous
>> package revision:
>
> Oh, I completely forgot that, thanks f
reassign 870843 golang-github-sirupsen-logrus-dev
thanks
This bug is filed under the wrong package.
Package: golang-golang-x-tools-dev
Version: 0.0~git20170629.0.1b3bb8de-1
Severity: grave
Since 0.0~git20170629.0.1b3bb8de-1 a patch has made the source files shipped
fail to build in mips* architectures. It does not FTBFS just because tests have
been disabled in a previous version, but it is makin
FS.
>
I am being stupid and mixing x/tools with x/sys. Sorry about the noise.
--
Martín Ferrari (Tincho)
s/prometheus/web/api/v1
> github.com/prometheus/prometheus/web/ui returned exit code 2
> debian/rules:46: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 2
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
If I disable optimizations (-N option for go tool compile), the error
disappears. I think this confirms it is a compiler bug.
$ GOPATH=$PWD/build go test -c -v -gcflags=-N
github.com/prometheus/prometheus/storage/local
$ GOPATH=$PWD/build go test -c -v
github.com/prometheus/prometheus/storage/loca
forwarded 877541 https://github.com/golang/go/issues/22429
thanks
I have opened an issue in upstream's tracker:
https://github.com/golang/go/issues/22429
--
Martín Ferrari (Tincho)
p.To.Index = v.Args[1].Reg()
On 24/10/17 19:44, Martín Ferrari wrote:
> forwarded 877541 https://github.com/golang/go/issues/22429
> thanks
>
> I have opened an issue in upstream's tracker:
> https://github.com/golang/go/issues/22429
>
--
Martín Ferrari (Tincho)
t20171021.c20a0b1~ds1-2_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
--
Martín Ferrari (Tincho)
Control: tag -1 pending
Hello,
Bug #911434 in prometheus reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/prometheus/commit/76974d404f073b166c0
for reporting, will fix asap!
--
Martín Ferrari (Tincho)
t seems this patch is not needed any more.
Tobias: I see you did the latest upload, but you did not follow the git
workflow I had started, and instead of following git commits, you merged
a snapshot.. I will need to rewrite git history now :(
--
Martín Ferrari (Tincho)
Control: tag -1 pending
Hello,
Bug #916236 in golang-go.net reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/golang-go.net/commit/7130cabebd53c0
Tobias,
On 14/12/2018 21:54, Dr. Tobias Quathamer wrote:
> Am 14.12.2018 um 14:28 schrieb Martín Ferrari:
>> Tobias: I see you did the latest upload, but you did not follow the git
>> workflow I had started, and instead of following git commits, you merged
>> a snapshot.. I
On 24/10/18 13:04, Andreas Beckmann wrote:
> Followup-For: Bug #911444
> Control: found -1 3.2.4-2
>
> Hi,
>
> you added the B+R to python3-flask-httpauth instead of
> python-flask-httpauth-doc
Oh, ffs. Sorry, I will reupload now
--
Martín Ferrari (Tincho)
Control: tag -1 pending
Hello,
Bug #911436 in prometheus-haproxy-exporter reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/prometheus-haproxy-e
Control: tag -1 pending
Hello,
Bug #911436 in prometheus-haproxy-exporter reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
https://salsa.debian.org/go-team/packages/prometheus-haproxy-e
://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/prometheus-mysqld-exporter.html
>
> ...
> === RUN TestScrapeInnodbMetrics
> --- FAIL: TestScrapeInnodbMetrics (0.00s)
> info_schema_innodb_metrics_test.go:17: no such flag -log.level
--
Martín Ferrari (Tincho)
nk the problem is the latest upload of
golang-github-prometheus-client-golang-dev, which had some incompatible
changes. It also affected docker go-metrics (#900597).
Sadly, the only solution is to update to the new API, but probably
upstream has already done it in their repo.
--
Martín Ferrari (Tincho)
ivalent of a soname change..
> https://salsa.debian.org/ruby-team/meta has build script which makes it
> very easy to rebuild all reverse build dependencies.
We have ratt, but that requires sbuild, so I ended up never using it.
--
Martín Ferrari (Tincho)
ration for a new upload
of the alertmanager, so this FTBFS will be solved as soon as I am finished.
Sadly, the golang ecosystem is very immature and has not yet learned
about API stability or even releases...
--
Martín Ferrari (Tincho)
Type '(successCallback:
(response: IHttpPromiseCallbackArg) => TResult |
IPromise(successCallback:
(promiseValue: void | TResult | IHttpPromiseCallbackArg) => I...'.
Type 'IPromise>' is not assignable to type
. The packages
should build out of the box. Can't you add the correct build
restrictions for gccgo so we don't need the tags?
--
Martín Ferrari (Tincho)
Source: golang-google-cloud
Version: 0.5.0-2
Severity: serious
Justification: fails to build from source
Since the latest update to golang-google-genproto-dev, this package FTBFS.
The fix for this is in release 0.7.0, but that requires also updating
golang-github-googleapis-gax-go-dev, and I am n
On 20/02/18 19:17, Adrian Bunk wrote:
> Source: golang-golang-x-tools
> Version: 1:0.0~git20170707.0.bce9606b+ds-1
> Severity: serious
Thanks for the report. It seems this is one of the packages that broke
with the swtich to golang 1.10. I will take a look into it.
--
Martín Ferrari (Tincho)
reproduce..
I have a fix and it seems I can't reproduce the problem any more.
--
Martín Ferrari (Tincho)
t I've
heard it is actually a kernel problem).
I think it does not make much sense to open more RC bugs against these
packages that cannot really be fixed until the root cause is addressed.
--
Martín Ferrari (Tincho)
severity 855124 serious
thanks
Hi, I am also getting this error, which makes the tool unusable.
Moreover, this seems to affect sid and stable, and has got no replies
since February..
--
Martín Ferrari (Tincho)
Moreover, if I try to patch the library adding this:
import gi
gi.require_version("Gtk", "3.0")
I don't get the Gtk error, but still get a segmentation fault. This was
also reported on Launchpad (https://bugs.launchpad.net/geis/+bug/1695998)
On 27/09/17 15:36, Martín
stache.js and its reverse dependencies.
--
Martín Ferrari (Tincho)
pannerServer:
> *MockCloudSpanner does not implement spanner.SpannerServer (missing
> ListSessions method)
> ...
It seems the latest upload to golang-google-genproto broke the API. Will
have to investigate...
--
Martín Ferrari (Tincho)
It seems that updating to v0.16.0 fixes this issue but that pulls new
dependencies, so I am just going to backport the fix for this.
On 04/01/18 11:49, Martín Ferrari wrote:
> On 14/12/17 22:48, Adrian Bunk wrote:
>
>> # cloud.google.com/go/spanner/internal/testutil
>> src/c
Source: golang-golang-x-net-dev
Version: 1:0.0+git20170629.c81e7f2+dfsg-1
Severity: serious
Justification: fails to build from source
I noted a few packages failing to build from source on s390x, and tracked down
the cause to this package:
# golang.org/x/net/internal/socket
src/golang.org/x/net/i
rt Adrian, this seems like a CPU contention issue; I
have just reported it upstream. I will disable these flakey tests for
now to fix the build.
--
Martín Ferrari (Tincho)
Status update: still waiting for upstream's fix.
On 18/12/17 04:55, Martín Ferrari wrote:
> Adrian,
>
> Thanks for the report. I presume this error is due to the change in the
> Prometheus' common library. I am already preparing a new upstream
> release, but that is w
Package: prometheus
Version: 2.1.0+ds-1
Severity: grave
Tags: upstream
Justification: renders package unusable
The upstream developers of Prometheus have advised me to block transition of
prometheus 2.1.0+ds-1 due to some serious performance issues introduced with
this release. I expect a fix for
ackage directly with go get, I get no errors. So, I pressume this might
be related to some change in golint's only dependency, x/tools...
--
Martín Ferrari (Tincho)
tests fail because of timeouts...
These are not time-dependent tests, so I guess my only option is to
increase a few timeouts to something that is not past the end of the
universe :)
--
Martín Ferrari (Tincho)
he common prometheus library a bit too soon, since upstream does
niot make releases for it, I did not know it was not safe..
--
Martín Ferrari (Tincho)
severity 835661 wishlist
thanks
Until libjs-handlebars is removed from main, this is not an RC bug in
prometheus. Dropping severity accordingly, I have enough trouble to keep
up with shit breaking al around me because of things I have no control of.
--
Martín Ferrari (Tincho)
note, not only the target directory were wrong, the modinfo
output would show the wrong version too (2.6.12 vs 2.6.12-1-686)
--
Martín Ferrari
I just wanted to comment that the closing of #363009 didn't fix this
problem in my pbuilder, but HE's patch does.
--
Martín Ferrari
placed the libtest-builder-tester-perl
dependency with perl-modules > 5.8.8, since the former are now
included in the latter.
--
Martín Ferrari
diff -Naur libtest-class-perl-0.11/t/die_before_plan.t libtest-class-perl-0.11-new/t/die_before_plan.t
--- libtest-class-perl-0.11/t/die_before_plan.t 200
Sorry, one of the patches had a mistake.
--
Martín Ferrari
diff -Naur libtest-class-perl-0.11-new/debian/control libtest-class-perl-0.11-newdebian/debian/control
--- libtest-class-perl-0.11-new/debian/control 2006-04-15 01:30:27.0 -0300
+++ libtest-class-perl-0.11-newdebian/debian
Package: libsub-uplevel-perl
Version: 0.09-2
Severity: serious
Tags: patch
The unexpected verbosity of this package is responsible for #356829,
which is a RC bug. As it's used in test cases where the output is
searched for warnings and errors.
It seems that this bug spawned with a fix in the warn
Both #356829 and #357765 are caused by a bug in libsub-uplevel-perl. I
have tested applying the patch included in #363009 and both packages
start to compile correctly
--
Martín Ferrari
tatic
address 81.169.168.202
netmask 255.255.255.0
network 81.169.168.0
broadcast 81.169.168.255
gateway 81.169.168.1
As it is not a bug in the software, I'm closing this bug now. Please
reopen if neccesary.
--
Martín Ferrari
close 375177
merge 375177 375192
thanks
I'm closing and merging this bug report, as it is the same as #375192.
Below is included my explanation for the original close.
-- Forwarded message --
From: Martín Ferrari <[EMAIL PROTECTED]>
Date: Jul 1, 2006 10:06 PM
Subjec
s a makedev bug or not.
Also, lilo is checking /proc/partitions for major number 43, which
doesn't seem a robust as it may change in the future, isn't there any
alternative?
--
Martín Ferrari
rse, lilo has no excuse to ignore makedev :) The problem may be
is that one's tempted to try MAKEDEV nbd, which doesn't work, and you
may think that MAKEDEV has no nbd support.
It is worth mentioning that the mknod in lilo.postinst spawns from #235805
--
Martín Ferrari
This seems to be a change in the APR api, APR_BRIGADE_FOREACH was
already deprecated and now is gone. The same for
'apr_filename_of_pathname'.
You can read this thread:
http://marc2.theaimsgroup.com/?l=apache-modules&m=114797734209756&w=2
--
Martín Ferrari
1 - 100 of 199 matches
Mail list logo