Bug 670860 - Review Request: trytond-modules - Modules for Tryton
Summary: Review Request: trytond-modules - Modules for Tryton
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Whiteboard: NotReady
Depends On:
TreeView+ depends on / blocked
Reported: 2011-01-19 14:55 UTC by Dan Horák
Modified: 2011-01-31 10:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-01-31 10:54:47 UTC

Attachments (Terms of Use)

Description Dan Horák 2011-01-19 14:55:56 UTC
This a placeholder for reviews of application modules for Tryton.

The spec files for all 48 modules are at http://fedora.danny.cz/tryton/modules/

Their generator is http://fedora.danny.cz/tryton/modules/tryton-module2spec and corresponding template is http://fedora.danny.cz/tryton/modules/tryton-module2spec.template

Comment 1 Fabian Affolter 2011-01-20 13:27:12 UTC
Just a first quick comment, please just 'global' instead of 'define' (https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define)

Comment 2 Dan Horák 2011-01-20 13:44:01 UTC
Thanks, Fabian, the template and specs at http://fedora.danny.cz/tryton/modules/ are updated.

Comment 3 Tim Lauridsen 2011-01-20 14:56:14 UTC
I have reviewed the template

Package Review

- = N/A
x = Check
! = Problem
? = Not evaluated


[x]  Package is named according to the Package Naming Guidelines. [1]
[x]  Spec file name must match the base package %{name}, in the format %{name}.spec.
[x]  Spec file is legible and written in American English.
[x]  Spec file lacks Packager, Vendor, PreReq tags.
[x]  Spec uses macros instead of hard-coded directory names.
[x]  Package consistently uses macros.
[x]  Macros in Summary, %description expandable at SRPM build time.
[x]  PreReq is not used.
[x]  All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [2]
[x]  Buildroot is correct (%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)).
[x]  Package run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) and the beginning of %install.
[x]  Package use %makeinstall only when ``make install DESTDIR=...'' doesn't work.
[x]  Package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
[-]  The spec file handles locales properly.
[x]  Changelog in prescribed format.
[x]  License field in the package spec file matches the actual license.
[x]  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.
[-]  License file installed when any subpackage combination is installed.
[x]  Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [3,4]
[x]  Sources contain only permissible code or content.
[-]  Compiler flags are appropriate.
[-]  %build honors applicable compiler flags or justifies otherwise.
[-]  ldconfig called in %post and %postun if required.
[x]  Package must own all directories that it creates.
[x]  Package does not own files or directories owned by other packages.
[x]  Package requires other packages for directories it uses.
[x]  Package does not contain duplicates in %files.
[x]  Permissions on files are set properly.
[x]  Each %files section contains %defattr.
[x]  No %config files under /usr.
[-]  %config files are marked noreplace or the reason is justified.
[-]  Package contains a properly installed %{name}.desktop using desktop-file-install file if it is a GUI application. [5]
[-]  Package contains a valid .desktop file.
[x]  Package contains code, or permissable content.
[-]  Package contains a SysV-style init script if in need of one.
[x]  File names are valid UTF-8.
[-]  Large documentation files are in a -doc subpackage, if required.
[x]  Package uses nothing in %doc for runtime.
[x]  Package contains no bundled libraries.
[-]  Header files in -devel subpackage, if present.
[-]  Static libraries in -static subpackage, if present.
[x]  Package contains no static executables.
[-]  Package requires pkgconfig, if .pc files are present.
[-]  Development .so files in -devel subpackage, if present.
[-]  Fully versioned dependency in subpackages, if present.
[x]  Package does not contain any libtool archives (.la).
[x]  Useful -debuginfo package or justification otherwise.
[x]  Rpath absent or only used for internal libs.
[x]  Package does not genrate any conflict.
[x]  Package does not contains kernel modules.
[x]  Package is not relocatable.

[x]  Package is not known to require ExcludeArch.
[x]  Package obeys FHS, except libexecdir and /usr/target.
[x]  Package meets the Packaging Guidelines. [6]

[?]  Package functions as described.
[x]  Latest version is packaged.
[x]  Package does not include license text files separate from upstream.
[-]  If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
[!]  Description and summary sections in the package spec file contains translations for supported Non-English languages, if available.
[x]  SourceX is a working URL.
[x]  SourceX / PatchY prefixed with %{name}.
[?]  Final provides and requires are sane (rpm -q --provides and rpm -q --requires).
[!]  %check is present and all tests pass.
[-]  Usually, subpackages other than devel should require the base package using a fully versioned dependency.
[?]  Reviewer should test that the package builds in mock.
[?]  Package should compile and build into binary rpms on all supported architectures.
[x]  Dist tag is present.
[x]  Spec use %global instead of %define.
[-]  Scriptlets must be sane, if used.
[-]  The placement of pkgconfig(.pc) files are correct.
[-]  No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[?]  Packages should try to preserve timestamps of original installed files.
[-]  File based requires are sane.
[-]  Man pages included for all executables.
[?]  Uses parallel make.
[-]  Patches link to upstream bugs/comments/lists or are otherwise justified.

