Re: BIC in libkonq
Hello, On antradienis 03 Rugpjūtis 2010 22:52:36 Dirk Mueller wrote: libkonq is an edge case, it is used in quite some other modules, on the other side, due to the anything that depends on *workspace* must require the exact version anyway, making an exception for libkonq doesn't make that much sense to me. 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. 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. [1] $ apt-cache rdepends libsolidcontrol4 libsolidcontrol4 Reverse Depends: knm-runtime plasma-widget-networkmanagement network-manager-kde knm-runtime ktorrent kdelirc plasma-widgets-workspace plasma-desktop plasma-dataengines-workspace kdebase-workspace-dev kdebase-workspace-bin kbluetooth $ apt-cache rdepends libtaskmanager4a libtaskmanager4a Reverse Depends: plasma-widget-smooth-tasks plasma-widget-ktorrent plasma-widget-lancelot plasma-desktop plasma-dataengines-workspace kdebase-workspace-dev $ apt-cache rdepends libkonq5 libkonq5 Reverse Depends: konq-plugins kmess kdiff3 ark plasma-widget-folderview libkonq5-dev konqueror kfind kdepasswd kdebase-apps dolphin -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. ___ 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
KDE SC 4.5.0: Dolphin instable
Hi, I'm very sorry for noticing you that late, but my timing to recognize the root cause of some Dolphin related crashes was very bad this time: Dolphin might be instable in KDE SC 4.5.0, when tooltips or the information panel are enabled. Sebastian Trüg and I provided two patches on the 4.5 branch that solve this issues (SVN commit 1157302 and 1158299 [1]), but of course it is too late now for 4.5.0. If possible, I think this should be mentioned in the release notes as known issue. A suggestion of the text might be: Dolphin might be instable in KDE SC 4.5.0, when tooltips or the information panel are enabled. A fix will be available for KDE SC 4.5.1. Some background info: Dolphin receives the meta data shown in tooltips or the information panel in a thread, to assure that the user interface does not get blocked. Before KDE SC 4.5 it just used Nepomuk to get the data, since 4.5 it uses KFileMetaInfo as fallback when Nepomuk is disabled. It turned out, that KFileMetaInfo is not reentrant, which of course is a disaster when being used in a thread. I initially thought this is related to a d-bus issue (https://bugs.freedesktop.org/show_bug.cgi?id=17754), but sadly was wrong here :-( Best regards, Peter [1] I still need to go manually through all tooltip and information panel related bug reports, to set them to resolved. But I did not want to do this in a hurry, so the patches currently don't contain BUG: tags. PS: I'm offline today, but should be available again tomorrow. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.5.0: Dolphin instable
On Wednesday 04 August 2010 08:04:01 Peter Penz wrote: [...] Sebastian Trüg and I provided two patches on the 4.5 branch that solve this issues (SVN commit 1157302 and 1158299 [1]), but of course it is too late now for 4.5.0. Sorry for the noise, the SVN commit numbers are 1157302 and 1158288 (not 1158299). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
On 04.08.10 11:16:01, Modestas Vainius wrote: On antradienis 03 Rugpjūtis 2010 22:52:36 Dirk Mueller wrote: libkonq is an edge case, it is used in quite some other modules, on the other side, due to the anything that depends on *workspace* must require the exact version anyway, making an exception for libkonq doesn't make that much sense to me. 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 libs from ksysguard (libprocess and libprocessui) are also used outside of workspace. 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. You overestimate how many people actually have a clue about sonames. Most developers do not know what that number means or when it should be increased. They simply use the variable set by FindKDE4Internal and are done with it. 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. As Lubos said, you're barking up the wrong tree, the release team can do 0 about this. The developers actually can, but most of them don't read this list. Andreas -- You are a very redundant person, that's what kind of person you are. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
Hello, 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], 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. In this case, our arguments were apparently discarded because making an exception for libkonq doesn't make that much sense. 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. [1] http://lists.kde.org/?l=kde-core-develm=124061169122689w=2 [2] http://www.mail-archive.com/release-team@kde.org/msg02970.html -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
4.5.0 Release Thursday
Hi all, As it stands now, we'll get 4.5.0 out tomorrow, around mid-day in Europe. This gives everybody a bit of time to re-roll their packages after yesterday's updates. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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
4.5.0 Delayed Until Tuesday, 10th August 2010
Hi all, After discussing the amount of changes that have gone into the 4.5 branch post-RC3, the release team has decided to wait another couple of days for things to settle down and to re-tag the 4.5.0 release from branch in a bit more than an hour, at 1600 UTC. We'll push the further schedule for the 4.5 series for 1 week as well. The current plan for 4.6.x is not affected. There was a number of last-minute changes introduced we didn't feel completely comfortable shipping. Also, delaying the release a bit gives us the chance to have zero-day packages available for more OSen than we'd have with only about 24h head-time for packagers, and will likely lead to better and more complete material for the press to be available and seeded early. Please have another good look for what you'd consider a show-stopper for the 4.5.0 release. Also, if you have any last-minute change you consider serious enough to go into the 4.5.0 release, please commit this *now* to ther 4.5 branch (don't forget to forward-port into trunk), and failing to make that deadline, email us via release-t...@kde.org. Thanks for your understanding, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.5.0 Delayed Until Tuesday, 10th August 2010
On Wed, 4 Aug 2010, Sebastian Kügler wrote: Hi all, After discussing the amount of changes that have gone into the 4.5 branch post-RC3, the release team has decided to wait another couple of days for things to settle down and to re-tag the 4.5.0 release from branch in a bit more than an hour, at 1600 UTC. We'll push the further schedule for the 4.5 series for 1 week as well. The current plan for 4.6.x is not affected. There was a number of last-minute changes introduced we didn't feel completely comfortable shipping. Also, delaying the release a bit gives us the chance to have zero-day packages available for more OSen than we'd have with only about 24h head-time for packagers, and will likely lead to better and more complete material for the press to be available and seeded early. Please have another good look for what you'd consider a show-stopper for the 4.5.0 release. Also, if you have any last-minute change you consider serious enough to go into the 4.5.0 release, please commit this *now* to ther 4.5 branch (don't forget to forward-port into trunk), and failing to make that deadline, email us via release-t...@kde.org. Thanks for your understanding, I guess that this is good for KDE 4.5.0, unfortunately it is bad for Slackware, because I am going on holiday end of this week, and by now am fed up with endless rebuilds of 4.5.0 packages, only to find that it was all in vain because you are re-tagging the release. Oh well, I'll wait for 4.5.1. That'll keep me sane. Eric -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Two post-4.5.0 patches to fix a serious stability issue in Dolphin
Dear packagers, please consider backporting the following commits to your 4.5.0 packages: http://websvn.kde.org/?revision=1157302view=revision http://websvn.kde.org/?revision=1158288view=revision They fix the bug https://bugs.kde.org/show_bug.cgi?id=232054 It got reported quite frequently recently (many duplicates are not marked yet). Some further information can be found in http://mail.kde.org/pipermail/release-team/2010-August/004044.html http://mail.kde.org/pipermail/release-team/2010-August/004045.html Sorry about the late notification. Thanks, Frank ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
Hello,
On trečiadienis 04 Rugpjūtis 2010 15:09:32 Lubos Lunak wrote:
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.
The latter is exactly my point. libkonq 4.5 is BIC in comparison with libkonq
4.4 and soname was NOT bumped (when should have). So what is opposite there to
my arguments?
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.
Do I decide what ends up in tarballs? No. Things which do not make much sense
are typically not done. So conclusion is that nothing would have been done wrt
kdebase.
Given that there is still a week until 4.5.0, we may find all those BIC cases
and fix them in 4.5 by bumping soname where needed. Would there be any
objections to that? I think this question is on-topic for release-team ML.
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.
Thank you for suggestion. Maybe I will try again. Though even if you do not
agree, this has already been brought up on that list a couple of times before
and I can't say that situation has improved much over time. Yes, libkonq has
not broken BC during 4.x cycle before, but many others non-kde(pim)libs did.
In neither case soname was bumped with a good exception of libplasma when it
was in workspace and moved to kdelibs (libplasma.so.{1,2,3}).
It's probably that the topic is not important or considered as not worth the
extra effort by majority of developers, so I don't expect situation to improve
greatly despite conclusion on k-c-d. It's not me, you or release-team who can
fix all cases each release. What's more, I'm also afraid that when pushing too
hard people might start doing otherwise for the sake of extra safety - bump
soname in advance as soon as trunk opens without checking if changes are BC or
not. Tracking BC is not an easy task.
--
Modestas Vainius modes...@vainius.eu
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Two post-4.5.0 patches to fix a serious stability issue in Dolphin
Sorry everyone, I had missed the mail about the delay of the 4.5.0 release. http://mail.kde.org/pipermail/release-team/2010-August/004050.html The new packages which are tagged later should be fine. Feel free to ignore my previous mail. 2010/8/4 Frank Reininghaus frank7...@googlemail.com: Dear packagers, please consider backporting the following commits to your 4.5.0 packages: http://websvn.kde.org/?revision=1157302view=revision http://websvn.kde.org/?revision=1158288view=revision They fix the bug https://bugs.kde.org/show_bug.cgi?id=232054 It got reported quite frequently recently (many duplicates are not marked yet). Some further information can be found in http://mail.kde.org/pipermail/release-team/2010-August/004044.html http://mail.kde.org/pipermail/release-team/2010-August/004045.html Sorry about the late notification. Thanks, Frank ___ 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 18:01:27 Modestas Vainius wrote:
Hello,
On trečiadienis 04 Rugpjūtis 2010 15:09:32 Lubos Lunak wrote:
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.
The latter is exactly my point. libkonq 4.5 is BIC in comparison with
libkonq 4.4 and soname was NOT bumped (when should have). So what is
opposite there to my arguments?
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.
Do I decide what ends up in tarballs? No. Things which do not make much
sense are typically not done. So conclusion is that nothing would have
been done wrt kdebase.
Given that there is still a week until 4.5.0, we may find all those BIC
cases and fix them in 4.5 by bumping soname where needed. Would there be
any objections to that? I think this question is on-topic for release-team
ML.
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.
Thank you for suggestion. Maybe I will try again. Though even if you do not
agree, this has already been brought up on that list a couple of times
before and I can't say that situation has improved much over time. Yes,
libkonq has not broken BC during 4.x cycle before, but many others
non-kde(pim)libs did. In neither case soname was bumped with a good
exception of libplasma when it was in workspace and moved to kdelibs
(libplasma.so.{1,2,3}).
It's probably that the topic is not important or considered as not worth
the extra effort by majority of developers, so I don't expect situation to
improve greatly despite conclusion on k-c-d. It's not me, you or
release-team who can fix all cases each release. What's more, I'm also
afraid that when pushing too hard people might start doing otherwise for
the sake of extra safety - bump soname in advance as soon as trunk opens
without checking if changes are BC or not. Tracking BC is not an easy
task.
It is not. It should be done by developers themselves when they introduce
features, change code.
But.. such changes happen frequently in trunk (before next branching and after
previous one) so developers would need to either bump SOVERSION every time
they change ABI (hardly optimal, you'd end up with libplasma.so.50 early) or
postpone SOVERSION bump just before tagging for all libraries with public
interface that had their ABI changed. In the second case it's easy to forget
about it.
Also developers usually don't have tools to reliably detect ABI changes - but
disto devs sometimes do.
That being said, those equipped with sufficient tools - if possible - could
run their tool just before tagging and list all libraries with public
interface that need SOVERSION bump on kde-core-devel or kde-buildsystem ml
(but that would mean the need to package RC's in Debian I suppose? no idea
whether other distros have such means).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: BIC in libkonq
On 04.08.10 19:01:27, Modestas Vainius wrote: It's probably that the topic is not important or considered as not worth the extra effort by majority of developers, so I don't expect situation to improve greatly despite conclusion on k-c-d. As I already said, the problem is not that developers don't care, they simply don't know that a soname change is necessary (or they don't know/understand when its necessary). You need to tell them (each and every one) somehow, for example by putting something on techbase and directing the developers in question (via their mailinglist) to the place. They won't notice soname-problems themselves as they only have 1 version of the library installed which all apps link against. It's not me, you or release-team who can fix all cases each release. What's more, I'm also afraid that when pushing too hard people might start doing otherwise for the sake of extra safety - bump soname in advance as soon as trunk opens without checking if changes are BC or not. Tracking BC is not an easy task. Right, tracking all BiC changes by reading commit logs is _extremely_ hard, especially in active projects. So IMHO its a valid way to simply bump soname after a release. If you can't guarantee that your library is BC between two releases (for whatever reason, including that its too much work to track BiC changes, especially since there's no automated way to do it), then the best you can do is bump the soname as soon as a new development cycle starts. Andreas -- Your love life will be... interesting. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.5.0 tarballs (try#2) uploaded
Hi, I just uploaded now the 2nd attempt at KDE 4.5.0 tarballs, freshly created from current KDE 4.5 branch. Please let me know of any issues. Release is targetted now Tuesday next week. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
