Bug#1072533: procps: flaky autopkgtest:

2024-07-20 Thread Paul Gevers

Hi,

Sorry for being tense yesterday.

On 19-07-2024 8:12 p.m., Paul Gevers wrote:

On 19-07-2024 10:04 a.m., Craig Small wrote:

Ideally, I'd like to push a pre-release into the Debian CI and see if
it works now. I'm not sure
thereĀ  is a way of doing that.


You can upload to experimental. The upload will be tested on amd64 and 
arm64 automatically (in unstable, like normal uploads to unstable are 
tested in testing), and you can use the self-service [1] to schedule more.


I can give you access to a testbed on our infrastructure where you can 
play in a production environment exactly like the tests run. We'd need 
to align the date/time, as in the current way that I can provide this 
service, I need to be on-line at the same time.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072533: procps: flaky autopkgtest:

2024-07-19 Thread Paul Gevers

Hi

On 19-07-2024 10:04 a.m., Craig Small wrote:

Ideally, I'd like to push a pre-release into the Debian CI and see if
it works now. I'm not sure
there  is a way of doing that.


You can upload to experimental. The upload will be tested on amd64 and 
arm64 automatically (in unstable, like normal uploads to unstable are 
tested in testing), and you can use the self-service [1] to schedule more.


Paul

[1] https://ci.debian.net/user/


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072533: procps: flaky autopkgtest:

2024-07-19 Thread Craig Small
On Tue, 4 Jun 2024 at 05:57, Paul Gevers  wrote:
> I looked at the results of the autopkgtest of your package, because it
> showed up in the glibc regressions. I noticed that it regularly fails on
> amd64, ppc64el and s390x. For your info, as it seems to correlate, those
> are the architectures where multiple tests run in parallel, each in
> their own lxc container.
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.
I'll need some help here, the lxc environment is doing something odd/wrong with
the proc filesystem. We've been bit before from lxc, but I don't know
enough about the
CI system to know what's going on.

This *might* be fixed with a commit checking for odd ways LXC presents files[1]
discussed at [2]. It also appears to be LXC version dependent.

1: 
https://gitlab.com/procps-ng/procps/-/commit/42dce4d9f4132360647c4dcae1fbbfa1171528b3
2: https://gitlab.com/libvirt/libvirt/-/issues/492

Ideally, I'd like to push a pre-release into the Debian CI and see if
it works now. I'm not sure
there  is a way of doing that.

 - Craig



Bug#1072533: procps: flaky autopkgtest:

2024-06-04 Thread Craig Small
On Tue, 4 Jun 2024 at 05:57, Paul Gevers  wrote:
> I looked at the results of the autopkgtest of your package, because it
> showed up in the glibc regressions. I noticed that it regularly fails on
> amd64, ppc64el and s390x. For your info, as it seems to correlate, those
> are the architectures where multiple tests run in parallel, each in
> their own lxc container.
So the lxc container is probably presenting something odd to the
procfs because that type of virtualisation in particular naively
overwrites files in /proc.
What is strange is this works every time on my (amd64) system. It also
works on salsa.

>   53s  [1;31mASSERT: [0mvalue line
I see the prepare_testbed just before this failed too, not sure what that is.
The value line is running 'vmstat' and then for the third line
grep -E '^([[:space:]]+[[:digit:]]+){18}$' "${stdoutF}"
i.e. is there 18 fields.

 - Craig



Bug#1072533: procps: flaky autopkgtest:

2024-06-03 Thread Paul Gevers

Source: procps
Version: 2:4.0.4-4
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package, because it 
showed up in the glibc regressions. I noticed that it regularly fails on 
amd64, ppc64el and s390x. For your info, as it seems to correlate, those 
are the architectures where multiple tests run in parallel, each in 
their own lxc container.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

E.g.

https://ci.debian.net/packages/p/procps/testing/amd64/47064938/

 52s autopkgtest [06:08:26]: test vmstat: [---
 53s test_no_arguments
 53s ASSERT:value line
 53s shunit2:ERROR test_no_arguments() returned non-zero 
return code.

 53s test_forks
 53s test_disk
 53s
 53s Ran 3 tests.
 53s
 53s FAILED (failures=2)
 53s autopkgtest [06:08:27]: test vmstat: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature