Trying to use proot with sys-apps/pkgcore I get: > proot pmerge /usr/lib64/python-exec/python-exec2: no supported Python implementation variant found! pmerge has shebang: #!/usr/lib/python-exec/python-exec2-c I don't know if this is a proot or python-exec issue though, lets start with python-exec as it is a gentoo-tool
That's VERY strange. proot DOES NOT install any parts of Python-related code, so it can not be the real issue. CCing pkgcore maintainers
I don't think this is a pkgcore issue, its is either a proot or python-exec. A guess is that python-exec requires some particular argv0 handling This works: proot sh -c pmerge usage: pmerge [-h] [--version] [--debug] [--color BOOLEAN] [--add-config SECTION KEY VALUE] [--new-config SECTION KEY VALUE] [--empty-config] [--domain DOMAIN] [-N] [-s SET] [-C] [--clean] [-p] [--ignore-failures] [-a] [--force] [-f] [-1] [-u] [-D] [--preload-vdb-state] [-i] [-B] [-O] [-n] [-k] [-K] [-S] [-e] [-v] [--quiet-repo-display] [-F FORMATTER] [targets [targets ...]] pmerge: error: Need at least one atom/set
(In reply to Joakim Tjernlund from comment #2) > I don't think this is a pkgcore issue, its is either a proot or > python-exec. > > A guess is that python-exec requires some particular argv0 handling > This works: > proot sh -c pmerge > usage: pmerge [-h] [--version] [--debug] [--color BOOLEAN] > [--add-config SECTION KEY VALUE] > [--new-config SECTION KEY VALUE] [--empty-config] > [--domain DOMAIN] [-N] [-s SET] [-C] [--clean] [-p] > [--ignore-failures] [-a] [--force] [-f] [-1] [-u] [-D] > [--preload-vdb-state] [-i] [-B] [-O] [-n] [-k] [-K] [-S] [-e] > [-v] [--quiet-repo-display] [-F FORMATTER] > [targets [targets ...]] > pmerge: error: Need at least one atom/set Sorry, you do not get my point. There is no Python parts in proot installation process. Not a single one. phantom PRoot-4.0.0 # pwd /var/tmp/portage/sys-apps/proot-4.0.0/work/PRoot-4.0.0 phantom PRoot-4.0.0 # grep -ir pmerge . phantom PRoot-4.0.0 # No pmerge => not proot issue. Reassigning to python-exec maintainers, cause i know that previous versions(0.*) had some issues with handling of argv[0], IIRC
(In reply to Sergey Popov from comment #3) > (In reply to Joakim Tjernlund from comment #2) > > I don't think this is a pkgcore issue, its is either a proot or > > python-exec. > > > > A guess is that python-exec requires some particular argv0 handling > > This works: > > proot sh -c pmerge > > usage: pmerge [-h] [--version] [--debug] [--color BOOLEAN] > > [--add-config SECTION KEY VALUE] > > [--new-config SECTION KEY VALUE] [--empty-config] > > [--domain DOMAIN] [-N] [-s SET] [-C] [--clean] [-p] > > [--ignore-failures] [-a] [--force] [-f] [-1] [-u] [-D] > > [--preload-vdb-state] [-i] [-B] [-O] [-n] [-k] [-K] [-S] [-e] > > [-v] [--quiet-repo-display] [-F FORMATTER] > > [targets [targets ...]] > > pmerge: error: Need at least one atom/set > > Sorry, you do not get my point. There is no Python parts in proot > installation process. > Not a single one. > > phantom PRoot-4.0.0 # pwd > /var/tmp/portage/sys-apps/proot-4.0.0/work/PRoot-4.0.0 > phantom PRoot-4.0.0 # grep -ir pmerge . > phantom PRoot-4.0.0 # pmerge is part of pkgcore, not proot. > > No pmerge => not proot issue. ehh, thast is not a valid claim. proot is supposed to be transparant to the apps it launches but here something gets in the way. > > Reassigning to python-exec maintainers, cause i know that previous > versions(0.*) had some issues with handling of argv[0], IIRC
If "proot sh -c pmerge" works but "proot pmerge" doesn't, then it's a bug in PRoot. I'll take a look at it.
(In reply to Cédric Vincent from comment #5) > If "proot sh -c pmerge" works but "proot pmerge" doesn't, then it's a bug in > PRoot. I'll take a look at it. Yes, I think so too. Did some strace of proot pmerge and plain pmerge, got this far: jocke@gentoo-jocke ~ $ proot /usr/lib/python-exec/python2.7/pmerge usage: filter-env [-h] [--version] [--debug] [-V] [-F] [-i INPUT] [-f FUNCS] [-v VARS] [--print-vars | --print-funcs] filter-env: error: failed loading/parsing input: Refusing to read from stdin since it's a TTY jocke@gentoo-jocke ~ $ /usr/lib/python-exec/python2.7/pmerge usage: pmerge [-h] [--version] [--debug] [--color BOOLEAN] [--add-config SECTION KEY VALUE] [--new-config SECTION KEY VALUE] [--empty-config] [--domain DOMAIN] [-N] [-s SET] [-C] [--clean] [-p] [--ignore-failures] [-a] [--force] [-f] [-1] [-u] [-D] [--preload-vdb-state] [-i] [-B] [-O] [-n] [-k] [-K] [-S] [-e] [-v] [--quiet-repo-display] [-F FORMATTER] [targets [targets ...]] pmerge: error: Need at least one atom/set Perhaps a symlink problem(following all symlinks to the end, like realpath do)?
(In reply to Cédric Vincent from comment #5) > If "proot sh -c pmerge" works but "proot pmerge" doesn't, then it's a bug in > PRoot. I'll take a look at it. Any clues yet?
I'm able to reproduce this bug; it happens when launching a script through a symlink (ie. this is not specific to Python): $ cat -> 1.sh #!/bin/sh echo $0 ^D $ ln -s 1.sh 2.sh $ proot 2.sh /usr/local/cedric/git/proot/tests/rootfs/bin/1.sh $ proot sh -c ./2.sh ./2.sh At a first glance, this bug comes from the initialize_command() and launch_process() functions in PRoot, that's why it doesn't happen when using a shell. I'm investigating for the right fix, Cédric.
Fix: https://github.com/cedric-vincent/PRoot/commit/520fa3601c36dd0a3c84e310bd2a1189259000bd
(In reply to Cédric Vincent from comment #9) > Fix: > https://github.com/cedric-vincent/PRoot/commit/ > 520fa3601c36dd0a3c84e310bd2a1189259000bd Super,it was a symlink problem after all! I do not see this commit in the master branch though. I hope you do not plan to release proot without this fix as it causes apps to crash and burn. Got a question too, proot affects perforamnce too but is the penalty constant no matter what options you use? Could you elaborate if it depends on how one uses proot? Wishlist, make -0 as good as fakeroot.
--- Comment #10 from Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- > I do not see this commit in the master branch though. I hope you > do not plan to release proot without this fix as it causes > apps to crash and burn. Well, the situtation is not so dramatic :) since it happens only if all the following conditions are met: - the program in launched by PRoot directly, ie. it is not launched by a shell or any other program previously launched by PRoot; and - the program is launched through a symbolic link; and - the program is a script (ie. it contains a shebang); and - argv[0] impacts the behavior of the program. This fix will be included in the next release, maybe in September. By the way, the latest release (v4.0.1) contains a fix to a bug exposed by Gentoo's sandbox (which is not recommended under PRoot anyway, see below). > Got a question too, proot affects perforamnce too but is the penalty > constant no matter what options you use? Could you elaborate if it > depends on how one uses proot? > > Wishlist, make -0 as good as fakeroot. I put answers in a dedicated thread: https://groups.google.com/forum/?fromgroups#!topic/proot_me/GQU5s8XR_yU
Joakim, it was proot issue, after all. I was wrong and probably rude, sorry for that. Cédric, big thanks for such quick fix! I will backport it into upcoming ebuild for 4.0.1
(In reply to Cédric Vincent from comment #11) > --- Comment #10 from Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- > > I do not see this commit in the master branch though. I hope you > > do not plan to release proot without this fix as it causes > > apps to crash and burn. > > Well, the situtation is not so dramatic :) since it happens only if > all the following conditions are met: > > - the program in launched by PRoot directly, ie. it is not launched by > a shell or any other program previously launched by PRoot; and > > - the program is launched through a symbolic link; and > > - the program is a script (ie. it contains a shebang); and > > - argv[0] impacts the behavior of the program. My case only then it seems :-) > > This fix will be included in the next release, maybe in September. > > By the way, the latest release (v4.0.1) contains a fix to a bug > exposed by Gentoo's sandbox (which is not recommended under PRoot > anyway, see below). I looked for the ref to Gentoo sandbox and proot but I did not find any, did you forget it or am I just blind? > > > > Got a question too, proot affects perforamnce too but is the penalty > > constant no matter what options you use? Could you elaborate if it > > depends on how one uses proot? > > > > Wishlist, make -0 as good as fakeroot. > > I put answers in a dedicated thread: > https://groups.google.com/forum/?fromgroups#!topic/proot_me/GQU5s8XR_yU saw your answer, looks good I must say:-)
(In reply to Joakim Tjernlund from comment #13) > My case only then it seems :-) Well, it seems I have underestimated the impact of this bug, it turns out it affects not only scripts, but also dynamically linked programs (since the ELF interpreter is used explicitly as a loader). In other words, the patch for the bug you have reported also fixes issues #20 and #65 (duplicate) on https://github.com/cedric-vincent/PRoot/issues/ > I looked for the ref to Gentoo sandbox and proot but I did not find any, > did you forget it or am I just blind? https://github.com/cedric-vincent/PRoot/releases/tag/v4.0.1 https://github.com/cedric-vincent/PRoot/commit/bf1003c246790d4631e95df485d6ba7f72c0d24a
+*proot-4.0.1 (02 Sep 2014) + + 02 Sep 2014; Sergey Popov <pinkbyte@gentoo.org> -proot-4.0.0.ebuild, + +proot-4.0.1.ebuild, +files/proot-4.0.1-argv.patch: + Version bump, wrt bug #520050 with fix for bug #517496. Thanks to Joakim + Tjernlund <Joakim.Tjernlund AT transmode.se> for discovering this issues. + Drop old version So, i bring fix for this into unstable. Will proceed with stabilization after usual period of waiting.
Hello, The fix for this bug was released upstream (v4.0.2): https://groups.google.com/forum/#!msg/proot_me/K_DsLNI8UlY/yaAL9isZwLQJ Thanks!
3.2.2-r1 is in stable for a quite long period, closing this as fixed
