Simon McVittie

My reading of the assertion failure is that if we reach that assertion, somehow `g_hash_table_remove_internal()` has called `g_hash_table_lookup_node()` and successfully found an item, but then on entering `g_hash_table_remove_node()`, it turns...

> With the pytest setup we currently have, we can only test config in $HOME but we could modify things for this test to launch x-d-p in a new mount...

> In [this](https://gitlab.collabora.com/vivek/libcapsule/-/blob/master/utils/ld-libs.c?ref_type=heads#L649) line, libcapsule uses `/lib:/usr/lib` as a fallback path for library lookup. This is incorrect for 64-bit libraries/systems, which typically use `/lib64:/usr/lib64`. What architecture and OS are you...

> libcapsule really relies on `ld.so.cache` to be up to date, so if there's an OS distribution that doesn't already reliably update that cache with package manager triggers, I'd recommend...

> The logic to regenerate ld.so.cache exists in Flatpak, there's just no way for us to trigger an invalidation of the cache yet from our end If this is for...

> We could try to update the ld.so.cache when the environment is started up (in a tmpfs or something), but if that takes ~2 seconds that's already twice our muvm...

As a first step towards this, I think I'm going to add a debugging/development environment variable that will be used as if it was the hard-coded fallback search path. That...

We already run `ldconfig` once during each pressure-vessel startup, to build a `ld.so.cache` *inside* the container, because that turns out to be the only reliable way to tell games which...

> [we run ldconfig once] per muvm startup, which for example would be once per Steam startup the way we package Steam today. Essentially "any time an x86 program is...

I should have pointed out before, but: Steam is designed for x86 machines, and running Steam on an ARM system emulating an x86 is not really something that we support....