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 attachment 101603 [details] 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 attachment 102759 [details] 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 attachment 108178 [details, diff] 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 attachment 115819 [details] 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 attachment 116022 [details, diff] 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 attachment 118876 [details] 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 attachment 131522 [details] 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 attachment 132174 [details] 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 attachment 132176 [details] 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 attachment 135664 [details, diff] 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
