[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#813096: marked as done (ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis)

Your message dated Sat, 11 Jun 2016 08:02:22 +0000 (UTC)
with message-id <3722958.2081739.1465632142868.JavaMail.yahoo@mail.yahoo.com>
and subject line Re: Bug#813096: AW: Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
has caused the Debian Bug report #813096,
regarding ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
813096: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813096
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
X-Debbugs-Cc: debian-mentors@lists.debian.org
Package: wnpp
Owner: Roman Fiedler <roman.fiedler@ait.ac.at>
Severity: wishlist

Package name: logdata-anomaly-miner
Version: 0.0
Upstream Author: Roman Fiedler <roman.fiedler@ait.ac.at>
URL: FIXME
Sources URL: [Seems https://alioth.debian.org/projects/collab-maint/ is 
recommended, would be nice using it. Requirements?]
License: GPLv3
Programming Lang: Python
Description: logdata-anomaly-miner is a GUI-less server component
  to analyze log lines and detect anomalies via various methods:
Dependencies: python

Long description:
  logdata-anomaly-miner allows to create log analysis
  pipelines to analyze log data streams and detect violations
  or anomalies in it. It can be run from console, as daemon with
  e-mail alerting or embedded as library into own programs. It
  was designed to run the analysis with limited resources and
  lowest possible permissions to make it suitable for production
  server use. Analysis methods include:
  .
  * static check patterns similar to logcheck but with extended
    syntax and options.
  * detection of new data elements (IPs, user names, MAC addresses)
  * statistical anomalies in log line frequencies
  * correlation rules between log lines as described in th AECID
    approach http://dx.doi.org/10.1016/j.cose.2014.09.006
  .
  The tool is suitable to replace logcheck but also to operate
  as a sensor feeding a SIEM.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


--- End Message ---
--- Begin Message --- 

Hi,

 Il Sabato 11 Giugno 2016 8:15, Fiedler Roman <Roman.Fiedler@ait.ac.at> ha scritto:


>Understood for the ITP-case. (I assumed "dpkg-source --commit" would have 
>added those lines for a reason, so I kept them). As there is no specific bug 
>to close, I removed all the lines mentioned above EXCEPT the "Author" one, as 
>this should be mandated by "dep3", if understood correctly.


yes
>What would be the correct way of handling for non-ITP bugs? Should they be 
>only mentioned in the changelog, the patches or both? Some example what I 
>could think about: "Backport of some-logic-flaw from upstream". Does Debian 
>system also use the bug reference entries from patches to auto-close bugs? I 
>assumed, that only changelog-bug references would do that?


yes, only changelog, converted in changes during the dpkg-buildpackage phase
(so, changelog is not parsed by Debian system, but the resulting changes file is)

>Seems so. As the upstream native package would also greatly benefit from these 
>changes, I will backport most of the stuff done here for the next version, 
>then we could drop most or perhaps even all of the patches. Would it make 
>sense to keep the sponsor-workflow also for those uploads (pro: learn from 
>sponsor, con: consumes sponsor's time) or becoming a maintainer (pro: shorter 
>upload workflow, con: no second opinion on own work)?
>Thanks for your patience!


becoming a Maintainer needs somebody advocating you, and this is not  possible right now.
If you want to become a DM, just do work on other packages, show/improve your skills
and somebody will eventually advocate you :)

so, for now you are stuck in the RFS workflow (or also ping me directly for this package, if you want)

For next relases:
$ AMiner
AMiner: config "/etc/aminer/config.py" not (yet) available!


AMinerRemoteControl 
Traceback (most recent call last):
File "/usr/bin/AMinerRemoteControl", line 40, in <module>
remoteControlSocket.connect(remoteControlSocketName)
File "/usr/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 2] No such file or directory


try to make it "installable and runnable", without much user intervention


G.

--- End Message ---
Reply to: