tde-devels

devels@trinitydesktop.org

3836 discussions

Preparing v3.5.13.1
by Slávek Banko 19 Jun '12

19 Jun '12

Hi, It's been a long time since I announced the current status of preparation 3.5.13.1. As you probably know, the process is not stopped. Not only was it incorporated many other patches, but it was set up branch in the GIT, in which patches were included. In the GIT so you can see some modules with branch v3.5.13-sru. Because packages in my PPA include not only commits cherry picked from GIT, but some patches "cherry picked" from Bugzilla, I would like to open discussion about these patches: + kdelibs -- Fix Konqueror file pane updates http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=756 -- Fix mimetype detection is incorrect, some files appear as Unknown http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=656 + kdepim -- [kmail] fixed composer crash http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=953 + kdeutils -- [klaptodaemon] removes dpkg commands http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/kdeutils/kdeut… All these patches are for some time already part of prepared v3.5.13.1, so are some time tested by users. I propose to push them into the GIT. What do you think? Slavek --

3 3

Corrupt image files in gwenview sources
by Darrell Anderson 18 Jun '12

18 Jun '12

There are 6 png and 2 svg files in applications/gwenview/src/gvdirpart. All png files are unviewable. I can restore the 6 png images from the original 1.4.2 sources. The difference with the png images is one byte in file size, so probably some kind of CR/LF copy error. I have pushed those 6 fixes to GIT. One of the svg files won't open in gwenview, in Trinity GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview. I can open the suspect svg in karbon and resave but before I push that copy I'd be grateful if one of the artists here would look at the file: applications/gwenview/src/gvdirpart/crsc-app-gvdirpart.svg I can open the suspect svg in a text editor. Thanks again! Darrell

5 11

Suspect debugging symbols
by Darrell Anderson 18 Jun '12

18 Jun '12

I notice in my kcrash backtrace captures that sometimes I see references to files in "dev/shm." That is the location for tmpfs/$TMP on my system, where I build packages. Are those "dev/shm" references normal or am I doing something wrong with creating my debugging symbol packages? Thanks much. Darrell

2 7

tdesdk/kbugbuster FTBFS
by Darrell Anderson 17 Jun '12

17 Jun '12

I am unable to build kbugbuster in tdesdk. I realize kbugbuster is more or less broken but we should still be able to build. I can build tdesdk in one of two ways: * -DBUILD_KBUGBUSTER=OFF * Reversing GIT patches b04ab117 and 629e2283, both from 03-27-2012. The failure is being unable to find the libkcal headers installed by tdepim. Those headers are installed in $PREFIX/include/libkcal, as seen in tdepim/libkcal/CMakeLists.txt: DESTINATION ${INCLUDE_INSTALL_DIR}/libkcal. Therefore reversing the two patches in GIT seems the correct way to fix this. Comments? Objections? Darrell

1 0

TDE naming inconsistencies and kdm-trinity
by David Hare 17 Jun '12

17 Jun '12

Some of you may know of "smxi" which is a set of administration scripts for Debian going back a number of years. Originating from the sidux project, smxi is well-known and repected among Debian (particularly testing/sid) users. I recently requested on smxi forum http://techpatterns.com/forums/about2131-10.html for kdm-trinity to be added to the list of supported display managers. The scripts autodetect the default DM so it can stop/start it when nececcary. The admin was happy to do so, however it did not work as expected because of TDE naming inconsistencies and the DM executable being in other than /usr/bin $ which kdm /opt/trinity/bin/kdm $ ls /etc/init.d | grep kdm kdm-trinity $ cat /etc/X11/default-display-manager /opt/trinity/bin/kdm I would like to draw attention to this, as I am sure TDE would be more widely accepted if more general standards were followed (however, I know the team is already working in this area)

4 6

tdenetwork FTBFS with latest GIT
by Darrell Anderson 17 Jun '12

17 Jun '12

