tde-devels December 2013

devels@trinitydesktop.org

18 participants
106 discussions

How to insert a cmake variable into a *.desktop file
by Darrell Anderson 22 Dec '13

22 Dec '13

All, I want to create a patch that modifies two *.desktop files during compile time. What is the correct syntax to use for the cmake variable in the *.desktop files? For example: Exec=%CMAKE_VARIABLE% Thanks. :-) Darrell

3 2

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 22 Dec '13

22 Dec '13

>Ok... I'll add both my patches there too... I suppose the further >discussion will take place there... Good idea because all of this is way over my head. :) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 22 Dec '13

22 Dec '13

>Crap! It seems I finally found the exactly line that triggers the >cmake bug! =) Great! >Try this... > >PS: I'm not sure if it will break something in other nm-related >modules... >But it should repair the build of the tdelibs with the 2.8.12. >PPS: Also there could be some other similar issues in other >modules... You and Slavek seem to be on similar paths. He just attached a patch to bug report 1759. I'm in the middle of testing his patch now. I only just started but with Slavek's patch tdelibs finally finished the configuration without the infamous LINK_ONLY error and is compiling with 2.8.12. I still need to test with 2.8.12.1 and then backwards compatibility with 2.8.8. Darrell

2 1

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 22 Dec '13

22 Dec '13

>Try this patch... expected results are: ><cmake-2.8.12: works fine as always were >=cmake-2.8.12: no warnings; but the same LINK_ONLY-bla-bla error >/* I still >can't reproduce it, but I suspect it's because of some link flags >e.g. I >don't use hidden-visibility*/ >cmake-2.8.12.1: no warnings; clean build. Your patch works nicely with cmake <= 2.8.12.0 or 2.8.12.1. Builds are clean. As you noted, the patch does not help with 2.8.12.0. I receive the same exact LINK_ONLY failure. As noted, the problem is described in the gentoo bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=490194 The bug report mentions a specific patch and the patch became part of cmake 2.8.12.1. To my understanding, there is no downstream fix for this breakage with 2.8.12.0. The best we will be able to do for Trinity packagers is to let them know that Trinity will not build with 2.8.12.0. I asked the Slackware maintainer to update Slackware 14.1 to cmake 2.8.12.1 and I referenced the gentoo bugzilla. All I can do now is wait and see. I believe the Slackware maintainer avoided problems with cmake 2.8.12.0 in that the 2.8.12.0 was not updated in the Slackware 14.1 release cycle until just before RC1, well after all of the KDE packages had been built. Very likely he never saw the same build failures because he used cmake 2.8.10.2 to build the KDE4 packages for Slackware 14.1. Darrell

2 1

Opinion of Trinity R14.0.0
by Darrell Anderson 22 Dec '13

22 Dec '13

All, In the upcoming R14.0.0 press release I would like to include one user and one developer opinion why they enjoy Trinity R14.0.0. These types of quotations are common in product related press releases. If you volunteer an opinion, please be aware that some kind of identity connection to you is necessary. That connection can be a well-known online alias, but birth names are preferred to enhance credibility. The reason is in case a reviewer or reporter decides to perform fact checking. The press release will not include email addresses or anything like that. Just a name that a reviewer or reporter can identify and through the contacts listed at the end of the press release, be able to contact you to validate or expand upon your opinion. Although many people prefer privacy, providing an opinion and a name in the press release could serve as a free publicity of your coding and project participation skills. Please limit opinions to a maximum of three sentences. If English is not your native language, please still feel welcome to offer an opinion. I'll help you massage the text. As primary developers, Tim and Slavek should be the main press release contact points, but that is a decision for both of you to make. A draft of the press release is available in the etherpads: http://trinity.etherpad.trinitydesktop.org/37 Please feel welcome to improve the draft. Please post any such opinions here to the dev mail list. I'll select two, although I might roll dice to perform the selection. :-) Thank you! Darrell

