On Wed, 11 Feb 2026 09:03:39 +0100 marillat
<[email protected]> wrote:
> It would be interesting to know how you ended up having libwinpr2-2t64
> (with the t64 suffix) on an oldstable system.
Again from Debian. 2.11.7+dfsg1-6 has been packaged in Debian oldstable.
I am not the only one.
https://snapshot.debian.org/binary/libwinpr2-2t64/
,----
| Binary package libwinpr2-2t64
|
| Available versions:
|
| 2.11.7+dfsg1-6 (source: freerdp2 2.11.7+dfsg1-6)
| 2.11.7+dfsg1-5 (source: freerdp2 2.11.7+dfsg1-5)
snapshot.d.o doesn't tell if these packages has been in
bookworm or not.
This is quite messy.
I see 2.11.7+dfsg1-6~deb12u1 in bookworm - which has no t64 suffix.
2.11.5+dfsg1-1 is the first version with t64 suffix, uploaded at
Mon, 15 Jul 2024 16:46:25 +0200 - this is after bookworm has been
released, so it, and subsequent versions up to -6, weren't part of
bookworm. Only -6~deb12u1 was, and that one has no t64 suffix again.
No t64 libraries must appear in bookworm, if there are, it's really
a serious bug. But it is only problematic for 32bit systems, there's
no issue for 64bit systems.
So I'm still curious how you ended with a t64 package in bookworm when
it weren't part of bookworm.
But all this does not make sense in context of this bug report, -- I
uploaded a version which has Replaces: for the file in question, for
both variants of the package name (with and without t64).
The bug exists regardless of the presence of t64 in the package name
you've installed on bookworm - both variants has the same file so
trigger the same conflict.
And I still disagree wrt the severity - release notes clearly state to
remove obsolete packages, which you obviously didn't do.
Thanks,
/mjt