Bug#1126368: gdm3: autopkgtest depends sssd which isn't in testing

[Chris Hofstaedtler]

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