Вс 23 окт 2022 @ 09:16 Paul Gevers <elb...@debian.org>: > Hi Lev, > > On 23-10-2022 09:08, Lev Lamberov wrote: >> Сб 22 окт 2022 @ 21:27 Paul Gevers <elb...@debian.org>: >>> With a recent upload of swi-prolog the autopkgtest of logol fails in >>> testing when that autopkgtest is run with the binary packages of >>> swi-prolog from unstable. It passes when run with only packages from >>> testing. In tabular form: >> >> I've tried to build the logol package against swi-prolog in unstable on >> s390x porterbox and it was successful. I'm not sure whether it runs the >> same tests as during the autopkgtest testing. Unfortunately, I cannot >> test these rebuilt logol packages on s390x at the moment. The last >> change in the swi-prolog package was related to a bug concerning broken >> handling of endiannes (the bug was seen on s390x indeed, but not on >> other architectures). Now swi-prolog should correctly handle it. >> Probably, logol needs to be rebuilt against this new swi-prolog. > > If rebuilding is "the" solution, the change in swi-prolog feels like an > ABI breakage (on big endian architectures), right? If that's true, what > about the other reverse build dependencies of swi-prolog? Should all of > them be rebuild? ... Hmm, we're only talking about ppl in addition to > logol here.
I'm not sure it is the solution, it needs testing. The change in swi-prolog concerns pre-compiled prolog source code, when there is no pre-complied prolog code rebuilt is not needed. SWI-Prolog supports three different kinds of pre-compilation, at least one of them was affected and another was not. The mentioned endiannes bug can be found in BTS, #1006818 [bts]. As I can see, ppl provides pretty simple prolog-interface to libppl, and it does not rely to pre-compiled prolog code. [bts] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006818 Cheers! Lev
