Bug 510841

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.

Thanks, I'll try and bug upstream about this.  Has octave been rebuilt to 3.2.0 in rawhide yet?

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.

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.

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.

(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.

(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.

(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.

(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.

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.

Can you attach the octave-forge-20090607-includes.patch?  It wasn't in the patch included above.  Thanks.

Created attachment 355775 [details]
Add missing include to main/parallel-2.0.0/src/pserver.cc

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

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

(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.

(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?

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

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.

(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.

Created attachment 358694 [details]
stdout/stderr of rpmbuild -a

Builds fine (albeit with zillion of errors) here on Rawhide

(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.

> 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)

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.

ppc64 build completes:

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

as does ppc one:

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

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?

(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).

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

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.
--

(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.

(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).

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).

(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

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.

(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

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

can we add "make check" to the octave rpm build?

(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.

(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".

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.

(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.

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.

* 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.