On 28.03.24 23:33, Santiago Vila wrote:
If you prefer I could report this build failure in a new report
(or you can also use the clone command so that the bug has a new number,
then close the old bug).
Please report a new bug, with just the relevant info regarding the new
build failure.
We
As expected:
=== RUN TestQuerierIndexQueriesRace/[m!="0"___name__="metric"]
panic: test timed out after 20m0s
...
FAILgithub.com/prometheus/prometheus/tsdb 1200.016s
On 28.03.24 23:13, Santiago Vila wrote:
Ok, I'm attaching one of my build logs for version 2.45.3+ds-3.
This one was
On 28.03.24 15:00, Santiago Vila wrote:
In either case, this is still happening for me in the current version:
Lucas Nussbaum wrote:
FAILED:
1:48: parse error: unexpected character inside braces: '0'
I think you are taking the "FAILED" out of context and misinterpreting
the test output.
On 28.03.24 15:00, Santiago Vila wrote:
Daniel Swarbrick wrote:
* Add new 0022-Support-prometheus-common-0.47.0.patch (Closes: #1064765)
Hello. I don't quite understand how the above fix is related to
the bug itself (but maybe it's because I don't know prometheus internals).
As described
It appears that bumping prometheus/common to 0.47.0 in the prometheus
go.mod will reproduce the test failure.
prometheus/common 0.46.0 and earlier does not provoke the test failure.
OpenPGP_signature.asc
Description: OpenPGP digital signature
On Wed, 26 Jul 2023 22:08:15 +0200 Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > mkdir -p temp/zic/2023c temp/zdump/2023c
> > cp -RL /usr/share/zoneinfo/posix/* temp/zic/2023c/
> > cp: cannot stat '/usr/share/zoneinfo/posix/*': No such file or
directory
> > make[1]: ***
On 25.08.23 19:40, Mathias Gibbens wrote:
Something has changed in sid's golang environment since August 4
which is causing dh-make-golang to fail to determine a package's
dependencies and generate a correct d/control. For example, this worked
fine on August 4 but now fails:
It's probably
Control: tag -1 pending
Hello,
Bug #1026650 in golang-github-census-instrumentation-opencensus-proto 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:
Aha, I overlooked the fact that a new test (TestByPassBasicAuthVuln) had
been added to web/handler_test.go since the 02-Avoid_race_in_test.patch
was added by Tina.
I patched in the same time.Sleep workaround for the new
TestByPassBasicAuthVuln, and it seems to fix the failures. Hooray for
Control: tag -1 pending
Hello,
Bug #1031463 in golang-github-prometheus-exporter-toolkit 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:
This seems to be a resurrection of #1013578, i.e.
https://github.com/prometheus/exporter-toolkit/issues/108.
With unpatched sources, I can get various tests in handler_test.go to
intermittently fail simply by running tests on an upstream git clone, on
a 16-core host. Running tests with
I am unable to reproduce this in a clean sid chroot.
OpenPGP_signature
Description: OpenPGP digital signature
On 07.01.23 12:40, Adrian Bunk wrote:
Does running the autopkgtests on 32-bit bring more benefits than hassle,
or should they be run only on 64-bit architectures?
As troublesome as the tests are on 32-bit, and as much as it would
probably be simpler to just blanket disable them in d/rules, I
Paraphrasing myself from #1027365, this package's tests will pass (even
without tzdata present) if "-tags timetzdata" is used, e.g. by
overriding dh_auto_test.
OpenPGP_signature
Description: OpenPGP digital signature
Paraphrasing myself from #1027365, this package's tests will pass (even
without tzdata present) if "-tags timetzdata" is used, e.g. by
overriding dh_auto_test.
OpenPGP_signature
Description: OpenPGP digital signature
Aha, reading the docs for the Go tzdata package more thoroughly sheds
some light on the topic:
> Package tzdata provides an embedded copy of the timezone database. If
this package is imported anywhere in the program, then if the time
package cannot find tzdata files on the system, it will use
I am able to reproduce the FTBFS in a schroot, sans tzdata package.
However, this is weird, because Go ships with an embedded copy of tzdata
(https://pkg.go.dev/time/tzdata). AFAICT, this is not stripped out in
Debian golang-go packages.
Only selected tests fails, and only those which
I think I just found the smoking gun, so to speak.
In the reproducible builds log, I spotted this:
=== RUN TestDNSProtocol
dns_test.go:490: "localhost" doesn't resolve to ::1.
--- SKIP: TestDNSProtocol (0.00s)
This is due to this check in TestDNSProtocol:
_, err :=
Studying the test failure with the panic more closely, I think it is due
to the inherent raciness caused by tests which spin up http servers, tcp
servers etc in goroutines within the same test.
I think that what's happening is that the grpc server in the goroutine
is not ready in time, so
In general, the gRPC tests (in a pristine v0.23.0 checkout) seem to be
utterly broken.
What's more, isolating the tests to just the GRPC tests fails in a
completely different way:
$ go test ./...
ok github.com/prometheus/blackbox_exporter (cached)
ok
Hi Mathias,
Given that a pristine, upstream checkout fails on that test for the last
two releases, I think we will have to just skip the test.
See https://github.com/prometheus/blackbox_exporter/issues/969
OpenPGP_signature
Description: OpenPGP digital signature
On 22.12.22 20:52, Shengjing Zhu wrote:
Hmm, this works for me, the generated pb.go uses old timestamp type.
I have added above change and built the package, then checked the result.
My mistake, I think I must have looked at a stale build. The suggested
.proto mapping workaround seems to do
Updating the 01-Use_go_generate.patch as follows results in a successful
build (without needing to add golang-google-protobuf-dev as a dependency):
diff --git a/debian/patches/01-Use_go_generate.patch
b/debian/patches/01-Use_go_generate.patch
index cafa5e2..ffa83cf 100644
---
Hi,
On 22.12.22 00:41, Shengjing Zhu wrote:
Hi,
The workaroud could be like this:
https://salsa.debian.org/go-team/packages/notary/-/commit/b0a072faa72857f7523c8245ecaa8814d5a60051
Fixing the build failure in golang-github-prometheus-client-model is a
simple matter of including
After a fair amount of head scratching, I tracked this down to a change
in behaviour of the protobuf compiler. Version 3.14.0+ generates
slightly different pb.go files with respect to the timestamp type (and
possibly others):
--- metrics.pb.go.old 2022-11-08 23:31:00.0 +1300
+++
Hi Paul,
I have also noticed the fairly frequent failures of the memory-intensive
tests on 32-bit, and I am doing my best to keep on top of them with
t.Skip() patches where appropriate. Several of the tests result in the 4
GiB memory footprint threshold being exceeded.
Prometheus itself is
I noticed in the debian/rules that rebuilding the timezone JS data from the
tzdata package is *optional*, and only occurs if the moment-timezone
package has a +x suffix, e.g. +2021e. If not, the timezone JS data from
the upstream moment-timezone source will be used.
I just tried building
This bug is now blocking Prometheus (which I co-maintain) from
transitioning to testing.
In the meantime, I see that there is a new release of moment-timezone.js
upstream (0.5.34) which updates the IANA TZDB to 2021e, and would thus
perhaps resolve the test failures that I see when trying to
I'm fairly sure this error disappear if you attempt a rebuild now.
Earlier versions of dh-golang disabled GOCACHE, and Go 1.12 and later
requires that the GOCACHE env var point to a writable directory. This is
AFAIK now the case in the current dh-golang package.
If the error still occurs,
On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank wa...@debian.org wrote:
- ceph depends on fdisk, parted and whole lot other crap it does not
need.
This is most likely a dependency of the ceph-disk-prepare or ceph-deploy
scripts, which handle preparing partitions and filesystems on new disks
On Sun, Sep 15, 2013 at 1:03 PM, Bastian Blank wa...@debian.org wrote:
There is a python script ceph-rest-api. Where is this used? Why does
it warrant a dependency on 20 other packages?
This is the as yet sparsely documented admin REST WSGI app (which can also
run as a standalone server),
On 09/12/2013 03:13 AM, László Böszörményi (GCS) wrote:
#714881 is already fixed with 0.48-2 , closed the bugreport.
Bastian won't NMU Ceph, but started cooperating. He started working on
the current pkg-ceph Git tree[1], which is version 0.67.2 . It's the
latest stable version. Upstream
32 matches
Mail list logo
