python-pillow / pillow-wheels Goto Github PK

Pillow macOS Wheel Builder

Home Page: https://github.com/python-pillow/pillow-wheels/releases

Shell 100.00%

pillow-wheels's Introduction

Pillow Wheel Builder

This repository creates wheels for tagged versions of Pillow:

./update-pillow-tag.sh <VERSION>

Wheels

Wheels are uploaded to https://github.com/python-pillow/pillow-wheels/releases. Credentials for this specific repo are stored in a Travis CI secret, so the upload won't work from another repository.

Windows wheels are not created here. Instead, they are GitHub Actions artifacts created on each run of the Pillow repository.

PyPI

Download wheels from the latest release and upload to PyPI:

python3 -m twine upload Pillow-<VERSION>-*

pillow-wheels's People

Contributors

Stargazers

Watchers

Forkers

wiredfool hugovk matthew-brett radarhere gregbowyer varenc sgillies jokester nulano kawka-maciej fdintino sqmeeee veeratejag mgiessing ethicalsecurity-agency nikitagashkov

pillow-wheels's Issues

delocate.delocating.DelocationError: wheel/PIL/.dylibs/libwebp.7.dylib already exists

This has started happening for Python 3.8 on macOS since Travis changed from a 10.13.3 image to a 10.13.6 image:

Building wheels for collected packages: delocate
  Building wheel for delocate (setup.py): started
  Building wheel for delocate (setup.py): finished with status 'done'
  Created wheel for delocate: filename=delocate-0.8.0-cp38-none-any.whl size=101856 sha256=a8ed72c8c953b730b87150979092ef15f37998dbc7f66a384f2e874e3de21fb8
  Stored in directory: /Users/travis/Library/Caches/pip/wheels/a7/ec/01/fff106a59b5697042f1ff32814f1f112e3eee5a2c5239d7735
