are you going to provide also a compat package for version 3.2? i don't think you can push a major upgrade of a library on EPEL as there is also a mojor soname bump
Hi Andrea, thanks for your feedback, and you are fully right in principle, either a compatibility package should be provided, or that upgrade should not reach the stable repository. I just removed the auto-push feature. So, that package will reach the stable repository only if all the parties involved actually want it.
Note that in practice, there is a single package (outside of my own packages) depending on SOCI, namely fts, your package:
As I have recently built SOCI for EPEL 8, using the opportunity that SOCI 4.0.0-RCx has just been released (it is not so often that upstream make a release at all), I thought that this new version could be beneficial to EPEL 7 too. But I cannot spend too much time on it either. Normally, just a rebuild is necessary (soci-4.0.0 is already in the buildroot; so, launching a Koji/fedpkg build of your package should be enough). If you want, I can do it for you.
So, the easiest and quickest option would be to launch a rebuild of your package (fts), and if you are fine with the result, soci-4.0.0 can reach the stable repository on EPEL 7 when it is stable enough (in 12 days or something).
But if you do not want, and prefer to stick to soci-3.2, then no problem, I'll cancel soci-4.0.0 on EPEL 7.
thanks a lot for your reply and for your action. i tried also a local build and my component was fine with that version, but i would like to do more testing of course to see that everything is fine.
We are also about to release a new version of the component and indeed i wanted to tell you to wait to rebuild until we are ready, but you were too fast:-)
i will let you know in case i find issues with my testing, but in principle i'm fine to just release a new build. If we are the only users of this package (strange!) we don't need to spend time on compatibility packages and the like.
If you find any issue, then please speak up so that I can stop this update to reach the stable repository.
As a matter of fact, technically speaking your package is not the only one to use SOCI; there are at least 10 other packages depending on SOCI... but they are all mines! That is why I packaged SOCI in the first place :)
Since SOCI was getting old (there has not been any release for at least the last 5 years), when building Docker images for instance, I had to release SOCI manually in /opt from the Git master branch, which was pretty bad for reproducibility/maintenance (on CentOS 7, it was fine though). Now that they eventually release the very long-awaited 4.0.0 version, I take that opportunity to replace all those custom builds by properly packaged SOCI. And there is no reason that CentOS 7 should not enjoy the upgrade too :)
I guess that it would be better to create an issue upstream: https://github.com/SOCI/soci/issues
It may be easier if you first install the debugging symbols (with something like sudo debuginfo-install soci-devel)
This update has been submitted for testing by denisarnaud.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
Hello,
are you going to provide also a compat package for version 3.2? i don't think you can push a major upgrade of a library on EPEL as there is also a mojor soname bump
thanks
Andrea
denisarnaud edited this update.
Hi Andrea, thanks for your feedback, and you are fully right in principle, either a compatibility package should be provided, or that upgrade should not reach the stable repository. I just removed the auto-push feature. So, that package will reach the stable repository only if all the parties involved actually want it.
Note that in practice, there is a single package (outside of my own packages) depending on SOCI, namely fts, your package:
As I have recently built SOCI for EPEL 8, using the opportunity that SOCI 4.0.0-RCx has just been released (it is not so often that upstream make a release at all), I thought that this new version could be beneficial to EPEL 7 too. But I cannot spend too much time on it either. Normally, just a rebuild is necessary (soci-4.0.0 is already in the buildroot; so, launching a Koji/fedpkg build of your package should be enough). If you want, I can do it for you.
So, the easiest and quickest option would be to launch a rebuild of your package (fts), and if you are fine with the result, soci-4.0.0 can reach the stable repository on EPEL 7 when it is stable enough (in 12 days or something). But if you do not want, and prefer to stick to soci-3.2, then no problem, I'll cancel soci-4.0.0 on EPEL 7.
Kind regards
Denis
Ok, a new update of fts has just been submitted, based on SOCI 4.0.0. So, all should be fine by now then.
denisarnaud edited this update.
Hi Denis,
thanks a lot for your reply and for your action. i tried also a local build and my component was fine with that version, but i would like to do more testing of course to see that everything is fine.
We are also about to release a new version of the component and indeed i wanted to tell you to wait to rebuild until we are ready, but you were too fast:-)
i will let you know in case i find issues with my testing, but in principle i'm fine to just release a new build. If we are the only users of this package (strange!) we don't need to spend time on compatibility packages and the like.
thanks
Andrea
Thanks for your kind words!
If you find any issue, then please speak up so that I can stop this update to reach the stable repository. As a matter of fact, technically speaking your package is not the only one to use SOCI; there are at least 10 other packages depending on SOCI... but they are all mines! That is why I packaged SOCI in the first place :)
Since SOCI was getting old (there has not been any release for at least the last 5 years), when building Docker images for instance, I had to release SOCI manually in /opt from the Git master branch, which was pretty bad for reproducibility/maintenance (on CentOS 7, it was fine though). Now that they eventually release the very long-awaited 4.0.0 version, I take that opportunity to replace all those custom builds by properly packaged SOCI. And there is no reason that CentOS 7 should not enjoy the upgrade too :)
ok, i'm running tests and everything looks ok so far
i have just updated the FTS update to remove autopush BTW
thanks Andrea
This update has been obsoleted by soci-4.0.0-2.el7.
Hi Denis unfortunately i have a problem with the latest soci. Sometimes our server crashes with a SIGABRT and this is what i see within gdb
0 0x00007f453bd52337 in raise () from /lib64/libc.so.6
1 0x00007f453bd53a28 in abort () from /lib64/libc.so.6
2 0x00007f453c6627d5 in _gnu_cxx::_verbose_terminate_handler() () from /lib64/libstdc++.so.6
3 0x00007f453c660746 in ?? () from /lib64/libstdc++.so.6
4 0x00007f453c65f6f9 in ?? () from /lib64/libstdc++.so.6
5 0x00007f453c660364 in __gxx_personality_v0 () from /lib64/libstdc++.so.6
6 0x00007f453c0f98a3 in ?? () from /lib64/libgcc_s.so.1
7 0x00007f453c0f9dd7 in _Unwind_Resume () from /lib64/libgcc_s.so.1
8 0x00007f452c934100 in soci::details::once_temp_type::~once_temp_type() () from /lib64/libsoci_core.so.4.0
like an exception is thrown from that destructor, but even if we catch it in our code its not handled
Have you ever seen this in your experience with SOCI 4? thanks a lot Andrea
Thanks Andrea!
I guess that it would be better to create an issue upstream: https://github.com/SOCI/soci/issues It may be easier if you first install the debugging symbols (with something like
sudo debuginfo-install soci-devel)