Hi Peter, On 12/15/25 21:16, Paul Gevers wrote:
Can you please check the test cases (the Packages_i386 and Sources files in var/data/(unstable|testing) and try to find where I didn't understand you correctly?
Prompted by Matthias on IRC and the situation with rust-glib-sys I looked into this again yesterday. After several hours I was able to spot the thing that made britney2 schedule the wrong tests on loong64. Initially I thought that was because we added loong64 testing rather late. So I was trying variants of the scenarios already mentioned in this bug, but all worked (not ideally, but getting the job done). The reason why on loong64 britney2 gets the wrong set is because of BREAK_ARCHES. I have a local testcase for that now and will shape it ready for upload. I think that fixing the AutopkgtestPolicy for the current BREAK_ARCHES logic (in DependsPolicy) is going to be non-trivial work, I don't expect that to be fixed soon.
My conclusion of this exercise is that I still can't reproduce the issue that was reported originally. Apart from the loong64 situation now, please notify me immediately if you spot a situation where britney2 doesn't schedule at least one good combination, such that I can take a snapshot for debugging. Given a remark on IRC related to suricata [1], I wonder if *that* case is what you're running into occasionally. I have a snapshot [2] for that case and will hopefully look into that to figure out what's wrong there.
Paul [1] suricata depends on librte-common-mlx5-26, librte-common-mlx5-26 ispulled from unstable, librte-common-mlx5-26 depends on ibverbs-providers (>= 63) which is in unstable, but ibverbs-providers is pulled in the job from testing [2] respighi:/home/elbrus/tmp/live-2026-06-04_bug-1138829_smarter-easy-hints.tar.xz
OpenPGP_signature.asc
Description: OpenPGP digital signature
