tde-devels

devels@trinitydesktop.org

9 participants
3819 discussions

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

13 Aug '13

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

2 1

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

13 Aug '13

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

3 2

Re: [trinity-devel] ktorrent and avahi
by Darrell Anderson 13 Aug '13

13 Aug '13

>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

1 0

Re: [trinity-devel] ktorrent and avahi
by Darrell Anderson 13 Aug '13

13 Aug '13

>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

2 1

ktorrent and avahi
by Darrell Anderson 13 Aug '13

13 Aug '13

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

2 1

tdehwlib dbus daemon
by Slávek Banko 12 Aug '13

12 Aug '13

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

1 1

Re: [trinity-devel] Tim: tdeioslave crashes?
by Darrell Anderson 12 Aug '13

12 Aug '13

>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

2 1

Tim: tdeioslave crashes?
by Darrell Anderson 12 Aug '13

12 Aug '13

Tim, With a full clean rebuild last night, I now see the following messages in xsession-errors log: tdeioslave: ####### CRASH ###### protocol = pid = 29858 signal = 11 /opt/trinity/lib/libtdeio.so.4(_ZN5TDEIO9SlaveBase15sigsegv_handlerE i+0xd0)[0xb742f350] tdeio_media [tdeinit] media /dev/shm/tdesocket- root/tdelauncherM6C(_ZTI15TQPtrCollection+0x0)[0x8057564] The pid changes but the remainder of the message string remains the same. Darrell

2 1

Re: [trinity-devel] Tim: tdebindings FTBFS --- also libtqt-perl
by Darrell Anderson 12 Aug '13

12 Aug '13

>libtqt-perl requires libsmoketqt from tdebindings. Are you sure? I have a note in my build script that libtqt-perl has its own built-in smoke libs but will use the smoke version from tdebindings when found during compiliation and tdebindings is already installed. I remember a discussion about this, perhaps even a bug report and a resulting patch in libtqt-perl not to build smoke when already found installed. Darrell

2 1

tdehwlib upower and devicekit-power backend
by Slávek Banko 12 Aug '13

12 Aug '13

Hello, as pointed out by François in bug report 1588, upower was previously named devicekit-power. And with corresponding dbus paths. I wonder what is the cost of dbus call? I hesitate to support devicekit-power as an second dbus paths for upower or as a standalone backend. What is your opinion? http://bugs.pearsoncomputing.net/show_bug.cgi?id=1588 Thanks, Slavek

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels