# Base package fails to build under OS X El Capitan

XMLWordPrintable

#### Details

• Type: Bug
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Team:
Architecture

#### Description

I tried to build the stack on a Mac running El Capitan Public beta 2, and it gave three errors in base.

  % Total % Received % Xferd Average Speed Time Time Time Current  Dload Upload Total Spent Left Speed 100 12671 100 12671 0 0 18798 0 --:--:-- --:--:-- --:--:-- 18799   LSST Software Stack Builder =======================================================================   Detected git version 2.3.2 (Apple Git-55). OK.     In addition to Python 2.7, some LSST packages depend on recent versions of numpy, matplotlib, and scipy. If you don't have all of these, the installation may fail. Using the Anaconda Python distribution will ensure all these are set up.   Anaconda Python installed by this installer will be managed by LSST's EUPS package manager, and will not replace or modify your system python.   Would you like us to install Anaconda Python distribution (if unsure, say yes)? yes   Installing EUPS (v1.5.9)... done. Installing Anaconda Python Distribution ...   [ 1/1 ] anaconda 2.2.0 done.  Installing the basic environment ...   [ 1/5 ] doxygen 1.8.5 done.   [ 2/5 ] python 0.0.3 ...  Using externally provided Python 2.7.9 :: Anaconda 2.2.0 (x86_64).  [ 2/5 ] python 0.0.3 done.   [ 3/5 ] scons 2.3.4 done.   [ 4/5 ] sconsUtils 10.1-4-gce72cec+1 done.   [ 5/5 ] lsst 10.1-1-g84e9557+13 done.  Creating startup scripts (bash) ... done. Creating startup scripts (ksh) ... done. Creating startup scripts (csh) ... done. Creating startup scripts (zsh) ... done.   Bootstrap complete. To continue installing (and to use) the LSST stack type one of:   source "/Users/srp/stack/lsst/loadLSST.bash" # for bash source "/Users/srp/stack/lsst/loadLSST.csh" # for csh source "/Users/srp/stack/lsst/loadLSST.ksh" # for ksh source "/Users/srp/stack/lsst/loadLSST.zsh" # for zsh   Individual LSST packages may now be installed with the usual eups distrib install' command. For example, to install the science pipeline elements of the LSST stack, use:   eups distrib install lsst_apps   Next, read the documentation at:    https://confluence.lsstcorp.org/display/LSWUG/LSST+Software+User+Guide   and feel free to ask any questions via our mailing list at:    https://lists.lsst.org/mailman/listinfo/dm-users    Thanks!  -- The LSST Software Teams  http://dm.lsst.org/   srps-Mac-Pro:stack srp$pwd /Users/srp/stack srps-Mac-Pro:stack srp$ ls install.sh lsst srps-Mac-Pro:stack srp$cd lsst srps-Mac-Pro:lsst srp$ ls DarwinX86 eups loadLSST.csh newinstall.sh EupsBuildDir eupsbuild.log loadLSST.ksh site _build loadLSST.bash loadLSST.zsh ups_db srps-Mac-Pro:lsst srp$source loadLSST.bash srps-Mac-Pro:lsst srp$ eups distrib install lsst_apps  [ 1/51 ] cfitsio 3360.lsst1 done.   [ 2/51 ] doxygen 1.8.5 (already installed) done.   [ 3/51 ] eigen 3.2.0 done.   [ 4/51 ] fftw 3.3.3 done.   [ 5/51 ] gsl 1.16.lsst1 done.   [ 6/51 ] minuit2 5.28.00 done.   [ 7/51 ] mysqlclient 5.1.73.lsst1-1-gb8bcc43 done.   [ 8/51 ] python 0.0.3 (already installed) done.   [ 9/51 ] swig 3.0.2.lsst1 done.   [ 10/51 ] xpa 2.1.15.lsst2 done.   [ 11/51 ] boost 1.55.0.1.lsst2+3 done.   [ 12/51 ] mysqlpython 1.2.3+17 done.   [ 13/51 ] numpy 0.0.1+5 ...  Using externally provided numpy v1.9.2.  [ 13/51 ] numpy 0.0.1+5 done.   [ 14/51 ] scons 2.3.4 (already installed) done.   [ 15/51 ] wcslib 4.14+7 done.   [ 16/51 ] astrometry_net 0.50.1+6 done.   [ 17/51 ] matplotlib 0.0.1+5 ...  Using externally provided matplotlib v1.4.3.  [ 17/51 ] matplotlib 0.0.1+5 done.   [ 18/51 ] pyfits 3.2.4.lsst1+3 done.   [ 19/51 ] sconsUtils 10.1-4-gce72cec+1 (already installed) done.   [ 20/51 ] astrometry_net_data 10.0+23 done.   [ 21/51 ] base 10.1-1-g8080078+14 ...   ***** error: from /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/build.log: c++ -o lib/libbase.dylib -dynamiclib -Wl,-install_name -Wl,libbase.dylib src/ModuleImporter.os -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lpthread swig -o tests/testModuleImporterLib_wrap.cc -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 -c++ -python tests/testModuleImporterLib.i c++ -o python/lsstcppimport_wrap.os -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -fPIC -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 python/lsstcppimport_wrap.cc c++ -o tests/ptr tests/ptr.o -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread running tests/ptr... c++ -o tests/testModuleImporter1 tests/testModuleImporter1.o -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread c++ -o tests/testModuleImporterLib_wrap.os -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -fPIC -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 tests/testModuleImporterLib_wrap.cc sh: line 1: 70182 Trace/BPT trap: 5 "tests/ptr" >> "tests/.tests/ptr" 2>&1 failed buildConfig(["doc/doxygen.conf"], ["doc/doxygen.conf.in"]) running tests/testModuleImporter1... sh: line 1: 70192 Trace/BPT trap: 5 "tests/testModuleImporter1" >> "tests/.tests/testModuleImporter1" 2>&1 failed doxygen /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/base-10.1-1-g8080078+14/doc/doxygen.conf /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/base-10.1-1-g8080078+14/doc/mainpage.dox:61: warning: unable to resolve link to lsst.pipe.base.cmdLineTask.CmdLineTask' for \link command c++ -o python/_lsstcppimport.so -bundle -F/ -undefined suppress -flat_namespace python/lsstcppimport_wrap.os -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread -ldl -lpython2.7 c++ -o tests/_testModuleImporterLib.so -bundle -F/ -undefined suppress -flat_namespace tests/testModuleImporterLib_wrap.os -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread -ldl -lpython2.7 running tests/testModuleImporter2.py... failed 3 tests failed scons: *** [checkTestStatus] Error 1 scons: building terminated because of errors. + exit -4 eups distrib: Failed to build base-10.1-1-g8080078+14.eupspkg: Command:  source /Users/srp/stack/lsst/eups/bin/setups.sh; export EUPS_PATH=/Users/srp/stack/lsst; (/Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/build.sh) >> /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/build.log 2>&1 4>/Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/build.msg  exited with code 252   srps-Mac-Pro:lsst srp\$ 

