Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Hi, Paul Gevers писал 2022-03-06 21:36: > Hi Lev, > > On 06-03-2022 11:30, dogs...@riseup.net wrote: >> As I can see, there is only one reverse build-dependency on swi-prolog >> apart from eye and logol, that is ppl. It is a C++ library providing >> SWI-Prolog interface. I tried to build it against swi-prolog from >> unstable on amd64 porterbox and the build was successful (including >> tests, which are unfortunately not autopkgtest-ready). > > Is this enough to say the ABI change doesn't effect ppl? I'm not sure whether ppl depends and/or somehow uses some particular swi-prolog ABI, I tried to run tests from ppl source package with ppl and swi-prolog binary packages installed (from unstable), but with no success. I just don't know right now how to run them correctly (these are C++ source code, as far as I can tell). So, CCing uploaders of ppl. Tobias, Michael, is it possible that ABI changes in swi-prolog may break binaries of ppl in unstable? How can we test it? As quoted above, I already tried to build ppl against the newest swi-prolog in unstable, and ppl was built successfully. Regards, Lev
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Paul Gevers писал 2022-03-06 01:09:
> Hi Lev,
>
> On 04-03-2022 11:42, dogs...@riseup.net wrote:
>>> Do you confirm that this ABI change doesn't effect the other reverse
>>> build dependencies of src:swi-prolog? If that's the case I'm fine with
>>> removing the block. But I'm afraid (without checking from my side)
>>> that the other package don't have the right virtual ABI package in
>>> their dependencies. If they do, wouldn't they need a rebuild too?
>>
>> New upstream version of eye was uploaded the same day as new version
>> of swi-prolog (in fact, after swi-prolog), and its autopkgtests pass
>> with swi-prolog in unstable (on amd64, and these are "not a regression"
>> on other architectures; they never were successful since at least Nov
>> 2019, as I can see).
>>
>> And eye already does this:
>>
>> Package: eye
>> Depends:
>> swi-prolog-nox,
>> swi-prolog-abi-${prolog:ABI},
>> ${misc:Depends}
>
> I already mentioned `eye` explicitly in my earlier messages, I wasn't
> worried about it. Please comment on the other reverse build
> dependencies (apart from eye and logol).
As I can see, there is only one reverse build-dependency on swi-prolog
apart from eye and logol, that is ppl. It is a C++ library providing
SWI-Prolog interface. I tried to build it against swi-prolog from
unstable on amd64 porterbox and the build was successful (including
tests, which are unfortunately not autopkgtest-ready).
Regards,
Lev
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Paul Gevers писал 2022-03-04 00:46:
> Hi Lev,
>
> On 03-03-2022 08:46, dogs...@riseup.net wrote:
>> swi-prolog package (namely, swi-prolog-core) provides an easy way to
>> require some particular ABI since 8.2.0+dfsg-2 uploaded on Jun 9, 2020.
>> Specifically, in this case logol requires version 67 of binary ABI
>> (pre-compiled Prolog code), where the version of swi-prolog in unstable
>> is at version 68. In case of logol, its fixed version needs to depend on
>> swi-prolog-binary-68 (again, provided by swi-prolog-core). In this case
>> it will be easier to track problems with ABI changes.
>>
>> There are more ABI stuff in swi-prolog which can be tracked the same
>> way.
>> It is documented in d/Debian.NEWS and d/README.Debian and there are
>> references to SWI-Prolog upstream reference guide. More specifically,
>> swi-prolog provides 5 virtual packages, each of them containing (a part)
>> of some specific ABI version claimed by the current swi-prolog version.
>> All these components are extensively documented in SWI-Prolog upstream
>> reference guide.
>>
>> These virtual packages were introduced to prevent the same
>> ABI-incompatibility problems with another Debian package, eye.
>
> Do you confirm that this ABI change doesn't effect the other reverse
> build dependencies of src:swi-prolog? If that's the case I'm fine with
> removing the block. But I'm afraid (without checking from my side)
> that the other package don't have the right virtual ABI package in
> their dependencies. If they do, wouldn't they need a rebuild too?
New upstream version of eye was uploaded the same day as new version
of swi-prolog (in fact, after swi-prolog), and its autopkgtests pass
with swi-prolog in unstable (on amd64, and these are "not a regression"
on other architectures; they never were successful since at least Nov
2019, as I can see).
And eye already does this:
Package: eye
Depends:
swi-prolog-nox,
swi-prolog-abi-${prolog:ABI},
${misc:Depends}
> Also, if logol is already doing the right thing, shouldn't you as the
> uploader of swi-prolog request a binNMU for logol to enable your
> package to migrate at all? I mean, I would expect the migration to
> become blocked by uninstallability of logol in testing without a
> rebuild.
Hmmm... I'm not quite sure what would be the better option for logol
and swi-prolog. If logol depends on swi-prolog-abi-binary-68, then
change of ABI will require changing dependencies by hand. If logol
depends on swi-prolog-abi-binary-$(prolog:ABI) as eye does (prolog:ABI
should be handled in d/rules) and _not_ build-depend on it (but
just build-depend on swi-prolog without version), then binNMU is
possible. I think the latter is the easier way. What do you think,
guys?
Regards,
Lev
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Hi Paul, Paul Gevers писал 2022-03-03 00:44: > On 01-03-2022 12:01, Paul Gevers wrote: >> This "fix" suggest there may be more breakage, normally the Release Team >> would schedule binNMU's. Can you please elaborate how ABI is normally >> maintained within swi-prolog, such that the rebuilds can be detected and >> requested? I fail to see how in the case of logol and swi-prolog the right >> versions are chosen. In other words, I think the "fixed" logol can migrate >> to testing even if swi-prolog does not and will be broken in testing until >> swi-prolog can migrate. Normally *versioned* dependencies should prevent >> this. > > I just read the backlog of the bug report (by default, submitters of > bug reports in Debian don't get notified of messages, I missed the > discussion). It seems my worry was already raised. The bug was > reassigned to logol, so the swi-prolog maintainers missed my message. > >> I checked, there are more reverse build dependencies of swi-prolog, I'm >> afraid there's more breakage that hasn't been detected yet. (eye seems to go >> in lockstep, so that package currently seems OK). > > Maybe swi-prolog maintainers can comment. Thanks for your input. Since the problem is resolved now, could you please unblock migration of swi-prolog, logol, and eye (another package depending on swi-prolog). swi-prolog package (namely, swi-prolog-core) provides an easy way to require some particular ABI since 8.2.0+dfsg-2 uploaded on Jun 9, 2020. Specifically, in this case logol requires version 67 of binary ABI (pre-compiled Prolog code), where the version of swi-prolog in unstable is at version 68. In case of logol, its fixed version needs to depend on swi-prolog-binary-68 (again, provided by swi-prolog-core). In this case it will be easier to track problems with ABI changes. There are more ABI stuff in swi-prolog which can be tracked the same way. It is documented in d/Debian.NEWS and d/README.Debian and there are references to SWI-Prolog upstream reference guide. More specifically, swi-prolog provides 5 virtual packages, each of them containing (a part) of some specific ABI version claimed by the current swi-prolog version. All these components are extensively documented in SWI-Prolog upstream reference guide. These virtual packages were introduced to prevent the same ABI-incompatibility problems with another Debian package, eye. Cheers! Lev
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Hi Olivier! > ok, > I uploaded logol 1.7.9+dfsg-2 built against swi-prolog 8.4.2 and > closing the issue with upload. > Let's see what happens for migration. Thank you!
Bug#1006578: swi-prolog: FTBFS with OpenSSL 3.0
Hi Sebastian, Sebastian Andrzej Siewior писал 2022-02-28 03:41: > Source: swi-prolog > Version: 8.2.4+dfsg-1 > Severity: important > Tags: bookworm sid > User: pkg-openssl-de...@lists.alioth.debian.org > Usertags: ftbfs-3.0 > > Your package is failing to build using OpenSSL 3.0 with the > following error: > > | /<>/packages/ssl/crypto4pl.c: In function ‘get_padding’: > | /<>/packages/ssl/crypto4pl.c:851:69: error: > ‘RSA_SSLV23_PADDING’ undeclared (first use in this function); did > you mean ‘RSA_X931_PADDING’? > | 851 | else if ( a == ATOM_sslv23 && mode == RSA_MODE ) > *padding = RSA_SSLV23_PADDING; > | | >^~ > | | >RSA_X931_PADDING > | /<>/packages/ssl/crypto4pl.c:851:69: note: each > undeclared identifier is reported only once for each function it > appears in This is version of swi-prolog from testing, newer version in unstable, 8.4.2+dfsg-2, should compile clean against OpenSSL 3.0. Sorry, at the moment I cannot test it by myself. Could you re-run your build test for the version in unstable? With regards, Lev
Bug#1006384: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Dear Olivier, sorry for the delay with my message and thanks for your input. olivier sallou писал 2022-02-25 12:12: > ok, > after a quick look, issue is Logol is compiled against swi-prolog, and > there is an ABI issue I think, getting error: > > incompatible version (file: 67, Prolog: 68)] > > Recompiling logol in sid against swi-prolog 8.4.2+dfsg-2 results in > correct execution/tests. > > So, 2 things: > > * As swi-prolog is only a debian update (-1 to -2), I wonder why we > have this break now > * Possible fix is to rebuild logol package against this version in > sid, with a dep requirement on swi-prolog>=8.4.2+dfsg-2. But I don't > know how this should be managed (logol in testing will still prevent > swi-prolog to go, and logol in sid won't either go to testing because > will need swi-prolog version from sid...) It is not just Debian update. I've uploaded new upstream version of SWI-Prolog on Feb 15 (upgrade from 8.2.4 to 8.4.2). It is a new major update of stable branch of SWI-Prolog, and it breaks compatibility. As I can see logol tests failed already with 8.4.2+dfsg-1. There was an issue with ODBC support for SWI-Prolog on 32-bit platforms, so I uploaded 8.4.2+dfsg-2 fixing this issue. I think swi-prolog and (updated) logol may migrate simultaneously as it is the case for swi-prolog and eye (another package depending on swi-prolog). Otherwise, we could ask someone from Debian Release team to trigger the migration for the involved packages. Cheers! Lev > Le jeu. 24 févr. 2022 à 19:36, Paul Gevers a > écrit : > >> Source: swi-prolog, logol >> Control: found -1 swi-prolog/8.4.2+dfsg-2 >> Control: found -1 logol/1.7.9+dfsg-1 >> Severity: serious >> Tags: sid bookworm >> X-Debbugs-CC: debian...@lists.debian.org >> User: debian...@lists.debian.org >> Usertags: breaks needs-update >> >> Dear maintainer(s), >> >> 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: >> >> passfail >> swi-prolog from testing8.4.2+dfsg-2 >> logol from testing1.7.9+dfsg-1 >> all others from testingfrom testing >> >> I copied some of the output at the bottom of this report. >> >> Currently this regression is blocking the migration of swi-prolog to >> >> testing [1]. Due to the nature of this issue, I filed this bug >> report >> against both packages. Can you please investigate the situation and >> reassign the bug to the right package? >> >> More information about this bug and the reason for filing it can be >> found on >> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation >> >> Paul >> >> [1] https://qa.debian.org/excuses.php?package=swi-prolog >> >> > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/19529867/log.gz >> >> calling logol with parameters -g 1799.logol -s 1799.fasta -dna >> log4j:ERROR setFile(null,true) call failed. >> java.io.FileNotFoundException: /var/log/logol/logol.log (Permission >> denied) >> at java.base/java.io [1].FileOutputStream.open0(Native >> Method) >> at java.base/java.io >> [1].FileOutputStream.open(FileOutputStream.java:298) >> at java.base/java.io >> [1].FileOutputStream.(FileOutputStream.java:237) >> at java.base/java.io >> [1].FileOutputStream.(FileOutputStream.java:158) >> at >> org.apache.log4j.FileAppender.setFile(FileAppender.java:294) >> at >> org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) >> at >> > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) >> at >> > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) >> at >> > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) >> at >> > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) >> at >> > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) >> at >> > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) >> at >> > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) >> at >> > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) >> at >> > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) >> at org.apache.log4j.LogManager.(LogManager.java:127) >> at org.apache.log4j.Logger.getLogger(Logger.java:117) >> at org.irisa.genouest.logol.Logol.(Unknown Source) >> For help, use option -h >> INFO org.irisa.genouest.logol.Logol - Using configuration file: >> /usr/share/logol/prolog/logol.properties >> INFO org.irisa.genouest.logol.Logol - option g called with >> 1799.logol >> INFO org.irisa.genouest.logol.Logol - option s called with >> 1799.fasta >> INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, >> >> using defaults >> INFO
Bug#1005887: unixodbc-dev does not contain unixodbc_conf.h
Hi Hugh,
Thanks for your reply.
Hugh McMaster писал 2022-02-19 14:11:
> Hi Lev,
>
> Thank you for the bug report.
>
> On Thu, 17 Feb 2022 at 04:45, Lev Lamberov wrote:
>>
>> unixodbc-dev does not ship unixodbc_conf.h (at least, on amd64 and
>> i386). The version in stable does ship it, but the version in testing
>> and unstable does not.
>>
>> It breaks builds of some packages, e. g. build of swi-prolog fails for
>> 32-bit architectures. 32-bit platforms support 64-bit integers and
>> actually all should as SWI-Prolog cannot work without them. There is a
>> suggestion that somehow SQLBIGINT is not configured correctly. More
>> specifically, the missing unixodbc_conf.h should contain either both
>> or one of
>>
>> #define HAVE_LONG_LONG 1
>> #define SIZEOF_LONG_INT 8
>
> unixodbc_conf.h is not really intended for use by downstream packages.
> Most of the #defines it contains are internal and reflect the system
> unixodbc was compiled on.
>
> Your build is broken because HAVE_LONG_LONG is not defined by cmake.
> This #define is needed by sqltypes.h. In general, you need to define
> this macro yourself.
>
> I took a look at the odbc package module in swi-prolog. While
> SIZEOF_LONG_LONG is defined, the corresponding existence variable is
> HAVE_SIZEOF_LONG_LONG.
>
> You need to patch the source in packages/ocbc/CMakeLists.txt to pass
> LONG_LONG as the second argument to check_type_size().
>
> -check_type_size("long long" SIZEOF_LONG_LONG)
> +check_type_size("long long" LONG_LONG)
>
> This way, HAVE_LONG_LONG is defined as true and the build completes as
> expected.
>
> I'll look into defining HAVE_LONG_LONG in sqltypes.h to avoid this
> problem with other packages.
I forwarded your reply to the swi-prolog upstream. Haven't tested your
suggestion yet. Hope to take a look into it a bit later.
And I think it would be great to have HAVE_LONG_LONG defined on the
side of unixodbc.
Cheers!
Lev
