Octave-forge is a collection of half- or unmaintained scripts and functions for Octave. This release is specifically tailored for the current version of Octave 2.1.58, see bug 62982, not yet in portage at the time of filing.
Created attachment 39316 [details] Ebuild for octave-forge-2004.09.09
*** Bug 60265 has been marked as a duplicate of this bug. ***
BTW, does octave-forge really depend on sed or should that be in RDEPEND?
Created attachment 39994 [details] New ebuild I think sed is used only in the ebuild (who knows), but not during the program, so I don't think that sed should be made a runtime dependency. On the other hand, octave itself and other programs needed at runtime may indeed. The attachment implements RDEPEND, and has a different licence scheme (some files are BSD, some GPL, some "as-is").
Created attachment 46004 [details] octave-forge-2004.11.16.ebuild Slightly modified from the ebuild in Comment #4. Tested with the new Octave 2.1.64 (although the octave-forge information says its for Octave 2.1.62). Seems to work for me on ~x86.
I confirm that it works for me too. I suggest including it in portage.
I got the ebuild to work, but since the recatagorization, all the app-sci references need to be changed to sci-mathematics instead. I've attached my slightly altered version of the original 11.16.ebuild to reflect this. I have successfully merged it on two systems.
Created attachment 48570 [details] Update to submitted ebuild to fix catagorization renaming
Ebuild spotted in portage, consider bug fixed...
...and closed.
Sorry, I forgot to search for ebuilds here first. The ebuild currently in portage works for you? You don't have the problems mentioned in bug #78502?
Woops, reopening bug again :( I assumed that the ebuild in portage was one of those discussed here, I did not bother making a diff. No, of course the one in portage does not work. It's missing a critical edit of the Makefile (see any of the above ebuilds, they should all work from that point of view). It's the part that tells Make were to put compiled files. Can't remember what was wrong in the Makefile exactly, but I think it has to do with the fact that it wants to install files to a folder named "octave" and not "octave-forge" (or ${P}), as Portage might expect; or maybe it's because the folder is hardcoded in the Makefile instead of being passed by configure. I think I use the second ebuild I submitted (with some adjusments for the new hierarchy of sci-* packages). In any case, octave-forge-2004-11-16 is installed on my machine and I just verified it's working. :-) I'm not sure what the patch in the ${FILESDIR} does, is it useful? Cheers, -Federico
"Of course" it does not work? Could you please elaborate on this and tell me which paths in which files are wrong if you think this is "of course"? I am just unable to see the problem, sorry. The patch you are asking about should do what the man1dir and bindir substitution by sed did in earlier ebuilds to "mex" (otherwise you get sandbox violations).
Whoops - I looked at the wrong patch, I read the octave-forge-2004.02.12-fPIC.patch. Sorry for the misunderstanding, that one is the one that "of course" does nothing. But, does the version in portage work then? I'd prefer not to recompile again to know... Anyway, the patch seems to apply to the mex subdirectory only, while the problem of bad target is the whole package's. I'm not sure what influence that one subdirectory Makefile has, but I remember all the files of octave-forge being misplaced after an emerge when I first tried it. I'm not really sure what should be modified, but I would recommend any of the ebuilds on this page to the reporter of bug 78502.
Admittedly, the ebuild in portage needs modification (and if it was just for the dependencies) - I am a bit irritated that you ask me if the version in portage works since your previous comment looked like it didn't work for you, and that was what I was asking you... Anyway, I'd really like to know how the ebuild currently in portage manages to put all files in the wrong location, since it doesn't on my system and I just want to understand what's going wrong and where.
Look Patrick, I don't want to flame here by any means. It seemed to me that bug 78502 was due to some problem in the ebuild, and your first post gave me the impression that the problem was unsolved, and you were surprised I did not encounter problems with the portage version. I noticed that the portage ebuild wa different from the ones posted here, so I reopened the bug. Since I previosly fixed an issue similar to bug 78502 by inserting the sed commands (I think it was that one), and seeing that the portage version missed those, I thought that was the problem. Furthermore I managed to look at the wrong patch <:-p, so I thought the ebuild was broken. Now I recompiled and yes, the portage version works on my machine, and I consider this bug fixed. Sorry for any misunderstanding!
Didn't mean to flame at all, sorry if I sounded aggressive. It's just that I am still not sure if the version in portage has a problem or not. It works fine for me, it works for you, it doesn't work for the reporter of bug #78502. Thank you for recompiling and reporting!
octave-forge-2004.11.16 in portage builds fine for me. Thanks!
i used the last ebuild attached and i had again the same problem described in the http://bugs.gentoo.org/show_bug.cgi?id=78502 what should i do???? seems i'm the only one with this absurd bug
Patrizio, this happens only with octave-forge, no other package?
Hi Patrizio, Have you tried to do # ebuild octave-forge-2004-11-16.ebuild compile # ebuild octave-forge-2004-11-16.ebuild install # ebuild octave-forge-2004-11-16.ebuild merge and looking at what it happens? From what you say, it seems that for some reason the last step is being skipped.