In the file /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/build.log, near the end, we have:

 Checking whether the C++ compiler works... yes C++11 supported with '-std=c++11' Checking for C++ header file tr1/unordered_map... no Setting up environment to build package 'base'. Checking whether int64_t is long ... no Determining RTLD values...ok scons: done reading SConscript files. scons: Building targets ... c++ -o src/ModuleImporter.os -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -fPIC -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 src/ModuleImporter.cc Cannot guess fingerprint without .git directory; will be set to '0x0'. swig -o python/lsstcppimport_wrap.cc -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 -c++ -python python/lsstcppimport.i c++ -o tests/ptr.o -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 tests/ptr.cc cd python && m4 -Dm4_RTLD_GLOBAL=8 -Dm4_RTLD_NOW=2 < lsst64defs.py.m4 > /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/base-10.1-1-g8080078+14/python/lsst64defs.py c++ -o tests/testModuleImporter1.o -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 tests/testModuleImporter1.cc c++ -o lib/libbase.dylib -dynamiclib -Wl,-install_name -Wl,libbase.dylib src/ModuleImporter.os -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lpthread swig -o tests/testModuleImporterLib_wrap.cc -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 -c++ -python tests/testModuleImporterLib.i c++ -o python/lsstcppimport_wrap.os -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -fPIC -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 python/lsstcppimport_wrap.cc c++ -o tests/ptr tests/ptr.o -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread running tests/ptr... c++ -o tests/testModuleImporter1 tests/testModuleImporter1.o -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread c++ -o tests/testModuleImporterLib_wrap.os -c -std=c++11 -g -DLSST_HAVE_TR1=0 -DLSST_LITTLE_ENDIAN=1 -O3 -Wall -Wno-unused-function -fPIC -Iinclude -I/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/include -I/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/include/python2.7 tests/testModuleImporterLib_wrap.cc sh: line 1: 70182 Trace/BPT trap: 5 "tests/ptr" >> "tests/.tests/ptr" 2>&1 failed buildConfig(["doc/doxygen.conf"], ["doc/doxygen.conf.in"]) running tests/testModuleImporter1... sh: line 1: 70192 Trace/BPT trap: 5 "tests/testModuleImporter1" >> "tests/.tests/testModuleImporter1" 2>&1 failed doxygen /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/base-10.1-1-g8080078+14/doc/doxygen.conf /Users/srp/stack/lsst/EupsBuildDir/DarwinX86/base-10.1-1-g8080078+14/base-10.1-1-g8080078+14/doc/mainpage.dox:61: warning: unable to resolve link to lsst.pipe.base.cmdLineTask.CmdLineTask' for \link command c++ -o python/_lsstcppimport.so -bundle -F/ -undefined suppress -flat_namespace python/lsstcppimport_wrap.os -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread -ldl -lpython2.7 c++ -o tests/_testModuleImporterLib.so -bundle -F/ -undefined suppress -flat_namespace tests/testModuleImporterLib_wrap.os -Llib -L/Users/srp/stack/lsst/DarwinX86/boost/1.55.0.1.lsst2+3/lib -L/Users/srp/stack/lsst/DarwinX86/anaconda/2.2.0/lib/python2.7/config -lbase -lpthread -ldl -lpython2.7 running tests/testModuleImporter2.py... failed 3 tests failed scons: *** [checkTestStatus] Error 1 scons: building terminated because of errors. + exit -4 

