Bug#1055427: RFP: neovim-gtk -- Rust-based GTK frontend for Neovim
Package: wnpp Severity: wishlist * Package name: neovim-gtk Version : 1.0.4 (or probably HEAD) Upstream Contact: Lyude Paul * URL : https://github.com/Lyude/neovim-gtk/ * License : GPLv3 Programming Lang: Rust Description : Rust-based GTK frontend for Neovim This is a simple Rust-based GTK 4 frontend for Neovim with tabs and a sidebar. This is useful because it the existing graphical frontend in Debian is Qt-based, and a GTK-based frontend works better for users using GNOME or MATE. In addition, it can work using Neovim over SSH (if invoked from a script) to allow graphical editing of remote repositories on systems which don't offer X11 forwarding, which many other graphical Neovim frontends do not. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA signature.asc Description: PGP signature
Bug#794338: RFP: ruby-rubygems-openpgp -- Digitally sign Ruby gems via OpenPGP
Package: wnpp Severity: wishlist * Package name: ruby-rubygems-openpgp Version : 0.6.0 Upstream Author : Grant Olson * URL : https://github.com/grant-olson/rubygems-openpgp * License : BSD Programming Lang: Ruby Description : Digitally sign Ruby gems via OpenPGP An extension to rubygems to allow signing gems with OpenPGP. This package is useful because it allows one to authenticate downloaded gems without having to either purchase an X.509 certificate or create a self-signed one, instead using the Web of Trust. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#696836: RFP: libmath-pari-perl -- Perl bindings for PARI
On Sat, Dec 29, 2012 at 01:50:54AM +, brian m. carlson wrote: > I forgot one: Crypt::Random (not listed in the Makefile.PL), which > depends on, you guessed it, Math::Pari. I've proposed a patch upstream > (RT#82314) to use Bytes::Random::Secure as a fallback. This is what > will be used in the proposed Crypt::RSA that doesn't use Pari. One more thing: I plan on submitting a patch upstream to support the Camellia ciphers, so Crypt::Camellia might be a good idea as well. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#696836: RFP: libmath-pari-perl -- Perl bindings for PARI
On Sat, Dec 29, 2012 at 02:26:52AM +0100, gregor herrmann wrote: > On Fri, 28 Dec 2012 23:00:01 +0000, brian m. carlson wrote: > > > > Which modules are those? I haven't looked at the chain in a little > > > while, but i thought we'd packaged up most of the rest of the non-PARI > > > dependencies. I'm probably wrong :) > > As far as direct dependencies: I forgot one: Crypt::Random (not listed in the Makefile.PL), which depends on, you guessed it, Math::Pari. I've proposed a patch upstream (RT#82314) to use Bytes::Random::Secure as a fallback. This is what will be used in the proposed Crypt::RSA that doesn't use Pari. > > Digest::SHA1 (although I'm happy to patch this to use Digest::SHA) > > Oh yes, we won't reintrodcue Digest::SHA1 after we finally managed to > get rid of it :) A patch to use Digest::SHA is now RT#82316 (which also introduces support for all the SHA-2 algorithms). > > Crypt::CAST5_PP (Crypt::CAST5 can likely be used instead) > > Sounds good. A patch to use Crypt::CAST5 is now RT#82315. > > Crypt::RSA > > Here we have #532839 > (I haven't looked if it stills needs Math::Pari) It does, although within the past two weeks an alternative implementation has been proposed upstream using Math::Bigint instead of Math::Pari. It's available as Alt::Crypt::RSA::Bigint in the mean time. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#696836: RFP: libmath-pari-perl -- Perl bindings for PARI
On Fri, Dec 28, 2012 at 05:22:44PM -0500, Daniel Kahn Gillmor wrote: > https://rt.cpan.org/Ticket/Display.html?id=52689 > > It looks like there's some rough consensus to have the PARI-less > Crypt::RSA become the new version of Crypt::RSA soon. I was planning to > ITP it when that happens (though i might also consider packaging > Alt::Crypt::RSA::BigInt first, if anyone with deeper debian-perl > knowledge can provide guidance on how "Ingy's Alt namespace idea" might > interact with debian packaging). Excellent. > > I'd like to point out that several other modules are missing for > > Crypt::OpenPGP to be functional without using cpan. I can open RFPs for > > those if there's interest in packaging them. > > Which modules are those? I haven't looked at the chain in a little > while, but i thought we'd packaged up most of the rest of the non-PARI > dependencies. I'm probably wrong :) As far as direct dependencies: Crypt::RIPEMD160 Digest::SHA1 (although I'm happy to patch this to use Digest::SHA) Crypt::CAST5_PP (Crypt::CAST5 can likely be used instead) Crypt::IDEA Crypt::RSA We don't need to patch out Crypt::IDEA since all the patents have expired. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#696836: RFP: libmath-pari-perl -- Perl bindings for PARI
On Thu, Dec 27, 2012 at 09:02:07PM -0500, Daniel Kahn Gillmor wrote: > On 12/27/2012 08:41 PM, gregor herrmann wrote: > > The last ITP for this package (#440527) was also closed after some > > time because it's somewhere between untrivial and impossible ... > > > > After a quick glance at the old bug report it would need something > > like libpari-source ... > > > > AFAICS there was no reply from the libpari maintainer, and upstream > > in https://rt.cpan.org/Ticket/Display.html?id=30552 also didn't > > follow up on Gunnar's request. > > > > INSTALL mentions some ways about using a pre-built libpari but this > > doesn't sound very encouraging ... (And the hint with LIBPARI= also > > doesn't seem to work for me.) It didn't work for me, either. I was hoping someone had already figured out how to do this and it would only have to be done once. > Fortunately for my own Crypt::OpenPGP goals, recent work on Math::Prime > and Crypt::RSA might relieve us of some Math::PARI dependencies, which > could clear the way forward for Crypt::OpenPGP (finally!) by jessie. Can you point me to where that work's occuring? I'd be happy to contribute if it means I don't need Math::PARI. > brian, what in particular do you want or need Math::PARI for? Maybe > there's another route that would help you get to your goal? As I said, I want it for Crypt::OpenPGP. Crypt::OpenPGP sounds interesting, but it can't yet be used to build a fully-featured OpenPGP implementation. I want to change that, and I'd like to build such an implementation, as well as a keyserver that honors the no-modify bit. I'd like to point out that several other modules are missing for Crypt::OpenPGP to be functional without using cpan. I can open RFPs for those if there's interest in packaging them. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#696836: RFP: libmath-pari-perl -- Perl bindings for PARI
Package: wnpp Severity: wishlist * Package name: libmath-pari-perl Version : 2.01080605 Upstream Author : Ilya Zakharevich * URL : http://search.cpan.org/~ilyaz/Math-Pari-2.01080605/Pari.pm * License : Perl (Artistic | GPL-1+) Programming Lang: Perl Description : Perl bindings for PARI Math::Pari is a Perl interface to the famous library PARI for numerical, scientific, and number-theoretic calculations. It allows the use of most PARI functions in Perl, and (almost) seamless merging of PARI and Perl data. The description is slightly modified from the upstream description. I'm interested in this primarily as an indirect dependency for Crypt::OpenPGP, and building it by hand is non-trivial if I want it to link to Debian's libpari. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
On Fri, Jan 13, 2012 at 12:57:37AM +0100, Mike Gabriel wrote: > On Fr 13 Jan 2012 00:37:57 CET Stefan Lippers-Hollmann wrote: > >forked monolithic X.org 6.9 source tree. > > This is indeed the case. I can't speak for the ftpmasters and Security Team, but honestly I can't see why they would allow this in the archive or in any stable release, respectively. > >Most likely with little to no bug-/ security fixes since 2005 - or am > >I missing anything vital in that packaging git? Likewise the current > >debian/copyright appears to lack all copyright notices of the original > >XFree86/ X.org code, which makes up, by far, most of the source. > > The X2Go upstream team will be open to security and feature patches > and will love to be pointed at security issues discovered. In the > very very very long run there might be someone (we are currently > talking about people in Austria being interested in such a project) > who refactors NX for latest Xorg code, but currently what we can > provide is an active maintenance of NoMachine's code. I think you're missing the issue here. Since X.org 6.9, there's been a lot of bug fixes and improved code. So you're essentially using an obsolete codebase with a new protocol hacked on. The Security Team does not like code copies. Porters do not like patching the same software again and again, except with slight differences that make it impossible to reuse the same patches[0]. The Debian X Strike Force has lots of bugs that need to be dealt with, very likely because of a lack of time and manpower[1]. If your code is a fork of 6.9, then all those bugs that were dealt with previously (or are still present) are probably present in your code. Also, even though X2Go may provide security support for nx-libs, the Debian Security Team still has to issue DSAs and build packages on all of the release architectures independent of X2Go. [0] I have had the joy of assisting the kFreeBSD porters with patching every embedded and modified copy of libgc. [1] This is not a dig at the X Strike Force; they do a very good job with package maintenance and bug handling with the manpower they have. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#655180: ITP: afpfs-ng -- Client for the Apple Filing Protocol (AFP)
On Sun, Jan 08, 2012 at 08:57:23PM -0500, Andres Mejia wrote: > * Package name: afpfs-ng > Version : 0.8.1 > Upstream Author : Alex deVries > * URL : http://sites.google.com/site/alexthepuffin/home > * License : GPL > Programming Lang: C > Description : Client for the Apple Filing Protocol (AFP) > > This is a client for the Apple Filing Protocol (AFP) which will let you mount > and access shared volumes from Mac OS X (or netatalk) to Linux, BSD and > Mac OS X systems. You might want to mention that this is a FUSE file system somewhere in the description. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#655010: ITP: missing-manpages -- manual pages for software missing them
On Sat, Jan 07, 2012 at 04:08:23PM -0600, Jonathan Nieder wrote: > brian m. carlson wrote: > > > missing-manpages provides free manual pages for software that does not > > have them. > > Sounds useful, and like something other distros could take advantage > of, too. The man-pages project already includes pages for a few GNU > programs. Have you looked into submitting these there? (I'm not sure > if it would be accepted since gcc already has an upstream manpage, but > it seems worth a try.) I can ask. Two things, though. One, these manual pages are totally incomplete. There's no way that they're going to be finished anytime soon, simply because of the number of options, and also because I don't have access to the -v --help output for every architecture, only i386, amd64, and sparc (and maybe powerpc). The other thing is that the gcc manual pages must be shipped in a separate package because Matthias Klose wants to be able to depend on gcc-manpages | gcc-4.6-doc (or whatever the two packages are called). I just called the upstream project that because I needed a name and because I figured it was better to be more generic and anticipate that I might write other man pages. Right now there are only man pages for gcc and friends. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#655010: ITP: missing-manpages -- manual pages for software missing them
On Sat, Jan 07, 2012 at 09:39:12PM +0100, Martin Zobel-Helas wrote: > i would prefer wishlist bugs on the packages that miss manpages, to get them > applied on those packages. Already filed and marked wontfix by Matthias Klose: #654931. His objection was that the non-free manpages from upstream would have to be diverted. If you and he want to fight it out, be my guest; just let me know what you decide. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#655010: ITP: missing-manpages -- manual pages for software missing them
Package: wnpp Severity: wishlist Owner: "brian m. carlson" * Package name: missing-manpages Version : 1 Upstream Author : brian m. carlson * URL : https://github.com/bk2204/missing-manpages * License : GPL-2/Apache-2.0/CC-BY-SA-3.0 tri-license Programming Lang: man Description : manual pages for software missing them missing-manpages provides free manual pages for software that does not have them. Note that this is the name of the source package. Currently only manual pages for GCC are available, but it's possible manpages for other packages will be included at some point in the future. This is being packaged separately from gcc because its maintainer is not interested in including manpages in the gcc-4.6 package. The exact name for the binary package containing the gcc manpages is yet to be determined pending feedback from debian-gcc (CC'd). The description for the binary package is as follows: documentation for the GNU Compiler Collection This package contains manual pages for the GNU Compiler Collection. The upstream manual pages cannot be included in main for license reasons, so these (incomplete) manual pages have been written from scratch to replace them. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#643324: ITP: profphd -- secondary structure and solvent accessibility predictor
On Tue, Sep 27, 2011 at 11:24:44AM +0200, Laszlo Kajan wrote: > Package: wnpp > Severity: wishlist > Owner: Laszlo Kajan > > > * Package name: profphd > Version : 1.0.35 > Upstream Author : Laszlo Kajan > * URL : http://rostlab.org/ > * License : GPL > Programming Lang: Perl > Description : secondary structure and solvent accessibility predictor > > Solvent accessibility is predicted by a neural network method rating at a > correlation coefficient (correlation between experimentally observed and > predicted relative solvent accessibility) of 0.54 cross-validated on a set of > 238 globular proteins (Rost & Sander, Proteins, 1994, 20, 216-226; > evaluation of accuracy). The output of the neural network codes for 10 states > of relative accessibility. Expressed in units of the difference between > prediction by homology modelling (best method) and prediction at random > (worst method), PROFacc is some 26 percentage points superior to a comparable > neural network using three output states (buried, intermediate, exposed) and > using no information from multiple alignments. These paragraphs sound like a scientific abstract or part of a scientific paper. The long description is supposed to help me (as a sysadmin) decide whether or not I want to install the package. Perhaps you could simply describe what the package itself is good for and include the minimum background necessary for me to understand so I can make a decision. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#641887: ITP: libcrypt-rc4-perl -- Perl implementation of the RC4 encryption algorithm
On Sat, Sep 17, 2011 at 08:18:14AM +0100, Nicholas Bamber wrote: > * Package name: libcrypt-rc4-perl > Version : 2.02 > Upstream Author : Kurt Kincaid (sifuk...@yahoo.com) > * URL : http://search.cpan.org/dist/Crypt-RC4/ > * License : Artistic or GPL-1+ > Programming Lang: Perl > Description : Perl implementation of the RC4 encryption algorithm > > A simple implementation of the RC4 algorithm, developed by RSA Security, > Inc. > Here is the description from RSA's website: Why are you adding this to the archive? RC4 is less secure than many other algorithms. It may be faster and simpler, but security-wise, it's on its way out. > Independent analysts have scrutinized the algorithm and it is considered > secure. This is simply not true. RC4 is extremely vulnerable to related-key attacks, the initial bytes of the keystream leak significant amounts of information of the key, and those initial bytes tend to be very biased (the first byte has a 37% chance of being 0x01 and the second has a 12% chance of being 0x03; they should each be 1/256). Also, RC4's keyspace is not flat; that is, it has weak keys. These vulnerabilities have been practically exploited to break WEP (see aircrack-ng). If you insist on adding this to the archive, please note in the description that RC4 is vulnerable to a variety of security attacks and should not be used except in protocols that have specially designed countermeasures to avoid these problems. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#633953: ITP: tyxml -- typed XML in OCaml
On Fri, Jul 15, 2011 at 01:37:48PM +0200, Stéphane Glondu wrote: > * Package name: tyxml > Version : 1.91 > Upstream Author : Thorsten Ohl, Vincent Balat, and others > * URL : http://ocsigen.org/tyxml/install > * License : LGPL > Programming Lang: OCaml > Description : typed XML in OCaml > > TyXML allows one to build XML trees whose validity is ensured by the > typechecker. It's based on a traduction of XML types into polymorphic You probably want "translation" instead of "traduction". While the latter is not incorrect, it's very uncommon in modern English (to the point that I had to look it up). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#630753: ITP: snap -- gene finding with HMMs in Eukaryotes and Prokaryotes
On Fri, Jun 17, 2011 at 01:17:10AM +0200, Steffen Moeller wrote: > * Package name: snap > * URL : http://homepage.mac.com/iankorf/ > * License : GPL > Description : gene finding with HMMs in Eukaryotes and Prokaryotes It's my understanding (and correct me if I'm wrong) that cells are either eukaryotic or prokaryotic; there isn't a third class. If so, it's probably better to use a term that includes both, since as it reads now, it implies that it handles these two types, but not some unknown third. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#619059: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format
On Sun, Mar 20, 2011 at 09:26:07PM +, Nicholas Bamber wrote: > * Package name: libmozilla-ca-perl > Version : 20110301 > Upstream Author : Gisle Aas > * URL : http://search.cpan.org/dist/Mozilla-CA/ > * License : MPL-1.1 or GPL-2+ or LGPL-2.1+ > Programming Lang: Perl > Description : Mozilla's CA cert bundle in PEM format > > Mozilla::CA provides a copy of Mozilla's bundle of Certificate Authority > certificates in a form that can be consumed by modules and libraries > based on > OpenSSL. Is this really appropriate for Debian's purposes? I would think that using ca-certificates is probably better since not only are the certificates already in PEM format but the administrator can choose to add, remove, enable, or disable certificates in one central place. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
On Thu, Feb 17, 2011 at 12:35:26AM -0800, Vincent Cheng wrote: > * Package name: dropbox > Version : 1.0.20-1 > Upstream Author : Dropbox, Inc. > * URL : http://www.dropbox.com > * License : Proprietary > Section : non-free/net > Description : secure backup, sync and sharing util It looks like you're still missing the source for librsync.so.1 in your packages. Also, I *strongly* recommend that you not include binary-only shared libraries that are already available in Debian. The security team will not be very happy with you. As an example, your package ships libz.so.1, which has been the target of a DSA previously. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#611422: ITP: libmath-base85-perl -- Perl extension for base 85 numbers, as referenced by RFC 1924
On Sat, Jan 29, 2011 at 08:45:58PM +0200, Niko Tyni wrote: > Do you really have a use case for this? It looks like this is not generic enough, but if it were, it could be used for PostScript and PDF, which can use Ascii85. The printable characters used there are different, though. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#599446: ITP: libapache2-mod-rivet -- Server-side Tcl programming system combining ease of use and power
On Thu, Oct 07, 2010 at 06:13:28PM +0200, Massimo Manghi wrote: > * Package name: libapache2-mod-rivet > Version : 2.0.1 > Upstream Author : The Rivet Team > * URL : http://tcl.apache.org/rivet/ > * License : Apache-2.0 > Programming Lang: C, Tcl > Description : Server-side Tcl programming system combining ease of use > and power > > Apache Rivet is a system for creating dynamic web content via a > programming language integrated with Apache Web Server. It is > designed to be fast, powerful and extensible, consume few system > resources, be easy to learn, and to provide the user with a platform > that can also be used for other programming tasks outside the web > (GUI's, system administration tasks, text processing, database > manipulation, XML, and so on). In order to meet these goals > Tcl programming language was chosen to combine with the Apache Web > Server. If Rivet only works with Tcl, then instead of saying "via a programming language", say, "via the Tcl programming language". Otherwise, it's confusing because at first the description implies that any programming language might be acceptable, whereas later I read to mean that only Tcl is available. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Mon, Sep 06, 2010 at 11:55:51PM +0200, Andrea Colangelo wrote: > * Package name: woof > Version : 2009.12.27 > Upstream Author : Simon Budig > * URL : http://www.home.unix-ag.org/simon/ > * License : GPL2 > Programming Lang: Python > Description : A small, simple, stupid webserver to share files We have a lot of web servers in Debian. Could you provide a long description for the package that helps an adminstrator decide why she might want to install woof instead of some other lightweight web server? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#595805: Other problems with devmem2
devmem2 also crashes with a SIGBUS when it's requested to access unaligned memory on machines that forbid it. For example, on sparc: blackhole ok % sudo ./devmem 0x7000 w /dev/mem opened. Memory mapped at address 0xf7fec000. Value at address 0x7000 (0xf7fec000): 0x82106120 blackhole ok % sudo ./devmem 0x7001 w /dev/mem opened. Memory mapped at address 0xf7fc. zsh: bus error sudo ./devmem 0x7001 w This should not be allowed to occur. devmem2 should either forbid unaligned access where the processor forbids it (and that means on alpha, ia64, and other architectures where PR_SET_UNALIGN is implemented, unless it's disabled) or perform a fix-up like the kernel does in such situations. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#595805: ITP: devmem2 -- Simple program to read/write from/to any hardware address
On Mon, Sep 06, 2010 at 09:37:33PM +0200, Michael Opdenacker wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Opdenacker > > > * Package name: devmem2 > Version : 1.0.0 > Upstream Author : Jan-Derk Bakker > * URL : http://www.lartmaker.nl/lartware/port/devmem2.c > * License : GPLv2 or later > Programming Lang: C > Description : Simple program to read/write from/to any hardware address > > devmem2 can be used to access physical addresses > in your system, when allowed by the kernel. > It releaves you from having to access > /dev/mem by yourself with a C program, and > allows for quick experiments with the hardware > from the command line, before implementing a > real device driver. This is simply a really small wrapper around /dev/mem. Whether it is a worthwhile enough tool to maintain as a package, I have no opinion. But I would like to point out that it is not portable. It assumes a 4k page size and that sizeof(unsigned long) == 4. We have numerous architectures on which one or both of those are not true. That doesn't even take into consideration that poking around in /dev/mem is almost always the wrong thing. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: > Package: wnpp > Severity: wishlist > Owner: "Marco Túlio Gontijo e Silva" > > * Package name: haskell-gnomevfs > Version : 0.11.0 > Upstream Author : Duncan Coutts > * URL : http://www.haskell.org/gtk2hs/ > * License : LGPL-2.1+ > Programming Lang: Haskell > Description : Binding to the GNOME Virtual File System library It's my understanding that gnome-vfs is deprecated upstream and is going away. Most GNOME components no longer use it or include support for it. Do you really want to package a binding for unsupported software? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#579796: ITP: othman -- electronic Quran browser in Python
On Tue, May 04, 2010 at 09:39:02PM +0200, Frank Lin PIAT wrote: > I wonder who many people use the word "Coran" for Qur'an in English. If > this is quite frequent, you might want insert this synonym somewhere in > the description. In my experience, it's either "Qur'an" or "Koran." I think Gunnar used "Coran" because TTBOMK that's the term that's used in Spanish (except with an accent: Corán). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#568598: ITP: librt-java -- runtime routines for projects of intarsys
On Sat, Feb 06, 2010 at 10:25:43AM +0100, Guillem Jover wrote: > This name seems pretty generic to me (rt → real-time/run-time), wouldn't > it be better to use something like libisrt-java? I agree. Also: lakeview no % dpkg -L openjdk-6-jre-headless | grep rt.jar /usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#560088: ITP: python-portio -- low level port I/O for Linux
On Tue, Dec 08, 2009 at 08:23:15PM +, Dmitrijs Ledkovs wrote: > * Package name: python-portio > Version : 0.4 > Upstream Author : Fabrizio Pollastri > * URL : http://portio.inrim.it/ > * License : GPL-3+ > Programming Lang: Python, C > Description : low level port I/O for Linux > > Wrapper for the port I/O macros like outb, inb and other provided by the C > library on Linux x86 platforms. Honestly, this doesn't sound like something that should be encouraged. inb and outb are the source of much incompatibility between architectures, and any package depending on this one will be (likely permanently) stuck to i386. Is there something that you want to package that depends on this? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#551210: ITP: blame -- display the last modification for each line in an RCS file
On Fri, Oct 16, 2009 at 05:44:19PM +0200, Mike Hommey wrote: > As much as I do like this software as it turned out to be useful to me > in several cases, I'm not sure using the generic 'blame' name is a > good idea. Probably rcs-blame (with or without dash, you choose) would > be better IMHO. I concur. I'm actually working on a project right now (called "blame") that does something completely different: aggregate sources of spam and other network attacks (such as SSH bruteforcing) and automatically create and modify configuration files to block them. Probably a less generic name (for both this software and mine) would be appropriate. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
On Wed, Oct 07, 2009 at 04:13:59PM +0200, Mike Hommey wrote: > Except the issue is not about dual licensing, but about intent being > different to what the license actually says. i.e. The GPL3 the code is > supposed to be released under doesn't have these obligations, and > anybody not contributing back or taking commercial advantage in a closed > source solution is in its total rights under the GPL3 license. Except that the GPLv3 explicitly covers this case (from §7): All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. If the relevant source files do not have these terms, then they do not apply. If they are present, then we can remove them, because the GPLv3 says we can. Either way, it should be fine. This is a distinct difference between the GPLv2 and the GPLv3. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#538802: ITP: mercury -- The Mercury programming system, a pure logical/functional programming language.
On Mon, Jul 27, 2009 at 05:34:44PM +1000, Paul Bone wrote: > * Package name: mercury > Version : 0.13.1-rotd20090725 > Upstream Author : Mercury Group > * URL : http://www.mercury.csse.unimelb.edu.au/ > * License : GPL2 > Programming Lang: Mercury > Description : The Mercury programming system, a pure logical/functional > programming language. This used to be in Debian some time ago, because I remember trying to work on the package for some reason. I believe that it is self-hosting[0], which may be a problem, except that it supposedly comes with a C version of the compiler as well. To make life easy for porters, I'd request that you always build the C compiler and then, if you want to, bootstrap the Mercury compiler from that. If I'm remembering incorrectly, or that's no longer the case, feel free to disregard this. [0] That is, the compiler is written in Mercury. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#446028: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)
On Thu, Apr 09, 2009 at 10:06:55PM +0100, Neil Williams wrote: On Thu, 9 Apr 2009 20:41:12 + "brian m. carlson" wrote: [CC'd -legal as well; you probably want to follow up there.] I don't need to be CC'd, thanks. M-F-T set accordingly. On Thu, Apr 09, 2009 at 05:46:58PM +0200, Daniel Knabl wrote: >Seems to me that Broadcom Inc. does really allow Debian to >re-distribute the included firmware explicitly. The GPLv2 requires that distributors provide source code in certain circumstances. Source code is defined in the GPLv2 as the preferred form for modification. Unless Broadcom uses a hex editor to modify the firmware, Debian does not have the source code (the preferred form for modification) and therefore cannot provide it upon request. Since Debian cannot comply with the license, it is not permitted to distribute it at all. Doing so would be copyright infringement. That wasn't the result of the GR: Option 5 "Assume blobs comply with GPL unless proven otherwise" I'm going to ignore for the moment the fact that this title has a negligible relation to the proposal's content and that the actual proposal supports my point. There are two issues here: * Broadcom says that the entire driver (presumably including firmware) is GPLv2. Because we know that it is not shipped with source code (see below), we know that this is insufficient to make the firmware legally distributable. * The firmware actually has a separate license that reads as follows: * Firmware is: *Derived from proprietary unpublished source code, *Copyright (C) 2000-2003 Broadcom Corporation. * *Permission is hereby granted for the distribution of this firmware *data in hexadecimal or equivalent format, provided this copyright *notice is accompanying it. This license does not allow for modification. Therefore, Debian can legally distribute the firmware, but only in non-free. I have no objection to Debian distributing this firmware in non-free; nevertheless, as I stated in my original post, whether Debian distributes this firmware is mostly irrelevant with regard to having a functioning tg3 driver. Do we know if there is "source code" for this firmware. There is no proof that the firmware does not comply with the GPLv2 AFAICT, therefore the GR requires that we assume that the firmware does comply, whatever that means with regard to the "preferred form for modification". Why assume that using a hex editor is impossible? I'm not saying that using a hex editor is impossible. I'm saying that there's source code: * Firmware is: *Derived from proprietary unpublished source code, *Copyright (C) 2000-2003 Broadcom Corporation. I don't know about you, but I'd much prefer to modify any sort of program, firmware or not, using C or assembly rather than editing the binary directly. I suspect that this is the case for any reasonable programmer. Thus, we do not have the preferred form for modification, and thus, we cannot distribute it under the GPLv2. This issue is completely separate from whether the firmware has source code according to the DFSG. How can it be separate? The assertion from your reply was that there was source code behind the hex. Is there *evidence* and *proof* that this is the case? Yes. Why would Broadcom lie about there being source code? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#446028: tg3 firmware - was (Fw: [CASE#221365]: Closed - need firmware files)
[CC'd -legal as well; you probably want to follow up there.] On Thu, Apr 09, 2009 at 05:46:58PM +0200, Daniel Knabl wrote: Seems to me that Broadcom Inc. does really allow Debian to re-distribute the included firmware explicitly. The GPLv2 requires that distributors provide source code in certain circumstances. Source code is defined in the GPLv2 as the preferred form for modification. Unless Broadcom uses a hex editor to modify the firmware, Debian does not have the source code (the preferred form for modification) and therefore cannot provide it upon request. Since Debian cannot comply with the license, it is not permitted to distribute it at all. Doing so would be copyright infringement. If Broadcom were to license the firmware under a revised BSD license or another license that does not require providing source code, then Debian would be permitted to distribute it in non-free. This issue is completely separate from whether the firmware has source code according to the DFSG. As a practical matter, only certain very old revisions of the hardware actually need the firmware at all for basic functionality. Most hardware using the tg3 driver (like my laptop) are completely functional without any firmware at all. Certain extra features, like TCP Segment Offloading (TSO), are enabled by the firmware, but these features are not required for basic functionality. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#468221: ITP: missidentify -- a program to find win32 applications
On Wed, Feb 27, 2008 at 09:07:33PM +0100, Monniez Christophe wrote: Miss Identify is a program to find Win32 applications. In its default mode it displays the filename of any executable that does not have an executable extension (i.e. exe, dll, com, sys, cpl, hxs, hxi, olb, rll, or tlb). The program can also be run to display all executables encountered, regardless of the extension. This is handy when looking for all of the executables on a drive. Other options allow the user to record the strings found in an executable and to work recursively What does this do that file(1) does not? lakeview ok % file setup.exe setup.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit, UPX compressed -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#452750: RFP: icedtea -- icedtea: Java runtime based on OpenJDK
Package: wnpp Severity: wishlist * Package name: icedtea Version : 7~b22-1.5~20071018 Upstream Author : IcedTea maintainers * URL : http://icedtea.classpath.org/ * License : GPL with ClassPath exception Programming Lang: C, Java Description : icedtea: Java runtime based on OpenJDK Icedtea is a temporary fork of OpenJDK There are preliminary icedtea packages available from Matthias Klose at deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/ deb-src http://people.ubuntu.com/~doko/ubuntu/ gutsy/ Getting these packages into main would be extremely useful, since many Java packages now in contrib (for example, fop), would be eligible for main. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#430642: Patch to make ttyrec with openpty
package ttyrec tags 430632 + patch kthxbye Attached is a patch that makes ttyrec use openpty. It builds successfully and seems to work successfully as well. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 diff -ur ttyrec.old/Makefile ttyrec-1.0.6/Makefile --- ttyrec.old/Makefile 2007-11-23 19:11:50.0 + +++ ttyrec-1.0.6/Makefile 2007-11-23 19:17:51.0 + @@ -1,5 +1,6 @@ CC = gcc -CFLAGS = -O2 +CFLAGS = -O2 -DHAVE_openpty +LIBS = -lutil VERSION = 1.0.6 TARGET = ttyrec ttyplay ttytime @@ -10,13 +11,13 @@ all: $(TARGET) ttyrec: ttyrec.o io.o - $(CC) $(CFLAGS) -o ttyrec ttyrec.o io.o + $(CC) $(CFLAGS) -o ttyrec ttyrec.o io.o $(LIBS) ttyplay: ttyplay.o io.o - $(CC) $(CFLAGS) -o ttyplay ttyplay.o io.o + $(CC) $(CFLAGS) -o ttyplay ttyplay.o io.o $(LIBS) ttytime: ttytime.o io.o - $(CC) $(CFLAGS) -o ttytime ttytime.o io.o + $(CC) $(CFLAGS) -o ttytime ttytime.o io.o $(LIBS) clean: rm -f *.o $(TARGET) ttyrecord *~ diff -ur ttyrec.old/ttyrec.c ttyrec-1.0.6/ttyrec.c --- ttyrec.old/ttyrec.c 2007-11-23 19:11:50.0 + +++ ttyrec-1.0.6/ttyrec.c 2007-11-23 19:14:05.0 + @@ -70,8 +70,12 @@ #define _(FOO) FOO #ifdef HAVE_openpty +#ifdef __GLIBC__ +#include +#else #include #endif +#endif #if defined(SVR4) && !defined(CDEL) #if defined(_POSIX_VDISABLE) signature.asc Description: Digital signature
Bug#449317: ITP: zekr-quran-translations-ur -- Zekr Quran Urdu translations
On Mon, Nov 05, 2007 at 01:48:04AM -0500, Mohammad Derakhshani wrote: I named this packaged based on another package of mine which was reviewed and accepted: <http://packages.debian.org/sid/zekr-quran-translations-en> Do you think the dfsg even in the accepted package zekr-quran-translations-en should be removed? You only use "dfsg" in the version number of a package when you have repacked the original tarball to exclude materials that aren't in compliance with the DFSG. Since you obviously don't do that with non-free packages, there's no point in using the "dfsg" label. I think that whenever you upload a new upstream version, you should remove the "dfsg" in the English translations package, yes. Don't re-upload just to remove the "dfsg". I think this translation is good enough to be packaged for Debian. But because 1. issue of translating Quran is very disputable (In Islamic theology, perfectly translating Quran is considered impossible), and I'm aware of this debate. 2. we are not sure enough that the current translation is exactly word by word matches the real translation done by the its translator, and 3. in zekr-quran-translations-en which was reviewed and accepted we used exactly the same disclaimer, in my humble opinion, I think it is better to not change the disclaimer. Okay. I'm not at all picky. You're always free to ignore my suggestions; you're the maintainer, and I'm not. P.S: If you can send me a link of howto discussing when a package should be called dfsg I will appreciate. Included above. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#449317: ITP: zekr-quran-translations-ur -- Zekr Quran Urdu translations
On Sun, Nov 04, 2007 at 10:10:58PM -0500, Mohammad Derakhshani wrote: Package: wnpp Severity: wishlist X-Debbugs-CC: [EMAIL PROTECTED] * Package name: zekr-quran-translations-ur Version : 1.1.dfsg Upstream Author : Mohsen Saboorian <[EMAIL PROTECTED]> * URL : http://siahe.com/zekr/resources.html * License : Only free for non-commercial purposes This is not in compliance with the Debian Free Software Guidelines, so you'll have to upload this to non-free (in which case there's no point labeling the version with "dfsg"). But see below. Urdu - Pakistan Urdu. Authors: - Maulana Shah Imam Ahmed Raza Khan (kanzul_iman.zip). According to Wikipedia, the translator died in 1921, which means that his translation occurred prior to 1923. In this case, the translation is in the public domain in the United States, so the license above is incorrect. There is no authenticity or correctness warranty for these translations. For more information please read the provided /usr/share/doc/zekr-quran-translations-ur/README.txt file. Disclaimers are most appropriate in the copyright file, not in the package description. The package description should provide only enough information for one to decide whether or not to install the package. If the correctness of the translation is so doubtful as to be useless, then perhaps the translation should not be packaged at all. IANAL; IANADD. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#85392: DocBook schemas
tags 85392 -upstream tags 85392 -wontfix kthxbye -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
debian-wnpp@lists.debian.org
-BEGIN PGP SIGNED MESSAGE- On Friday 09 July 2004 15:12, Thomas Maurer wrote: > Package: wnpp > Severity: wishlist > > * Package name: helix-player > Version : 1.0 (gold release this summer, currently beta) > Upstream Author : Helix Community <[EMAIL PROTECTED]> > * URL : http://player.helixcommunity.org > * License : Dual-licensed RPSL/RCSL (soon GPL) This license is non-free. Please only package the GPL version. Search the -legal archives for information. > Description : Helix Player is the Helix Community's open source > media player > > The Helix Player 1.0 is an open-source media player built in the > Helix Community for consumers. Built using GTK, it plays open source > formats, like Ogg Vorbis and Theora using the powerful Helix DNA > Client Media Engine. > > Homepage: http://player.helixcommunity.org > > Probably the RealPlayer which builds on the helix-client will follow > (in non-free of course) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQO79J+WR/8lWBVPnAQHkZgf8C3NY1e3ichNeUrC/2sFjqxsuKOijZLGo 9HrVeHDZcN99rvnOH/XGZGbdzwWo+Tjl+3UxdyJFS3eKxB4i1LztTkYNFG2T7wFa bqIJCHt0/tJrTrbc7JljGSXRdKjd58TBbr9L1HyHJOvg4y6F8dMZPBiMdIkyO73X qdPNfwGVDhEWJfa4SpoJyEv6tIjvedeId032F3ezmh1eUM3URt2E5PleYDCSpNbJ S+0YBzfIY1riW9JKGFUDy+REsHIndAw/QnhQBdyH+4rkeotUsred1axPEV66aggP Ld1fwsWOkmokf0mNmfOndPDRNvv7hiTL59Qvln0VSwQDM/ze9oe0wg== =010q -END PGP SIGNATURE-
Bug#181969: ITP: jasper -- Image library for the JPEG-2000 Part 1 Standard
) SHALL ASSUME THE COST OF ANY NECESSARY SERVICING, > REPAIR OR CORRECTION. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, > WHETHER TORT (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL THE > INITIAL DEVELOPER, THE UNIVERSITY OF BRITISH COLUMBIA, IMAGE POWER, INC., > MICHAEL DAVID ADAMS, ANY OTHER CONTRIBUTOR, OR ANY DISTRIBUTOR OF THE > JASPER SOFTWARE, OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO > THE USER OR ANY OTHER PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR > CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, > DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR > MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES, EVEN IF > SUCH PARTY HAD BEEN INFORMED, OR OUGHT TO HAVE KNOWN, OF THE POSSIBILITY > OF SUCH DAMAGES. THE JASPER SOFTWARE AND UNDERLYING TECHNOLOGY ARE NOT > FAULT-TOLERANT AND ARE NOT DESIGNED, MANUFACTURED OR INTENDED FOR USE OR > RESALE AS ON-LINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING > FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, > AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT > LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE > JASPER SOFTWARE OR UNDERLYING TECHNOLOGY OR PRODUCT COULD LEAD DIRECTLY > TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE > ("HIGH RISK ACTIVITIES"). LICENSOR SPECIFICALLY DISCLAIMS ANY EXPRESS > OR IMPLIED WARRANTY OF FITNESS FOR HIGH RISK ACTIVITIES. USER WILL NOT > KNOWINGLY USE, DISTRIBUTE OR RESELL THE JASPER SOFTWARE OR UNDERLYING > TECHNOLOGY OR PRODUCTS FOR HIGH RISK ACTIVITIES AND WILL ENSURE THAT ITS > CUSTOMERS AND END-USERS OF ITS PRODUCTS ARE PROVIDED WITH A COPY OF THE > NOTICE SPECIFIED IN THIS SECTION. -- Brian M. Carlson <[EMAIL PROTECTED]> 0x560553e7 "Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all." --Douglas Adams pgpVq1hsNXVvS.pgp Description: PGP signature
Bug#170583: RFP: ghdl -- a VHDL simulator for designing electronic systems
Package: wnpp Version: unavailable; reported 2002-11-24 Severity: wishlist * Package name: ghdl Version : 0.1 Upstream Author : Tristan Gingold <[EMAIL PROTECTED]> * URL : http://ghdl.free.fr/ * License : GPL Description : a VHDL simulator for designing electronic systems GHDL is a VHDL simulator which implements almost all of the original VHDL87 specification and some features of the later VHDL93. Its purpose is to design electronic systems. This package is actually a compiler; it is works with gcc-3.2. Note to maintainer: this only currently works on i386; I will be glad to help port it to at least powerpc. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stonewall 2.4.19ck #1 Wed Nov 13 04:03:59 UTC 2002 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set) -- Brian M. Carlson <[EMAIL PROTECTED]> 0x560553e7 "Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all." --Douglas Adams pgpae9EtZSvQW.pgp Description: PGP signature
Re: Bug#160928: ITP: 7zip -- 7zip is file compressor which can handle many archive formats
On Mon, Sep 16, 2002 at 09:37:50AM -0500, Graham Wilson wrote: > On Mon, Sep 16, 2002 at 08:21:24AM -0500, Drew Scott Daniels wrote: > > It might be nice to note in the description that 7-zip does better > > compression than pkzip and other archivers for the .zip archive > > format. > > is is better than infozip's zip? Obviously so, because it can handle RAR archives. The only RAR archiver that we have in Debian is in non-free. 7-zip is GPL'd, IIRC. -- Brian M. Carlson <[EMAIL PROTECTED]> <http://decoy.wox.org/~bmc> 0x560553E7 I came to MIT to get an education for myself and a diploma for my mother. pgp6LyfXYELYM.pgp Description: PGP signature
Bug#160706: RFP: buildd -- Debian package build daemon
Package: wnpp Version: unavailable; reported 2002-09-12 Severity: wishlist * Package name: buildd Version : 2001.09.07 Upstream Author : James Troup / Roman Hodek * URL : http://m68k.debian.org/buildd/getting.html * License : GPL v2 Description : Debian package build daemon This is the long-awaited build daemon which automagically builds Debian packages for architectures where there is no binary. It takes the source and downloads the build-dependencies on its own. A must-have for the serious package builder. See <http://buildd.debian.org/> for a real example in action. - Description ends here - Note to packager: there is already a debian/ directory in CVS. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stonewall 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set) -- Brian M. Carlson <[EMAIL PROTECTED]> <http://decoy.wox.org/~bmc> 0x560553E7 "Once they go up, who cares where they come down? That's not my department." -- Werner von Braun pgphg7BcEEABq.pgp Description: PGP signature
Bug#154428: RFP: ae -- Anthony's Editor -- a tiny full-screen editor
On Fri, Jul 26, 2002 at 03:09:03PM -0600, Adam Conrad wrote: > > -Original Message- > > From: Brian M. Carlson [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 26, 2002 3:00 PM > > > > Package: wnpp > > Version: N/A; reported 2002-07-26 > > Severity: wishlist > > > > * Package name: ae > > Version : 962-26 (19960200-26) > > Upstream Author : Anthony Howe > > I was planning on filing an ITP and re-introducing ae into unstable > really soon, actually. I'd like to get the really annoying "long line" > bug fixed before I do, but I suppose that can wait until after I've > uploaded it. That's great. It doesn't matter to me whether you fix the bugs first or not. There are some patches in some closed bugs that you might want to look at. (54501, 73605). I think bug 12695 about the two digit year in the version number is something that you might want to think about before you do an upload. > If no one else wants this, I'll be happy to retitle the bug and upload a > new version, and start working on old bugs (they were all closed when it > was removed from the archive, but there seems to be a lot there to > reopen and look at) I was told in bug 147137 that "[n]o Debian developer was interested in maintaining ae in unstable", so I think you're pretty safe. -- Brian M. Carlson <[EMAIL PROTECTED]> <http://decoy.wox.org/~bmc> 0x560553E7 "There is such a fine line between genius and stupidity." - David St. Hubbins, "Spinal Tap" pgppwfAoXAbDP.pgp Description: PGP signature
Bug#154428: RFP: ae -- Anthony's Editor -- a tiny full-screen editor
Package: wnpp Version: N/A; reported 2002-07-26 Severity: wishlist * Package name: ae Version : 962-26 (19960200-26) Upstream Author : Anthony Howe * URL : http://ftp.debian.org/dists/potato/main/binary-i386/base/ae_962-26.deb http://ftp.debian.org/dists/potato/main/source/base/ae_962-26.diff.gz http://ftp.debian.org/dists/potato/main/source/base/ae_962-26.dsc http://ftp.debian.org/dists/potato/main/source/base/ae_962.orig.tar.gz * License : GPL-like Description : ae: Anthony's Editor -- a tiny full-screen editor ae is a tiny full-screen text editor with both modal (vi-like) and modeless (emacs-like) modes, determined by an ae.rc config file. . Keybindings are configurable in the configuration file. The default config file is /etc/ae.rc, but another configuration file is provided in /etc/ae/*.rc, as an alternate example. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stonewall 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US (ignored: LC_ALL set) -- no debconf information -- Brian M. Carlson <[EMAIL PROTECTED]> <http://decoy.wox.org/~bmc> 0x560553E7 QOTD: "Sure, I turned down a drink once. Didn't understand the question." pgpVL88kzeb0Q.pgp Description: PGP signature
Bug#154294: ITP]: amavis-ng -- AMaViS - "Next Generation"
On Thu, Jul 25, 2002 at 10:31:31PM +0200, Hilko Bengen wrote: > As the main author, I have provided a debian/ subdirectory in the > source tarball. It can be downloaded from: > http://prdownloads.sourceforge.net/amavis/amavis-ng-0.1.4.tar.gz > > A preliminary Debian package can be downloaded from: > http://prdownloads.sourceforge.net/amavis/amavis-ng_0.1.4_i386.deb I looked at this package. Part of the dependencies read as follows: Recommends: unarj (>=2.63), unrar, zoo, arc, lha None of those packages are in main. In fact, they are all in non-free, except for arc, which does not exist in unstable. Yet you state the Section: as admin. This is a violation of Policy 2.1.2 which states, in part: In addition, the packages in _main_ * must not require a package outside of _main_ for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-_main_ package), Therefore, it is acceptable for this package to be in contrib, or possibly for you to place those as Suggests:, although we should not encourage the use of non-free software. You could alternatively remove those dependencies if they are not essential to the working of the program. > Lintian gives me a lot of error messages, mostly > perl-module-in-core-directory, binary-without-manpage, and > suidregister-used-in-maintainer-script; they will of course be fixed > before uploading. This is one of those errors lintian just won't warn you about. ;-) Otherwise, I'm elated, and I'm waiting for the package to be released. -- Brian M. Carlson <[EMAIL PROTECTED]> <http://decoy.wox.org/~bmc> 0x560553E7 /* now make a new head in the exact same spot */ -- Larry Wall in cons.c from the perl source code pgpxZ3azb55Qd.pgp Description: PGP signature
Bug#79131: Is anyone packaging this?
Package: wnpp Version: N/A; reported 2002-07-03 Followup-For: Bug #79131 This bug has been stagnant since 2002-12-08. That is 1 year and 207 days. Well, except for the spam. I'd like to know if this ITP bug is going to pan out, or if I should stop holding my breath and file an RFP bug. Thanks. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux stonewall 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US (ignored: LC_ALL set) -- no debconf information -- Brian M. Carlson <[EMAIL PROTECTED]> <http://decoy.wox.org/~bmc> 0x560553E7 Universities are places of knowledge. The freshman each bring a little in with them, and the seniors take none away, so knowledge accumulates. pgpDCQx7PUjSN.pgp Description: PGP signature