On 12/06/2016 10:51 PM, Orion Poplawski wrote:
The hdf5 update prompted me to (perhaps too hastily) update octave to
4.2 in
rawhide as well. This unfortunately has led to the need to rework the octave
package build/install macros. I have what I hope is a fix building now
(octave-4.2.0-2). I've tested it with a simple octave package on x86_64 - it
might fail with more complex ones and/or on different arches. I'll be doing
rebuilds in the morning.
More to come later, but I need to go to bed now.
I hope I've *finally* got the magic right now with 4.2.0-8 (eighth time is the
charm) after running up against a still not yet understood issue with gzip
handling on non-x86 arches. It's building now and will try again when it
completes.
Current octave packages should build fine as is. However, behind the scenes
%octave_pkg_build now re-tars the unpacked build directory as octave's pkg
build command now requires a tarball, and then unpacks into the octave pkg
build directory for debuginfo generation. However, if you have a simple
package that doesn't need to modify
the source at all and currently does:
%prep
%setup -q -n %{octpkg}-%{version}
%build
%octave_pkg_build
Instead you can do:
%prep
%setup -qcT
%build
%octave_pkg_build -T
and this avoids the initial unpack by %setup and repack by %octave_pkg_build
On the down side, it appears that swig does not support API changes with
octave 4.2. I've filed
https://github.com/swig/swig/issues/847 to get that
ball rolling. Help welcome from swig/octave people. But at the moment a
number of packages are FTBFS due to this, including mathgl and COPASI.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301
http://www.nwra.com