Giocoso on [K]ubuntu

Back in April of this year, as I mentioned previously, I bought myself a new Minisforum UM250 small-form-factor PC. The experiment with using it with Arch and/or Manjaro proved less than successful -so I reverted back to my vintage 2012 PC and retired the UM250 back to its box, in which it has sat ever since, on one of the bookshelves in my study.

Around June of this year (I think), I happened to be laid up in bed (after one of my Covid-19 vaccine shots) and was thus using an old laptop for browsing the web. It was a 2016-vintage Dell of some bog-standard sort. But way-back-when, I had installed multiple operating systems on it, so I could boot into Windows 10, Ubuntu 18.x and Manjaro as and when I chose... and I happened to notice that the laptop's fan noise was considerably worse when booted into Manjaro than it was if I booted into Ubuntu. I can't remember if it was any worse or better in Windows, but it struck me at the time that in the presence of laptop-style hardware, Ubuntu seemed to have a better lid on thermal management than Manjaro did. I don't know if that's actually true or not -or, if it is, why that might be. But if made me think that if I had conducted my earlier Minisforum experiment with Ubuntu (or one of its derivative flavours) rather than with Arch or Manjaro, maybe it would have run more quietly too, and thus the outcome might have been happier all round.

This week, I put that chance observation-and-speculative-guess to the test. I wheeled out the Minisforum once more and installed Kubuntu 20.04 on it. Kubuntu, because I can't stand the Gnome desktop, but find the KDE one more than acceptable; Version 20.04 because it's a Long-Term Edition of that distro (meaning it's supported until 2024 at least).

The first thing I noticed was that it was considerably quieter in operation than I remembered it being on my initial installations with Arch and Manjaro. The second thing I noticed was that it was a hell of a lot more stable: my earlier blog post reported strange graphical glitches and lock-ups at ever-increasing frequencies, for example... but the Minisforum has been running Kubuntu for 4 days now and hasn't glitched or locked up once. So, on this occasion, the Minisforum seems to be a success and it's something I'm planning on transitioning to as my full-time desktop PC in the next couple of days. It's already doing most of the heavy lifting in that regard, anyway.

All the software packages I've used on the old PC have been readily available for the new Kubuntu distro, so I've not lacked anything there, either. But one little quirk popped up that annoyed me for a while: Giocoso had weird trouble displaying the name of the piece of music it was playing underneath the album art displayed for that piece. Here is an example:

That blank red rectangle underneath the album art picture itself is supposed to be displaying text that reveals the actual name of the composition being played... but clearly, it isn't. I couldn't think what was going wrong, really, because the exact same code worked perfectly on my Manjaro-running old PC. Even on Kubuntu, though, Giocoso wasn't having any problem persuading the ImageMagick program to display the album art itself.

Well, I couldn't think of a rational explanation for this behaviour, so I had to add some debug code into Giocoso to see what was going on at the point it was creating that red rectangle plus album name text... and I was thus able to spot the program encountering this error:

...and in case you can't read the error text from that screenshot too clearly, here it is in plain-vanilla text form:

convert-im6.q16: attempt to perform an operation not allowed by the security policy '...caption.txt' @ etc. etc. etc

So the 'convert' program (which is part of ImageMagick) is trying to do something with 'caption.txt' and being prevented from doing it by some sort of security policy or other. That certainly sounds like the root cause of my album title display problem -since the ALBUM tag data is first exported to a text file called .caption.txt, and from there is piped to ImageMagick to turn into a graphical rectangle.

So, I had to do a DuckDuckGo search for that error message, and the first result it found was this page of helpful advice. That confirmed something I'd sort-of guessed at: you see, I've encountered this sort of 'security policy prohibition on useful things' before (on Manjaro, even) when attempting to convert a bunch of JPGs into a PDF -and that's precisely what that linked site is describing. Having dealt with this myself before, I should probably have already known the solution, but alas my memory is not that infallible! Fortunately, that search-result article points out that it merely involves editing the contents of the /etc/imagemagic-6/policy.xml file.

Well... that's almost the answer! Unfortunately, on a fresh install of Ubuntu 20.04 (or its Kubuntu cousin), the actual folder involved is called /etc/ImageMagick-6 ...the extra capital letters are rather important for the business of successfully navigating your file system to reach the right place! Also note that a version 7 of ImageMagick has been out for quite some time, so the correct folder might have a "-7" at the end of its name rather than a "-6" if you're using a more up-to-date version.

Anyway, once the right folder had been found, and the right file (which is called policy.xml) has been opened in a text editor using sudo privileges (because you need root privileges to save modifications in the /etc folder), you'll see this set of lines:

 <!-- disable ghostscript format types --> 
 <policy domain="coder" rights="none" pattern="PS" /> 
 <policy domain="coder" rights="none" pattern="PS2" /> 
 <policy domain="coder" rights="none" pattern="PS3" /> 
 <policy domain="coder" rights="none" pattern="EPS" /> 
 <policy domain="coder" rights="none" pattern="PDF" /> 
 <policy domain="coder" rights="none" pattern="XPS" />

...and as that article I found on the search engine mentions, to be able to convert JPGs to PDFs, you need to edit the PDF line (second from the bottom) from rights 'none' to rights of 'read|write'. That's a good thing to be able to do anyway, so sure: whilst I was there, I turned that part of the script into this:

 <!-- disable ghostscript format types --> 
 <policy domain="coder" rights="none" pattern="PS" /> 
 <policy domain="coder" rights="none" pattern="PS2" /> 
 <policy domain="coder" rights="none" pattern="PS3" /> 
 <policy domain="coder" rights="none" pattern="EPS" /> 
 <policy domain="coder" rights="read|write" pattern="PDF" /> 
 <policy domain="coder" rights="none" pattern="XPS" />

...and I've bolded the affected line. That vertical line between the words 'read' and 'write' is simply the 'pipe character', by the way. It functionally means 'or', so the line now reads that users now have read or write privilges when using ImageMagick to convert anything to a PDF file.

Which, as I say, is a very handy thing to be able to do at any time, so making that edit was a bit of a non-brainer for me. Trouble is, that's not the security policy violation Giocoso is encountering! It's not trying to convert things to a PDF. It's trying to convert text to a graphic format... and there are no policy lines in the snippet I've shown you above which relate to doing that at all. So, nice edit to perform, anyway -but it doesn't fix Giocoso's album art display problem.

A couple of lines above this snippet, however, is this, which I simply guessed might be relevant:

 <!-- in order to avoid to get image with password text --> 
 <policy domain="path" rights="none" pattern="@*"/>

The comment above the functional line mentions something about 'getting an image with text', so that seemed a plausible line of interest. I therefore changed the text here to read:

 <!-- in order to avoid to get image with password text --> 
 <policy domain="path" rights="read|write" pattern="@*"/>

...with, again, the modified bit shown in bold.

Now I ran Giocoso once more, with this command:

...and this was the result:

Bingo! As you can see, the composition name is, once more, being displayed correctly, as the Giocoso-launching command requested, white-on-red.

So, the switchover to the Minisforum can continue, but the lesson to draw is that different distros implement ImageMagick security policies differently. Manjaro, like Ubuntu (and Kubuntu, which are basically the same for the purposes of this discussion) sets the 'cannot convert things to PDF' policy -but Manjaro does not prohibit converting text to an image (which is why I'd never encountered this particular problem on that distro). But Ubuntu does set this policy to 'prohibited' as well -so, out of the box, Giocoso is not allowed to convert the composition name to text to display as a caption beneath the album art. You therefore end up, by default, with a coloured bar under the album art without any text in it at all... which is about as much use as a chocolate tea-pot!

It's a failing in my testing Giocoso on multiple distros that I didn't notice this before, so I apologise for the oversight before now. Fundamentally, though, it's not a problem or bug in Giocoso that's causing this, but a distro-specific security configuration peculiarity. Fortunately, it's easily fixed, as I say, by relaxing the polices mentioned in /etc/Imagemagic-6/policy.xml (remembering to substitute in the correct version of the ImageMagick program name, which can be upper-or-lower cased as whim and fashion changes, and take a different version number too).

Anyway: that's a long way of saying that Giocoso can work properly on most Linux distros, but ImageMagick has its own peculiarities which might need sorting and tweaking before the ideal Giocoso output is achieved!

It's also a long-winded way of warning you that I'm almost certainly going to be switching to a new PC for day-to-day work and switching from Manjaro to Kubuntu at the same time. Any future developments that might come to Giocoso will, therefore, be first tested on Ubuntu-based distros, with Manjaro and Arch-based distros becoming rather more second-class citizens as a result.