#### Activity

Hide
Russell Owen added a comment -

Thank you for the explanations.

The extra line break is in scripts.py at line 394:

  state.env.SwigLoadableModule("_" + name, src,  LIBS=state.env.getLibs("main python")) `

I'm glad to know that the doc strings cannot be found, but I still think using standard doc strings would make the code easier to read. And Doxygen will parse standard doc strings provided they begin with """!. But that is clearly out of scope for this ticket.

Regarding processing files in bin.src. I had not realize that only python files were even expected to appear in this directory, but I'm glad you will add a warning. A code comment might clarify things a bit. As I recall you prefer that python executables not a ".py" suffix, so the obvious filter won't work. I do wonder what other sort of executables we can expect. C++ and shell scripts both seem plausible. Other languages seem less likely in the DM stack, though I wonder if java can be expected in orchestration. Do we need to munge the shebang for shell scripts?

Show
Russell Owen added a comment - Thank you for the explanations. The extra line break is in scripts.py at line 394: state.env.SwigLoadableModule("_" + name, src, LIBS=state.env.getLibs("main python")) I'm glad to know that the doc strings cannot be found, but I still think using standard doc strings would make the code easier to read. And Doxygen will parse standard doc strings provided they begin with """! . But that is clearly out of scope for this ticket. Regarding processing files in bin.src. I had not realize that only python files were even expected to appear in this directory, but I'm glad you will add a warning. A code comment might clarify things a bit. As I recall you prefer that python executables not a ".py" suffix, so the obvious filter won't work. I do wonder what other sort of executables we can expect. C++ and shell scripts both seem plausible. Other languages seem less likely in the DM stack, though I wonder if java can be expected in orchestration. Do we need to munge the shebang for shell scripts?
Hide
Tim Jenness added a comment -

We might need to be able to spot other shebangs but I'll cross that bridge when we come across the problem. Shell scripts may be a bit of a problem as /bin/sh will not allow DYLD_LIBRARY_PATH to be passed in.

I do think the documentation in this package will need to be revisited. I'll save that for Jonathan Sick.

Show
Tim Jenness added a comment - We might need to be able to spot other shebangs but I'll cross that bridge when we come across the problem. Shell scripts may be a bit of a problem as /bin/sh will not allow DYLD_LIBRARY_PATH to be passed in. I do think the documentation in this package will need to be revisited. I'll save that for Jonathan Sick .
Hide
Steve Pietrowicz added a comment -

No plans that I'm aware of for Java in orchestration. The only thing in the github DM structure that I'm aware of that uses Java is the complex event processing software in ctrl_evmon, and that's not currently in use or even being distributed.

Show
Steve Pietrowicz added a comment - No plans that I'm aware of for Java in orchestration. The only thing in the github DM structure that I'm aware of that uses Java is the complex event processing software in ctrl_evmon, and that's not currently in use or even being distributed.
Hide
Tim Jenness added a comment -

Closing this now that lsst_distrib builds on El Capitan. I will write up a tech note covering the details.

Qserv does not build because of issues with partition and qserv.

Show
Tim Jenness added a comment - Closing this now that lsst_distrib builds on El Capitan. I will write up a tech note covering the details. Qserv does not build because of issues with partition and qserv.
Hide
Russell Owen added a comment -

Review of technical note http://dmtn-001.lsst.codes/en/master/

This is a very clear and helpful document. Nonetheless, I do have a few suggested changes.

"The Summer 2015 version of the LSST software stack does not work with OS X El Capitan". That is true, but I encourage you to highlight the fact that no version of the stack up to and including Summer 2015. Also, the incompatibility extends beyond that point, and I am wondering if we can explicitly tag a new release soon that is compatible with El Capitan, to give a clearer marker, e.g. Winter 2016. In which case you could say something like "OS X 10.11 (El Capitan) is not compatible with any version of the LSST software stack prior to Winter 2016".

"scons runs the tests and so the tests do not have the correct environment; applications such as processCcd.py will also not function properly." I found this slightly confusing. I suggest you break it into two sentences and explain what you mean by "applications" or even use a different term (I don't think of our bin scripts as applications, but I am not sure what our official documentation calls them), e.g. "Executables in <package>/bin, such as processCcd.py, will also not function properly."

"2. /usr/bin/env can no longer be used to run python scripts from the command line." I suggest omitting the word "python" because this applies to any executable found with /usr/bin/env. I admit that will make the rest of the paragraph a bit messier, as you then need to point out that we only fix python scripts in bin.src because that is all we have, so far. I think it is worth the work to increase clarity and highlight a possible need to modify other kinds of scripts in the future.

"One additional complication on El Capitan is that Apple no longer distribute" is the start of an interesting paragraph. Clearly you view "Apple" as a collective noun, whereas I do not. This may be a British vs. American viewpoint or I may just be exposing my ignorance. Perhaps consider wording that makes the distinction less obvious, such as: "One additional complication on El Capitan is that Apple no longer distributes OpenSSL include files. Apple deprecated the use of OpenSSL in OS X 10.7 (Lion) and removed the include files in El Capitan (though the libraries remain for binary compatibility)." (where I used "distributes" but you would probably prefer "distribute").

In addition, it would help to briefly explain why we felt we could get away with simply removing SSL support. The tickets you refer to later explain this, but a brief note here would be comforting, e.g. "We did not need SSL support in those packages (see DM-4327 and DM-4334) so we disabled it".

I do not know what this means: "Executable shell scripts should ensure they run setup rather than relying on the setup of the parent shell." Could you please say more, or provide an example?

"If a package requires OpenSSL consider optionally using Apple CommonCrypto" I suggest a comma after OpenSSL. Also, I had to read it twice to understand it. I think by "optionally using Apple CommonCrypto" you mean as an alternative to OpenSSL, rather than making Apple CommonCrypto optional in the sense that it can be omitted. Perhaps it would be clearer to say "If a package requires OpenSSL, consider supporting Apple CommonCrypto as an alternative" or "If a package requires SSL, consider supporting both Apple CommonCrypto and OpenSSL".

The hyphen in "pre-requisite" is unnecessary.

Show
Russell Owen added a comment - Review of technical note http://dmtn-001.lsst.codes/en/master/ This is a very clear and helpful document. Nonetheless, I do have a few suggested changes. "The Summer 2015 version of the LSST software stack does not work with OS X El Capitan". That is true, but I encourage you to highlight the fact that no version of the stack up to and including Summer 2015. Also, the incompatibility extends beyond that point, and I am wondering if we can explicitly tag a new release soon that is compatible with El Capitan, to give a clearer marker, e.g. Winter 2016. In which case you could say something like "OS X 10.11 (El Capitan) is not compatible with any version of the LSST software stack prior to Winter 2016". "scons runs the tests and so the tests do not have the correct environment; applications such as processCcd.py will also not function properly." I found this slightly confusing. I suggest you break it into two sentences and explain what you mean by "applications" or even use a different term (I don't think of our bin scripts as applications, but I am not sure what our official documentation calls them), e.g. "Executables in <package>/bin, such as processCcd.py, will also not function properly." "2. /usr/bin/env can no longer be used to run python scripts from the command line." I suggest omitting the word "python" because this applies to any executable found with /usr/bin/env. I admit that will make the rest of the paragraph a bit messier, as you then need to point out that we only fix python scripts in bin.src because that is all we have, so far. I think it is worth the work to increase clarity and highlight a possible need to modify other kinds of scripts in the future. "One additional complication on El Capitan is that Apple no longer distribute" is the start of an interesting paragraph. Clearly you view "Apple" as a collective noun, whereas I do not. This may be a British vs. American viewpoint or I may just be exposing my ignorance. Perhaps consider wording that makes the distinction less obvious, such as: "One additional complication on El Capitan is that Apple no longer distributes OpenSSL include files. Apple deprecated the use of OpenSSL in OS X 10.7 (Lion) and removed the include files in El Capitan (though the libraries remain for binary compatibility)." (where I used "distributes" but you would probably prefer "distribute"). In addition, it would help to briefly explain why we felt we could get away with simply removing SSL support. The tickets you refer to later explain this, but a brief note here would be comforting, e.g. "We did not need SSL support in those packages (see DM-4327 and DM-4334 ) so we disabled it". I do not know what this means: "Executable shell scripts should ensure they run setup rather than relying on the setup of the parent shell." Could you please say more, or provide an example? "If a package requires OpenSSL consider optionally using Apple CommonCrypto" I suggest a comma after OpenSSL. Also, I had to read it twice to understand it. I think by "optionally using Apple CommonCrypto" you mean as an alternative to OpenSSL, rather than making Apple CommonCrypto optional in the sense that it can be omitted. Perhaps it would be clearer to say "If a package requires OpenSSL, consider supporting Apple CommonCrypto as an alternative" or "If a package requires SSL, consider supporting both Apple CommonCrypto and OpenSSL". The hyphen in "pre-requisite" is unnecessary.

#### People

Assignee:
Tim Jenness
Reporter:
Steve Pietrowicz
Reviewers:
Russell Owen
Watchers:
Chris Walter, David Shupe, Frossie Economou, Jim Bosch, John Swinbank, Paul Price, Russell Owen, Steve Pietrowicz, Tim Jenness