Hi Andreas, I noticed that you are one of the dkms uploaders, so maybe you can answer a follow-up question? :)
Quoting Johannes Schauer Marin Rodrigues (2024-05-27 23:45:08) > Quoting Andreas Beckmann (2024-05-27 18:52:58) > > On 27/05/2024 18.32, Johannes Schauer Marin Rodrigues wrote: > > > I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as > > > the > > > relevant hardware is unlikely (or rather impossible) to be found on other > > > architectures. Or do you think that this would be a bed "solution"? > > > > No objections. > > > > Either make the package Architecture: <list> instead of all or try > > BUILD_EXCLUSIVE_ARCH="<list>" in dkms.conf > > (directive exists, but I've never used it and AFAIK no other Debian > > package does use it; maybe needs kernel architectures instead of Debian > > architectures) > > or if you can anchor it on some CONFIG_* option > > BUILD_EXCLUSIVE_CONFIG="CONFIG_FOO !CONFIG_BAR" > > (it's an AND-ed list, no OR possible) > > > > You may need to add debian/tests/autopkgtest-pkg-dkms.conf with > > architecture = <list> > > if the package is not arch:all as autodep8 may not (be able to) take the > > architecture list of the binary packages into account. > > the package is already using: > > BUILD_EXCLUSIVE_CONFIG="CONFIG_WIRELESS" > > which prevents building it for the cloud kernel, for example. I read a bit > into > the dkms.in sources and found that BUILD_EXCLUSIVE_ARCH is a bash regex, so I > set it up like tihs now: > > BUILD_EXCLUSIVE_ARCH="^(aarch64|x86_64|riscv64)$" > > The architectures seem to be what "uname -m" is printing. this seems to have done the trick: https://tracker.debian.org/pkg/ezurio-qcacld-2.0-dkms But I wonder, the autopkgtest results now say (for example for arm64): 657s I: Summary: 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-arm64 657s I: SKIP ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-cloud-arm64 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-rt-arm64 As a result, the whole test is marked as "skipped" and not "successful", so I do not get the few days migration bonus. The module is not meant to be built for the cloud kernel, so can I somehow tell the dkms autopkgtest that so that it only tries to build it on the kernels where it makes sense and thus the whole test becomes "green" and not "yellow"? It's of course no big deal if there is no way. :) Thanks! cheers, josch
signature.asc
Description: signature
