Bug 957260 - PyQt4: %{python_sitelib}/dbus/mainloop/qt.so should be in %python_sitearch
Summary: PyQt4: %{python_sitelib}/dbus/mainloop/qt.so should be in %python_sitearch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: PyQt4
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-26 19:03 UTC by Rex Dieter
Modified: 2013-05-14 01:25 UTC (History)
2 users (show)

Fixed In Version: sip-4.14.6-1.fc17
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-02 04:36:16 UTC


Attachments (Terms of Use)

Description Rex Dieter 2013-04-26 19:03:02 UTC
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 :-)

Comment 1 Rex Dieter 2013-04-27 03:34:37 UTC
%changelog
* Fri Apr 26 2013 Rex Dieter <rdieter@fedoraproject.org> 4.10.1-2
- filter private shared objects
- %%{python_sitelib}/dbus/mainloop/qt.so should be in %%python_sitearch (#957260)
- .spec cleanup
- -assistant subpkg

Comment 2 Fedora Update System 2013-04-27 13:19:47 UTC
PyQt4-4.10.1-2.fc19,sip-4.14.6-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/PyQt4-4.10.1-2.fc19,sip-4.14.6-1.fc19

Comment 3 Fedora Update System 2013-04-27 13:20:13 UTC
PyQt4-4.10.1-2.fc18,sip-4.14.6-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/PyQt4-4.10.1-2.fc18,sip-4.14.6-1.fc18

Comment 4 Fedora Update System 2013-04-27 13:20:47 UTC
PyQt4-4.10.1-2.fc17,sip-4.14.6-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/PyQt4-4.10.1-2.fc17,sip-4.14.6-1.fc17

Comment 5 Fedora Update System 2013-04-27 17:26:57 UTC
Package PyQt4-4.10.1-2.fc19, sip-4.14.6-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing PyQt4-4.10.1-2.fc19 sip-4.14.6-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6795/PyQt4-4.10.1-2.fc19,sip-4.14.6-1.fc19
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2013-05-02 04:36:17 UTC
PyQt4-4.10.1-2.fc19, sip-4.14.6-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2013-05-14 01:23:08 UTC
sip-4.14.6-1.fc18, PyQt4-4.10.1-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2013-05-14 01:25:30 UTC
sip-4.14.6-1.fc17, PyQt4-4.10.1-4.fc17 has been pushed to the Fedora 17 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.