kdesu build problem
Can anyone get kdesu to build? I find it doesn't pass the DESTDIR to the chgrp command and gives an error -- Installing: /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud -- Removed runtime path from /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud chgrp: cannot access '/build/buildd/kdesu-4.99.0/debian/tmplib/x86_64-linux-gnu/libexec/kf5/kdesud': No such file or directory (chgrp is missing the /usr/ in its path) I get the same problem with a git checkout and compile. The CMakeLists file is using DESTDIR, but it doesn't seem to be passed in? Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 118048: Make the KF5_LIBEXEC_INSTALL_DIR default depend on LIBEXEC_INSTALL_DIR
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118048/ --- Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Make the KF5_LIBEXEC_INSTALL_DIR default depend on LIBEXEC_INSTALL_DIR This way, overriding LIBEXEC_INSTALL_DIR will change where frameworks install libexec files in the expected way. Diffs - kde-modules/KDEInstallDirs.cmake 9efa90f85a6d595a9be35b46468b4345ed41abb7 Diff: https://git.reviewboard.kde.org/r/118048/diff/ Testing --- Configured kdesu both with and without -DLIBEXEC_INSTALL_DIR=/some/abs/path, and visually inspected the generated cmake_install.cmake files. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesu build problem
On 08/05/14 09:37, Jonathan Riddell wrote: Can anyone get kdesu to build? I find it doesn't pass the DESTDIR to the chgrp command and gives an error -- Installing: /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud -- Removed runtime path from /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud chgrp: cannot access '/build/buildd/kdesu-4.99.0/debian/tmplib/x86_64-linux-gnu/libexec/kf5/kdesud': No such file or directory (chgrp is missing the /usr/ in its path) I get the same problem with a git checkout and compile. The CMakeLists file is using DESTDIR, but it doesn't seem to be passed in? Fixed in http://commits.kde.org/kdesu/729e09034b7dadbae7b61aa1c3a64635ad0d9794 Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-frameworks-devel] Re: kdesu build problem
On Thu, May 08, 2014 at 10:59:16AM +0100, Alex Merry wrote: On 08/05/14 09:37, Jonathan Riddell wrote: Can anyone get kdesu to build? I find it doesn't pass the DESTDIR to the chgrp command and gives an error -- Installing: /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud -- Removed runtime path from /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud chgrp: cannot access '/build/buildd/kdesu-4.99.0/debian/tmplib/x86_64-linux-gnu/libexec/kf5/kdesud': No such file or directory (chgrp is missing the /usr/ in its path) I get the same problem with a git checkout and compile. The CMakeLists file is using DESTDIR, but it doesn't seem to be passed in? Fixed in http://commits.kde.org/kdesu/729e09034b7dadbae7b61aa1c3a64635ad0d9794 Lovely. I'd strongly suggest this gets put in the release tar as it stops the package being built. Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118048: Make the KF5_LIBEXEC_INSTALL_DIR default depend on LIBEXEC_INSTALL_DIR
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118048/#review57568 --- Ship it! Ship It! - Aleix Pol Gonzalez On May 8, 2014, 9:47 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118048/ --- (Updated May 8, 2014, 9:47 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Make the KF5_LIBEXEC_INSTALL_DIR default depend on LIBEXEC_INSTALL_DIR This way, overriding LIBEXEC_INSTALL_DIR will change where frameworks install libexec files in the expected way. Diffs - kde-modules/KDEInstallDirs.cmake 9efa90f85a6d595a9be35b46468b4345ed41abb7 Diff: https://git.reviewboard.kde.org/r/118048/diff/ Testing --- Configured kdesu both with and without -DLIBEXEC_INSTALL_DIR=/some/abs/path, and visually inspected the generated cmake_install.cmake files. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : sonnet_master_qt5 #58
See http://build.kde.org/job/sonnet_master_qt5/58/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118025: meinproc5 nam page update to kf5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118025/ --- (Updated May 8, 2014, 6:59 p.m.) Status -- This change has been marked as submitted. Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Update to kf5 Diffs - docs/meinproc5/man-meinproc5.8.docbook be6d683 Diff: https://git.reviewboard.kde.org/r/118025/diff/ Testing --- checkXML Thanks, Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118025: meinproc5 nam page update to kf5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118025/#review57600 --- This review has been submitted with commit e8877998aa10b812e1982bb90d6560262075e880 by Burkhard Lück to branch master. - Commit Hook On May 7, 2014, 10:55 a.m., Burkhard Lück wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118025/ --- (Updated May 7, 2014, 10:55 a.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Update to kf5 Diffs - docs/meinproc5/man-meinproc5.8.docbook be6d683 Diff: https://git.reviewboard.kde.org/r/118025/diff/ Testing --- checkXML Thanks, Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 118029: Cleanup kdelibs references (mostly replaced by kdoctools)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118029/#review57602 --- Ship it! Thanks - Burkhard Lück On May 7, 2014, 12:04 a.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118029/ --- (Updated May 7, 2014, 12:04 a.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- See summary and the patch... Diffs - docs/meinproc5/man-meinproc5.8.docbook be6d683 src/CMakeLists.txt 409c10e src/customization/catalog.xml 31e01eb src/meinproc.cpp 6d9360b src/template.docbook da9e687 Diff: https://git.reviewboard.kde.org/r/118029/diff/ Testing --- Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-frameworks-devel] Re: kdesu build problem
On Thursday 08 May 2014 11:11:03 Jonathan Riddell wrote: On Thu, May 08, 2014 at 10:59:16AM +0100, Alex Merry wrote: On 08/05/14 09:37, Jonathan Riddell wrote: Can anyone get kdesu to build? I find it doesn't pass the DESTDIR to the chgrp command and gives an error -- Installing: /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec/ kf5/kdesud -- Removed runtime path from /build/buildd/kdesu-4.99.0/debian/tmp/usr/lib/x86_64-linux-gnu/libexec /kf5/kdesud chgrp: cannot access '/build/buildd/kdesu-4.99.0/debian/tmplib/x86_64-linux-gnu/libexec/kf5/ kdesud': No such file or directory (chgrp is missing the /usr/ in its path) I get the same problem with a git checkout and compile. The CMakeLists file is using DESTDIR, but it doesn't seem to be passed in? Fixed in http://commits.kde.org/kdesu/729e09034b7dadbae7b61aa1c3a64635ad0d9794 Lovely. I'd strongly suggest this gets put in the release tar as it stops the package being built. Done. New tar uploaded, details attached. Ah, and I made the directory public - beta2 is out. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 kdesu v4.99.0-rc4 4f4f2a9092deccf2fc8b701bd9e2e17043c24adb 9bc1dad3d86c28bae406d18de5b5dccf84d6e0a18a8a02f6fec1ca2911d61ebb sources/kdesu-4.99.0.tar.xz ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
[Taking k-c-d out, too much cross-posting] On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote: If we have more than 50 libraries, do all of them need a full new release every month ? Not doing that leads to 1) a huge mess of versioning. The latest available version for each framework would be different, so how do you make sure you have the latest of each? And the min required version in each find_package would have to be increased manually, since it would no longer be the same everywhere. In a year we'd be at KArchive 5.3, KIO 5.7 required by KParts 5.1 required by KTextEditor 5.4, etc. etc. This seems extremely messy to deal with, for everyone. We decided long ago against this, for these very reasons. 2) more work for me: every month, for each of the 61 frameworks, I'd have to decide which ones need to be released and which one shouldn't As Luigi says, some of the smaller libraries may not see many changes at all, and maybe only old style patch level releases for them would be good enough ? That's exactly what will happen for the frameworks which didn't see many changes. The monthly release will include at most a few bugfixes and updated translations. The only difference is whether to call this 5.2 or 5.1.1 -- but again, these are libraries, so e.g. new methods don't break existing apps, the fear of new features doesn't work the same way as in applications. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117987: Always return true for alphaBlending()
On May 4, 2014, 2:17 p.m., Luigi Toscano wrote: The patch compiles, and non-gui kio clients like kio_info and kio_gopher (which use a KIconLoader) works (tested through kioclient cat). If no one else objects and this is approved, would you please mention that this setting has not been configurable for a long time as discussed on IRC? Thanks for testing. If no one objects, I am going to commit this tomorrow. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117987/#review57256 --- On May 4, 2014, 2:01 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117987/ --- (Updated May 4, 2014, 2:01 p.m.) Review request for KDE Frameworks and Luigi Toscano. Repository: kiconthemes Description --- Using QPixmap::defaultDepth() causes a crash when the icon loader is only used get icon paths and the application is only a QCoreApplication. Diffs - src/kiconloader.cpp 501367a Diff: https://git.reviewboard.kde.org/r/117987/diff/ Testing --- None, I currently have no KF setup to test. Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 118057: Use CMAKE_INSTALL_FOODIR style variables for KDEInstallDirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118057/ --- Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- This matches how CMake's GNUInstallDirs does things. The documentation is not yet updated, as this is an RFC, really. The old variable names still work, both when passed to the CMake command and when used in CMake scripts (the code keeps the old and new variables in sync). I took the opportunity to version the variable names for directories that are themselves versioned, which should help the transition to KF6. Diffs - kde-modules/KDEInstallDirs.cmake cadbba130fb282faa485594a420210710c8f951c Diff: https://git.reviewboard.kde.org/r/118057/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.05.2014 18:36, schrieb David Faure: [Cross posting against my will...] On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote: I understand that the big concern was about the testing: stable branches did not receive the same attention This is not the main concern. My main concern is that application developers prefer to work around bugs in KF5 (previously: kdelibs) rather than fix things at the right level, because fixes in KF5 will only be available in 6 months, and I want the bug fixed now. Your suggestion (6-months stable release) brings us back to exactly that. We'd like to try something better. Monthly small increments. Never big changes that break things, they get cut into small increments too. So no reason to buffer changes for 6 months. One thing I want to mention here because I think there is no real work around: When will you add new dependencies? In a rolling release process this is possible every month. From a packagers point of view, this is hardly doable: You cannot accept new dependencies in a security update. So what is the solution for the packager? Probably make a branch on top of the release that was used first, and try to find as many bug fixes as possible that will still apply. While rereading your email I see the following thing: fixes in KF5 will only be available in 6 months, and I want the bug fixed now. If these are _fixes_, why are they not backported to the stable branch atm? Maybe we should fix another issue here, and instead modify our understanding of stable branch. Even if it is hard for me, the maintainance of the Linux Kernel could be an example: with clear maintainers (or teams) of branches which will check which issues need backports. I think this is also the way it would happen (distros would probably try to maintain stable branches together), so I'd prefer if we could plan this ahead of the first release instead and possibly involving the developers of the libraries. regards, Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTa/OHAAoJEPAKI6QtGt1xyGoP/3mjMSidWSYy0jyw53Gl+ksW FWGeYU9drfo253iR+DemaiD3VSa6vOgdKl2RK03dpdM1GaKl2Hhpls/HcbucmCza 7vUa+IqjDiaFWLWtEn95ktRTCmbPHCGB87G1D9m7KrVmBqVHwVtIbkn3myXdPRR8 4fq1e4sPid020QGZNL6WoGqbYFePeFEf8rLu7pyNUTvE3mJsqSsXHDUKfCeDzW1a epxiheJxgCsz99GwQbvY7w3E3ge1I36jDlnCfCSwWoUbZe+uFU+wRD5fxtCDQcyE rkpy9IV4uzqFhloNI0wnTXrfBjME+b15uDDWCQBDGczWx6nJIS/ie7tI8BHNh8lf q2xdviVaBvgDCgjYjf5vxYr+HnO4LiRT5mZktCtjDbNEjAfhuOos5fLVqDFXXT3j oJUtmn7pxqM/0rrTTExRXtdKN8pz/bHdciOlo8I4T/j+bVn4Sd7MQFJE4DYmsfa3 /ZZW63dgbUbRHEBFl3hjLQ3NtB1nk+YHlhwi89VB1yBmi8M5MVQDazkxhpygrPJC K/JWRYfbar2dJSjZiQl0psl5ieJB/6+CL+sHK/36FGht1Otrx+rUAY+Km7oCxYy+ l9vzPd2CgL7LQHRxRxbEgRrNlSq0zrqApxUmau5sJsW9HoinOUvUvSr7qXQczPQB wyo3Djyu0lKuS8227eoV =LbgL -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
On Thursday, May 08, 2014 22:08:06 David Faure wrote: [Taking k-c-d out, too much cross-posting] On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote: If we have more than 50 libraries, do all of them need a full new release every month ? Not doing that leads to 1) a huge mess of versioning. The latest available version for each framework would be different, so how do you make sure you have the latest of each? And the min required version in each find_package would have to be increased manually, since it would no longer be the same everywhere. In a year we'd be at KArchive 5.3, KIO 5.7 required by KParts 5.1 required by KTextEditor 5.4, etc. etc. This seems extremely messy to deal with, for everyone. We decided long ago against this, for these very reasons. Yes, I know, I see it exactly the same way. That's the situation you have if you have a number of separate libraries. IMO it would be the correct thing if each of these libraries would actually specify the exact version of the other libraries they actually need... dependency hell. OTOH this would mean I could update one or a set of the frameworks libraries if I see the need to, without having to update them all, just because they all require for simplicity the same version of all libraries. That's why I still think we may have gone a bit too far with the splitting. 2) more work for me: every month, for each of the 61 frameworks, I'd have to decide which ones need to be released and which one shouldn't Well, if we say we have 61 independent frameworks libraries, ideally each should have a maintainer who takes care of releases, required dependencies etc., i.e. not one single person doing it for all. I know we don't have enough maintainers in real life. Just my 2c. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kdelibs_stable #1083
See http://build.kde.org/job/kdelibs_stable/1083/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks Release Cycle
[This message is a reply to all people requesting a long-term-maintained frameworks branch.] On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote: Kevin Ottens ha scritto: So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien, David, Rohan and myself. We juggled with several options, trying to address the following constraints: * We don't have many contributors; * We don't have enough testing in the stable branches, developers tend to have a hard time to dog food those; Other big projects with frequent releases, like the Linux kernel or Firefox have stable branches too; not all of the releases, but some of them. In case of the Linux kernel those stable branches are maintained by dedicated volunteers. Without those volunteers there wouldn't be any long-term-maintained Linux kernel branches. If you (Luigi and/or Alex [Neundorf] and/or Patrick) are willing to maintain a stable frameworks branch then nobody will stop you from doing so. On the contrary, I'm sure many people would be grateful for your initiative and all the work you put into maintaining such a branch. But please don't expect other people (in particular the small number of frameworks maintainers) to do this job for you. Remember, that in KDE (as in any other volunteer organization) you should never say we should do foo unless you mean I volunteer to [help with] do[ing] foo. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kdelibs_stable #1084
See http://build.kde.org/job/kdelibs_stable/1084/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
