tde-devels

devels@trinitydesktop.org

3 participants
3808 discussions

March Meeting
by Robert Xu 21 Mar '12

21 Mar '12

Forgive me for not bringing this up earlier. We invite everyone to attend the March Meeting on IRC (irc.freenode.net, #trinity-desktop-meeting). It will take place on 25 March 2012, at 1200 EST (that's 1600 for my friends in London, and 1100 for Central Time). If you cannot make it, or you are busy, please let me know ASAP so that I can change the date or time. You may also leave topics to be discussed with any opinions or such. And this is also a friendly reminder that Etherpad still exists (etherpad.trinitydesktop.org). Thanks, Robert Xu

3 6

Updating bugzilla
by Darrell Anderson 21 Mar '12

21 Mar '12

I would like us to improve our bug report triage efforts. If you filed bug reports related to build issues, please consider updating them as follows: * Any package that fails to build from source (FTBFS), change to Blocker P1. Ensure the acronym FTBFS is in the description. * Any package that builds without failure but requires work-arounds or nominal patching, change to Critical P1. * Any package that builds without failure but builds incompletely, such as missing components, or causes other problems, change to Major P1. Thanks! Darrell

1 0

gtk-qt-engine KDE -> TDE issues + patch to push
by David C. Rankin 21 Mar '12

21 Mar '12

Tim, Darrell, applications-gtk-qt-engine had KDE -> TDE issues. See: http://www.3111skyline.com/dl/dt/trinity/ss/gtk-styles-kde-fix.jpg The patch file K2T.patch corrects this issue. I just need someone to push it. Let me know if we need a bug report, otherwise, you can just add it to the GIT code. -- David C. Rankin, J.D.,P.E.

3 3

xorg 1.12 - All Apps Work! Seems to be limited to Init of Desktop
by David C. Rankin 20 Mar '12

20 Mar '12

Tim, All, I've started another thread as I think I have narrowed down the problem I'm having with TDE on xorg 1.12 to just the initializing of the TDE desktop. As a test, I launched all the TDE apps that I normally use in fluxbox running on xorg 1.12 -- they all work! Have a look: http://www.3111skyline.com/dl/dt/trinity/ss/tde-in-flux.jpg So the tde failure on xorg 1.12 seems to be limited to the initialization process when the splash screen is running (ksplash maybe?). What I need is to identify what is running when the crash occurs to help narrow it down. I'm not familiar with the 'startup sequence' so it would help if somebody who know could chime in. The best I can describe the point at which the crash occurs is this: The splash screen gets to the 'hard drive icon' (Initializing system services) chugs away for a while and then crashes. I also notice that during this part of the startup, there is no background image shown as it was originally. Now only a light-blue desktop color is shown. Can somebody help fill in the list of potential processes running at this point so I can take a look? I can think of one to add: List of potential processes: ksplash What else is running at this point in time? -- David C. Rankin, J.D.,P.E.

3 6

knetworkmanager8 - patched QCString -> TQCString bug, now get TQCString error in SlotActivate()
by David C. Rankin 20 Mar '12

20 Mar '12

Tim, Darrell, Fixing knetworkmanager8, I patched the first QString reference that was causing the build failure with: --- knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-wireless_menuitem.cpp +++ knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-wireless_menuitem.cpp 2012-03-20 00:55:13.388877442 -0500 @@ -74,7 +74,7 @@ { kdDebug() << "Activate Connection " << _conn->getObjectPath().data() << " on Device " << _dev->getObjectPath().ascii() << endl; #if NM_CHECK_VERSION(0,8,992) - if (!nm->ActivateConnectionAsync(id, "org.freedesktop.NetworkManagerUserSettings", _conn->getObjectPath(), TQT_DBusObjectPath(QCString(_dev->getObjectPath())), _conn->getObjectPath(), err)) + if (!nm->ActivateConnectionAsync(id, "org.freedesktop.NetworkManagerUserSettings", _conn->getObjectPath(), TQT_DBusObjectPath(TQCString(_dev->getObjectPath())), _conn->getObjectPath(), err)) #else if (!nm->ActivateConnectionAsync(id, NM_DBUS_SERVICE_USER_SETTINGS, _conn->getObjectPath(), TQT_DBusObjectPath(TQCString(_dev->getObjectPath())), _conn->getObjectPath(), err)) #endif This solved the error: [ 75%] Building CXX object knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-wireless_menuitem.cpp.o cd /build/src/build/knetworkmanager-0.8/src && /usr/bin/c++ -Dtdeinit_knetworkmanager_shared_EXPORTS -DHAVE_CONFIG_H -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -fPIC -I/build/src/build/knetworkmanager-0.8/src -I/build/src/build -I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -I/opt/trinity/include/dbus-1-tqt -I/usr/include/NetworkManager -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -UQT_NO_ASCII_CAST -o CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-wireless_menuitem.cpp.o -c /build/src/knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-wireless_menuitem.cpp /build/src/knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-wireless_menuitem.cpp: In member function 'void WirelessNetworkItem::slotActivate()': /build/src/knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-wireless_menuitem.cpp:77:160: error: 'QCString' was not declared in this scope make[2]: *** [knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-wireless_menuitem.cpp.o] Error 1 make[2]: Leaving directory `/build/src/build' make[1]: *** [knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/all] Error 2 make[1]: Leaving directory `/build/src/build' make: *** [all] Error 2 The next error encountered after the patch was: [ 75%] Building CXX object knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-menuitem.cpp.o cd /build/src/build/knetworkmanager-0.8/src && /usr/bin/c++ -Dtdeinit_knetworkmanager_shared_EXPORTS -DHAVE_CONFIG_H -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -fPIC -I/build/src/build/knetworkmanager-0.8/src -I/build/src/build -I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -I/opt/trinity/include/dbus-1-tqt -I/usr/include/NetworkManager -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -UQT_NO_ASCII_CAST -o CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-menuitem.cpp.o -c /build/src/knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-menuitem.cpp /build/src/knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-menuitem.cpp: In member function 'void NetworkMenuItem::slotActivate()': /build/src/knetworkmanager8/knetworkmanager-0.8/src/knetworkmanager-menuitem.cpp:99:163: error: 'QCString' was not declared in this scope make[2]: *** [knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-menuitem.cpp.o] Error 1 make[2]: Leaving directory `/build/src/build' make[1]: *** [knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/all] Error 2 make[1]: Leaving directory `/build/src/build' make: *** [all] Error 2 I attempted to patch the TQString -> TQCString consistent with the earlier patch -- but that obviously failed. I have grepped QCString and TQString looking at the declarations, but I am over my c++ multi-inheritance limit at this point. Can someone point me in the right direction to correct the QCString error. Admittedly, my first attempt may have caused the second error, so can someone confirm the first patch as well. Thanks. -- David C. Rankin, J.D.,P.E.

2 3

Anyone building and running on X.Org server 1.12?
by David C. Rankin 20 Mar '12

20 Mar '12

Guys, I am still troubleshooting a few issues with X.Org version 1.12. Is there anyone else building and running on this version of xorg-server? I have updated virtualbox to 4.1.10 (compiled for xorg 1.12) and fluxbox runs flawlessly, but when starting TDE it hangs and crashes on "Initializing System Services" (the 2nd icon in the splash). The Xorg.O.log is clean, so I'm scratching my head. There are no other logs (.xsession-errors, etc..) in ~/. Does TDE generate other logs that might be of use? I'll try another complete rebuild since the packages are from 3/18 and 3/19 (old). I'll report back after that. In the mean time, if you have any other thoughts, please let me know. Thanks. -- David C. Rankin, J.D.,P.E.

2 3

Howto handle differing versions of libtool in TDE builds
by David C. Rankin 20 Mar '12

20 Mar '12

Tim, Serghei, Darrell, What are your thoughts on how we should handle differing versions of libtool/auto... with tde building? The tdeutils build failure has really brought this to light. libtool 2.4.2-4 in Arch contains parsing functions that do not exist in the libtool version in tde GIT that causes the libtool process to attempt to use variable that are uninitialized and not declared resulting in build failures. For tdeutils the build fails with the call to "$to_host_file_cmd $1". The to_host_file_cmd isn't part of libtool in TDE. Evidently, the new libtool tries to call to_host_file_cmd on every source it compiles. Since to_host_file_cmd is not defined anywhere -- it bombs. The file name to toolchain parsing functions are at the end of the arch libtool.m4 file: <snip> to_host_file_cmd=$lt_cv_to_host_file_cmd AC_MSG_RESULT([$lt_cv_to_host_file_cmd]) _LT_DECL([to_host_file_cmd], [lt_cv_to_host_file_cmd], [0], [convert $build file names to $host format])dnl AC_MSG_CHECKING([how to convert $build file names to toolchain format]) AC_CACHE_VAL(lt_cv_to_tool_file_cmd, [#assume ordinary cross tools, or native build. lt_cv_to_tool_file_cmd=func_convert_file_noop case $host in *-*-mingw* ) case $build in *-*-mingw* ) # actually msys lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32 ;; esac ;; esac ]) to_tool_file_cmd=$lt_cv_to_tool_file_cmd AC_MSG_RESULT([$lt_cv_to_tool_file_cmd]) _LT_DECL([to_tool_file_cmd], [lt_cv_to_tool_file_cmd], [0], [convert $build files to toolchain format])dnl ])# _LT_PATH_CONVERSION_FUNCTIONS I guess the question is "does the libtool in tde need to be updated?" ..or.. is there some way to just to bypass the version inconsistency? It might be arch that is having issues today, but it will be the remainder of the distros that have the issue after a libtool update. I have tried several times to get familiar with cmake conversion, but as of today, I don't have the tools to tackle something like tdeutils. I don't know if that would provide a better solution than trying to fix libtool or how much work that would be. What are the thoughts of the experts? -- David C. Rankin, J.D.,P.E.

3 4

Rosegarden builds on Arch
by David C. Rankin 20 Mar '12

20 Mar '12

Just a status for the Arch folks, Rosegarden builds fine from GIT. I've updated the latest PKGBUILD source .tar.gz files. You can grab them at: http://www.3111skyline.com/dl/dt/tde/src/ The current list of dependencies and TDE packages available are listed below. Note: tdeutils, avahi-tqt and amarok are not building. The remainder build with the current GIT sources: antlr3.tar.gz hal-info.tar.gz hal.tar.gz libantlr3c.tar.gz libkarma.tar.gz libmtp-git.tar.gz libnjb.tar.gz libutempter.tar.gz python-daap.tar.gz tde-amarok.tar.gz tde-arts.tar.gz tde-avahi-tqt.tar.gz tde-dbus-1-tqt.tar.gz tde-dbus-tqt.tar.gz tde-dolphin.tar.gz tde-gtk-qt-engine.tar.gz tde-kio-locate.tar.gz tde-kpowersave.tar.gz tde-libart-lgpl.tar.gz tde-libcaldav.tar.gz tde-libcarddav.tar.gz tde-rosegarden.tar.gz tde-tdeartwork.tar.gz tde-tdebase.tar.gz tde-tdegraphics.tar.gz tde-tdelibs.tar.gz tde-tdemultimedia.tar.gz tde-tdenetwork.tar.gz tde-tdepim.tar.gz tde-tdesdk.tar.gz tde-tde-style-qtcurve.tar.gz tde-tdesvn.tar.gz tde-tdeutils.tar.gz tde-tdevelop.tar.gz tde-tdewebdev.tar.gz tde-tqca-tls.tar.gz tde-tqt3.tar.gz tde-tqtinterface.tar.gz yauap.tar.gz -- David C. Rankin, J.D.,P.E.

1 0

kpowersave - /usr/bin/ld: cannot find -ldbus-tqt-1
by David C. Rankin 20 Mar '12

20 Mar '12

Tim, Darrell, Other than a few hiccups, the build with tqtinterface and libart_lgpl in /usr has run fairly smooth. I did just run into another issue with kpowersave at 96% which looks like another ldconfig issue. The problem here is I didn't have any ldconfig or issues with kpowersave prior to the tqtinterface move to /usr. Is there something we can do with cmake that will help prevent the "I can't find the library issue?" The failure is libdbus-tqt-1 and it is in the same location it has been all along with correct package config information: [23:44 nirvana:/mnt/nv1/home/chroot/david/opt/trinity/lib/pkgconfig] # cat dbus-1-tqt.pc prefix=/opt/trinity exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include/dbus-1-tqt Name: dbus-tqt Description: DBUS bindings for the Trinity Qt [TQt] interface Version: 0.9.0 Libs: -L${libdir} -ldbus-1-tqt Cflags: -I${includedir} [23:44 nirvana:/mnt/nv1/home/chroot/david/opt/trinity/lib/pkgconfig] # cat dbus-tqt.pc prefix=/opt/trinity exec_prefix=${prefix} libdir=${prefix}/lib includedir=${prefix}/include Name: dbus-tqt-1 Description: D-BUS TQt bindings Version: 0.7 Requires: dbus-1 Libs: -L${libdir} -ldbus-tqt-1 -ldbus-1 -lpthread -lrt Cflags: -I${includedir} -I${includedir}/dbus-1.0 (NOTE: why is the package name dbus-tqt, while the pkg-config 'Name: dbus-tqt-1'? Could this be causing the error?) Further, below, the error shows that -L/opt/tqt3/lib is pull in before the dbus-tqt 'Libs:' string instead of /opt/trinity/lib specified in the dbus-tqt.pc file (above): -L/opt/tqt3/lib -ldbus-tqt-1 -ldbus-1 -lpthread -lrt / ^^^^^^^^^^^^^^^ <according to the dbus-tqt.pc it should be:> -L/opt/trinity/lib -ldbus-tqt-1 -ldbus-1 -lpthread -lrt / ^^^^^^^^^^^^^^^^^^ But the error I get says it getting '-L/opt/tqt3/lib -ldbus-tqt-1': [ 96%] Building CXX object src/CMakeFiles/tdeinit_kpowersave-shared.dir/suspend_Dialog.cpp.o cd /build/src/build/src && /usr/bin/c++ -Dtdeinit_kpowersave_shared_EXPORTS -DHAVE_CONFIG_H -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -fPIC -I/build/src/build/src -I/build/src/build -I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -I/opt/trinity/include/dbus-1.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/hal -o CMakeFiles/tdeinit_kpowersave-shared.dir/suspend_Dialog.cpp.o -c /build/src/build/src/suspend_Dialog.cpp Linking CXX shared library libtdeinit_kpowersave.so cd /build/src/build/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/tdeinit_kpowersave-shared.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -Wl,--no-undefined -shared -Wl,-soname,libtdeinit_kpowersave.so -o libtdeinit_kpowersave.so CMakeFiles/tdeinit_kpowersave-shared.dir/dummy.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/autodimm.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/autosuspend.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/blacklistedit_Dialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/blacklisteditdialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/configure_Dialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/configuredialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/countdown_Dialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/countdowndialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/dbusHAL.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/detailed_Dialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/detaileddialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/hardware.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/hardware_battery.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/hardware_batteryCollection.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/hardware_cpu.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/inactivity.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/info_Dialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/infodialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/kpowersave.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/kpowersave_skel.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/log_viewer.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/logviewer.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/main.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/screen.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/settings.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/suspenddialog.cpp.o CMakeFiles/tdeinit_kpowersave-shared.dir/suspend_Dialog.cpp.o -L/opt/tqt3/lib -ldbus-tqt-1 -ldbus-1 -lpthread -lrt /opt/trinity/lib/libkio.so.4.2.0 -lhal -lXext -lXtst -lXss /opt/trinity/lib/libtdeui.so.4.2.0 -lfreetype -lfontconfig /opt/trinity/lib/libtdesu.so.4.2.0 -lutil /opt/trinity/lib/libkwalletclient.so.1.0.1 /opt/trinity/lib/libtdecore.so.4.2.0 /opt/trinity/lib/libDCOP.so.4.2.0 /opt/trinity/lib/libtdefx.so.4.2.0 -ltqt -ltqt-mt -lXrender -lX11 -lz -lidn -lXcomposite -lICE -lSM -Wl,-rpath,/opt/tqt3/lib:/opt/trinity/lib: /usr/bin/ld: cannot find -ldbus-tqt-1 collect2: ld returned 1 exit status make[2]: *** [src/libtdeinit_kpowersave.so] Error 1 make[2]: Leaving directory `/build/src/build' make[1]: *** [src/CMakeFiles/tdeinit_kpowersave-shared.dir/all] Error 2 make[1]: Leaving directory `/build/src/build' make: *** [all] Error 2 Looking at the -ldbus-tqt-1 designation - it is one of the few that does not have the full path information. Where is that supposed to come from if not from the pkg-config results? The pkg-config lib results are correct, so what's up? -- David C. Rankin, J.D.,P.E.

3 12

Updating ktorrent 2.2.6 -> 2.2.8
by Darrell Anderson 20 Mar '12

20 Mar '12

I have a patch available to update ktorrent from 2.2.6 to 2.2.8. The patch is available in bug report 363 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=363). The patch is in tar.gz format because the bug tracker won't allow a patch larger than 1MB. Patch created by comparing original 2.2.6 to 2.2.7 sources and then original 2.2.7 to 2.2.8 sources. Then adjusted for TQt layer. According to the ktorrent change log, there were only a few patches from 2.2.6 to 2.2.8. The attached patch matches those change log descriptions. With the patch ktorrent builds with no failures on Slackware 13.1. I would be grateful if other users would test the patch. If no further problems then I'll push to GIT. :) Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels