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
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
>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
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
All,
I rebuilt a new package set last night. I haven't tested thoroughly
but thus far no surprises. Looks like I updated my sources just
after commit 3c06aad1 2013-08-11, [tdelibs] Fix tdebindings FTBFS.
Darrell
>> Was the release announcement for 3.5.13.2 sent to any media
>folks?
>
>If I know announcement was not sent to the media.
Better late than never?
Darrell
Hello,
A few days ago I sent a proposal to add a HAL backend for power
management. Meanwhile, I fixed call Suspend and added support for
governor (not tested).
I also noticed that setting the brightness and governor is in condition
WITH_UPOWER, although in fact uses Trinity DBus daemon => has nothing to
do with upower. I added to the option WITH_TDEHWLIB_DAEMONS and fixed
incorrect WITH_UPOWER conditions.
Please test it. At the same time I'm waiting for your opinions -
incorporate it or not?
Thanks
Slavek
>It's sad on the bug, that RiscOS theme supplied with tde doesn't
>work
>either (see the screenshot).
>So it seems to be a bug somewhere deep inside tdelibs or qt3.
I ran some tests and filed a comment in the bug report (1609). The
pixmaps do not show in 3.5.10 either, so pixmaps have been broken
for a while. The kinstalltheme command never gets run when creating
a new profile. In a new profile, only after manually running
kinstalltheme did I finally see riscos in the kcontrol drop-down
list.
Darrell