Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
The purpose of this bug is to track all progress with the new split octave-forge ebuilds (required for octave-2.9.x) that will replace the present monolithic version. Here's what I plan to do: 1) Each octave-forge package will get its own ebuild category called octave-forge-xxxx (e.g. octave-forge-audio etc.) 2) The previous monolithic octave-forge ebuild will become a meta ebuild that will pull in all split octave-forge-xxx ebuilds. This should allow a smooth upgrade path for users already having octave-forge on their system and also allow one to only emerge selected octave-forge-xxxx packages instead of all of them. The new split ebuilds will initially be added to the overlay at http://dev.gentoo.org/~markusle/octave-overlay/ until they are all functional; once this is accomplished, we can merge them together with octave-2.9.x itself into portage. I will post all progress to this bug. Please post all octave-forge-xxxx related problems here. Bugs relating to octave itself should go to bug #153462. cheers, Markus
Great! Could you please incorporate the sparse stuff from the octave-2.9.10 ebuild at bug# 153462 and also add the ebuilds from bug# 173900 and bug# 53394 to your overlay. Thanks.
Hi Johan, Thanks for your comment. I will definitely add the sparse matrix stuff but I simply haven't gotten around to testing. My initial goal will be the get the 40 or so octave-forge-xxxx ebuilds out and then I will have a closer look at the sparse matrix stuff and add it to the octave ebuild. Best, Markus
I've tried the octave-2.9.12 build and it seems to build fine. So far I don't see any octave-forge-xxxx packages in your overlay so I tried to create my own. It seems that the install is actually managed by octave. http://octave.sourceforge.net/FAQ.html#install I tried doing this in the context of an ebuild (see below) and got a sandbox violation. echo pkg install plot-1.0.0-tar.gz |/usr/bin/octave How do you plan to do it? Have you made progress? Thanks,
Hi Peter, Unfortunately, I haven't had the time to look at this in much detail yet. Hopefully, I will have some time next week. The most sensible thing to do would be to not use octave's pkg install command but let the ebuild do the compiling and installing. As far as I can tell the "pkg" command (see /usr/share/octave/2.9.12/m/pkg/pkg.m) is simply a wrapper that does just that. If this leads to much code duplication in each of the octave-forge ebuilds we should consider writing an eclass that automates this. Any thoughts on this would be welcome. Thanks, Markus
We definitely need to make some progress here since octave is so much more functional with octave-forge. In response to comment #3, maybe setting the "prefix" appropriately first and then using the install option "-local" would help (see >pkg help). I would like to try to help, but maybe you could post a start of an ebuild for me to work with (or by email)? Thanks!
I finally found some time to fight my way through 1600+ lines of octave installer code. Clearly, we can't use octave's built in package installer since we need to be able to add and remove octave-forge packages from the live filesystem (outside the sandbox) which is portage's job, as well as update the octave database file responsible for keeping track of which octave-forge package is installed and where. Hence, I've decided to write an octave-forge.eclass which provides the relevant features from octave's pkg command. The individual ebuilds themselves should then be trivial to write and maintain. I hope I can whip up something fairly quickly but there are a few tricky issues along the way so we'll see how things progress. Best, Markus
Folks, I have just uploaded the files for the octave-forge.eclass as well as ebuilds for octave-forge-audio and octave-forge-gsl, both of which have been my guinea pigs for the last couple of weeks. Please be aware of the fact that the eclass currently is alpha and things may break. However, things seem to work fine for me, at least for the two octave-forge ebuilds I've posted. I'll have to iron out some rough edges and there will probably be some changes/additions to the eclass to accomodate the remaining octave-forge ebuilds. But overall I am hopeful that the eclass will do its job. As you may notice, the actual octave-forge ebuilds are now trivial to write and pretty much only contain additional dependencies. Please give them a spin, make sure they work in octave itself and please report all problems so I can iron out as many bugs as possible. I'll post additional octave-forge packages as soon as I have some time. cheers, Markus
I'd like to help test these. Can you give, or point me to, brief instructions about where to place the eclass file and how to sync with your overlay? So far I have had to manually make the directory tree and manually download each file. Thanks, Jonathan (In reply to comment #7) > I have just uploaded the files for the octave-forge.eclass as well as > ebuilds for octave-forge-audio and octave-forge-gsl, both of > which have been my guinea pigs for the last couple of weeks. ><snip> > Please give them a spin, make sure they work in octave itself > and please report all problems so I can iron out as many > bugs as possible.
Hi Jonathan, Simply copy the octave-forge.eclass in the eclass directory in your local overlay, e.g., /usr/local/portage/eclass. Then move the content of the octave-forge-audio/gsl directories to /usr/local/portage/sci-mathematics. Then, you should be able to just emerge octave-forge-audio, octave-forge-gsl as usual. If you have already installed some octave-forge packages "by hand" into /usr/share/octave portage I'd recomment that you move them out of the way for testing (i.e. /usr/share/octave/packages as well as the database file /usr/share/octave/octave_packages) since otherwise there may be potential for some clashes since portage of course doesn't know about these. Please don't hesite to post back if you need additional help. Best, Markus
Created an attachment (id=125794) [details] sci-mathematics/octave-forge-gsl
Created an attachment (id=125795) [details] sci-mathematics/octave-forge-geometry
OK, I tested "gsl" and created "geometry". I noticed the gsl ebuild description and url were copied from audio. I fixed this and have added the ebuild as an attachment here. I have also attached an ebuild for the geometry package. The packages seem to be working for me on amd64, although I haven't tested them thoroughly yet; e.g. I haven't tried uninstalling them. Jonathan
Hi Jonathan, Thanks for pointing out the "messed up" description. I'll fix this as soon as I get to it. Best, Markus
Created an attachment (id=125929) [details] patch for octave-forge.eclass Not all octave-forge packages have a configure script. This patch tests for one.
Created an attachment (id=125930) [details] sci-mathematics/octave-forge-general
Created an attachment (id=125932) [details] sci-mathematics/octave-forge-optim
Created an attachment (id=128959) [details] Octave-forge-2007.07.26 split ebuilds Hi everybody, Based on the fantastic work of Markus, I've set up the whole complete octave-forge packages available in the main repository (http://octave.sourceforge.net/packages.html) as split ebuilds. I've also updated the meta octave-forge ebuild, and the eclass file to fix problems with some packages that had configure and Makefile not in the src directory but in the main directory instead. You'll find my complete job in this archive. The whole ebuilds are keyworded ~x86 because it's the only architecture I have. They have all been tested with octave 2.9.13, and the only package that does not work is Zenity, it shows an error message when I try to load it from a session. Hope you'll find this useful, Reynald
Hi Reynald, That's fantastic, thank you very much! I'll check it out over the weekend and will move things into my overlay. If other people could test it out as well and report back any problems that would be much appreciated. We particularly need to make sure that the eclass handles emerging/unmerging and updating of the database reliably. Best, Markus
Folks, My overlay now contains all octave-forge ebuilds apart from the splines one since it has a different license which I have to look at in more detail. I've cleaned up the eclass quite a bit and also added an octave-forge-meta ebuild which should pull in all of octave-forge. Please test and report all problems. I am planning of moving this into the gentooscience overlay fairly soon. best, Markus
I tried to emerge everything on an amd64 system except vrml (freewrl has no amd64 keyword). I had four problems: 1) typo in octcdf: DEPENT -> DEPEND 2) parallel does not compile (amd64 thing?) >>> Unpacking source... >>> Unpacking parallel-1.0.2.tar.gz to /tmp/portage/portage/sci-mathematics/octave-forge-parallel-1.0.2/work >>> Source unpacked. >>> Compiling source in /tmp/portage/portage/sci-mathematics/octave-forge-parallel-1.0.2/work/parallel-1.0.2 ... /tmp/portage/portage/sci-mathematics/octave-forge-parallel-1.0.2/work/parallel-1.0.2 /tmp/portage/portage/sci-mathematics/octave-forge-parallel-1.0.2/work/parallel-1.0.2 mkoctfile -s sclose.cc mkoctfile -s connect.cc mkoctfile -s pserver.cc mkoctfile -s recv.cc mkoctfile -s reval.cc recv.cc: In function ‘octave_value_list Frecv(const octave_value_list&, int)’: recv.cc:133: warning: overflow in implicit constant conversion recv.cc:135: error: cast from ‘double*’ to ‘int’ loses precision recv.cc:136: warning: comparison is always true due to limited range of data type recv.cc:146: error: cast from ‘double*’ to ‘u_int32_t’ loses precision recv.cc:183: warning: overflow in implicit constant conversion recv.cc:185: error: cast from ‘Complex*’ to ‘int’ loses precision recv.cc:186: warning: comparison is always true due to limited range of data type recv.cc:196: error: cast from ‘Complex*’ to ‘u_int32_t’ loses precision recv.cc:237: warning: overflow in implicit constant conversion recv.cc:239: warning: comparison is always true due to limited range of data type recv.cc:241: error: cast from ‘char*’ to ‘int’ loses precision pserver.cc: In function ‘int reval_loop(int)’: pserver.cc:206: warning: overflow in implicit constant conversion pserver.cc:208: warning: comparison is always true due to limited range of data type pserver.cc:210: error: cast from ‘char*’ to ‘int’ loses precision make: *** [recv.oct] Error 1 make: *** Waiting for unfinished jobs.... pserver.cc: In function ‘octave_value_list Fpserver(const octave_value_list&, int)’: pserver.cc:417: warning: overflow in implicit constant conversion make: *** [pserver.oct] Error 1 reval.cc: In function ‘octave_value_list Freval(const octave_value_list&, int)’: reval.cc:118: warning: overflow in implicit constant conversion reval.cc:120: warning: comparison is always true due to limited range of data type reval.cc:122: error: cast from ‘char*’ to ‘int’ loses precision make: *** [reval.oct] Error 1 !!! ERROR: sci-mathematics/octave-forge-parallel-1.0.2 failed. Call stack: ebuild.sh, line 1638: Called dyn_compile ebuild.sh, line 985: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1328: Called octave-forge_src_compile octave-forge.eclass, line 215: Called die !!! make failed in src !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/tmp/portage/portage/sci-mathematics/octave-forge-parallel-1.0.2/temp/build.log'. This ebuild used the following eclasses from overlays: /usr/local/portage/eclass/octave-forge.eclass !!! This ebuild is from an overlay: '/usr/local/portage' 3) sometimes packages fail and then a bit later they succeed (with the same packages installed). Maybe something with MAKEOPTS? For example: >>> Emerging (20 of 37) sci-mathematics/octave-forge-odepkg-0.3.1 to / * odepkg-0.3.1.tar.gz MD5 ;-) ... [ ok ] * odepkg-0.3.1.tar.gz RMD160 ;-) ... [ ok ] * odepkg-0.3.1.tar.gz SHA1 ;-) ... [ ok ] * odepkg-0.3.1.tar.gz SHA256 ;-) ... [ ok ] * odepkg-0.3.1.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking odepkg-0.3.1.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking odepkg-0.3.1.tar.gz to /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work >>> Source unpacked. >>> Compiling source in /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work/odepkg-0.3.1 ... /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work/odepkg-0.3.1 /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work/odepkg-0.3.1 ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed checking for mkoctfile... mkoctfile retrieving compile and link flags from mkoctfile checking for F77_FUNC... yes checking for octave... octave checking for OCTAVE_VERSION in Octave... 2.9.13 checking for octave_config_info('canonical_host_type') in Octave... x86_64-pc-linux-gnu checking for octave_config_info('SHLEXT') in Octave... so checking whether ln -s works... yes checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib checking for strip... strip configure: creating ./config.status config.status: creating Makeconf "$prefix" is /usr "$exec_prefix" is ${prefix} octave commands will install into the following directories: m-files: /usr/share/octave/2.9.13/site/m/octave-forge oct-files: /usr/libexec/octave/2.9.13/site/oct/x86_64-pc-linux-gnu/octave-forge binaries: /usr/libexec/octave/2.9.13/site/exec/x86_64-pc-linux-gnu alternatives: m-files: /usr/share/octave/2.9.13/site/octave-forge-alternatives/m oct-files: /usr/libexec/octave/2.9.13/site/octave-forge-alternatives/oct/x86_64-pc-linux-gnu shell commands will install into the following directories: binaries: ${exec_prefix}/bin man pages: /usr/share/man libraries: /usr/lib64 headers: ${prefix}/include octave-forge is configured with octave: octave (version 2.9.13) mkoctfile: mkoctfile for Octave 13 find . -name NOINSTALL -print # shows which toolboxes won't be installed /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work/odepkg-0.3.1 /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work/odepkg-0.3.1 /tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/work/odepkg-0.3.1 mkoctfile --mex -c odepkg_mexsolver_dopri5.c -o odepkg_mexsolver_dopri5.o mkoctfile --mex -c odepkgmex.c -o odepkgmex.o Unpacking external packages: hairer.tgz mkoctfile --mex -c odepkgext.c -o odepkgext.o make: *** No rule to make target `hairer/dopri5.o', needed by `all'. Stop. make: *** Waiting for unfinished jobs.... Patching external packages: hairer.diff patching file hairer/dc_decsol.f patching file hairer/odex.f patching file hairer/dopri5.f patching file hairer/dop853.f patching file hairer/radau.f patching file hairer/radau5.f patching file hairer/seulex.f patching file hairer/rodas.f !!! ERROR: sci-mathematics/octave-forge-odepkg-0.3.1 failed. Call stack: ebuild.sh, line 1638: Called dyn_compile ebuild.sh, line 985: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1328: Called octave-forge_src_compile octave-forge.eclass, line 215: Called die !!! make failed in src !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/tmp/portage/portage/sci-mathematics/octave-forge-odepkg-0.3.1/temp/build.log'. 4) optiminterp seems to need octave-forge-sockets. Without it it seems to miss a fortran module: /tmp/portage/portage/sci-mathematics/octave-forge-optiminterp-0.2.3/work/optiminterp-0.2.3 /tmp/portage/portage/sci-mathematics/octave-forge-optiminterp-0.2.3/work/optiminterp-0.2.3 /tmp/portage/portage/sci-mathematics/octave-forge-optiminterp-0.2.3/work/optiminterp-0.2.3 mkoctfile -DHAVE_OCTAVE_ -v -c optiminterp.cc FFLAGS="-O" mkoctfile -DHAVE_OCTAVE_ -v -c optimal_interpolation.F90 FFLAGS="-O" mkoctfile -DHAVE_OCTAVE_ -v -c optiminterp_wrapper.F90 x86_64-pc-linux-gnu-g++ -c -fPIC -I/usr/include/octave-2.9.13 -I/usr/include/octave-2.9.13/octave -march=nocona -O2 -pipe -DHAVE_OCTAVE_ optiminterp.cc -o optiminterp.o x86_64-pc-linux-gnu-gfortran -c -fPIC -O -DHAVE_OCTAVE_ optiminterp_wrapper.F90 -o optiminterp_wrapper.o In file optiminterp_wrapper.F90:24 use optimal_interpolation 1 Fatal Error: Can't open module file 'optimal_interpolation.mod' for reading at (1): No such file or directory make: *** [optiminterp_wrapper.o] Error 1 make: *** Waiting for unfinished jobs.... x86_64-pc-linux-gnu-gfortran -c -fPIC -O -DHAVE_OCTAVE_ optimal_interpolation.F90 -o optimal_interpolation.o !!! ERROR: sci-mathematics/octave-forge-optiminterp-0.2.3 failed. Call stack: ebuild.sh, line 1638: Called dyn_compile ebuild.sh, line 985: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1328: Called octave-forge_src_compile octave-forge.eclass, line 215: Called die I have not really tested whether they actually work. Thanks
(In reply to comment #20) > 1) typo in octcdf: DEPENT -> DEPEND Fixed, thanks! > 2) parallel does not compile (amd64 thing?) Compiles for me on x86. I just had a look at the code and there's some really horrible looking back-and-forth casting of variables going on; we should probably report this upstream so they can fix it if it is indeed an error. > 3) sometimes packages fail and then a bit later they succeed (with the same > packages installed). Maybe something with MAKEOPTS? Yeah, that looks like an issues with MAKEOPTS even thought I don't see this here with -j3. Could you try with -j1 and see if that works please! > 4) optiminterp seems to need octave-forge-sockets. Without it it seems to miss > a fortran module: This is another MAKEOPTS issue I think. Could you please also try with -j1! Looks like we have to disable parallel building for octave forge for the time being. > Thanks Thank you for testing!
(In reply to comment #21) > > 2) parallel does not compile (amd64 thing?) > > Compiles for me on x86. I just had a look at the code and > there's some really horrible looking back-and-forth casting of variables > going on; we should probably report this upstream so they can > fix it if it is indeed an error. I'll look at it tomorrow. > > > 3) sometimes packages fail and then a bit later they succeed (with the same > > packages installed). Maybe something with MAKEOPTS? > > Yeah, that looks like an issues with MAKEOPTS even thought I don't > see this here with -j3. Could you try with -j1 and see if that works > please! I have no problems with -j1. 4) is also solved. I had -j5 (which is useless anyway as I found that my processor does not use hyperthreading).
Hi Sebastian, Thanks for testing. I've changed the eclass to disable parallel builds for now. Best, Markus
Octave maintainers list is talking about release 3.0 and a point of discussion is the octave-forge package system. The octave-eclass was listed. Perhaps you might want to joint the discussion? http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-September/004066.html PS The geometry package has gone away. (or will do so very soon, since it is now in octave)
Hi Peter, Thanks for the note; I'll try to have a look at the relevent threads as soon as I get to it. I've bumped octave to 2.9.14 in my overlay and octave-forge-geometry is gone since it is part of the main-line now. As soon as I have commit access to the gentoo-science overlay I'll move everything over. Thanks, Markus
I'm getting the error below after emerging the octave-forge-plot package with 2.9.15. (As yet, this is the only package I've tried). I suspect it has to do with the eclass not adding a needed part of the structure... but I don't have a real understanding of what is going on there and perhaps it should go upstream? Has anybody else tried 2.9.15? By the way I've also bumped the plot package to 1.0.2 ---------------- GNU Octave, version 2.9.15 Copyright (C) 2007 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Octave was configured for "i686-pc-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to <bug@octave.org> (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). For information about changes from previous versions, type `news'. error: structure has no member `archprefix' error: evaluating argument list element number 1 error: evaluating assignment expression near line 1937, column 11 error: called from `pkg:getarchdir' in file `/usr/share/octave/2.9.15/m/pkg/pkg.m' error: evaluating assignment expression near line 2017, column 12 error: evaluating for command near line 2011, column 3 error: called from `pkg:load_packages_and_dependencies' in file `/usr/share/octave/2.9.15/m/pkg/pkg.m' error: called from `pkg:load_packages' in file `/usr/share/octave/2.9.15/m/pkg/pkg.m' error: evaluating switch command near line 244, column 3 error: called from `pkg' in file `/usr/share/octave/2.9.15/m/pkg/pkg.m' error: near line 2 of file `/usr/share/octave/2.9.15/m/pkg/PKG_ADD' error: source: error sourcing file `/usr/share/octave/2.9.15/m/pkg/PKG_ADD' error: near line 11 of file `/usr/share/octave/2.9.15/m/startup/octaverc'
Thank for the note Peter! I'll try to have a look at it asap. Best, Markus
(In reply to comment #26) > I'm getting the error below after emerging the octave-forge-plot package with > 2.9.15. (As yet, this is the only package I've tried). I suspect it has to do > with the eclass not adding a needed part of the structure... but I don't have a > real understanding of what is going on there and perhaps it should go upstream? Upstream changed their package format and thereby sort-of broke backward compatibility with octave-2.9.14. Anyway. I've fixed the octave-forge-eclass to handle this. Also, I updated all the octave-forge ebuilds to their most recent versions and moved all ebuilds over to the science overlay [1]. Hence, after syncing your overlay you should be good to go. I've keyworded all ebuilds x86 and amd64; two of the packages (vrml, parallel) have been excluded from amd64 since the former is missing a dependency and the latter doesn't build. If you have success building on arches other than x86 and amd64 please let me know. As usual, please report any problems so they can be fixed. I've removed the previous overlay from my dev space since all development will now take place in the science overlay. Enjoy! Markus [1] http://overlays.gentoo.org/proj/science
(In reply to comment #28) > (In reply to comment #26) > > I'm getting the error below after emerging the octave-forge-plot package with > > 2.9.15. (As yet, this is the only package I've tried). I suspect it has to do > > with the eclass not adding a needed part of the structure... but I don't have a > > real understanding of what is going on there and perhaps it should go upstream? > > Upstream changed their package format and thereby sort-of broke > backward compatibility with octave-2.9.14. Anyway. I've fixed the > octave-forge-eclass to handle this. > > Also, I updated all the octave-forge ebuilds to their most recent versions > and moved all ebuilds over to the science overlay [1]. Hence, after syncing > your overlay you should be good to go. I've keyworded all ebuilds x86 > and amd64; two of the packages (vrml, parallel) have been excluded > from amd64 since the former is missing a dependency and the latter > doesn't build. If you have success building on arches other than x86 > and amd64 please let me know. > > As usual, please report any problems so they can be fixed. > > I've removed the previous overlay from my dev space since all > development will now take place in the science overlay. > > Enjoy! > > Markus > > [1] http://overlays.gentoo.org/proj/science > Thank you for the great work! I wanted to add that the error I reported above will still occur unless the /usr/share/octave/octave-packages (created prior to version 2.9.15) is removed. The easiest thing I found was to just delete it and reemerge the octave-forge packages. This would not have to be done for each upgrade, just the after the structure change that occurred in 2.9.15. Thanks again, Pete
(In reply to comment #29) > > Thank you for the great work! You are welcome :) > I wanted to add that the error I reported above will still occur unless the > /usr/share/octave/octave-packages (created prior to version 2.9.15) is removed. > The easiest thing I found was to just delete it and reemerge the octave-forge > packages. > Yeah, after upgrading to 2.9.15 one has to manually remove /usr/share/octave/octave-packages and re-emerge all installed packages. Let's hope upstream doesn't do this too often or will at least keep their package manager backward compatible. Markus
Hi guys, the ebuilds in the science overlay don't work for me, because OCT_PKG seems to be null. I had to replace OCT_PKG by OCT_PKG_NAME, like it was called in previous ebuilds. Simon
Created an attachment (id=134350) [details] sci-mathematics/octave-forge-odepkg Corrected description and homepage.
Hi Simon, OCT_PKG should be correct since it is the one that expands to the versioned package name whereas OCT_PKG_NAME is the plain package name. Please make sure that you don't have an old octave-forge.eclass floating around that is being used instead of the most recent one in the overlay, i.e., there should be only one octave-forge.eclass in /usr/portage/local/layman/science/eclass and nowhere else. best. Markus
Using the octave and octave-forge ebuilds in the science overlay, I had a problem with octave-forge-image. Specifically, the .oct files were not in the path, and I subsequently could not read JPEG files. I got the error message: octave:6> img = imread('image-2007-01-04-22:32:50.jpg') error: imread: image data chunk has invalid size error: evaluating if command near line 136, column 5 error: called from `imread' in file `/usr/share/octave/packages/image-1.0.4/imread.m' error: evaluating assignment expression near line 6, column 5 It seems that __magick_read__ isn't in the path so imread assumes the file is a pgm and subsequently fails. It looks as if the octage-forge.eclass has some problems which I corrected in the attached patch. The patch also forces the package name to be lowercase which is consistent with the behaviour of the octave pkg function.
Created an attachment (id=141018) [details] patch to octave-forge.eclass file in science overlay
Hi Roman, Thanks a lot for pointing this out and I believe I just fixed this in svn. cheers, Markus
I get an error running octave with any (?) octave-forge package installed (I tried physical constants and statistics) using recent ebuilds: error: structure has no member `archprefix' error: evaluating argument list element number 1 error: evaluating assignment expression near line 1955, column 11 error: called from `pkg:getarchdir' in file `/usr/share/octave/3.0.0/m/pkg/pkg.m' error: evaluating assignment expression near line 2035, column 12 error: evaluating for command near line 2029, column 3 error: called from `pkg:load_packages_and_dependencies' in file `/usr/share/octave/3.0.0/m/pkg/pkg.m' error: called from `pkg:load_packages' in file `/usr/share/octave/3.0.0/m/pkg/pkg.m' error: evaluating switch command near line 243, column 3 error: called from `pkg' in file `/usr/share/octave/3.0.0/m/pkg/pkg.m' error: near line 20 of file `/usr/share/octave/3.0.0/m/startup/octaverc' error: near line 1 of file `/home/sebschub/.octaverc' To be sure I unmerged every octave-forge package and octave itself and deleted /usr/share/octave. Then I reinstalled the stuff and get the error above. I'm on an AMD64 machine. Any idea? cheers Sebastian
Hi Sebastian, Everything seems to be well on my amd64 system. Could you please check there everything is ok with you .octaverc > error: near line 1 of file `/home/sebschub/.octaverc' cheers, Markus
Hi, my .octaverc is not the problem. If I remove it I get the same error as before just without the very last line. The global octaverc is empty as well (ok, except some standard comments). Thanks Sebastian
(In reply to comment #39) > Hi, > > my .octaverc is not the problem. If I remove it I get the same error as before > just without the very last line. The global octaverc is empty as well (ok, > except some standard comments). > > Thanks > Sebastian > Odd. Just to make sure I understand correctly: With only octave installed all is well and typing, e.g., "pkg list", in octave properly returns that no packages are installed. As soon as you install any octave-forge package from the overlay things break. If this is the case, could you please post your /usr/share/octave/octave_packages file! Also, please make sure that there are no local package lists installed, such as ~/.octave_packages. Thanks, Markus
(In reply to comment #40) > Odd. Just to make sure I understand correctly: With only octave > installed all is well and typing, e.g., "pkg list", in octave > properly returns that no packages are installed. Yes, that's right. > As soon as you > install any octave-forge package from the overlay things > break. If this is the case, could you please post your > /usr/share/octave/octave_packages file! I installed the statistics package and get the error posted above. The package list in octave works, though: octave:1> pkg list Package Name | Version | Installation directory --------------+---------+----------------------- Statistics | 1.0.5 | /usr/share/octave/packages/statistics-1.0.5 The path of the package's .m files is not in the path variable, though. I'll attach the octave_packages file. > Also, please make > sure that there are no local package lists installed, > such as ~/.octave_packages. Yes, that's the case: sebschub@tux ~ $ ls .oct* .octave_hist .octaverc (and .octaverc as mentioned above is not the problem) Thanks
D'oh! Sorry! I just found an old octave.eclass in my local overlay which I forgot to remove (not listed when installing something, just the place of the ebuild is shown...). Now, everything works... Sorry again. Sebastian
(In reply to comment #42) > D'oh! Sorry! I just found an old octave.eclass in my local overlay which I > forgot to remove (not listed when installing something, just the place of the > ebuild is shown...). Now, everything works... > I am glad you figured this one out ... I was running out of suggestions for you to try ;) cheers, Markus
Bugs in two packages: in both octave-forge-image and octave-forge-odepkg, the description reads "Audio recording, processing and playing tools for use with octave". The description for octave-forge-image should be: "Functions for reading, writing, and processing images", or something like that, and the one for octave-forge-odepkg should be "A toolkit for Differential Equations and Initial Value Problems."
Hi Juan, Thanks much for the note. I just fixed this in the overlay. Best, Markus
I had some problems with these octave-forge stuff. The first one is octave's fault, octave-forge-symbolic-1.0.6 tarball doesn't exists. I had to get it from the package bundle. The other one: I had some problems during the last package upgrade. Octave didn't found them, even they were in the correct location. This also caused building failures in those packages that depend on another one, like optim, which depends on miscellaneous. I had to reinstall all of them, then they were found and loaded by octave. And a thought: I think that the octave-forge eclass hides too much information. AFAIK the compile function doesn't do anything, and the package is compiled and installed during the install function. Apart for the obvious problem that those functions doesn't honor their name, the install section doesn't build any logs, and for tracking down the previous error with optim package I had to compile it by hand (I didn't know that I could use pkg list in octave to see if its dependencies where installed).
>The other one: I had some problems during the last package upgrade. Octave >didn't found them, even they were in the correct location. This also caused >building failures in those packages that depend on another one, like optim, >which depends on miscellaneous. I had to reinstall all of them, then they were >found and loaded by octave. Strangely, I've never had any problems upgrading but I try to have a look at it. >And a thought: I think that the octave-forge eclass hides too much information. >AFAIK the compile function doesn't do anything, and the package is compiled and >installed during the install function. Apart for the obvious problem that those >functions doesn't honor their name, the install section doesn't build any logs, >and for tracking down the previous error with optim package I had to compile it >by hand (I didn't know that I could use pkg list in octave to see if its >dependencies where installed). The "problem" is that the current eclass uses octave's "pkg add" command to compile and install the package inside the sandbox. Hence, the compile and install process are one single step and as such can only be done either in src_compile or src_install and I've chosen the latter. The fact that octave's pkg command does not produce any output is very annoying and I have to check if we can patch octave to fix this. Another solution would be to do the compilation and installation ourselves instead of using octave's pkg command. As a matter of fact this is the way it used to be in an earlier version of the eclass. The downside of this approach is that fact that everytime upstream decides to change the way pkg works the eclass will break. I am not quite sure at the moment which one is the better solution, but clearly the non-verbosity of the install phase sucks. Any thoughts? Thanks, Markus
(In reply to comment #47) > The fact > that octave's pkg command does not produce any output is very annoying and > I have to check if we can patch octave to fix this. Have you tried "pkg install -verbose"? Jonathan
(In reply to comment #48) > (In reply to comment #47) > > > The fact > > that octave's pkg command does not produce any output is very annoying and > > I have to check if we can patch octave to fix this. > > Have you tried "pkg install -verbose"? > > Jonathan > Yes, the eclass currently uses "pkg install -verbose -local". I'll see if I can patch the pkg.m file to reveal the compile info. Also, maybe I should move the installation from src_install to src_compile since this may be more intuitive to users. Thanks, Markus
I've changed the eclass and compilation and installation now take place in the proper ebuild functions. Compilation is now also more verbose (though it is buffered as opposed to real-time due to octave's pkg installer). Best, Markus
markusle: is the octave-forge stuff ever going to merge back to the main tree?
While we wait to get this into the portage tree, I have made ebuilds for 22 octave packages, so we can slow this thing even more. I can attach a tarball with all of them if somebody is interested, but I think that there would be too many packages, so maybe we need a new category, like dev-texlive. I have installed all of these packages, and tried some of them, except one, octave-forge-video, which can't be installed because of a bug/feature in octave. It seems that mkoctfile can't parse the "-pthread" flag, which is needed because of the dependency of octave-forge-video in ffmpeg. FreeBSD people have found this bug too, and they have a patch [1]. But maybe I should open a new bug for this, or even better, attach the tarball with the ebuilds. [1] http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2008-August/148801.html
Created an attachment (id=173825) [details] octave-forge.tar.bz2 Here's the tarball with the patches, the previous post is quite useless and confusing without this, and it's only 3kb. If there is anything that I can do to get this in portage soon...
Created an attachment (id=174229) [details] sci-mathematics/octave-forge-video-1.0.1.ebuild I've found that octave-forge-video doesn't have that pthreads problem with lastest ffmpeg, which needs to be stabilized because of the gcc-4.3 stuff, just like this bug, BTW. It needs a patch that I get from upstream, the package is patched in SVN but there isn't a release yet. But since it has been accepted upstream and it has been made to fix ffmpeg API breakage, I don't see any reason to not use it. Here is the ebuild...
Created an attachment (id=174231) [details] octave-forge-video-1.0.1-ffmpeg.patch ... and here is the patch. I have an updated tarball, but with a dir called "sci-mathematics" and the ebuilds with their manifests and patches in their correct subdirs, if somebody is interested. We should think about a new category for this, as I said before. And this bug should be fixed ASAP, because the octave-forge in the tree is ancient and doesn't work with the lastest octave (3.0.3), because octave is not-that-useful without these toolboxes, and because of gcc-4.3. So please, somebody tell what we need to do before.
Can I do something to have this in portage ASAP? Eventually, gcc-4.3 stabilizing people are going to get angry, and we don't want that to happen.
Juan has done a great job for up-to-date octave-forge ebuilds. Currently, octave has been bumped to version 3.2.0 and there are new octave-forge packages, too.
Created an attachment (id=204875) [details] Version bump on many octave-forge packages Most of the files were an old version, and several would not compile on my amd64 system. The upstream versions were fixed. Submitted as a tar since I don't have any write access to the git for layman to use. This seemed like a logical place to post this, is octave-forge for 3.x ever going to move into the mainline?
Created an attachment (id=204876) [details] Script to fetch version numbers of most recent octave-forge packages This is a pretty hacky bash script for getting version numbers off of the octave-forge website, it only works in the /usr/local/portage/layman/science directory currently. It grabs the html from octave-forge, parses it, and grabs the version number of the packages, then looks for ebuilds and compares the versions, if a new version is found, it makes a new ebuild and digest. I'm sure there is an easier way to do it, hope it helps.
octave-forge-meta seems to do moderately well on science overlay. What's with the portage inclusion? I guess eclass needs to go through some review, still something missing? (This thread also doesn't seem too trackerish, perhaps there could be separate bugs for problems with individual ebuilds)
(In reply to comment #60) > octave-forge-meta seems to do moderately well on science overlay. What's with > the portage inclusion? > > I guess eclass needs to go through some review, still something missing? > > (This thread also doesn't seem too trackerish, perhaps there could be separate > bugs for problems with individual ebuilds) > We decided a while ago (sorry, can't come up with a link to the proper thread right now) that we don't want to go the route things are set up right now in the science overlay, i.e. eclass plus many tens of octave-forge ebuilds which are pretty much doing nothing but bloat the portage tree. The proper way to go (if at all possible) is to do something g-cpan like [1], i.e. we have the eclass who does all the work, plus a wrapper that generates and installs octave-forge ebuilds on the fly. Unfortunately, nobody has so far written this wrapper. The eclass itself should be in pretty good shape and somebody has recently actually contacted me with a (what looks like) much improved version. Hence, we really need somebody who wants to spearhead the "g-octave-forge" thingy. Best, Markus [1] http://www.gentoo.org/proj/en/perl/g-cpan.xml
