Package: debhelper Version: 12.1.1 Severity: normal Hello Niels (and whoever else is in the party),
to resume the discussion in #931985: The way dh_strip and
dh_shlibdepends call the seccomp-enabled file program causes breakage -
the syscalls done by fakeroot are not whitelisted, game over. So far,
impact was low since only the version of file in experimental (1:5.37-1)
has seccomp support enabled.
But a seccomp-enabled file package should land in unstablle soon.
Since you - lucky me - expressed in that bug report that seccomp
support in the file programm was something worth to have, I am asking
you to make some changes on your side that disable seccomp support when
calling the file program. Theoretically I could hack a fakeroot
detection into file but ... no.
A sane solution were if debhelper uses Perl bindings for libmagic
instead of calling the program - but AFAICS File::LibMagic does not
provide all the functions needed. Perhaps some day someone(tm) could
give that package some love.
A feasible solution was if debhelper would call file with an additional
--no-sandbox option to disable seccomp support - but this would break
debhelper on all archs where that support is not available or if the
version of file is too old. For the first problem however there is a
change coming: file upstream accepted my patch to make file's
--no-sandbox option a no-op if there's no seccomp support.
Now we are just left with an almost neglectable obstacle about the
transition: You will have to add that parameter to the file invocations
while my job is to upload a file package with seccomp support and the
above parameter handling. This will create a race ...
* If the new version of file hits unstable first, *many* builds using
debhelper will break, as seen in #931985
* If insted a new debhelper version takes precedence, *many* builds
using debhelper will break as well - either from seccomp in file, or
from an unsatisfyable versioned debhelper dependency on like
"file (>= 1:5.37-2)" which of course you should declare.
So options:
* Take the risk: We coordinate the uploads so they will land - fingers
crossed - unstable in the same dak run.
* Two-step approach: First, I'd upload a transitional version of file
*without* seccomp support. It will understands --no-sandbox though so
you can upload a new debhelper version afterwards. Eventually I'll
upload another version file with seccomp *en*abled.
While the second option is more complex, I admit it's the saner way and
we should do that - unless you provide better ideas.
Opinions? Do you plan uploading a new debhelper in the next days?
Kind regards,
Christoph
signature.asc
Description: PGP signature
