I need some help debugging a phonon gstreamer backend issue. I'm using
KDE 4.3 from the unofficial repos and when I listen to music with
Amarok and open Dragon Player, phonon pops up a notification saying
(translated from Norwegian): "The device for sound playback, HDA
NVidia (ALC883 Analog), doesn't work. Instead the Default is used."
If i try to play something in Dragon player, it won't play anything at
all. I'm just seeing a black screen with nothing going on. The seeker
doesn't move at all. If I try to move the seeker, Dragon player just
sits still not doing anything at all. When I then click on close, a
box pops up saying that Dragon player is not responding and I can then
How do I go about reporting this?
This is my first post to this list btw :)
On Saturday 08 August 2009 16:06:05 Kevin Kofler wrote:
> Benjamin K. Stuhl wrote:
> > I committed another, alternative, DeviceKit-based Solid backend to
> > KDE's Subversion repository yesterday, in
> > branches/work/alternative-solid- devicekit. It grew out of some
> > experiments I was doing with writing a Qt-ish libudev wrapper (you can
> > see the API in solid/backends/udevqt.h). Since it got large enough to
> > perhaps be useful to other people, and also to convince me that the
> > general approach would work, I imported it into Subversion from my GitHub
> > repository. The major difference from Pino and Lukas's
> > work/solid-devicekit branch is that I also use libudev for enumeration,
> > as well as DeviceKit-*;
> Great! I told ltinkl this is necessary, he wasn't very thrilled by the
I can appreciate his lack of enthusiasm since it adds some complexity to the
code, but there's no way to get things like camera information from DeviceKit-
* -- e.g. AFAICT gphoto's plan is that they will just dump a .rules file into
udev that attaches a GPHOTO_DRIVER property to the detected cameras.
> > I have also made an effort to try to minimize the amount of boilerplate
> > code each Interface needs (c.f.
> > solid/backends/devicekit/dkdevice.cpp:dbusDeviceCall() and
> > solid/backends/devicekit/dkinterface.h). Please take a look and comment
> > or help out, especially if you know DeviceKit or libudev.
> In what state is it in? Is it something we could put into Rawhide, keeping
> in mind that the Fedora 12 release is less than 3 months from now? Or is it
> still incomplete and/or buggy?
> (We decided that the original work/solid-devicekit branch is not suitable
> because it's missing features the HAL backend has. With libudev, we should
> be able to provide those features.)
I would not say it's ready for Rawhide, especially since it doesn't have all
the Solid::Ifaces implemented yet. But even once the backend is "finished" (and
even it the code was bug-free), it's going to have some regressions against
HAL, simply because upstream projects like gphoto and libgpod haven't yet
released versions that store their eumeration data in udev. Maybe by Fedora 13
those versions will be out and KDE can switch to DeviceKit, but in the
meantime there would be a lot of complaints of "why did KDE suddenly stop
detecting my camera?".
To be honest, libudev/DeviceKit-* currently lacks substantial features in
comparison with HAL. Maybe in the future there will be a DeviceKit-* for every
device imaginable, but in the meantime I feel like I'm having to steal
substantial amounts of ideas from HAL's addons to get the features we need.
(E.g. I'm currently writing a class that uses the sg or bsg device associated
with your cdrom drive to listen for eject button presses -- in HAL, this is
done by hal-addon-storage, but DeviceKit-disks doesn't provide it.)
I'm getting the following error in Dolphin when trying to connect to a
server via ssh.
Connection to server <name> is broken
It appears in the Dolphin window (either in the bottom or as a popup).
Unfortunately it doesn't happen all the time. If a successful
connection is made and I can browse the directory on the remote host,
then it will likely pop up when performing a file operation (e.g. copy
a local file to the remote host).
The dialog is an information dialog, there is no crash and nothing
written to stdout when it occurs.
There is however a lot of "org.freedesktop.DBus.Error.ServiceUnknown -
The name org.kde.nepomuk.services.nepomukstorage was not provided by
any .service files" but these appear all the time so I'm not sure they
Anyone else have this problem? Can someone test?
paulsscott at gmail.com
(resending, since I wasn't subscribed to fedora-kde; my apologies if you get
I committed another, alternative, DeviceKit-based Solid backend to KDE's
Subversion repository yesterday, in branches/work/alternative-solid-devicekit.
It grew out of some experiments I was doing with writing a Qt-ish libudev
wrapper (you can see the API in solid/backends/udevqt.h). Since it got large
enough to perhaps be useful to other people, and also to convince me that the
general approach would work, I imported it into Subversion from my GitHub
repository. The major difference from Pino and Lukas's work/solid-devicekit
branch is that I also use libudev for enumeration, as well as DeviceKit-*; I
have also made an effort to try to minimize the amount of boilerplate code each
Interface needs (c.f. solid/backends/devicekit/dkdevice.cpp:dbusDeviceCall()
and solid/backends/devicekit/dkinterface.h). Please take a look and comment or
help out, especially if you know DeviceKit or libudev.
Pino, Lukas: I wasn't particularly trying to rewrite all your code, so I'm
SVN-copying your DeviceKit-disks-based parts from your work/solid-devicekit
branch and modifying them to fit in. I'd be happy if you would like to
contribute, but if you like your original design better and want to keep
working on it, I understand that too. One question: the code I wrote is
LGPLv2+, while your code is LGPLv2-only. If you do like my branch, would you
be willing to relicense your code to LGPLv2+ for consistency?
Last several times kpackagekit ran to update here, it didn't work well at all.
I told it to 'apply' updates. It seems to just hang, saying 'getting info' or
something like that. Eventually I just try to cancel. (I always end up with
2 of them, and need to try to cancel both. No idea what the hell is going
I'm left with the icon still there, if clicked it says:
Getting updates (cancelling).
In the meantime, it actually DID finish the updates OK.
Now that 4.3 is officially out, what are the chances of it finding its
way to fedora-stable in the near future? Or is the plan to hold it till
F11? (I'm currently on F11).
If the latter, I'll just go ahead and install from kde-testing.
Otherwise I might wait, unless of course I get antsy :-)
I wanted to tune the device actions to make Dolphin the first choice
(I've BZ'ed this in the past, see
https://bugs.kde.org/show_bug.cgi?id=164053 and many dupes), but can't
figure it out. Since 4.3 seems to carry on the tradition of not
documenting anything useful*, can anyone enlighten me?
* The settings dialogue is easy to understand, but the legal values for
the various fields are not documented and should be. Better still, the
dialogue should present them as a choice menu, since it already knows to
complain when they aren't legal. This is basic usability.
Hope somebody can help me with this. I just got a problem report from the "Sparc Koji Build System" which states
kde-plasma-translatoid-0.9-1.fc12 (36060) failed on korolev.ausil.us (noarch), korolev.ausil.us (sparc64):
BuildError: error building package (arch sparc64), mock exited with status 30; see root.log for more information
After scanning the root.log I found the error listed below. Is there any special procedure I need to follow to report this or do I report this as a regular bug? Is it possible that this problem is already known? Any advice would be appreciated.
DEBUG backend.py:561: /usr/bin/yum --installroot /var/lib/mock/dist-f12-build-50233-33341/root/ install 'kdebase-workspace-devel >= 4.2.0' 'gettext >= 0.17'
DEBUG util.py:280: Executing command: /usr/bin/yum --installroot /var/lib/mock/dist-f12-build-50233-33341/root/ install 'kdebase-workspace-devel >= 4.2.0' 'gettext >= 0.17'
DEBUG util.py:256: mkinitrd-6.0.87-1.fc12.sparc64 from build has depsolving problems
DEBUG util.py:256: --> Missing Dependency: grubby = 6.0.87-1.fc12 is needed by package mkinitrd-6.0.87-1.fc12.sparc64 (build)
DEBUG util.py:256: Error: Missing Dependency: grubby = 6.0.87-1.fc12 is needed by package mkinitrd-6.0.87-1.fc12.sparc64 (build)
DEBUG util.py:256: You could try using --skip-broken to work around the problem
DEBUG util.py:256: You could try running: package-cleanup --problems
DEBUG util.py:256: package-cleanup --dupes
DEBUG util.py:256: rpm -Va --nofiles --nodigest
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
so does the notification icon persist in the system tray now? i see that
it is grayed out with no activity, am i missing something about hiding
it with no activity?
can the delay be adjusted in some secret config|rc file? perhaps i can
wish for in the future a text box controlling a millisecond unit.
also the number of recently completed jobs remains where the info icon
is. i have to click the number and close completed jobs? i am not
understanding that. in particular i've noticed them when moving or
coping commands are sent through fish in dolphin.