Hide Forgot
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
Just a first quick comment, please just 'global' instead of 'define' (https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define)
Thanks, Fabian, the template and specs at http://fedora.danny.cz/tryton/modules/ are updated.
I have reviewed the template Package Review ============== Key: - = N/A x = Check ! = Problem ? = Not evaluated Template: === REQUIRED ITEMS === [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] === SUGGESTED ITEMS === [?] 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
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.
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
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.
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 ./trytond_account_de_skr03-1.8.0/account_de.xml ./trytond_sale_opportunity-1.8.0/opportunity.xml The license check in the source files also means there is no bundled 3rd party library as all code is owned by Tryton.
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
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.
All the module packages should be reviewed now :)
My BIG THANKS to you, Tim.