conda-forge / libtiff-feedstock

A conda-smithy repository for libtiff.

About libtiff-feedstock

Feedstock license: BSD-3-Clause

Home: http://www.libtiff.org/

Package license: HPND

Summary: Support for the Tag Image File Format (TIFF).

Documentation: http://www.libtiff.org/document.html

This software provides support for the Tag Image File Format (TIFF), a widely used format for storing image data.

Current build status

Azure

Variant Status linux_64 linux_aarch64 linux_ppc64le osx_64 osx_arm64 win_64

Current release info

Name	Downloads	Version	Platforms

Installing libtiff

Installing libtiff from the conda-forge channel can be achieved by adding conda-forge to your channels with:

conda config --add channels conda-forge
conda config --set channel_priority strict

Once the conda-forge channel has been enabled, libtiff can be installed with conda:

conda install libtiff

or with mamba:

mamba install libtiff

It is possible to list all of the versions of libtiff available on your platform with conda:

conda search libtiff --channel conda-forge

or with mamba:

mamba search libtiff --channel conda-forge

Alternatively, mamba repoquery may provide more information:

# Search all versions available on your platform:
mamba repoquery search libtiff --channel conda-forge

# List packages depending on `libtiff`:
mamba repoquery whoneeds libtiff --channel conda-forge

# List dependencies of `libtiff`:
mamba repoquery depends libtiff --channel conda-forge

About conda-forge

conda-forge is a community-led conda channel of installable packages. In order to provide high-quality builds, the process has been automated into the conda-forge GitHub organization. The conda-forge organization contains one repository for each of the installable packages. Such a repository is known as a feedstock.

A feedstock is made up of a conda recipe (the instructions on what and how to build the package) and the necessary configurations for automatic building using freely available continuous integration services. Thanks to the awesome service provided by Azure, GitHub, CircleCI, AppVeyor, Drone, and TravisCI it is possible to build and upload installable packages to the conda-forge anaconda.org channel for Linux, Windows and OSX respectively.

To manage the continuous integration and simplify feedstock maintenance conda-smithy has been developed. Using the conda-forge.yml within this repository, it is possible to re-render all of this feedstock's supporting files (e.g. the CI configuration files) with conda smithy rerender.

For more information please check the conda-forge documentation.

Terminology

feedstock - the conda recipe (raw material), supporting scripts and CI configuration.

conda-smithy - the tool which helps orchestrate the feedstock. Its primary use is in the construction of the CI .yml files and simplify the management of many feedstocks.

conda-forge - the place where the feedstock and smithy live and work to produce the finished article (built conda distributions)

Updating libtiff-feedstock

If you would like to improve the libtiff recipe or build a new package version, please fork this repository and submit a PR. Upon submission, your changes will be run on the appropriate platforms to give the reviewer an opportunity to confirm that the changes result in a successful build. Once merged, the recipe will be re-built and uploaded automatically to the conda-forge channel, whereupon the built conda packages will be available for everybody to install and use from the conda-forge channel. Note that all branches in the conda-forge/libtiff-feedstock are immediately built and any created packages are uploaded, so PRs should be based on branches in forks and branches in the main repository should only be used to build distinct package versions.

In order to produce a uniquely identifiable distribution:

• If the version of a package is not being increased, please add or increase the build/number.
• If the version of a package is being increased, please remember to return the build/number back to 0.

Feedstock Maintainers

• @hmaarrfk
• @jakirkham
• @mingwandroid
• @msarahan
• @ocefpaf
• @stuarteberg

libtiff-feedstock's Issues

Rebuild for fixed zstd on Windows

zstd 1.4.3 was erroneously built and released in debug mode for Windows. This was fixed with zstd 1.4.4 build 1, released earlier today.

It seems that libtiff for Windows has zstd pinned to 1.4.3. (I noticed that meta.yaml doesn't pin it explicitly, but I see that index.json in this tar has zstd >=1.4.3,<1.4.4.0a0; I'm not sure but am guessing that it's pinned automatically at build time.) Consequently, I'm encountering errors in Windows with the latest libtiff (my quest to track this down started with import matplotlib.pyplot as plt failing with a DLL import error).

libwebp run dependency is not installed

$ conda install -c conda-forge libtiff=4.1

## Package Plan ##

  added / updated specs:
    - libtiff=4.1

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    libtiff-4.1.0              |       h2733197_0         447 KB
    ------------------------------------------------------------
                                           Total:         447 KB

The following packages will be UPDATED:

  libtiff                                 4.0.10-h2733197_2 --> 4.1.0-h2733197_0

with

$ conda info

     active environment : foobar
            shell level : 2
 populated config files :
          conda version : 4.8.1
    conda-build version : not installed
         python version : 3.7.3.final.0
       virtual packages : __glibc=2.24
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/debionne/miniconda3/pkgs
                          /home/debionne/.conda/pkgs
               platform : linux-64
             user-agent : conda/4.8.1 requests/2.22.0 CPython/3.7.3 Linux/4.4.0-18362-Microsoft debian/9 glibc/2.24                     UID:GID : 1000:1000
             netrc file : None
           offline mode : False

The issue shows up when linking to libtiff with version 4.10:

$ld: warning: libwebp.so.7, needed by $PREFIX/lib/libtiff.so, not found (try using -rpath or -rpath-link)
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPPictureImportRGB'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPInitDecBufferInternal'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPPictureFree'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPIAppend'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPIDecGetRGB'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPINewDecoder'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPPictureImportRGBA'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPConfigInitInternal'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPEncode'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPValidateConfig'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPPictureInitInternal'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPFreeDecBuffer'
$ld: $PREFIX/lib/libtiff.so: undefined reference to `WebPIDelete'
collect2: error: ld returned 1 exit status

Unexpected SONAME for v4.5.0

Comment:

It's not clear to me how versioning works with libtiff but, since the release of 4.5.0, our packages (linked with 4.4.0, aka libtiff.so.5) are broken since 4.5.0 installs libtiff.so.6.

For a minor version increment, SONAME major version was incremented in:
https://gitlab.com/libtiff/libtiff/-/commit/dc73ae317e8ea3407bc15f8adfc8d9faa909b6f3

Actually it looks like the SONAME does not follow the version.

I guess we could pin libtiff but IMHO, SONAME and version should match and versions should follow SemVer in Conda. Shall the build system be patched?

Missed dependency on libwebp

Issue:

The issue came out installing any version of pillow which would result with the message

ImportError: libwebp.so.7: cannot open shared object file: No such file or directory

Environment (conda list):

$ conda list
# packages in environment at /home/edo/miniconda3/envs/c2:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                 conda_forge    conda-forge
ca-certificates           2019.11.28           hecc5488_0    conda-forge
certifi                   2019.11.28               py36_0    conda-forge
freetype                  2.10.0               he983fc9_1    conda-forge
giflib                    5.2.1                h516909a_1    conda-forge
jpeg                      9c                h14c3975_1001    conda-forge
libffi                    3.2.1             he1b5a44_1006    conda-forge
libgcc-ng                 9.2.0                h24d8f2e_1    conda-forge
libgomp                   9.2.0                h24d8f2e_1    conda-forge
libpng                    1.6.37               hed695b0_0    conda-forge
libstdcxx-ng              9.2.0                hdf63c60_1    conda-forge
libtiff                   4.1.0                hc3755c2_4    conda-forge
libwebp                   1.1.0                h56121f0_1    conda-forge
libwebp-base              1.1.0                         1    conda-forge
lz4-c                     1.8.3             he1b5a44_1001    conda-forge
ncurses                   6.1               hf484d3e_1002    conda-forge
olefile                   0.46                       py_0    conda-forge
openmp_impl               4.5                       0_gnu    conda-forge
openssl                   1.1.1d               h516909a_0    conda-forge
pillow                    5.4.1           py36h00a061d_1000    conda-forge
pip                       19.3.1                   py36_0    conda-forge
python                    3.6.7             h357f687_1006    conda-forge
readline                  8.0                  hf8c457e_0    conda-forge
setuptools                44.0.0                   py36_0    conda-forge
sqlite                    3.30.1               hcee41ef_0    conda-forge
tk                        8.6.10               hed695b0_0    conda-forge
wheel                     0.33.6                   py36_0    conda-forge
xz                        5.2.4             h14c3975_1001    conda-forge
zlib                      1.2.11            h516909a_1006    conda-forge
zstd                      1.4.4                h3b9ef0a_1    conda-forge

Details about conda and system ( conda info ):

$ conda info

active environment : c2
    active env location : /home/edo/miniconda3/envs/c2
            shell level : 2
       user config file : /home/edo/.condarc
 populated config files : /home/edo/.condarc
          conda version : 4.7.12
    conda-build version : 3.18.9
         python version : 3.7.3.final.0
       virtual packages : __cuda=10.1
       base environment : /home/edo/miniconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/free/linux-64
                          https://repo.anaconda.com/pkgs/free/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/edo/miniconda3/pkgs
                          /home/edo/.conda/pkgs
       envs directories : /home/edo/miniconda3/envs
                          /home/edo/.conda/envs
               platform : linux-64
             user-agent : conda/4.7.12 requests/2.22.0 CPython/3.7.3 Linux/3.10.0-957.27.2.el7.x86_64 centos/7.6.1810 glibc/2.17
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

I tracked down the issue to libtiff which is now dependent on libwebp, however libwebp.so.7 is not installed by libwebp rather by libwebp-base.

I'm not sure I understand correctly conda's documentation about host requirements, which seem to say that the current libtiff recipe is correct.

However, on my machines libwebp-base never gets installed and installing it seems to fix my problems.

Issue seems the same as #52

Imported target "TIFF::TIFF" includes non-existent path C:/bld/qt6-main_1696944674905/_h_env/Library/lib/cmake/tiff/include

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

when building qt6 on windows with 4.6.0 I get this error:

CMake Error in qtimageformats/src/plugins/imageformats/tiff/CMakeLists.txt:
2023-10-10T13:54:39.7768892Z   Imported target "TIFF::TIFF" includes non-existent path
2023-10-10T13:54:39.7905566Z 
2023-10-10T13:54:39.9591525Z     "C:/bld/qt6-main_1696944674905/_h_env/Library/lib/cmake/tiff/include"

I looked at the Library/lib/cmake/tiff/TiffTargets.cmake but it looks correct:

# Compute the installation prefix relative to this file.
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
  set(_IMPORT_PREFIX "")
endif()

# Create imported target TIFF::tiff
add_library(TIFF::tiff SHARED IMPORTED)

set_target_properties(TIFF::tiff PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
)

any idea ?

Installed packages

libtiff 4.6

Environment info

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=800840&view=logs&jobId=a70f640f-cc53-5cd3-6cdc-236a1aa90802&j=a70f640f-cc53-5cd3-6cdc-236a1aa90802&t=6119ccbe-9301-594f-7c27-f792b80a7fcc

More win32/unix I/O woes: libtiff crashing in poppler's pdftocairo on Windows

As reported in conda-forge/poppler-feedstock#73 , it seems that there are TIFF-related crashes in the poppler program pdftocairo on Windows. It can be recreated thus:

1. My test file is: https://arxiv.org/pdf/2005.01489
2. Run: pdftocairo -tiff 2005.01489.pdf
3. The program silently exits with an error code.
4. Resulting file 2005.01489-1.tif is empty.

The exit code is reported as -1073740791 = 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN, which means that a stack buffer overflow is occuring.

Running the program in a Windows debugger, I get this stack trace:

libtiff.la: why does it define inherited_linker_flags=' -pthread'?

For some weird reasons the libtiff.la on my mac contains:

# Linker flags that cannot go in dependency_libs.
inherited_linker_flags='  -pthread'

I am not sure how it got there and doubt that it should be there.

I tested with

libtiff - 4.0.6 - 4 - conda-forge

Broader context:
I am trying to prepare a libgd package. When linking libtiff, libtool reads this variable and adds it to the linker flags. Clang however does not like -pthread during linking, which gives a warning. Which in turn ends up in an error due to a -Werror flag.

4.3.0 released

https://lists.osgeo.org/pipermail/gdal-announce/2021-April/000088.html

Shared library filename changed from `libtiff.dll` to `tiff.dll`

I've been debugging some issues with gdal coming from conda-forge as of about two days ago. I tracked it down to a libtiff change. See conda-forge/gdal-feedstock#241 for more debugging details on this. Bottom line is that the _gdal*.pyd file is trying to link against libtiff.dll, but for the last couple builds of libtiff this file is called tiff.dll. If I copy tiff.dll to libtiff.dll on both my Windows 7 VM and on my appveyor environment I am able to import gdal successfully by doing:

python -c "from osgeo import gdal, osr"

I downloaded the last couple windows tarballs from anaconda.org and get:

$ ls -1 Library-4.0.9-*/bin/*tiff.dll
Library-4.0.9-h6ce49d1_0/bin/libtiff.dll
Library-4.0.9-he490001_1002/bin/tiff.dll
Library-4.0.9-he490001_2/bin/tiff.dll
Library-4.0.9-vc9_0/bin/libtiff.dll

My guess is that the vc9/vc14 builds of gdal have been depending on the vc9/vc14 builds of libtiff for a long time (libtiff.dll), but with recent rebuilds of gdal they are now using the newest compilers and build environments and are now using the newer builds of libtiff (tiff.dll) which is why no one has noticed this until now. Again this is just a guess and is coming from someone who doesn't build things on Windows usually.

Cannot import Image from PIL (libtiff 4.5.0-hc4f729c_0 and pillow 9.2.0-py310hdbb7713_4)

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Updating libtiff to 4.5.0-hc4f729c_0 and pillow to 9.2.0-py310hdbb7713_4 produces the error "DLL load failed while importing _imaging: The specified module could not be found" when trying to import Image from PIL.

Reverting both libtiff and pillow (to 4.4.0-h8e97e67_4 and 9.2.0-py310hd4fb230_3, respectively) solves the issue.

Installed packages

# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: win-64
alabaster=0.7.12=py_0
anyio=3.6.2=pyhd8ed1ab_0
argon2-cffi=21.3.0=pyhd8ed1ab_0
argon2-cffi-bindings=21.2.0=py310h8d17308_3
arrow=1.2.3=pyhd8ed1ab_0
astroid=2.12.13=py310h5588dad_0
atomicwrites=1.4.1=pyhd8ed1ab_0
attrs=22.1.0=pyh71513ae_1
autopep8=1.6.0=pyhd8ed1ab_1
babel=2.11.0=pyhd8ed1ab_0
backcall=0.2.0=pyh9f0ad1d_0
backports=1.0=pyhd8ed1ab_3
backports.functools_lru_cache=1.6.4=pyhd8ed1ab_0
bcrypt=3.2.2=py310h8d17308_1
beautifulsoup4=4.11.1=pyha770c72_0
binaryornot=0.4.4=py_1
black=22.10.0=py310h5588dad_2
bleach=5.0.1=pyhd8ed1ab_0
bokeh=3.0.3=pyhd8ed1ab_0
branca=0.6.0=pyhd8ed1ab_0
brotli=1.0.9=hcfcfb64_8
brotli-bin=1.0.9=hcfcfb64_8
brotlipy=0.7.0=py310h8d17308_1005
bzip2=1.0.8=h8ffe710_4
ca-certificates=2022.12.7=h5b45459_0
certifi=2022.12.7=pyhd8ed1ab_0
cffi=1.15.1=py310h628cb3f_3
chardet=5.1.0=py310h5588dad_0
charset-normalizer=2.1.1=pyhd8ed1ab_0
click=8.1.3=win_pyhd8ed1ab_2
cloudpickle=2.2.0=pyhd8ed1ab_0
colorama=0.4.6=pyhd8ed1ab_0
comm=0.1.2=pyhd8ed1ab_0
contourpy=1.0.6=py310h232114e_0
cookiecutter=2.1.1=pyh6c4a22f_0
cryptography=38.0.4=py310h52f42fa_0
cycler=0.11.0=pyhd8ed1ab_0
cython=0.29.32=py310h00ffb61_1
daal4py=2021.7.1=py310h220cb41_0
dal=2021.7.1=h6a75c08_19751
debugpy=1.6.4=py310h00ffb61_0
decorator=5.1.1=pyhd8ed1ab_0
defusedxml=0.7.1=pyhd8ed1ab_0
diff-match-patch=20200713=pyh9f0ad1d_0
dill=0.3.6=pyhd8ed1ab_1
dnspython=2.2.1=pyhd8ed1ab_0
docstring-to-markdown=0.11=pyhd8ed1ab_0
docutils=0.19=py310h5588dad_1
entrypoints=0.4=pyhd8ed1ab_0
et_xmlfile=1.0.1=py_1001
flake8=5.0.4=pyhd8ed1ab_0
flask=2.2.2=pyhd8ed1ab_0
flit-core=3.8.0=pyhd8ed1ab_0
folium=0.14.0=pyhd8ed1ab_0
fonttools=4.38.0=py310h8d17308_1
freetype=2.12.1=h546665d_1
gettext=0.21.1=h5728263_0
giflib=5.2.1=h8d14728_2
glib=2.74.1=h12be248_1
glib-tools=2.74.1=h12be248_1
gmpy2=2.1.2=py310hf735c17_1
gst-plugins-base=1.21.2=h001b923_0
gstreamer=1.21.2=h6b5321d_0
icu=70.1=h0e60522_0
idna=3.4=pyhd8ed1ab_0
imagesize=1.4.1=pyhd8ed1ab_0
importlib-metadata=5.2.0=pyha770c72_0
importlib_metadata=5.2.0=hd8ed1ab_0
importlib_resources=5.10.1=pyhd8ed1ab_0
inflection=0.5.1=pyh9f0ad1d_0
intel-openmp=2023.0.0=h57928b3_25922
intervaltree=3.0.2=py_0
ipykernel=6.19.3=pyh025b116_0
ipython=7.33.0=py310h5588dad_0
ipython_genutils=0.2.0=py_1
ipywidgets=7.7.2=pyhd8ed1ab_0
isort=5.11.3=pyhd8ed1ab_0
itsdangerous=2.1.2=pyhd8ed1ab_0
jaraco.classes=3.2.3=pyhd8ed1ab_0
jedi=0.18.2=pyhd8ed1ab_0
jellyfish=0.9.0=py310h8d17308_2
jinja2=3.1.2=pyhd8ed1ab_1
jinja2-time=0.2.0=pyhd8ed1ab_3
joblib=1.2.0=pyhd8ed1ab_0
jpeg=9e=h8ffe710_2
jsonschema=4.17.3=pyhd8ed1ab_0
jupyter=1.0.0=py310h5588dad_8
jupyter_client=7.4.8=pyhd8ed1ab_0
jupyter_console=6.4.4=pyhd8ed1ab_0
jupyter_core=5.1.0=py310h5588dad_0
jupyter_events=0.5.0=pyhd8ed1ab_0
jupyter_server=2.0.1=pyhd8ed1ab_0
jupyter_server_terminals=0.4.3=pyhd8ed1ab_0
jupyterlab_pygments=0.2.2=pyhd8ed1ab_0
jupyterlab_widgets=1.1.1=pyhd8ed1ab_0
keyring=23.11.0=py310h5588dad_0
kiwisolver=1.4.4=py310h232114e_1
krb5=1.20.1=h6609f42_0
lazy-object-proxy=1.8.0=py310h8d17308_0
lcms2=2.14=h90d422f_0
lerc=4.0.0=h63175ca_0
libblas=3.9.0=16_win64_mkl
libbrotlicommon=1.0.9=hcfcfb64_8
libbrotlidec=1.0.9=hcfcfb64_8
libbrotlienc=1.0.9=hcfcfb64_8
libcblas=3.9.0=16_win64_mkl
libclang=15.0.6=default_h77d9078_0
libclang13=15.0.6=default_h77d9078_0
libcurl=7.86.0=h68f0423_2
libdeflate=1.14=hcfcfb64_0
libffi=3.4.2=h8ffe710_5
libglib=2.74.1=he8f3873_1
libhwloc=2.9.0=h51c2c0f_0
libiconv=1.17=h8ffe710_0
liblapack=3.9.0=16_win64_mkl
libogg=1.3.4=h8ffe710_1
libpng=1.6.39=h19919ed_0
libsodium=1.0.18=h8d14728_1
libspatialindex=1.9.3=h39d44d4_4
libsqlite=3.40.0=hcfcfb64_0
libssh2=1.10.0=h680486a_3
libtiff=4.4.0=h8e97e67_4
libvorbis=1.3.7=h0e60522_0
libwebp=1.2.4=hcfcfb64_1
libwebp-base=1.2.4=h8ffe710_0
libxcb=1.13=hcd874cb_1004
libxml2=2.10.3=hc3477c8_0
libxslt=1.1.37=h0192164_0
libzlib=1.2.13=hcfcfb64_4
lingua-language-detector=1.1.3=pyhd8ed1ab_0
llvmlite=0.39.1=py310hb84602e_1
lxml=4.9.2=py310hc0e5b84_0
m2w64-gcc-libgfortran=5.3.0=6
m2w64-gcc-libs=5.3.0=7
m2w64-gcc-libs-core=5.3.0=7
m2w64-gmp=6.1.0=2
m2w64-libwinpthread-git=5.0.0.4634.697f757=2
markupsafe=2.1.1=py310h8d17308_2
matplotlib=3.6.2=py310h5588dad_0
matplotlib-base=3.6.2=py310h51140c5_0
matplotlib-inline=0.1.6=pyhd8ed1ab_0
mccabe=0.7.0=pyhd8ed1ab_0
mealpy=2.5.0=pypi_0
mistune=2.0.4=pyhd8ed1ab_0
mkl=2022.1.0=h6a75c08_874
montydb=2.4.0=pyhd8ed1ab_0
more-itertools=9.0.0=pyhd8ed1ab_0
mpc=1.2.1=h54e1faf_0
mpfr=4.1.0=h8d14728_1
mpir=3.0.0=he025d50_1002
mpmath=1.2.1=pyhd8ed1ab_0
msys2-conda-epoch=20160418=1
munkres=1.1.4=pyh9f0ad1d_0
mypy_extensions=0.4.3=py310h5588dad_6
nbclassic=0.4.8=pyhd8ed1ab_0
nbclient=0.7.2=pyhd8ed1ab_0
nbconvert=7.2.6=pyhd8ed1ab_0
nbconvert-core=7.2.6=pyhd8ed1ab_0
nbconvert-pandoc=7.2.6=pyhd8ed1ab_0
nbformat=5.7.1=pyhd8ed1ab_0
nest-asyncio=1.5.6=pyhd8ed1ab_0
nose=1.3.7=py_1006
notebook=6.5.2=pyha770c72_1
notebook-shim=0.2.2=pyhd8ed1ab_0
numba=0.56.4=py310h19bcfe9_0
numpy=1.23.5=py310h4a8f9c9_0
numpydoc=1.5.0=pyhd8ed1ab_0
openjpeg=2.5.0=hc9384bd_1
openpyxl=3.0.10=py310h8d17308_2
openssl=1.1.1s=hcfcfb64_1
opfunu=1.0.0=pypi_0
opt_einsum=3.3.0=pyhd8ed1ab_1
packaging=22.0=pyhd8ed1ab_0
pandas=1.5.2=py310h1c4a608_0
pandoc=2.19.2=h57928b3_1
pandocfilters=1.5.0=pyhd8ed1ab_0
paramiko=2.12.0=pyhd8ed1ab_0
parso=0.8.3=pyhd8ed1ab_0
pathspec=0.10.3=pyhd8ed1ab_0
patsy=0.5.3=pyhd8ed1ab_0
pcre2=10.40=h17e33f8_0
pexpect=4.8.0=pyh1a96a4e_2
pickleshare=0.7.5=py_1003
pillow=9.2.0=py310hd4fb230_3
pip=22.3.1=pyhd8ed1ab_0
pkgutil-resolve-name=1.3.10=pyhd8ed1ab_0
platformdirs=2.6.0=pyhd8ed1ab_0
plotly=5.11.0=pyhd8ed1ab_1
pluggy=1.0.0=pyhd8ed1ab_5
ply=3.11=py_1
prometheus_client=0.15.0=pyhd8ed1ab_0
prompt-toolkit=3.0.36=pyha770c72_0
prompt_toolkit=3.0.36=hd8ed1ab_0
psutil=5.9.4=py310h8d17308_0
pthread-stubs=0.4=hcd874cb_1001
pthreads-win32=2.9.1=hfa6e2cd_3
ptyprocess=0.7.0=pyhd3deb0d_0
pycodestyle=2.9.1=pyhd8ed1ab_0
pycparser=2.21=pyhd8ed1ab_0
pydocstyle=6.1.1=pyhd8ed1ab_0
pyflakes=2.5.0=pyhd8ed1ab_0
pygments=2.13.0=pyhd8ed1ab_0
pylint=2.15.9=pyhd8ed1ab_0
pylint-venv=2.3.0=pyhd8ed1ab_0
pyls-spyder=0.4.0=pyhd8ed1ab_0
pymongo=4.3.3=py310h00ffb61_0
pympler=1.0.1=pyhd8ed1ab_0
pynacl=1.5.0=py310h635b8f1_2
pyopenssl=22.1.0=pyhd8ed1ab_0
pyparsing=3.0.9=pyhd8ed1ab_0
pyqt=5.15.7=py310h1fd54f2_2
pyqt5-sip=12.11.0=py310h00ffb61_2
pyqtwebengine=5.15.7=py310h1fd54f2_2
pyrsistent=0.19.2=py310h8d17308_0
pysocks=1.7.1=pyh0701188_6
python=3.10.8=h0269646_0_cpython
python-dateutil=2.8.2=pyhd8ed1ab_0
python-fastjsonschema=2.16.2=pyhd8ed1ab_0
python-flatbuffers=22.12.6=pyhd8ed1ab_0
python-json-logger=2.0.1=pyh9f0ad1d_0
python-lsp-black=1.2.1=pyhd8ed1ab_0
python-lsp-jsonrpc=1.0.0=pyhd8ed1ab_0
python-lsp-server=1.6.0=hd8ed1ab_0
python-lsp-server-base=1.6.0=pyhd8ed1ab_0
python-slugify=7.0.0=pyhd8ed1ab_0
python_abi=3.10=3_cp310
pytoolconfig=1.2.4=pyhd8ed1ab_1
pytz=2022.7=pyhd8ed1ab_0
pywin32=304=py310h00ffb61_2
pywin32-ctypes=0.2.0=py310h5588dad_1006
pywinpty=2.0.9=py310h00ffb61_0
pyyaml=6.0=py310h8d17308_5
pyzmq=24.0.1=py310hcd737a0_1
qdarkstyle=3.0.3=pyhd8ed1ab_0
qstylizer=0.2.2=pyhd8ed1ab_0
qt-main=5.15.6=h068e40c_5
qt-webengine=5.15.4=hd018be4_3
qtawesome=1.2.1=pyhd8ed1ab_0
qtconsole=5.4.0=pyhd8ed1ab_0
qtconsole-base=5.4.0=pyha770c72_0
qtpy=2.3.0=pyhd8ed1ab_0
qtwebkit=5.212=h0db62b3_6
regex=2022.10.31=py310h8d17308_0
requests=2.28.1=pyhd8ed1ab_1
rope=1.6.0=pyhd8ed1ab_0
rtree=1.0.1=py310h1cbd46b_1
scikit-learn=1.2.0=py310had3394f_0
scikit-learn-intelex=2021.7.1=py310h5588dad_1
scipy=1.9.3=py310h578b7cb_2
seaborn=0.12.1=hd8ed1ab_0
seaborn-base=0.12.1=pyhd8ed1ab_0
send2trash=1.8.0=pyhd8ed1ab_0
setuptools=65.6.3=pyhd8ed1ab_0
sip=6.7.5=py310h00ffb61_0
six=1.16.0=pyh6c4a22f_0
sniffio=1.3.0=pyhd8ed1ab_0
snowballstemmer=2.2.0=pyhd8ed1ab_0
sortedcontainers=2.4.0=pyhd8ed1ab_0
soupsieve=2.3.2.post1=pyhd8ed1ab_0
sphinx=5.3.0=pyhd8ed1ab_0
sphinxcontrib-applehelp=1.0.2=py_0
sphinxcontrib-devhelp=1.0.2=py_0
sphinxcontrib-htmlhelp=2.0.0=pyhd8ed1ab_0
sphinxcontrib-jsmath=1.0.1=py_0
sphinxcontrib-qthelp=1.0.3=py_0
sphinxcontrib-serializinghtml=1.1.5=pyhd8ed1ab_2
spyder=5.4.0=py310h5588dad_0
spyder-kernels=2.4.0=win_pyhd8ed1ab_1
spyder-notebook=0.4.0=pyh1a96a4e_0
sqlite=3.40.0=hcfcfb64_0
statsmodels=0.13.5=py310h9b08ddd_2
sympy=1.11.1=py310h5588dad_2
tbb=2021.7.0=h91493d7_0
tenacity=8.1.0=pyhd8ed1ab_0
termcolor=2.1.1=pyhd8ed1ab_0
terminado=0.17.0=pyh08f2357_0
text-unidecode=1.3=py_0
textdistance=4.5.0=pyhd8ed1ab_0
threadpoolctl=3.1.0=pyh8a188c0_0
three-merge=0.1.1=pyh9f0ad1d_0
tinycss2=1.2.1=pyhd8ed1ab_0
tk=8.6.12=h8ffe710_0
toml=0.10.2=pyhd8ed1ab_0
tomli=2.0.1=pyhd8ed1ab_0
tomlkit=0.11.6=pyha770c72_0
tornado=6.2=py310h8d17308_1
tqdm=4.64.1=pyhd8ed1ab_0
traitlets=5.8.0=pyhd8ed1ab_0
typing=3.10.0.0=pyhd8ed1ab_0
typing-extensions=4.4.0=hd8ed1ab_0
typing_extensions=4.4.0=pyha770c72_0
tzdata=2022g=h191b570_0
ucrt=10.0.22621.0=h57928b3_0
ujson=5.5.0=py310h00ffb61_1
unicodedata2=15.0.0=py310h8d17308_0
unidecode=1.3.6=pyhd8ed1ab_0
urllib3=1.26.13=pyhd8ed1ab_0
vc=14.3=h3d8a991_9
vs2015_runtime=14.32.31332=h1d6e394_9
watchdog=2.2.0=py310h5588dad_0
wcwidth=0.2.5=pyh9f0ad1d_2
webencodings=0.5.1=py_1
websocket-client=1.4.2=pyhd8ed1ab_0
werkzeug=2.2.2=pyhd8ed1ab_0
whatthepatch=1.0.3=pyhd8ed1ab_0
wheel=0.38.4=pyhd8ed1ab_0
widgetsnbextension=3.6.1=pyha770c72_0
win_inet_pton=1.1.0=pyhd8ed1ab_6
winpty=0.4.3=4
wrapt=1.14.1=py310h8d17308_1
xlrd=2.0.1=pyhd8ed1ab_3
xorg-libxau=1.0.9=hcd874cb_0
xorg-libxdmcp=1.1.3=hcd874cb_0
xyzservices=2022.9.0=pyhd8ed1ab_0
xz=5.2.9=h64bf75a_0
yaml=0.2.5=h8ffe710_2
yapf=0.32.0=pyhd8ed1ab_0
zeromq=4.3.4=h0e60522_1
zipp=3.11.0=pyhd8ed1ab_0
zlib=1.2.13=hcfcfb64_4
zstd=1.5.2=h7755175_4

Environment info

conda version : 22.11.1
    conda-build version : not installed
         python version : 3.9.15.final.0
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
               platform : win-64
             user-agent : conda/22.11.1 requests/2.28.1 CPython/3.9.15 Windows/10 Windows/10.0.19045

undefined reference to lzma

I got this undefined references to lzma errors when compiling a library which needs libtiff. Same problem can be found here: https://bugs.ghostscript.com/show_bug.cgi?id=693116
Would it be possible to build without lzma?

@conda-forge-admin, please update circle

@conda-forge-admin, please update circle

libtiff 4.4 pkg-config file broken on Windows / Switch to libjpeg-turbo?

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

As seen in conda-forge/librsvg-feedstock#96, version 4.4 of libtiff adds a new Requires.private: line to its pkg-config file that breaks downstream libraries on Windows: the new libtiff version requires libjpeg.pc as a dependency, but conda-forge's Windows build of jpeg doesn't provide a pkg-config file. The non-Windows builds do, so it's not a problem elsewhere.

A potential solution would be to switch this library from depending on jpeg on Windows to libjpeg-turbo, which does provide a libjpeg.pc on all platforms. I think that this is pretty much a drop-in change, but I don't feel like I fully understand the ABI/etc implications of switching. Thoughts?

(Alternatively, we could update the jpeg CMake file to build and install the .pc file. The CMake file is custom to conda-forge.

CC @conda-forge/jpeg and @conda-forge/libjpeg-turbo for visibility.

Installed packages

N/A

Environment info

N/A

Enable zlib and jpeg compression on Windows build

See nmake.opt. Seems this is the reason for the confusing AdobeCreate error message.

Libtiff is built against jpeg 6.2 but conda forge pins jpeg on version 9

ldd /home/amir/miniconda/envs/_test/lib/python3.5/site-packages/bob/io/image/../../../../../libtiff.so.5
    linux-vdso.so.1 (0x00007ffd725d6000)
    libjpeg.so.62 => not found
    libz.so.1 => /home/amir/miniconda/envs/_test/lib/python3.5/site-packages/bob/io/image/../../../../.././libz.so.1 (0x00007f4eaa947000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f4eaa641000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f4eaa2a0000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x000056378a913000)

This caused a problem on a pull here: conda-forge/bob.io.image-feedstock#2

[4.3.0->4.4.0 ABI breakage?] undefined symbol: _TIFFDataSize

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Two CI jobs:

• Working
• Failed

Symptom:

Traceback (most recent call last):
  File "/var/lib/gitlab-runner/builds/VFPjm48d/3/inducer/pytential/.miniforge3/envs/testing/lib/python3.10/site-packages/pytools/prefork.py", line 51, in call_capture_output
    raise ExecError("status {} invoking '{}': {}".format(
pytools.prefork.ExecError: status 127 invoking 'gmsh -version': gmsh: symbol lookup error: /var/lib/gitlab-runner/builds/VFPjm48d/3/inducer/pytential/.miniforge3/envs/testing/bin/../lib/./././libfreeimage.so.3: undefined symbol: _TIFFDataSize

Between those two, libtiff went from 4.3.0 to 4.4.0.

Or maybe this is https://github.com/conda-forge/freeimage-feedstock/issues depending on a symbol on which it shouldn't? Not sure.

Installed packages

(see above CI logs)

Environment info

(see above CI logs)

Stricter pinning on libtiff

Comment:

I would like to pin libtiff a littler harder than it currently is.

While the ABI is compatible between builds, it seems that the returned values from the libraries often change by a very small amount to make it so that downstream projects need to patch before they become compatible with libtiff.

This is, for example, what is happening with pillow at the moment with:

• #76
• conda-forge/pillow-feedstock#119

Recipe is reporting the wrong license

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

The recipe is calling out jbig as a dependency. This builds libtiff for the native platform and will link to the jbig library - libtiff does not use dlopen to access the jbig library. However, JBIG is a GPL2 licensed library with no exceptions:

Public licence(sk): You can use JBIG-KIT free of charge under the conditions of the [GNU General Public Licence](http://www.fsf.org/licenses/licenses.html#GPL). [Linking](http://www.fsf.org/licenses/gpl-faq.html#LinkingWithGPL) JBIG-KIT statically or dynamically with other modules is making a combined work based on JBIG-KIT. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

Source: https://www.cl.cam.ac.uk/~mgk25/jbigkit/

Since the recipe is providing jbig in the host & run requirements per the above the GPL license supersedes the libtiff license.

In my research I could not locate a GPL exception for libtiff so it looks like the options are:

• Remove jbig
• Update the license in this recipe
• Update the recipe to provide multiple packages with and without jbig (and correspondingly with and without gpl)

Installed packages

libtiff

Environment info

Any

libtiff built against generally incompatible version of xz

So the libtiff package is built against xz 5.2.2.....which isn't compatible with 5.0.5. Trying to install 5.2.2 force my python to change from 3.5 to 3.4. Oh, and of course libtiff doesn't know it's not compatible with 5.0.5, so it happily tries to install alongside it.

Most recent build causing PIL error

Just started getting these errors in Satpy's CI after the most recent PR (#51 and #55 maybe?). I saw @hmaarrfk and @ocefpaf worked on those. Any ideas?

satpy/__init__.py:53: in <module>
    from satpy.writers import available_writers  # noqa
satpy/writers/__init__.py:45: in <module>
    from trollimage.xrimage import XRImage
../../../miniconda/envs/test/lib/python3.8/site-packages/trollimage/xrimage.py:40: in <module>
    from PIL import Image as PILImage
../../../miniconda/envs/test/lib/python3.8/site-packages/PIL/Image.py:69: in <module>
    from . import _imaging as core
   ImportError: dlopen(/Users/travis/miniconda/envs/test/lib/python3.8/site-packages/PIL/_imaging.cpython-38-darwin.so, 2): Library not loaded: @rpath/libwebp.7.dylib
     Referenced from: /Users/travis/miniconda/envs/test/lib/libtiff.5.dylib
     Reason: Incompatible library version: libtiff.5.dylib requires version 9.0.0 or later, but libwebp.7.dylib provides version 8.0.0

https://travis-ci.org/github/pytroll/satpy/jobs/663516059#L3943-L3953

Missing run-dependencies (resp. missing run-exports of the respective host deps)

Seen in conda-forge/staged-recipes#19665 (because that recipe ended up copying the DLL to site-packages, and so it showed up in the log):

WARNING (pygame,Lib/site-packages/pygame/libtiff.dll): Needed DSO Library/bin/libdeflate.dll found in ['libdeflate']
WARNING (pygame,Lib/site-packages/pygame/libtiff.dll): .. but ['libdeflate'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
WARNING (pygame,Lib/site-packages/pygame/libtiff.dll): Needed DSO Library/bin/Lerc.dll found in ['lerc']
WARNING (pygame,Lib/site-packages/pygame/libtiff.dll): .. but ['lerc'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
WARNING (pygame,Lib/site-packages/pygame/libtiff.dll): Needed DSO Library/bin/zstd.dll found in ['zstd']
WARNING (pygame,Lib/site-packages/pygame/libtiff.dll): .. but ['zstd'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

No module named 'libtiff'

Issue:

Commands that was done:

conda config --add channels conda-forge
conda install libtiff
python -c 'import libtiff; print(libtiff.version)'
'''
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'libtiff'
'''
which python
'''
/home/cmo1060/anaconda3/envs/tf__1_15/bin/python
'''

Environment (conda list):

$ conda list

packages in environment at /home/cmo1060/anaconda3/envs/tf__1_15:

Name Version Build Channel

_tflow_select 2.1.0 gpu anaconda
absl-py 0.10.0 py37_0 anaconda
astor 0.8.1 py37_0 anaconda
blas 1.0 mkl anaconda
c-ares 1.16.1 h7b6447c_0 anaconda
ca-certificates 2020.6.20 hecda079_0 conda-forge
certifi 2020.6.20 py37hc8dfbb8_0 conda-forge
cudatoolkit 10.0.130 0 anaconda
cudnn 7.6.5 cuda10.0_0 anaconda
cupti 10.0.130 0 anaconda
gast 0.2.2 py37_0 anaconda
google-pasta 0.2.0 py_0 anaconda
grpcio 1.31.0 py37hf8bcb03_0 anaconda
h5py 2.10.0 py37hd6299e0_1 anaconda
hdf5 1.10.6 hb1b8bf9_0 anaconda
importlib-metadata 1.7.0 py37_0 anaconda
intel-openmp 2020.2 254 anaconda
jpeg 9b habf39ab_1 anaconda
keras 2.3.1 0
keras-applications 1.0.8 py_1 anaconda
keras-base 2.3.1 py37_0 anaconda
keras-preprocessing 1.1.0 py_1 anaconda
ld_impl_linux-64 2.33.1 h53a641e_7 anaconda
libedit 3.1.20191231 h14c3975_1 anaconda
libffi 3.3 he6710b0_2 anaconda
libgcc-ng 9.1.0 hdf63c60_0 anaconda
libgfortran-ng 7.3.0 hdf63c60_0 anaconda
libprotobuf 3.13.0 hd408876_0 anaconda
libstdcxx-ng 9.1.0 hdf63c60_0 anaconda
libtiff 4.0.9 he6b73bb_1 conda-forge
lz4-c 1.9.2 he6710b0_1 anaconda
markdown 3.2.2 py37_0 anaconda
mkl 2019.4 243 anaconda
mkl-service 2.3.0 py37he904b0f_0 anaconda
mkl_fft 1.2.0 py37h23d657b_0 anaconda
mkl_random 1.1.0 py37hd6b4f25_0 anaconda
ncurses 6.2 he6710b0_1 anaconda
numpy 1.19.1 py37hbc911f0_0 anaconda
numpy-base 1.19.1 py37hfa32c7d_0 anaconda
openssl 1.1.1g h516909a_1 conda-forge
opt_einsum 3.1.0 py_0 anaconda
pip 20.2.2 py37_0 anaconda
protobuf 3.13.0 py37hf484d3e_0 anaconda
python 3.7.9 h7579374_0
python_abi 3.7 1_cp37m conda-forge
pyyaml 5.3.1 py37h7b6447c_1 anaconda
readline 8.0 h7b6447c_0 anaconda
scipy 1.5.2 py37h0b6359f_0 anaconda
setuptools 49.6.0 py37_0 anaconda
six 1.15.0 py_0 anaconda
sqlite 3.33.0 h62c20be_0 anaconda
tensorboard 1.15.0 pyhb230dea_0 anaconda
tensorflow 1.15.0 gpu_py37h0f0df58_0 anaconda
tensorflow-base 1.15.0 gpu_py37h9dcbed7_0 anaconda
tensorflow-estimator 1.15.1 pyh2649769_0 anaconda
tensorflow-gpu 1.15.0 h0d30ee6_0
termcolor 1.1.0 py37_1 anaconda
tk 8.6.10 hbc83047_0 anaconda
webencodings 0.5.1 py37_1 anaconda
werkzeug 0.16.1 py_0 anaconda
wheel 0.35.1 py_0 anaconda
wrapt 1.12.1 py37h7b6447c_1 anaconda
xz 5.2.5 h7b6447c_0 anaconda
yaml 0.2.5 h7b6447c_0 anaconda
zipp 3.1.0 py_0 anaconda
zlib 1.2.11 h7b6447c_3 anaconda
zstd 1.4.4 h0b5b093_3 anaconda

Details about conda and system ( conda info ):

$ conda info

packages in environment at /home/cmo1060/anaconda3/envs/tf__1_15:

Name Version Build Channel

_tflow_select 2.1.0 gpu anaconda
absl-py 0.10.0 py37_0 anaconda
astor 0.8.1 py37_0 anaconda
blas 1.0 mkl anaconda
c-ares 1.16.1 h7b6447c_0 anaconda
ca-certificates 2020.6.20 hecda079_0 conda-forge
certifi 2020.6.20 py37hc8dfbb8_0 conda-forge
cudatoolkit 10.0.130 0 anaconda
cudnn 7.6.5 cuda10.0_0 anaconda
cupti 10.0.130 0 anaconda
gast 0.2.2 py37_0 anaconda
google-pasta 0.2.0 py_0 anaconda
grpcio 1.31.0 py37hf8bcb03_0 anaconda
h5py 2.10.0 py37hd6299e0_1 anaconda
hdf5 1.10.6 hb1b8bf9_0 anaconda
importlib-metadata 1.7.0 py37_0 anaconda
intel-openmp 2020.2 254 anaconda
jpeg 9b habf39ab_1 anaconda
keras 2.3.1 0
keras-applications 1.0.8 py_1 anaconda
keras-base 2.3.1 py37_0 anaconda
keras-preprocessing 1.1.0 py_1 anaconda
ld_impl_linux-64 2.33.1 h53a641e_7 anaconda
libedit 3.1.20191231 h14c3975_1 anaconda
libffi 3.3 he6710b0_2 anaconda
libgcc-ng 9.1.0 hdf63c60_0 anaconda
libgfortran-ng 7.3.0 hdf63c60_0 anaconda
libprotobuf 3.13.0 hd408876_0 anaconda
libstdcxx-ng 9.1.0 hdf63c60_0 anaconda
libtiff 4.0.9 he6b73bb_1 conda-forge
lz4-c 1.9.2 he6710b0_1 anaconda
markdown 3.2.2 py37_0 anaconda
mkl 2019.4 243 anaconda
mkl-service 2.3.0 py37he904b0f_0 anaconda
mkl_fft 1.2.0 py37h23d657b_0 anaconda
mkl_random 1.1.0 py37hd6b4f25_0 anaconda
ncurses 6.2 he6710b0_1 anaconda
numpy 1.19.1 py37hbc911f0_0 anaconda
numpy-base 1.19.1 py37hfa32c7d_0 anaconda
openssl 1.1.1g h516909a_1 conda-forge
opt_einsum 3.1.0 py_0 anaconda
pip 20.2.2 py37_0 anaconda
protobuf 3.13.0 py37hf484d3e_0 anaconda
python 3.7.9 h7579374_0
python_abi 3.7 1_cp37m conda-forge
pyyaml 5.3.1 py37h7b6447c_1 anaconda
readline 8.0 h7b6447c_0 anaconda
scipy 1.5.2 py37h0b6359f_0 anaconda
setuptools 49.6.0 py37_0 anaconda
six 1.15.0 py_0 anaconda
sqlite 3.33.0 h62c20be_0 anaconda
tensorboard 1.15.0 pyhb230dea_0 anaconda
tensorflow 1.15.0 gpu_py37h0f0df58_0 anaconda
tensorflow-base 1.15.0 gpu_py37h9dcbed7_0 anaconda
tensorflow-estimator 1.15.1 pyh2649769_0 anaconda
tensorflow-gpu 1.15.0 h0d30ee6_0
termcolor 1.1.0 py37_1 anaconda
tk 8.6.10 hbc83047_0 anaconda
webencodings 0.5.1 py37_1 anaconda
werkzeug 0.16.1 py_0 anaconda
wheel 0.35.1 py_0 anaconda
wrapt 1.12.1 py37h7b6447c_1 anaconda
xz 5.2.5 h7b6447c_0 anaconda
yaml 0.2.5 h7b6447c_0 anaconda
zipp 3.1.0 py_0 anaconda
zlib 1.2.11 h7b6447c_3 anaconda
zstd 1.4.4 h0b5b093_3 anaconda

Instalation output after

conda install libtiff

``` Collecting package metadata (current_repodata.json): done Solving environment: done

Package Plan

environment location: /home/cmo1060/anaconda3/envs/tf__1_15

added / updated specs:
- libtiff

The following packages will be downloaded:

package                    |            build
---------------------------|-----------------
libtiff-4.0.9              |       he6b73bb_1         521 KB  conda-forge
------------------------------------------------------------
                                       Total:         521 KB

The following NEW packages will be INSTALLED:

python_abi conda-forge/linux-64::python_abi-3.7-1_cp37m

The following packages will be UPDATED:

openssl anaconda::openssl-1.1.1g-h7b6447c_0 --> conda-forge::openssl-1.1.1g-h516909a_1

The following packages will be SUPERSEDED by a higher-priority channel:

ca-certificates anaconda::ca-certificates-2020.7.22-0 --> conda-forge::ca-certificates-2020.6.20-hecda079_0
certifi anaconda::certifi-2020.6.20-py37_0 --> conda-forge::certifi-2020.6.20-py37hc8dfbb8_0
libtiff anaconda::libtiff-4.1.0-h2733197_1 --> conda-forge::libtiff-4.0.9-he6b73bb_1

Proceed ([y]/n)? y

Downloading and Extracting Packages
libtiff-4.0.9 | 521 KB | ##################################################################################################### | 100%
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

</details>

Odd behavior between libtiff and numpy

I'm looking for help debugging some failing CI jobs for my package. Some of the tests use the pylibtiff python package (wrapper around C libtiff) to write numpy arrays to a TIFF image.

Recently our CIs switched from using numpy 1.16.5 on appveyor to numpy 1.17. When this switch happened we started seeing failing tests where a numpy array of all 0s would result in the TIFF having non-zero pixels written to it.

I had seen this a couple days earlier on Travis on Linux because our CIs were accidentally installing numpy 1.18 from PyPI instead of numpy 1.17 from conda-forge, but I assumed this was just a lower-level compatibility issue taking a numpy wheel from PyPI and combining with conda-forge binaries so I ignored it. The above appveyor case is getting both numpy and libtiff from conda-forge.

Does anyone have an idea what might be going on between numpy 1.16 and numpy 1.17 to interfere with libtiff?

Working appveyor job: https://ci.appveyor.com/project/pytroll/satpy/builds/29983559
Failing appveyor job: https://ci.appveyor.com/project/pytroll/satpy/builds/30000631

My head hurts...