Bug#821736: prewikka: New prewikka version 1.2.6

[Thomas ANDREJAK]

Package: prewikka
Severity: normal

Dear Maintainer,

Since the end of 2015, there is a new version of Prewikka (and all Prelude 
modules) : 1.2.6
You can find the tarball here : 
https://www.prelude-siem.org/projects/prelude/files

Please, upgrade from 1.0.0 (2010) to 1.2.6 (2015)

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#754773: libprelude: New upstream version 3.1.0

[Thomas Andrejak]

Hello

I want to help to update this package but I'm new with debian process
so let me know if I'm wrong.

You can find in attachment a proposition for the new debian package.

Regards

Thomas


libprelude_3.1.0-1.debian.tar.xz
Description: Binary data

Bug#754773: libprelude: New upstream version 3.1.0

[Thomas Andrejak]

Here is a better version with a patch format

2017-03-02 1:14 GMT+01:00 Thomas Andrejak <thomas.andre...@gmail.com>:
> Hello
>
> I want to help to update this package but I'm new with debian process
> so let me know if I'm wrong.
>
> You can find in attachment a proposition for the new debian package.
>
> Regards
>
> Thomas


libprelude-1.0.0_to_3.1.0.patch
Description: Binary data

Bug#754773: libprelude: New upstream version 3.1.0

[Thomas Andrejak]

Here is a proper debdiff of debian folder to bump libprelude version
from 1.0.0 to 3.1.0

The full debdiff with source diff is about 20M

Regards

Thomas

2017-03-10 11:08 GMT+01:00 Thomas Andrejak <thomas.andre...@gmail.com>:
> Here is a better version with a patch format
>
> 2017-03-02 1:14 GMT+01:00 Thomas Andrejak <thomas.andre...@gmail.com>:
>> Hello
>>
>> I want to help to update this package but I'm new with debian process
>> so let me know if I'm wrong.
>>
>> You can find in attachment a proposition for the new debian package.
>>
>> Regards
>>
>> Thomas


libprelude_3.1.0-0.1.debdiff
Description: Binary data

Bug#872260: libpreludedb: New upstream version 3.1.0

[Thomas Andrejak]

Source: libpreludedb
Version: 1.0.0-2.4+b2
Severity: wishlist

libpreludedb 3.1 was released in 2016.

Thanks

Regards

Bug#868540: transition: libprelude

[Thomas Andrejak]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

New upstream version of libprelude (3.1.0) changes its soname from 2 to 23 for
low level library (libprelude2 -> libprelude23) and form 0 to 2 for high level
library (libpreludecpp0 to libpreludecpp8). Can you please create a new
transition slot for this ?

Affected packages (test rebuild OK):
* audit
* libpreludedb
* nufw
* prelude-lml
* suricata
* prelude-manager
* samhain

Ben file:

title = "libprelude";
is_affected = .depends ~ "libprelude2" | .depends ~ "libpreludecpp0" |
.depends ~ "libprelude23" | .depends ~ "libpreludecpp8";
is_good = .depends ~ "libprelude23" | .depends ~ "libpreludecpp8";
is_bad = .depends ~ "libprelude2" | .depends ~ "libpreludecpp0";

Thanks

Regards

Thomas

Bug#866957: libprelude: move the package from experimental to unstable and do the transition

[Thomas Andrejak]

Source: libprelude
Version: 3.1.0-0.3
Severity: medium
Justification: New upstream version

Actual version in unstable: 1.0 and package name is libprelude2
Actual version in experimental: 3.1 and package name is libprelude23

Please, move the package from experimental to unstable and do the transition.

If you need, I can help you by doing the transition.

Because your latest push on libprelude is from a long time, I can help
you on the package maintenance by becoming a comaintainer.

Thanks

Regards

Thomas

Bug#875533: prelude-manager: New upstream version 3.1.0

[Thomas Andrejak]

Source: prelude-manager
Version:1.0.1-5.2
Severity: wishlist

prelude-manager 3.1 was released in 2016.

Thanks

Regards

Bug#878607: prelude-lml: New upstream version 3.1.0

[Thomas Andrejak]

Source: prelude-lml
Version: 1.0.0-5.3
Severity: wishlist

prelude-lml 3.1 was released in 2016.

Thanks

Regards

Bug#876709: libpreludedb FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

[Thomas Andrejak]

Source: libpreludedb
Version: 3.1.0-0.1
Severity: serious

As for libprelude
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876591), please fix
gtk-doc in libpreludedb

Bug#884673: prelude-correlator: New upstream version 3.1.0

