Bug 700667

Is it practical to carry this as a separate package? Given that the version and code is identical, perhaps this could be added to the python-crypto package (in EPEL) as a subpackage, much in the same way that some python3 packages are generated.

If that's an accepted practice in EPEL, then by all means, it can be added as a subpackage.  I do not expect the source of this package to diverge from python-crypto at all.  Should I just contact the maintainers of that package?

Yeah, I would only pursue this route if the python-crypto maintainer objects.

(python-crypto maintainer here)

Another possibility, given that python26-crypto doesn't currently exist and the EPEL-5 python-crypto package is quite old (2.0.1; current upstream is 2.3) would be to make the new python26-crypto package use the current upstream release, as that is likely to be more useful to python26 users?

That would of course need a new review as it would be a new package rather than a subpackage of the existing python-crypto package.

I've no objection to the subpackage approach other than that I think a more recent version would be a better option going forward given that it's essentially a new package.

That's fine.  It makes little difference to me, as I only need it as a prerequisite for paramiko.  I can test out a 2.3 build and post that.

Updated to 2.3 and posted here (and my apologies for Google's content-type issue on the spec file):

SRPM:
https://www.grimmslanding.org/rpms/python26-crypto-2.3-4.el5.src.rpm

SPEC:
https://www.grimmslanding.org/rpms/python26-crypto.spec

I tried to change the spec as little as possible from the current version in he python-crypto master branch.  However, filter_provides_in obviously doesn't do anything in rpm 4.4.x, and I wasn't sure whether I should leave that in.  Also, I thought about overriding _provides to white out the shared lib deps, but did not.  (This practice is mentioned in http://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering , but it doesn't seem to be common in EPEL).
Thoughts?

(In reply to comment #6)
> Updated to 2.3 and posted here (and my apologies for Google's content-type
> issue on the spec file):
> 
> SRPM:
> https://www.grimmslanding.org/rpms/python26-crypto-2.3-4.el5.src.rpm
> 
> SPEC:
> https://www.grimmslanding.org/rpms/python26-crypto.spec
> 
> I tried to change the spec as little as possible from the current version in he
> python-crypto master branch.  However, filter_provides_in obviously doesn't do
> anything in rpm 4.4.x, and I wasn't sure whether I should leave that in.  Also,
> I thought about overriding _provides to white out the shared lib deps, but did
> not.  (This practice is mentioned in
> http://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering , but it
> doesn't seem to be common in EPEL).
> Thoughts?

To filter those you'd need to manually include the provides filter included in /usr/lib/rpm/redhat/macros (redhat-rpm-config package) in Fedora. I wouldn't bother, and I'd strip out the existing provides filtering code as it has no effect in EPEL < 6.

Created attachment 497224 [details]
Some simplifications

I think there are some other simplifications that can be made too:

%pybasever is defined in the spec so its use doesn't need to be conditionalized

%pythonver can be replaced by %pybasever since they have the same value

No need to evaluate the python-abi value as we're defining it as %pybasever ourselves

No need to specify a version requirement for python26-devel as any version will be OK

Attached patch implements these suggestions.

Created attachment 497358 [details]
Revised Simplifications

All of your suggestions make sense; the reason I left pythonver from the original recipe was to keep things as similar as possible to the python-crypto master (it might make merges easier later).  Rather than remove it and alter the %install section, I replaced pybasever with pythonver in this similar patch.

I'm not sure what to do next on this issue.  Do I need to post a spec / srpm with either Paul's patch or mine applied?  Does anyone have feedback on my patch?  Thanks.

I've updated python-crypto in Rawhide to use upstream's re-rolled tarball and to get rid of macros for system commands. Rebase your spec on that and then I'll review it when I can find a few spare jiffies.

Ah, I did see the comment in email about macros longer than the things they replace.  :-)  So now we have:

SPEC:
http://www.grimmslanding.org/rpms/python26-crypto.spec

SRPM:
http://www.grimmslanding.org/rpms/python26-crypto-2.3-5.el5.src.rpm

Thanks.

rpmlint output
==============
python26-crypto.x86_64: W: file-not-utf8 /usr/share/doc/python26-crypto-2.3/LEGAL/copy/stmts/Paul_Swartz.mbox
python26-crypto.x86_64: E: backup-file-in-package /usr/share/doc/python26-crypto-2.3/LEGAL/copy/LICENSE.orig

The first of these is a set of emails, with explicit encoding.
The second is a false positive - the file originates upstream and not from a patch.

review checklist
================
- rpmlint OK (see above)
- package and spec naming follows convention for python26 packages in EPEL
- package meets guidelines
- license is OK for Fedora and matches upstream (see upstream COPYRIGHT file)
- upstream licensing texts included in %doc
- spec file written in English and is legible
- source matches upstream
- package builds find in mock for EPEL-5
- buildreqs ok
- no locale data to worry about
- package does not include shared libraries in dynamic linker's default paths
- package does not bundle copies of system libraries
- package is not intended to be relocatable
- no directory ownership issues
- no duplicate files
- file permissions are fine
- macro usage is consistent
- code, not content
- no large docs included
- docs don't affect runtime
- no devel files included
- not a GUI app so no desktop file needed
- filenames are all valid UTF-8
- upstream test suite and benchmark script run in %check
- no scriptlets needed or included
- no subpackages warranted or created
- no file dependencies
- no binaries/scripts included, so no manpages warranted

All in all, no problems found.

APPROVED.

Andy, before you request any branches you need to get sponsored into the packager group.  Thankfully, Paul is a sponsor, so all you have to do is convince him to sponsor you.  :)

Blocking FE-NEEDSPONSOR...

I just sponsored Andy. Lifting FE-NEEDSPONSOR

New Package SCM Request
=======================
Package Name: python26-crypto
Short Description: Cryptography library for Python 
Owners: arg gholms
Branches: el5
InitialCC:

Git done (by process-git-requests).

python26-crypto-2.3-5.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/python26-crypto-2.3-5.el5

python26-crypto-2.3-5.el5 has been pushed to the Fedora EPEL 5 testing repository.

python26-crypto-2.3-5.el5 has been pushed to the Fedora EPEL 5 stable repository.