Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
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.Fiedler@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
Reply to: