Installed chromium breaks Qube Settings

[hyperfekt]

Qubes OS version:

R4.0rc4

Affected TemplateVMs:

fedora-26

---

Steps to reproduce the behavior:

1. install chromium via sudo dnf install chromium
2. shutdown the template
3. attempt to open Qube settings of the template either via Qube Manager or applications menu

Expected behavior:

Qube Settings dialog opens.

Actual behavior:

An error occurs:

CalledProcessError: Command '['qvm-appmenus', '--get-available', '--i-understand-format-is-unstable', '[VM-NAME]']' returned non-zero exit status 1
at line 9
of file /usr/bin/qubes-vm-setting.

Entering the erroring command in the console gives the following output:

Traceback (most recent call last):
  File "/usr/bin/qvm-appmenus", line 9, in <module>
    load_entry_point('qubesdesktop==4.0.11', 'console_scripts', 'qvm-appmenus')()
  File "/usr/lib/python3.5/site-packages/qubesappmenus/__init__.py", line 579, in main
    for available in appmenus.get_available(vm)))
  File "/usr/lib/python3.5/site-packages/qubesappmenus/__init__.py", line 578, in <genexpr>
    sys.stdout.write(''.join('{} - {}\n'.format(*available)
  File "/usr/lib/python3.5/site-packages/qubesappmenus/__init__.py", line 159, in get_available
    'template {!r} does not contain name'.format(filename)
AssertionError: template 'chromium-browser.desktop' does not contain name

General notes:

Removing chromium again will reenable the Qube Settings.

Related issues:

[hyperfekt]

I tried to pin this further down and got similar errors when cloning the fedora-26 template, only that they were about the preinstalled ones. This might be related to running out of space? Deleted some stuff and reinstalled chrome, worked fine this time.
Weirdly, in both cases the installation / the cloning appear to have completed successfully.

[hyperfekt]

I tried to pin this further down and got similar errors when cloning the fedora-26 template, only that they were about the preinstalled ones. This might be related to running out of space? Deleted some stuff and reinstalled chrome, worked fine this time.
Weirdly, in both cases the installation / the cloning appear to have completed successfully.

[andrewdavidwong]

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

[andrewdavidwong]

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

[hyperfekt]

I'm not sure this should be entirely ignored - does #1872 also apply to dom0?
Spewing unrelated errors when the disk is full (and no warning at all is given) is a highly dysfunctional UX.

[hyperfekt]

I'm not sure this should be entirely ignored - does #1872 also apply to dom0?
Spewing unrelated errors when the disk is full (and no warning at all is given) is a highly dysfunctional UX.

[andrewdavidwong]

I'm not sure this should be entirely ignored

It's certainly not being entirely ignored. You indicated that the problem had been resolved for you:

Deleted some stuff and reinstalled chrome, worked fine this time.

This suggests that the problem was either due to running out of disk space, as you indicated, or some unusual combination of factors.

does #1872 also apply to dom0?

Yes, the second thing described in #1872 applies to the entire primary physical system drive.

Spewing unrelated errors when the disk is full (and no warning at all is given) is a highly dysfunctional UX.

Agreed, but it sounds like this issue, if we were to reopen it for this reason, would be a duplicate of #1872. If you disagree, please update the title and description on this issue to clarify the distinct bug being reported.

[andrewdavidwong]

I'm not sure this should be entirely ignored

It's certainly not being entirely ignored. You indicated that the problem had been resolved for you:

Deleted some stuff and reinstalled chrome, worked fine this time.

This suggests that the problem was either due to running out of disk space, as you indicated, or some unusual combination of factors.

does #1872 also apply to dom0?

Yes, the second thing described in #1872 applies to the entire primary physical system drive.

Spewing unrelated errors when the disk is full (and no warning at all is given) is a highly dysfunctional UX.

Agreed, but it sounds like this issue, if we were to reopen it for this reason, would be a duplicate of #1872. If you disagree, please update the title and description on this issue to clarify the distinct bug being reported.