Switching python-setuptools to distribute
by Toshio Kuratomi
I've been a comaintainer of the python-setuptools package for a long time
and recently became the owner when icon relinquished it. It is currently a
tumultuous time for distributing python modules with a new and active
maintainer for distutils inside of the python stdlib and a fork of
setuptools being worked on.
That fork is named distribute and there are two branches of development on
it. The 0.7 branch aims to implement API, metadata, and other features that
will make packaging python modules for upstream building and distribution
easier while being more concerned with the effects this has on
Linux packagers. The 0.6 branch intends to be compatible with the current
seutptools package but to fix bugs and introduce features that are backwards
compatible and oft requested. This branch is being actively maintained by a
core group of five committers including the new distutils maintainer. By
contrast, setuptools is maintained by a single maintainer who often has
little time to work on it.
When installed, the 0.6 branch takes over the setuptools and pkg_resources
python modules. The reasoning is that distribute-0.6 provides the same API
as setuptools and is meant to replace it. If the module was installed
differently, consuming code (all the setup.py modules in any setuptools
using package as well as code that relies on setuptools features at runtime)
would all need to change their import statements to use the new names
explicitly. This choice is being made upstream by the distribute project.
Upstream, the python community has viewed the fork favorably but since it's
not part of python proper, the only one with say in the matter is the
setuptools author. He has not been willing to abandon the setuptools module
but at the same time hasn't gained any more free time to work on setuptools.
Several other Linux distributions (gentoo and arch) have started shipping
distribute-0.6 as the source of their setuptools package. I am thinking of
doing the same for rawhide and pushing the change to older Fedora releases
if bugs are reported that are fixed in distribute but not in seutptools as
having a responsive upstream that cares about distribution packaging issues
is a great plus for us. I raised this plan on fedora-python-devel and
received one positive comment and no negative feedback so I'm just
mentioning it here so a broader audience can ask any questions or raise any
issues before putting this into effect.
-Toshio
14 years, 6 months
Re: rpms/libid3tag/F-12 libid3tag.spec,1.19,1.20
by Todd Zullinger
Hi Marcela,
Marcela Mašláňová wrote:
> Modified Files:
> libid3tag.spec
> Log Message:
> * Mon Oct 12 2009 Marcela Mašláňová <mmaslano(a)redhat.com> - 0.15.1b-10
> - rebuilt of package with correct licence
[...]
> -License: GPLv2+
> +License: GPLv2 or GPL+ or MIT
I could easily be missing the obvious, but why is this change needed?
All of the *.c source files have:
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
The COPYRIGHT file included in the tarball states GPLv2+ as well.
So where does GPL+ come from? And what code is MIT?
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It could be that the purpose of your life is only to serve as a
warning to others.
-- Demotivators (www.despair.com)
14 years, 6 months
Help with debuging Xserver / Goes in an infinite loop
by Joshua C.
I have a problem with my xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64. I
read the instructions here
http://www.x.org/wiki/Development/Documentation/ServerDebugging but
this didin't help. My Xserver goes in an infinite loop and starts
consuming 100% my cpu. Therefore the whole system freezes and I have
to manually reboot it. This happens all the time when I use firefox on
random sites. After restart there is nothing in the xorg.0.log and
everything repeats itself when I start firefox again. Therefore I need
to remove the savesession.js from the firefox home directory.
On the second mashine I also turned this on: handle SIGUSR1 nostop,
handle SIGUSR2 nostop, handle SIGPIPE nostop.
The Xserver just keeps running and I get no messages on the second
mashine. How to debug it?
14 years, 6 months
rawhide report: 20091010 changes
by Fedora compose checker
Compose started at Sat Oct 10 06:15:04 UTC 2009
Broken deps for i386
----------------------------------------------------------
konversation-1.2-1.fc12.i686 requires kdelibs4 >= 0:4.3.2
sugar-toolkit-0.86.0-1.fc12.i686 requires python-json
Broken deps for x86_64
----------------------------------------------------------
konversation-1.2-1.fc12.x86_64 requires kdelibs4 >= 0:4.3.2
sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json
Broken deps for ppc
----------------------------------------------------------
konversation-1.2-1.fc12.ppc requires kdelibs4 >= 0:4.3.2
sugar-toolkit-0.86.0-1.fc12.ppc requires python-json
Broken deps for ppc64
----------------------------------------------------------
konversation-1.2-1.fc12.ppc64 requires kdelibs4 >= 0:4.3.2
python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json
Removed package gai
Removed package gai-pal
Removed package gai-temp
Removed package python-json
Updated Packages:
NetworkManager-0.7.996-4.git20091002.fc12
-----------------------------------------
* Fri Oct 02 2009 Dan Williams <dcbw(a)redhat.com> - 0.7.996-4.git20091002
- install: fix -gnome package %pre script failures (rh #526519)
- nm: fix failures validating private keys when using the NSS crypto backend
- applet: fix crashes when clicking on menu but not associated (rh #526535)
- editor: fix crash editing wired 802.1x settings
- editor: fix secrets retrieval when editing connections
Terminal-0.4.2-2.fc12
---------------------
* Thu Oct 08 2009 Christoph Wickert <cwickert(a)fedoraproject.org> - 0.4.2-2
- Fix locale problems in the UI (bugzilla.xfce.org #5842)
chromium-bsu-0.9.14-6.fc12
--------------------------
* Fri Oct 09 2009 Hans de Goede <hdegoede(a)redhat.com> 0.9.14-6
- Switch to quesoglc instead of ftgl (glc is the upstream default)
- This fixes chromium-bsu not finding its font, as quesoglc properly uses
fontconfig instead of using a hardcoded path to the font (#526995)
dopewars-1.5.12-9.1033svn.fc12
------------------------------
* Fri Oct 09 2009 Jussi Lehtola <jussilehtola(a)fedoraproject.org> - 1.5.12-8.1033svn
- Update to svn release to address security issues.
* Fri Oct 09 2009 Jussi Lehtola <jussilehtola(a)fedoraproject.org> - 1.5.12-9.1033svn
- Increment release to be able to tag in F-12.
dracut-002-13.4.git8f397a9b.fc12
--------------------------------
* Fri Oct 09 2009 Harald Hoyer <harald(a)redhat.com> 002-13.2
- do not fail, if libdmraid-events-isw.so is not present
* Fri Oct 09 2009 Harald Hoyer <harald(a)redhat.com> 002-13.3
- removed one wildcard of libdmraid-events-isw.so install
* Fri Oct 09 2009 Jesse Keating <jkeating(a)redhat.com> - 002-13.4
- Requires(pre) on plymouth to ensure plymouth is installed before kernel
drupal-service_links-6.x.1.0-5.fc12
-----------------------------------
* Fri Oct 09 2009 Jon Ciesla <limb(a)jcomserv.net> - 6.x.1.0-5
- Patch for CVE-2009-3648 from madirish.net, BZ 528200, 528201.
gcc-4.4.1-20.fc12
-----------------
* Thu Oct 08 2009 Jakub Jelinek <jakub(a)redhat.com> 4.4.1-20
- update from gcc-4_4-branch
- PRs c++/39863, c++/41038
- avoid redundant DW_AT_const_value when abstract origin already has one
(#527430)
- another VTA debug stmt renaming bugfix (#521991)
* Mon Oct 05 2009 Jakub Jelinek <jakub(a)redhat.com> 4.4.1-19
- update from gcc-4_4-branch
- PRs fortran/41479, fortran/41515
- VTA backports
- PRs debug/41353, debug/41404, rtl-optimization/41511
- another debug info fix for decls passed by reference (#527057,
PR debug/41558)
- don't emit DW_AT_name on DW_TAG_const_type (#526970)
- avoid invalid folding of casts to addresses of first fields
(#527121, PR middle-end/41317)
* Thu Oct 01 2009 Jakub Jelinek <jakub(a)redhat.com> 4.4.1-18
- update from gcc-4_4-branch
- PRs ada/41100, target/22093
- VTA backports
- PRs debug/41438, debug/41474, target/41279, testsuite/41444
- fix VTA ICE on Linux kernel (#521991)
- AMD Orochi -mfma4 support
- don't run install-info if info files are missing because of --excludedocs
(#515921, #515960, #515962, #515965, #516000, #516008, #516014)
gdm-2.28.0-9.fc12
-----------------
* Fri Oct 09 2009 Matthias Clasen <mclasen(a)redhat.com> - 1:2.28.0-8
- Move bubbles to the lower right on the login screen
* Fri Oct 09 2009 Ray Strode <rstrode(a)redhat.com> 2.28.0-9
- Fix Other... user.
* Wed Oct 07 2009 Ray Strode <rstrode(a)redhat.com> - 1:2.28.0-7
- Fix gdm-password / xguest interaction (bug 524421)
gtk2-2.18.2-2.fc12
------------------
* Fri Oct 09 2009 Matthias Clasen <mclasen(a)redhat.com> - 2.18.2-2
- Make selecting the final char work again (#528072)
konversation-1.2-1.fc12
-----------------------
* Fri Oct 09 2009 Rex Dieter <rdieter(a)fedoraproject.org> - 1.2-1
- konversation-1.2 (final)
libcap-ng-0.6.2-3.fc12
----------------------
* Fri Oct 09 2009 Steve Grubb <sgrubb(a)redhat.com> 0.6.2-3
- Apply patch to retain setpcap only if clearing bounding set
libv4l-0.6.2-1.fc12
-------------------
* Fri Oct 09 2009 Hans de Goede <hdegoede(a)redhat.com> 0.6.2-1
- New upstream release 0.6.2
libvirt-0.7.1-11.fc12
---------------------
* Fri Oct 09 2009 Mark McLoughlin <markmc(a)redhat.com> - 0.7.1-11
- Fix libvirtd memory leak during error reply sending (#528162)
- Add several PCI hot-unplug typo fixes from upstream
libvoikko-2.2.1-1.fc12
----------------------
* Fri Oct 09 2009 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 2.2.1-1
- New upstream release, fixes bugs found in 2.2
openoffice.org-3.1.1-19.11.fc12
-------------------------------
* Thu Oct 08 2009 Caolán McNamara <caolanm(a)redhat.com> - 1:3.1.1-19.11
- Resolves: rhbz#527177 add openoffice.org-3.1.1.ooo105613.vcl.a11y.exceptions.patch (caolanm)
- Resolves: rhbz#527719 add openoffice.org-3.1.1.oooXXXXXX.vcl.sniffscriptforsubs.patch
openssl-1.0.0-0.9.beta3.fc12
----------------------------
* Thu Oct 08 2009 Tomas Mraz <tmraz(a)redhat.com> 1.0.0-0.9.beta3
- fix typo in DTLS1 code (#527015)
- fix leak in error handling of d2i_SSL_SESSION()
plymouth-0.8.0-0.2009.29.09.9.fc12
----------------------------------
* Fri Oct 09 2009 Ray Strode <rstrode(a)redhat.com> 0.8.0-0.2009.29.09.8
- Fix crash in text plugin on shutdown
* Fri Oct 09 2009 Ray Strode <rstrode(a)redhat.com> 0.8.0-0.2009.29.09.9
- Fix frame-buffer fallback plugin
(broken by details fix in 0.8.0-0.2009.29.09.7)
pybluez-0.16-2.fc12
-------------------
* Thu Oct 08 2009 Paulo Roma <roma(a)lcg.ufrj.br> - 0.16-2
- Applied btmodule patch.
qemu-0.11.0-6.fc12
------------------
* Fri Oct 09 2009 Mark McLoughlin <markmc(a)redhat.com> - 2:0.11.0-6
- Fix fs errors with virtio and qcow2 backing file (#524734)
- Fix ksm initscript errors on kernel missing ksm (#527653)
- Add missing Requires(post): getent, useradd, groupadd (#527087)
* Tue Oct 06 2009 Mark McLoughlin <markmc(a)redhat.com> - 2:0.11.0-5
- Add 'retune' verb to ksmtuned init script
qt-4.5.2-25.fc12
----------------
* Fri Oct 09 2009 Rex Dieter <rdieter(a)fedoraproject.org> - 4.5.2-25
- qt webkit crash on drag (#528094)
* Tue Oct 06 2009 Jaroslav Reznik <jreznik(a)redhat.com> - 4.5.2-24
- disable JavaScriptCore JIT, SE Linux crashes (#527079)
* Sun Oct 04 2009 Than Ngo <than(a)redhat.com> - 4.5.2-23
- rhel cleanup
selinux-policy-3.6.32-24.fc12
-----------------------------
* Sat Oct 10 2009 Dan Walsh <dwalsh(a)redhat.com> 3.6.32-24
- Add home_cert_t for labeling of certs in the homedir
* Thu Oct 08 2009 Dan Walsh <dwalsh(a)redhat.com> 3.6.32-23
- Allow xdm to unlink xauth_home_t
xen-3.4.1-5.fc12
----------------
* Wed Oct 07 2009 Justin M. Forbes <jforbes(a)redhat.com> - 3.4.1-5
- add PyXML to dependencies. (#496135)
- Take ownership of {_libdir}/fs (#521806)
Summary:
Added Packages: 0
Removed Packages: 4
Modified Packages: 22
14 years, 6 months
Howto handle multilib conflict?
by Neal Becker
Just received:
https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error:
file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of
libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package
libotf-devel-0.9.8-2.fc11.x86_64
What is the recommended way to resolve this?
14 years, 6 months
rawhide report: 20091013 changes
by Fedora compose checker
Compose started at Tue Oct 13 06:15:09 UTC 2009
Broken deps for i386
----------------------------------------------------------
sugar-toolkit-0.86.0-1.fc12.i686 requires python-json
Broken deps for x86_64
----------------------------------------------------------
sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json
Broken deps for ppc
----------------------------------------------------------
sugar-toolkit-0.86.0-1.fc12.ppc requires python-json
Broken deps for ppc64
----------------------------------------------------------
python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot
sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json
Updated Packages:
anaconda-12.37-1.fc12
---------------------
* Mon Oct 12 2009 David Cantrell <dcantrell(a)redhat.com> - 12.37-1
- Missing volume_key shouldn't break LUKS support completely. (#526899)
(dlehman)
- Write multipathd.conf in anaconda so that dracut can find it. (pjones)
- Add MultipathDevice.getDMNode(), because .updateSysfsPath() needs it.
(pjones)
- Add MultipathDevice.updateSysfsPath() (pjones)
- Fix a segfault when stage2= boot parameter and kickstart url method is
used (#524417). (rvykydal)
- Fix parsing of optional portnr in iscsi target IP (#525118) (hdegoede)
Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 1
14 years, 6 months
Review Request: kompozer - Web Authoring System
by Ismael Olea
Hi:
I'm looking for a reviewer for Kompozer. A nice fact is the Kompozer
development is very active this days and the 0.8.* series are pretty
stable. I think this is a good tool for Fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=519521
Spec URL: http://olea.org/tmp/kompozer.spec
SRPM URL: http://olea.org/paquetes-rpm/fedora-11/kompozer-0.8-0.2.b1.fc11.src.rpm
Description:
A complete Web authoring system for Linux Desktop users, similar to
Microsoft Windows programs like FrontPage and Dreamweaver.
KompoZer is an unofficial branch of Nvu, previously developed by
Linspire Inc.
It makes managing a Web site a snap. Now anyone can create Web pages
and manage a Web site with no technical expertise or HTML knowledge.
Features
* WYSIWYG editing of pages, making Web creation as easy as typing a
letter with your word processor.
* Integrated file management via FTP. Simply log in to your Web
site and navigate through your files, editing Web pages on the
fly, directly from your site.
* Reliable HTML code creation that works with today's most popular
browsers.
* Jump between WYSIWYG editing mode and HTML using tabs.
* Tabbed editing to make working on multiple pages a snap.
* Powerful support for frames, forms, tables, and templates.
--
A. Ismael Olea González
http://olea.org/diario/
http://aduaneros.org, la ONG sin futuro.
El mundo debe empezar a tener miedo a un planeta OLEA
14 years, 6 months
Proposal: Python 3 in Fedora 13
by David Malcolm
Proposal: Python 3 in Fedora 13
"Evolutionary, not revolutionary": build a python 3 stack
parallel-installable with the python 2 stack.
= High-level summary =
- Python 3.0 was released almost 10 months ago, on 2008-12-03, and the
latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
- Other distros have python 3, though not necessarily with anything
"on top" resembling the full python 2 stack.
- We have a working, valuable python 2 stack, which is used by
critical system components (yum and anaconda): we must not destabilize
the python 2 stack.
- Python 3 is sufficiently different from python 2 that we need them
to be independent software stacks.
- I plan to spend a large chunk of my $DAYJOB over the next few months
trying to build a useful Python 3 stack for Fedora 13, for some
definition of "useful" (help will be appreciated!)
- I don't want to add extra work for package maintainers: if you
maintain an SRPM of a python 2 module that's working for you, you
shouldn't feel obligated to own a separate SRPM for python 3. If
someone has a need for the module on python 3, they can take on that
work.
= Background =
Python 3 is intended by upstream to be the future of Python, but we have
many critical components that use Python 2. Python 2 and Python 3 are
sufficiently different that we need both (try writing "print" in each).
Python 2 will be around for a long time.
An interesting summary of Python 3 adoption can be seen here:
http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096....
An earlier proposal about python 3 in Fedora is here:
https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
Going forward, I will have plenty of time to spend, as part of my
dayjob, on Python in Fedora [1]
= Proposal =
I want to get python 3 into Fedora, but I don't want to break yum or
anaconda (or anything else, for that matter!)
How to do this? I propose that Fedora shall have separate,
parallel-installable Python 2 and Python 3 stacks. I believe we can get
things to the point where on a Fedora box you'd be able to install both
stacks, and have some processes running python 2 code, and some running
python 3, simultaneously.
Where I would draw the line is on having both python 2 and python 3
running within the same _process_: the two libraries share most of their
symbol names, but with differing implementations, and the result of
trying to dynamically link the two into the same address space would be
highly unstable.
As an example, you'd be able to install both mod_python and mod_python3
rpms, but you wouldn't be able to (sanely) configure httpd to have both
running simultaneously (I guess we should add a run-time warning for
this case)
Scoping:
- this work would target Fedora 13. I'd avoid pushing it into F12
until it's proven safe to do so
- the proposal is for python 2 vs python 3. It could be extended to
support having multiple minor-versions of Python as well, but that's a
big extension of the work involved and not something I'm planning to
work on myself.
= Details =
We should split python 2 and python 3 at the source RPM level, where
possible.
The easy case is when upstream release separate tarballs for the python
2 and python 3 versions of code. For example, given package
"python-foo" in packaging CVS, there would be a separate "python3-foo"
for the python 3 version. There would be no expectation that the two
would need to upgrade in lock-step. (The two SRPMS could have different
maintainers within Fedora: the packager of a python 2 module might not
yet have any interest in python 3)
The more difficult case is when the python module is emitted as part of
the build of a larger module. Some examples:
- the build of "rpm" itself emits an "rpm-python" subpackage.
- Another example is the "postgres" srpm, which emits a
"postgresql-python" subpackage.
In a quick attempt at seeing other examples, on my laptop (F11), here
are the packages installed that provide python modules where the package
name differs from the srpm name:
$ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v "is not owned" |
sort | uniq | xargs rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}
%{SOURCERPM}\n" | sed -e"s/.src.rpm//" | squeal -f table col0, col1 from
- where col0 != col1
col0| col1|
----------------------------------------+----------------------------------+
at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11|
audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11|
cracklib-python-2.8.13-4| cracklib-2.8.13-4|
gamin-python-0.1.10-4.fc11| gamin-0.1.10-4.fc11|
hplip-libs-3.9.8-12.fc11| hplip-3.9.8-12.fc11|
libproxy-python-0.2.3-10.fc11| libproxy-0.2.3-10.fc11|
libselinux-python-2.0.80-1.fc11| libselinux-2.0.80-1.fc11|
libsemanage-python-2.0.31-4.fc11| libsemanage-2.0.31-4.fc11|
libuser-python-0.56.9-3| libuser-0.56.9-3|
libxml2-python-2.7.3-3.fc11| libxml2-2.7.3-3.fc11|
newt-python-0.52.10-4.fc11| newt-0.52.10-4.fc11|
plague-common-0.4.5.7-5.20090612cvs.fc11| plague-0.4.5.7-5.20090612cvs.fc11|
policycoreutils-python-2.0.62-12.12.fc11| policycoreutils-2.0.62-12.12.fc11|
python-magic-5.03-2.fc11| file-5.03-2.fc11|
python-slip-dbus-0.1.15-3.fc11| python-slip-0.1.15-3.fc11|
python-slip-gtk-0.1.15-3.fc11| python-slip-0.1.15-3.fc11|
rpm-python-4.7.1-1.fc11| rpm-4.7.1-1.fc11|
setroubleshoot-server-2.1.14-3.fc11| setroubleshoot-2.1.14-3.fc11|
system-config-printer-libs-1.1.8-6.fc11|system-config-printer-1.1.8-6.fc11|
Such SRPMS have a:
BuildRequires: python-devel
which is a subpackage from the python build (2.6)
My plan here is that we should create a python3-devel subpackage as a
subpackage of the python3 build, and have it parallel-installable with
the python-devel package.
We could then %prep the rpm build for each of the above so that the
python 3 support is built as a parallel component of the build,
independently of the python 2 support e.g. by copying the python2
support into a separate dir, then applying a patch as necessary (and
somehow wiring up the configuration/make so it builds both...) The
caveat here is that I haven't tried actually doing this yet for any of
these packages. Issues with this approach:
- I don't yet know if autoconfiguration will work well with both
-devel packages installed
- It will probably involve actually doing the porting work for each
package (yay, we get to be leaders!)
- Whoever does this for a package needs to work closely with the
upstream for that package
I'll have a go at doing this for rpm when I get back from vacation.
Arguably the existing python 2 binding of rpm isn't great, but it's
probably best to go for close compatibility between python 2 and python
3 rather than try to overhaul the bindings as part of the port to python
3: one thing at a time!
"Naming convention" proposal:
How does this sound:
- an rpm with a "python-" prefix means a python 2 rpm, of the
"default" python 2 minor version (for Fedora this will be the most
recent stable upstream minor release, for EPEL it will be the minor
release of 2 that came with the distro, so 2.4 for EPEL5)
- an rpm with a "python3-" prefix means a python 3 rpm, of the
"default" python 3 minor version (for Fedora this will be the most
recent stable upstream release)
(we could extend this to have specific minor-releases (e.g. use
"python24-" for a python 2.4 stack, in case some brave soul wants to get
zope/plone running. But may be better to try to fix the zope/2.6
incompatibility at that point (caveat: haven't looked at the details of
the issue). I don't intend to work on such versions))
What about packages without a "python-" prefix? Proposal: If upstream
has a naming convention for python2 vs python3, use it. Otherwise, add
a "python3-" prefix to make things clear. I'm not sure about the
details here. Examples?
There have been various discussions upstream about what to call the
python 3 binary. My favorite quote on the subject is from Guido,
http://mail.python.org/pipermail/python-3000/2008-March/012421.html :
> During the next 3 years or so, installing Py3k as the default "python"
> will be a deed of utter irresponsibility and is likely to break your
> system in subtle ways (both OSX and Linux these days use Python for
> certain system tasks). If you *really* want to shoot yourself in the
> foot this way, go ahead and explicitly use "make altinstall
> bininstall" or link it yourself.
I propose that for Fedora we have "/usr/bin/python3" for the
system/default version of python 3 and "/usr/bin/python" for the
system/default version of python 2. Both would be symlinks to a binary
with the minor-release embedded in the name ("/usr/bin/python3.1" and
"/usr/bin/python/2.6").
As I understand things, this should make us broadly in agreement with
upstream; see e.g.:
http://mail.python.org/pipermail/python-dev/2009-April/088862.html
http://mail.python.org/pipermail/python-dev/2009-April/088884.html
A rough plan for Fedora 13 might be:
- get python3 packaged in a manner compatible with the above
- (persuade /usr/lib/rpm/brp-python-bytecompile to use the correct
python when building rpms containing .py files)
- get rpm bindings working with python3
- get some useful components working e.g. a web stack: Django,
TurboGears etc (though e.g. Django's py3k support is a long way off
IIRC); ideas?
- solidify packaging guidelines for python 2 vs python 3 once we've
got some experience with the above and hopefully proven the techniques
- look at porting major components over to python3 (but probably don't
actually do this for F13; leave python 2 as the critical component, I
suspect):
- yum (rpm)
- anaconda
However "no plan survives contact with the enemy", we'll see how things
turn out in reality when trying to get a full integrated stack working.
Future work (F14?) could involve cutting over the major components, so
that the base install would bring in "python3", and "python" would
become optional. Obviously there's a _lot_ to be done before that can
be done sanely.
= Progress so far =
I've put together a somewhat-working python3 srpm, based on the python
srpm (with lots of FIXMEs added...) It's not yet ready for a formal
package review (I'm working through the various patches, and it's not
yet fully installable in parallel with the python 2 stack), but you can
see the specfile here:
http://people.redhat.com/dmalcolm/python3/python3.spec
and an SRPM here:
http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm
After I did this work, I saw that a couple of other people have written
Python 3 srpms for Fedora:
http://ivazquez.fedorapeople.org/packages/python3000/
and
https://bugzilla.redhat.com/show_bug.cgi?id=526126
and there was this proposal for doing Python 3 in F10:
https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
similar to this one. Obviously I want to work with those people to come
up with a working python 3 rpm in Fedora.
There's also the merge-review for python:
https://bugzilla.redhat.com/show_bug.cgi?id=226342 ; many of the
comments there would thus also apply to my srpm, given that I used the
former as my starting point.
On a tangent: we currently have 2.6.2 in F12/rawhide. Upstream is
preparing a 2.6.3 release, with many bugfixes. This seems to me like a
candidate for F13. (the release notes for the 2.6.3 rc are long; I'd
want it to have a _lot_ of testing before pushing it to F12))
Thoughts?
Dave
[1] I'm being transferred at work, and will be able to spend a lot of
time on Python within Fedora. Previously, my job involved keeping
various internal RH systems working (with any Fedora work done
afterhours or as a side project). Having said that, I'm about to go on
vacation with no access to a computer for the period October 3rd-10th
14 years, 6 months
libprojectM Packaging Problem
by Jameson
I'm having trouble getting the new version of libprojectM packaged,
and hope someone can shed some light on this for me. When I enter the
commands to build it manually, it builds fine, but when trying to
package it, it comes out with commands like:
cd /home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295/Renderer &&
/usr/lib64/ccache/c++ -DUSE_FBO -DLINUX -DSTBI_NO_DDS -DUSE_THREADS
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic ;-fPIC
-I/home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295
-DCMAKE_INSTALL_PREFIX="\"/usr\"" -o CMakeFiles/Renderer.dir/FBO.o -c
/home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295/Renderer/FBO.cpp
Which fail due to ;-fPIC. Any ideas on why this is happening? It
looks to me that it's a simple matter of getting rid of the ; in the
command, but I have no idea why it's there using rpmbuild, but not
when I build manually.
Thanks,
=-Jameson
14 years, 6 months