Re: RFS: transmission
On Wed, 13 Sep 2006 18:45:59 +0100 James Westby [EMAIL PROTECTED] wrote: On (12/09/06 01:03), Philipp Benner wrote: Hello, I need a sponsor for this package: * Package name: transmission There already is an ITP posted 170 days ago, but no one is responding. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358878 I wouldn't say that noone is responding. It is a little slow, but it seems like there is work being done. Have you contacted the people in the report? If you wish to take over you should really contact them and then either with their permission, or after some time with no response, take over the ITP. I tried to contact Leo Antunes because he seems to be responsible for uploading the package but didn't get a response. Although no one responds to the question of Joshua Kwan which he posted a month ago. I don't think that the mentioned license problems are relevant. This package includes some source files with different licenses but all are free. (See the copyright file for details) If the information there is accurate then it looks OK to me, but I am definately not an expert. However I can't see a license for the Sparkle stuff for instance. You are right, but since this Sparkle stuff is not interesting for debian I just deleted it in the source package. You also assert copyright of the Debian packaging, does this mean it is not based on the other packages of the software? I repackaged transmission since the other packages are not up to date and had some errors. Regards, Philipp Benner -- pub 1024D/EB88E930 2004-02-08 pgp.mit.edu C1A8 2BE8 7587 215D 91EB B015 A95C 3BEC EB88 E930 signature.asc Description: PGP signature
Re: RFS: transmission
On (14/09/06 11:51), Philipp Benner wrote: On Wed, 13 Sep 2006 18:45:59 +0100 James Westby [EMAIL PROTECTED] wrote: I wouldn't say that noone is responding. It is a little slow, but it seems like there is work being done. Have you contacted the people in the report? If you wish to take over you should really contact them and then either with their permission, or after some time with no response, take over the ITP. I tried to contact Leo Antunes because he seems to be responsible for uploading the package but didn't get a response. Although no one responds to the question of Joshua Kwan which he posted a month ago. Well there's no record of your contact in that bug report. It's a good idea to Cc: the bug report when you ping a maintainer so it is clear to others what is happening. I would suggest you email both of the people involved and Cc: the bug report, stating that you have packages ready and would like to upload. Also state that if you do not hear anything in 1/2 weeks you will upload. If you are happy for co-maintenance then say that as well. Be aware that the two people are DD's, and so if you approach them right they might just agree to co-maintenance and upload for you. I would suggest having clean packages to do this though. Ask here for a package check if you want before you do it. I don't think that the mentioned license problems are relevant. This package includes some source files with different licenses but all are free. (See the copyright file for details) If the information there is accurate then it looks OK to me, but I am definately not an expert. However I can't see a license for the Sparkle stuff for instance. You are right, but since this Sparkle stuff is not interesting for debian I just deleted it in the source package. Did you do all the things necessary for repackaging an upstream tarball? You also assert copyright of the Debian packaging, does this mean it is not based on the other packages of the software? I repackaged transmission since the other packages are not up to date and had some errors. That's fine then. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PAE enabled kernels
Derek \The Monkey\ Wueppelmann [EMAIL PROTECTED] writes: Hello, Is there any other way to get a PAE enabled kernel (from either stable or backports) other than recompiling a custom kernel? Everything I've read so far indicates that the only way to go about this is grab the kernel source and enabled the high mem option and recompile the kernel. -- o) Derek Wueppelmann (o (D . [EMAIL PROTECTED] D). ((` http://www.monkeynet.ca ( ) ` If you only need 4GB ram+swap but only 4GB address space per process and zou have a 64bit cpu then use the 64bit kernel with 32bit userland. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
Steve Langasek [EMAIL PROTECTED] writes:
If you want to declare a strict versioned dependency from an arch: all
package to an arch: any package... don't do that, because it will break
under binNMUs. :)
I only know of one simple way to handle this:
arch:any provides any-package-1.2-3
arch:all depends any-package-1.2-3
Some people try to use
arch:all depends any-package (= version), any-package ( next-version)
The BIG problem is how to get the next-version. Say you have version
1.2-3. A binNMU would be 1.2-3+b1, a security release would be
1.2-3etch1 (unless there was a binNMU).
Now, next-version must allow 1.2-3+b1 to be installed but not
1.2-3etch1. But 1.2-3etch1 is 1.2-3+b1 making this somewhat
impossible.
% dpkg --compare-versions 1.2-3etch1 1.2-3+b1 echo yes
yes
Maybe this would work:
any-package (= ${source:version}) | any-package (= ${source:version}+b1),
any-package (= ${source:version}) | any-package ( ${source:version}+c)
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bastet (updated package)
On (14/09/06 00:08), Nacho Barrientos Arias wrote: Firstly, i apologize for this massive email sending to the mail list. No problem. I uploaded to mentors a new package [1] which fix all this issues (and the suggested by James). I'm pending upstream's confirmation about license terms. [1] http://mentors.debian.net/debian/pool/main/b/bastet/bastet_0.41-4.dsc The debian/copyright is better, but you still need the clarification of the license issues. I see you are trying to get this though, thanks. Apart from this the package looks good to me, and should be ready for upload if the license issues are sorted. Unfortuanately I can't upload, as I am not a DD. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: isomd5sum (formerly anaconda)
On (13/09/06 21:20), Ryan Finnie wrote: Greetings James, Thank you for the recommendations. On 9/13/06, James Westby [EMAIL PROTECTED] wrote: * Your debian/copyright needs more work, see http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html debian/copyright brought up to standard, more on that below... Not quite, you missed md5.c. This file is not under the same license as the rest of the package, and must be documented in debian/rules. Also I'm not sure of -- /* Copyright 2001 Red Hat, Inc.*/ /* Michael Fulbright [EMAIL PROTECTED]*/ -- Is Michael Fulbright supposed to be asserting Copyright as well, or is he just the author or similar? I believe that he is not, but I wonder if anyone else has any opinions. * Consider using a python framework for managing the byte compilation, either python-support or python-central. pyisomd5sum is a .so extension, not a .py module, so byte compilation is not necessary/possible. Indeed. My apologies. I decided to separate the isomd5sum directory of the Anaconda sources into its own tarball. As a result, there is now only one copyright holder (Red Hat, Inc), and one license (GPLv2). More on that is at http://www.finnie.org/software/isomd5sum/ (this also serves as a home page for the broken-out tarball). This is not the normal method of doing this, but I think that it still works. It makes it slightly harder for whoever picks up the package if you were to go AWOL though. Also if you are repackaging can you remove the .cvsignore files from the resulting tarball? There is also no need to have the current maintainer documented in debian/copyright, that's what debian/control is for. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bastet (updated package)
Date: Thu, 14 Sep 2006 12:35:13 +0100 James Westby [EMAIL PROTECTED] wrote: Hi James, -- snip -- The debian/copyright is better, but you still need the clarification of the license issues. I see you are trying to get this though, thanks. Upstream didn't answer yet, but, in my opinion, COPYING file shows clearly that Bastet is licensed under the GPL2, probably upstream will say the same. Apart from this the package looks good to me, and should be ready for upload if the license issues are sorted. Unfortuanately I can't upload, as I am not a DD. Thank you for your nice work reviewing my package. I would be glad if someone uploaded this package for me :-) Bye, -- bye, - Nacho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE : RE : RFS: lisaac
On (13/09/06 21:59), PICCA Frédéric-Emmanuel wrote: * I'm a little wary of the copyright situation, as I can't see any statements within the package. It appears the license is DFSG free, but you need to include any and all copyright statements in your debian/copyright. If there are none you should contact upstream to add them. I checked I put the copyright in debian/copyright. So their is no copyright problem. Have a nice day.
Re: RFS: transmission
On Thu, 14 Sep 2006 12:21:18 +0100 James Westby [EMAIL PROTECTED] wrote: On (14/09/06 11:51), Philipp Benner wrote: On Wed, 13 Sep 2006 18:45:59 +0100 James Westby [EMAIL PROTECTED] wrote: I wouldn't say that noone is responding. It is a little slow, but it seems like there is work being done. Have you contacted the people in the report? If you wish to take over you should really contact them and then either with their permission, or after some time with no response, take over the ITP. I tried to contact Leo Antunes because he seems to be responsible for uploading the package but didn't get a response. Although no one responds to the question of Joshua Kwan which he posted a month ago. Well there's no record of your contact in that bug report. It's a good idea to Cc: the bug report when you ping a maintainer so it is clear to others what is happening. I would suggest you email both of the people involved and Cc: the bug report, stating that you have packages ready and would like to upload. Also state that if you do not hear anything in 1/2 weeks you will upload. If you are happy for co-maintenance then say that as well. Be aware that the two people are DD's, and so if you approach them right they might just agree to co-maintenance and upload for you. Thanks for your help. I sent a message to the bug report. I would suggest having clean packages to do this though. Ask here for a package check if you want before you do it. I don't think that the mentioned license problems are relevant. This package includes some source files with different licenses but all are free. (See the copyright file for details) If the information there is accurate then it looks OK to me, but I am definately not an expert. However I can't see a license for the Sparkle stuff for instance. You are right, but since this Sparkle stuff is not interesting for debian I just deleted it in the source package. Did you do all the things necessary for repackaging an upstream tarball? Thanks for the hint, I created a get-orig-source rule which handles the repackaging and explained what I modified in debian/README.Debian-source. You also assert copyright of the Debian packaging, does this mean it is not based on the other packages of the software? I repackaged transmission since the other packages are not up to date and had some errors. That's fine then. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- pub 1024D/EB88E930 2004-02-08 pgp.mit.edu C1A8 2BE8 7587 215D 91EB B015 A95C 3BEC EB88 E930 signature.asc Description: PGP signature
Re: Need help with kernel module building
Marc Haber wrote:
Which component of the build process is supposed to handle the control
file generation
module-assistant. You will see that debian/rules includes some files
from /usr/share/modass. The documentation for module-assistant has the
details.
as I suppose that the module build process actually
needs a control and a control.modules file, right?
For example, let's say that I'm packaging a module named foo, with source
package name foo. This is described by a control file as usual. It builds
a binary package called foo-source, which essentially only contains an
archive of the module sources in /usr/src/foo.tar.bz2. The actual module is
built from the contents of that archive. The control.modules.in file is
processed by the module-assistant rules during module build, and renamed
to control (by replacing placeholders with the actual kernel version).
This generated control file describes the resulting binary module package
foo-module-${KVERS}.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
On Thu, Sep 14, 2006 at 12:55:47PM +0200, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: If you want to declare a strict versioned dependency from an arch: all package to an arch: any package... don't do that, because it will break under binNMUs. :) I only know of one simple way to handle this: arch:any provides any-package-1.2-3 arch:all depends any-package-1.2-3 Some people try to use arch:all depends any-package (= version), any-package ( next-version) The BIG problem is how to get the next-version. Say you have version 1.2-3. A binNMU would be 1.2-3+b1, a security release would be 1.2-3etch1 (unless there was a binNMU). In the Great Scheme, these were supposed to become 1.2-3+etch1 instead of 1.2-3etch1 so that security NMUs would sort higher than binNMUs... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: weplab -- tool designed to break WEP keys
Hello James and Adam, James Westby James Westby [EMAIL PROTECTED]: On (12/09/06 13:53), Adam Cécile (Le_Vert) wrote: I am looking for a sponsor for my package weplab. * Package name: weplab Looks good to me. I would be glad if someone uploaded this package for me. I can't I'm afraid, but maybe someone else would like to. Good work, uploaded. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden, am 8. Oktober 2006 * Info: http://www.linux-info-tag.de/ *
Re: RFS: isomd5sum (formerly anaconda)
On 9/14/06, James Westby [EMAIL PROTECTED] wrote: Not quite, you missed md5.c. This file is not under the same license as the rest of the package, and must be documented in debian/rules. (I'm assuming you mean debian/copyright, not debian/rules.) Doh. Is there boilerplate text for non-copyright public domain text, or should I basically put the first paragraph of md5.c's comments in debian/copyright? Is Michael Fulbright supposed to be asserting Copyright as well, or is he just the author or similar? I believe that he is not, but I wonder if anyone else has any opinions. He's just the author, and is already documented as such. Red Hat employees assign copyright to the company for code they produce. I decided to separate the isomd5sum directory of the Anaconda sources into its own tarball. As a result, there is now only one copyright holder (Red Hat, Inc), and one license (GPLv2). More on that is at http://www.finnie.org/software/isomd5sum/ (this also serves as a home page for the broken-out tarball). This is not the normal method of doing this, but I think that it still works. It makes it slightly harder for whoever picks up the package if you were to go AWOL though. Yes, this is not the ideal situation, but the legal requirements makes it pretty daunting to maintain copyright notices for the entire anaconda project, especially considering 95% of the code won't be used (actually, 99.65% by source tarball size). If isomd5sum were constantly updated, I wouldn't have considered this, but the source has been feature complete and relatively untouched for years now. Nonetheless, I will consider it an active duty to check for changes in upstream. Also if you are repackaging can you remove the .cvsignore files from the resulting tarball? This will be done. There is also no need to have the current maintainer documented in debian/copyright, that's what debian/control is for. I agree, but that paragraph is listed as a good example in http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html ... Ryan Finnie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bastet (updated package)
Nacho Barrientos Arias Nacho Barrientos Arias [EMAIL PROTECTED]: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bastet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bastet/bastet_0.41-4.dsc I would be glad if someone uploaded this package for me. Good work. Uploaded. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden, am 8. Oktober 2006 * Info: http://www.linux-info-tag.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bastet (updated package)
Date: Thu, 14 Sep 2006 22:52:50 +0200 Erik Schanze [EMAIL PROTECTED] wrote: Good work. Uploaded. Thank you Erik. -- bye, - Nacho -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: isomd5sum (formerly anaconda)
On (14/09/06 13:44), Ryan Finnie wrote: On 9/14/06, James Westby [EMAIL PROTECTED] wrote: Not quite, you missed md5.c. This file is not under the same license as the rest of the package, and must be documented in debian/rules. (I'm assuming you mean debian/copyright, not debian/rules.) Indeed, sorry. Doh. Is there boilerplate text for non-copyright public domain text, or should I basically put the first paragraph of md5.c's comments in debian/copyright? Just stick the whole header in there really. It explains the whole situation well. That file is in many packages in the archive, and that is what I have encouraged other people to do. He's just the author, and is already documented as such. Red Hat employees assign copyright to the company for code they produce. Ok, that's fine then. Thanks for the clarification. This is not the normal method of doing this, but I think that it still works. It makes it slightly harder for whoever picks up the package if you were to go AWOL though. Yes, this is not the ideal situation, but the legal requirements makes it pretty daunting to maintain copyright notices for the entire anaconda project, especially considering 95% of the code won't be used (actually, 99.65% by source tarball size). If isomd5sum were That's understandable. constantly updated, I wouldn't have considered this, but the source has been feature complete and relatively untouched for years now. Nonetheless, I will consider it an active duty to check for changes in upstream. I meant that it's not usual to create a new tarball and host it. Usually the upstream tarball is still referenced, and there are just somethings added to the package. Then the maintainer recreates the .orig.tar.gz each new upstream version. I don't see that it matters either way though, so whatever you prefer. There is also no need to have the current maintainer documented in debian/copyright, that's what debian/control is for. I agree, but that paragraph is listed as a good example in http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html Ah true. I hadn't noticed that. I'll just consider it a small mistake in an otherwise excellent post. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: isomd5sum (formerly anaconda)
isomd5sum_11.1.0.95-1 has been updated in-place. Removed .cvsignore, added md5.c information to debian/copyright, removed unnecessary current maintainer line from debian/copyright. James, thanks a lot for your help. Ryan Finnie On 9/14/06, James Westby [EMAIL PROTECTED] wrote: Just stick the whole header in there really. It explains the whole situation well. That file is in many packages in the archive, and that is what I have encouraged other people to do. Done. I agree, but that paragraph is listed as a good example in http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html Ah true. I hadn't noticed that. I'll just consider it a small mistake in an otherwise excellent post. I have removed that line, because as you mentioned, it's largely unnecessary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Building a program with the library shipped in Debian, not in orig.tar.gz
Dear Mentors I am preparing Debian packages for EMBOSS (the European Molecular Biology Software Suite, www.emboss.org), and I run in the following problem: EMBOSS is shipped and built with its own copy of libpcre. As a result, the EMBOSS Debian package contains some files wich are also in the libpcre Debian package, and they conflict together. I would like to try to build EMBOSS with the libpcre from Debian, but I could not figure out how to do. Can somebody give me hints? EMBOSS uses the auto(make|conf) system - I do not understand the difference yet. The files for libpcre such as pcre.h are in the same directory as the files for a core EMBOSS library. I need to tell the program to use /usr/include/pcre.h and so on, but I have no clue on how to do this (I never programmed in C). Is there a documentation for solving that kind of problem? I beleive it should be recurrent in Debian... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building a program with the library shipped in Debian, not in orig.tar.gz
Am Freitag, den 15.09.2006, 09:46 +0900 schrieb Charles Plessy: I am preparing Debian packages for EMBOSS (the European Molecular Biology Software Suite, www.emboss.org), and I run in the following problem: EMBOSS is shipped and built with its own copy of libpcre. As a result, the EMBOSS Debian package contains some files wich are also in the libpcre Debian package, and they conflict together. I would like to try to build EMBOSS with the libpcre from Debian, but I could not figure out how to do. Can somebody give me hints? EMBOSS uses the auto(make|conf) system - I do not understand the difference yet. I guess, it will be more problematic to begin to change the Makefile.am/.in or configure.ac/.in files in the Debian package, than just making the custom changes to use Debian pcre-package. If EMBOSS compiles with a common libpcre-version, upstream should add the necessary checks for an libpcre installation and prefer this version, instead of the shipped pcre-version. But for you, this will be overkill I guess (you know, where the libpcre-header files are installed, so you don't need such checks). The files for libpcre such as pcre.h are in the same directory as the files for a core EMBOSS library. I need to tell the program to use /usr/include/pcre.h and so on, but I have no clue on how to do this (I never programmed in C). In short: Change #include pcre.h to #include pcre.h and see 'man pcre-config' for the compilation arguments (you only need, what --libs tells you in the linking step, IIRC). Is there a documentation for solving that kind of problem? I beleive it should be recurrent in Debian... HTH and regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Licence issues
I'm making a package for internal use, but want to get it right in case I decide to try to get it uploaded. Some of the upstream code has the license quoted at the end. That license IMHO makes the code not only non-free but actually not source-distributable. However, that code is unmaintained upstream and not used in the version i'm compiling. Should I repackage upstream's tarball to exclude it? The license: /* * * RADIUS -- Remote Authentication Dial In User Service * * COPYRIGHT (c) 1992, 1993, 1994, 1995, 1996 * THE REGENTS OF THE UNIVERSITY OF MICHIGAN AND MERIT NETWORK, INCORPORATED * ALL RIGHTS RESERVED * * PERMISSION IS GRANTED TO USE, COPY, CREATE DERIVATIVE WORKS AND REDISTRIBUTE * THIS SOFTWARE AND SUCH DERIVATIVE WORKS IN BINARY FORM ONLY FOR ANY PURPOSE, * SO LONG AS NO FEE IS CHARGED, AND SO LONG AS THE COPYRIGHT NOTICE ABOVE, THIS * GRANT OF PERMISSION, AND THE DISCLAIMER BELOW APPEAR IN ALL COPIES MADE; AND * SO LONG AS THE NAME OF THE UNIVERSITY OF MICHIGAN IS NOT USED IN ANY * ADVERTISING OR PUBLICITY PERTAINING TO THE USE OR DISTRIBUTION OF THIS * SOFTWARE WITHOUT SPECIFIC, WRITTEN PRIOR AUTHORIZATION. * * THIS SOFTWARE IS PROVIDED AS IS, WITHOUT REPRESENTATION FROM THE UNIVERSITY * OF MICHIGAN AS TO ITS FITNESS FOR ANY PURPOSE, AND WITHOUT WARRANTY BY THE * UNIVERSITY OF MICHIGAN OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING * WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * A PARTICULAR PURPOSE. THE REGENTS OF THE UNIVERSITY OF MICHIGAN SHALL NOT BE * LIABLE FOR ANY DAMAGES, INCLUDING SPECIAL, INDIRECT, INCIDENTAL, OR * CONSEQUENTIAL DAMAGES, WITH RESPECT TO ANY CLAIM ARISING OUT OF OR IN * CONNECTION WITH THE USE OF THE SOFTWARE, EVEN IF IT HAS BEEN OR IS HEREAFTER * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * For a License to distribute source code or to charge a fee for the program * or a product containing the program, contact MERIT at the University of * Michigan: * * [EMAIL PROTECTED] * * [This version puts NO LIMITS on the use. It grants the right to create * DERIVATIVE WORKS. The user may copy and distribute the code in the form * received AND DERIVATIVE WORKS, so long as no fee is charged. If copies are * made, our copyright notice and the disclaimer must be included on them. USE * THIS VERSION WITH CARE. THIS VERSION VERY LIKELY WILL KILL ANY POTENTIAL * FOR LATER COMMERCIALIZATION OF THE SOFTWARE.] -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
