Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056769 - No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Summary: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kdelibs
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukáš Tinkl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-22 21:50 UTC by Ian Pilcher
Modified: 2015-07-13 08:10 UTC (History)
9 users (show)

Fixed In Version: kdelibs-4.14.3-8.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-08 23:31:41 UTC


Attachments (Terms of Use)

Description Ian Pilcher 2014-01-22 21:50:35 UTC
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

Comment 1 Lukáš Tinkl 2014-01-22 22:15:04 UTC
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 :/

Comment 2 Ian Pilcher 2014-01-23 19:57:24 UTC
(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.

Comment 3 Kevin Kofler 2014-01-23 22:51:40 UTC
Can't we remove the obsolete signal connections? I agree that spamming error messages to the console is not an acceptable state of affairs.

Comment 4 Lukáš Tinkl 2014-01-24 12:30:55 UTC
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

Comment 5 Ian Pilcher 2014-01-24 12:40:58 UTC
(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.

Comment 6 Lukáš Tinkl 2014-01-24 12:52:46 UTC
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

Comment 7 Daniel Vrátil 2014-01-24 13:04:03 UTC
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 :)

Comment 8 Lukáš Tinkl 2014-01-24 16:59:51 UTC
Uhm, it's a DBUS signal, are you sure is it still possible? :)

Comment 9 Kevin Kofler 2014-01-25 00:24:17 UTC
In Fedora, we know exactly what version of upower is going to be used.

Comment 10 Daniel Vrátil 2014-01-27 11:14:27 UTC
(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 :)

Comment 11 Lukáš Tinkl 2014-11-07 14:18:53 UTC
Fixed upstream for Frameworks 5.5 with this commit:

http://commits.kde.org/solid/d5f6f40eb8b6a420520cb7c726959048593d2cab

Comment 12 Daniel Vrátil 2014-11-10 09:10:13 UTC
Could you consider backporting this to our kdelibs packages?

Comment 13 Lukáš Tinkl 2014-11-21 12:35:57 UTC
It got backported to 4.14 branch:

http://commits.kde.org/kdelibs/9f372807041ec73cfa69017edfdb739485867d26

Comment 14 Rex Dieter 2014-11-21 18:11:03 UTC
pulling fix into packaging,

%changelog
* Fri Nov 21 2014 Rex Dieter <rdieter@fedoraproject.org> - 6:4.14.3-2
- No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath) (#1056769)
- use upstream _DEFAULT_SOURCE commit/patch instead

Comment 15 Fedora Update System 2014-12-30 15:16:10 UTC
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

Comment 16 Fedora Update System 2014-12-30 15:22:31 UTC
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

Comment 17 Fedora Update System 2014-12-31 19:01:26 UTC
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).

Comment 18 Fedora Update System 2015-01-08 23:31:41 UTC
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.

Comment 19 Fedora Update System 2015-01-17 05:49:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.