tde-devels

devels@trinitydesktop.org

3 participants
3808 discussions

Build error: kdewebdev svn
by Baho Utot 08 Mar '11

08 Mar '11

Checked out revision 1224111. ==> SVN checkout of revision 1224111 -- Complete. Scanning dependencies of target utility-static [ 10%] Building CXX object quanta/utility/CMakeFiles/utility-static.dir/quantacommon.cpp.o [ 10%] Building CXX object quanta/utility/CMakeFiles/utility-static.dir/tagaction.cpp.o /build/src/kdewebdev/quanta/utility/tagaction.cpp:1285:25: fatal error: myprocess.moc: No such file or directory compilation terminated. make[2]: *** [quanta/utility/CMakeFiles/utility-static.dir/tagaction.cpp.o] Error 1 make[1]: *** [quanta/utility/CMakeFiles/utility-static.dir/all] Error 2 make: *** [all] Error 2 Aborting... Build is out of source in a separate build directory Any idea? Thanks

4 4

Some Encouraging Words
by Darrell Anderson 08 Mar '11

08 Mar '11

I realize everybody involved here is busy in one way or another. I appreciate all efforts. Despite my recent impatience, Trinity is my hope for a usable desktop environment in free/libre software. For the past several days I have been exploring Xfce and KDE4 as desktop alternatives. (I never have been a Gnome person.) Just exploring the option because I never used either in any meaningful fashion. I find myself repeatedly agitated and frustrated by both desktops. A desktop should never get in the user's way. Ever. Xfce is impotent. Simple configuration options such as setting the menu to include descriptions or disabling tool tip popups are either impossible or must be performed with a text editor. KDE4 is a nightmare of complexity that a significant number of everyday users never will need or even fathom. Trinity has an opportunity to be a splendid desktop for the masses. I realize much work remains to port the Trinity build process to cmake. There also is a large list of bugs that need quashing. I will do what I can to build and test packages. I will continue waddling along the next few months until the cmake transition is complete and a major bug quashing effort occurs. Yet I hope in a few month's time I find myself tickled pink from using Trinity 3.5.13. With the major effort in cmake, Trinity should remain usable and buildable for a long time. I hope Trinity becomes successful. To those of you involved in this process, please keep up the good work! :) And thank you! Darrell

3 5

Chroot
by Darrell Anderson 08 Mar '11

08 Mar '11

Can newer releases of a distro be run in a chroot from within an older release? What problems will occur? I'm running Slackware 12.2, mostly because that was the last release supporting KDE 3.5.10. I run my Trinity builds in a chroot. I would like to start Trinity build testing for the most recent Slackware release. I can run newer releases in a virtual machine, but I find virtual machines much slower than the chroot. Thanks. Darrell

4 3

Testing Bug Fixes
by Darrell Anderson 07 Mar '11

07 Mar '11

In light of the hopeful bug quashing in the next week or two, are most people able to build the 20 or so svn core packages (with either cmake or automake)? Would seem challenging to try to test any upcoming fixes if one can't compile all of the core packages, which is where I presume most of the focus would be. Thanks. Darrell

1 0

Old/Unknown CMakeLists.txt files in svn tree
by David C. Rankin 07 Mar '11

07 Mar '11

Guys, There are current 138 CMakeLists.txt in the first 3 levels of the Trinity tree. Of that 138, the following are of unknown origin. Some say kde4 and some are from Gentoo/Mandriva. These need to be looked at: * applications/kde-systemsettings/CMakeLists.txt * applications/kpilot/CMakeLists.txt * applications/kgtk-qt3/CMakeLists.txt * applications/rosegarden/CMakeLists.txt * applications/knemo/CMakeLists.txt * applications/kdesvn/CMakeLists.txt * applications/gtk-qt-engine/CMakeLists.txt * applications/kbfx/CMakeLists.txt I have added this info to http://lincom.ietherpad.com/9? -- David C. Rankin, J.D.,P.E.

2 5

kdelibs FTBFS with cmake 2.8.4
by Darrell Anderson 07 Mar '11

07 Mar '11

