Re: Bug#502305: ITP: ulogd2 -- The Netfilter Userspace Logging Daemon, version 2
Pierre Chifflier wrote: > Ulogd is already packaged in Debian, but I think ulogd2 should be proposed as > a separate package, because: > - they are completely different projects, supporting different targets (NFLOG) > or features (connection tracking) > - ulogd is still the stable daemon, for some time I think > - some applications are based on version 1, and a transition to v2 require > many changes > - both can be installed at the same time > - packages for ulogd2 will be completely different, for ex. using dbconfig I'm sorry, I disagree. I think that ulogd should be updated to v2 post-lenny, since v1 is unsupported, hasn't released for some time and has some serious limitations and bugs (e.g. doesn't work on 32-bit userland/64-bit kernel systems, including sparc64 which is the only way sparc systems will be supported in Debian in the future). Even if we go the separate package name way for some time, this should be a decision that the existing ulogd maintainers (which includes myself) should make and not someone else. You are, of course, welcome to help and/or comaintain. I've known about ulogd2 for some time but haven't worked on it because of its instabilities that make it unsuitable for release. An upload to experimental might make sense but I haven't worked on this (and neither Achilleas, AFAIK) because of my lack of time. If you intend to work on this, please try to coordinate with us. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#502305: ITP: ulogd2 -- The Netfilter Userspace Logging Daemon, version 2
On Wed, Oct 15, 2008 at 04:31:26PM +0300, Faidon Liambotis wrote: > Pierre Chifflier wrote: > > Ulogd is already packaged in Debian, but I think ulogd2 should be proposed > > as > > a separate package, because: > > - they are completely different projects, supporting different targets > > (NFLOG) > > or features (connection tracking) > > - ulogd is still the stable daemon, for some time I think > > - some applications are based on version 1, and a transition to v2 require > > many changes > > - both can be installed at the same time > > - packages for ulogd2 will be completely different, for ex. using dbconfig > I'm sorry, I disagree. I think that ulogd should be updated to v2 > post-lenny, since v1 is unsupported, hasn't released for some time and > has some serious limitations and bugs (e.g. doesn't work on 32-bit > userland/64-bit kernel systems, including sparc64 which is the only way > sparc systems will be supported in Debian in the future). Yes, v2 resolves these problems .. However, given the differences between v1 and v2 (have you looked at the config ?) are so important that upgrading cleanly is almost impossible, and is not planned anyway (I'm part of ulogd2 upstream, BTW). > > Even if we go the separate package name way for some time, this should > be a decision that the existing ulogd maintainers (which includes > myself) should make and not someone else. > You are, of course, welcome to help and/or comaintain. > I was under the impression that ulogd wasn't maintained, so I thought a complete rewrite would be best - I should have asked before. Since I would like to work on the packaging, would it be ok for a co-maintainance ? (I'll send patches for review before uploading, if you prefer). > I've known about ulogd2 for some time but haven't worked on it because > of its instabilities that make it unsuitable for release. An upload to > experimental might make sense but I haven't worked on this (and neither > Achilleas, AFAIK) because of my lack of time. Yes. > > If you intend to work on this, please try to coordinate with us. > I'd like to work on this. Is it ok for you ? (maybe we should discuss this directly, and trim the CC line) Pierre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
parallel builds using DEB_BUILD_OPTIONS
Hi, The Policy Manual [1] gives the following recipe for supporting parallel make: ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif Unfortunately, for packages that use recursive makefiles (the most common practice) this results in the following warning make[1]: warning: -jN forced in submake: disabling jobserver mode. which apparently is sub-optimal [2]. The issue in that MAKEFLAGS is applied to each recursive make. The recommended practice is to supply -jN *only* to the initial invocation of make. It strikes me, therefore, that the policy manual should be updated, removing MAKEFLAGS and instead showing an explicit "make -J$(NUMJOBS) ...". However, my problem is with cdbs: how can I supply -jN to only the initial make? Thanks, -Steve [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options [2] http://make.paulandlesley.org/jobserver.html signature.asc Description: Digital signature
Re: Delivery reports about your e-mail
I apologize for this automatic reply to your email. To control spam, I now allow incoming messages only from senders I have approved beforehand. If you would like to be added to my list of approved senders, please fill out the short request form (see link below). Once I approve you, I will receive your original message in my inbox. You do not need to resend your message. I apologize for this one-time inconvenience. Click the link below to fill out the request: https://webmail.atl.earthlink.net/wam/[EMAIL PROTECTED]&id=1kQ3KQ2E73Nl3qW1
Re: parallel builds using DEB_BUILD_OPTIONS
On Wed, Oct 15, 2008 at 07:17:41AM -0500, Steve M. Robbins wrote: > It strikes me, therefore, that the policy manual should be updated, > removing MAKEFLAGS and instead showing an explicit "make -J$(NUMJOBS) ...". Or better "$(MAKE) -j$(NUMJOBS)". > However, my problem is with cdbs: how can I supply -jN to only the > initial make? Maybe it's a ugly hack, but what about: DEB_MAKE_BUILD_TARGET = -j$(NUMJOBS) ACTUAL_BUILD_TARGET It should work at least in case you are using only the makefile.mk class, I haven't checked if it can be made to work with autotools.mk. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Rejuvenated kernel-package uploaded to unstable, please test
On Tue, Oct 14 2008, Paul Wise wrote:
> On Tue, Oct 14, 2008 at 12:23 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
>
>> Problem is that even though this may avoid package conflicts, it is *not*
>> correct given the way Debian currently looks for firmware. Also, it is
>> not the way upstream recommends to install firmware.
>>
>> All (non-free) Debian firmware packages install the firmware files
>> directly under /lib/firmware, not /lib/firmware/$kernel-version.
>>
>> And Debian's udev does not consider the kernel-version when looking for
>> firmware. /lib/udev/hotplug.functions has:
>> FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware
>> /usr/lib/hotplug/firmware'
>
> In contrast, the latest upstream udev (130) has this:
>
> FIRMWARE_DIRS="/lib/firmware/$(uname -r) /lib/firmware"
Seems like rpm spec files are likely to be changed as well.
manoj
--- Begin Message ---
[Евгений Маначкин - Wed, Oct 15, 2008 at 11:54:34PM +0700]
| This is OK ?
|
| --- linux-2.6.27/scripts/package/mkspec.orig2008-10-11 00:00:38.0
+0700
| +++ linux-2.6.27/scripts/package/mkspec 2008-10-11 00:39:43.0 +0700
| @@ -64,8 +64,10 @@ fi
| echo "%install"
| echo "%ifarch ia64"
| echo 'mkdir -p $RPM_BUILD_ROOT/boot/efi $RPM_BUILD_ROOT/lib/modules'
| +echo 'mkdir -p $RPM_BUILD_ROOT/boot/efi $RPM_BUILD_ROOT/lib/firmware'
| echo "%else"
| echo 'mkdir -p $RPM_BUILD_ROOT/boot $RPM_BUILD_ROOT/lib/modules'
| +echo 'mkdir -p $RPM_BUILD_ROOT/boot $RPM_BUILD_ROOT/lib/firmware'
| echo "%endif"
|
| echo 'INSTALL_MOD_PATH=$RPM_BUILD_ROOT make %{_smp_mflags} modules_install'
| @@ -92,5 +94,6 @@ echo "%files"
| echo '%defattr (-, root, root)'
| echo "%dir /lib/modules"
| echo "/lib/modules/$KERNELRELEASE"
| +echo "/lib/firmware"
| echo "/boot/*"
| echo ""
|
Evgeniy, it should be something like that
---
From: Evgeniy Manachkin <[EMAIL PROTECTED]>
Subject: [PATCH] mkspec - fix build rpm
Patch description goes here
Signed-off-by: Evgeniy Manachkin <[EMAIL PROTECTED]>
---
Patch body goes here
I didn't check the patch just show you the form of patch submission.
For example -- take a look on
http://lkml.org/lkml/2008/10/15/2
or
http://lkml.org/lkml/2008/10/15/20
Actually SubmittingPatches has a quite good description how to
make it right :)
- Cyrill -
--- End Message ---
--
Date: 23 Feb 90 19:04:55 GMT From: [EMAIL PROTECTED] (Randal
Schwartz) $,=' ';print grep(s/^.//, sort
"2another","4hacker,","1Just","3Perl");
Manoj Srivastava <[EMAIL PROTECTED]>
Bug#502301: ITP: lldpd -- implementation of IEEE 802.1ab (LLDP)
Package: wnpp Severity: wishlist Owner: Vincent Bernat <[EMAIL PROTECTED]> * Package name: lldpd Version : 0.1 Upstream Author : Vincent Bernat <[EMAIL PROTECTED]> * URL : https://trac.luffy.cx/lldpd/ * License : MIT Programming Lang: C Description : implementation of IEEE 802.1ab (LLDP) LLDP is an industry standard protocol designed to supplant proprietary Link-Layer protocols such as Extreme's EDP (Extreme Discovery Protocol) and CDP (Cisco Discovery Protocol). The goal of LLDP is to provide an inter-vendor compatible mechanism to deliver Link-Layer notifications to adjacent network devices. This implementation provides LLDP sending and reception, supports VLAN and bond interfaces and includes an SNMP subagent that can interface to an SNMP agent through AgentX protocol. This daemon is also able to deal with CDP, SONMP and EDP protocol. I have also an ITP on OpenLLDP (#488108) which is another implementation. Unfortunately, some pieces were missing and upstream seemed too busy to handle them. I have lost contact with upstream. lldpd is a more complete implementation (but less portable, Linux only). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502305: ITP: ulogd2 -- The Netfilter Userspace Logging Daemon, version 2
Package: wnpp Severity: wishlist Owner: Pierre Chifflier <[EMAIL PROTECTED]> * Package name: ulogd2 Version : 2.0.0beta2 Upstream Author : Harald Welte and netfilter team * URL : http://www.netfilter.org/projects/ulogd/ * License : GPLv2 Programming Lang: C Description : The Netfilter Userspace Logging Daemon, version 2 ulogd is a daemon that listens for Netlink packets generated by iptables's ULOG and NFLOG target, using ibnetfilter_log and libnetfilter_conntrack. Basically, it's a replacement for syslog for logging packets, and does a much better job - it logs to files, pcap files, MySQL, PostgreSQL, SQLite 3 and soon will be able to log remotely. . MySQL, PostgreSQL and SQLite 3 support is in separate packages, called ulogd-mysql, ulogd-pgsql and ulogd-sqlite3 respectively. pcap file support is in package called ulogd-pcap. Ulogd is already packaged in Debian, but I think ulogd2 should be proposed as a separate package, because: - they are completely different projects, supporting different targets (NFLOG) or features (connection tracking) - ulogd is still the stable daemon, for some time I think - some applications are based on version 1, and a transition to v2 require many changes - both can be installed at the same time - packages for ulogd2 will be completely different, for ex. using dbconfig -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changelog and patche
On Tue, Oct 14, 2008 at 05:19:16PM +, Laurent Guignard wrote: > Hi, > > How to inssert into the Changlog file the description of patch. > lintian ask ## DP: but when i put into the warning is alway here. > > Is there anywhere an example of typical Changelog file ? Please, debian-devel is really not the place for such beginner questions. You should use [EMAIL PROTECTED] or join #debian-mentors on irc.debian.org for this. TIA. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLI9QsLxVRS.pgp Description: PGP signature
debian-kernel (Re: kernel 2.6.27 in lenny?)
For kernel-related discussions, ask on debian-kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502279: ITP: mpclib -- multiple precision complex floating-point library
Package: wnpp
Severity: wishlist
Owner: Laurent Fousse <[EMAIL PROTECTED]>
* Package name: mpclib
Version : 0.5
Upstream Author : Andreas Enge, Philippe Théveny and Paul Zimmermann.
* URL : http://www.multiprecision.org/mpc/
* License : LGPL
Programming Lang: C
Description : multiple precision complex floating-point library
MPC is a portable library written in C for arbitrary precision
arithmetic on complex numbers providing correct rounding. For the time
being, it contains all arithmetic operations over complex numbers, the
exponential and the logarithm functions, the trigonometric and
hyperbolic functions.
.
Ultimately, it should implement a multiprecision equivalent of the ISO
C99 standard.
.
It builds upon the GNU MP and the MPFR libraries.
The source package is called mpclib because mpc is already taken. I
plan to name the binary packages libmpc{0,-dev}.
Laurent.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: powerpc (ppc)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