[Thomas Andrejak]

Source: prelude-correlator
Version: 1.0.0-1.1
Severity: wishlist

prelude-correlator 3.1 was released in 2016.

Thanks

Regards

Bug#880799: ITP: prelude-lml-rules -- Rules for Prelude LML package

[Thomas Andrejak]

Package: wnpp
Severity: wishlist
Owner: Thomas Andrejak <thomas.andre...@gmail.com>

* Package name: prelude-lml-rules
  Version : 3.1.0
  Upstream Author : Thomas Andrejak <thomas.andre...@gmail.com>
* URL : https://www.prelude-siem.org/
* License : GPL-2
  Programming Lang: C, Python
  Description : Rules for Prelude LML package

Rules for Prelude LML contributed by the community

Since Prelude 1.1, rules of Prelude LML are in an other package that the
initial prelude-lml. This new package is prelude-lml-rules and has to be
packaged for new prelude-lml versions.

I plan to maintain it.

Bug#885535: prewikka: New upstream version 3.1.0

[Thomas Andrejak]

Source: prewikka
Version: 1.0.0-1.3
Severity: wishlist

prewikka 3.1 was released in 2016.

Thanks

Regards

Bug#888548: kismet: Update to a more recent version

[Thomas Andrejak]

Source: kismet
Version: 2016.07.R1-1
Severity: wishlist

The actual version is 2016 and start to be old. Please update to a
more recent version.

Regards

Thanks

Thomas

Bug#887940: [Pkg-postgresql-public] Bug#887940: libpq-dev:

[Thomas Andrejak]

On Tue, 23 Jan 2018 09:50:32 +0100 Christoph Berg  wrote:
> Control: reassign -1 src:libpreludedb
>
> Re: Adrian Bunk 2018-01-23 <20180123043023.GA11847@localhost>
> > > > ./configure: line 19300: test: too many arguments
> > > > ...
> > >
> > > Looks like the ax_lib_postgresql.m4 macro should be fixed with some
> > > additional shell quoting.
> >
> > This is not about quoting, the pg_config output changed:
> >
> > 10.1-3:
> > $ pg_config --version
> > PostgreSQL 10.1 (Debian 10.1-3)
>
> The macro is buggy anyway, it decomposes the string into
> major/minor/micro, but the middle component doesn't exist anymore with
> PostgreSQL 10. That was fine with 10.0, but with 10.1, it will think
> there was a new major release "10.1".
>
> Both issues need to be fixed on the libpreludedb side.
>

OK but m4 came from autoconf-archive, they have to provide a new m4
not buggy so we can update it inside libpreludedb.

Regards

Thomas

Bug#891800: libprelude: New upstream version 4.1.0

[Thomas Andrejak]

Source: libprelude
Version: 3.1.0-1
Severity: wishlist

libprelude 4.1 was released in 2017.

Thanks

Regards

Bug#892789: prelude-manager: New upstream version 4.1.0

[Thomas Andrejak]

Source: prelude-manager
Version: 3.1.0-4
Severity: wishlist

prelude-manager 4.1 was released in 2017.

Thanks

Regards

Bug#892553: libpreludedb: New upstream version 4.1.0

[Thomas Andrejak]

Source: libpreludedb
Version: 3.1.0-2
Severity: wishlist

libpreludedb 4.1 was released in 2017.

Thanks

Regards

Bug#832049: python-parsley: please update to 1.3

[Thomas Andrejak]

Hello

Is it possible to go forward on this ?

If you need, I can help you

Thanks

Regards

On Thu, 21 Jul 2016 19:13:45 + Mattia Rizzolo  wrote:
> control: reassign -1 src:parsley 1.2-1
>
> On Thu, Jul 21, 2016 at 02:42:18PM -0400, Matthew Haughton wrote:
> > Source: python-parsley
>
> there is no source package with this name, I suppose you wanted
> 'parsley' instead ('python-parsley' is the name of the binary produced).
>
> reassigning accordingly.
>
> > Current package is out of date. Version 1.3 was released September 9, 2015.
> >
> > Note that the new version claims support for Python 3 which may
> > requires packaging updates.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#893233: python-lesscpy: python3-lesscpy not working with python 3.5 or newer

[Thomas Andrejak]

Here is the upstream bug : https://github.com/lesscpy/lesscpy/issues/85


When starting a simple lesscpy compile command, I got the same error.

Bug#893233: python-lesscpy: python3-lesscpy not working with python 3.5 or newer

[Thomas Andrejak]

Source: python-lesscpy
Version: 0.10-1
Severity: important

