Spec URL: http://cheeselee.fedorapeople.org/python-zope-filerepresentation.spec SRPM URL: http://cheeselee.fedorapeople.org/python-zope-filerepresentation-3.6.0-2.fc14.src.rpm Description: The interfaces defined here are used for file-system and file-system-like representations of objects, such as file-system synchronization, FTP, PUT, and WebDAV. rpmlint results: $ rpmlint ./python-zope-filerepresentation.spec ./python-zope-filerepresentation.spec: W: no-cleaning-of-buildroot %install ./python-zope-filerepresentation.spec: W: no-cleaning-of-buildroot %clean ./python-zope-filerepresentation.spec: W: no-buildroot-tag ./python-zope-filerepresentation.spec: W: no-%clean-section 0 packages and 1 specfiles checked; 0 errors, 4 warnings. $ rpmlint ./python-zope-filerepresentation-3.6.0-2.fc14.src.rpm python-zope-filerepresentation.src: W: no-cleaning-of-buildroot %install python-zope-filerepresentation.src: W: no-cleaning-of-buildroot %clean python-zope-filerepresentation.src: W: no-buildroot-tag python-zope-filerepresentation.src: W: no-%clean-section 1 packages and 0 specfiles checked; 0 errors, 4 warnings. $ rpmlint ./python-zope-filerepresentation-3.6.0-2.fc14.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
In a package such as this and the rest of the zope packages submitted recently, would it not be better to leave the buildroot and cleaning tags in? As I am sure it would be useful in EPEL even more so with the longer life cycle of EL. Just a thought.
(In reply to comment #1) > In a package such as this and the rest of the zope packages submitted recently, > would it not be better to leave the buildroot and cleaning tags in? As I am > sure it would be useful in EPEL even more so with the longer life cycle of EL. > Just a thought. What I am doing mainly aims for f14 and above and epel6. I may consider building them for epel5 after finishing them for latest Fedora releases. If the ZTK packages are tested to work in epel5, I will be responsible to revise the spec files. After that, the ZTK packages are mainly used by those end products like later Zope2, Grok and BlueBream. The old version of Zope2 available in epel5 doesn't need these ZTK packages. And later versions of Zope2 are not compatible with Python2.4 in el5. That meens, later versions of Zope2 are not able to go to el5, and so the ZTK packages may not be of much use in el5.
EL6 don't need %clean and buildroot, the minimum python requirement for ZTK 1.0 is 2.6.
(In reply to comment #3) > EL6 don't need %clean and buildroot, the minimum python requirement for ZTK 1.0 > is 2.6. ZTK 1.0 supports Python 2.4[*]. But I would focus on the latest releases of Fedora at this time. [*] http://docs.zope.org/zopetoolkit/process/python-versions.html#ztk-1-0
(In reply to comment #4) > (In reply to comment #3) > > EL6 don't need %clean and buildroot, the minimum python requirement for ZTK 1.0 > > is 2.6. > ZTK 1.0 supports Python 2.4[*]. But I would focus on the latest releases of > Fedora at this time. > [*] http://docs.zope.org/zopetoolkit/process/python-versions.html#ztk-1-0 This is incorrect, see http://pypi.python.org/pypi/ZODB3/3.10.0b6#prerequisites ZODB 3.10 requires Python 2.5 or later.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > EL6 don't need %clean and buildroot, the minimum python requirement for ZTK 1.0 > > > is 2.6. > > ZTK 1.0 supports Python 2.4[*]. But I would focus on the latest releases of > > Fedora at this time. > > [*] http://docs.zope.org/zopetoolkit/process/python-versions.html#ztk-1-0 > > This is incorrect, see http://pypi.python.org/pypi/ZODB3/3.10.0b6#prerequisites > > ZODB 3.10 requires Python 2.5 or later. ZODB is not a component of ZTK.
Any progress here? Robin, are you still interested?
I would still like to maintain this package. Changes: - Update to 3.6.1 - Requires python-zope-schema - Don't own %%{python_sitelib}/zope/ Spec URL: http://cheeselee.fedorapeople.org/python-zope-filerepresentation.spec SRPM URL: http://cheeselee.fedorapeople.org/python-zope-filerepresentation-3.6.1-1.fc17.src.rpm
Package Review ============== Key: - = N/A x = Pass ! = Fail ? = Not evaluated ==== Generic ==== [x]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [-]: MUST %build honors applicable compiler flags or justifies otherwise. [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: MUST Buildroot is not present Note: Unless packager wants to package for EPEL5 this is fine [x]: MUST Package contains no bundled libraries. [x]: MUST Changelog in prescribed format. [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: MUST Sources contain only permissible code or content. [x]: MUST Each %files section contains %defattr if rpm < 4.4 [x]: MUST Macros in Summary, %description expandable at SRPM build time. [x]: MUST Package requires other packages for directories it uses. [x]: MUST Package uses nothing in %doc for runtime. [x]: MUST Package is not known to require ExcludeArch. [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Spec file lacks Packager, Vendor, PreReq tags. [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [-]: MUST Large documentation files are in a -doc subpackage, if required. [x]: MUST If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [x]: MUST License field in the package spec file matches the actual license. [x]: MUST Package consistently uses macros (instead of hard-coded directory names). [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST Package does not generate any conflict. [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [x]: MUST Package must own all directories that it creates. [x]: MUST Package does not own files or directories owned by other packages. [ ]: MUST Package installs properly. [x]: MUST Requires correct, justified where necessary. [x]: MUST Rpmlint is run on all package Output below [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. [x]: MUST Spec file is legible and written in American English. [x]: MUST Spec file name must match the spec package %{name}, in the format %{name}.spec. [-]: MUST Package contains a SysV-style init script if in need of one. [x]: MUST File names are valid UTF-8. [-]: MUST Useful -debuginfo package or justification otherwise. [x]: SHOULD Reviewer should test that the package builds in mock. [-]: SHOULD If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: SHOULD Dist tag is present. [x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [?]: SHOULD Package functions as described. [x]: SHOULD Latest version is packaged. [x]: SHOULD Package does not include license text files separate from upstream. [x]: SHOULD SourceX is a working URL. [-]: SHOULD Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [-]: SHOULD Package should compile and build into binary rpms on all supported architectures. [-]: SHOULD %check is present and all tests pass. [x] SHOULD Packages should try to preserve timestamps of original installed files. [x]: SHOULD Spec use %global instead of %define. Non-blocking issues: - I suggest that you add --quiet flag 'setup build' and 'setup install' in order to make output easier to read. - Consider adding PKG-INFO to %doc: License and author info (which is mostly present in other files, but it doesn't hurt). rpmlint python-zope-filerepresentation-3.6.1-1.fc18.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. rpmlint python-zope-filerepresentation-3.6.1-1.fc18.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. <mock-chroot># rpmlint python-zope-filerepresentation python-zope-filerepresentation.noarch: I: enchant-dictionary-not-found en_US 1 packages and 0 specfiles checked; 0 errors, 0 warnings. <mock-chroot># rpm -q --requires python-zope-filerepresentation | grep -v rpmlib python(abi) = 2.7 python-zope-interface python-zope-schema <mock-chroot># rpm -q --provides python-zope-filerepresentation python-zope-filerepresentation = 3.6.1-1.fc15 /home/mk/tmp/633634/zope.filerepresentation-3.6.1.tar.gz : MD5SUM this package : 4a7a434094f4bfa99a7f22e75966c359 MD5SUM upstream package : 4a7a434094f4bfa99a7f22e75966c359 Generated by fedora-review 0.1.3 External plugins: No blocking issues: *** Approved
New Package SCM Request ======================= Package Name: python-zope-filerepresentation Short Description: File-system Representation Interfaces Owners: cheeselee Branches: f16 f17 InitialCC:
Git done (by process-git-requests).
python-zope-filerepresentation-3.6.1-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/python-zope-filerepresentation-3.6.1-1.fc16
python-zope-filerepresentation-3.6.1-1.fc16 has been pushed to the Fedora 16 testing repository.
python-zope-filerepresentation-3.6.1-1.fc16 has been pushed to the Fedora 16 stable repository.