AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

2016-06-09 Thread Fiedler Roman
> Von: Piotr Ożarowski []
> [Fiedler Roman, 2016-06-09]
> > > is AMiner and AMinerRemoteControl symlinked in /usr/bin/?
> > > (you can use debian/logdata-anomaly-miner.links to do that)
> >
> > Currently they are not symlinked. I took the same approach as with
> > e.g. /usr/lib/apt/methods/http or /usr/lib/eject/dmcrypt-get-device
> > where those binaries are usually not intended to be called by user
> > directly. Meanwhile this has changed, e.g. AMinerRemoteControl is more
> > or less now OK for cmd-line use. So I would add the symlinks. Or would
> > moving of the files be more Debianic?
> dh_python2 doesn't add interpreter to Depends for scripts that are not
> in $PATH. That's why lintian complains. You can:
> * symlink them in /usr/bin/ (or any other appropriate path)

I did that, modification:

$ cat debian/logdata-anomaly-miner.links 
/usr/lib/logdata-anomaly-miner/AMiner /usr/bin/AMiner
/usr/lib/logdata-anomaly-miner/AMinerRemoteControl /usr/bin/AMinerRemoteControl

> * drop executable bit from these scripts, if they're not meant to be
>   execute  (IIRC lintian ignores shebangs in non-executable files)

not an option

> * or if they're meant to be executed, but you don't want them to be
>   available out of the box, add "python" to Suggests or Recommends

There are some usecases for users to call them, so let's have them available 

Still lintian will complain about this file, current header:

#!/usr/bin/python2 -BEsSt

But as patching that to 2.7 will make the warnings go away, from my point of 
view, that workaround is sufficient for me.

New package is uploaded.

Are there any other open points I shall address?

Description: S/MIME cryptographic signature

AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

2016-06-09 Thread Fiedler Roman
> Von: Piotr Ożarowski []
> just a quick reply:
> * private dir is the right call, do not install into dist-packages
>   (only "python-*" binary packages should install there)

OK, done.

> * install into /usr/lib/logdata-anomaly-miner/ and dh_python2 will pick
>   it up without any overrides, additional options, etc.

So I guess, before that (where dh_python2 refused to operate at all), using 
/usr/lib/aminer as a shorthand - as the package name is quite long - was a bad 

As import names cannot contain a dash, is use of 
"usr/lib/logdata-anomaly-miner/aminer" as module storage directory and "aminer" 
as shorthand module name in imports OK?

> * use dh --with python2 or dh_python2 (/usr/bin/dh_python2) but never
>   ever depend on internal implementation detail. I will change
>   /usr/share/dh-python/dh_python2 file name just to mess with you ;-P

OK. Understood. Using the "usr/lib/logdata-anomaly-miner" layout for python 
stuff as recommended above, dh_python2 is more happy with the situation: It 
would complain about "python:Versions" substitution in

./debian/control:XB-Python-Version: ${python:Versions}

but XB-.. should be deprecated anyway. I dropped also " XS-Python-Version" 
(which was hardcoded to >=2.6), as substitution would not work here also.

Still when building, lintian is unhappy with the output package:

E: logdata-anomaly-miner: python-script-but-no-python-dep 
E: logdata-anomaly-miner: python-script-but-no-python-dep 

Since the situation became a lot of clearer using your suggestions, I will 
again try to tackle the lintian issue.


> --
> Piotr Ożarowski Debian GNU/Linux Developer
> GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Description: S/MIME cryptographic signature

AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

2016-06-09 Thread Fiedler Roman
> Von: Gianfranco Costamagna []
> Hi,
> (answering where I can!)
>> Moving the code to "/usr/lib/python2.7/dist-packages/aminer" in fact allows
>> dh_python2 to extract the version information:
>> Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), python-tz,
>> init-system-helpers (>= 1.18~)
>> (Remark: Is there any reason to restrict the versions to >=2.7.5? The tools
>> should have compatibility with >=2.6 and I would expect the "Depends"
>> section
>> to somehow reflect that reality. Is DEBPYTHON_SUPPORTED and
>> DEBPYTHON_DEFAULT intended to be used to fix that?)
> that stuff is built for unstable/testing, so the variables are filled
> with the current python situation
> (2.6 is only on old-stable, and Stretch has 2.7.11 already).
> Probably if you try to build it with a jessie chroot, you get different 
> values, and this is correct.
> (you can't in general install deb built against stretch into wheezy/jessie, 
> without
> breaking stuff, this is why some dependencies are not too relaxed, to avoid 
> people
> doing that, but instead upgrading the minimal set of packages to make sure
> things will work after the apt-pinning).
> I don't foresee any issue here, because even in case of a backport, the
> package will need to be rebuilt on top of that.

OK, so I will not attempt to fiddle with that and stick to the stricter 

> >But doing the move, lintian will not like the produced package any more:
> >
> >E: logdata-anomaly-miner: python-script-but-no-python-dep 
> >usr/lib/aminer/AMiner
> I can't say, I don't see the package installing stuff in usr/lib/python* on
> mentors

Maybe the hints from Piotr Ożarowski's followup mail will fix that, using his 

> >The rationale behind not putting aminer into dist-packages (and removing
> >dist-packages from python-path) was:
>> [Snip]
> >b) prepare against possible future risks due to accidental loading (call to
> >__init__) of other packages residing in dist-packages, that may give rise to
> >privilege escalation (like the GNU-TLS CVE from this/last week)
> mmm you want to avoid people importing your library?
> ok

Not directly avoid, but make them think more about it before adding. I also 
remember having issues with some svg-python library, that starts to misbehave 
as soon as other packages are installed because of "try: import xxx; ..." 
blocks. Just want to reduce the risks.
> >Of course, it should be possible to move the code to
> >/usr/lib/python2.7/dist-packages/aminer and perform the "link" operation,
> but
> >this could make it more "sexy" for an admin to include whole dist-packages
> in
> >python path again.
> >In that light, should the code be moved?
> leaving to other folks the answer
> >Apart from that, this will also make it harder to use the same codebase for
> >both python2.6/python2.7, but that should be fixable by providing more
> >patches.
> you can't use python2.6 on Stretch, so no issue here.

Understood, dropping the 2.6/2.7 compatibility stuff
> >> >-#!/usr/bin/python2 -BEsSt
> >> >+#!/usr/bin/python2.7 -BEsSt
> >>
> >> this should be also handled by dh_python2 AFAIK
> >
> >Even with move dh_python2 does not touch the files. The only difference is,
> >that lintian does not like the files any more.
> can you please double check with the documentation?

The "python2" selection in the binaries was effect of reading it, but perhaps I 
got something wrong:

Intro: "It (the LibraryStyleGuide) is not intended to supplant the Debian 
Python Policy and in fact, if you have not read that document, stop now and go 
read it"

And from " Debian Python Policy"

"Python scripts that require the default Python 2 version should specify 
python2 as the interpreter name."

So should be OK in my opinion.

> [Snip]

Description: S/MIME cryptographic signature