This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 510841 - Update to 20090607
Update to 20090607
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: octave-forge (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Alex Lancaster
Fedora Extras Quality Assurance
:
Depends On: 520518
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-11 09:12 EDT by Susi Lehtola
Modified: 2009-09-07 22:21 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-07 22:21:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to spec file in devel branch (6.61 KB, patch)
2009-07-11 09:15 EDT, Susi Lehtola
no flags Details | Diff
Add missing include to main/parallel-2.0.0/src/pserver.cc (429 bytes, patch)
2009-07-31 03:37 EDT, Susi Lehtola
no flags Details | Diff
stdout/stderr of rpmbuild -a (233.42 KB, text/plain)
2009-08-26 06:09 EDT, Matěj Cepl
no flags Details

  None (edit)
Description Susi Lehtola 2009-07-11 09:12:27 EDT
octave-forge should be updated to the newest release, but there are a few issues with it:


ann_wrap.cpp: In member function 'void octave_swig_type::install_global()':
ann_wrap.cpp:1197: error: 'curr_sym_tab' was not declared in this scope
ann_wrap.cpp:1197: error: 'link_to_global_variable' was not declared in this scope
ann_wrap.cpp:1204: error: 'symbol_record' was not declared in this scope
ann_wrap.cpp:1204: error: 'sr' was not declared in this scope
ann_wrap.cpp:1204: error: 'global_sym_tab' was not declared in this scope
ann_wrap.cpp: In function 'void SWIG_Octave_SetModule(void*, swig_module_info*)':
ann_wrap.cpp:2110: error: 'curr_sym_tab' was not declared in this scope
ann_wrap.cpp:2110: error: 'link_to_global_variable' was not declared in this scope
ann_wrap.cpp: In function 'octave_value_list Fann(const octave_value_list&, int)':
ann_wrap.cpp:9617: error: 'curr_sym_tab' was not declared in this scope
ann_wrap.cpp:9617: error: 'link_to_global_variable' was not declared in this scope
ann_wrap.cpp: At global scope:
ann_wrap.cpp:853: warning: 'void Swig::swig_register_director(octave_swig_type*, void*, Swig::Director*)' declared 'static' but never defined
make[2]: *** [ann.oct] Error 1

The Octave header octave/variables.h used to provide these, but not anymore in Octave 3.2.0. (I can't find these anywhere in the Octave headers.)

Also, main/parallel-2.0.0/src/pserver.cc is also missing a #include <iostream>.
Comment 1 Susi Lehtola 2009-07-11 09:15:47 EDT
Created attachment 351342 [details]
Patch to spec file in devel branch

This patch updates the spec file from 3.0.5 to 3.2.0.

Doesn't build at the moment, though.
Comment 2 Alex Lancaster 2009-07-19 07:08:09 EDT
Thanks, I'll try and bug upstream about this.  Has octave been rebuilt to 3.2.0 in rawhide yet?
Comment 3 Alex Lancaster 2009-07-19 07:12:53 EDT
Ah, looks like it was cancelled:

http://koji.fedoraproject.org/koji/getfile?taskID=1471062&name=build.log

Perhaps you could temporarily remove the .pdf from the %files list in rawhide so we could get it to build, then we can try to build the newer octave-forge against the new octave 3.2.0.
Comment 4 Alex Lancaster 2009-07-19 07:19:23 EDT
Looks like it's been reported a couple of times upstream:

http://thread.gmane.org/gmane.comp.gnu.octave.devel/1827
http://thread.gmane.org/gmane.comp.gnu.octave.devel/2222

but no responses to those threads from the developers.
Comment 5 Alex Lancaster 2009-07-19 07:29:58 EDT
Also where did you find the octave bundle "tar.gz" for your local build?  I can't find it on:

http://sourceforge.net/projects/octave/files/

Did you have to generate the tarball yourself from the individual packages?  I seem to recall that they were discontinuing the bundle tarball.
Comment 6 Susi Lehtola 2009-07-19 10:15:09 EDT
(In reply to comment #3)
> Ah, looks like it was cancelled:
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=1471062&name=build.log
> 
> Perhaps you could temporarily remove the .pdf from the %files list in rawhide
> so we could get it to build, then we can try to build the newer octave-forge
> against the new octave 3.2.0.  

The problem's not that. The problem is that currently octave 3.2.0 doesn't compile on i686, due to some malloc bug in IIRC pdfetex. The same spec compiles on other architectures, on F11 they all work out fine.

(In reply to comment #5)
> Also where did you find the octave bundle "tar.gz" for your local build?  I
> can't find it on:
> 
> http://sourceforge.net/projects/octave/files/
> 
> Did you have to generate the tarball yourself from the individual packages?  I
> seem to recall that they were discontinuing the bundle tarball.  

I generated the tarball using the instructions in the specfile: I took the bundle and removed the non-free stuff.
Comment 7 Alex Lancaster 2009-07-19 15:51:07 EDT
(In reply to comment #6)

> The problem's not that. The problem is that currently octave 3.2.0 doesn't
> compile on i686, due to some malloc bug in IIRC pdfetex. The same spec compiles
> on other architectures, on F11 they all work out fine.

I mean, just disable the generation of the pdf altogether, so it never calls pdfetex.

> (In reply to comment #5)
> > Also where did you find the octave bundle "tar.gz" for your local build?  I
> > can't find it on:
> > 
> > http://sourceforge.net/projects/octave/files/
> > 
> > Did you have to generate the tarball yourself from the individual packages?  I
> > seem to recall that they were discontinuing the bundle tarball.  
> 
> I generated the tarball using the instructions in the specfile: I took the
> bundle and removed the non-free stuff.  

Hmm, I couldn't find a tarball of the bundle for version 20090607 on that above sourceforge site.
Comment 8 Susi Lehtola 2009-07-19 17:36:38 EDT
(In reply to comment #7)
> (In reply to comment #6)
> 
> > The problem's not that. The problem is that currently octave 3.2.0 doesn't
> > compile on i686, due to some malloc bug in IIRC pdfetex. The same spec compiles
> > on other architectures, on F11 they all work out fine.
> 
> I mean, just disable the generation of the pdf altogether, so it never calls
> pdfetex.

Yeah, that would be the best option. I didn't note an easy way to do it, however, so I didn't do anything.

The source tar ships AFAIK with all of the pdfs necessary, so there shouldn't be any reason to regenerate them.

> > (In reply to comment #5)
> > > Also where did you find the octave bundle "tar.gz" for your local build?  I
> > > can't find it on:
> > > 
> > > http://sourceforge.net/projects/octave/files/
> > > 
> > > Did you have to generate the tarball yourself from the individual packages?  I
> > > seem to recall that they were discontinuing the bundle tarball.  
> > 
> > I generated the tarball using the instructions in the specfile: I took the
> > bundle and removed the non-free stuff.  
> 
> Hmm, I couldn't find a tarball of the bundle for version 20090607 on that above
> sourceforge site.  

It is there. It's under "Octave Forge", not "Octave Forge Packages" that is open on top.
Comment 9 Alex Lancaster 2009-07-20 14:37:45 EDT
(In reply to comment #8)

> Yeah, that would be the best option. I didn't note an easy way to do it,
> however, so I didn't do anything.
> 
> The source tar ships AFAIK with all of the pdfs necessary, so there shouldn't
> be any reason to regenerate them.

> > Hmm, I couldn't find a tarball of the bundle for version 20090607 on that above
> > sourceforge site.  
> 
> It is there. It's under "Octave Forge", not "Octave Forge Packages" that is
> open on top.  

Ah, I see it now.  I had looked under "Octave Forge" and saw the versions starting at 2008- and going down to 2004- and so assumed that there were no releases in 2009.  Turns out that they added "R" to the front of the version number which because of the way sf.net sorts, the latest was no longer at the top, but right down near the bottom of the list.  Grr.
Comment 10 Alex Lancaster 2009-07-31 00:22:57 EDT
For some reason Jesse Keating's rebuild of octave 3.2.0 as part of the F-12 Mass Rebuild was successful :

http://koji.fedoraproject.org/koji/buildinfo?buildID=124900

(perhaps something was fixed in the TeX backend and/or glibc as function of the rebuild as the error I got was a glibc malloc error)

I will now attempt to rebuild the matching octave-forge as best I can.
Comment 11 Alex Lancaster 2009-07-31 01:09:05 EDT
Can you attach the octave-forge-20090607-includes.patch?  It wasn't in the patch included above.  Thanks.
Comment 12 Susi Lehtola 2009-07-31 03:37:50 EDT
Created attachment 355775 [details]
Add missing include to main/parallel-2.0.0/src/pserver.cc
Comment 13 Alex Lancaster 2009-08-01 00:27:41 EDT
OK, well I made some progress.  The issue is with SWIG, and I got a fix from upstream SVN which gets the ann module building, but now have issues with the ftp package, which isn't yet fixed upstream.  See:

http://article.gmane.org/gmane.comp.gnu.octave.devel/2532

and build:

http://koji.fedoraproject.org/koji/getfile?taskID=1571408&name=build.log
Comment 14 Alex Lancaster 2009-08-19 02:31:13 EDT
Getting closer by disabling ftp as suggested by upstream, but now the 'parallel' package fails to build:

mkoctfile -s pserver.cc
pserver.cc:65: error: 'quitting_gracefully' was declared 'extern' and
later 'static' /usr/include/octave-3.2.2/octave/toplev.h:51: error: previous
declaration of 'quitting_gracefully'

I'm not sure if this is related to the SWIG problem or not.  Is this a
known issue?  The full build log is here:

http://koji.fedoraproject.org/koji/getfile?taskID=1613399&name=build.log

See also post on upstream list:

http://article.gmane.org/gmane.comp.gnu.octave.devel/2617
Comment 15 Orion Poplawski 2009-08-19 12:04:56 EDT
(In reply to comment #14)
> mkoctfile -s pserver.cc
> pserver.cc:65: error: 'quitting_gracefully' was declared 'extern' and
> later 'static' /usr/include/octave-3.2.2/octave/toplev.h:51: error: previous
> declaration of 'quitting_gracefully'
> 
> I'm not sure if this is related to the SWIG problem or not.  Is this a
> known issue?

It's not a swig generated file.  Looks like an API clash.  I would just remove the declaration in pserver.cc for now.  Nothing in there sets it, it just checks its value.
Comment 16 Alex Lancaster 2009-08-20 00:55:19 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > mkoctfile -s pserver.cc
> > pserver.cc:65: error: 'quitting_gracefully' was declared 'extern' and
> > later 'static' /usr/include/octave-3.2.2/octave/toplev.h:51: error: previous
> > declaration of 'quitting_gracefully'
> > 
> > I'm not sure if this is related to the SWIG problem or not.  Is this a
> > known issue?
> 
> It's not a swig generated file.  Looks like an API clash.  I would just remove
> the declaration in pserver.cc for now.  Nothing in there sets it, it just
> checks its value.  

Thanks, I reported it upstream and generated a new patch, but there are more errors, upstream is working on fixing it (I hope).  Meanwhile I removed the 'parallel' package as well as some other minor packages such as 'graceplot' which haven't yet been ported to Octave 3.2 to get the most of the octave-forge packages out there to at least fix the broken deps in rawhide.

Unfortunately just as the package is almost completed, I get this message during the final %install (after the %build all of the packages) during installing the financial-0.3.2 package:

+ cd ..
+ for dir in '*.[0-9]'
+ cd financial-0.3.2
+ make install TMPDIR=/var/tmp
+ DESTDIR=/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.x86_64
+ DISTPKG=redhat
mkdir (/var/tmp/oct-BuLyRd)
untar (/var/tmp/financial-0.3.2.tar.gz, /var/tmp/oct-BuLyRd)
panic: Illegal instruction -- stopping myself...
/bin/sh: line 41: 21088 Illegal instruction     octave -H -q
+ --no-site-file --eval
+ "warning('off','all');pkg('prefix','$octprefix','$archprefix');pkg('global_list',fullfile('$shareprefix','octave_packages'));pkg('local_list',fullfile('$sha\
reprefix','octave_packages'));pkg('install','-nodeps','-nodeps','-verbose','/var/tmp/financial-0.3.2.tar.gz');"
error: can't perform indexing operations for cs-list type
error: evaluating argument list element number 1
error: evaluating argument list element number 1
/bin/sh: line 25: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 26: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 27: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 28: /packinfo/dist_admin: No such file or directory
/bin/sh: line 29: /packinfo/dist_admin: No such file or directory
/bin/sh: line 30: /packinfo/dist_admin: No such file or directory
/bin/sh: line 31: /packinfo/dist_admin: No such file or directory
/bin/sh: line 32: /packinfo/dist_admin: No such file or directory
/bin/sh: line 33: /packinfo/dist_admin: No such file or directory
/bin/sh: line 34: /packinfo/dist_admin: No such file or directory
/bin/sh: line 35: /packinfo/dist_admin: No such file or directory
/bin/sh: line 36: /packinfo/dist_admin: No such file or directory
/bin/sh: line 37: /packinfo/dist_admin: No such file or directory
/bin/sh: line 38: /packinfo/dist_admin: No such file or directory
/bin/sh: line 39: /packinfo/dist_admin: No such file or directory
chmod: cannot access `/packinfo/dist_admin': No such file or directory

Has something changed in the way packages are installed?
Comment 17 Alex Lancaster 2009-08-20 19:43:32 EDT
Unfortunately this doesn't always die in the same place, making this difficult to debug, I did another build and it crashed installing the civil-engineering package:

http://koji.fedoraproject.org/koji/getfile?taskID=1616380&name=build.log

Googling, this seems to some kind of octave issue and it has been reported in previous versions of octave/octave-forge, see: Bug #197109.

I've reported it upstream, but no response as yet:

http://article.gmane.org/gmane.comp.gnu.octave.devel/2623
Comment 18 Dmitri A. Sergatskov 2009-08-25 08:09:42 EDT
I was able to build the package on Fedora 11 (with octave 3.2.2 from
rawhide as well). So I suspect the problem is elsewhere. The fact that 
it crashes at random places suggests that it might be a hardware
problem (bad memory, bad cooling), system running out of tmp space,
or something like that. 

Dmitri.
Comment 19 Alex Lancaster 2009-08-26 05:00:09 EDT
(In reply to comment #18)
> I was able to build the package on Fedora 11 (with octave 3.2.2 from
> rawhide as well). So I suspect the problem is elsewhere. The fact that 
> it crashes at random places suggests that it might be a hardware
> problem (bad memory, bad cooling), system running out of tmp space,
> or something like that. 

Thanks, that's good to know.  I've reported/summarised the issue on fedora-devel-list:

https://www.redhat.com/archives/fedora-devel-list/2009-August/msg01297.html

Hopefully we'll get some feedback from the infrastructure people.   One key test would be doing a mock build on a rawhide machine outside the Fedora build farm.
Comment 20 Matěj Cepl 2009-08-26 06:09:18 EDT
Created attachment 358694 [details]
stdout/stderr of rpmbuild -a

Builds fine (albeit with zillion of errors) here on Rawhide
Comment 21 Alex Lancaster 2009-08-26 06:36:59 EDT
(In reply to comment #20)
> Created an attachment (id=358694) [details]
> stdout/stderr of rpmbuild -a
> 
> Builds fine (albeit with zillion of errors) here on Rawhide  

Thanks, good to know.  So this means that the problem is probably related to the Fedora build machines in some way.
Comment 22 Alex Lancaster 2009-08-26 06:49:44 EDT
> Created an attachment (id=358694) [details]
> stdout/stderr of rpmbuild -a
> 
> Builds fine (albeit with zillion of errors) here on Rawhide  

Hmm, so a report on the list suggests they had a problem with i686, was your build a x86_64 or i686 machine?(In reply to comment #20)
Comment 23 Alex Lancaster 2009-08-26 07:09:30 EDT
OK, now I think we're getting somewhere.

Using koji, the x86_64 build appears to complete correctly (as verified by comment #20):

http://koji.fedoraproject.org/koji/taskinfo?taskID=1634667

but the i686 build has the install failures mentioned above:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1634671

which is also verified by a post on the list:

https://www.redhat.com/archives/fedora-devel-list/2009-August/msg01303.html

So the build failures may be related to the switch from i586 -> i686 on rawhide.
Comment 24 Alex Lancaster 2009-08-26 07:53:13 EDT
ppc64 build completes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1634748
Comment 25 Alex Lancaster 2009-08-26 16:06:41 EDT
as does ppc one:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1634728
Comment 26 Alex Lancaster 2009-08-28 18:04:17 EDT
I setup mock locally.  And I can now reliably generate an error in a mock build for the i686 architecture on my own personal machine.  After the mock build fails, I can enter the directory manually (after chroot-ing) and generate the error:


# make install TMPDIR=/var/tmp DESTDIR=/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.i386 DISTPKG=redhat
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
mkdir (/var/tmp/oct-A1qbfn)
untar (/var/tmp/java-1.2.6.tar.gz, /var/tmp/oct-A1qbfn)
error: memory exhausted or requested size too large for range of Octave's index type -- eval failed
structure has no member `local_packages'
error: called from `pkg>installed_packages' in file /usr/share/octave/3.2.2/m/pkg/pkg.m near line 1847, column 20

warning: lo_ieee_init: unrecognized floating point format!
error: can't perform indexing operations for cs-list type
error: evaluating argument list element number 1
error: evaluating argument list element number 1
/bin/sh: line 25: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 26: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 27: /packinfo/on_uninstall.m: No such file or directory
/bin/sh: line 28: /packinfo/dist_admin: No such file or directory
/bin/sh: line 29: /packinfo/dist_admin: No such file or directory
/bin/sh: line 30: /packinfo/dist_admin: No such file or directory
/bin/sh: line 31: /packinfo/dist_admin: No such file or directory
/bin/sh: line 32: /packinfo/dist_admin: No such file or directory
/bin/sh: line 33: /packinfo/dist_admin: No such file or directory
/bin/sh: line 34: /packinfo/dist_admin: No such file or directory
/bin/sh: line 35: /packinfo/dist_admin: No such file or directory
/bin/sh: line 36: /packinfo/dist_admin: No such file or directory
/bin/sh: line 37: /packinfo/dist_admin: No such file or directory
/bin/sh: line 38: /packinfo/dist_admin: No such file or directory
/bin/sh: line 39: /packinfo/dist_admin: No such file or directory
chmod: cannot access `/packinfo/dist_admin': No such file or directory
make: *** [install] Error 1


Note that on the very same machine the x86_64 build works fine.

I have no idea about how to debug this, anyone?
Comment 27 Alex Lancaster 2009-08-28 18:06:48 EDT
(In reply to comment #18)
> I was able to build the package on Fedora 11 (with octave 3.2.2 from
> rawhide as well). So I suspect the problem is elsewhere. The fact that 
> it crashes at random places suggests that it might be a hardware
> problem (bad memory, bad cooling), system running out of tmp space,
> or something like that. 

As I describe in comment #26 above, I suspect that you won't see this error unless you specifically request a build on rawhide using the i686 architecture (which is the new minimum processor Fedora builds for in F-12 and beyond).
Comment 28 Alex Lancaster 2009-08-28 18:20:08 EDT
So I started narrowing on the Makefile and traced the error to this Octave code (executing by "make install"):

octave -H -q --no-site-file --eval "warning('off','all');pkg('prefix','/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.i386//usr/share/octave/packages','/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.i386//usr/libexec/octave/packages');pkg('global_list',fullfile('/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.i386//usr/share/octave','octave_packages'));pkg('local_list',fullfile('/builddir/build/BUILDROOT/octave-forge-20090607-8.fc12.i386//usr/share/octave','octave_packages'));pkg('install','-nodeps','-nodeps','-verbose','/var/tmp/java-1.2.6.tar.gz');"
warning: lo_ieee_init: unrecognized floating point format!
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
warning: autoload: `./__java__.oct' is not an absolute file name
mkdir (/tmp/oct-Me8WmG)
untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)
error: memory exhausted or requested size too large for range of Octave's index type -- eval failed
Comment 29 Dmitri A. Sergatskov 2009-08-28 20:03:20 EDT
Post this to octave-forge mailing list. I do not have i686
handy to try to debug it myself.
Can you run these successfully at the command prompt:

mkdir (/tmp/oct-Me8WmG)
untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)

?

Dmitri.
--
Comment 30 Alex Lancaster 2009-08-28 21:44:19 EDT
(In reply to comment #29)
> Post this to octave-forge mailing list. I do not have i686
> handy to try to debug it myself.

With mock, you don't actually need i686, you can compile a i686 RPM on an x86_64 machine, see:

https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

> Can you run these successfully at the command prompt:
> 
> mkdir (/tmp/oct-Me8WmG)
> untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)

Will check.
Comment 31 Alex Lancaster 2009-08-28 21:49:32 EDT
(In reply to comment #30)

> > Can you run these successfully at the command prompt:
> > 
> > mkdir (/tmp/oct-Me8WmG)
> > untar (/var/tmp/java-1.2.6.tar.gz, /tmp/oct-Me8WmG)
> 
> Will check.  

Yes, I can successfully run these commands inside the octave prompt (these are octave calls, not Makefile commands).
Comment 32 Alex Lancaster 2009-08-28 21:51:40 EDT
Drilling into the octave script, the error comes when running:

pkg('install','-nodeps','-nodeps','-verbose','/var/tmp/java-1.2.6.tar.gz');

I'll post this to the octave-forge list (following up on our thread).
Comment 33 Alex Lancaster 2009-08-29 01:24:52 EDT
(In reply to comment #32)

> I'll post this to the octave-forge list (following up on our thread).  

Posted here:

http://article.gmane.org/gmane.comp.gnu.octave.devel/2653
Comment 34 Alex Lancaster 2009-08-31 03:15:16 EDT
Ok, partial success, finally got octave-forge to build by temporarily disabling the java package:

http://koji.fedoraproject.org/koji/buildinfo?buildID=129937

I'll work on:

1. adding back some of the other temporarily removed packages that have upstream fixes
2. adding missing packages reported by Dmitri
3. working on re-enabling java, but at least for now this will fix the broken deps in rawhide.
Comment 35 Alex Lancaster 2009-08-31 08:25:21 EDT
(In reply to comment #34)

> I'll work on:
> 
> 1. adding back some of the other temporarily removed packages that have
> upstream fixes

Added back parallel, now builds correctly.

> 2. adding missing packages reported by Dmitri

Tried enabling 'fixed'.  The patch from upstream SVN allows the package to build, but it fails at install-time with errors similar to the 'java' package, so disabled again for now, this will have to wait fixing of the java issue

+ cd fixed-0.7.10
+ make install TMPDIR=/var/tmp DESTDIR=/builddir/build/BUILDROOT/octave-forge-20090607-11.fc12.i386 DISTPKG=redhat
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
warning: lo_ieee_init: unrecognized floating point format!
mkdir (/var/tmp/oct-0ATLk6)
untar (/var/tmp/fixed-0.7.10.tar.gz, /var/tmp/oct-0ATLk6)

But I did get the vrml package working using patches from upstream SVN.

> 3. working on re-enabling java, but at least for now this will fix the broken
> deps in rawhide.  

More or less stuck on this.  Will leave disabled for the time being until such time as it can be made to install.

I would like to get to the bottom of the warning message that jwe identified:

warning: lo_ieee_init: unrecognized floating point format!

that keeps appearing all over the place.

Most recent build is here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=129969
Comment 36 Dmitri A. Sergatskov 2009-08-31 17:34:05 EDT
Currently dlamch in Fedora's lapack compiled with -Os optimization.
I recompiled it with "-ffloat-store -O0" (-ffloat-store may be redudndant)
and now dlamch looks OK.
After that Atlas has to be rebuild against this fixed lapack
(currently both atlas-sse and atlas-sse2 have the same problem, not
surprisingly), for some reason i cannot build atlas rpm...

Anyway, I filled the bug against lapack:

https://bugzilla.redhat.com/show_bug.cgi?id=520518
Comment 37 Dmitri A. Sergatskov 2009-09-01 18:10:28 EDT
can we add "make check" to the octave rpm build?
Comment 38 Alex Lancaster 2009-09-03 04:32:55 EDT
(In reply to comment #37)
> can we add "make check" to the octave rpm build?  

Probably should open up a bug on the octave component for that, so that the octave maintainer(s) will see it.
Comment 39 Orion Poplawski 2009-09-03 10:23:51 EDT
(In reply to comment #37)
> can we add "make check" to the octave rpm build?  

I'll look into it, but I'm not sure it would have helped that much:

+ make check                                                           
make -f octMakefile check                                  
make[1]: Entering directory `/builddir/build/BUILD/octave-3.2.2'          
make -C test check                                                           
make[2]: Entering directory `/builddir/build/BUILD/octave-3.2.2/test'
../run-octave --norc --silent --no-history ./fntests.m .   
warning: lo_ieee_init: unrecognized floating point format!    
Integrated test scripts:                                 
error: memory exhausted or requested size too large for range of Octave's index type -- execution of ./fntests.m failed      
make[2]: Leaving directory `/builddir/build/BUILD/octave-3.2.2/test'   
make[1]: Leaving directory `/builddir/build/BUILD/octave-3.2.2'
+ exit 0                        

So, while the error was there, the tests still "succeeded".
Comment 40 Dmitri A. Sergatskov 2009-09-03 12:10:13 EDT
I do not know make process well enough to understand 
why does it return 0. But even in this case a human would 
be able to see a build log with errors.
I actually just tried to build 3.2.3rc2  on fedora 11/ppc
and while the build succeeded, make check fails (crashed octave),
though with different errors.  

jwe just made a change so future versions of octave will
fail rather than issue warning here.
Comment 41 Alex Lancaster 2009-09-03 16:10:21 EDT
(In reply to comment #40)

> jwe just made a change so future versions of octave will
> fail rather than issue warning here.  

Do we know the underlying cause of this message yet?  Is it related to the lapack version.  I'm still not quite clear on what's happening here.
Comment 42 Alex Lancaster 2009-09-07 17:44:55 EDT
OK, with the fixed ATLAS, finally the java package in octave-forge builds and installs properly in i686 and the ieee warning messages have gone away:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1660968

I'm now doing a full chain-build of octave/octave-forge against the new ATLAS/lapack combination:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1661002

Once that finishes, I'll finally close this bug and we can open up new bugs to track the remaining subpackages that need to be fixed such as "fixed", "spanish" etc.
Comment 43 Alex Lancaster 2009-09-07 22:21:59 EDT
* Mon Sep  7 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 20090607-15
- Re-enable 'fixed' subpackage, builds now, this closes #510841
- ftp, graceplot and spanish packages need fixing upstream, leave
  disabled for the moment

http://koji.fedoraproject.org/koji/buildinfo?buildID=130989

Thanks to all for helping get octave 3.2 and the matching octave-forge into shape, especially Dmitri for tracking down those tricky numerical atlas/blas problems.  Any new build failures or packaging bugs etc. please open a new bug.

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