gmane.linux.redhat.fedora.python

libpython2.7.so, /usr/lib or /usr/lib64, Liquid error parsing markdown

Nick Fenwick — 2012-05-01T04:47:53

Hi all,

I'm a first time poster looking for guidance about what seems to be a 
configuration or packaging problem on my system. I'm running Octopress, 
a blogging framework in Ruby, which uses Liquid running via Python to 
parse some embedded code blocks into a pretty format.

Environment:
Fedora Core 16 - 3.3.2-6.fc16.x86_64
python-2.7.2-5.2.fc16.x86_64
ruby 1.9.2p320 (2012-04-20 revision 35421) [x86_64-linux]
rvm 1.13.0 (stable) by Wayne E. Seguin

Liquid failed out of the box with a codeblock that tried to use .html or 
.js suffixes, with a rather unhelpful error message in the blog post 
being formatted:

Liquid error: undefined method `Py_IsInitialized’ for 
RubyPython::Python:Module

Googling for this error led me to many other Octopress blogs (and 
others) with this error. They've deployed broken blog posts unwittingly 
(I hope).

I found that I have /usr/lib64/libpython2.7.so but nothing in /usr/lib. 
Some google results led me to try:

ln -s /usr/lib64/libpython2.7.so /usr/lib/libpython2.7.so

This immediately fixed the Liquid error, and I'm able to generate my 
blog, Liquid works. Hurrah.

I know very little about 64 bit packaging, whether this is likely to be 
a python packaging problem or something in Liquid, rubypython, ruby, or 
octopress that's failing to find the correct libpython2.7.so.

Where should I look next?

Thanks all
Nick
_______________________________________________
python-devel mailing list
python-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Bug #787712 threaded python deadlocks

Warren Togami Jr. — 2012-02-24T09:32:40

Hey folks,

https://bugzilla.redhat.com/show_bug.cgi?id=787712
I am hitting this bug very frequently on Fedora 16 where python deadlocks.
 I tried to apply the patch in this bug to python.src.rpm currently in
Fedora 16, but my local rpmbuild fails with a test error.  After disabling
%check rpmbuild fails with these missing files:

    File not found:
/home/warren/rpmbuild/BUILDROOT/python-2.7.2-5.2.fc16.fork.x86_64/usr/lib64/python2.7/lib-dynload/ossaudiodev.so
    File not found:
/home/warren/rpmbuild/BUILDROOT/python-2.7.2-5.2.fc16.fork.x86_64/usr/lib64/python2.7/plat-linux2

It seems python is missing some BuildRequires.

Anyhow, who maintains python these days?  Could we please go ahead with a
F16 test update?  This is a pretty serious issue. =(

Warren Togami
wtogami-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
_______________________________________________
python-devel mailing list
python-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Help with a simple package

Caghan Demirci — 2012-02-09T02:40:05

  Hi everyone,

  I wonder if someone would be interested in releasing a simple Fedora
package for EPEL.  In my estimate, it shouldn't take more than an hour.  I
would do it myself, but I need to go through the whole process of getting
into FAS, and it's not worth the trouble for just an hour of real work.
  I am asking for the "nautilus-python" package.  The EPEL owner is listed
as dignan under
https://admin.fedoraproject.org/pkgdb/acls/name/nautilus-python, and I
think there is already an EPEL branch for nautilus-python.  However, I
can't find an EPEL build for nautilus-python.  See RepoView, for example:
http://dl.fedoraproject.org/pub/epel/6/SRPMS/repoview/letter_n.group.html.
And I haven't been able to reach dignan.
  nautilus-python versions up to 0.7.0-3 should work under both RHEL 5 and
RHEL 6 without any modifications.  Versions 0.7.0-4 and higher won't work
under RHEL 5 or RHEL 6 because they require Nautilus 3.
  I already created a bug for this (
https://bugzilla.redhat.com/show_bug.cgi?id=771262) and I have been trying
to get people's attention, but no one seems to be interested in some good
karma. :)

  Thanks in advance and best wishes!

  -Caghan
_______________________________________________
python-devel mailing list
python-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

python-sqlite2 retirement/orphaning

Toshio Kuratomi — 2012-02-07T18:08:03

In cleaning up some half-retired packages yesterday, we discovered that
the python-sqlite2 maintainer wishes to retire the package.  There are a few
packages that depend on it but after reviewing the history and the code of
the packages, I think that it is reasonably safe to let this go ahead.

Historically, there was a python-sqlite module.  This version is not required
by any of the code we ship now.  It was replaced by python-sqlite2 (in
python, this is import pysqlite2).  In python-2.5, this library entered the
python stdlib as sqlite3 (import sqlite3).  The pysqlite2 library continues
to be released outside of the stdlib, mainly so that people who want to get
changes to the module (perhaps bugfixes or optimizations) at a faster rate
than the python stdlib's release cycle are able to.

In Fedora, there are several packages that have an explicit:
  Requires: python-sqlite2

I've reviewed the code for all of them and discovered that most will try to
import sqlite3 from the stdlib if pysqlite2 is not present.  Likely, these
just need to have the Requires: python-sqlite2 removed and the package is
then rebuilt:

* anki
* supybot-gribble
* bibus
* conduit
* firmware-extract
* gourmet
* griffith
* hamster-applet
* mysql-workbench
* python-tg-devtools
* python-sqlobject
* roundup
* sigul
* transifex
* trytond-sqlite
* yokadi
* python-keystone

There is one package that actually has a code dependency on pysqlite2.  I've
submitted a patch and asked someone I know who uses the package to test it:

* plague https://bugzilla.redhat.com/show_bug.cgi?id=788189

There are two packages that have a requirement on sqlite but don't actually
have any code that uses it:

* synce-sync-engine --  Looks like it may have at one time but has been ported
  to a lighterweight, internal, picklable data struct instead.

* poky-depends -- This is supposed to be a metapackage:
    The poky-depends is to ensure all the required packages are installed to
    build poky images. Please note that this only installs the dependency
    packages.
    If you want to build images, you will need to download Poky. Please refer:
    http://pokylinux.org/getit/
    http://pokylinux.org/support/
  I'll have to talk to the poky-depends maintainer to find out if the poky
  upstream works with sqlite3 from the stdlib since we aren't actually
  shipping the poky code... just this package that installs the
  dependencies.

If it seems acceptable to everyone involved, I'll go ahead and modify and
rebuild the packages in the first group for F17/rawhide.  I'll continue to
work on porting plague and contact the maintainers of synce-sync-engine and
poky-depends to see if it's okay to remove their deps.  Once all that's
done, I'll finish up the retire package process for the python-sqlite2
maintainer.

If people want to keep the python-sqlite2 package around, I'd strongly
suggest they volunteer to take over maintainance of the package so the
current maintainer can release ownership to them.

Thanks,
-Toshio
_______________________________________________
python-devel mailing list
python-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

More Re: [Distutils] Compatibility of bdist_rpm with Fedora packaging instructions

Stanley A. Klein — 2011-11-27T17:05:08

One additional issue:  The system produces pyo and pyc files for all the
.py files it finds.  That is good for the files that go into site-packages
because they are intended to be executed from there, but might not be so
good for documentation files such as examples and code-snippets that are
intended to be run or otherwise used in user-space.

The commands:
find . -type f -name *.pyc  -exec rm -f {} \;
find . -type f -name *.pyo  -exec rm -f {} \;

executed at some point in the process at the root of the default
documentation directory after the .pyc and .pyo files have been created
can remove them.  However, I can't seem to figure out where to put the
statements.  Also, might there be a way to prevent the byte compiling of
documentation files?


Stan Klein


_______________________________________________
python-devel mailing list
python-devel< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Cryptographic tweaks in python/python3 in rawhide (F17)

David Malcolm — 2011-09-14T21:15:33

Summary: most users shouldn't see any differences, but rawhide's python
should now better support OpenSSL FIPS mode, as of python-2.7.2-14.fc17
and python3-3.2.2-5.fc17 onwards.

Long version:
I've just built some tweaks to python's cryptographic code in rawhide,
aimed at making it play better with FIPS mode.  It's actually a forward
port of some code that's been in RHEL 6's python 2.6 since RHEL 6.0
(where it was was rhbz#563986).

The idea is that in high-security environments, it's possible to set
site-wide configuration to deny the use of known insecure cryptographic
algorithms.

The main example here is MD5.  MD5 is past its "use-by date", and should
not be used for security purposes.  See e.g.:
  http://www.kb.cert.org/vuls/id/836068

In the past, Fedora build of the python 2 standard library has contained
the following modules:

  Pure python modules:

    * hashlib (implemented in terms of _hashlib)
    * md5 (implemented in terms of _hashlib, falling back to _md5)
    * sha (implemented in terms of _hashlib, falling back to _sha256,
_sha512,
      _sha as appopriate)

  C module wrapping OpenSSL:

    * _hashlib

  Modules with pure C implementations of certain crypto hash algorithms:
    * _md5
    * _sha256
    * _sha512
    * _sha

As of python-2.7.2-14.fc17, I've dropped the final four modules above;
instead, all crypto code within our build of python's stdlib is
implemented in terms of _hashlib, and thus OpenSSL.

Similarly python3-3.2.2-5.fc17 drops the final four modules.

There is a slight risk that this will break any code that uses "_md5"
etc directly, but such code shouldn't be using those modules: they
should use the analogous API entrypoints in either md5/sha or hashlib
instead.  (Potentially this could lead to hardware acceleration of the
hash computation).

I've also fixed things so that the remaining modules do the right thing
in FIPS mode.

In the past, if you ran python with OPENSSL_FORCE_FIPS_MODE=1 in the
enviroment, the _hashlib module would segfault when used with a broken
crypto hash algorithm.  I've now fixed this so that an exception will be
raised when using bad algorithms:

In normal mode:
  $ python -c "import hashlib; m = hashlib.md5(); m.update('abc'); print
m.hexdigest()"
  900150983cd24fb0d6963f7d28e17f72

In FIPS mode:
  $ OPENSSL_FORCE_FIPS_MODE=1 python -c "import hashlib; m =
hashlib.md5(); m.update('abc'); print m.hexdigest()"
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  ValueError: error:060800A0:digital envelope
routines:EVP_DigestInit_ex:unknown cipher
(previously, this case would segfault)

[Note that you may need to turn off prelinking, and undo any prelinking
that may have occurred for FIPS mode to work: sudo prelink -u --all ]

If you're using FIPS mode but have some legacy non-security purpose for
MD5 (e.g. hash buckets for optimization, not security), I've added a
non-standard optional keyword argument: usedforsecurity=True, which you
can override to False to mark a callsite as non-security sensitive, and
thus keep using MD5 at audited callsites:

  $ OPENSSL_FORCE_FIPS_MODE=1 python -c "import hashlib; m =
hashlib.md5(usedforsecurity=False); m.update('abc'); print
m.hexdigest()"
  900150983cd24fb0d6963f7d28e17f72

I've sent a version of this upstream for Python 3 as
http://bugs.python.org/issue9216

Hope the above makes sense (and that I didn't break anything)
Dave

python-distutils-extra for EPEL?

Matt Domsch — 2011-08-30T20:58:16

Is anyone in the Python SIG interested in maintaining
python-distutils-extra in el6?  The Fedora maintainer has declined to
participate in EPEL, but would welcome someone else doing so.  The
rawhide copy builds clean in koji against el6 right now, so it
shouldn't be that hard to maintain.

This is needed by openstack-nova, which the Cloud SIG is in process of
packaging for Fedora and EL6.

Thanks,
Matt

Need a python3 person for docutils

Toshio Kuratomi — 2011-05-16T16:08:07

Hey all, Currently docutils is unable to update in Fedora 15 because of bugs
in the python3 compatibility.  Is there anyone who cares about python3 here
who is willing to take a look at fixing it?  Otherwise, we're stuck on the
current version of docutils (for both python2 and python3) and the python3
package will be non-functional.

https://bugzilla.redhat.com/show_bug.cgi?id=579567

-Toshio

the difference of "exec" and "import" in python

tom z — 2011-05-03T08:16:37

Hi~ all guys,
I have a strange question, what's the difference of "exec" and "import"?
IMO, when we use "import", the script is also be executed, (maybe its
namespace is owned by itself), and "exec" does something like this, it
executes some script. So i think its difference is its namespace.
I want to get your hint~

thanks a lot

how to include a .so file in my python rpm

Erik Blankinship — 2011-01-26T13:59:40

In my python application, I need to include a .so binary I built of a custom
gstreamer plugin.  My python application works fine with this plugin when
launching from the command line.

Now that I am packaging my python application into a fedora rpm, I need to
compile the plugin as part of the packaging process?

I ask because when I try to include the .so file in %files and part of the
manifest, I get this error from rpmbuild:

"arch dependent binaries in noarch package"

Could someone point me to an example of how to create a spec file which
shows how to include "nested" c code so as to avoid this error and
successfully build my rpm?

Thanks much.  Erik

how to include lots of media assets into a python rpm?

Erik Blankinship — 2011-01-25T02:02:55

I have a lot of media assets to include in my python rpm.  I am confused as
to the best way to include these files in my rpm.

Here is my setup:

setup.py
sun.py
gfx/sun_1.png
gfx/sun_2.png
gfx/sun_3.png
gfx/core/core_1.png
gfx/core/core_2.png
...
gfx/core/core_99.png


I list everything I want to include in my manifest.in file with:

recursive-include gfx *.png


and when I make a source tar.gz ( via python setup.py bdist --format=rpm )
 all of the media assets are included in the resultant tar.gz bundle.

Then I move the source tar.gz into ~/rpmbuild/SOURCES/  and then I run rpmbuild
-ba SunnyApp.spec

Unfortunately, none of the gfx are transfered over.   However, if I modify
my setup.py as follows:

from setuptools import find_packages

pkgs = find_packages( )


setup(   name='SunnyApp',
         ...

         data_files=[ ('SunnyApp/gfx', ['gfx/sun_1.png', 'gfx/sun_2.png'] ),

                      ('SunnyApp/gfx/core', ['gfx/core/core_1.png',
'gfx/core/core_2.png'] ) ],

         ...

         packages=pkgs,

         ....

         )


Only those files that I list make it into the rpm (in this case sun_1.png,
sun_2.png, core_1.png, core_2.png)  Unfortunately, there does not appear to
be a way to include *.png for all subdirectories in gfx.

Is there a way to include lots of files with a pattern when calling
rpmbuild?  I am not sure how to use package_data to list wildcards because
of how I am using packages=find_packages( )

Any suggestions?  Thanks much.

best practices for python applications targeting f11 gnome on theolpc xo

Erik Blankinship — 2011-01-24T21:57:34

What would be the best practice for python applications targeting f11 gnome
on the olpc xo?

I am developing on f13, but my target is f11 (an olpc xo machine) running
python 2.6.

The rpms I am generating have the name:

SunnyApp-1.1-1.fc13.noarch.rpm

Two things here stand out to me (the very new rpm packager) which suggest I
have not done a great job targeting my platform.

1. fc13
2. noarch

I would like to make sure the rpms are as compatible as possible with that
platform.

Also, I have some code in my application which is python 2.6 specific -- is
there a way to designate/enforce that in the file to ensure it runs
smoothly?

Thank you!

packing an rpm without source code?

Erik Blankinship — 2011-01-24T04:36:27

Can someone point me at an example of how to package a fedora python rpm
without the source code (only the .pyc or .pyo files)?

Would I make this change in my spec file?

Thank you for your help.

help: Doc of the rpm-python module

tom z — 2011-01-06T08:16:24

Hi all,
  I can't find any doc of rpm-python. If you have one, could you send a copy
to me?
Thanks a lot~

FYI: Python-2.7 distutils incompatibility

Toshio Kuratomi — 2011-01-04T02:23:56

I mentioned this to dmalcolm as a possible bug on IRC and as I figured out
what's going on I felt I should share with others that might run into this.

In python-2.7, an incompatibility was introduced in what is allowed to be in
a setup.py file.  A setup.py looks something like this::

  #!/usr/bin/python -tt
  # -*- coding: utf-8 -*-

  from distutils.core import setup

  setup(name='test',
      version='1.0',
      description='Test',
      author='Toshio Kuratomi',
      author_email='toshio< at >fp.o',
      license='MIT',
      url='http://localhost/',
      download_url='http://localhost/',
      keywords='test',
      classifiers=[
            'Development Status :: 3 - Alpha',
          ],
  )

In python-2.7, the values of those entries to the setup function cannot be
unicode strings.  They must be byte strings (str type).  This is true even
if the value is all ASCII.  For instance, this is invalid::

  setup(name=u'test', [...]

Although this is a change in behaviour from earlier python versions, it is
now a documented behaviour (see the notes section of this link:
http://docs.python.org/distutils/setupscript.html#additional-meta-data ) so
it's not a bug, it's a feature ;-)

-Toshio

PyPy is now available in Fedora

David Malcolm — 2011-01-03T22:20:00

I've imported pypy and built it into rawhide.

I've updated the list on:
https://fedoraproject.org/wiki/SIGs/Python#Python_Runtimes

moving it from "Awaiting review" to "Within Fedora".

Enjoy!
Dave

My email

Abdel G. Martínez L. — 2010-11-04T16:24:57

abdel.g.martinez.l-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

python-distutils-extra

Luke Macken — 2010-10-29T21:45:09

Just a heads up to some new behavior that I noticed in F14.

When python-distutils-extra is installed, it will cause pylint to be run
against your project automatically when `python setup.py sdist` is
called.  It installs DistUtilsExtra.command.check on the
distutils.commands check entry-point.

This shouldn't be a problem in koji-land, since nothing currently pulls
this in at build time.

This turns out to be an annoyance for me, since it causes an infinite
recursion error with one of my projects.  Whether or not we want to
patch this behavior out is still up for discussion.

luke

(unknown)

Toshio Kuratomi — 2010-10-21T18:33:16

For those who aren't also subscribed to the python-dev mailing list :-),
Dave and Neal's posts about fpconst sparked some interest in porting work
there.  Talking with Barry Warsaw we'd like to use the
python-porting-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org mailing list to coordinate efforts to port so that
distros can help each other with this task rather than everybody reinventing
the same patches:

http://mail.python.org/mailman/listinfo/python-porting

There's also a few wiki pages on wiki.python.org that we've decided to use
as well:

http://wiki.python.org/moin/PortingToPy3k/
http://wiki.python.org/moin/PortingToPy3k/PortingHelpers

It's a wiki so feel free to edit information, post scripts to the mailing
list to gather information, etc.  Right now I'm in brainstorming mode but we need to
figure out some ways to make actual progress on the code too.  For that we
need to figure out how to submit code upstream and how/when to fork if
upstreams are dead, etc.

-Toshio

(unknown)

Toshio Kuratomi — 2010-10-21T18:33:16

Wiki gardening

David Malcolm — 2010-09-30T18:38:08

As I mentioned on IRC yesterday, I've moved the huge tables showing
Python 3 status from:
 https://fedoraproject.org/wiki/Features/Python3F13#Porting_status

to a new page:
 https://fedoraproject.org/wiki/Python3

(rather than have it be specific to Fedora 13)

I've tried to preserve the barebones structure of that section on the
old page, since there are a few links to those places elsewhere.


I've also tried to add:
  [[Category:Python]]
to various pages that were missing it (including various feature pages
that relate directly to python).

You can see the pages tagged with this category here:
  https://fedoraproject.org/wiki/Category:Python

In particular, there's a link to that page from the bottom of our SIG
page:
  https://fedoraproject.org/wiki/SIGs/Python

If I've missed any, please feel free to add the:
  [[Category:Python]]
tag to other python-related pages.


Hope this makes sense
Dave