Dear maintainer(s),

With a recent upload of linux-signed-amd64 the autopkgtest of zfs-linux
fails in testing when that autopkgtest is run with the binary packages
of linux-signed-amd64 from unstable. It passes when run with only
packages from testing. In tabular form:

                        pass            fail
linux-signed-amd64     from testing    6.10.3+1
zfs-linux              from testing    2.2.4-2
all others             from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of
linux-signed-amd64 to testing [1]. Of course, linux-signed-amd64
shouldn't just break your autopkgtest (or even worse, your package), but
linux is too much at the core of our distribution that we don't want to
wait for updates of packages like this one that seem to break too easily
by changes in linux. Is it possible to make the autopkgtest skip the
test (restriction skipable with exit code 77) if a too new kernel is
installed? Such that you can still see the difference between PASS and
NEUTRAL for linux kernels and hence not blocking src:linux, while at the
same time still have it failing on other regressions and thus blocking
those from migrating? I think we can facilitate this better from ci.d.n
side, by also exposing PASS-to-NEUTRAL changes (I think we don't do that
currently) in the rss feed we provide if that would help you.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from linux-signed-amd64 should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

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

Paul

[1] https://qa.debian.org/excuses.php?package=linux-signed-amd64

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfs-linux/50319905/log.gz

195s checking whether blk_queue_max_hw_sectors() is available...
configure: error: 195s 	*** None of the expected
"blk_queue_max_hw_sectors" interfaces were detected.
195s 	*** This may be because your kernel version is newer than what is
195s 	*** supported, or you are using a patched custom kernel with
195s 	*** incompatible modifications.
195s 	***
195s 	*** ZFS Version: zfs-2.2.4-2
195s 	*** Compatible Kernels: 3.10 - 6.8
195s
195s make: *** [debian/rules:232: override_dh_configure_modules_stamp]
Error 1
196s autopkgtest [01:12:27]: test binary-debs-modules

Hi,

zfs 2.2.5 is compatible with Linux 6.10. We will upload 2.2.5-1 soon.

I will try this in later versions. Thanks for your advice!

If you would like to do so, Linux 6.10 would break zfs-dkms (<<2.2.5).

Cheers,
Shengqi Chen

This seems like the wrong thing to do. The result will just be that
the breakage is hidden? IOW the situation will strictly be worse
than what we have?

Chris

control: severity -1 important
control: fixed -1 2.2.5-1

I’m resetting the severity since this bug is (superficially) fixed by 2.2.5-1,
which is compatible with linux 6.10. Also upcoming but not-released zfs
2.2.6 will support linux 6.11. So we might keep up the pace with kernel.

But the problem itself can be discussed further. I now prefer linux-image
setting Breaks on early zfs-dkms versions, rather than zfs skipping tests
on new kernels. As Chris mentioned, it might hide problems.

Thanks,
Shengqi Chen

close 1078427 2.2.5-1
thanks

Hi Salvatore,


Are you sure? I think the intention of this bug was to stay open and
think of how to expose test results from zfs-linux autopkgtest without
blocking newer versions of linux by just not being up-to-date yet. Is
that issue addressed by now?

Paul

Hi Paul,

No sorry the 'done' was a mistake and got confused while reviewing
src:linux bugs (discovering this one as fixed but not closed).

Hopefully I restored all as before the closure.

Regards,
Salvatore