Bug 817268 - Review Request: python-faces - Python project management tool
Summary: Review Request: python-faces - Python project management tool
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Robin Lee
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AwaitingSubmitter
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-28 13:23 UTC by Alec Leamas
Modified: 2012-07-02 19:25 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-02 19:25:36 UTC
Type: ---
robinlee.sysu: fedora-review?


Attachments (Terms of Use)

Description Alec Leamas 2012-04-28 13:23:56 UTC
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.

Comment 1 Michael S. 2012-04-29 09:37:34 UTC
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 ?

Comment 2 Alec Leamas 2012-04-29 09:55:30 UTC
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.

Comment 3 Michael S. 2012-04-29 10:06:43 UTC
But I am not sure that count as a python module if there is a standalone executable.

Comment 4 Alec Leamas 2012-04-29 10:19:18 UTC
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?

Comment 5 Michael S. 2012-04-29 10:29:53 UTC
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.

Comment 6 Alec Leamas 2012-04-29 10:38:27 UTC
(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!

Comment 7 Alec Leamas 2012-04-30 03:15:15 UTC
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

Comment 8 Alec Leamas 2012-05-08 08:44:27 UTC
Robin: did you forget to set the fedora-review flag to '?'.

Comment 9 Robin Lee 2012-05-09 05:57:05 UTC
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.

Comment 10 Alec Leamas 2012-05-09 08:22:09 UTC
(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.

Comment 11 Robin Lee 2012-05-09 10:14:32 UTC
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.

Comment 12 Robin Lee 2012-05-09 10:20:05 UTC
Patching faces/__init__.py actually changes the API of the module, so I considers it too heavy.

Comment 13 Alec Leamas 2012-05-09 10:53:17 UTC
(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.

Comment 14 Robin Lee 2012-05-09 11:16:08 UTC
(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.

Comment 16 Alec Leamas 2012-05-12 05:11:59 UTC
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 (!)

Comment 17 Alec Leamas 2012-05-12 05:16:42 UTC
Not blocking  ATM

Comment 18 Alec Leamas 2012-07-02 19:25:36 UTC
openerp is approved with the bundled faces sources, and this revierw request is thus obsolete. CLosig


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