Desktop file does not open ImageMagick from the menu

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

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1550210

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.

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:
https://launchpad.net/~ubuntustudio-dev/+archive/ubuntu/dev-testing
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.

Attaching debdiff

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.

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.

Bug about binaries being the same (alternatives not really alternatives):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817842

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.

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

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.

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?

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

https://bazaar.launchpad.net/~ubuntu-gnome-dev/ubuntu-gnome-default-settings/ubuntu/files/head:/usr/share/gnome/applications/

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

/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

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/

https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#desktop-file-id

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

:)

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.

This should be fixed in imagemagick once it comes through zesty-proposed, it's currently uninstallable at the moment: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt

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

It looks like, though, it was not fixed until imagemagick/8:6.9.7.4+dfsg-1 in Debian and we're currently merged to 8:6.9.7.0+dfsg-2. 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!

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.

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

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!

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.

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:

https://anonscm.debian.org/git/collab-maint/imagemagick.git/commit/?h=debian/6.9.7.4%2bdfsg-2&id=f9b7075

Further to comment #25:
xenial and yakkety are no longer supported so closing.