2 1

tdebase FTBFS with clang
by Fat-Zer 21 Dec '13

21 Dec '13

tdebase FTBFS on kdesktop than it is built with clang. It's because clang can't handle "-z now" correctly. Build log: http://bpaste.net/show/160888/ Here is a patch. I'm going to provide yet another patch for LINKER_IMMEDIATE_BINDING_FLAGS wondering

1 1

Re: [trinity-devel] Recent mouse click problems
by Darrell Anderson 21 Dec '13

21 Dec '13

>>>I see this on my workstation with a flaky USB mouse. Do you see >>>frequent USB device disconnect/reconnect events in dmesg? >> >> I'm not seeing anything in the logs. Would you please show me a >> snippet of what you have seen? >> >> Darrell > >I'm not at that machine right now, but it is very obvious in the >syslog. > >I'll have to see if I can replicate on my R14 test box. I see nothing obvious in my system logs. Could the recent patches to use udisks rather than pmount play a role in this? Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 21 Dec '13

21 Dec '13

All, I ran some more testing against the cmake 2.8.12 CMP-0022 problem. The TL;DR version: The proposed patch partially works but needs attention. If we refine the patch to eliminate certain errors we probably will be able to place this entire cmake episode behind us. :-) The longer story: On Slackware 14.0 I have no problems compiling Trinity packages. The stock Slackware 14.0 came with cmake 2.8.8, but a while ago I updated my 14.0 build environment to cmake 2.8.10.2. I updated cmake because I was trying to anticipate what eventually would become Slackware 14.1. Along the way of developing the 14.1 branch after Slackware 14.0, cmake was updated to 2.8.10.2. Regardless, I have had no problems with 2.8.8 or 2.8.10.2. Slackware 14.0 comes with gcc 4.7.1 and glibc 2.15. In all of the following tests I attempted to build only the dependencies and core packages through tdebase. In each test I rebuilt all packages except TQt3 because that package has no cmake requirements. On Slackware 14.0, I built and installed cmake 2.8.12.0. I did not apply the proposed patch. I saw a slew of CMP0022 warnings for arts and tdelibs. While arts did compile, I was unable to build tdelibs. Next on Slackware 14.0, I built and installed cmake 2.8.12.1. I did not apply the proposed patch. I again saw a slew of CMP0022 warnings for arts, tdelibs, and tdebase. This time I was able to build tdelibs and tdebase. Thus 2.8.12.1 does provide a work-around to 2.8.12.0. Next on Slackware 14.0, I returned to cmake 2.8.8 (the version provided in the original 14.0). I applied the proposed patch. This was to test backwards compatibility of the patch in distros using cmake < 2.8.12. I got as far as tdelibs with no errors or warnings. tdebase failed to build, with a slew of errors such as the following: /dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference to `TQString::TQString(char const*)' /dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference to `TDEGlobal::locale()' /dev/shm/tdebase/tdmlib/kgreet_classic.cpp:494: undefined reference to `TDELocale::removeCatalogue(TQString const&)' CMakeFiles/kgreet_winbind- module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTI7TQGList[_ZTI7TQGL ist]+0x8): undefined reference to `typeinfo for TQPtrCollection' CMakeFiles/kgreet_winbind- module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTI15KWinbindGreeter[ _ZTI15KWinbindGreeter]+0x10): undefined reference to `typeinfo for TQObject' CMakeFiles/kgreet_winbind- module.dir/kgreet_winbind.cpp.o:(.data.rel.ro._ZTV7TQGList[_ZTV7TQGL ist]+0xc): undefined reference to `TQGList::clear()' Next on Slackware 14.0, I returned to cmake 2.8.10.2. I applied the proposed patch. Again no build failures through tdelibs while tdebase failed to build with the same errors. Next on Slackware 14.0, I returned to cmake 2.8.12.0. I applied the proposed patch. tdelibs failed to build, but I saw the same failures in Slackware 14.1. Apparently at least part of the patch is required to build tdelibs with cmake 2.8.12.0. Next on Slackware 14.0, I returned to cmake 2.8.12.1. I applied the proposed patch. Again no build failures through tdelibs while tdebase failed to build with the same errors. The original cmake 2.8.12 problems I reported occurred with Slackware 14.1 and not 14.0. I used 14.0 as a test environment to establish some kind of baseline. The primary differences between Slackware 14.1 and 14.0: cmake 2.8.12.0 vs. 2.8.8, gcc 4.8.2 vs. 4.7.1, and glibc 2.17 vs. 2.15. Yet by using Slackware 14.0 I believe I affirmed the failures I am experiencing are not related to gcc, glibc, etc. Some Trinity members report they can build Trinity with cmake 2.8.12.0 although they witness the slew of CMP0022 warnings. With 2.8.12.X I always have been able to build arts but always either fail to build tdelibs or tdebase. The proposed patch allows me to build tdelibs but not tdebase. I don't believe the problem is Slackware 14.1. Just cmake 2.8.12.X. Darrell

2 1

Re: [trinity-devel] Minimum cmake version to compile Trinity
by Darrell Anderson 21 Dec '13

21 Dec '13

>IMO it's a good idea to update at least to 2.6. Lower versions >definitely won't work... >I'm not sure about 2.8. It may be only a «soft» limit. On the >other hand I >don't suppose it will cause any problems... And nobody will test >for >compatibility with versions lower than 2.8... And nobody of users >would be >able to because tdelibs requres 2.8... so, go ahead =) > >NOTE: I'm just successfully built tdebase and tdelibs with cmake >versions 2.8.0 and 2.8.3. The oldest release of Slackware that I can build Trinity is 13.1. In bug report 1741 I shared my attempts at building Trinity in Slackware 12.2 and 13.0. Ignoring cmake, newer versions of several upstream packages need to be backported to build Trinity in Slackware 12.2 or 13.0. Trinity builds in Slackware 13.1 just fine. Slackware 13.1 was released with cmake 2.8.1. If we establish cmake 2.8 as a minimum requirement, we then --- indirectly --- include other problematic upstream packages against which Trinity would not build. That is, any distro that came with cmake 2.8 likely did not include the older upstream packages that would be problematic for building Trinity. Darrell

1 0

Re: [trinity-devel] Minimum cmake version to compile Trinity
by Darrell Anderson 21 Dec '13

21 Dec '13

>CMakeLists.txt in tdelibs and tdebase defines 2.8. But I'm not >sure in it... may be it should be updated... Thanks, that helped! With that information, here is what I found: tdeutils/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdegraphics/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdepim/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdeartwork/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdenetwork/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdebase/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdeaddons/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdemultimedia/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdesdk/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdelibs/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdetoys/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/tdesvn/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/kgtk-qt3/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/wlassistant/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/amarok/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/konversation/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/tde-style-qtcurve/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/abakus/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/gtk-qt-engine/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/rosegarden/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/tdeio-locate/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) applications/kbfx/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) dependencies/dbus-tqt/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) dependencies/tqtinterface/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) dependencies/dbus-1-tqt/CMakeLists.txt: cmake_minimum_required( VERSION 2.8 ) tdevelop/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) tdewebdev/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) applications/tdepowersave/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) applications/knetworkmanager8/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) applications/tdenetworkmanager/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) applications/dolphin/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) applications/kpowersave/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) dependencies/arts/CMakeLists.txt: cmake_minimum_required( VERSION 2.6 ) applications/kpilot/CMakeLists.txt: cmake_minimum_required(VERSION 2.4.4) applications/kile/src/CMakeLists.txt: CMAKE_MINIMUM_REQUIRED( VERSION 2.4.4 FATAL_ERROR ) For consistency, should the modules requiring 2.6 or 2.4.4 be updated to 2.8? Darrell

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels December 2013