ebuild for Arp Warp. Arpwarp is a software suite for improvement and objective interpretation of crystallographic electron density maps and automatic construction and refinement of macromolecular models. This is a often used software in macromolecular crystallography. Should be available on gentoo. Tested on x86 where it works, but should also work with amd64. Hope someone could test it. Reproducible: Always
Created attachment 145081 [details] sci-chemistry/arp-warp-7.0.1.ebuild
Created attachment 145083 [details] license
Created attachment 146035 [details] arp-warp-bin-7.0.1.ebuild I learned some thing, improved something. :) Cleaned some lines, renamed to bin. (Symlinks aren't corrected as long as I don't know how to use them correctly.)
> # Copyright 1999-2008 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: $ > > inherit eutils autotools python > > DESCRIPTION=" ARP/wARP is a software for improvement and interpretation of crystallographic electron density maps" > SRC_URI="arp_warp_7.0.1.tar.gz" Versions shouldn't be hardcoded. > HOMEPAGE="http://www.embl-hamburg.de/ARP/" > LICENSE="ArpWarp" > RESTRICT="fetch" > SLOT="0" > KEYWORDS="-* ~x86" No amd64? > IUSE="" > RDEPEND="|| ( app-shells/tcsh app-shells/csh ) > >=sci-chemistry/ccp4-6 > sys-apps/gawk > >dev-lang/python-2.3" You probably want >= here, >2.3 means 2.3.0.1 fulfills it. > DEPEND="${RDEPEND}" Unlikely. > pkg_nofetch(){ > einfo "Fill out the form at http://www.embl-hamburg.de/ARP/" > einfo "and place these files: ${A}" > einfo "in ${DISTDIR}" > } > > pkg_setup(){ > # if use gui && built_with_use sci-chemistry/ccp4 X;then > # einfo "The ArpWarp gui needs sci-chemistry/ccp4 to be build with X" > # die "sci-chemistry/ccp4 without X" > # fi > #Adopted from the original installer > einfo "Checking decimal seperator" > testcommand=`echo 3 2 | awk '{printf"%3.1f",$1/$2}'` Let's adapt this stuff to Gentoo/bash conventions. Use $(command) instead of `command`. > if [ $testcommand == "1,5" ];then > ewarn "*** ERROR ***" > ewarn " 3/2=" $testcommand > ewarn "Invalid decimal separator (must be ".")" > # ewarn > # ewarn "One way of setting the decimal separator is:" > # ewarn "setenv LC_NUMERIC C' in your .cshrc file" > # ewarn "tor" > # ewarn "export LC_NUMERIC C' in your .bashrc file" > # ewarn "Otherwise please consult your system manager" Why's this commented? > die > fi > einfo "Checking SSE2 extensions availability" > if [ grep sse2 /proc/cpuinfo >& /dev/null ];then No need for the brackets, and you can use -q instead of >&/dev/null. > ewarn " ***WARNING***" > ewarn "The CPU on this hardware platform is lacking the SSE2 instruction set!" > ewarn "Some executables of ARP/wARP 7.0.1 however depend on these. Take notice that" > ewarn "part of the software will not work and consider remote job submission to the" > ewarn "dedicated facility at EMBL-Hamburg." > fi > # namesystem=`uname` > # nameprocessor=`uname -m | sed -e 's/ //g'` > # currentplatform="bin-"${nameprocessor}"-"${namesystem} > # # Checking availability of 'SSE2' extensions for platforms where it matters > # if [ $namesystem == "Linux" ]; then > # bin/$currentplatform/sse2_detection >& /dev/null > # if [ $status ];then > # echo > # ewarn " ***WARNING***" > # ewarn "The CPU on this hardware platform is lacking the SSE2 instruction set!" > # ewarn "Some executables of ARP/wARP 7.0.1 however depend on these. Take notice that" > # ewarn "part of the software will not work and consider remote job submission to the" > # ewarn "dedicated facility at EMBL-Hamburg." > # echo > # fi > # fi > } > > src_unpack() { > unpack ${A} > mv arp_warp_7.0.1 ${P} Hardcoded version. You might also want to consider setting S (the source directory) at the top of the ebuild, with the other variables, instead of moving directories. > } > > src_compile(){ > cd flex-wARP-src > for i in `ls *py`;do > python_mod_compile $i > done Weird. Can you do this in pkg_postinst and do python_mod_optimize for the whole directory instead? > } > > src_install(){ > python_version > insinto /opt/${P}/byte-code/python-${PYVER} > doins flex-wARP-src/*{pyc,pyo} ||die "python-code" This is really strange. Is it actually required? Now I see why you were manually compiling above. There's no value in this die message, because portage will print the command it died on. > > insinto /opt/${P}/flex-wARP-src-261 What's this 261 mean? > doins flex-wARP-src-261/*py > dosym /opt/${P}/flex-wARP-src-261 /opt/${P}/flex-wARP-src dosym flex-wARP-src-261 /opt/${P}/flex-wARP-src Although really, can you just move the directory? > > exeinto /opt/${P}/bin/bin-`uname -m`-`uname` > doexe bin/bin-`uname -m`-`uname`/* ||die "executables" Another die message without value. > > exeinto /opt/${P}/share > doexe share/*sh > insinto /opt/${P}/share > doins share/*{gif,XYZ,bash,csh,dat,lib,tbl,llh} > > for i in `ls "${D}"opt/${P}/share/` > do > dosym /opt/${P}/share/$i /opt/${P}/bin/bin-`uname -m`-`uname`/$i dosym $i /opt/${P}/... This is symlinking binaries into share/? That seems odd. > done > > sed 's:arpwarphome="$1X":arpwarphome="/opt/arp-warp-7.0.1":'<share/arpwarp_setup_base.bash>${T}/arpwarp_setup.bash > sed 's:arpwarphome="$1X":arpwarphome="/opt/arp-warp-7.0.1":'<share/arpwarp_setup_base.csh>${T}/arpwarp_setup.csh Hardcoded versions. Also, use in-place sed: sed -i -e "s:foo:bar:g" file > > insinto /usr/share/${P}/ > doins "${T}"/arpwarp_setup.{bash,csh} > > dodoc README > dohtml -r manual/* > insinto /usr/share/doc/${PF} > doins -r examples ARP_wARP_CCP4I6.tar.gz > } > > pkg_postinst(){ > einfo "Do not forget to add this line in your .cshrc file:" > einfo "source /usr/share/${P}/arpwarp_setup.csh" What you can do instead is just install a *.csh file to /etc/profile.d/ and it should get dealt with. > einfo "" > einfo "If you prefer to use bash, add the following line in your .bashrc or .bash_profile file:" > einfo "source /usr/share/${P}/arpwarp_setup.bash" Same, for /etc/profile.d/*.sh > einfo "" > einfo "The ccp4 interface file could be found in /usr/share/doc/"${P} > einfo "" > }
Created attachment 148954 [details] arp-warp-bin-7.0.1-r1.ebuild I have rewriten the whole thing and it should be much simpler and clearer now. There is no need for the src and other stuff which was installed by the old ebuild. Two things still don't work: 1. on amd64 it could be installed, but as ccp4 is need and doesn't support amd64 it does not. 2. For the GUI another solution must be found. Until then it must be installed by the user.
Created attachment 148955 [details] setup-7.0.1-r1.patch
Created attachment 148956 [details] setup-7.0.1.patch
(In reply to comment #5) > Created an attachment (id=148954) [edit] > arp-warp-bin-7.0.1-r1.ebuild Thanks for the update! I'll look it over soon. > I have rewriten the whole thing and it should be much simpler and clearer now. > There is no need for the src and other stuff which was installed by the old > ebuild. Two things still don't work: 1. on amd64 it could be installed, but as > ccp4 is need and doesn't support amd64 it does not. I'm running ccp4 on my amd64 right now.
(In reply to comment #8) > I'm running ccp4 on my amd64 right now. > But the official ebuild doesn't support it. So arp-warp is blocked by that. Another important thing to this ebuild is, that the ccp4 setup has to be done through /etc/profile.d too, because arp-warp depends on the variables set there. A question to that, does it make sense to give the files in /etc/profile.d priorities similar to /etc/env.d? E.g. 10foo 30bar? In an normal shell everything went fine, the ccp4 as well as the arp-warp variables are set correctly, but during boot it seems to mix up the setups. The arp-warp setup is processed before the ccp4 one.
(In reply to comment #9) > In an normal shell everything went fine, the ccp4 as well as the arp-warp > variables are set correctly, but during boot it seems to mix up the setups. The > arp-warp setup is processed before the ccp4 one. Okey, I answered my questions myself, a short look in /etc/profile helped! :) There for the ccp4 setup should be something like 1ccp4.sh and the arp-warp one 9arpwarp.sh.
(In reply to comment #9) > (In reply to comment #8) > > I'm running ccp4 on my amd64 right now. > > > But the official ebuild doesn't support it. So arp-warp is blocked by that. Oh, did I forget to commit that? I'll get it in soon.
(In reply to comment #11) > Oh, did I forget to commit that? I'll get it in soon. Does it also fix all the other issues reported?
Created attachment 149084 [details] arp-warp-bin-7.0.1-r1.ebuild one thing!
(In reply to comment #12) > (In reply to comment #11) > > Oh, did I forget to commit that? I'll get it in soon. > Does it also fix all the other issues reported? Except for prelink, yeah. I just committed it, should show up in an hour or so.
Cool, I will try it at once. What about the /etc/profile.d thing. Did you just put it in as ccp4.setup.sh like in your overlay or did you index it somehow, like 10ccp4.setup.sh? This is needed for arpwarp to work correctly, or the arpwarp setup has to be index alphabetically, eg zzarp-warp-setup.sh.
(In reply to comment #15) > Cool, I will try it at once. What about the /etc/profile.d thing. Did you just > put it in as ccp4.setup.sh like in your overlay or did you index it somehow, > like 10ccp4.setup.sh? Just normally. I suppose it could be changed, though.
Created attachment 153031 [details] arp-warp-bin-7.0.1.ebuild.diff Updated some lines. Minor change but more beauty.
Created attachment 157057 [details, diff] diff to updated ebuild There was a mistake with naming -> corrected Updated the the control by adding some dies.
I added this to the tree, thanks for your work on it! I ended up making a slight patch to the setup file to make sure the ccp4 one got sourced first. Thinking about the ccp4i thing, it might be worth putting the effort into trying to autogenerate the shared files (modules.def for example) if we get any more packages needing to get into them.
(In reply to comment #19) > Thinking about the ccp4i thing, it might be worth putting the effort into > trying to autogenerate the shared files (modules.def for example) if we get any > more packages needing to get into them. > If in the future here will be a split into separate packages, this will be an optimisation. E.g. refmac introduces new features which needs changes in the gui to use them. I don't know more examples but isn't it that easy: Install them to /etc/ccp4 and symlinking them to the location where ccp4 expect them?
(In reply to comment #20) > (In reply to comment #19) > > Thinking about the ccp4i thing, it might be worth putting the effort into > > trying to autogenerate the shared files (modules.def for example) if we get any > > more packages needing to get into them. > > > > If in the future here will be a split into separate packages, this will be an > optimisation. E.g. refmac introduces new features which needs changes in the > gui to use them. I don't know more examples but isn't it that easy: Install > them to /etc/ccp4 and symlinking them to the location where ccp4 expect them? The whole symlink thing won't work with the shared files, because if you're adding two independent things to ccp4i, neither of the two modules.def will contain information from the other. I was thinking last night about making ccp4i its own package to make updates easier to deal with. That would also make it easier to totally change the setup down the road.
