[DM-3200] Base package fails to build under OS X El Capitan - Jira

Details

Type: Bug
Status: Done
Resolution: Done
Fix Version/s: None
Component/s: base
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

Attachments

Issue Links

is triggering

DM-4310 Missing Doxygen documentation

Done

DM-4327 ActiveMQCPP does not build on OS X El Capitan

Done

DM-4334 libevent does not build on OS X El Capitan

Done

DM-4360 obs_subaru fails to compile after DM-3200

Done

DM-4396 ctrl_execute test fails to find test binary

Done

DM-4609 Partition package should use the standard package layout

Done

DM-4378 Improve SConscript product discovery in AFW and coadd_utils

Done

DM-4513 Quoting of paths in doxygen configuration files breaks makeDocs

Done

relates to

DM-5030 Tests fail on Qserv on OS X El Capitan because of SIP

Done

RFC-215 Disallow executable tests due to "#!/usr/bin/env python" problems on OSX

Adopted

DM-4359 lsstsw deploy on OS X El Capitan fails with git / openssl

Done

DM-4345 OSX CI/jenkins build slaves

Done

mentioned in: Page Loading...

(3 is triggering, 4 relates to, 1 mentioned in)

Activity

Ascending order - Click to sort in descending order

26 older comments

Hide

Permalink

Russell Owen added a comment - 10/Nov/15 11:01 AM

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 - 10/Nov/15 11:01 AM 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

Permalink

Tim Jenness added a comment - 10/Nov/15 11:05 AM

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 - 10/Nov/15 11:05 AM 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

Permalink

Steve Pietrowicz added a comment - 10/Nov/15 12:40 PM

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 - 10/Nov/15 12:40 PM 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

Permalink

Tim Jenness added a comment - 12/Nov/15 3:01 PM

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 - 12/Nov/15 3:01 PM 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

Permalink

Russell Owen added a comment - 16/Nov/15 10:53 AM

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 - 16/Nov/15 10:53 AM 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.

Data Management

Base package fails to build under OS X El Capitan

Details

Description

Attachments

Issue Links

Activity

People

Dates

Jenkins