Re: [AMBER-Developers] bugfix update script

From: Ross Walker <>
Date: Mon, 7 Nov 2011 22:23:37 -0800

Looks great... Now just merge the AMBERTools and AMBER src and test
directories, create a nice smart build script that is aware of whether the
tree contains the full AMBER or just the free AMBER + create a script to
allow us to build release tar files for AMBER and FreeAMBER and we are
laughing! :-)

One question. How does the script handle deleting files, creating blank
directories and or brand new files? - I think several versions of patch do
not support patching a non-existant file for example so you need to be
careful here.

All the best

> -----Original Message-----
> From: Jason Swails []
> Sent: Monday, November 07, 2011 10:13 PM
> To: AMBER Developers Mailing List
> Subject: [AMBER-Developers] bugfix update script
> Hello everyone,
> I've put together a prototype script for managing bug fixes for future
> versions of Amber and AmberTools. This should make it much easier for
> the
> user to apply the latest bug fixes without having to jump through the
> hoops
> they used to. I think the benefit this provides is worth the fact that
> it's written in Python :-P (it works on Python 2.4 -- Python 2.7, so it
> should work on every system we've ever tested it on). It's in the
> master
> branch (but if you try to use it there it will just try applying
> Amber11
> and AmberTools 1.5 patches to your git repo -- don't do that :)
> To keep this email short, I've attached 3 documents describing how to
> use
> this script, how the script was implemented (which may elucidate
> weaknesses), as well as the format restrictions this places on bug
> fixes
> (basically, just let git do it, but it should not be too different than
> what we have now, except for people not used to making individual
> patches
> that need to be applied from AMBERHOME).
> As I think this will do a lot to improve user-friendliness, I would
> *greatly* appreciate any kind of feedback and discussion regarding this
> script. If you can spare it, please take some time, test it out on a
> fresh
> AmberTools 1.5/Amber11 tree, and tell me what you think. How can it be
> improved? Are there any problems with it? Anything unclear? As
> evidenced
> by (which didn't get much if any testing/suggestions
> before
> it was thrown into production), this will greatly benefit from more
> than
> just my ideas and perspective.
> Thanks in advance!
> Jason
> P.S. -- A tip from when I was testing this script:
> To aid in my own testing, I created a new git repository from the
> AmberTools 1.5/Amber11 checkout with the patch_amber script in it. A
> quick
> git init; git add .; git commit -m 'initial commit'
> command in that fresh directory (after you copy in will
> create the git repository and initialize it. Then, you can always
> restart
> from the beginning with
> git clean -f -x -d; git checkout .
> from the amber11 directory (that's the only way it'll clean the whole
> directory).
> Some things I already know and are not bugs -- Amber bugfixes 9 and 12
> will
> fail unless you use --ignore-fails, since both of those bug fixes try
> to
> fix configure from AmberTools 1.4. The script will only ignore failed
> HUNKs if you force it to (this is intentional). Bugfix.17 for Amber
> will
> complain that no files are there to fix. That's because the patch is
> just
> the header, the actual patch is a hacked-up, bzipped tarball of the
> likes
> that we won't see again (since this new script will be able to allow us
> to
> handle that patch done "correctly").
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032

AMBER-Developers mailing list
Received on Mon Nov 07 2011 - 22:30:04 PST
Custom Search