I have successfully built tqtinterface and arts in Slackware 12.2 with cmake 2.8.4. Building kdelibs failed quickly: ======================================= - Looking for alsa/asoundlib.h -- Looking for alsa/asoundlib.h - found -- checking for one of the modules 'arts' -- checking for one of the modules 'openssl' -- Looking for ippDeleteAttribute in cups -- Looking for ippDeleteAttribute in cups - found -- Found Cups: /usr/lib/libcups.so CMake Error at cmake/modules/TDEMacros.cmake:20 (message): ################################################# Source for /dev/shm/kdelibs/kdecore/kaccelprivate.moc doesn't exists. ################################################# Call Stack (most recent call first): cmake/modules/TDEMacros.cmake:280 (tde_message_fatal) cmake/modules/TDEMacros.cmake:575 (tde_automoc) kdecore/CMakeLists.txt:128 (tde_add_library) -- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. ======================================= Darrell

2 1

Trinity Checklist!
by Robert Xu 07 Mar '11

07 Mar '11

Hey all, going strong! We currently have a revised and current checklist being edited and added on here: http://lincom.ietherpad.com/9 Please add on, we need to make sure we got everything! If you've added on already, go back and check! Tons of stuff has been added! Make sure to follow the pad etiquette outlined at the top. Also, we will have a meeting on #trinity-desktop-meeting sometime next week. Please mark your available times here: http://www.doodle.com/2arwhkrdzenzkzdg I will announce the definite time and date of the meeting around Thursday afternoon. A separate announcement will be made on trinity-users about a different meeting, more of a public relations one. Please do not confuse the two. Consider that one Trinity Community Day, held on irc. I still have to see when that's possible... We will do that once the new site is up, probably. -- later, Robert Xu

3 8

kdebraphics krule/kview - Unknown CMake commands?
by David C. Rankin 07 Mar '11

07 Mar '11

Guys, Here are the errors I'm getting with kdegraphics kruler and kview. I know they are both recently ported (or may be still in the process). So question (1) is: "should they be considered ready to build?" Question (2), "do I build them both independently or do I have to build the whole kdegraphics package at once?" If so (or regardless), here are the errors: trinity-kdegraphics-kruler: -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at pics/CMakeLists.txt:16 (tde_install_icons): Unknown CMake command "tde_install_icons". trinity-kdegraphics-kview: -- Detecting CXX compiler ABI info - done CMake Error at kimageviewer/CMakeLists.txt:25 (install): install FILES given no DESTINATION! CMake Error at kimageviewer/CMakeLists.txt:32 (tde_add_library): Unknown CMake command "tde_add_library". So does this just tell me - they ain't ready yet? -- David C. Rankin, J.D.,P.E.

3 7

kdepim - CMake error at ConfigureChecks.cmake:45 (string)
by David C. Rankin 07 Mar '11

07 Mar '11

Serghei, I have run across a cmake error in kdepim: -- checking for 'gpgme' CMake Error at ConfigureChecks.cmake:45 (string): string sub-command REGEX, mode REPLACE needs at least 6 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:86 (include) -- checking for 'Qt' -- Performing Test HAVE_PATCHED_QT3 -- Performing Test HAVE_PATCHED_QT3 - Success -- found patched Qt, version 3.3.8 -- checking for one of the modules 'TQt' -- checking for 'TDE' -- found 'TDE', version 3.5.13 -- Looking for inttypes.h <snip> -- checking for 'libkmime' -- ok, activated for build -- checking for 'ktnef' -- ok, activated for build -- checking for 'libkcal' -- ok, activated for build -- checking for 'libkdepim' -- ok, activated for build -- Configuring incomplete, errors occurred! Aborting... I can't wait to give it another go once you work a little bit more of your magic on it :) -- David C. Rankin, J.D.,P.E.

3 19

Bugs, bugs, bugs
by Darrell Anderson 07 Mar '11

07 Mar '11

