Jack Hill

Thanks for your hard work on this! I've tested on [Guix](https://guix.gnu.org) by updating our dino package to [Dino commit dbc6d87cb9c26a5858ccf7400a43cdd4f6f26971](https://github.com/dino/dino/commit/dbc6d87cb9c26a5858ccf7400a43cdd4f6f26971) and uncommenting [all the lines](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/messaging.scm?id=854e38eeb7b007b6027364696615ec5eaa619c52#n1362) that say to uncomment for...

A follow up to the problem with incomming calls. I still see the problem with the 0.3.0 now officially in Guix. I can also re-create it on a Debian 11...

I just had a sucessful Dino to Dino incomming call, so I don't think it is a problem with my network or XMPP server. I'm happy to gather more debugging...

I believe that I've run into this while troubleshooting a [WebKitGTK bug on GNU Guix](https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40837#31). In this case the application is generating an `--ro-bind /etc /etc` followed by an `--ro-bind-try...

Thanks, canonicalizing paths before passwing them to Bubblewrap sounds like a good path forward. In general, I agree that it seems like this issue can be closed if there is...

I think I may have just run into this issue (at least can't open a channel with `"no message in [channel], fetching from server"`, but setting `slack-render-image-p` to `nil` didn't...

Actually, updating to the latest commit seems to have fixed this for me now (and with `slack-render-image-p` set to `1`). Maybe it's time for another release?

Ah, it seems that this may have been fixed in cee22450ee30e79952f594796721dc6b17798ee6 and it just hasn't made it into a release. I ended up filing a [Guix bug](https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31726)