RFS: fig2sxd
Dear debian mentors, for my graphics conversion utility fig2sxd, which is included in debian unstable, I am looking for a new sponsor. The version in debian is 0.13, while the most recent version available from http://fig2sxd.sf.net/ is 0.16. I would appreciate if the updated version could be uploaded. Thank you for your help. Alexander Bürger
Re: RFS: fig2sxd
Alexander Bürger wrote: for my graphics conversion utility fig2sxd, which is included in debian unstable, I am looking for a new sponsor. I can do that, but you need to point me please to the package sources (URI to the *.dsc file). -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
IANADD (but I feel like arguing anyway) On Mon, 11 Dec 2006 11:34:02 -0700 Warren Turkal [EMAIL PROTECTED] wrote: On Monday 11 December 2006 03:42, Patrick Schönfeld wrote: * debian/copyright: * IMO you should mention the ones who previous did packaging The software was previously packaged for Debian by Karl Sackett, Brian Mays, and others. This package is a complete reengineering of of the packaging to bring the package up to current standards. It is not based on prior packaging except for compatibility of package names. On this I disagree with Patrick. IMHO, the copyright file is no place for history. This information is contained in the changelog already. Since you revamped the package completely, you are the only author and copyright holder for the debian directory material, that's what has to go into copyright (as well as which license you put on these files). The previous maintainers would have to be listed here only if you were still using their work. Regards, Thibaut.
Re: netcdf packages
On Monday 11 December 2006 15:53, Warren Turkal wrote: New version (3.6.2-beta4~pre1) at [1]. This version sorts before the last one so you will have to manually remove the prior packages I posted if you used apt* to install them. Here's the changelog entry. netcdf (3.6.2-beta4~pre1) unstable; urgency=low . * New maintainer: Warren Turkal * Completely repackaged with cdbs (closes: #378610). * Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, #278739) * Combined all libs into one package. * Upstream version fixes inconsistent manpage (closes: #353332) * Touched up descriptions on some of the packages I just wanted to ping everyone for comments on the package @ [1]. I will cut a -1 release ready for sponsored upload if I don't hear anything else. wt [1]http://www.penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: netcdf packages
Thibaut Paumard wrote: On Mon, 11 Dec 2006 11:34:02 -0700 Warren Turkal [EMAIL PROTECTED] wrote: [...] The software was previously packaged for Debian by Karl Sackett, Brian Mays, and others. This package is a complete reengineering of of the packaging to bring the package up to current standards. It is not based on prior packaging except for compatibility of package names. On this I disagree with Patrick. IMHO, the copyright file is no place for history. This information is contained in the changelog already. Well, at last we do not disagree to each other. In general i think copyright's existence is to honor every bodies copyright and licensing. Therefore *if* the package is based on previous packages i feel like it is for history. But if not (if 99,999% of the work were done by Warren) ... see next paragraph. Since you revamped the package completely, you are the only author and copyright holder for the debian directory material, that's what has to go into copyright (as well as which license you put on these files). Yes, thats the fact i wasn't aware of when i wrote my comments. In this case i agree with you. If - and only if - Warren totally reworked everything (exceptions for the name of the package and changelog) it shouldn't be necessary (IMHO!) to list previous authors there. But it would be nicer to do so. Greets Patrick signature.asc Description: OpenPGP digital signature
Bad practice to make a package depend on a specific kernel image
Is it bad practice to make a package depend on a specific kernel image? This might be a loaded question, but I was just trying to get an opinion. All of the boxes using this package are of the same configuration. Jerry DuVal Pace Systems Group, Inc. 800.624.5999 www.Pace2020.com smime.p7s Description: S/MIME cryptographic signature
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006, Neil Williams wrote: What are the problems with CDBS (apart from debian/control automation)? Badly-documented black-box on something that we have to understand well to sponsor or work with. This is Not Acceptable IMO. Which kinds of packages have the most trouble with a CDBS method? Any. I do not sponsor anything CDBS, nor would I co-maintain CDBS packages. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad practice to make a package depend on a specific kernel image
On Tue, 12 Dec 2006 13:40:47 -0500 Jerry DuVal [EMAIL PROTECTED] wrote: Is it bad practice to make a package depend on a specific kernel image? This might be a loaded question, but I was just trying to get an opinion. All of the boxes using this package are of the same configuration. Why would this be needed? Is the package always going to be replaced whenever the specific kernel image is upgraded? What happens if the kernel image is upgraded and the package has to be removed - what functionality is lost? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp1RWReBHB99.pgp Description: PGP signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Dec 12, 2006 at 01:40:47PM -0500, Jerry DuVal wrote: Is it bad practice to make a package depend on a specific kernel image? This might be a loaded question, but I was just trying to get an opinion. All of the boxes using this package are of the same configuration. Generally speaking, yes it is bad practice. kernel modules packages do, but they are tightly coupled to the kernel (could be considered part of it), so it is ok. Probably for anything else it is a case of bad programming. At the very least they should try to run, notice the missing feature because the kernel is less than version X and gracefully exit. We live in a strange world though, there is probably some other rare reasons why you could depend on a specific version. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: LiE computer algebra for Lie groups
Please post the complete URL to your .dsc file, it's easier for potential sponsors to grab it. http://www.aei.mpg.de/~peekas/debian/lie_2.2.2-1.dsc FWIW: Dear DD's, pending minor comments below, I believe this package is close to ready for sponsorhip. I have fixed all the remaining problems, except for: And, a final comment, please give some license statement concerning the packaging itself, in the copyright file. I have been unable to contact the authors so far, so it's probably best to keep things in non-free for the time being. Or did you mean a statement about my copyright? What's appropriate in this case? Best, Kasper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: LiE computer algebra for Lie groups
On Tue, Dec 12, 2006 at 10:35:00PM +0100, Kasper Peeters wrote: Please post the complete URL to your .dsc file, it's easier for potential sponsors to grab it. http://www.aei.mpg.de/~peekas/debian/lie_2.2.2-1.dsc FWIW: Dear DD's, pending minor comments below, I believe this package is close to ready for sponsorhip. I have fixed all the remaining problems, except for: And, a final comment, please give some license statement concerning the packaging itself, in the copyright file. I have been unable to contact the authors so far, so it's probably best to keep things in non-free for the time being. Or did you mean a statement about my copyright? What's appropriate in this case? Yes, that's what I meant. Your work in packaging has a copyright and thus needs a license. Given upstream's licensing status I recommend you go for a permissive license, to avoid the possibility that upstream+packaging is undistributable. BSD should be OK. So, something like the following, right at the end of the copyright file: Packaging is Copyright 2006 - Kasper Peeters It can be distributed under the terms of the so and so license, available at /usr/share/licences/so-and-so in a Debian system. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Re: RFS: LiE computer algebra for Lie groups
Your work in packaging has a copyright and thus needs a license. Ok, all done. DD's, can I get sponsorship for http://www.aei.mpg.de/~peekas/debian/lie_2.2.2-1.dsc (all other files in http://www.aei.mpg.de/~peekas/debian/) Thanks! Best, Kasper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Dec 12, 2006 at 01:40:47PM -0500, Jerry DuVal wrote: Is it bad practice to make a package depend on a specific kernel image? This might be a loaded question, but I was just trying to get an opinion. All of the boxes using this package are of the same configuration. What if the kernels on those machines are installed by hand? Thus, dpkg won't know about them. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: netcdf packages
On Tuesday 12 December 2006 10:06, schönfeld / in-medias-res.com wrote: Yes, thats the fact i wasn't aware of when i wrote my comments. In this case i agree with you. If - and only if - Warren totally reworked everything (exceptions for the name of the package and changelog) it shouldn't be necessary (IMHO!) to list previous authors there. But it would be nicer to do so. The fact is I downloaded the source and started from a dh_make to package the source. I didn't use any code from the old package because it is a pre-debhelper package. I actually have had to compile it locally for a while (for F90 support) and used that experience for developing the package. So, should the prior package author attribution be included or not? I would like to address this issue ASAP. wt -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science
Re: Bad practice to make a package depend on a specific kernel image
On Wed, 2006-12-13 at 08:14 +1100, Craig Small wrote: On Tue, Dec 12, 2006 at 01:40:47PM -0500, Jerry DuVal wrote: Is it bad practice to make a package depend on a specific kernel image? This might be a loaded question, but I was just trying to get an opinion. All of the boxes using this package are of the same configuration. Generally speaking, yes it is bad practice. kernel modules packages do, but they are tightly coupled to the kernel (could be considered part of it), so it is ok. Probably for anything else it is a case of bad programming. At the very least they should try to run, notice the missing feature because the kernel is less than version X and gracefully exit. We live in a strange world though, there is probably some other rare reasons why you could depend on a specific version. The basic problem is that presence of a kernel package does not imply presence of the desired patch/enabled feature in that package, nor that the running kernel is the installed one. What you need to do is twofold: depend upon the presence of the ABI required, if you can get the kernel package maintainers to add an appropriate provides: entry, and secondly handle the absence of that ABI gracefully at runtime. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: netcdf packages
Warren Turkal wrote: So, should the prior package author attribution be included or not? not in copyright, no. if you upload your new packages, we can go then through them piece by piece tomorrow. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
On Tuesday 12 December 2006 16:22, Daniel Baumann wrote: not in copyright, no. I removed that paragraph. if you upload your new packages, we can go then through them piece by piece tomorrow. Uploaded to [1]. Some notes of things already addressed: 1) I have already deleted watch.ex post 1~pre2. 2) I have already deleted netcdf.doc-base.EX post 1~pre2. wt [1]http://penguintechs.org/~wt/debian/netcdf/ -- Warren Turkal, Research Associate III/Systems Administrator Colorado State University, Dept. of Atmospheric Science -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netcdf packages
Warren Turkal wrote: netcdf (3.6.2-beta4~pre1) unstable; urgency=low . * New maintainer: Warren Turkal * Completely repackaged with cdbs (closes: #378610). * Enabled Fortran 90 support by compiling with Gfortran. (closes: #219592, #278739) Hi Warren, Regarding the use of gfortran -- are you aware that g77 and gfortran produce object code with somewhat incompatible ABIs? See my previous emails on this topic here: http://lists.debian.org/debian-science/2005/09/msg00071.html http://lists.debian.org/debian-science/2006/06/msg5.html Unfortunately it seems that no one is yet endeavoring to make sure there is a reasonable transition plan for libraries from g77 to gfortran. (Possibly I will try to do something about this post-etch, if I have time and once gfortran supports all the g77 intrinsics.) For that reason I recommend that all FORTRAN libraries, when possible, be compiled with g77 for the moment. If netcdf does not have any functions returning REAL (single-precision) or COMPLEX, maybe building netcdf with gfortran is OK though. best regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