=== Issues ===
1. None

Comment 4 Tim Lauridsen 2011-01-20 14:56:59 UTC
These MUSTS needs to be checked for each module:

[?]  Package successfully compiles and builds into binary rpms on at least one supported architecture.
[?]  Sources used to build the package matches the upstream source, as provided in the spec URL.
     MD5SUM this package     : 
     MD5SUM upstream package : 
[?]  Rpmlint output is silent.
[?]  Requires correct, justified where necessary.
[?]  Package installs properly.

Comment 5 Tim Lauridsen 2011-01-20 15:01:10 UTC
I am unsure who to handle it.

Do we need a full review for each module ?
or can we just make a partial review for each module for the points in
https://bugzilla.redhat.com/show_bug.cgi?id=670860#c4 and link to this report.

Comments please

Comment 6 Dan Horák 2011-01-20 15:25:35 UTC
I've opened the question how to deal with the modules on packaging list and Jason's opinion is to open a new request for each module. It works fine for me, I only need to prepare few helper scripts to automatize the usually manual steps. I think no one will object if the review comment for the modules will consist of a pointer to the template review here and the part from comment #4.

Comment 7 Dan Horák 2011-01-21 07:49:06 UTC
I did a license check on the tree with expanded module archives in version 1.8.0 and all 327 source files (*.py) contain the standard Tryton licensing header, few of them with a slight typos (will be fixed in next release). The command I've used is 

find . -name \*.py -o -name \*.xml | xargs grep -m 5 -L -E -e "(This file is part of Tryton.) +(The COPYRIGHT file at the top level)"

It checks also the xml data files (91) and there are 2 of them where the licensing header is missing, but upstream confirms it's an omission and will fixed in next release. Those 2 files are

The license check in the source files also means there is no bundled 3rd party library as all code is owned by Tryton.

Comment 8 Dan Horák 2011-01-21 14:25:58 UTC
Review requests for individual modules are opened, the list is here:

trytond-account-be is bug #671393
trytond-account-de-skr03 is bug #671394
trytond-account-invoice-history is bug #671396
trytond-account-invoice-line-standalone is bug #671397
trytond-account-invoice is bug #671398
trytond-account-product is bug #671399
trytond-account is bug #671400
trytond-account-statement is bug #671401
trytond-analytic-account is bug #671402
trytond-analytic-invoice is bug #671403
trytond-analytic-purchase is bug #671404
trytond-analytic-sale is bug #671405
trytond-calendar-classification is bug #671406
trytond-calendar-scheduling is bug #671407
trytond-calendar is bug #671408
trytond-calendar-todo is bug #671409
trytond-company is bug #671410
trytond-company-work-time is bug #671411
trytond-country is bug #671412
trytond-currency is bug #671413
trytond-dashboard is bug #671414
trytond-google-maps is bug #671415
trytond-google-translate is bug #671416
trytond-ldap-authentication is bug #671417
trytond-ldap-connection is bug #671418
trytond-party-siret is bug #671419
trytond-party is bug #671420
trytond-party-vcarddav is bug #671421
trytond-product-cost-fifo is bug #671422
trytond-product-cost-history is bug #671423
trytond-product-price-list is bug #671424
trytond-product is bug #671425
trytond-project-plan is bug #671426
trytond-project-revenue is bug #671428
trytond-project is bug #671429
trytond-purchase-invoice-line-standalone is bug #671430
trytond-purchase is bug #671431
trytond-sale-opportunity is bug #671432
trytond-sale-price-list is bug #671433
trytond-sale is bug #671434
trytond-stock-forecast is bug #671435
trytond-stock-inventory-location is bug #671436
trytond-stock-location-sequence is bug #671437
trytond-stock-product-location is bug #671438
trytond-stock is bug #671439
trytond-stock-supply-day is bug #671440
trytond-stock-supply is bug #671441
trytond-timesheet is bug #671442

Comment 9 Dan Horák 2011-01-21 14:29:23 UTC
I've used the bugzilla tool from python-bugzilla package to create the review requests, so I think the tool can be used also by the reviewer to submit comments, change flags etc in an efficient way.

Comment 10 Tim Lauridsen 2011-01-26 09:31:04 UTC
All the module packages should be reviewed now :)

Comment 11 Dan Horák 2011-01-26 09:40:47 UTC
My BIG THANKS to you, Tim.

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