Re: courier-authlib encoding failing on certain architectures like s390x
On 12/8/25 21:25, Soren Stoutner wrote:
I am in the process of updating courier-authlib (an authentication library
used by Courier MTA) from 0.72.4-3 to 0.72.6-2. Previous builds built on
every architecture.
https://buildd.debian.org/status/package.php?p=courier-authlib
Current builds are failing on the following architectures: s390x, hppa,
powerpc, ppc64, sparc64.
Interestingly, those architectures ^^ are all big-endian.
At the time of this email, the following
architectures are awaiting build, so it is possible some of them may fail as
well: riscv64, hurd-i386, sh4.
and those are little-endian, so if they don't fail with the same error, then
it's probably a endianess issue...
Helge
https://buildd.debian.org/status/package.php?p=courier-authlib&suite=experimental
The failures are the same for each architecture, which is an encoding problem
in a test suite:
make[4]: Entering directory '/build/reproducible-path/courier-authlib-0.72.6/
libs/rfc822'
./testsuite | diff -U 5 ./testsuite.txt -
./testsuitecpp | diff -U 5 ./testsuite.txt -
--- ./testsuite.txt 2025-05-26 09:00:02.467330639 +0000
+++ - 2025-12-06 23:37:33.376674246 +0000
@@ -190,7 +190,11 @@
nobody@example.com,
"Mr. Nobody" <nobody@example.com>]
=?utf-8?B?
4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk?
=
=?utf-8?B?
4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk?
= =?utf-8?B?4oWk?=
=?utf-8?B?
4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk4oWk?
= =?utf-8?B?4oWkzIA=?=
+print_address unexpected error test results:
+Test
<00><00><04><38><00><00><04><41><00><00><04><3F><00><00><04><4B><00><00><04><42><00><00><04><30><00><00><04><3D><00><00><04><38><00><00><04><35>(decoding
error)
+test5@<00><00><04><38><00><00><04><41><00><00><04><3F><00><00><04><4B><00><00><04><42><00><00><04><30><00><00><04><3D><00><00><04><38><00><00><04><35>.net(decoding
error)
+Test
<00><00><04><38><00><00><04><41><00><00><04><3F><00><00><04><4B><00><00><04><42><00><00><04><30><00><00><04><3D><00><00><04><38><00><00><04><35>(decoding
error)
<test5@<00><00><04><38><00><00><04><41><00><00><04><3F><00><00><04><4B><00><00><04><42><00><00><04><30><00><00><04><3D><00><00><04><38><00><00><04><35>.net(decoding
error)>
NobÒdy <test3@испытание.net>, Nobody <nobody@example.com>
NobÒdy <test3@xn--80akhbyknj4f.net>, nobody@example.com
make[4]: *** [Makefile:993: check-am] Error 1
https://buildd.debian.org/status/fetch.php?pkg=courier-authlib&arch=s390x&ver=0.72.6-2&stamp=1765064254&raw=0
There are several changes that could relate to encoding issues:
1. courier-authlib depends on a new version of courier-unicode, which is
undergoing a library transition that this update depends on. Is it possible
that the new unicode library is failing to encode things on these particular
architectures for some reason.
2. As part of the courier-unicode transition, some of the code has been
rewritten in C++17. For example, the courier-unicode upstream changelog
contains the following: "ABI break. Update the C++ API to C++17. Several
functions’ std::u32string parameter replaced with a std::u32string_view,
where possible. Fill in a small functional gap, implement unicode::totitle().”
Is there some known incompatibility with C++17 code and the failing
architectures?
3. Because some of the tests use ISO-8859-1, “locales-all <!nocheck>” is now
available in Build-Depends. I can’t think of anyway that having locales-all
present would cause an encoding error, but it is the things I can’t think of
that I’m trying to find, so I figured this was worth mentioning.
The fact that this failure only happens on certain architectures is what
puzzles me, particularly because it fails the same way on these architectures.
Because I don’t know much about what makes all these failing architectures
different that all the ones that succeed, I thought I would ask here hoping
that there is something obvious that people more experienced with these
architectures might immediately notice.
Reply to: