Spec URL: http://mattdm.org/misc/fedoraextras/calc.spec SRPM URL: http://mattdm.org/misc/fedoraextras/calc-2.12.1.6-3.fc7.mattdm.src.rpm Description: Calc is an arbitrary precision C-like arithmetic system that is a calculator, an algorithm-prototyper, and a mathematical research tool. Calc comes with a rich set of built-in mathematical and programmatic functions.
Hold on a bit -- there's a new version out, and a few issues I've fixed.
Okay, updated. New: Spec URL: http://mattdm.org/misc/fedoraextras/calc.spec SRPM URL: http://mattdm.org/misc/fedoraextras/calc-2.12.1.8-1.fc7.mattdm.src.rpm
A remark based on coarse visual inspection only The sources are LGPL'ed. Your spec 'BR: readline-devel'. -> Compiling/linking this package against readline will violate readline's GPL.
Oh, good point. It actually has an internal readline alternative it can use. I'll check with the author about the licensing and readline, and if there's no ability to make a change I'll modify it to not use readline. Thanks.
Oh, wait, no coffee yet this morning. The LGPL allows conversion to GPL, so technically I can do that without any upstream input. So really the consideration here comes down to how much using gnu readline benefits the program. Right now, since there's actually no dynamic library, using LGPL over GPL provides no benefit at all to anyone, so I might as well make the conversion. Further, it's probable that the calc library itself could remain under the gpl with just the calc command-line binary converted -- the best of both worlds. Because probably online the command-line util actually links against readline. (Or am I missing something there?)
(In reply to comment #5) > Oh, wait, no coffee yet this morning. The LGPL allows conversion to GPL, so > technically I can do that without any upstream input. Yes, AFAICT, _YOU_ could re-licence/re-publish the whole package under the GPL (With all implications of it - You'd be the upstream, shipping a derived product). Yet another solution would be not to link against readline. > Further, it's probable that the calc library itself could remain under the gpl > with just the calc command-line binary converted -- the best of both worlds. > Because probably online the command-line util actually links against readline. One would have to check the sources for details - Unfortunately this package applies a pretty ugly and not easy to understand build/make-system > (Or am I missing something there?) I don't think so.
Yeah, rather than using autoconf, it does a similar bunch of tests in its makefile. Good times.
Okay, updated without readline: Spec URL: http://mattdm.org/misc/fedoraextras/calc.spec SRPM URL: http://mattdm.org/misc/fedoraextras/calc-2.12.1.8-2.fc7.mattdm.src.rpm There's another possible license issue here, with the license of the included md5.c file: /* *********************************************************************** ** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. ** ** ** ** License to copy and use this software is granted provided that ** ** it is identified as the "RSA Data Security, Inc. MD5 Message- ** ** Digest Algorithm" in all material mentioning or referencing this ** ** software or this function. ** ** ** ** License is also granted to make and use derivative works ** ** provided that such works are identified as "derived from the RSA ** ** Data Security, Inc. MD5 Message-Digest Algorithm" in all ** ** material mentioning or referencing the derived work. ** ** ** ** RSA Data Security, Inc. makes no representations concerning ** ** either the merchantability of this software or the suitability ** ** of this software for any particular purpose. It is provided "as ** ** is" without express or implied warranty of any kind. ** ** ** ** These notices must be retained in any copies of any part of this ** ** documentation and/or software. ** *********************************************************************** */ which is basically like the BSD license except the wording about "all material mentioning or referencing" is a bit stronger than the BSD license's "in the documentation and/or other materials" phrase. Honestly, I'm a little bit fuzzy on why the 3-clause BSD license is GPL-compatible but the 4-clause one isn't, and which category this falls into.
Oh, wait, it's worse than that. Ahh, licensing is such joy. See this discussion regarding a similar problem in apr-utils. http://mail-archives.apache.org/mod_mbox/apr-dev/200610.mbox/%3c87y7rpw8g3.fsf@thosu.err.no%3e
Okay, so upstream is now aware of and working on the above issue. I expect a pretty quick resolution.
Was there ever any resolution to this?
I need to make an updated package. The md5 module is either removed in the current upstream release or will be. Haven't decided whether to link against readline or not. (Really, it needs some code reworking so that the library and the command-line tool aren't so intertwined -- there's no reason at all for the *library* to need readline.)
Finally had some time to work on this. New packages in http://mattdm.org/misc/fedoraextras/ I patched out md5 (should be okay -- it's redistributable, just not linkable with GPL/LGPL code) and made a flag which patches from LGPL->GPL if you enable readline, which I've made the default, because it's so handy. Still working with upstream for the better solution -- splitting the command line interface (which benefits from Readline and not from being LGPL) from the library (the opposite). But that may take some time, and I don't think that's a reason to hold up getting this in Fedora.
What about replacing the MD5 code with a GPL-compatible implementation instead of zapping it entirely?
I've discussed that with upstream. I'd actually suggested one alternative (http://sourceforge.net/project/showfiles.php?group_id=42360&package_id=34443), and the maintainer's lawyer's advice was that that was licensed in an unclear way which made it even more restrictive and less free. I just now discovered the mhash library, and perhaps code from that would be suitable -- or a future version of calc could just use the library directly. However, in a private e-mail, the author noted to me that since md5 has been show to have some weakness, he considers it not very important to have and even suggested just removing it to resolve the problem. So, following that advice seemed to be the best bet for now.
I just confirmed with the upstream author that the next upstream version will remove md5 functionality. Reimplementing it will be explored in future releases.
Did anything ever happen here? Or were the packages in comment 13 ready for review? I guess the License: tag(s) will need fixing in any case.
I'm working on packages for calc-2.12.2. This upstream release removes the questionable md5 code and, bonus, dynamically links libraries. Should be ready real soon now. In the meantime, you can look at the packages in the link at comment 13 -- if the release number starts with "0", there are known problems (and probably unknown ones) that I'm still working on (but review comments are still welcome). Right now I have it with an option in the spec file which, if "1", converts from LGPL to GPL and links with readline. This is intended to be temporary -- right now, the code is such that there's not a good distinction between the command-line utility and the library. In theory, all readline-dependent functionality could be split out from the library and only the command-line calc program linked against that; then we'd have LGPLv2 for the libs and GPL for the actual program. But that's for the future. Personally, I really value having real readline support (the built-in alternative is nothing close) more than having the libraries LGPL, but upstream really wants the basic libs to be LGPL, which is an understandable position. So I'm taking suggestions for how to set the flag by default.
Okay, so, I made some time to work on this. The packages you see there now (calc-2.12.2-0.5.fc8.mattdm.gpl.src.rpm et al) look pretty good to me and are ready for review. Thanks.
Now updated to calc 2.12.2.1.
- This should have a calc- prefix: Source2: COPYING-GPL - The -devel package should require the -libs package, not the main package. - MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. the -devel and -libs packages do not have a %defattr line
Thank you very much. > - This should have a calc- prefix: > Source2: COPYING-GPL Even when it's the unmodified, canonical GPL file? > - The -devel package should require the -libs package, not the main package. Thanks. Actually, probably more files should be moved to the libs package, too. > the -devel and -libs packages do not have a %defattr line I believe the one from %files carries through. But sure, I'll fix it. :)
Okay, new packages up. Fixed a couple more things I noticed while I was at it. Thanks again. * Wed Sep 05 2007 Matthew Miller <mattdm> - 2.12.2.1-2 - allow customlib functions with -DCUSTOM. - made stdrc subpackage for standard resource files and scripts. - only ship internal line-editor keybindings file if we're not using readline - fix some packaging issues as follows (thanks Till Maas). - Prefix COPYING-GPL source file with "calc" to avoid file conflicts. Just in case. :) - defattr for all files sections. - make the devel package rely on calc-libs, not calc. This is largely academic since the calc libs and binaries are not as clearly separated as they should be -- a future upstream version will improve this, though, so we might as well do the right thing. - make calc-libs not require calc proper; theoretically this should be true.
Wait, hold off on that one. More coming.
No, I take that back. I thought I'd discovered that the new version had detangled the readline-using parts of the command-line tool better from the library, but turns out not. Let's just go ahead with what I have now and I'll work with upstream further on that.
I am confused looking, matt -- GPL or LGPL -- the website states: The calc program is free. It is distributed under the GNU Lesser General Public License. Calc is open software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation version 2.1 of the License. see: http://isthe.com/chongo/tech/comp/calc/
GPL, as per section 3 of LGPL v2.1, so we can link against readline. This is a temporary situation I'm working on dealing with upstream. Alternately, there's logic in the spec file to build without readline and remain LGPL. I'm open to making that the default if we have other non-GPL-compatible free software packages in Fedora that people are interested in linking against calc. That uses the much-inferior internal line editing routines, though, and makes the command-line program noticeably less nice to use, so I'd prefer to not. The upstream possibilities are 1) modify the source to be libedit/editline compatible (or fix whatever it is in libedit's readline-interface compatibility layer that isn't working), or 2) split the package so the math and language libraries don't need to be linked against the line input code -- then, the command line "calc" program can by GPL and the libraries (which have no real use for readline) can stay LGPL. #1 is probably relatively trivial; #2 manageable but less so. If you'd like to help with either, that'd be awesome.
So, yeah. Anything else? If the package looks basically good/clean, I'm eager to get it in and work on further improvements from there.
I didn't look at this yet, however * Keep timestamp - When you use "cp" or "install", add "-p" option to keep timestamp * Parallel make - Support parallel make when possible, otherwise write a comment in the spec file which shows that the Makefile does not support parallel make * Permission - Please explain why you chose the permission "0444", not "0644". * Defattr - We now recommend "%defattr(-.root.root,-)" * rebuild - mock build fails at least on ppc http://koji.fedoraproject.org/koji/taskinfo?taskID=163593 Please post the full URL of your spec/srpm so that we can easily find which spec/srpm are the newest (and should be reviewed).
Thanks for the comments. > * Keep timestamp fixed. > * Parallel make fixed (it doesn't work). > * Permission Following upstream. I changed the executables from 555 to 755; I have no really strong feelings about changing or leaving the rest, but I have a slight preference for staying the way they have it since it seems like unnecessary clutter to change it in the spec file. I can ask upstream about it and see if they have any objection to changing the defaults in the make file. > * Defattr fixed. > * rebuild > - mock build fails at least on ppc Will look into. There's updated packages at: http://mattdm.org/misc/fedoraextras/calc.spec http://mattdm.org/misc/fedoraextras/calc-2.12.2.1-2.fc8.mattdm.gpl.src.rpm but I still have to look at the ppc build issue.
Okay, builds fine on ppc64. I've tracked down the bug to what looks like some wrong assumptions about integer sizes in the makefile. I'll get that fixed. (Package review guidelines indicate that we can go ahead in the meantime; I'll file the separate bug for that as soon as possible.) So.... http://mattdm.org/misc/fedoraextras/calc.spec http://mattdm.org/misc/fedoraextras/calc-2.12.2.1-4.fc8.mattdm.gpl.src.rpm
For 2.12.2.1-4: * rpmlint - rpmlint complains about lots of undefined-non-weak-symbols. ----------------------------------------------------- $ rpmlint calc-libs calc-libs.i386: W: no-documentation calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1 _zeroval_ calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1 conf calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1 _oneval_ calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcustcalc.so.2.12.2.1 qalloc (and so many) calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcalc.so.2.12.2.1 cust calc-libs.i386: W: undefined-non-weak-symbol /usr/lib/libcalc.so.2.12.2.1 rl_readline_name (and so many) ------------------------------------------------------ This will cause linkage failure against these libraries and cannot be accepted (if you want to provide -devel subpackage). * Documents - For this package, the "core" package is calc-libs. i.e. all other packages depend on calc-libs, and even one can try to install only calc-libs and try not to install calc. So there can be the case in which no documents like license texts are installed, which is not proper. In short, license texts and so on must be moved to -libs subpackage.
Huh, I had no idea rpmlint could do that. Thanks, I'll track that down and fix it. Should documents be just moved to libs, or duplicated there?
Fixing the link issues is turning out to be little bit of a pain (patches to the code). Will have an update tomorrow.
Okay. New version fixes that by disabling the custom function interface -- the two libraries are very messily interlinked, and the custom interface is by definition an optional feature. I'll work with upstream in getting that fixed eventually. http://mattdm.org/misc/fedoraextras/calc.spec http://mattdm.org/misc/fedoraextras/calc-2.12.2.1-7.fc8.mattdm.gpl.src.rpm
Okay. ---------------------------------------------------- This package (calc) is APPROVED by me ----------------------------------------------------
Thanks for your help, everyone. New Package CVS Request ======================= Package Name: calc Short Description: Arbitrary precision arithmetic system and calculator Owners: mattdm Branches: F-7 InitialCC: Cvsextras Commits: yes
cvs done.
Package Change Request ====================== Package Name: calc New Branches: F-8 Please branch for F-8. Thank you.