DisplayCAL and Fedora 32

Does anybody know if there is a way (Appimage somewhere out it the wild, private repo, something…) to have DisplayCAL working in Fedora 32?

In one of my PCs I have a Fedora which I’ve lately upgraded to 32 from 31 and I had to remove DisplayCAL in order to have the upgrade going through. Then I wanted to try and install it again…
On DisplayCAL website there is no download available for Fedora 32, only for 31. Well, that one doesn’t install on 32, apparently because it still depends on Python2.

 Problem: conflicting requests
  - nothing provides wxPython >= 2.8.11 needed by DisplayCAL-
  - nothing provides python2-gobject needed by DisplayCAL-
(try to add '--skip-broken' to skip uninstallable packages)

I don’t know if this is the best place to ask, but I looked around a bit, including DisplayCAL forum and so, but I couldn’t find much. Maybe somebody has already dealt with this.
I guess this is also the case with Ubuntu 20.04, but I have no PC with it, yet.
Or let’s… If I finally decide also to upgrade my 18.04 to 20.04, will I have to give up on DIsplayCAL?

I’m currently running Mint 20 (Based on Ubuntu 20.04). I’m, sure I had to install python2 to get Displaycal to work, since Ubuntu 20.04 doesn’t ship with Python 2 installed. This worked for me on Mint 20, perhaps the equivelant command on Fedora 32 would work?

$ sudo apt install python-minimal

FYI: no problems with DisplayCAL on Xubuntu 18.04.
An alternative could be to use argyll from the command line, that’s what DisplayCAL is based on.

yeah, I know about *buntu 18.04, my main machine is Ubuntu 18.04 (not upgraded yet mostly for stuff like this and the uncertainty they bring along).

yeah, I couldn’t find a way to have it working on Fedora 32 yet… it seems some packages and some bins for python2 are not exactly the same…
E.g. I have ‘pygobject2’ installed, which probably is not good for DisplayCAL that looks for ‘python2-gobject’ (in Fedora 32 there is only ‘python3-gobjet’). Similar story for wxPython (actually there doesn’t seem to be any of that for Python 2…).

Hence I finally resolved to ask here if anybody had direct experience about it…

Ok, there seem to be a topic in the DisplayCAL forum.

It involved installing from python2 pip manually and then using sources…

mmm that would involve a bit of extra effort to maintain consistency further on…

Perfect usecase for a flatpak!

1 Like

Is there one already around?
That’d be perfect…

Nope, but it isn’t too hard to package.

you didn’t need to open a new bug. you just want to follow https://hub.displaycal.net/issue/17813/

or see all the threads about gimp and python3, as this is basically the same problem.

No bug opened.

And yeah, I came across that thread. So, for now it’s just waiting, apparently…

I can use a live distro to calibrate screens on that machine, for now. I hope it gets better soon.

And yeah, I’m well aware of all this Python 2 deprecation thing. It’s not the gratest time to be a FOSS user right now… but I guess it’ll just be a matter of some patience.
I can live with some older distros for a little longer I guess.

I figured out a workaround for the time being.

On Fedora, there’s a command called toolbox, provided by the toolbox package. It’s a wrapper around podman, which is a drop-in replacement for docker, but doesn’t require a system process always running all the time (a “daemon” process). It also lets you run containers as a user, instead of making root mandatory. It has a bunch of other nice and wonderful features too. But anyway…

First, ensure you have toolbox with a dnf install -y toolbox

Then, you can create a toolbox for Fedora 31, which lets you run Fedora 31 inside of Fedora 32. Toolbox + Podman is basically almost magic. And from the Fedora 31 container, you can run DisplayCal.

Here’s how to do it (run the following commands in a terminal, as a user):

  1. toolbox create -c displaycal -r 31
  2. toolbox run -c displaycal sudo dnf install -y libXScrnSaver https://displaycal.net/download/Fedora_31/x86_64/DisplayCAL.rpm
  3. toolbox run -c displaycal displaycal
  4. When DisplayCal starts, it should show a popup telling you that updates are available. Click “Cancel”, as updating won’t work with this method. (There’s probably no harm in choosing “Update” anyway.)
  5. Select the File menu, choose “Locate ArgyllCMS executables…”
  6. A different update dialog will appear. Click “OK”.

This creates the Fedora 31 container, downloads and installs DisplayCal and its dependencies, and runs displaycal, all from the container. DisplayCal will download precompiled executables and run them from your normal filesystem in the container to provide additional support. (At no point do you need to become root or use sudo. Except in the container, but that’s running as your user, so it’s not really doing that. It’s container magic.)

To run DisplayCal again, enter this at the command line:
toolbox run -c displaycal displaycal

You can run any of the other displaycal commands this way. For example:
toolbox run -c displaycal displaycal-apply-profiles --help

(The first displaycal, directly after -c is your toolbox container’s name.)

You can also enter the container and it’s just like the command line on your own machine, but in the Fedora 31 container installation:
toolbox enter -c displaycal

It detects my monitor (although I had to manually select it from the dropdown) and my calibration device. As I write this I’m using the Fedora 31 DisplayCal in the Fedora 31 toolbox container on my Fedora 32 laptop to profile my display.

Let’s see how well this works when it’s finished… I hope you all have success!

Meanwhile: I wish the developer would just port to Python 3.

Rant: Python 3 has been out since 2008. Python 2 has been deprecated since 2014 and it was put out of commission last year. There’s been over a decade to port software over and six years of a “last minute” chance to port stuff. Distributions have (rightfully) been removing Python 2 since the beginning of this year. (As Python 2 is unsupported as of 2020.)


Thanks a lot for your suggestion.
It needs a bit more than a minute, but I think I’ll try it, it seems not too much cryptic.

And yeah, I do understand your rant… but also I’d like to sympathize somewhat with developers, given the fact that moving from Python 2 to 3 is not really a porting… it’s quite more, especially if you software is quite complex and depending one many libs, which are themselves not “ported” to 3… (at work we had a sort of server for meas instruments written for Python 2; it’s basically a real huge lot of work to “port” it, so we basically have it running in an outdated VM, while we develop a whole new thing, so, if we were to maintain this software for any public, we’d be effectively discontinuing the software altogether…).

1 Like

On the same topic, just out of curiosity, does anydoy know how the situation is in Ubuntu 20.04, with respect to DiplayCAL, of course?
On the website there’s no official package for 20.04, yet.

Does anybody know if the package for 19.10 (or others) are working, or some more complex workaround are needed?

I’d like to sort all this things out before upgrading 18.04… (I’m so tempted to drop Ubuntu altogether after 12+ years, though…)

I think the version vor 19.10 works on 20.04

You should not do this. You’ll likely end up with missing dependencies.

1 Like

You mean, I should not use the Ubuntu 19.10 official DisplayCAL package on 20.04, right?

This also solves, for now, the doubt about upgrading the OS… (also because I guess other software I didn’t check yet will stop working… it’s was a long time I though Ubuntu was matured enough and safe to upgrade… I fell like it’s quite a step back for this distro)


1 Like