Re: Determining a .deb's intended Debian Version
Christopher Crammond <[EMAIL PROTECTED]> writes: > I was wondering if someone could provide me with some additional > information related to Debian packaging. Specifically, I would like to > know if there is a way to determine which version of Debian that a > package belongs to? No. Almost all packages in stable have been uploaded to unstable, were migrated to testing and then were released as stable. We would have to do new uploads for each of these transitions to keep such a field updated. Why do you need it, anyway? Marc -- BOFH #408: Computers under water due to SYN flooding. pgp3zqAdUjZKv.pgp Description: PGP signature
Linup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As there is no linup anymore I plan to take over this package on my private debian ftp. Is there anyone who has the last source package? On snapshoot.debian.net the relevant dir are not readable. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ3MXtp+OKpjRpO3lAQL7xAf+PlyHOp6SA/6ny/vi972+ofuhONHYMn9x e6O5UKquMUtR81eU91CHEfKRqazr06HbzwQBB5TZj8Uul/YacpswM3XDu362zqqU W+nB6JMxyps08LlxfJuoDBi6/8G9mTUZ4dBKL5JpPP/NWsVpmjIv30XCp+NjUY76 wEH2Oyx1uJUNH/FVpW5vBiSWNFGHKGS+km67BSWoQdYzIFEr1kYAb+pKGBHIyLIi VYxLMv7JfGajd6a6OqsAxps0G7dbLjSBLsCIXctm7iKHOy+F+IYp3Siv9GWcld/G rL+Tdabt4M4rFLjigViPtucnbW0CC7p/xSeL5nBzt/SkDSrZ8iI/jA== =t4N4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Determining a .deb's intended Debian Version
In article <[EMAIL PROTECTED]> you wrote:
> I was wondering if someone could provide me with some additional
> information related to Debian packaging. Specifically, I would like to
> know if there is a way to determine which version of Debian that a
> package belongs to?
You can check if it belongs currently to a version bymeans of the signed
package file.
http://ftp.de.debian.org/debian/dists/Debian3.1r0/Release{,.gpg}
is the release file with the associated signature, which lists the md5sums
of the package files. And the package files list the version of the packages
and the checksum of the archive file in:
http://ftp.de.debian.org/debian/dists/Debian3.1r0/main/binary-i386/Packages
Gruss
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338382: ITP: python-formencode -- FormEncode is a validation and form generation package.
On 09/11/2005 Bob Tanner wrote: > Package: wnpp > Severity: wishlist > Owner: Bob Tanner <[EMAIL PROTECTED]> > > > * Package name: python-formencode > Version : 0.2.2 > Upstream Author : Ian Bicking <[EMAIL PROTECTED]> > * URL : http://formencode.sf.net > * License : PSF > Description : FormEncode is a validation and form generation package. > > The validation can be used separately from the form generation. The validation > works on compound data structures, with all parts being nestable. It is > separate > from HTTP or any other input mechanism. it would be better to mention, what FormEncode actually validates. I guess it validates and generates HTML code, but it is not clear from the description. also, PSF doesn't seem to be a license, but more an acronym for "Python Software Foundation". after reading the Python License, i'm even not sure whether it is possible to license third-party software under it, as it seems to talk about the PSF all the time, and that doesn't apply for software which is not copyrighted by the PSF, am i correct here? ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338463: ITP: squirrelmail-decode -- Extra decoding routines for complex character sets
Package: wnpp Severity: wishlist Owner: Thijs Kinkhorst <[EMAIL PROTECTED]> * Package name: squirrelmail-decode Version : 1.0 Upstream Author : SquirrelMail Project Team * URL : http://www.squirrelmail.org/ * License : GPL Description : Extra decoding routines for complex character sets SquirrelMail decoding functions are used to display and convert messages encoded in different character sets. This extra decoding library provides support for some complex Eastern character sets and some rarely used Apple character sets. The current release supports Big5, Windows-874 (cp874, Thai), Windows-949 (UHC, Korean), EUC-CN, EUC-JP, EUC-KR, EUC-TW, GB18030, GB2312, ISO-2022-CN, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-KR, Shift_JIS and various x-mac-* character sets. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On 10/29/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > On 10/25/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > On 10/24/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > > On Mon, Oct 24, 2005 at 02:21:04PM +0200, Olaf van der Spek wrote: > > > > I'm afraid I have to ask the same question again (three months later). > > > > What's the status of this package in general and my patch in particular? > > > > There was some discussion about it, but nothing really happened. > > > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=222324 > > > > > > there was no consensus on the patch yet, if i see that correctly. > > > > Ian Jackson did not respond to my last message, but I think you're the > > one that has to decide as you're the (upstream) maintainer. > > Bernd? Bernd?
Re: net-tools maintenance status
On Thu, Nov 10, 2005 at 01:48:27PM +0100, Olaf van der Spek wrote: > On 10/29/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:> On 10/25/05, Olaf > van der Spek <[EMAIL PROTECTED]> wrote:> > On 10/24/05, Bernd Eckenfels > <[EMAIL PROTECTED]> wrote:> > > On Mon, Oct 24, 2005 at 02:21:04PM +0200, > Olaf van der Spek wrote:> > > > I'm afraid I have to ask the same question > again (three months later).> > > > What's the status of this package in > general and my patch in particular?> > > > There was some discussion about > it, but nothing really happened.> > > >> > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=222324> > >> > > there was > no consensus on the patch yet, if i see that correctly.> >> > Ian Jackson did > not respond to my last message, but I think you're the> > one that has to > decide as you're the (upstream) maintainer.>> Bernd? > Bernd? any chance you could get quoting right? this message is totally unreadable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On 11/10/05, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > any chance you could get quoting right? this message is totally > unreadable. Maybe it's caused by lack of support for UTF-8?
Bug#338468: ITP: xglk -- an implementation of the Glk user interface for the X Window System
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: xglk Version : 0.4.11 Upstream Author : Andrew Plotkin <[EMAIL PROTECTED]> * URL : http://www.eblong.com/zarf/glk/ * License : Custom (see below) Description : an implementation of the Glk user interface for the X Window System This library is an implementation of the Glk user interface specification that uses the X Window System, supporting text styles and graphics. . Glk is a cross-platform, portable user interface library specification. It can handle simple graphics but does best at text, which can contain formatting and hyper-links. It is targeted primarily for interactive fiction (text adventure) systems. . The Glk API implemented by this library is 0.6.1. License: XGlk: X Windows Implementation of the Glk API. XGlk Library: version 0.4.11 Glk API which this implements: version 0.6.1. Designed by Andrew Plotkin <[EMAIL PROTECTED]> http://www.eblong.com/zarf/glk/index.html The source code in this package is copyright 1998-9 by Andrew Plotkin. You may copy and distribute it freely, by any means and under any conditions, as long as the code and documentation is not changed. You may also incorporate this code into your own program and distribute that, or modify this code and use and distribute the modified version, as long as you retain a notice in your program or documentation which mentions my name and the URL shown above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338471: ITP: glkterm -- an implementation of the Glk user interface library for terminals
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: glkterm Version : 0.7.8 Upstream Author : Andrew Plotkin <[EMAIL PROTECTED]> * URL : http://www.eblong.com/zarf/glk/ * License : Custom (see below) Description : an implementation of the Glk user interface library for terminals This library is an implementation of the Glk user interface specification that works on a terminal and uses the ncurses library. It supports limited text styles, but no graphics or sound. . Glk is a cross-platform, portable user interface library specification. It can handle simple graphics but does best at text, which can contain formatting and hyper-links. It is targeted primarily for interactive fiction (text adventure) systems. License: GlkTerm: Curses.h Implementation of the Glk API. GlkTerm Library: version 0.7.8. Glk API which this implements: version 0.6.1. Designed by Andrew Plotkin <[EMAIL PROTECTED]> http://www.eblong.com/zarf/glk/index.html The source code in this package is copyright 1998-2000 by Andrew Plotkin. You may copy and distribute it freely, by any means and under any conditions, as long as the code and documentation is not changed. You may also incorporate this code into your own program and distribute that, or modify this code and use and distribute the modified version, as long as you retain a notice in your program or documentation which mentions my name and the URL shown above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338473: ITP: cheapglk -- the most basic implementation of the Glk user interface
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: cheapglk Version : 0.8.7 Upstream Author : Andrew Plotkin <[EMAIL PROTECTED]> * URL : http://www.eblong.com/zarf/glk/ * License : Custom (see below) Description : the most basic implementation of the Glk user interface This library is an implementation of the Glk user interface specification that is as basic as possible. It uses simple stdio streams for input and output and only supports a single window. It supports limited text styles, but no graphics or sound. . Glk is a cross-platform, portable user interface library specification. It can handle simple graphics but does best at text, which can contain formatting and hyper-links. It is targeted primarily for interactive fiction (text adventure) systems. License: CheapGlk: Cheapass Implementation of the Glk API. CheapGlk Library: version 0.8.7. Glk API which this implements: version 0.6.1. Designed by Andrew Plotkin <[EMAIL PROTECTED]> http://www.eblong.com/zarf/glk/index.html The source code in this package is copyright 1998-2000 by Andrew Plotkin. You may copy and distribute it freely, by any means and under any conditions, as long as the code and documentation is not changed. You may also incorporate this code into your own program and distribute that, or modify this code and use and distribute the modified version, as long as you retain a notice in your program or documentation which mentions my name and the URL shown above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New version of kernel-package to create image packages using debconf
Hi, > > it would be convenient if 'vmlinux' is included > > somewhere like /usr/lib/debug/lib/modules/`uname -r`/vmlinux > > (which seems to be the case with RedHat[2]). > > in a separate linux-image-dbg package? > > $ du -h vmlinux arch/i386/boot/bzImage > 19M vmlinux > 884Karch/i386/boot/bzImage I've looked at it; on my system it doesn't make much difference. $ ls -lh vmlinux /boot/vmlinuz-2.6.14 -rw-r--r-- 1 root root 1.8M 2005-11-08 17:37 /boot/vmlinuz-2.6.14 -rwxr-xr-x 1 dancer dancer 7.4M 2005-11-08 17:32 vmlinux and since it's mostly debug data, when it's compressed, it's not much different from vmlinuz: $ ls -lh vmlinux.gz -rwxr-xr-x 1 dancer dancer 2.1M 2005-11-10 22:34 vmlinux.gz My impression is that it won't impact deb package size too much (only double :P ) even if it were included in normal Debian package. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338382: ITP: python-formencode -- FormEncode is a validation and form generation package.
On 10-Nov-05, 05:59 (CST), Jonas Meurer <[EMAIL PROTECTED]> wrote: > also, PSF doesn't seem to be a license, but more an acronym for "Python > Software Foundation". after reading the Python License, i'm even not > sure whether it is possible to license third-party software under it, as > it seems to talk about the PSF all the time, and that doesn't apply for > software which is not copyrighted by the PSF, am i correct here? That's true, the PSF is not suitable for third party modules. The FAQ even says so: "The PSF license was developed specifically and only for Python and its standard libraries." (http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq). It does go on to say how to modify the PSF license, which is mostly 's/PSF/Your Organization/g'. This may be what has been done for formencode. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New version of kernel-package to create image packages using debconf
On Wed, 2005-11-09 at 21:49 +0900, Junichi Uekawa wrote: > I've been pondering on using kernel-package to generate > debug 'vmlinux' images which are used in tools like > kernel crash dump analysis tools and oprofile[1]. I'm totally for a -dbg kernel package with an unstripped kernel for OProfile, as I use it quite frequently. I wanted to use OProfile and get kernel stacks on Ubuntu Breezy, so ended up recompiling the standard kernel for vmlinux. To be useful I needed to turn on DEBUG_INFO and DEBUG_FRAME_POINTERS, and this gave me a 25M vmlinux. I'd expect DEBUG_INFO could be always on as the symbols would be stripped for the production kernel, but I don't think "normal" kernels should have frame pointers. If this is correct, then maybe the debug kernel should be just another build with the debug options on, and no stripping. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Bug#338475: ITP: nitfol -- a Z-machine adventure game interpreter
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: nitfol Version : 0.5 Upstream Author : Evin Robertson <[EMAIL PROTECTED]> * URL : http://www.ifarchive.org/indexes/if-archiveXinfocomXinterpretersXnitfol.html * License : GPL Description : a Z-machine adventure game interpreter Nitfol is an interpreter that will play adventure games written for Infocom's Z-machine standard. It uses the Glk library and is thus highly portable and will run on both X and a terminal. It has limited support for sound and graphics, a built-in Z-code debugger and an automapper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338476: ITP: glulxe -- an adventure game interpreter for the Glulx virtual machine
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: glulxe Version : 0.3.5 Upstream Author : Andrew Plotkin <[EMAIL PROTECTED]> * URL : http://www.eblong.com/zarf/glulx/ * License : Custom (see below) Description : an adventure game interpreter for the Glulx virtual machine Glulxe is an interpreter for the Glulx virtual machine designed for playing interactive fiction (adventure games), similar to the Infocom's Z-machine standard. It uses the Glk library for I/O and is thus highly portable and will run on both X and a terminal. License: Glulxe: the Glulx VM interpreter Version 0.3.5 Designed by Andrew Plotkin <[EMAIL PROTECTED]> http://www.eblong.com/zarf/glulx/index.html The source code in this package is copyright 1999 by Andrew Plotkin. You may copy and distribute it freely, by any means and under any conditions, as long as the code and documentation is not changed. You may also incorporate this code into your own program and distribute that, or modify this code and use and distribute the modified version, as long as you retain a notice in your program or documentation which mentions my name and the URL shown above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New version of kernel-package to create image packages using debconf
On Thu, 2005-11-10 at 22:36 +0900, Junichi Uekawa wrote: > Hi, > > > > it would be convenient if 'vmlinux' is included > > > somewhere like /usr/lib/debug/lib/modules/`uname -r`/vmlinux > > > (which seems to be the case with RedHat[2]). > > > > in a separate linux-image-dbg package? > > > > $ du -h vmlinux arch/i386/boot/bzImage > > 19M vmlinux > > 884Karch/i386/boot/bzImage > > I've looked at it; on my system it doesn't > make much difference. > > $ ls -lh vmlinux /boot/vmlinuz-2.6.14 > -rw-r--r-- 1 root root 1.8M 2005-11-08 17:37 /boot/vmlinuz-2.6.14 > -rwxr-xr-x 1 dancer dancer 7.4M 2005-11-08 17:32 vmlinux It think it is because my kernels have CONFIG_DEBUG_INFO turned on. CONFIG_DEBUG_INFO=y 884K../build-sbc-gx533/arch/i386/boot/bzImage 20M ../build-sbc-gx533/vmlinux CONFIG_DEBUG_INFO=n 884K../build-sbc-gx533/arch/i386/boot/bzImage 2.2M../build-sbc-gx533/vmlinux I don't know how useful all that extra debug info is but it sounds like the sort of stuff which ought to be in a debug image... Anyway, I'm not too fussed, just thought it was worth mentioning. Ian. -- Ian Campbell Current Noise: Iron Maiden - Run To The Hills The world really isn't any worse. It's just that the news coverage is so much better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338477: ITP: glkloader -- a dynamic loading front end for Glk user interface libraries
Package: wnpp Severity: wishlist Owner: Niko Tyni <[EMAIL PROTECTED]> * Package name: glkloader Version : 0.3.2 Upstream Author : Joe Mason <[EMAIL PROTECTED]> * URL : http://www.ifarchive.org/indexes/if-archiveXprogrammingXglkXimplementations.html * License : BSD Description : a dynamic loading front end for Glk user interface libraries Glk is a cross-platform, portable user interface library specification. It can handle simple graphics but does best at text, which can contain formatting and hyper-links. It is targeted primarily for interactive fiction (text adventure) systems. . This library does not provide a real Glk implementation, just a dynamic loading front-end that lets the actual Glk library be chosen at runtime. You need a Glk implementation before this library actually becomes usable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338480: ITP: libtext-simpletable-perl -- Simple Eyecandy ASCII Tables
Package: wnpp Severity: wishlist Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> * Package name: libtext-simpletable-perl Version : 0.02 Upstream Author : Sebastian Riedel, <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~sri/Text-SimpleTable-0.02/ * License : (Perl: Artistic/GPL) Description : Simple Eyecandy ASCII Tables Replacement for Text::ASCIITable module. . If you need to create text tables like . .---+. | foob- | yadayaday- | | arbaz | ada| '---+' . this module is for You. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
On Wednesday 09 November 2005 05:18, Anthony Towns wrote: > For those playing along at home, the CDDL isn't GPL compatible, and > OpenSolaris's libc is CDDL'ed -- so anything GPLed can't link to libc > since that would violate 3(a) [0]. The reason GPL'ed software is okay > for regular Solaris is the "major components" exception, but that only > applies if those components don't "accompan[y] the executable". > [0] Presuming the FSF's claims about dynamic linking hold up in this > case, anyway. I consider a Debian-derived distribution a derived work of the contained Debian tools in more ways than "mere" dynamic linking. To be more specific: I don't believe that the fact that software A is being packaged with Debians tools is a derived work of said tools, but I can't imagine a LiveCD, looking and feeling like a Debian system, which indeed employs said tools and methods by incorporating them source- and binarywise NOT being a derivative work of said tools. But IANAL, so I don't know whether the distinction between "merely aggregated" applications on the System and the System itself holds up. > So there're three fairly simple ways around that issue: > (a) [seperate distribution] > (b) [relicinsing OpenSolaris' libc] > (c) [porting glibc] I'd like to add (d) distributing as source only. Compiling the whole thing on the users system changes the deliverable from "Debian lookalike" to "CD-Image builder". The latter is subtly different by shipping Debians tools not as an integral part of a system but as one of many possible implementations of the various command line interfaces. Of course thusly built ISO images wouldn't be distributable, but IIRC this would be similar to the pine and qmail situation, which also prohibit (modified) binary distribution. On other news, private communication by the gnusolaris.org people lead me to the conviction that they are internally working on resolving their problems with the legalese and we should give them a break. I will keep you informed about their progress. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: net-tools maintenance status
* Christoph Hellwig <[EMAIL PROTECTED]> [2005-11-10 13:51:57 +0100]: > any chance you could get quoting right? this message is totally > unreadable. Came through just fine on my end. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Bug#338503: ITP: cvssuck -- inefficient cvs repository grabber using cvs command
Package: wnpp Severity: wishlist Owner: Piotr Roszatycki <[EMAIL PROTECTED]> * Package name: cvssuck Version : 0.3.cvs20020108 * URL : http://cvs.m17n.org/~akr/cvssuck/ * License : BSD Description : inefficient cvs repository grabber using cvs command CVSsuck is a mirroring tool for CVS repositories. Unlike other tools such as CVSup or rsync, it uses cvs command to access the repository. So, it works well with remote repositories without a special server or shell account. However it is inefficient and not perfect because CVS client/server protocol is not designed for mirroring. If a server provides special way to grab a repository, you shouldn't use CVSsuck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sugarcrm licence issue
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Thu, Nov 10, 2005 at 05:42:07PM +, Matthew Garrett wrote: >> This is based on the contents of their copyright files. Can we please >> stop this "The only code under the MPL is Mozilla" argument? > > It's not an "argument"--nobody is claiming that a license is free or non- > free based on whether or not the license is being used. (I'm a bit > disappointed that you're essentially saying "even if this license is > non-free, you can probably get away with it anyway", though.) The ultimate decision over whether a license is free or not rests with the FTP masters. They can be overruled by a general resolution. The presence of code under the MPL in the main section of the archive suggests (but does not confirm) that the people who actually make the decision believe it to conform to the DFSG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf problem
Hi Joey, thanks for being patient with me. I promise that I'll write this up (for debconf-devel(7) or the developer's reference or whatever you suggest) once we've sorted this out. Joey Hess <[EMAIL PROTECTED]> wrote: >> Does that mean I must use some hackish handmade flags that are reset >> only at the end of the postinst, and thus indicate whether there was a >> postinst run after the last config run? > > No, it means that you're taking the wrong approach to using debconf. > I've been trying to point you at tools that will lead to an appropriate > solution. Ah, I see. > Your package is being converted from a previous version, which did not > use debconf and did have the files, to a version which does use debconf. > So why ask the question on upgrade from this previous version at all? Because it isn't true that the previous version didn't use debconf. It just asked the questions totally differently and took an approach that I now would call flawed. But still it gave the users the impression that their ls-R files' permissions are managed by debconf, and probably many thought they were properly managed and didn't do any manual changes. Now if I just let the system be as it is, I kind of leave these users alone. But maybe you are right and this is the only solution - we could indicate in NEWS.Debian that everybody who wants debconf management should reconfigure the package. But then, why not ask anyway? > The parameters passed to the config script can be used to detect the > upgrade and not ask any questions or populate the debconf database at > all, while leaving debconf asking the question on fresh installs and > when reconfigured. Oh, but that seems very hard to do right: The only way to differentiate between an upgrade and reconfigure seems to be the version number of the last installed version. But since one could install the package noninteractively, but switch to an interactive frontend before an upgrade, I would have to avoid asking questions for *any* last-installed version number older than the current one (if I decide not to ask and act at all upon upgrade). To avoid this, and also detect such upgrades, I have to put the *current* version number into the config script, and only act if the version passed as installed-version is either empty (fresh install), or it matches the hardcoded version current number in the script (reconfigure). And even if I don't forget to update the version number in the config script, what about NMUs? Binary-only NMUs? I hope I'm wrong... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
dueling banjos sheet music
I am looking for the sheet music to the song dueling banjos from the movie deliverance. It's for guitar. Can you tell me where I can find it?
Re: Debconf problem
Frank Küster wrote: > Because it isn't true that the previous version didn't use debconf. It > just asked the questions totally differently and took an approach that I > now would call flawed. But still it gave the users the impression that > their ls-R files' permissions are managed by debconf, and probably many > thought they were properly managed and didn't do any manual changes. Well, assuming that your debconf questions are different from the ones it asked before, this is the same as not having had questions before. Consider what I've said before to operate on a per-question basis. (In other words, I'm suggesting that you rename your questions and ask the new ones on upgrade from the broken versions of the package.) > > The parameters passed to the config script can be used to detect the > > upgrade and not ask any questions or populate the debconf database at > > all, while leaving debconf asking the question on fresh installs and > > when reconfigured. > > Oh, but that seems very hard to do right: The only way to differentiate > between an upgrade and reconfigure seems to be the version number of the > last installed version. No, in an upgrade, $2 is "configure", for a reconfigure $2 is "reconfigure". > But since one could install the package noninteractively, but switch > to an interactive frontend before an upgrade, I would have to avoid > asking questions for *any* last-installed version number older than > the current one (if I decide not to ask and act at all upon upgrade). Only if the noninteractive install ran with DEBCONF_NONINTERACTIVE_SEEN not set to true. Not setting that to true by default is agruably a bug in debconf since it does lead to this edge condition, but it's not an edge case I would worry about dealing with in your package. -- see shy jo signature.asc Description: Digital signature
Closing bugs bevore the upload is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today I did a update of the system (yes, sid and yes I know it can be unstable but...) and the update includes grep where no open critical bug was seen. After Boot the system was completely broken as of the libpcre dependency. So please do not close bugs bevore it is available on servers. This break of the system musn't be. Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ3O3Y5+OKpjRpO3lAQKi1Qf/Rtbt/DBmdipL4yOKRfVkXoF22hKehkuq Pm0M2ByDBTN5XLsCl6gFjczCBxtFbC20dimWBilK+KEjDhCzLPD2EmN696AJGkVq CqcZD2VN8KnVAbVmkO29oBWZomoQf13e5yYPNgmbiRJ+2+5tY9DrQOnsa554IDxD /loHGsKQgz33BgQ0AwR89vd7zFPahGd0WLzrpj2I4137Zkudrcsv/iMNd8YLq6Dv 3P2pD1doSPgIedNWUo2hUDl7/4Fc4+lkCk6lrXpuHp3u02FWs6uaYtacWAxF9lsx rO+RVKuUjnJVPH0CyDro9QvoIjzHzKSQwNqzUHTXrxBcgK3DviAIIQ== =t/PH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338530: ITP: 915resolution -- resolution modify tool for Intel 915/999/1000 graphic chipsets
Package: wnpp Severity: wishlist Owner: Steffen Joeris <[EMAIL PROTECTED]> * Package name: 915resolution Version : 0.4.7 Upstream Author : Steve Tomljenovic [EMAIL PROTECTED] * URL : http://www.geocities.com/stomljen/download.html * License : under public domain Description : resolution modify tool for Intel chipsets 915resolution is a tool to modify the video BIOS of the 800 and 900 series Intel graphics chipsets. This includes the 845G, 855G, and 865G chipsets, as well as 915G, 915GM, and 945G chipsets. This modification is necessary to allow the display of certain graphics resolutions for an Xorg or XFree86 graphics server. . 915resolution's modifications of the BIOS are transient. There is no risk of permanent modification of the BIOS. This also means that 915resolution must be run every time the computer boots inorder for it's changes to take effect. If you want to automatically set the resolution on each boot and before X is launched, see /usr/share/doc/915resolution/README.Debian for information about configuring the provided initscript. . Web site: http://www.geocities.com/stomljen/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
Le jeudi 10 novembre 2005 à 13:32 -0800, Debian Installer a écrit : > Rejected: source only uploads are not supported. Why is this the case ? I'm running with experimental GNOME packages; if I upload a binary package depending on them, it will be uninstallable on unstable systems. I can't see the rationale for rejecting source uploads, and they used to be accepted in the past. (And don't tell me to use pbuilder, I don't have the disk space nor the bandwidth for it.) -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: Closing bugs bevore the upload is available
Klaus Ethgen <[EMAIL PROTECTED]> writes: > Today I did a update of the system (yes, sid and yes I know it can be > unstable but...) and the update includes grep where no open critical bug > was seen. After Boot the system was completely broken as of the libpcre > dependency. > > So please do not close bugs bevore it is available on servers. This > break of the system musn't be. Sorry, but this is standard Debian practice. Unstable is unstable. Bugs are closed when the fix is uploaded. My system wasn't completely broken; I simply booted single user, diagnosed the problem, and copied the shared libraries into /lib. In a day or so the fixed grep will be uploaded, and I can delete the copied libraries. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338530: ITP: 915resolution -- resolution modify tool for Intel 915/999/1000 graphic chipsets
Le jeudi 10 novembre 2005 à 22:02 +0100, Steffen Joeris a écrit : > 915resolution is a tool to modify the video BIOS of the 800 > and 900 series Intel graphics chipsets. This includes the 845G, > 855G, and 865G chipsets, as well as 915G, 915GM, and 945G chipsets. > This modification is necessary to allow the display of certain > graphics resolutions for an Xorg or XFree86 graphics server. Is it a full replacement for 855resolution? In this case, could you synchronize with the 855resolution maintainer to avoid having both packages in the archive? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: gnome-swallow_1.2-2_source.changes REJECTED
* Josselin Mouette [Thu, 10 Nov 2005 22:45:20 +0100]: > (And don't tell me to use pbuilder, I don't have the disk space nor the > bandwidth for it.) Why bandwidth? Several systems exist to cache debs so they don't have to be fetched from the net each time they're used (apt-cacher, apt-proxy, or even a shared /var/cache/apt/archives). Cheers, -- Adeodato Simó EM: dato (at) the-barrel.org | PK: DA6AE621 Listening to: Matthew Kimball - I don't want to fall in love We learned that the Linux load average rolls over at 1024. And we actually found this out empirically. -- H. Peter Anvin from kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
On Tue, Nov 08, 2005 at 01:40:07PM -0600, Adam Heath wrote: > Also, with this email, I am making a formal request: I am the original author > of DBS, the most widely used patch system available in debian. This system > tends to want to be embedded inside each and every package that makes use of > it(altho, this is not always the case nowadays, with dbs.deb and cdbs). I > therefor make an official request that you remove all distributition of all > such dbs-derived packages until such time as this mismatch is fixed. Are you going to send the same to Mepis (www.mepis.org) ? As far as I know they don't release source debs either and are a more interesting target. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
Le jeudi 10 novembre 2005 à 23:00 +0100, Adeodato Simó a écrit : > * Josselin Mouette [Thu, 10 Nov 2005 22:45:20 +0100]: > > > (And don't tell me to use pbuilder, I don't have the disk space nor the > > bandwidth for it.) > > Why bandwidth? Several systems exist to cache debs so they don't have > to be fetched from the net each time they're used (apt-cacher, > apt-proxy, or even a shared /var/cache/apt/archives). And here comes the lack of disk space... -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: gnome-swallow_1.2-2_source.changes REJECTED
[Josselin Mouette] > I can't see the rationale for rejecting source uploads, and they used > to be accepted in the past. It's the first line of defense against people uploading things that don't build, wasting various infrastructure resources. Perhaps what you need is for someone to set up an autobuilder queue that doesn't upload packages but just returns them to you somehow, with logs, so you can sign and upload yourself. Of course this autobuilder queue should be under control of Debian developers, lest we have another round of flames about uploading untrusted binaries. signature.asc Description: Digital signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
On Thu, Nov 10, 2005 at 11:43:26PM +0100, Josselin Mouette wrote: > Le jeudi 10 novembre 2005 à 23:00 +0100, Adeodato Simó a écrit : > > * Josselin Mouette [Thu, 10 Nov 2005 22:45:20 +0100]: > > > > > (And don't tell me to use pbuilder, I don't have the disk space nor the > > > bandwidth for it.) > > > > Why bandwidth? Several systems exist to cache debs so they don't have > > to be fetched from the net each time they're used (apt-cacher, > > apt-proxy, or even a shared /var/cache/apt/archives). > > And here comes the lack of disk space... Why not get someone else that has sufficient bandwidth/diskspace to build it in a pbuilder and upload for you? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgp49yrUQS1Kr.pgp Description: PGP signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
On Thu, Nov 10, 2005 at 04:49:08PM -0600, Peter Samuelson wrote: > > [Josselin Mouette] > > I can't see the rationale for rejecting source uploads, and they used > > to be accepted in the past. > > It's the first line of defense against people uploading things that > don't build, wasting various infrastructure resources. > > Perhaps what you need is for someone to set up an autobuilder queue > that doesn't upload packages but just returns them to you somehow, with > logs, so you can sign and upload yourself. Of course this autobuilder > queue should be under control of Debian developers, lest we have > another round of flames about uploading untrusted binaries. > I don't want to speak for him, but Anibal has a pbuilder that he kindly let me use while he was sponsoring my packages. I just had to email the URL to the .dsc file to [EMAIL PROTECTED] and then it would download, build and email me the report. Maybe he (or someone else) would be willing to make something like that more widely available. If nothing else, maybe someone can provide the recipe and then someone else can set one up. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgphwenO99dZl.pgp Description: PGP signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
Le jeudi 10 novembre 2005 à 17:49 -0500, Roberto C. Sanchez a écrit : > Why not get someone else that has sufficient bandwidth/diskspace to > build it in a pbuilder and upload for you? That's the obvious solution, but it just makes things more complicated. I was wondering the rationale behind refusing source-only uploads. Working around human issues by removing functionality has never proved to be efficient. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: gnome-swallow_1.2-2_source.changes REJECTED
On Thu, Nov 10, 2005 at 10:45:20PM +0100, Josselin Mouette wrote: > I can't see the rationale for rejecting source uploads, and they used to > be accepted in the past. AFAIK, this is false. Source-only uploads were never allowed in Debian. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
On 10469 March 1977, Josselin Mouette wrote: >> Rejected: source only uploads are not supported. > I can't see the rationale for rejecting source uploads, and they used to > be accepted in the past. Because people then fuck up their packages even more. No, they havent been accepted in the past. Ubuntu does that, Debian not. -- bye Joerg i just managed to procrastinate an extra 30 mins by reading an article on how not to procrastinate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Resignation and orphan list
Having lost my access to my old GPG key, I followed project procedure for creating and validating a new one. The final step is a signed request to [EMAIL PROTECTED] That request was sent on October 3. However, my new key is still not on the keyring. James Troup (elmo) is the only human behind [EMAIL PROTECTED] Over the past five weeks, Mr. Troup has found lots of time to participate in Ubuntu development, as evidenced by his continued activity on the #ubunto-devel IRC channel. However, despite many requests by mail and IRC, he has not found five minutes to update the keyring with my new key. Branden Robinson, the DPL, is aware of this organizational failure. But he has done nothing effective to repair it. He has suggested that another DD, Jeroen van Wolffelaar, has the authority to make keyring changes -- an odd situation, given the [EMAIL PROTECTED] alias, but no matter -- but Mr. van Wolffelaar has made no more progress than Mr. Troup has: that is to say, none. I see no point in trying to force my way (back) into a project that shows no interest in allowing me to keep participating. Therefore, I hereby resign from the Debian Project. My resignation orphans the following packages: deliver libclass-factory-perl libclass-inner-perl libcss-tiny-perl libextutils-cbuilder-perl libextutils-parsexs-perl libhttp-server-simple-perl liblist-moreutils-perl libmail-spf-query-perl libmodule-signature-perl libnet-cidr-lite-perl libnet-ftpserver-perl libpadwalker-perl libppi-html-perl libppi-perl libppi-xs-perl libproc-background-perl libstring-koremutake-perl libsys-hostname-long-perl libterm-size-perl libyaml-perl -- Chip Salzenberg <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Resignation and orphan list
On Thu, Nov 10, 2005 at 03:23:08PM -0800, Chip Salzenberg wrote: > I see no point in trying to force my way (back) into a project that shows no > interest in allowing me to keep participating. Therefore, I hereby resign > from the Debian Project. That's a pity, imho. > My resignation orphans the following packages: > > libppi-html-perl > libppi-perl > libppi-xs-perl > libterm-size-perl > libyaml-perl I'd like to adopt those. Regards, Flo -- BOFH excuse #68: only available on a need to know basis signature.asc Description: Digital signature
Re: [Pbuilder-maint] Shall Debian's su conform to other implementations
Hi, > Unfortunately, this broke pbuilder (see #317264), and other Debian > packages (e.g. dchroot). So this patch was (at least temporarily) removed, > and the current behavior documented. > > > We would now like to get rid of this bug. What do you recommend: > * keep a Debian specific implementation and tag this bug wontfix > * reapply the patch to fix this bug, and report bugs on the packages that >uses this "feature" Could you document and wait until etch release? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and orphan list
On Thu, Nov 10, 2005 at 03:23:08PM -0800, Chip Salzenberg wrote: > I see no point in trying to force my way (back) into a project that shows no > interest in allowing me to keep participating. Therefore, I hereby resign > from the Debian Project. Why are you assimilating the project to an handful of individual ? There are around 1000 developers out there. At the very least I am sure you would find several of them willing to sponsor your upload. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
Joerg Jaspert <[EMAIL PROTECTED]> writes: > On 10469 March 1977, Josselin Mouette wrote: > >>> Rejected: source only uploads are not supported. >> I can't see the rationale for rejecting source uploads, and they used to >> be accepted in the past. > > Because people then fuck up their packages even more. > > No, they havent been accepted in the past. Ubuntu does that, Debian not. Oh, so Ubuntu packages are fucked up more by their maintainers more than Debian packages are? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
In article <[EMAIL PROTECTED]> you wrote: > Why is this the case ? I'm running with experimental GNOME packages; if > I upload a binary package depending on them, it will be uninstallable on > unstable systems. How can you test your packages if you dont build them? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338530: ITP: 915resolution -- resolution modify tool for Intel 915/999/1000 graphic chipsets
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le jeudi 10 novembre 2005 à 22:02 +0100, Steffen Joeris a écrit : >> 915resolution is a tool to modify the video BIOS of the 800 >> and 900 series Intel graphics chipsets. This includes the 845G, >> 855G, and 865G chipsets, as well as 915G, 915GM, and 945G chipsets. >> This modification is necessary to allow the display of certain >> graphics resolutions for an Xorg or XFree86 graphics server. > > Is it a full replacement for 855resolution? In this case, could you > synchronize with the 855resolution maintainer to avoid having both > packages in the archive? and also provide, replace and conflict with it, of course ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house."
Re: Licenses for DebConf6
On Thu, 10 Nov 2005 13:02:22 +0100 Henning Makholm wrote: > [I tried to crosspost this between -legal and -devel, but apparently > it never arrived on -legal. Resending...] Thanks. > > Scripsit Francesco Poli <[EMAIL PROTECTED]> > > > Don't you agree that seeing non-free or even undistributable (no > > license means "All Rights Reserved", with current laws!) papers at a > > DebConf is really a shame? > > I don't. > > Remember that non-free != evil, and that some of the arguments why > free software is a good thing do not apply to expositions of scholary > work or other conference contributions. IMHO, papers to be presented at a conference are documents (often pieces of documentation) that can (technically) be read, studied, adapted, copied, redistributed and improved by other people. In a manner much similar to computer programs. I think that /legally/ allowing the above operations is a good thing for both programs and papers (and many other works of authorship). Are we restarting the "documentation is (not) software" discussion? Again? I hope we are not... ;-) > > People who think that intellectual property is in and of itself an > evil concept are free to license their contributions liberally. I don't think that (all) free software developers see "intellectual property" in and of itself as an evil concept. However, I would rather avoid the term "intellectual property"... > But > on the other hand, people who like free software for pragmatic reasons > related to its being, well, software should not be forced to give away > more rights than practically necessary for making the conference work. Most of those "pragmatic reasons" apply to conference papers too, IMHO. Anyway, nobody is forced to give a talk at DebConf6, hence nobody would be forced to publish a DebConf paper in a DFSG-free manner (even if my suggestion were accepted). I mean: some constraints *need* to be put for a DebConf anyway. For instance non-exclusive publication rights are already required. Moreover the topic of the paper cannot be arbitrarily chosen: would you accept a paper about the proprietary Microsoft tools used to deploy a Microsoft network? or about medieval history? What I suggest is just adding another (good, IMHO) constraint. > > For example, it is common not to want to allow derived works for > conference papers. It is also common to require high fees for attending international congresses and conferences. DebConf is not doing this, though (fortunately: a big thanks to all the sponsors!). It is also common not to want to allow derived works for computer programs (see e.g. Microsoft, Sun Microsystems, Apple, Oracle, ...). Debian developers do not contribute to Debian this way, though. > That does not conflict with the SC, because the > papers are not going to be part of our operating system. I'm perfectly aware that we are not talking about SC violations. But complying with the SC is not the *only* good thing that DDs can do... :-) Moreover, I don't see a good reason to consider packaging DebConf papers for inclusion in Debian as an absurd idea. It could be done and could be useful. After all, we currently have several Linux Gazette issues in (sarge's) main: they have licensing problems, but if they hadn't any, I would have nothing against their presence in main. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpQygxemupEi.pgp Description: PGP signature
Re: Licenses for DebConf6
On Thu, 10 Nov 2005 12:25:11 +0100 Henning Makholm wrote: > Scripsit Francesco Poli <[EMAIL PROTECTED]> > > > That's why I consider this issue as an important one: every DebConf > > is an event through which we get public attention and can thus > > spread our philosophy. The message really works better if we act > > consistently with our philosophy, IMHO. > > We do not have a philosophy that says that everything ought to be > DFSG-free. Do you think that a DebConf with more non-free papers and less DFSG-free ones would be a better conference? > > We have a philosophy that says that we only distribute things in main > if they are DFSG-free. That is a different thing. I know, but why do we accept things in main only if they are DFSG-free? For a dogmatic adherence to rules written by others? Or rather for reasons that we consider as good ones and that lead to the rules detailed in the SC? I think the same reasons lead to think that papers should be accepted at a DebConf only if they are DFSG-free. > > > Just like a Debian package doesn't enter main, until it meets Policy > > requirements (DFSG-freeness being one of them). > > DebConf papers will not be distributed in main. They are not, currently. That's why I said "like" and haven't filed any serious bug against the non-existent debconf-papers package... However, for the future, who knows? Someone could ITP some papers, maybe. At that point only the DFSG-free ones will be able to go in main. It will be better, if there are more of them. > > > Actually the C4P already requires some permissions from the authors: > > > | Debconf requires non-exclusive publication rights to papers, > > | presentations, and any additional handouts or audio/visual > > | materials used in conjunction with the presentation. > > And this requirement would be a no-op under your theory that a > DFSG-free license for the papers is required. Therefore I conclude > that your theory is wrong. Which theory? Mine is a suggestion, not a theory. If it's accepted, the C4P will obviously be modified and will drop the non-exclusive publication rights requirement (as it is actually implied by the DFSG-compliance requirement that I'm suggesting). > > > What I suggest is simply adding one further condition. > > For the record, I oppose this suggestion. I cannot fully understand why, but I take note of it. Are you concerned that less papers would be submitted to DebConf6 with such a rule? In case you are: why aren't you similarly concerned that less packages will be distributed in main, if we care "too much" about Freeness issues? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpFpEKqbvRNG.pgp Description: PGP signature
Re: Resignation and orphan list
Chip Salzenberg <[EMAIL PROTECTED]> writes: > I see no point in trying to force my way (back) into a project that shows no > interest in allowing me to keep participating. Therefore, I hereby resign > from the Debian Project. Please, don't do that. I agree we have problem inside of project but we need to work together to fix them. Resign from it doesn't help us! I also offer myself to sponsor any uploads that you need in case and then help you to keep your packages in good shape! -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Resignation and uploads
Bill Allombert <[EMAIL PROTECTED]> writes: > There are around 1000 developers out there. At the very least I am > sure you would find several of them willing to sponsor your upload. That's not a fix, it's a bad workaround. I was a DD. I should have been sponsoring uploads for other people, not trolling for sponsors. Since I sent my resignation mail, I have been told that the keyring was updated twice after my initial request for key change. Why was my key not added? No reason has been presented, publically or privately. -- Chip Salzenberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
* Chip Salzenberg <[EMAIL PROTECTED]> [2005-11-10 16:22]: > Since I sent my resignation mail, I have been told that the keyring > was updated twice after my initial request for key change. Why was my > key not added? No reason has been presented, publically or privately. Did you follow http://keyring.debian.org/replacing_keys.html ? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338554: ITP: kde-windeco-powder -- A window decoration for kde
Package: wnpp Severity: wishlist Owner: Sune Vuorela <[EMAIL PROTECTED]> * Package name: kde-windeco-powder Version : 0.6 Upstream Author : Remi Villatel * URL : http://www.kde-look.org/content/show.php?content=29935 * License : GPL Description : A window decoration for kde A plasmoid inspired window decoration for kde with 'glowing' buttons. With larger borders for easy size-changin. optionally changing menu-button with a button matches the window-buttons. .. This is not a style, but a window decoration. -- Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6
(FWIW, this is probably more of a d-project thing; d-legal is more about figuring out whether licenses are free and safe.) On Fri, Nov 11, 2005 at 12:24:58AM +0100, Francesco Poli wrote: > > DebConf papers will not be distributed in main. Why not (and "says who")? If they're worth anything at all, they sure seem like a decent thing to want to package--much more so than a lot of what seems to be packaged these days. > I cannot fully understand why, but I take note of it. > Are you concerned that less papers would be submitted to DebConf6 with > such a rule? > In case you are: why aren't you similarly concerned that less packages > will be distributed in main, if we care "too much" about Freeness > issues? His argument appears to be "we don't *have* to do this, therefore we shouldn't", which isn't much of an argument. (FWIW, I don't have a strong opinion either way; I just happen to find Henning's arguments--at least, those you've quoted--to be empty.) FYI, a possible response might be: "we care about freeness, but we pick our battle, and our battle is Debian main". I care about starving children, but I don't donate the majority of every check to feed them: there are lots of good causes, and the fact that everybody has to pick and choose their causes doesn't mean people "don't care enough". (That said, I don't agree with that response: it should be no big deal for people to freely license their papers, so they can be packaged later in Debian. This isn't a big, difficult fight.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and orphan list
On Thu, Nov 10, 2005 at 03:23:08PM -0800, Chip Salzenberg wrote: > Branden Robinson, the DPL, is aware of this organizational failure. But he > has done nothing effective to repair it. He has suggested that another DD, > Jeroen van Wolffelaar, has the authority to make keyring changes -- an odd > situation, given the [EMAIL PROTECTED] alias, but no matter -- but Mr. van > Wolffelaar has made no more progress than Mr. Troup has: that is to say, none. I'm sorry to hear that you think resigning is the only option. I don't actually have anything to do with keyring-maint, Branden just wasn't sure how to deal with your inquiry and asked me if I could help in some way. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] http://jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
On Fri, Nov 11, 2005 at 12:48:14AM +, Martin Michlmayr wrote: > * Chip Salzenberg <[EMAIL PROTECTED]> [2005-11-10 16:22]: > > Since I sent my resignation mail, I have been told that the keyring > > was updated twice after my initial request for key change. Why was my > > key not added? No reason has been presented, publically or privately. > > Did you follow http://keyring.debian.org/replacing_keys.html ? Yes. -- Chip Salzenberg <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-shadow-devel] Bug#276419: [Pbuilder-maint] Shall Debian's su conform to other implementations
Quoting Junichi Uekawa ([EMAIL PROTECTED]): > > We would now like to get rid of this bug. What do you recommend: > > * keep a Debian specific implementation and tag this bug wontfix > > * reapply the patch to fix this bug, and report bugs on the packages that > >uses this "feature" > > Could you document and wait until etch release? Etch release? We already delayed this for sarge release.then tried to fix it (badly as you know). I don't want bug reports rotting in the BTS. I have no idea of the shadow devel team healt in more than 1 year and I prefer we fixed as many bugs as possible while we can. Are these changes *that* invasive for pbuilder? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages file missing from unstable archive
On Wed, Nov 09, 2005 at 04:26:59PM +0100, Goswin von Brederlow wrote: > Anthony Towns writes: > > On Sun, Oct 30, 2005 at 09:48:35AM +0100, Goswin von Brederlow wrote: > >> Zsync checksum files are, depending on block size, about 3% of the > >> file size. For the full archive that means under 10G more data. As > >> comparison adding amd64 needs ~30G. After the scc split there might be > >> enough space on mirrors for both. > > Adding amd64 needs 30G? Since when? > With stable/testing/unstable/experimental it should end up around > there I think. Its 6-7G for the amd64 sarge debs so depending on > overlap you get more or less. Assuming no overlap, and your numbers you get 3 * 7 = 21 << 30. For architectures in the archive, including oldstable through experimental, disk space used by debs of that architecture range from 9GB (m68k) to 14GB (i386, ia64), including 13GB arch:all packages. It's necessary to have accurate numbers on these things, rather than pulling things out of the air. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Thu, Nov 10, 2005 at 07:49:36PM -0500, Glenn Maynard wrote: > FYI, a possible response might be: "we care about freeness, but we pick > our battle, and our battle is Debian main". I care about starving children, > but I don't donate the majority of every check to feed them: there are lots > of good causes, and the fact that everybody has to pick and choose their > causes doesn't mean people "don't care enough". (That said, I don't agree > with that response: it should be no big deal for people to freely license > their papers, so they can be packaged later in Debian. This isn't a big, > difficult fight.) Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? My blog's licensed under the CC No-derivs/non-commerical license for much the same reasons as most of RMS's writings aren't DFSG-free; but that's fine -- I'm not trying to get them to become the basis of a developer community or similar, and that's why I'm not bothered by not having comments on my blog, either. Likewise my list posts (like this one) don't have any explicit license, just the implied license that evolves from knowingly posting to public mailing lists -- which gives people the right to quote and archive them, and the occassional fair use right, but certainly not enough to qualify for main in the strictest sense. My debbugs paper was licensed under the CC Attrib/ShareAlike license, which is relatively free, but also not DFSG-free apparently. OTOH, it's also already out of date. Of course, "DFSG-free" isn't all the dc6 organisers are insisting on, but the right to MIT/X11 recordings of presentations too -- not even giving presenters the option to copyleft the recording of their presentation for some reason. BTW, a question: if you say "you must make your stuff DFSG-free", aren't you inspiring debate from people who don't want to, or who aren't comfortable with that, on why the DFSG isn't appropriate? If you made it optional or encouraged instead of compulsory, wouldn't that encourage debate on why the DFSG is good in the specific instances where people choose not to use free licenses? Wouldn't that be better? I'd prefer something like this: During and after the conference various materials will be made available to attendees and the general public; submission of a paper thus indicates permission to: * distribute verbatim copies and translations of the paper, slides and other materials provided by the presenter * distribute audio and video recordings of the presentation Presenters are encouraged to provide a specific license (preferably DFSG-free) under which the materials and presentation can be redistributed. Having the video/slide license appear as the first slide at each talk while the introduction's happening might be amusing. But not if it's just the BSD license each time :) Cheers, aj signature.asc Description: Digital signature
Re: Packages file missing from unstable archive
On Tue, Nov 01, 2005 at 09:54:09AM -0500, Michael Vogt wrote: > My next test was to use only the data.tar.gz of the two > archives. Zsync will extract the gzip file then and use the tar as the > base. With that I got: > 8< > Read data.tar.gz. Target 34.1% complete. > used 1056768 local, fetched 938415 > 8< > The size of the data.tar.gz is 1210514. Fetching 938kB instead of 1210kB is a 22.5% saving, so 12% of the desired data was apparently already present, but redownloaded anyway. > A problem is that zsync needs to teached to deal with deb files (that > is, that it needs to unpack the data.tar and use that for the syncs). That seems kinda awkward -- you'd need to start by downloading the ar header, working out where in the file the data.tar.gz starts, then redownloading from there. I guess you could include that info in the .zsync file though. OTOH, there should be savings in the control.tar.gz too, surely -- it'd change less than data.tar.gz most of the time, no? How much zsync data is required for that 22.5% saving over 1MB? I guess it'd be about 16 bytes per 4k of uncompressed data, assuming 33% compression, that's 16bytes per 3kB, or .5% overhead. For 100GB of debs in the archive, that's about an extra half gig of space used. Hrm, thinking about it, I guess zsync probably works by storing the state of the gzip table at certain points in the file and doing a rolling hash of the contents and recompressing each chunk of the file; that'd result in the size of the .gz not necessarily being the same, let alone the md5sum. Feh, trying to verify this with ~512kB of random data, gzipped, I just keep getting "Aborting, download available in zsyncnew.gz.part". That's not terribly reassuring. And trying it with gzipped text data, I get stuck on 99.0%, with zsync repeatedly requesting around 700 bytes. Anyway, if it's recompressing like I think, there's no way to get the same compressed md5sum -- even if the information could be transferred, there's no guarantee the local gzip _can_ produce the same output as the remote gzip -- imagine if it had used gzip -9 and your local gzip only supports -1 through -5, eg. Hrm, it probably also means that mirrors can't use zsync -- that is, if you zsync fooA to fooB you probably can't use fooA.zsync to zsync from fooB to fooC. Anyway, just because you get a different file, that doesn't mean it'll act differently; so we could just use an "authentication" mechanism that reflects that. That might involve providing sizes and sha1s of the uncompressed contents of the ar in the packages file, instead of the md5sum of the ar. Except the previous note probably means that you'd still need to use the md5sum of the .deb to verify mirrors; which means mirrors and users would have different ways of verifying their downloads, which is probably fairly undesirable. Relatedly, mirrors (and apt-proxy users, etc) need to provide Packages.gz of a particular md5sum/size, so they can't use Packages.diff to speed up their diffs. It might be worth considering changing the Release file definition to just authenticate the uncompressed files and expect tools like apt and debootstrap to authenticate only after uncompressing. A "Compression-Methods: gz, bz2" header might suffice to help tools work out whether to try downloading Packages.gz, Packages.bz2 or just plain Packages first. Possibly "Packages-Compress:" and "Sources-Compress:" might be better. Cheers, aj signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Thu, Nov 10, 2005 at 06:07:33PM +0100, David Schmitt wrote: > > [0] Presuming the FSF's claims about dynamic linking hold up in this > > case, anyway. > I consider a Debian-derived distribution a derived work of the contained > Debian tools in more ways than "mere" dynamic linking. That doesn't much matter -- Debian doesn't claim any copyright on its efforts in collecting work, so deriving from Debian doesn't involve any copyrights but that of the aggregate parts you use. The relevant parts are the licenses of individual packages that get linked against OpenSolaris' libc, and whether libc counts as a "module [the program] contains" and is thus covered as part of the "complete source code" as part of paragraph 3(a) of the GPL. > To be more specific: I don't believe that the fact that software A is being > packaged with Debians tools is a derived work of said tools, That's not actually the question -- the only "derivative" issue is that Nexenta's dpkg (eg) is a derivative of Debian's dpkg (or gcc is a derivative of upstream gcc) and thus covered by the GPL. The FSF argues (and Debian accepts) that dynamic linking should be legally treated the same as static linking, and thus that an executable that would contain libc when statically linked must be treated as "containing" libc when dynamically linked too. In this case, that's a pretty tenuous argument, but in other cases it's not so tenuous (linking to OpenSSL for example) and in such cases it has been an effective argument at getting libraries relicensed to be GPL compatible (such as for Qt). (Actually, it's probably worth noting that the core argument -- that /usr/bin/dpkg "contains" libc and thus that the former can't be distributed under the GPL without also distributing the source to the latter under the GPL -- is tenuous enough that actually following through on the legal threats we've seen could result in the argument being rejected, giving a precedent for all the folks who'd like to modify GPLed programs to rely on proprietary libraries.) > I'd like to add (d) distributing as source only. Compiling the whole thing on > the users system Note that compiling Nexenta involves using gcc, so you'd need to cross-compile from a glibc system, or you'd have the same problem in that you'd be distributing libc and gcc (which is GPLed and links to libc) together. > On other news, private communication by the gnusolaris.org people lead me to > the conviction that they are internally working on resolving their problems > with the legalese and we should give them a break. I will keep you informed > about their progress. Ugh; giving people a break's a good thing, but doing things in private and behind closed doors isn't. Participating in Debian in public can be (unreasonably) rough, but closing yourself up from the community and having communication bottle necks isn't a win either. Cheers, aj signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Tue, Nov 08, 2005 at 11:56:32PM -0600, Bill Gatliff wrote: > >And, I mean, seriously: using the threat of legal action to make people > >remove free software from the Internet? Whose side are we on here? > No. The threat of legal action to stop the theft of Free software. Big > difference. First, "theft" isn't an appropriate term to use about copyright violations -- you're not depriving anyone of their use. Don't buy into the FUD. Second, not only are they not depriving anyone of the software, they're working to make it available, at no cost, to a wider audience -- those people who'd like to use dpkg, but aren't willing to give up dtrace eg. For some people, making source more widely available is a bad thing -- it undercuts their monopoly rights to distribute the source, and thus the business model that funds their development. For free software developers, there's no such business model though, all it does is undercut the amount of software available for Linux but not Solaris, and the ability to say "this library isn't GPL-compatible, so you can't link it with the GPLed executable". Other examples of that are Qt (historically), OpenSSL (currently), and possible (future) proprietary extensions to things like gcc. However the CDDL'ed libc is *not* a proprietary extension -- it's free software available under terms very similar to (1) and (2) of the GPL. The problem is a technicality, not a moral or practical difference from the GPL's expectations: you still have the source to OpenSolaris libc, and you still have permission to modify it, redistribute it, sell it, etc. > Erast hasn't done *anything* to address or even acknowledge the CDDL/GPL > compatibility issue. His system as currently implemented clearly > depends on linking CDDL works with GPL works. The authors of the > software he's distributing with his system haven't given him permission > to do that. Quite simple, actually. "For every complex problem, there is an answer that is short, simple and wrong." BTW, a more accurate claim would be "I haven't seen Erast do anything to address the issue". Maybe you've got a right to see everything Erast and his colleagues do, but I'd bet you don't actually get to. > To be fair, I must admit that I'm not a DD and I don't hold copyright to > any of Erast's software. But I believe strongly in the way Debian does > things, and I use a *lot* of Debian software in my work. So I justify > my participation in this thread based on my interest in protecting > Debian's interests. Debian's interests are in the promotion of free software, not the promotion of highly technical legalistic parsing of copyright rules and licenses. If there weren't any copyright, Debian would still exist, and philosophically we'd be encouraging the release of source code and be advocating against treating source code as a secret. The above is fundamentally a distraction from our goals -- it's an important one, because we like to play by the book rather than pretending to be above the law, and since copyright does exist helping people use it effectively in accordance with our goals is useful; but Debian's not about IP rights, it's about free software. Cheers, aj signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Wed, Nov 09, 2005 at 01:40:27PM -0600, Kenneth Pronovici wrote: > On Wed, Nov 09, 2005 at 02:53:01PM +1000, Anthony Towns wrote: > > On Tue, Nov 08, 2005 at 08:55:41PM -0600, Kenneth Pronovici wrote: > > > many of Erast's responses were at best antagonistic, > > > and at worst showed a complete disregard for what Debian is all about. > > Speaking of antagonistic... > Huh? "Kenneth's responses have ranged from being dismissive to hostile." That would be antagonistic in that: * it makes the problem overly personal -- I'd be making you, personally, out to be the problem rather than saying your arguments or claims are wrong and should be abandoned; * it's overly critical -- portions of your responses might have been dismissive or the OpenSolaris guys' work, and it might've been possible to interpret your responses in a hostile manner, but that doesn't mean such an interpretation is correct or the most important aspect of your mails; * it's also blatantly dishonest -- not all of your mails have been dismissive to hostile. The latter's the case for Erast too -- take [0] eg, which doesn't seem remotely antagonistic, let alone showing a complete disregard for what Debian is all about. [0] http://lists.debian.org/debian-devel/2005/11/msg00165.html > > > This strikes me as a rather poor way to start a > > > relationship with someone, especially when you've just based most of > > > your userspace on that someone's source code. > > That's a very proprietary attitude about source code, don't you think? > Er, in what sense? "Proprietary" doesn't just mean "not open source" -- its more general meaning is a sense of ownership of something, which in turn means the right and ability to exercise some a degree of control over your property. One way in which people get proprietary about things is to charge rents and fees for their exploitation; the other way is to refuse them to be allowed to be exploited in various ways -- such as by using them for military or anti-government purposes, or by using them without helping make the author famous, or by using them without establishing a "relationship" with the author. Copyright law isn't the only way you can establish proprietary interests in software; patent law's another, as is establishing a monopoly on the tools you need to work on the software. Public opinion and moral suasion can work too, though; and while that's more democratic and less liable to certain abuses, it's still got many of the main drawbacks of proprietary software: it discourages innovation and reuse. Cheers, aj signature.asc Description: Digital signature
Bug#338571: ITP: python-pylib -- python unit testing framework
Package: wnpp Severity: wishlist Owner: Bob Tanner <[EMAIL PROTECTED]> * Package name: python-pylib Version : 20051109 Upstream Author : Holger Krekel <[EMAIL PROTECTED]> * URL : http://codespeak.net/py/current/doc/test.html * License : Copyright Description : python unit testing framework The py lib aims at supporting a decent development process addressing important deployment, versioning, testing and documentation issues - seen primarily from the perspective of a FOSS (Free and Open Source) developer. . Homepage: http://codespeak.net/py/current/doc/home.html -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Nov 11, 2005
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 203 (new: 0) Total number of packages offered up for adoption: 92 (new: 2) Total number of packages requested help for: 20 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 203 packages are orphaned. See http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: cvsbook (#337849), offered 4 days ago Description: Open Source Development with CVS, the book mon (#337944), offered 3 days ago Description: monitor hosts/services/whatever and alert about problems Reverse Depends: ultrapossum-failover webmin-mon 90 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: aboot (#315592), requested 140 days ago Description: Alpha bootloader: Looking for co-maintainers Reverse Depends: aboot-cross ltsp-server dfsbuild aboot athcool (#278442), requested 380 days ago Description: Enable powersaving mode for Athlon/Duron processors debtags (#321654), requested 96 days ago Description: Enables support for package tags Reverse Depends: debtags-edit dselect (#282283), requested 355 days ago Description: a user tool to manage Debian packages fetchmail (#331642), requested 37 days ago Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail grub (#248397), requested 549 days ago Description: GRand Unified Bootloader Reverse Depends: webmin-grub grubconf replicator dfsbuild grub-splashimages gtkpod (#319711), requested 109 days ago Description: manage songs and playlists on an Apple iPod gutenbrowser (#331203), requested 39 days ago Description: Project Gutenberg Etext reader lib (#329966), requested 47 days ago Description: Perl interfaces to the Gtk and Gnome libraries lsdvd (#316922), requested 129 days ago Description: read the contents of a DVD mwavem (#313369), requested 150 days ago (non-free) Description: Mwave/ACP modem support software openssl (#332498), requested 35 days ago Description: Secure Socket Layer (SSL) binary and related cryptographic tools Reverse Depends: openssh-server-udeb libopensc-openssl libecpg-compat2 apache-ssl pound webmin bzflag-server wpasupplicant pgadmin3 dsniff slapd libnet-ssleay-perl liblasso3 ultrapossum-tls ssmtp sqlrelay-sqlite cacti-cactid d4x hplip sylpheed-claws-gtk2 sylpheed-gtk1 libapache-mod-php4 php4-cgi postgresql-contrib-8.1 libpq3 sylpheed-claws-gtk2-clamav libldap-2.2-7 lwresd newpki-server hula davfs2 xine-ui heartbeat-2 php5-cli libecpg-dev racoon postfix cyrus21-common pyca ftpd-ssl fireflier-server siege nagios-plugins-basic libpq4 libyaz pantomime-dev libzorpll-dev usermin libpam-mount python2.3-sqlrelay apache2-mpm-prefork mozilla-opensc kannel-extras aria libkeynote0 sslwrap libsope-ldap4.4 postgresql-7.4 xsupplicant newpki-client tellico webauth-utils ca-certificates libopensc1-dev dovecot-pop3d libsnmp9-dev isync nmap dovecot-imapd esmtp libpam-musclecard postgresql-client-8.1 libc-client-dev libace5.4.7 libaws-dev libdar3 ipopd gambas-gb-net-curl libopensc1 telnet-ssl apache2-prefork-dev sylpheed-claws-gtk2-spamassassin php4-lasso asterisk php4-curl lprng ftp-ssl libgnustep-base1.10-dev libclamav1 php4-sqlrelay curl dnsutils libapache-mod-php5 libssl-ocaml libopenssl-ruby1.8 irssi-text balsa cyrus21-imapd fireflier-client-gtk libsqlrelay-ruby cl-tclink uw-imapd libsnmp9 openswan apache2-common libcurl3 libtao-orbsvcs1.4.7 pdns-backend-pgsql libapache-mod-ssl schooltool rdesktop libaqbanking0c2 jpilot-plugins ntp libgwenhywfar17c2 trustedqsl libsqlrelay-tcl pure-ftpd-postgresql bitchx-ssl postgresql-contrib-8.0 hammerhead hostapd libdns20 yaz sim postgresql-client-8.0 apache2-utils libapache2-webauth libcurl3-openssl-dev libace-dev libhula0 python2.3-lasso php5-cgi libnewpki2 pure-ftpd-mysql php5-dev kdesvn bincimap tinc httperf tinyca kmymoney2 postgresql-8.0 php4-cli openssh-client netmrg telnetd-ssl skyutils-dev sendmail-bin bazaar libclamav-dev ardour-gtk nessus-plugins apcupsd apcupsd-cgi dovecot-common stone spamc libsword5 pwsafe qterm tn5250 courier-ssl fireflier-client-kde libtorrent5 fwbuilder-linu
