On Wed Jan 07 2015 at 11:11:08 AM Javier Fernandez-Sanguino <
j...@computer.org> wrote:
>
> With the upcoming ntopng, will ntop upstream still provide security
> support for previous ntop releases (i.e to version 5.0 which is in testing)
> ?
>
No.
> If upstream is *not* going to provide security
Hi,
I am maintaining both ntop and ntopng. They are both in testing.
ntop is no longer supported by upstream and I would like to remove it from
Debian.
ntopng is a complete rewrite of ntop.
How would you recommend to phase it out?
I could have ntopng include a ntop transitional package, but:
-
On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett wrote:
> On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
>> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
>> > 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> > sett
On Sun, Aug 17, 2014 at 4:20 AM, Marc Haber
wrote:
> On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl
> wrote:
>>I also happen to notice, that you use a ENABLED=1 flag.
>>It would be a good idea to deprecate that as well and remove that.
>>
>>We have better mechanisms nowadays to enable/disable
Josh,
On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> settings there.
yes, that would be an option. I forgot to add the requirement "without
patching upstream code" :)
> 4) Teach ntopng to automatically detect the
Hi,
I am writing a systemd service file for a daemon (ntopng) and I would
like to know what you think is the best way to load some
configuration.
The ntopng daemon takes multiple interfaces in the format of multiple
-i command-line options. For example.
ntopng -i eth0 -i wlan0
Currently the inte
Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon
* Package name: ndpi
Version : 1.4.0
Upstream Author : Luca Deri
* URL : http://www.ntop.org/products/ndpi/
* License : LGPL-3
Programming Lang: C
Description : extensible deep packet inspection
Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon
* Package name: ntopng
Version : 1.0
Upstream Author : Luca Deri
* URL : http://www.ntop.org/products/ntop/
* License : GPL-3
Programming Lang: C++
Description : High-Speed Web-based Traffic
On 04/30/2011 04:32 PM, Pierre Habouzit wrote:
> FWIW I think that "rolling" or "CUT" miss the point entirely. As a
> Debian user I use stable on my servers (with a few backports for the 3-4
> things I need bleeding edge for). For my desktop I use unstable, and
> when that breaks (which is *very* r
Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon
* Package name: geoip-database-contrib
Version : 1.0
Upstream Author : Ludovico Cavedon
* URL :
http://git.debian.org/?p=collab-maint/geoip-database-contrib.git
* License : GPL-2+
Programming Lang
On 09/06/2010 10:46 PM, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport main
On Tue, Apr 27, 2010 at 7:40 AM, Marco d'Itri wrote:
> On Apr 27, Juliusz Chroboczek wrote:
>> But you're breaking peoples' systems *now*. And breaking systems
> Which ones? There is only one bug open (gdm) and it has patches.
>
> Based on this data I believe that the change has been a great suc
On Tue, Apr 6, 2010 at 11:20 PM, Vincent Danjean wrote:
> ...and squeeze should be released with the default value that minimizes
> the number of broken behavior (not the number of bugs because whatever
> the default value is, if the application depends on a particular default
> value, the bug exi
Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon
Owner: Ludovico Cavedon
* Package name: javacc-maven-plugin
Version : 2.6
Upstream Author : Jesse McConnell
* URL : http://mojo.codehaus.org/javacc-maven-plugin/
* License : Apache-2
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon
Owner: Ludovico Cavedon
* Package name: cssparser
Version : 0.9.5
Upstream Author : David Schweinsberg.
* URL : http://cssparser.sourceforge.net/
* License : LGPL
Programming Lang: Java
Description
Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon
* Package name: htmlunit-core-js
Version : 2.7
Upstream Author : Mike Bowler
* URL : http://htmlunit.sourceforge.net/
* License : MPL-1.1
Programming Lang: Java
Description : JavaScript language
Hi,
The jcc package [1] has been out of date for a long time.
Back in July 2009 I offered [2] to help with the package or adopt it,
but got no answer from the maintainer.
A couple of weeks ago I decided to upload it with a 10-days NMU (which
was anyway needed to fix a RC bug [3]), but still no fe
Kurt Roeckx wrote:
>> qutecom: relocation error: /usr/lib/qutecom/libphapi.so: symbol
>> CRYPTO_malloc_debug_init, version OPENSSL_0.9.8 not defined in file
>> libcrypto.so.0.9.8 with link time reference
>>
>
> It seems I missed that that symbol changed from a define to a
> real symbol and didn't
Hi,
If you see en error message like this one (from [1]):
qutecom: relocation error: /usr/lib/qutecom/libphapi.so: symbol
CRYPTO_malloc_debug_init, version OPENSSL_0.9.8 not defined in file
libcrypto.so.0.9.8 with link time reference
does it mean than openssl changed ABI without an SO chanage? Or
2009/3/19 Josselin Mouette :
> Le jeudi 19 mars 2009 à 11:12 -0700, Ludovico Cavedon a écrit :
>> are application using gconf *required* to have provide a schema?
>> In other words, does it make sense to file a bug against applications
>> which fail to do so?
>
> The
Hi all,
are application using gconf *required* to have provide a schema?
In other words, does it make sense to file a bug against applications
which fail to do so?
IMHO it makes sense, so you can clean no longer useful keys from the
gconf db, but I could not find a precise policy about that.
Than
On Mon, Apr 7, 2008 at 12:57 PM, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 06, 2008 at 11:59:39PM +0200, Cyril Brulebois wrote:
> > On 06/04/2008, Ludovico Cavedon wrote:
> > > automatic build of wengophone [1] on arm failed because of a GCC
> > &
Hi,
automatic build of wengophone [1] on arm failed because of a GCC
internal compiler error.
Who should I ask to request a retry of the build?
Thanks,
Ludovico
[1] http://packages.qa.debian.org/w/wengophone.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tr
23 matches
Mail list logo