tdenetwork built without error on 6/14. Now fails to build. [ 40%] Building CXX object kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o cd /dev/shm/tdenetwork.build/kopete/protocols/groupwise/libgroupwise && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/trinity/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/dev/shm/tdenetwork.build/kopete/protocols/groupwise/libgroupwise -I/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise -I/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/qca/src -I/dev/shm/tdenetwork/kopete/libkopete -I/opt/trinity/include -I/usr/include/tqt -fPIC -o CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o -c /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp In file included from /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:43: /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: expected ')' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: expected ')' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: ISO C++ forbids declaration of 'TLS' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: ISO C++ forbids declaration of 'SASL' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: expected ';' before '*' token In file included from /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:48: /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.h:38: warning: 'typedef' was ignored in this declaration /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: ISO C++ forbids declaration of 'TLS' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp: In constructor 'ClientStream::Private::Private()': /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:78: error: 'tls' was not declared in this scope make[2]: *** [kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/tdenetwork.build' make[1]: *** [kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/tdenetwork.build' make: *** [all] Error 2 This is a clean build from scratch, against TQt3, just like 6/14. Everything else builds. There are no tdenetwork patches in the last 18 hours. tdenetwork will build with the following: -DBUILD_KOPETE_PROTOCOL_GROUPWISE=OFF -DBUILD_KOPETE_PROTOCOL_JABBER=OFF Darrell

2 2

svg - artifact issue
by David C. Rankin 17 Jun '12

17 Jun '12

All, After tweaking the go.svg file a couple of days ago Darrell mentioned that when rendered in TDE, the svg file showed artifacts which I couldn't explain as the original inkscape file looked fine. Long story short, I was using konqueror file manager on a suse box (3.5.10 on opensuse 11.4) and I noticed black artifacts in an svg file preview. Here is a screenshot of the actual svg file in inkscape: http://www.3111skyline.com/dl/dt/trinity/ss/svg-artifact-error-2.jpg Here is the preview in konqueror (3.5.10) http://www.3111skyline.com/dl/dt/trinity/ss/svg-artifact-error-1.jpg The svg file had a black fill on the rectangle below the image, so I changed it to white to see if that made any difference on the artifact -- it didn't. Here is a link to the svg file itself: http://www.3111skyline.com/dl/dt/trinity/ss/firstTest.svg So, it looks like there is something that KDE did not handle correctly in svg preview that now shows up in TDE as well. I have no clue where to go with this, but I would like to start with asking "Has anyone else seen this type of artifact with svg files?" Then "does anybody have any experience working with svg file rendering in KDE/TDE who would know what part of the code is responsible for generating the svg previews?" What say the graphic file format wizards on the list? What is going on in these images? Is it a svg format change causing problems with old rendering code or what? Obviously this isn't a blocker type issue, but right now, I don't know enough about it to author an intelligent bug report... -- David C. Rankin, J.D.,P.E.

3 7

amarok FTBFS with latest GIT
by Darrell Anderson 16 Jun '12

16 Jun '12

amarok built without error on 6/14. Now fails to build. Scanning dependencies of target amarokcore-static make[2]: Leaving directory `/dev/shm/amarok.build' make -f amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/build.make amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/build make[2]: Entering directory `/dev/shm/amarok.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/amarok.build/CMakeFiles [ 1%] Building CXX object amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/amarokdcopiface_skel.cpp.o cd /dev/shm/amarok.build/amarok/src/amarokcore && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/trinity/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/dev/shm/amarok.build/amarok/src/amarokcore -I/dev/shm/amarok/amarok/src/amarokcore -I/dev/shm/amarok.build -I/dev/shm/amarok/amarok/src -I/dev/shm/amarok/amarok/src/statusbar -I/opt/trinity/include -I/usr/include/tqt -I/usr/include/taglib -fPIC -o CMakeFiles/amarokcore-static.dir/amarokdcopiface_skel.cpp.o -c /dev/shm/amarok.build/amarok/src/amarokcore/amarokdcopiface_skel.cpp /usr/bin/cmake -E cmake_progress_report /dev/shm/amarok.build/CMakeFiles [ 1%] Building CXX object amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/amarokdcophandler.cpp.o cd /dev/shm/amarok.build/amarok/src/amarokcore && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/trinity/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/dev/shm/amarok.build/amarok/src/amarokcore -I/dev/shm/amarok/amarok/src/amarokcore -I/dev/shm/amarok.build -I/dev/shm/amarok/amarok/src -I/dev/shm/amarok/amarok/src/statusbar -I/opt/trinity/include -I/usr/include/tqt -I/usr/include/taglib -fPIC -o CMakeFiles/amarokcore-static.dir/amarokdcophandler.cpp.o -c /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp: In member function 'virtual bool Amarok::DcopScriptHandler::runScript(const TQString&)': /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:914: error: 'ScriptManager' has not been declared /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp: In member function 'virtual bool Amarok::DcopScriptHandler::stopScript(const TQString&)': /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:919: error: 'ScriptManager' has not been declared /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp: In member function 'virtual TQStringList Amarok::DcopScriptHandler::listRunningScripts()': /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:924: error: 'ScriptManager' has not been declared make[2]: *** [amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/amarokdcophandler.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/amarok.build' make[1]: *** [amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/amarok.build' make: *** [all] Error 2 This is a clean build from scratch, against TQt3, just like 6/14. Everything else builds. There are no amarok patches in the last 18 hours. Darrell

1 0

Getting a stacktrace from systemsettings with the Ubuntu packages
by Julius Schwartzenberg 16 Jun '12

16 Jun '12

With the nightly packages, systemsettings crashes here. I can't seem to generate a proper stack trace however. Is there a -dbg package I can install to let it create a proper stack trace? Best regards, Julius

4 18

Latest R14 XDG updates
by Darrell Anderson 16 Jun '12

16 Jun '12

The latest starttde update and new r14-xdg-update script were pushed to GIT in hashes 6ebf92cb and 5464fc6f. All changes revolve around R14 XDG compliance updates. I figured pushing to GIT was easier for folks to test rather than post as attachments to a bug report. I moved the R14 XDG compliance updates to a new script named r14-xdg-update. In the GIT sources the new script is added to tdebase/r14-xdg-update and is installed to $PREFIX/bin, just like starttde. The new script can be run stand-alone. starttde now calls this new script rather than perform the updates directly. I updated the migratekde3 profile migration shell script in bug report 709 and pushed in GIT hash 6ebf92cb. In the GIT sources the migratekde3 script is added to tdebase/migratekde3 and is installed to $PREFIX/bin, just like starttde. This script is a stand-alone script and is not run anywhere automatically. Compared to the initial XDG update snippets in starttde, the new r14-xdg-update script performs the following: * Error checking against sym linked profile directories (a corner case but needed). * Usage of a verbose X message box to warn about a sym linked profile directory, why an R14 XDG compliance update will not occur, what fails to function properly because of that missing update, and possible remedies available for the user. * When run directly from the command line, r14-xdg-update asks the user to automatically break the sym link, and then will ask whether to migrate a KDE3 profile. * Nominal validation tests that the XDG updates succeeded. When failures are detected then an X message box appears for each type of failure, thereby informing the user specifically what needs repair. * Supporting a command line parameter named "force" that allows users/administrators to run the r14-xdg-update script even when the kdeglobals Updated key value is set to true. * Fixed a few bugs found along the way. * If all goes well, then the user sees nothing and everything should just work. I have been testing all afternoon. :-) Everything is more robust, but I won't pretend I anticipated all usage methods or corner cases or that I found all bugs or did not introduce new bugs. I have not yet added anything related to test the XDG updating against administratively locked files and directories. I am open to suggestions. I need to review the specifications of what can be locked in a Trinity profile and how that likely affects the XDG updates. There are some "TODO" notes in the new r14-xdg-update script. Please help with testing and to improve the scripts! Darrell

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels