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.

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to