Bug 1413450 - octave-devel-4.2 rpm macros contain undefined value
Summary: octave-devel-4.2 rpm macros contain undefined value
Alias: None
Product: Fedora
Classification: Fedora
Component: octave
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-16 03:08 UTC by Dmitrij S. Kryzhevich
Modified: 2017-01-24 10:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-01-24 10:07:29 UTC
Type: Bug

Attachments (Terms of Use)

Description Dmitrij S. Kryzhevich 2017-01-16 03:08:45 UTC
Description of problem:
New octave 4.2 devel subpackage in macros.octave contain %{octave_tar_suffix} value which is not defined in %octave_pkg_install procedure. It's defined in %octave_pkg_build what seems to be not enough.

Version-Release number of selected component (if applicable):

Comment 1 Orion Poplawski 2017-01-16 03:59:28 UTC
Is there some problem you are running into?

%octave_pkg_build defines the macro in rpm, so it is available later any other use.

Comment 2 Dmitrij S. Kryzhevich 2017-01-16 05:32:47 UTC
Yes. Here in mathgl %octave_pkg_build is not called. Bindings are built with cmake itself from swig .i files. But installation of octave module is done in a way of tar file copied in somewhere only. No registration, no debuginfo extraction, no stripping (what results in a *very* big file size). So to use install macro here looks like not so bad idea.

It worked in 4.0 and it fails in 4.2.

Comment 3 Dmitrij S. Kryzhevich 2017-01-23 09:05:05 UTC
If it's mathgl-related only may be I should define this var in mathgl.spec in some kind of %global ? That could be a solution I suppose.

(if it really triggers *only* mathgl)

Comment 4 Orion Poplawski 2017-01-23 15:50:05 UTC
Well, it like is only mathgl that call %octave_pkg_install without calling %octave_pkg_build.  A workaround would be to do

%global octave_tar_suffix %{octave_host}-%{octave_api}

It's actually a tricky problem to solve because it's conditional on whether or not the package is noarch or not, which is easiest to do in the %octave_pkg_build lua macro.  I may convert %octave_pkg_install to lua, but that will take a little time.

Comment 5 Dmitrij S. Kryzhevich 2017-01-24 07:41:54 UTC
Well. That's not so simple. There are too much differences in install scripts between 4.0 and 4.2. Have to handle them by hands.
OK, I'l try.

Comment 6 Dmitrij S. Kryzhevich 2017-01-24 10:07:29 UTC
Here is a part of spec:

%if 0%{?fedora} >= 21 && 0%{?fedora} < 26
%global mgl_octarch_dir %{_tmppath}/%{name}-%{version}-%{release}.%{_arch}
%global mgl_octarch_name %{octpkg}-%{version}.tar.gz
%if 0%{?fedora} >= 26
%global octave_tar_suffix %{octave_host}-%{octave_api}
%global mgl_octarch_dir %{_builddir}/%{buildsubdir}/build/
%global mgl_octarch_name %{octpkg}-%{version}-%{octave_tar_suffix}.tar.gz


%if 0%{?with_octave}
mkdir -p %{mgl_octarch_dir}
cp %{_target_platform}_serial/lang/%{octpkg}.tar.gz %{mgl_octarch_dir}/%{mgl_octarch_name}

And it works.
So, if %octave_pkg_install will be dramatically changed ping me please.

Note You need to log in before you can comment on or make changes to this bug.