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 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
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 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: No more release schedules.
Hello, On penktadienis 10 Birželis 2011 11:49:47 Eric Hameleers wrote: > Again, monolithic tarballs or not, this is not the topic. Coordinating > the release process for all the individual submodules is what is going > to make or break KDE's acceptance. Do I have to remind you of the > consequences of the X.Org release process? For the past years, ever > since X.Org went modular, there has not been a single distro that was > able to deliver a consistently working X desktop. Oh yes. And in the past, with XFree86 or monolithic Xorg X was stable as a rock? That's definitely not true. In my opinion, it was a nightmare (esp. to package). Actually, things improved when Xorg was split because it became possible to get (upstream approved) bugfixes to the users more quickly. Yet I'm not saying that lack of coordination among Xorg modules help things. It surely *does not*. > Why do you think > Wayland gets so much attention? There is total chaos in the release > process for X.Org, individual submodule maintainers decide largely > among themselves what dependencies and what software versions they > require for their releases. As a result, packaging X.Org is not a > pleasant and reqarding experience. With the proposal under discussion, > I predict that KDE is going to foot itself firmly on the same > slippery slope. I don't think that Wayland gets so much attention mainly because of this. Like any very old project, Xorg has much legacy code, which makes codebase very huge and hard to understand, some decisions of the past made development very complicated etc. So sometimes it is easier to rewrite everything from scratch applying modern concepts and techniques. > > On penktadienis 10 Birželis 2011 00:09:16 Eric Hameleers wrote: > > > This now, is exactly what I was afraid for when I voiced my concern > > > about the break-up of this relatively small collection of coherent > > > source tarballs we are used to work with, into a fragmented and > > > potentially disconnected set of individual small (project-oriented) > > > source tarballs. This would mean, KDE as an integrated software > > > collection is dissolving into a loose collection of software perhaps > > > not even branded "KDE" anymore. > > On penktadienis 10 Bir?elis 2011 00:09:16 Eric Hameleers wrote: > > What do small tarballs have to do with this disintegration? I do > > understand that you dislike small well-split tarballs but, seriously, > > don't blame everything on them. It's only a different way how tarballs > > are generated, it has nothing to do with integration or testing. > > Forget about my earlier dislike of splitting into smaller tarballs for > a moment - that issue has nothing to do with this dicscussion at hand. > If KDE release team decides to stop releasing monolithic tarballs, I > will find a way to cope with it - there is more work involved but > essentially the build and packaging process will only have to change > once. For as long as the release process stays co-ordinated and all > sources are released in unison, so that I know what I am packaging. [... snip ...] > So forget about monolithic tarballs please. It is clouding the issue. It was not me who brought monolithic vs. split tarballs up here. So of course I will forget them in this context because I agree they have nothing to do with the topic of this thread. Glad to see misunderstandings cleared up. -- Modestas Vainius 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: No more release schedules.
Hello, On penktadienis 10 Birželis 2011 00:09:16 Eric Hameleers wrote: > > That both makes no sense. Suggestion 1 fails completely with the "if they > > like" part, since we all know already how much pain the "out of sync > > kdepim" caused. Suggestion 2 fails with the "independent of the > > schedules" part, because you can't release somthing that is not > > stabilized and tested. > > > > Please try to get some sense back... > > > > Cheers, > > Andreas > > Andreas, how I agree! > > This now, is _exactly_ what I was afraid for when I voiced my concern > about the break-up of this relatively small collection of coherent > source tarballs we are used to work with, into a fragmented and > potentially disconnected set of individual small (project-oriented) > source tarballs. This would mean, KDE as an integrated software > collection is dissolving into a loose collection of software perhaps > not even branded "KDE" anymore. What do small tarballs have to do with this disintegration? I do understand that you dislike small well-split tarballs but, seriously, don't blame everything on them. It's only a different way how tarballs are generated, it has nothing to do with integration or testing. > Notwithstanding the "frameworks" concept, which sounds appealing, you > should focus on keeping the ecosystem together. Otherwise there will > not be a "KDE SC" soon, but instead "KDE for Slackware, KDE for > Fedora, KDE for Arch, KDE for Windows, KDE for Solaris ..." and every > version will be unpredictably different from the others. Distros are already pretty different with monolithic tarballs. Have you tried various distros lately? Some distros patch or backport more, some less or don't at all, some use official branding, some don't etc. Distros can even skip entire modules if they wish. Or they can skip (and they do) parts of some modules, it just needs a one-line patch to the top CMakeLists.txt. Or apps can be thrown away post-build. KDE might be disintegrating at community level, but being packaged in a better way at the source level does not have anything to do with this. > This > unpredictability kills the killer concept: that KDE transcends > operating systems. I predict that it will end up like GNOME: one > distro adds Gnome Shell, the next adds Unity, and yet another decides > to stick to a forward-ported old version of the desktop manager. This > surely is not what KDE (and its users!) deserve. Well, if a distro wanted to add Unity of KDE, it would. If you seriously think that monolithic tarballs are going stop from doing that, you're really mistaken. -- Modestas Vainius 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 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 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 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 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 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 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 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
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-devel&m=124061169122689&w=2 [2] http://www.mail-archive.com/release-team@kde.org/msg02970.html -- Modestas Vainius 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 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 00:22:54 Dirk Mueller wrote: > On Monday 02 August 2010, George Kiagiadakis wrote: > > Hello, > > > > While packaging KDE 4.5.0 I noticed that libkonq is BIC due to [1]. I > > am wondering why there was no SONAME bump for this. Actually, I was > > about to add a local patch to bump SONAME from 5 to 5a when that came > > into discussion with Tom Albers, who suggested to bring this here. > > Obviously, it is better if this SONAME bump is done upstream. What do > > you think? > > Good point. we should bump it to version 6? Yes, one of the main SONAME purposes is to manage BIC changes. Unfortunately, libraries outside kde(pim)libs break BC all the time but rarely ever bump SOVERSIONs (for example, kdebase-workspace libraries). Hopefully, such a bump in libkonq would set a good example for the future. -- Modestas Vainius 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 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 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
