Bug#199241: O: awesfx -- various utility programs for controlling AWE32/64 driver
Package: wnpp Severity: normal orphaning this package because I dont have a AWE32/64 anymore. The package is bug free but upstream isn't working on it anymore -- Noèl Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#199242: O: camstream -- collection of tools for webcams and other video-devices
Package: wnpp Severity: normal orphaing this package because I don't use it regular anymore and want to concentrate on some of my packages. upstream is acive and the only open bug is that camstream is i386 specific. -- Noèl Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#199247: O: gtkrecover -- GUI for recover
Package: wnpp Severity: normal orphaing this package because I don't use it regular anymore and want to concentrate on some of my packages. -- Noèl Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#199250: O: recover -- Undelete files on ext2 partitions
Package: wnpp Severity: normal orphaning this package because I don't use it regular anymore and want to concentrate on some of my packages. -- Noèl Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#199242: O: camstream -- collection of tools for webcams and other video-devices
On Sun, Jun 29, 2003 at 01:25:57PM +0200, Noèl Köthe wrote: Package: wnpp Severity: normal orphaing this package because I don't use it regular anymore and want to concentrate on some of my packages. upstream is acive and the only open bug is that camstream is i386 specific. I am interested by this package. I will upload a new version soon. Aurelien pgpqPDGtAmHjj.pgp Description: PGP signature
Bug#199242: O: camstream -- collection of tools for webcams and other video-devices
Am Son, 2003-06-29 um 15.32 schrieb Aurelien Jarno: On Sun, Jun 29, 2003 at 01:25:57PM +0200, Noèl Köthe wrote: Package: wnpp Severity: normal orphaing this package because I don't use it regular anymore and want to concentrate on some of my packages. upstream is acive and the only open bug is that camstream is i386 specific. I am interested by this package. I will upload a new version soon. Thank you! -- Noèl Köthe noel debian.org Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#199266: ITP: ffmpeg -- multimedia streaming system
Package: wnpp Version: unavailable; reported 2003-06-29 Severity: wishlist Since the ffmpeg ITP (#157719) was closed almost one year ago, I assume no one is interested anymore, thus this ITP. I use ffmpeg daily and I am not satisfied with the reasons given for closing the ITP. If anyone disagrees I'll gladly elaborate. * Package name: ffmpeg Version : upcoming 0.4.7, probably latest CVS snapshot Upstream Author : Fabrice Bellard et al. * URL : http://ffmpeg.sf.net/ * License : GPL (but see notes below) Description : multimedia streaming system Package: ffmpeg Description: converter for audio and video formats FFmpeg is a very fast video and audio converter. It can work on files but also grab from a live audio/video source. . FFmpeg can convert from any sample rate to any other, and resize video on the fly with a high quality polyphase filter. Package: ffserver Description: multimedia streaming server FFserver is a streaming server for both audio and video. It supports several live feeds, streaming from files and time shifting on live feeds (you can seek to positions in the past on each live feed). Package: libavcodec-dev Description: FFmpeg's audio/video codec library FFmpeg is a complete solution to record, convert and stream audio and video. This package includes libavcodec, the leading audio/video codec library. Notes: There will be no ffserver package at first because it is slightly broken at the moment. Also, libavcodec optionally links with GPL libraries. I will build with support for those libraries that are already in Debian (hence the License: GPL), but will also provide _lgpl variants (à la libart-dev). And since the API is not stable, PIC libs will be static (_pic.a) instead of shared. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux c18 2.4.21-rc5 #2 Wed May 28 22:10:14 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=fr_FR
Bug#199213: RFP: perlapi-5.6.1 -- PACKAGE perlapi-5.6.1 NOW MISSING IN SARGE
On Sat, Jun 28, 2003 at 08:31:42PM -0700, Mark Hedges wrote: Package: wnpp Version: unavailable; reported 2003-06-28 Severity: wishlist * Package name: perlapi-5.6.1 Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.some.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : PACKAGE perlapi-5.6.1 NOW MISSING IN SARGE (Include the long description here.) perlapi-5.6.1 is a package that disappeared from the sarge distribution after rollout of perl 5.8.0 and needs to be re-created. I disagree. We simply need to get to a position where the packages still depending on it in sarge can be updated. FYI, perlapi-5.6.1 was never a real package; it was a virtual package provided by perl 5.6.1. Any repackaging of it would be extraordinarily difficult, as for fairly good reasons Debian's perl packaging strategy does not support multiple concurrent versions of perl in the archive at any one time. This needs to be a dummy package pointing to the components of perl 5.8.0 that satisfy the dependencies, That would be very wrong; the resulting packages would not work despite their dependencies apparently being satisfied. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#199266: ITP: ffmpeg -- multimedia streaming system
On Sun, Jun 29, 2003 at 05:11:58PM +0200, Sam Hocevar wrote: Since the ffmpeg ITP (#157719) was closed almost one year ago, I assume no one is interested anymore, thus this ITP. I use ffmpeg daily and I am not satisfied with the reasons given for closing the ITP. If anyone disagrees I'll gladly elaborate. The reasons given for closing the ITP were moronic, however there is a more pressing problem. ffmpeg is in the same boat as mjpegtools, in that it implements algorithms such as mpeg-2 encoders, which are patented and aggressively enforced by the patent owners. Somebody will have to investigate all the algorithms it implements and see whether we can get away with distributing it or not (sometimes the patent owners allow free implementations; sometimes they forbid them outright, particularly when DRM is involved). Note that being patented isn't fundamentally an issue, but having the patent owner prohibit our distribution of the code is. That's not to say it can't be included in the distribution, but you've got some work to do first to find out. It may be necessary to gut some codecs. Also, it is probably not appropriate to build shared libraries at this time, since the API isn't stable (and upstream don't appear to understand this). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpMgPqiOGpoJ.pgp Description: PGP signature
Bug#197817: [Fwd: Re: Net::SCP::Expect licensing question (for Debian packaging)]
License question resolved. --jay -Forwarded Message- From: Daniel Berger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Net::SCP::Expect licensing question (for Debian packaging) Date: 28 Jun 2003 22:54:23 -0600 Hi Jay, Oops - guess I should've included that. I hereby declare that Net::SCP::Expect, and every other module that I own on CPAN, is licensed under the same terms as Perl itself. I should probably upload a new file with that info. Regards, Dan In the immortal words of Socrates, I drank what? MSN 8 helps ELIMINATE E-MAIL VIRUSES. Get 2 months FREE*. -- Jay Bonci| [EMAIL PROTECTED] GPG: E0B8B2DE| 562B 35DC BE8D 7802 DB31 6423 64D8 790F E0B8 B2DE signature.asc Description: This is a digitally signed message part
Bug#197817: ITP: libnet-scp-expect-perl -- Wrapper for scp that allows passwords to be sent via Expect
retitle 197817 ITP: libnet-scp-expect-perl -- Wrapper for scp that allows passwords to be sent via Expect thanks I'll take this module. It's available at http://jay.bonci.com/?node=libnet-scp-expect-perl It'll get uploaded when I get more stuff sponsored. --jay -- Jay Bonci| [EMAIL PROTECTED] GPG: E0B8B2DE| 562B 35DC BE8D 7802 DB31 6423 64D8 790F E0B8 B2DE pgp4mD2AJblx4.pgp Description: PGP signature
Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tue, 24 Jun 2003 19:51:13 +1000, Daniel Stone [EMAIL PROTECTED] wrote: Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) Please make this a project on alioth and create a -devel mailing list. What you are proposing is a great idea that deserves careful planning. Let me ramble on for a minute. The backup script should probably call up a list of packages on the system, build from these list a list of files installed from packages. These files should be excluded from the Backup. It should also back up the partition table of the hard disk, and information about which file systems are in use. The data generated this way could be written to CD images, or there could be an amanda interface that lets only the files that are not replaceable from a Debian mirror end up in the amanda archive. Restore procedure would boot from a CD (a dedicated recovery CD or the first CD of an image set created by debbackup). Next steps would be: - optionally restore hard disk partitioning - file system creation - mount file systems in a chroot - Use debootstrap to install a base system with working apt - dpkg --set-selections with the packet list backed up - apt-get -f install to install Packages and files - Restore of locally changed files and other data from the backup medium (using the CD images or amrecover). I would like to work with you on that package. I really appreciate your project and will certainly take a serious look into it when I get back online. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Bug#199266: ITP: ffmpeg -- multimedia streaming system
On Sun, Jun 29, 2003, Andrew Suffield wrote: The reasons given for closing the ITP were moronic, however there is a more pressing problem. ffmpeg is in the same boat as mjpegtools, in that it implements algorithms such as mpeg-2 encoders, which are patented and aggressively enforced by the patent owners. Any examples of such aggressive behaviour? I have been monitoring ffmpeg since a long time and they have never been threatened. Also, distributions such as Gentoo or FreeBSD which have worldwide mirrors are distributing ffmpeg. Somebody will have to investigate all the algorithms it implements and see whether we can get away with distributing it or not It will be hard for me to draw the line between a Save As or XOR cursor patent and one that can not be distributed, since they are probably valid only in that totalitarian country between Canada and Mexico, anyway. I'm not saying this patent audit is useless (I'll probably do it if no one else stands up), but since neither the authors of the software nor the entities redistributing it in source or binary forms have ever been intimidated, I do not see a real risk for Debian. Note that being patented isn't fundamentally an issue, but having the patent owner prohibit our distribution of the code is. That's not to say it can't be included in the distribution, but you've got some work to do first to find out. It may be necessary to gut some codecs. Okay, I'll investigate and send my findings to the BTS for archival. Also, it is probably not appropriate to build shared libraries at this time, since the API isn't stable (and upstream don't appear to understand this). Yup, that was my intention (see the end of the ITP). Sam. -- Sam Hocevar [EMAIL PROTECTED] http://sam.zoy.org/
Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
On Fri, 27 Jun 2003, Millis Miller wrote: Package: wnpp Version: N/A; reported 2003-06-27 Severity: wishlist * Package name: email Version : 1.9.0 Upstream Author : Dean Jones [EMAIL PROTECTED] * URL : http://www.cleancode.org/email * License : Custom Description : Send email from command line, either via MTA or SMTP, with optional encryption email is a simple command-line program to send emails. It can be configured to use either your sendmail installation or directly via smtp. . Also, if gpg is installed, it can digitally sign and encrypt outgoing emails. Do I even need to say it?
Bug#199266: ITP: ffmpeg -- multimedia streaming system
On Sun, Jun 29, 2003 at 11:12:56PM +0200, Sam Hocevar wrote: The reasons given for closing the ITP were moronic, however there is a more pressing problem. ffmpeg is in the same boat as mjpegtools, in that it implements algorithms such as mpeg-2 encoders, which are patented and aggressively enforced by the patent owners. Any examples of such aggressive behaviour? I have been monitoring ffmpeg since a long time and they have never been threatened. Also, distributions such as Gentoo or FreeBSD which have worldwide mirrors are distributing ffmpeg. I think it's a question of the difference between distributing source and binaries. Source code is protected free speech in the US; binaries are not. I don't know the specifics offhand, I just recall mjpegtools falls into this category for having an mpeg-2 encoder. Somebody will have to investigate all the algorithms it implements and see whether we can get away with distributing it or not It will be hard for me to draw the line between a Save As or XOR cursor patent and one that can not be distributed, since they are probably valid only in that totalitarian country between Canada and Mexico, anyway. The significant difference is whether anybody is seriously trying to pursue the patents or not - some of the mpeg patents are, including the infamous ones on mpeg audio, plus the ones on the recent microsoft stuff (off the top of my head). Actually, that's probably the first one you'll find with issues; ffmpeg uses lame for mp3 encoding, so that's got to go (should be easy). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgph9N0yAT1mQ.pgp Description: PGP signature
Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
Benj. Mako Hill [EMAIL PROTECTED] writes: On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote: Package: wnpp Version: N/A; reported 2003-06-27 Severity: wishlist * Package name: email I understand that email is the name of the upstream client but I'd like to urge you to reconsider keeping this name while the program is in Debian. Fortunately, this is no problem, since the license (http://email.cleancode.org/download/COPYING) doesn't allow redistribution anyway and so it cannot even go to non-free. -- Falk
Bug#163836: Debian package for GNU lightning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a Debian package ready for the 1.1 release of GNU lightning and plan to upload it to the archives within a week if no objections apply. - Marco -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+/2WuKwsh7RJ8uAgRAkyNAJ9azdX8zIiGmvXJJlWU7nT8vXh0JwCfY+4g CY28iJlCsa6RCoGO1vuwpf0= =fcFH -END PGP SIGNATURE-
Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
On Sat, Jun 28, 2003 at 03:33:16PM -0500, Steve Langasek wrote: On Sat, Jun 28, 2003 at 04:08:05PM +0100, Millis Miller wrote: E) Email does binary attachments and uses MIME (mime types, base64 encoding) to attach and send them with the message. You can't do this by doing what is described above. You can UUEncode it, but A LOT of mail clients don't support UUEncoding anymore. Plus, you can attach multiple binary files with email, not just one UUEncoded file. For instance: uuencode file.bin | gpg --clearsign | mail OTOH, the above features seem useful. mime-construct does multiple mime attachments. it does an excellent job, a very useful and versatile tool. it doesn't do uuencode, but a) uuencode is deprecated and should be avoided, and b) that's easy enough to do anyway: (for i in file1.bin file2.bin file3.bin ; uuencode $i ; echo ; done) | \ gpg --clearsign | mail ... FWIW, i don't think that mere duplication of existing functionality is a reason for a package not to be included in debian(*), but email is a really bad name for this program and this package. it's far too generic. (*) the only criteria for inclusion in debian are: 1. is it free? 2. is someone willing to package and maintain it? craig
Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Hi Marc! On Sun, Jun 29, 2003 at 10:43:14PM +0200, Marc Haber wrote: What you are proposing is a great idea that deserves careful planning. Let me ramble on for a minute. The backup script should probably call up a list of packages on the system, build from these list a list of files installed from packages. These files should be excluded from the Backup. It should also back up the partition table of the hard disk, and information about which file systems are in use. Doing actual backup is completely out of the scope of what I had planned - there are fantastic backup tools already. The debbackup script itself will only generate a tarball needed by debrestore - no more, no less. If you want to work on an Amanda interface, or a dedicated backup program, that's fine, but debrestore itself will continue to have a single, dedicated task, for setups where most data is shared (e.g. /home), or where perfectly good backup regimens already exist. The data generated this way could be written to CD images, or there could be an amanda interface that lets only the files that are not replaceable from a Debian mirror end up in the amanda archive. debbackup-mmddhhmm.tar.bz2 can already be written to a CD image. Restore procedure would boot from a CD (a dedicated recovery CD or the first CD of an image set created by debbackup). Yeah, a custom ISO has already been proposed - I think that's a fantastic idea. Next steps would be: - optionally restore hard disk partitioning - file system creation - mount file systems in a chroot - Use debootstrap to install a base system with working apt - dpkg --set-selections with the packet list backed up - apt-get -f install to install Packages and files - Restore of locally changed files and other data from the backup medium (using the CD images or amrecover). I would like to work with you on that package. I really appreciate your project and will certainly take a serious look into it when I get back online. I'll put up some sources when they're ready for consumption. Unfortunately, it's my understanding that 'guests' can't actually create Alioth projects, so I can't create it - I don't think I can ever actually commit it! I might be able to get a publically-accessible Subversion repository up, however. -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgp6TBhHEH74j.pgp Description: PGP signature
Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
On Fri, 27 Jun 2003, Luca - De Whiskey's - De Vitis wrote: On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote: * License : Custom Its license is non-free, not Custom: * Copyright (C) 2001 email by Dean Jones * * This source and program come as is, WITHOUT ANY WARRANTY and/or * WITHOUT ANY IMPLIED WARRANTY. * * Users of said software should realize that they cannot and will not * Hold Cleancode.org reliable or responsible for any purpose WHAT SO EVER. * Please read all documentation and use said software responsibly. * * ANY COMMERCIAL REDISTRIBUTION OR ANY PROPRIETARY REDISTRIBUTION OF THIS * OR ANY SOURCE FROM CLEANCODE.ORG IS PROHIBITED UNDER CERTAIN CONDITIONS AND * SHALL NOT BE RE-SOLD OR REDISTRIBUTED WITHOUT PRIOR AGREEMENTS WITH * CLEANCODE.ORG * * I can be reached by electronic mail if there are any questions or concerns * about this or any other software that was written/distributed by * Cleancode.org * [EMAIL PROTECTED] * * Software supplied and written by http://www.cleancode.org I'm not sure (i'm not good with legalese), but i suppose that you (we) shold ask cleancode.org the agreement about redistribution of 'email' to cleancode.org: i'm Cc-ing -legal to get some advise. For what it's worth, I believe this licence is *way* non-free. It doesn't allow redistribution at all, it doesn't allow modification, it discriminates against fields of endeavour (commercial interests), and if we asked for a prior agreement we'd get around most of the above issues but it would specific to Debian. I also have issues with the definition of commercial redistribution or proprietary redistribution - I get the feeling that would be a hairy one to argue in court (proprietary, especially). Also, unless http://www.cleancode.org is a legally registered entity, how can it have supplied and written the software in question? Sounds like an assertion of copyright to me, but I don't think a simple website can hold copyright (unless it's a registered legal entity, of course). So, we've violated DFSG 1, 2, 3, 5/6, and 8. Not bad for one licence which someone thought was DFSG free. I'd recommend going to upstream, showing them the DFSG, and asking if they'd mind relicencing it in some half-ways decent (or at least, unambiguous) manner, preferably a standard licence that fits their needs (it's not as though there aren't enough of them to choose from), and clarify the ownership of the code. -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Bug#198957: ITP: email -- Send email from command line, either via MTA or SMTP, with optional encryption
On Friday, Jun 27, 2003, at 11:05 US/Eastern, Luca - De Whiskey's - De Vitis wrote: On Fri, Jun 27, 2003 at 12:32:59AM +0100, Millis Miller wrote: * License : Custom Its license is non-free, not Custom: * ... SHALL NOT BE RE-SOLD OR REDISTRIBUTED WITHOUT PRIOR AGREEMENTS WITH * CLEANCODE.ORG ...or redistributed without prior agreements... That can't be packaged, even for non-free.
