Re: [log4cxx] Next steps / release?
On Fri, Jan 06, 2023 at 08:40:57PM -0500, Robert Middleton wrote: > The release has been formally completed at this point; mirrors have > their copy of the official tar.gz file. log4xx 1.0.0 just migrated to Debian/testing, so the transistio is done :) -- tobi > -Robert Middleton > > On Fri, Jan 6, 2023 at 7:36 AM Tobias Frost wrote: > > > > On Mon, Jan 02, 2023 at 10:45:37PM -0500, Robert Middleton wrote: > > > Awesome! Thanks for the packaging work that you do. Once we get it > > > voted on you should have a proper release. > > > > FYI, release-team acked the transistion and we've got the go to do the > > transition. So once the proper release is available, I now could upload > > it to unstable for the final steps needed to complete the transition, > > but I prefer to do this with the final release. > > > > Do you have an ETA when the release will become available? (It's still > > a bit time critical…) > > > > -- > > Cheers, > > tobi > > > > -- > > tobi > > > > > -Robert Middleton > > > > > > On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost wrote: > > > > > > > > Update: > > > > > > > > FTP masters have been very quick and approved the package, so the > > > > snapshot is > > > > already in experimental. [1] > > > > > > > > I've also rebuilt all reverse depdencies successfully and asked the > > > > release team > > > > to approve the transition. [2] > > > > > > > > [1] https://packages.debian.org/source/experimental/log4cxx > > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 > > > > > > > > Cheers, > > > > -- > > > > tobi > > > > > > > > On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > > > > > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > > > > > > > > > The last time we talked about this Tobias Frost said that the > > > > > > soft-freeze for Debian is the 12th of January[1], so after that > > > > > > point > > > > > > an updated library wouldn't make it into Debian. I would like to > > > > > > get > > > > > > this version into Debian if possible(as that is the distribution I > > > > > > use), but that depends on Tobias' availability. > > > > > > > > > > To have a chance to make that happen, I've started the transistion > > > > > workflow [1]. > > > > > TBH, due to the soft freeze is in less than two weeks, changes are > > > > > high that > > > > > we won't make it, but at least I want to have tried it. > > > > > > > > > > The first step is "Upload your new version to experimental (and have > > > > > it clear > > > > > NEW)", which is what I've just have done: I've uploaded a snapshot > > > > > (commit > > > > > cbd23ff1) to debian experimental. This needs now to be approved by > > > > > the (Debian) > > > > > ftp masters, which is (usually) for such a change quick, but if they > > > > > aren't or > > > > > not happy for any reason, this can spoil the game. [2] > > > > > > > > > > Only after that, I can ask for a transition slot from the release > > > > > team. If they are > > > > > not happy with a transition that late (IOW that short before the > > > > > freeze), well > > > > > that will be something I have to accept and that will mean 1.0.0 not > > > > > in > > > > > bookworm. > > > > > > > > > > In parallel I'll see if the reverse dependencies are still building > > > > > with the > > > > > new version, as for any breakage I will need to have patches > > > > > available… > > > > > > > > > > So, let's see how it works out. > > > > > > > > > > [1] if you want to know the details: > > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > > > > [2] It needs to go through NEW due to the binary package rename, due > > > > > to the SONAME bump. > > > > > > > > > > -- > > > > > tobi
Re: [log4cxx] Next steps / release?
The release has been formally completed at this point; mirrors have their copy of the official tar.gz file. -Robert Middleton On Fri, Jan 6, 2023 at 7:36 AM Tobias Frost wrote: > > On Mon, Jan 02, 2023 at 10:45:37PM -0500, Robert Middleton wrote: > > Awesome! Thanks for the packaging work that you do. Once we get it > > voted on you should have a proper release. > > FYI, release-team acked the transistion and we've got the go to do the > transition. So once the proper release is available, I now could upload > it to unstable for the final steps needed to complete the transition, > but I prefer to do this with the final release. > > Do you have an ETA when the release will become available? (It's still > a bit time critical…) > > -- > Cheers, > tobi > > -- > tobi > > > -Robert Middleton > > > > On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost wrote: > > > > > > Update: > > > > > > FTP masters have been very quick and approved the package, so the > > > snapshot is > > > already in experimental. [1] > > > > > > I've also rebuilt all reverse depdencies successfully and asked the > > > release team > > > to approve the transition. [2] > > > > > > [1] https://packages.debian.org/source/experimental/log4cxx > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 > > > > > > Cheers, > > > -- > > > tobi > > > > > > On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > > > > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > > > > > > > The last time we talked about this Tobias Frost said that the > > > > > soft-freeze for Debian is the 12th of January[1], so after that point > > > > > an updated library wouldn't make it into Debian. I would like to get > > > > > this version into Debian if possible(as that is the distribution I > > > > > use), but that depends on Tobias' availability. > > > > > > > > To have a chance to make that happen, I've started the transistion > > > > workflow [1]. > > > > TBH, due to the soft freeze is in less than two weeks, changes are high > > > > that > > > > we won't make it, but at least I want to have tried it. > > > > > > > > The first step is "Upload your new version to experimental (and have it > > > > clear > > > > NEW)", which is what I've just have done: I've uploaded a snapshot > > > > (commit > > > > cbd23ff1) to debian experimental. This needs now to be approved by the > > > > (Debian) > > > > ftp masters, which is (usually) for such a change quick, but if they > > > > aren't or > > > > not happy for any reason, this can spoil the game. [2] > > > > > > > > Only after that, I can ask for a transition slot from the release team. > > > > If they are > > > > not happy with a transition that late (IOW that short before the > > > > freeze), well > > > > that will be something I have to accept and that will mean 1.0.0 not in > > > > bookworm. > > > > > > > > In parallel I'll see if the reverse dependencies are still building > > > > with the > > > > new version, as for any breakage I will need to have patches available… > > > > > > > > So, let's see how it works out. > > > > > > > > [1] if you want to know the details: > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > > > [2] It needs to go through NEW due to the binary package rename, due to > > > > the SONAME bump. > > > > > > > > -- > > > > tobi
Re: [log4cxx] Next steps / release?
On Mon, Jan 02, 2023 at 10:45:37PM -0500, Robert Middleton wrote: > Awesome! Thanks for the packaging work that you do. Once we get it > voted on you should have a proper release. FYI, release-team acked the transistion and we've got the go to do the transition. So once the proper release is available, I now could upload it to unstable for the final steps needed to complete the transition, but I prefer to do this with the final release. Do you have an ETA when the release will become available? (It's still a bit time critical…) -- Cheers, tobi -- tobi > -Robert Middleton > > On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost wrote: > > > > Update: > > > > FTP masters have been very quick and approved the package, so the snapshot > > is > > already in experimental. [1] > > > > I've also rebuilt all reverse depdencies successfully and asked the release > > team > > to approve the transition. [2] > > > > [1] https://packages.debian.org/source/experimental/log4cxx > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 > > > > Cheers, > > -- > > tobi > > > > On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > > > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > > > > > The last time we talked about this Tobias Frost said that the > > > > soft-freeze for Debian is the 12th of January[1], so after that point > > > > an updated library wouldn't make it into Debian. I would like to get > > > > this version into Debian if possible(as that is the distribution I > > > > use), but that depends on Tobias' availability. > > > > > > To have a chance to make that happen, I've started the transistion > > > workflow [1]. > > > TBH, due to the soft freeze is in less than two weeks, changes are high > > > that > > > we won't make it, but at least I want to have tried it. > > > > > > The first step is "Upload your new version to experimental (and have it > > > clear > > > NEW)", which is what I've just have done: I've uploaded a snapshot (commit > > > cbd23ff1) to debian experimental. This needs now to be approved by the > > > (Debian) > > > ftp masters, which is (usually) for such a change quick, but if they > > > aren't or > > > not happy for any reason, this can spoil the game. [2] > > > > > > Only after that, I can ask for a transition slot from the release team. > > > If they are > > > not happy with a transition that late (IOW that short before the freeze), > > > well > > > that will be something I have to accept and that will mean 1.0.0 not in > > > bookworm. > > > > > > In parallel I'll see if the reverse dependencies are still building with > > > the > > > new version, as for any breakage I will need to have patches available… > > > > > > So, let's see how it works out. > > > > > > [1] if you want to know the details: > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > > [2] It needs to go through NEW due to the binary package rename, due to > > > the SONAME bump. > > > > > > -- > > > tobi signature.asc Description: PGP signature
Re: [log4cxx] Next steps / release?
Awesome! Thanks for the packaging work that you do. Once we get it voted on you should have a proper release. -Robert Middleton On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost wrote: > > Update: > > FTP masters have been very quick and approved the package, so the snapshot is > already in experimental. [1] > > I've also rebuilt all reverse depdencies successfully and asked the release > team > to approve the transition. [2] > > [1] https://packages.debian.org/source/experimental/log4cxx > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 > > Cheers, > -- > tobi > > On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > > > The last time we talked about this Tobias Frost said that the > > > soft-freeze for Debian is the 12th of January[1], so after that point > > > an updated library wouldn't make it into Debian. I would like to get > > > this version into Debian if possible(as that is the distribution I > > > use), but that depends on Tobias' availability. > > > > To have a chance to make that happen, I've started the transistion workflow > > [1]. > > TBH, due to the soft freeze is in less than two weeks, changes are high that > > we won't make it, but at least I want to have tried it. > > > > The first step is "Upload your new version to experimental (and have it > > clear > > NEW)", which is what I've just have done: I've uploaded a snapshot (commit > > cbd23ff1) to debian experimental. This needs now to be approved by the > > (Debian) > > ftp masters, which is (usually) for such a change quick, but if they aren't > > or > > not happy for any reason, this can spoil the game. [2] > > > > Only after that, I can ask for a transition slot from the release team. If > > they are > > not happy with a transition that late (IOW that short before the freeze), > > well > > that will be something I have to accept and that will mean 1.0.0 not in > > bookworm. > > > > In parallel I'll see if the reverse dependencies are still building with the > > new version, as for any breakage I will need to have patches available… > > > > So, let's see how it works out. > > > > [1] if you want to know the details: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > [2] It needs to go through NEW due to the binary package rename, due to the > > SONAME bump. > > > > -- > > tobi
Re: [log4cxx] Next steps / release?
Update: FTP masters have been very quick and approved the package, so the snapshot is already in experimental. [1] I've also rebuilt all reverse depdencies successfully and asked the release team to approve the transition. [2] [1] https://packages.debian.org/source/experimental/log4cxx [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 Cheers, -- tobi On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > The last time we talked about this Tobias Frost said that the > > soft-freeze for Debian is the 12th of January[1], so after that point > > an updated library wouldn't make it into Debian. I would like to get > > this version into Debian if possible(as that is the distribution I > > use), but that depends on Tobias' availability. > > To have a chance to make that happen, I've started the transistion workflow > [1]. > TBH, due to the soft freeze is in less than two weeks, changes are high that > we won't make it, but at least I want to have tried it. > > The first step is "Upload your new version to experimental (and have it clear > NEW)", which is what I've just have done: I've uploaded a snapshot (commit > cbd23ff1) to debian experimental. This needs now to be approved by the > (Debian) > ftp masters, which is (usually) for such a change quick, but if they aren't or > not happy for any reason, this can spoil the game. [2] > > Only after that, I can ask for a transition slot from the release team. If > they are > not happy with a transition that late (IOW that short before the freeze), well > that will be something I have to accept and that will mean 1.0.0 not in > bookworm. > > In parallel I'll see if the reverse dependencies are still building with the > new version, as for any breakage I will need to have patches available… > > So, let's see how it works out. > > [1] if you want to know the details: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > [2] It needs to go through NEW due to the binary package rename, due to the > SONAME bump. > > -- > tobi signature.asc Description: PGP signature
Re: [log4cxx] Next steps / release?
On Sat, Dec 31, 2022 at 1:57 PM Tobias Frost wrote: > (sorry for being short worded, not having much time right now) > Please note that library versioning has nothing do do with project versioning, > don't conflate them… It is a sign of improper library versioning if the > project has the same version as the library. IOW, so name versioning do > not follow semantic versioning. > So it seems that there are like three versions to take into account here(using liblog4cxx11): 1. The user-visible version(e.g. 0.11.0) 2. The version that the SO file has(e.g. liblog4cxx.so.11.0.0) 3. The ABI version of the library(e.g. 11) As for the project version being the same version as the library, that is the case with certain libraries: robert@debian:/usr/lib/x86_64-linux-gnu$ apt-cache policy libqt5core5a libqt5core5a: Installed: 5.11.3+dfsg1-1+deb10u5 Candidate: 5.11.3+dfsg1-1+deb10u5 Version table: *** 5.11.3+dfsg1-1+deb10u5 500 500 http://deb.debian.org/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 5.11.3+dfsg1-1+deb10u3 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages robert@debian:/usr/lib/x86_64-linux-gnu$ ls -l libQt5Core* -rw-r--r-- 1 root root1256 Mar 26 2022 libQt5Core.prl lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so -> libQt5Core.so.5.11.3 lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so.5 -> libQt5Core.so.5.11.3 lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so.5.11 -> libQt5Core.so.5.11.3 -rw-r--r-- 1 root root 5208360 Mar 26 2022 libQt5Core.so.5.11.3 If I'm understanding all of this correctly, using Qt as an example there the user-visible version is 5.11.3, the SO version is 5.11.3, and the ABI version is 5(since all Qt versions are ABI stable for every minor release in their major). > I still believe that the real name needs to be liblog4cxx.15.0.0, and this > also matches my experience how it is done generally. I pretty please ask not > to deviate from that, libraries are very easily made so that they are subtly > break, and my experience shows that your are always best of by following > established > practices. > > BTW, I'm getting a (new) lintian warning [0] > W: liblog4cxx15: package-name-doesnt-match-sonames liblog4cxx15.0.0 > > readelf -a liblog4cxx.so.1.0.0.0 | grep SONAME > 0x000e (SONAME) Library soname: > [liblog4cxx.so.15.0.0] > > compare that to eg. of libpng: > readelf -a /usr/lib/x86_64-linux-gnu/libpng16.so.16.39.0 | grep SONAME > 0x000e (SONAME) Library soname: [libpng16.so.16] > > I think there is something broken, ENOTIME to investiate right now, probably > SO version* is set to 15.0.0 instead of only 15. > > * sorry for the non-exact wording… > > [0] https://lintian.debian.org/tags/package-name-doesnt-match-sonames > > > Anyway, I'm going to do the following: > > * Update the changelog for this new release > > * Make sure the ABI dump is up to date(only needed for builds on > > github, this is not in the release tarball) > > * Merge next_stable into master and delete next_stable, so that master > > becomes the new master > > * Call a release vote > > Please lets first fix the SONAME issue… This is something which has a huge > impact and having the need to have a Debian specific patch here would be > really bad. I'll make everything with the SONAME 15.0.0, since that follows what we have been doing before. That lintian error is useful; now that I know that you're getting that error, it makes sense to fix it on the upstream end instead of having you fix that on yours. -Robert Middleton
Re: [log4cxx] Next steps / release?
On Sat, Dec 31, 2022 at 10:38:37AM -0500, Robert Middleton wrote: > On Sat, Dec 31, 2022 at 4:22 AM Tobias Frost wrote: > > The generated file names look strange: > > > > Now: > > tobi@isildor:~/workspace/deb/packages/log4cxx/upstream/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > > ls -la liblog4cxx* > > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:51 liblog4cxx.so -> > > liblog4cxx.so.15.0.0 > > -rw-r--r-- 1 tobi tobi 22632496 Dec 31 08:50 liblog4cxx.so.1.0.0.0 > > lrwxrwxrwx 1 tobi tobi 21 Dec 31 08:51 liblog4cxx.so.15.0.0 -> > > liblog4cxx.so.1.0.0.0 > > > > I'd expect the (actually) library be liblog4cxx.so.15.0.0 and symlinks > > pointing to it: > > liblog4cxx.so --> liblog4cxx.so.15 --> liblog4cxx.so.15.0.0 > > (linker name) --> (soname)--> (real name) > > > > (References: > > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, > > https://man7.org/conf/lca2006/shared_libraries/slide5b.html and following > > slides) > > > > before it was like this, which matches what I see on other libraries and > > what I would expect: > > tobi@isildor:~/workspace/deb/packages/log4cxx/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > > ls -la liblog4cxx* > > total 22780 > > lrwxrwxrwx 1 tobi tobi 16 Dec 31 08:55 liblog4cxx.so -> > > liblog4cxx.so.13 > > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:55 liblog4cxx.so.13 -> > > liblog4cxx.so.13.0.0 > > -rw-r--r-- 1 tobi tobi 23308784 Dec 31 08:54 liblog4cxx.so.13.0.0 > > ) > > > > (If you want to encode the project version into the name, it would be more > > liblog4cxx-1.0.0.so, liblog4cxx-1.0.0.so.15 and sliblog4cxx-1.0.0.so.15.0.0 > > , but that's breaking > > the concept of soanmes alltogether, as for the linker/loader > > liblog4cxx-1.0.0.so.15 and liblog4cxx-1.0.1.so.15 would > > be different, unrelated libraries) > > FWIW my reference is mostly from this (old) thread on the KDE mailing > list: https://mail.kde.org/pipermail/kde-buildsystem/2008-April/004543.html > This would seem to agree with the TLDP documentation, which states: > "Every shared library has a special name called the ``soname''. The > soname has the prefix ``lib'', the name of the library, the phrase > ``.so'', followed by a period and a version number that is incremented > whenever the interface changes (as a special exception, the > lowest-level C libraries don't start with ``lib''). A fully-qualified > soname includes as a prefix the directory it's in; on a working system > a fully-qualified soname is simply a symbolic link to the shared > library's ``real name''. > > Every shared library also has a ``real name'', which is the filename > containing the actual library code. The real name adds to the soname a > period, a minor number, another period, and the release number. The > last period and release number are optional. The minor number and > release number support configuration control by letting you know > exactly what version(s) of the library are installed. Note that these > numbers might not be the same as the numbers used to describe the > library in documentation, although that does make things easier." > > So setting the SONAME to 15.0.0 results in the liblog4cxx.so.15, with > a version of 1.0.0.0(liblog4cxx.so.1.0.0.0) which would correspond to > the correct log4cxx version in this case(CMake allows for > major.minor.patch.tweak, but for the human-readable release I do just > major.minor.patch). As far as I can tell, the important thing is that > the SONAME does not always equal the version name(if we were following > semantic versioning earlier it probably would be the same), but that's > part of this release to get it into a state where the versions and > SONAME should increment independently of each other. (sorry for being short worded, not having much time right now) Please note that library versioning has nothing do do with project versioning, don't conflate them… It is a sign of improper library versioning if the project has the same version as the library. IOW, so name versioning do not follow semantic versioning. I still believe that the real name needs to be liblog4cxx.15.0.0, and this also matches my experience how it is done generally. I pretty please ask not to deviate from that, libraries are very easily made so that they are subtly break, and my experience shows that your are always best of by following established practices. BTW, I'm getting a (new) lintian warning [0] W: liblog4cxx15: package-name-doesnt-match-sonames liblog4cxx15.0.0 readelf -a liblog4cxx.so.1.0.0.0 | grep SONAME 0x000e (SONAME) Library soname: [liblog4cxx.so.15.0.0] compare that to eg. of libpng: readelf -a /usr/lib/x86_64-linux-gnu/libpng16.so.16.39.0 | grep SONAME 0x000e (SONAME) Library soname: [libpng16.so.16] I think there is something broken, ENOTIME to investiate right now, probably SO version* is set to 15.0.0 instead of only 15. * sorry for the non-exact wording… [0]
Re: [log4cxx] Next steps / release?
On Sat, Dec 31, 2022 at 4:22 AM Tobias Frost wrote: > The generated file names look strange: > > Now: > tobi@isildor:~/workspace/deb/packages/log4cxx/upstream/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > ls -la liblog4cxx* > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:51 liblog4cxx.so -> > liblog4cxx.so.15.0.0 > -rw-r--r-- 1 tobi tobi 22632496 Dec 31 08:50 liblog4cxx.so.1.0.0.0 > lrwxrwxrwx 1 tobi tobi 21 Dec 31 08:51 liblog4cxx.so.15.0.0 -> > liblog4cxx.so.1.0.0.0 > > I'd expect the (actually) library be liblog4cxx.so.15.0.0 and symlinks > pointing to it: > liblog4cxx.so --> liblog4cxx.so.15 --> liblog4cxx.so.15.0.0 > (linker name) --> (soname)--> (real name) > > (References: > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, > https://man7.org/conf/lca2006/shared_libraries/slide5b.html and following > slides) > > before it was like this, which matches what I see on other libraries and what > I would expect: > tobi@isildor:~/workspace/deb/packages/log4cxx/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > ls -la liblog4cxx* > total 22780 > lrwxrwxrwx 1 tobi tobi 16 Dec 31 08:55 liblog4cxx.so -> liblog4cxx.so.13 > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:55 liblog4cxx.so.13 -> > liblog4cxx.so.13.0.0 > -rw-r--r-- 1 tobi tobi 23308784 Dec 31 08:54 liblog4cxx.so.13.0.0 > ) > > (If you want to encode the project version into the name, it would be more > liblog4cxx-1.0.0.so, liblog4cxx-1.0.0.so.15 and sliblog4cxx-1.0.0.so.15.0.0 , > but that's breaking > the concept of soanmes alltogether, as for the linker/loader > liblog4cxx-1.0.0.so.15 and liblog4cxx-1.0.1.so.15 would > be different, unrelated libraries) FWIW my reference is mostly from this (old) thread on the KDE mailing list: https://mail.kde.org/pipermail/kde-buildsystem/2008-April/004543.html This would seem to agree with the TLDP documentation, which states: "Every shared library has a special name called the ``soname''. The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start with ``lib''). A fully-qualified soname includes as a prefix the directory it's in; on a working system a fully-qualified soname is simply a symbolic link to the shared library's ``real name''. Every shared library also has a ``real name'', which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional. The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier." So setting the SONAME to 15.0.0 results in the liblog4cxx.so.15, with a version of 1.0.0.0(liblog4cxx.so.1.0.0.0) which would correspond to the correct log4cxx version in this case(CMake allows for major.minor.patch.tweak, but for the human-readable release I do just major.minor.patch). As far as I can tell, the important thing is that the SONAME does not always equal the version name(if we were following semantic versioning earlier it probably would be the same), but that's part of this release to get it into a state where the versions and SONAME should increment independently of each other. Anyway, I'm going to do the following: * Update the changelog for this new release * Make sure the ABI dump is up to date(only needed for builds on github, this is not in the release tarball) * Merge next_stable into master and delete next_stable, so that master becomes the new master * Call a release vote -Robert Middleton
Re: [log4cxx] Next steps / release?
On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > The last time we talked about this Tobias Frost said that the > soft-freeze for Debian is the 12th of January[1], so after that point > an updated library wouldn't make it into Debian. I would like to get > this version into Debian if possible(as that is the distribution I > use), but that depends on Tobias' availability. To have a chance to make that happen, I've started the transistion workflow [1]. TBH, due to the soft freeze is in less than two weeks, changes are high that we won't make it, but at least I want to have tried it. The first step is "Upload your new version to experimental (and have it clear NEW)", which is what I've just have done: I've uploaded a snapshot (commit cbd23ff1) to debian experimental. This needs now to be approved by the (Debian) ftp masters, which is (usually) for such a change quick, but if they aren't or not happy for any reason, this can spoil the game. [2] Only after that, I can ask for a transition slot from the release team. If they are not happy with a transition that late (IOW that short before the freeze), well that will be something I have to accept and that will mean 1.0.0 not in bookworm. In parallel I'll see if the reverse dependencies are still building with the new version, as for any breakage I will need to have patches available… So, let's see how it works out. [1] if you want to know the details: https://wiki.debian.org/Teams/ReleaseTeam/Transitions [2] It needs to go through NEW due to the binary package rename, due to the SONAME bump. -- tobi
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 12:43:18PM -0500, Robert Middleton wrote: > On Fri, Dec 30, 2022 at 11:43 AM Tobias Frost wrote: > > When doing the same against the branch "next_stable", currently at [2] > > the result is much much worse: > > https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html > > > > /me confused… (I've read your text as it should be the opposite…) > > > > The new version should be ABI stable moving forward, but it needs to > be released first. > > > If it is only API compatible, but not ABI compable, we'll need a SONAME > > bump. > > > > I bumped the SONAME a little bit ago; you probably grabbed the code > shortly before I bumped it. Indeed :) > I think I've done it correctly, but it > would be nice to have somebody double-check it. I arbitrarily bumped > it to version 15, skipping 14. The version of the SO file should also > now match the version of log4cxx, but that version is not the same as > the SONAME. The generated file names look strange: Now: tobi@isildor:~/workspace/deb/packages/log4cxx/upstream/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ ls -la liblog4cxx* lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:51 liblog4cxx.so -> liblog4cxx.so.15.0.0 -rw-r--r-- 1 tobi tobi 22632496 Dec 31 08:50 liblog4cxx.so.1.0.0.0 lrwxrwxrwx 1 tobi tobi 21 Dec 31 08:51 liblog4cxx.so.15.0.0 -> liblog4cxx.so.1.0.0.0 I'd expect the (actually) library be liblog4cxx.so.15.0.0 and symlinks pointing to it: liblog4cxx.so --> liblog4cxx.so.15 --> liblog4cxx.so.15.0.0 (linker name) --> (soname)--> (real name) (References: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, https://man7.org/conf/lca2006/shared_libraries/slide5b.html and following slides) before it was like this, which matches what I see on other libraries and what I would expect: tobi@isildor:~/workspace/deb/packages/log4cxx/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ ls -la liblog4cxx* total 22780 lrwxrwxrwx 1 tobi tobi 16 Dec 31 08:55 liblog4cxx.so -> liblog4cxx.so.13 lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:55 liblog4cxx.so.13 -> liblog4cxx.so.13.0.0 -rw-r--r-- 1 tobi tobi 23308784 Dec 31 08:54 liblog4cxx.so.13.0.0 ) (If you want to encode the project version into the name, it would be more liblog4cxx-1.0.0.so, liblog4cxx-1.0.0.so.15 and sliblog4cxx-1.0.0.so.15.0.0 , but that's breaking the concept of soanmes alltogether, as for the linker/loader liblog4cxx-1.0.0.so.15 and liblog4cxx-1.0.1.so.15 would be different, unrelated libraries) > -Robert Middletona -- tobi
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 11:43 AM Tobias Frost wrote: > When doing the same against the branch "next_stable", currently at [2] > the result is much much worse: > https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html > > /me confused… (I've read your text as it should be the opposite…) > The new version should be ABI stable moving forward, but it needs to be released first. > If it is only API compatible, but not ABI compable, we'll need a SONAME bump. > I bumped the SONAME a little bit ago; you probably grabbed the code shortly before I bumped it. I think I've done it correctly, but it would be nice to have somebody double-check it. I arbitrarily bumped it to version 15, skipping 14. The version of the SO file should also now match the version of log4cxx, but that version is not the same as the SONAME. -Robert Middleton
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 10:29:46AM -0500, Robert Middleton wrote: > On Fri, Dec 30, 2022 at 10:17 AM Tobias Frost wrote: > > > > On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote: > > > IF an SONAME bump is required, it will become more challenging, as other > > > Debian teams are involved (and other maintainers if it casues breakages in > > > reverse dependencies) > > > I would basically needs something (it does not need to be the final > > > release, just something with the target SONAME) now to kick of the > > > process. Fixes > > > (without SONAME bump) can still then be provided until February. > > > > Ok, I've compiled the new version and the version currently in Debian and > > threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with > > 8 errors. > > > > I've put the report here: > > https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html > > > > 1 = old version, currently in debian > > 2 = new version "head" of current git, master-branch. > > > > Level::initializeLevels ( ) should not be deleted… > > > > On the other erros, where registers have changed, I have no idea what's > > going on… > > > > The registers changing sounds like something in the compiler changed. Both versions were freshly compiled, with the same compiler and using the same "debian/rules" > But it looks like that's on master, where what we're talking about > here is currently in the next_stable branch(which should have a > ridiculous number of ABI failures, Yes, https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html was from the branch "master" to 0.13.0 (as in "from the release tarball" [1]) When doing the same against the branch "next_stable", currently at [2] the result is much much worse: https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html /me confused… (I've read your text as it should be the opposite…) [1] sha256sum log4cxx_0.13.0.orig.tar.gz 4e5be64b6b1e6de8525f8b87635270b81f772a98902d20d7ac646fdf1ac08284 log4cxx_0.13.0.orig.tar.gz [2] commit ad751d5fc523205e47fda013df0ff51691eaffb3 (HEAD -> next_stable, origin/next_stable) Author: Stephen Webb Date: Fri Dec 30 16:17:56 2022 +1100 Prevent compilation error when the log4cxx user uses a different C++ standard to the log4cxx build The result is much much worse: https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html > but it should still be source-compatible). If it is only API compatible, but not ABI compable, we'll need a SONAME bump. > > -Robert Middleton Cheers, -- tobi signature.asc Description: PGP signature
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 10:17 AM Tobias Frost wrote: > > On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote: > > IF an SONAME bump is required, it will become more challenging, as other > > Debian teams are involved (and other maintainers if it casues breakages in > > reverse dependencies) > > I would basically needs something (it does not need to be the final > > release, just something with the target SONAME) now to kick of the process. > > Fixes > > (without SONAME bump) can still then be provided until February. > > Ok, I've compiled the new version and the version currently in Debian and > threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with > 8 errors. > > I've put the report here: > https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html > > 1 = old version, currently in debian > 2 = new version "head" of current git, master-branch. > > Level::initializeLevels ( ) should not be deleted… > > On the other erros, where registers have changed, I have no idea what's going > on… > The registers changing sounds like something in the compiler changed. But it looks like that's on master, where what we're talking about here is currently in the next_stable branch(which should have a ridiculous number of ABI failures, but it should still be source-compatible). -Robert Middleton
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote: > IF an SONAME bump is required, it will become more challenging, as other > Debian teams are involved (and other maintainers if it casues breakages in > reverse dependencies) > I would basically needs something (it does not need to be the final > release, just something with the target SONAME) now to kick of the process. > Fixes > (without SONAME bump) can still then be provided until February. Ok, I've compiled the new version and the version currently in Debian and threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with 8 errors. I've put the report here: https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html 1 = old version, currently in debian 2 = new version "head" of current git, master-branch. Level::initializeLevels ( ) should not be deleted… On the other erros, where registers have changed, I have no idea what's going on… [1] https://github.com/lvc/abi-compliance-checker -- Cheers, tobi > > > > -Robert Middleton > > > > [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7
Re: [log4cxx] Next steps / release?
On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > With some fixes that have been accomplished over the past few weeks, > we now have only 1-2 issues in JIRA that would need to be finished for > a release, and I think both of those are effectively done at this > point. > > I'm pretty happy with where things are at the moment - there's always > more tweaking that can be done, but I can't think of anything major > that needs to be done that could be done within a reasonable > timeframe. The major thing that was done for the next release was to > make things ABI stable, so as long as we commit to that going > forward(and only breaking it with proper versioning) we should be > good. > > The last time we talked about this Tobias Frost said that the > soft-freeze for Debian is the 12th of January[1], so after that point > an updated library wouldn't make it into Debian. I would like to get > this version into Debian if possible(as that is the distribution I > use), but that depends on Tobias' availability. Yes, I'm generally available. > With that in mind, should we do a release in the immediate > future(within the next ~7 days), or should we wait a bit for some more > tweaking and/or features? > As said, if the new version does _not_ need an SONAME bump, the deadline is February 12th (at which time it must be in "testing", so effectivly I have to upload it minmum 10 days earlier. (12 to be safe). IF an SONAME bump is required, it will become more challenging, as other Debian teams are involved (and other maintainers if it casues breakages in reverse dependencies) I would basically needs something (it does not need to be the final release, just something with the target SONAME) now to kick of the process. Fixes (without SONAME bump) can still then be provided until February. -- Cheers, tobi > -Robert Middleton > > [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7
Re: [log4cxx] Next steps / release?
I think the next_stable branch should be released now. I am not aware of any issue that would prevent a release. I will do some more tests with production code this weekend to ensure there is no anything I have missed. On Fri, Dec 30, 2022 at 9:21 AM Robert Middleton wrote: > With some fixes that have been accomplished over the past few weeks, > we now have only 1-2 issues in JIRA that would need to be finished for > a release, and I think both of those are effectively done at this > point. > > I'm pretty happy with where things are at the moment - there's always > more tweaking that can be done, but I can't think of anything major > that needs to be done that could be done within a reasonable > timeframe. The major thing that was done for the next release was to > make things ABI stable, so as long as we commit to that going > forward(and only breaking it with proper versioning) we should be > good. > > The last time we talked about this Tobias Frost said that the > soft-freeze for Debian is the 12th of January[1], so after that point > an updated library wouldn't make it into Debian. I would like to get > this version into Debian if possible(as that is the distribution I > use), but that depends on Tobias' availability. > > With that in mind, should we do a release in the immediate > future(within the next ~7 days), or should we wait a bit for some more > tweaking and/or features? > > -Robert Middleton > > [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7 >
[log4cxx] Next steps / release?
With some fixes that have been accomplished over the past few weeks, we now have only 1-2 issues in JIRA that would need to be finished for a release, and I think both of those are effectively done at this point. I'm pretty happy with where things are at the moment - there's always more tweaking that can be done, but I can't think of anything major that needs to be done that could be done within a reasonable timeframe. The major thing that was done for the next release was to make things ABI stable, so as long as we commit to that going forward(and only breaking it with proper versioning) we should be good. The last time we talked about this Tobias Frost said that the soft-freeze for Debian is the 12th of January[1], so after that point an updated library wouldn't make it into Debian. I would like to get this version into Debian if possible(as that is the distribution I use), but that depends on Tobias' availability. With that in mind, should we do a release in the immediate future(within the next ~7 days), or should we wait a bit for some more tweaking and/or features? -Robert Middleton [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7
