After running a emerge /usr/portage/app-sci/scilab/scilab-2.7.ebuild, the help browser was not installed. It is a critical component in scilab. Reproducible: Always Steps to Reproduce: 1. emerge /usr/portage/app-sci/scilab/scilab-2.7.ebuild 2. scilab 3. (In scilab) help Actual Results: nothing. Expected Results: Start help browser. I made a fixed ebuild that is available on Gentoo forums, at this address: http://forums.gentoo.org/viewtopic.php?t=77671 Stdout and Stderr of the ebuild for my system are available (link after ebuild text in the forum post linked above). I am NOT an experienced ebuild writer, and my ebuild may have some things wrong. I think I enforced a dependency with dev-lang/tk, and erased some lines that conditioned the install of the help browser to I-don't-know-what. Maybe it's not 1337 engineering, but Works For Me
After running a emerge /usr/portage/app-sci/scilab/scilab-2.7.ebuild, the help browser was not installed. It is a critical component in scilab. Reproducible: Always Steps to Reproduce: 1. emerge /usr/portage/app-sci/scilab/scilab-2.7.ebuild 2. scilab 3. (In scilab) help Actual Results: nothing. Expected Results: Start help browser. I made a fixed ebuild that is available on Gentoo forums, at this address: http://forums.gentoo.org/viewtopic.php?t=77671 Stdout and Stderr of the ebuild for my system are available (link after ebuild text in the forum post linked above). I am NOT an experienced ebuild writer, and my ebuild may have some things wrong. I think I enforced a dependency with dev-lang/tk, and erased some lines that conditioned the install of the help browser to I-don't-know-what. Maybe it's not 1337 engineering, but Works For Me.
Searching for a solution for this bug, I found a patch (a tarball with patched files) on the scilab webpage that obsoletes the fixes in the ebuild (that I wrote some time ago) and that permits to compile scilab cleanly without tcltk. I thick tcltk should stay optional, cause the documentation can still be reached through an external browser (now a drop-down menu should appear hitting 'Help->Help Browser' when tcltk is not in USE, or simply point your favourite browser to /usr/lib/scilab-2.7/man/eng/index.htm). So, I attach my proposed ebuild with the patch, and with a couple of other changes: - make Xaw3d optional - use econf - Important: tweak postinst and postrm. This is necessary cause if scilab-2.7 is reemerged on top of a previous install, the new files are installed and then postrm from the "old" scilab is executed and wipes some of them (and then postinst of the "new" scilab" is executed). About the list of files to install in the ebuild: I copied and pasted from the Makefile, so it can't be wrong ;) Tested with all four combinations of use flags (*sweat* ;) HTH.
Created attachment 17325 [details] proposed scilab-2.7-r1.ebuild
Hi guys Thanks for the fix and patches (although this is a quite rare way to package them :) - I mean on the package creators side). I have tested the ebuild and committed it. Please test. George
Hi, the ebuild works NOT fine for me. I reply so late because I tried to log in to stable.gentoo.org, but it seems that that server is not in use anymore. Anyway, the bug is now that exporting from plots is going to kill scilab, which is far worse than not having the help browser. To replicate: 1 - Open scilab 2 - enter " plot2() ", it will open a simple demo of plot2d() function 3 - in the graph window, click on "File" and select "Export". Chances are, scilab will crash immediately, losing all the variables in scilab space. Since Export is typically the last step when one's looong work is finished, this bug is very frustrating. The message output to StdErr is: usr/bin/scilab: line 205: 15385 Aborted $SCI/bin/scilex $* I believe that we ought better enforce a few dependencies more with tcl and xaw rather than risking this. This bug is actually what made scilab 2.6 suck. It happened also with packages installed without portage, e.g. it happened in RedHat 8.0 which I used back then. So I can't really blame the ebuild - maybe it's the code. Possibly there is some sloppy programming that calls for xaw3d or tcl/ck even though it was specified in the compiling options that it was not to be used (maybe I had not installed them on my former RedHat system, so this would explain things). Will try to modify the ebuild later... Cheers, -Federico
Ok, here we go. I propose this r2 ebuild that requires xaw3d. Even though there is the possibility of compiling without xaw3d, even the scilab FAQ recognises this is prone to crashes and had better be avoided. Tcl-ck is kept optional. Other fix: the file-removing section at pkg_postrm() has been taken out, since it would have erased some key files of people upgrading from 2.7-r2. Instead, the ebuild tells now the user what to do manually. I don't know if there's a way to make the algorithm aware of whether it's in a unmerge or in an upgrade and act accordingly, that would be the best, but m3 n0 1337 h4x0r. The files are just a handful and very small anyway, so the annoyance of entering a command is pretty much irrelevant compared to having to recompile everything from scratch, or figuring out what's happened. Ebuild is double-checked, and I have set it to x86. Plot export does not make the program crash, and the help browser is there. The patch suggested by Gregorio is also in the ebuild, and Works As It Should
Ok, here we go. I propose this r2 ebuild that requires xaw3d. Even though there is the possibility of compiling without xaw3d, even the scilab FAQ recognises this is prone to crashes and had better be avoided. Tcl-ck is kept optional. Other fix: the file-removing section at pkg_postrm() has been taken out, since it would have erased some key files of people upgrading from 2.7-r2. Instead, the ebuild tells now the user what to do manually. I don't know if there's a way to make the algorithm aware of whether it's in a unmerge or in an upgrade and act accordingly, that would be the best, but m3 n0 1337 h4x0r. The files are just a handful and very small anyway, so the annoyance of entering a command is pretty much irrelevant compared to having to recompile everything from scratch, or figuring out what's happened. Ebuild is double-checked, and I have set it to x86. Plot export does not make the program crash, and the help browser is there. The patch suggested by Gregorio is also in the ebuild, and Works As It Should. Well, here comes my first ebuild... :-) Please give it a test.
What the... The system does not let me insert attachments (it says "you have specified no attachment", but I of course did). I'll post the ebuild here, I hope nobody minds... --------------------------------------------- # Copyright 1999-2003 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-x86/app-sci/scilab/scilab-2.7.ebuild,v 1.3 2003/09/11 01:02:54 msterret Exp $ DESCRIPTION="Scientific software package for numerical computations, Matlab lookalike" SRC_URI="ftp://ftp.inria.fr/INRIA/Projects/Meta2/Scilab/distributions/${P}.src.tar.gz http://www-rocq.inria.fr/scilab/bugfix/patch_browsehelp.tar.gz" HOMEPAGE="http://www-rocq.inria.fr/scilab/" LICENSE="scilab" SLOT="0" KEYWORDS="x86" IUSE="tcltk" DEPEND="virtual/x11 x11-libs/Xaw3d tcltk? ( dev-lang/tk )" src_unpack() { unpack ${A} cd ${S} && unpack ${DISTFILES}/patch_browsehelp.tar.gz } src_compile() { local myopts use tcltk || myopts="${myopts} --without-tk" econf ${myopts} || die "./configure failed" env HOME=${S} make all || die } src_install() { PVMBINDISTFILES="\ ${P}/pvm3/Readme \ ${P}/pvm3/lib/pvm \ ${P}/pvm3/lib/pvmd \ ${P}/pvm3/lib/pvmtmparch \ ${P}/pvm3/lib/pvmgetarch \ ${P}/pvm3/lib/LINUX/pvmd3 \ ${P}/pvm3/lib/LINUX/pvmgs \ ${P}/pvm3/lib/LINUX/pvm \ ${P}/pvm3/bin/LINUX/*" BINDISTFILES="\ ${P}/.binary \ ${P}/.pvmd.conf \ ${P}/ACKNOWLEDGEMENTS \ ${P}/CHANGES \ ${P}/Makefile \ ${P}/Makefile.OBJ \ ${P}/Makefile.incl \ ${P}/Makemex \ ${P}/Path.incl \ ${P}/README_Unix \ ${P}/Version.incl \ ${P}/configure \ ${P}/libtool \ ${P}/license.txt \ ${P}/licence.txt \ ${P}/scilab.quit \ ${P}/scilab.star \ ${P}/X11_defaults \ ${P}/bin \ ${P}/config \ ${P}/contrib \ ${P}/demos \ ${P}/examples \ ${P}/imp/NperiPos.ps \ ${P}/imp/giffonts \ ${P}/macros \ ${P}/man/eng/*.htm \ ${P}/man/eng/*/*.htm \ ${P}/man/fr/*/*.htm \ ${P}/man/fr/*.htm \ ${P}/man/*.dtd \ ${P}/man/*/*.xsl \ ${P}/maple \ ${P}/routines/*.h \ ${P}/routines/Make.lib \ ${P}/routines/default/FCreate \ ${P}/routines/default/Flist \ ${P}/routines/default/README \ ${P}/routines/default/fundef \ ${P}/routines/default/*.c \ ${P}/routines/default/*.f \ ${P}/routines/default/*.h \ ${P}/routines/graphics/Math.h \ ${P}/routines/graphics/Graphics.h \ ${P}/routines/graphics/Entities.h \ ${P}/routines/interf/*.h \ ${P}/routines/intersci/sparse.h \ ${P}/routines/menusX/*.h \ ${P}/routines/scicos/scicos.h \ ${P}/routines/sun/*.h \ ${P}/routines/xsci/*.h \ ${P}/scripts \ ${P}/tcl \ ${P}/tests \ ${P}/util" touch .binary strip bin/scilex cd ${S}/tests && make distclean cd ${S}/examples && make distclean dodir /usr/lib (cd ${S}/..; tar cf - ${BINDISTFILES} ${PVMBINDISTFILES} | (cd ${D}/usr/lib; tar xf -)) rm .binary dodir /usr/bin dosym /usr/lib/${P}/bin/scilab /usr/bin/scilab dosym /usr/lib/${P}/bin/intersci /usr/bin/intersci dosym /usr/lib/${P}/bin/intersci-n /usr/bin/intersci-n } # the following is needed in order to create the startup scripts with # the right paths pkg_postinst() { (cd /usr/lib/${P}; make) } pkg_postrm () { einfo "" einfo "Some small files compiled in post-emerge time were probably not erased." einfo "If you have NOT upgraded to another version of scilab," einfo "but want to completely remove scilab from your machine, run:" einfo "rm -Rf /usr/lib/${P}/ /usr/bin/scilab" einfo "" }
I agree about Xaw3d. Regarding the postrm stuff, I thought -r1 it was doing the right things. In case of a package removal, all files are removed. In case of an upgrade, pkg_postrm deletes just those files that will be regenerated by the subsequent pkg_postinst from the new scilab version. Did you notice some strange behaviour? BTW: the homepage has changed, now it can be reached through http://www.scilab.org Bye
Hi Guido, What I noticed happening was that, in an upgrade, first you compile and install the new package, and then uninstall the old one, so actually pkg_postrm( ) comes after pkg_postinst( ), since we are talking of two different ebuilds. Now, portage manages not to remove a new installation's files, but the bash-instructions in pkg_postrm( ) do not. Therefore, what happens is that after an upgrade those files are removed, no matter they are from the new install, and among those there is a certain /usr/lib/scilab... To replicate, try upgrading from 2.6, 2.7 or 2.7-r1, that use basically the same pkg_postrm( ), and try to launch scilab. I was pretty lucky because I had read the ebuild carefully before, but an average user would not know what happened. I guess we never saw this problem since scilab has been stuck in version 2.6 for ages. Thanks for pointing out the new homepage! I had completely forgotten that. Cheers, -Federico
Created attachment 18655 [details] Scilab 2.7-r2 ebuild Enforces dependency with xaw3d (else buggy code); does not remove files (causes problems with upgrading), but prompts user.
Ok... after a bit of testing I can state quite surely that pkg_postrm is executed _before_ pkg_postinst. However, I admit that problems may arise in some cases: upgrading from 2.7 to 2.7-r[0,1,2] won't work because pkg_postrm in 2.7 is broken (2.6 is excluded because it involves a different directory) and we can do nothing about it. The other problem is that if we want pkg_postinst to be succesfull, it has to include the "touch Path.incl" bit (that file could have been removed by pkg_postrm) and probably that's the reason why upgrades to 2.7-r2 fail. In my opinions, upgrades 2.6 -> 2.7-r1 and 2.7-r1 -> 2.7-r1 should work. Ugh... I hope we can get out soon from this mess :) Bye!
Hey guys. Ok, more activity on this package :). Unfortunately I missed this issue of post_inst/rm.. Actually this is a portage limitation, which really should be addressed. I think it isn't in nearest plans, because it is hard to fix and then post.. stuff really shouldn't contain this kind of stuff (since they should be able to work for binary packages as well). In any case it is better to finalize all files while in src_install. So, I did just that: After seing that it is make that is being run I was afraid that some last-minute binaries are being created. Fortunately it all went down to a bunch of wrapper scripts, which are trivial to fix. One-liner grep|sed was all that is necessary. Please take a look at the -r2 (in portage already) and check if it works on you. It is ~x86 now, but I would like to move it to stable ASAP, if it indeed fixes all stuf that we found so far.. George PS. I also added gtk use flag, since scilab apparently started supporting --with-gtk, ableit without mentioning this in documentation (#30219)
Hi George, I tried the install and all seems alright, including uninstall procedure, except that thing with gtk+. It seems that the implementation is not yet mature, and I would recommend to keep it outside the ebuild until there is a better implementation. Problems with gtk: - Does not start demos - Does not start help browser - Gives a number of error messages at start and when calling for other functions as demos or help - Does not give the possibility of choosing the help browser. I think the gtk interface is a _very_ good idea (though I'd prefer Qt...), but at this stage it makes it impossible to use the software productively - I'd say this is an extremely alpha stuff - so it should be left out until it is made working acceptably. Among the positive things with gtk, I could finally use the mouse wheel and type in instruction without worrying that my mouse should be hovering over the scilab window. In case I decided to contribute a bit of my spare time by helping the scilab project to implement a Qt interface, how much time do you think it would take me? I don't really have much programming experience, though I do remember some C from university courses, and would have to learn most things from scratch. I'd like to see scilab in a more eye-candy fashion, since its look sucks a bit to be honest, but I don't know whether I can teach me enough to be useful. Yet I remember reading that programming with Qt should be easy... Regards, -Federico
Thanks Federico. You might want to test again ;). Looks like enabling gtk caused installation procedure bypass building macros. I forced this in ebuild (by descenting into macros dir and calling make), no it does not seem to complain and I was able to run some help stuff. Also I added the check for preinstalled scilab, forcing people who have it to unmerge it before merging this version, since all the previous would cause malfunction of this one upon straight update.. !!Note to anybody who will do updates later: this check should be removed after -r2 goes into stable and some time passes, so taht we can be sure that people migrated to the -r2. George
Great work George! Some notes: during configure I have: --- checking for gtk-config... yes checking for gnome-config... no configure: WARNING: gnome-config not found: I will not use -with-gtk --- so I guess that we need another dependency if gtk is in use (gnome-libs?) gtk should be in IUSE typo: "before continuing" instead of "before continuig" Thanks a lot! Gregorio
Hi George, I have emerge-sync'ed and emerge-scilab'ed, and the problem with gtk is still there. When I push the help menu and select "Scilab help", or equivalently type "help" in, I get: !--error 4 undefined variable : help If I click the demos button, I get: num=x_choose(demolist(:,1),['Click to choose a demo'; !--error 4 undefined variable : demolist at line 16 of exec file called by : exec('SCI/demos/alldems.dem'); When I start, I see the following error message: Startup execution: loading initial environment load('SCI/macros/mtlb/lib') !--error 241 File SCI/macros/mtlb/lib does not exist or read access denied at line 50 of exec file called by : exec('SCI/scilab.star',-1);;quit There's something fishy here. Moreover, the possibility of choosing the browser is still missing. Maybe it's far-fetched, but I'm running scilab under KDE - I have gtk installed for other apps; could this be the reason?
A few other things about gtk: When I close the Scilab window, the process does not die, but zombies on taking something like 80% of the system resources and even being resilient to a root-level kill command (can't imagine how they do it). If you select "Graphic window" and then "+", the Help button will change place and will sit before the Graphic window one. Now, unless that's my configuration (I will test this tomorrow at my work machine), I believe that this gtk stuff should be kept out of the ebuild until it's perfected. It seems to me it's way too work-in-progress.
Tested it on my work machine. Problems are exactly the same, though it worked out in the beginning (I had left USE = "-gtk -gnome" in make.conf, so I had no gtk ;-) I'm more and more sceptical about enabling this feature - I really don't want to be a jerk spitting on other's work, the idea of a gtk interface is great, but this implementation is not yet complete. Regards, -Federico
Hi Federico. Thanks for more testing! Well, what can I say, such behaviour is a blockef for this feature, but strangely looks like nobody else can reproduce it now. Lets try just one last time ;)? Just an idea: what versions of gtk+ do you have installed? More specifically, do you have gtk+-1.2* or only =gtk+-2.0? It looks to me that the package only works woth 1.2, even though ./configre --help asks for >= (and I have both up here, so having 2.0 on top of 1.2 is apparently not a problem).. If this is indeed the case, I can change the dependency to =gtk+-1.2* and this shoud cover it. Or if you think even stricter dependencies are needed I can try some fancy combiation of gtk? and !gtk2 flags to block pure gtk+-1.2. George
Ok, changed DEPEND to contain gtk? ( =x11-libs/gtk+-1.2* >=gnome-base/gnome-libs-1.4.2 ) Lets see if this fixes gtk issue. If it still does not work, I'll probably pull gtk support off, untill it is properly documented. George
Hi George, tried to compile again after another sync, but same old problems. I'm wondering, are you and all the people who manage to get the thing working running gnome? Maybe the dependency is with a bit more than just gtk+. I'm happy with kde and have gtk+ because of some apps, like dia, that use them. On my system, I currently have gtk+-2.2.4-r1 and gtk+-1.2.10-r10. I might try to install gnome to check, but an emerge gnome -p gave me a few screen of packages that scared the hell out of me... :-) Regards, -Federico
>I might try to install gnome to check, but an emerge gnome -p gave me a few >screen of packages that scared the hell out of me... :-) Well, you shouldn't, only a handfull of them are most likely necessary. I added bunch of dependencies to gtk? part of DEPEND, following what ldd scilex gave me. I hope this is all it takes. Please see if this fixes the issue for you, if you still would liek to get gtk interface ;). George
Hi George, it seems that my machine already complies with those new dependencies. I'll ask a friend of mine to install scilab, so we can see whether it's just my machine or what.
Any news concerning this bug? scilab-2.7-r2 has been stable for same time now, maybe this could be closed?
Yes, I would say it's fixed.
