10.1 RC1: bug in %suse_update_desktop_file + about python packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Started building on 10.1 RC1 and I noticed two things:
1) there's a bug in the %suse_update_desktop_file macro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(in the /usr/lib/rpm/suse_macros file)
I always use that macro like this:
%suse_update_desktop_file -r "%{name}" Foo Bar
The -r flag overwrites categories that already exist in the .desktop
file (without -r, it just appends to the existing).
That doesn't work on 10.1, the bug + workaround is described here:
https://bugzilla.novell.com/show_bug.cgi?id=166170
Workaround: edit /usr/lib/rpm/suse_macros and change line 48:
%suse_update_desktop_file() \
into this:
%suse_update_desktop_file(cinrud) \
2) all your spec files that build using python setuptools are hosed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The default prefix for builds with Python setuptools (setup.py) is now
/usr/local instead of /usr
So you need to change the
%__python ./setup.py install --root="%{buildroot}"
line into this:
%__python ./setup.py install --prefix="%{_prefix}" --root="%{buildroot}"
Then it works as expected.
I wanted to file a bug for this one as well, but I've been told it's
explicitely wanted that way.
Could someone @SUSE comment on this one ? Adrian ?
Is it a bug or is it intended ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal Bleser wrote:
2) all your spec files that build using python setuptools are hosed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The default prefix for builds with Python setuptools (setup.py) is now /usr/local instead of /usr [...] Could someone @SUSE comment on this one ? Adrian ? Is it a bug or is it intended ?
It's intended as a fix for https://bugzilla.novell.com/show_bug.cgi?id=149809 and https://bugzilla.novell.com/show_bug.cgi?id=149843 The idea is that manually installed python programs should go to /usr/local (as autotooled programs do). It probably should have been announced on opensuse-packaging in advance. Michal Marek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Marek wrote:
Pascal Bleser wrote:
2) all your spec files that build using python setuptools are hosed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The default prefix for builds with Python setuptools (setup.py) is now /usr/local instead of /usr [...] Could someone @SUSE comment on this one ? Adrian ? Is it a bug or is it intended ?
It's intended as a fix for https://bugzilla.novell.com/show_bug.cgi?id=149809 and https://bugzilla.novell.com/show_bug.cgi?id=149843
The idea is that manually installed python programs should go to /usr/local (as autotooled programs do). It probably should have been announced on opensuse-packaging in advance.
Yes, I can imagine the reason. It's just a bit annoying for packagers because as previously the "correct" Python prefix (for RPM packages, that is) has been set automatically by setup.py, I suppose I'm not the only one who never thought of passing --prefix="%{_prefix}", so now for 10.1 all python-*.spec have to be modified. What just makes me wonder... what's the point of installing Python libraries under /usr/local when the default sys.path doesn't include that directory ? $ python Python 2.4.2 (#1, Apr 9 2006, 16:08:21) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys print sys.path ['', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/gtk-2.0']
No /usr/local/lib64/python2.4/site-packages in there...
Anyway, I guess we'll just have to live with it ;)
Thanks for your comments.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal Bleser wrote:
What just makes me wonder... what's the point of installing Python libraries under /usr/local when the default sys.path doesn't include that directory ?
$ python Python 2.4.2 (#1, Apr 9 2006, 16:08:21) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys print sys.path ['', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/gtk-2.0']
No /usr/local/lib64/python2.4/site-packages in there...
It will appear in sys.path only only if the directory exists: # mkdir -p /usr/local/lib64/python2.4/site-packages/ $ python -c 'import sys; print sys.path;' ['', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/local/lib64/python2.4/site-packages'] ^^^^^^^ To be honest, I don't know why it works this way (my python knowledge is quite limited), ask jmatejek@suse.cz if you have problems with the current way it works: * Mon Feb 27 2006 - jmatejek@suse.cz - implemented /usr/local path schemes for bug #149809 - python now recognizes packages in /usr/local/lib/python2.4 - distutils install by default into /usr/local/lib/python2.4/site-packages - on 64bit systems that is of course lib64 Michal
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Marek wrote:
Pascal Bleser wrote:
What just makes me wonder... what's the point of installing Python libraries under /usr/local when the default sys.path doesn't include that directory ?
$ python Python 2.4.2 (#1, Apr 9 2006, 16:08:21) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys print sys.path ['', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/lib64/python2.4/site-packages/Numeric', '/usr/lib64/python2.4/site-packages/gtk-2.0']
No /usr/local/lib64/python2.4/site-packages in there...
It will appear in sys.path only only if the directory exists:
# mkdir -p /usr/local/lib64/python2.4/site-packages/ $ python -c 'import sys; print sys.path;' ['', '/usr/lib/python24.zip', '/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2', '/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload', '/usr/lib64/python2.4/site-packages', '/usr/local/lib64/python2.4/site-packages'] ^^^^^^^
Oh, right, then it's fine :)
To be honest, I don't know why it works this way (my python knowledge is quite limited), ask jmatejek@suse.cz if you have problems with the current way it works:
That's ok. Thanks for clarifying :)
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Hi Pascal, Am Friday 14 April 2006 04:26 schrieb Pascal Bleser:
Started building on 10.1 RC1 and I noticed two things:
1) there's a bug in the %suse_update_desktop_file macro ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (in the /usr/lib/rpm/suse_macros file) I always use that macro like this: %suse_update_desktop_file -r "%{name}" Foo Bar
The -r flag overwrites categories that already exist in the .desktop file (without -r, it just appends to the existing).
That doesn't work on 10.1, the bug + workaround is described here: https://bugzilla.novell.com/show_bug.cgi?id=166170
Workaround: edit /usr/lib/rpm/suse_macros and change line 48:
%suse_update_desktop_file() \
I do have a %suse_update_desktop_file(:-:) line here. And this works also for me here. You may want to check rpm -V rpm ? bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
participants (3)
-
Adrian Schröter -
Michal Marek -
Pascal Bleser