Filing this against the kate component, although I suspect the problem is in a library somewhere ... I use kwrite a lot on the command line. After starting a new kwrite process, the first time I click on the open file button, I get the following two messages in my terminal: Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath) This (and similar message spew) has been a longstanding "feature" of KDE applications; I'm finally irritated enough the BZ it. kwrite-4.11.5-1.fc20.x86_64 kdelibs-4.11.5-1.fc20.x86_64 qt-4.8.5-11.fc20.x86_64 upower-0.9.23-2.fc20.x86_64
It's harmless warning coming from Qt, when the new solid's upower backend is in use; you can just ignore it. Blame the upower guys for breaking the DBUS interface :/
(In reply to Lukáš Tinkl from comment #1) > It's harmless warning coming from Qt, when the new solid's upower backend is > in use; you can just ignore it. Blame the upower guys for breaking the DBUS > interface :/ I find it extremely annoying, i.e. not harmless. I'm going to change this to WONTFIX, which seems to be the reality of the situation.
Can't we remove the obsolete signal connections? I agree that spamming error messages to the console is not an acceptable state of affairs.
No... the long story is that currently there exist 2 different signals on the DBUS depending on the upower version and since we can't know which one it is with Qt DBUS, we "blindly" connect to both, the connection will succeed with the correct one and spam those debugs with the other one :/ Unfortunately I can't do anything about this
(In reply to Lukáš Tinkl from comment #4) > No... the long story is that currently there exist 2 different signals on > the DBUS depending on the upower version and since we can't know which one > it is with Qt DBUS, we "blindly" connect to both, the connection will > succeed with the correct one and spam those debugs with the other one :/ > > Unfortunately I can't do anything about this Why not? There's some code somewhere that is printing these messages. It *could* be patched to not do so. (That might be a really bad idea, but that's a separate question.) If that code isn't in kate, please reassign this to the correct component.
The code is in Qt, most probably in QObject::connect() and patching it out is not a good idea either, in most cases it prints real and useful warnings worth fixing
You could use QMetaObject::indexOfSignal() to check whether a metamethod for the signal exists before attempting to connect to it. It's just a few lines of code and would solve this. I also find this quite annoying, but knowing why it's happening, I didn't bother reporting it :)
Uhm, it's a DBUS signal, are you sure is it still possible? :)
In Fedora, we know exactly what version of upower is going to be used.
(In reply to Lukáš Tinkl from comment #8) > Uhm, it's a DBUS signal, are you sure is it still possible? :) You could try QDBusInterface *iface = new QDBusInterface("org.freedesktop.UPower","/org/freedesktop/UPower", "org.freedesktop.UPower", QDBusConnection::systemBus()); if (iface->metaObject()->indexOfSignal("DeviceAdded()") > -1) { .... } I looked into QtDBus code briefly, but it's not clear to me whether the metaobject is populated by signals available on given interface. It would make sense (otherwise I don't know how else QObject could detect that the signal is missing), but couldn't find it. Funny thing is that grepping Qt source code for "No such signal" returns no hits :)
Fixed upstream for Frameworks 5.5 with this commit: http://commits.kde.org/solid/d5f6f40eb8b6a420520cb7c726959048593d2cab
Could you consider backporting this to our kdelibs packages?
It got backported to 4.14 branch: http://commits.kde.org/kdelibs/9f372807041ec73cfa69017edfdb739485867d26
pulling fix into packaging, %changelog * Fri Nov 21 2014 Rex Dieter <rdieter> - 6:4.14.3-2 - No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) (#1056769) - use upstream _DEFAULT_SOURCE commit/patch instead
kdelibs-4.14.3-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kdelibs-4.14.3-8.fc21
kdelibs-4.14.3-8.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kdelibs-4.14.3-8.fc20
Package kdelibs-4.14.3-8.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kdelibs-4.14.3-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-17744/kdelibs-4.14.3-8.fc21 then log in and leave karma (feedback).
kdelibs-4.14.3-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
kdelibs-4.14.3-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.