Bug 957260

Summary says it all,
%{python_sitelib}/dbus/mainloop/qt.so

is arch-specific and should be in %python_sitearch instead.


Had a nice chat in #fedora-devel today (log appended).


Long and short is that abadger came up with a simple fix approach:

# Add %{buildroot} to all of this for the spec file
# And use python_sitelib sitearch etc
# Should be able to to this on 64 and 32 bit... the directory will just be
# /usr/lib/python2.7/site-packages/_dbus_qt on 32 bit

mkdir /usr/lib64/python2.7/site-packages/_dbus_qt                                                                         
mv /usr/lib/python2.7/site-packages/dbus/mainloop/qt.so /usr/lib64/python2.7/site-packages/_dbus_qt/qt.so
touch /usr/lib64/python2.7/site-packages/_dbus_qt/__init__.py
echo 'from _dbus_qt.qt import *' > /usr/lib/python2.7/site-packages/dbus/mainloop/qt.py

# These shouldn't be needed in the rpm but may be needed when hacking it together locally for testing
restorecon -R  /usr/lib/python2.7/site-packages/dbus/mainloop/qt.py                          
restorecon -R /usr/lib64/python2.7/site-packages/_dbus_qt/ 


-------------irc log------------------------------

[04/26/13 13:08] <rdieter> abadger1999: (or anyone else with ample python packaging fu), ping when you get a chance, I see PyQt4 packaging installs a whole bunch of .so's under %{python_sitearch}/PyQt4/ , and one @ %{python_sitelib}/dbus/mainloop/qt.so shouldn't this latter one be in sitearch too?
[04/26/13 13:09] <thm_> imho yes.
[04/26/13 13:09] <fenrus02> thm_, excellent, thanks!
[04/26/13 13:10] <rdieter> thm_: that for me?
[04/26/13 13:10] <thm_> rdieter: yes.
[04/26/13 13:11] <rdieter> looks like it naively just plops it into the same place as where dbus-python does (which uses python_sitelib)
[04/26/13 13:13] <thm_> rdieter: also, PyQt4 'provides' all its private shared objects.
[04/26/13 13:13] <thm_> it shouldn't, if I am not missing something.
[04/26/13 13:13] <rdieter> sure, that's another separate issue (lacks filtering)
[04/26/13 13:14] <abadger1999> rdieter: yep, it should be in sitearch as well
[04/26/13 13:15] <abadger1999> oh wait...
[04/26/13 13:15] <abadger1999> dbus-python might be in the wrong htere as well.
[04/26/13 13:15] <abadger1999> *sigh* senses a complex interaction i nthe making
[04/26/13 13:15] <rdieter> dbus-python is pure python, looks ok
[04/26/13 13:15] <rdieter> unless I'm missing something?
[04/26/13 13:16] <abadger1999> okay...
[04/26/13 13:16] <abadger1999> So the dbus-python strategy is --
[04/26/13 13:16] <thm_> dbus-python has its .so in %sitearch, as it should be.
[04/26/13 13:16] <abadger1999> arch specific module with a different name in %{python_sitearch} => /usr/lib64/python2.7/site-packages/_dbus_bindings.so  and /usr/lib64/python2.7/site-packages/_dbus_glib_bindings.so
[04/26/13 13:16] <abadger1999> then the dbus namespace is in sitelib
[04/26/13 13:17] <abadger1999> and pure python modules that provide the python front end to the raw bindings are in sitelib inside of that namespace.
[04/26/13 13:17] <volter> tibbs|w: Can I close the FTBFS ticket for i4uc yet?
[04/26/13 13:17] <tibbs|w> I thought I did.
[04/26/13 13:17] <abadger1999> note that htis is hte de facto namespace, not an explicit, new-style namespace
[04/26/13 13:17] <abadger1999> rdieter: So pyqt4 could copy that strategy.
[04/26/13 13:18] <volter> tibbs|w: No, it's still open.
[04/26/13 13:18] <abadger1999> rdieter: or we'd have to get python-dbus to create an explicit new-style namespace.
[04/26/13 13:18] <tibbs|w> volter: I must have forgotten to submit the form.  I'll do that now.
[04/26/13 13:18] <abadger1999> import dbus.mainloop.* could search in all physical directories on disk that are inside of that namespace.
[04/26/13 13:20] <abadger1999> rdieter: the reason that simply moving the pyqt dbus module elsewhere will not work is that without explicit namespaces, python is only going to search for a module until it finds a directory that matches.
[04/26/13 13:20] <rdieter> abadger1999: pretend I don't know what either of those mean and that I'm just a simple package monkey (not far from the truth here).   can you explain your suggestion(s) more simply to help me understand better how to make the packaging of one or both of these better?
[04/26/13 13:20] <abadger1999> So if there's two directories that contain python files for hte same module, only the first one found will be used.
[04/26/13 13:20] <rdieter> ok
[04/26/13 13:20] <rdieter> maybe it's not worth "fixing" at this point?
[04/26/13 13:21] <abadger1999> so that's why we can't just have %{python_sitearch}/dbus and %{python_sitelib}dbus
[04/26/13 13:21] <abadger1999> rdieter: well -- if you want to have qt dbus integration you'll have to have it fixed.
[04/26/13 13:21] <tibbs|w> volter: I also pushed a dead.package file.
[04/26/13 13:21] <rdieter> abadger1999: one option is to just leave it as-is. :)
[04/26/13 13:21] <volter> tibbs|w: Thanks!
[04/26/13 13:21] <abadger1999> rdieter: I see threee ways of fixing it.
[04/26/13 13:22] * rdieter is listening
[04/26/13 13:23] <abadger1999> rdieter: Easiest from a code perspective si to have dbus-python install into python_sitearch.  the when you drop your modules in they go into python_sitearch as well and will be found by python.
[04/26/13 13:23] <abadger1999> rdieter: politically, that's probably doable if dbus actively supports adding things to the dbus.mainloop package by third party packages.
[04/26/13 13:24] <abadger1999> rdieter: 2nd solution -- dbus-python provides an explicit namespace by working with __path__.
[04/26/13 13:24] <abadger1999> rdieter: I don't have a lot of information on that handy although I've done it once.
[04/26/13 13:25] <abadger1999> (and only once)
[04/26/13 13:26] <abadger1999> rdieter: 3rd solution is to change what the compiled pyqt4 dbus extension is called and put that into python_sitearch.  Then drop a small wrapper into sitelib/dbus/mainloop to bring the names from the compiled module into the proper namespace
[04/26/13 13:26] <abadger1999> rdieter: that might be easy but it should have some testing.
[04/26/13 13:27] <rdieter> yeah, 1 sounds easiest, 3 feels like the better option long-term though
[04/26/13 13:27] <abadger1999> rdieter: it's also the only one entirely in the pyqt4 maintainer's control.
[04/26/13 13:27] <abadger1999> <nmod>
[04/26/13 13:27] <abadger1999> <nod>
[04/26/13 13:27] <abadger1999> rdieter: is this a problem in all build of pyqt4?  can I test it quickly on f17?
[04/26/13 13:28] <rdieter> abadger1999: I believe so , yea
[04/26/13 13:28] <thm_> rdieter: see /usr/lib/python2.7/site-packages/dbus/__init__.py .. from _dbus_bindings import etc...
[04/26/13 13:30] <abadger1999> rdieter: Do you have a test case to show that the pyqt dbus integration is working by any chance?
[04/26/13 13:30] <rdieter> abadger1999: not offhand, but I'll look around
[04/26/13 13:30] <rdieter> abadger1999: more than just seeing if loading works? :)
[04/26/13 13:31] <abadger1999> rdieter: heh.  Yeah -- I'm going to do that test right now ;-)
[04/26/13 13:31] <rdieter> abadger1999: woo, PyQt4-devel includes examples/dbus/ (in %doc)
[04/26/13 13:33] <rdieter> except that doesn't seem to use this
[04/26/13 13:37] <abadger1999> heh
[04/26/13 13:38] <Roark> anybody there?
[04/26/13 13:39] <thm_> about 350
[04/26/13 13:41] <abadger1999> rdieter: okay, shuffling files around the filesystem and creating a small wrapper passes the import test.
[04/26/13 13:41] <rdieter> abadger1999: found this in pykde4 , polkitqtExamples/pkexamplehelper.py:import dbus.mainloop.qt
[04/26/13 13:41] <abadger1999> There's a few steps -- let me write it up
[04/26/13 13:42] * abadger1999 tries the pkexamplehelper
[04/26/13 13:43] * abadger1999 well... downloads it and writes up the steps while waiting
[04/26/13 13:45] <abadger1999> rdieter: Hmm... is polkitqt available on f17?
[04/26/13 13:46] <rdieter> abadger1999: seems not.  I'm looking @ that now
[04/26/13 13:46] <abadger1999> k
[04/26/13 13:46] <abadger1999> let me write this up and then maybe you can test it :-)
[04/26/13 13:47] <rdieter> k
[04/26/13 13:47] <rdieter> offhand those look like deprecated bindings for stuff before polkit-1
[04/26/13 13:47] <nirik> REMINDER: there's a fedorahosted.org outage starting in about 15min.
[04/26/13 13:52] <abadger1999> rdieter: http://paste.fedoraproject.org/8843/02363136/
[04/26/13 13:54] <rdieter> abadger1999: thanks!
[04/26/13 13:57] <abadger1999> rdieter: I couldn't just rename qt.so to _dbus_qt.so... I think that the extension module name is compiled into the qt.so.  But if this works and you can convince upstream to separate it out like this, they should be able to change the name that gets compiled in.
[04/26/13 13:57] <abadger1999> (so they could build it as _dbus_qt.so if they wanted to.)
[04/26/13 13:57] <rdieter> abadger1999: cool thanks, you pre-empted my asking about that. :)
[04/26/13 13:58] <abadger1999> Cool :-)