Re: Tarballs missing from Plasma 5.90.0
Yeah, I had noticed new tarballs in the Plasma directory and was already looking for their purpose, thanks for sharing those release notes (I should have looked there first). On Wed, 20 Dec 2023, Jonathan Riddell wrote: See release notes, they were renamed https://community.kde.org/Plasma/Plasma_6.0_Release_notes#Tars_Moved_From_Frameworks On Wed, 20 Dec 2023 at 18:42, Eric Hameleers wrote: Hi all, Somehow I never saw an announcement of Plasma 5.90.0 source availability but I am now about to gather everything needed for the Beta2 Mega Release. Looking at download.kde.org I still see Plasma 5.90.0 but not the 5.91.0 which I expected to be there. And in 5.90.0 the following packages are missing which migrated over from Frameworks and were present in Plasma 5.27.80: - kactivities - kactivities-stats - plasma-framework But kwayland is there, strange enough (also moved from Frameworks). Can a Plasma 5.91.0 release be cut please, including these missing three tarballs? Cheers, Eric -- Eric Hameleers Home: http://alien.slackbook.org/blog/ Cheers, Eric -- Eric Hameleers Home: http://alien.slackbook.org/blog/
Tarballs missing from Plasma 5.90.0
Hi all, Somehow I never saw an announcement of Plasma 5.90.0 source availability but I am now about to gather everything needed for the Beta2 Mega Release. Looking at download.kde.org I still see Plasma 5.90.0 but not the 5.91.0 which I expected to be there. And in 5.90.0 the following packages are missing which migrated over from Frameworks and were present in Plasma 5.27.80: - kactivities - kactivities-stats - plasma-framework But kwayland is there, strange enough (also moved from Frameworks). Can a Plasma 5.91.0 release be cut please, including these missing three tarballs? Cheers, Eric -- Eric Hameleers Home: http://alien.slackbook.org/blog/
Re: KDE Gear 24.02 Alpha packages available
On Thu, 9 Nov 2023, Albert Astals Cid wrote: El dijous, 9 de novembre de 2023, a les 7:46:34 (CET), Eric Hameleers va escriure: On Wed, 8 Nov 2023, Albert Astals Cid wrote: Please everyone wait for the actual "Mega release" announcement before starting to make noise, but you can start compiling things. I have not had time to compile them locally but CI says things should mostly build. https://community.kde.org/KDE_Gear/24.02_Release_notes https://kde.org/info/sources/source-releases-24.01.75.html Cheers, Albert P.S: https://kde.org/info/releases-24.01.75 should have been created but it wasn't and I don't know why ^_^ Hi, Kleopatra looks for MimeTreeParser and fails to build without it. However, MimeTreeParser was not part of the Alpha release. Can a tarball for mimetreeparser be created please? Done. Cheers, Albert Thanks! Cheers, Eric -- Eric Hameleers Home: http://alien.slackbook.org/blog/
Re: KDE Gear 24.02 Alpha packages available
On Wed, 8 Nov 2023, Albert Astals Cid wrote: Please everyone wait for the actual "Mega release" announcement before starting to make noise, but you can start compiling things. I have not had time to compile them locally but CI says things should mostly build. https://community.kde.org/KDE_Gear/24.02_Release_notes https://kde.org/info/sources/source-releases-24.01.75.html Cheers, Albert P.S: https://kde.org/info/releases-24.01.75 should have been created but it wasn't and I don't know why ^_^ Hi, Kleopatra looks for MimeTreeParser and fails to build without it. However, MimeTreeParser was not part of the Alpha release. Can a tarball for mimetreeparser be created please? Cheers, Eric -- Eric Hameleers Home: http://alien.slackbook.org/blog/
Re: Plasma 5.25 beta
That's just confusing me to no end. On Thu, 19 May 2022, Jonathan Riddell wrote: Please note that plasma-remotecontrollers should not have been included in this beta release and will not be included in the final Plasma 5.25 releases. Cheers, Eric -- Eric Hameleers Home: http://alien.slackbook.org/blog/
Re: KDE Frameworks 5.43.0
On Wed, 7 Feb 2018, Andrius ?tikonas wrote: 2018 m. vasario 7 d., tre?iadienis 12:56:23 GMT Eric Hameleers ra??: On Wed, 7 Feb 2018, Aleix Pol wrote: On Tue, Feb 6, 2018 at 11:46 PM, Eric Hameleers <al...@slackware.com> wrote: On Mon, 5 Feb 2018, David Faure wrote: Dear packagers, KDE Frameworks 5.43.0 has been uploaded to the usual place. New frameworks: kholidays and purpose (the purpose is to go on holidays, clearly). Public release next Saturday. Thanks for the packaging work! According to https://api.kde.org/frameworks/index.html , purpose is a Tier-1 Framework and should depend only on Qt and possibly a small number of 3rd party libraries. But I find that purpose refuses to compile without kio (supposedly a Tier-3 Framework) and kaccounts-integration (from Applications). I think this new Framework was added in a haste? Better to add it to Applications instead? Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ I'll change the tier. Aleix That won't fix everything. If purpose depends on kaccounts-integration (from Applications) then it can not be a Framework, right? Cheers, Eric I uninstalled kaccounts-integration and purpose still compiles fine. Yes, it prints a warning that kaccounts is not available, but still compiles. Thanks, I will try again. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/
Re: KDE Frameworks 5.43.0
On Wed, 7 Feb 2018, Aleix Pol wrote: On Tue, Feb 6, 2018 at 11:46 PM, Eric Hameleers <al...@slackware.com> wrote: On Mon, 5 Feb 2018, David Faure wrote: Dear packagers, KDE Frameworks 5.43.0 has been uploaded to the usual place. New frameworks: kholidays and purpose (the purpose is to go on holidays, clearly). Public release next Saturday. Thanks for the packaging work! According to https://api.kde.org/frameworks/index.html , purpose is a Tier-1 Framework and should depend only on Qt and possibly a small number of 3rd party libraries. But I find that purpose refuses to compile without kio (supposedly a Tier-3 Framework) and kaccounts-integration (from Applications). I think this new Framework was added in a haste? Better to add it to Applications instead? Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ I'll change the tier. Aleix That won't fix everything. If purpose depends on kaccounts-integration (from Applications) then it can not be a Framework, right? Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/
Re: KF 5.37 requiring Qt 5.7
On Wed, 2 Aug 2017, David Faure wrote: According to the policy that KF5 should work with the last 3 releases of Qt5.x, it is time now for upcoming releases of KF5 to drop support for Qt 5.6. Packagers: is that acceptable? Normally I would have just gone ahead with applying the policy, but after my recent finding that even some very recent distributions are still on Qt 5.6 LTS, I just want to make sure. (On the other hand I guess it's fine in the actual case I know about, given that the OpenSuSE KDE:Frameworks5 repo is based on Qt 5.9) I don't see an issue for Slackware. Officially we do not even ship Plasma 5 yet (nor do we ship Qt 5) and my 'unofficial' Plasma 5 package repository is already being built against Qt 5.9. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/
Re: KDE Applications 17.04.0 packages available for packagers
On Fri, 14 Apr 2017, Albert Astals Cid wrote: At the usual location. Haven't had time to compile yet, will start now. REVISIONS_AND_HASHES file at https://paste.kde.org/ptskor7sa Public release next week thursday. Cheers, Albert After compiling marble, I end up with these library files and links: $ ll /usr/lib64/libmarblewidget-qt5.so* lrwxrwxrwx 1 root root 25 Apr 16 13:07 /usr/lib64/libmarblewidget-qt5.so -> libmarblewidget-qt5.so.27* -rwxr-xr-x 1 root root 7854768 Apr 16 12:56 /usr/lib64/libmarblewidget-qt5.so.0.26.20* lrwxrwxrwx 1 root root 30 Apr 16 13:07 /usr/lib64/libmarblewidget-qt5.so.27 -> libmarblewidget-qt5.so.0.26.20* Why the ".so.27"? As a result, digikam (compiled against marble 16.12.3) complains with "error while loading shared libraries: libmarblewidget-qt5.so.26" Looking at the library name "libmarblewidget-qt5.so.0.26.20" I would expect the symlink to end on 26, instead of 27. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/
Re: Review of special packager access
On Fri, 8 Jul 2016, Ben Cooksley wrote: Hi all, My apologies if you're not a packager or someone associated with a distribution - you can ignore this email. Packagers, please read on as this contains important details. First: If you're a packager, please ensure you are subscribed to kde-distro-packag...@kde.org, which is our usual list for communicating with packagers. It would seem a number of you are missing from there :) Prompted by a recent email I took a look at the list of accounts (one per distribution) which are provided in order to facilitate early access to packages - however for many i've no idea who would be the relevant point of contact. I'd therefore like for someone from each distribution to please confirm that their distro is still active and who can serve as a general point of contact for that distribution. It would also be appreciated if folks could check over their ~/.ssh/authorized keys file and remove any outdated keys. If your distribution has completely lost access, please have someone with an email address belonging to that distribution's domain email sysad...@kde.org to sort that out. KDE servers normally use a format something like this to clearly label whose key(s) are whose, for those that might find it helpful.: ## Name <email.address@domain> ssh-rsa ## Next Name The list of accounts, which should approximately correspond to distributions, is as follows: - Active - Aix - Aosc - Archlinux - Arklinux - Asplinux - Bluewhite64 - Chakra - Conectiva - Crux - Darwin - Debian - Exherbo - Fedora - FreeBSD - Gentoo - Kaos - Mageia - Magic - Mandriva - Meego - NetBSD - OpenBSD - PCLinuxOS - PLD - Redhat - Rpath - Siduction - Slackware - Slamd64 - SUSE - Tld - Tru64 - Tukaani - Turbo - Ubuntu - Uludag - Uoirix - Uomandriva - Uosolaris - Vine - Yellow - Yoper In two weeks time we'll go ahead and disable ones we don't get a response from. Thanks, Ben Cooksley KDE Sysadmin I confirm that Slackware is still alive and using the early access to the KDE source tarballs. You can use the following contacts: Patrick Volkerding Eric Hameleers Note that as far as I know, Bluewhite64 and Slamd64 (two Slackware 64bit spinoffs from before Slackware had its own 64bit edition) are dead for years now. And Tukaani is no longer a (slackware based) distro but now only develops XZ compression tools. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Plasma 5.7.0 tars
On Thu, 30 Jun 2016, David Edmundson wrote: Fixed - and checked a bit more thorougly this time. Thanks again. David I have two compile errors in plasma-desktop which were not there when I built the 5.6.95 tarballs: ... [ 93%] Building CXX object applets/trash/plugin/CMakeFiles/trashplugin.dir/trash plugin.cpp.o [ 93%] Building CXX object applets/pager/CMakeFiles/pagerplugin.dir/plugin/pager .cpp.o [ 93%] Building CXX object containments/desktop/plugins/desktop/CMakeFiles/desktopplugin.dir/systemsettings.cpp.o /tmp/kde-build/plasma/plasma-desktop-5.7.0/applets/pager/plugin/pager.cpp:52:18: fatal error: task.h: No such file or directory compilation terminated. applets/pager/CMakeFiles/pagerplugin.dir/build.make:86: recipe for target 'applets/pager/CMakeFiles/pagerplugin.dir/plugin/pager.cpp.o' failed make[2]: *** [applets/pager/CMakeFiles/pagerplugin.dir/plugin/pager.cpp.o] Error 1 CMakeFiles/Makefile2:7980: recipe for target 'applets/pager/CMakeFiles/pagerplugin.dir/all' failed make[1]: *** [applets/pager/CMakeFiles/pagerplugin.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs [ 93%] Building CXX object containments/desktop/plugins/desktop/CMakeFiles/desktopplugin.dir/desktopplugin_automoc.cpp.o [ 93%] Building CXX object applets/trash/plugin/CMakeFiles/trashplugin.dir/trashplugin_automoc.cpp.o ... and later: ... [ 88%] Building CXX object applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/ plugin/backend.cpp.o In file included from /tmp/kde-build/plasma/plasma-desktop-5.7.0/applets/taskmanager/plugin/backend.cpp:22:0: /tmp/kde-build/plasma/plasma-desktop-5.7.0/applets/taskmanager/plugin/backend.h: 26:26: fatal error: groupmanager.h: No such file or directory compilation terminated. applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/build.make:62: recipe for target 'applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/backend.cpp.o ' failed make[2]: *** [applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/backend.cpp.o] Error 1 CMakeFiles/Makefile2:7874: recipe for target 'applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/all' failed make[1]: *** [applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2 What's up? Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 16.04.0 packages available for packagers
On Fri, 15 Apr 2016, Martin Graesslin wrote: Please understand this. As a distro packager, I would welcome a simple piece of documentation written by the developer that is *not* a CMakeLists.txt file. At Plasma we are currently discussing a metadata format for our projects including the inter-project dependencies. Please have a look at https:// mail.kde.org/pipermail/plasma-devel/2016-April/051581.html whether that would help you. Inter-project dependencies need to be stored in a central repository. Otherwise it is *impossible* for scripts such as kdesrc-build as well as the CI system to resolve project dependencies (because you need to drag in dependencies of dependencies). This issue is actually more severe for kdesrc-build which needs to be able to resolve the dependency tree to determine the build order. Please consult with those of us who have worked on inter-project dependency stuff within KDE before when making proposals such as this. Please note that this does not intend to replace the global dependency data. It's more intended to be of use for distributions. I completely understand Eric's concerns and are trying to address exactly that. The main problem with the more global build data is that it's rolling. It doesn't preserve the dependencies. E.g. if I would look at build metadata for KWin right now it would not match the dependencies of the Plasma 5.6 releases. As the metadata is bundled with the tarball it would be up to date. Cheers Martin I understand that the CI tools need to be able to resolve interdependencies. So, why not use CI functionality to generate a global dependency list and publish that? It would be an essential first stop for everyone trying to compile KDE components. But Martin's proposal is a sane one, too. If a project documents internally, in its own release tarballs, in an agreed-upon file format, which other KDE components it is relying on, that would be helpful indeed for distro packagers. The CI tools will probably only look at git head and not bother with releases (correct me if I am wrong). But the developer will have to keep a dependency list (obscure and not easily readable to human eyes) in CMakeLists anyway, so doing the same in a human-readable way is a bonus for us, humans. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 16.04.0 packages available for packagers
On Thu, 14 Apr 2016, Albert Astals Cid wrote: El dijous, 14 d?abril de 2016, a les 13:42:18 CEST, Eric Hameleers va escriure: On Thu, 14 Apr 2016, Albert Astals Cid wrote: At the usual location. Haven't had time to compile yet, will try to get to it on monday since this weekend i'm away at Akademy-es. REVISIONS_AND_HASHES file at https://paste.kde.org/pfq4epsxp Cheers, Albert Albert, there is a great many new tarballs: We do Beta and RC for a reason, seems you're realizing a bit too late ;) Well... Keeping a KDE package repository uptodate with the ever evolving Frameworks, Plasma and Application tarballs is already taking enough time just when tracking stable releases. We are a small team, KDE packaging is just one of the things I do. Stuff like LibreOffice, Chromium, multilib compilers and Slackware Live come on top. Know what - I pass on Beta and RC versions. libksieve messagelib libgravatar libkdepim kdgantt2 incidenceeditor eventviews grantleetheme kdepim-apps-libs mailimporter minuet libkleo kdepim-addons pimcommon mailcommon kleopatra calendarsupport There are more new tarballs, minuet, ktp-call-ui, kde-l10n-ast at least I also pointed a list to the new tarballs in old emails about KDE Applications 16.04, i'll leave as an exercise for you to search for it. Helpful, as always. But I can read diffs of directory listings thank you. It takes me exactly one command to get a listing of tarballs that are not yet being used in my build framework, so this is a irrelevant comment... I am interested in *build order* . I assume these belong to KDEPIM. Where is their build order documented - also in relation to the other pre-existing tarballs? In their CMakeLists.txt, in the kde-build-metadata repo and in the totally random order i use to build packages that seemed to work last time (don't take this as anything official) http://paste.ubuntu.com/15838970/ Please understand this. As a distro packager, I would welcome a simple piece of documentation written by the developer that is *not* a CMakeLists.txt file. If you develop software and cut that into 20 tarballs, it does not cost you blood to write up what a packager needs to do with them. If every distro needs to figure out a build order, you introduce randomness in the resulting packages and therefore you make it a lot more difficult to troubleshoot the resulting bugs when end users report them back to you. Now that paste is more like something of a serious answer to a serious question. You do have some interesting differences in build order, compared to me. I will figure something out locally, as I do want my target audience to experience the new Plasma/Applications sooner rather than later. Cheers, Albert Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 16.04.0 packages available for packagers
On Thu, 14 Apr 2016, Albert Astals Cid wrote: At the usual location. Haven't had time to compile yet, will try to get to it on monday since this weekend i'm away at Akademy-es. REVISIONS_AND_HASHES file at https://paste.kde.org/pfq4epsxp Cheers, Albert Albert, there is a great many new tarballs: libksieve messagelib libgravatar libkdepim kdgantt2 incidenceeditor eventviews grantleetheme kdepim-apps-libs mailimporter minuet libkleo kdepim-addons pimcommon mailcommon kleopatra calendarsupport I assume these belong to KDEPIM. Where is their build order documented - also in relation to the other pre-existing tarballs? Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Packaging of Wayland session
On Wed, 9 Dec 2015, Martin Graesslin wrote: Hi KDE distro packagers, as you probably are aware Plasma 5.5 is the first release shipping a Wayland session file. In the current state the session is not much usable as can be seen in the known issues section. Given that I expect that distributions move the relevant files * startplasmacompositor * startplasma * plasmawayland.desktop into a dedicated package (plasma-desktop-wayland-session) and do not install it by default! We don't want users to select the Wayland session by accident and run into a broken system. Also please see https://community.kde.org/KWin/Packaging for advice on how to package the Wayland session elements. Best Regards Martin Gräßlin Well... Slackware does not create sub-packages, that does not fit in with our philosophy. I expect that the sources are configured to *not* enable compiling the session components by default? Not having checked out Plasma 5.5 yet, I guess I will eventually find out whether I need to explicitly disable building it, or else delete the offending files from the package afterwards. I do not want to ship stuff with Plasma 5.5 that is really just a tech preview and gives the user the wrong impression. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Packaging of Wayland session
On Wed, 9 Dec 2015, Bhushan Shah wrote: Hi, On Wed, Dec 9, 2015 at 3:13 PM, Eric Hameleers <al...@slackware.com> wrote: I think that not shipping the session file in its default location but instead adding it to the documentation directory would be the most desirable way forward for me and my Slackware packages. I know about the hard dep on Wayland, that is not a problem. I am more concerned about user experience. People who want to tinker and test should indeed be given that opportunity. I am not sure but, what version of sddm Slackware is using? Thanks! it is SDDM 0.13.0 currently. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
On Wed, 28 Oct 2015, Martin Graesslin wrote: On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote: I like the idea of getting more visibility for bugfixes that will give the enduser a better Plasma experience. Ideal for me would be a patch tracker (not the same as a bug tracker) where intermediate patches are made available that are scheduled for inclusion in the next release. That allows me as a package builder to assimilate those patches if I think they can not wait until the next release. That sounds like you just want the latest stable git branch, in this example Plasma/5.5? No, of course not. I consider the git branch to be in eternal flux. The git HEAD may contain valuable usability patches but also other meh stuff that can wait until the next major release. I do not want to dig through hashes and commits to find out whether you solved some blocking issue. Please never do that! You are risking the quality of the product. What you consider the "meh stuff" might be a very required patch to make the software work together with other patches. I also understood your request for a patch tracker in the same way as sebas and Albert and that you just need a better way to get the patches from git. Anything else is not realistic. If I do a commit to a stable branch of course it is a required bug fix and not some "meh stuff". We have policies and we keep to it. A patch tracker, containing patches you (the developers) consider critical and which should find their way to the user ASAP, that is a place where I would look. It doesn't work that way. Let's say I have this super critical bug fix done for 5.4.3, I mark that as critical in the patch tracker. Then you roll it out, what might happen: a) it doesn't even compile b) it breaks in horrible, horrible runtime ways Why? Because it build up on a "not so super critical bug fix" from the 5.4.2 release which you did not include. This doesn't make sense. We will never be able to guarantee that this works. We have a stable release branch which gets CI tested. We don't have a random set of patches which gets CI tested. If we had that, well what would be the difference to the stable branch? Anyway: I would like to come back to the actual discussion whether more bug fix releases can be delivered by the distributions. Cheers Martin Then I would vote for your original proposal of staggered intermediate releases in quick succession. At least that way we get a consistent set of source tarballs, and it is up to the distro maintainers to decide if they want to use all, or only some, of these intermediate releases. Oh well, at least I sparked a fruitful discussion ;-) Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
On Tue, 27 Oct 2015, Martin Graesslin wrote: Hi distribution maintainers, I was thinking about the problem of how we can get bug fixes quicker to our user. With a three month release cycle a one-month bug fix cycle sounds too long to me. So I thought we should make bug fix releases faster and more often. In 5.4 we already went for this partially by having the first bug fix earlier. I wanted to know how much work this would mean for our distributions. If we ship out way more bug fix releases, would you be able to work with it? Would it block you? Would you have to skip releases? Or is it just pressing a button to run automatic scripts which upload your packages? What had I been thinking about? I was thinking about a Fibonacci based release schedule. This gives us quick bug fix releases directly after the release with slowly larger intervals. Of course it would mean tag and release happens on same day. So a hypothetical release schedule for Plasma 5.5 could look like: * 2015-12-08: 5.5.0 * 2015-12-15: 5.5.1 * 2015-12-22: 5.5.2 * 2016-01-05: 5.5.3 * 2016-01-26: 5.5.4 (* 2016-03-01: 5.5.5) Opinions? Cheers Martin I like the idea of getting more visibility for bugfixes that will give the enduser a better Plasma experience. Ideal for me would be a patch tracker (not the same as a bug tracker) where intermediate patches are made available that are scheduled for inclusion in the next release. That allows me as a package builder to assimilate those patches if I think they can not wait until the next release. I do much more than maintaining the Plasma 5 package set for Slackware. So my users get an update once a month, where I incorporate the latest Frameworks, Plasma and Applications. It is just not humanly possible to do more than that. Internediate patch releases will be ignored by me, that is why I hinted at a patch tracker instead. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
On Tue, 27 Oct 2015, Martin Graesslin wrote: On Tuesday, October 27, 2015 6:25:42 AM CET Eric Hameleers wrote: On Tue, 27 Oct 2015, Martin Graesslin wrote: Hi distribution maintainers, I was thinking about the problem of how we can get bug fixes quicker to our user. With a three month release cycle a one-month bug fix cycle sounds too long to me. So I thought we should make bug fix releases faster and more often. In 5.4 we already went for this partially by having the first bug fix earlier. I wanted to know how much work this would mean for our distributions. If we ship out way more bug fix releases, would you be able to work with it? Would it block you? Would you have to skip releases? Or is it just pressing a button to run automatic scripts which upload your packages? What had I been thinking about? I was thinking about a Fibonacci based release schedule. This gives us quick bug fix releases directly after the release with slowly larger intervals. Of course it would mean tag and release happens on same day. So a hypothetical release schedule for Plasma 5.5 could look like: * 2015-12-08: 5.5.0 * 2015-12-15: 5.5.1 * 2015-12-22: 5.5.2 * 2016-01-05: 5.5.3 * 2016-01-26: 5.5.4 (* 2016-03-01: 5.5.5) Opinions? Cheers Martin I like the idea of getting more visibility for bugfixes that will give the enduser a better Plasma experience. Ideal for me would be a patch tracker (not the same as a bug tracker) where intermediate patches are made available that are scheduled for inclusion in the next release. That allows me as a package builder to assimilate those patches if I think they can not wait until the next release. do you have ideas how this could work? Do you know of any existing (web)applications to keep track of it? If there is some it should be relatively easy to set it up - "just" some git hooks for commits on the stable branch. I do much more than maintaining the Plasma 5 package set for Slackware. So my users get an update once a month, where I incorporate the latest Frameworks, Plasma and Applications. It is just not humanly possible to do more than that. Internediate patch releases will be ignored by me, that is why I hinted at a patch tracker instead. Ok, thank's for the info. So in that case given the schedule I outlined I expect you would go with 5.5.2 or 5.5.3 and skip the previous ones? Cheers Martin Hi Martin, Indeed I would aim to skip at least the .0 releases and perhaps even the .1 releases. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
On Tue, 27 Oct 2015, Sebastian Kügler wrote: On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote: I like the idea of getting more visibility for bugfixes that will give the enduser a better Plasma experience. Ideal for me would be a patch tracker (not the same as a bug tracker) where intermediate patches are made available that are scheduled for inclusion in the next release. That allows me as a package builder to assimilate those patches if I think they can not wait until the next release. That sounds like you just want the latest stable git branch, in this example Plasma/5.5? No, of course not. I consider the git branch to be in eternal flux. The git HEAD may contain valuable usability patches but also other meh stuff that can wait until the next major release. I do not want to dig through hashes and commits to find out whether you solved some blocking issue. A patch tracker, containing patches you (the developers) consider critical and which should find their way to the user ASAP, that is a place where I would look. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
On Tue, 27 Oct 2015, Albert Astals Cid wrote: El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure: On Tue, 27 Oct 2015, Albert Astals Cid wrote: El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure: On Tue, 27 Oct 2015, Sebastian Kügler wrote: On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote: I like the idea of getting more visibility for bugfixes that will give the enduser a better Plasma experience. Ideal for me would be a patch tracker (not the same as a bug tracker) where intermediate patches are made available that are scheduled for inclusion in the next release. That allows me as a package builder to assimilate those patches if I think they can not wait until the next release. That sounds like you just want the latest stable git branch, in this example Plasma/5.5? No, of course not. I consider the git branch to be in eternal flux. The git HEAD may contain valuable usability patches but also other meh stuff that can wait until the next major release. I do not want to dig through hashes and commits to find out whether you solved some blocking issue. A patch tracker, containing patches you (the developers) consider critical and which should find their way to the user ASAP, that is a place where I would look. Yes, of course yes. Every single patch commited to a stable branch is a bugfix and thus the developer considers critical and should be released as soon as possible to users, otherwise instead of to the stable branch the developer would commited the patch to the development branch. Cheers, Albert You developers are so funny, my false teeth fell out from shaking. I did a serious reply to your comment and all i got back was sarcasm, please let's try to be constructive, otherwise what's the point of having this discussions? Do you really think we commit things that are not bugfixes to stable branches? Can you name some "meh stuff" that was commited to a stable branch and in your opinion should have waited for the next major release? Says the master of sarcasm. I was being constructive. Please put on your release management hat. But you are indeed correct, I should adjust one of my statements, by s/major/minor/ ; patches should not have to wait for the next *major* release. However, I id not interpret your reply as anywhere near serious. If your view of distro packaging is that the packager should follow the git commits from day to day, minute to minute then you need to adjust your view of distro development. It is OK for *developers* to sit on top of the git commits since that is what they do. A packager on the other hand needs proper releases, because that makes the user's experience of the distro deterministic and will add the developer in triaging the bug reports because he knows what source went into the distro. If the developer wants to push critical patches downstream, then the developer still wants deterministic behaviour from the binaries produced by the distros and therefore a proper patch-release management is crucial. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More Plasma bug fix releases
On Tue, 27 Oct 2015, Albert Astals Cid wrote: El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure: On Tue, 27 Oct 2015, Sebastian Kügler wrote: On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote: I like the idea of getting more visibility for bugfixes that will give the enduser a better Plasma experience. Ideal for me would be a patch tracker (not the same as a bug tracker) where intermediate patches are made available that are scheduled for inclusion in the next release. That allows me as a package builder to assimilate those patches if I think they can not wait until the next release. That sounds like you just want the latest stable git branch, in this example Plasma/5.5? No, of course not. I consider the git branch to be in eternal flux. The git HEAD may contain valuable usability patches but also other meh stuff that can wait until the next major release. I do not want to dig through hashes and commits to find out whether you solved some blocking issue. A patch tracker, containing patches you (the developers) consider critical and which should find their way to the user ASAP, that is a place where I would look. Yes, of course yes. Every single patch commited to a stable branch is a bugfix and thus the developer considers critical and should be released as soon as possible to users, otherwise instead of to the stable branch the developer would commited the patch to the development branch. Cheers, Albert You developers are so funny, my false teeth fell out from shaking. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Noto font for Plasma 5.5
On Fri, 16 Oct 2015, Jonathan Riddell wrote: The Plasma team plan to switch to Noto for Plasma 5.5 https://www.google.com/get/noto/ Distros will need packages of it. Let me know if anyone has problems with this Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team Almost 500 MB download for these fonts? I surely hope that you only want to use a small subset. I will have a problem in Slackware otherwise - 500 MB add-on just for some fonts will meet with a veto in the distro. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Noto font for Plasma 5.5
On Fri, 16 Oct 2015, Jonathan Riddell wrote: On Fri, Oct 16, 2015 at 10:38:58AM -0700, Eric Hameleers wrote: On Fri, 16 Oct 2015, Jonathan Riddell wrote: The Plasma team plan to switch to Noto for Plasma 5.5 https://www.google.com/get/noto/ Distros will need packages of it. Let me know if anyone has problems with this Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team Almost 500 MB download for these fonts? I surely hope that you only want to use a small subset. I will have a problem in Slackware otherwise - 500 MB add-on just for some fonts will meet with a veto in the distro. I think that's the source for the complete set. The Latin languge set is under 1 MB and the complete set minus CJK is 13MB as packaged in Ubuntu. Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team The 469 MB ZIP file contains 131 TTF fonts and 36 OTF fonts - no source, only actual fonts. I think it will be good if you are *very* specific about the exact Noto fonts you expect distributions to carry. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Qt 5.5 for Plasma 5.5
On Fri, 16 Oct 2015, Jonathan Riddell wrote: Plasma is wanting to, and infact already is, depending on Qt 5.5, our release is due in December, is this a problem for distros? Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team Not a problem for the Plasma 5 packages for Slackware. Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08.2 tarballs available for packagers
On Fri, 9 Oct 2015, Albert Astals Cid wrote: Available at the usual location. Public release is this tuesday. Cheers, Albert Directory permissions prohibit their download: drwx--4096 2015/10/09 09:15:46 15.08.2 Cheers, Eric -- Eric Hameleers <al...@slackware.com> Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08.0 available for packagers
On Tue, 25 Aug 2015, Daniel Vrátil wrote: Date: Tue, 25 Aug 2015 13:21:23 +0200 From: Daniel Vrátil dvra...@kde.org To: release-team@kde.org Cc: Eric Hameleers al...@slackware.com Subject: Re: KDE Applications 15.08.0 available for packagers On Tuesday, August 25, 2015 3:02:54 AM CEST Eric Hameleers wrote: On Tue, 18 Aug 2015, Antonio Rojas wrote: Subject: Re: KDE Applications 15.08.0 available for packagers I seem to be unable to compile kdepim after all the other new kdepim related packages have been built successfully. I have grantlee 5.0.0 installed, and it is found by cmake: ... * Qt5OpenGL * Qt5 * Qt5Gui * Grantlee5 (required version = 5.0) * Gpgme , The GnuPG Made Easy (GPGME) library) , http://www.gnupg.org/related_software/gpgme * Gettext ... But I get a linker error like this: [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/printing/grantleeprint.cpp.o [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/kaddressbookgrantlee_automoc.cpp.o Linking CXX shared library libkaddressbookgrantlee.so CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::GrantleeContactFormatter()' : grantleecontactformatter.cpp:(.text+0x2bc): undefined reference to `Grantlee::FileSystemTemplateLoader::FileSystemTemplateLoader()' CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::setGrantleeTheme(GrantleeTh eme::Theme const)': grantleecontactformatter.cpp:(.text+0x543): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x564): undefined reference to `Grantlee::TemplateImpl::errorString()' grantleecontactformatter.cpp:(.text+0x645): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x729): undefined reference to `Grantlee::TemplateImpl::errorString()' ...etc. I have no idea how to troubleshoot or fix this. I do want to ship the new kdepim with my next batch of Slackware updates. I think I've seen similar problem when having both Qt 4 and Qt 5 Grantlee installed. Could you try without Qt4 Grantlee installed? Dan Ultimately, your suggestion was key to the solution. Indeed, with the Qt4 grantlee removed, these errors disappeared (but other errors appeared instead). In the end, I decided to get rid of Qt4 grantlee entirely and install the headers for Qt5 grantlee in /usr/include/grantlee/ instead of /usr/include/grantlee-qt5/ ... and then everything compiled. Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08.0 available for packagers
On Tue, 25 Aug 2015, Daniel Vrátil wrote: On Tuesday, August 25, 2015 3:02:54 AM CEST Eric Hameleers wrote: On Tue, 18 Aug 2015, Antonio Rojas wrote: Subject: Re: KDE Applications 15.08.0 available for packagers I seem to be unable to compile kdepim after all the other new kdepim related packages have been built successfully. I have grantlee 5.0.0 installed, and it is found by cmake: ... * Qt5OpenGL * Qt5 * Qt5Gui * Grantlee5 (required version = 5.0) * Gpgme , The GnuPG Made Easy (GPGME) library) , http://www.gnupg.org/related_software/gpgme * Gettext ... But I get a linker error like this: [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/printing/grantleeprint.cpp.o [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/kaddressbookgrantlee_automoc.cpp.o Linking CXX shared library libkaddressbookgrantlee.so CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::GrantleeContactFormatter()' : grantleecontactformatter.cpp:(.text+0x2bc): undefined reference to `Grantlee::FileSystemTemplateLoader::FileSystemTemplateLoader()' CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o : In function `KAddressBookGrantlee::GrantleeContactFormatter::setGrantleeTheme(GrantleeTh eme::Theme const)': grantleecontactformatter.cpp:(.text+0x543): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x564): undefined reference to `Grantlee::TemplateImpl::errorString()' grantleecontactformatter.cpp:(.text+0x645): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x729): undefined reference to `Grantlee::TemplateImpl::errorString()' ...etc. I have no idea how to troubleshoot or fix this. I do want to ship the new kdepim with my next batch of Slackware updates. I think I've seen similar problem when having both Qt 4 and Qt 5 Grantlee installed. Could you try without Qt4 Grantlee installed? Dan Hi Dan, Indeed I had both grantlee Qt4 and Qt5 interfaces installed, and after removing the old Qt4 based version and adding /usr/include/grantlee-qt5 to the include path (that is where I installed the Qt5 version in order to not make it clash) I no longer get the aforementione errors, but instead I get this new one twice: the first time around 2% of the compilation: [ 2%] Automatic moc for target grantlee_messageheaderfilters Generating moc_messageheadergrantleefilters.cpp /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messageheader grantleefilters.h:31: Error: Undefined interface AUTOGEN: error: process for /tmp/kde-build/kdepim/kdepim-15.08.0/build/messagevi ewer/grantleefilters/moc_messageheadergrantleefilters.cpp failed: /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messageheader grantleefilters.h:31: Error: Undefined interface moc failed... make[2]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_automoc] Error 1 make[1]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_automoc.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Generating moc_kwatchgnupgconfig.cpp And then the compilation runs for a long time until it hits the same spot again: [ 51%] Automatic moc for target grantlee_messageheaderfilters Generating moc_messageheadergrantleefilters.cpp /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messageheadergrantleefilters.h:31: Error: Undefined interface AUTOGEN: error: process for /tmp/kde-build/kdepim/kdepim-15.08.0/build/messageviewer/grantleefilters/moc_messageheadergrantleefilters.cpp failed: /tmp/kde-build/kdepim/kdepim-15.08.0/messageviewer/grantleefilters/messageheadergrantleefilters.h:31: Error: Undefined interface moc failed... make[2]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_automoc] Error 1 make[1]: *** [messageviewer/grantleefilters/CMakeFiles/grantlee_messageheaderfilters_automoc.dir/all] Error 2 make: *** [all] Error 2 I am at a loss. Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 15.08.0 available for packagers
On Tue, 18 Aug 2015, Antonio Rojas wrote: Subject: Re: KDE Applications 15.08.0 available for packagers I seem to be unable to compile kdepim after all the other new kdepim related packages have been built successfully. I have grantlee 5.0.0 installed, and it is found by cmake: ... * Qt5OpenGL * Qt5 * Qt5Gui * Grantlee5 (required version = 5.0) * Gpgme , The GnuPG Made Easy (GPGME) library) , http://www.gnupg.org/related_software/gpgme * Gettext ... But I get a linker error like this: [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/printing/grantleeprint.cpp.o [ 22%] Building CXX object kaddressbookgrantlee/CMakeFiles/kaddressbookgrantlee. dir/kaddressbookgrantlee_automoc.cpp.o Linking CXX shared library libkaddressbookgrantlee.so CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o: In function `KAddressBookGrantlee::GrantleeContactFormatter::GrantleeContactFormatter()': grantleecontactformatter.cpp:(.text+0x2bc): undefined reference to `Grantlee::FileSystemTemplateLoader::FileSystemTemplateLoader()' CMakeFiles/kaddressbookgrantlee.dir/formatter/grantleecontactformatter.cpp.o: In function `KAddressBookGrantlee::GrantleeContactFormatter::setGrantleeTheme(GrantleeTheme::Theme const)': grantleecontactformatter.cpp:(.text+0x543): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x564): undefined reference to `Grantlee::TemplateImpl::errorString()' grantleecontactformatter.cpp:(.text+0x645): undefined reference to `Grantlee::TemplateImpl::error()' grantleecontactformatter.cpp:(.text+0x729): undefined reference to `Grantlee::TemplateImpl::errorString()' ...etc. I have no idea how to troubleshoot or fix this. I do want to ship the new kdepim with my next batch of Slackware updates. Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to make Wayland hard build dependency in KWin starting with Plasma 5.5
On Thu, 16 Jul 2015, Martin Gräßlin wrote: Hi KDE distro packagers, we are currently (Plasma 5.4) in the awkward situation that plasma-workspace has a hard Wayland dependency and KWin has only an optional build dependency. After the release of Plasma 5.4 I want to change this and turn some optional build dependencies into hard dependencies in KWin. Reasoning: over the Plasma 5.4 cycle I have pretty much only worked on Wayland support and that has resulted in more than 100 #if HAVE_WAYLAND ... #endif As our CI system and most distributions only compile with Wayland support the risk of accidental breakage increases each day. Even more it means that running builds without this build dependency is pretty much untested. While it's unlikely to affect kwin_x11, it is possible, nevertheless. Given that I want to turn the following list of dependencies from optional to required in the next development cycle: * KF5Wayland * Wayland::Cursor * Wayland::Egl * xkbcommon * libdrm * gbm Speaking for Slackware, we will not move to Plasma 5 nor Wayland in the foreseeable future anyway. Having said that, I am the one who maintains the bleeding edge KDE packages for Slackware in my personal repository and there I do not have these restrictions - except that I can not make software-related decisions that would go against the Slackware policy (my packages always end up being part of the Slackware core at some point). And I already compile Plasma 5 in the presence of Wayland, so the move to a hard *build-time* dependency is OK with me. as long as it does not become a hard *run-time* dependency. An xkbcommon package would have to be added to my repository as a new dependency but that is not an issue for me. So, no objections from me for the hard build requirements. The following Wayland specific dependencies would be kept optional: * X11_XCB * libhybris * Libinput * udev Thanks for that, I am not prepared to add libinput since according to your erlier posts it would require logind (which we don't and won't include) or a logind-shim (implementations of which do not exist at present). And libhybris? A library to allow the use of Android device drivers? Surely that will always remain optional. I would like to ask you to try to compile kwin (as of master/5.4 branch) and verify that you can provide the listed required packages. If your distribution is not able to provide one please inform me ASAP about it, so that I can evaluate how much impact it has to keep the dependency optional. Please note that libinput and udev are only kept optional as to my knowledge BSDs cannot provide them. Unfortunately it means that the drm backend in KWin is not functional (doesn't support input) without this dependency. Thank you for your collaboration. Best Regards Martin Gräßlin Head of KDE Wayland porting team Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Request to make Wayland hard build dependency in KWin starting with Plasma 5.5
On Thu, 16 Jul 2015, Martin Gräßlin wrote: On Thursday 16 July 2015 02:54:17 Eric Hameleers wrote: An xkbcommon package would have to be added to my repository as a new dependency but that is not an issue for me. So, no objections from me for the hard build requirements. A small note on xkbcommon: Qt/xcb also requires it. Please make sure that Qt is built with a system xkbcommon, otherwise it picks the one bundled in 3rd- party and that has resulted in crashes in KWin in the past if KWin is build with a system xkbcommon. My Qt5 so far has been built using the 3rdparty source which is part of the qt tarball. Once I add xkbcommon as a system package I will have to recompile Qt5, is what you are telling? Is this a Qt5 bug that has not been addressed yet? Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Future frameworks releases
On Tue, 9 Jun 2015, Michael Palimaka wrote: Date: Tue, 09 Jun 2015 00:25:24 +1000 From: Michael Palimaka kensing...@gentoo.org Reply-To: KDE release coordination release-team@kde.org To: release-team@kde.org Subject: Re: Future frameworks releases On 08/06/15 09:28, David Faure wrote: Hello packagers, The thread Versioning of Frameworks on kde-frameworks-devel has led to the idea that some future frameworks (coming from the kdepim world) would not be part of every Frameworks release, and would have their own versioning scheme. This is at the request of their maintainer, Christian, CC'ed. For example: KF 5.12 would contain KImap 2.1 KF 5.13 would not contain a KImap release KF 5.14 would contain KImap 2.1.1 KF 5.15 would contain KImap 2.2 Why? Will other frameworks skip a release too if they have no commits? The only sane way forward is that every Frameworks release contains all Frameworks tarballs, regardless of updates since the previous public release. Every Framework should adhere to the overall version number. This is the base on which you are building everything, guys! Don't start messing with tarballs present yes/no/perhaps and version number mumbo-jumbo. In the past everybody was very critical about when a piece of software was finally allowed to enter the holy ground of Frameworks, and with good reason: quality and stability. So please don't make us drift into a swamp by approving this KImap proposal. Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Re: 5.2.1 tars for packagers
On Tue, 24 Feb 2015, Martin Gräßlin wrote: Do you want to have access to my inbox to see that it might happen that I forget about it? Read it on the smartphone, didn't answer on it (because I hate typing on the smartphone), notification discarded by Google+ and I forgot about it on Monday. Exactly that's why I don't accept bug reports on any other medium than bugs.kde.org to not forget about it. Sorry that I did not point out that it's better to report on bko than to me on Google+ because I was only on smartphone and didn't type. Everyone's busy, and if I would get an answer sorry, no time to think this over, too busy that would have been unfortunate, but a perfectly acceptible answer. I did not post to the mailing list until after you had created multiple new posts on G+ ... such things happen. If you want to assume ill will by it, fine with me. Being pragmatic about it that I'm just human and buried in the load of incoming communications might be fairer, though. Ill will, no. Frustration because of a usability issue introduced in an upcoming bugfix release and not finding commitment, yes. Well you can also see that I didn't post on the Weekend on Google+, might be it was weekend after all ;-) The question was not urgent for me in the weekend, and I did not see any other postings in the weekend so indeed I assumed you were enjoying yourself somewhere away from computers. I can be obnoxious but I don't mess with people's private lives. Let's bury the hatchet. If you have any ideas about where the cause of my issue could lie, then I still would like to hear, otherwise I will just wait and see what happens with the 5.2.1 release. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 5.2.1 tars for packagers
On Tue, 24 Feb 2015, Albert Astals Cid wrote: El Dimarts, 24 de febrer de 2015, a les 14:48:38, Harald Sitter va escriure: On Tue, Feb 24, 2015 at 2:46 PM, Anke Boersma d...@kaosx.us wrote: FWIW, no such regressions here with Plasma 5.2.1 Krunner/Alt-F2 works as should, focus of opened apps with krunner is correct. The hotkey issue could totally be a missing kglobalaccel daemon actually. What with it having moved to KF5.7. Was removed in between Plasma 5.2.0 and Plasma 5.2.1? Cheers, Albert The krunner issue was indeed caused by kglobalaccel. The deamon moved from plasma-workspace-5.2.0 into kglabalaccel-5.7.0, so when I built kglobalaccel with plasma-workspace-5.2.0 present it picked up a dependency on that package's libkdeinit5_kglobalaccel5.so library. When I upgraded to Plasma 5.2.1, that library was gone and kglobalaccel5 would no longer start. I rebuilt kglobalaccel with all of the Plasma packages removed and that solved it. Thanks for helping me clear my mind and see the root cause. Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 14.12.2 ready for packagers
On Mon, 2 Feb 2015, Harald Sitter wrote: On Mon, Feb 2, 2015 at 4:13 PM, Eric Hameleers al...@slackware.com wrote: On Fri, 30 Jan 2015, Albert Astals Cid wrote: Usual location, I'm at FOSDEM this weekend so it may happen that if you guys find some issue (hopefully not) it'll have to wait until monday for me to act on it. Cheers, Albert Hi Albert Where can I find the list of applications that have been ported to Qt5/Frameworks versus the ones that still reply on KDE 4 libs? this [1] should offer a complete list of kf5 apps in the 14.12 apps bundle, everything else is kdelibs4 based [1] https://community.kde.org/Frameworks/Application-release-status-December-2014 HS That page was last modified in November 2014. This means, there will not be a change in KF5 ports for alll the Applications 14.12.x releases? And likewise, there will be an unchanging list of KF5 ports for the upcoming Applications 15.04.x ? Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Applications 14.12.2 ready for packagers
On Fri, 30 Jan 2015, Albert Astals Cid wrote: Usual location, I'm at FOSDEM this weekend so it may happen that if you guys find some issue (hopefully not) it'll have to wait until monday for me to act on it. Cheers, Albert Hi Albert Where can I find the list of applications that have been ported to Qt5/Frameworks versus the ones that still reply on KDE 4 libs? Cheers, Eric -- Eric Hameleers al...@slackware.com Home: http://alien.slackbook.org/blog/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: kdeedu-data
On Thu, 23 Oct 2014, Jeremy Whiting wrote: Hey packagers, A quick heads up about kdeedu-data strangeness. The upcoming KDE Applications 14.12 release will have some applications based on kdelibs4 and others based on kf5. Because some applications that use libkdeedu/libkeduvocdocument are going to be still based on kdelibs4 while others have already been ported to qt5 and kf5 there will be both libkdeedu and libkeduvocdocument tarballs released. Because both used to contain a handful of kvtml files, we moved them out into kdeedu-data which both libkdeedu and libkeduvocdocument should depend on (or at least khangman(kdelibs4) and kanagram(libkeduvocdocument) should depend on in order to run. Now kdeedu-data uses ecm instructions to build like other kf5 based applications. Is that going to be a problem to make both khangman and kanagram run time depend on these packages, while kdeedu-data at build time requires ecm to build? I'm open to other solutions, but this is the best we could come up with at this time. thanks, Jeremy Please explain to me why applications in the 4.14.12 release should depend on kf5? The kf5 dependencies must be left out of the tarball for the KDE SC 4.14 releases. And if that is impossible for you, then consider this alternative. Anything depending on kf5 or ecm or qt5 will have to be optional when compiling the Applications 4.14.12 tarball. Additionally, no build-time dependency should be enforced on anything that relates to kf5. Eric -- Eric Hameleers al...@slackware.com ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.14.1 packages up for packagers
On Fri, 12 Sep 2014, Albert Astals Cid wrote: Hi, the 4.14.1 packages are up for packagers at the usual location. kde-workspace 4.11.12 is also included. Public release is next Tuesday. I have not yet built the packages since downloading them from limited akademy bandwidth is not an option. Cheers, Albert When building kdebindings, I run into these errors (akonadi 1.13.0 installed in case that's relevant): [ 78%] Building CXX object akonadi/CMakeFiles/smokeakonadi.dir/x_7.o /tmp/kde-build/kdebindings/smokekde-4.14.1/build/akonadi/x_7.cpp: In member function 'void __smokeakonadi::x_Akonadi__ItemFetchScope::x_33(Smoke::Stack)': /tmp/kde-build/kdebindings/smokekde-4.14.1/build/akonadi/x_7.cpp:3454:32: error: variable 'Akonadi::TagFetchScope xret' has initializer but incomplete type Akonadi::TagFetchScope xret = ((const x_Akonadi__ItemFetchScope*)this)-Akonadi::ItemFetchScope::tagFetchScope(); ^ /tmp/kde-build/kdebindings/smokekde-4.14.1/build/akonadi/x_7.cpp:3454:120: error: invalid use of incomplete type 'class Akonadi::TagFetchScope' Akonadi::TagFetchScope xret = ((const x_Akonadi__ItemFetchScope*)this)-Akonadi::ItemFetchScope::tagFetchScope(); ^ In file included from /usr/include/akonadi/changerecorder.h:23:0, from /tmp/kde-build/kdebindings/smokekde-4.14.1/akonadi/akonadi_includes.h:16, from /tmp/kde-build/kdebindings/smokekde-4.14.1/build/akonadi/x_7.cpp:2: /usr/include/akonadi/monitor.h:37:7: error: forward declaration of 'class Akonadi::TagFetchScope' class TagFetchScope; ^ /tmp/kde-build/kdebindings/smokekde-4.14.1/build/akonadi/x_7.cpp:3455:62: error: invalid use of incomplete type 'class Akonadi::TagFetchScope' x[0].s_class = (void*)new Akonadi::TagFetchScope(xret); ^ In file included from /usr/include/akonadi/changerecorder.h:23:0, from /tmp/kde-build/kdebindings/smokekde-4.14.1/akonadi/akonadi_includes.h:16, from /tmp/kde-build/kdebindings/smokekde-4.14.1/build/akonadi/x_7.cpp:2: /usr/include/akonadi/monitor.h:37:7: error: forward declaration of 'class Akonadi::TagFetchScope' class TagFetchScope; ^ make[2]: *** [akonadi/CMakeFiles/smokeakonadi.dir/x_7.o] Error 1 make[1]: *** [akonadi/CMakeFiles/smokeakonadi.dir/all] Error 2 make: *** [all] Error 2 A What's happening here? Cheers, 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
Re: 4.14.0 packages up for packagers
On Thu, 14 Aug 2014, Albert Astals Cid wrote: El Dijous, 14 d'agost de 2014, a les 02:08:04, Eric Hameleers va escriure: On Thu, 14 Aug 2014, Albert Astals Cid wrote: Hi, there 4.14.0 packages are up for packagers at the usual location. Public release is next Wednesday. I have not yet built the packages, doing so now. Cheers, Albert Hi Albert Seems the kactivities and kde-workspace tarballs are absent. No, they are not absent. Neither of them are part of these release since they have not been part of any of the betas/RC. Cheers, Albert OK thanks for the heads-up. I have not had time for the betas and RC because of the frameworks/plasma5 releases, so I was not aware yet. Cheers, 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
Re: KF5 beta3
On Wed, 4 Jun 2014, Sebastian Kügler wrote: Hi Eric, On Tuesday, June 03, 2014 12:49:01 Eric Hameleers wrote: I did however have to write a couple of patches to get everything compiling. Well, except kdepimlibs (frameworks branch) which I can not get to compile no matter what I try. The four patches I created are attached for those who may want them. Could you submit them to reviewboard? Tagged with the right repo, they'll reach their maintainer and can get picked up there. Thanks, Reviewboard does not accept my diff files. Are they only accepted when created with git diff? I create packages, but I do not develop software. Therefore I do not work in the KDE repositories and I do not have local clones. A git diff will not be an option. Can I pass on these diffs in another way? Cheers, 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
Re: KF5 beta3
On Wed, 4 Jun 2014, David Faure wrote: On Wednesday 04 June 2014 06:17:17 Eric Hameleers wrote: On Wed, 4 Jun 2014, Sebastian Kügler wrote: Hi Eric, On Tuesday, June 03, 2014 12:49:01 Eric Hameleers wrote: I did however have to write a couple of patches to get everything compiling. Well, except kdepimlibs (frameworks branch) which I can not get to compile no matter what I try. The four patches I created are attached for those who may want them. Could you submit them to reviewboard? Tagged with the right repo, they'll reach their maintainer and can get picked up there. Thanks, Reviewboard does not accept my diff files. Are they only accepted when created with git diff? No, but they should probably have the same kind of paths. I cloned the plasma-desktop and kde-cli-tools repositories and created git diffs from my patches. Those were accepted by reviewboard and the result is: https://git.reviewboard.kde.org/r/118540/ https://git.reviewboard.kde.org/r/118539/ I am not sure if I added the second patch correctly to that first request, but I'll just see what happens. Thanks for pointing me to reviewboard. Cheers, 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
Re: KF5 beta3
On Sun, 1 Jun 2014, David Faure wrote:
As planned, here's KF5 beta3, aka 4.100.0.
* New this month:
- kfileaudiopreview doesn't exist anymore
- the attached tags.git file indicates the tag to use for distros using git
instead of tarballs [note the exception on the last line...]
* Public release date: June 4 (unless someone shouts otherwise)
I built the KF5 Beta 3 without issues. Then I built a Plasma Next
package set on top of that, using git HEAD checkouts (of the
frameworks branch where applicable) and have a much better-looking
desktop experience (although crash-prone) than when I tested the
plasma 4.96.0 tarballs. Good progress!
One thing which I did not find, is the repository from which
libkscreen2-1-71.tar.xz source tarball was created, so I re-used the
tarball I found in the plasma-4.96.0 directory on ftp.kde.org.
I did however have to write a couple of patches to get everything
compiling. Well, except kdepimlibs (frameworks branch) which I can not
get to compile no matter what I try.
The four patches I created are attached for those who may want them.
Cheers, Eric
--
Eric Hameleers al...@slackware.com
Jabber: al...@jabber.xs4all.nl--- plasma-desktop-20140602git/kcms/kfontinst/lib/CMakeLists.txt.orig
2014-06-03 16:08:19.294297273 +0200
+++ plasma-desktop-20140602git/kcms/kfontinst/lib/CMakeLists.txt
2014-06-03 16:09:12.420293700 +0200
@@ -15,6 +15,6 @@
set_target_properties(kfontinst PROPERTIES VERSION ${GENERIC_LIB_VERSION}
SOVERSION 5 )
add_library(kfontinstui SHARED ${kfontinstui_LIB_SRCS})
-target_link_libraries(kfontinstui Qt5::X11Extras KF5::KIOCore KF5::KIOWidgets
${FREETYPE_LIBRARIES} ${FONTCONFIG_LIBRARIES} ${X11_X11_LIB} ${X11_Xft_LIB}
kfontinst )
+target_link_libraries(kfontinstui Qt5::X11Extras KF5::KIOCore KF5::KIOWidgets
KF5::KDELibs4Support XCB::XCB XCB::IMAGE ${FREETYPE_LIBRARIES}
${FONTCONFIG_LIBRARIES} ${X11_X11_LIB} ${X11_Xft_LIB} kfontinst )
set_target_properties(kfontinstui PROPERTIES VERSION ${GENERIC_LIB_VERSION}
SOVERSION 5 )
install(TARGETS kfontinst kfontinstui ${INSTALL_TARGETS_DEFAULT_ARGS} )
--- plasma-desktop-20140602git/kcms/kfontinst/dbus/CMakeLists.txt.orig
2014-06-02 13:47:27.0 +0200
+++ plasma-desktop-20140602git/kcms/kfontinst/dbus/CMakeLists.txt
2014-06-03 17:17:01.382378586 +0200
@@ -14,11 +14,11 @@
set_target_properties(fontinst_bin PROPERTIES OUTPUT_NAME fontinst)
target_link_libraries(fontinst_bin
- Qt5::DBus Qt5::Xml ${FONTCONFIG_LIBRARIES} kfontinst)
+ Qt5::DBus Qt5::Xml Qt5::X11Extras KF5::KDELibs4Support
XCB::XCB XCB::IMAGE ${FONTCONFIG_LIBRARIES} kfontinst)
set_target_properties(fontinst_helper PROPERTIES OUTPUT_NAME fontinst_helper)
target_link_libraries(fontinst_helper
- Qt5::DBus Qt5::Xml ${FONTCONFIG_LIBRARIES} kfontinst)
+ Qt5::DBus Qt5::Xml Qt5::X11Extras KF5::KDELibs4Support
XCB::XCB XCB::IMAGE ${FONTCONFIG_LIBRARIES} kfontinst)
install(TARGETS fontinst_bin DESTINATION ${LIBEXEC_INSTALL_DIR} )
install(TARGETS fontinst_helper DESTINATION ${LIBEXEC_INSTALL_DIR} )
--- plasma-desktop-20140602git/kcms/kfontinst/kcmfontinst/CMakeLists.txt.orig
2014-06-02 13:47:27.0 +0200
+++ plasma-desktop-20140602git/kcms/kfontinst/kcmfontinst/CMakeLists.txt
2014-06-03 19:19:00.376164975 +0200
@@ -10,6 +10,7 @@
add_library(kcm_fontinst MODULE ${kcm_fontinst_PART_SRCS})
target_link_libraries(kcm_fontinst
+Qt5::X11Extras
KF5::Archive
KF5::KCMUtils
KF5::Su
--- plasma-desktop-20140602git/kcms/kfontinst/apps/CMakeLists.txt.orig
2014-06-02 13:47:27.0 +0200
+++ plasma-desktop-20140602git/kcms/kfontinst/apps/CMakeLists.txt
2014-06-03 19:27:47.209175028 +0200
@@ -31,6 +31,7 @@
)
target_link_libraries(kfontprint_bin
Qt5::PrintSupport
+Qt5::X11Extras
KF5::IconThemes
KF5::KDELibs4Support
${X11_X11_LIB}
@@ -38,7 +39,7 @@
kfontinstui
kfontinst
)
-target_link_libraries(kfontview_bin KF5::Parts KF5::XmlGui kfontinstui
kfontinst )
+target_link_libraries(kfontview_bin KF5::Parts KF5::XmlGui
KF5::KDELibs4Support kfontinstui kfontinst )
install(TARGETS kfontinst_bin ${INSTALL_TARGETS_DEFAULT_ARGS} )
install(TARGETS kfontprint_bin DESTINATION ${LIBEXEC_INSTALL_DIR} )
--- plasma-desktop-20140602git/kcms/kfontinst/kio/CMakeLists.txt.orig
2014-06-02 13:47:27.0 +0200
+++ plasma-desktop-20140602git/kcms/kfontinst/kio/CMakeLists.txt
2014-06-03 19:31:34.379189708 +0200
@@ -5,7 +5,7 @@
set(kio_fonts_PART_SRCS FontInstInterface.cpp KioFonts.cpp
${libkfontinstdbusiface_SRCS})
# qt5_add_dbus_interface(kio_fonts_PART_SRCS ../dbus/org.kde.fontinst.xml
FontinstIface)
add_library(kio_fonts MODULE ${kio_fonts_PART_SRCS} ${KFI_FONTINST_AUTH_SRC} )
-target_link_libraries(kio_fonts Qt5::DBus Qt5::X11Extras Qt5::Xml KF5::Archive
KF5::KIOCore KF5::KIOWidgets kfontinst )
+target_link_libraries(kio_fonts Qt5::DBus Qt5
Re: KDE SC 4.12.2 tarballs
On Fri, 31 Jan 2014, Albert Astals Cid wrote: Hi, The tarballs for the 4.12.2 release are now available in the usual location. I've not compiled them (and will take a while since I'll be at FOSDEM this weekend) so please report any issues you find. sha1 sums and revisions/hashes are attached. Cheers, Albert Permissions are not righ: rsync: change_dir /home/ftpslackware//stable/4.12.2/src failed: Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1518) [Receiver=3.0.8] Cheers, 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
Re: KDE SC 4.12.1 tarballs
On Sat, 11 Jan 2014, Albert Astals Cid wrote: El Divendres, 10 de gener de 2014, a les 01:31:09, Albert Astals Cid va escriure: Hi, The tarballs for the 4.12.1 release are now available in the usual location. I've not compiled them (yet) so please report any issues you find. FWIW they compiled just fine here. Cheers, Albert Same here (Slackware). Cheers, 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
Re: KDE SC 4.11.5 tarballs
On Sat, 4 Jan 2014, Albert Astals Cid wrote: El Divendres, 3 de gener de 2014, a les 17:56:01, Albert Astals Cid va escriure: Hi, The tarballs for the 4.11.5 release are now available in the usual location. I've not compiled them (yet) so please report any issues you find. Built without any issue here. Cheers, Albert Same here (Slackware 14.1 stable). Cheers, 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
Re: Umbrello KDE/4.11 does not compile - was - Re: KDE SC 4.11.4 tarballs
On Sat, 30 Nov 2013, Wulf C. Krueger wrote: Hello Joris, On 30.11.2013 10:53, Joris Steyn wrote: Eric, could you tell me what compiler version you are using? And did you do a debugfull cmake build or just a regular build? I'm not Eric but we've seen the same issue in Exherbo using... Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/paludis/build/sys-devel-gcc-4.8.2/work/gcc-4.8.2/configure - --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu - --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share - --sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules - --enable-fast-install --libdir=/usr/lib64 --cache-file=config.cache - --libdir=/usr/lib64 --with-pkgversion='exherbo gcc-4.8.2' - --program-suffix=-4.8 --disable-bootstrap --enable-clocale=gnu - --enable-languages=c,c++,fortran,java --enable-lto --enable-multilib - --enable-nls --enable-serial-configure --enable-libquadmath - --enable-libquadmath-support --with-cloog --enable-libgomp - --disable-libobjc --disable-libssp --with-as=x86_64-pc-linux-gnu-as - --with-ld=x86_64-pc-linux-gnu-ld --with-system-zlib Thread model: posix gcc version 4.8.2 (exherbo gcc-4.8.2) It was a regular (non-debug) build. - -- Best regards, Wulf Hi Joris I did not get your original email for some reason. However, this is Slackware 14.1 x86_64 and I am performing a Release build of KDE SC. This is my gcc information: Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.8.2/specs COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/4.8.2/lto-wrapper Target: x86_64-slackware-linux Configured with: ../gcc-4.8.2/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --enable-java-home --with-java-home=/usr/lib64/jvm/jre --with-jvm-root-dir=/usr/lib64/jvm --with-jvm-jar-dir=/usr/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-jar=/tmp/gcc/antlr-runtime-3.4.jar --enable-java-awt=gtk --disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux Thread model: posix gcc version 4.8.2 (GCC) Hope this helps. Also good (for me) to see that I am not the only one who ran into this error. Cheers, 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
Re: Umbrello KDE/4.11 does not compile - was - Re: KDE SC 4.11.4 tarballs
On Sat, 30 Nov 2013, Joris Steyn wrote: that's bad news. I pushed this commit to KDE/4.11 just now to fix the error (other branches are fine): http://quickgit.kde.org/?p=umbrello.gita=commith=5f9f6a68716a8aced2c5f962247d9b05b326fcf5 Doing a non-debug build of 4.11 worked without warnings on my system, that's how the error got in 4.11 unnoticed. I hope to prevent that in the future but I'm not sure what compiler version/options make the difference in allowing this error without warning, and complete failure. That commit fixed it for me, thanks! Cheers, 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
Re: KDE SC 4.11.4 tarballs
On Fri, 29 Nov 2013, Torgny Nyblom wrote: Hi, The tarballs for the 4.11.4 release are now available in the usual location. I've not compiled them so please report any issues you find. sha1 sums and revisions/hashes are attached. /Regards Torgny When compiling umbrello (part of our Slackware kdesdk module), I run into this error: [ 11%] Building CXX object umbrello/CMakeFiles/umbrello.dir/dialogs/classoptionspage.cpp.o [ 11%] Building CXX object umbrello/CMakeFiles/umbrello.dir/dialogs/classpropdlg.cpp.o /tmp/kde-build/kdesdk/umbrello-4.11.4/umbrello/dialogs/classifierlistpage.cpp: In member function 'void ClassifierListPage::slotActivateItem(QListWidgetItem*)': /tmp/kde-build/kdesdk/umbrello-4.11.4/umbrello/dialogs/classifierlistpage.cpp:349:9: error: 'listItem' was not declared in this scope listItem = getItemList().at( itemIndex ); ^ /tmp/kde-build/kdesdk/umbrello-4.11.4/umbrello/dialogs/classifierlistpage.cpp:354:74: error: cannot dynamic_cast 'listItem' (of type 'type error') to type 'class UMLOperation*' (source is not a pointer) m_pCodeTE-setPlainText( dynamic_castUMLOperation*(listItem)-get SourceCode() ); ^ make[2]: *** [umbrello/CMakeFiles/umbrello.dir/dialogs/classifierlistpage.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs [ 0%] Built target umbrello_automoc [ 0%] Building CXX object umbrello/CMakeFiles/umbrello.dir/dialogs/classifierlistpage.cpp.o /tmp/kde-build/kdesdk/umbrello-4.11.4/umbrello/dialogs/classifierlistpage.cpp: In member function 'void ClassifierListPage::slotActivateItem(QListWidgetItem*)': /tmp/kde-build/kdesdk/umbrello-4.11.4/umbrello/dialogs/classifierlistpage.cpp:349:9: error: 'listItem' was not declared in this scope listItem = getItemList().at( itemIndex ); ^ /tmp/kde-build/kdesdk/umbrello-4.11.4/umbrello/dialogs/classifierlistpage.cpp:354:74: error: cannot dynamic_cast 'listItem' (of type 'type error') to type 'class UMLOperation*' (source is not a pointer) m_pCodeTE-setPlainText( dynamic_castUMLOperation*(listItem)-getSourceCode() ); ^ make[2]: *** [umbrello/CMakeFiles/umbrello.dir/dialogs/classifierlistpage.cpp.o] Error 1 make[1]: *** [umbrello/CMakeFiles/umbrello.dir/all] Error 2 make: *** [all] Error 2 kdesdk failed to build. Any clue? Cheers, 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
Re: 4.11.0 tarballs available (for packagers)
On Mon, 12 Aug 2013, Albert Astals Cid wrote: El Dilluns, 12 d'agost de 2013, a les 14:06:09, Eric Hameleers va escriure: On Mon, 12 Aug 2013, Albert Astals Cid wrote: New packages uploader for nepomuk-core and marble nepomuk-core fixes problems with restoring backups marble fixes issues with python bindings not building git hashes: d7b168bc8a7bb3e998f7ab94c90dafe9cd592ee7 Branch KDE/4.11 nepomuk-core 93d07d2e859a8a8f4e4e4957f7d3ba2f09b2c2dd Branch KDE/4.11 marble tar.xz sha1sums: 16b3176b9c615199321c87c383ad27802041d7dd nepomuk-core-4.11.0.tar.xz a7feb09a825f93c301fdfec5975813f09f14f41b marble-4.11.0.tar.xz Cheers, Albert There is a _whole_ lot of additional updated tarballs all of a sudden... what's up with that? Nothing, they are the same package (check the sha1sum or diff them) i just touched them by mistake. Cheers, Albert Thanks Albert, for the heads-up. Cheers, 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
Re: Binary packages section of info/release.php pages
On Sat, 10 Nov 2012, Michael Palimaka wrote: On 2012-11-09 23:33, Sebastian Kügler wrote: On Friday, November 09, 2012 00:27:18 Albert Astals Cid wrote: I was looking today at http://www.kde.org/info/4.9.3.php#binary and see there's only the Kubuntu information there when i know a few more distros have released 4.9.3 packages. Do we still need that? It looks a bit sad how it looks right now (and has looked in the various releases). Do we want to remove it? Do we want to replace it with something else? Ideas? In its current state, I'd say: ditch it. If packagers would like to see their binary packages listed there (and it's not just one or two distros), then we need to find a way to add the binary packages as they arrive. Could be a manual thing, asking someone to add a link there, even, or we put it on a wiki page, making it less maintainance work for the release team and easier to edit for those that would like to see their packages advertised. Hi, I wonder why packagers aren't updating that page anymore? I also note that http://www.kde.org/download/distributions.php is looking a bit sad too. If maintaining a list of which distro has what is not working, perhaps we could just list distros that carry it, linking to their respective KDE packages/guide/information/whatever? Best regards, Michael I asked Dirk on two occasions how I could add the Slackware packages for KDE on that page, but I never revceived an answer. If anyone can instruct me how to get access to that page for editing I would be glad to update it! Cheers, 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
Re: New kdesdk package (for beta 2) available
On Mon, 11 Jun 2012, Albert Astals Cid wrote: $ sha1sum kdesdk-4.8.90.tar.xz 7526fb0fe5fd217cb536b692a0409951b04f6502 kdesdk-4.8.90.tar.xz Based svn.kde.org/home/kde/trunk/KDE/kdesdk revision 1299778 Cheers, Albert ___ Everything compiled nicely for KDE 4.8.90 except the kde-l10n-gl source tarball. I get a lot of warnings about missing CMakeLists.txt files, and it ends with this error: CMake Error: Error in cmake code at /tmp/kde-l10n-gl-4.8.90/data/kdeedu/khangman/CMakeLists.txt:4: Parse error. Expected a command name, got unquoted argument with text .. -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. Can this be fixed before release? It that release still planned for today? Cheers, 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
Re: final KDE 4.8.4 tarballs
On Thu, 7 Jun 2012, Andrea Scarpino wrote: On Wednesday 06 June 2012 23:13:39 Dirk Mueller wrote: af1ff1da6f1fbd5eab18fdd57282f5c1 kdepim-4.8.4.tar.xz - kmail crash fix This doesn't build anymore: /build/src/kdepim-4.8.4/messageviewer/viewer_p.cpp: In member function ?void MessageViewer::ViewerPrivate::openAttachment(KMime::Content*, const QString)?: /build/src/kdepim-4.8.4/messageviewer/viewer_p.cpp:378:35: error: no matching function for call to ?MessageViewer::ViewerPrivate::attachmentOpen(KMime::Content*, KService::Ptr)? /build/src/kdepim-4.8.4/messageviewer/viewer_p.cpp:378:35: note: candidate is: In file included from /build/src/kdepim-4.8.4/messageviewer/viewer_p.cpp:25:0: /build/src/kdepim-4.8.4/messageviewer/viewer_p.h:228:8: note: void MessageViewer::ViewerPrivate::attachmentOpen(KMime::Content*) /build/src/kdepim-4.8.4/messageviewer/viewer_p.h:228:8: note: candidate expects 1 argument, 2 provided The others tarballs are fine. I have the same error. Cheers, 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
Re: Re: Request for delaying 4.8.4 request
On Tue, 5 Jun 2012, Alex Fiestas wrote: Reviewed and pushed to kdelibs KDE/4.8 Hash: 19213a6c34e1b47a100815ccbfee8b5c70c3c12a Thanks for everything ! Please re-spin the kdelibs-4.8.4 tarball. Cheers, 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
Re: Nepomuk-Core clashes with other Repos
On Sat, 26 May 2012, Albert Astals Cid wrote: El Divendres, 25 de maig de 2012, a les 12:43:53, Eric Hameleers va escriure: On Fri, 25 May 2012, Vishesh Handa wrote: Hello Packagers! We seem to have 2 minute problems - * Nepomuk-core and kde-runtime both install libnepomukcommon.so * You can ignore the kde-runtime version * Nepomuk-core and kdelibs both install rcgen * You can ignore the nepomuk-core one Sorry about all the trouble. I've fixed them in the git repositories and the beta2 release will contain these fixes. I would advise to fix the beta1 tarballs instead. Because of how we generate the tarballs/tags (we tag the master branch) the only way of updating the tarballs and not breaking the tag is including everything that was commited between the tag and the fix (and this may not be wanted), so we have decided to not do it. In the future when the real packaging team arises (i.e. not a temporary man like me), the process has to account for how to add random patches to the tarballs and still having a proper tag in git. Cheers, Albert Then can you at least post URL's of the commits which fix this, so that we can use those as patches in our beta1 packages? 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
Re: Nepomuk-Core clashes with other Repos
On Sat, 26 May 2012, Vishesh Handa wrote: Then can you at least post URL's of the commits which fix this, so that we can use those as patches in our beta1 packages? Of course. kde-runtime - 959412fdd7a3bbff6921474342d1209c212a410d [1] nepomuk-core - 6ec4e729e2426dac37e9e27932d4d9e579d53ba4 [2] and b60025c6d5d6201b2bbe6881f11c431ec2671677 [3] [1] https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/959412fdd7a3bbff6921474342d1209c212a410d [2] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core/repository/revisions/6ec4e729e2426dac37e9e27932d4d9e579d53ba4 [3] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core/repository/revisions/b60025c6d5d6201b2bbe6881f11c431ec2671677 Perfect! Cheers, 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
Re: KDE 4.8.1 tarballs uploaded
On Fri, 2 Mar 2012, Dirk Mueller wrote: Hi, just finished uploading the first set of KDE 4.8.1 tarballs. As usual, please speak up if there are any blocking issues. I have added a set of .xz tarballs under sources/xz. Those are identical with the bzip2 version, just being recompressed. I appreciate any feedback on those. Thanks, Dirk Everything compiled with zero issues. Thanks for the .xz tarballs! Cheers, 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
Re: KDE 4.8.0 tarballs (try#1)
On Fri, 20 Jan 2012, Andreas K. Huettel wrote: Am Freitag 20 Januar 2012, 00:43:18 schrieb Eric Hameleers: Indeed, kdeutils was split, into ark, filelight, kcalc, kcharselect, kdf, kfloppy, kgpg, printer-applet, kremotecontrol, ktimer, kwallet, superkaramba, sweeper, ksecrets. And the same is true for kdeaccessibility. That one split up into jovie, kaccessible, kmag, kmouth, kmousetool. Cheers, Eric Right... now the question is, are the combined tarballs going away with 4.8.0 or will they exist in the future again (as in 4.7.97)? No problem in principle with either thing here, it would just be nice to know. The kdeaccessibility and kdeutils were planned to be split for 4.8 from the start. Their tarballs have not been in any of the earlier 4.8 betas either. Cheers, 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
Re: KDE 4.7.4 tarballs (try#1) uploaded
On Fri, 2 Dec 2011, Dirk Mueller wrote: just finished uploading the first set of KDE 4.7.4 tarballs. As usual, please speak up if there are any blocking issues. kde-l10n generation is still running, will come later tomorrow morning after some sleep. Hi Dirk Can you please upload the kde-l10n tarballs? They are still missing. The whole set of KDE 4.7.4 built without issues, I had to upgrade my libmsn to version 4.2.1 in order to compile kopete without errors. Cheers, 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
Re: KDE 4.7.4 tarballs (try#1) uploaded
On Fri, 2 Dec 2011, Arkadiusz Mi?kiewicz wrote: On Friday 02 of December 2011, Dirk Mueller wrote: Hi, just finished uploading the first set of KDE 4.7.4 tarballs. As usual, please speak up if there are any blocking issues. kde-l10n generation is still running, will come later tomorrow morning after some sleep. Ehhhm, kdeaccessibility and kdeutils are missing. That would be the 3rd time these two are absent... Dirk can you please update your scripts? Cheers, 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
Re: KDE 4.7.3 tarballs uploaded
On Mon, 31 Oct 2011, Dirk Mueller wrote: On Friday 28 October 2011, Eric Hameleers wrote: Two tarballs are missing: kdeaccessibility and kdeutils. Please add those to the set ASAP. added. And the kde-l10n files, need to be generated still I assume? also uploaded now. All built fine for me. Thanks, Dirk Hi Dirk I noticed the new tarballs earlier on sunday, and everything compiled without issues. Good to go, I guess. One remark, the miss on kdeaccessibility/kdeutils happened for 4.7.2 as well if I remember correctly. Is this an issue with your tarball generation script that you need to address? Is there a chance that you can publish those scripts so that we (packagers) can go ahead in cases like this? Cheers, 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
Re: KDE 4.7.3 tarballs uploaded
On Fri, 28 Oct 2011, Dirk Mueller wrote: Hi guys, sorry for the late upload, I'm travelling and have a very bad connection. I just finished uploading 1sst try of KDE 4.7.3 tarballs. Please let me (and kde-packa...@kde.org) know about any major issues with them. Targetted release date is tuesday or wednesday. Thanks, Dirk Hi Dirk Two tarballs are missing: kdeaccessibility and kdeutils. Please add those to the set ASAP. And the kde-l10n files, need to be generated still I assume? Cheers, 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
Re: KDE 4.7.2 (try#1) uploaded
On Sun, 2 Oct 2011, Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. Let me know of any issues (my own build is still running). kde-l10n is still being generated and will be uploaded in ~ 3 hours. Thanks, Dirk Hi Dirk Thanks for finally uploading the l10n tarballs, but still missing are kdeutils and kdeaccessibility. Could you upload those too please? Cheers, 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
Re: KDE 4.7.1 tarballs (try #1)
On Sat, 3 Sep 2011, Eric Hameleers wrote: On Fri, 2 Sep 2011, Raphael Kubo da Costa wrote: Hi! Seems ark-4.7.1.tar.bz2 tarball missing There shouldn't be one, as kdeutils is not supposed to be split in 4.7.x. Still waiting for kdeutils basically... I noticed that even if kdeutils was not supposed to be split, this is what actually happened. The repository was moved from SVN to git, and split into its many components, but then these components have never been tagged for v4.7.1 so I can not go ahead and check out a consistent set myself. Can someone please tag the kdeutils components with v4.7.1 please? And of course, create tarballs! There is no v4.7.1 tag in any of the KDE modules, at all! Dirk or release team, could you please tag KDE for v4.7.1 ? Cheers, 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
Re: KDE 4.7.1 tarballs (try #1)
On Fri, 2 Sep 2011, Dirk Mueller wrote: Hi, just finished uploading the first set of 4.7.1 tarballs. I have not yet been able to fully build them myself yet, given that my scripts failed early over night.. Anyway, I hope it works out. I have rebuilt kdeaccessibility and kdeutils from the modular git trees into the previous monolithic tarballs so that the tarball layout does not change between 4.7.x releases. If you know about any issues (unexptected changes in the tarball layout, or build issues, blocking bugs), please let me know. I'll try to respond on Sunday, currently travelling with limited internet. Greetings, Dirk Dirk, Access to the 4.7.1 directory is denied because of these directory properties: drwx--4096 2011/09/02 09:28:42 4.7.1 Can you please open up the 4.7.1 directory? Cheers, 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
Re: KDE 4.7.1 tarballs (try #1)
On Fri, 2 Sep 2011, Ben Cooksley wrote: On Fri, Sep 2, 2011 at 8:52 PM, Eric Hameleers al...@slackware.com wrote: On Fri, 2 Sep 2011, Dirk Mueller wrote: Hi, just finished uploading the first set of 4.7.1 tarballs. I have not yet been able to fully build them myself yet, given that my scripts failed early over night.. Anyway, I hope it works out. I have rebuilt kdeaccessibility and kdeutils from the modular git trees into the previous monolithic tarballs so that the tarball layout does not change between 4.7.x releases. If you know about any issues (unexptected changes in the tarball layout, or build issues, blocking bugs), please let me know. I'll try to respond on Sunday, currently travelling with limited internet. Greetings, Dirk Dirk, Hi Eric, Access to the 4.7.1 directory is denied because of these directory properties: drwx-- 4096 2011/09/02 09:28:42 4.7.1 Can you please open up the 4.7.1 directory? You should now be able to access the 4.7.1 directory if you have a packagers account. Cheers, Eric Regards, Ben Cooksley KDE Sysadmin Hi Ben Yes thanks, I get access to the tarballs now. Cheers, 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
Re: No more release schedules.
On Fri, 10 Jun 2011, Modestas Vainius wrote: 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. 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. Certainly, distros apply patches, backports and branding but the issue is that when someone states I am using KDE SC 4.6.3 you largely know what he is using. If the user has an issue, this makes the troubleshooting more deterministic. 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. 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. 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. Give me the chance to have a deterministic build process and I will cheer. I am not aiming at let's ruffle through the KDE ftp server directories, grab this and that software update and hope for a 95% working desktop. I want a _working_ desktop. So forget about monolithic tarballs please. It is clouding the issue. 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
Re: No more release schedules.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 9 Jun 2011, Andreas K. Huettel wrote: Dear KDE upstream, Since KDE is the community, how can we do a KDE 4.8? And then Platform will call itself 5 if I understood correctly. So how do we call a new release schedule then? I just read a very good novel where all such talk about Software Collection or Platform was aptly called commercial bulshytt. I think many of us, including your only-users, would appreciate it if you all there upstream would just stick to KDE, because that is what everyone uses. Nothing else. Are you serious that you want to decouple the release of our frameworks from each other? THat would create a huge mess, extreme amounts of overhead, be very destructive to our community... This puzzles me as I know how much you love KDE. What does my love for KDE have to do with it? I think it's good for KDE to let each module set their freezes on their own, depending on which work flow they will adapt. If we decide it early the module maintainers have time enough to get used to creating the schedule. Basically this is nothing but a dissolution of the KDE project as a whole. Sure, we'll end up with a lot of projects using and enhancing kdelibs (or whatever becomes of that), but there will be no coherence anymore. We can set a preferred release day twice a year, which every module can work to if they like. We can still package and release them if you like, that's independent of the schedules. 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. 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. 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. Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3xNoAACgkQXlaqr6dcvaD7XQCeKTkJxp3D3ag/+S7d8H4HIgZF p4EAn3iZBqj2vNpoBYNOMcxcTMsa3frx =3Ofn -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: modular kdelibs: packagers' view
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 5 Jun 2011, Sebastian Kügler wrote: Hi all, I'm writing this email from the Platform11 sprint in Randa, and I'd like to collect input how we can get the different needs of developers and packagers together. Let me quickly outline the situation. There has been a trend and desire to ship kdelibs (and other parts of our development platform, I'm just writing kdelibs here for convenience) as separate libraries, the reasons for this are: * can be individually consumed by 3rd party developers, no either or decision for kdelibs, helps 3rd party adoption * kdelibs' purpose is not anymore just desktop, mobile use cases become more important, more modularity helps to create leaner systems If we end up doing this, it has two important ramifications: * More individual packages, might create extra work for packagers, depending on their tools * Change in package's structures While the consequences for developers can be kept rather low, it *will* mean some restructuring of existing packages. I see a couple of things we can do here: * Provide traditional tarballs, leading to relatively little disruption, but means duplication as we provide different sets of tarballs that overlap, might be more confusing than worth it I would say that this is the cleanest solution. For me, because it allows to build the same coherent set of packages we use to build in Slackware (you get it all). For other packagers who stepped up to indicate that they do split into smaller sub-packages but work from monolithic source tarballs. An important advantage to providing monolithic tarballs is the reassurance (to us packagers) that what we get is a set of software sources that belongs together. What do I mean with that (and please shoot holes in it if my view is wrong): at this moment the set of 4.6.80 tarballs are all carrying that version number. That indicates that this collection too, is a coherent set. But once this split is accepted and agreed upon, what prevents individual developer teams from stating that they are unable to meed the general release schedule for the KDE SC? Like what happened to KDEPIM (and for good reasons - the team rewrote their suite from scratch) and we ended up with a lot of questions as to what to ship when, and what dependencies to use (or avoid). There is no control mechanism I could find that would prevent other teams from taking the same stance. If a split of sources into more and smaller tarballs is to become the future release policy, then a strict rule about commitment to the overall release schedule would be welcome. Else one of the pillars of KDE's strength - reliable source releases- would crumble. That is why I would vote for keeping the larger monolithic tarballs. * Do the split once, try to prevent the git migration mess where we've clearly not thought through the ramifications for release management, which lead to much confusion and frustration among packagers I absolutely agree that the next step should be more cleanly executed. What happened to kdeedu was not pretty, and not discussed thoroughly. As we haven't taken any firm decisions, I'd like to invite input from you, to see how we can accommodate your workflows and keep the extra work for those packaging low. Please do keep in mind that those changes are necessary for KDE to move on, since modularizing our platform is an entirely useless effort, if those changes aren't reflected in the form they end up on most developers' machines. In the end, for Slackware it will mean more work, but that would be largely a one-time effort (like is the case for other teams). We can create a modular framework for building KDE. If I don't do it, Pat will most certainly do it ;-) Considering the size of Slackware's core team it might delay the adoption of KDE 4.7 into the distribution. But that would not be new or unusual - while I provide bleeding edge KDE packages in my own repository, Slackware is usually a bit behind on KDE releases, and with good reasons. Precisely this approach has made the KDE experience on Slackware generally a very pleasant one. Thanks for your input already. Also please don't wait too long with your feedback, since it's essential for ongoing discussions here at Platform11. I will be collecting the input and taking it into the discussions going on here. (There are some packagers present, but obviously we should give everyone the chance to provide input.) Cheers, It took a while to read up on mailing list emails, but you caught up on me already in other channels, which I do appreciate. Good luck! Cheers, Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3tHUAACgkQXlaqr6dcvaCS4ACeP7mqfWJg37qYyzmE0nRP1MwZ IkgAmwY2Kn3a8t3bfsKhvWQHcSmb7Raf =of/G
Re: git migration, next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 3 Jun 2011, Jeremy Whiting wrote: Dirk, all, 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? thanks, Jeremy Whiting Hi Jeremy Thanks for asking this, really appreciated. I would feel very relieved if the old monolithic tarballs would stay as a download option. Even if the release team maintains a series of scripts that makes a controlled checkout of monolithic tarballs possible for packagers, that would be an acceptible solution. I expressed my thoughts on the split of kdeedu in an earlier post and coincidentally I fired up this discussion on my blog and the SLackware forum a few hours ago... Slackware will have to consider dropping KDE if we are confronted with source fragmentation. We are a small team and can not accept the added burden of maintaining a fragmented KDE based desktop environment. Fragmenting the source tarballs may be only one step but seeing what happens in GNOME land, with Redhat employees forcibly pushing people into directions they do not want to be taken, I would welcome it if KDE would remain the sane, independent desktop enviroment, or even Software Collection, that I have come to love. Cheers, Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3o+cAACgkQXlaqr6dcvaC6dgCfeQLtEetvS4t/MEZmIFkrgsEg naIAn12z4bp/1EjO00dKiL/HkVizoRVR =3XmU -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 3 Jun 2011, Kevin Kofler wrote: On Friday 03 June 2011, Eric Hameleers wrote: Fragmenting the source tarballs may be only one step but seeing what happens in GNOME land, with Redhat employees forcibly pushing people into directions they do not want to be taken, I would welcome it if KDE would remain the sane, independent desktop enviroment, or even Software Collection, that I have come to love. Please leave Red Hat out of this! Red Hat has absolutely nothing to do with these splits! In fact, the main Red Hat KDE packager (Than Ngo) has also expressed his unhappiness about the split tarballs in the Fedora KDE SIG discussions. Kevin, it was not meant as a stab at you and your KDE team. My apologies if it came across like that. I do like Redhat's Linux, use it on a daily basis on my laptop even. I also respect Fedora as a testing ground and a distro in itself. No more bad words about your employer. I want to rephrase then: I would like to see KDE keep its independent position and easy build process. Please don't let it grow more GNOME-like in maintenance effort and limitation of the target audience. If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. Cheers, Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3pAg8ACgkQXlaqr6dcvaBaJQCfQQkEn/+NYbrf5le7WRMPRRRM 2JcAnjP4Gjqgyt8L8FzBpB+4elVozvRp =czYD -END PGP SIGNATURE- ___ 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)
On Tue, 24 May 2011, Alexander Neundorf wrote: On Sunday 22 May 2011, Alexander Neundorf wrote: On Sunday 22 May 2011, Kevin Kofler wrote: On Sunday 22 May 2011, Alexander Neundorf wrote: So, what I'm doing right now for kdesupport is to create one CMakeLists.txt, which contains all the contained projects (automoc4, phonon, attica, akonadi, ...) via the externalproject()-feature from CMake. What it does, is it gets and updates all the sources from git, configures, builds and installs them. So it feels almost like it did before. Unfortunately, this is of no use for us packagers because we are banned by policy (and at least in Fedora, this is enforced by the build system) from downloading stuff during build. We can only work from tarballs. (If we want to package a snapshot, we have to check it out, tar it, then package the resulting tarball.) I'll see whether I can do something for this. Alex Looks good :-) I have here now a CMakeLists.txt for kdesupport, which downloads everything from git and builds it. But on make package, it creates basically a package of the downloaded sources together with a matching CMakeLists.txt (which then doesn't download, but just uses the already present sources). I.e. you could do cmake srcdir , then make package (or maybe some custom target), and then you'd have a tgz of kdesupport which you can unpack and build anywhere. Would that help your case ? Alex Hi Alex Absolutely! I have no issues with creating a comprehensive tarball myself. In fact, if this allows me to build a single monolithic kdesupport package again, then you provide what I need. The resulting kdesupport source tarball will then of course also be available to other interested parties, since Slackware (and/or my own test repository) will provide this source tarball along with the binary Slackware package. I think it would be awesome if this should be repeated for the other tarballs which got split (kdeedu, and I think kdebase too but I have not yet looked closer). Cheers, 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
Re: KDE 4.7 Beta1 (4.6.80) tarballs uploaded (try#1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 21 May 2011, Dirk Mueller wrote: On Saturday 21 May 2011, Dirk Mueller wrote: I found several myself already: And as I found out, kdelibs now depends on kdelibs-experimental, so I had to remove the splitting for now: 890d551e6332baea19b9bcb0655fce0c kdelibs-4.6.80.tar.bz2 Thanks, Dirk Oh boy. The turn of events with KDE 4.7.x is most unfortunate. I noticed an explosion of source tarballs. Dirk, are instructions available on how to re-assemble sources back to the original set? Or else, are instructions available on how to compile the bigger all-comprising packages where the separated applications and libraries are included again, like was the case all the time up to 4.7? It would be nice if there would at least be scripts available for distro packagers that allow to checkout bundled source tarballs from the repository. In the presence of such scripts, I would be able to generate old-style source tarballs and make them available for other packagers, if the KDE release team decided against making those available on the ftp site. Why am I proposing this? I am afraid that for Slackware, the bloat in KDE packages is not acceptible from a maintenance point of view. I do not speak _for_ Patrick Volkerding, but I spoke _with_ him, and since I also do a lot of the work with regard to researching and packaging KDE for Slackware, I have to say this on the matter: If there are no ways around this, then we are seriously considering the removal of KDE from the Slackware distribution and turning support over to willing third parties. This will go the way of GNOME which was abandoned by Slackware for the same reasons - we refuse to participate in a maintenance hell. Cheers (but not really), Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3X92EACgkQXlaqr6dcvaDoyQCgpdZ+6W2wIfbL/wRAOwkYhgtm FrAAn2VKLO1H9FUWMY1hq3k98ZrTlKAj =ZBu3 -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.0 tarballs (try#1) uploaded
On Fri, 21 Jan 2011, Dirk Mueller wrote: Hi, I just finished uploading the first set of KDE 4.6.0 tarballs. It includes a hotfix for the last showstopper bug, so we can continue. Thanks to Sebastian and Will for debugging and working on the issue. Release announcement might slip a bit given that we're quite late in the game, though I prefer not to. Let me know if thats a problem for you in any case. Building is not finished yet for me, so let me know if you find any showstopper issues. Thanks, Dirk Hi Dirk The l10n files do not contain localizations for kdepim. Can you provide kdepim-l10n source tarballs for the 4.6 beta? Apparently the kdepim devs themselves have no idea how to do this? Or can the localization files for kdepim-4.4.5 still be used? Cheers, 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
Re: KDE 4.6.0 tarballs (try#1) uploaded
On Fri, 21 Jan 2011, Albert Astals Cid wrote: The l10n files do not contain localizations for kdepim. Obviously as kdepim is not being released. I did not talk about kdepim 4.6 here. I was referring to kdepim 4.4.9 (or 4.4.10) that I want to package (including localization) together with KDE 4.6.0. Can you provide kdepim-l10n source tarballs for the 4.6 beta? No OK. Then, are there any changes with respect to older 4.4.x releases or can I use those old translations still? Apparently the kdepim devs themselves have no idea how to do this? Bullshit. Albert I was not my intention to piss you off Albert. Perhaps I should not have been speaking in plural, but I had http://www.kdedevelopers.org/node/4321 in the back of my mind when I wrote that. Please prove me wrong. Cheers, 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
Re: KDE 4.6.0 tarballs (try#1) uploaded
On Fri, 21 Jan 2011, Albert Astals Cid wrote: As Allen as said lots of times, yes, if you want to use kdepim 4.4.x use l10n from the last 4.4.x kde Call me old and forgetful then. Last kdepim 4.6 beta package had localizations inside, happy to be proven wrong? Albert I always am at peace with being proven wrong. It means that people care. Thank you. Cheers, 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
Re: KDEPIM 4.4.10 Planning
On Thu, 13 Jan 2011, Allen Winter wrote: Howdy, I think we'll make one final bugfix release for 4.4 and then we'll be done forever with the 4.4 series. Target date for tagging and release is 26 January 2011, but I'm very flexible with this date. If anyone has time to fix some of the more notorious bugs -- especially regressions that may have occurred with 4.6 kdelibs|kdepimlibs -- please don't hesitate to do so. Comments? Objections? -Allen Can anyone tell me how I can create a separate l10n tarball for kdepim? As it stands now, we have to ship KDE 4.5.5 (and later KDE 4.6.0) with kdepim-4.4.9 or kdepim-4.4.10 but currently I do not have any idea how to include the localizations for kdepim into the kde-l10n packages. Is there a script that extracts kdepim-l10n from the repository? Cheers, 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
Re: KDE 4.6 Beta1 tarballs (4.5.80) uploaded
On Fri, 19 Nov 2010, Dirk Mueller wrote: Hi, I just finished uploading the first set of tarballs.. I believe I need a couple of more tarballs for those to work properly (akonadi etc), working on that now. Please let me know of urgent fixes/compile issues in those tar balls. Thanks, Dirk Thanks Dirk Is there a spec sheet with the dependencies / requirements for 4.6.x available somewhere? Cheers, 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
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
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Tue, 3 Aug 2010, Max Brazhnikov wrote: On Thu, 29 Jul 2010 14:09:45 +0200, Dirk Mueller wrote: Hi, I just finished uploading the first set of KDE 4.5.0 tarballs to stable/4.5.0/src. Please let me know of any blocking issues (JRiddels PyQt 4.7 fix is not yet included I believe). kde-l10n tarballs are still building. Thanks, Dirk What about extragears, will they be released? Max All the sources (including kde-l10n) built without issues on Slackware, Dirk. But I was wondering about the status of extragear as well. Cheers, 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
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Tue, 3 Aug 2010, Dirk Mueller wrote: On Monday 02 August 2010, Dirk Mueller wrote: and those were wrong, I'm rebuilding them now (upload tomorrow morning). New kde-l10n* tarballs uploaded. Greetings, Dirk Hi Dirk Btween the original upload and the fixed set of kde-l10n tarballs, some translations seem to have disappeared. kde-l10n-tg-4.5.0.tar.bz2 kde-l10n-si-4.5.0.tar.bz2 kde-l10n-mk-4.5.0.tar.bz2 kde-l10n-mai-4.5.0.tar.bz2 kde-l10n-csb-4.5.0.tar.bz2 Was this intentional? Cheers, 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
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Mon, 2 Aug 2010, Dirk Mueller wrote: Date: Mon, 2 Aug 2010 13:32:31 +0200 From: Dirk Mueller muel...@kde.org To: release-team@kde.org Cc: kde-packa...@kde.org, Marco Martin notm...@gmail.com, Raphael Kubo da Costa kub...@gmail.com Subject: Re: KDE 4.5.0 tagged (1st try of tarballs uploaded) On Sunday 01 August 2010, Raphael Kubo da Costa wrote: A workaround is to simply create the KConfig object before calling importLayout(), so that it is not passed as a temporary. I've committed revisions 1157732 (trunk) and 1157733 (4.5 branch) which fix the reported issue. Thanks. I've included this fix in the 4.5.0 tarball: a552e93b963879b97853fe5e4b699d27 kdebase-workspace-4.5.0.tar.bz2 Greetings, Dirk Hi Dirk Apparently this email originated outside of kde-packager mailing list. I have no previous email about this conversation, so I would like to know what this is about, and whether it is useful to rebuild my 4.5.0 kdebase-workspace package for these two commits? Cheers, 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
Re: tags
On Thu, 1 Jul 2010, Sebastian Kügler wrote: On Wednesday 30 June 2010 22:05:10 David Faure wrote: SVN commit 1144780 by dfaure: Here comes kdesupport-for-4.5, based on the latest stable tag for each of its components. Just a problem with polkit-qt (tags/polkit-qt/0.9.3 doesn't exist, I emailed Dario), and phonon not here yet (I'll import it from git) CCMAIL: kde-core-de...@kde.org Thanks David! I'm CC:ing release-team and kde-packagers so more relevant people see this (and stop wondering which dependencies to package). A kdesupport-for-4.5 (directory) A kdesupport-for-4.5/VERSIONS A kdesupport-for-4.5/akonadi (directory) A kdesupport-for-4.5/attica (directory) A kdesupport-for-4.5/automoc4 (directory) A kdesupport-for-4.5/oxygen-icons (directory) A kdesupport-for-4.5/polkit-qt (directory) A kdesupport-for-4.5/polkit-qt-1 (directory) A kdesupport-for-4.5/qca (directory) A kdesupport-for-4.5/qimageblitz (directory) A kdesupport-for-4.5/soprano (directory) A kdesupport-for-4.5/strigi (directory) A kdesupport-for-4.5/taglib (directory) Stupid question perhaps, but I am assuming that these are just minimum version numbers, is that correct? Several of the above pieces of software have newer versions available than recommended in kdesupport-for4.4. Yet I would like to have one set of support packages that are able to be used with KDE SC 4.4.5 as well as the current RC for 4.5. Will KDE 4.4.5 be OK with the versions of kde-support packages targeted for 4.5.0 ? Cheers, 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
Re: KDE 4.5 RC1 uploaded
On Thu, 24 Jun 2010, Dirk Mueller wrote: just finished uploading 4.4.90 (4.5 RC1) tarballs.. Still compiling. Let me know of critical issues. Checking them tomorrow, not feeling well today. Hope you will get better soon. Come to think of it, what is KDE 4.5 target version for Qt? Is it still 4.6.2 or do I have to start building against 4.7 ? Cheers, 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
Re: KDE 4.5 Beta2 (4.4.85) uploaded
On Wed, 9 Jun 2010, Dirk Mueller wrote: On Wednesday 09 June 2010, Volker Krause wrote: sorry, I should have mentioned that, using Akonadi 1.3.80 is perfectly fine for KDE 4.4.85, 1.3.85 just contains a few useful fixes but no API or protocol extensions. Thanks,Volker! is everybody fine with releasing Beta2 today (unlike originally planned tomorrow morning)? It seems it all went smooth and at least opensuse has packages ready (and people are asking for it already). Please let me know ASAP if you need more time. Thanks, Dirk I have my packages for Slackware ready, and at the last moment added the new akonadi 1.3.85 package too. Cheers, 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
Re: KDE 4.4.3 tarballs uploaded (try #1)
On Mon, 3 May 2010, Dirk Mueller wrote: On Friday 30 April 2010, Albert Astals Cid wrote: tips_ter_voorbereiding.1, so I assume the problem is because the manpage translates the command name itself. You might want to take the fixed docbook from r1121234 after including that, it fails in nl/docs/kdepim/kmail now. The new tarball is 331bf5fe65db5916331731512a645c8d kde-l10n/kde-l10n-nl-4.4.3.tar.bz2 Greetings, Dirk Hi Dirk, Does that actually compile for you? Because I see these lines still, in kde-l10n-nl-4.4.3/docs/kdelibs/preparetips/man-preparetips.1.docbook: command kdeopties/command The kdeopties is translated from kdeoptions but as an instance of the actual command name, it should not have been translated in this location. Cheers, 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
Re: KDE 4.4.2 tarballs (try #1) uploaded
On Sat, 27 Mar 2010, Simon Edwards wrote: Eric Hameleers wrote: On Fri, 26 Mar 2010, Dirk Mueller wrote: I just finished uploading the first set of KDE 4.4.2 tarballs. Please let me know of any issues that you might experience. Intended release date is next week Tuesday/Wednesday (I'm sorry that I'm a day late with tagging). The kdebindings tarball fails to build with this error: [ 91%] Building CXX object python/pykde4/CMakeFiles/python_module_PyKDE4_kutils.dir/sip/kutils/sipkutilspart7.o Linking CXX shared library ../../lib/pykde/kutils.so [ 91%] Built target python_module_PyKDE4_kutils [ 91%] Generating sip/nepomuk/sipnepomukpart0.cpp, sip/nepomuk/sipnepomukpart1.cpp, sip/nepomuk/sipnepomukpart2.cpp, sip/nepomuk/sipnepomukpart3.cpp, sip/nepomuk/sipnepomukpart4.cpp, sip/nepomuk/sipnepomukpart5.cpp, sip/nepomuk/sipnepomukpart6.cpp, sip/nepomuk/sipnepomukpart7.cpp sip: QDebug is undefined make[2]: *** [python/pykde4/sip/nepomuk/sipnepomukpart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_nepomuk.dir/all] Error 2 make: *** [all] Error 2 I am building against sip 4.10.1 and kde-qt 4.6.2-patched I'm not seeing this error on my 4.4 svn branch build. Can you tell me which version of Python PyQt you are using? Is anyone else seeing this problem? I have PyQt-x11-gpl-4.7.2 and python-2.6.4 installed here. Cheers, 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
Re: kde-l10n-sv for 4.4.2 does not compile
This is the exact eror when building sv. I build on KDE 4.4.2: [ 85%] Generating ktouch.1 Writing ktouch.1 for refentry [ 85%] Built target ktouch-manpage-man-ktouch Scanning dependencies of target kturtle-handbook [ 85%] Generating index.cache.bz2 using-kturtle.docbook:24: parser error : Entity 'turtlelang' not defined (3) on the left where you type the turtlelang; commands, the link linkend=t ^ using-kturtle.docbook:44: parser error : Entity 'turtlelang' not defined In the code editor you type the turtlelang; commands. It has all of the featur ^ using-kturtle.docbook:68: parser error : Entity 'turtlelang' not defined You can open turtlelang; files by choosing menuchoice ^ using-kturtle.docbook:156: parser error : Entity 'turtlelang' not defined Creates a new, empty turtlelang; file./para ^ using-kturtle.docbook:179: parser error : Entity 'turtlelang' not defined Opens a turtlelang; file./para ^ using-kturtle.docbook:196: parser error : Entity 'turtlelang' not defined Opens a turtlelang; file that has been opened recently./para ^ using-kturtle.docbook:213: parser error : Entity 'turtlelang' not defined Open example turtlelang; programs. The examples are in your favorite language ^ using-kturtle.docbook:242: parser error : Entity 'turtlelang' not defined Saves the currently opened turtlelang; file./para ^ using-kturtle.docbook:259: parser error : Entity 'turtlelang' not defined Saves the currently opened turtlelang; file on a specified location./para ^ using-kturtle.docbook:976: parser error : chunk is not well balanced ^ index.docbook:238: parser error : Failure to process entity using-kturtle using-kturtle; ^ index.docbook:238: parser error : Entity 'using-kturtle' not defined using-kturtle; ^ make[2]: *** [docs/kdeedu/kturtle/index.cache.bz2] Error 1 make[1]: *** [docs/kdeedu/kturtle/CMakeFiles/kturtle-handbook.dir/all] Error 2 make: *** [all] Error 2 Cheers, Eric On Tue, 30 Mar 2010, Albert Astals Cid wrote: Date: Tue, 30 Mar 2010 08:38:33 + (GMT) From: Albert Astals Cid aa...@kde.org To: kde-packa...@kde.org, Dirk Mueller muel...@kde.org Cc: release-team@kde.org Subject: Re: kde-l10n-sv for 4.4.2 does not compile It complains about turtlelang entity not being defined as far as i can remember, the Debian team had the same problem, maybe you built against kdelibs not from 4.4.2? Albert --- El mar, 30/3/10, Dirk Mueller muel...@kde.org escribió: De: Dirk Mueller muel...@kde.org Asunto: Re: kde-l10n-sv for 4.4.2 does not compile Para: kde-packa...@kde.org CC: Albert Astals Cid aa...@kde.org, release-team@kde.org Fecha: martes, 30 de marzo, 2010 10:30 On Monday 29 March 2010, Albert Astals Cid wrote: You might want to remove sv/kdeedu/kturtle/index.docbook to make it compile. whats the error message? strangely it built for me. Greetings, Dirk ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager Cheers, 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
Re: KDE 4.4.2 tarballs (try #1) uploaded
On Fri, 26 Mar 2010, Dirk Mueller wrote: I just finished uploading the first set of KDE 4.4.2 tarballs. Please let me know of any issues that you might experience. Intended release date is next week Tuesday/Wednesday (I'm sorry that I'm a day late with tagging). The kdebindings tarball fails to build with this error: [ 91%] Building CXX object python/pykde4/CMakeFiles/python_module_PyKDE4_kutils.dir/sip/kutils/sipkutilspart7.o Linking CXX shared library ../../lib/pykde/kutils.so [ 91%] Built target python_module_PyKDE4_kutils [ 91%] Generating sip/nepomuk/sipnepomukpart0.cpp, sip/nepomuk/sipnepomukpart1.cpp, sip/nepomuk/sipnepomukpart2.cpp, sip/nepomuk/sipnepomukpart3.cpp, sip/nepomuk/sipnepomukpart4.cpp, sip/nepomuk/sipnepomukpart5.cpp, sip/nepomuk/sipnepomukpart6.cpp, sip/nepomuk/sipnepomukpart7.cpp sip: QDebug is undefined make[2]: *** [python/pykde4/sip/nepomuk/sipnepomukpart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_nepomuk.dir/all] Error 2 make: *** [all] Error 2 I am building against sip 4.10.1 and kde-qt 4.6.2-patched Cheers, 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
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Wed, 20 Jan 2010, Eric Hameleers wrote: Date: Wed, 20 Jan 2010 08:30:10 -0800 (PST) From: Eric Hameleers al...@slackware.com To: Dirk Mueller muel...@kde.org Cc: kde-bindi...@kde.org, kde-packa...@kde.org, Simon Edwards si...@simonzone.com, KDE release coordination release-team@kde.org Subject: Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded On Wed, 20 Jan 2010, Dirk Mueller wrote: On Thursday 07 January 2010, Simon Edwards wrote: [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all] Error 2 make: *** [all] Error 2 It should work fine with a recent SIP and PyQt snapshot. A new stable release of PyQt is imminent, then can I up the version check in CMakeLists.txt. Sorry for the inconvenience guys. Is it possible to make the bindings only use released versions of sip/pyqt? with RC2, there is a new problem: /usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_1.o cd kdebindings-1077263/build/smoke/qt /usr/bin/c++ -Dsmokeqt_EXPORTS - D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL - DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT - DSMOKE_BUILDING -DGCC_VISIBILITY -DBASE_SMOKE_BUILDING -O2 -march=i586 - mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector - funwind-tables -fasynchronous-unwind-tables -Werror=format-security -Wmissing- format-attribute -Werror=return-type -Wnon-virtual-dtor -Wno-long-long -ansi - Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat- security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common - Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility- inlines-hidden -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline - fPIC -Ikdebindings-1077263/build/smoke/qt -Ikdebindings-1077263/smoke/qt - Ikdebindings-1077263 -Ikdebindings-1077263/build -Ikdebindings-1077263/smoke - Iinclude -Iinclude/KDE -I/usr/include/KDE -I/usr/include/QtXmlPatterns - I/usr/include/QtXml -I/usr/include/QtWebKit -I/usr/include/QtUiTools - I/usr/include/QtTest -I/usr/include/QtSvg -I/usr/include/QtSql - I/usr/include/QtScriptTools -I/usr/include/QtScript -I/usr/include/QtOpenGL - I/usr/include/QtNetwork -I/usr/include/QtMultimedia -I/usr/include/QtHelp - I/usr/include/QtDesigner -I/usr/include/QtDBus -I/usr/include/QtAssistant - I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore - I/usr/include/Qt -I/usr/share/qt4/mkspecs/default -D_GNU_SOURCE - D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o CMakeFiles/smokeqt.dir/x_1.o -c kdebindings-1077263/build/smoke/qt/x_1.cpp kdebindings-1077263/build/smoke/qt/x_1.cpp: In static member function 'static void __smokeqt::x_QAbstractPrintDialog::x_8(Smoke::StackItem*)': kdebindings-1077263/build/smoke/qt/x_1.cpp:4175: error: cannot allocate an object of abstract type '__smokeqt::x_QAbstractPrintDialog' kdebindings-1077263/build/smoke/qt/x_1.cpp:4131: note: because the following virtual functions are pure within '__smokeqt::x_QAbstractPrintDialog': /usr/include/QtGui/qabstractprintdialog.h:87: note: virtual int QAbstractPrintDialog::exec() kdebindings-1077263/build/smoke/qt/x_1.cpp: In constructor '__smokeqt::x_QAbstractPrintDialog::x_QAbstractPrintDialog()': kdebindings-1077263/build/smoke/qt/x_1.cpp:4178: error: no matching function for call to 'QAbstractPrintDialog::QAbstractPrintDialog()' /usr/include/QtGui/qabstractprintdialog.h:114: note: candidates are: QAbstractPrintDialog::QAbstractPrintDialog(const QAbstractPrintDialog) /usr/include/QtGui/qabstractprintdialog.h:111: note: QAbstractPrintDialog::QAbstractPrintDialog(QAbstractPrintDialogPrivate, QPrinter*, QWidget*) /usr/include/QtGui/qabstractprintdialog.h:84: note: QAbstractPrintDialog::QAbstractPrintDialog(QPrinter*, QWidget*) What is the solution here? Thanks, Dirk I want to add that I got these errors with sip-4.10 and PyQt-4.7 installed, i.e. these are not the snapshot versions which were available for RC1. Dirk Your commit 1077826 solved the above issue, but this is the next error I get in compiling kdebindings: parsing /tmp/kdebindings-4.3.95/smoke/qimageblitz/qimageblitz_includes.h Generating SMOKE sources... preparing SMOKE data [qimageblitz] writing out smokedata.cpp [qimageblitz] writing out x_*.cpp [qimageblitz] Done. Scanning dependencies of target smokeqimageblitz [ 26%] Building CXX object smoke/qimageblitz/CMakeFiles/smokeqimageblitz.dir/smokedata.o [ 26%] Building CXX object smoke/qimageblitz/CMakeFiles/smokeqimageblitz.dir/x_1.o Linking CXX shared library ../../lib/libsmokeqimageblitz.so [ 26%] Built target smokeqimageblitz [ 26%] Generating smokedata.cpp, x_1.cpp, x_2.cpp, x_3.cpp, x_4.cpp, x_5.cpp, x_6.cpp, x_7.cpp, x_8.cpp, x_9.cpp, x_10.cpp Couldn't find config file /tmp/kdebindings-4.3.95/build/smoke/solid/../kde/config.xml Cannot load library generator_: (libgenerator_.so
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Wed, 20 Jan 2010, Dirk Mueller wrote: On Thursday 07 January 2010, Simon Edwards wrote: [python/pykde4/CMakeFiles/python_module_PyKDE4_plasma.dir/all] Error 2 make: *** [all] Error 2 It should work fine with a recent SIP and PyQt snapshot. A new stable release of PyQt is imminent, then can I up the version check in CMakeLists.txt. Sorry for the inconvenience guys. Is it possible to make the bindings only use released versions of sip/pyqt? with RC2, there is a new problem: /usr/bin/cmake -E cmake_progress_report kdebindings-1077263/build/CMakeFiles Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_1.o cd kdebindings-1077263/build/smoke/qt /usr/bin/c++ -Dsmokeqt_EXPORTS - D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DQT_NO_STL - DQT_NO_CAST_TO_ASCII -D_REENTRANT -DKDE_DEPRECATED_WARNINGS -DQT3_SUPPORT - DSMOKE_BUILDING -DGCC_VISIBILITY -DBASE_SMOKE_BUILDING -O2 -march=i586 - mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector - funwind-tables -fasynchronous-unwind-tables -Werror=format-security -Wmissing- format-attribute -Werror=return-type -Wnon-virtual-dtor -Wno-long-long -ansi - Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat- security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common - Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility- inlines-hidden -g -O2 -fno-reorder-blocks -fno-schedule-insns -fno-inline - fPIC -Ikdebindings-1077263/build/smoke/qt -Ikdebindings-1077263/smoke/qt - Ikdebindings-1077263 -Ikdebindings-1077263/build -Ikdebindings-1077263/smoke - Iinclude -Iinclude/KDE -I/usr/include/KDE -I/usr/include/QtXmlPatterns - I/usr/include/QtXml -I/usr/include/QtWebKit -I/usr/include/QtUiTools - I/usr/include/QtTest -I/usr/include/QtSvg -I/usr/include/QtSql - I/usr/include/QtScriptTools -I/usr/include/QtScript -I/usr/include/QtOpenGL - I/usr/include/QtNetwork -I/usr/include/QtMultimedia -I/usr/include/QtHelp - I/usr/include/QtDesigner -I/usr/include/QtDBus -I/usr/include/QtAssistant - I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore - I/usr/include/Qt -I/usr/share/qt4/mkspecs/default -D_GNU_SOURCE - D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o CMakeFiles/smokeqt.dir/x_1.o -c kdebindings-1077263/build/smoke/qt/x_1.cpp kdebindings-1077263/build/smoke/qt/x_1.cpp: In static member function 'static void __smokeqt::x_QAbstractPrintDialog::x_8(Smoke::StackItem*)': kdebindings-1077263/build/smoke/qt/x_1.cpp:4175: error: cannot allocate an object of abstract type '__smokeqt::x_QAbstractPrintDialog' kdebindings-1077263/build/smoke/qt/x_1.cpp:4131: note: because the following virtual functions are pure within '__smokeqt::x_QAbstractPrintDialog': /usr/include/QtGui/qabstractprintdialog.h:87: note: virtual int QAbstractPrintDialog::exec() kdebindings-1077263/build/smoke/qt/x_1.cpp: In constructor '__smokeqt::x_QAbstractPrintDialog::x_QAbstractPrintDialog()': kdebindings-1077263/build/smoke/qt/x_1.cpp:4178: error: no matching function for call to 'QAbstractPrintDialog::QAbstractPrintDialog()' /usr/include/QtGui/qabstractprintdialog.h:114: note: candidates are: QAbstractPrintDialog::QAbstractPrintDialog(const QAbstractPrintDialog) /usr/include/QtGui/qabstractprintdialog.h:111: note: QAbstractPrintDialog::QAbstractPrintDialog(QAbstractPrintDialogPrivate, QPrinter*, QWidget*) /usr/include/QtGui/qabstractprintdialog.h:84: note: QAbstractPrintDialog::QAbstractPrintDialog(QPrinter*, QWidget*) What is the solution here? Thanks, Dirk I want to add that I got these errors with sip-4.10 and PyQt-4.7 installed, i.e. these are not the snapshot versions which were available for RC1. Cheers, 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
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Wed, 6 Jan 2010, Dirk Mueller wrote: Hi, I just finished the first set of 4.3.90 (KDE 4.4 RC1) tarballs and uploaded them. kde-l10n still takes a few more hours, I'll upload them later. Please let me know of any urgent issues, we'd like to release this asap. Greetings, Dirk ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The 4.3.85 tarball did not have any problem finding and using shared-desktop-ontologies. The shared-desktop-ontologies which I have installed has not changed at all in the meantime (this is v0.2). I see that kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake has changed since, to make v 0.2 a requirement (the previous version would just use /usr/share/ontologies as a fallback which is indeed correct) but I do not understand why cmake does not find my installed SDO 0.2. I have /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmake with this content: set(SHAREDDESKTOPONTOLOGIES_VERSION_MAJOR 0) set(SHAREDDESKTOPONTOLOGIES_VERSION_MINOR 2) set(SHAREDDESKTOPONTOLOGIES_VERSION 0.2) set(SHAREDDESKTOPONTOLOGIES_ROOT_DIR /usr/share/ontology) Cheers, 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
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thu, 7 Jan 2010, Dirk Mueller wrote: On Thursday 07 January 2010, Eric Hameleers wrote: SDO 0.2. I have /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmak e with this content: you need /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfigVersion.cmake as well, this is installed by my package here. Greetings, Dirk Yeah I have that too, it can not be the problem. But I am going to try updating the cmake and see if that helps. My current cmake is 2.6.2 which may be too old. Cheers, 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
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thu, 7 Jan 2010, Christophe Giboudeaux wrote: On Thursday 07 January 2010 14:28:22 Eric Hameleers wrote: Here, kdelibs 4.3.90 fails to find shared-desktop-ontologies. The 4.3.85 tarball did not have any problem finding and using shared-desktop-ontologies. The shared-desktop-ontologies which I have installed has not changed at all in the meantime (this is v0.2). I see that kdelibs/cmake/modules/FindSharedDesktopOntologies.cmake has changed since, to make v 0.2 a requirement (the previous version would just use /usr/share/ontologies as a fallback which is indeed correct) Well, no, this wasn't correct. When SDO 0.2 wasn't found, CMake was indeed looking in /usr/share/ontologies and was setting SDO_FOUND = true even if the required version didn't match the one installed. but I do not understand why cmake does not find my installed SDO 0.2. I have /usr/share/cmake/SharedDesktopOntologies/SharedDesktopOntologiesConfig.cmak e with this content: The only reason I see is the CMake version. cmake 2.6.3 will only look in $prefix/share/SharedDesktopOntologies/cmake/. Any higher version will also look in $prefix/share/cmake/SharedDesktopOntologies/ Christophe. Indeed, and as Sebastian Kügler also suggested, cmake was too old, being 2.6.2 here. With cmake 2.8.0, SDO was found alright. My suggestion would be to force the cmake version in building KDE 4.4 to be at least 2.6.3. Cheers, 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
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
On Thu, 7 Jan 2010, Dirk Mueller wrote: Can anybody else confirm that it builds? I would release the tarballs then. Greetings, Dirk 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_tree_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' [ 75%] Building CXX object apps/keditbookmarks/CMakeFiles/kdeinit_keditbookmarks.dir/settings.o In file included from /tmp/kdebase-4.3.90/build/apps/konqueror/sidebar/trees/konqsidebar_tree_final_cpp.cpp:3: /tmp/kdebase-4.3.90/apps/konqueror/sidebar/trees/konq_sidebartree.cpp:497:2: warning: #warning TODO port to QDrag (only possible once porting away from Q3ListView?) make[2]: *** [apps/konqueror/sidebar/CMakeFiles/konq_sidebar.dir/konq_sidebar_final_cpp.o] Error 1 make[1]: *** [apps/konqueror/sidebar/CMakeFiles/konq_sidebar.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs Cheers, 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
