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
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
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.
owner 461583 ! retitle 461583 ITP: libdc1394-22 -- high level programming interface for IEEE1394 digital camera severity 461583 wishlist thanks On Sat, Jan 19, 2008 at 12:41:48PM -0500, Peter Antoniac wrote: > Package: wnpp > Severity: urgent > Owner: Peter Antoniac <[EMAIL PROTECTED]> > > 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. [...] I don't mean any offense, but looking at the ITP and the libdc1394v2 package itself, I get the feeling that you are not completely up to date with Debian packaging: - There is no bug severity named "urgent", and ITPs should have severity "wishlist". - The way to ensure library packages don't conflict with older versions is to append the soname to the package names, it should be libdc1394-22 instead of libdc1394v2. - Missing and incorrect Conflicts: entries in the control file for Debian. Therefore I decided to use Peter de Schrijver's and my own packaging as a basis for packaging 2.0.1. I'm adopting the packages from Peter de Schrijver. I will include a -doc package and rename -examples to -utils. If you have other suggestions I will be happy to hear them. If you really want to maintain the Debian packages yourself, read all on http://www.debian.org/devel/, read up on all Debian bug reports regarding libdc1394, and try to become an official Debian developer. Otherwise, I think it is better that you work on the library itself instead of its packaging; I believe there is a lot to do to get everything working with the juju stack. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#461583: ITP: libdc1394-22
On Fri, Jan 25, 2008 at 07:40:04PM +0100, Kurt Roeckx wrote: > On Sun, Jan 20, 2008 at 11:15:09PM +0100, Guus Sliepen wrote: > > On Sun, Jan 20, 2008 at 11:18:14PM +0200, Peter Antoniac wrote: [...] > > I also added Conflicts with 20, because some people might have installed > > that one from experimental, and the -utils package has to Conflict with > > the old -examples package. > > I'm guessing that there is a minor misunderstanding here. The conflicts > are only for the -dev packages. The library packages themself don't > conflict. > > But I have to wonder a few things: > - Why do you need 2 source packages for libdc1394? Do you think > migrating from the current "13" to "22" will take a long time? Did > things change alot in the API? We only seem to have 10 packages > in unstable that build depend on libdc1394 so I don't see why we > need 2 source packages for that. Because they all depend on libdc1394-13, and the API has changed a lot in the mean time. You cannot recompile even the simplest application written for libdc1394-13 with libdc1394-22. I don't expect all those packages depending on the old libdc1394 to have everything ported before lenny is released. Another point is that libdc1394-13's last release was in August 2007, so you can still consider it maintained by upstream. There is no reason for applications to move to the new libdc1394 unless they use new things not found in the older library. > - Why do you want to embed the current soname in things like the -dev > and -doc packages? (It might be related to the first question.) Exactly because I want other package maintainers to be able to choose between 13 or 22, depending on what their upstream supports. > - Is there really a need to have 2 "utils" binary packages? They > even conflict with each other, and the "22" doesn't seem to make > any sense in this case. Hm, I agree that the "22" in the utils package is unnecessary. I'll try to remove it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
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
Bug#461446: O: libdc1394-13
owner 461446 !
retitle 461446 ITA: libdc1394 -- high level programming interface for IEEE1394
digital camera
thanks
I've taken over maintainership of libdc1394. Because most users of
libdc1394 still use the old API, libdc1394 will stay for the time
being. I will close this bug when there is a need to upload a new
libdc1394 package.
For those who would like to use libdc1394 >= 2.0, use the libdc1394-22
packages.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#467085: 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
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
Bug#467085: 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
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
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
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
Bug#468183: 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
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
Bug#468183: 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
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
Bug#471312: ITP: libhyphenate -- An hyphenation library for C++
On Mon, Mar 17, 2008 at 12:18:28PM +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. > > Thank you for the feedback. I added this line to make sure that this > package is found when an user searches for libhnj, which omitted cru- > cial parameters in the hyphenation algorithm and thus can waste quite > some time. > > Is there a good way to formulate this? Surely Conflicts: is too hard? > Or just erase it and hope libhnj will get fixed some day? Conflicts: should only be used if both libraries cannot be installed at the same time, for example because they install binaries or libraries with exactly the same filename. There is no libhnj in sid anymore. There is libhyphen, which says it's a modified version of libhnj based on the TeX algorithm. Have a look at it, maybe it does the same as your libhyphenate. If not, maybe you can merge your improvements with libhyphen. If you do package libhyphenate and want to mention libhnj, just say in the long description that it works similar as libhnj but has an improved algorithm. Even though you think it sucks, the package description is not the place to complain about other packages. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#471312: ITP: libhyphenate -- An hyphenation library for C++
On Sun, Mar 23, 2008 at 11:47:21PM +0100, Steve Wolter wrote: > On the positive side, I've a small C file here that provides a library > interface that is binary-compatible to libhyphen. I'll write to the > maintainers of libhyphen, check with them on my implementation (which > even fixes libhyphen bugs), and make sure that libhyphen gets replaced > if possible. There really should not be two libraries with the same job > around, but unfortunately libhyphen is unmaintainable. The libhyphen maintainers might disagree about libhyphen being unmaintainable. Also, even if the libhyphen maintainers agree that your version is better and can completely replace libhyphen, you should talk with the maintainers/upstream of packages depending on libhypen, and see if they might not use your library directly instead of using a compatibility layer. > The new version of the comment is: > This library provides an implementation of Frank Liangs hyphenation > algorithm, better known as the TeX hyphenation algorithm, for C++ and C. > The algorithm is similar to the one used by libhnj/libhyphen, but > handles hyphenation-free areas at the start and end of words correctly. > libhyphenate1 supports English, German, French and Spanish out of > the box, and every site with a TeX installation can distill its > TeX hyphenation files for more languages. > . > This package comes with complete documentation for the interface > and the process of pattern generation. > > Is that better? Yes! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#471312: ITP: libhyphenate -- An hyphenation library for C++
On Mon, Mar 24, 2008 at 11:12:16AM +0100, Steve Wolter wrote: > Great. I've packaged the libhyphenate (without any compatibility > interface), lintian-checked it and uploaded to: > http://swolter.sdf1.org/libhyphenate-debian.tar.gz I see that it's a so-called native package. Since your library is useful outside Debian, you should not put the debian/ directory inside the libhyphenate_1.1.0.tar.gz file. Rather, you have a libhyphenate_1.1.0.orig.tar.gz without the debian/ directory, you unpack it, add the debian/ directory, and change the version number in debian/changelog to 1.1.0-1. If you then build the package, it will create a .diff.gz file with just the Debian specific changes. > I'm no maintainer, however, but if I got the Manual right, the > package needs a sponsor now to be uploaded. I'll put the project > on http://sponsors.debian.net soon, if that's the right way. That is the right way. Once you have a sponsor he should be able to help you figure out the last details. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
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
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
Bug#330953: I might be interested!
reassign 330953 ftp.debian.org retitle 321907 Please remove package rocks from unstable and testing. thanks On Sun, Nov 27, 2005 at 05:38:56PM +0100, Torsten Schlabach wrote: > >>>I might be interested to adopt the rocks package. > >>>What would I have to do to adopt the package? > >>> > >>Upload a new version with yourself as the maintainer :) > > > >I still haven't seen you do that. > > > Sorry, a lot of other prios. But thank you for the reminder! I still haven't seen an upload, and I still haven't seen a new upstream version. In other words, this package is useless (it doesn't work) and unmaintained. I ask the ftp-masters to remove this package from the archives. Torsten, this does not change much for you. If you ever do get around to working on this package, you probably can just upload it, it then will be treated as a new package. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#341102: Please remove trophy from the archives.
reassign 341102 ftp.debian.org retitle 341102 Please remove package trophy from unstable and testing. thanks Noone has shown interest in taking over Trophy, both upstream and downstream. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#352537: O: rosegarden2 -- An integrated MIDI sequencer and musical notation editor
Is there a reason why this package is being orphaned instead of being removed from Debian? As I see it, Rosegarden 4 is a complete replacement for Rosegarden 2. If so then there is no need to keep Rosegarden 2 around. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#365344: ITP: kalign -- Global and progressive multiple sequence alignment
On Sat, Apr 29, 2006 at 09:00:03PM +0900, Charles Plessy wrote:
> URL : http://msa.cgb.ki.se/downloads/kalign-1.04.tgz
I was about to say that an URL to the home page of this program would be
more useful than a link to the latest tarball, but I noticed that
> Homepage: http://msa.cgb.ki.se
Produces a page that only contains broken links. If you have any
connections with the webmaster of that site or the upstream maintainer,
please tell them to fix their website.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#368291: ITP: libnuml-cil -- library for manipulating UML 2.0 models.
On Sun, May 21, 2006 at 09:51:52AM +0200, Victor Seva wrote:
> * Package name: libnuml-cil
> Version : 2.0.0
Please close this bug or merge it with #368292.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Bug#368266: ITP: stardict-xmlittre -- Littré dictionary for Stardict
On Sat, May 20, 2006 at 06:02:36PM -0500, Itay Ben-Yaacov wrote: > * Package name: stardict-xmlittre > Version : 2.4.2 > Upstream Author : François Gannaz <[EMAIL PROTECTED]> > * URL : http://francois.gannaz.free.fr/Littre/horsligne.php > * License : GPL > Programming Lang: None. > Description : Littré dictionary for Stardict > > (Include the long description here.) Please provide a long description. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
Bug#531040: ITP: xvidcore -- High quality ISO MPEG4 ASP codec library
On Fri, May 29, 2009 at 02:18:00PM +0200, Loïc Martin wrote:
>License is GPL2+, except for 2 files (src/dct/{fdct.c,idct.c} ) which are
>GPL2+, but with the additionnal note:
>
>> Permission is hereby granted to use, copy, modify, and distribute this
>>software (or portions thereof) for any purpose, without fee, subject to
>> these
>>conditions:
>>(1) If any part of the source code for this software is distributed, then
>> this
>>README file must be included, with this copyright and no-warranty notice
>>unaltered; and any additions, deletions, or changes to the original files
>>must be clearly indicated in accompanying documentation.
>>(2) If only executable code is distributed, then the accompanying
>>documentation must state that "this software is based in part on the work
>> of
>>the Independent JPEG Group".
>>(3) Permission for use of this software is granted only if the user
>> accepts
>>full responsibility for any undesirable consequences; the authors accept
>>NO LIABILITY for damages of any kind.
How is that compatible with the rest of the code? Clearly the whole library
would not be GPL2+ if there are additional restrictions.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 11:03:41AM +0100, Steve Langasek wrote: > On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote: > > * Package name: libposix > > Why? > > This is a subset of the interfaces provided by glibc, which must be present > on all systems. So it would be stupid for any package in Debian to link > against libposix instead of just using libc. Why do we want a library in > Debian that no packages should depend on? Just see it as dash vs. bash. Once libposix reaches maturity, I will certainly consider linking applications I wrote myself against libposix. Applications linked against it will probably use less memory and cannot inadvertently use glibc extensions. This will make it easier to port those applications, and will also make it easier to run things on embedded platforms. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote: > Is libposix complete enough to link against for real programs yet? If > not, why should it be included at this time? I agree that if the only thing that works at this moment is the simplest "Hello world" program, that it should not be packaged yet. > Moreover, can libposix and libc coexist in the same address space? What address space are you talking about? There is also dietlibc and uClibc, who can coexist with glibc. But applications can only link against one of them at the time of course. > If not, all of debian's existing libraries will be incompatible with it. > It seems like the sort of thing that you might want to build an entire > distro against, or a custom/development build against, but not just > some programs in a distro... Having a glibc replacement for just a few programs is not an argument in itself for not including this package. Perhaps I want to develop a program that needs to run in an embedded environment that I want to test? Then I'd like to have a libposix-dev package that I can use to build my own software with. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote: > > Once libposix reaches maturity, I will certainly consider linking > > applications I wrote myself against libposix. Applications linked against > > it will probably use less memory > > Why would they use less memory? Since they don't link against a large library. Granted, that is only a benefit if all running programs link against libposix instead of glibc. > > and cannot inadvertently use glibc extensions. > > So instead you get to reimplement all the extensions you need, in the name > of "portability"? Yes, if that is what it takes for my application to work on platforms that do not have glibc. > > and will also make it easier to run things on embedded platforms. > > Why does this make anything easier? If you're rebuilding your whole system > against libposix, you're not doing that in the archive, so packaging > libposix seems largely irrelevant to this; if you aren't rebuilding your > whole system against libposix, you get two libcs, so that's hardly a win for > embedded systems. If I'm compiling I'd rather do it on a fast desktop with all my usual stuff installed than on an embedded system. > If there are to be embedded environments that will use libposix, then that's > an argument for packaging it - but since these environments don't exist > today, it seems premature to me to put the package in Debian. Are there any > use cases for this that are both non-theoretical and non-crackful? Although I disagree with your other reasons for not including this library in Debian, I agree that it shouldn't be packaged yet since it is quite unusable in this stage :) -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 06:33:44PM -0400, Bryan Donlan wrote: > >> Why would they use less memory? > > > > Since they don't link against a large library. Granted, that is only a > > benefit > > if all running programs link against libposix instead of glibc. > > What makes you think libposix will be smaller? It is currently very > incomplete; by the time it reaches a full implementation of POSIX, it > may well be the same size as libc. Glibc implements much more than just POSIX, and it is not known for its leanness, hence the existence of dietlibc, uClibc, etc. > > If I'm compiling I'd rather do it on a fast desktop with all my usual stuff > > installed than on an embedded system. > > Again, this is what a cross-compile toolchain is for (mandatory if > your embedded platform is anything other than your desktop arch!). You > could adapt the crosstool buildscripts that uclibc uses, for example. > If you just use debian's normal GCC, you're going to have a hell of a > time convincing it to not use libc's include files/statically-linked > startup objects/dynamic linker. That's true. Probably something the upstream maintainer should consider to provide. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
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
Bug#485553: 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
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
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
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
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
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
Bug#492727: ITP: uuidm -- Universally unique identifiers for OCaml
On Mon, Jul 28, 2008, Sylvain Le Gall wrote: > uuidm is the name of the source package. libuuidm-ocaml-dev is the > name of the binary package as per OCaml Policy. Perhaps it is better to also include "ocaml" in the source package name. There are a lot of languages, and they probably all have module/library/component for generating hashes and unique identifiers. To avoid possible conflicts in the source package name space, make your source package identifier unique as well ;) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
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
Bug#492875: 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
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
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
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
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
Bug#494738: ITP: mtpsync -- Syncronize files/music with a MTP device
On Mon, Aug 11, 2008 at 05:31:32PM -0300, Leandro Lucarella wrote: > * Package name: mtpsync [...] > Description : Syncronize files/music with a MTP device > > MTPSync is used to syncronize files/music with a MTP device (as supported > by libmtp) Please expand the acronym MTP at least once. Also, syncronise is spelled wrong, it should be synchronise. > * Syncronising Zencasts What is a Zencast? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
Bug#499537: ITP: iw -- tool for configuring Linux wireless devices
On Sat, Sep 20, 2008 at 01:06:06AM +1000, Kel Modderman wrote: > * Package name: iw > Description : tool for configuring Linux wireless devices Is this going to replace wireless-tools, or is it to be used in conjuction with wireless-tools? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
Bug#499537: ITP: iw -- tool for configuring Linux wireless devices
On Wed, Sep 24, 2008 at 07:05:20AM +1000, Kel Modderman wrote: > > > * Package name: iw > > > Description : tool for configuring Linux wireless devices > > > > Is this going to replace wireless-tools, or is it to be used in conjuction > > with > > wireless-tools? > > As I understand it, it would ultimately supercede wireless tools, but there > would be an extremely long overlap period. During which time, I have no idea > how they will co-operate, do you? No :) > You are the maintainer of wireless-tools, would you like to help with or have > iw? Well, I don't have any hardware that works with software drivers (yet), so it would be very hard for me to test iw. But I would like to work together to make sure there are no conflicts between the two tools, and perhaps to merge functionality where it can and should be merged. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
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
Bug#441303: 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
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
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
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
Bug#446790: 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
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
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
Bug#456519: ITP: pystock -- watch Chinese stock stats
On Sun, Dec 16, 2007 at 09:12:48PM +0800, LI Daobing wrote: > > >Package name: pystock [...] > > 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. > > > 1. I will talk about with upstream about the package name. > 2. the final description is as below[1], please help check whether > it's clear enough. > [1] > Description: Chinese stock realtime information > Show the selected stock's realtime information in a GTK Window. All > stocks in Shanghai Stock Exchange and Shenzhen Stock Exchange can be > selected. That looks good. > . > The interface is in Simplified Chinese and not sensible with locale. That is also very useful to know. > . > Author: yetist <[EMAIL PROTECTED]> The author should not be mentioned in the long description. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#456519: ITP: pystock -- watch Chinese stock stats
On Sun, Dec 16, 2007 at 09:28:58PM +0800, LI Daobing wrote: > > > Author: yetist <[EMAIL PROTECTED]> > > > > The author should not be mentioned in the long description. > > > Hmmm, some other packages also put author in description (e.g. > zh-autoconvert). > > Why It should not be put here? The Debian policy only mentions this about the long description: "The extended description should describe what the package does and how it relates to the rest of the system (in terms of, for example, which subsystem it is which part of)." Of course, it does not forbid including the name of the author. But maybe it is better to include a Homepage: field in the debian/control file, that way people who want to know more about a package than just a description of what it does can find out much more information, including the name of the author. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#456456: ITP: unperish -- release and build free software projects
On Sun, Dec 16, 2007 at 07:32:56PM +, Lars Wirzenius wrote: > > How does unperish make life easier than "make dist" and "debuild"? This > > is unclear if you only look at the description. > > You're right, I shall elaborate: > > Unperish takes care of all the repetitive, mechanical steps of releasing > and building a free software project. Starting from files committed to a > version control system (Bazaar, Subversion), it can create the upstream Perhaps you should add "in on go," or "with one command," here. > tarball (foo-1.2.tar.gz) and the Debian source package > (.orig.tar.gz, .dsc, .diff.gz), then build the binary package using > pbuilder, check the result with lintian, linda, and piuparts, and put > the results in an apt repository using reprepro (assuming everything is > OK). Further, it is built around a plugin architecture, making > automation of further steps easy. > > Does that sound like a better description? Much better, thanks! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#456519: ITP: pystock -- watch Chinese stock stats
On Sun, Dec 16, 2007 at 09:31:41PM +0800, LI Daobing wrote: > you can use 'dget > http://mentors.debian.net/debian/pool/main/p/pystock/pystock_0.2-1.dsc' > to download the source package, please help check it, thanks. It looks fine! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
On Mon, Dec 17, 2007 at 10:42:46PM +0100, Toni Mueller wrote: > * Package name: tcpwatch [...] > Description : tcpwatch is a recorder for HTTP requests in Python > > tcpwatch is a HTTP traffic monitoring program and proxy in Python. This > program allows recording of HTTP requests by being used as a proxy > server. It writes out the requests sent to a file. This program is > recommended by funkload, as it is required for funkload's recording > option to work. A few things: why is it called "tcpwatch" when it only watches HTTP requests? A better name would be "httpwatch". Also, the fact that it is written in Python doesn't really matter. You should not mention it in the short description, and it has not much use in the long description either. The tag system is a better way to indicate that this program is written in Python. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
On Tue, Dec 18, 2007 at 12:21:25AM +0100, Toni Mueller wrote: > > A few things: why is it called "tcpwatch" when it only watches HTTP > > requests? A better name would be "httpwatch". > > it's named that way by upstream. I want to keep confusion to a minimum > and don't see much benefit in renaming it, esp. as it is called that > way in all the literature. No need to make Debian different only > because we can, imho. "Iceweasel" and friends cause sufficient > confusion already (although this is a different case). Of course, but maybe you can talk to upstream about the name? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
On Fri, Dec 21, 2007 at 02:28:28PM +, Gerrit Pape wrote: > qmail is meant as a replacement for the entire sendmail-binmail system > on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and > BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements. [...] This is not a proper ITP. You only mention where to find documentation on system with a supposedly already installed qmail. To file a proper ITP, make sure you've read the policy manual about what to put in the short and long description of a package, and do: aptitude install reportbug reportbug wnpp And select 1. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#457695: ITP: kissdx -- kissdx is a PC-Link clone for KiSS media players
On Mon, Dec 24, 2007 at 04:38:13PM +0100, Pjotr Kourzanov wrote: > Package: wnpp > Severity: wishlist > Owner: Pjotr Kourzanov <[EMAIL PROTECTED]> > > * Package name: kissdx > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ > * License : (GPL, LGPL, BSD, MIT/X, etc.) > Programming Lang: (C, C++, C#, Perl, Python, etc.) Please fill in the real version, upstream author, url, license and programming language. > Description : kissdx is a PC-Link clone for KiSS media players > > kissdx is a PC-Link clone for KiSS media players, based for the > most part on kissd (which it now replaces), with added features > for media playback, management, flexibility and more. Please explain in the long description what a "PC-Link clone" does and what a KiSS media player is (I had to google to find out it is some kind of set top box to view movies, not a Kisekae Set System viewer). -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon
On Wed, Feb 03, 2010 at 10:37:08AM +0100, Tollef Fog Heen wrote:
> ]] Tourneur Henry-Nicolas
>
> | * License : No license, only a copyright file
>
> Surely that makes it illegal for us to distribute?
Actually, it does have a license, which is in the COPYING file and at the top
of all the source code files:
Permission to use, copy, modify, and distribute this software for
any purpose and without fee is hereby granted, provided that this
copyright and permission notice appear on all copies of the
software and supporting documentation, the name of Cisco Systems,
Inc. not be used in advertising or publicity pertaining to
distribution of the program without specific prior permission, and
notice be given in supporting documentation that modification,
copying and distribution is by permission of Cisco Systems, Inc.
I think this can be distributed in the non-free section?
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon
On Wed, Feb 03, 2010 at 11:06:28AM +0100, Henry-Nicolas Tourneur wrote: > > | * License : No license, only a copyright file > > > > Surely that makes it illegal for us to distribute? > > > Yeah but what Craig Small said on mentors is that looks very much like a MIT > license - see COPYING file. > His mail is here : > http://lists.debian.org/debian-mentors/2010/02/msg00027.html But, that's still a license. But look carefully, it says "without fee" in the license. I don't know if that means "you can use it without paying anyone" or "you can only redistribute it if you don't charge anyone". > So it's more some kind of errors from my side because that wasn't very > clear. > Should I update this bug to put MIT-like as license ? It's better to include the whole license if it isn't exactly equal to a standard license. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
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
Bug#429752: O: libraw1394 -- library for direct access to IEEE 1394 bus (aka FireWire)
owner 429752 ! retitle 429752 ITA: libraw1394 -- library for direct access to IEEE 1394 bus (aka FireWire) thanks I'll adopt this package. I will upload with a new Maintainer field as soon as there are bugs to fix or when there is a new upstream version. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#374534: New package of space simulator Celestia - please accept my improvements
On Mon, Jun 25, 2007 at 11:53:19PM +0300, Mantas Kriaučiūnas wrote: > I've noticed, that wonderfull space simulation software - Celestia is > very old in Ubuntu and Debian (look at https://bugs.launchpad.net/bugs/53491 ) > I've noticed, that some people from Debian and Ubuntu are working on new > package, but at this moment there are no stable packages of celestia > 1.4.x, look at http://bugs.debian.org/374534 for more info. > > Luckily I found Christophe Teyssier's packages at > http://epicycle.free.fr/ubuntu/ > As these packages still have several bugs I fixed them and uploaded > fixed .diff.gz and packages for Ubuntu 6.10 to > ftp://ftp.akl.lt/Linux/Baltix/Baltix-Ubuntu-packages/edgy/celestia > > Christophe, and Debian/Ubuntu developers, please add my improvements to > your builds, here is list of my improvements: [...] Thanks, I already implemented some of those improvements myself, but will add the rest as well. I did try to upload celestia to Debian unstable a while ago, but was blocked by the ftpmasters because of possible copyright issues. I think I clarified the debian/copyright file a lot, and will upload it again soon, if it is blocked again then it may have to go into non-free. If anyone is interested in the discussion I had with the ftpmaster, I can forward you the emails. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#410655: ITP: qtpfsgui - GUI to work with HDR images
Hello, What is the status of this ITP? If you don't have time to work at it at the moment, I can package it, and you can take over later if you want. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
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
Bug#575953: ITP: gmock -- Google's framework for writing and using C++ mock classes
On Tue, Mar 30, 2010 at 08:51:04PM +0200, Fredrik Hallenberg wrote:
> * License : Google (SEE BELOW)
That's just the BSD license, with s/Regents of the University of
California/Google/.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Bug#584579: ITP: wikkid -- Bazaar-backed wiki implementation
On Fri, Jun 04, 2010 at 08:43:18PM +0200, Jelmer Vernooij wrote: > * Package name: wikkid > > A wiki that is backed by Bazaar that allows local branching of the wiki > for later merging. It doesn't have any page locks and uses Bazaar's three > way merging. Sounds like ikiwiki. If there is a significant overlap in the features of both projects, perhaps you should inform the upstream maintainers so they can work together? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: Digital signature
Bug#129176: ITP: trophy -- A 2D car racing action game.
package: wnpp severity: wishlist Description: 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. It was downloaded from: http://trophy.sourceforge.net/ Upstream Author(s): Andrew Mustun Copyright: GPL version 2, see /usr/share/common-licenses/GPL. I have already packaged trophy (see ftp://sliepen.warande.net/pub/trophy/), but I'm getting it up to date with the latest clanlib packages (which will be uploaded in a few days as I've been told) and merging it with Andreas Tille's trophy package (http://auric.debian.org/~tille/dists/test/). -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]>
Bug#129699: ITP: race -- A 3D arcade overhead car game.
package: wnpp severity: wishlist Description: Race is a 3D racing game where you compete against computer oponents. The objective is to finish first. The setting is mostly off-road. This package contains the game and the graphics. Due to licensing issues the soundtrack cannot be included in Debian, unless I put both the GPL part and the soundtrack in one single package in non-free. The license for the soundtrack explicitly does NOT allow me to distribute it seperately of the actual game. It was downloaded from http://race.sourceforge.net/ Upstream Authors: Race development team <[EMAIL PROTECTED]> Copyright: GPL version 2, see /usr/share/common-licenses/GPL. You can find packages at ftp://sliepen.warande.net/pub/race/. I will upload it when the new clanlib packages enter unstable. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgpe3x2QTGYDr.pgp Description: PGP signature
Bug#129699: ITP: race -- A 3D arcade overhead car game.
On Fri, Jan 18, 2002 at 10:27:55AM +0100, Tille, Andreas wrote: > > This package contains the game and the graphics. Due to licensing > I'd strongly suggest to split the architecture independend data part from > the package to race-common to avoid bloating the Debian archive. > Please raise up hands if you need a patch for this. Good point, I'll do this for race, trophy and maybe crawl and omega-rpg as well. > > issues the soundtrack cannot be included in Debian, unless I put both > > the GPL part and the soundtrack in one single package in non-free. The > > license for the soundtrack explicitly does NOT allow me to distribute > > it seperately of the actual game. > I would see no problems with the license if you would make a separate > package race-sound in non-free which *depends* from race which imlies > that you downloaded tha race game before. But I'm no license expet. I too am no lawyer, so I'm not going to put effort in this. Besides, the music is not my taste :). > > You can find packages at ftp://sliepen.warande.net/pub/race/. I will > > upload it when the new clanlib packages enter unstable. > You should use versioned dependency from the ClanLib packages, IMHO. Hm well the clanlib packagers don't think it's necessary... > Thanks for your effort, Guus. I suggest to include Race into > Debian-Jr. Ok, if there is anything special that needs to be done for Debian-Jr, please tell me. (After hearing the soundtrack I think it wouldn't be suitable for Debian-Jr anyway.) -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgp7D8dPKDuOf.pgp Description: PGP signature
Bug#129699: ITP: race -- A 3D arcade overhead car game.
On Fri, Jan 18, 2002 at 02:05:48PM +0100, Tille, Andreas wrote: > > Good point, I'll do this for race, trophy and maybe crawl and omega-rpg > > as well. > If I should resend you my preliminary stuff for race please tell me soon If you don't mind I'd like to figure it out myself. > ... but I've seen you just found it and used the icons :). I want to > add that I wanted to use a > convert debian/trophy.xpm `pwd`/debian/trophy/usr/share/pixmaps/trophy.png > to have a png file in /usr/share/pixmaps which is more compact. Unfortunately > the build stuff does not support binary diffs and so the image has to be > included as xpm in the source. I noticed, but I removed the convert command from the rules file because you'd need a build-dep on imagemagick for this one pixmap. The xpm is not that big, every program can use it, and the only reason to use pngs is truecolour support. > > I too am no lawyer, so I'm not going to put effort in this. Besides, the > > music is not my taste :). > I personally do not care about music and I have to admit that I mostly > switch it off (by software or by just removing the power connector of > the speakers ;-). But it was just an idea for those who might like it ... > It wouldn't be a real problem for me if there wouldn't be any sound. I'll ask the band that wrote the music about it. > Perhaps we build a further package junior-race? > > > (After hearing the soundtrack I think it wouldn't be > > suitable for Debian-Jr anyway.) > Well than it would go this way: > > junior-race > > Depends: trophy, race > Suggests: tuxracer ## only suggets, because it needs 3D support > Conflicts: race-sound ## if there would really be a race-sound Ok, I'll keep this in mind. BTW, race also needs 3D support. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgpG5o4PiQUg0.pgp Description: PGP signature
Bug#140848: ITP: rocks -- Make network sockets reliable in a transparent way
Package: wnpp Version: N/A; reported 2002-04-02 Severity: wishlist * Package name: rocks Version : 2.1 Upstream Author : Victor C. Zandy <[EMAIL PROTECTED]> * URL : http://www.cs.wisc.edu/~zandy/rocks/ * License : LGPL Description : Make network sockets reliable in a transparent way 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. You can find the package at ftp://sliepen.warande.net/pub/rocks/. I'd like to hear if this is the best way to package it. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux haplo 2.5.3 #2 do jan 31 13:12:25 CET 2002 i686 Locale: LANG=nl_NL, LC_CTYPE=nl_NL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#148076: ITP: schedutils -- Linux scheduler utilities
Package: wnpp Version: N/A; reported 2002-05-24 Severity: wishlist * Package name: schedutils Version : 0.0.5 Upstream Author : Robert Love <[EMAIL PROTECTED]> * URL : http://tech9.net/rml/ * License : GPL Description : Linux scheduler utilities These are the Linux scheduler utilities - schedutils for short. These programs take advantage of the scheduler family of syscalls that Linux implements across various kernels. These system calls implement interfaces for scheduler-related parameters such as CPU affinity and real-time attributes. The standard UNIX utilities do not provide support for these interfaces -- thus this package. The programs that are included in this package are taskset, irqset, lsrt, and rt. Together with nice and renice (not included), they allow full control of process scheduling parameters. Suggestions for related utilities are welcome, although it is believed (barring new interfaces) that all scheduling interfaces are covered. Package already prepared, you can find them at: ftp://sliepen.warande.net/pub/schedutils/ -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux haplo 2.5.3 #2 do jan 31 13:12:25 CET 2002 i686 Locale: LANG=nl_NL, LC_CTYPE=nl_NL -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149611: ITP: powerprefs -- Configurationtool for pbbuttonsd
On Tue, Jun 11, 2002 at 12:18:20AM +0200, Guus Sliepen wrote: > > * Package name: powerprefs > > Version : 0.2.1 > > Upstream Author : Matthias Grimm <[EMAIL PROTECTED]> > > * URL : > > http://www.cymes.de/members/joker/projects/pbbuttons/pbbuttons.html > > Why is the package name different from upstream's project name? Oops, ignore my question. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgpr8j0CE0ddS.pgp Description: PGP signature
Bug#149611: ITP: powerprefs -- Configurationtool for pbbuttonsd
On Mon, Jun 10, 2002 at 11:25:16PM +0200, Jan-Hendrik Palic wrote: > * Package name: powerprefs > Version : 0.2.1 > Upstream Author : Matthias Grimm <[EMAIL PROTECTED]> > * URL : > http://www.cymes.de/members/joker/projects/pbbuttons/pbbuttons.html Why is the package name different from upstream's project name? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgp7sS8A7cxQo.pgp Description: PGP signature
Bug#150706: ITP: dhis -- Dynamic Host Information System
Package: wnpp Version: N/A; reported 2002-06-22 Severity: wishlist * Package name: dhis-server, dhis-client, dhis-dns-engine, dhis-mx-sendmail-engine, dhis-tools-dns Version : 5.x Upstream Author : Joao Cabral <[EMAIL PROTECTED]> * URL : http://www.dhis.org/dhis/r5/ * License : BSD Description : Dynamic Host Information System DHIS is a client-server architecture meant to update databases for systems which are assigned a dynamic IP[v4] address. By the means of a DHIS client a host which is assigned a dynamic IP address (either from its ISP or from DHCP) is able to communicate with a DHIS server in order to advertise its newly acquired IP address. The packages can be found at: ftp://ftp.sliepen.eu.org/pub/dhis/ -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux haplo 2.5.24-v4l2 #2 Fri Jun 21 18:16:02 CEST 2002 i686 Locale: LANG=nl_NL, LC_CTYPE=nl_NL -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#150706: ITP: dhis -- Dynamic Host Information System
On Sat, Jun 22, 2002 at 04:16:25PM +0200, Luca - De Whiskey's - De Vitis wrote: > On Sat, Jun 22, 2002 at 02:58:24PM +0200, Guus Sliepen wrote: > > Package: wnpp > > Version: N/A; reported 2002-06-22 > > Severity: wishlist > > > > * Package name: dhis-server, dhis-client, dhis-dns-engine, > > dhis-mx-sendmail-engine, dhis-tools-dns > > Version : 5.x > > Upstream Author : Joao Cabral <[EMAIL PROTECTED]> > > * URL : http://www.dhis.org/dhis/r5/ > > Package: dhid > Maintainer: Manuel Estrada Sainz <[EMAIL PROTECTED]> > Description: Dynamic Host Information System (DHIS) client > > copyright file says: > > It was downloaded from ftp://ftp.dhis.org/pub/dhis/dhid-4.0.1.tar.gz > > Upstream Author: Joao Cabral ([EMAIL PROTECTED]) > > What's about it? Aarg! I searched everything for instances of "dhis*", but I totally failed to notice that package... Thanks for telling me :) Manuel, I tried to package the complete DHIS suite in a uniform way. You only packaged the client. If you want I can take over your package, if not I can drop dhis-client, but then I'd like to see a version 5.1 client. Please let me know what you think, -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgpj0R8dSX0dW.pgp Description: PGP signature
Bug#150706: ITP: dhis -- Dynamic Host Information System
On Sat, Jun 22, 2002 at 06:18:21PM +0200, Manuel Estrada Sainz wrote: > Go ahead, take it over. Just two things: > - Please try to recycle as much of my work as you find > appropriate. I will. > - Make a dummy dhid package depending on dhis-client and try to > make the transition as painless as posible for users. Ok. > For now a couple of comments: > - Does it really make sense to make a directory under /etc/ to > put a single file in it? > If so, you will have to move dhid's configuration file > from /etc/dhid.conf to /etc/dhis-client/dhid.conf on > the > postinst or tell the user to do so via debconf. No, it doesn't make sense. I will move it to /etc. > - My dhid package includes genkeys as 'dhis_genkeys' which I > think is usefull for users. > I even wrote a manpage for it. dhis-tools-dns contains all the pass and key generation utilities. > - On README.Debian I explain where to go to get a service > provider, how to generate the QRC keys and how to upgrade > from > older versions. Most is extracted from the README, but it is > adapted to the way the package is done and I think that a > little bit clearer. > - My dhid package warns the user about old configuration files > via debconf. I'll incorporate that in the dhis-client package. Thanks! -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgpTQTA7rx1oW.pgp Description: PGP signature
Bug#150706: ITP: dhis -- Dynamic Host Information System
On Sat, Jun 22, 2002 at 06:44:23PM +0200, Manuel Estrada Sainz wrote:
> I forgot, if you need help on doing the transition or anything, just
> say so.
What would be the best way to create a dummy dhid package?
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
pgpKozkIstyA0.pgp
Description: PGP signature
Bug#150706: ITP: dhis -- Dynamic Host Information System
On Sat, Jun 22, 2002 at 06:18:21PM +0200, Manuel Estrada Sainz wrote:
> - Make a dummy dhid package depending on dhis-client and try to
> make the transition as painless as posible for users.
I made dhis-client conflict, depend and provide dhid. Could you verify
that the latest (5.1-3, uploaded a few moments ago) is good enough for
people still using dhid to use instead?
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
pgpPmytf1CqT9.pgp
Description: PGP signature
Bug#157433: RFA: ifenslave -- Attach and detach slave interfaces to a bonding device.
Package: wnpp Version: N/A; reported 2002-08-20 Severity: normal I request an adopter for the ifenslave package. The package description is: This is a tool to attach and detach slave network interfaces to a bonding device. A bonding device will act like a normal Ethernet network device to the kernel, but will send out the packets via the slave devices using a simple round-robin scheduler. This allows for simple load-balancing, identical to "channel bonding" or "trunking" techniques used in switches. . The kernel must have support for bonding devices for ifenslave to be useful. The problem is that ifenslave depends on kernel headers. I'd like someone more experienced with working with kernel headers to take over this package. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux haplo 2.4.19-ac4 #1 Tue Aug 6 09:51:40 CEST 2002 i686 Locale: LANG=nl_NL, LC_CTYPE=nl_NL -- no debconf information
Bug#96694: Status?
On Sun, Aug 25, 2002 at 10:33:18PM +0100, Jonathan Amery wrote: > How's the packaging going? It's not. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96694&msg=16&repeatmerged=yes -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> pgpObJDRBUb7n.pgp Description: PGP signature
Bug#192416: ITP: rsh-redone -- Reimplementation of remote shell tools.
Package: wnpp Version: unavailable; reported 2003-05-08 Severity: wishlist * Package name: rsh-redone Version : 51 Upstream Author : Guus Sliepen <[EMAIL PROTECTED]> * URL : ftp://sliepen.eu.org/pub/rsh-redone/ * License : GPL Description : Reimplementation of remote shell tools. Rsh-redone is a reimplementation of the remote shell clients and servers. It is written from the ground up to avoid the bugs found in the standard clients and servers. It also fully supports IPv6. The rsh-redone-server package contains rshd and rlogind and completely replaces the rsh-server package (from netkit). The rsh-redone-client package contains rsh and rlogin and can coexist with the existing rsh-client package (which might still be needed for rcp). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux haplo 2.4.20 #1 Sun Dec 1 14:03:28 CET 2002 i686 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (ignored: LC_ALL set)
Bug#96694: ITP: majordomo
Package: wnpp Severity: wishlist I plan to package Majordomo version 2. It is the succesor of the widely known Majordomo 1.94.5 mailing list manager, which is not in Debian because the license is not DFSG complaint. However, I checked out the CVS version of Majordomo 2 and they have radically changed their license. It is now DFSG compliant: Copyright (c) 1997, 1998 Jason Tibbitts for The Majordomo Development Group. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the Majordomo Development Group for use in the Majordomo 2 project (http://www.hpc.uh.edu/majordomo/)." 4. The names "Majordomo", "Majordomo 2", "Bouncefilter", and "Majordomo Development Group" must not be used to endorse or promote products derived from this software without prior written permission. 5. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the Majordomo Development Group for use in the Majordomo 2 project (http://www.hpc.uh.edu/majordomo/)." THIS SOFTWARE IS PROVIDED BY THE MAJORDOMO DEVELOPMENT GROUP ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE MAJORDOMO DEVELOPMENT GROUP OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. === This software consists of voluntary contributions made by many individuals on behalf of the Majordomo Development Group. The CREDITS file is intended to contain a complete list of all contributors; please report any omissions. [ Note that this license is a slightly modified version of the Apache (http://www.apache.org) license, used by permission. ] pgpQniWkQqhyR.pgp Description: PGP signature
Bug#96694: Location of upstream source
I'm sorry, I forgot to mention that you can find the homepage of majordomo with instructions to download the CVS version at: http://www.hpc.uh.edu/majordomo/#mj2 Snapshots of the new majordomo version can be found at: ftp://ftp.hub.org/pub/Majordomo2/ --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- pgpNyliP7b0Hb.pgp Description: PGP signature
Bug#96694: ITP: majordomo
On Tue, May 08, 2001 at 01:54:39AM +0200, Adrian Bunk wrote: > > I thought it was removed from Debian because it had so many security > > flaws. > > AFAIR it was removed at the end of the potato freeze because it had a > known security hole with a known fix but upstream didn't release a new > version and the old copyright did forbit the distribution of modified > binaries. The new licence as quoted in the last mail doesn't seem to have > this problem (although I think it doesn't comply to the DFSG because it's > a licence in the style of the old BSD licence _with_ the advertising > clause). Which clause of the DFSG prohibits that? --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- pgpSzMhFWNvD6.pgp Description: PGP signature
