Upgrade Ubuntu Jaunty to Karmic (9.04 to 9.10) breaks self-compiled octave

[Uwe Dippel]

Alas, there it is gone, my octave ... :(

And this is why, after upgrade of Jaunty to Karmic:
$ which octave
/usr/local/bin/octave
$ /usr/local/bin/octave
/usr/local/bin/octave: error while loading shared libraries:
libumfpack.so.3.2.0: cannot open shared object file: No such file or
directory
$ locate libumfpack.so
/usr/lib/libumfpack.so
/usr/lib/libumfpack.so.5.4.0


And the version coming with 9.10 is 3.05 only.

FYI, in case you thought of upgrading.

Uwe

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Judd Storrs]

Karmic has octave 3.2.2 in universe. It's called "octave3.2" instead
of "octave". I've used it for about two weeks without problem.

--judd


On Fri, Oct 30, 2009 at 10:19 AM, Uwe Dippel <udippel@...> wrote:

> Alas, there it is gone, my octave ... :(
>
> And this is why, after upgrade of Jaunty to Karmic:
> $ which octave
> /usr/local/bin/octave
> $ /usr/local/bin/octave
> /usr/local/bin/octave: error while loading shared libraries:
> libumfpack.so.3.2.0: cannot open shared object file: No such file or
> directory
> $ locate libumfpack.so
> /usr/lib/libumfpack.so
> /usr/lib/libumfpack.so.5.4.0
>
>
> And the version coming with 9.10 is 3.05 only.
>
> FYI, in case you thought of upgrading.
>
> Uwe
>
> _______________________________________________
> Help-octave mailing list
> Help-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Uwe Dippel-5]

Judd Storrs wrote:
> Karmic has octave 3.2.2 in universe. It's called "octave3.2" instead
> of "octave". I've used it for about two weeks without problem.
>  

Yes, it is. Thanks, Judd!
Though it would be great to have a transitional package.
I wonder if there is a good reason to name it octave2.9 / octave3.0 /
octave3.2 instead of maybe just octave? So that it gets updated
automatically?

Uwe

>
> On Fri, Oct 30, 2009 at 10:19 AM, Uwe Dippel <udippel@...> wrote:
>  
>> Alas, there it is gone, my octave ... :(
>>
>> And this is why, after upgrade of Jaunty to Karmic:
>> $ which octave
>> /usr/local/bin/octave
>> $ /usr/local/bin/octave
>> /usr/local/bin/octave: error while loading shared libraries:
>> libumfpack.so.3.2.0: cannot open shared object file: No such file or
>> directory
>> $ locate libumfpack.so
>> /usr/lib/libumfpack.so
>> /usr/lib/libumfpack.so.5.4.0
>>
>>
>> And the version coming with 9.10 is 3.05 only.
>>
>> FYI, in case you thought of upgrading.
>>
>> Uwe
>>
>> _______________________________________________
>> Help-octave mailing list
>> Help-octave@...
>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>
>>    

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Uwe Dippel]

Judd Storrs wrote:
> Karmic has octave 3.2.2 in universe. It's called "octave3.2" instead
> of "octave". I've used it for about two weeks without problem.
>  

Yes, it is. Thanks, Judd!
Though it would be great to have a transitional package.
I wonder if there is a good reason to name it octave2.9 / octave3.0 /
octave3.2 instead of maybe just octave? So that it gets updated
automatically?

Uwe

>
> On Fri, Oct 30, 2009 at 10:19 AM, Uwe Dippel <udippel@...> wrote:
>  
>> Alas, there it is gone, my octave ... :(
>>
>> And this is why, after upgrade of Jaunty to Karmic:
>> $ which octave
>> /usr/local/bin/octave
>> $ /usr/local/bin/octave
>> /usr/local/bin/octave: error while loading shared libraries:
>> libumfpack.so.3.2.0: cannot open shared object file: No such file or
>> directory
>> $ locate libumfpack.so
>> /usr/lib/libumfpack.so
>> /usr/lib/libumfpack.so.5.4.0
>>
>>
>> And the version coming with 9.10 is 3.05 only.
>>
>> FYI, in case you thought of upgrading.
>>
>> Uwe
>>
>> _______________________________________________
>> Help-octave mailing list
>> Help-octave@...
>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>
>>    

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Uwe Dippel]

Uwe Dippel wrote:
> Judd Storrs wrote:
>> Karmic has octave 3.2.2 in universe. It's called "octave3.2" instead
>> of "octave". I've used it for about two weeks without problem.
>>  
>
> Yes, it is. Thanks, Judd!

Sorry, too early. Same problem in Karmic:

$ sudo apt-get install octave3.2
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  octave3.0-common libqt4-svg
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libqrupdate1 octave3.2-common
Suggested packages:
  octave3.2-info octave3.2-doc octave3.2-htmldoc octave3.2-headers
  octave3.2-emacsen
The following NEW packages will be installed:
  libqrupdate1 octave3.2 octave3.2-common
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.9MB of archives.
[...]
Selecting previously deselected package libqrupdate1.
(Reading database ... 204693 files and directories currently installed.)
Unpacking libqrupdate1 (from .../libqrupdate1_1.0.1-1_amd64.deb) ...
Selecting previously deselected package octave3.2-common.
Unpacking octave3.2-common (from
.../octave3.2-common_3.2.2-2build1_all.deb) ...
Selecting previously deselected package octave3.2.
Unpacking octave3.2 (from .../octave3.2_3.2.2-2build1_amd64.deb) ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Setting up libqrupdate1 (1.0.1-1) ...

Setting up octave3.2-common (3.2.2-2build1) ...
Setting up octave3.2 (3.2.2-2build1) ...
update-alternatives: using /usr/bin/octave-3.2.2 to provide
/usr/bin/octave (octave) in auto mode.
update-alternatives: using /usr/bin/octave-bug-3.2.2 to provide
/usr/bin/octave-bug (octave-bug) in auto mode.
octave-3.2.2: error while loading shared libraries: libumfpack.so.3.2.0:
cannot open shared object file: No such file or directory
dpkg: error processing octave3.2 (--configure):
 subprocess installed post-installation script returned error exit
status 127
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
 octave3.2
E: Sub-process /usr/bin/dpkg returned an error code (1)

Uwe

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Judd Storrs]

That's strange. On my system (Karmic x86_64) libumfpack3.2.0 isn't
referenced by /usr/bin/octave-3.2.2:

$ ldd /usr/bin/octave-3.2.2 | grep umf
        libumfpack.so.5.4.0 => /usr/lib/libumfpack.so.5.4.0 (0x00007f5949aad000)

Is it possible your /usr/local/bin/octave is hiding /usr/bin/octave
during install? Maybe you could temporarily rename
/usr/local/bin/octave to /usr/local/bin/octave-disable and try again?

--judd


