Bohuslav Kabrda | 23 May 08:06
Picon
Favicon

Introducing pyp2rpm - A python package to rpm specfile convertor

Hi all,
for past few days, I've been working on a project called pyp2rpm. It's a tool that allows you to easily
convert python package from PyPI to an RPM specfile. I would like to get it tested before I package it into
Fedora, so if anyone is interested, here are the links:

http://pypi.python.org/pypi/pyp2rpm
https://bitbucket.org/bkabrda/pyp2rpm

You can install pyp2rpm by running "easy_install pyp2rpm" or "pip-python install pyp2rpm".

I will be glad for any comments/suggestions for improvement (including comments like "hey, I don't
understand your readme nor help and I don't know how to use that!", which is why i intentionally didn't put
any information about usage here :) ).

Thanks!

--

-- 
Regards,
Bohuslav "Slavek" Kabrda.
_______________________________________________
python-devel mailing list
python-devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Nick Fenwick | 1 May 06:47
Gravatar

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

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 
(Continue reading)

Warren Togami Jr. | 24 Feb 10:32
Picon

Bug #787712 threaded python deadlocks

Hey folks,


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
_______________________________________________
python-devel mailing list
python-devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Caghan Demirci | 9 Feb 03:40
Picon

Help with a simple package


  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
Toshio Kuratomi | 7 Feb 19:08
Picon
Gravatar

python-sqlite2 retirement/orphaning

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
Bohuslav Kabrda | 18 Jan 10:38
Picon
Favicon

Django packages - proposed name changes

Hi Pythonists!
in RHBZ #736776, Yury V. Zaytsev proposed renaming all Django packages (including Django itself) to
python-django-*. This change is suggested because of current inconsistent state: Django and
Django-south packages start with capital letters, other Django extension libraries start with
lowercase letters - django-*. Also, since Django is a Python framework (not a standalone app), all of the
modules should have 'python-' prepended. Personally, I agree with Yury and I think we should make this
change. Here are the steps that I propose:
- discuss it on this list
- ask FPC what they think
- create a special section in Python packaging guidelines for packaging Django extensions/libraries, if
we agree that we should do this change
- perhaps postponing this change to F18 might be a good idea

Note, that this change should not affect applications written in Django, only Django itself and its
extensions/libraries. I would also consider using some kind of virtual provides, so that if someone
types "yum install django", it will work - maybe each Django extension/library could have a virtual
provide like "Provides: django(foo) = %{version}".

So, what do you think?

Regards,
Bohuslav.
_______________________________________________
python-devel mailing list
python-devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
Stanley A. Klein | 27 Nov 18:05

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

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
Stanley A. Klein | 26 Nov 20:00

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

Tarek -

Thanks.

I got it working and want to document some of my findings.  I'm cc:'ing
the Fedora Python list so they can take these issues into account in their
Python packaging instructions.  My findings are as follows:

1.  The source code management system was git.  I needed to install
setuptools-git to get files recognized that were being maintained under
git.

2.  I also needed to establish a MANIFEST.in file to ensure all relevant
files were included.

3.  The setup.cfg statement under [bdist_rpm] of "doc_files =" doesn't
work if there are directories involved.  This is a documented "gotcha" in
http://fedoraproject.org/wiki/How_to_create_an_RPM_package

They also advise avoiding use of INSTALLED_FILES.

Here is what I used in the spec file (it had to be edited for the
directories to be included in docs):

%install
python setup.py install --root=$RPM_BUILD_ROOT
cd $RPM_BUILD_ROOT
mkdir -p %{buildroot}%{_defaultdocdir}/%{name}-%{version}/
mkdir -p %{buildroot}%{_defaultdocdir}/%{name}-%{version}/docs
mkdir -p %{buildroot}%{_defaultdocdir}/%{name}-%{version}/examples
cd  %{_builddir}/%{name}-%{version}
cp -p *.txt %{buildroot}%{_defaultdocdir}/%{name}-%{version}/
cp -rp docs/ %{buildroot}%{_defaultdocdir}/%{name}-%{version}/docs
cp -rp examples/ %{buildroot}%{_defaultdocdir}/%{name}-%{version}/examples

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
%{_defaultdocdir}/%{name}-%{version}/
%{python_sitelib}/%{name}/
%{python_sitelib}/%{name}-%{version}-py%{python_version}.egg-info/

4.  The overall approach I used was to run

$ python setup.py --command-packages=pypi2rpm.command bdist_rpm2
 --spec-only

That brought in items such as the description specified in setup.py.  I
then moved the spec file up a directory level from dist, edited in the
above parts relevant to the doc files, and finally ran

$ python setup.py --command-packages=pypi2rpm.command bdist_rpm2
> --spec-file=SPECFILE

I also found it very useful to actually run

python setup.py --command-packages=pypi2rpm.command bdist_rpm2 --spec-file
SPECFILE   >buildout 2>&1

Recording the build output enabled me to find details of errors that
occurred during the build.  There were a number of those, and the output
flies by too quickly to notice them for diagnosis of problems that need to
be fixed.  (an approach I've also used in the past is to tee the output,
so I can see if the build was successful when it completes).  Also, the -k
option came in useful in figuring out the documentation-related fixes to
the spec file, because it helped seeing what was included in the build and
what was available in the build but not getting copied to the install.

5.  I inquired about how the project produced its sdist files for pypi,
and was told that they had so many problems related to their switch to git
that they simply did a gzipped tar of their repository.

6.  The project used a different extension on their README file from the
expected values of README and README.txt.  I needed to change that to
README.txt to get it to process properly.

Again, thanks.

Stan Klein

On Fri, November 11, 2011 6:00 am, Tarek Ziad? <ziade.tarek <at> gmail.com> wrote:

>
> Message: 3
> Date: Thu, 10 Nov 2011 18:42:08 +0100
> From: Tarek Ziad? <ziade.tarek <at> gmail.com>
> To: "Stanley A. Klein" <sklein <at> cpcug.org>
> Cc: distutils-sig <at> python.org
> Subject: Re: [Distutils] Compatibility of bdist_rpm with Fedora
> 	packaging	instructions
>
> On Thu, Nov 10, 2011 at 6:11 PM, Stanley A. Klein <sklein <at> cpcug.org>
> wrote:
>> Tarek -
>>
>> I downloaded pypi2rpm and built it using bdist_rpm.
>
> you built it ? pypi2rpm is a script and a bidist_rpm2 command, no need
> to build, just install
>
>
>> ?The instructions on how to use it are rather thin.
>
> Yes there's no doc, as its mostly use in our own build tools for now.
>
>> My best guess is to run it in spec-only
>> mode, modify the spec, and then run it with the modified spec specified.
>> I tried to get a help listing but that was also think and I couldn't
>> quite
>> figure out how to run it.
>>
>> Could you provide further information on how to use it.
>>
>> Thanks.
>
> Once it's installed you can build a rpm in your project, using:
>
> $ python setup.py --command-packages=pypi2rpm.command bdist_rpm2
> --spec-file=SPECFILE
>
> (there are other options you can find with --help)
>
>
>>
>> Stan Klein
>>
>>
>>
>> On Thu, November 10, 2011 5:06 am, Tarek Ziad? wrote:
>>> On Thu, Nov 10, 2011 at 10:04 AM, Paul Nasrat <pnasrat <at> gmail.com>
>>> wrote:
>>>> I don't think bdist_rpm should track vendor packaging requirements,
>>>> purely as those recommendations may change faster than the release
>>>> process of distutils. I also believe bdist_rpm may be going away in
>>>> the future:
>>>
>>> Yes I confirm this. We removed it in packaging because we believe it
>>> should be maintained by the RPM communities -- with their own release
>>> cycles etc.
>>>
>>> FWIW I have a custom version in the pypi2rpm project where I just feed
>>> a .spec file to the bdist_rpm command, so I can do proper RHEL or
>>> Fedora packaging.
>>>
>>>> For Fedora have you considered rpmdev-newspec which can creates a
>>>> templated python spec file for your packages.
>>>>
>>>> http://fedoraproject.org/wiki/How_to_create_an_RPM_package
>>>>
>>>> Paul
>>>>
>>>> On 8 November 2011 21:40, Stanley A. Klein <sklein <at> cpcug.org> wrote:
>>>>> I will need to build some Python packages for Fedora and Centos. ?The
>>>>> spec
>>>>> file produced by bdist_rpm automatically includes the statement
>>>>> %files -f INSTALLED_FILES
>>>>>
>>>>> The Fedora Python packaging instruction includes a recommendation to
>>>>> avoid
>>>>> use of INSTALLED_FILES and provides some alternatives. ?That is the
>>>>> first
>>>>> incompatibility I've encountered, but there may be more.
>>>>>
>>>>> The bdist_rpm code probably should be changed to enable
>>>>> compatibility.
>>>>> Meanwhile, is there a workaround?
>>>>>
>>>>>
>>>>> Stan Klein

_______________________________________________
python-devel mailing list
python-devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
David Malcolm | 14 Sep 23:15
Picon
Favicon

Cryptographic tweaks in python/python3 in rawhide (F17)

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

Matt Domsch | 30 Aug 22:58
Picon
Favicon

python-distutils-extra for EPEL?

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

--

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO
Toshio Kuratomi | 16 May 18:08
Picon
Gravatar

Need a python3 person for docutils

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

Gmane