Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on arm64 only
since July 2022. Can you please investigate the situation and fix it? I
copied some of the output at the bottom of this report. I'd like to note
that our arm64 workers are all hosted in China, which *might* be of
relevance as this test seems to be testing against the internet (I could
be wrong). If it is testing against the internet, it requires the
needs-internet restriction (although that currently doesn't change
anything).

The release team has announced [1] that failing autopkgtest on amd64 and
arm64 are considered RC in testing. [Release Team member hat on] Because
we're currently in the hard freeze for bookworm, I have marked this bug
as bookworm-ignore. Targeted fixes are still welcome.

More information about this bug and the reason for filing it can be
found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg00002.html

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32818576/log.gz

=== RUN   TestLogReqRespNoBody
     logger_test.go:90: request header doesn't match:
(2023-04-12T19:18:59.1355402+08:00) INFO: REQUEST: GET
https://fakething/dot/com
--- FAIL: TestLogReqRespNoBody (0.01s)
=== RUN   TestLogReqRespWithBody
     logger_test.go:155: request header doesn't match:
(2023-04-12T19:18:59.1420497+08:00) INFO: REQUEST: GET
https://fakething/dot/com
--- FAIL: TestLogReqRespWithBody (0.01s)
FAIL
FAIL	github.com/Azure/go-autorest/logger	0.017s

Looks like it was caused by the UTC+8 timezone in the testbed.

I agree it's nice to have the tests not depending on the system
timezone. But do we really want to bother with that? Could you just
ensure all testbeds have the same timezone?

Hi Shengjing,

In my opinion we should do both. You don't want people to go figure this
out if they try to run the tests themselves in their own timezone. Also,
we are only in control of the hosts that Debian uses. Any downstream may
run into the same problems.

Paul

Hi,

I have changed the timezone on all our hosts, but your test still fails.

https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32859920/log.gz
is the test I just scheduled. It failed in the same way.

Paul

Maybe you haven't rebuilt the lxc image with the new timezone, so it
still uses UTC+8.

Anyway, I've staged the change in git
https://salsa.debian.org/go-team/packages/golang-github-azure-go-autorest/-/commit/73b09d0

Hi,

That's what I thought so later too. Let's see what tomorrow brings.
Great.

Paul

Hi,

So, the testsing container was rebuild on Apr 14 06:29 (UTC) and I just
ran the golang-github-azure-go-autorest test:
https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-azure-go-autorest/32898818/log.gz

It still fails.

Paul

Hi,

Turns out that /etc/timezone is also used in some places and that
although the host was running UTC, the containers were *still* being
created in the timezone mentioned in /etc/timezone.

I have now made all our hosts run on UTC with *both* /etc/timezone and
/etc/localtime fixed [1]. I hope that tomorrow will see this resolved
from the infrastructure side of things too.

Paul

[1]
https://salsa.debian.org/ci-team/debian-ci-config/-/commit/42162fb473f9ee3ca0af2be882fb0f1e2bd8917b

Hi,

The tests now pass.

I still appreciate it if you future upload also fixes this on the
package side as discussed earlier, as it's not only Debian's
infrastructure that's affected.

Paul