On Thu, May 08, 2025 at 04:39:52PM +0200, Simon Josefsson wrote: > >> The testing migration seems a bit unclear to me, can you take a look if > >> this will actually migrate? It is scheduled for autoremoval right now. > >> https://tracker.debian.org/pkg/gsasl > >> https://tracker.debian.org/pkg/libgssglue > >> I think you need a dependence on 'dovecot (>= 2.4~)' in > >> gsasl/libgssglue, and a 'Breaks: gsasl (<< 2.2.2-1.1~), libgsasl (<< > >> 0.9-1.1~)' in dovecot. > > > > Without having spend a lot of time checking, this appears to be > > correct to me. To get more confidence, is the failure of the > > autopkgtest only a *test* regression, or is this also impacting > > regular use cases for users? > > My reading is that the autopkgtest failure happens because it install > dovecot 2.3 and the NMU changed gsasl to only work with dovecot 2.4: > > https://ci.debian.net/packages/g/gsasl/testing/amd64/60433568/#S15 > > 67s Get:35 http://deb.debian.org/debian testing/main amd64 dovecot-imapd > amd64 1:2.3.21.1+dfsg1-1+b2 [1,547 kB] > > I think a 'dovecot (>= 2.4~) in gsasl/debian/tests/control would have > helped here. I clicked the 'retry' buttons for debci now, but I never > grok how debci picks dependency package versions. Maybe it will install > dovecot 2.4 now and things will look green soon. > > I'm not so sure about my statement above, is a Breaks: appropriate when > it is not breaking the package build but only breaks debci for that > package? Seems like that ought to be handled by > gsasl/debian/tests/control Depends:.
Right; the only reason there's any interaction between dovecot and the other packages is because dovecot is used in their tests. There's no relationship between them in the debian/control level at all. > As for test vs user-facing, as far as I understand, nothing except the > self-test changed in gsasl here, and dovecot upstream created a patch to > make things work with gsasl and that is in the Debian devecot 2.4 > package. I haven't reviewed details to see if dovecot really was buggy > here or if they decided to just silence the problem by patching things > on their side, but I'm also not sure that matters. The gsasl patches > had nothing to do with the interop failure, it was just to make the > gsasl self-test start again after dovecot changed their configuration > syntax. Dovecot 2.4 introduced a regression impacted GSSAPI authentication in some cases. It was actually discovered by the gsasl autopkgtests, but the fix belonged with the dovecot upstream. I've incorporated that fix in the 1:2.4.1+dfsg1-3 packages currently in unstable. If I understand the debci autopkgtest behavior correctly (looking at it purely from the outside in), what's happening is that the tests are running in a trixie environment but with sid sources enabled at a lower priority. So by default, dependencies (either from d/control or d/tests/control) will be satisfied from trixie, unless version restrictions require that they come from sid. So in this case, because the gsasl d/tests/control contains an unversioned dependency on dovecot packages, the 2.3.x packages from trixie get installed, which leads to a test failure because gsasĺ's tests now expect 2.4. If this is accurate, then adding a version constraint of (>= 1:2.4~) to the dovecot dependencies for the tests is the correct solution. noah
