Fedora 23: gnome-terminal.desktop doesn't exist

[qjoo]

When starting a gnome-terminal on fc23 I get:

qubes-core-vm-3.0.20-1.fc23

xdg.py:8:launch:TypeError: constructor returned NULL

Traceback (most recent call last):
  File "/usr/bin/qubes-desktop-run", line 7, in <module>
    launch(*sys.argv[1:])
  File "/usr/lib64/python2.7/site-packages/qubes/xdg.py", line 8, in launch
    launcher = Gio.DesktopAppInfo.new_from_filename(desktop)
TypeError: constructor returned NULL

Local variables in innermost frame:
files: ()
desktop: '/usr/share/applications/gnome-terminal.desktop'

[marmarek]

Does /usr/share/applications/gnome-terminal.desktop exist at all (in
the VM)? Maybe it was renamed to something like org.gnome.terminal or
so (haven't fc23 system handy).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Does /usr/share/applications/gnome-terminal.desktop exist at all (in
the VM)? Maybe it was renamed to something like org.gnome.terminal or
so (haven't fc23 system handy).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[qjoo]

You are right, it doesn't exist, sorry for the noise. (btw: wondering why I didn't get this reply via email)

[qjoo]

You are right, it doesn't exist, sorry for the noise. (btw: wondering why I didn't get this reply via email)

[mattmccutchen]

Workaround: Run the following in dom0 (assuming all VMs are on Fedora 23 or newer, otherwise feel free to write and share a script to process only VMs based on one template):

sed -i -e 's,gnome-terminal\.desktop,org.gnome.Terminal.desktop,' /var/lib/qubes/*/*/*whitelisted-appmenus.list

And then:

#!/usr/bin/python2
from qubes.qubes import QubesVmCollection, QubesAdminVm
c = QubesVmCollection()
c.lock_db_for_reading()
c.load()
for vm in c.values():
  if not isinstance(vm, QubesAdminVm):
    vm.appmenus_recreate()
c.unlock_db()

[mattmccutchen]

Workaround: Run the following in dom0 (assuming all VMs are on Fedora 23 or newer, otherwise feel free to write and share a script to process only VMs based on one template):

sed -i -e 's,gnome-terminal\.desktop,org.gnome.Terminal.desktop,' /var/lib/qubes/*/*/*whitelisted-appmenus.list

And then:

#!/usr/bin/python2
from qubes.qubes import QubesVmCollection, QubesAdminVm
c = QubesVmCollection()
c.lock_db_for_reading()
c.load()
for vm in c.values():
  if not isinstance(vm, QubesAdminVm):
    vm.appmenus_recreate()
c.unlock_db()

[marmarek]

qvm-sync-appmenus should also recreate them at the end.

[marmarek]

qvm-sync-appmenus should also recreate them at the end.

[andrewdavidwong]

qvm-sync-appmenus solved the issue for me. I had no need for any other workarounds.

[andrewdavidwong]

qvm-sync-appmenus solved the issue for me. I had no need for any other workarounds.

[mattmccutchen]

@axon-qubes: I believe I ran qvm-sync-appmenus and it did not help. Do you have a theory for how it worked for you? AIUI, as long as the *whitelisted-appmenus.list files refer to gnome-terminal.desktop, which does not exist in the VMs, no amount of qvm-sync-appmenus will solve the problem.

[mattmccutchen]

@axon-qubes: I believe I ran qvm-sync-appmenus and it did not help. Do you have a theory for how it worked for you? AIUI, as long as the *whitelisted-appmenus.list files refer to gnome-terminal.desktop, which does not exist in the VMs, no amount of qvm-sync-appmenus will solve the problem.

[andrewdavidwong]

@mattmccutchen: Sorry, I have no idea. All I did was upgrade the template according to the documented instructions, reboot it, and run qvm-sync-appmenus in dom0. Then I had to readd the Terminal entry using Add/remove shortcuts for each VM based on the new template.

[andrewdavidwong]

@mattmccutchen: Sorry, I have no idea. All I did was upgrade the template according to the documented instructions, reboot it, and run qvm-sync-appmenus in dom0. Then I had to readd the Terminal entry using Add/remove shortcuts for each VM based on the new template.

[mattmccutchen]

