Bug 676858
| Summary: | octave bundles libraries | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominik 'Rathann' Mierzejewski <dominik> |
| Component: | octave | Assignee: | Orion Poplawski <orion> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | alex, code, orion, private, susi.lehtola |
| Target Milestone: | --- | Keywords: | Tracking |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-03-16 10:20:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 504493 | ||
|
Description
Dominik 'Rathann' Mierzejewski
2011-02-11 15:26:48 UTC
Blocking FE-Legal for possible amos issue. I don't see any real evidence that the amos files are derived from the TOMS files. The statement about being an "improved version" of the algorithms almost certainly means that it implements a faster way of doing the same math, not that there is any other relationship, and I'm inclined to assume that unless there is real evidence to the contrary. The bundling is a real issue though. Lifting FE-Legal Is it octave upstream that is doing the bundling (i.e. are these bundles in the regular tarball)? Odd considering that Octave is an official GNU project and I thought that they frown upon bundling too. At least fftpack is not used, since FFTW is preferred over it. The same may apply to the other ones as well... (In reply to comment #2) > I don't see any real evidence that the amos files are derived from the TOMS > files. I think that amos library is derived from the TOMS library. See Reference URI. Reference: http://pl.digipedia.org/usenet/thread/12697/9625/ http://octave.1599824.n4.nabble.com/Fwd-OctDev-libcruft-amos-nonfree-Bessel-code-in-Octave-td4632360.html http://octave.1599824.n4.nabble.com/Can-we-freely-use-AMOS-in-Octave-td4642557.html http://www.netlib.org/toms/644 http://www.netlib.org/amos/cairy.f This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Based on http://octave.1599824.n4.nabble.com/Can-we-freely-use-AMOS-in-Octave-td4642557.html, I think it is safe to consider AMOS as being in the Public Domain. The bundling is still an issue. I've sent a message to the netlib folks to see if they can make it any easier to download the files. Yeesh. Any progress in unbundling? Looks like current version bundles even more stuff. libgui/qterminal -> QTerminal (https://github.com/qterminal/qterminal) liboctave/cruft/ Faddeeva (http://ab-initio.mit.edu/wiki/index.php/Faddeeva_Package) slatec-err (http://www.netlib.org/slatec/err/) slatec-fn -> slatec-fnlib (http://www.netlib.org/slatec/fnlib/) amos, odepack, quadpack and ran(d)lib are still there. da(spk|srt|ssl) seem to have moved to http://iguana.cs.ucsb.edu/wordpress/?page_id=224#linux Bah, one step forward, two back it seems. Actually, the qterminal in octave seems more like http://code.google.com/p/qterminal/ Ping? I think there's no point in keeping this bug open as obviously unbundling isn't happening. The bundled codes are declared in Provides, so packaging guidelines are being followed at least. |