Simon McVittie: > Package: debhelper > Version: 13.1 > Severity: important > > After the release of debhelper 13.1, mutter fails to build from source > with test failures. I can reproduce the build failure with a previous > version of mutter that used to build successfully. > > [...] > > In systemd's implementation (which is more or less the reference), the real > $XDG_RUNTIME_DIR is "/run/user/$uid", leaving 90+ bytes available for the > suffix of an AF_UNIX socket. > > Some ideas: > > * Maybe use shorter path segments: debian/.dh/gen/_s/xrd instead of > debian/.debhelper/generated/_source/xdg-runtime-dir? >
The shortest, I think I can realistically get this path is about 27 characters for the debhelper part[1]. Then there is the socket name + the build directory, which is beyond debhelper's control. Now, the build path on buildds are based on package name and version, so there are trivially packages that will naturally exceed the limits no matter what I do. E.g. firefox-esr version 68.9.0esr have the build path, which gives something like: * /build/firefox-esr-kioUND/firefox-esr-68.9.0esr/ (49 chars) * debian/.debhelper/.t/home/ (+27 chars) * <socket-name> (32 chars left) With your case taking 27 chars, we are quite close to the limit as it is. And a +dfsg suffix (or git snapshot version) can now be the difference between a working built and a FTBFS. This makes me think that we are looking at a dead end for this approach and delaying the inevitable. [1] I have promised to people that debian/.debhelper would be the last time they had to update their .gitignore and I intend to stick to that promise. > * Maybe use a random temporary directory /tmp/dh-xrd-XXXXXX for the > XDG_RUNTIME_DIR instead of having it in the build directory, perhaps > with a symlink in debian/.debhelper to make it easier to find? > That is doable and I got a poc code for that. The major issue I see is that there is no "clean on error" hook for debhelper. I fear this could be a non-trivial problem for buildds that see a non-trivial number of failures and are long running. So either debhelper need to unconditionally clean up the directories on failure in each helper creating them or we need an external "on-error" clean up hook that can assist debhelper. Neither are currently part of the design of the tools involved. The relevant question here being whether /tmp is cleaned automatically by sbuild, pbuilder (etc.) on errors. If it is, then this approach might be a non-issue. > * Or maybe create a random temporary directory /tmp/dh-XXXXXX with > symlinks /tmp/dh-XXXXXX/xrd -> .../debian/.debhelper/... and > /tmp/dh-XXXXXX/home -> .../debian/.debhelper/..., and then set > HOME=/tmp/dh-XXXXXX/home and XDG_RUNTIME_DIR=/tmp/dh-XXXXXX/xrd > instead of using the physical paths? (I don't know whether that would > solve the problem for AF_UNIX sockets though - they might try to put > the canonicalized physical path in a struct sockaddr_un, rather than > the symlink.) > AFAICT, this has the same issue as the above, except the cruft leak are symlinks rather than directories with content. > For now I'm going to put a workaround in mutter to create its own > temporary XDG_RUNTIME_DIR, but it seems a shame not to be able to take > advantage of debhelper solving this problem centrally. > > smcv > Finally, there is the third option of rolling back this feature as premature and dysfunctional until a better solution can be found. I doubt neither of us wants it, but I think the previous status-quo was better than broken builds that are hard to work around. Thanks, ~Niels
