>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
I read an article today abut using Valgrind to test software code.
Do we perform any such tests for Trinity? If not then how could we
start such a program?
Darrell
>I've attached it. If I'm reading it correctly, once it's applied,
>you pass --without-avahi to disable the relevant code.
I updated the patch for the tqt framework. I tested with
avahi/avahi-tqt installed and not installed. Looks great. I'll push
to git.
Note to all: the defaults remain the same. As mentioned, --disable-
avahi must be explicitly defined in the configuration. Otherwise
nothing changes --- even the configuration warnings remain the same
when avahi is not found and will not be compiled.
Thanks!
Darrell
>> >btw: haven't forgot to rename cmake variables? e.g. in
>> >tdeartwork...
>>
>> Is that a question? To me?
>>
>Um... yes,,,, why are you so mush surprised?
>During most of previous renames, I noticed, the cmake options were
>left-behind,
No, I wasn't surprised. I just did not understand the question. If
you mean, did I remember to update the CMakeLists.txt files, yes. :-
) As I mentioned, everything built without error, everything
installed to $PREFIX/share/apps/tdestyle, and there is no remnant
$PREFIX/share/apps/kstyle after updating the packages.
Typically though I tend to forget to run 'git add --all' before
creating the commit message. I know better --- but there isn't a
sufficiently hefty 2x4 here to sometimes remind me. :-)
Darrell
>> 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.
Woops! A typo in my diff command resulted in the large diff. The
final patch is now MUCH smaller and sane. :-)
>I don't feel that I'm one of core testers, but why not to push
>them into
>their own branch and let somebody test it?
>IMO It's easier than mess with patch-sets and no mob of angry
>developers or
>testers will not want to broke your legs ;)
Branch? Um, nope, ain't going down that road. :-) Git hates me and
I hate git. I'm reasonably confident the patch set can be pushed to
git as is because I'm seeing no problems here. I asked the question
of posting patches for testing in case others don't feel confident,
which I'm fine with.
>btw: haven't forgot to rename cmake variables? e.g. in
>tdeartwork...
Is that a question? To me?
Darrell
>>> 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
>I've attached it. If I'm reading it correctly, once it's applied,
>you
>pass --without-avahi to disable the relevant code.
Hey, thanks! I'll give that a whirl.
>Note that I don't actually use ktorrent—I'm mostly just reading
>old ebuilds.
I don't either, but I build most of the packages simply to help the
project. :-)
Darrell
>ktorrent proper doesn't depend on avahi, but it has an optional
>plugin that does, and by default the build system checks to see if
>avahi is present. There's an old Gentoo patch that I think is
>intended
>to provide support for explicitly disabling avahi (thus killing
>the check
>and just not building the plugin) via a configuration option, but
>it
>obviously won't apply if ktorrent has been converted to CMake.
>
>In other words, the warning is harmless if you're okay with
>autodetects,
>but we may be able to fix it anyway.
Any chance you could find the patch? I should be able to massage
into our tqt3/renaming framework.
I realize there is no harm, but I like clean builds and a tad of
"spit polish." :-)
Darrell
All,
Does ktorrent depend upon avahi? I don't have avahi or avahi-tqt
installed. In the ktorrent build log I always see the following:
checking for avahi-client >= 0.6.10... checking for avahi-tqt >=
0.6.10... checking if apps should be compiled... yes
...
KTorrent WARNING:
Cannot find avahi-client with version 0.6.10 or later or
cannot find avahi-tqt.
The zeroconf plugin will not be installed because of this.
Should there be a configuration option to explicitly exclude using
avahi?
Darrell