$ ldd /usr/bin/octave-3.2.2
        linux-vdso.so.1 =>  (0x00007fffe9118000)
        liboctinterp.so => /usr/lib/octave-3.2.2/liboctinterp.so (0x00007fd6ca8db000)
        liboctave.so => /usr/lib/octave-3.2.2/liboctave.so (0x00007fd6c9bd5000)
        libcruft.so => /usr/lib/octave-3.2.2/libcruft.so (0x00007fd6c9948000)
        libumfpack.so.5.4.0 => /usr/lib/libumfpack.so.5.4.0 (0x00007fd6c9688000)
        libamd.so.2.2.0 => /usr/lib/libamd.so.2.2.0 (0x00007fd6c947e000)
        libcamd.so.2.2.0 => /usr/lib/libcamd.so.2.2.0 (0x00007fd6c9273000)
        libcolamd.so.2.7.1 => /usr/lib/libcolamd.so.2.7.1 (0x00007fd6c906b000)
        libcholmod.so.1.7.1 => /usr/lib/libcholmod.so.1.7.1 (0x00007fd6c8d6d000)
        libccolamd.so.2.7.1 => /usr/lib/libccolamd.so.2.7.1 (0x00007fd6c8b61000)
        libcxsparse.so.2.2.3 => /usr/lib/libcxsparse.so.2.2.3 (0x00007fd6c892f000)
        liblapack.so.3gf => /usr/lib/atlas/liblapack.so.3gf (0x00007fd6c7e44000)
        libblas.so.3gf => /usr/lib/atlas/libblas.so.3gf (0x00007fd6c7487000)
        libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0x00007fd6c718c000)
        libfftw3f.so.3 => /usr/lib/libfftw3f.so.3 (0x00007fd6c6e99000)
        libqrupdate.so.1 => /usr/lib/libqrupdate.so.1 (0x00007fd6c6c73000)
        libarpack.so.2 => /usr/lib/libarpack.so.2 (0x00007fd6c6a1f000)
        libftgl.so.2 => /usr/lib/libftgl.so.2 (0x00007fd6c67ee000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007fd6c6569000)
        libz.so.1 => /lib/libz.so.1 (0x00007fd6c6352000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fd6cb826000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007fd6c60e1000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fd6c5dab000)
        libreadline.so.5 => /lib/libreadline.so.5 (0x00007fd6c5b6d000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x00007fd6c592a000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fd6c5726000)
        libhdf5-1.6.6.so.0 => /usr/lib/libhdf5-1.6.6.so.0 (0x00007fd6c5403000)
        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007fd6c5117000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fd6c4e07000)
        libm.so.6 => /lib/libm.so.6 (0x00007fd6c4b83000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fd6c496c000)
        libc.so.6 => /lib/libc.so.6 (0x00007fd6c45fd000)
        libpcre.so.3 => /lib/libpcre.so.3 (0x00007fd6c43cf000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd6c41b3000)
        libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00007fd6c3141000)
        libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x00007fd6c3040000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fd6c2e2e000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fd6c2c12000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd6cb7ff000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fd6c2a0f000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fd6c280a000)
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Judd Storrs]

On Fri, Oct 30, 2009 at 12:26 PM, Judd Storrs <storrsjm@...> wrote:
> Is it possible your /usr/local/bin/octave is hiding /usr/bin/octave
> during install? Maybe you could temporarily rename
> /usr/local/bin/octave to /usr/local/bin/octave-disable and try again?

The debian/in/PACKAGE.postinst script runs

octave-$VERSION --silent --no-history --no-init-file \
                    --eval "pkg ('rebuild');"

I think what's happening is that your broken
/usr/local/bin/octave-3.2.2 in being used instead of the package's
/usr/bin/octave-3.2.2

My suggestion to temporarily rename /usr/local/bin/octave won't fix
that. You'll have to rename /usr/local/bin/octave-3.2.2 for apt-get to
succeed. I think anyone could break the install easily by

ln -s /bin/false /usr/local/bin/octave-3.2.2

--judd
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Jordi Gutiérrez Hermoso]

2009/10/30 Uwe Dippel <udippel@...>:
> Though it would be great to have a transitional package.
> I wonder if there is a good reason to name it octave2.9 / octave3.0 /
> octave3.2 instead of maybe just octave? So that it gets updated
> automatically?

I can't remember the exact reason for it, but roughly, I believe it
has to do with other packages dependent on Octave and of course, on
specific versions of Octave.

Rafael Laboissiere and his heir apparent Thomas Weber had very good
reasons for keeping the version name in the package name, so perhaps
one of them can provide an explanation.
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Thomas Weber-8]

On Sat, Oct 31, 2009 at 11:20:12AM -0600, Jordi Gutiérrez Hermoso wrote:

> 2009/10/30 Uwe Dippel <udippel@...>:
> > Though it would be great to have a transitional package.
> > I wonder if there is a good reason to name it octave2.9 / octave3.0 /
> > octave3.2 instead of maybe just octave? So that it gets updated
> > automatically?
>
> I can't remember the exact reason for it, but roughly, I believe it
> has to do with other packages dependent on Octave and of course, on
> specific versions of Octave.
>
> Rafael Laboissiere and his heir apparent Thomas Weber had very good
> reasons for keeping the version name in the package name, so perhaps
> one of them can provide an explanation.

Off the top of my head (and maybe mixing some version numbers in the
2.0/2.1 case).

