Package: sbuild Version: 0.91.1 Severity: normal X-Debbugs-Cc: [email protected] User: [email protected] Usertags: origin-kali
Dear Maintainer, 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? What do you think? Thanks in advance, Arnaud
