Hi, Quoting Arnaud Rebillout (2025-10-28 15:45:11) > I'm running sbuild with unshare mode in GitLab CI, on gitlab.com shared > runners. > > For a bit more context: Salsa CI [1] switched to using sbuild / unshare > recently. At Kali Linux (a Debian derivative), we have a fork of Salsa > CI [2], that runs on gitlab.com. Today I was working on updating our > fork to be in line with Salsa CI, and so I find myself running sbuild / > unshare on gitlab.com shared runners. > > [1]: https://salsa.debian.org/ > [2]: https://gitlab.com/kalilinux/tools/kali-ci-pipeline/ > > Turns out that /dev/console doesn't exist in the container, in GitLab > CI, and so sbuild spits out a lot of logs like that: > > ``` > cannot bind-mount /dev/console as it does not exist outside the chroot at > /usr/libexec/sbuild-usernsexec line 438. > cannot bind-mount /dev/console as it does not exist outside the chroot at > /usr/libexec/sbuild-usernsexec line 438. > cannot bind-mount /dev/console as it does not exist outside the chroot at > /usr/libexec/sbuild-usernsexec line 438. > ``` > > I've setup a minimal Git repo to demonstrate the issue, and you can find > the complete logs at: > > https://gitlab.com/arnaudr/gitlab-ci-sbuild-unshare/-/jobs/11874917839 > > In the logs above, the warning appears 116 times... > > Out of curiosity, you can compare the output from the same job, but this > time running on salsa.debian.org: > > https://salsa.debian.org/arnaudr/gitlab-ci-sbuild-unshare/-/jobs/8515908 > > So, I was wondering, how to improve that, and avoid littering the logs. > > One possibility would be to issue the log once only (ie. add a variable > to remember that the logs was shown). > > Another possibility: do we even need this log? What's the consequence if > /dev/console isn't present in the chroot? Maybe sbuild doesn't even need > to log anything for this particular device?
yes, we need this line. Before we had this, there was a bug which I spent days to track down. The bug was that the container system that sbuild was running on did not have one of the device nodes and as a result the build inside was failing in interesting ways which I was unable to reproduce. Since the container was not under my control this was an extremely frustrating bug to track down. Thus, I'd like sbuild to complain loudly if it does not find some of the things that it expects to be present. What we can talk about is to only print this error message once instead of a hundred times. Unfortunately, doing this might be tricky because the error message is printed by a utility that is run independently of the sbuild executable itself. So the program which prints this message will exit before it is started again and prints the next message. Patches welcome! Thanks! cheers, josch
signature.asc
Description: signature