When 2.0 was stable, it was so for a really long time. Most users
actually used the 2.1 version. So, both were introduced into Debian
(I think this was actually done by Dirk Eddelbuettel, but it happened
before I got involved in Debian, so maybe it was someone else).

2.1 vs. 2.9/3.0: There were some big changes, breaking other people's
software. I don't remember what exactly, but I submitted at least one
patch to another maintainer to get his package working on the new 3.0
stuff.

Ultimately, we are talking about Octave as a library and an interpreter,
not as a standalone software.
If a new release isn't 100% backwards compatible, you somehow need to
give people a way to migrate their scripts to the new version. That
means they need the old release in ordr to work and the new release for
porting their stuff.

        Thomas
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Uwe Dippel]

Thomas Weber wrote:

>
> Off the top of my head (and maybe mixing some version numbers in the
> 2.0/2.1 case).
>
> When 2.0 was stable, it was so for a really long time. Most users
> actually used the 2.1 version. So, both were introduced into Debian
> (I think this was actually done by Dirk Eddelbuettel, but it happened
> before I got involved in Debian, so maybe it was someone else).
>
> 2.1 vs. 2.9/3.0: There were some big changes, breaking other people's
> software. I don't remember what exactly, but I submitted at least one
> patch to another maintainer to get his package working on the new 3.0
> stuff.
>
> Ultimately, we are talking about Octave as a library and an interpreter,
> not as a standalone software.
> If a new release isn't 100% backwards compatible, you somehow need to
> give people a way to migrate their scripts to the new version. That
> means they need the old release in ordr to work and the new release for
> porting their stuff.
>  

Dear Thomas,

appreciate your explanation very much. I thought so, since Eidors was
broken with 3.0. Unfortunately, 2.X was not available under Jaunty, and
some list members suggested to compile 3.2.2 myself. (Which was quite a
hassle, but finally done with some very helpful people on this list.)
The whole thing broke again, with the update of Jaunty to Karmic.

Maybe I should say a few words about my background and motivation: being
a FOSS-person for > 10 years, I was looking to replace expensive/pirated
Matlab stuff in my workplace (students can easily buy Matlab for around
US$1 in various markets). We were doing EIT-research, using Eidors. Our
data, alas, cannot be shown on octave, subsequent to the transition
2.X->3.X of octave, because it broke Eidors compatibility; so we are
stuck with Matlab. With students' work, I was trying to get some
first-year second-semester students to use octave for their basic Bode
plots, but the instructions on the web, for Matlab, don't work neither.
With the usually utmost helpful people on this list, another syntax made
those plots work, but with the title printed in the center instead of at
the top. And still, the Bode plot comes with warnings, despite of using
the suggested syntax.
Add together with my hours (now rather days) just for installing, I'm
not really impressed. Though I tried very hard to be impressed. For next
Friday, I am invited to show the potential replacement of proprietary
research tools (SPSS, Matlab) with FOSS tools in the MyGOSSCon 2009
(Malaysian Government Open Source Conference). What should/could I say
without lying? Oh, yes, qtocatve is incompatible with 3.2.2.
Also in this respect, your sentence

Ultimately, we are talking about Octave as a library and an interpreter,
not as a standalone software.

confuses me. Does that mean octave does not want to be a competitor to
Matlab?
I really don't know what to say at MyGOSSCon. As of now, I can only
summarise, that I couldn't find fault with R as a full replacement of
the functionality of SPSS (nevermind GUI), function; while octave -
sorry, only to my own personal experiences in the last few months, and
not wanting to hurt anyone - looks more like alpha. At least, seen from
the perspective of someone who intends to replace it for Matlab in
teaching and research.
(And, from the point of view of a FOSS-developer, a software that seems
to have seen some wrong decisions. But that's not what I feel like
discussing here. Terms like backward compatibility and Matlab
compatibility would need addressing before I could full-heartedly
recommend its use.)

Uwe


_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Thomas Weber-8]

On Sun, Nov 01, 2009 at 05:27:22PM +0800, Uwe Dippel wrote:

