[Debichem-devel] some improvements to the vmd packaging
Johannes Schauer
j.schauer at email.de
Fri Sep 13 13:36:54 UTC 2013
Hi,
Quoting Steffen Möller (2013-08-30 13:55:18)
> I do not have the spare capacity at the very moment and am very happy about
> your work.
I see you uploaded my changes. I will base additional contributions on them.
Thanks!
One thing I fixed was the plugin loading. In another email to me you noticed
that you were not able to load some files anymore. The reason for that is
twofold:
- the vmd build system doesnt declare dependencies between targets in the
Makefiles correctly
- the vmd build system copies non-existing files without ever failing with a
non-zero exit status
This led to the fact that my patches accidentally removed the plugin building.
The patch attached to this email fixes this problem by building the plugins
differently (it removes an earlier patch and builds directly from debian/rules)
and also by patching the way the distrib target works. It now declares its
dependencies correctly and fails on errors.
We are now using vmd in production and noticed some other things. First of all,
the Debian tachyon version works like a charm, so I added a Recommends for it.
Sadly povray is non-free and doesnt exist in Debian right now. For the case it
becomes available I left a commented line in debian/control as a reminder for
the future.
We also noticed two additional problems. Vmd needs binaries called Stride and
SURF (not the image registration surf) for certain displaying tasks. Those
binaries are under their own non-free undistributable licenses which of course
adds additional headache... Both can currently be downloaded from here:
http://www.ks.uiuc.edu/Research/vmd/extsrcs/
Instead of creating new source and binary packages from them, I would just
include them into the vmd source package. Does that sound right?
Another problem was due to me having compiled vmd with cuda. This drew in
non-free dependencies which upon installation deactivated glx on our machines.
The machine I tried it on only has an Intel graphics card and no nvidia
graphics card. It took me some while to figure out that one has to run:
update-alternatives --config glx
to fix the broken system state introduced by installing the nvidia stuff. So
maybe it would make sense to have a normal vmd version and a vmd-cuda version
in addition? Systems without an nvidia graphics card would then not have to
install all those nvidia things. Of course compiling vmd twice with different
configure settings complicates the debian/rules file but I'm willing to try
whether it can be done more or less nicely or not. Do you know an example
package I can look at to see how others do such a thing of compiling the same
source twice with different settings to create different binary packages?
A last thing is with respect to redistributability of vmd. I wrote an email
about this and the other issues to the vmd mailing list [1] but do not expect
any license changes. Until then, maybe there is another way this can be
achieved. I wrote the following python script which allows to verify one self
at the commandline:
import mechanize
from lxml import etree
import sys
from subprocess import call
br = mechanize.Browser()
br.open("http://www.ks.uiuc.edu/Development/Download/download.cgi?UserID=&AccessCode=&ArchiveID=1190")
def foo(n):
try: return "UserName" in n and "Password" in n
except: return False
br.select_form(predicate=foo)
br["UserName"] = sys.argv[1]
br["Password"] = sys.argv[2]
resp = br.submit()
def foo(n):
try: return "LicenseText" in n
except: return False
br.select_form(predicate=foo)
print br["LicenseText"]
def foo(n):
try: return "AgreeToLicense" in n
except: return False
br.select_form(predicate=foo)
resp = br.submit("AgreeToLicense")
tree = etree.fromstring(resp.read(), etree.HTMLParser())
call(["wget", "http://www.ks.uiuc.edu"+tree.xpath("//meta[@http-equiv='refresh']/@content")[0][6:]])
As you can see from the last line, the final download is done by just executing
a wget process. So no cookies or special session ids are required to download
vmd. In fact, the directory with the vmd binary even offers a directory
listing. I'm not posting the direct link here as I have no clue about legal
issues. But you are free to execute above script and then look at the url which
wget downloaded from. Since everybody can access this url without
authentication, it would even be possible to create a better debian/watch file
which can download the file directly. While this would be technically possible,
the license of course still requires that one has registered oneself with the
website before using vmd.
Extending the above python script could potentially allow to create a package
like the non-free adobe flash package which downloads a binary from the
internet upon installation. Maybe something similar can be done for vmd
together with checking the login as the script above does?
Here a short overview of what the attached patch does:
- deletes more things from the upstream tarball to make it even cleaner
- vmd Recommends: tachyon
- fix a hardening problem in a plugin
- instead of patching vmd, do the plugin building from debian/rules (remove
plugins_build.patch)
- activate verbose builds by removing the .SILENT target in all plugins for
full verbosity (output was redirected to /dev/null before)
- exit with an error if any plugin doesnt build/install
- fix plugin makefile target dependencies
- drop tcsh dependency as build.csh is not called anymore
The initially mentioned problem with plugin building should not occur again
because of the fixes in the last three points. If something goes wrong now, the
build process will fail. And less vmd changes are needed to build. Instead
those are moved to debian/rules. This means no calls to build.csh anymore (no
tcsh dependency) and no need for Make-arch anymore as variables are set in
debian/rules now.
Something I didnt try yet is whether everything works well with i386. It's on
my TODO list.
cheers, josch
[1] http://www.ks.uiuc.edu/Research/vmd/mailing_list/vmd-l/22536.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmd.patch
Type: text/x-diff
Size: 33633 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20130913/c1621356/attachment-0001.patch>
More information about the Debichem-devel
mailing list