cinnamon-settings doesn't open with pillow >= 6.0.0

[alefpereira]

 * Cinnamon version 4.0.10
 * Distribution - Linux Mint 19.1 (Tessa) 
 * Graphics hardware *and* driver used unimportant
 * 32 or 64 bit
 * Attach /home/<username>/.xsession-errors, or /var/log/syslog
 ```

**Issue**
cinnamon-settings doesn't open with pillow >= 6.0.0. It doesn't open and the following Traceback is shown:

```Traceback (most recent call last):
  File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 619, in <module>
    window = MainWindow()
  File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 247, in __init__
    for module in modules:
  File "/usr/share/cinnamon/cinnamon-settings/modules/cs_backgrounds.py", line 5, in <module>
    import imtools
  File "/usr/share/cinnamon/cinnamon-settings/bin/imtools.py", line 623, in <module>
    if Image.VERSION == '1.1.7':
AttributeError: module 'PIL.Image' has no attribute 'VERSION'

Steps to reproduce

1. Install pillow >= 6.0.0 in python: pip3 install pillow=='6.0.0'
2. Try to open cinnamon-settings: cinnamon-settings

Expected behaviour

cinnamon-settings should open normally.

Other information

Issue Thread in Linux Mint Forums: https://forums.linuxmint.com/viewtopic.php?f=68&t=291452&p=1617409#p1617409

Since version 6.0.0 pillow does not use "Image.VERSION", and recommend to use "Image.__version__" (python conventional way to check package/modules versions) as it will be the only way to check in 7.0.0. If you want to, you can find more details in links below.

Until it is not officially fixed in the repositories I manually changed imtools.py file in the line from "if Image.VERSION == '1.1.7':" to "if Image.__version__ == '1.1.7':" and cinnamon-settings is running just fine.

Here are their plans for VERSION and PILLOW_VERSION.
https://pillow.readthedocs.io/en/stable/releasenotes/5.2.0.html?highlight=VERSION

The release note stating that VERSION was removed in version 6.0.0.
https://pillow.readthedocs.io/en/stable/releasenotes/6.0.0.html

Here there is a comment saying that PILLOW_VERSION will also be removed in version 7.
https://pillow.readthedocs.io/en/stable/_modules/PIL/Image.html?highlight=PILLOW_VERSION

[JosephMcc]

Thank you for the excellent bug report and already doing the research to make this easy to troubleshoot on our side. Much appreciated

[FrancoARossi]

Can confirm. I changed:
File "/usr/share/cinnamon/cinnamon-settings/bin/imtools.py", line 623, in <module>
if Image.VERSION == '1.1.7':

to:
if Image.__version__ == '1.1.7':

And it worked!

[conqp]

Since, this is a check for a fix for an older version of PIL, the test will most likely break on PIL 1.1.7 where Image.VERSION is still in place.
Hence, I suggest this:

--- imtools.py  2019-04-05 11:57:35.619594623 +0200
+++ /usr/share/cinnamon/cinnamon-settings/bin/imtools.py    2019-04-05 12:03:05.775027173 +0200
@@ -620,7 +620,7 @@
         has_alpha(image)


-if Image.VERSION == '1.1.7':
+if getattr(Image, 'VERSION', None) == '1.1.7':

     def split(image):
         """Work around for bug in Pil 1.1.7

[eli-schwartz]

break on PIL 1.1.7

PIL 1.1.7 was released in 2009 and does not support python3 at all, Pillow is what basically everyone uses for the last decade. We're finally in a safe place where we can absolutely guarantee no crazy people have this ancient and terrible PIL implementation installed, so we do not have to try to handle it at all. ;)

[robshep]

Thanks for the work on this. As a Mint 19.1 Cinnamon user, what can I do to workaround this issue?

When will it appear in the update channels?

Thanks

[smurphos]

@robshep, pending an update rolling out I posted some instructions to apply the fixing patch manually for someone suffering the issue over on the Mint forums - https://forums.linuxmint.com/viewtopic.php?p=1622330#p1622330

[Chrisdanyk]

pip uninstall Pillow==x.x.x
pip3 uninstall Pillow==x.x.x
pip3 install Pillow==5.4.1

[eli-schwartz]

The most recent maintenance release of cinnamon predated the fix for this issue, but hopefully it could be backported now so that the next maintenance release will include the fix.

It may only affect Linux Mint for users who have updated versions of pillow installed to their user PYTHONPATH, but several other distros have pillow 6 now, and could be broken. I've backported the commit for Arch Linux, but I think e.g. Gentoo may be broken. Fedora would be unaffected I guess due to currently packaging a snapshot from git master.

[bernd-wechner]

For the record just stumbled upon this and patched imtools.py to use __version__ and am rolling again. Guess I'll see it fixed with an upgrade to Cinnamon some time.

[sam5558]

Thank you so much @FrancoARossi, you just saved my life :+1:

[ghtmtt]

FYI: Just updated debian sid (update && safe-upgrade) and hit the same issue. I solved thanks to https://github.com/linuxmint/cinnamon/issues/8495#issuecomment-480059701

[crosser]

JFYI happens on Ubuntu (eoan)

[AndrewDavis]

On Linux Mint 19.1 Cinnamon 4.0.10 now (can tell because I can open System Settings->System Info now :D), had this problem for months, just updated, and I still have this problem. @FrancoARossi's solution worked for me as well, but really this should have been fixed months ago in the update channels.

[smurphos]

@AndrewDavis it is fixed in Cinnamon 4.2, Mint 19.2. You can upgrade via the Update Manager - look in the edit menu.

[eli-schwartz]

Sure it should have been fixed. Unfortunately, it is entirely outside of our control, for the most part. Debain and Ubuntu doesn't have good quality assurance, because they are using a very very old version of Cinnamon but also updating their python3-pil package to incompatible versions.

Since this is not the Debian or Ubuntu bugtracker, the Linux Mint team cannot do anything about Debian/Ubuntu being broken, which is what a lot of people here are complaining about. Possibly something can be done about old versions of Linux Mint? As I don't use Debian-based distros, I'm unclear what versions of related packages are available there. Is this on the stock system, or has pillow been updated via pip again, as the original reporter did?

(If you are using pip to upgrade system packages, maybe don't do that!)

[AndrewDavis]

@smurphos I like how Update Manager says, "Your system is up to date". I'll give it a shot, thanks.

@eli-schwartz AFAIK I haven't been using pip at all. I take issue with what you said though, for two reasons:

1. Mint can do something about it, I guess they just don't want to separate from Ubuntu.
2. More importantly, Mint can test its own stuff before releasing updates, and this is something that should have borkt in the tests.

[eli-schwartz]

Again, most of these issues seem to be coming from Debian/Ubuntu users, where it is legitimately broken because of bad QA and because the Debian packagers apparently have no problem updating python3-pil in bullseye/sid (and that then ends up in Ubuntu eoan). I guess it doesn't matter to them because hey, it's only the testing versions of the distribution. And the original reporter, on Linux Mint 19.1, used pip to upgrade pillow to a version not officially supported by the package repositories.

So I guess the question is, what version of python3-pil is reported by apt on a Linux Mint 19.1 system? Back in April, the answer was "not 6.x", and I don't think that it's supposed to start pulling from sid/eoan? But Linux Mint does not AFAIK run a website instance of https://salsa.debian.org/webmaster-team/packages, so I cannot check.

[AndrewDavis]

@eli-schwartz apt show python3-pil says Version is 5.1.0-1, for me.

Btw, is this feedback somehow getting relayed to Debian?

[FistfulOfStars]

most of these issues seem to be coming from Debian/Ubuntu users

I, and others using Linux Mint are experiencing the same issue.

Speaking for myself only:

LM 19.1 Tessa
Cinnamon: 4.0.10
python3-pil: 5.1.0-1 (NOT upgraded manually via pip)

But Linux Mint does not AFAIK run a website instance of https://salsa.debian.org/webmaster-team/packages, so I cannot check.

http://packages.linuxmint.com/

Sure it should have been fixed. Unfortunately, it is entirely outside of our control, for the most part.

I thought Mint's repos would supersede Ubuntu's, so if the package was hosted with the required changes (a single line in this case) it would fix the issue for Mint users. Maybe I'm wrong, I'm not very experienced with this stuff.

---

I am not prepared to upgrade to 19.2, and if 19.1 is still supported I don't think that's a valid solution anyway.

For ease of others finding this info, as indicated elsewhere in this thread, this solved it for me:

In /usr/share/cinnamon/cinnamon-settings/bin/imtools.py, line 623, change:

if Image.VERSION == '1.1.7':

to:

if Image.__version__ == '1.1.7':

[eli-schwartz]

Since you both agree that, when running Linux Mint 19.1, your python3-pil version is 5.1.0, I do not see how you could possibly have this issue!

python3-pil 5.1.0 does not have this problem. The VERSION variable was only removed in 6.0.0 as the reporter of this issue specifically mentioned. See the code here:

https://github.com/python-pillow/Pillow/blob/5.1.0/src/PIL/Image.py#L27
which imports from
https://github.com/python-pillow/Pillow/blob/5.1.0/src/PIL/__init__.py#L16

So I will say once again: you should not have this problem unless you have used pip to upgrade Pillow to something more recent than provided by the distribution update channel.
If apt show python3-pil shows 5.1.0-1, then what does this show?

$ python
import PIL
print(PIL.__version__)

Because I really, really think that you somehow have a mismatched pillow installation.

...

While it would be nice if this could be fixed in a manner that safeguarded users on all supported versions of Mint, even when using a Pillow version from pip instead of apt, I really do not think it is fair to blame the distro for not supporting this use case.

[eli-schwartz]

@FistfulOfStars

http://packages.linuxmint.com/

Compare this to the software running on https://packages.debian.org and https://packages.ubuntu.com -- the Linux Mint version is a custom directory listing, basically, and only shows the versions of things that Linux Mint has modified -- not the full list of software available via apt, and not a UI that lets one toggle between OS releases to see which one has which version of the package.

python3-pil is not shown there.

[FistfulOfStars]

python
Python 2.7.15+ (default, Nov 27 2018, 23:36:35) 
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import PIL
>>> print(PIL.__version__)
5.1.0

Meanwhile, in python3:

python3
Python 3.6.8 (default, Jan 14 2019, 11:02:34) 
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import PIL
>>> print(PIL.__version__)
6.1.0

I don't know what to tell you though, I never upgraded anything manually via PIP. this came from the distro itself. I'm not 'blaming' anyone, I'm saying it's causing issue for Mint users.

[eli-schwartz]

What is PIL.__file__?

[FistfulOfStars]

~/.local/lib/python3.6/site-packages/PIL/__init__.py

[eli-schwartz]

That is definitely a pip-installed version. :) I would venture to say you have other software installed in ~/.local/lib/python3.6/site-packages/ which maybe caused pip to automatically install a new version of Pillow. It's therefore possible to have updated Pillow using pip, without having explicitly tried to update Pillow itself.

In any event, you have a few options:

• use a newer version of Linux Mint, which maybe even supports the new Pillow version via apt
• uninstall your local copies of python3 modules, and consider using virtualenv if you need to develop stuff with newer versions of Pillow
• locally patch your computer with the correct fix which is present in the latest version of cinnamon: https://github.com/linuxmint/cinnamon/pull/8496
• change if Image.VERSION == '1.1.7': to if False, because VERSION is not the same as __version__, and the latter will never be 1.1.7 anyway... but both versions of the function should work fine anyway.

[FistfulOfStars]

Thanks for the assistance. You are correct, I have many things installed in that directory. I assume it only makes sense the other 5 people experiencing this issue do as well. Perhaps we installed the same rogue code somewhere along the way.

Are the four options you provided preferable to my chosen solution of manually changing it to __version__ for some reason? Should I go a different route?

Edit: Form what you're saying it sounds like __version__ is the same result as setting it to just False, so I guess I'll leave it as-is until I upgrade to 19.2.

Thanks again for the info.

[eli-schwartz]

@AndrewDavis

Btw, is this feedback somehow getting relayed to Debian?

Debian has 2 bugs which are both marked as "severity: grave", for this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931777
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932578

It was first reported July 10, but I don't know what their status is on fixing this.

...

Meanwhile, this bug was first reported on April 4. Within 24 hours, I submitted a Pull Request to fix it, got Clem to merge it, and uploaded the fixed version of cinnamon to the Arch Linux package repositories.
I doubt I will ever understand how slow Debian-based distros are. ¯_(ツ)_/¯

But the feedback is there, so I guess we wait until someone with Debian maintainer privileges fixes things for the Debian sid/Ubuntu eoan users?

[eli-schwartz]

@FistfulOfStars options 1 and 2 involve making sure that apt agrees with python on what version of Pillow is available. I generally encourage making sure your package manager knows which version of the code you are using, because it is possible other programs you install via apt also need fixes/updates in order to run using the newer Pillow version. I can tell you as a distribution packager, cinnamon was not the only software that needed to be fixed to stop using PIL.VERSION.

Options 3 and 4 are essentially the same as switching to __version__, because it doesn't matter what you use to compare to the number 1.1.7, Pillow still isn't going to be 1.1.7 and the code is simply going to run into the "else" clause. Moreover, both the if and the else do basically the same thing, so I think any modification that makes the file run at all would be safe. But I'm biased in favor of using the officially approved fix which I submitted in #8496

[FistfulOfStars]

I appreciate the help you've provided.

I've tried learning a bit about development as a hobby just out of curiosity, and frankly the entire infrastructure really feels like a house of cards to me. There are so many moving parts and dependencies that you have no control over, it's a miracle anything works ever.

[smurphos]

Meanwhile, this bug was first reported on April 4. Within 24 hours, I submitted a Pull Request to fix it, got Clem to merge it, and uploaded the fixed version of cinnamon to the Arch Linux package repositories.
I doubt I will ever understand how slow Debian-based distros are. ¯_(ツ)_/¯

Your fix really ought to be candidate for a backport to Cinnamon 3.8 and 4.0. Numerous users on the Mint forums have reported this issue and applying your patch manually is what I've always advised.

Maybe @clefebvre will consider a backport?

[eli-schwartz]

Maybe! I did say above I think it would be a nice-to-have. It would prevent a potential footgun.

Maybe it would also finally be a candidate for Debian sid, which is still somehow stuck on cinnamon 3.8.8

[AndrewDavis]

@FistfulOfStars I'm a developer and that's exactly how most people do development nowadays, and it really pisses me off. But development itself is not the problem, people are; the venture itself is great. I tend to build things from scratch or use small powerful libraries that only do one thing, and I use languages like c++ or C# that give you well-defined understanding of exactly what your code is doing (usually). This Python version and package nonsense is like the epitome of everything wrong with development nowadays (don't ever bother with Node, if you can help it), even though Python itself is a pretty decent language.

Basically what's going on here is Cinnamon is letting itself be affected by software that's installed standardly by the user. That should never happen. It should be operating in its own, totally isolated environment, from start to finish.

[eli-schwartz]

@AndrewDavis I've seen too many people sudo make install some library into /usr/local/lib which clashes with system libraries. And of course in order for users to install their own software they typically need to go that route... or alternatively make install into some prefix in $HOME, which then gets added to LD_LIBRARY_PATH and still manages to break any C program.

Same applies for people breaking their shellscripts by installing some custom script called "install" into $HOME/bin/ (being able to add your own user programs to $PATH is important), and thereby breaking any shellscript that makes use of GNU coreutils "install".

"totally isolated environment", right.

[sarkaari]

most of these issues seem to be coming from Debian/Ubuntu users

I, and others using Linux Mint are experiencing the same issue.

Speaking for myself only:

LM 19.1 Tessa
Cinnamon: 4.0.10
python3-pil: 5.1.0-1 (NOT upgraded manually via pip)

But Linux Mint does not AFAIK run a website instance of https://salsa.debian.org/webmaster-team/packages, so I cannot check.

http://packages.linuxmint.com/

Sure it should have been fixed. Unfortunately, it is entirely outside of our control, for the most part.

I thought Mint's repos would supersede Ubuntu's, so if the package was hosted with the required changes (a single line in this case) it would fix the issue for Mint users. Maybe I'm wrong, I'm not very experienced with this stuff.

I am not prepared to upgrade to 19.2, and if 19.1 is still supported I don't think that's a valid solution anyway.

For ease of others finding this info, as indicated elsewhere in this thread, this solved it for me:

In /usr/share/cinnamon/cinnamon-settings/bin/imtools.py, line 623, change:

if Image.VERSION == '1.1.7':

to:

if Image.__version__ == '1.1.7':

Thanks a lot, this fixed my debian-testing installation.