Summary: | dev-qt/qtcore-5.4.2 - tee: /dev/stderr: Permission denied | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | qtcore-5.4.2:20150924-141912.log |
Description
Agostino Sarubbo
![]() Created attachment 412788 [details]
qtcore-5.4.2:20150924-141912.log
build log
> tee: /dev/stderr: Permission denied
I don't know what you're doing but your environment doesn't look sane...
(In reply to Davide Pesavento from comment #2) > > tee: /dev/stderr: Permission denied > > I don't know what you're doing but your environment doesn't look sane... I'm in a simply chroot. All works well. could be a portage or sandbox bug...? (In reply to Davide Pesavento from comment #4) > could be a portage or sandbox bug...? dunno, but I'm trying on a fresh and clean chroot. Fails in the same way in a clean chroot. I'd invite to run the same test. ok. I didn't have /dev/std* here because on this server, udev was never started up. My fault. Anyway I guess the ebuild should check the presence of /dev/std* (In reply to Agostino Sarubbo from comment #6) > Fails in the same way in a clean chroot. I'd invite to run the same test. I cannot reproduce. The attached build log reports a sandbox violation. Are you sure you didn't modify your sandbox.conf, e.g. removing /proc/self/fd from SANDBOX_WRITE? (In reply to Davide Pesavento from comment #8) > (In reply to Agostino Sarubbo from comment #6) > > Fails in the same way in a clean chroot. I'd invite to run the same test. > > I cannot reproduce. > > The attached build log reports a sandbox violation. Are you sure you didn't > modify your sandbox.conf, e.g. removing /proc/self/fd from SANDBOX_WRITE? To reproduce you need to NOT have /dev/stderr. The way to do it is not have udev started and check also that /dev/stderr does not exist. Are you using tee as part of your chroot scripts? (In reply to Michael Palimaka (kensington) from comment #10) > Are you using tee as part of your chroot scripts? no As I already said, fix your setup please. We're not supposed to check the existence of basic stuff in /dev from ebuilds. (In reply to Davide Pesavento from comment #12) > As I already said, fix your setup please. We're not supposed to check the > existence of basic stuff in /dev from ebuilds. As I already said, this is not anymore a problem for me. The bug appears if you don't have udev started and this could happen on any setup. (In reply to Agostino Sarubbo from comment #13) > The bug appears if you don't have udev started and this could happen on any > setup. No, your setup is broken if you don't have basic device nodes and symlinks in /dev. Are we supposed to start checking for /dev/null before using it now?! This is nonsense. If you don't use udev you should use some other static dev manager that sets up a minimal environment for you. Or use bind mounts if you're in a chroot or container. |