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
Hello,
I noticed that tdehwlib dbus daemon is not running, although it is properly
installed. When I tried to check it via dbus-send, I got the answer:
Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with
unknown return code 1
When I tried to run it manually in the console, the crash not occurred, but
apparently not implemented parts that might be useful:
[tde_dbus_hardwarecontrol] Unknown method 'NameAcquired' called on
interface 'org.freedesktop.DBus', ignoring
[tde_dbus_hardwarecontrol] Unknown method 'Introspect' called on
interface 'org.freedesktop.DBus.Introspectable', ignoring
Setting the brightness and governor therefore cannot work.
Slavek
>I can confirm the same behavior on Debian Squeeze!
>
The only recent patch directly associated with tdeioslaves was
d89555cc 2013-08-10, [tdebase] Fix tdeioslaves FTBFS when compiled
in standalone for bug report 1617. Would something so simple cause
the errors?
Darrell
