Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: transition
X-Debbugs-Cc: [email protected]
Control: affects -1 + src:dovecot
Since we're in a transition freeze, I'd like to request an exception to
allow src:dovecot 2.4 to enter trixie. src:dovecot builds dovecot-dev,
which has two reverse build-deps, so requires a small transition.
The two potentially controversial issues with this transition are:
1. Reverse build-dep dovecot-antispam does not support version 2.4. Its git
repository has seen no upstream activity since 2017 and the package has seen
no maintainer activity since 2018, so my suggestion is that we remove this
package from trixie altogether.
2. Dovecot 2.4 does not build on 32-bit architectures. My intent was to
drop i386 anyway, but I did put out a call for help on [email protected]
in case anybody wants to fix the issues as they impact 32-bit arm*
architectures. Receiving no responses thus far, I'm inclined to drop
support for these architectures from the package.
Additionally, upstream is likely to publish a bugfix release (2.4.1) in the
near future. Given the nature of this release, getting into trixie would
also be ideal. I'd consider that a second transition for this package, as
we're currently working with 2.4.0, but I do want to mention it.
Thanks
noah
Ben file:
title = "dovecot";
is_affected = .depends ~ "dovecot-dev" | .depends ~ "dovecot-dev";
is_good = .depends ~ "dovecot-dev";
is_bad = .depends ~ "dovecot-dev";
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Wed, 26 Mar 2025 15:21:01 GMT) (full text, mbox, link).
On Mon, Mar 17, 2025 at 10:27:46AM -0400, Noah Meyerhans wrote:
> 2. Dovecot 2.4 does not build on 32-bit architectures. My intent was to
> drop i386 anyway, but I did put out a call for help on [email protected]
> in case anybody wants to fix the issues as they impact 32-bit arm*
> architectures. Receiving no responses thus far, I'm inclined to drop
> support for these architectures from the package.
Note that I've fixed the 32-bit build issues, so this is no longer a
concern.
Thanks
noah
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 24 Apr 2025 10:33:01 GMT) (full text, mbox, link).
Hi Noah,
Sorry taking so long to reply. I assumed because you filed a transition
bug that there was a regular SONAME bump involved. I see that the
dovecot-core ships libraries, but it looks like they didn't bump SONAME.
So how is this supposed to work in the dovecot ecosystem? Isn't the
package name supposed to change when SONAMEs change (Debian policy) and
isn't ABI breaking (which is implied by the transition request and
suggested by your Provides) not a reason to bump SONAME? As this is a
unconventional transition, I'm not comfortable to judge.
I'm unhappy with removing dovecot-antispam [1] so late for a transition
especially as I don't see a warning to its maintainers/users [2]. The
unconventional library handling (via the dovecot-abi-*.abiv* Provides
from dovecot-core IIUC) makes me want to defer to Release Team member
colleagues who handle much more transitions than I do.
Paul
[1] popcon suggest > 5% of dovecot installs use it, if we remove it I
guess it's worth documenting in release-notes
[2] I think it would have been nice to its maintainer and potential
users that look at the BTS if you would have filed a bug report against
dovecot-antispam once you learned it wasn't compatible. Can you please
do so ASAP regardless of how we handle this transition/unblock request?
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 24 Apr 2025 16:15:01 GMT) (full text, mbox, link).
On Thu, Apr 24, 2025 at 12:30:41PM +0200, Paul Gevers wrote:
> Sorry taking so long to reply. I assumed because you filed a transition bug
> that there was a regular SONAME bump involved.
It's likely my fault for not highlighting the unusual nature of dovecot
when filing the bug.
> I see that the dovecot-core ships libraries, but it looks like they
> didn't bump SONAME. So how is this supposed to work in the dovecot
> ecosystem? Isn't the package name supposed to change when SONAMEs
> change (Debian policy) and isn't ABI breaking (which is implied by the
> transition request and suggested by your Provides) not a reason to
> bump SONAME? As this is a unconventional transition, I'm not
> comfortable to judge.
In the past, I don't believe we've actually treated dovecot version
bumps as transitions, despite the impact that they have on reverse
builddeps. I chose to do that for the 2.4 change because, at the time I
opened the request, we were just starting the freeeze and I didn't want
to risk complicating things with uncoordinated changes.
Dovecot's relationship with its reverse builddeps is somewhat inverted
from normal library providers. The reverse builddeps are plugins to the
dovecot process, so they build shared libraries that are loaded by
dovecot with dlopen(). They don't actually link against any
dovecot-provided shared libraries at build time (in fact, the -dev
package doesn't include any libraries). The binary interface is the
dovecot process itself, plugins explicitly declare any dovecot plugin
dependencies they may have, and symbol resolution happens at runtime.
The ABI version and API version are considered the same thing, and are
bumped with every upstream release.
See https://doc.dovecot.org/2.4.1/developers/design/plugins.html
> I'm unhappy with removing dovecot-antispam [1] so late for a transition
> especially as I don't see a warning to its maintainers/users [2]. The
> unconventional library handling (via the dovecot-abi-*.abiv* Provides from
> dovecot-core IIUC) makes me want to defer to Release Team member colleagues
> who handle much more transitions than I do.
I did notify the maintainer privately, before realizing that they seem
MIA, but didn't follow up with a bug report. I've now opened #1104033
for better visibility.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104033
noah
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 24 Apr 2025 16:21:01 GMT) (full text, mbox, link).
Control: tags -1 confirmed
Hi,
On 24-04-2025 18:13, Noah Meyerhans wrote:
> It's likely my fault for not highlighting the unusual nature of dovecot
> when filing the bug.
I could have asked earlier.
> I did notify the maintainer privately, before realizing that they seem
> MIA, but didn't follow up with a bug report. I've now opened #1104033
> for better visibility.
With both of the issues out of the way, go ahead.
Paul
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Sat, 26 Apr 2025 08:06:01 GMT) (full text, mbox, link).
Hi
On 24-04-2025 18:20, Paul Gevers wrote:
> With both of the issues out of the way, go ahead.
For the record of this bug, there's a piuparts issue (tagged pending):
1104047.
Paul
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Sat, 26 Apr 2025 10:09:01 GMT) (full text, mbox, link).
Hi Noah,
On 26-04-2025 10:03, Paul Gevers wrote:
> For the record of this bug, there's a piuparts issue (tagged pending):
> 1104047.
Please also help the reverse dependencies to fix their autopkgtests
(filing bugs and/or providing patches). It seems that the new dovecot
requires an update to configuration files. Is that worth mentioning in
the release-notes too?
Paul
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Sun, 27 Apr 2025 20:39:01 GMT) (full text, mbox, link).
On Sat, Apr 26, 2025 at 12:05:31PM +0200, Paul Gevers wrote:
> > For the record of this bug, there's a piuparts issue (tagged pending):
> > 1104047.
>
> Please also help the reverse dependencies to fix their autopkgtests (filing
> bugs and/or providing patches). It seems that the new dovecot requires an
> update to configuration files. Is that worth mentioning in the release-notes
> too?
Yes, I'll post the release-notes MR tomorrow.
autopkgtests fixes are in the works. When reporting bugs against the
impacted packages, what severities and/or tags are most appropriate?
RC with 'sid' tag seems like it could be appropriate, but maybe not
necessary?
Thanks
noah
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Mon, 05 May 2025 15:51:05 GMT) (full text, mbox, link).
On Sat, Apr 26, 2025 at 12:05:31PM +0200, Paul Gevers wrote:
> Hi Noah,
>
> On 26-04-2025 10:03, Paul Gevers wrote:
> > For the record of this bug, there's a piuparts issue (tagged pending):
> > 1104047.
>
>
> Please also help the reverse dependencies to fix their autopkgtests (filing
> bugs and/or providing patches). It seems that the new dovecot requires an
> update to configuration files. Is that worth mentioning in the release-notes
> too?
All rdeps have fixed autopkgtests at this point. Only
dovecot-fts-xapian isn't uploaded yet (pending maintainer action on
https://salsa.debian.org/debian/dovecot-fts-xapian/-/merge_requests/3)
One of these rdeps actually found a dovecot regression with its
autopkgtests, which is now fixed, so that's nice...
noah
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 13:03:02 GMT) (full text, mbox, link).
Hi Noah,
On Thu, 08 May 2025 10:10:06 +0200 Simon Josefsson <[email protected]>
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? In the latter case, the Breaks and versioned Depends are
appropriate. In the former case I can get the tests to be scheduled to
use both packages from unstable. (And I wonder the same about the other
autopkgtest failures triggered by dovecot).
For avoidance of doubt, if we think these are only test failures and not
user facing failures, I rather avoid further upload before things
migrate to testing.
Paul
Acknowledgement sent
to Simon Josefsson <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 14:42:03 GMT) (full text, mbox, link).
Paul Gevers <[email protected]> writes:
> Hi Noah,
>
> On Thu, 08 May 2025 10:10:06 +0200 Simon Josefsson
> <[email protected]> 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:.
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.
Sorry for not really answering your question, but maybe the above helps
you make a better assessment of the situation than I'm able to.
/Simon
> In the latter case, the Breaks and versioned Depends are
> appropriate. In the former case I can get the tests to be scheduled to
> use both packages from unstable. (And I wonder the same about the
> other autopkgtest failures triggered by dovecot).
>
> For avoidance of doubt, if we think these are only test failures and
> not user facing failures, I rather avoid further upload before things
> migrate to testing.
/Simon
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 14:57:01 GMT) (full text, mbox, link).
Hi,
On 08-05-2025 16:39, Simon Josefsson wrote:
> 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:.
>
> 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.
What I mean is, that if a *user* would keep an older version of gsasl
and would install the new dovecot, would they see (some) broken behavior
or not? And in the reverse, if they would keep the old dovecot, but
upgraded gsasl, would that work for them? In either case it needs a
versioned relation. If the failure is only in the test (which I think
I'm reading in your explanation above), one of the two relations will
help the migration software to figure out what tests to run, but for
test only failures some maintainers feel like that's overkill. You can
add the versioned relation also to the *test* dependencies, but the
migration software doesn't inspect that itself. For the cases where
maintainers prefer not to add the relations for test only failures, I
can schedule the combination manually.
Hope this helps too.
Paul
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 14:57:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1104411: gsasl: autopkgtests fail with dovecot 2.4
Date: Thu, 8 May 2025 10:54:45 -0400
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
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 15:00:01 GMT) (full text, mbox, link).
Subject: Re: Bug#1104411: gsasl: autopkgtests fail with dovecot 2.4
Date: Thu, 8 May 2025 10:57:51 -0400
On Thu, May 08, 2025 at 04:52:36PM +0200, Paul Gevers wrote:
> > 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:.
> >
> > 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.
>
>
> What I mean is, that if a *user* would keep an older version of gsasl and
> would install the new dovecot, would they see (some) broken behavior or not?
No, there would be no issue.
> And in the reverse, if they would keep the old dovecot, but upgraded gsasl,
> would that work for them?
There would be no issue.
> In either case it needs a versioned relation. If the failure is only
> in the test (which I think I'm reading in your explanation above), one
> of the two relations will help the migration software to figure out
> what tests to run, but for test only failures some maintainers feel
> like that's overkill. You can add the versioned relation also to the
> *test* dependencies, but the migration software doesn't inspect that
> itself. For the cases where maintainers prefer not to add the
> relations for test only failures, I can schedule the combination
> manually.
The failure is only in the tests. I'm happy to do an NMU adding the
missing version constraing to gsasl's debian/tests/control if that's
useful.
noah
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 15:27:01 GMT) (full text, mbox, link).
Hi,
On 08-05-2025 16:54, Noah Meyerhans wrote:
> If this is accurate,
> then adding a version constraint of (>= 1:2.4~) to the dovecot
> dependencies for the tests is the correct solution.
Yes, but as the RT is already involved, it doesn't bring us much to do
another upload just for this. So let me handle it (to speed up
migration). If I didn't misinterpret the state, we're mostly (only)
waiting for the dovecot-fts-xapian upload.
Paul
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Thu, 08 May 2025 15:33:01 GMT) (full text, mbox, link).
Subject: Re: Bug#1104411: gsasl: autopkgtests fail with dovecot 2.4
Date: Thu, 8 May 2025 11:30:07 -0400
On Thu, May 08, 2025 at 05:25:41PM +0200, Paul Gevers wrote:
> > If this is accurate,
> > then adding a version constraint of (>= 1:2.4~) to the dovecot
> > dependencies for the tests is the correct solution.
>
> Yes, but as the RT is already involved, it doesn't bring us much to do
> another upload just for this. So let me handle it (to speed up migration).
> If I didn't misinterpret the state, we're mostly (only) waiting for the
> dovecot-fts-xapian upload.
Sounds good, thank you.
The dovecot-fts-xapian upload is still pending maintainer attention on
https://salsa.debian.org/debian/dovecot-fts-xapian/-/merge_requests/3.
I suggested there that I'd NMU it today if I didn't hear otherwise from
the maintainer, so expect the upload soon.
noah
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Sun, 11 May 2025 09:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Sun, 11 May 2025 13:51:01 GMT) (full text, mbox, link).
Subject: Re: Bug#1100698: Bug#1104411: gsasl: autopkgtests fail with dovecot
2.4
Date: Sun, 11 May 2025 09:49:50 -0400
On Sun, May 11, 2025 at 11:09:20AM +0200, Paul Gevers wrote:
> > The dovecot-fts-xapian upload is still pending maintainer attention on
> > https://salsa.debian.org/debian/dovecot-fts-xapian/-/merge_requests/3.
> > I suggested there that I'd NMU it today if I didn't hear otherwise from
> > the maintainer, so expect the upload soon.
>
>
> It seems that the autopkgtest fails consistently on i386. The log isn't all
> that clear, so I didn't spot why.
>
> https://ci.debian.net/packages/d/dovecot-fts-xapian/testing/i386/
> https://ci.debian.net/packages/d/dovecot-fts-xapian/unstable/i386/
I'm looking into it. Dovecot-lda (one of the mail delivery components)
is segfaulting within the dovecot-fts-xapian plugin. It's crashing when
attempting to operate on an uninitialized structure that it receives
from dovecot as part of the plugin interface. What's not yet clear is
whether dovecot has not correctly initialized the datastructure or
whether the plugin is failing to cope with a legitimate state. Also
unclear why this is only happening on i386. Other 32-bit architectures
aren't impacted.
noah
Acknowledgement sent
to Paul Gevers <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Sun, 11 May 2025 14:03:01 GMT) (full text, mbox, link).
Hi,
On 11-05-2025 15:49, Noah Meyerhans wrote:
> Also
> unclear why this is only happening on i386. Other 32-bit architectures
> aren't impacted.
.oO(time_t 64 vs 32 bits?)
Paul
Acknowledgement sent
to Noah Meyerhans <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <[email protected]>.
(Tue, 13 May 2025 00:51:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1100698: Bug#1104411: gsasl: autopkgtests fail with dovecot
2.4
Date: Mon, 12 May 2025 20:46:12 -0400
On Sun, May 11, 2025 at 04:01:18PM +0200, Paul Gevers wrote:
> > Also
> > unclear why this is only happening on i386. Other 32-bit architectures
> > aren't impacted.
>
> .oO(time_t 64 vs 32 bits?)
Yep. It turns out that dovecot was using a 64-bit time_t internally,
even on i386. While this may have been OK within dovecot, it broke
out-of-tree extensions like dovecot-fts-xapian. I've disabled this
behavior on i386 in 2.4.1+dfsg1-4, just uploaded.
This will require a binNMU of dovecot-fts-xapian on i386. Other
architectures will not need to be rebuilt.
noah
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.