@axon-qubes: You didn't mention the "Add/remove shortcuts" part before. With that step, I'm willing to believe your procedure works, except I'm not sure it updates the default shortcuts for new VMs in /var/lib/qubes/vm-templates/*/{vm,netvm}-whitelisted-appmenus.list. My sed command covers those files and saves me doing "Add/remove shortcuts" manually for 14 VMs. It's plausible to me that the sed command followed by qvm-sync-appmenus would work (though I don't want to spend time retesting it now); if so, I think that's what we should recommend.

[mattmccutchen]

@axon-qubes: You didn't mention the "Add/remove shortcuts" part before. With that step, I'm willing to believe your procedure works, except I'm not sure it updates the default shortcuts for new VMs in /var/lib/qubes/vm-templates/*/{vm,netvm}-whitelisted-appmenus.list. My sed command covers those files and saves me doing "Add/remove shortcuts" manually for 14 VMs. It's plausible to me that the sed command followed by qvm-sync-appmenus would work (though I don't want to spend time retesting it now); if so, I think that's what we should recommend.

[marmarek]

Follow up from QubesOS/qubes-doc#60:

What would trigger the replacement?

It would be a separate point in upgrade instruction.

Would two entries appear in the Applications tab in Qubes Manager?

I think no - it only displays entries which have the underlying files (and when you save, only those entries are stored in whitelisted-appmenus.list).

Could org.gnome.Terminal.desktop get removed from a Fedora 21 VM (either by the user removing a broken entry or automatically when an unrelated change is made), and then be missing when the VM is upgraded to Fedora 23?

I think this is exactly what currently is happening. Ough, only on R3.1 - QubesOS/qubes-issues#1411

The better solution might be to have qvm-sync-appmenus update the *whitelisted-appmenus.list files for a VM to match the desktop file present in the VM.

Theoretically yes, but there is no generic way to know that gnome-terminal.desktop is renamed to org.gnome.Terminal.desktop. Or maybe there is?

[marmarek]

Follow up from QubesOS/qubes-doc#60:

What would trigger the replacement?

It would be a separate point in upgrade instruction.

Would two entries appear in the Applications tab in Qubes Manager?

I think no - it only displays entries which have the underlying files (and when you save, only those entries are stored in whitelisted-appmenus.list).

Could org.gnome.Terminal.desktop get removed from a Fedora 21 VM (either by the user removing a broken entry or automatically when an unrelated change is made), and then be missing when the VM is upgraded to Fedora 23?

I think this is exactly what currently is happening. Ough, only on R3.1 - QubesOS/qubes-issues#1411

The better solution might be to have qvm-sync-appmenus update the *whitelisted-appmenus.list files for a VM to match the desktop file present in the VM.

Theoretically yes, but there is no generic way to know that gnome-terminal.desktop is renamed to org.gnome.Terminal.desktop. Or maybe there is?

[mattmccutchen]

Theoretically yes, but there is no generic way to know that gnome-terminal.desktop is renamed to org.gnome.Terminal.desktop. Or maybe there is?

I was proposing to hard-code that pair and any future renames that affect the default whitelisted-appmenus.list entries of the official Qubes templates. (We could have a directory where third parties could add config files for other renames.) If whitelisted-appmenus.list contains gnome-terminal.desktop, but we see that the VM contains org.gnome.Terminal.desktop and not gnome-terminal.desktop, I don't see how we could be wrong to make the edit. Was that your question?

[mattmccutchen]

Theoretically yes, but there is no generic way to know that gnome-terminal.desktop is renamed to org.gnome.Terminal.desktop. Or maybe there is?

I was proposing to hard-code that pair and any future renames that affect the default whitelisted-appmenus.list entries of the official Qubes templates. (We could have a directory where third parties could add config files for other renames.) If whitelisted-appmenus.list contains gnome-terminal.desktop, but we see that the VM contains org.gnome.Terminal.desktop and not gnome-terminal.desktop, I don't see how we could be wrong to make the edit. Was that your question?

[marmarek]

whitelisted-appmenus.list is managed solely by dom0, VM have no influence over it. So that list need to be in dom0 (or somehow transferred to dom0). I think the better option would be to provide some script as part of upgrade instruction, not something integrated into qvm-sync-appmenus (or other generic tool). Especially when alternative exists - installing new template version (*).

(*) Yes, not yet available, building new one with #1490 fixed now...

[marmarek]

whitelisted-appmenus.list is managed solely by dom0, VM have no influence over it. So that list need to be in dom0 (or somehow transferred to dom0). I think the better option would be to provide some script as part of upgrade instruction, not something integrated into qvm-sync-appmenus (or other generic tool). Especially when alternative exists - installing new template version (*).

(*) Yes, not yet available, building new one with #1490 fixed now...

[mattmccutchen]

I think the better option would be to provide some script as part of upgrade instruction

As you prefer. I drafted one in QubesOS/qubes-core-admin-linux#4. Perhaps it should call qvm-sync-appmenus afterwards? You understand better than I do how this works.

[mattmccutchen]

I think the better option would be to provide some script as part of upgrade instruction

As you prefer. I drafted one in QubesOS/qubes-core-admin-linux#4. Perhaps it should call qvm-sync-appmenus afterwards? You understand better than I do how this works.

[unman]

@andrewdavidwong I believe this issue is resolved in 3.2, and can be closed, since there's now a tool to help with issues such as this. (Cf #1634)

[unman]

@andrewdavidwong I believe this issue is resolved in 3.2, and can be closed, since there's now a tool to help with issues such as this. (Cf #1634)