When are bugs going to receive attention? I don't eat my own dog food. Despite some enhancements, I continue using KDE 3.5.10 rather than Trinity 3.5.12. I expended a lot of energy last autumn packaging Trinity 3.5.12 for Slackware 12.2. My personal schedule prevented further packaging efforts, but now that I again have some time, I am not motivated to package for recent releases. Why? There are many usability bugs that render Trinity frustrating. Many of which do not exist in KDE 3.5.10. I filed bug reports for all of the problems after discussing them in this list. Not a single bug I filed in the bugzilla has been touched. I don't know C++ and that frustrates me because I can't fix the problems. Some of the bugs in Trinity are carry overs from KDE3 and have existed a long time. Consider the bug of using kdeconfig as root user. Every time root uses kdeconfig, the applet creates a .kde folder in the system root directory. I have to add special lines to my rc.local to check and delete that directory. Could I use Trinity despite all the usability bugs I reported? I could but I won't. For example, the kdesu bugs I reported leave me quite frustrated. I use kdesu many times each day and that tool works as expected in KDE 3.5.10. A primary reason cited by many people for liking KDE3 is the desktop is highly configurable yet simple. No cruft like KDE4. People do not have to run a sqlite database in the background just to check email. People running KDE3 are not interested in a social or semantic desktop. Reading reviews and comments indicate overwhelmingly that many users detest Nepomuk, Strigi, and Akonadi. KDE3 is far more configurable than Xfce or LXDE without the cruft of KDE4. KDE3 can be run on more older hardware than KDE4 can ever hope. In other words, KDE3 is already a good desktop. Hence the dismay by many with the utter abandonment by the developers. Trinity brought hope to such users. Many users of Trinity and KDE 3.5.10 do not want additional bling. They want a highly configurable yet stable desktop. In other words, the immediate focus should be bug quashing. I appreciate the effort to move to a more modern build environment with cmake and interoperability with QT4. Those are good long-term goals and should continue, but I suspect those efforts have little to nothing to do with the immediacy of swatting bugs. Usability bugs are solved at the code level and not the build level. If the reason for not quashing bugs is a lack of C++ coders, then Trinity is doomed right now. My Slackware 12.2 system remains usable. Yet as time moves forward I cannot install or update certain packages because of the typical but awful lack of backwards compatibility found in free/libre software. Therefore I am facing the unpleasant decision of updating to a more recent release of Slackware. That means moving to a different desktop environment. I don't relish that decision, which is why I supported Trinity. With the lack of bug quashing my enthusiasm for Trinity has diminished. Time for the rubber to meet the road. I am studying KDE4 and preparing for a possible migration. I would rather support Trinity but I have to face reality. So do all end-users who might prefer Trinity. Packages must be readily available for end users. Other than Debian/(K)Ubuntu and Slackware 12.2, no other systems are listed as being supported. Such a short list supports the idea that Trinity is a niche product. With the release of KDE 4.5.x series, and now 4.6, some people have written that KDE4 is ready for serious usage and has surpassed KDE3 in quality. Doesn't matter whether the proclamations are true or tainted --- the typical end-user believes the statements. Regrettably, such proclamations relegate Trinity to the status of niche product and the majority of users are not going to follow. Therefore any hopes of wide scale Trinity usage is fighting windmills. The only hope for Trinity is to provide a superb product for those who choose Trinity. Long-scale survival efforts such as with cmake and QT4 support are noble efforts but does nothing to push Trinity now. End-users don't care how packages are built. They only want to download and install packages. End users have to ask themselves a basic question: is Trinity a viable choice for desktop environments? Being stable and bug-free goes a long way toward spawning interest in Trinity. As KDE4 increases in popularity and pushes Trinity further into niche product status, people will use Trinity because they do not want the massive cruft of KDE4 or the limited flexibility of Xfce and LXDE. Yet if Trinity is buggy then willingness to use Trinity disintegrates. That is now my unfortunate position. I'm willing to support this project and have proven as much in the past. Many of the build issues that were fixed to allow building on a non-Kubuntu system were a result of my testing last summer. For many weeks last summer I think Tim and I were the only ones actively working with Trinity. I single-handedly created packages for Slackware 12.2. I can continue adding value in that respect, but I can't fix bugs without a healthy understanding of C++ and the overall desktop environment. Obtaining that level of knowledge and expertise requires many months of study. I likely have stirred a hornet's nest with these comments. Yet so many bugs remaining untouched is a troubling sign. I am willing to try to package Trinity for the next Slackware release, but not until many bugs are quashed. The Ubuntu people had a project called 100 Paper Cuts. I plea for the Trinity 101 Paper Cuts Project. Darrell

5 26

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels