Spec URL: http://dl.dropbox.com/u/17870887/python-faces-0.11.7-1/python-faces.spec SRPM URL: http://dl.dropbox.com/u/17870887/python-faces-0.11.7-1/python-faces-0.11.7-1.fc16.src.rpm faces is a powerful and flexible project management tool. It not only offers many extraordinary features like multiple resource balancing algorithms and multi scenario planing, but can also be easily extended and customized. rpmlint: python-faces.noarch: E: explicit-lib-dependency python-matplotlib - Package actually requires it, and it's not picked up by automatic deps. python-faces.noarch: W: no-manual-page-for-binary faces - No blocker This is a dependency for an upcoming request for openerp-server.
hi, I am not sure of the naming, if the upstream project is called faces or faces-pm, why is the rpm called python-faces ?
Hi, Thanks for commenting... in reply: - the python prefix is as mandated in http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29 - The thought of using python-faces-pm instead of python-faces has crossed my mind; it's slightly more descriptive.
But I am not sure that count as a python module if there is a standalone executable.
Nor am I. I choose this way because my actual usage was as a module. Would it be better to use a sub-package to split it into 'python-faces' for the python site-package stuff and 'faces' (requiring python-faces) just for the binary?
I would do that, yes. ( in fact, i would call it faces-pm since that's the name of the upstream tarball, and keep python-faces, if the module is called faces ). Also, since that's a graphical application, this would requires a desktop file. But maybe you should try to check with someone from the python-SIG, or a more experienced packager than me, as I am not really sure about the policy for that.
(In reply to comment #5) [cut] > But maybe you should try to check with someone from the python-SIG, or a more > experienced packager than me, as I am not really sure about the policy for > that. Actually I won't, you have convinced me and I'll make an update :) Thanks for bringing this issue up!
The _bindir application is broken. It requires unpatched parts of the python lib which uses nowadays not existing functions in matplotlib. The openerp patch removes these parts. This absolutely necessary, the unpatched sources doesn't even pass setup.py. Obviously, there is no actual usage of the app. I have looked into patching the it, but deemed it as not feasible. Since my interest is in the python module, I have simply removed the app. Updated in place, same links
Robin: did you forget to set the fedora-review flag to '?'.
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. [x]: 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. [!]: MUST Changelog in prescribed format. [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) Note: Clean would be needed if support for EPEL is required [x]: MUST Sources contain only permissible code or content. [x]: MUST Each %files section contains %defattr if rpm < 4.4 Note: Note: defattr macros not found. They would be needed for EPEL5 [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 Fully versioned dependency in subpackages, if present. [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. Note: rm -rf would be needed if support for EPEL5 is required [x]: 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 License file installed when any subpackage combination is installed. [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. [x]: MUST Package installs properly. [!]: MUST Requires correct, justified where necessary. [x]: MUST Rpmlint output is silent. (python-matplotlib is not an elf library) rpmlint python-faces-0.11.7-1.fc18.noarch.rpm python-faces.noarch: E: explicit-lib-dependency python-matplotlib 1 packages and 0 specfiles checked; 1 errors, 0 warnings. rpmlint python-faces-0.11.7-1.fc18.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. rpmlint python-faces-timescale-0.11.7-1.fc18.noarch.rpm python-faces-timescale.noarch: W: no-documentation 1 packages and 0 specfiles checked; 0 errors, 1 warnings. [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. /home/cheese/Public/817268/faces-pm-0.11.7.tar.gz : MD5SUM this package : eea3cd8dc7f201ac6d745fe9d34274cd MD5SUM upstream package : eea3cd8dc7f201ac6d745fe9d34274cd [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. [x]: MUST Package contains a SysV-style init script if in need of one. [x]: MUST File names are valid UTF-8. [x]: 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 Patches link to upstream bugs/comments/lists or are otherwise justified. [!]: SHOULD SourceX / PatchY prefixed with %{name}. Note: Source0: http://downloads.sourceforge.net/faces-project/faces- pm-%{version}.tar.gz (faces-pm-%{version}.tar.gz) Patch0: python-faces- openerp.patch (python-faces-openerp.patch) Patch1: python-faces- version.patch (python-faces-version.patch) Patch2: python-faces-fsf- fix.patch (python-faces-fsf-fix.patch) Patch3: python-faces- timescale.patch (python-faces-timescale.patch) [x]: SHOULD SourceX is a working URL. [x]: SHOULD Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: SHOULD Package should compile and build into binary rpms on all supported architectures. [x]: SHOULD %check is present and all tests pass. (Upstream comes no tests) [x]: SHOULD Packages should try to preserve timestamps of original installed files. [x]: SHOULD Spec use %global instead of %define. Issues: [!]: MUST Requires correct, justified where necessary. Not requiring pygtk2. [!]: The 'git' macro is defined but not used [!]: I suggest the srpm be named 'faces-pm', and split into four rpms: - faces-pm "A project management tool based on Python" (the executable, and desktop entry file if you can provide) - python-faces "Python modules of Faces project management tool" - python-metapie "An application framework based on wxpython" (quoted from metapie/__init__.py) - python-faces-timescale "Timescale module for python-faces for Faces project management tool" [!] There is a special homepage for this project: http://faces.homeip.net/ [!] The urls for Patch0 and Patch3 are the same. [!] Patch0 is too heavy, actually cuts and relicenses the original file. I think the job can be done within OpenERP instead of patching faces/__init__.py. Since Faces-pm seems dead, it may be acceptable that OpenERP adopts some useful source files from Faces directly. [!]: MUST Changelog in prescribed format. Every time of change should bump release number, even still under review. An empty is required between two changelog entries. [!]: SHOULD Package functions as described. I may not approve this package if the application doesn't run. Simply removing the executable is not responsible.
(In reply to comment #9) > Issues: > [!]: MUST Requires correct, justified where necessary. > Not requiring pygtk2. Good catch! Agreed. > [!]: The 'git' macro is defined but not used Agreed > [!]: I suggest the srpm be named 'faces-pm', and split into four rpms: > - faces-pm "A project management tool based on Python" (the executable, > and desktop entry file if you can provide) > - python-faces "Python modules of Faces project management tool" > - python-metapie "An application framework based on wxpython" (quoted from > metapie/__init__.py) > - python-faces-timescale "Timescale module for python-faces for Faces > project management tool" Agreed: split out python-metapie. As for application faces-pm, see below. > [!] There is a special homepage for this project: http://faces.homeip.net/ Agreed. There is more about that, faces have been and is hosted at many sites. Still I think sourceforge is the place for the most recent activities. The submitter of bug #693425 made some work here, and the overall conclusion at that point was to proceed like this. Since then, no more actual source has been released, so the situation is the same. Agreed: URL:http://faces.homeip.net/ > [!] The urls for Patch0 and Patch3 are the same. Agreed (patch0 is wrong). > [!] Patch0 is too heavy, actually cuts and relicenses the original file. I > think the job can be done within OpenERP instead of patching faces/__init__.py. Agreed: to patch the license is unacceptable. This is published under GPLv2+, and a patch can't change this. Also a good catch! That said, is there a rule saying how heavy a patch can be? Given that current code doesn't even pass setup.py? And that upstream doesn't respond when submitting patches? > Since Faces-pm seems dead, it may be acceptable that OpenERP adopts some useful > source files from Faces directly. This would be to bundle. That's something to avoid IMHO. > [!]: MUST Changelog in prescribed format. > Every time of change should bump release number, even still under review. No. http://fedoraproject.org/wiki/Packaging:Guidelines#Multiple_Changelog_Entries_per_Release > An empty is required between two changelog entries I could certainly put a blank between the entries. Is there such a requirement in the guidelines? > [!]: SHOULD Package functions as described. > I may not approve this package if the application doesn't run. Simply removing > the executable is not responsible. This is the core issue. We have here a package which is not maintained since many years, and thus partly doesn't work with recent python. There is no recent upstream activities I'm aware of about this. I have actually looked into patching it, and my conclusion is that it would *not* be responsible of me to try to fix it. It's simply beyond what I can do, it would end up in something which doesn't work. OTOH, openerp is doing exactly that for the libraries. It's just that they have no interest in the application. The project is dead, definitely. The openerp patch represents among other things what need to be done just to build it. This patch is sent upstream without any response at all. Note that the last commits (2010) are indeed openerp contributions i. e., openerp is nowadays the part which (partly) keeps faces up to recent python standards, something the upstream project don't. Open issues: - If you can't approve removing the application. - If you can't accept patch0 (revised for licensing) because being to heavy. I suggest that we consult the mailing list in case these cannot be resolved here. With these issues open, I don't publish new links ATM.
IMHO, the best practice for OpenERP is to incorporate and keep maintaining the needed modules from Faces, if OpenERP license compatible with GPL. Then if the maintenance is obvious, this can be considered as forking and acceptable in Fedora.
Patching faces/__init__.py actually changes the API of the module, so I considers it too heavy.
(In reply to comment #11) > IMHO, the best practice for OpenERP is to incorporate and keep maintaining the > needed modules from Faces, if OpenERP license compatible with GPL. Then if the > maintenance is obvious, this can be considered as forking and acceptable in > Fedora. The OpenERP license is AGPLv3, which is compatible with GPLv2+ OpenERP includes the sources today. This clearly constitutes a bundling, and this request is really about unbundling the faces library from OpenERP. See http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries. Basically, I need to either package faces or get a bundling exception. In this case, I'm certain that a request for bundling exception would give a "package separately" reply. The patch is basically between what's in OE today and (partly) works, and the upstream which is unusable. (In reply to comment #12) > Patching faces/__init__.py actually changes the API of the module, so I > considers it too heavy. Shall we ask the list about this? Seems that we just disagree ?! As far as I know, there is no rule blocking this kind of patching. OTOH, not everything is covered in rules, it's also about overall judgment. Which can be harder to agree on, though.
(In reply to comment #13) > Shall we ask the list about this? Seems that we just disagree ?! As far as I > know, there is no rule blocking this kind of patching. OTOH, not everything is > covered in rules, it's also about overall judgment. Which can be harder to > agree on, though. OK. This is a good situation to discus on. Go ahead and ask on the devel list.
Let's start with new links (release bump; after all, a new subpackage) Spec: http://dl.dropbox.com/u/17870887/python-faces-0.11.7-2/python-faces.spec srpm: http://dl.dropbox.com/u/17870887/python-faces-0.11.7-2/python-faces-0.11.7-2.fc16.src.rpm patch, the one we are discussing: http://dl.dropbox.com/u/17870887/python-faces-0.11.7-2/python-faces-openerp.patch
Message sent: http://lists.fedoraproject.org/pipermail/devel/2012-May/166818.html No reply besides your's. Too bad. After sleeping on this, I have decided to put this request on ice, and proceed with bug #817271 using bundled faces sources. If that review passes, this request can be closed. If that review ends up being blocked on faces being a bundled library, I'll have to go to the FPC unless that makes you change your mind. /me marking as AwaitingSubmitter (!)
Not blocking ATM
openerp is approved with the bundled faces sources, and this revierw request is thus obsolete. CLosig