Bug 1122537
Summary: | build: Warn that manual intervention is required for gsettings schema install | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | jean-christophe manciot <actionmystique> |
Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | berrange, crobinso, gscrivan, rbalakri |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-04-06 20:04:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jean-christophe manciot
2014-07-23 12:58:12 UTC
It seems to be a Path issue: I have found "org.virt-manager.virt-manager.gschema.xml" inside /usr/local/share/glib-2.0/schemas"; I suppose they are searched inside "/usr/share/glib-2.0/schemas". There must a link with the bug in 6. in previous comment. Same bug here: https://www.redhat.com/archives/virt-tools-list/2013-July/msg00056.html Yes, as mentioned in my mail in that thread, there's two issues: - python setup.py install isn't running glib-compile-schemas where it is dumping our schema. - gsettings likely doesn't know to look in /usr/local/share for schemas. I don't want to go down the route of making this automatically work, since virt-manager would have to mess with GSETTINGS_SCHEMA_DIR. However we can at least make the build system warn about what manual steps are likely required. Could you elaborate on the manual intervention required for gsettings? As I said before, I thing there's an issue with the global path setting somewhere: /usr/share is used instead of /usr/local/share. Here's why: I've compiled the schemas with: root@VBox-Ubuntu-14:/usr/local/share/glib-2.0/schemas# glib-compile-schemas /usr/local/share/glib-2.0/schemas The "gschemas.compiled" has been coorectly created in the same directory. Please note that this file looks identical to the "virt-manager-1.0.1/data/gschemas.compiled" Then: virt-manager-1.0.1/# export GSETTINGS_SCHEMA_DIR=/usr/local/share/glib-2.0/schemas Then: virt-manager-1.0.1/# virt-manager --debug[sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (cli:187) Launched with command line: /usr/local/share/virt-manager/virt-manager --debug [sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (virt-manager:150) virt-manager version: 1.0.1 [sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (virt-manager:151) virtManager import: <module 'virtManager' from '/usr/local/share/virt-manager/virtManager/__init__.pyc'> [sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (virt-manager:209) GTK version: 3.10.8 [sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (engine:484) libguestfs inspection support: False [sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (systray:152) Showing systray: False [sam., 26 juil. 2014 14:53:41 virt-manager 17818] DEBUG (cli:182) Uncaught exception: Traceback (most recent call last): File "/usr/local/share/virt-manager/virtManager/engine.py", line 132, in _activate self.show_manager() File "/usr/local/share/virt-manager/virtManager/engine.py", line 924, in show_manager self._do_show_manager(None) File "/usr/local/share/virt-manager/virtManager/engine.py", line 868, in _do_show_manager manager = self.get_manager() File "/usr/local/share/virt-manager/virtManager/engine.py", line 829, in get_manager obj = vmmManager() File "/usr/local/share/virt-manager/virtManager/manager.py", line 117, in __init__ vmmGObjectUI.__init__(self, "manager.ui", "vmm-manager") File "/usr/local/share/virt-manager/virtManager/baseclass.py", line 203, in __init__ self.builder.add_from_string(file(uifile).read()) IOError: [Errno 2] No such file or directory: '/usr/share/virt-manager/ui/manager.ui' Traceback (most recent call last): File "/usr/local/share/virt-manager/virtManager/engine.py", line 132, in _activate self.show_manager() File "/usr/local/share/virt-manager/virtManager/engine.py", line 924, in show_manager self._do_show_manager(None) File "/usr/local/share/virt-manager/virtManager/engine.py", line 868, in _do_show_manager manager = self.get_manager() File "/usr/local/share/virt-manager/virtManager/engine.py", line 829, in get_manager obj = vmmManager() File "/usr/local/share/virt-manager/virtManager/manager.py", line 117, in __init__ vmmGObjectUI.__init__(self, "manager.ui", "vmm-manager") File "/usr/local/share/virt-manager/virtManager/baseclass.py", line 203, in __init__ self.builder.add_from_string(file(uifile).read()) IOError: [Errno 2] No such file or directory: '/usr/share/virt-manager/ui/manager.ui' Have you noticed the "No such file or directory: '/usr/share/virt-manager/ui/manager.ui'" errors? This file exists in the folder... /usr/local/share/virt-manager/ui/ The manual intervention I meant was glib-schemas-compile and usage of GSETTINGS_SCHEMA_DIR to point to /usr/local The UI path issue I haven't seen specifically, perhaps we are hardcoding /usr/share somewhere, instead of using whatever the configured prefix is. FWIW, I think it would be worth setting GSETTINGS_SCHEMA_DIR automatically in virt-manager. I had this same problem with Entangle and even though I clearly tell people what to do in summary printed by configure, there was still a never ending stream of bug reports. The code to set it isn't that difficult https://gitorious.org/entangle/entangle/source/939ff0f16ee568287221da47376a679f147cb8cc:src/backend/entangle-preferences.c#L793 @ Daniel Berrange: I have already tried to set GSETTINGS_SCHEMA_DIR. Other symptoms have been exposed afterwards which seem to indicate that there's a core issue with some basic path somewhere. It seems that some parts of the code use /usr/share while some other parts use /usr/local/share. For example, when we install virt-manager with "python setup.py install", - virt-manager tree is installed under /usr/local/share - but all virt-* scripts inside /usr/local/bin point to usr/share/virt-manager/ - and /usr/share/glib-2.0/schemas/gschemas.compiled has been modified: maybe virt-manager-1.0.1/data/gschemas.compiled has been merged into it - and there are attempts to read /usr/share/virt-manager/ui/manager.ui instead of /usr/local/share/virt-manager/ui/manager.ui I added a warning pointing at GSETTINGS_SCHEMA_DIR to setup.py install if not installing into /usr/share |