Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master
On Mon, Dec 17, 2012 at 4:42 PM, Alexander Neundorf neund...@kde.orgwrote: Not really. For the frameworks branch the most current cmake is required, which is 2.8.10.1 currently. We will stay there with the most current until we get somewhat stable. I see. My post seems to date back then when it was discussed. Apparently, I have not contributed to frameworks to even notice it, at least not the way through that branch. My understanding got outdated. Thank you for the information. :) Laszlo PS.: If only the entry barrier was not so high for even a basic tool like cmake. It is certainly not a problem for me as an arch user, but I can understand this a -1 for many. This is of course off-topic here. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Boost vs cmake 2.8.8 vs kdepimlibs master
On Sun, Dec 16, 2012 at 11:07 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 17 de desembre de 2012, a les 00:03:38, Luigi Toscano va escriure: Albert Astals Cid wrote: El Diumenge, 16 de desembre de 2012, a les 23:53:23, Antonis Tsiapaliokas va escriure: Hello, Attached, can somebody give it a try ? Alex I have test the attached patch with 2.8.8 cmake and it doesn't work. With the 2.8.9 cmake, the issues is solved, without the attached patch needed. So let's go for the cmake increase? Anyone against it? (I will need an answer before RC1 tag on tuesday night) I am all for it. On a side note, I have never understood the objection against 2.8.9 before as that is what was also required for framework. Hence, it would somewhat lower the barrier for the framework contribution, too. IIRC, one of the main issues was the debian way, but it does not seem the case anymore: http://packages.debian.org/search?searchon=nameskeywords=cmake Laszlo ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request: aprs: use external QextSerialPort for TTY reading
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107536/#review22832 --- Off-topic: This patch reminds me that this ext serial port usage should msot likely be gone altogether in the near future in favour of QtSerialPort we developed for Qt4 and Qt5 in open, but that is for later. - Laszlo Papp On Nov. 30, 2012, 6:29 p.m., Pino Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107536/ --- (Updated Nov. 30, 2012, 6:29 p.m.) Review request for kdewin, Marble and Release Team. Description --- Instead of embedding an (old) copy of the QextSerialPort library, find for an external one; only if found enable the reading from TTY, which is otherwise disabled (leaving its configuration tab disabled). The drop of the internal QextSerialPort should also fix all the portability issues, since the plugin itself does not use any OS-dependent API, and it is then reenabled unconditionally. Hence, bug 241125 should now be fixed, and bug 237931 and bug 242039 should not happen anymore. @release-team: yes, I know this would introduce a new optional dependency, but on the other hand a copy of a 3rd party library would go away. Would this be acceptable at this point? This addresses bug 241125. http://bugs.kde.org/show_bug.cgi?id=241125 Diffs - cmake/modules/FindQextSerialPort.cmake PRE-CREATION src/plugins/render/CMakeLists.txt d82293ee782e735ff1c90e6e13d330fb7cf8563c src/plugins/render/aprs/AprsPlugin.cpp f406cec2ad665977830416aa7f5df59851a5e430 src/plugins/render/aprs/AprsTTY.cpp c65ac38b24269b608c8f3ea1452b670f9422174d src/plugins/render/aprs/CMakeLists.txt fb6ef13c80568a72a5bfcf8a2e675b969238b9f6 src/plugins/render/aprs/aprsconfig.h.in d0e6b5c4ce36080dc0e59422529c55728ff04b3a src/plugins/render/aprs/posix_qextserialport.cpp 118843f02a5c62fd708b9157e59a039dff06e238 src/plugins/render/aprs/qextserialport.h 457d831cffc4ae8c43ac7db2d85a20546eb65044 src/plugins/render/aprs/qextserialport.cpp 790e5a2701ba1291a645c4fd4b09a8a1c55d7541 src/plugins/render/aprs/qextserialport_global.h 013a6dcd4ecab97425b1286139af4f0e911c38c9 src/plugins/render/aprs/win_qextserialport.cpp 5f21d7302e61b50825f79a68b352d5b9544b3fa3 Diff: http://git.reviewboard.kde.org/r/107536/diff/ Testing --- The Aprs plugin compiles fine with and without an external QextSerialPort library. Thanks, Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
