libarmadillo failure when conda installing ISIS 4.2.0 on Jenkins

[krlberry]

Description
The automated test to check if ISIS can be installed using conda install is failing with a libarmadillo error (cannot find libarmadillo.so)

How to reproduce
Check re-run Jenkins job.

Possible Solution
Possibly moving libarmadillo into the hosts section?

Additional context

[jessemapel]

@kberryUSGS Can you link to the test job that it's failing on. I looked at the most recent and they are failing on not finding kakadu, not armadillo.

[krlberry]

@jessemapel Absolutely! The general job it's failing on is: https://astroservices.usgs.gov/jenkins/job/ISIS-Nightly-Builds/job/anaconda_tests/, and since I've been working on this a little bit, the most recent runs don't show the libarmadillo error, but this one does: https://astroservices.usgs.gov/jenkins/job/ISIS-Nightly-Builds/job/anaconda_tests/379/

[krlberry]

I'm still working on this, but more information:

• Updating the Jenkinsfile to test ISIS 4.3.0 instead of ISIS 4.2.0 fixes the issue of the Jenkins job failing, but as per discussion in the standup, we should absolutely still be supporting installation of ISIS 4.2.0.

[jessemapel]

Likely related to #4108

[krlberry]

@jessemapel Yeah, definitely! I've modified the meta.yaml and am testing now.

[krlberry]

This issue was bigger than I could tackle during continuous support. Here is some information about what I tried and found out:

In the meta.yaml, I tried moving armadillo to the hosts section, but then gsl started failing (cannot find libgsl.so). Then I moved gsl to the hosts section and something else started failing... and so on. After this, I just moved everything to the hosts section that was linked to libisis, removed the run section entirely, since in theory packages which use run_exports should be added to the run section automatically and then result is here: https://anaconda.org/kberryUSGS/isis/files labeled only_run_exports. Note that the list of installation requirements is just far too small for this build.

[krlberry]

Here is the meta.yaml I tried that failed to solve the problem and resulted in the build as described in the previous comment:
And to review, just moving over libarmadillo to hosts did not solve the problem.

# When building ISIS for a public release, be sure that these variables are properly set to reflect
# your current build. Keep in mind that these values are how conda build names its .tar.bz2 build
# file, and so must be unique to other builds sitting in the USGS-Astrogeology channel on Anaconda
# Cloud, or they will be overwritten when you upload this current build. It is always a good idea to
# confirm that you will not be overwriting a file that has already been uploaded by checking the
# channel before building.

# Also keep in mind that there must already be a Release or a Tag by the name <version>_<build_number>
# on the USGS-Astrogeology/ISIS3 repo before invoking the conda build system as this will pull the
# tar.gz of that name to build. After pushing changes for a release build (so as to
# include these changes in the release), but before building using the conda build system, be
# sure to create this Release or Tag.

# This is the version of ISIS that you are building. (Please refer to
# RFC2 (https://github.com/USGS-Astrogeology/ISIS3/wiki/RFC2:-Release-Process) if you are not sure
# about what version you are building.)
# Examples:
#       A Public Release for ISIS3.6.1:                        {% set version = "3.6.1" %}
#       A Release Candidate for ISIS3.6.1:                     {% set version = "3.6.1_RC" %}
#       A custom build of ISIS3.6.1 for the CaSSIS mission:    {% set version = "3.6.1_cassis" %}
{% set version = "4.2.0" %}

# This is the build number for the current version you are building. If this is the first build of
# this version, the build number will be 0. It is incremented by 1 with every consecutive build of
# the same version.
{% set build_number = "6" %}

package:
  name: isis
  version: {{ version }}

source:
  git_url: 'https://github.com/USGS-Astrogeology/ISIS3.git'
  git_tag: {{ version }}
  # url: 'https://github.com/USGS-Astrogeology/ISIS3/archive/{{ version }}.tar.gz'
  # sha256 is the prefered checksum -- you can get it for a file with:
  # `openssl sha256 <file name>`. Simply run this command with the .tar.gz
  # file specified in the "url" tag above.
  # sha256: '62b88bec88471588feb581e28afc2aa9248bd4e165ad83c448a4c5fa7b59a6e1'

build:
  number: {{ build_number }}

# Shotgun strat on requirements until we can narrow them down
requirements:
  build:
  - cmake >=3.15
  - make
  - xalan-c
  - openssl>=1.0.0,<1.1.0

  host:
    - ale >=0.8.1
    - armadillo
    - blas
    - boost=1.68.0
    - bullet=2.86.1=0
    - bz2file
    - bzip2
    - cspice
    - eigen
    - embree
    - icu
    - jama
    - geos>=3.7,<3.8
    - geotiff
    - gmm
    - gmp
    - gsl
    - hdf5
    - libtiff
    - mesalib
    - nanoflann
    - nn
    - opencv=3.2
    - pcl
    - protobuf=3.9.1
    - qhull
    - suitesparse
    - superlu
    - tnt
    - x264=20131218
    - mysql
    - mysql-connector-c
    - nlohmann_json
    - ninja==1.7.2
    - openssl>=1.0.0,<1.1.0
    - qt=5.9.6
    - qwt=6.1.3
    - sqlite
    - xorg-kbproto
    - xorg-libice
    - xorg-libsm
    - xorg-libx11
    - xorg-libxi
    - zlib
    - curl
    - jpeg==9b
    - kakadu==1
    - krb5
    - libpng>=1.6.34
    - libprotobuf=3.9.1
    - xerces-c
    - libxml2

# Add the tests eventually
# test:
#

# about:
#   home: https://developers.google.com/protocol-buffers/
#   license: BSD 3-Clause
#   license_file: LICENSE
#   summary: "Protocol Buffers - Google's data interchange format."

# extra:
#   recipe-maintainers:

[github-actions]

Thank you for your contribution!

Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.'

If no additional action is taken, this issue will be automatically closed in 180 days.