> Thomas Weber wrote:
>>
>> Off the top of my head (and maybe mixing some version numbers in the
>> 2.0/2.1 case).
>>
>> When 2.0 was stable, it was so for a really long time. Most users
>> actually used the 2.1 version. So, both were introduced into Debian
>> (I think this was actually done by Dirk Eddelbuettel, but it happened  
>> before I got involved in Debian, so maybe it was someone else).
>>
>> 2.1 vs. 2.9/3.0: There were some big changes, breaking other people's
>> software. I don't remember what exactly, but I submitted at least one
>> patch to another maintainer to get his package working on the new 3.0
>> stuff.
>>
>> Ultimately, we are talking about Octave as a library and an interpreter,
>> not as a standalone software.
>> If a new release isn't 100% backwards compatible, you somehow need to
>> give people a way to migrate their scripts to the new version. That
>> means they need the old release in ordr to work and the new release for
>> porting their stuff.
>>  
>
> Dear Thomas,
>
> appreciate your explanation very much. I thought so, since Eidors was  
> broken with 3.0. Unfortunately, 2.X was not available under Jaunty, and  
> some list members suggested to compile 3.2.2 myself. (Which was quite a  
> hassle, but finally done with some very helpful people on this list.)  
> The whole thing broke again, with the update of Jaunty to Karmic.

I'm sorry to say that, but you are using the wrong distribution. Get a
distribution with a *real* maintainer caring for Octave. Ubuntu's "let's
recompile whatever happens to be in Debian unstable/testing at an
arbitrary point of time" attitude just doesn't cut it. That goes for
Octave's dependencies as well.

If you don't want Debian, Fedora seems to be a sensible alternative.

> Maybe I should say a few words about my background and motivation: being  
> a FOSS-person for > 10 years, I was looking to replace expensive/pirated  
> Matlab stuff in my workplace (students can easily buy Matlab for around  
> US$1 in various markets). We were doing EIT-research, using Eidors. Our  
> data, alas, cannot be shown on octave, subsequent to the transition  
> 2.X->3.X of octave, because it broke Eidors compatibility; so we are  
> stuck with Matlab.

> Add together with my hours (now rather days) just for installing, I'm  
> not really impressed. Though I tried very hard to be impressed. For next  
> Friday, I am invited to show the potential replacement of proprietary  
> research tools (SPSS, Matlab) with FOSS tools in the MyGOSSCon 2009  
> (Malaysian Government Open Source Conference). What should/could I say  
> without lying? Oh, yes, qtocatve is incompatible with 3.2.2.

Hm, are you sure about the incompatibility? I know for a fact that 3.2.3
works:

https://buildd.debian.org/pkg.cgi?pkg=qtoctave

> Also in this respect, your sentence
>
> Ultimately, we are talking about Octave as a library and an interpreter,
> not as a standalone software.
>
> confuses me. Does that mean octave does not want to be a competitor to  
> Matlab?

I don't know what Octave wants to be. I don't care about Matlab at all.
I'm no longer at the university and buying Matlab is out of the
question.

My sentence was meant in the idea that Octave is not a stand-alone
project like OpenOffice.org. Ie, I need to care for people having
written code specific to older versions of Octave by giving them a
migration path.

> I really don't know what to say at MyGOSSCon. As of now, I can only  
> summarise, that I couldn't find fault with R as a full replacement of  
> the functionality of SPSS (nevermind GUI), function; while octave -  
> sorry, only to my own personal experiences in the last few months, and  
> not wanting to hurt anyone - looks more like alpha. At least, seen from  
> the perspective of someone who intends to replace it for Matlab in  
> teaching and research.

<shrug> I've used Octave for several years at the university without
problems. If it doesn't meet your needs, you seem to have different
needs than I have.

> (And, from the point of view of a FOSS-developer, a software that seems  
> to have seen some wrong decisions. But that's not what I feel like  
> discussing here. Terms like backward compatibility and Matlab  
> compatibility would need addressing before I could full-heartedly  
> recommend its use.)

Then continue to use Matlab. I don't see a problem with that at all. If
money is a problem, <shrug>. You can't eat your cake and have it, too.

        Thomas
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave