Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Dear Tobias, Michael, Can be please have an answer to the question below? Your lack of answer is blocking migration to testing of multiple packages. On 07-03-2022 17:28, dogs...@riseup.net wrote: Paul Gevers писал 2022-03-06 21:36: 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. Paul OpenPGP_signature Description: OpenPGP digital signature
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)
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? Paul OpenPGP_signature Description: OpenPGP digital signature
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)
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).
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?
As eye does seems like the way to go to me.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
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)
Le jeu. 3 mars 2022, 20:51, Paul Gevers a écrit : > 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? > > 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. > Hi, i have rebuilt and pushed logol in sid recompiled with the new abi. However, with lev info, i should add for later updates the swi-prolog-binary-68 dependency. Swi prolog needs to move to testing before updated logol. Olivier > Paul > > >
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
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? 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. Paul OpenPGP_signature Description: OpenPGP digital signature
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: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Hi, 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. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1006384: closed by Debian FTP Masters (reply to Olivier Sallou ) (Bug#1006384: fixed in logol 1.7.9+dfsg-2)
Dear logol and swi-prolog maintainers, On 01-03-2022 10:21, Debian Bug Tracking System wrote: Changes: logol (1.7.9+dfsg-2) unstable; urgency=medium . * Source only upload, rebuilding against swi-prolog/8.4.2+dfsg-2 after swi-prolog ABI break (Closes: #1006384). 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 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). Paul OpenPGP_signature Description: OpenPGP digital signature
