On Sun, Jan 25, 2026 at 03:23:44PM +0000, Simon McVittie wrote: > On Sun, 25 Jan 2026 at 16:06:58 +0100, Chris Hofstaedtler wrote: > > On Sat, Jan 24, 2026 at 09:44:37PM +0100, Paul Gevers wrote: > > > I guess what you meant is that sssd is no longer in testing, and hence the > > > test in testing fails. The migration-reference/0 runs fail due to missing > > > test dependencies. > > > > Right, that was a bit unclear / mixed up things. > > migration-reference/0 fail due to sssd not being installable. Other > > tests which claim to pull in a single thing from unstable also pull > > sssd from unstable. > > I don't think gdm3 really gets to have any control over this: during the > autopkgtest run, an apt source for unstable is available (with > less-preferred pinning), so any dependency that is satisfiable in unstable > but not in testing is always going to get satisfied from unstable.
Yes; I think this is a gap in how autopkgtest sets the sources up. But this is a side-discussion. > So I think the only thing that gdm3 could do to resolve this bug would be to > drop the test coverage that tries to detect/avoid regressions when > configured to do smart card authentication using sssd, leaving those code > paths untested. (Concretely, that would mean dropping > "sssd-gdm-smartcard-auth-test", leaving only "greeter".) Now that the migration-reference/0 test failed, there is no benefit to gdm3 having tests. Other packages which might or might not break gdm3 won't know, as the gdm3 test is in total considered failed. > Is that what the > release team wants? TTBOMK RT considers failing tests rc. Maybe autopkgtest could support this specific usecase better (I think this is basically an optional dependency in gdm3)? Best, Chris