python-lesscpy 0.10 do not support python 3.5 or newer. Please upgrade
this package to have a working python-lesscpy with python3.

The actual stable upstream version is 0.13

Thanks

Regards

Bug#923356: unblock: prelude-lml/4.1.0-1+b2

[Thomas Andrejak]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package prelude-lml

The package was removed from testing due to a bad purge script which has just 
been fixed (#919869).
Prelude-LML is an important part of the Prelude suite, it would be nice to have 
it.

The fix has been accepted by Mattia Rizzolo: 
https://tracker.debian.org/news/1032409/accepted-prelude-lml-410-2-source-into-unstable/

Thank you,

Thomas Andrejak

unblock prelude-lml/4.1.0-1+b2

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#941657: Needed too

[Thomas Andrejak]

Hello

I'm also interested. I need it to bump version of Prewikka.

If you want, we can co-maintain the package

Thanks

Regards

Thomas

Bug#945088: prewikka: depends on unexisting package

[Thomas Andrejak]

Hello

I'm waiting for this ITP :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941657

Regards

Thomas

Le mar. 19 nov. 2019 à 14:15, Gianfranco Costamagna <
locutusofb...@debian.org> a écrit :

> Source: prewikka
> Version: 5.1.1-1
> Severity: serious
>
> Hello,
> prewikka/amd64 unsatisfiable Depends: python3-lark-parser
> prewikka/i386 unsatisfiable Depends: python3-lark-parser
>
> Does this package depend on something that is not yet in the archive?
>
> Can you please have a look? Testing migration is stalled by this
>
>
> Gianfranco
>
>

Bug#941657: python-lark-parser -- Change of plans?

[Thomas Andrejak]

Hello Peter,

Thanks for trying.

Regarding the situation, I'm OK with you.

Regards

Thomas

Le lun. 23 déc. 2019 à 17:44, Peter Wienemann  a écrit :

> Hi Thomas,
>
> On 30.10.19 21:07, Peter Wienemann wrote:
> > Getting lark-parser into Debian requires more work than packaging
> > lark-parser itself. That is why this bug is blocked by #943783 which in
> > turn is blocked by #943785.
> >
> > Progress on #943785 can be tracked here:
> >
> > https://salsa.debian.org/python-team/modules/python-pyjsparser
> >
> > My work on #943783 is presently slowed down by a problem with a js2py
> > unit test error [0]. After some necessary clean-up I will push my js2py
> > packaging work in progress to
> >
> > https://salsa.debian.org/python-team/modules/python-js2py
> >
> > Peter
> >
> > [0] https://github.com/PiotrDabkowski/Js2Py/issues/185
>
> after a discussion with upstream [0] and a lack of feedback on the js2py
> issue [1] I tend to go forward without the Nearley conversions in
> lark-parser and consequently stop the efforts to get pyjsparser and
> js2py into Debian.
>
> Would that be fine for your use case, too?
>
> Best regards, Peter
>
> [0] https://github.com/lark-parser/lark/issues/501
> [1] https://github.com/PiotrDabkowski/Js2Py/issues/185
>

Bug#941657: name change: python-lark-parser -> python-lark

[Thomas Andrejak]

Hello

Why changing the name ? it's named lark-parser in pypi.

Moreover, in pypi, there already is a "lark" module which is not lark-parser

Regards

Thomas

Le sam. 28 déc. 2019 à 05:03, Peter Wienemann  a écrit :

> Following the suggestions in
>
> https://bugs.debian.org/945823
>
> I have changed the name from python-lark-parser to python-lark.
>
> The new repository URL is
>
> https://salsa.debian.org/python-team/modules/python-lark
>
> Peter
>
> --
> To unsubscribe, send mail to 941657-unsubscr...@bugs.debian.org.
>

Bug#941657: name change: python-lark-parser -> python-lark

[Thomas Andrejak]

Hello

I asked "why changing the name" because (OK, I'm the author of some, but
not all) :
- On Fedora/EPEL : it is lark-parser
https://src.fedoraproject.org/rpms/python-lark-parser
- On gentoo : it is lark-parser
https://github.com/gentoo/gentoo/tree/master/dev-python/lark-parser
- On Arch Linux : it is lark-parser
https://www.archlinux.org/packages/community/any/python-lark-parser/
- On OpenSuse : it is lark-parser
https://software.opensuse.org/package/python-lark-parser

After that, I understand all arguments. I let you choose the final name. In
the end, the most important is to be able to do "import lark" :)

Regards

Thomas

Le lun. 30 déc. 2019 à 21:43, Simon McVittie  a écrit :

