Re: what about Netplan?
On Mon, Jul 15, 2024 at 10:26:09AM +0200, Thomas Goirand wrote: > Also, Netplan is just a configuration layer. That's a way simpler than NM or > sd-networkd. In principle, ifupdown is little more than a configuration layer as well. It doesn't manage anything itself, it delegates everything to external tools, either just iproute2 for static configuration, or dhcpd, wpasupplicant and other daemons for more dynamic configuration. Ifupdown could be modified to translate its configuration to networkd, NM and so on. Of course, if netplan is an even better configuration language then I'd prefer that. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Re: fftw3 needs testing on K6
On Mon, Nov 01, 2004 at 10:57:52PM +, Paul Brossier wrote:
> fftw3 needs testing on AMD K6. The solution suggested by the upstream
> authors is available at http://piem.org/~piem/debian/fftw3/ . it would
> be nice if a K6 owner could reproduce the bug (for instance running
> jamin with fftw3 3.0.1-10) and then try again using the above version.
> Please CC your reports to [EMAIL PROTECTED]
-10 crashes with illegal instruction, -11 runs fine on my k6.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#341102: RFA: trophy -- A 2D car racing action game
Package: wnpp Severity: normal I request an adopter for the trophy package. The package description is: Trophy is a single-player racing game for Linux. Even though the goal is basically to finish the laps as the first, Trophy is an action game which offers much more than just a race. Lots of extras enable "unusual" features for races such as shooting, putting mines and many others. Trophy is a nice but limited game. Upstream is not working on this game anymore, and there are a number of open bugs, mostly about memory leaks and segmentation faults. These problems are becoming more and more evident, I guess it is bit rot taking place. This package needs a developer with C++ knowledge that wants to find the bugs in the source code and keep the package in shape, despite the inactive upstream. If noone wants to adopt this package, I will request for its removal from Debian. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.3 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITH: silc-toolkit
On Wed, Mar 08, 2006 at 07:24:51PM -0500, Michael Schultheiss wrote: > I intend to hijack silc-toolkit. It has had three RC bugs open for 150+ > days and another RC bug open for almost a year and a half. > > On August 14, 2005 in > Message-ID: <[EMAIL PROTECTED]>, the current > maintainer, Tamas Szerb, stated "I'm gladly give it to anybody who is > interested in it" - see bug #273871 for more info (including the message > referenced above). This is not an ITH, but an ITA (intent to adopt). You should file a wnpp bug as well, and send a Cc to the current maintainer so he gets a chance to respond. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#316128: ITP: enc -- tools for managing encrypted mailinglists
On Tue, Jun 28, 2005 at 08:20:29PM +0200, Riccardo Setti wrote: > * Package name: enc That is a very generic name. Since this is a tool meant especially for mailinglists, could it be renamed to "enclist" or "encmailing" or something more specific? > * URL : http://www.neuroni.org/ I can't find any reference to enc on that Italian website. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#316128: ITP: enc -- tools for managing encrypted mailinglists
On Wed, Jun 29, 2005 at 11:23:16AM +0200, Laurent Fousse wrote: > * Guus Sliepen [Wed, Jun 29, 2005 at 11:08:31AM +0200]: > > > * URL : http://www.neuroni.org/ > > > > I can't find any reference to enc on that Italian website. > > Try https://neuroni.org/ml/docs.php That points me to another page completely in Italian. I see links to three scripts, "marchingegno", "nuovalista" and "frullatore". Is that perhaps what you are packaging? I don't often complain about ITPs, but if it is just a bunch of shell scripts, in Italian only, no version numbers that I can see, then I don't think this should be part of the Debian archive. Perhaps you should create the package, but provide your own archive so people who really want it can add a line to /etc/apt/sources.list. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: gcc-4.1 [gfdl] documentation packages for non-free
On Sun, Sep 17, 2006 at 12:06:02AM +0400, Nikita V. Youshchenko wrote: > I've created gcc-4.1-doc-non-dfsg package, intended for non-free. This > package builds several binary packages (cpp-4.1-doc, gcc-4.1-doc, > gfortran-4.1-doc, tree;ang-4.1-doc), that contain all files - man pages, > info and html docs - that have been in gcc-4.1 4.1.1-10 package [last > version before documentation removal], but are not in the current > 4.1.1ds1-13 package. > > I'm going to upload this to non-free. > But before that, I'd like interested people to look into the package, and > give any comments they feel appropriate. > Currently, I've put the package to > http://zigzag.lvk.cs.msu.su/~nikita/debian/gcc-doc/ Why is this a native Debian package? I know that the tarball it is based on is not one distributed as such by upstream, but it is based on files from an upstream source. The way you do it now, you can't see what you have changed in the documentation, because there is no diff.gz file. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: gcc-4.1 [gfdl] documentation packages for non-free
On Sun, Sep 17, 2006 at 11:02:16AM +0400, Nikita V. Youshchenko wrote: > > Why is this a native Debian package? I know that the tarball it is based > > on is not one distributed as such by upstream, but it is based on files > > from an upstream source. The way you do it now, you can't see what you > > have changed in the documentation, because there is no diff.gz file. > > If I separate files taken from upstream into '.orig.tar.gz', where should I > place Makefile that I wrote to build documentation? > Since this file is not from upstream, looks like should place it > to .diff.gz > But if I do that, .orig.tar.gz file will be of little interest itself, > without .diff.gz It really doesn't matter if the orig.tar.gz is useful or not. > If the only reasoning to split is informationl, I guess a README file in > debian/, plus usage of dpatch if any patches will be added, will serve the > same purpose better. Well, in the Debian Policy, the only reason for making a native package is described in this way: "[The debian_revision] is optional; if it isn't present then the upstream_version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian package, and so there is only one "debianization" of it and therefore no revision indication is required." The GCC documentation is not written specifically to be turned into a Debian package. On the other hand, there is no MUST or MAY NOT in the Policy about native packages. > Also, with currently implemented versioning scheme, new -doc packages get > versions that dpkg will consider higher than old -doc packages that are > removed from archive, but stay on users systems. So, if users have > non-free in their sources, they will get new packages transparently. You can also do that if you keep the same versioning scheme as the current gcc packages, and just bump the Debian revision. Another advantage of making it a non-native package is that the orig.tar.gz only has to be uploaded once for every upstream release, whenever you change something and create a new package with an increased Debian revision, you only need to upload the diff.gz to the archives. By the way, apart from this, I can see nothing wrong with your package :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Possibly RC bug 399980
On Wed, Nov 29, 2006 at 09:01:01AM +0100, Mgr. Peter Tuharsky wrote:
> there is another bug that I feel might be classified as RC. See 399980.
This bug is in no way release-critical.
> Seems that it is impossible to switch keyboard properly on X level
> (without GNOME applet). The bug is quite new, encountered some month
> ago. Thus it is impossible to properly use any other window manager.
There are a number of tools that can switch keyboard layouts, as
mentioned by Lionel Elie Mamane.
> Debian stable has never met such problem for last 5 years at least.
That does not make it release-critical. Also, if you feel the severity
of a bug is incorrect, you should mention that in a follow-up to the
bugreport, or indicate the severity in your initial bugreport. This list
is not meant to discuss bug severities.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)
On Thu, Nov 30, 2006 at 06:41:21AM -0500, Thomas Dickey wrote: > > Changes: > > lynx (2.8.5-2sarge2.2) unstable; urgency=low > > . > >* Non-maintainer upload. > >* Read user configuration from home directory, not current > > working directory. Closes: #396964 > > Thanks to Tom Parker for the patch. > > There's no possibility of including that patch upstream. So what? If upstream does not want to accept a patch that fixes a security bug (which #396964 is, if I read it correctly), that's their problem. Debian often releases packages with patches that are not accepted by upstream, for various reasons. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)
On Thu, Nov 30, 2006 at 07:00:14AM -0500, Thomas Dickey wrote: > > > There's no possibility of including that patch upstream. > > > > So what? If upstream does not want to accept a patch that fixes a > > so what? Read the patch. You certainly didn't, or if you _did_ you > understand nothing of the change. > > The patch breaks existing functionality (hardcodes one of the configurable > selections). I didn't know PERSONAL_MAILCAP was run-time configurable (it looks a #define to me). If apt-get source wasn't segfaulting at the moment I'd check it. But this explaination is a lot more useful than "upstream won't accept it". But why did you send this to the debian-devel mailing list instead of as a follow-up to the bugreport? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: RFS: libssh - SSH and SCP library
On Sat, Dec 16, 2006 at 11:03:51PM +0100, Jean-Philippe Garcia Ballester wrote: > Hi everybody, > I'm looking for a sponsor for the libssh package : > > * Package name: libssh > Version : 0.2rc > Upstream Author : "Aris Adamantiadis" <[EMAIL PROTECTED]> > * URL : http://www.0xbadc0de.be/libssh:libssh > * License : LGPL > Description : SSH and SCP library Make sure you compile it with --with-libgcrypt, so that it really is LGPL. If it's linked to OpenSSL, then a GPLed application using this library probably needs to add a license exception before we can distribute it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: RFS: libssh - SSH and SCP library
On Sun, Dec 17, 2006 at 11:44:27AM +0100, Guus Sliepen wrote: > Make sure you compile it with --with-libgcrypt, so that it really is > LGPL. If it's linked to OpenSSL, then a GPLed application using this > library probably needs to add a license exception before we can > distribute it. Ehm, never mind, I should've read your email completely before replying. I see I'm preaching to the choir :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#363598: udev should conflict with ifrename
On Thu, Apr 20, 2006 at 01:43:07AM +0200, Marco d'Itri wrote: > > Besides the fact that ifrename is more of a hack, now that udev enables > > persistent naming of interfaces (z25_persistent-net.rules) udev should > > conflict with ifrename. Otherwise the user could get unexpected results > > if /etc/iftab still exists and the ifrename init script tries to rename the > > interfaces (again) with possibly different names than the ones set in > > z25_persistent-net.rules. > > If you have not noticed yet, the latest udev release by default > automatically generates rules to have persistent names for network > interfaces. > > I am inclined to agree with the bug reporter, but I want to double check > and ask if anybody has other arguments. I'm sure there are people who use both ifrename and udev, and if udev Conflicts: with ifrename, and I get bugreports about ifrename being uninstallable together with udev, I'll reassign them to udev. The two packages coexist peacefully, but if a user fills in both /etc/iftab and z25_persistent-net.rules I say he is on his own. A warning in README.Debian or in debconf is perhaps warranted though. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#363598: udev should conflict with ifrename
On Fri, Apr 21, 2006 at 10:32:21PM +0200, Marco d'Itri wrote: > > I'm sure there are people who use both ifrename and udev, and if udev > Which part of "ifrename does not work with udev" you did not understand? The part where both work fine simultaneously on my own machines. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: O: lirc - Linux Infra-red Remote Control support
On Sun, Apr 23, 2006 at 10:53:39PM +0200, Amaya wrote: > I am orphaning lirc, it deserves a better maintainer. > Please contact me if you are interested. You should file a wnpp bug. Since I'm also the maintainer of the inputlirc package, I could adopt this package, but I'd rather let someone else who (still) uses homebrewn receivers adopt it. Let me know if noone else steps up. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#368551: ITP: xml-security-c -- C++ library for XML Digital Signatures
On Mon, May 22, 2006 at 05:28:07PM -0700, Russ Allbery wrote: > * Package name: xml-security-c > Programming Lang: C++ > Description : C++ library for XML Digital Signatures If it is a C++ library, please name the package xml-security-c++. If upstream names their tarballs xml-security-c, tell them to change that as well. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#377546: ITP: schedtools -- Queries/alters process's scheduling policy; supports the -ck kernel patch
On Mon, Jul 10, 2006 at 07:32:25PM +0200, Thibaut VARENE wrote: > >> schedtool can be used to query or alter a process' scheduling policy > >> under Linux. Support for CPU-affinity has also been added and most > >recently > >> (re-)nicing of processes. Thus, schedtool is the definitive interface to > >> Linux's scheduler. > > > >How does it compare to schedutils which are already in Debian? > > already answered that in this thread Schedutils is being merged with util-linux. Maybe you can convince schedtool's upstream to talk with the util-linux people and get their improvements to be merged? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: mass bug filing on packages that are blocking use of cdebconf
On Mon, Sep 26, 2005 at 07:57:23PM +0200, Joey Hess wrote: > Joey Hess wrote: > > Just a reminder that these maintainers still have packages that depend > > on debconf by itself without an alternate dependency on | debconf-2.0. > > As I mentioned in my original post, I plan to file bugs on all of these > > soon, which, omitting all the lg-issue* packages, comes to about 550 > > bugs. > (Original post here: > http://lists.debian.org/debian-devel/2005/08/msg00136.html) > > This is your third and final reminder. I count 542 packages remaining, > down only 9 from last month. I assume most of the people below do not > read debian-devel, so I've taken the librerty of BCCing you all. :-P This is the first time I see this. If it is a bug, then you have my blessing to file a bugreport. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#330953: RFA: rocks -- Make network sockets reliable in a transparent way
Package: wnpp Severity: normal I request an adopter for the rocks package. The package description is: Rocks protect sockets-based applications from network failures, particularly failures common to mobile computing, including: . - Link failures (e.g., unexpected modem disconnection); - IP address changes (e.g., laptop movement, DHCP lease expiry); - Extended periods of disconnection (e.g., laptop suspension). . Rock-enabled programs continue to run after any of these events; their broken connections recover automatically, without loss of in-flight data, when connectivity returns. Rocks work transparently with most applications, including SSH clients, X window applications, and network service daemons. The current package does not work at all anymore (although it still builds from source). Upstream told me more than a year ago they would fix it, but nothing has happened since then. I also think there are not many users of this package. If noone adopts it, I will ask for its removal. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-rc6 Locale: LANG=nl_NL, LC_CTYPE=nl_NL (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SONAME in C++ libraries
On Thu, Oct 13, 2005 at 12:51:01PM +0200, Shachar Shemesh wrote: > Andreas Fester wrote: > > >If upstream is unwilling to change the SONAME each time the binary > >compatibility breaks, then IMHO the only choice is that you do it > >yourself for the Debian package. Otherwise trouble begins when other > >packages within the Debian archive start linking against your library. > >See also http://www.trolltech.com/developer/faqs/index.html?catid=&id=362 > >for what breaks binary compatibility of C++ libraries. > > > That doesn't make sense. If I start inventing my own SO versions, I'll > be in trouble should upstream change their mind some time in the future. > > What I thought was to use "0" as SO version, which is a standard way to > state that the interface is not guarenteed to remain stable. I'll also > add a comment to readme.Debian to the effect that, when linking against > the library, you should include the precise version number in the > dependencies. Another alternative is not providing a shared library, only a static one, at least until upstream has come to their senses and made a stable library with a proper soname. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#461583: ITP: libdc1394v2 -- As the maintainer for libdc1394 didn't answer for many months, we (developers of libdc1394) would like to get involved also with maintaining the package.
On Sat, Jan 19, 2008 at 12:41:48PM -0500, Peter Antoniac wrote: > As the maintainer for libdc1394 didn't answer for many months, we > (developers of libdc1394) would like to get involved also with maintaining > the package. Moreover, the maintainer didn't follow our recommandations not > to pack the libdc1394 version 2.0 until we release it (and he packed it at > RC7). Peter de Schrijver is alive but apparently doesn't have time to respond to email. I have NMUd coriander 2.0.0~rc5 and libdc1394 2.0.0~rc7, but I uploaded them to experimental. I have already offered to take over maintainership, but haven't heard either a "no" or a "yes" from Peter. > It will be also better for the stability of the package if the > developers have also something to say in the packaging. For example, we have > releases the new version with doxygen generated web pages, pdf's and ps > documentation, so there is more documentation available for the developers. > We also think that what is now called libdc1394-examples should be called > -utils, as the binaries are more like utilities for the library. We have > already done some packaging and testing using the Ubuntu PPA tools, and you > can already see the fruits of our work here: [...] Unless Peter de Schrijver responds, I'll be happy to have a look at your packages and upload them to unstable if they are in good shape. From a quick glance, it looks OK, but I'd name the source package libdc1394-22 though. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#461950: ITP: eet -- Enlightenment file chunk reading/writing library
On Mon, Jan 21, 2008 at 04:38:30PM +, Albin Tonnerre wrote: > * Package name: eet > Version : 0.9.10 > Upstream Author : Carsten Haitzler and the e17 devel team <[EMAIL > PROTECTED]> > * URL : http://www.enlightenment.org I cannot find a source tarball for eet at that site. If it's part of enlightenment's source itself, there is no need for an ITP, just create another binary package from the source package. > * License : BSD > Programming Lang: C > Description : Enlightenment file chunk reading/writing library > > (Include the long description here.) Please enlighten us, it sounds like it is nothing more than read() and write(). What exactly does this library do? Is it of use for other application developers? If I google I can find some documentation for eet. It seems like it is a reimplementation of "ar". Maybe you can ask upstream why it was necessary to reinvent this wheel? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#461969: ITP: evas -- Enlightenment advanced canvas library
On Mon, Jan 21, 2008 at 06:23:55PM +, Albin Tonnerre wrote: > Description : Enlightenment advanced canvas library > > (Include the long description here.) Please *do* include a long description. It's a shame reportbug allows ITPs like this to be written... -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#461950: ITP: eet -- Enlightenment file chunk reading/writing library
On Mon, Jan 21, 2008 at 08:40:22PM +0100, Albin Tonnerre wrote: > > I cannot find a source tarball for eet at that site.> > > The download page is at http://download.enlightenment.org/snapshots/LATEST/ > The snapshots are a bit outdated, as upstream only builds tarballs on version > bumps. > (and this library is not part of enlightenment's source itself) Ah, ok. > > Please enlighten us, it sounds like it is nothing more than read() and > > write(). What exactly does this library do? [...] > EET is a tiny library designed to write an arbitary set of chunks of data to > a file and optionally > compress each chunk (very much like a zip file) and allow fast random-access > reading of the file later > on. EET files are perfect for storing data that is written once (or rarely) > and read many times, > especially when the program does not want to have to read all the data in at > once. That is a nice long description. I'm still wondering if "eet" it is not just a reinvention of "ar". -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#465204: ITP: fusil -- Fuzzing program to test applications
On Mon, Feb 11, 2008 at 02:18:05PM +0100, Pierre Chifflier wrote: > > The description is very unclear to me. [...] > Right, the previous description was not clear. I have reworded it, from > the README file, and from the author description: > > Fusil is a fuzzing framework designed to expose bugs in software by > changing random bits of its input. > It helps to start process with a prepared environment (limit memory, > environment variables, redirect stdout, etc.), start network client or > server, and create mangled files. Fusil has many probes to detect > program crash: watch process exit code, watch process stdout and syslog > for text patterns (eg. "segmentation fault"), watch session duration, > watch cpu usage (process and system load), etc. > . > Fusil is based on a modular architecture. It computes a session score > used to guess fuzzing parameters like number of injected errors to > input files. > . > Available fuzzing projects: ClamAV, Firefox (contains an HTTP server), > gettext, gstreamer, identify, libc_env, libc_printf, libexif, > linux_syscall, mplayer, php, poppler, vim, xterm. Wow, that is much better! The only remark I have is that you can define your own fuzzing projects, I would replace "Available" in the last paragraph by "Pre-defined" or something equivalent. Upstream should put your description on their front page :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#465204: ITP: fusil -- Fuzzing program to test applications
On Mon, Feb 11, 2008 at 09:46:48AM +0100, Pierre Chifflier wrote: > * Package name: fusil > * URL : http://fusil.hachoir.org > Description : Fuzzing program to test applications > > Fusil project is a fuzzing program for any project type (remote > process, fake HTTP server, fuzz network socket, etc.). Fusil > implementation is based on multi-agent system architecture. > Fusil is able to crash ClamAV, Image Magick, libc printf(), Mplayer, > PHP, RPM, xterm, libc gettext, libc environment variables, libpoppler > (pdf), vim, etc The description is very unclear to me. After looking at the Fusil website, I have some understanding of what fusil does. It is not a stand-alone program like fuzz or zzuf that work directly with any program. It rather is a framework that allows you to write Python scripts that specifically target a certain program. You should mention that in the long description. The part about the implementation being based on a multi-agent system architecture is not useful information. "multi-agent" is a bit of a buzzword that can mean many things. Furthermore, it is not useful for a user of a program to know whether it is implemented in C, with a multi-agent system or with bananas. The list of programs and libraries that Fusil can crash will change over time, since the whole point of Fusil is to find bugs so one can fix them. If you want to mention it, change the sentence to the past or perfect tense, like "Fusil was able to..." or "Fusil has been used to...". -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Firewire support in lenny
On Sun, Feb 03, 2008 at 10:04:18AM +0100, Marc 'HE' Brockschmidt wrote: > Early March 2008 > Very soft freeze [...] > Mid of July 2008 > Full freeze I guess that means that lenny will be released with linux kernel 2.6.24.x. If that is so, then I kindly request that the debian kernel packages will be released with the stable Firewire stack modules compiled. The current kernel package mainainer(s) has (have) decided to disable the stable modules in favour of the new and experimental JuJu stack[0]. The new stack has the advantage that is more secure and has a cleaner code base, but the drawback that a lot of devices and features are not yet supported. To summarise what the JuJu developers themselves say about the current state of the new stack[1]: Compatibility and stability At the time of this writing (01/2008), there are still multiple problems with the new FireWire kernel driver stack (alias Juju) compared to the old stack: * Lacking userspace integration. * Lack of testing. Therefore compatibility issues with some controllers and external devices. * There are still problems with isochronous reception on some OHCI 1.0 variants of VIA VT6306/6307 based cards. Cameras and audio devices are unusable with the new drivers if you have such a chip. * Almost no support for IIDC cameras: Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. * Stability issues of the storage device driver firewire-sbp2 on some hardware. * Missing IP over 1394 support. Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors (kernel packagers) as well as to regular users is: Build only the old IEEE 1394 drivers. There are security issues with the stable stack[2], so to protect our users it is better to load the modules for the JuJu stack by default. But for those people who need the stable stack to do work, the modules for the stable stack should be available. There is no reason not to build both stacks, they don't conflict with each other (except that only one works if you load both, of course). I hope the kernel package maintainer(s) will make sure kernel packages with the stable modules available, but blacklisted by default, will enter testing soon, so that users of testing get a chance to test it before lenny is released. [0] http://bugs.debian.org/436267 [1] http://wiki.linux1394.org/JujuMigration [2] http://en.wikipedia.org/wiki/FireWire#Security_issues -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#436267: Firewire support in lenny
On Tue, Feb 12, 2008 at 02:38:13PM +0100, maximilian attems wrote: > > My IIDC cameras do not work correctly with a juju-enabled libdc1394 > > 2.0.1. Furthermore, apart from coriander there are no applications that > > have migrated from libdc1394 v1 to v2. > > even with 2.6.24-4 linux images? > please mention the uname of your tests I'll see if I can do the tests on a clean install with the latest linux images tomorrow. > if you are on amd64 2.6.25-rc1-git2 > -> http://photon.itp.tuwien.ac.at/~mattems/ > will build i686 during day (takes much longer) > > please if 2.6.24 has troubles feedback on that one. I'll try both in any case. [...] > you can't have both without blacklisting one otherwise udev loads > randomly from boot to boot other firewire stack. changing blacklist > files in /etc/modprobe.d is trivial. I agree. I'm just asking that the old stack will be blacklisted, but still available in the linux images. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#436267: Firewire support in lenny
On Tue, Feb 12, 2008 at 11:49:22AM +0100, maximilian attems wrote: > > I guess that means that lenny will be released with linux kernel > > 2.6.24.x. If that is so, then I kindly request that the debian kernel > > packages will be released with the stable Firewire stack modules > > compiled. > > no certainly not, we haven't yet discussed the release kernel. > options are 2.6.25 or 2.6.26. Given the pace of kernel releases, I do not believe 2.6.26 is possible for lenny, but 2.6.25 is possible, although I think it will only be released a month or two before the final freeze. > > Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors > > (kernel packagers) as well as to regular users is: Build only the old > > IEEE 1394 drivers. > > you omit the interesting next paragraph: > "Building the new drivers is only for advanced users (who for example > want the better speed of firewire-sbp2 relative to sbp2) - and for > distributors who know what is required in userspace to make use of the > new drivers and who can get bugfixes backported and rolled out quickly." > > on the kernel side we do backport firewire patches. > for the userspace side i still see lack of action on libdc1394 > "2008/01/05: The official version 2.0.0 has been released. > 2008/01/05: A first set of fixes have been released (version 2.0.1)" > > why is that not even in unstable/experimental? libdc1394 2.0.1 is in unstable: http://packages.debian.org/libdc1394-22 My IIDC cameras do not work correctly with a juju-enabled libdc1394 2.0.1. Furthermore, apart from coriander there are no applications that have migrated from libdc1394 v1 to v2. > the progress of the juju stack is very nice, there are quite some > fixes queued for 2.6.25, we will make those snapshots available > soonest. That is good to hear. > if the regression list for 2.6.25 is still high we may reconsider > there to build the old stack with blacklisted modules. > that has always been our stated fallback position, currently in the > development phase we encourage testing of the newer stack > on latest linux-images. I do not see why making the old stack available again, but blacklisted by default, discourages testing of the newer stack. If you have both available, then yes, users can switch to the new stack more easily, but at least they will still be using Debian kernel packages, and they can switch back to the juju stack just as well. If you do not make this option available, those who have problems with the new stack will have to compile their own kernels, and then they will not track the Debian kernel packages anymore. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#436267: Firewire support in lenny
On Tue, Feb 12, 2008 at 06:05:20PM +0100, Guus Sliepen wrote: > > even with 2.6.24-4 linux images? > > please mention the uname of your tests > > I'll see if I can do the tests on a clean install with the latest linux > images tomorrow. uname: Linux barebone1 2.6.24-1-amd64 #1 SMP Mon Feb 11 13:47:43 UTC 2008 x86_64 GNU/Linux I do get a good picture now, but isochronous channel allocation is not implemented, so I can't read out more than one camera at a time. This maybe workable for users who only have one IEEE1394 device that uses an isochronous channel, but for me it is still useless; I need to read out at least four cameras simultaneously (which works flawlessly with the stable stack). It may not be a fault of the new stack, because libdc1394-22 itself just doesn't provide channel allocation. I'll try the latest revision from Subversion later. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Intent to hijack gtkglext
On Sun, Feb 17, 2008 at 09:20:12PM -0600, William Pitcock wrote: > The current maintainer of gtkglext has not been maintaining the package > since 2004. The last upload was in 2006 to fix an NMU, which has not > been acknowledged yet. The current package is two major versions out of > date (1.0 vs 1.2). > > I need a newer version of gtkglext for various projects I am working on, > so if there is no objections within a reasonable amount of time (say a > week or so), I intend to prepare an upload and take the package. If I look at bugs #363395, there have been enough delays already. Just upload it now. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: ITP: ASTK -- Code_Aster build/control system and front-end
On Fri, Feb 22, 2008 at 05:07:20PM -0500, Adam C Powell IV wrote: > Package name: astk Why is it called astk? I can't find an astk tarball on the www.code-aster.org site. > Version: 1.5.5 > Author: EDF (Electricite de France) R&D > License: GPL > URL: http://www.code-aster.org/ > Description: Code_Aster build/control system and front-end Don't repeat the name of the package in the short description. Also, what is it a system and front end for? That is unclear from the description. > ASTK is a client-server front-end for the Code_Aster finite element > software (a.k.a. aster), as well as a build system used by Code_Aster > and Homard. It is unclear to me what this software can do. Can I generate finite element models with it? Or is it just a way to start simulations on a backend? Can I view models, or meshes, or results of calculations? What kind of finite elements are supported? If this is a frontend, is the backend also packaged for Debian? What is Homard? > The client is written in Tcl, and the server and build system in > python. I think it doesn't matter what language these tools are written in, as long as they do whay they're supposed to do. So this is not useful information for the long description. Use the debtags system instead for these kinds of annotations. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: ITP: ASTK -- Code_Aster build/control system and front-end
On Fri, Feb 22, 2008 at 07:40:45PM -0500, Adam C Powell IV wrote: > > Why is it called astk? I can't find an astk tarball on the > > www.code-aster.org site. > > astk is one of the tarballs in the aster-full-src-9.2.0-2.noarch.tar.gz > tarball on the site. They distribute sixteen .tar.gz tarballs within > that tarball, of which: [...] > There's really no point in distributing this tarball-of-tarballs, so > we're packaging the four unique tarballs from within it as separate > packages. You are absolutely right. > > It is unclear to me what this software can do. Can I generate finite > > element models with it? Or is it just a way to start simulations on a > > backend? Can I view models, or meshes, or results of calculations? What > > kind of finite elements are supported? If this is a frontend, is the > > backend also packaged for Debian? > > It's the build system and graphical interface for the aster binary(ies) > built in the aster package. Ah, so there will be other packages that will Build-Depend on astk? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
On Sat, Feb 23, 2008 at 01:41:05AM +0100, Sylvestre Ledru wrote: > Upstream Author : EDF / R&D Please include the full name of the author(s). > Description : ASter Command FIle Editor > > This package provides an application to help to create Code Aster > command files. > Code Aster is all-purpose FEM simulation software for structural > analysis. Please expand FEM to Finite Element Method. Also, is this a tool that provides a graphical user interface, or is it a command-line tool? What features make it so good at helping to create command files? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
On Sat, Feb 23, 2008 at 01:00:43PM +0100, Sylvestre Ledru wrote: > I updated it: > http://svn.debian.org/wsvn/pkg-scicomp/eficas/trunk/debian/control?op=file&rev=0&sc=0 > Is it ok for do you want me to develop this more ? > Description: ASter Command FIle Editor [...] The long description looks fine now, but I'd write the following short description instead: Description: graphical editor for Code Aster command files -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#468132: ITP: packagekit [...]
On Wed, Feb 27, 2008 at 08:53:04AM +0100, Sebastian Heinlein wrote: > * Package name: packagekit > Description : PackageKit provides a distribution neutral interface to > manage software packages. It provides a system wide daemon that performs > tasks like refreshing the cash, updating, installing and removing software > independetly from the user interface. By default, PackageKit uses PolicyKit > for user authentication. This allows to specify with fine-grained control > what your users can and cannot do. > > (Include the long description here.) Debian packages have both a short description and a long one. I also see you made some spelling errors. I suggest the following short and long description: Description: distribution neutral software package manager PackageKit provides a distribution neutral interface to manage software packages. It provides a daemon that refreshes the package cache, updates, installs and removes packages independent of the user interface. . By default, PackageKit uses PolicyKit to provide fine-grained access control. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Wed, Feb 27, 2008 at 03:51:38PM +0100, Thorsten Schmale wrote: > * Package name: monkey > Description : monkey is a small webserver based on the HTTP/1.1 protocol Don't include the name of the package in the short description. Also, "HTTP/1.1 protocol" is more something for the long description. Description: light-weight web server > Monkey is a Web Server written in C based on the HTTP/1.1 protocol. The > objective is to develop a fast, efficient, small and easy to configure > webserver. > Although it is very small and does not need much system resources, it > has a lot of nice features like Multithreading, Mimetype Support, > Virtualhosts, CGI & PHP, Basic Security features (Deny by URL + IP) The language the server is written in is not important. Use the debtags system to annotate the package with that kind of information. Also, don't use subjective wording like "nice features". There are also too much capitals in your description. I suggest the following: Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web server. It uses multi-threading and has support for MIME, virtual hosts, CGI and PHP. It offers basic security features, such as denying access to certain URLs for certain IP addresses. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Many packaged programs that are doing the same thing
On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: > > Even there, it looks very much like other "very small" webservers, > > such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd, > > mini-httpd or thttpd. What does it do better than any of them? Or > > worse? Or different? > > Why does a package need to clarify what's different about it than others > like it? Debian is about having the possibility of choosing between many > options for the same thing e.g. openssh, dropbear for sshd, 12 different > httpd options, etc. There is nothing wrong with having multiple packages in Debian that do the same thing. However, you can wonder whether it is really helpful for the user to have 10 or more light-weight http daemons to choose from. As a distribution, we have a much broader view than the authors of those http daemons. When we see something like this, maybe we should contact the upstream authors and suggest that they work together, so that the number of light-weight daemons to choose from decreases but the quality of the remaining will be better. Again, I'm not saying there should only be one light-weight http daemon. But more than 10? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
On Fri, Feb 29, 2008 at 02:30:29AM +, Ben Hutchings wrote: > On Sat, 2008-02-23 at 10:09 +0100, Guus Sliepen wrote: > > On Sat, Feb 23, 2008 at 01:41:05AM +0100, Sylvestre Ledru wrote: > > > > > Upstream Author : EDF / R&D > > > > Please include the full name of the author(s). > > > EDF is the usual name of the company whose logo appears on the upstream > web site <http://www.code-aster.org/>. (The initials used to stand for > Electricité de France, but the company has diversified and no longer > expands the initials.) Ok. But three letters is not enough for me, who is not French, to know that it stands for the company formerly known as Electricité de France. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Many packaged programs that are doing the same thing
On Fri, Feb 29, 2008 at 04:58:11AM -0600, William Pitcock wrote: [...] > > When we see something like this, maybe we should contact > > the upstream authors and suggest that they work together, so that the > > number of light-weight daemons to choose from decreases but the quality > > of the remaining will be better. > > > > Again, I'm not saying there should only be one light-weight http daemon. > > But more than 10? > > Why not? Debian ships more than 10 different shells, media players, etc. > Why should an httpd be not included because there are already others. > This isn't about being "helpful", this is about _choice_. When does it stop? After 20 httpds? 50? 1000? Surely there is a point where there is too much choice. So if we, as a distributor with an overview of the situation, see that there is so much choice, which can be good but _not necessarily_, we should put some effort in determining if we can improve the situation. For example: if two light-weight httpds have a very similar feature set, then if the two upstream maintainers can be made to work together and create a single httpd with the best qualities of both, then that will reduce choice, but the one choice left is better than both old choices. > Have you considered that perhaps the upstreams don't work together > because they DON'T WANT TO? Again, it's a matter of _choice_. Other possibilities: upstream doesn't know that there are other software packages available that do what they want. Or maybe he doesn't want to work together with other upstreams for the wrong reasons. > As a distribution, Debian's goals are to: > * provide the widest latitude of free software; > * provide the highest quality of packaging of said free software; > * ensure the software we ship by default is really free. Not only the highest quality of packaging, we also want to make sure the software itself is of good quality. Otherwise, why would we bother tracking upstream bugs? > If that means having a lot of different httpds to choose from, then > great! You're not being forced to use them, so why does it matter to you > if they are available in Debian? Most software in Debian is maintained > for personal reasons, e.g. the maintainer uses it. What further > justification than that is required? If we can create even better httpds by merging the development efforts, then yes it does matter to me. I want high quality software. I don't want a lot of choice of bad quality software. I am not saying that more or less httpds to choose from is good or bad in itself, but more than 10 light-weight httpds might be an indication that there is room for improvement. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#471312: ITP: libhyphenate -- An hyphenation library for C++
On Mon, Mar 17, 2008 at 11:09:24AM +0100, Steve Wolter wrote:
[...]
> In contrast to the libhnj implementation, this one isn't broken.
I think you should remove this line from the package description.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: exim, local resolver, host name lookups and IPv6
On Fri, Apr 11, 2008 at 05:48:19PM +, Robert Edmonds wrote: > Why is exim using gethost* calls? If you look in the > exim-4.69/src/host.c file, you'll see implementation details like: > > #if HAVE_GETIPNODEBYNAME > hostdata = getipnodebyname(CS host->name, af, 0, &error_num); > #else > hostdata = gethostbyname2(CS host->name, af); > error_num = h_errno; > #endif [...] > glibc has had these new getipnode* calls for quite some time; there's no > reason not to use them. Why doesn't exim-4.69/OS/os.h-Linux define > these feature macros? From the getipnodebyname(3) manpage: NOTES These functions were present in glibc 2.1.91-95, but were removed again. Several Unix-like systems support them, but all call them deprecated. The best way is to use getaddrinfo() and getnameinfo(). > Yes, there is a much better way: do not perform name resolution to > determine the host's FQDN. It is wrong. I agree. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[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
Re: Bug#478690: ITP: jit -- Just-in-time compilation support for GNU R
On Wed, Apr 30, 2008 at 06:54:00AM -0500, Dirk Eddelbuettel wrote:
> * Package name: jit
Same here. Please name the source package r-cran-jit.
> Package: r-cran-jit
> Architecture: any
> Depends: ${shlibs:Depends}, r-base-core (>= 2.7.0)
> Description: GNU R package just-in-time compilation support
> This package provides just-in-time compilation support. This requires
> the Ra extensions to R (to be provided by r-base-core-ra) and has no
> effect under the standard build of GNU R. For more on Ra and jit, see
> http://www.milbo.users.sonic.net/ra/index.html.
If it requires r-base-core-ra, add it to the Depends field.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: Bug#478689: ITP: getopt -- Command-line parsing for GNU R
On Wed, Apr 30, 2008 at 06:51:08AM -0500, Dirk Eddelbuettel wrote:
> * Package name: getopt
Please name the source package r-cran-getopt as well, just getopt is a
bit too generic.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: Bug#484532: ITP: festcat -- Catalan voices for festival
On Wed, Jun 04, 2008 at 08:01:41PM +0200, Miguel Gea Milvaques wrote: > * Package name: festcat > * URL : http://www.talp.upc.edu/festcat > > The FestCat package consists of a library providing > analysis of Catalan text, and the data to extend > Festival so that it can speak Catalan. Please follow the naming convention of the other festival packages. Name the source package festival-catalan or festival-ca, and the binary packages festvox-ca(talan) and/or festlex-ca(talan), depending on whether they contain voices or lexicographics. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#485553: ITP: charybdis -- fast, scalable irc server
On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote: > * URL : http://www.ircd-charybdis.net > * License : GPL > > Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody > seems to care about that, I'm going to assume that it's OK. People DO care, and it is not OK. Linking with OpenSSL is only allowed if there is an exemption to the license of charybdis that explicitly allows linking to the OpenSSL. See for example this page which gives a nice summary and links to some related debian-legal emails: http://www.gnome.org/~markmc/openssl-and-the-gpl.html -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
GPL+OpenSSL, Re: Bug#485553: ITP: charybdis -- fast, scalable irc server
On Tue, Jun 10, 2008 at 06:38:19AM -0500, William Pitcock wrote: > So, in a nutshell, nobody in the current IRCd development community > cares about perceived GPL+OpenSSL compatibility issues, so only Debian > does, which is "ok", but that's not so useful when Debian is already > shipping packages linked against OpenSSL with no exception (see below). [...] > So, in the grand scheme of things, I don't really think one more package > linked against OpenSSL is going to hurt anything. There are lots of packages which have licensing issues, but we try to resolve those issues. Adding a new one with known issues is not helping, it is hurting our efforts to produce a distribution that is free from licensing issues. I think if you discuss the issue with the other main developers and you agree to add the exemption to the upstream tarball, then it is OK for Debian to distribute charybdis. I don't think dead authors or people who contributed small patches will object, after all the intention was all along that one could freely distribute charybdis linked to OpenSSL. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#486425: ITP: bomstrip -- strip Byte-Order Marks from UTF-8 text files
On Mon, Jun 16, 2008 at 03:08:02AM +0300, Peter Pentchev wrote: > * Package name: bomstrip > Programming Lang: Awk, Brainf*ck, C, C++, Forth, Haskell, OCaml, Ook!, > Pascal, PHP, Perl, PostScript, Python, Ruby, sed, > Unlambda All these programming languages got me wondering. Apparently the same program is implemented in all these languages. But you only need one to get the desired functionality. Also, I see the sed variant is just a one-liner. Perhaps it is better if this functionality is merged with a package like coreutils or recode, if it is not already there someway. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#549901: ITP: eibd-server -- KNX/EIB server
On Tue, Oct 06, 2009 at 09:56:07AM +0200, Marc Leeman wrote: > * Package name: eibd-server > Description : KNX/EIB server > > eibd is a daemon which supports connection to an EIB (KNX) network > over various interfaces. It provides its services over TCP/IP or Unix > domain sockets. > It can also act as an EIBnet/IP server. The description provides no clue what this package does unless you already know what EIB, KNX and EIBnet/IP is. Please expand the acronyms and describe what use this daemon has to a user. What services does it provide over those sockets? What interfaces does it support other than EIBnet/IP? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
On Sat, Oct 24, 2009 at 08:24:31PM +0200, Marco d'Itri wrote: > I am proposing to set net.ipv6.bindv6only=1 by default for new > installations, to simplify configuration and administration of systems > using IPv6 and to make the system behaviour match the one of all other > operating systems, which default to this or just do not provide a > choice. [...] > While net.ipv6.bindv6only=0 is useful for daemons which are not designed > to listen on multiple sockets, it is annoying because it requires > dealing with IPv4-mapped addresses in logs and configuration files > unless the program takes care to convert them to IPv4 addresses. And bindv6only=0 is also not RFC compliant. However, a *lot* of applications that use listening sockets will not work correctly anymore when you change the default. So it probably is better to make it a release goal that applications should work with bindv6only=1, and only if enough of them are fixed to change the default. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
On Sat, Oct 24, 2009 at 10:00:07PM +0200, Marco d'Itri wrote: > > And bindv6only=0 is also not RFC compliant. However, a *lot* of applications > > that use listening sockets will not work correctly anymore when you change > > the > > default. So it probably is better to make it a release goal that > > applications > Can you make a list? I do not think there is a significant number, I > only know about vmware. Well, last time I tried bindv6only=1 on a server running many listening daemons. Over half of them stopped working properly (not listening on IPv4 anymore for example). I'll try this again when I can and present a list, but I cannot cover every program Debian. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: texi2html -split_chapter destination changed
On Tue, Oct 27, 2009 at 06:22:50PM -0700, Daniel Schepler wrote: > Hi, with the current version of texi2html (1.82-1), I'm getting lots of build > failures like (from diffutils-doc): [...] > It looks like it put the html files in diff before, but now it's putting them > just in the current directory. Before I started filing bug reports, I wanted > to know: is this an intentional change in behavior, or is it a bug in > texi2html? Oh great, I'm seeing build failures in one of my own packages as well. This is not the first time that texi2html changed its behaviour, in 2005 I had to change the build scripts as well (see bug #318562). It seems the latest texi2html reverts to the behaviour of before 2005. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
On Sat, Oct 24, 2009 at 10:05:51PM +0200, Guus Sliepen wrote: > > Can you make a list? I do not think there is a significant number, I > > only know about vmware. > > Well, last time I tried bindv6only=1 on a server running many listening > daemons. > Over half of them stopped working properly (not listening on IPv4 anymore for > example). I'll try this again when I can and present a list, but I cannot > cover > every program Debian. polipo and ircd-hybrid are the only ones that are problematic for me. I guess things have improved. Well, except for those daemons that are not listening on IPv6 at all of course... -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: doxygen + dot => anti-aliased png (was Re: Ridiculously large packages)
On Tue, Dec 01, 2009 at 03:03:37PM +0100, Mathieu Malaterre wrote: > Just for reference. Some package (such as vtk-doc) became very large > due to a minor change in doxygen/dot. Now PNG files are generated > using cairo which by default is doing antialiasing. Using : > > dot -Tpng:gd output.png input.dot > > force the use of libgd to create the png file. The file size was > reduced by a factor of 10 on the small experiments I played with. > > There is currently no easy way to update doxygen script to use this > trick (*). DD & DM have to resort hacking the DOT_PATH and have a fake > DOT script calling dot with the proper parameter. Perhaps it is better to generate SVG files? This will preserve the anti-aliased look, scale much better, and is probably even smaller than non-anti-aliased PNG. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: doxygen + dot => anti-aliased png (was Re: Ridiculously large packages)
On Tue, Dec 01, 2009 at 05:44:37PM +, Roger Leigh wrote: > > Perhaps it is better to generate SVG files? This will preserve the > > anti-aliased > > look, scale much better, and is probably even smaller than non-anti-aliased > > PNG. > > Definitely. I was just about to suggest the same thing. > > I think the only requirement this might not satisfy is clickable links > in the image (can you do the equivalent of image maps with SVG images?) Yes, even better, because you can put tags in the SVG itself. A quick Google shows this howto: http://www.zvon.org/HowTo/Output/howto_jj_svg_20.html -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Bug#423605: ITP: ndisgtk -- graphical frontend for ndiswrapper (installation of Windows WiFi drivers)
On Sun, May 13, 2007 at 12:00:53PM +0200, Julian Andres Klode wrote: > * Package name: ndisgtk > Version : 0.6 > Upstream Author : Sam Pohlenz <[EMAIL PROTECTED]> > * URL : http://archive.ubuntu.com/ubuntu/pool/universe/n/ndisgtk/ That is a link to the Ubuntu package. It's not a native package, so Ubuntu got the upstream source from somewhere. You should ask the Ubuntu maintainer(s) responsible for this package, and/or the upstream author, where the upstream source can be downloaded from. If it only exists in the Ubuntu repository, Ubuntu should make it a native package, but that seems undesirable to me. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Merging packages
On Sun, May 13, 2007 at 10:02:24AM -0500, Luis Rodrigo Gallardo Cruz wrote: > 1. I'll be shipping the compatibility script as /usr/bin/stunnel3 and > the main v4 binary as /usr/bin/stunnel4. I'll ship a /usr/bin/stunnel > symlink pointing at the wrapper for now, and eventually (after lenny, > for sure) change it to point at the v4 binary. You can use the alternatives system to create such a symlink for you. That automatically sets up a symlink, but the system administrator can also override it manually. > 2. Ditto for manpages The alternatives system can set up slave symlinks for the manpage that mirror any changes of the /usr/bin/stunnel symlink. > 3. I will turn the stunnel4 package into a dummy that just pulls the > new stunnel. How about creating a dummy stunnel package that pulls in stunnel4? Maybe in the future there will be version 5 of stunnel, and you have to do this all over again. > 4. stunnel v3 uses no configuration files, stunnel4 does and its > package has them installed on /etc/stunnel4 and similarly named files > and dirs. Since the surviving package is to be called stunnel, I think > it would be correct for its config files to have no '4' suffix on > their names. Nevertheles, I'd like stunnel4 users to have a painles > migration, which means somehow grabbing their stunnel4 files and > putting them in the new places. Is that a good idea? Should such > migration logic be put in the dummy transitional package? Or maybe I > should just live with funnily-named conf files for stunnel? I think you should mv /etc/stunnel4 /etc/stunnel in the new real package's preinst if /etc/stunnel does not exist yet. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Building packages twice in a row
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
> > Wouldn't it be better to unpack a package twice in two different
> > directories, build and clean in one dir and then compare the obtained
> > tree with the tree available in the other dir?
>
> IMHO, a good test would be to build the package twice and then to compare
> whether the created .debs are identical between the first and second run.
> (Of course, file timestamps would have to be ignored when comparing.)
There are lots of reasons why the resulting package can differ each time
you build it, some of them perfectly valid. For example, this is not
uncommon in C programs:
printf("foo version %s (built %s %s)\n", VERSION, __DATE__, __TIME__);
Also, running update-po will always change the header of a .po file to
reflect the last time update-po was run. I don't think we can require
that building a package twice in a row produces exactly the same .deb
and/or .diff.gz.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: making in stable or testing
On Sun, Jun 24, 2007 at 05:25:29PM +0100, Luis Matos wrote: > Dom, 2007-06-24 às 17:05 +0200, [EMAIL PROTECTED] escreveu: > > Hello devolpers, > > > > I want devolp packages for debian, must I make it in stable or testing? > > check your timetable ... do you want to develop your application to > start to use in th next two months or 2 years? > > the first one, develop in stable. > the second develop in testing, because by the time you finish, the > actual stable will be in shortly replaced, or will already be. You should develop packages in unstable, never in testing. If you also want people who are currently running stable to use your package, then you can also build the package in stable, but this will not be part of any official Debian repository. You might try to get it in the backports archive though. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#432023: ITP: ll-core -- Core modules used by all ll- and other modules
On Fri, Jul 06, 2007 at 09:34:36PM +0200, Bernd Zeimetz wrote: > * Package name: ll-core > Version : 1.9.1 > Upstream Author : Walter Doerwald <[EMAIL PROTECTED]> > * URL : http://www.livinglogic.de/Python/core/index.html > * License : Python lic. > Programming Lang: Python > Description : Core modules used by ll- and other packages [...] > If anybody can come up with a better short description - please let me > know. I'm packaging this module collection as dep. of XIST (itp > #336685). The packages will be added to the python-module team's svn. Shouldn't the package name be "python-ll-core"? Anyway, you should probably mention in the short description that it is a collection of Python modules, and what the modules do. I don't think it is useful to mention what the reverse dependencies are, unless it is only useful for XIST and other ll projects. Maybe something like this: Description: Python modules providing various basic utility functions -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492157: ITP: apollo -- The Apollo Solr Server
On Thu, Jul 24, 2008 at 03:47:53PM +1200, Paul Waite wrote: > Description : The Apollo Solr Server That is not a description, that's just the full name. What does this package do? I cannot find any answer in the long description either. The project website mentions that it is an "enterprise search server". Still vague, but I guess it is something equivalent to htdig. Both the short and long description should make clear that this is a web-based search engine/server/whatever. > The Apollo Solr Server is a debian packaging of the standard Solr Server > available from the Apache project (http://lucene.apache.org/solr/). This There is no need to mention that this is a Debian package. Also, the URL to the project page is already in the Homepage: header, there is no need to repeat it. > package can be installed with replication enabled, either as a Master or > a Slave. The latter is set up for you to rsync from the Master via cron. > > This apollo package also supports any number of instances of Solr, > running on separate ports. These are managed via a common utility 'apollo' > to provide create, remove, purge, start, stop, restart, and status. > > The package also includes a MaoriMacronsFilter plugin which can be set up > in your schema.xml to map macronned characters to stright ascii on both > index and query operations. The default schema.xml has this set up for > the 'text' field type already. It is a trivial exercise to provide other > mappings. The rest of the description reads like a manual page, not like a description of the features of Solr. Then, where does the name "Apollo" come from? I do not see any reference to that name on the Solr website. Finally, it seems Solr is already packaged by the Debian Java Maintainers, see http://packages.debian.org/solr-tomcat5.5. If there is anything in your package that is not in theirs, please coordinate with them. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492157: ITP: apollo -- The Apollo Solr Server
On Sat, Jul 26, 2008 at 09:00:52AM +1200, Paul wrote: [...] > I should also add that apollo is currently built as a native Debian > package, where the Solr tarball is downloaded in the build process, and > then bits of it used to construct the apollo binary package. Ok I see now that you have added your own enhancements to Solr. In that case, maybe it is better not to make a native Debian package, but to create your own "upstream" project, or of course try to get your enhancements merged with the original Solr project. In case they do not want to merge, you should make an official Apollo Solr website (you can use alioth.debian.org for that I think). That way other distributions can also easily track your progress and make packages out of it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492303: ITP: python-odfsvn -- odfsvn is a toolset that allows you to store ODF documents in a subversion repository.
On Fri, Jul 25, 2008 at 01:51:58AM -0300, Ricardo Ichizo wrote: > Description : odfsvn is a toolset that allows you to store ODF > documents in a subversion repository. You may be wondering why you would want > to store your documents in subversion. > > odfsvn is a toolset that allows you to store ODF documents in a > subversion repository. You may be wondering why you would want to > store your documents in subversion. There are a few reasons: [...] This cut&paste from the website isn't really a useful, self-contained description for this Debian package. In the description you copied, I don't see any reason to use odfsvn over plain svn. Looking at the website, I see that the real feature of odfsvn is to store the Subversion metadata inside the ODF header. You should mention this in the description. Regarding the formatting of the short and long description, please read http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-desc-basics -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492760: ITP: freedink -- A portable version of the Dink Smallwood game engine.
On Mon, Jul 28, 2008 at 06:40:11PM +0100, Bradley Smith wrote: > Description : A portable version of the Dink Smallwood game engine. The short description should be self-contained (people reading it may not see the long description at the same time). People generally do not know what a Dink Smallwood is, so you shouldn't refer to it in the short description. A better one is: Description: adventure and role-playing game engine > Dink Smallwood is an adventure/role-playing game, similar to Zelda, made > by RTsoft. Besides twisted humour, it includes the actual game editor, > allowing players to create hundreds of new adventures called Dink > Modules or D-Mods for short. The Dink Network hosts a copy of almost all > of them. I do not know for sure, but I think Dink Smallwood is a game, and FreeDink is just a game engine. You should make this clear in the long description. > In 2003, Seth A. Robinson from RTsoft released the source code of the > game engine, at version 1.07, under a free software license. You shouldn't mention the above sentence in the long description. The copyright information goes into the debian/copyright file, the version number is already part of the package, and the fact that it is released under a free software license is also superfluous, since your package will be part of Debian :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492875: ITP: wader -- graphical assistant for 3G connections
On Tue, Jul 29, 2008 at 04:50:14PM +0200, Jorge Salamero Sanz wrote: > Description : graphical assistant for 3G connections > > (from the website, not final description): > > Wader is a 3G communications software (GPL licensed), consisting of: > wader-core: a fork of the core of Vodafone Mobile Connect Card driver for > Linux, with some of its parts rewritten and improved to be able to interact > via freedesktop's D-BUS with other applications and the whole operating > system and desktop environment. > wader-gtk: a simple user interface, decoupled from core using D-BUS methods > and signals. Please put some thought in the long and short descriptions before posting the ITP, so we can review it. As you mentioned you copied the description from the website, but it is completely unclear to me what the software does and why I would want to install it. So it has something to do with these GPRS/UMTS dongles you can put in your laptop and surf via your mobile phone account. But what exactly does it assist me with? Is it a kind of network-manager clone for 3G cards? If so, shouldn't the functionality be merged with network-manager? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492922: ITP: arpon -- arp handler inspection
On Tue, Jul 29, 2008 at 11:27:55PM +0200, Giuseppe Iuculano wrote: > Description : arp handler inspection That is not a short description, that is just the expansion of the acronym. > ArpON (Arp handler inspectiON) is a portable handler daemon with some > nice tools to handle all ARP aspects. > It makes Arp a bit safer. This is possible using two kinds of anti Arp > Poisoning tecniques, the first is based on SARPI or "Static Arp > Inspection", the second on DARPI or "Dynamic Arp Inspection" approach. > You can use ArpON to pentest some switched/hubbed LAN with/without DHCP > protocol, in fact you can disable the daemon in order to use the tools > to poison the ARP Cache That is just ripped from the website. It is not very clear to me if this is a stand-alone daemon or some command-line tools or both, if it works as a real, bona-fide ARP daemon or if it is some kind of intrusion detection tool or vulnerability scanner. Some words, like "pentest" and "hubbed" do not exist in English as far as I know. Make sure capitalisation is consistent. Please clarify the description. Try to get upstream to clarify their description on the website as well. If you haven't already done so, read http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-desc-basics Other interesting things to know: How does arpon relate to existing packages like arpalert, arping, arptables and farpd? Does it also handle Neighbour Discovery packets (IPv6's equivalent of ARP)? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#492922: ITP: arpon -- arp handler inspection
On Wed, Jul 30, 2008 at 01:26:11AM +0200, Giuseppe Iuculano wrote: > > That is not a short description, that is just the expansion of the > > acronym. > > Yes, this won't to be package synopsis. > > > That is just ripped from the website. > > Yes, this is only a rip from upstream website. Please note that the reason ITPs are Cc'ed to debian-devel is that other developers can review them. This is not possible if the ITPs do not contain the information that would also be used in the final package(s). Although it doesn't have to be perfect from the start, just ripping some text only to fill in the fields is not helpful. > > It is not very clear to me if this > > is a stand-alone daemon or some command-line tools or both, > > both > > > if it works > > as a real, bona-fide ARP daemon or if it is some kind of intrusion > > detection tool or vulnerability scanner. > > Arpon is quite versatile, the main goal is to be an anti arp poisoning daemon, > but it can be an arp passive sniffer, arp cache manager ecc.. Ok, perhaps you can include a bullet list of all the things arpon can do in the long description. > You can read this: > http://arpon.sourceforge.net/manpage.html > http://arpon.sourceforge.net/documentation.html The long and short descriptions should be self-contained, one should not have to look up webpages in order to understand what the package does. (But I did read those webpages before I responded to your ITP.) > > Other interesting things to know: How does arpon relate to existing > > packages like arpalert, arping, arptables and farpd? > > Sorry, I don't understand this question, what problems could I have with > arping > arpalert ecc.? A Debian user who does not know which ARP tools are in Debian might search for "ARP" and find lots of packages. I also noticed that arpon implements some functionality also implemented by arpalert and arping for example. It would be nice to know if there is overlap between packages, if some things (like sending ARP pings) is easier to do with arping or arpon, etcetera. > > Does it also > > handle Neighbour Discovery packets (IPv6's equivalent of ARP)? > > As before, the main goal is to be an anti arp poisoning daemon, I'm not sure, > but with IPv6 this shouldn't be relevant. As far as I know, ND works exactly the same as ARP, except that the former is encapsulated in an ICMPv6 packet and ARP just has its own Ethernet type. So I think things like ARP poisoning should also be possible with ND, and if you can do ARP pings, you would also want to do ND pings. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#493697: ITP: mobile-manager -- mobile manager GPRS/3G daemon
On Mon, Aug 04, 2008 at 12:12:33PM +0200, Juan Manuel Garcia Molina wrote: > * Package name: mobile-manager [...] > Description : mobile manager GPRS/3G daemon > > Mobile Manager is a GPRS/3G daemon developed by Telefonica. > This daemon cover the GPRS/3G functions for develop and work > over GPRS/3G Is this similar to "wader" (see ITP bug #492875)? If so, perhaps you should make the upstreams work together. As for the description in your ITP, it doesn't really tell me what it is doing except that it has something to do with GPRS/3G. On the website, there is a very clear description, you should use it as a basis for the description of your package: Mobile Manager is a D-Bus service to control and use mobile data devices in Linux-based platforms. Mobile Manager provides a unified API to govern the following aspects of the GPRS/3G devices attached to the system: . * Plug & Play device support. * PIN/PUK management. * Device information and status. * Connection establishment and traffic monitoring. What is missing here is whether or not mobile-manager comes with a GUI component to interact with the daemon. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface
On Wed, Aug 06, 2008 at 11:44:51AM +0200, Vincent Bernat wrote: > * Package name: etherpuppet > Description : create a virtual interface from a remote Ethernet > interface > > Etherpuppet is a small program that will create a virtual interface > (TUN/TAP) on one machine from the ethernet interface of another > machine through a TCP connection. Everything seen by the real > interface will be seen by the virtual one. Everything sent to the > virtual interface will be emitted by the real one. > > It has been designed because one often has a small machine as his > Internet gateway, and sometimes want to run some big applications that > need raw access to this interface, for sniffing (Ethereal, etc.) or > for crafting packets that do not survive being reassembled, NATed, > etc. What is the added value of etherpuppet over existing tools, such as openvpn, tinc, gvpe, vde2? If there is none, or if the functionality that is missing from etherpuppet can be easily integrated with one of the existing tools, then you should tell upstream that it would be better to invest time and energy in one of the other solutions. Disclaimer: I'm the upstream and Debian maintainer of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#493977: ITP: embassy-phylip -- EMBOSS conversions of the programs in the phylip package
On Wed, Aug 06, 2008 at 07:31:19PM +0900, Charles Plessy wrote: > Package name: embassy-phylip > Description : EMBOSS conversions of the programs in the phylip package > > The embassy-phylip programs are EMBOSS conversions of the programs in > Joe Felsenstein's PHYLIP package, a package of programs for inferring > phylogenies. These programs all have the prefix "f" to distinguish them > from the original programs. First of all, the description of the package should be self-contained. If it does the same as the phylip package, then copy the description of the phylip package, and only add at the end of the description that this is an "EMBOSS conversion". Then there is the question what an EMBOSS conversion entails. Why would one want to use embassy-phylip instead of phylip? The only difference you describe is that there is an extra "f" in the filename. If the differences between embassy-phylip and phylip are small, then you should suggest both upstreams to work together. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface
On Wed, Aug 06, 2008 at 02:10:46PM +0200, Yves-Alexis Perez wrote: > > What is the added value of etherpuppet over existing tools, such as > > openvpn, tinc, gvpe, vde2? If there is none, or if the functionality > > that is missing from etherpuppet can be easily integrated with one of > > the existing tools, then you should tell upstream that it would be > > better to invest time and energy in one of the other solutions. > > Well, etherpuppet is not really something to use as a simple vpn. You > use it to really clone (including low level stuff) the interface on the > remote side. Ok, I see now that only one side of the etherpuppet tunnel uses a tun/tap device, the other side copies everything to/from a real Ethernet interface. Still, the other tools I mentioned can all handle Ethernet frames. In fact, tinc can be compiled to connect to a real Ethernet interface instead of a tun/tap device, so it might already have the capability to do what etherpuppet does. The advantage of these tools is that they can provide encryption, and some of them can connect more than two endpoints together. The reason I urge you to consider having upstream merge his functionality with one of the others is that otherwise there is yet another tunnel tool out there. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#494488: ITP: polyml -- Standard ML implementation
On Sat, Aug 09, 2008 at 11:45:49PM +0200, Lionel Elie Mamane wrote: > * Package name: polyml [...] > Description : Standard ML implementation > > Poly/ML supports the full version of the language as given in the > "Definition of Standard ML (Revised)", generally known as ML97. As > well as being extremely fast and efficient implementation of Standard > ML Poly/ML provides several additional features. There is a foreign > language interface which allows dynamically linked libraries to be > loaded and functions within them called from ML. An X11 > interface using Motif is available. There is also a symbolic debugger > for Poly/ML. Your definition assumes the reader knows what Standard ML is. Most of them don't. Please include something like the following paragraph in the long description (taken from Wikiepedia): Standard ML is a general-purpose, modular, functional programming language with compile-time type checking and type inference. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#495630: ITP: libfaketime -- report faked system time to programs
On Tue, Aug 19, 2008 at 02:13:44AM -0400, Daniel Kahn Gillmor wrote: > * Package name: libfaketime > Description : report faked system time to programs There is already another package in Debian that provides similar functionality: datefudge. Perhaps you can get both upstreams to merge there efforts? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#499917: ITP: esekeyd -- multimedia keyboard daemon for Linux
On Tue, Sep 23, 2008 at 06:24:04PM +0200, Krzysztof Burghardt wrote: > * Package name: esekeyd > Description : multimedia keyboard daemon for Linux > > ESE Key Daemon is a multimedia keyboard daemon for Linux. With the 2.6 kernel > series it can also handle remote controls, as they are presented as keyboards. > No kernel patch is required. It is a userspace program that pools > /dev/input/event? interfaces for incoming keyboard key presses. Sounds like it does something similar as inputlirc (for which I'm both upstream and Debian maintainer), or does it do something else? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#502482: ITP: xplot-xplot.org -- fast tool to graph and visualize lots of data
On Thu, Oct 16, 2008 at 10:02:00PM +0200, Michael Banck wrote: > > * Package name: xplot-xplot.org > > > > xplot is a fast visualization tool for examining multiple data sets in > > parallel plots. It supports easy zoom-in and zoom-out capabilities, and > > synchronized views into multiple data sets (with the -x, -y, and -tile > > options). > > Looks like the last release was in 2003, is this still maintained > upstream? If not, what make it stand out beyond the other plotting apps > we have already? Fast zoom-in, zoom-out and panning on multiple plots on large datasets is something very little plotting apps do. The only good app that can do that that I've used is kst. I haven't tried xplot, but if it can do this then it would stand out (especially since it's a very small tool). -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 03:05:32PM +0100, Christoph Haas wrote: > it took a little longer than I expected but I finally launched > > http://screenshots.debian.net [...] > Have fun and let me know what you think. Please do not reduce images in size. The screenshots of, for example, dillo and amiwm are horrible. If you have a guideline of having a maximum size of 800x600 pixels, just give an error when someone uploads a screenshot that is larger than that. A link to packages.debian.org for every package would also be nice. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Let's restart from scratch the gr_lenny vote (in a better form this time)?
On Thu, Dec 18, 2008 at 01:22:40PM +0100, Sandro Tosi wrote: > So, how many are in favor of redo *completely* the vote (in more > ballot, the first being the one for lenny ONLY)? how many should we be > to let it happen? how many should be in contrary to stop this re-vote? > how can we express the need for a better vote to let our beloved lenny > be released? I'm against stopping the current vote. Let's wait for the outcome, and after that hold new votes for options that are still relevant then. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Let's restart from scratch the gr_lenny vote (in a better form this time)?
On Thu, Dec 18, 2008 at 02:59:52PM +0100, Michael Tautschnig wrote: > Do we have any well-defined procedure to stop/cancel a GR (in progress)? If > not, > is it the DPL to decide, based on what is voiced on this list? Shouldn't > people > just say "Further discussion" in their votes to express such concerns (in > terms > of a vote)? Certainly, if there are enough people putting "Further discussion" at the top, the GR is effectively canceled. And even if "Further discussion" does not win, those who oppose of the current ballot can still specify their preferences for the other options. AFAIK, it's also possible for those people who already voted and are now changing their mind after reading these discussions to recast their vote. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Bug#509225: ITP: tevent -- talloc-based event loop library
On Fri, Dec 19, 2008 at 10:53:47PM +0100, Jelmer Vernooij wrote: >Package name: tevent > Description: talloc-based event loop library > > tevent is a simple library that can handle the main event loop for an > application. It supports three kinds of events: timed events, file > descriptors becoming readable or writable and signals. > > Talloc is used for memory management, both internally and for private > data provided by users of the library. It seems very similar to libevent and libev, both already in Debian. Is there anything special about tevent using talloc? Is upstream aware of these other projects? If possible, try to get them to work with each other to merge their features and reduce the number of event loop libraries. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: "Semantic" shell? (for lack of better name)
On Fri, Jan 02, 2009 at 08:51:12PM -0600, Bryan Bishop wrote: > I've basically written up this email on a site as well- > http://heybryan.org/shell.html I do not see what this has to do with Debian Development. It also sounds awfully similar to what doxygen does. However, most manuals generated with doxygen are absolutely worthless: first and foremost they describe the syntax, not the semantics. It's up to the programmer to describe the semantics, and most of them forget. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Bug#510624: ITP: pigz -- Parallel Implementation of GZip
On Sat, Jan 03, 2009 at 09:57:33PM +0100, Eduard Bloch wrote: > PS: I plan to hack it a little bit and use syssconf function on Debian > systems to determine the real number of CPU cores (#x) since pigz's > default value is 8 which is much more than home systems have nowadays, > and the performance isn't getting (much) better with a constant number > of idle threads, they just consume more memory. Although sysconf() can tell you the total number of cores and the number of cores that are online in your system, it does not tell you how many cores are available for your program. It's better to use sched_getaffinity() to get the set of CPU (cores) available to your program. And if you know better than the OS, use sched_setaffinity() to bind each thread to it's own core. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: Bug#511938: RFP: netlogo -- logo interpreter with several turtles
On Thu, Jan 15, 2009 at 09:21:45PM +0200, Nick Shaforostoff wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > > --- Please fill out the fields below. --- > please package it, if the license is ok for you. > >Package name: netlogo > Version: > Upstream Author: [NAME ] You need to fill in the version and upstream author(s). > URL: [http://ccl.northwestern.edu/] A better URL would be http://ccl.northwestern.edu/netlogo/ > License: [GPL, LGPL, BSD, MIT/X, etc.] The license of netlogo (which you should have filled in) is not DFSG-compliant. So netlogo can only go into non-free. Also, according to the netlogo website, the source code is not available. Do you really want to package this? > Description: [NetLogo is a cross-platform multi-agent programmable > modeling environment.] Please fill in ALL the fields, and provide a long description as well. Also, do not repeat the name of the package in the short description. See section 6.2 of the Developers Reference for more information: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-debian-control -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Re: ITP: randim -- Random Image Generation using Iterated Function Systems
On Sat, Jul 28, 2007 at 12:53:42PM +0200, Gürkan Sengün wrote: > Package: wnpp > Severity: wishlist > > * Package name: randim >Version : 0.5 >Upstream Author: Adrian Robert <[EMAIL PROTECTED]> > * URL : http://interstitiality.net/ifs_f.html > * License : GNU GPL >Description : Random Image Generation using Iterated Function > Systems > This is an interactive fractal image generation program based on the > theory of iterated function systems as developed by M. F. Barnsley > (1988). > One well-known and remarkable image generated by this method is a > detailed picture of a fern leaf (see, e.g., Gleick, 1987). [...blabla...] It's interesting that IFS can generate such a remarkable image, and it is interesting to know that it is only 4 sets of 6 numbers that produces it, but this is not a description of randim. What does randim do and how would you use it? Does it have a graphical user interface or is it a command line utility? Does it output vector or bitmap graphics? Things like that should be in the description. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
wireless-tools marked non-for-us on S390, blocking other packages from entering testing
Hello,
Several people have emailed me that their packages, which depend on
wireless-tools, can't enter testing because wireless-tools is
out-of-date on S390. It appears that at some point, the wireless-tools
package was marked not-for-us on S390. Newer versions have been uploaded
since then, but since the S390 autobuilders did not build them, and an
older S390 package was still in the archive, the new versions are not
being considered to move to testing.
Now, the S390 architecture may be different enough from other
architectures that it does not have the ability to connect a wireless
network card to. I can see why you would want to block wireless-tools
from being autobuilt on S390 then. But if you follow the reverse
dependencies of the wireless-tools and libiw29 packages, you see that
blocking these packages means that you end up making KDE and GNOME
uninstallable.
The wireless-tools packages are very small, and have in the past been
autobuilt for S390 without any problems. Please choose whether you want
to include wireless-tools on S390, even if the only functionality on
S390 would be to say "no, this interface has no wireless capabilities",
or to exclude wireless-tools on S390, and consequently want to deal with
the rather large problem of reverse dependencies.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: bonding and bridging
On Tue, Aug 14, 2007 at 01:25:49AM +1000, Russell Coker wrote: > I want to have a server with two Ethernet links in a redundant configuration, > and to bridge it as the primary interface. So far the below is the only > configuration in /etc/network/interfaces that I can get to work. > > It would be cleaner and clearer if I could have a separate bond0 device > specified in the interfaces file, but according to my experiments so far this > seems impossible. Add the bonding module to /etc/modules, so that bond0 exists when the network interfaces are brought up. Then you can do something like: iface bond0 inet static address 0.0.0.0 netmask 0.0.0.0 slaves eth0 eth1 iface xenbr0 inet static address 10.0.0.123 gateway 10.0.0.1 bridge_ports bond0 That should do virtually all that you want. Look into the README.Debians of the bridge-utils and ifenslave packages for more details. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: bonding and bridging
On Mon, Aug 13, 2007 at 08:21:35PM +0200, Stephan Seitz wrote: > > iface bond0 inet static > >address 0.0.0.0 > >netmask 0.0.0.0 > >slaves eth0 eth1 > > I would use: > iface bond0 inet manual Ah, I forgot about the inet manual method. > slaves eth0 eth1 > pre-up /sbin/ifconfig bond0 up > > Without the pre-up line bond0 will not be activated (Etch). Correct. It is not necessary for lenny though. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Package cache
On Sat, Aug 18, 2007 at 07:29:55PM +0200, Gonsolo wrote: > Would it be feasible to add something like a package cache to Debian? > > This way only a minimal Debian system would be installed locally on > the hard disk. All other packages are fetched only when used. For example, > user Joe sets his package cache to 400MB and installs Openoffice. > The installation lasts one second because only a few symlinks are created. > When Joe uses Openoffice for the first time, All necessary files are fetched > from the Internet and put in the package cache. So the first startup will be > slow. The next time all necessary files are on the disk and Openoffice starts > as usual. [...] Well, it could be implemented with a FUSE daemon, that you mount over /usr for example, and which periodically fetches the Contents-.gz file from a mirror. It the uses the Contents file to generate directory listings. If some package tries to open() a file that is not already in the original /usr filesystem, it will look into the Contents file to determine which package contains the open()ed file, installs it, and then lets the open() continue. It can also track usage information this way. It's a daemon that you can start as root during boot, so users don't need special privileges. Also, if you stop the daemon, the original /usr filesystem becomes visible again, which can be used without problems. I'm not going to implement this though. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Package cache
On Tue, Aug 21, 2007 at 11:31:39AM +0200, Krzysztof Burghardt wrote: > 2007/8/21, Guus Sliepen <[EMAIL PROTECTED]>: > > I'm not going to implement this though. > > Doesn't auto-apt do this? It uses a bit different approach - preloaded > library to overwrite stat(), open() and so on, then pauses program > until package is installed. Hm, yes that would do almost the same, except that a user has to explicitly run auto-apt, and the user needs to have sudo rights to install packages. OTOH it doesn't require a daemon that mounts over an existing filesystem, and it already exists :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Package cache
On Wed, Aug 22, 2007 at 01:52:40PM +0200, Michelle Konzack wrote: > Am 2007-08-21 11:26:26, schrieb Guus Sliepen: > > Well, it could be implemented with a FUSE daemon, that you mount over > > /usr for example, and which periodically fetches the Contents-.gz > > file from a mirror. It the uses the Contents file to generate directory > > listings. If some package tries to open() a file that is not already in > > the original /usr filesystem, it will look into the Contents file to > > determine which package contains the open()ed file, installs it, and > > then lets the open() continue. It can also track usage information this > > way. It's a daemon that you can start as root during boot, so users > > don't need special privileges. Also, if you stop the daemon, the > > original /usr filesystem becomes visible again, which can be used > > without problems. > > > > I'm not going to implement this though. > - END OF REPLIED MESSAGE - > > I have short checked the Contents-i386.gz from Sarge > and it contain 1.457.478 lines... > > Which mean, you need at least those inodes availlable > otherwise you will run into heavy trouble. That is not a problem with FUSE. You only have to make data available on demand. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#440823: ITP: kelbt -- backtracking LR parser
On Tue, Sep 04, 2007 at 05:43:15PM +0200, Robert Lemmen wrote: [...] > Description : backtracking LR parser > > Kelbt generates backtracking LALR(1) parsers. Standard LALR(1) parser If it is a parser _generator_, mention this in de short description as well. > generators emit an error upon encountering a conflict in the parse tables. [...] > strategy is achieved. In cases where productions are parsed out of the order > given, there is a simple grammar transformation which remedies the problem. > See the CASCON paper for more details. > . > As a proof of concept, Kelbt has been used to write a partial C++ parser > (included) which is composed of strictly a scanner, a name lookup stage and a > grammar with standard semantic actions and semantic undo actions. Which CASCON paper? I don't think you should mention this in the description. The description is meant for a user to decide if he wants to install this package or not. You shouldn't make a user follow references, that is besides the point. I also don't think that the paragraph about the proof of concept is useful. The only useful information is "C++". Does Kelbt indeed output C++ code? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#441224: ITP: oracleasm -- This is the kernel driver for a generic Linux implementation of ASMLib.
On Fri, Sep 07, 2007 at 04:09:14PM +0200, Bjoern Boschman wrote: > Package: wnpp > Severity: wishlist > Owner: Bjoern Boschman <[EMAIL PROTECTED]> > > > * Package name: oracleasm > Version : 2.0.4 > Upstream Author : Joel Becker <[EMAIL PROTECTED]> > * URL : http://oss.oracle.com/projects/oracleasm/ > * License : GPL > Programming Lang: C > Description : ASMLib is a library addon for the Automatic Storage > Manager of Oracle Database 10g. This is the kernel driver for a generic Linux > implementation of ASMLib. That is too long. Keep the short description to one sentence, preferably not more than about 60 characters. > (Include the long description here.) You also need to create a long description, so we can review it before you upload this package. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#441302: ITP: getxpath -- extract a value from a XML file using a XPATH expression
On Sat, Sep 08, 2007 at 01:37:37PM +0200, Loic Dachary wrote: > Package: wnpp > Owner: Loic Dachary (OuoU) <[EMAIL PROTECTED]> > Severity: wishlist > > * Package name: getxpath > Version : 0.4.0 > Upstream Author : Loic Dachary > * URL or Web page : http://specs.dachary.org/getxpath/ > * License : GNU GPLv2 or later > Description : extract a value from a XML file using a XPATH expression > > getxpath(1) > getxpath(1) > > NAME >getxpath - extract a value from a XML file using a XPATH expression > > SYNOPSIS >getxpath xpath [selector] xmlfile [...] That is NOT a description. That is a copy of the manual page. A description is a few paragraphs describing what the program does, if it is a command line tool or a graphical user interface, maybe what its strengths and weaknesses are, but not which arguments you can specify on the command line. Have a look at the description of other packages to see how it should look like. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#441224: ITP: oracleasm -- This is the kernel driver for a generic Linux implementation of ASMLib.
On Sat, Sep 08, 2007 at 03:38:49PM +0200, Bjoern Boschman wrote: > Description: kernel driver for implementation of Oracle ASMLib > > Long Description: > > ASMLib is a support library for the Automatic Storage Management feature of > Oracle Database 10g. Automatic Storage Management (ASM) simplifies database > administration. It eliminates the need for the DBA to directly manage > potentially thousands of Oracle database files, requiring only the > management of groups of disks allocated to the Oracle Database. ASMLib > allows an Oracle Database using ASM more efficient and capable access to > the disk groups it is using. Much better! The only thing that is unclear from the long description is whether this is a library or a kernel driver. Looking at the oracleasm source, it is indeed a kernel driver. You should mention this in the long description as well. On a side note, I tried to compile it on 2.6.22.1 for the amd64 architecture, but it failed. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#446791: ITP: python-pycg -- NVIDIA's Cg 1.4 for Python
On Mon, Oct 15, 2007 at 08:15:32PM +0200, Sandro Tosi wrote: > Package: wnpp > Severity: wishlist > Owner: Sandro Tosi <[EMAIL PROTECTED]> > > * Package name: python-pycg > Version : 0.14.1 > Upstream Author : Calle Lejdfors <[EMAIL PROTECTED]> > * URL : http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/ > * License : ? You must specify the license that governs this package. > Programming Lang: Python > Description : NVIDIA's Cg 1.4 for Python You also must write a long description. Please reply to this message with the missing information, so we can have a look at it. The same goes for the PyGLEW package. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#446791: ITP: python-pycg -- NVIDIA's Cg 1.4 for Python
On Mon, Oct 15, 2007 at 10:20:34PM +0200, Sandro Tosi wrote: > > You also must write a long description. Please reply to this message > > with the missing information, so we can have a look at it. The same goes > > for the PyGLEW package. > > Thanks for your reply. I know I have to provide licence and long > description, but as of now I still don't know them; I've contacted Maybe you don't know the license (although PyGPU is GPL version 2, it says so in COPYRIGHT.txt), but you can already write a long description. > upstream author (the same of pygpu, I'm packaging it and it depends on > pyglew and pycg provided by upstream) regarding the packages he > provides, since they are only a bunch of binary files (with no source) > and an installer python script. Well, the PyGLEW package should also be GPL version 2. If it has a license incompatible with GPLv2, then you cannot link both that library and PyGPU to an application, and the website says that PyGPU doesn't work without PyGLEW. While you're at it, tell upstream that they should include the full license text in COPYRIGHT.txt, or ask if they really expect everyone to write a letter to the Free Software Foundation :) > I'll surely write down those information as soon as I'll be sure about that. Ok, but next time explicitly mention that you are missing information (and why) in the ITP. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: net-tools maintenance status
On Sat, Dec 01, 2007 at 12:24:58PM +0100, Olaf van der Spek wrote: > I'm sorry to ask again, but: > What's the maintenance status of the net-tools package? > Is there any chance Lenny will ship with for example working IPv6 > support in netstat? > I emailed MIA about this, but MIA went MIA itself, no response anymore. :( > > The bug count is up to 112. > Only two NMU translation uploads have been done in the past two years. > No other uploads at all. Hm, looks bad indeed. I'll try to see if Bernd Eckenfels is still alive but if I can't reach him in a week I'll adopt the package. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#456456: ITP: unperish -- release and build free software projects
On Sun, Dec 16, 2007 at 01:21:49AM +0200, Lars Wirzenius wrote: > Package: wnpp > Severity: wishlist > Owner: Lars Wirzenius <[EMAIL PROTECTED]> > > * Package name: unperish > Version : 2.2 > Upstream Author : Lars Wirzenius <[EMAIL PROTECTED]> > * URL : http://liw.iki.fi/liw/unperish/ > * License : GPL-2+ > Programming Lang: Python > Description : release and build free software projects > > Unperish takes care of all the repetitive, mechanical steps of releasing > and bulding a free software project: creating a tar.gz for distribution, > building a Debian package, etc. How does unperish make life easier than "make dist" and "debuild"? This is unclear if you only look at the description. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#456519: ITP: pystock -- watch Chinese stock stats
On Sun, Dec 16, 2007 at 07:41:08PM +0800, LI Daobing wrote: >Package name: pystock > Version: 0.2 > Upstream Author: yetist <[EMAIL PROTECTED]> > URL: > http://tel.linuxfans.org/nuke/modules.php?name=Site_Downloads&op=geninfo&did=4892 > License: GPLv2 > Description: watch Chinese stock stats This is only the short description. You also need to provide a long description in your ITP. It would be very interesting to know how you can watch stock stats with this program. Is it a commandline utility that only displays the current stock price? Or is it a GUI that shows graphs? That aside, is this program only useful for Chinese stocks? If so, the package name is too generic. It should probably renamed to pystock-chinese or something equivalent. If possible, also convince upstream to make the package name less generic. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
