[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

courier-authlib encoding failing on certain architectures like s390x



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.  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.

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.

-- 
Soren Stoutner
soren@debian.org

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: