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
>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
>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
>> 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
>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
>> 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
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
>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
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
