Bug 476600 - Review Request: python-ZODB3 - Zope Object Database: Object Database and Persistence
Summary: Review Request: python-ZODB3 - Zope Object Database: Object Database and Pers...
Keywords:
Status: CLOSED DUPLICATE of bug 629027
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 468222 476523 476524 476525 476526 476527 476528 476599
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-16 01:23 UTC by Conrad Meyer
Modified: 2013-01-08 22:49 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-31 18:03:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to fix incorrect python shebang (344 bytes, patch)
2010-06-18 20:40 UTC, Nathaniel McCallum
no flags Details | Diff

Description Conrad Meyer 2008-12-16 01:23:11 UTC
Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/python-ZODB3.spec
SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/python-ZODB3-3.9.0-0.1.a7.fc9.src.rpm
Description:
The Zope Object Database provides an object-oriented database for Python
that provides a high-degree of transparency. Applications can take
advantage of object database features with few, if any, changes to
application logic. ZODB includes features such as a plugable storage
interface, rich transaction support, and undo.

Comment 1 Mads Kiilerich 2009-10-28 00:50:16 UTC
An informal walkthrough of the spec file from a wannabee-packager:

Mock build fails.

Why group Development/Languages when it isn't a language? I would assume Development/Libraries would fit better.

URL should point to a version-independent site, I guess that it should be http://pypi.python.org/pypi/ZODB3/ instead.

Unused BuildRequires should not just be commented out. Remove them if they are invalid.

The packages for python-zope-proxy and python-zdaemon are not available in rawhide, so this package can't be properly reviewed yet.

Source should not be modified in %prep; it is a kind of build process and belongs in %build. Has this problem with invalid hash-bangs been filed and discussed upstream?

I am not familiar with CFLAGS combined with setup.py. I assume that the right flags from python-devel is used automatically. I think the python-numeric package is similar to this one in many ways, and even though it does many things wrong it can perhaps be used for reference: It do not list CFLAGS. Can you reference any documentation or prior art from other packages?

The mv code in %install seems overly complex and clever. 
Couldn't it be written as
  mv $RPM_BUILD_ROOT%{_bindir}/{fsdump,fsoids,fsrefs,fstail,mkzeoinst,repozo,runzeo,zeoctl,zeopack,zeopasswd} \
    $RPM_BUILD_ROOT%{_libexecdir}/%{name}/
or just
  mv $RPM_BUILD_ROOT%{_bindir}/* $RPM_BUILD_ROOT%{_libexecdir}/%{name}/
?

A %check section should either be there or not - not just contain a disabled checkout without further comments.

When building I notice an error which should be fixed:
byte-compiling /home/mk/rpmbuild/BUILDROOT/python-ZODB3-3.9.0-0.1.a7.fc12.i386/usr/lib/python2.6/site-packages/ZEO/scripts/zeoserverlog.py to zeoserverlog.pyc
SyntaxError: ('invalid syntax', ('/usr/lib/python2.6/site-packages/ZEO/scripts/zeoserverlog.py', 374, 6, '    as = []\n'))

rpmlint output:
python-ZODB3.i686: W: devel-file-in-non-devel-package /usr/lib/python2.6/site-packages/persistent/*.[ch]
python-ZODB3.i686: W: devel-file-in-non-devel-package /usr/lib/python2.6/site-packages/BTrees/*.[ch]
python-ZODB3.i686: W: devel-file-in-non-devel-package /usr/include/python2.6/ZODB3/*.h
3 packages and 1 specfiles checked; 0 errors, 34 warnings.
The include files should perhaps go to a -devel package, and I guess the rest of the files shouldn't be there at all.
/usr/include/python2.6/ZODB3 should be in a package which requires python-devel which owns /usr/include/python2.6/

It seems like this package contains 4 quite independent python modules. Consider putting them in independent packages: python-BTrees python-persistent python-ZEO python-ZODB

Hmm ... this brief review ends up being longer than the spec. IMHO there are too many issues here. The packager should have worked more with the package before filing a review request.

Comment 2 Conrad Meyer 2009-10-28 01:25:56 UTC
(In reply to comment #1)
> Mock build fails.

Against what? Rawhide? Fedora 11? Fedora 10? As you noted lower down in your initial review, there's a Python 2.6 incompatibility in this (Fedora 9!) package. I will update to the newer version later today, which should fix this issue.

> Why group Development/Languages when it isn't a language? I would assume
> Development/Libraries would fit better.

Many Python libraries are Development/Languages (the default in the rpmdev-spec template for python packages). In my personal opinion, RPM Group tags are totally useless at this point, and accordingly I don't have a strong opinion on this.

> URL should point to a version-independent site, I guess that it should be
> http://pypi.python.org/pypi/ZODB3/ instead.

ACK.

> Unused BuildRequires should not just be commented out. Remove them if they are
> invalid.

ACK.

> The packages for python-zope-proxy and python-zdaemon are not available in
> rawhide, so this package can't be properly reviewed yet.

What you mean to say is "fully", not "properly". This package can't be approved yet, but it can certainly go through most of the review process.
 
> Source should not be modified in %prep; it is a kind of build process and
> belongs in %build. Has this problem with invalid hash-bangs been filed and
> discussed upstream?

This is complete fiction. %prep is the place for modifying source -- patches, sed scriptlets, etc go here. Nothing has been filed upstream, because it's fairly minor change IMO. I would be glad to contact upstream about it if that's a blocker.

> I am not familiar with CFLAGS combined with setup.py. I assume that the right
> flags from python-devel is used automatically. I think the python-numeric
> package is similar to this one in many ways, and even though it does many
> things wrong it can perhaps be used for reference: It do not list CFLAGS. Can
> you reference any documentation or prior art from other packages?

file:///etc/rpmdevtools/spectemplate-python.spec (if you have the rpmdevtools package installed).

> The mv code in %install seems overly complex and clever. 
> Couldn't it be written as
>   mv
> $RPM_BUILD_ROOT%{_bindir}/{fsdump,fsoids,fsrefs,fstail,mkzeoinst,repozo,runzeo,zeoctl,zeopack,zeopasswd}
> \
>     $RPM_BUILD_ROOT%{_libexecdir}/%{name}/
> or just
>   mv $RPM_BUILD_ROOT%{_bindir}/* $RPM_BUILD_ROOT%{_libexecdir}/%{name}/
> ?

These are all identical and don't win us anything.

> A %check section should either be there or not - not just contain a disabled
> checkout without further comments.

I forget why I have it disabled, but probably the tests either fail, or python-zope-testing wasn't yet in Fedora when this spec file was originally written. I think leaving a way to remember how to run the tests is valuable even if they are disabled currently.

> When building I notice an error which should be fixed:
> byte-compiling
> /home/mk/rpmbuild/BUILDROOT/python-ZODB3-3.9.0-0.1.a7.fc12.i386/usr/lib/python2.6/site-packages/ZEO/scripts/zeoserverlog.py
> to zeoserverlog.pyc
> SyntaxError: ('invalid syntax',
> ('/usr/lib/python2.6/site-packages/ZEO/scripts/zeoserverlog.py', 374, 6, '   
> as = []\n'))

Looks like a new Python 2.6 keyword; this is probably fixed in a newer version (such as 3.9.3, which I'll update the spec/srpm to later today).

> rpmlint output:
> python-ZODB3.i686: W: devel-file-in-non-devel-package
> /usr/lib/python2.6/site-packages/persistent/*.[ch]
> python-ZODB3.i686: W: devel-file-in-non-devel-package
> /usr/lib/python2.6/site-packages/BTrees/*.[ch]
> python-ZODB3.i686: W: devel-file-in-non-devel-package
> /usr/include/python2.6/ZODB3/*.h
> 3 packages and 1 specfiles checked; 0 errors, 34 warnings.
> The include files should perhaps go to a -devel package, and I guess the rest
> of the files shouldn't be there at all.
> /usr/include/python2.6/ZODB3 should be in a package which requires python-devel
> which owns /usr/include/python2.6/

ACK.

> It seems like this package contains 4 quite independent python modules.
> Consider putting them in independent packages: python-BTrees python-persistent
> python-ZEO python-ZODB

I don't see any reason to; AFAIK they come from one upstream and are used only by themselves.

> Hmm ... this brief review ends up being longer than the spec. IMHO there are
> too many issues here. The packager should have worked more with the package
> before filing a review request.

Off-topic and rude -- not to mention, plenty of the assertions in this "brief review" were incorrect.

Comment 3 Mads Kiilerich 2009-10-28 16:01:00 UTC
>> Mock build fails.
> 
> Against what? Rawhide? Fedora 11? Fedora 10? As you noted lower down in your
> initial review, there's a Python 2.6 incompatibility in this (Fedora 9!)
> package. I will update to the newer version later today, which should fix this
> issue.

Sorry, forget to say that I am using rawhide/f12. I assumed that was the default for new packages and didn't consider the age of the review request.

>> > Source should not be modified in %prep; it is a kind of build process and
>> > belongs in %build. Has this problem with invalid hash-bangs been filed and
>> > discussed upstream?
> This is complete fiction. %prep is the place for modifying source -- patches,
> sed scriptlets, etc go here. Nothing has been filed upstream, because it's
> fairly minor change IMO. I would be glad to contact upstream about it if that's
> a blocker.

It wasn't intended to be fiction, but you are right that I was wrong. Sorry.

>> I am not familiar with CFLAGS combined with setup.py. I assume that the right
>> flags from python-devel is used automatically. I think the python-numeric
>> package is similar to this one in many ways, and even though it does many
>> things wrong it can perhaps be used for reference: It do not list CFLAGS. Can
>> you reference any documentation or prior art from other packages?
> 
> file:///etc/rpmdevtools/spectemplate-python.spec (if you have the rpmdevtools
> package installed).

Right. Diving into it I can see that many packages does it that way - but also many noarch packages. And many python arch packages doesn't do it. It seems to me like the Python packaging guidelines could use some clarification here?

>> A %check section should either be there or not - not just contain a disabled
>> checkout without further comments.
> 
> I forget why I have it disabled, but probably the tests either fail, or
> python-zope-testing wasn't yet in Fedora when this spec file was originally
> written. I think leaving a way to remember how to run the tests is valuable
> even if they are disabled currently.

Doesn't that mean that we need a comment about why it is disabled?

>> It seems like this package contains 4 quite independent python modules.
>> Consider putting them in independent packages: python-BTrees python-persistent
>> python-ZEO python-ZODB
> 
> I don't see any reason to; AFAIK they come from one upstream and are used only
> by themselves.

That might be true, even though I assume they are separate modules because upstream considers them independent?

I don't feel comfortable with a package reserving such a generic term as "persistent" from the global Python module namespace just for its internal use.

>> Hmm ... this brief review ends up being longer than the spec. IMHO there are
>> too many issues here. The packager should have worked more with the package
>> before filing a review request.
> 
> Off-topic and rude -- not to mention, plenty of the assertions in this "brief
> review" were incorrect.

Sorry, that wasn't the intention. The failing mock build and the pylint output made me think that is wasn't ready for review yet and I was wasting my time. One year of bitrot can however explain it. I guess I should have asked if it still was ready before looking at it?

Comment 4 Conrad Meyer 2009-10-29 05:58:02 UTC
(In reply to comment #3)
> >> Mock build fails.

I've built the new version, which builds in rawhide mock for me.

Re: CFLAGS combined with setup.py:
> Right. Diving into it I can see that many packages does it that way - but also
> many noarch packages. And many python arch packages doesn't do it. It seems to
> me like the Python packaging guidelines could use some clarification here?

Yes, I completely agree. The guidelines could use some cleaning up and the spec templates should be updated to match.

Re: commented out %check section: 
> Doesn't that mean that we need a comment about why it is disabled?

Yes, this is something I should have done, sorry. The age of the review is such that I don't remember anymore -- I'll figure this out when I build the new version.

Re: this package installs 4 separate python modules
> That might be true, even though I assume they are separate modules because
> upstream considers them independent?
> 
> I don't feel comfortable with a package reserving such a generic term as
> "persistent" from the global Python module namespace just for its internal use.

Hm, good point. I will package them as separate sub-packages.

New SRPM/SPEC:
http://konradm.fedorapeople.org/fedora/SPECS/python-ZODB3.spec
http://konradm.fedorapeople.org/fedora/SRPMS/python-ZODB3-3.9.3-1.fc11.src.rpm

Comment 5 Mads Kiilerich 2009-10-29 17:52:54 UTC
Any comments to rpmlint warnings like the following?

python-BTrees.i586: W: devel-file-in-non-devel-package /usr/lib/python2.6/site-packages/BTrees/_IOBTree.c
python-BTrees.i586: E: non-standard-executable-perm /usr/lib/python2.6/site-packages/BTrees/_OIBTree.so 0775
python-persistent.i586: W: devel-file-in-non-devel-package /usr/lib/python2.6/site-packages/persistent/cPersistence.h
python-ZODB3.i586: W: devel-file-in-non-devel-package /usr/include/python2.6/ZODB3/cPersistence.h

Have you considered putting sub-modules somewhere else than in the global namespace instead of creating sub-packages? If it was an executable it could be put in /usr/share (like for example rpmlint does), but in this case I guess it could be below /usr/lib/python2.6/site-packages/ZODB? What is upstreams opinion? (My past experience with Zope is that they have their own strong sub-community and don't try that hard to fit into system packaging, but instead recommends building a python from source and not sharing it with anything else.)

Shouldn't some of the subpackages require a specific version of the others? There must be a reason the modules are distributed in one tar file?

Upstream project on pypi is ZODB3, and ZODB3 is also used in the tar name. But it provides the ZODB module, and it seems like upstream consistently refers to it as ZODB (or ZODB 3.9). Shouldn't the package be called python-ZODB instead?

Comment 6 Conrad Meyer 2009-10-29 21:29:21 UTC
(In reply to comment #5)
> Any comments to rpmlint warnings like the following?
> 
> python-BTrees.i586: W: devel-file-in-non-devel-package
> /usr/lib/python2.6/site-packages/BTrees/_IOBTree.c
> python-BTrees.i586: E: non-standard-executable-perm
> /usr/lib/python2.6/site-packages/BTrees/_OIBTree.so 0775
> python-persistent.i586: W: devel-file-in-non-devel-package
> /usr/lib/python2.6/site-packages/persistent/cPersistence.h
> python-ZODB3.i586: W: devel-file-in-non-devel-package
> /usr/include/python2.6/ZODB3/cPersistence.h

Yes, after I replied I remembered that I had forgotten to deal with these. My next package will simply remove these files from the install, unless you have a better suggestion.

> Have you considered putting sub-modules somewhere else than in the global
> namespace instead of creating sub-packages? If it was an executable it could be
> put in /usr/share (like for example rpmlint does), but in this case I guess it
> could be below /usr/lib/python2.6/site-packages/ZODB? What is upstreams
> opinion? (My past experience with Zope is that they have their own strong
> sub-community and don't try that hard to fit into system packaging, but instead
> recommends building a python from source and not sharing it with anything
> else.)

I'm not familiar with this; I think it would involve (at least) modifying all the ZODB sources to look for these packages in a different place (or run any program using ZODB with a PYTHONPATH including whatever subdirectory we choose). My particular interest in Zope libraries is for SAGE (http://fedoraproject.org/wiki/SIGs/SciTech/SAGE).
 
> Shouldn't some of the subpackages require a specific version of the others?
> There must be a reason the modules are distributed in one tar file?

Quite possibly. I must apologize for the sloppy work, I was rushed for time yesterday.

> Upstream project on pypi is ZODB3, and ZODB3 is also used in the tar name. But
> it provides the ZODB module, and it seems like upstream consistently refers to
> it as ZODB (or ZODB 3.9). Shouldn't the package be called python-ZODB instead?

This sounds reasonable.

New Spec/SRPM:
http://konradm.fedorapeople.org/fedora/SPECS/python-ZODB.spec
http://konradm.fedorapeople.org/fedora/SRPMS/python-ZODB-3.9.3-2.fc11.src.rpm

Comment 7 Mads Kiilerich 2009-10-30 00:49:31 UTC
>> python-BTrees.i586: W: devel-file-in-non-devel-package
>> /usr/lib/python2.6/site-packages/BTrees/_IOBTree.c
>> python-BTrees.i586: E: non-standard-executable-perm
>> /usr/lib/python2.6/site-packages/BTrees/_OIBTree.so 0775
>> python-persistent.i586: W: devel-file-in-non-devel-package
>> /usr/lib/python2.6/site-packages/persistent/cPersistence.h
>> python-ZODB3.i586: W: devel-file-in-non-devel-package
>> /usr/include/python2.6/ZODB3/cPersistence.h
> 
> Yes, after I replied I remembered that I had forgotten to deal with these. My
> next package will simply remove these files from the install, unless you have a
> better suggestion.

I guess that depends on what upstreams purpose with the files is? Are they installed on purpose or is it an oversight? 

FWIW I can't imagine any reasons why .c files should be included in any package. Theoretically it could perhaps make sense to expose the C code as a C library and put the .h files in a -devel package, but I don't think that is upstreams intention.

>> Have you considered putting sub-modules somewhere else than in the global
>> namespace instead of creating sub-packages? If it was an executable it could be
>> put in /usr/share (like for example rpmlint does), but in this case I guess it
>> could be below /usr/lib/python2.6/site-packages/ZODB? What is upstreams
>> opinion? (My past experience with Zope is that they have their own strong
>> sub-community and don't try that hard to fit into system packaging, but instead
>> recommends building a python from source and not sharing it with anything
>> else.)
> 
> I'm not familiar with this; I think it would involve (at least) modifying all
> the ZODB sources to look for these packages in a different place (or run any
> program using ZODB with a PYTHONPATH including whatever subdirectory we
> choose). 

It _could_ be done in the ZODB module simply by inserting the right path in sys.path before importing - or by manipulating sys.modules. But I don't know if I would propose doing it in a Fedora patch.

I think we need input from upstream if they see it as one module or as 4 modules each on their own right. In either case it could be nice if they distributed it in a way which matched their intention.

Comment 8 Conrad Meyer 2009-10-30 02:11:40 UTC
(In reply to comment #7)
> I guess that depends on what upstreams purpose with the files is? Are they
> installed on purpose or is it an oversight? 
> 
> FWIW I can't imagine any reasons why .c files should be included in any
> package. Theoretically it could perhaps make sense to expose the C code as a C
> library and put the .h files in a -devel package, but I don't think that is
> upstreams intention.

Agree. I think it's just upstream being braindead (Zope does some unintelligent things).

Re: Putting the 3 other modules in some subdirectory:
> It _could_ be done in the ZODB module simply by inserting the right path in
> sys.path before importing - or by manipulating sys.modules. But I don't know if
> I would propose doing it in a Fedora patch.
> 
> I think we need input from upstream if they see it as one module or as 4
> modules each on their own right. In either case it could be nice if they
> distributed it in a way which matched their intention.  

I agree. I've sent an email to upstream asking for clarification on this.

Comment 9 Prasad H. L. 2010-04-26 17:37:47 UTC
Any progress on this?

Comment 10 Conrad Meyer 2010-04-26 18:26:02 UTC
No response from upstream; still blocking on python-zope-proxy's review.

Comment 11 Robin Lee 2010-06-15 13:37:06 UTC
Here some notes:
* %python_sitearch is defined by default after F-13, so it's better to add a conditional according to the guideline: http://fedoraproject.org/wiki/Packaging:Python#Macros

* Latest stable version is 3.9.5: http://pypi.python.org/packages/source/Z/ZODB3/ZODB3-3.9.5.tar.gz

* python-ZODB3 and python-ZEO seem noarch.

* A -devel package should be made for all the useful header files.

* The C source files in binary packages should be removed.

* Packages contain text files in the Python filesystem, consider moving the unnecessary ones to %docdir.

Comment 12 Conrad Meyer 2010-06-15 23:27:48 UTC
No need to continue this review, I've lost interest in getting SAGE packaged for Fedora (and don't have any other interest in this package). Closing.

Comment 13 Robin Lee 2010-06-16 11:56:24 UTC
I now take over this review request.

Changes:
- Update to 3.9.5
- Take over the review request (#476600).
- Don't split out per-extension subpackages.
- BR: python-setuptools added
- Requires: python-zope-testing removed
- Make a -devel subpackage to contain all the header files
- Remove the C source files installed by setup.py
- Include more documents
- Don't move the executable scripts

Spec: http://cheeselee.fedorapeople.org/python-ZODB3.spec
Spec file is version-controlled in http://fedorapeople.org/gitweb?p=cheeselee/public_git/rpm.git;a=blob;f=python-ZODB3/F-13/python-ZODB3.spec;hb=master

SRPM: http://cheeselee.fedorapeople.org/yum/zope/13/source/python-ZODB3-3.9.5-1.fc13.src.rpm
Rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2253141

rpmlint results:

$ rpmlint ./python-ZODB3.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

$ rpmlint SRPMS/python-ZODB3-3.9.5-1.fc13.src.rpm 
python-ZODB3.src: W: spelling-error Summary(en_US) Zope -> Zoe, Ope, Nope
python-ZODB3.src: W: spelling-error %description -l en_US pluggable -> plug gable, plug-gable, plugged
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint RPMS/i686/python-ZODB3-3.9.5-1.fc13.i686.rpm 
python-ZODB3.i686: W: spelling-error Summary(en_US) Zope -> Zoe, Ope, Nope
python-ZODB3.i686: W: spelling-error %description -l en_US pluggable -> plug gable, plug-gable, plugged
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_IIBTree.so _IIBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/persistent/cPickleCache.so cPickleCache.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_LFBTree.so _LFBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/persistent/TimeStamp.so TimeStamp.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_LOBTree.so _LOBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_OOBTree.so _OOBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_OIBTree.so _OIBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/persistent/cPersistence.so cPersistence.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_LLBTree.so _LLBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_OLBTree.so _OLBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_fsBTree.so _fsBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_IFBTree.so _IFBTree.so
python-ZODB3.i686: W: private-shared-object-provides /usr/lib/python2.6/site-packages/BTrees/_IOBTree.so _IOBTree.so
python-ZODB3.i686: W: no-manual-page-for-binary mkzeoinst
python-ZODB3.i686: W: no-manual-page-for-binary fstail
python-ZODB3.i686: W: no-manual-page-for-binary runzeo
python-ZODB3.i686: W: no-manual-page-for-binary zeoctl
python-ZODB3.i686: W: no-manual-page-for-binary zeopasswd
python-ZODB3.i686: W: no-manual-page-for-binary fsdump
python-ZODB3.i686: W: no-manual-page-for-binary zeopack
python-ZODB3.i686: W: no-manual-page-for-binary fsrefs
python-ZODB3.i686: W: no-manual-page-for-binary repozo
python-ZODB3.i686: W: no-manual-page-for-binary fsoids
1 packages and 0 specfiles checked; 0 errors, 25 warnings.

$ rpmlint RPMS/noarch/python-ZODB3-devel-3.9.5-1.fc13.noarch.rpm 
python-ZODB3-devel.noarch: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

Comment 14 Nathaniel McCallum 2010-06-18 20:40:21 UTC
Created attachment 425250 [details]
Patch to fix incorrect python shebang

repozo has an incorrect shebang, this patch fixes it

Comment 15 Robin Lee 2010-06-19 13:01:03 UTC
(In reply to comment #14)
> Created an attachment (id=425250) [details]
> Patch to fix incorrect python shebang
> 
> repozo has an incorrect shebang, this patch fixes it    

The shebang has been entirely removed in the %prep section of the spec file.
Shebangs in unexecutable files are not permitted in Fedora.

Comment 17 Robin Lee 2010-08-31 18:03:01 UTC

*** This bug has been marked as a duplicate of bug 629027 ***


Note You need to log in before you can comment on or make changes to this bug.