Successfully built delocate
Installing collected packages: delocate
Successfully installed delocate-0.8.0
Traceback (most recent call last):
  File "/Users/travis/build/python-pillow/pillow-wheels/venv/bin/delocate-wheel", line 8, in <module>
    sys.exit(main())
  File "/Users/travis/build/python-pillow/pillow-wheels/venv/lib/python3.8/site-packages/delocate/cmd/delocate_wheel.py", line 68, in main
    copied = delocate_wheel(wheel, out_wheel, lib_filt_func=lib_filt_func,
  File "/Users/travis/build/python-pillow/pillow-wheels/venv/lib/python3.8/site-packages/delocate/delocating.py", line 376, in delocate_wheel
    copied_libs = delocate_path(package_path, lib_path,
  File "/Users/travis/build/python-pillow/pillow-wheels/venv/lib/python3.8/site-packages/delocate/delocating.py", line 289, in delocate_path
    return copy_recurse(lib_path, copy_filt_func, copied)
  File "/Users/travis/build/python-pillow/pillow-wheels/venv/lib/python3.8/site-packages/delocate/delocating.py", line 145, in copy_recurse
    _copy_required(lib_path, copy_filt_func, copied_libs)
  File "/Users/travis/build/python-pillow/pillow-wheels/venv/lib/python3.8/site-packages/delocate/delocating.py", line 230, in _copy_required
    raise DelocationError(out_path + ' already exists')
delocate.delocating.DelocationError: /private/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg80000gn/T/tmpyrhzp83g/wheel/PIL/.dylibs/libwebp.7.dylib already exists

Failing build:

https://travis-ci.org/python-pillow/pillow-wheels/jobs/627386267

Earlier passing build:

https://travis-ci.org/python-pillow/pillow-wheels/jobs/624597203

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/lint.yml

actions/checkout v4

actions/setup-python v4

pre-commit/action v3.0.0

.github/workflows/wheels-linux.yml

actions/checkout v4

actions/setup-python v4

actions/upload-artifact v3

.github/workflows/wheels-macos.yml

actions/checkout v4

actions/setup-python v4

actions/upload-artifact v3

.github/workflows/wheels.yml

actions/download-artifact v3

fnkr/github-action-ghr v1.3

Check this box to trigger a request for Renovate to run again on this repository

Stripping the Pillow libraries fails makes pyinstaller binary fail at runtime

What did you do?

When using PyInstaller to freeze an application that contains pillow as a dependency, the --strip option runs strip on the libraries. This fails on the _imaging pillow library.

What did you expect to happen?

The pillow C libraries should still be loaded when stripped.

I'm not exactly sure this is a Pillow issue, but since it works without stripping, I guess it is.

The unstripped binary is 3MB, stripping brings it down to 636kB.

libs.tar.gz

What actually happened?

ELF load command address/offset not page-aligned

What are your OS, Python and Pillow versions?

OS: Arch Linux
Python: 3.10.4
Pillow: 9.1.0

$ cd "$(mktemp -d)"
$ python3.10 -m venv .
$ source bin/activate
$ pip install pillow pyinstaller
$ $EDITOR pilstrip.py
$ pyinstall -n pil-nostrip pilstrip.py
$ dist/pil-nostrip/pil-nostrip
<module 'PIL.Image' from '/tmp/tmp.5d4W8x0r8d/dist/pil-nostrip/PIL/Image.pyc'>
$ pyinstaller -n pil-strip --strip pilstrip.py
$ dist/pil-strip/pil-strip
Traceback (most recent call last):
  File "pilstrip.py", line 1, in <module>
    from PIL import Image
  File "PyInstaller/loader/pyimod03_importers.py", line 495, in exec_module
  File "PIL/Image.py", line 132, in <module>
ImportError: /tmp/tmp.5d4W8x0r8d/dist/pil-strip/PIL/_imaging.cpython-310-x86_64-linux-gnu.so: ELF load command address/offset not page-aligned
[221404] Failed to execute script 'pilstrip' due to unhandled exception!

from PIL import Image

print(Image)

Reasonable way to run locally?

@hugovk @nulano

Because of python-pillow/Pillow#4225, I need to be able to reproduce the production builds locally. Have either of you done anything like this? It looks like it needs a specially setup trusty virtual machine including modern python & docker, or docker in docker to make it work.

Xcode 6.4 builds deprecated in Travis CI

As seen at https://travis-ci.org/python-pillow/pillow-wheels/jobs/428587685 -

Running builds with Xcode 6.4 in Travis CI is deprecated and will be removed in January 2019. If Xcode 6.4 is critical to your builds, please contact our support team at [email protected] to discuss options.

Given #84 and python-pillow/Pillow#3068, this bears discussion.

If we upgrade from Xcode 6.4, then we lose OS X 10.10, as noted #84 (comment)

universal2 wheels for macOS

Hello! It would be really helpful to have universal2 builds of Pillow available for macOS in addition to the x86_64 and arm64 builds.

Having a single wheel that supports both platforms makes it a lot easier to release tools across both macOS architectures.

Depends

This might just introduce confusion, but throwing the idea out there for consideration - would it be worth removing the pillow-wheels archive directory, and instead use the pillow-depends repository?

curl: (28) Failed to connect to sourceware.org port 443: Operation timed out

There's been some timeouts, such as this on linux / 3.10 musllinux x86_64:

    0     0    0     0    0     0      0      0 --:--:--  0:02:04 --:--:--     0
    0     0    0     0    0     0      0      0 --:--:--  0:02:05 --:--:--     0Still building...
  
    0     0    0     0    0     0      0      0 --:--:--  0:02:06 --:--:--     0
    0     0    0     0    0     0      0      0 --:--:--  0:02:07 --:--:--     0
    0     0    0     0    0     0      0      0 --:--:--  0:02:08 --:--:--     0
    0     0    0     0    0     0      0      0 --:--:--  0:02:09 --:--:--     0
    0     0    0     0    0     0      0      0 --:--:--  0:02:10 --:--:--     0
  curl: (28) Failed to connect to sourceware.org port 443 after 130355 ms: Operation timed out
  Error: Process completed with exit code 28.

(Full logs)

Here's another:

linux-latest / 3.8 manylinux i686

Can we make this more robust?

https://sourceware.org/mirrors.html says:

These sites mirror the free software ftp directory directly. The master sourceware.org server itself is usually overloaded.

Python 3.2 builds failing

For example:
https://travis-ci.org/python-pillow/pillow-wheels/builds/103963385

/tmp/tmp88uwda/pip.zip/pip/_vendor/pkg_resources/__init__.py:87: UserWarning: Support for Python 3.0-3.2 has been dropped. Future versions will fail here.
Traceback (most recent call last):
  File "downloads/get-pip.py", line 19033, in <module>
    main()
  File "downloads/get-pip.py", line 194, in main
    bootstrap(tmpdir=tmpdir)
  File "downloads/get-pip.py", line 82, in bootstrap
    import pip
  File "/tmp/tmp88uwda/pip.zip/pip/__init__.py", line 15, in <module>
  File "/tmp/tmp88uwda/pip.zip/pip/vcs/mercurial.py", line 9, in <module>
  File "/tmp/tmp88uwda/pip.zip/pip/download.py", line 35, in <module>
  File "/tmp/tmp88uwda/pip.zip/pip/utils/ui.py", line 15, in <module>
  File "/tmp/tmp88uwda/pip.zip/pip/_vendor/progress/bar.py", line 48
    empty_fill = u'âˆ™'
                      ^
SyntaxError: invalid syntax
Failed to install pip

Here's a setuptools commit that contains the warning "Support for Python 3.0-3.2 has been dropped. Future versions will fail here."
https://bitbucket.org/pypa/setuptools/commits/1cbe02d87fa9b23c3798ef45f3e80e6c75426452

And then, perhaps coincidentally, pip fails to install. See this report and workaround: pypa/pip#3390 (comment)

I think this installation stuff comes from https://github.com/MacPython/terryfy, @matthew-brett please can you have a look?

It looks like two things are needed: first, fix pip installation (now). Second, pin setuptools to some 18.x release (for later).

Linux builds fail: no rsync

Since turning on cron builds a couple of days ago, the Linux jobs are failing. They were passing when the last changes were pushed on 1st January. (MacOS passed before and pass now.)

Dependencies are failing to build because a missing rsync fails to fetch the zip files.

/io/multibuild/common_utils.sh: line 107: rsync: command not found
/io/multibuild/library_builders.sh: line 99: cd: jpeg-9b: No such file or directory

https://travis-ci.org/python-pillow/pillow-wheels/jobs/347228468#L527

Linux builds failing

https://travis-ci.org/python-pillow/pillow-wheels/jobs/168719096

Now it appears that the many-linux wheels for linux are failing, because libjpeg.so can't be found.

3.3.0 push didn't upload wheels

@matthew-brett It looks like push for Pillow 3.3.0 didn't send the wheels to the rackspace cdn.

About link

https://github.com/python-pillow/pillow-wheels shows a link to rackcdn in the About section.

This is no longer relevant, as per #146, and should be removed.

py35 branch can be removed

Just a minor cleanup. The py35 branch in this repository can be removed, since the only change - https://github.com/python-pillow/pillow-wheels/compare/py35 - was included in 46d2be4

x64 wheels are broken

The build process for the x64 wheels is broken due to repos being inaccessible. I don't know if this is a temporary issue or not.

see https://travis-ci.org/python-pillow/pillow-wheels/jobs/218267819 for trace

Musllinux wheels

CI request: build PEP 656-compliant "musllinux" wheels. This will allow easy installation in Alpine Docker images

libpng not properly linked to libz in manylinux wheels?

What did you do?

With the following Dockerfile:

FROM python:3.6-slim
RUN pip install --no-cache Pillow==4.0.0
RUN find /usr/local/lib/python3.6/site-packages -name '*.so*' | xargs ldd

Run docker build -t pillow-ldd .. Observe output of last RUN command.

What did you expect to happen?

Expected all libraries to be linked successfully.

What actually happened?

All libraries are linked except for libpng:

/usr/local/lib/python3.6/site-packages/PIL/.libs/libpng16-4b619e46.so.16.25.0:
	linux-vdso.so.1 (0x00007ffc46363000)
	**libz-a147dcb0.so.1.2.3 => not found**
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f78e2e06000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f78e2a5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00005652f53d8000)

Other libraries link to libz-a147dcb0.so.1.2.3 successfully, just not libpng for some reason.

I don't know if this manifests in any actual issues. It's just concerning that the library doesn't link.

What versions of Pillow and Python are you using?

As you can see, this is Python 3.6 with Pillow 4.0.0. I've seen the same with Python 2.7 + Pillow 4.0.0.

Travis CI failing due to missing features: fribidi harfbuzz raqm

Travis CI builds for this repo have had several months of downtime. Since we got new Travis CI credits and re-enabled this repo (python-pillow/Pillow#5028 (comment)), the build is failing.

For example:

https://travis-ci.com/github/python-pillow/pillow-wheels/builds/225368840

Tests run, but then it hangs and times out after features mismatch:

...
SKIPPED [1] Tests/test_shell_injection.py:34: cjpeg not available
SKIPPED [1] Tests/test_shell_injection.py:39: Netpbm not available
SKIPPED [1] Tests/test_shell_injection.py:45: Netpbm not available
XFAIL Tests/test_decompression_bomb.py::TestDecompressionBomb::test_exception_ico
  different exception
XFAIL Tests/test_image_resample.py::TestCoreResampleAlphaCorrect::test_levels_rgba
  Current implementation isn't precise enough
XFAIL Tests/test_image_resample.py::TestCoreResampleAlphaCorrect::test_levels_la
  Current implementation isn't precise enough
XPASS Tests/test_file_palm.py::test_p_mode Palm P image is wrong
= 2532 passed, 230 skipped, 3 xfailed, 1 xpassed, 17 warnings in 94.88s (0:01:34) =
Features should be: 'fribidi harfbuzz raqm transp_webp webp_anim webp_mux xcb'; but are 'transp_webp webp_anim webp_mux xcb'
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
The build has been terminated

The missing features are fribidi harfbuzz raqm.

From run_tests in config.sh:

pillow-wheels/config.sh

Lines 171 to 176 in 3b8d915

 local features=$(python3 -c 'from PIL.features import *; print(" ".join(sorted(get_supported_features())))') 

 if [ "$features" != "$EXP_FEATURES" ]; then 

 echo "Features should be: '$EXP_FEATURES'; but are '$features'" 

 ret=1 

 fi 

 return $ret

Looks like run_tests is called by multibuild.

Why is there a feature mismatch causing this failure?
Why is it hanging instead of failing immediately?

Alpine Linux MUSL Arm64

What is your OS versions?

Alpine Linux ARM64

Hi,

I was searching on PyPI for Pillow MuslLinux_ARM64 wheel. (https://pypi.org/project/Pillow/#files)

When searching for a MuslLinux Wheel I only find it for x86/x64. What does it need to provide an Arm64 Musl wheel?

Would be great to have this also for Arm64.

Thank you!

Do not upload to rackspace

As per matthew-brett/multibuild#304, projects should not upload to rackspace since this is no longer free. Over at numpy-wheels, we chose to use anaconda.org for staging. Cython chose to upload them to github as release packages. One advantage to using a shared location is that any of the wheels in that location can be installed with a single -i https://pypi.anaconda.org/scipy-wheels-nightly/simple argument to pip.

If you choose the anaconda route, I can give a pillow admin rights to the anaconda staging area.

Pillow wheels >= 3.2.0 not installable on Mac OS X due to --with-pymalloc

Recent Pillow wheels are not installable on Mac OS X / Python 2.7. The last one which works is 3.1.1. Taking a close look at pip --verbose install Pillow reveals that older builds apparently are not compiled with any ABI flags (see PEP 3149) (e.g. on https://pypi.python.org/pypi/Pillow/3.1.1 there is Pillow-3.1.1-cp27-none-macosx_10...) while newer ones apparently were compiled with --with-pymalloc (e.g. on https://pypi.python.org/pypi/Pillow/3.2.0 there is Pillow-3.2.0-cp27-cp27m-macosx_10..., note -cp27m- instead of -none- ).

Wheels built with a Python version built with --with-pymalloc are apparently incompatible with Mac OS X Python interpreter (El Capitan in my case).

Enable re-running failed jobs

The first attempt at a release build had a single timeout caused by #276.

Luckily GitHub has a new feature to re-run only the failed jobs:

https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

But for some reason, that's not available here and we needed to re-run all jobs:

The second attempt had another job failing with a similar timeout. Again it required re-running all jobs (takes about 45 minutes).

Perhaps the "Re-run failed jobs" is unavailable due to this "cross-over" of dependant jobs?

Idea for testing: make all jobs a no-op so they don't actually take a long time to build, and make a single job always fail.

Could ask here or there:

Still need help?
Ask the GitHub community
Contact support

Travis CI not deploying wheels to GitHub Releases

Travis CI is meant to upload the aarch64 wheels it builds to GitHub Releases:

# Upload wheels to GitHub Releases
deploy:
  provider: releases
  api_key: $GITHUB_RELEASE_TOKEN
  file_glob: true
  file: "${TRAVIS_BUILD_DIR}/${WHEEL_SDIR}/*.whl"
  on:
    repo: python-pillow/pillow-wheels
  skip_cleanup: true

For the past few releases, it's not worked.

For example yesterday's 9.1.1:

Skipping a deployment with the releases provider because this branch is not permitted: 9.1.1

As a workaround yesterday, I pushed a branch called build-aarch64 with this:

diff --git a/.travis.yml b/.travis.yml
index 98f9cb4..a6771bd 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -55,4 +55,5 @@ deploy:
   file: "${TRAVIS_BUILD_DIR}/${WHEEL_SDIR}/*.whl"
   on:
     repo: python-pillow/pillow-wheels
+    branch: build-aarch64
   skip_cleanup: true

Which built the branch, plus three others:

https://app.travis-ci.com/github/python-pillow/pillow-wheels/builds

And deployed the wheels into 3 untagged* tags:

I think what happened is the first one made a deploy, and then those 3 "tags" triggered builds which didn't deploy:

Anyway, this was just a workaround to get the release finished.

Maybe we need an explicit tags: true for the deploy trigger:

tags can be true, false or any other string:

tags: true: deployment is triggered if and only if $TRAVIS_TAG is set. Depending on your workflow, you may set $TRAVIS_TAG explicitly, even if this is a non-tag build when it was initiated. This causes the branch condition to be ignored.
...

https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on

Where:

TRAVIS_TAG: If the current build is for a git tag, this variable is set to the tag’s name, otherwise it is empty ("").

https://docs.travis-ci.com/user/environment-variables/

I'll try it out with a 9.1.1.post1 tag, just for testing purposes.

Pillow wheel 5.1 broken on OS X 10.11.6 due to liblzma.5.dylib

It appears that the liblzma.5.dylib file was built for OS X 10.12 and up which means the build is broken for OS X 10.11.6

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/PIL/Image.py", line 60, in <module>
    from . import _imaging as core
ImportError: dlopen(/usr/local/lib/python3.6/site-packages/PIL/_imaging.cpython-36m-darwin.so, 2): Symbol not found: _clock_gettime
  Referenced from: /usr/local/lib/python3.6/site-packages/PIL/.dylibs/liblzma.5.dylib (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib
 in /usr/local/lib/python3.6/site-packages/PIL/.dylibs/liblzma.5.dylib

Python 3.11 wheel for macOS does not work for x86_64

What did you do?

Attempted to use cibuildwheel to build a package that depends on Pillow.

  ImportError while loading conftest '/Users/runner/work/neuroglancer/neuroglancer/python/tests/conftest.py'.
  work/neuroglancer/neuroglancer/python/tests/conftest.py:16: in <module>
      import neuroglancer.webdriver
  /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/neuroglancer/__init__.py:16: in <module>
      from .server import set_static_content_source, set_server_bind_address, is_server_running, stop
  /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/neuroglancer/server.py:31: in <module>
      from . import local_volume, static
  /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/neuroglancer/local_volume.py:29: in <module>
      from .chunks import encode_jpeg, encode_npz, encode_raw
  /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/neuroglancer/chunks.py:19: in <module>
      from PIL import Image
  /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/PIL/Image.py:100: in <module>
      from . import _imaging as core
  E   ImportError: dlopen(/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/PIL/_imaging.cpython-311-darwin.so, 2): no suitable image found.  Did find:
  E   	/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-95w581j7/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/PIL/_imaging.cpython-311-darwin.so: mach-o, but wrong architecture

What are your OS, Python and Pillow versions?

OS: macOS 11.6.8 (github actions macos-latest)
Python: 3.11
Pillow: 9.2.0

OSX Builds Failing

@matthew-brett

https://travis-ci.org/python-pillow/pillow-wheels/jobs/164959060

OSX builds were working earlier today -- and this doesn't appear to be something that's related to the Pillow code.

Ideas?

	local features=$(python3 -c 'from PIL.features import *; print(" ".join(sorted(get_supported_features())))')
	if [ "$features" != "$EXP_FEATURES" ]; then
	echo "Features should be: '$EXP_FEATURES'; but are '$features'"
	ret=1
	fi
	return $ret

python-pillow / pillow-wheels Goto Github PK

pillow-wheels's Introduction

Pillow Wheel Builder

Archives

Wheels

PyPI

pillow-wheels's People

Contributors

Stargazers

Watchers

Forkers

pillow-wheels's Issues

Detected dependencies

What did you do?

What did you expect to happen?

What actually happened?

What are your OS, Python and Pillow versions?

What did you do?

What did you expect to happen?

What actually happened?

What versions of Pillow and Python are you using?

What is your OS versions?

What did you do?

What are your OS, Python and Pillow versions?

Recommend Projects

Recommend Topics

Recommend Org