Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
regards, Nikos
On 15. 07. 19 12:41, Nikos Mavrogiannopoulos wrote:
Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
I've recently seen an Arch Linux user ranting about this particular update on Twitter.
The tweet is unfortunately Czech only: https://twitter.com/stibi/status/1149659975070842882
I suggest we make double sure not to break X and/or Chromium.
On 15. 07. 19 12:41, Nikos Mavrogiannopoulos wrote:
Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
Nearly all of my packages now fail to resolve because of:
nothing provides libnettle.so.6()(64bit) needed by gnutls-3.6.8-1.fc31.x86_64
Why is this not done in a side tag?
On 15. 07. 19 13:24, Miro Hrončok wrote:
On 15. 07. 19 12:41, Nikos Mavrogiannopoulos wrote:
Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
Nearly all of my packages now fail to resolve because of:
nothing provides libnettle.so.6()(64bit) needed by gnutls-3.6.8-1.fc31.x86_64
Why is this not done in a side tag?
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8-1.fc31.armv7hl
On 15. 07. 19 13:54, Miro Hrončok wrote:
On 15. 07. 19 13:24, Miro Hrončok wrote:
On 15. 07. 19 12:41, Nikos Mavrogiannopoulos wrote:
Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
Nearly all of my packages now fail to resolve because of:
nothing provides libnettle.so.6()(64bit) needed by gnutls-3.6.8-1.fc31.x86_64
Why is this not done in a side tag?
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8-1.fc31.armv7hl
I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1729946
If somebody could untag nettle, that would be great.
I've done this:
$ koji tag-build f31-pending nettle-3.4.1rc1-3.fc31
But not sure if that is enough.
On Mon, Jul 15, 2019 at 2:48 PM Miro Hrončok mhroncok@redhat.com wrote:
On 15. 07. 19 13:54, Miro Hrončok wrote:
On 15. 07. 19 13:24, Miro Hrončok wrote:
On 15. 07. 19 12:41, Nikos Mavrogiannopoulos wrote:
Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
Nearly all of my packages now fail to resolve because of:
nothing provides libnettle.so.6()(64bit) needed by gnutls-3.6.8-1.fc31.x86_64
Why is this not done in a side tag?
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8-1.fc31.armv7hl
I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1729946
If somebody could untag nettle, that would be great.
I've done this:
$ koji tag-build f31-pending nettle-3.4.1rc1-3.fc31
But not sure if that is enough.
And all this could have been prevented if only the nettle update was announced and updated according to the Updates Policy ...
"When a proposed update contains an ABI or API change: notify a week in advance both fedora-devel and maintainers directly (using the packagename-owner@ alias) whose packages depend on yours to rebuild or offer to do these rebuilds for them."
https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master
I'm really looking forward to the day when pushing a build that breaks ABI to rawhide will require manual intervention.
Fabio
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Jul 15, 2019 at 9:45 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jul 15, 2019 at 2:48 PM Miro Hrončok mhroncok@redhat.com wrote:
On 15. 07. 19 13:54, Miro Hrončok wrote:
On 15. 07. 19 13:24, Miro Hrončok wrote:
On 15. 07. 19 12:41, Nikos Mavrogiannopoulos wrote:
Hi, The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
Nearly all of my packages now fail to resolve because of:
nothing provides libnettle.so.6()(64bit) needed by gnutls-3.6.8-1.fc31.x86_64
Why is this not done in a side tag?
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8-1.fc31.armv7hl
I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1729946
If somebody could untag nettle, that would be great.
I've done this:
$ koji tag-build f31-pending nettle-3.4.1rc1-3.fc31
But not sure if that is enough.
And all this could have been prevented if only the nettle update was announced and updated according to the Updates Policy ...
"When a proposed update contains an ABI or API change: notify a
week in advance both fedora-devel and maintainers directly (using the packagename-owner@ alias) whose packages depend on yours to rebuild or offer to do these rebuilds for them."
https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master
I'm really looking forward to the day when pushing a build that breaks ABI to rawhide will require manual intervention.
I know it’s beating a dead horse, but I’d rather have the buildsystem *deal* with such a trivial problem than require manual intervention. Cycling through and building things properly in order to deal with a soname bump is something our tooling should do for us.
Neal Gompa wrote:
I know it’s beating a dead horse, but I’d rather have the buildsystem *deal* with such a trivial problem than require manual intervention. Cycling through and building things properly in order to deal with a soname bump is something our tooling should do for us.
And how is the tooling supposed to do that automatically if a straightforward rebuild fails due to a circular dependency, as happened with gnutls in this case?
Kevin Kofler
The builsystem should rebuild all the other participants in the cycle against the new link, then rebuild the new link against the updated cycle, then rebuild again the rest of the cycle against the new link
If that fails, attempt to do the same with a bootstrap pass, hoping one of the cycle participants contains cycle breaking bootstrap conditionals
If that fails, refuse the update and wait till humans deal with the mess
It's not rocket science, I've already described multiple times on this list how to handle cycles gracefully, because Go is full of those
Miro Hrončok wrote:
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8-1.fc31.armv7hl
Don't you love circular dependencies?
This is really the biggest issue that we have: There are more and more circular dependencies. Each of them is a major PITA when trying to upgrade a library.
Kevin Kofler
Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
Miro Hrončok wrote:
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8- 1.fc31.armv7hl
Don't you love circular dependencies?
This is really the biggest issue that we have: There are more and more circular dependencies. Each of them is a major PITA when trying to upgrade a library.
Here[1] is a nice example of how to break the cycle by building both so- versions in a bootstrap build.
With the bootstrap build one can chain-build all consumers to use the new so-version. After that has been finished one simply rebuilds the lib without bootstrap to just get the new so-version.
Let me know if you want me to change the nettle spec file accordingly to the given example and trigger a working rebuild chain.
Cheers, Björn
[1] https://src.fedoraproject.org/rpms/json-c/blob/master/f/json-c.spec
Björn 'besser82' Esser wrote:
Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
Miro Hrončok wrote:
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8- 1.fc31.armv7hl
Don't you love circular dependencies?
This is really the biggest issue that we have: There are more and more circular dependencies. Each of them is a major PITA when trying to upgrade a library.
Here[1] is a nice example of how to break the cycle by building both so- versions in a bootstrap build.
I don't like this example, at all. This puts the burden of working around the circular dependency on the library, which is likely not even part of the actual cycle. (It just happens to be used by something that has a circular dependency and that hence cannot be simply rebuilt against the new version of the library.)
The original idea of bootstrap builds was to actually break the cycle, e.g., to find a way to build gnutls without requiring gnutls itself. This is usually done by disabling some optional functionality in some library. But of course, it only works if upstream did think of the bootstrap issue and actually made the circular dependency optional. If all dependencies in the cycle are mandatory, we are stuck.
But your approach of stuffing 2 versions of a library in a single RPM is a really ugly hack that really should not be needed. But it is getting used more and more often because of a lack of proper bootstrap logic (or of upstream support for it).
Kevin Kofler
Am Dienstag, den 16.07.2019, 12:00 +0200 schrieb Kevin Kofler:
Björn 'besser82' Esser wrote:
Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
Miro Hrončok wrote:
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8- 1.fc31.armv7hl
Don't you love circular dependencies?
This is really the biggest issue that we have: There are more and more circular dependencies. Each of them is a major PITA when trying to upgrade a library.
Here[1] is a nice example of how to break the cycle by building both so- versions in a bootstrap build.
I don't like this example, at all. This puts the burden of working around the circular dependency on the library, which is likely not even part of the actual cycle. (It just happens to be used by something that has a circular dependency and that hence cannot be simply rebuilt against the new version of the library.)
We have a circular dependency in the minimal buildroot:
systemd --> cryptsetup-libs --> json-c
cryptsetup needs json-c for LUKS2 and there is no option to disable LUKS2 during build.
However systemd can *possibly* be build without support for cryptsetup.
The original idea of bootstrap builds was to actually break the cycle, e.g., to find a way to build gnutls without requiring gnutls itself. This is usually done by disabling some optional functionality in some library. But of course, it only works if upstream did think of the bootstrap issue and actually made the circular dependency optional. If all dependencies in the cycle are mandatory, we are stuck.
Technically I could do a bootstrap build of systemd without cryptsetup, but that would touch a package, which does not have a direct dependency on json-c, and thus wouldn't need to be rebuilt in any cycle at all.
But your approach of stuffing 2 versions of a library in a single RPM is a really ugly hack that really should not be needed. But it is getting used more and more often because of a lack of proper bootstrap logic (or of upstream support for it).
In my conclusion I consider it to be "cleaner" to have a build with two versions of a library for a *single* step of the whole rebuild process involved, then to touch an unrelated package to break the dependency cycle.
Which build chain does look cleaner, shorter, and more semantically correct?
1. systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup --> systemd (with cryptsetup) --> other consumers in chains
2. json-c (double so-ver) --> cryptsetup and all other consumers --> json-c (new so-ver)
Le mardi 16 juillet 2019 à 18:53 +0200, Björn 'besser82' Esser a écrit :
Which build chain does look cleaner, shorter, and more semantically correct?
systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup --> systemd (with cryptsetup) --> other consumers in chains
json-c (double so-ver) --> cryptsetup and all other consumers --> json-c (new so-ver)
The second may look shorter but it is certainly not more correct. At the end of it you still can't be sure everything has been built using the new so-ver, so you need to add at least one rebuild stage using the new json-c to be sure the result is self-hosting.
Any way you look at it, the last stage should involve rebuilding all dependant packages over a repo state that includes only the final state of the changed package, or you may unadvertently still depend on things you think you removed
Am Dienstag, den 16.07.2019, 19:26 +0200 schrieb Nicolas Mailhot via devel:
Le mardi 16 juillet 2019 à 18:53 +0200, Björn 'besser82' Esser a écrit :
Which build chain does look cleaner, shorter, and more semantically correct?
systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup --> systemd (with cryptsetup) --> other consumers in chains
json-c (double so-ver) --> cryptsetup and all other consumers --> json-c (new so-ver)
The second may look shorter but it is certainly not more correct. At the end of it you still can't be sure everything has been built using the new so-ver, so you need to add at least one rebuild stage using the new json-c to be sure the result is self-hosting.
Any way you look at it, the last stage should involve rebuilding all dependant packages over a repo state that includes only the final state of the changed package, or you may unadvertently still depend on things you think you removed
That example was a bit shortened…
My actual build-chain in that case is:
json-c (double so-ver) --> cryptsetup --> json-c (new so-ver) --> all other consumers
Björn 'besser82' Esser wrote:
We have a circular dependency in the minimal buildroot:
systemd --> cryptsetup-libs --> json-c
cryptsetup needs json-c for LUKS2 and there is no option to disable LUKS2 during build.
However systemd can *possibly* be build without support for cryptsetup.
Why does the minimal buildroot need to contain systemd at all? It does nothing in a chroot. If we can get that fixed, the many dependencies of systemd shouldn't be a bootstrapping issue anymore.
Kevin Kofler
Because of systemd-libs… It is a dependency of util-linux at least. That ships logger and lslogins utilities which link against libsystemd.
On Tue, Jul 16, 2019 at 8:42 PM Kevin Kofler kevin.kofler@chello.at wrote:
Björn 'besser82' Esser wrote:
We have a circular dependency in the minimal buildroot:
systemd --> cryptsetup-libs --> json-c
cryptsetup needs json-c for LUKS2 and there is no option to disable LUKS2 during build.
However systemd can *possibly* be build without support for cryptsetup.
Why does the minimal buildroot need to contain systemd at all? It does nothing in a chroot. If we can get that fixed, the many dependencies of systemd shouldn't be a bootstrapping issue anymore.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Am Dienstag, den 16.07.2019, 19:49 +0200 schrieb Kevin Kofler:
Björn 'besser82' Esser wrote:
We have a circular dependency in the minimal buildroot:
systemd --> cryptsetup-libs --> json-c
cryptsetup needs json-c for LUKS2 and there is no option to disable LUKS2 during build.
However systemd can *possibly* be build without support for cryptsetup.
Why does the minimal buildroot need to contain systemd at all? It does nothing in a chroot. If we can get that fixed, the many dependencies of systemd shouldn't be a bootstrapping issue anymore.
Which even then would still remain an issue, as cryptsetup build- requires device-mapper-devel, which requires systemd for some unknown reason…
Björn 'besser82' Esser wrote:
Which even then would still remain an issue, as cryptsetup build- requires device-mapper-devel, which requires systemd for some unknown reason…
My idea is that the minimal buildroot should contain a fake package that Obsoletes and Provides: systemd. Maybe it can be completely empty, maybe it needs to contain at least a dummy implementation of systemctl to make the scriptlets not fail, but it should contain as little as possible and have as few dependencies as possible (ideally, only glibc and libgcc). So whatever requires systemd won't actually get it in the buildroot.
Kevin Kofler
On Tue, Jul 16, 2019 at 5:34 AM Björn 'besser82' Esser besser82@fedoraproject.org wrote:
Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
Miro Hrončok wrote:
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8- 1.fc31.armv7hl
Don't you love circular dependencies?
This is really the biggest issue that we have: There are more and more circular dependencies. Each of them is a major PITA when trying to upgrade a library.
The common workaround is to provide a compatibility library for a limited period, with very careful handling of "Provides" and "Obsoletes" and "Conlicts" until the discrepancy is resolved. This has happened with gcc multiple times.
Here[1] is a nice example of how to break the cycle by building both so- versions in a bootstrap build.
With the bootstrap build one can chain-build all consumers to use the new so-version. After that has been finished one simply rebuilds the lib without bootstrap to just get the new so-version.
Let me know if you want me to change the nettle spec file accordingly to the given example and trigger a working rebuild chain.
Cheers, Björn
[1] https://src.fedoraproject.org/rpms/json-c/blob/master/f/json-c.spec _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, 2019-07-16 at 06:37 -0400, Nico Kadel-Garcia wrote:
On Tue, Jul 16, 2019 at 5:34 AM Björn 'besser82' Esser besser82@fedoraproject.org wrote:
Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
Miro Hrončok wrote:
gnutls now cannot be rebuilt:
nothing provides libnettle.so.6 needed by gnutls-3.6.8- 1.fc31.armv7hl
Don't you love circular dependencies?
This is really the biggest issue that we have: There are more and more circular dependencies. Each of them is a major PITA when trying to upgrade a library.
The common workaround is to provide a compatibility library for a limited period, with very careful handling of "Provides" and "Obsoletes" and "Conlicts" until the discrepancy is resolved. This has happened with gcc multiple times.
That makes sense when one needs to keep the old version because (1) the new API is incompatible and applications need time to update, or (2) the ABI compatibility must be retained across releases. We didn't care about either in this update (we have API-compatibile release), so indeed, if the tooling could handle such issues as it was suggested it would save lots of work. Kudos to Daiki who handled the issues that arised.
regards, Nikos
Nikos Mavrogiannopoulos nmav@redhat.com writes:
The latest nettle (3.5.1) update will break ABI on rawhide. The API remains the same hence recompilation will be sufficient to address any issues.
Thanks to the suggestion from Miro, the new nettle and gnutls built against it are now in rawhide. I am using the approach bundling 2 versions of nettle shared libs in the single package, so I will drop the old ones once the rest of packages are built.
Regards,