head: cannot open '/var/tmp/portage/games-util/deutex-5.2.2/temp/sandbox.log' for reading: No such file or directory ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no_multilib_hardened-j4-20211219-130223 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.3.1 [2] x86_64-pc-linux-gnu-10.3.1 [3] x86_64-pc-linux-gnu-11.2.1 * clang version 13.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/13/bin /usr/lib/llvm/13 13.0.0 Python 3.9.9 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) [3] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.57.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.312_p07 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 php cli: HEAD of ::gentoo commit 2e6ef9a87179205a09e7e63c8bcd37fc36357497 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Dec 22 05:36:45 2021 +0000 2021-12-22 05:36:43 UTC emerge -qpvO games-util/deutex [ebuild N ] games-util/deutex-5.2.2 USE="png -man"
Created attachment 760030 [details] emerge-info.txt
Created attachment 760031 [details] emerge-history.txt
Created attachment 760032 [details] etc.portage.tar.bz2
Created attachment 760033 [details] games-util:deutex-5.2.2:20211222-061930.log
Created attachment 760034 [details] logs.tar.bz2
I'm not familiar with the sandbox feature. What does it do and what are the requirements of an ebuild for it? Is this error occurring because SRC_URI points to a tar.zst file?
Haven't looked at this closely, but it seems caused by zstd-1.5.1 (it's fine with 1.5.0). That aside .zst in SRC_URI only works by accident I believe, zst is not currently in PMS[1] [1] https://projects.gentoo.org/pms/8/pms.html#x1-13500012.3.15
Ah okay, I understand now. I'll define a src_unpack() and manually unpack this so we don't run into any other issues besides this.
(In reply to William Breathitt Gray from comment #8) > Ah okay, I understand now. I'll define a src_unpack() and manually unpack > this so we don't run into any other issues besides this. Sounds good to me, thanks. src_unpack is not sandboxed so this issue shouldn't apply then, I'm not quite sure why it does in the first place but zst in SRC_URI may just be doing something unexpected. Do add BDEPEND on zstd too, that too is bit of an accident given current portage happens to depend on it but that's not a definite thing.
(In reply to Ionen Wolkens from comment #9) > src_unpack is not sandboxed Well more precisely, it is sandboxed but not the namespace/time/network/etc... unsharing which is what's happening here.
So I looked into this a bit further and discovered that the _unpacker() function of the unpacker.eclass is what's handling the .zst file. The unpacker.eclass exports a src_unpack() function so we won't need to implement our own in the deutex.ebuild it seems. I've created a pull request regardless because we still should be specifying the required BDEPEND dependencies for the unpacker. Perhaps the missing dependency line is what's causing the error. I haven't been able to reproduce the error yet, so please verify if this solves the issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee4df4fd230ece2fb39286674cf570336f2785d6 commit ee4df4fd230ece2fb39286674cf570336f2785d6 Author: William Breathitt Gray <vilhelm.gray@gmail.com> AuthorDate: 2021-12-23 03:29:00 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2021-12-24 09:54:44 +0000 games-util/deutex: Add build dependencies for unpacker Closes: https://bugs.gentoo.org/829799 Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/23477 Signed-off-by: James Le Cuirot <chewi@gentoo.org> games-util/deutex/deutex-5.2.2.ebuild | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
(In reply to William Breathitt Gray from comment #11) > So I looked into this a bit further and discovered that the _unpacker() > function of the unpacker.eclass is what's handling the .zst file. The > unpacker.eclass exports a src_unpack() function so we won't need to > implement our own in the deutex.ebuild it seems. > > Perhaps the missing dependency line is what's causing the error. I haven't > been able to reproduce the error yet, so please verify if this solves the > issue. Oh my bad, hadn't realized this was actually using unpacker, thought it was odd. Think the reason I couldn't reproduce when I made my own src_unpack was because I used zstd through tar rather than zstd directly. That aside I'm still able to reproduce, but this isn't an issue specific to deutex. unpacker.eclass? zstd? sandbox? $ ebuild deutex-5.2.2.ebuild clean unpack * deutex-5.2.2.tar.zst BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking deutex-5.2.2.tar.zst to /tmp/portage/games-util/deutex-5.2.2/work * ACCESS DENIED: utimensat: /*stdout*\
unpacker simply calls `zstd -dfc` on the compressed file, so I suspect the issue is with the sandbox then: zstd 1.5.1 executes `utimensat` which results in the ACCESS DENIED, but the sandbox is supposed to permit that kind of operation.
*** Bug 829918 has been marked as a duplicate of this bug. ***
(In reply to William Breathitt Gray from comment #14) why do you think sandbox is supposed to allow this ? the log says zstd is trying to modify a file in / which it specifically is designed to prevent & block. note that it's not stylizing the output ... zstd is trying to modify the file literally named "*stdout*\" in the / directory. it doesn't happen with zstd-1.5.0, but does with ztsd-1.5.1. running it through strace shows the same behavior: $ strace -eutimensat zstd -dfc deutex-5.2.2.tar.zst >/dev/null utimensat(AT_FDCWD, "/*stdout*\\", [UTIME_NOW, {tv_sec=1642107797, tv_nsec=848905272} /* 2022-01-13T16:03:17.848905272-0500 */], 0) = -1 ENOENT (No such file or directory)
i bisected it and sent a bug upstream about it
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fb557c79e06436c6ca1245ac68cf006b567ce69c commit fb557c79e06436c6ca1245ac68cf006b567ce69c Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-21 23:50:38 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-21 23:52:43 +0000 app-arch/zstd: add 1.5.2 Closes: https://bugs.gentoo.org/829799 Closes: https://bugs.gentoo.org/829849 Signed-off-by: Sam James <sam@gentoo.org> app-arch/zstd/Manifest | 1 + app-arch/zstd/zstd-1.5.2.ebuild | 65 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+)
