On 28.03.24 15:00, Santiago Vila wrote:
Daniel Swarbrick <dswarbr...@debian.org> 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 in the patch: This cherry-picks part of a commit relating to negotiation of the "Accept" header, which became more complex with prometheus/common 0.47.0. See upstream commit a28d786.This resolved the original FTBFS for which this bug was opened, as far as I could see, which was this test failure:
> === RUN TestFederationWithNativeHistograms > federate_test.go:417:> Error Trace: /<<PKGBUILDDIR>>/.build/src/github.com/prometheus/prometheus/web/federate_test.go:417
> Error: Not equal: > expected: 4 > actual : 1 > Test: TestFederationWithNativeHistograms > --- FAIL: TestFederationWithNativeHistograms (0.01s)I was able to reliably reproduce that failure by rolling forward / back the prometheus/common dependency in go.mod on a local git clone.
In either case, this is still happening for me in the current version: Lucas Nussbaum <lu...@debian.org> wrote:FAILED: 1:48: parse error: unexpected character inside braces: '0'
This sounds like a _new_ bug.
Note: I'm currently using virtual machines with 1 CPU and with 2 CPUs for archive rebuilds. On systems with 2 CPUs, the package FTBFS randomly. On systems with 1 CPU, the package FTBFS always. Therefore, to reproduce, please try GRUB_CMDLINE_LINUX="nr_cpus=1" in /etc/default/grub first.
I'm struggling to see how a different number of CPU cores would elicit the aforementioned new bug. It doesn't seem to have the typical characteristics of a race condition. I'll have to try to find some time to setup a VM and try to reproduce it.
OpenPGP_signature.asc
Description: OpenPGP digital signature