control: owner -1 ! control: tags -1 moreinfo Hi, lets review:
1) one single changelog entry and close the ITP bug 2) lintian W: logdata-anomaly-miner: readme-debian-contains-debmake-template E: logdata-anomaly-miner: description-starts-with-package-name W: logdata-anomaly-miner: description-starts-with-leading-spaces W: logdata-anomaly-miner: extended-description-line-too-long W: logdata-anomaly-miner: spelling-error-in-description-synopsis allows to allows one to I: logdata-anomaly-miner: spelling-error-in-manpage usr/share/man/man1/AMinerRemoteControl.1.gz allows to allows one to E: logdata-anomaly-miner: python-script-but-no-python-dep usr/lib/aminer/AMiner E: logdata-anomaly-miner: python-script-but-no-python-dep usr/lib/aminer/AMinerRemoteControl W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:30 W: logdata-anomaly-miner: maintainer-script-calls-systemctl prerm:31 3) a pybuild system might make the packaging easier to maintain 4) d/docs <-- empty 5) debian/logdata-anomaly-miner.dirs debian/logdata-anomaly-miner.install why? 6) watch: please ask on debian-mentors mail list or irc (OFTC/#debian-mentors) 7) std-version is 3.9.8 now 8) postinst has too much stuff abort-upgrade|abort-remove|abort-deconfigure) ;; *) echo "postinst called with unknown argument \`$1'" >&2 exit 1 ;; ##DEBHELPER## should take care of that part 9) prerm too, I think systemd already know to stop services during removal. 10) debian/source/format -> quilt, not native why do you have a native package? seems not something Debian specific apt-get install check-all-the-things -t experimental $ check-all-the-things $ codespell --quiet-level=3 $ find \( -name .git -o -name .svn -o -name .bzr -o -name CVS -o -name .hg -o -name _darcs -o -name _FOSSIL_ -o -name .sgdrawer \) -prune -o -empty -print $ fdupes -q -r . | grep -vE '/(\.(git|svn|bzr|hg|sgdrawer)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s $ pep8 --ignore W191 . $ pyflakes . $ pyflakes3 . # Users of binary packages do not need install instructions. $ find -type f -iname '*README*' -a ! \( -iname README.md -o -iname README.install \) -exec grep --ignore-case --fixed-strings --with-filename install {} + ./root/usr/share/doc/aminer/Readme.txt:Installation Requirements: $ grep -riE 'fixme|todo|hack|xxx' . out of time right now, if you can fix the above I'll do another trip. cheers, G. Il Lunedì 18 Aprile 2016 20:15, Fiedler Roman <roman.fied...@ait.ac.at> ha scritto: Hi, I tried to address the issues from the first review for V0.0.0 at http://mentors.debian.net/package/logdata-anomaly-miner, the changes are now in the V0.0.2~pre0 package uploaded. But still there are some points not completely clear to me: Issues from https://www.debian.org/doc/debian-policy/ * I tried to follow this one, but seem to have overlooked some points. Could someone please give me a pointer? Issues from https://www.debian.org/doc/packaging-manuals/python-policy/ * Python3: As this software especially targets production use, currently Python 2.6 is attempted to allow use over a broad range of OS. If community is sufficiently large to support a parallel Python2/3 development, Python 3 support is definitely a goal. * Python2 reference from package: Changed from #!/usr/bin/python -BEsSt to #!/usr/bin/python2 -BEsSt Is this sufficient to address the issues from the review? * Python package dependency: Not sure how to handle that in suitable way: there is no abstract "python2" package, so add a control file for to source tree for each distro to build for having the correct "python2.X" dependency in it? Or would that be better: "Depends: python2.6 | python2.7, python-tz, ${misc:Depends}" As second solution seems simpler, I prefer that. * Arch-dependency: Currently the code calls directly into libc as Python is missing quite all syscalls for secure filesystem interaction. Apart from that, no use of arch-dependent .pyc files is made: the tool is long-running, so the overhead acceptable and all the .pyc-related attack surface can be skipped for the uid=0 part of the program. Considering that, is there a change of package structure needed and if yes, which? Issues from https://packaging.python.org/en/latest/distributing/: * Does this really apply? Currently the components are packaged as application, use as a module was not attempted/tested yet. Perhaps split the application from the module later on? Current layout should be compliant with https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html, depending how the libc link for different CPU-archs is treated as mentioned above. @Native package: * Currently this mode chosen, as there is only a single source code repository for open-source upstream development also holding the Debian packaging stuff. What would be right way to split that? Remove Debian-part from upstream and instead add it to debian collab platform? Or keep both mixed but split build process into "BuildTgz" and "BuildDebPackage"? I have added a watch file because lintian complained about that, now it is complaining about the existence of the watch file. (The pubkey issue I'll fix as soon as it is clear, if a watch file is really needed). @Versioning: * I was just waiting for pointers for good versioning policy during and after porting from java. As the package was already needed to be available on Ubuntu, I started with simple versioning scheme with major.minor.sub. Source code repository is here: http://bazaar.launchpad.net/~roman-fiedler/logdata-anomaly-miner/roman-fiedl er/files More about the package releases, versioning is here: https://launchpad.net/logdata-anomaly-miner Thanks for any comments, Roman