On Mon, Apr 06, 2026 at 02:08:17PM +0300, Michael Tokarev wrote: > > > I weren't aware of this change. With this change in mind, yes, it is > > > a good reason NOT to push 2.4.2 to trixie. > > > > BTW, you can do it other way around: package 2.4.2 for trixie and > > revert > > > that particular pcre change to keep it compatible with the trixie > > > behavior. That'd be fun though. > > > > "fun" yeah. > > > > It is definitely not an ideal situation. > > > > > > Given the above, I expect to continue backporting fixes for 2.4.1 while > > > > trixie is stable. Do you have any specific fixes you're looking for, or > > > > is this a general request? > > > > No, unfortunately not. I see my dovecot in trixie is crashing > > (rarely > > > but surely), and my questions to upstream about this got suggestions to > > > upgrade to the current version (2.4.2) only, so far. Yes, I'll try to > > > install 2.4.2 (debian package in forky built for trixie) just to see if > > > it changes this particular problem. Debugging were not successful so > > > far, either. > > > > What component is crashing for you? > > > > If you're able to get a stack trace, that might help track down a fix > > upstream, assuming the issue has been fixed in 2.4.2. It's entirely > > possible that it is, as they've fixed quite a few crashes. > > After updating my install to 2.4.2, the crashes continued, but I weren't > able to get a real stack trace, as it happens rarely. It is fts/index > corruption and an assortment of issues when dealing with corrupt index. > > Upstream suggested it is some old corruption which is revealed now. The > fact the crashes occurs less and less often, also suggests it might be > the case. > > Now, it's an interesting situation. I can try to downgrade dovecot sw > back to trixie version (which will require recompiling sieve scripts), > in a hope the problem is fixed. But the prob might reappear there.
Thanks for the update. > > > Either way, I'm not uploading it just yet, let's see about the bug. > > > If it's fixed in 2.4.2, we can pick up that particular change to trixie. > > > > That would be ideal. If you do end up looking to upload to > > trixie-backports, I'd like to ask that you maintain the backport in a > > branch in https://salsa.debian.org/debian/dovecot/ > > I upgraded to 2.4.3 now (btw, 2.4.3 upload to debian FTBFS on buildds), > let's see how it will do. Apparently I'll have to maintain the backport > in the end :) I had almost convinced myself that we can update to a newer upstream version within trixie, as the behavior changes introduced by the libpcre switch were apparently regressions due to incorrect usage of that library, and have been fixed upstream. But then 2.4.3 came out that broke our autopkgtests. So I'm definitely not confident that we could safely update with an acceptable level of risk. 2.4.3 is failing to build for sid due to a socket name length issue in the test suite when built in the buildd environment. I'll have that fixed fairly soon... noah
