Bugzilla Bug 153462

GNU Octave 2.9.9 is already available. There's only 2.1.* in Portage. That's
it.

(In reply to comment #0)
> GNU Octave 2.9.9 is already available. There's only 2.1.* in Portage. That's
> it.
> 

If you look at http://www.gnu.org/software/octave/download.html
you will see that the 2.1.* branch is the testing and recommended
branch. 2.9.* is octave's development branch and I don't see
any need for it in portage at the moment. Is there any reason
why you need it?

Thanks,
Markus

If you'll look at other packages, you would see development versions for some
of them, too. Yes I've used Octave 2.9.9 on windows (aww), so i would like to
use _the same_ version on gentoo.

Thanks,
Zaba

P.S.: later, i would probably maintain own ebuilds. These days I couldn't find
a good tool for making them (except of Kate, but it looks like it don't have
syntax highlighting for ebuilds :P).

(In reply to comment #2)
> If you'll look at other packages, you would see development versions for some
> of them, too. Yes I've used Octave 2.9.9 on windows (aww), so i would like to
> use _the same_ version on gentoo.
> 
> Thanks,
> Zaba
> 

Agreed! However, since we're currently up-to-date with the most
recent testing version which works well for most people, providing
an ebuild for octave-2.9.x currently isn't very high on my priority
list. But I will have a look once I find some time.

Once you have an ebuild for octave-2.9.x that works please feel
free to post it here; this might speed up things considerably!
Thanks in advance.

Best,
Markus

Created an attachment (id=101603) [edit]
Initial ebuild for octave 2.9.9

This ebuild is just an adaption from the 2.1.73-r1 one with just the patches
removed. It installed nicely on my box, which is a quite regular ~x86 install.

The word on the octave-dev list is that this version will be the next testing
release (which is where the development is done). I've also heard that debian
added this release to unstable, so it's about time gentoo got it, too. This
version seems to be faster than the previous ones thanks to m-file caching and
stuff and I have not noticed any big bugs yet.

Thanks Johan!
I'll try to have a look at this soon!

best,
Markus

(In reply to comment #5)
Just a quick comment:  There should be a companion octave-forge ebuild for the
version that works with 2.9.9. (I probably didn't need to tell you that.) I
believe there have been many octave-forge functions that have moved into octave
with this release.  Most users need this package.

I'd love to submit an ebuild but I wasn't able to create one that worked in the
limited time I had available.  

Created an attachment (id=102759) [edit]
Ebuild for the latest octave-forge. This one installs fine with octave 2.9.9

Here is an ebuild for the latest octave-forge package, which is designed to be
used with octave 2.9.6 or higher.

The only diff to previous ebuilds is that it does
touch extra/mex/NOINSTALL
to disable octave-forge's mex interface since there already is one in the
octave dist.

Just reporting that both octave and octave-forge ebuilds appear to work on my
~x86 and ~amd64 machines.  I'll let you know if anything comes up during more
extensive use.

(In reply to comment #8)
> Just reporting that both octave and octave-forge ebuilds appear to work on my
> ~x86 and ~amd64 machines.  I'll let you know if anything comes up during more
> extensive use.
> 

Thanks to all for your testing and providing ebuilds. As soon as I find some
time
and the stabilization of octave-2.1.73/octave-forge is done on all arches
I'll tackle this one.

Thanks,
Markus

I've compiled octave 2.9.9 successfully on amd64, but just
download_source-configure-make-make_install-make_clean ;-). I'll be waiting for
it in portage anyway. Thanks everyone who have already provided ebuilds. I hope
I don't need too much...

I'm not sure if anybody else has experienced this problem but, calling the
Inverse function from c++, like:

/* from /usr/include/octave..../dMatrix.h
 Matrix inverse (int& info, double& rcond, int force = 0,
                  int calc_cond = 1) const;
*/
   Matrix tmp( ROWS , COLS );
   OctMat( &tmp );  // copy from my representation
   int info;
   double rc = 0;
   Matrix tmp2; // inverted matrix

   tmp2 = tmp.inverse( info , rc , (int)0 , (int)1 );
// does not worh, but
   tmp2 = tmp.inverse();
// works

I use "GNU Octave, version 2.1.73 (i686-pc-linux-gnu)" I have tired it on two
different computers, an intel centrino and an athlon-xp, with the same result.
Upgrading to 2.9.9 solves the problem (thanks for the ebuild provided here). 

Perhaps it is a silly mistake by me and then simply ignore this message, else
it would be nice with an 2.9. version in the portage tree.

regards

klas


Portage 2.1.1-r2 (default-linux/x86/no-nptl, gcc-4.1.1, glibc-2.3.6-r5,
2.6.18-gentoo-r6 i686)
=================================================================
System uname: 2.6.18-gentoo-r6 i686 AMD Athlon(tm) XP 1700+
Gentoo Base System version 1.12.6
Last Sync: Thu, 04 Jan 2007 19:50:01 +0000
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://ds.thn.htu.se/linux/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 X alsa alsa_cards_via82xx alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw
alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix
alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty
alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks
alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa
alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter
alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null
alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route
alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol apache2
apm arts bash-completion bcmath berkdb bitmap-fonts blas calendar cli cracklib
crypt cups debug dlloader dri dvd dvdr eds elibc_glibc emacs emboss encode
firefox flac foomaticdb fortran gd gdbm gif glut gnome gpm gstreamer gtk gtk2
hal iconv imagemagick imlib input_devices_evdev input_devices_keyboard
input_devices_mouse ipv6 isdnlog java javascript jpeg kde kernel_linux lapack
libg++ libwww mad mikmod motif mp3 mpeg mysql mysqli ncurses nls ogg opengl oss
pam pcre pdf perl php png pppd python qt3 qt4 quicktime readline reflection sdl
session spell spl ssl tcpd tetex truetype truetype-fonts type1-fonts usb
userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_chips
video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev
video_cards_glint video_cards_i128 video_cards_i740 video_cards_i810
video_cards_imstt video_cards_mga video_cards_neomagic video_cards_nsc
video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge
video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb
video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng
video_cards_v4l video_cards_vesa video_cards_vga video_cards_via
video_cards_vmware video_cards_voodoo vorbis xinerama xml xorg xv zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

(In reply to comment #1)
> (In reply to comment #0)
> > GNU Octave 2.9.9 is already available. There's only 2.1.* in Portage. That's
> > it.
> > 
> 
> If you look at http://www.gnu.org/software/octave/download.html
> you will see that the 2.1.* branch is the testing and recommended
> branch. 2.9.* is octave's development branch and I don't see
> any need for it in portage at the moment. Is there any reason
> why you need it?
> 
> Thanks,
> Markus
> 

Well, I'm no expert on the octave C++ API and it is not very well documented,
but from the code you're posting I can see that the int info is not
initialized. I don't know whether this is a mistake when you copied the code or
if it is not necessary.

Anyway, you should go to http://www.gnu.org/software/octave/archive.html and
post to the help list if you want to find this out.

Created an attachment (id=108178) [edit]
Patch to correct delaunay argument

Diff from http://velveeta.che.wisc.edu/octave/lists/help-octave/2005/4368

(In reply to comment #7)
> Created an attachment (id=102759) [edit]
> Ebuild for the latest octave-forge. This one installs fine with octave 2.9.9
> 
> Here is an ebuild for the latest octave-forge package, which is designed to be
> used with octave 2.9.6 or higher.
> 
> The only diff to previous ebuilds is that it does
> touch extra/mex/NOINSTALL
> to disable octave-forge's mex interface since there already is one in the
> octave dist.
> 

Hi, I tried the ebuild on amd64, and noted two things:

1. The octave 'static' use flag breaks this version of octave-forge. The build
runs, but linking fails with -fPIC related errors ('...relocation against..'
etc.) as described in the FAQ on the AMD64 project page.
2. The function 'griddata.m' does not work at all without libqhull, and
segfaults with. I made the patch attached above to fix the problem, from the
linked diff. Rename it as you wish.

Hey all,

I'm just beginning to get the itch to try version 2.9.10.  I tried compiling
with the old ebuild, which didn't work.  That itself is not the reason I'm
posting.  

The real reason: One problem I'm sure that will need to be dealt with is the
companion octave-forge.  They have gone to a package build system instead of
monolithic.  Some thought should go into how gentoo will handle this with
ebuilds.

http://octave.sourceforge.net/packages.html

Just a discussion starter... any thoughts?

As I see it, our three options are:
1. Use one ebuild that pulls all packages and builds them.
2. Add a lot of bizarre USE flags to the single ebuild so that it will install
different packages depending on use flags.
3. Use one ebuild per octaveforge package (or one for a couple of o-f packages)
and add one meta-ebuild depending on them all so all of octaveforge can be
installed at once.

The question really here is whether or not people will want to install only
parts of octaveforge and I think that some might. If that i the case, we need
the third alternative with the many ebuilds. This will also help if there is an
update to one of the packages. I guess that's the rationale behind their
decision to split the package in the first place.

The third approach will also help to keep inter-package dependencies sane.
Doing this with USE-flags seems like suicide. It is possible that some USE
flags should be added to the ebuild depending on all the other so that some
packages can be avoided if the user wishes. Bindings to other libs comes to
mind. Some users might want to keep their systems lean and therefor not willing
to add all the bindings.

So my vote is that we split the ebuild into multiple packages. Not necessarily
one ebuild per o-f package, for instance we might group some signal processing
packages into one ebuild, some linear algebra into another and some statistical
into a third.

I'm currently doing some compiling testing my ebuild for 2.9.10. We'll see how
that one turns out.

(In reply to comment #16)
> So my vote is that we split the ebuild into multiple packages. Not necessarily
> one ebuild per o-f package, for instance we might group some signal processing
> packages into one ebuild, some linear algebra into another and some statistical
> into a third.


I also vote for split ebuilds with a meta package.  I liked it when the kde
ebuilds went that direction, as I was able to go a little more lean.  I'm
certain that I would bring in the whole meta package for o-f though, not the
individual ebuilds, so my preference isn't strong, it just might be more
flexible for others.


By the way, here is my failure to build on amd64 with the above ebuild (for
2.9.9).  If anybody is in debug mode (not yet for me) I thought it might help. 
It relates to the emacs use flag.

---
make[2]: Leaving directory
`/var/tmp/portage/sci-mathematics/octave-2.9.10/work/octave-2.9.10/examples'
make[1]: Leaving directory
`/var/tmp/portage/sci-mathematics/octave-2.9.10/work/octave-2.9.10'
install: cannot stat `otags': No such file or directory

!!! ERROR: sci-mathematics/octave-2.9.10 failed.
Call stack:
  ebuild.sh, line 1614:   Called dyn_install
  ebuild.sh, line 1060:   Called qa_call 'src_install'
  environment, line 4026:   Called src_install
  octave-2.9.10.ebuild, line 93:   Called die

Ok. I'm working on the ebuild right now. I managed to install it yesterday on
my ~x86 box but it needs some more dependencies for sparse matrices to work. I
did not use the emacs build flag, though. I'm testing it right now. It seems to
only affect installation so it should not be a big issue.

Created an attachment (id=115819) [edit]
octave-2.9.10 ebuild

This is an ebuild for octave 2.9.10. It works with the emacs use flag and has
updated deps.

It also adds a sparse USE flag that makes it install a lot of sparse packages
so that octave can detect them. The ebuilds that are needed for this can be
found at http://bugs.gentoo.org/show_bug.cgi?id=173900

These ebuilds require metis which can be found at
http://bugs.gentoo.org/show_bug.cgi?id=53394

Created an attachment (id=116022) [edit]
Patch to fix a whitespace problem

I needed this patch to make the octave-forge compilation work. It fixes a
problem where octave returns unexpected whitespace that then causes configure
to fail. I fixed this with a sed substitution.

When I attempted to emerge octave-2.9.10 with the mpi useflag enabled, as well
as all others expect sparse, static, and debug, compile failed.  Actually, it
hung during Octave's self-preparation phase, and just sat there, "defunct",
using 0% CPU.  I had to close the terminal to kill it.

Removing the mpi useflag resulted in a successful compile and emerge.

Created an attachment (id=118876) [edit]
build log from failed octave-forge-2006.07.09 build

Trying to build octave-forge from the above package with USE="X ginac -qhull"
fails with many errors.  I attach the resulting build log; I recommend you grep
through for "error".

$ emerge --info
Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0,
2.6.19-gentoo-r5 i686)
=================================================================
System uname: 2.6.19-gentoo-r5 i686 Genuine Intel(R) CPU           L2400  @
1.66GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Sat, 28 Apr 2007 23:50:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.31-r5
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.15-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-O2 -mcpu=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache confcache distlocks metadata-transfer parallel-fetch sandbox
sfperms strict userfetch userpriv usersandbox"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="en_US.UTF-8"
LINGUAS="en_US en es"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="3ds X X509 a52 aac acpi aiglx aim alsa amr amrr aotuv asf avahi
bash-completion beagle berkdb bitmap-fonts blas bluetooth bootsplash branding
bzip2 cairo ccache cdda cddb cdparanoia cdr cjk cli cpudetection cracklib
crosscompile crypt cups dbus directfb dmi dmx doc dri dts dv dvd dvdr dvdread
dvi eds emacs emboss enblend encode esd exif fam fat fbcon fbsplash ffmpeg fftw
firefox flac flash fortran ftp gb gcj gdbm gif gimp ginac glitz glut gnome
gnuplot gphoto2 gpm gps grammar gstreamer gtk guile gzip hal hardenedphp hdaps
hddtemp i8x0 iconv icq ieee1394 imagemagick imap imlib ipv6 irc isdnlog jabber
jack java javascript jbig jpeg jpeg2k kdeenablefinal kerberos ladspa lapack
lash lcms ldap libg++ libnotify lirc live mad matroska midi mikmod mime ming
mjpeg mmap mmx mmxext mng mod mono mozsvg mp3 mp4 mpeg mpi musepack nautilus
ncurses nls nptl nptlonly nsplugin ntfs offensive ogg openexr opengl oscar pam
pcre pda pdf perl plotutils png postscript ppds pppd python quicktime readline
real realmedia reflection rtc sdl session shorten sift smp speex spell spl sse
sse-filters sse2 ssl svg tcpd tetex tga theora threads thunderbird tiff
timidity toolkit-scroll-bars truetype truetype-fonts type1-fonts unicode usb
vcd videos vorbis wavpack wifi win32codecs wma wmf x264 x86 xanim xine xinerama
xml xorg xpm xv xvid xvmc yv12 zip zlib" ALSA_CARDS="ali5451 als4000 atiixp
atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968
fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx
via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop
empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi
null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard
mouse evdev joystick" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk
hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US en es" USERLAND="GNU"
VIDEO_CARDS="i810 vesa"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

That is the old octave-forge for octave 2.9.9. I wouldn't expect it to work
with 2.9.10. Which reminds me that we need to create that ebuild...

However, the mpi problem needs to be fixed. I could merge octave-2.9.10 on my
~x86 using mpi. Could you attach the output from the merge on your box?

We should probably keep track of which mpi implementations we
are each talking about (mpich, lam-mpi, mpich2) and which ones
work or don't.

BTW: Thanks for testing to everybody involved. Hopefully, I'll
have some time soon to have a serious look at octave 2.9.*
myself.

Cheers,
Markus

I have the following mpi installed:
[ebuild   R   ] sys-cluster/mpich-1.2.7_p1  USE="crypt doc" 0 kB

Folks.

Looks like octave-2.911 was released into the testing branch today. Hopefully,
I'll be able to get an ebuild up and running soon, so we can start
testing it. 

Best,
Markus

(In reply to comment #26)
 > Looks like octave-2.911 was released into the testing branch today.
Hopefully,

This should have been 2.9.11, of course! 

Markus

Folks,

Due to the tight correlation between octave and octave-forge
I've decided to initially create an overlay [1] and develop both
of them until everything works before merging the ebuilds
into portage. 

I've just added an ebuild for octave-2.9.12 at [1] that is fairly
complete apart from the sparse-matrix stuff which I plan
to add after all the octave-forge stuff is done. Please give
it a short and let me know of any problems.

Also, I've created a tracker bug for the new octave-forge
(bug #179885) that details my plan for the split octave-forge
ebuilds and that I will use to track their progress. Please cc
yourself to the bug if you're interested.

I'd appreciate if we could all try to use this bug for octave-2.9.x
ONLY and discuss all octave-forge related issues at the tracker
bug. Thanks for all your help.

cheers,
Markus

[1] http://dev.gentoo.org/~markusle/octave-overlay/

The 2.9.12 ebuild worked for me on amd64.

Is there a way to get the overlay tree directly without downloading each file
separately?

Created an attachment (id=131522) [edit]
updated ebuild for octave 2.9.14

this ebuild built fine on ~x86 box with gcc 4.2.0... the ebuild requires no
patches

As soon as I get commit access to the gentoo-overlay I will
move the new octave as well as all the split octave-forge ebuilds
over there. I'll let you guys know once it is done.

Thanks,
Markus 

(In reply to comment #30)
> Created an attachment (id=131522) [edit]
> updated ebuild for octave 2.9.14
> 
> this ebuild built fine on ~x86 box with gcc 4.2.0... the ebuild requires no
> patches
> 

Ryan, can you comment on some of your significant changes?  
1) Particularly, I'm wondering about the static and zlib use flags.  What
exactly do they address?  I assume static means static libraries with a larger
executable?  The zlib bug you cite is from 2004, is it current?
2) Also, is the intel section just a comment or do you intend to have a use
flag for it eventually?
3) Is the fortran section of the prior ebuild not needed anymore?
4) Does your src_unpack section do anything that wouldn't be done if it is
eliminated entirely?  I don't think it does, but am not an expert.
5) You eliminated curl use flag, is this helpful?

Thanks,

I've bumped octave to 2.9.14 in my local overlay (still no
commit access to the gentoo-science overlay, hopefully soon).
Upstream has merged octave-forge-geometry into the
main line, hence this ebuild is gone now from the octave-forge
packages.

Thanks,
Markus

Created an attachment (id=132174) [edit]
sci-libs.tar.gz -- Sparse support, ebuilds for ccolamd cholmod colamd cxsparse

Hello all,

Attached is a tar file with four ebuilds.  When combined with an octave-2.9.14
ebuild which I will attach separately, they will provide sparse matrix
functionality to octave.  They also address add the geometry package qhull.

qhull and sparse are new use flags.

I've built these on x86 and amd64.

Please test and provide feedback.

Pete Gustafson



Contents are:

sci-libs/ccolamd/
sci-libs/ccolamd/Manifest
sci-libs/ccolamd/files/
sci-libs/ccolamd/files/ccolamd-2.7.0-Makefiles.patch
sci-libs/ccolamd/files/digest-ccolamd-2.7.0
sci-libs/ccolamd/ccolamd-2.7.0.ebuild
sci-libs/cholmod/
sci-libs/cholmod/Manifest
sci-libs/cholmod/files/
sci-libs/cholmod/files/digest-cholmod-1.5.0
sci-libs/cholmod/files/cholmod-1.5.0-Makefiles.patch
sci-libs/cholmod/cholmod-1.5.0.ebuild
sci-libs/colamd/
sci-libs/colamd/Manifest
sci-libs/colamd/files/
sci-libs/colamd/files/digest-colamd-2.7.0
sci-libs/colamd/files/colamd-2.7.0-Makefiles.patch
sci-libs/colamd/colamd-2.7.0.ebuild
sci-libs/cxsparse/
sci-libs/cxsparse/Manifest
sci-libs/cxsparse/cxsparse-2.2.0.ebuild
sci-libs/cxsparse/files/
sci-libs/cxsparse/files/digest-cxsparse-2.2.0
sci-libs/cxsparse/files/cxsparse-2.2.0-Makefiles.patch

Created an attachment (id=132176) [edit]
octave-2.9.14.ebuild -- Sparse support

This ebuild enables octave sparse and geometry support via use flags sparse and
qhull.  Having not heard from Ryan yet, I didn't attempt to incorporate changes
from his ebuild.  However this one also builds without patches on my machine.

Feedback?

Pete Gustafson

(In reply to comment #34)
> Created an attachment (id=132174) [edit]
> sci-libs.tar.gz -- Sparse support, ebuilds for ccolamd cholmod colamd cxsparse

Hi Peter,

Work on these packages is going on in bug #173900, and are now in the science
overlay.

Sébastien 

octave 2.9.15 was released on 2007/09/13.

make that 2007/10/13. (yesterday) ;)

The current ebuilds in science overlay, which are the same as here, depend on
blas, lapack, fftw, tetex and others, while the old ones in portage have these
dependecies as optional via USE flags. The new ones shouldn't be that way?

(In reply to comment #39)
> The current ebuilds in science overlay, which are the same as here, depend on
> blas, lapack, fftw, tetex and others, while the old ones in portage have these
> dependecies as optional via USE flags. The new ones shouldn't be that way?
> 

Thanks much for your note.
The most up to date octave ebuild in portage (2.1.73-r2) also hard depends
on virtual/blas etc. It is much preferable to depend on a well tested external
blas/lapack/... implementation rather than a possibly buggy version that
ships with the package. 
You are probably correct though with respect to tetex which should possibly
only be pulled in for USE="doc" only. I'll have a look at it and see if this is 
indeed the case.

Thanks,
Markus

AFAIK blas, lapack, latex (tetex in the ebuild) and fftw are not mandatory.
Blas and lapack are high performance libaries for linear algebra, so if octave
is build without support for them it won't use internal blas/lapack libraries,
it won't use anything related to blas/lapack but different algorithms that
don't use those (usually slower).

The same happens with fftw, is a high performance FFT library, if octave isn't
built with fftw support it will be use a standard and slower FFT algorithm.
About the Latex part, I don't know.

I'm not sure if these things apply in octave, but is the way that some other
programs behave, like dev-lang/R with blas and lapack and some audio and video
codecs with fftw.

Even if most octave users compile it with blas/lapack/fftw support, I think
that it must be optional if possible. After all, Gentoo is about choice.

(In reply to comment #40)
> (In reply to comment #39)
> > The current ebuilds in science overlay, which are the same as here, depend on
> > blas, lapack, fftw, tetex and others, while the old ones in portage have these
> > dependecies as optional via USE flags. The new ones shouldn't be that way?
> > 
> 
> Thanks much for your note.
> The most up to date octave ebuild in portage (2.1.73-r2) also hard depends
> on virtual/blas etc. It is much preferable to depend on a well tested external
> blas/lapack/... implementation rather than a possibly buggy version that
> ships with the package. 
> You are probably correct though with respect to tetex which should possibly
> only be pulled in for USE="doc" only. I'll have a look at it and see if this is 
> indeed the case.
> 
> Thanks,
> Markus
> 

(In reply to comment #41)
> AFAIK blas, lapack, latex (tetex in the ebuild) and fftw are not mandatory.
> Blas and lapack are high performance libaries for linear algebra, so if octave
> is build without support for them it won't use internal blas/lapack libraries,
> it won't use anything related to blas/lapack but different algorithms that
> don't use those (usually slower).

Last time I checked (I may be wrong) octave would build its own versions
of blas/lapack/... located in octave-2.x/libcruft/ if no external blas/..
is specified. This we want to avoid since it frequently leads to 
maintenance nightmares. If indeed USE="-blas" would mean that
no blas is built and linked against we could put the USE flag 
back into place.

BTW, installing the blas/lapack/reference-ebuild will give you very
good and well tested libraries that are very easy to install (unlike
atlas).



cheers,
Markus

(In reply to comment #41)
> Even if most octave users compile it with blas/lapack/fftw support, I think
> that it must be optional if possible. After all, Gentoo is about choice.

Choice... speed...  what is it about???  :)

FWIW there was recent talk on the octave-maintainers list about removing some
or all of the libcruft code.  As of right now they remain but they might go
away and introduce hard dependencies.

(In reply to comment #43)
> (In reply to comment #41)
> > Even if most octave users compile it with blas/lapack/fftw support, I think
> > that it must be optional if possible. After all, Gentoo is about choice.
> 
> Choice... speed...  what is it about???  :)
> 

Here's my opinion which is by no means meant to be the "correct" one.
Choice is good, but it also very often introduces much more work
from a developer point of view, leads to hard to maintain
packages and in this case moves packages out of the realm of our eselect 
blas/lapack/cblas infrastructure. 

This is also not necessary about speed but about reliable
and correct execution of linear algebra routines. I am pretty confident
that the linear algebra libraries in portage are well tested and just work. I
don't know this about octave's shipped stuff and I simply would like
to avoid having to deal with bugs - like has happened many times
in the past - where people report that they obtain strange results 
and after lots of digging it turned out that they linked against
some shipped library.

Personally, I feel that somebody who needs octave to do work can be
expected to have the basic linear algebra routines on his machine;
otherwise octave may actually not even be the right tool for the job and
a more simple program (calc, ..) without these dependencies
may be more appropriate. Now, if a significant number of octave
users feel that they want to have an octave package without blas
(should this be actually possible) then this may actually be worth
our while.

Just my 0.5 cents though.

cheers,
Markus

I would support Markus in not having a use flag for blas, based on those
maintenance arguments.  A flag structure something like this:

zlib? ( sys-libs/zlib )
hdf5? ( sci-libs/hdf5 )
curl? ( net-misc/curl )
qhull? ( media-libs/qhull )
sparse? ( sci-libs/umfpack sci-libs/colamd sci-libs/ccolamd sci-libs/cholmod
sci-libs/cxsparse )

and, perhaps a doc or tetex if that is even possible.

I say those because I don't perceive them as "core" functions in octave,
whereas blas is very much at the "core" of what octave is meant to do.  Of
course that is my perception...

After reading the configure script for octave, I agree that BLAS and LAPACK
shouldn't have use flags. It seems that both are necessary, so it will use the
internal libs, not very good ones. The reference libs are in portage for every
arch, are better than the internal octave libs and are stable enough.

About the tetex thing, I haven't found anything tetex/latex/tex related in the
config script, so I don't know how to manage this. However, I think that isn't
mandatory, so maybe it should be mamaged with an use flag.

Finally, fftw is not necessary although is recommended. The configure script
will try to use it if possible, so the "--with-fftw" thing in the ebuild is not
necessary. I don't mind if fftw is installed as a dependency instead of being
choosed via useflags, however, if the lastest is choosed, the ebuild should
have "--without-fftw" for the configure script when fftw is unset.

octave 2.9.16 was released on 2007/10/31.

(In reply to comment #46)
> About the tetex thing, I haven't found anything tetex/latex/tex related in the
> config script, so I don't know how to manage this. However, I think that isn't
> mandatory, so maybe it should be mamaged with an use flag.
> 
> Finally, fftw is not necessary although is recommended. The configure script
> will try to use it if possible, so the "--with-fftw" thing in the ebuild is not
> necessary. I don't mind if fftw is installed as a dependency instead of being
> choosed via useflags, however, if the lastest is choosed, the ebuild should
> have "--without-fftw" for the configure script when fftw is unset.
> 

Thanks for your comments and I'll definitely have a look at the 
tetex and fftw stuff. 

Cheers,
Markus

Created an attachment (id=135664) [edit]
octave-2.9.17.diff

The octave guys are evil and in the octave directory in their ftp only the last
version of the program is present, so the ebuild cannot fetch the file if isn't
the last (like now with 2.9.15). Fortunately there is a dir called
bleeding-edge which contains the previous releases and the last one. This patch
for the ebuild fixes SRC_URI to download the tarball from there, so the ebuild
can always download it, whether it is the last one or not.

One more thing: the last version is 2.9.17 and the same ebuild for 2.9.15 works
(it works without the SRC_URI fix for now). Somebody can upload the ebuild for
the last version with the fix instead fixing the old ones.

(In reply to comment #49)
> Created an attachment (id=135664) [edit]
> octave-2.9.17.diff
> 
> The octave guys are evil and in the octave directory in their ftp only the last
> version of the program is present, so the ebuild cannot fetch the file if isn't
> the last (like now with 2.9.15). Fortunately there is a dir called
> bleeding-edge which contains the previous releases and the last one. This patch
> for the ebuild fixes SRC_URI to download the tarball from there, so the ebuild
> can always download it, whether it is the last one or not.
> 
> One more thing: the last version is 2.9.17 and the same ebuild for 2.9.15 works
> (it works without the SRC_URI fix for now). Somebody can upload the ebuild for
> the last version with the fix instead fixing the old ones.
> 

Thanks for the note and I hope I can get to it over the weekend. I was out of
town at a conference for two weeks and am just now catching up with things.

cheers,
Markus

FYI, I just bumped octave to version 2.9.17 in the overlay.

Makrus

octave 2.9.18 was released today.

octave 3.0.0 was released today!

I see the title of this bug is octave 3.0.0 version bump, 
I see octave 3.0.0 is released...
If someone where to post a 3.0 ebuild I would be excited to try it.
::subscribes to CC list::

(In reply to comment #54)
> I see the title of this bug is octave 3.0.0 version bump, 
> I see octave 3.0.0 is released...
> If someone where to post a 3.0 ebuild I would be excited to try it.
> ::subscribes to CC list::
> 

If you rename the latest octave-2.9.* ebuild in the science
overlay you should be fairly close apart from one
of the patches perhaps ;)

Markus 

There is STABLE octave 3.0 which have some big changes so ebuild should be
updated.

octave-3.0.0 is available in the science overlay. We are
currently working on getting all the dependencies needed for 
octave 3.0.0 into the tree. Once that's done octave 3.0.0 will 
follow.

Thanks,
Markus

AFAIK all dependencies of octave and the forge packages are in the tree. While
we wait another couple of years to get this in the tree, we can bump octave to
3.0.1, a bugfix release. I haven't tried it, but my guess is that the same
ebuild will work.

(In reply to comment #58)
> AFAIK all dependencies of octave and the forge packages are in the tree. While
> we wait another couple of years to get this in the tree, we can bump octave to
> 3.0.1, a bugfix release. I haven't tried it, but my guess is that the same
> ebuild will work.
> 

Thanks much for the note and I'll try to bump it as soon as I get some testing
done. The main reason for the delay really is the fact that I was trying
to get both octave and the new octave-forge into portage simultaneously.
Unfortunately, I have come to realize that that won't happen since the
new octave-forge eclass requires further work. Hence, as soon as all
dependencies required for 3.0.0 are keyworded on all arches I'll move 
octave-3.* into portage (I've added all outstanding bugs I am
aware of). Sorry for the inconvenience.

best,
Markus

on amd64:

i just want to note, that i'm using

sci-mathematics/octave-3.0.1  
USE="readline sparse zlib -curl -debug -doc -emacs -fftw -hdf5 -xemacs"

quite a lot for about ten days and didn't experience any issues.

Portage 2.1.4.4 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0,
2.6.24-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.24-gentoo-r7 x86_64 Intel(R) Core(TM)2 Duo CPU E6550 @
2.33GHz
Timestamp of tree: Sat, 14 Jun 2008 09:32:01 +0000
app-shells/bash:     3.2_p33
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python:     2.4.4-r9
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf
/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c
/etc/udev/rules.d"
CXXFLAGS="-march=nocona -O2 -pipe"
DISTDIR="/var/portage/distfiles"
FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict
unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://gd.tuwien.ac.at/opsys/linux/gentoo/
http://mirror.uni-c.dk/pub/gentoo/ http://trumpetti.atm.tut.fi/gentoo/ "
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LINGUAS="en de"
MAKEOPTS="-j3"
PKGDIR="/var/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/portage/repos/gentoo"
PORTDIR_OVERLAY="/var/portage/repos/layman/sajinet
/var/portage/repos/layman/science /var/portage/repos/private"
SYNC="rsync://192.168.0.1/gentoo-portage"
USE="3dnow 3dnowext X a52 aac acpi alsa amd64 berkdb bzip2 cairo caps cddb
cdparanoia cdr cli cracklib crypt cups dbus djvu dri dvd dvdr dvdread eds
emboss encode evo exif fam ffmpeg firefox flac fortran gd gdbm gif gimp gnome
gnome-keyring gphoto2 gpm gstreamer gtk hal hddtemp iconv icu ipod ipv6 isdnlog
java jpeg jpeg2k lcms ldap libnotify lm_sensors mad matroska midi mikmod mmap
mmx mmxext mono mp3 mpeg mudflap musicbrainz ncurses nls nptl nptlonly nvidia
ogg opengl openmp pam pcre pdf perl plotutils png pppd pulseaudio python
qt3support quicktime readline reflection ruby sdl session spell spl sse sse2
ssl ssse3 svg tcpd tetex theora threads tiff tracker truetype unicode usb vcd
vim-syntax vorbis xattr xine xml xorg xv xvid zlib" ALSA_PCM_PLUGINS="adpcm
alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa
lfloat linear meter mulaw multi null plug rate route share shm softvol"
APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm
authn_default authn_file authz_dbm authz_default authz_groupfile authz_host
authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir
disk_cache env expires ext_filter file_cache filter headers include info
log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling
status unique_id userdir usertrack vhost_alias" CAMERAS="canon konica ptp2
kodak" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux"
LINGUAS="en de" USERLAND="GNU" VIDEO_CARDS="nvidia nv"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

> sci-mathematics/octave-3.0.1  
> USE="readline sparse zlib -curl -debug -doc -emacs -fftw -hdf5 -xemacs"
>
this is the version from the science overlay of course....

Thanks much for testing, Matthias. I am currently
preparing the new octave-forge eclass for approval
by gentoo-dev. Once this has been accomplished,
both octave and the octave-forge ebuilds will be
moved to the main tree.

Best,
Markus

Is there anything I could do to speed up this issue ? I am expectantly waiting
for octave 3.0.x :)

(In reply to comment #63)
> Is there anything I could do to speed up this issue ? I am expectantly waiting
> for octave 3.0.x :)
> 

octave 3.* in its current state in the science overlay is ready
to go and has been for a while. The one thing holding it back is
the new split octave-forge stuff which isn't quite ready yet. I am
currently pondering adding octave-3.* to the tree despite this fact.
However, this would mean that current users of octave-forge will
either have to mask octave-3.* for the time being or pull in the
current split octave-forge ebuilds from the science overlay which
will result in a bit of inconvenience. Any opinion what would be
preferable from a user's point of view?

Thanks much for your patience.

Best,
Markus

> Any opinion what would be preferable from a user's point of view?

what about adding octave-3.* to the tree and mask it? so some people have the
freedom to use the new package if they want to, and the setups of unknowing
users won't break.

i'm not sure though if it'll be better to soft-mask or hard-mask it.

I've just added octave-3.0.1 to portage. The ebuild is currently
masked so I can test it a bit more. Please give it a try and
file new bugs (please don't post to this one) should there be
any problems.

Thank you very much for your patience and enjoy!

Best,
Markus