Desktop file does not open ImageMagick from the menu

Bug #1550210 reported by Set Hallstrom on 2016-02-26
This bug affects 8 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
imagemagick (Debian)
Fix Released
imagemagick (Ubuntu)
Nish Aravamudan
ubuntustudio-default-settings (Ubuntu)

Bug Description

The ImageMagick launcher shipped in every Ubuntu "desktop" flavor does nothing when clicked.

Test Case
Install the update.
Then click ImageMagick in the Unity Dash.
Does the ImageMagick window open?

Regression Potential
Basically none. Without this minimal fix, imagemagick's .desktop launcher is unusable.

Original Bug Report
Starting ImageMagick from the whisker menu gives no reaction. Running the commands executed by those entries in a cli however does start ImageMagick

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubuntustudio-default-settings 0.56
ProcVersionSignature: Ubuntu 4.4.0-7.22-lowlatency 4.4.2
Uname: Linux 4.4.0-7-lowlatency x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CasperVersion: 1.367
CurrentDesktop: XFCE
Date: Fri Feb 26 08:53:55 2016
LiveMediaBuild: Ubuntu-Studio 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160224)
PackageArchitecture: all
 PATH=(custom, no user)
SourcePackage: ubuntustudio-default-settings
UpgradeStatus: No upgrade log present (probably fresh install)

Set Hallstrom (sakrecoer) wrote :
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Ross Gammon (rosco2) wrote :

This is a problem with the desktop file in imagemagick.
Setting "Terminal=" to true instead of false fixes it.

Expect a patch to fix it soon.

affects: ubuntustudio-default-settings (Ubuntu) → imagemagick (Ubuntu)
Changed in imagemagick (Ubuntu):
assignee: nobody → Ross Gammon (retail-0)
status: New → Confirmed
Changed in imagemagick (Debian):
status: Unknown → New
Changed in imagemagick (Ubuntu):
importance: Undecided → High
Changed in hundredpapercuts:
status: New → Confirmed
importance: Undecided → High
Ross Gammon (rosco2) wrote :

Sorry it has taken so long. This is the 2nd time I have had to rebase my patch after a separate update to imagemagick occurred before I had finished testing.

You can test the fix by installing from the Ubuntu Studio Test ppa:
Only the changelog is different compared to the debdiff I am about to attach.

The attached debdiff sets the desktop file to "teminal=true" so that the menu correctly executes the command from a terminal.

The debdiff also disables the second desktop file (which only links to the same binary as the other desktop file). This fixes #1549732.

Ross Gammon (rosco2) wrote :

Attaching debdiff

Tim Lunn (darkxst) wrote :

Hi Ross, thanks for the patch.

Both desktop files are provided by the debian packaging, so just commenting out one of them in the .install file is not the best thing to do. Using the default build both binaries are built with Quantum 16. However in a custom build you could set QUANTAMDEPTH= Q32 and the binaries will differ, so this probably needs to be handled with a bit of extra logic in the debian/rules files.

Not sure why its setup like that, obviously all archive builds will end up with not just duplicate desktop files, but also (essentially) duplicate binary packages. I would suggest you follow this up with the debian maintainers.

Ross Gammon (rosco2) wrote :

Hi Tim,

Yes, debian/rules is quite messy. Actually, I think only one binary is built and the second is a link to the first.

I can see that the version of imagemagick in Debian experimental is supposed to contain a fix for the desktop situation, but I couldn't take anything from that version due to all the other changes in debian/rules. I therefore figured the best thing was to comment the second desktop file out, because eventually the fix will come from Debian and we can just drop the delta. But I could delete the line instead if you prefer. There is no point having a 2nd desktop file installed that has no icon, and only executes the same binary as the other desktop file. This just confuses the users.

I will submit a bug about the duplicate binary packages and building with a different Quantum depth. There are already lots of other related bugs, but not that one specifically.

Ross Gammon (rosco2) wrote :

Bug about binaries being the same (alternatives not really alternatives):

Tim Lunn (darkxst) wrote :

Can you cherrypick the desktop fix from the debian packaging git branch?

On 03/12/2016 09:07 AM, Tim wrote:
> Can you cherrypick the desktop fix from the debian packaging git branch?

Which one? :-) They do not use the standard git branch layout
master/pristine-tar/upstream. There are so many branches that I couldn't
work out where the branches were for the current releases. And the
debian/rules changes in the experimental version are significant, mostly
unrelated to this particular fix, and made it hard to cherry-pick
without bringing across unwanted changes.

In any case, the desktop issue is not properly fixed in Debian
experimental from what I can see. We would still need to patch the
desktop file to set "Terminal=true" anyway.

I think we have a simple fix for the issue here, and once we open up for
the next cycle, we can confirm that the mess is sorted out in Debian,
and start syncing again?

OK. I had some time today to work out the branch structure being used for imagemagick on alioth in Debian. It appears that the version of imagemagick in Debian Experimental fixes the duplicated desktop issue by making imagemagick-6.q16 a virtual package for the default quantum depth & imagemagick with the appropriate Replaces/Breaks & Provides etc. Therefore, both packages are not installed at the same time. This is all a bit much to bring over to Ubuntu at this stage.

So, I have suggested a fix in ubuntustudio-menu to remove the duplication for Ubuntu Studio.

That just leaves the issue that clicking on the remaining menu item does nothing. So I have reduced my patch down to just fixing this issue by setting Terminal=true in the desktop file.

I hope someone can help by uploading this before the Xenial release, because having a menu item that does not work is very frustrating for users. And there is a really simple fix.

Mathew Hodson (mhodson) on 2016-03-25
summary: - ImageMagick Entries not working in whiskers
+ Desktop file does not open ImageMagick from the menu
Mathew Hodson (mhodson) on 2016-04-08
Changed in imagemagick (Ubuntu):
importance: High → Medium
Changed in hundredpapercuts:
importance: High → Medium
Mathew Hodson (mhodson) on 2016-05-20
Changed in imagemagick (Ubuntu):
status: Confirmed → Triaged
tags: added: patch
Mathew Hodson (mhodson) on 2016-06-23
tags: added: bitesize desktop-file
Jb (jebsolutions) wrote :

This bug still exists in Lubuntu 16.10 daily image dated 2016-Aug-14.

Paul White (paulw2u) on 2016-08-15
tags: added: yakkety
Jeremy Bicha (jbicha) wrote :

We "fixed" this in Ubuntu GNOME years ago by hiding the imagemagick app launchers by default. We need the command line imagemagick, but we don't need the gui frontend. It would be nice if it was split off to a separate package so those that want it can install it.

fossfreedom (fossfreedom) wrote :

Hi Jeremy - please can you expand slightly - how did you hide the imagemagick app launchers? Via your ISO build mechanism by deleting the .desktop files?

Jeremy Bicha (jbicha) wrote :

David, Ubuntu GNOME hides app launchers by creating .desktops in /usr/share/gnome/applications/ with NoDisplay=true

For Budgie, I'd want to know what the output of $XDG_DATA_DIRS is. In GNOME (on X; I'm missing some environment variables in Wayland), it's


According to the final section of the below specification, .desktops with the same name that come first should be used so that's why /usr/share/gnome/applications/ overrides /usr/share/applications/

fossfreedom (fossfreedom) wrote :

Jeremy - much appreciated!!

same trick works on budgie-desktop created the NoDisplay=true containing .desktop files in /usr/share/budgie-desktop/applications and all is well


Ross Gammon (rosco2) wrote :

Thanks for the tip Jeremy.

I am now attaching a patch to ubuntustudio-default-settings that drops a desktop file into /usr/share/ubuntustudio/applications with Terminal=true so that imagemagick runs from the menu at least in Ubuntu Studio.

Ross Gammon (rosco2) on 2016-10-13
Changed in imagemagick (Ubuntu):
assignee: Ross Gammon (rosco2) → nobody
Changed in ubuntustudio-default-settings (Ubuntu):
status: New → Confirmed
Changed in ubuntustudio-default-settings (Ubuntu):
importance: Undecided → Medium
Changed in imagemagick (Debian):
status: New → Confirmed
Changed in imagemagick (Debian):
status: Confirmed → Fix Released
Simon Quigley (tsimonq2) wrote :

This should be fixed in imagemagick once it comes through zesty-proposed, it's currently uninstallable at the moment:

Ross Gammon (rosco2) on 2017-02-04
Changed in ubuntustudio-default-settings (Ubuntu):
assignee: nobody → Ross Gammon (rosco2)
Nish Aravamudan (nacc) wrote :

FYI, imagemagick is installable again, but stuck right now because of emacs25. Hopefully we'll get it sorted next week.

Nish Aravamudan (nacc) wrote :

It looks like, though, it was not fixed until imagemagick/8: in Debian and we're currently merged to 8: Given how long we've been waiting to get even that version though, let me check on how things look next week and see if we can just re-merge to updated release from Debian before Feature Freeze. Thanks!

Changed in imagemagick (Ubuntu):
assignee: nobody → Nish Aravamudan (nacc)
Ross Gammon (rosco2) wrote :

I attach a debdiff for ubuntustudio-default-settings which I need sponsorship for. It also fixes #1630347. We would like to get this into Zesty before the final Beta.

Ross Gammon (rosco2) on 2017-02-21
Changed in ubuntustudio-default-settings (Ubuntu):
assignee: Ross Gammon (rosco2) → nobody
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntustudio-default-settings - 0.64

ubuntustudio-default-settings (0.64) zesty; urgency=medium

  * Temporarily override the desktop file for imagemagick
    with Terminal set to true (LP: #1550210)
  * Move configuration from ubuntustudio-lightdm-theme (LP: #1630347)
    Prvide a dummy transitional ubuntustudio-lightdm-theme package
    which can be removed after next LTS release (18.04).

 -- Ross Gammon <email address hidden> Sun, 26 Feb 2017 12:32:33 +0100

Changed in ubuntustudio-default-settings (Ubuntu):
status: Confirmed → Fix Released
Jeremy Bicha (jbicha) on 2017-03-19
Changed in imagemagick (Ubuntu Xenial):
status: New → Triaged
importance: Undecided → Medium
Changed in imagemagick (Ubuntu Yakkety):
status: New → Triaged
importance: Undecided → Medium
no longer affects: ubuntustudio-default-settings (Ubuntu Xenial)
no longer affects: ubuntustudio-default-settings (Ubuntu Yakkety)
Jeremy Bicha (jbicha) on 2017-03-19
description: updated
Changed in imagemagick (Debian):
status: Fix Released → Confirmed
Mathew Hodson (mhodson) on 2017-03-25
Changed in imagemagick (Debian):
status: Confirmed → Unknown
Changed in imagemagick (Debian):
status: Unknown → Confirmed
Robie Basak (racb) wrote :

I see tasks open and SRU information filled out, but it isn't clear to me if any of the patches attached are still current and being proposed for upload. Please could you clarify? Once you have something ready, please re-subscribe ~ubuntu-sponsors. Thanks!

Ross Gammon (rosco2) wrote :

Hi Robie,

We have now added a desktop file to ubuntustudio-default-settings, so that the issue is no longer a problem for Ubuntu Studio. SO the us-default-settings patches can be ignored. I don't see the problem as important enough to SRU to current releases (as most people use imagemagick from the command line). But it can be frustrating for users to click on a menu item and see that nothing happens in other flavours.

The other imagemagick patches would fix the problem for all flavours, but they are stale now and would need to be rebased on top of the latest released versions. If there was a wish for it, I could do it, but it would have to wait a while as I am quite busy these days. Maybe this was Nish's plan anyway?

The correct thing to do would be to get the right fix upstream in Debian (or even imagemagick). Apparently, the claimed fix in Debian didn't work. I hadn't had time to look into it, but I believe Jeremy did this in the Debian bug recently.

Jeremy Bicha (jbicha) wrote :

I was mistaken; the Debian fix (which is also now in 17.04) works. Someone just needs to prepare the SRUs. This is the Debian fix:

Changed in imagemagick (Ubuntu):
status: Triaged → Fix Released
Changed in imagemagick (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.