Bug#671288: I don't think this is the way to go for this concept
close 671288 thanks https://etbe.coker.com.au/2023/12/14/fat-finger-shell/ I think that this should be reimplemented with the source of a newer terminal program that uses Wayland or reimplemented as an on-screen Wayland keyboard that uses transparency. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#849719: O: cyclades-serial-client
Package: wnpp Severity: normal The package cyclades-serial-client is designed to work with Cyclades terminal servers (which have not been manufactured for a while) and other devices using RFC 2217 (which probably includes some Cisco gear that's still in service). It has a shared object that takes over library calls like tcsetattr(3) to implement a fake serial port. I haven't used this for years and don't have enough spare time to maintain it. I can assist if someone else wants to take it over.
Bug#678926: RFA: maildir-bulletin -- Deliver bulletins directly to the users' Maildir.
Package: wnpp Severity: normal I request an adopter for the maildir-bulletin package. The package description is: Deliver bulletins directly to the Maildir mail storage of users. Designed to be run from the /etc/aliases file with command-line parameters for which groups to send mail to. This package also needs a new upstream developer. The current way it works doesn't suit any systems I run so I don't use it myself. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120625043955.8080.22730.reportbug@athena
Bug#572174: adopted these packages
close 572174 thanks Rudi told me that I could have this package, but I don't recall him mentioning that he had already orphaned it. So I'm closing the bug now. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007022021.48696.russ...@coker.com.au
Bug#436119: ITA: dict-gcide
On Wed, 16 Dec 2009, Ritesh Raj Sarraf r...@researchut.com wrote: Sure. Looks like a good candidate to start a new project with ? Especially since it contains more than 8 decades of data which can stand of value even if just archived and maintained. Probably we just host it on alioth and let interested parties contribute to and use it. As long as those 8 decades of data are not tainted. The GCIDE entries that originate from the 1913 Webster dictionary are very useful. There will always be a demand for historic definitions. I would rather see some older dictionaries split out and preserved. It would be good if someone scanned some old dictionaries that are out of copyright for historical purposes. I would also like to have old encyclopedias available, Wikipedia is great, but it's also good to know the historic definitions of terms and descriptions of the world as it was 100+ years ago. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD
On Sat, 14 Mar 2009, Mike Hommey m...@glandium.org wrote: [Mike Hommey] Screen does that too, so that would hardly be less secure than screen. Well, if by in /tmp you mean in /var/run/screen. Well, that's a Debian thing. Upstream default is /tmp/screens, and last time I checked on RH, it was there too. RHEL 5.2 has /var/run/screen. Debian/Lenny and RHEL 5.2 work in a similar way, you have a setgid screen program and the /var/run/screen directory is writable by the group. In Debian there is an init.d script to create that directory (presumably to support tmpfs /var/run) while in RHEL it is installed as part of the package. RHEL 4.7 has the directory /tmp/screens for root and /tmp/uscreens for user sessions. /tmp/uscreens is owned by the first non-root user who ran screen and group writable. If that user is hostile (or even clueless) then chmod 700 /tmp/uscreens will make it unusable for others. I don't know whether they can do anything really bad, screen appears to check the ownership of the socket so it should be OK apart from DOS attacks. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
On Tuesday 05 June 2007 16:52, Shachar Shemesh [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] What benefits does this offer over authbind which has been in Debian for ages? -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
On Wednesday 06 June 2007 20:05, Shachar Shemesh [EMAIL PROTECTED] wrote: What benefits does this offer over authbind which has been in Debian for ages? It uses a (I think) much more secure mode of operation. In particular: - No SUID executables - User who launches the daemon must be root Having a daemon instead of a SUID executable does not inherently make it more secure (there has been no shortage of exploits for bugs in daemons in the past). - Privileges go down, never up The usual system is that a process with UID != 0 can not bind to ports below 1024. Breaking this involves increasing the privileges of some programs. And, as a result: - No global configuration necessary (though one will probably be added later if necessary). How can there be no global configuration needed? The sysadmin needs to decide which users are granted the privilege to bind to low ports and which ports those users may bind to. -- [EMAIL PROTECTED] http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416151: ITP: nss -- Network Security Service libraries
On Sunday 25 March 2007 20:07, Mike Hommey [EMAIL PROTECTED] wrote: * Package name: nss Version : 3.11.5 Upstream Author : Mozilla Project * URL : http://www.mozilla.org/projects/security/pki/nss/ * License : GPL/LGPL/MPL Programming Lang: C Description : Network Security Service libraries How about a name other than nss. We already have libnss3 and libnss-*, having another package using a name based on nss would only add to confusion. This library is already provided by the xulrunner source package, but the intent is now to have it built from a separate package. How about xulrunner-nss for a package name? -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416397: ITP: haproxy -- fast and reliable load balancing reverse proxy
On Wednesday 28 March 2007 02:20, Arnaud Cornet [EMAIL PROTECTED] wrote: HAProxy is a TCP/HTTP reverse proxy which is particularly suited for high availability environments. It features connection persistence through HTTP cookies, load balancing, header addition, modification, deletion both ways. It has request blocking capabilities and provides interface to display server status. How do you preserve the mapping between the origin IP address and the connection that the web server receives? For HTTP the easiest solution would be to insert a header with the origin IP that could then be logged, does the HTTP header addition/modification functionality of HAProxy support this? Has this problem been solved for a protocol other than HTTP? In theory you could have a user-space TCP stack that sends data to the back-end server with a source address that is the same as that of the origin. Has anyone done this? -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311214: auditd -- User space tools for 2.6 kernel SELinux auditing
On Friday 23 March 2007 05:42, Manoj Srivastava [EMAIL PROTECTED] wrote: I would prefer you do move it back to /sbin. A number of SELinux tools are moving to depend on audit, and some of these do require them to be functional before the other file systems are mounted. I can live with them being in /usr, but that does reduce the functionality of user tools for SELinux in early boot. I think it's probably best to leave it in the upstream location in this case. However given that /var/log will probably be a separate FS and /var/log/audit will certainly be a separate FS for anyone who is really serious about auditing it seems that relying on /usr isn't going to be a problem - non-root FSs have to be mounted before auditd is started anyway. Thanks for taking up audit, BTW, or else I wqould have had top package it myself for lenny, and I don't really want any more packages than I already have. AOL. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347832: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer
On Wednesday 25 January 2006 21:53, Florian Weimer [EMAIL PROTECTED] wrote: There is no difference between decoders and encoders. Both require patent licenses. There are a few references to a statement by some of the patent holders (Thomson IIRC, the company representing one of the larger MP3 pools) that free[1] decoders can use a royalty-free license. This statement has either never been made by Thomson, or it has been withdrawn. Thomson has no intent to go after purely non-commercial activities, though. So Debian itself should be fine, but Debian distributors probably aren't. [1] free as in beer. If you use your free-as-in-freedom GPLed decoder for commercial activities, you need to obtain a license. Thomson made that one pretty clear. This factor makes it significantly different from the other programs which are afflicted with patent claims. If Thomson has made clear statements about a common use case of software based on their patents in Debian then it's quite different to a battle between Adobe and Macromedia. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347832: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer
On Wednesday 25 January 2006 17:40, Joe Wreschnig [EMAIL PROTECTED] wrote: On Wed, 2006-01-25 at 17:08 +1100, Russell Coker wrote: MP3 software does not belong in Debian/main. Unlike many patents the MPEG patents probably have a good basis. To make it clear, this is a *radical* divergence from our previous position. If other distributions start shipping the Fluendo plugin, it is also a major step backwards in usability. Have we consulted a lawyer about this? As far as I am aware OGG media is a good alternative to MPEG in every technical measure. OGG is not as well supported by 3rd party devices (no support in iPod for example) but there are devices which support it (iRiver as an example - incidentally the iRiver gives better sound quality according to the experts and allows recording so is better than the iPod anyway). It's clear to me you've never had to use an iRiver's Ogg support. It fails outside a limited bitrate range, drains battery faster, does not read metadata, and is not available on all devices. Newer iRivers also use a proprietary communications protocol that is not yet supported in Debian. Finally, the recording is MP3 only. iRiver will have more incentive to support OGG well if Linux distributions take a stand on this issue. By continuing to support MPEG in Debian/main we are decreasing the support of OGG. By continuing to support MS Word .doc in Debian/main, we are decreasing the support of OpenDocument. So what? Users have millions, billions of files in these formats. If we can support them, we should. If there was a patent on the MS file formats then I would advocate removing support from Debian. This also applies to mpc123. The Musepack developers are of the opinion that they no longer infringe on any patents, as the algorithm has diverged wildly from the MPEG-1 Layer 2 algorithm upon which it is based. It's on at least as good legal ground as every other audio format in Debian. So please leave it out of this discussion. Do we have any legal advice on this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer
On Wednesday 25 January 2006 12:10, Joe Wreschnig [EMAIL PROTECTED] wrote: 2) We take the patent issue seriously, and drop all MP3 support. MP3 software does not belong in Debian/main. Unlike many patents the MPEG patents probably have a good basis. Any software which is based on Frauhoffer patents (MP3 and other similar encoding systems) should be on an external archive. As far as I am aware OGG media is a good alternative to MPEG in every technical measure. OGG is not as well supported by 3rd party devices (no support in iPod for example) but there are devices which support it (iRiver as an example - incidentally the iRiver gives better sound quality according to the experts and allows recording so is better than the iPod anyway). By continuing to support MPEG in Debian/main we are decreasing the support of OGG. I believe that the best thing for the community is to drop MP3 support from main thus avoiding any potential patent risk for Debian users and also increasing the support for alternatives that can be legally used. This also applies to mpc123. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347832: ITP: mpc123 -- Command-line Musepack audio player
On Friday 13 January 2006 08:35, Daniele Sempione [EMAIL PROTECTED] wrote: MPC is a lossy compression format like MP3 or Ogg Vorbis. It is based on the MPEG-1 Layer-2 / MP2 algorithms, but has vastly improved. If it's based on the MPEG algorithms then it's also subject to the MPEG patents. Why would we want to have such a program which is not legally usable in most jurisdictions as well as having a total lack of content? OGG is free and not encumbered by any patents, there are a good number of OGG files available from many sources, and OGG is well supported by many other devices. Many personal music players support OGG, my iRiver supports OGG and MP3. It seems to me that the benefits of OGG over MPC (as you describe it) are so great that there's no benefit in creating a new non-US archive for it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321054: ITP: mls -- Mls is a linux clone of Mdir.
On Wednesday 03 August 2005 16:02, Ki-Heon Kim [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Ki-Heon Kim [EMAIL PROTECTED] MLS also stands for Multi Level Security. It would probably avoid confusion if the package was named mdir. NB We will have MLS in Debian in the next release. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251980: ITP: hc-cron -- A cron daemon for home computers
On Wed, 2 Jun 2004 06:42, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: It runs specified jobs at periodic intervals and will remember the time when it was shut down and catch up jobs that have occurred during down time when it is started again. Hc-cron is based on the widely used vixie-cron and uses the same crontab format so that it can be used as a drop-in replacement for that program. fcron can do all of this, it is stable, it has been in Debian for some time now, and it has SE Linux support and a friendly upstream which likes Debian. Why do we need hc-cron? What sets it appart from fcron? Fcron uses its own binary format for the compiled crontabs, but the format for fcrontabs There was a suggestion made that fcron be the standard cron in Fedora. http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01496.html The conclusion was that having two packages providing the same functionality was not desired, and fcron isn't entirely compatible with Vixie cron so isn't a good upgrade path for Red Hat users. Things are different in Debian. There is no objection to having multiple packages doing almost the same thing, and there is less objection from the users to slight changes of functionality in upgrades. In fact, I bet fcron upstream would, should someone do most of the grunt work, be amicable to making sure fcron could work as a drop-in replacement for Debian cron (i.e. with all the Debian quirks). I didn't have the time when I was maintaining it, and I don't think Russell Corker does either... but who knows :) Correct, I don't have enough time to do all of this. I can confirm that any patches you write for fcron which are good code will be well accepted by upstream. If someone wants to work on fcron I will be happy to help them and vet any patches that are sent upstream if necessary (I've already sent quite a few patches to Thibault and we get along well). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Bug#190312: O: kernel-patch-2.4-speedtouch -- speedtouch USB ADSL support for 2.4
Package: wnpp Version: unavailable; reported 2003-04-23 Severity: normal I intend to orphan the kernel-patch-2.4-speedtouch package. The package description is: The Alcatel SpeedTouch USB ADSL device is one of the cheapest pieces of hardware you can use for an ADSL connection. This patch supplies the Linux driver for it as well as the necessary sarlib. Supports 2.4.10 and 2.4.13.
Bug#179055: Adopting lilo
On Sat, 1 Feb 2003 12:28, Martin Michlmayr wrote: * Andres Roldan [EMAIL PROTECTED] [2003-01-30 18:30]: I intend to adopt lilo. I'm not a Debian Developer yet, but Luis Bustamante [EMAIL PROTECTED] will sponsor me with this package. Nothing personal against you, but since you're not neither a DD not even in the NM queue, how can we know that you have adequate skills to maintain an important package like LILO properly? Have you maintained other packages before or are you involved with upstream development of LILO? I have to agree with Martin here. LILO is a difficult package to maintain, it would be good to see a record of technical ability and ability to manage the Debian processes. The first thing a new LILO maintainer is going to have to deal with is a conflict between the people who want debconf support and the people who never want debconf support. Russell Coker
Bug#179055: O: lilo -- LInux LOader - The Classic OS loader can load Linux and others
Package: wnpp Version: unavailable; reported 2003-01-30 Severity: important I intend to orphan the lilo package. This package takes up too much time and gets me too many bug reports from idiots. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux lyta 2.4.20-se-32 #1 Thu Jan 23 21:41:58 CET 2003 i686 Locale: LANG=C, LC_CTYPE=C
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sat, 28 Dec 2002 08:28, Brian May wrote: - The Author recommends linking with -static, so restoration programs will work without extra libraries. I haven't decided if this is a good idea or not, if it needs to be applied to all binaries. lintian gets upset if my package contains static binaries. I suggest having a separate dar-restore-static package for that. - My version is compiled with ATTR (EA) support, however, DAR gets very verbose if the filesystem doesn't support ATTRs (IMHO errors of type Operation not supported need to be ignored). These warnings will disappear if the -Uu flags are used (don't archive ATTRs). Maybe you could patch it to check for ATTR support on backup at the start of each file system. If a file system does not support ATTR then display a single message File system /var does not support ATTR. and continue on with no further messages. Of course it's a bit more serious if you do a restore with ATTR support and the file system doesn't like it... - ssh can be used for backups (just pipe the data via ssh to the destination file), for incremental backups (generate catalog at server and send it to client first). However, I am not certain about restores (client requires 2 pipes to server, one in each direction; this makes me nervous about potential deadlocks). Shouldn't be a problem, just do ssh client restore-comand and then the client's stdin and stdout are the two pipes you need. Gotta test it first of course, but I expect it to work. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Bug#174525: ITP: dar -- Disk ARchive: Backup directory tree and files.
On Sun, 29 Dec 2002 00:52, Brian May wrote: Shouldn't be a problem, just do ssh client restore-comand and then the client's stdin and stdout are the two pipes you need. Gotta test it first of course, but I expect it to work. That only brings STDOUT and STDIN to the local computer. The hard part will be doing: dar ... | ssh client darr_slave | dar ... In other programs (eg. rsync, scp, cvs) it is more usually done like: dar ... -e ssh client darr_slave dar currently doesn't support this. Shouldn't be THAT difficult for you to code... ;) -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Bug#157916: RSBAC support in Debian
On Sat, 7 Dec 2002 22:43, Russell Coker wrote: On Wed, 6 Nov 2002 12:29, Christoph Martin wrote: In http://www.debian.org/doc/FAQ/ch-nexttime.html it says that work on RSBAC support in Debian is in progress. I have not seen any discussion of it on the list. However there is an RFP: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=157916 Is anybody working on this? I have built some kernel packages for RSBAC and put them online on http://www.coker.com.au/rsbac/ . Please check them out, if people think that they are OK then I'll upload them. I have not received any email response to this message and I conclude that there is no significant interest in using RSBAC in Debian at the moment. I will not do any more work on RSBAC at the moment for this reason and because I believe that RSBAC is overly complex to use. Could we get the web page that started this discussion changed to refer to SE Linux instead? SE Linux in Debian is getting some use and is under very active development. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Bug#157916: RSBAC support in Debian
On Wed, 6 Nov 2002 12:29, Christoph Martin wrote: In http://www.debian.org/doc/FAQ/ch-nexttime.html it says that work on RSBAC support in Debian is in progress. I have not seen any discussion of it on the list. However there is an RFP: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=157916 Is anybody working on this? I have built some kernel packages for RSBAC and put them online on http://www.coker.com.au/rsbac/ . Please check them out, if people think that they are OK then I'll upload them. I don't want to maintain these packages long-term as I have no plans to use RSBAC. After getting through the configuration phase I decided that I don't like it as much as SE Linux, grsec, and OpenWall. The packages on my site work well enough to produce a kernel package with make-kpkg. I have not tried booting from such a package as I don't have the user-space tools (or the time to spare). Even though I don't plan to use RSBAC myself I think it's a worthy thing to have in Debian, so I'm happy to maintain the kernel packages for a while (sans proper testing) to help kick-start the Debian/RSBAC project. Russell Coker
Bug#171253: ITP: libdjbdns -- DNS client library designed to replace the BIND res_*/dn_* library
On Sat, 30 Nov 2002 15:34, Gerrit Pape wrote: License: Bernstein has put the .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c, dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c, dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c, dns_txt.c) and all necessary lower-level .[ch] files into the public domain[1]. I do not plan to make any changes to those files, so Bernstein's djbdns security guarantee[2] applies. My additions to the package will be licensed under a BSD compatible license. The URL did not make this license adequately clear to me. Does this specifically differ from the license of Qmail?
Bug#155275: ITP: iozone3 -- Filesystem, disk-system benchmarking tool
On Fri, 2 Aug 2002 22:20, Kevin M. Rosenberg wrote: * Package name: iozone3 Version : 3.120 Upstream Author : William Norcott, Don Capps * URL : http://www.iozone.org/ * License : [NON-FREE]: limitation of distribution of modifications License to freely use and distribute this software is hereby granted by the author, subject to the condition that this copyright notice remains intact. The author retains the exclusive right to publish derivative works based on this work, including, but not limited to, revised versions of this work I discussed this matter with Don some time ago. At the time I told him that I would put IOZone in Debian within 48 hours if he released a version under a more free license. He said that he'd think about it and discuss it with his co-author (and I haven't heard from him since). The limitation on derivative works makes it suitable for non-free at best, and at worst entirely excludes it from Debian (depending on the interpretation of derivative works). Is a Debian package a derivative work of the original source? I think so, the author probably doesn't intend it quite that way - but until get get some clarification in writing I think we have to interpret it in it's most strict fashion. Russell Coker
Bug#152036: ITP: mls -- MLS: MailListStat - a text mode program to display MBOX statistics
On Fri, 5 Jul 2002 15:31, Kevin M. Rosenberg wrote: * Package name: mls MLS is a commonly used acronym which is about to become more common with it's use in systems such as NSA SE Linux. Perhaps it would be less confusing if you choose a different name... From V.E.R.A. -- Virtual Entity of Relevant Acronyms June 2002 [vera]: MLS MultiLevel Secure [operating systems / platforms] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#114756: ITP: kernel-patch-2.4.10-pppoa -- kernel patch for PPP over ATM
Package: wnpp Severity: wishlist I downloaded the patch from: http://www.kernel.org/pub/linux/kernel/people/axboe/PPPoATM/2.4.8-pre5/ Copyright: GPL 2.0
Bug#114757: ITP: kernel-patch-2.4.10-speedtouch -- kernel patch for SpeedTouch USB ADSL modem
Package: wnpp Severity: wishlist I downloaded the patch from: Speedtouch: http://sourceforge.net/project/showfiles.php?group_id=3581 Sarlib: http://sourceforge.net/project/showfiles.php?group_id=1 Copyright: GPL 2.0
