Trimmomatic Galaxy tool: zlib issue when using container

[torfinnnome]

Trimmomatic Galaxy tool: zlib issue when using container

[pjbriggs]

Hello @torfinnnome thanks for looking into this further - I don't know enough to figure out what might be wrong with the mulling process in Galaxy, so maybe it's best for now just to try patching the tool to work around it?

If you're happy to make a pull request with the fix then I'll look at updating the tool, if there are no other issues. Thanks!

[pjbriggs]

Hello @torfinnnome

Sorry you've encountered problems running the tool. Unfortunately I haven't been able to replicate the zlib issue using a vanilla (conda) installation of the tool, so I'm not completely sure at this stage that it's an issue with the conda package.

I wonder, does Trimmomatic run okay using the Singularity container outside of the Galaxy tool?

[torfinnnome]

Galaxy first tries to make a mulled container, with Trimmomatic and coreutils, as specified in the requirements section:

Dec 09 16:20:29 test.usegalaxy.no uwsgi[18743]: Executing: /srv/galaxy/server/involucro -v=3 -f /srv/galaxy/server/lib/galaxy/tool_util/deps/mulled/invfile.lua -set CHANNELS=cond
a-forge,iuc,bioconda -set TARGETS=trimmomatic=0.38,coreutils=8.25 -set REPO=quay.io/biocontainers/mulled-v2-e1a6ade46756da3bd8ceef31e6d2
e7645f383a87:5cea15127895d50e80d4a0350938adabaf77375e-0 -set BINDS=build/dist:/usr/local/ -set DEST_BASE_IMAGE=bgruening/busybox-bash:0.1 -set SINGULARITY=1 -set SINGULARITY_IMAG
E_NAME=mulled-v2-e1a6ade46756da3bd8ceef31e6d2e7645f383a87:5cea15127895d50e80d4a0350938adabaf77375e-0 -set SINGULARITY_IMAGE_DIR=/srv/galaxy/containers/singularity/mulled -set USE
R_ID=1024:1024 -set TEST=true build-and-test
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT The following NEW packages will be INSTALLED:
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT _libgcc_mutex      conda-forge/linux-64::_libgcc_mutex-0.1-conda_forge
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT _openmp_mutex      conda-forge/linux-64::_openmp_mutex-4.5-1_gnu
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT coreutils          bioconda/linux-64::coreutils-8.25-1
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT libgcc             conda-forge/linux-64::libgcc-7.2.0-h69d50b8_2
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT libgcc-ng          conda-forge/linux-64::libgcc-ng-9.3.0-h5dbcf3e_17
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT libgomp            conda-forge/linux-64::libgomp-9.3.0-h5dbcf3e_17
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT libstdcxx-ng       conda-forge/linux-64::libstdcxx-ng-9.3.0-h2ae2ef3_17
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT openjdk            conda-forge/linux-64::openjdk-10.0.2-h14c3975_1015
Dec 09 16:21:13 test.usegalaxy.no uwsgi[18743]: [Dec  9 16:21:13] SOUT trimmomatic        bioconda/linux-64::trimmomatic-0.38-0
[...]

The resulting Singularity container is this:
/srv/galaxy/containers/singularity/mulled/mulled-v2-e1a6ade46756da3bd8ceef31e6d2e7645f383a87:5cea15127895d50e80d4a0350938adabaf77375e-0

Now, let's first see if the default Biocontainer Trimmomatic container works:

$ singularity exec docker://quay.io/biocontainers/trimmomatic:0.38--1 trimmomatic -version
INFO:    Using cached SIF image
WARNING: Skipping mount /var/singularity/mnt/session/etc/resolv.conf [files]: /etc/resolv.conf doesn't exist in container
0.38

Yup! All good.

Now, with the newly built mulled container with Trimmomatic and coreutils:

$ singularity exec /srv/galaxy/containers/singularity/mulled/mulled-v2-e1a6ade46756da3bd8ceef31e6d2e7645f383a87:5cea15127895d50e80d4a0350938adabaf77375e-0 trimmomatic -version
WARNING: Skipping mount /var/singularity/mnt/session/etc/resolv.conf [files]: /etc/resolv.conf doesn't exist in container
java: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

It fails.

Checking if the container actually includes zlib:

$ singularity exec docker://quay.io/biocontainers/trimmomatic:0.38--1 ls -l /usr/local/lib/libz.so.1
INFO:    Using cached SIF image
WARNING: Skipping mount /var/singularity/mnt/session/etc/resolv.conf [files]: /etc/resolv.conf doesn't exist in container
lrwxrwxrwx    1 root     root            14 Aug  4  2018 /usr/local/lib/libz.so.1 -> libz.so.1.2.11

$ singularity exec /srv/galaxy/containers/singularity/mulled/mulled-v2-e1a6ade46756da3bd8ceef31e6d2e7645f383a87:5cea15127895d50e80d4a0350938adabaf77375e-0 ls -l /usr/local/lib/libz.so.1
WARNING: Skipping mount /var/singularity/mnt/session/etc/resolv.conf [files]: /etc/resolv.conf doesn't exist in container
/usr/local/bin/ls: cannot access '/usr/local/lib/libz.so.1': No such file or directory

So, it seems the Galaxy-mulling process somehow does not include zlib?

[bgruening]

I'm not sure where zlib should really be added (perhaps to the trimmomatic conda package?).

This. Somewhere is a zlib dependency missing and my guess is the trimmomatic package - at least in this version.

[pjbriggs]

Hello @bgruening so would your suggestion be to update the bioconda recipe for Trimmomatic?

The relevant file is https://github.com/bioconda/bioconda-recipes/blob/master/recipes/trimmomatic/meta.yaml, however it looks like the latest version is 0.39. So either:

• a retrospective patch is needed for 0.38 in bioconda, or
• a patch for 0.39 in bioconda along with an update to the Galaxy tool for Trimmomatic to version 0.39

An update to the tool version should probably happen anyway. How does this sound?

[pjbriggs]

Added new issue #78 for the version update.