Launching Emacs outside of gdm seems like a typical use case for a headless client, for instance using Virtualbox and ssh. I also noticed placing this in the environment:
export NO_AT_BRIDGE=1 resolves the error by preventing this AT extension from loading. My Emacs load time is much faster. Why was the change integrated and should it be backed out? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to at-spi2-atk in Ubuntu. https://bugs.launchpad.net/bugs/1845645 Title: Emacs logs AT-SPI warnings to console on startup Status in at-spi2-atk package in Ubuntu: New Bug description: When starting up certain (GTK?) applications from console in a custom X session, such as emacs or ubuntu-bug, there is a lot of log output like: """ ** (emacs:4437): WARNING **: 15:05:10.026: AT-SPI: Could not obtain desktop path or name """ or """ ** (apport-gtk:175957): WARNING **: 15:16:16.747: AT-SPI: Could not obtain desktop path or name """ The issue seems to be related to at-spi2-atk, or at least that's where the code that prints the error is: In register_reply in bridge.c: if (reply) { gchar *app_name, *obj_path; if (strcmp (dbus_message_get_signature (reply), "(so)") != 0) { g_warning ("AT-SPI: Could not obtain desktop path or name\n"); } Which seems to be triggered by an attempt to register the application to ATK: static gboolean register_application (SpiBridge * app) { DBusMessage *message; DBusMessageIter iter; DBusPendingCall *pending; g_free (app->desktop_name); g_free (app->desktop_path); /* These will be overridden when we get a reply, but in practice these defaults should always be correct */ app->desktop_name = g_strdup (ATSPI_DBUS_NAME_REGISTRY); app->desktop_path = g_strdup (ATSPI_DBUS_PATH_ROOT); message = dbus_message_new_method_call (SPI_DBUS_NAME_REGISTRY, ATSPI_DBUS_PATH_ROOT, ATSPI_DBUS_INTERFACE_SOCKET, "Embed"); dbus_message_iter_init_append (message, &iter); spi_object_append_reference (&iter, app->root); if (!dbus_connection_send_with_reply (app->bus, message, &pending, -1) || !pending) { if (pending) dbus_pending_call_unref (pending); dbus_message_unref (message); return FALSE; } dbus_pending_call_set_notify (pending, register_reply, app, NULL); It seems to be caused by nobody being available at the ATSPI_DBUS_PATH_ROOT to handle the message. I have not yet been able to figure out what *should* be handling the message. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/at-spi2-atk/+bug/1845645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
