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
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
Most/all of the command line executables in Trinity have no man pages. Seems some people have provided man pages, such as the Ubuntu people.
Are there any licensing or ethical objections to us grabbing such man pages for Trinity?
Darrell
Bug report 872 is resolved. All tdesdk components now build without error when building with cmake.
Building with automake should no longer be required.
Please update build scripts and test! :-)
Darrell
The splash images for digikam and showFoto need updating from KDE -> TDE, at the bottom of each image:
GIT locations:
applications/digikam/digikam/data/pics/digikam-splash.png
applications/digikam/digikam/showfoto/pics/showfoto-splash.png
Possibly each respective xcf file too, but I can't open them here with anything.
Thank you again!
Darrell
Tim,
I traced the build failure to a Debian patch from Debian bug report 357775. The specific patch is 11_fix_get_libdir_name.diff, which can be viewed here, about midpoint in the page:
http://lists.alioth.debian.org/pipermail/pkg-kde-commits/2006-June/003702.h…
I reversed the patch and then was able to build on 64-bit. Ignoring obvious file size differences, my 64-bit package looks exactly the same as my 32-bit package.
In my patch I added some informational text to help debugging because the specific build failure message appears in three different locations. Here is my proposed patch:
===========================================================
diff -urN pytdeextensions/setup.py pytdeextensions.new/setup.py
--- pytdeextensions/setup.py 2012-05-27 17:59:26.000000000 -0500
+++ pytdeextensions.new/setup.py 2012-06-13 20:12:18.000000000 -0500
@@ -135,7 +135,7 @@
if self.clib!=None:
self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0]
if self.clib is None:
- raise SystemExit, "Failed to find a suitable libgcc library"
+ raise SystemExit, "setup.py: Failed to find a suitable libgcc library"
self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules
diff -urN pytdeextensions/src/kdedistutils.py pytdeextensions.new/src/kdedistutils.py
--- pytdeextensions/src/kdedistutils.py 2012-06-13 11:01:28.000000000 -0500
+++ pytdeextensions.new/src/kdedistutils.py 2012-06-13 20:17:43.000000000 -0500
@@ -660,7 +660,7 @@
if self.clib!=None:
self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0]
if self.clib is None:
- raise SystemExit, "Failed to find a suitable libgcc library"
+ raise SystemExit, "kdedistutils.py (1): Failed to find a suitable libgcc library"
self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules
@@ -1591,7 +1591,7 @@
if self.clib!=None:
self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0]
if self.clib is None:
- raise SystemExit, "Failed to find a suitable libgcc library"
+ raise SystemExit, "kdedistutils.py (2): Failed to find a suitable libgcc library"
self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules
@@ -2229,7 +2229,7 @@
###########################################################################
def get_libdir_name():
- #if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
- # return 'lib64'
- #else:
+ if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
+ return 'lib64'
+ else:
return 'lib'
===========================================================
Do you want me to push this patch to GIT or do you want to first run a Debian/Ubuntu test build?
Darrell
I built and installed tde-systemsettings. I can't get the app to run and thus can't validate whether the likely patche set I created is needed. Hopefully the package is not distro-specific and can be installed on Slackware.
Here is a backtrace of systemsettings, when run from the mini cli, built and installed as-is:
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5 0x0805be69 in TQValueList<RowIconView*>::detach (this=0x8c)
at /opt/trinity/include/ntqvaluelist.h:566
#6 0x0805c0b2 in TQValueList<RowIconView*>::operator[] (this=0x8c, i=0)
at /opt/trinity/include/ntqvaluelist.h:540
#7 0x0805b763 in KcmSearch (this=0x80f8b00, moduleViewList=0x80ecbfc,
parent=0x80f86b0, name=0x8065509 "search") at kcmsearch.cpp:31
#8 0x08061610 in MainWindow::buildActions (this=0x80ecb28)
at mainwindow.cpp:129
#9 0x0806271d in MainWindow (this=0x80ecb28, embed=true, menuFile=...,
parent=0x0, name=0x0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at mainwindow.cpp:65
#10 0x080601e5 in main (argc=7, argv=0xbfc48114) at main.cpp:56
Here is a backtrace of systemsettings, when run from the mini cli, built and installed after patching with potential XDG patching (same backtrace, which indicates the lack of patching is not the likely cause):
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5 0x0805be69 in TQValueList<RowIconView*>::detach (this=0x8c)
at /opt/trinity/include/ntqvaluelist.h:566
#6 0x0805c0b2 in TQValueList<RowIconView*>::operator[] (this=0x8c, i=0)
at /opt/trinity/include/ntqvaluelist.h:540
#7 0x0805b763 in KcmSearch (this=0x80f8bd8, moduleViewList=0x80ed07c,
parent=0x80f8788, name=0x8065509 "search") at kcmsearch.cpp:31
#8 0x08061610 in MainWindow::buildActions (this=0x80ecfa8)
at mainwindow.cpp:129
#9 0x0806271d in MainWindow (this=0x80ecfa8, embed=true, menuFile=...,
parent=0x0, name=0x0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at mainwindow.cpp:65
#10 0x080601e5 in main (argc=7, argv=0xbff685f4) at main.cpp:56
Darrell
I just updated to the latest nightlies and it seems quite a lot broke
because of it.
What I've seen so far (after logging out & back in):
- Errors about TDE's media manager not running
- This error when trying to run Konqueror:
There was an error loading the module Detailed List View.
The diagnostics is:
Library files for ".la" not found in paths.
- alt+f2, does not allow executing scripts from ~/bin anymore (probably
the PATH variable doesn't get set correctly anymore)
- entering ~ (or clicking the home button in Konqueror) gives this error:
Malformed URL
~
All these things were working correctly with the nightlies as updated
till yesterday.
The previous issues I reported are still there.
Best regards,
Julius