Bug#813096: AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
Hi
> I still don't see "python" in build-dependencies.
>I tried that already, but somehow it did not work out (that's why the manual
>"python2.6 | python2.7" is kept).
the reason should be the missing python dependency and the missing dh_python2 call
>I'll stay on that one (see todos), at the moment I am trying to figure out
>with strace what the rule
>
> /usr/share/dh-python/dh_python2 -p logdata-anomaly-miner
>usr/lib/aminer/AMiner usr/lib/aminer/AMinerRemoteControl
>
>is doing and why it does not detect the correct version to pass it on to
>dpkg-gencontrol.
don't know, dh --python2 should do the job.
not sure why you override that
>You are good! Funny, how dumb one can be ... Just used the stubs from previous
>packages without thinking ...
:)
IIRC I did the same mistake some years ago :D
>Would that split of old postinst solve all problems without provoking new
>ones?
I guess so
>a) new preinst: the user/creation (with #DEBHELPER#)
>b) postinst: chmod/chown, .. changes to files (WITHOUT the #DEBHELPER#)
with DEBHELPER too.
preinst <-- user creation
postinst <-- systemd start (automatically)
prerm <-- systemd stop (automatically)
postrm <-- user del and whatever
I'm not completely sure, just try, test and look at the policy
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
>OK, I have deleted for now. What about the suggestion with the CHANGELOG?
>
>Currently debian/changelog is the "packaging changelog". But the software has
>also a "feature/version changelog". Where should that be kept best? Options:
dh_installchangelogs is your friend :)
(but files that has similar names are added automatically I guess, just check if
it is added or not
>I have removed that part, both unused options and the error handling.
it should already be handled in the DEBHELPER macro, right?
>Thanks for the pointer to quilt. Seems to make sense, is on the todo list.
ok
>Understood, quilt will do here also.
yes
>OK, I will change. There is only one question open at the moment: what is the
>Debian policy for versioning of those Debian-specific build files? Could they
>be hosted just anywhere, e.g. adding them to the same upstream repository,
>used to build the source.tar.gz or should the go to a separate repository,
>perhaps even under control of Debian folks like the "Debian collab platform"?
>Would https://wiki.debian.org/Alioth/PackagingProject make sense?
whenever you want, a "debian" branch in upstream packaging, a directory on your pc
whenever is convenient for you (also alioth, collab-maint, github)
having a different branch on git will make the packaging of new releases easy as
git checkout debian
git merge vVERSION-tag
dch
and so on
(YMMW)
>Thank you very much for your answers and patience, I will do a clean package
>build after doing some more reading/testing.
keep your time :)
>Todos:
>* Fix: " dh --with=systemd,python2" somehow fails to substitute
>dependencies/version in control
>* Check transition to "pybuild" and possible side effects (see mails
>~2016-06-02) after solving the dependency problem
>* Enable quilt mode to patch upstream Launchpad source.tar.gz after deciding
>about versioning of Debian-specific patches.
irc/OFTC and #debian-python/#debian-mentors channels might be your friends,
as well as manpages :)
(or the debian-mentors mail list)
G.
Reply to: