ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
| 11 .. solid/solid/backends/fstab/fstabdevice.h |3 .. solid/solid/backends/fstab/fstabmanager.cpp | 14 .. solid/solid/backends/fstab/fstabstorageaccess.cpp |3 .. solid/solid/backends/wmi/wmiblock.cpp | 18 .. solid/solid/backends/wmi/wmicdrom.cpp | 55 .. solid/solid/backends/wmi/wmicdrom.h |1 .. solid/solid/backends/wmi/wmidevice.cpp | 332 .. solid/solid/backends/wmi/wmidevice.h | 14 .. solid/solid/backends/wmi/wmimanager.cpp | 254 .. solid/solid/backends/wmi/wmimanager.h | 32 .. solid/solid/backends/wmi/wmiopticaldisc.cpp | 120 .. solid/solid/backends/wmi/wmiopticaldisc.h |4 .. solid/solid/backends/wmi/wmiprocessor.cpp | 149 .. solid/solid/backends/wmi/wmiquery.cpp | 270 .. solid/solid/backends/wmi/wmiquery.h | 26 .. solid/solid/backends/wmi/wmistorage.cpp | 75 .. solid/solid/backends/wmi/wmistorage.h |4 .. solid/solid/backends/wmi/wmistorageaccess.cpp | 49 .. solid/solid/backends/wmi/wmistorageaccess.h |2 .. solid/solid/backends/wmi/wmivolume.cpp | 63 .. solid/solid/backends/wmi/wmivolume.h |4 .. 167 files changed, 7679 insertions(+), 1902 deletions(-) while: $ diff -uNr kdelibs-4.8.80 kdelibs-4.8.4 | diffstat -f 3 CMakeLists.txt|4 -. README|2 .. doc/kioslave/data/index.cache.bz2 |binary doc/kioslave/file/index.cache.bz2 |binary doc/kioslave/ftp/index.cache.bz2 |binary doc/kioslave/help/index.cache.bz2 |binary doc/kioslave/http/index.cache.bz2 |binary doc/kioslave/mailto/index.cache.bz2 |binary doc/kioslave/rlogin/index.cache.bz2 |binary doc/kioslave/telnet/index.cache.bz2 |binary doc/kioslave/webdav/index.cache.bz2 |binary doc/sonnet/index.cache.bz2|binary kdecore/sycoca/ksycoca.cpp|2 .. kdeui/dialogs/kshortcutschemeseditor.cpp |5 -- kio/kio/tcpslavebase.cpp | 20 +++--. plasma/package.cpp| 57 +- solid/solid/backends/fstab/fstabmanager.cpp | 14 +++--- solid/solid/backends/upower/upowerbattery.cpp |7 ---... 18 files changed, 42 insertions(+), 69 deletions(-) I don't know yet if any other modules from 4.8.4 has been mis-packaged in the same way -- Modestas Vainius mo...@debian.org 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: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
Hello, On šeštadienis 09 Birželis 2012 13:01:20 Albert Astals Cid wrote: here at Debian we had a really bad experience with 4.8.4. While 4.8.3 was pretty good, 4.8.4 seemed like a huge step backwards in terms of stability (random crashes there and there). After quick investigation of kdelibs 4.8.4 I found the following: I don't know yet if any other modules from 4.8.4 has been mis-packaged in the same way There's no mispackaging. If you followed the list or read the archives before blaming people of wrong doing you'd know that kdelibs for 4.8.4 and 4.8.80 actually come from the same branch. Thank you for pushing a bunch of untested huge changes in the minor point release. Really appreciated. -- Modestas Vainius mo...@debian.org 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: git migration, next steps
Hello, On penktadienis 03 Birželis 2011 17:27:41 Rex Dieter wrote: On 06/03/2011 09:19 AM, Jeremy Whiting wrote: As you may or may not know kdeaccessibility and kdeutils are ready to migrate to git (when the freeze is over, don't worry). And we'd like to know what the feeling is about the best time to migrate to minimize packaging/releasing stresses. We'd also like to know what packagers/release-team think of the split repos already done in kde-edu, etc. Should we provide artificial monolithic tarballs? I would advocate for monolithic tarballs (again) in general (not just kdeedu), the current quasi-arbitrary half-done hodge-podge kde-4.6.80 tarballs are quite a mess (with both my packager and release-team hats on). Split tarballs *after* migrations are final and where it can be carefully planned and executed would be more welcome, say for kde-4.8. Personally, I'm in favour of split tarballs. But as there seems to be so much opposition to this approach [1], I could take return to old ways with everything except kdebindings. Could you please keep that ugly beast split in 4.7 and on onwards? Btw, a decision (whatever it is) needs to be made quickly and some real work *must be put* to implement it in case you decide to go back to those monolithic tarballs. With so much uncertainty in the air, nobody valuing his/her own time will package any betas or RCs until there is no way back when 4.7final is released. [1] Do you really want to go back in time when Xorg/XFree86 was monolithic? Xorg 6.9.0 died pretty fast and there was a good reason for it. -- Modestas Vainius mo...@debian.org 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: KDE 4.6.4 uploaded (try#1)
Hello, On šeštadienis 04 Birželis 2011 11:18:50 Stephen Kelly wrote: Anyway, please create tarballs from the 4.6 branch for kdepim and kdepim- runtime. They will be released at the same time as 4.6.4, but they're still not technically part of the SC in 4.6. I don't know if that makes any difference to your process or where the tarballs actually go etc. Why? How can KDE SC 4.6.4 and kdepim 4.6.0 be the same release? Sure, kdepim 4.6.0 can be released at the same time as SC 4.6.4 but, imho, kdepim 4.6 should NOT be part of SC 4.6.x up until 4.7. In particular, please do not start including kdepim* translations in the kde-l10n tarballs and keep them in kdepim* tarballs. In general, IMHO, it's a pretty bad idea to do such changes so late in KDE SC 4.6 release cycle. -- Modestas Vainius mo...@debian.org 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: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
Hello, On sekmadienis 22 Gegužė 2011 00:29:10 Wulf C. Krueger wrote: The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. I strongly disagree. Splitting KDE SC up more is a step in the right direction as it allows for easier control about what to install. Since unrelated or slightly related applications are no longer bundled in the same source package, each package is faster to build and links fewer system components together. In the end, users can freely choose what to install and maintainers what and how to package. I am afraid that for Slackware, the bloat in KDE packages is not acceptible from a maintenance point of view. Again, I disagree. Yes, it's a bit more work but it reduces the bloat for users in the end. Most people don't need everything KDE SC has to offer and, thus, it's well worth some effort. The split does not bloat KDE SC since it has been bloated for a long time already. On the contrary, the split allows to ignore applications which are not that important for the distro (but used to be shipped in the bundle next to important applications). Also more people can work in parallel and responsibilities can be split according to the maintainer/user interest in the applications themselves. Therefore I also welcome the split very much and please continue the work in this direction. -- Modestas Vainius mo...@debian.org 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: KDE 4.6.2 tarballs (try#1)
Hello, On Monday 04 April 2011 23:37:19 Dirk Mueller wrote: On Monday 04 April 2011, Modestas Vainius wrote: So has it been decided that kde-l10n-* tarballs will be shipping konq-plugins translations from now on? I don't care either way, what do you recommend? Neither do I as long as it's not going to change in the future :-) konq- plugins is in kdebase already anyway. So if everybody is OKay with that, let it stay this way. -- Modestas Vainius mo...@debian.org 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: KDE 4.6.2 tarballs (try#1)
Hello, On Friday 01 April 2011 22:47:44 Dirk Mueller wrote: I just finished uploading the first set of tarballs. kdegraphics probably does not build yet, but other than that, I see good intermediate results already. Please report any serious issues or build failures with those tarballs to me. So has it been decided that kde-l10n-* tarballs will be shipping konq-plugins translations from now on? -- 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
Hello, On pirmadienis 09 Rugpjūtis 2010 17:07:17 Jonathan Riddell wrote: On Mon, Aug 09, 2010 at 02:57:20PM +0100, Richard Moore wrote: On Mon, Aug 9, 2010 at 10:47 AM, David Faure fa...@kde.org wrote: I'm perfectly fine with increasing the SOVERSION now. 5a or 6? I wasn't aware that one could use letters in the SOVERSION :) 6 Please, or we'll start joining the openssl version number insanity! I don't see any point in doing that now. The BIC change was in January and we've had 4.4 and 4.5 releases since then. 4.5 has not been released yet. -- 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
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
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
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: phonon-4.3.1 tarballs gone
Hello, On penktadienis 30 Spalis 2009 02:56:17 Maciej Mrozowski wrote: If you refer to phonon-backends source tarball of http://packages.debian.org/sid/phonon-backend-xine it's clear that it's just renamed phonon tarball. And I think what's proposed here is distributing (and thus allowing to build with no cmake hackery involved) phonon backends separately from phonon, and allowing them to build against phonon that's distributed with Qt4. From packager's perspective, it would be really nice to have it finally sorted out. Sure, I'm just saying that it would be nice to have a tarball with ALL backends (including gstreamer one which is released with Qt). -- 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: phonon-4.3.1 tarballs gone
Hello, On ketvirtadienis 29 Spalis 2009 23:47:58 Martin Sandsmark wrote: Torsdag 29. oktober 2009 22.32.50 skrev Nicolas Lécureuil : i am not in favor of this because there is fixes in the phonon gstreamer engine that are not in Qt itself . How to simply have qt branch synced ? I assume they will import the GSTreamer engine over to Qt as well. So the only we need to release separately is Phonon-Xine. I would prefer for tarball to keep ALL backends (aka phonon-backends package). This has worked well so far, why try to fix things which aren't broken? -- 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
