Hi Daniel, thanks a lot for all the valuable feedback. I will dive into it later. Do you have any further recommendations on finding a sponser (after streamlining the package)? THanks a lot and kind regards Cornelius Am Sonntag, den 11.10.2015, 00:18 +0200 schrieb Daniel Stender: > Hi Cornelius, > > I can't sponsor an upload of your work, but here are the results of my review > of your package I was doing for my DD application process (I am CCing this email > to the application manager and the archives for this purpose). > > Here are some collected suggestions for improvement, > > 1) debian/changelog: the target distribution can't be "jessie". Jessie is the current > stable release, and new packages are not going to be added to that. If there's no > special reason to want to get uploaded into experimental you are heading for unstable, > codename "sid". But "unstable" is the suite resp. target name, which is going to be > used here [a]. > > [a] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#distribution > > 2) debian/changelog: you have release information in the changelog entry of your > package, but debian/changelog is reserved for changes of the Debian version of > the package [a]. For there are no changes on the package yet, "Initial release" > is all what's happening with this package. > > [a] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog > > 3) debian/changelog: the ITP bug usually gets closed by the initial upload through > a "Closes:" in the deb/changelog, which should be added to the "Initial release" > line [a]. > > [a] https://lintian.debian.org/tags/new-package-should-close-itp-bug.html > > 4) debian/watch: uscan scan fails because the watch line is missing the actual > Perl regex pattern matching the tarball. But direct scanning of Pypi for upstream > tarballs is deprecated, anyway [a]. The Python team maintains a great Pypi > redirector, which allows easy installation of a proper watch file [b]: > $ curl -o debian/watch http://pypi.debian.net/privacyidea/watch > > [a] https://lintian.debian.org/tags/debian-watch-file-unsupported-pypi-url.html > > [b] https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch > > 5) debian/control: better is to use the current debhelper (>= 9~), that also needs > a bump of the compat level to "9" in debian/compat [a]. > > [a] https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html > > 6) debian/control: the "X-Python-Version" element doesn't belong in the binary package > section, but above into the source package section [a] > > [a] https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions > > 7) debian/control: though not mandatory nor recommended by the policy [a], if the > "Homepage:" field is present in the source package section, it's easy to browse to > it from the package tracker page. > > [a] https://www.debian.org/doc/debian-policy/ch-controlfields.html > > 8) debian/control: the build-dependency against python-setuptools is redundant, and > the versioning against >= 0.6b3 is obsolete, even oldstable has 0.6.24. > > 9) debian/rules: since the tarball ships a testsuite, the tests should be run during > build time (for the package has a lot of dependencies, it would be great if also a > DEP-8 compatible test setup for Debian CI could be installed, even if you are upstream > [a,b]). > > [a] http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD > > [b] http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debci_and_the_Debian_Continuous_Integration_project.webm > > 10) debian/control: there are some errors in the package descriptions like that > "python" isn't capitalized, "authenticaion" etc. (please recheck and see the related > Lintian complaints). The description text looks like it's just a copy of the program's > documentation, and copyright statements should not be included here [a]. > > [a] https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions > > 11) debian/control: you've got Breaks and Replaces against a package "privacyidea", > but which isn't in the archive. I would guess that's a non-official package around > somewhere? I'm not sure if a use like that could be discussed, but another use (maybe > you mean the upstream version) would be unwanted, definitely [a]. > > [a] https://www.debian.org/doc/debian-policy/ch-relationships.html > > 12) debian/rules: "python_distutils" is usually put by py2dsc/stdeb as buildsystem > but you might want to use "pybuild" (that's commonly used for new packages). That > also needs a build-dep on "dh-python" in debian/control (that's recommended anyway > when you run the dh sequencer "--with python2", see the complaint in the build log). > > 13) in python-privacyidea and privacyidea-pam, you have a five executable scripts in > /usr/bin without manpages. There is a "should have" in the policy on this issue [a], > but missing manpages are considered being a bug. And if missing manpages adds to a couple > of other issues like that (like sub standard descriptions) the chance of being rejected > by the FTP team rises [b]. > > [a] https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1 > > [b] https://ftp-master.debian.org/REJECT-FAQ.html (see "Manpages") > > 14) debian/copyright: this files is the complete license text of the AGPL-3.0, but > although this is also being marked as optional in the policy [a], it would be better > if it would follow the (machine parse-able) DEP-5 copyright file format [b] instead. > > [a] https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightformat > > [b] http://dep.debian.net/deps/dep5/ > > 15) you have some third-party files in the source package which follow a > different license, like privacyidea/static/contrib/js/jquery-1.11.3.js (MIT). All > licenses and copyright holders must be listed in debian/copyright (you have to make > it DEP-5). Misses are a common reason for new packages to get rejected by the > FTP masters [a]. > > [a] https://ftp-master.debian.org/REJECT-FAQ.html (see "License III"). > > 16) debian/*.copyright: the individual copyright files for different binaries should > be dropped in favour of a DEP-5 debian/copyright, the same for all the binaries. I've > rechecked, the policy says: "a copy of the file which will be installed in > /usr/share/doc/package/copyright should be in debian/copyright in the source > package" [a]. > > [a] https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile > > 17) debian/control: the "python-" prefix for the main binary "python-privacyidea" could > be dropped, that's mend for packages with public modules used by other packages [a] > (there might be different opinions on if you should keep it like it is). But the build-dep > on python-all should be replaced with "python", for that package doesn't need > to get build against any/all supported Python versions, but only the default one. > > [a] https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names > > 18) maybe you would like to build the Sphinx documentation in doc/ into a > privacyidea-docs package. As far as I see it doesn't make much sense to run this application > offline, but it would be more comfortable to have the documentation that way, instead of > only on the web. > > 19) maintscripts: you have two symlinks in debian/, privacyidea-apache2.postinst and > privacyidea-nginx.postinst which are dead (it's "../deploy/debian-ubtuntu/" instead of > "../debian-ubuntu/"). They should be replaced by the actual scripts. Policy 6.1: > "... they must be proper executeable files" [a] (and not symlinks). The others aren't > executable here, either. > > [a] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html > > 20) debian/privacyidea-radius.postinst: there's a Lintian complaint of running > the "service" command for a restart-after-upgrade, which isn't wanted for maintainer > scripts. > > 21) the manpage ./usr/share/man/man1/privacyidea-server.1.gz has a Lintian complaint > on "manpage-has-errors from-man" [a], and furthermore there is the problem that this > manpage is in section "1", which is reserved for binaries resp. executables, but this > is a general documentation. That's pre generated out of the Sphinx docs, maybe you > would like to put this out in plain text and put it into /usr/share/docs/, if not going > for 18), instead (and manpages aren't handled by debian/install, either). > > [a] https://lintian.debian.org/tags/manpage-has-errors-from-man.html > > 22) you've got important Lintian complaints on privacy breaches (fetching data from > external websites on runtime) in some of the Javascript libraries in > privacyidea/static/contrib/js/ (angular.js and ui-bootstrap-tpls-0.13.0.js), > this must be patched out. > > 23) There are some more Lintian complaints on things copied into the binaries, which aren't > wanted (image-file-in-usr-lib, extra-license-file), please make your package Lintian clean! > > 24) there are some more issues on the source tarball (contains .pyc bytecode files, prebuild > Javascript objects), and maybe you would like to remove docs/sphinx_rtd_theme.zip from the > source package (and use the package python-sphinx-rtd-theme). You might want to use "Files-Excluded:" > in debian/copyright [a] to created a reduced Debian tarball via uscan. > > [a] https://wiki.debian.org/UscanEnhancements > > I'm sure that privacyIDEA would be a great addition to the Debian archive (I'm going to watch > the talk on Datenspuren 2014 [a] after I've sended this), and I would really like to see that > package pass the sponsoring-requests stage and that you'll find a sponsor. > > [a] https://www.youtube.com/watch?v=fvKPQMpvYnw > > Best, > Daniel Stender >
Attachment:
signature.asc
Description: This is a digitally signed message part