How about this? https://salsa.debian.org/sssd-team/sssd/-/merge_requests/33/diffs
Tests still running... On Tue, Dec 17, 2024 at 5:28 AM Michael Prokop <m...@debian.org> wrote: > > Hi, > > * Chris Hofstaedtler [Wed Dec 11, 2024 at 11:50:21AM +0100]: > > On Tue, Dec 03, 2024 at 05:02:30PM -0300, Andreas Hasenack wrote: > > > > Sergio[1] got access to the actual container that failed to run this > > > test, and we tried to troubleshoot it a bit. We were pressed for time, > > > and didn't get very far. > > > > > > What we did/tried: > > > - reproduced the problem at will, in every single test run, interactively > > > - verified that the ldap setup was sound. We changed the expect script > > > to work via ssh <testuser>@localhost, and the test passed > > > - we realised that /usr/bin/login in debian and in ubuntu are > > > different. The debian one comes from util-linux, whereas the ubuntu > > > one comes from shadow > > > - in that session, whenever we tried to run login directly, to > > > manually test a login, that would disconnect us from the session > > > > Yes. You cannot use login on an existing shell/logged in terminal. > > login calls vhangup, and thus kills whatever was there before, /or/ > > fails. > > > > > What does everybody else think? > > > > I'm worried that the tests in Debian do not *consistently* fail. > > If they were, then I'd say your reproduction case above is > > consistent with the CI-ran tests (=> you have the vhangup call). > > But given they are not, I think there's another problem still. > > Might it be worth to *temporarily* disable the failing autopkgtests > to make sure sssd at least makes it way back into Debian/testing? > > I prepared this as MR if that helps: > > https://salsa.debian.org/sssd-team/sssd/-/merge_requests/35 > > Thanks to everyone looking into this. > > regards > -mika-
