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-
signature.asc
Description: PGP signature
