tde-devels August 2013

devels@trinitydesktop.org

12 participants
90 discussions

Help handbook support for tdepowersave/kpowersave
by Darrell Anderson 17 Aug '13

17 Aug '13

In commit 071d5a84 I pushed a patch to restore the Help handbook for TDEPowersave. Apparently those files got lost in the shuffle when converting to cmake. I presume the same changes are needed for KPowersave, but I don't have a HAL based system to compile KPowersave. To somebody who does and is interested in restoring the Help handbook to KPowersave, you should be able to copy the patch, modify for naming differences, and then push to git. Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 16 Aug '13

16 Aug '13

>Sorry, I'm a little confused, so, slackware doesn't have libbfq at >all or just demangle.h is missing? I don't know about "libbfq," but I suspect you meant to type "libbfd." :-) Yes, libbfd is part of Slackware binutils. As I shared previously, demangle.h is not part of Slackware 14.0 or previous releases. The next official release, 14.1, WILL contain demangle.h in the binutils package. For my own personal usage, I rebuilt binutils for Slackware 14.0 to include demangle.h. Therefore, technically, I no longer need the tdelibs patch. I nonetheless can temporarily rename or delete demangle.h to simulate the non-existence of that file and to test any such patch. The tdelibs patch remains necessary because Slackware is not alone in excluding demangle.h from binutils. Search the dev mail list archives for a previous discussion about demangle.h and affected distros. When demangle.h is not installed, the recent tdeioslave backtrace support patch in tdelibs will not compile. The tdelibs patch, and the predessor patch for tdebase, only allows compiling the modules when demangle.h is not installed in the build environment. The patches have nothing to do with the actual bactrace support. Those folks who compile without those patches merely obtain the ability to compile without demangle.h. When compiled in that manner, those users do not have any ability to produce backtraces from the affected code. Only those folks who compile with demangle.h installed have the ability to produce backtraces from the affected code. >Anyway in a day or two I'll came with a normal patch to move all >that to >kdebug.cpp and provide WITH_LIBBFD for optional linkage... + some >additional backtrace features. I don't think WITH_LIBBFD is necessary. Only an option WITH_DEMANGLE is necessary, or, in my preliminary draft patch, WITH_TDEIOSLAVE_BACKTRACE. I derived my compile option name from the previous tdebase patch, which uses WITH_KDESKTOP_LOCK_BACKTRACE. The whole purpose of this discussion is only to patch tdelibs to compile when demangle.h is not installed. Nothing more. Seems the proposed changes to my preliminary draft patch from Slavek are all that is needed. :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 16 Aug '13

16 Aug '13

>I created a patch and am compiling as I write. Here is the patch. >Please review! Slavek, The patch did not cause any build failures. Hopefully the patch is actually correct too. Now to test the crash patch.... Darrell

4 6

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 16 Aug '13

16 Aug '13

>> For that purpose there is a NDEBUG deffinition used all over the >sources. > >Hmm, it starts to get complicated :) > >And if I want to backtrace handler, but I do not want NDEBUG >because it >enables additional debugging code, that I not want in this >situation? You two are now discussing things over my head! :-) Slavek, I basically copied your original patch and modified as necessary. You do what else is necessary to satisfy yourself and everybody else. That said, the next official version of Slackware will include demangle.h in binutils, although I know some other distros still do not. I am now rebuilding binutils that came with Slackware 14.0 so I can have demangle.h and creae useful backtraces. The tdelibs configuration patch is still needed, of course, for those distros that don't. Should the default be ON or OFF? I don't know. Seems we need the backtrace abilities only for debugging. So while we debug bug report 1627, having the backtrace is nice. Once Tim resolves the cause is the backtrace ability necessary thereafter? Probably not unless we again run into the same problem with a different cause. If the default is OFF then the developer support request in the bug report will be "Please rebuild tdelibs with - DWITH_TDEIOSLAVE_BACKTRACE=ON." Just my two cents. :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 15 Aug '13

15 Aug '13

>Sorry about that guys, I only had a short time to work on the >crash bug >and therefore didn't add in the compile time checks/flags. Thanks >for cleaning this up! That's what janitors do.... :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 15 Aug '13

15 Aug '13

>As soon as I saw Tim's commit, it was clear to me that we will >need to add >such a choice. You have prepared a patch or should I do it? I created a patch and am compiling as I write. Here is the patch. Please review! ===================================== diff -urN tdelibs/CMakeLists.txt tdelibs.new/CMakeLists.txt --- tdelibs/CMakeLists.txt 2013-08-15 16:35:14.000000000 -0500 +++ tdelibs.new/CMakeLists.txt 2013-08-15 18:38:21.659877443 -0500 @@ -24,6 +24,7 @@ include( FindPkgConfig ) include( CheckIncludeFile ) +include( CheckIncludeFiles ) include( CheckSymbolExists ) include( CheckFunctionExists ) include( CheckCSourceCompiles ) @@ -94,6 +95,7 @@ OPTION( WITH_SUDO_TDESU_BACKEND "Use sudo as backend for tdesu (default is su)" OFF ) OPTION( WITH_OLD_XDG_STD "Use the pre R14.0.0 XDG standard where both TDE and KDE are recognized in desktop files" OFF ) OPTION( WITH_LZMA "Enable support for LZMA/XZ" ${WITH_ALL_OPTIONS} ) +OPTION( WITH_TDEIOSLAVE_BACKTRACE "Enable backtrace in tdeioslave exception handler" ${WITH_ALL_OPTIONS} ) OPTION( WITH_ASPELL "Enable aspell support" ${WITH_ALL_OPTIONS} ) OPTION( WITH_HSPELL "Enable hspell support" ${WITH_ALL_OPTIONS} ) diff -urN tdelibs/config.h.cmake tdelibs.new/config.h.cmake --- tdelibs/config.h.cmake 2013-08-10 16:36:57.000000000 -0500 +++ tdelibs.new/config.h.cmake 2013-08-15 18:22:48.581678444 -0500 @@ -707,6 +707,9 @@ /* Use FontConfig in tdeinit */ #cmakedefine TDEINIT_USE_FONTCONFIG 1 +/* tdeioslave backtrace */ +#cmakedefine WITH_TDEIOSLAVE_BACKTRACE 1 + /* Use Xft preinitialization in tdeinit */ #cmakedefine TDEINIT_USE_XFT 1 diff -urN tdelibs/tdeio/tdeio/CMakeLists.txt tdelibs.new/tdeio/tdeio/CMakeLists.txt --- tdelibs/tdeio/tdeio/CMakeLists.txt 2013-08-15 16:35:14.000000000 -0500 +++ tdelibs.new/tdeio/tdeio/CMakeLists.txt 2013-08-15 18:32:46.337606197 -0500 @@ -81,13 +81,18 @@ kdirnotify.cpp kdirnotify.skel kdirnotify_stub.cpp observer.cpp ../misc/uiserver.stub observer.skel tdeemailsettings.cpp kprotocolinfo.cpp renamedlg.cpp skipdlg.cpp kremoteencoding.cpp - kmimetypechooser.cpp backtrace_symbols.c + kmimetypechooser.cpp ) +if( WITH_TDEIOSLAVE_BACKTRACE ) + list( APPEND ${target}_SRCS backtrace_symbols.c ) + set( BACKTRACE_LIBRARY bfd ) +endif( ) + tde_add_library( ${target} STATIC_PIC AUTOMOC SOURCES ${${target}_SRCS} DEPENDENCIES dcopidl - LINK bfd + LINK ${BACKTRACE_LIBRARY} bfd ) diff -urN tdelibs/tdeio/tdeio/ConfigureChecks.cmake tdelibs.new/tdeio/tdeio/ConfigureChecks.cmake --- tdelibs/tdeio/tdeio/ConfigureChecks.cmake 1969-12-31 19:00:00.000000000 -0500 +++ tdelibs.new/tdeio/tdeio/ConfigureChecks.cmake 2013-08-15 18:29:10.768715615 -0500 @@ -0,0 +1,17 @@ +################################################# +# +# (C) 2010-2011 Serghei Amelian +# serghei (DOT) amelian (AT) gmail.com +# +# Improvements and feedback are welcome +# +# This file is released under GPL >= 2 +# +################################################# + +if( WITH_TDEIOSLAVE_BACKTRACE ) + check_include_files( "bfd.h;demangle.h;libiberty.h" HAVE_BINUTILS_DEV ) + if( NOT HAVE_BINUTILS_DEV ) + tde_message_fatal( "binutils-dev are required, but not found on your system" ) + endif( ) +endif( ) diff -urN tdelibs/tdeio/tdeio/slavebase.cpp tdelibs.new/tdeio/tdeio/slavebase.cpp --- tdelibs/tdeio/tdeio/slavebase.cpp 2013-08-15 16:35:14.000000000 -0500 +++ tdelibs.new/tdeio/tdeio/slavebase.cpp 2013-08-15 18:35:12.114855058 -0500 @@ -70,6 +70,7 @@ #ifdef HAVE_BACKTRACE void print_trace() { +#ifdef WITH_TDEIOSLAVE_BACKTRACE void *array[10]; size_t size; char **strings; @@ -85,6 +86,7 @@ } free (strings); +#endif } #endif #endif ===================================== Darrell

1 0

Re: [trinity-devel] kstyle-tdestyle renaming --- update
by Darrell Anderson 15 Aug '13

15 Aug '13

>> Am I supposed to push the patch set to git? > >Currently I'll be a few hours away from the computer, so I will >not be able to >promptly deal with any necessary corrections to the Debian/Ubuntu >packaging files. Your reply implies I should push the patches to git. That's fine, just let me know when you are ready and we'll coordinate. I'm not seeing anything here to indicate problems with the patches, but of course, I only use one distro. Regardless, there should not be any major problems, if any at all. Darrell

1 0

Re: [trinity-devel] kstyle-tdestyle renaming --- update
by Darrell Anderson 15 Aug '13

15 Aug '13

On Tue, 13 Aug 2013 19:48:37 -0500 "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote: >>>>> Should the kstyle directories and files be changed to >tdestyle? >>>>> >>>>Probably. How much would that break at this point though >>>>configuration wise? >>> >>>I don't know. I'm not complaining. :-) I only noticed the >>>differences when I was responding to bug report 1609. Seems we >>>have >>>moved far with so much renaming and of late we have continued >some >>> >>>mopping up of those efforts. :-) >>> >>>A quick scan of modules that install files to >>>$PREFIX/share/apps/kstyle: >>> >>>tdelibs >>>tdebase >>>tdeartwork >>>tdesdk >>> >>>I don't have all packages installed right now so there might be >a >>>few more. >>> >>>Other loose ends include renaming $TDEHOME/share/apps/kstyle- >>>>tdestyle, where ever that is defined (tdelibs?), and r14-xdg- >>>update. Probably other loose ends too. >>> >>>I notice when grepping the sources some internal functions of >>>kstyle* still exist. tdebase/kpersonalizer has cpp files with >>>kstyle8. >>> >>>I could hammer out and test the patches. The grunt work of the >>>patches should go fine, but I'd need a some days of validating >>>build runs and usability testing. If I get overwhelmed I holler. >>>Probably first scream and cry, but eventually holler. :-) >> >> Creating patches went surprisingly smooth. The final list is >short: >> >> tdelibs >> tdebase >> tdeartwork >> tdesdk >> tde-style-lipstik >> tde-style-qtcurve >> koffice >> tde-i18n >> >> I had no build errors. A superficial test of selecting the >styles >> in kcontrol resulted in no errors or problems. >> >> Caveat: The tde-i18n patch is huge. So huge that I will not even >> try to post the patch or try to push to git until I reduce to >> smaller patches and push piece-meal one at a time. >> >> That said, how do we want to proceed next? I can post the >patches >> online and somebody else could test. Or I could just push to git >> and listen for screams of pain and anguish. No problems noticed >> here, but I'm only one person with my own perspective. >> >> Darrell > >Slavek, can you handle updating the Debian/Ubuntu packaging files >for this change? Am I supposed to push the patch set to git? Darrell

2 1

Re: [trinity-devel] Valgrind
by Darrell Anderson 15 Aug '13

15 Aug '13

>Whenever an application misbehaves in an unusual manner (e.g. >platform >dependent, working one day and not another, etc.) I generally run >it under >Valgrind to see if there are any memory corruption issues. >Otherwise, for >fun I sometimes load applications under Valgrind, but that is the >extent >of the QA in this area. Is there anything we can do to supplement that kind of approach? I'm no valgrind expert at all. Just curious whether we can help Trinity with valgrind. Darrell

1 0

Automated qt3->tqt3 updates
by Darrell Anderson 15 Aug '13

15 Aug '13

I see some qt3 updates in the commit list web page for bug report 1350. I am able to pull those changes. I am not seeing any changes in tqt3 to pull. Is the automated tqt3 script functioning? Darrell

3 5

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels August 2013