GNOME Bugzilla – Bug 691347
gnome-terminal doesn't start in jhbuild 3.8 session
Last modified: 2013-01-14 17:02:20 UTC
When I try to start gnome-terminal from gnome-shell in a 3.8 jhbuild session, it won't start. Trying from another tty in a jhbuild shell I get: $ DISPLAY=:2 gnome-terminal Error creating terminal: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Profile "b1dcc9dd-5262-4d8d-a863-c897e6d979b9" $ gsettings get org.gnome.Terminal.Settings legacy-profiles ['5d0df8e9-feae-4e5a-a2f2-b4051bced6d8'] $ gsettings get org.gnome.Terminal.Settings legacy-default-profile <some id that was different from the 5d0df8e9-feae-4e5a-a2f2-b4051bced6d8> setting the org.gnome.Terminal.Settings schema version back to 0 and running the gnome terminal profile migrator from libexec had the same results (different IDs). on IRC, chpe suggested to try the following change: diff --git a/src/migration.c b/src/migration.c index 686280a..670e79f 100644 --- a/src/migration.c +++ b/src/migration.c @@ -443,7 +443,7 @@ migrate_profiles (GError **error) profile_uuids = g_ptr_array_new_with_free_func ((GDestroyNotify) g_free); - dvalue = gconf_client_get_without_default (client, GCONF_GLOBAL_PREFIX "/default_profile", NULL); + dvalue = gconf_client_get (client, GCONF_GLOBAL_PREFIX "/default_profile", NULL); if (dvalue != NULL && dvalue->type == GCONF_VALUE_STRING) default_profile = gconf_value_get_string (dvalue); followed by resetting the schema version to 0 again and running the migrator again. This led to: $ gsettings get org.gnome.Terminal.Settings legacy-default-profile '221ae85b-fab2-4c1b-9c86-9789fc3f4249' $ gsettings get org.gnome.Terminal.Settings legacy-profiles ['221ae85b-fab2-4c1b-9c86-9789fc3f4249'] And now I'm able to start gnome-terminal form tty in a jhbuild shell: $ DISPLAY=:2 gnome-terminal but it still doesn't start when I try to launch it from the dash in the jhbuild session.
Not sure, but this is might just be some dbus issue with my jhbuild setup.
That last issue looks more like a jhbuild/dbus setup problem, yes. Since g-t is now using a client/server model, maybe it's just not finding the .service file?
The migration issue should be fixed on git master; please check.