Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-3200

Base package fails to build under OS X El Capitan

    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

            Activity

            Hide
            rowen 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
            rowen 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
            tjenness 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
            tjenness 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
            spietrowicz 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
            spietrowicz 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
            tjenness 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
            tjenness 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
            rowen 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
            rowen 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:
                tjenness Tim Jenness
                Reporter:
                spietrowicz Steve Pietrowicz
                Reviewers:
                Russell Owen
                Watchers:
                Chris Walter, David Shupe, Frossie Economou, Jim Bosch, John Swinbank, Paul Price, Russell Owen, Steve Pietrowicz, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel