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

newinstall.sh fails to install Miniconda

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: lsst
    • Labels:
      None

      Description

      $ bash newinstall.sh 
       
      LSST Software Stack Builder
      =======================================================================
       
      ######################################################################## 100.0%
      Detected git version 2.13.3. OK.
       
       
      In addition to Python 2 (>=2.7) or 3 (>=3.5), some LSST packages depend on
      recent versions of numpy, matplotlib, and scipy.  If you do not have all of
      these, the installation may fail.  Using the Miniconda Python distribution
      will ensure all these are set up.
       
      Miniconda 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 the Miniconda Python distribution (if
      unsure, say yes)? yes
       
      Configured EUPS_PKGROOT: https://eups.lsst.codes/stack/src
       
      ::: Deploying Miniconda2-4.2.12-MacOSX-x86_64.sh
      mktemp: too few X's in template ‘XXXXXXXX.Miniconda2-4.2.12-MacOSX-x86_64.sh’
      

        Attachments

          Issue Links

            Activity

            Hide
            jhoblitt Joshua Hoblitt added a comment -

            Unless the the repo in question needs to be CI'able by lsstsw, I have generally followed the conventional github model of fork + PR to prevent littering branches in the canonical repo. I don't believe that the published workflow process is really intended for repos which do not contain an EUPS product. I recall Jonathan Sick and I having some discussion about this at the time the guide was written, but have forgotten the details.

            Show
            jhoblitt Joshua Hoblitt added a comment - Unless the the repo in question needs to be CI'able by lsstsw , I have generally followed the conventional github model of fork + PR to prevent littering branches in the canonical repo. I don't believe that the published workflow process is really intended for repos which do not contain an EUPS product. I recall Jonathan Sick and I having some discussion about this at the time the guide was written, but have forgotten the details.
            Hide
            jhoblitt Joshua Hoblitt added a comment -

            Review comments on PR have been addressed. It looks like travis has woken up enough to run the linux matrix cells. OSX still has not triggered yet. I'll give it an our or so for OSX to run and then merge.

            Show
            jhoblitt Joshua Hoblitt added a comment - Review comments on PR have been addressed. It looks like travis has woken up enough to run the linux matrix cells. OSX still has not triggered yet. I'll give it an our or so for OSX to run and then merge.
            Hide
            jhoblitt Joshua Hoblitt added a comment -

            John Swinbank Could you re-test in your OSX+GNU env to confirm this issue is resolved?

            Show
            jhoblitt Joshua Hoblitt added a comment - John Swinbank Could you re-test in your OSX+GNU env to confirm this issue is resolved?
            Hide
            swinbank John Swinbank added a comment -

            Thanks Josh — I can confirm this is working for me.

            Not a big deal in this case, but I do request that everybody follows our regular workflow. I understand that you have well thought through reasons for not doing so, but that doesn't scale: if everybody started doing their own thing, even with the best of technical justifications, we'd wind up confused and chaotic. (And Jonathan may have written the docs, but he doesn't get to issue exemptions.)

            Also — no merge commit? I'm not sure if that's just an oversight or if it was another variation on our regular workflow. I do find them very useful for tracing which ticket a particular piece of work originated on.

            Show
            swinbank John Swinbank added a comment - Thanks Josh — I can confirm this is working for me. Not a big deal in this case, but I do request that everybody follows our regular workflow. I understand that you have well thought through reasons for not doing so, but that doesn't scale: if everybody started doing their own thing, even with the best of technical justifications, we'd wind up confused and chaotic. (And Jonathan may have written the docs, but he doesn't get to issue exemptions.) Also — no merge commit? I'm not sure if that's just an oversight or if it was another variation on our regular workflow. I do find them very useful for tracing which ticket a particular piece of work originated on.
            Hide
            jhoblitt Joshua Hoblitt added a comment -

            I'm scratching my head as to the lack of a merge commit. The only theory I can come up with is that github did a "rebase" PR merge and I mashed the button without noticing a non-standard mode was selected. There doesn't seem to a record post PR merge of the "method" used.

            Show
            jhoblitt Joshua Hoblitt added a comment - I'm scratching my head as to the lack of a merge commit. The only theory I can come up with is that github did a "rebase" PR merge and I mashed the button without noticing a non-standard mode was selected. There doesn't seem to a record post PR merge of the "method" used.

              People

              • Assignee:
                jhoblitt Joshua Hoblitt
                Reporter:
                swinbank John Swinbank
                Reviewers:
                John Swinbank
                Watchers:
                John Swinbank, Joshua Hoblitt, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel