conda-forge / gdk-pixbuf-feedstock Goto Github PK

View Code? Open in Web Editor NEW

0.0 7.0 14.0 163 KB

A conda-smithy repository for gdk-pixbuf.

License: BSD 3-Clause "New" or "Revised" License

Shell 72.38% Batchfile 27.62%

gdk-pixbuf-feedstock's Introduction

About gdk-pixbuf-feedstock

Feedstock license: BSD-3-Clause

Home: https://developer.gnome.org/gdk-pixbuf/

Package license: LGPL-2.1-or-later

Summary: GdkPixbuf is a library for image loading and manipulation.

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 gdk-pixbuf

Installing gdk-pixbuf 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, gdk-pixbuf can be installed with conda:

conda install gdk-pixbuf

or with mamba:

mamba install gdk-pixbuf

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

conda search gdk-pixbuf --channel conda-forge

or with mamba:

mamba search gdk-pixbuf --channel conda-forge

Alternatively, mamba repoquery may provide more information:

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

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

# List dependencies of `gdk-pixbuf`:
mamba repoquery depends gdk-pixbuf --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 gdk-pixbuf-feedstock

If you would like to improve the gdk-pixbuf 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/gdk-pixbuf-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

gdk-pixbuf-feedstock's People

Contributors

Watchers

Forkers

notestaff regro-cf-autotick-bot pkgw croth1 tjakob chrisburr ryanvolz anacondarecipes tschoonj isuruf erykoff tsibley conda-forge-admin xhochy

gdk-pixbuf-feedstock's Issues

Unable to install for other platforms

When installing for a different platform (or cross-compiling with conda-build) installing the environment fails:

$ CONDA_SUBDIR=linux-ppc64le conda create --name test gdk-pixbuf
.....
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
ERROR conda.core.link:_execute(700): An error occurred while installing package 'conda-forge::gdk-pixbuf-2.38.2-hb6602f3_4'.
Rolling back transaction: done

LinkError: post-link script failed for package conda-forge::gdk-pixbuf-2.38.2-hb6602f3_4
location of failed script: /home/cburr/miniconda3/envs/test/bin/.gdk-pixbuf-post-link.sh
==> script messages <==
<None>
==> script output <==
stdout:
stderr: /home/cburr/miniconda3/envs/test/bin/.gdk-pixbuf-post-link.sh: line 21: /home/cburr/miniconda3/envs/test/bin/gdk-pixbuf-query-loaders: cannot execute binary file: Exec format error

return code: 126

()

This is due to the post link script and to avoid this the conda-build docs state:

Post-link and pre-unlink scripts should:

Depend only on simple system tools such as rm, cp, mv, and ln.

I've not looked into the details yet but is there any way running gdk-pixbuf-query-loaders can be avoided?

2.36.12 1004 always creates python3.8 folder in /envs/envname/lib

Issue: the latest version of gdk-pixbuf (2.36.12 haf2c3b9_1004) will create a python3.8 folder in miniconda/envs/<envname>/lib, even if installed with python 3.7 (as in my case).

there is only a single file in this folder:

$ find python3.8
python3.8
python3.8/__pycache__
python3.8/__pycache__/_sysconfigdata_x86_64_conda_cos6_linux_gnu.cpython-38.pyc

The build (1003) before was still fine!

It seems like the file is packaged during build.

While this could be just of aesthetic interest, there is an issue I encountered because of it: conda develop will infer the site packages folder by checking for python* folder in lib using glob. The python3.8 one might come first and then it fails as it does not contain a site packages folder.

Environment (conda list):

$ conda list
# packages in environment at /home/***/miniconda3/envs/tmp-gtk-pixbuf:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                        main    conda-forge
bzip2                     1.0.8                h516909a_1    conda-forge
ca-certificates           2019.11.28           hecc5488_0    conda-forge
cairo                     1.16.0            hfb77d84_1002    conda-forge
certifi                   2019.11.28               py37_0    conda-forge
fontconfig                2.13.1            h86ecdb6_1001    conda-forge
freetype                  2.10.0               he983fc9_1    conda-forge
gdk-pixbuf                2.36.12           haf2c3b9_1004    conda-forge
gettext                   0.19.8.1          hc5be6a0_1002    conda-forge
glib                      2.58.3          py37h6f030ca_1002    conda-forge
gobject-introspection     1.58.2          py37h5503ade_1002    conda-forge
icu                       64.2                 he1b5a44_1    conda-forge
jpeg                      9c                h14c3975_1001    conda-forge
ld_impl_linux-64          2.33.1               h53a641e_7    conda-forge
libffi                    3.2.1             he1b5a44_1006    conda-forge
libgcc-ng                 9.2.0                hdf63c60_0    conda-forge
libiconv                  1.15              h516909a_1005    conda-forge
libpng                    1.6.37               hed695b0_0    conda-forge
libstdcxx-ng              9.2.0                hdf63c60_0    conda-forge
libtiff                   4.1.0                hc3755c2_1    conda-forge
libuuid                   2.32.1            h14c3975_1000    conda-forge
libxcb                    1.13              h14c3975_1002    conda-forge
libxml2                   2.9.10               hee79883_0    conda-forge
lz4-c                     1.8.3             he1b5a44_1001    conda-forge
ncurses                   6.1               hf484d3e_1002    conda-forge
openssl                   1.1.1d               h516909a_0    conda-forge
pcre                      8.43                 he1b5a44_0    conda-forge
pip                       19.3.1                   py37_0    conda-forge
pixman                    0.38.0            h516909a_1003    conda-forge
pthread-stubs             0.4               h14c3975_1001    conda-forge
python                    3.7.3                h357f687_2    conda-forge
readline                  8.0                  hf8c457e_0    conda-forge
setuptools                42.0.2                   py37_0    conda-forge
sqlite                    3.30.1               hcee41ef_0    conda-forge
tk                        8.6.10               hed695b0_0    conda-forge
wheel                     0.33.6                   py37_0    conda-forge
xorg-kbproto              1.0.7             h14c3975_1002    conda-forge
xorg-libice               1.0.10               h516909a_0    conda-forge
xorg-libsm                1.2.3             h84519dc_1000    conda-forge
xorg-libx11               1.6.9                h516909a_0    conda-forge
xorg-libxau               1.0.9                h14c3975_0    conda-forge
xorg-libxdmcp             1.1.3                h516909a_0    conda-forge
xorg-libxext              1.3.4                h516909a_0    conda-forge
xorg-libxrender           0.9.10            h516909a_1002    conda-forge
xorg-renderproto          0.11.1            h14c3975_1002    conda-forge
xorg-xextproto            7.3.0             h14c3975_1002    conda-forge
xorg-xproto               7.0.31            h14c3975_1007    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 : tmp-gtk-pixbuf
    active env location : /home/***/miniconda3/envs/tmp-gtk-pixbuf
            shell level : 2
       user config file : /home/***/.condarc
 populated config files : /home/***/.condarc
          conda version : 4.7.12
    conda-build version : 3.18.10
         python version : 3.6.7.final.0
       virtual packages : 
       base environment : /home/***/miniconda3  (writable)
           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/***/miniconda3/pkgs
                          /home/***/.conda/pkgs
       envs directories : /home/***/miniconda3/envs
                          /home/***/.conda/envs
               platform : linux-64
             user-agent : conda/4.7.12 requests/2.22.0 CPython/3.6.7 Linux/4.15.0-70-generic ubuntu/18.04.3 glibc/2.27
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

Need a way to update list of gdk-pixbuf loaders

Other packages can provide "loader" plugins that gdk-pixbuf can load dynamically, allowing it to process new image format files. But in order for gdk-pixbuf to know about these loaders, a special cache file must be updated when these packages are installed or uninstalled.

I believe that this means that packages that provide gdk-pixbuf loaders — like the newly-added librsvg — need post-link and post-unlink scripts to deal with updating the gdk-pixbuf loader cache.

In order to update the loader cache, one needs to execute a non-trivial bit of shell code. Below is what I have been using in my personal packages:

# Make sure that loaders.cache is fully up-to-date. I don't want to assume
# that pkg-config is available, so we hack a bit to avoid running it when we
# get the cache location. Or we could just glob or hardcode the binary version
# ...

set -e
eval $(grep -v : $PREFIX/lib/pkgconfig/gdk-pixbuf-2.0.pc)
if [ -z "$gdk_pixbuf_cache_file" ] ; then
    bindir="$(echo $PREFIX/lib/gdk-pixbuf-2.0/*)"
    if [ ! -d $bindir ] ; then
       echo >&2 "error: no such gdk-pixbuf binary directory $PREFIX/lib/gdk-pixbuf-2.0/*"
       exit 1
    fi
    gdk_pixbuf_cache_file=$bindir/loaders.cache
fi
$PREFIX/bin/gdk-pixbuf-query-loaders >$gdk_pixbuf_cache_file

I think that gdk-pixbuf should provide this bit of shell script so that not every dependent package needs to embed the same logic — that way, if the script needs changing, all that needs to happen is to update the gdk-pixbuf package itself.

By the same logic, I think that the above script should just be provided as gdk-pixbuf's own post-link and post-unlink scripts. Other packages can then just pass off responsibility on to it:

exec $PREFIX/bin/.gdk-pixbuf-post-link.sh

I can prepare a PR if this sounds like a good plan.

Mark 2.36.12 1004 as broken

When #14 is build and deployed we should ask core to mark the affected builds as broken.

Add back zlib as dependency

Additional comment:

See conda-forge/gtk3-feedstock#58 (comment) and the comment that follows

@conda-forge-admin please rerender