Re: Syncing `master`
Hi Ralph, On Fri, 30 Dec 2022 at 21:56, Ralph Goers wrote: > I am not understanding the format of this table. I expected it to contain a > list of PRs/Jira issues that were not propagated. Instead it seems to be a > list of modules and package names. Are we supposed to mark the packages that > have been validated? If I knew which Jira issues were not propagated, I would easily propagate the changes. Maybe after Volkan splits `changes.xml` we can find out the differences The problem is I don't know what is missing: I do a diff of the two branches to see which changes are missing and where. I think that anything that does not concern the DI, removing deprecated methods or replacing Java 8 methods with Java 11 is suspicious. Piotr
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 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 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 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] https://lintian.de
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
