Hi. I'm uploading !36 now, let's hope it silences this so we can get
back to uploading a new upstream release. I'm happy to review and
sponsor uploads, but I have limited ability to test things beyond
autopkgtest/debci (which would be nice to enhance to cover the important
use cases).
/Simon
s
This one I actually prefer:
https://salsa.debian.org/sssd-team/sssd/-/merge_requests/36
We will "never" know why the login test was flaky, but this should
work always... (tests are running)
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 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
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 g
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
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
Hi,
On Mon, Dec 2, 2024 at 5:06 AM Michael Prokop wrote:
> So it sadly still doesn't seem to work on amd64. :(
> Quoting from
> https://ci.debian.net/packages/s/sssd/testing/amd64/54970410/:
>
> | test ldap-user-group-ldap-auth: test run
> | [...]
> | 86s + [ testuser1 ldapusers != testuser1 l
found 1081027 2.9.5-4
thanks
Hi,
* Michael Prokop [Fri Nov 08, 2024 at 11:44:52AM +0100]:
> * Paul Gevers [Wed Nov 06, 2024 at 08:00:21PM +0100]:
> > On 06-11-2024 07:43, Michael Prokop wrote:
> > > Or what would be the best option to ignore this for now until it has
> > > been tracked down, mar
* Michael Prokop [Fri Nov 08, 2024 at 11:44:51AM +0100]:
> Right. Looking at the autopkgtest's of sssd I noticed, that inside
> debian/tests/login.exp there's a hardcoded timeout of 10 seconds,
> which very much could be related to the load situation and flaky
> behavior on Debian's CI infrastruct
Hi,
* Paul Gevers [Wed Nov 06, 2024 at 08:00:21PM +0100]:
> On 06-11-2024 07:43, Michael Prokop wrote:
> > Paul, do you know what could be the best option to reproduce the
> > behavior of https://ci.debian.net/ (locally)? Because the problem
> > seems to be environment specific, no one seems to h
Is d/t/ldap-user-group-krb5-auth also flaky? Because it uses the same
expect script:
d/t/ldap-user-group-krb5-auth:
...
# tests begin here
run_common_tests
# login works with the kerberos password
echo "The Kerberos principal can login on a terminal"
kdestroy > /dev/null 2>&1 || /bin/true
/usr/bi
Hi
On 06-11-2024 07:43, Michael Prokop wrote:
Paul, do you know what could be the best option to reproduce the
behavior of https://ci.debian.net/ (locally)? Because the problem
seems to be environment specific, no one seems to have been able to
reproduce it on salsa so far. :-/
As reported, it
Hi!
* Andreas Hasenack [Tue Nov 05, 2024 at 03:08:03PM -0300]:
> On Tue, Nov 5, 2024 at 2:38 PM Andreas Hasenack wrote:
> > I wrote that test initially, and it has been passing in Ubuntu. Sounds
> > like it's some difference in the infrastructure.
> >
> > I tried locally in a debian LXD containe
It passed[1] in salsa:
+ /usr/bin/expect -f debian/tests/login.exp testuser1 testuser1secret
The LDAP user can login on a terminal
spawn login
ldap login: testuser1
Password:
Linux ldap.example.com 5.10.0-33-cloud-amd64 #1 SMP Debian 5.10.226-1
(2024-10-03) x86_64
The programs included with the De
I wrote that test initially, and it has been passing in Ubuntu. Sounds
like it's some difference in the infrastructure.
I tried locally in a debian LXD container, and it passed just fine. Is
it also failing in salsa pipeline runners, or just in the migration by
britney?
The error seems to indicat
Hi,
* Paul Gevers [Sat Sep 07, 2024 at 07:13:21AM +0200]:
> I looked at the results of the autopkgtest of your package. I noticed that
> it regularly fails.
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
>
Source: sssd
Version: 2.9.5-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails.
Because the unstable-to-testing migration software now blocks on
regressions in t
17 matches
Mail list logo