> On Mon, 30 Dec 2019 at 17:15:54 +0100, Peter Wienemann wrote:
> > https://bugs.debian.org/945823
> >
> > which says:
> >
> > "use the name you import in preference to the name from the PKG-INFO".
> >
> > That is why I decided to change the name to python-lark. But given the
> > PyPI name clash this is certainly not optimal either. So this seems to
> > be a particular unfortunate case.
>
> If there are two modules on PyPI, both of which you use via
> "import lark", then they cannot both be installed correctly into the
> system-wide module search path on the same Debian system - if they
> were, even if they happen to avoid having directly conflicting files
> (because one is /usr/lib/python3/dist-packages/lark.py and the other is
> /usr/lib/python3/dist-packages/lark/__init__.py, or similar), installing
> both and using "import lark" would not consistently import the one you
> intended to use, leading to broken programs.
>
> So the rule has served its purpose: it has detected a conflict that needs
> to be avoided somehow.
>
> For users of virtualenv there is perhaps no problem, because you can
> install the lark you wanted in a particular virtualenv and avoid installing
> the other lark, but Debian packages are a flat global namespace of modules.
>
> There are two options:
>
> * If "lark" on PyPI is a dead project, or otherwise something that is never
>   going to be useful to package in Debian for some reason, then perhaps
> it's
>   safe for the lark parser to claim the python3-lark name.
>
> * Otherwise, if its PyPI name is lark-parser, then I would personally
>   recommend asking the upstream developer to rename the module you import
>   to lark_parser (or maybe larkparser if that's preferred), and packaging
>   it as python3-lark-parser (or python3-larkparser), optionally with
>   compatibility glue to make "import lark" continue to work (which might
> not
>   get packaged in Debian).
>
> (I'm talking about binary package names python3-foo because those are the
> most important thing for avoiding conflicts, but if the binary package
> name is python3-foo then it probably makes most sense for the source
> package to be python-foo.)
>
> smcv
>

Bug#959150: Add support for Prelude

[Thomas Andrejak]

Package: clamav

Version: 0.102.2

Please enable Prelude support:

* d/control: Add libprelude-dev Build-Depends

* d/rule: Add --enable-prelude to the ./configure

Thanks

Regards

Thomas

Bug#959150: [Pkg-clamav-devel] Bug#959150: Add support for Prelude

[Thomas Andrejak]

Hello

Thanks for your reply.

The performance you pointed out is about the database inserts, not the
libprelude used by ClamAV. So, for an security tool, there is no
performance issue. For a Prelude end user, if he gets too many alerts per
seconds, there are mechanisms to filter this and do not fall into
performance issues.

For your information, Suricata already enable prelude support in it's
packages and there is no issue.

Regards

On Wed, 29 Apr 2020 23:31:34 + Scott Kitterman 
wrote:
> According to the prelude web site:
>
> Prelude OSS is the open source edition of Prelude SIEM . Prelude OSS is
aimed for evaluation, research and test purpose on very small environments.
Please note that Prelude OSS performances are way lower than the Prelude
SIEM edition.

>
> What testing have you done to determine the performance implications of
the proposed change?
>
> Scott K
>
> On April 29, 2020 11:15:43 PM UTC, Thomas Andrejak <
thomas.andre...@gmail.com> wrote:
> >Package: clamav
> >
> >Version: 0.102.2
> >
> >Please enable Prelude support:
> >
> >* d/control: Add libprelude-dev Build-Depends
> >
> >* d/rule: Add --enable-prelude to the ./configure
> >
> >Thanks
> >
> >Regards
> >
> >Thomas
>
>

Bug#959150: [Pkg-clamav-devel] Bug#959150: Add support for Prelude

[Thomas Andrejak]

Hello

How can I help you to go forward on this ?

Enabling prelude support should be easy

Regards

Thomas

Le jeu. 30 avr. 2020 à 09:09, Thomas Andrejak  a
écrit :

> Hello
>
> Thanks for your reply.
>
> The performance you pointed out is about the database inserts, not the
> libprelude used by ClamAV. So, for an security tool, there is no
> performance issue. For a Prelude end user, if he gets too many alerts per
> seconds, there are mechanisms to filter this and do not fall into
> performance issues.
>
> For your information, Suricata already enable prelude support in it's
> packages and there is no issue.
>
> Regards
>
> On Wed, 29 Apr 2020 23:31:34 + Scott Kitterman 
> wrote:
> > According to the prelude web site:
> >
> > Prelude OSS is the open source edition of Prelude SIEM . Prelude OSS is
> aimed for evaluation, research and test purpose on very small environments.
> Please note that Prelude OSS performances are way lower than the Prelude
> SIEM edition.
>
> >
> > What testing have you done to determine the performance implications of
> the proposed change?
> >
> > Scott K
> >
> > On April 29, 2020 11:15:43 PM UTC, Thomas Andrejak <
> thomas.andre...@gmail.com> wrote:
> > >Package: clamav
> > >
> > >Version: 0.102.2
> > >
> > >Please enable Prelude support:
> > >
> > >* d/control: Add libprelude-dev Build-Depends
> > >
> > >* d/rule: Add --enable-prelude to the ./configure
> > >
> > >Thanks
> > >
> > >Regards
> > >
> > >Thomas
> >
> >
>

Bug#959150: Add support for Prelude

[Thomas Andrejak]

Hello

Thanks for the reply.

Yes, the 5.1 version is under GPLv2 but next version that will be release
shortly is under LGPLv2
https://www.prelude-siem.org/projects/libprelude/repository/revisions/55f478f4ae5aa8b30372e7a0e3cf20ebe52df889

So if I well understand, it will be OK with this new version ?

Is that the only issue that block the packaging for you ?

Regards

Le sam. 11 juil. 2020 à 12:32, Sebastian Andrzej Siewior
 a écrit :

> On 2020-07-07 00:24:18 [+0200], To Thomas Andrejak wrote:
> > On 2020-07-06 11:19:21 [+0200], Thomas Andrejak wrote:
> > > How can I help you to go forward on this ?
> > >
> > > Enabling prelude support should be easy
> >
> > Let me try look at this this week.
>
> So enabling prelude at build time will pull in the libprelude package.
> Runtime wise it does nothing unless enabled in the config file. Doesn't
> look too bad.
> The libprelude seems to be under GPLv2 (there parts of the library under
> LGPLv2+ but my understanding is that there are parts of the library under
> GPL). There is no OpenSSL license exception and my understanding is that
> we need this even for dependencies. See also #924937 where this
> currently discussed for other packages. I don't see that I can enable it
> at this time.
> There is an upcoming OpenSSL 3.0 is under the Apache-2 license which
> still doesn't work unless the license is v2 or later. The alternative
> would be an OpenSSL license exception. Upstream seem to have moved from
> OpenSSL to GnuTLS due to license issues instead of granting an excpetion
> and be done with it. See
>   https://www.prelude-siem.org/issues/19
>
> > > Regards
> > >
> > > Thomas
>
> Sebastian
>

Bug#959150: Add support for Prelude

[Thomas Andrejak]

Hello Sebastian,

The new libprelude is in debian testing as you can see here :
https://tracker.debian.org/pkg/libprelude

Is it possible to re-work on this issue ?

Thanks

Regards

Thomas

Le ven. 17 juil. 2020 à 00:06, Sebastian Andrzej Siewior
 a écrit :

> On 2020-07-12 15:12:12 [+0200], Thomas Andrejak wrote:
> > Yes, the 5.1 version is under GPLv2 but next version that will be release
> > shortly is under LGPLv2
> >
> https://www.prelude-siem.org/projects/libprelude/repository/revisions/55f478f4ae5aa8b30372e7a0e3cf20ebe52df889
> >
> > So if I well understand, it will be OK with this new version ?
> >
> > Is that the only issue that block the packaging for you ?
>
> I don't know if the OpenSSL license is compatible with LGPLv2, I will
> have to double check once it gets to it. I ping would be nice once the
> library in Debian.
> From browsing over the issue, libircclient is LGPLv2 and not linked
> against OpenSSL.
>
> Aside from that I don't see any other issue.
>
> > Regards
>
> Sebastian
>

Bug#1009425: prewikka: FTBFS: AttributeError: module 'collections' has no

[Thomas Andrejak]

On Sun, 8 May 2022 09:42:13 +0200 s3v  wrote:
> Dear Maintainer,
>
> >   File "/usr/lib/python3/dist-packages/lesscpy/lessc/utility.py", line
28, in flatten
> > if isinstance(elm, collections.Iterable) and not isinstance(elm,
string_types):
> > AttributeError: module 'collections' has no attribute 'Iterable'
>
> This issue belongs to python3-lesscpy and has been fixed upstream [1]

So I need to fix something or just wait python3-lesscpy to be fixed ?

Thanks for your help


>
> Kind Regards
>
> [1]
https://github.com/lesscpy/lesscpy/commit/0bbcf058e9ca6715c73f8e438529a837476978c3
>
>