Spec URL: http://jpopelka.fedorapeople.org/python-cups.spec SRPM URL: http://jpopelka.fedorapeople.org/python-cups-1.9.52-1.src.rpm Description: This package provides Python bindings for the CUPS API, known as pycups. It was written for use with system-config-printer, but can be put to other uses as well.
I *strongly* recommend keeping the upstream name "pycups" [this is allowed in the Naming Guidelines]. rpmlint output: python-cups.src: W: spelling-error %description -l en_US pycups -> eyecups, pycnidiums, scups python-cups.src: W: spelling-error %description -l en_US config -> con fig, con-fig, configure python-cups.src: W: no-cleaning-of-buildroot %install python-cups.src: W: no-cleaning-of-buildroot %clean python-cups.src: W: no-buildroot-tag python-cups.src: W: no-%clean-section python-cups.x86_64: W: spelling-error %description -l en_US pycups -> eyecups, pycnidiums, scups python-cups.x86_64: W: spelling-error %description -l en_US config -> con fig, con-fig, configure python-cups.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/cups.so cups.so()(64bit) python-cups.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/cups.so 0775L python-cups.x86_64: W: spurious-executable-perm /usr/share/doc/python-cups-1.9.52/examples/cupstree.py python-cups.x86_64: W: doc-file-dependency /usr/share/doc/python-cups-1.9.52/examples/cupstree.py /usr/bin/python 3 packages and 0 specfiles checked; 1 errors, 11 warnings. The srpm warnings can be dismissed. However, you need to fix the executable perms and private-shared-object-provides stuff. You can do this by chmoding chmod 755 %{buildroot}%{python_sitearch}/cups.so at the end of install and adding # we don't want to provide private python extension libs %{?filter_setup: %filter_provides_in %{python_sitearch}/.*\.so$ %filter_setup } to the beginning of the spec file. *** I would recommend using the standard CFLAGS="%{optflags}" python setup.py build to build the library and python setup.py install -O1 --skip-build --root %{buildroot} to install it, as I don't really trust that the build always uses %{optflags} otherwise. The Makefile seems to run python setup.py build anyway. Now it seems to use the flags -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC on x86_64. You can then build the documentation manually with the same procedure as in the Makefile, i.e. rm -rf html epydoc -o html --html $< *** MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK MUST: The spec file for the package is legible and macros are used consistently. OK MUST: The package must be named according to the Package Naming Guidelines. OK MUST: The spec file name must match the base package %{name}. OK MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines. OK MUST: The License field in the package spec file must match the actual license. OK MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK dc5ea2f3e0ef61837f493a70d1f74905 pycups-1.9.52.tar.bz2 dc5ea2f3e0ef61837f493a70d1f74905 ../SOURCES/pycups-1.9.52.tar.bz2 MUST: The package MUST successfully compile and build into binary rpms. OK MUST: The spec file MUST handle locales properly. N/A MUST: Optflags are used and time stamps preserved. OK MUST: Packages containing shared library files must call ldconfig. N/A MUST: A package must own all directories that it creates or require the package that owns the directory. OK MUST: Files only listed once in %files listings. OK MUST: Debuginfo package is complete. OK MUST: Permissions on files must be set properly. OK MUST: Large documentation files must go in a -doc subpackage. NEEDSWORK - HTML documentation is half a megabyte, split examples and html to -doc. MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK MUST: Header files must be in a -devel package. N/A MUST: Static libraries must be in a -static package. N/A MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A MUST: Packages does not contain any .la libtool archives. N/A MUST: Desktop files are installed properly. N/A MUST: No file conflicts with other packages and no general names. OK SHOULD: %{?dist} tag is used in release. OK SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK SHOULD: The package builds in mock. OK
Jussi, thank you for taking the review and your useful hints. Hope I fixed everything as you had described. Spec URL: http://jpopelka.fedorapeople.org/python-cups.spec SRPM URL: http://jpopelka.fedorapeople.org/python-cups-1.9.52-2.src.rpm For the naming issue I would rather ask Tim Waugh (upstream). Tim, can you read https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29 and decide whether and how to change this package name ?
OK, let's wait for Tim's reply (here and in bug #648987). The main point here is the exception: 'If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable.' [In this case the upstream tarballs are named "pycups" and "pysmbc".]
OK. I named pycups and pysmbc by just copying the "pygtk" style of name. Let's go with that then.
(In reply to comment #3) > OK, let's wait for Tim's reply (here and in bug #648987). > > The main point here is the exception: 'If the upstream source has "py" (or > "Py") in its name, you can use that name for the package. So, for example, > pygtk is acceptable.' [In this case the upstream tarballs are named "pycups" > and "pysmbc".] From my point of view the main point here is that you *can* use that (upstream) name. There's no 'should' or 'strong suggestion'. The paragraph says: " They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script. " We use 'import cups' and 'import smbc' in Python scripts which gives me a python-cups and python-smbc package names.
I don't have a strong point of view about this either way. If I were naming the upstream tarballs again today I would probably choose "python-cups" and "python-smbc".
(In reply to comment #5) > From my point of view the main point here is that you *can* use that (upstream) > name. There's no 'should' or 'strong suggestion'. On the other hand, "General Naming When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision." > "They should take into account the upstream name of the python module. This > makes a package name format of python-$NAME. When in doubt, use the name of the > module that you type to import it in a script." > > We use 'import cups' and 'import smbc' in Python scripts which gives me a > python-cups and python-smbc package names. This is true - the Python modules are not named consistently. (In reply to comment #6) > I don't have a strong point of view about this either way. If I were naming > the upstream tarballs again today I would probably choose "python-cups" and > "python-smbc". Very well. You could still do this, you know ;) ** Everything has been fixed, so this package has been APPROVED
(In reply to comment #7) > > We use 'import cups' and 'import smbc' in Python scripts which gives me a > > python-cups and python-smbc package names. > > This is true - the Python modules are not named consistently. They're consistent with how pygtk names things, which I thought was a good example at the time. > (In reply to comment #6) > > I don't have a strong point of view about this either way. If I were naming > > the upstream tarballs again today I would probably choose "python-cups" and > > "python-smbc". > > Very well. You could still do this, you know ;) It would mean changing the git repository names and URIs (can that even be done?), and the PyPI index name for pycups, etc. So the upstream names will stay the same.
New Package SCM Request ======================= Package Name: python-cups Short Description: Python bindings for CUPS Owners: twaugh jpopelka Branches: InitialCC:
Git done (by process-git-requests).
I would like to see this in EPEL6. Would you be willing to maintain it there, or shall I?
The 'Python bindings for CUPS' are part of system-config-printer-libs in RHEL-6.
Ah, okay, never mind then.