Bug#475822: ITP: fwsnort -- Fwsnort translates Snort rules into iptables rules.
Package: wnpp Severity: wishlist Owner: Franck Joncourt <[EMAIL PROTECTED]> * Package name: fwsnort Version : 1.0.4 Upstream Author : Michael Rash <[EMAIL PROTECTED]> * URL : http://www.cipherdyne.org/fwsnort/ * License : GPL Programming Lang: Perl Description : Fwsnort translates Snort rules into iptables rules. fwsnort translates Snort rules into iptables rules and generates a Bourne shell script that implements the resulting iptables commands. This ruleset allows network traffic that exhibits Snort signatures to be logged and/or dropped by iptables directly without putting an interface into promiscuous mode or queuing packets from kernel to user space. Note that fwsnort can also build an iptables policy that combines the string match extension with the NFQUEUE or QUEUE targets to allow the kernel to perform preliminary string matches that are defined within Snort rules before queuing matching packets to userspace. Because the bulk of network communications are not malicious, this should provide a speedup for snort_inline since the majority of packets do not then have to be copied from kernel memory into user memory and subsequently inspected by snort_inline. There is a tradeoff here in terms of signature detection however because snort_inline does not have the opportunity to see all packets associated with a session, so stream reassembly and signature comparisons against a reassembled buffer do not take place (the stream preprocessor - stream4, stream5, etc. - should be disabled). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475834: ITP: nlkt -- non-linear visual keyboard trainer
Package: wnpp Severity: wishlist Owner: "Eugene V. Lyubimkin" <[EMAIL PROTECTED]> * Package name: nlkt Version : 0.2.3 Upstream Author : Eugene V. Lyubimkin <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/nlkt/ * License : GPL 2+ Programming Lang: C++ Description : non-linear visual keyboard trainer nlkt is a lightweight keyboard trainer (touch-typing tutor). Non-linearness minds that program use dynamic, not static exercises, which based on current user's progress and mistakes. Exercises are built from user's mistakes and fortunes. Features: multiple accounts for single user, support for several layouts, visual keyboard state, keyboard hints. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-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/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475842: RFP: psychosynth -- An interactive, collaborative and networked synthesizer.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: psychosynth Version: 0.1.1 Upstream Author: Juan Pedro Bolívar Puente URL: http://www.psychosynth.com License: GPL Description: An interactive, collaborative and networked synthesizer. The Psychosynth project aims to create an interactive modular soft-synth inspired by the ideas of the Reactable. We will try to provide a clean object oriented API to allow the creation of new innovative interfaces for the synthetizer and a 3D simulator of a Reactable-alike device with support for collaborative music creation over the internet. Hi, I am the maintainer of Psychosynth and I am quite interested of it being included in Debian. I have already made some ad-hoc packages for Sid following a step by step tutorial. The packages can be found here, in case someone finds use them to start: http://www.psychosynth.com/doku.php?id=debian Thanks, JP
Bug#475850: ITP: libsfml -- simple and fast cross-platform multimedia library
Package: wnpp Severity: wishlist Owner: Christoph Egger <[EMAIL PROTECTED]> * Package name: libsfml Version : 1.2 Upstream Author : Laurent Gomila ([EMAIL PROTECTED]) * URL : http://www.sfml-dev.org/ * License : MIT/X Programming Lang: C++ Description : simple and fast cross-platform multimedia library SFML is an modern multimedia library offering a wide range of subsystems usefull to produce an multimedia app. It offers OpenGL integration for Hardware accelerated Graphics, Windowing and Input support, Audio and Network facilities and supports GNU/Linux MS Windows and Mac OS X. Although SFML offers integration not only for C++ but also for C Ruby and Python I intent to first concentrate on C++. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim, local resolver, host name lookups and IPv6
Steve Langasek wrote:
On Sat, Apr 12, 2008 at 12:13:36PM +0600, Alexander E. Patrakov wrote:
Marc Haber wrote:
In some cases, exim still looks up its IP address when a listening
daemon starts up. This is why the Debian installer configures
127.0.1.1 (not 127.0.0.1) for the local hostname on installation,
yielding /etc/hosts files like
127.0.0.1 localhost
127.0.1.1 myfoo.localdomain myfoo
This being said, I consider the entire 127.0.1.1 business a horrible
hack which is one of the most ugly things I have ever seen. Do we have
a chance to implement this in a more cleaner way, or is it still the
way to go for the distribution, where we don't know zilch about the
environment where an installed system is going to be used?
I second this request.
Oh yes, by all means, let's flip-flop the /etc/hosts implementation back and
forth because people /second/ it, without ever bothering to understand the
reasons that made this necessary.
I don't understand this Debian-specific _hack_ because the unusual and
Debian-specific 127.0.1.1 entry has no comment referring to a problem that it
fixes ("see bug #xx" would be enough). Honestly, I even considered it my own
typo first when I encountered the vde2 breakage.
Just a data point: this 127.0.1.1 setup breaks the "vde2" package (namely,
its slirp-based part) if a local DNS server that listens on 127.0.0.1 only
(e.g., pdnsd) is used.
Then vde2 has broken assumptions and should be fixed.
I will file a bug against both pdnsd and vde2.
--
Alexander E. Patrakov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
elegant ways to build a package two times
The inn2 packages is not as useful as it should be, since it does not support LFS which is mandatory for large servers. I cannot just enable LFS support since there is no transition path for some classes of users, so we need both inn2 and inn2-lfs packages. I am looking for *elegant* ways to build both packages from the same source with the least possible duplication of the code in debian/rules and of the debian/ debhelper files (the package is complex and needs much work before and after make install). Please let me know if you know about packages which solved similar issues. INN uses autoconf but not automake, so mkdir bin && ./configure does not generate working makefiles. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#475772: dpkg should set GREP_OPTIONS
Processing commands for [EMAIL PROTECTED]: > reassign 475772 general Bug#475772: dpkg should set GREP_OPTIONS Warning: Unknown package 'a' Warning: Unknown package 'lot' Warning: Unknown package 'of' Warning: Unknown package 'them' Bug reassigned from package `a lot of them' to `general'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libcwd in Debian unstable
On Thu, Apr 10, 2008 at 04:50:07PM +0200, Cyril Brulebois wrote: > On 10/04/2008, Carlo Wood wrote: > > It was added 16 March, that is 3+ weeks ago! :/ > > So, debian-devel@lists.debian.org: can someone tell me why > > libcwd was added as amd64 package, but still doesn't exist > > as x86 package please? > > Because there are additional requirements for non-free packages to be > autobuilt. See the following announcement for more info. > > http://lists.debian.org/debian-devel-announce/2006/11/msg00012.html I did what it says there. This is the mail to [EMAIL PROTECTED] as requested. Package: libcwd It can be autobuild because I see no reason why not. Author, copyright holder, maintainer, tired of this, and all what not, -- Carlo Wood <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: elegant ways to build a package two times
On Sun, Apr 13, 2008 at 05:50:39PM +0200, Marco d'Itri wrote: > I am looking for *elegant* ways to build both packages from the same > source with the least possible duplication of the code in debian/rules > and of the debian/ debhelper files (the package is complex and needs > much work before and after make install). > Please let me know if you know about packages which solved similar > issues. I maintain celestia, which comes with three front-ends, GLUT, GNOME and KDE. Unfortunately, upstreams build system only allows you to build for one specific front-end at a time. In celestia's debian/rules, the source is copied three times to separate build directories. Then it is compiled three times, each time with different options to ./configure. I have taken care that the makefile rules in debian/rules are such that repeated builds work fine, and that if you interrupt the build you can resume it, without the need for the build system to start over again. Also, I recently made it so that the build directory copies are made with cp -l, to speed up the process and to prevent disk space from being consumed unnecessarily. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
I'm hijacking yaz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, You will find my previous mail at the end of this one. I never heard anything about Eric Schwartz since my last mail (in fact, since the beginning). And nothing has changed in Debian about yaz, despite of a very cooperative upstream (about licensing issue in particular) and a DSFG-ok upstream version since January, 15th 2008. I want newer yaz to be in lenny (moreover, the version of yaz in stable, testing and sid should be removed due to the old licensing issue...) So, I announce here that I hijack the yaz package. I will maintain it in the yaz git sub-project (in the alioth collab-maint project). Any co-maintainers are welcome (I would be very happy if Eric Schwartz comes back). I need this package for another one (koha) and that is the only reason why I look at it. I'm uploading yaz-3.0.26+debian.1. It will sit in NEW due to new libraries package (new soname). Package are available on my web page[1]. I'm working with upstream to merge our packaging effort: they were proposing their Debian version of the yaz package. I'm very confident that packages on their website and packages in Debian (sid, testing and backports.org) will be the same :-) And next upstream releases will not include debian/ directory avoiding the need to recreate a orig.tar.gz :-) Best regards, Vincent [1] http://www-id.imag.fr/~danjean/deb.html#yaz Note: this webpage is not always up-to-date nor exact... Vincent Danjean wrote: > Adam Dickmeiss (upstream) wrote: >> YAZ 3.0.24 is available. All source is now covered by 'Revised BSD' - >> including the CCL module. The ziffy part has been removed (is GPL). ziffy >> be distributed separately at a later time. > > Thank you very much for your work on this point. This cleanup the licensing > issue with this sowtware. > > Can the current yaz maintainer (Eric Schwartz) says what he wants to do ? > > For information : > - libnet-z3950-zoom-perl (in the Debian perl group) depend on a new version > of yaz > - Koha (an ITP) is also waiting for a new version of yaz > > - before etch release, I made an NMU in experimental (I do not want to disturb > the release) of yaz 2.1.48+debian.1-0.2 > - a few month ago, I remade an NMU in unstable this time (3.0.16+debian.1-0.1) > It has been rejected due to the licensing problem. I send a mail to upstream > that tell us that they will work on this issue. > Of cause, for both NMU, I try to talk to Eric. I got no answer (and nothing > appears in the BTS) > - a few weeks later (31.12.2007), Eric made an upload of 3.0.18 (always > without > any mail explaining for examples what are his plans). Of course, ftp-master > reject it with the same reason as my 3.0.16 NMU (and seems a little bit > upset > that Eric does not take care of the previous reject) > - on 29.01.2008, upstream (Adam Dickmeiss) tells us that a new upstream > release > fixing licensing issue is available (#463116) > - on 27.02.2008, a mail from the Debian External Health System (a.k.a. DEHS) > was sent to [EMAIL PROTECTED] talking about the new release. > > I do not want to maintain yaz if it is maintain by someone else. But several > people (including me) need a new version of yaz in Debian. > > I do not want to make yet another NMU because I fear that my work (and time) > will be lost (as Eric made a 3.0.18 release without telling anybody about it). > > So either Eric makes a new release or I will hijack this package. > There are too many changes since the 2.1.18-2 currently in Debian for an NMU > (it would be way to intrusive). I was hopping that Eric will make his > maintainer > job (releasing AND communicating) but it is not the case. > > I will wait for a few weeks again. But if nothing comes from Eric, I will > hijack his package without any other mail (there have been too many not > answered > at all, and nothing in the BTS) > If this happens, I will be glad to accept any other co-maintainer willing to > help > on yaz packaging. > > Best regards, > Vincent > - -- Vincent Danjean GPG key ID 0x9D025E87 [EMAIL PROTECTED] GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAoi0C/d4Z50CXocRAuFYAJ9aL1Q4taTGvR/BdwfKUQwlqZL+5gCePCIu sv9ImGSCqVtjaVod0op3DtA= =/gAO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475772: dpkg should set GREP_OPTIONS
At 2:08p -0400 on Sun, 13 Apr 2008, Colin Watson wrote: reassign 475772 general I think an appropriate solution would be to unset or export GREP_OPTIONS='--color=none' in the beginning of scripts that rely on grep. [not feasible, *lots* of legacy scripts to fix] Good point. I guess the mode I was thinking as I wrote that was more along the lines of "start from a known good point". Fine, it won't happen overnight, but it could be entered into a "best practices" thing for noob maintainers and whatnot. For a semi-analogous example, I'm seeing more and more folks build their website CSS by starting with a block of rules and selectors that resets all CSS to be the same across all browsers. I think this is very good practice. For reference: http://snipurl.com/24bfp [snipplr_com] I'm not saying fix all packages, but perhaps enter the general mindset and let it trickle down. [fix your *interactive* environment] alias grep='grep --color=always' Now see, that's smart! This fixes the *interactive* environment, and leaves scripts to do their own thing. Nice. A little tidbit here, a bit more there, and sooner or later I'll get my environment perfect. /me edits his .bashrc Thanks! Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475928: ITP: python-edje -- Python bindings for the Enlightenment layout and animation library (edje)
Package: wnpp Severity: wishlist Owner: "Jan Lübbe" <[EMAIL PROTECTED]> * Package name: python-edje Version : 0.2.1 Upstream Author : Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> * URL : http://www.enlightenment.org * License : BSD Programming Lang: Python Description : Python bindings for the Enlightenment layout and animation library (edje) Edje is a graphical layout and animation library for animated resizable, compressed and scalable themes. It is the theming engine behind Enlightenment DR 0.17. This package contains modules that allow you to use evas from Python. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-x60s (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libcwd in Debian unstable
On Mon, Apr 14, 2008 at 4:11 AM, Carlo Wood <[EMAIL PROTECTED]> wrote: > Author, copyright holder, maintainer, tired of this, and all what not, Do you mind if I ask why you chose the QPL instead of a DFSG-free licence? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libcwd in Debian unstable
"Paul Wise" <[EMAIL PROTECTED]> writes: > On Mon, Apr 14, 2008 at 4:11 AM, Carlo Wood <[EMAIL PROTECTED]> wrote: > > > Author, copyright holder, maintainer, tired of this, and all what not, > > Do you mind if I ask why you chose the QPL instead of a DFSG-free licence? According to the FSF, the Q Public License version 1.0 is a free software license: Q Public License (QPL), Version 1.0 This is a non-copyleft free software license which is incompatible with the GNU GPL. It also causes major practical inconvenience, because modified sources can only be distributed as patches. http://www.fsf.org/licensing/licenses/> Debian's wiki, on the DFSGLicense page, categorises QPLv1 in the "unsettled" section: The QPL is not GPL-compatible, which, regardless of one's opinion about the license's DFSG-freeness, poses a major practical problem for any code licensed under the QPL that is reused elsewhere in conjunction with code under the GNU GPL. This makes the QPL alone a particularly poor choice of license for a library. http://wiki.debian.org/DFSGLicenses#head-32008704067079028804a5dc10bb340d4086> All that aside, though, if Carlo Wood is "tired of all this", he would be best advised to choose to license his work under terms whose freedom status *is* settled. -- \ "I filled my humidifier with wax. Now my room is all shiny." | `\ -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I have added these mails ids
Nishtha
