Control: retitle 971422 libvte-2.91-0: vte_terminal_spawn_async doesn't accept NULL callback since 0.62
On Wed, 30 Sep 2020 at 12:12:22 +0200, Pascal wrote: > as described in this bug : https://bugs.debian.org/cgi- > bin/bugreport.cgi?bug=970356 > It's impossible to launch mssh . > > mssh -a serveurs > > (mssh:105138): VTE-CRITICAL **: 12:10:20.197: void > vte_terminal_spawn_with_fds_async(VteTerminal*, VtePtyFlags, const char*, > const > char* const*, const char* const*, const int*, int, const int*, int, > GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify, int, > GCancellable*, VteTerminalSpawnAsyncCallback, gpointer): assertion 'callback' > failed > > an mssh window opens, but remains empty. The documentation for vte_terminal_spawn_async() and its newer version vte_terminal_spawn_with_fds_async() says it's valid to call them with a NULL callback, but since 0.62.x the implementation doesn't allow this. At least one of the documentation or the implementation must be wrong. This is a regression in libvte-2.91-0: it doesn't accept something that previously worked. However, mssh can work around this by passing a non-NULL callback. I would recommend making mssh use a non-NULL callback *anyway*, because it's the only way for vte_terminal_spawn_async() to report errors, which any non-trivial vte user should be reporting in some way. Something like this should be suitable: static void terminal_spawn_async_cb (VteTerminal *terminal, GPid pid, GError *error, gpointer user_data) { if (error != NULL) g_critical ("Error setting up terminal: %s", error->message); else g_debug ("Terminal set up, process ID: %d", pid); } (Or whatever error handling mssh wants to do instead of complaining on stderr: for example, it might want to emit the session-closed signal on errors, or something like that.) smcv
