Page MenuHomeLubuntu Development

Drop or change pkexec patch in Calamares
Stalled, Waiting on Upstream, LowPublic


The pkexec patch for the calamares .desktop file appears to be unnecessary. We use a different .desktop file that is on the desktop and in the menu. Therefore 2 installer items appear in the menu. The question is, should we change the patch that exists, drop the patch altogether or something altogether different? I would like to sort this out so that I can package Calamares 3.2.12 for release into Eoan. @tsimonq2 what are your thoughts on this?

Event Timeline

kc2bez triaged this task as High priority.Aug 8 2019, 10:03 PM
kc2bez created this task.

After testing a bit, I think that pkexec does not work well with Calamares.


  1. Boot live-system
  2. Open terminal and execute pkexec calamares
  3. On the welcome screen, click on "Lubuntu support"

Instead of opening Firefox, you see these messages in the console:

16:43:00 [0]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /home/lubuntu/.Xauthority which is owned by lubuntu.)
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /home/lubuntu/.Xauthority which is owned by lubuntu.)
Running Firefox as root in a regular user's session is not supported.  ($XAUTHORITY is /home/lubuntu/.Xauthority which is owned by lubuntu.)
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: iceweasel: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: seamonkey: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: mozilla: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: epiphany: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: konqueror: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium-browser: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: google-chrome: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening ''

If you start Calamares from System Tools > Install System, then you have the same behaviour: Firefox does not start. (<= That is not a problem, because Firefox should never be run as root)

In my opinion, you can drop the patch, because it patches the "wrong" .desktop file. And I suggest to drop also the calamares.desktop file.

lubuntu-calamares.desktop should be the only desktop file, we provide. And there is a hacky workaround to run Firefox as lubuntu user.

It smells like a design flaw/bug in Calamares. In an ideal world, Calamares would be executed as lubuntu and only run the processes with elevated privileges when needed (e.g. when applying the partitioning scheme).

@wxl @Tj @teward @tsimonq2

So what you're suggesting is effectively splitting Calamares so it has a system process presumably exposing a DBus API for its client (user) process to call to do privileged operations ?

What you're suggesting is correct, @apt-ghetto. This should really be addressed upstream, but for now, we have our hacky workaround. :)

Opened upstream issue.

@Tj: Yes, your question is the more detailed version of my plan of attack.

@tsimonq2: As long as we don't have a better alternative, I won't remove the hacky workaround. It is a good workaround, but hacky, because it is hard to understand. I had more than half an hour to understand why we have and need it.

For this release I will change the patch so that NotShowIn=LXQt; is added to the stock .desktop that ships with Calamares leaving only our workaround visible in the menu and desktop. We can revisit it when there is an upstream change.

@wxl I am confused here. I added NotShowIn=LXQt; to the desktop file yet it still shows in the menu. I re-read the spec and still don't see where I went wrong. Any ideas?

I don't know this one off the top of my head, but you should see what environment variable the menu reads from to determine whether or not to show menu items. Probably in lxqt-panel.

I have a hunch it's expecting "Lubuntu", which would be cool...

No, that's not it. $XDG_CURRENT_DESKTOP is LXQt as it should be.

In T108#2111, @wxl wrote:

No, that's not it. $XDG_CURRENT_DESKTOP is LXQt as it should be.

Right, so it further adds to my confusion.

How are you ensuring the menu's cache is being updated?

It does it on a live iso, I wouldn't think there was any cache.
I also did try this on a different .desktop file and I tried a logout and login as well as a reboot. They all still show.

Strangely xdg-desktop-menu forceupdate isn't really behaving nice, but a log out and back in does the trick. I can change various attributes but that indeed seems to have no effect.

Interestingly, this seems to be the only Desktop Entry we have with that key, though we have lots with OnlyShowIn.

I've looked for bugs as far as upstream related to NotShowIn and I can't find anything. I've pinged #ubuntu-flavors to see if they have problems as well.

kc2bez lowered the priority of this task from High to Low.Oct 2 2019, 11:16 AM

I will bump this to 20.04. We are waiting on an upstream fix for this ultimately (2 of them actually, one for Cala to run firefox as the user and one for LXQt to respect proper .desktop menu items). I also lowered the priority it isn't a showstopper that we have two menu items just somewhat annoying.

kc2bez changed the task status from Open to Upstream.Jan 23 2020, 2:12 AM

The qml theming in upcoming versions may help with some of this. We can set a stylesheet that all users will get independent of chosen DE theme. Launching a web page as root is the only other sticking point after that. More experimentation needed, bouncing to 20.10.