Keeping binary compatibility
Hello, as you probably know, the theory is that KDE libraries keep backwards binary compatibility. As you might or might not know, that is the theory. I've found a tool called abi-compliance-checker (http://ispras.linux-foundation.org/index.php/ABI_compliance_checker) and it has a page with checks for various libraries including ours (http://linuxtesting.org/upstream-tracker/versions/kde-libs.html), which is not as green as it should be. I've also compared openSUSE packages for 4.4.4 and 4.5.1 and there are problems too (http://ktown.kde.org/~seli/abi/ for what I checked). Let me point out just one, http://reviewboard.kde.org/r/2608/ , which I think shows that this occassionally happening is inevitable. Moreover, there seem to be cases where we simply don't seem to have rules (or at least I couldn't find them). Do we have rules that say more than kdelibs is BC stable, we don't care about the rest? What's the status with e.g. kdeedu libs? I'm asking because, consider e.g. these errors from an attempt to uninstall kdebase/workspace package here: libkscreensaver.so.5()(64bit) is needed by (installed) kdeartwork4-screensaver-4.4.4-2.1.1.x86_64 libkworkspace.so.4()(64bit) is needed by (installed) ktorrent-3.3.4-4.1.x86_64 libkworkspace.so.4()(64bit) is needed by (installed) kor-0.3-2.2s.x86_64 libsolidcontrol.so.4()(64bit) is needed by (installed) ktorrent-3.3.4-4.1.x86_64 libsolidcontrol.so.4()(64bit) is needed by (installed) kbluetooth-0.4.2-3.1.x86_64 libsolidcontrol.so.4()(64bit) is needed by (installed) NetworkManager-kde4-libs-0.9.svn1057339-4.1.x86_64 libtaskmanager.so.4()(64bit) is needed by (installed) ktorrent-3.3.4-4.1.x86_64 Now, an explanation is probably needed for those who live only in the SVN world or with distros where breakages are solved by rebuilding everything. If you develop e.g. on openSUSE and you notice a library you might like to use, then you perhaps install its -devel package, maybe go as far as reading its documentation (which doesn't say anything interesting in the case of kdebase4-workspace-devel or libkeedu4-devel), or maybe you just read its .h files and then make your app use the library. Then you release a tarball, some packager builds it, adds also the -devel package to the build requirements, the app builds and the packaging system records a dependency on the library, as seen above. That is, on the library soname (libname.so.+one number). That's how it's done. I read somewhere that when using unstable KDE libs the requirement should be on the exact version, but that's not how it's done. Can you see above ktorrent requiring kdebase4-workspace = 4.4.4? No, and it's unlikely a system like that would get as far as the packager knowing and doing so (not only because not knowing, but also because it's stupid - why should anybody be forced to upgrade ktorrent from a 3rd party repo whenever there's another patchlevel SC release). Looking at how KDE provides various libraries leads to a number of WTH questions, like: - WTH is the ABI stability documented, besides kdelibs? - WTH is there e.g. libiris_ksirk.so (i.e. a development .so symlink), where are the .h files? - WTH does e.g. libtaskmanager seem to have soname versioning following SC version, like stable kdelibs libraries do, but it's not actually stable? - WTH does e.g. ksysguard install libraries .so and .h files for something that looks a lot like its internal libraries? Therefore I propose the following: - private libraries do not (obviously ...?) install their .h files and do use NAMELINK_SKIP option in install (see e.g. http://websvn.kde.org/trunk/KDE/kdebase/workspace/khotkeys/libkhotkeysprivate/CMakeLists.txt?r1=862343r2=895764) - ABI stability for each public library is documented, I would suggest a README.library file in sources and in the main doxygen page - ABI of each stable library (obviously) does not change - whenever ABI of an unstable library changes, its soname is increased (which means that each library will need in its CMakeLists.txt something like this http://websvn.kde.org/trunk/KDE/kdelibs/plasma/CMakeLists.txt?r1=879765r2=879766; , handled manually, instead of generic macros) - the release team howto gets a new entry 'each new version is ABI tested before release' (I do not have tests for 4.5.2 yet as I'm waiting for the packages to rebuild, and as said above I also don't quite know what to check, but in general I have a quite easy way of checking the whole KDE SC on each release) -- Lubos Lunak openSUSE Boosters team, KDE developer l.lu...@suse.cz , l.lu...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
On Wednesday 04 of August 2010, Modestas Vainius wrote: Yes, probably most of libraries are local to kdebase-workspace. But if they are local, they should not install headers to the world. But they all do (why?). A few libraries in kdebase-workspace are definitely public, for example libsolidcontrol (afaik, it broke BC in 4.5 without bumping soname) and libtaskmanager [1] (it broke ABI in 4.4 in comparison with 4.3). The recent example on top of all that workspace stuff: libsolidinterfaces was moved to kdelibs 4.4 with completely reworked API and without any soname bump. Looks like KDE violates soname concept for the sake of what? Because a single change in CMakeLists.txt is too hard? Or SOVERSION 4 is such a good looking number that there is a strict policy not to touch it? I'm sorry but I don't know how else I could explain this. Laziness and unawareness are pretty good excuses for many things. Anyway, at this point I see this as completely lost battle. I guess we will need to start adding distro patches (sad) for bumping sonames of those public libraries because you do not seem to have much interest in following well defined practises in the unix world which are supported by libc/ldconfig/ld.so.conf. And they seem to be quite good excuses for you too, it seems. If you want this problem solved, kde-core-devel is a much better place for the discussion then the release-team list at the point when the tarballs are about to be released. You apparently have known for quite some time, so yours you is actually we. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lu...@suse.cz , l.lu...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
On Wednesday 04 of August 2010, Modestas Vainius wrote: On trečiadienis 04 Rugpjūtis 2010 12:31:27 Lubos Lunak wrote: Anyway, at this point I see this as completely lost battle. I guess we will need to start adding distro patches (sad) for bumping sonames of those public libraries because you do not seem to have much interest in following well defined practises in the unix world which are supported by libc/ldconfig/ld.so.conf. And they seem to be quite good excuses for you too, it seems. If you want this problem solved, kde-core-devel is a much better place for the discussion then the release-team list at the point when the tarballs are about to be released. You apparently have known for quite some time, so yours you is actually we. s/libsolidinterfaces/libnepomukquery/ in my previous mail. Similar topics have been on k-c-d before [1][2], There is nothing in either of those mails that supports your position, in fact exactly the opposite. They both state that some libraries, by design, do not keep binary compatibility, and that when a change happens, soname should be changed. but POV of Laziness and unawareness are pretty good excuses for many things. simply prevails. libnepomukquery is a pretty good example of that. People simply don't consider this important enough. Or they don't know, or they have forgotten. In this case, our arguments were apparently discarded because making an exception for libkonq doesn't make that much sense. to me is missing at the end of that sentence. And, while I'm at it, the consequent any other opinions? is missing too. I admit it may be a bit late as we do not package pre-releases nowadays (which may be our fault but that's the way it is for now). Therefore, I cannot be in supervisor position for these things until it is too late nor anybody would listen to me. Oh, poor you. But in case you'll get over this attitude and will be interested in fixing the problem, you've been told where the right place to discuss the problem is. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lu...@suse.cz , l.lu...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4.3 tarballs uploaded (try #1)
On Friday 30 of April 2010, Dirk Mueller wrote: Hi, I just finished uploading the first set of 4.4.3 tarballs. They seemed to have compiled fine for me over night. Please report any issues you might encounter that justify a retag to me/release-t...@kde.org. These include compile failures or serious regressions. kde4-l10n-nl fails at make install with 'file INSTALL cannot find /usr/src/packages/BUILD/kde-l10n-nl-4.4.3/docs/kdelibs/preparetips/preparetips.1'. It is because make actually creates tips_ter_voorbereiding.1, so I assume the problem is because the manpage translates the command name itself. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lu...@suse.cz , l.lu...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thursday 07 of January 2010, Eric Hameleers wrote: I have the following build error in kdebase after having built kdelibs and kdepimlibs: [ 74%] Building CXX object apps/konqueror/sidebar/trees/CMakeFiles/konqsidebar_tree.dir/konqsidebar_tr ee_final_cpp.o In file included from /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.cpp:21, from /tmp/kdebase-4.3.90/build/apps/konqueror/sidebar/konq_sidebar_final_cpp.cpp :4: /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:31: error: redefinition of 'class ModuleManager' /tmp/kdebase-4.3.90/apps/konqueror/sidebar/module_manager.h:32: error: previous definition of 'class ModuleManager' Oh, somebody else uses final build mode too :) ? I've fixed this in SVN, but I don't think final build failures have even been blockers for tarball release (I'd guess there's a number such failures nowadays). Just build it normally or get r1071282 from SVN. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lu...@suse.cz , l.lu...@kde.org ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Minor Point Release Policy
On Friday 11 of December 2009, Jonathan Riddell wrote: Over at Kubuntu we're trying to concince our technical board that its ok to put KDE minor point releases in updates. However it seems there's no formal rules for what is or isn't acceptable in minor point releases. I think it would be a good thing to have some since it gives guidance on what should or shouldn't be put into release branches after release. So I wrote some down quickly. Does this make sense to adopt for KDE? Additions welcome. http://techbase.kde.org/Policies/Minor_Point_Release_Policy/Draft * Severe bugs: security vulnerabilities, severe regressions from previous releases, data loss bugs Every bug is severe to somebody. If you draw the line too far, it means that every single stable release will be full of non-major bugs, because that simply happens with x.y.0 and people won't be allowed to fix them. * Fixes to bugs which are easy to verify and have a report in bugs.kde.org So if I notice a problem, I have to first report it? * Updated translations They must not contain * API changes I expect you mean no new API, since everything else is ruled out already. And fixes occassionally do require new API. It is not recommended to have older kdelibs than anything else from KDE SC anyway. * New strings Similar to above. Unlike with API I don't know for sure if this happens, but I'd be surprised if not when needed. Frankly, I'd prefer if we rather wrote down the existing guidelines, with 'use common sense' as first, and named them as such (=guidelines), rather than having a policy and pointless discussions about details that do not matter. -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: l.lu...@suse.cz , l.lu...@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE 4.2.2 xrandr bug, block for dual-head setups
On Thursday 26 of March 2009, Dirk Mueller wrote: Hi, does anyone have an idea how to resolve this issue? Thanks, Dirk ... this is only a blocker for dual-head setups, maybe it could still get into your list (couldn't tag it). https://bugs.kde.org/show_bug.cgi?id=170920 http://linux-tipps.blogspot.com/2009/03/fixing-high-latency-with-kde4-displ ay.html Kephal bug, commented, reopened and reassigned. According to Novell X developers there is currently no way around the problem. -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: l.lu...@suse.cz , l.lu...@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: update the feature plan!
On Tuesday 18 of November 2008, Sebastian Kügler wrote: To prepare the release notes, and to give users and the press exact information about the changes, it's important to have an up to date feature list. I have a question: One of the big new features of KWin in 4.2 is enabling compositing by default, which technically is not a feature (and neither new, in a way). Since I think this definitely should go into the release notesCo., should I still add it to the feature list at techbase, or is there some better way how to handle this? -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdelibs/cmake/modules
On Friday 04 of January 2008, Alexander Neundorf wrote: Yes, it is very unlikely, but very unlikely != impossible. The thing is, the names were in sync with the names of the variables in the FindX11.cmake of cmake cvs since several months. So since several months some cmake cvs users may already use that variable. Ok, it is the cvs version only, but still it is there for quite some time already and changing this can break the build of somebody (you never know what somebody does with the variables). So this change means either we can never use the module from cmake or I need to add some transition logic on the cmake side. So is it really necessary to change the name ? I guess that depends on which of changing a rarely used name from cmake cvs and having a confusing rarely used name you consider to be worse. We are at the day of the tagging, IMO too late for such changes. It was broken. In which way was it exactly broken ? Somebody got confused by the names and it didn't match in kdebase/workspace/CMakeChecks.cmake. -- Lubos Lunak KDE developer -- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
