Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
- "nomap" mode passes all paths, execs, etc. thru the logic in our
preload library, but does not map anything. This is mostly useful for
debugging SB2 itself, but can be used for benchmarking etc. also.
- Had to add a new option to sb2-init, otherwise "nomap" mode could not
be properly initialized on 64-bit intel hosts.
|
|
We want to get rid of the stupid -drop-ld-preload flag in qemu upstream.
Therefor mandatory for sb2 2.0. release :)
Only lightly tested but appears to work as expected.
Signed-off-by: Riku Voipio <riku.voipio@iki.fi>
|
|
- Both the C <-> Lua and the rule file interfaces were
changed by a previous patch ("l10n: message catalogs are
now mapped based on active exec policy"), but the
interface numbers were not changed, this commit fixes that
|
|
- Map /etc/perl* and /etc/python* just like /usr/lib/p...* are handled =
conditionally, depending on active exec policy
|
|
|
|
- Removed usage of native_app_message_catalog_prefix variable in
exec policy. There is no need for that anymore as we can find
out correct mappings using conditional rules.
- LOCPATH and NLSPATH are cleared always before exec so they don't
get inherited to child unless really needed.
- __SB2_REAL_BINARYNAME is not anymore needed but I left it there
in case there is some future needs for that.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
- reorganized some rules in the mapping modes and added a check to
utils/sb2, so that $SBOX_SESSION_DIR does not contain symlinks
|
|
- Mika Westerberg's last change to the "emulate" mode uses "next_chain"...
|
|
- Previously it was not possible to install, for example, package
osso-af-sb-startup because it tried to install file
/usr/bin/scratchbox-launcher.sh and other that were wrapped
with sb1 compatibility scripts (readonly).
- Now dpkg has its own rules chain that allows it to install packages
regardless of what we have wrapped.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
Some people compile and run stuff from /tmp.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
|
|
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
|
|
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
|
|
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
|
|
1) Part of rules were left out because of a bug
2) Now reverses conditional mapping rules, too (previously those were
not reversed at all)
There was even a "FIXME"-comment about this; the comment stated
"...This should be fixed, even if it is not a problem with our current
official mapping modes." This comment was valid once, but not anymore;
recent changes to the mapping modes practically require that we
have reverse rules also for conditional rules.
|
|
- When debian package resolvconf is installed it creates directory
/etc/resolvconf and makes /etc/resolv.conf symlink that points
there. Now paths under /etc/resolvconf come also from host.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
- don't create reverse mapping rules for programs that belong
to the cross-gcc toolchain, etc. This is needed because otherwise
"gcc" won't be able to find "cc1"; this is important once we have
a better reverse rule generator (=really soon)
|
|
- an exec policy can now define more than one rule to map the script
interpreter (previously only one rule was allowed)
- "devel" mode: Added yet another SB1 compatibility feature: Support
for mapping interpreters from /scratchbox/tools/bin to <tools_root>/usr/bin
- Interface version of the mapping engine <-> mapping rules interface
was incremented (this is the lua<->lua interface version, C<->lua interface
was not modified)
|
|
- a similar rule already exists in "emulate" and "devel" modes
|
|
|
|
- set exec_policy correctly for perl and python also when an incorrectly built
package wants to start them from /scratchbox/tools/bin. Hard dependencies
to the SB1 environment are not nice (but we are, aren't we? Because we are
trying to make all these compatibility rules, so that old badly behaving
packages could be build with SB2, too...)
|
|
|
|
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
- this rule already exists in the "emulate" mode
|
|
- happened because C->Lua interface left trash to Lua's stack => script
execution failed to find corect exec_policy for the script interpreter
- Also included:
- added new debugging level NOISE3
- added dump_lua_stack() (luaif/argvenvp.c), name says it all..
|
|
- This is practically the opposite of SBOX_REDIRECT_IGNORE.
- Devel mode: including /usr/bin/perl and/or /usr/bin/python in
SBOX_REDIRECT_FORCE will force perl and/or python to be taken from tools
(the default is to map these to target_root).
- Note that if SBOX_REDIRECT_IGNORE and SBOX_REDIRECT_FORCE are both
active at the same time, SBOX_REDIRECT_IGNORE will have priority.
|
|
- Changed default mapping of perl* and python* to target_root:
Prefixes /usr/bin/perl* and /usr/bin/python* are now mapped to
the rootstrap.
- Previously these scripting languages were used from tools_root
- Script interpreter mapping policies have been set up so that
a script which is executed from tools_root will take the interpreter
still from tools_root => there are many tools that are written as
scripts (for example, many of the dpkg-* tools are perl script),
so these continue to run with the correct libraries
- Obviously, this has some performance penalties when building for
a foreign architecture, because the default script interpreter would
be running under CPU transparency. However, that penalty appears to
be quite minimal (average result, at least)
|
|
- No longer uses "bash" or "perl" from tools_root to execute scripts
from host. For example, sb2's various scripts now take the interpreter
from the host environment.
|
|
- First try to map to tools_root, but if the program does not exist
there, the mapping leads to target_root. This makes it possible to
use many tools that are not available at all from the tools distro.
|
|
- Previously, a subtree in a ruleset was required to perform a mapping.
- This commit changes the algorithm so that if a match is not found from
the subtree, searching continues in the calling ruleset; i.e. the subtrees
are now called like subroutines are called in programs, not jumped into.
|
|
- Exec policy for scripts is now correctly selected when the script
interpreter is selected (things were messed up when the exec policy
had requirements for the interpreters..)
|
|
- There is new lua script: create_argvmods_rules.lua which
is used to create explicit rules based rules created by argvenvp_xxx.lua.
- Separated mangling rules for misc binaries to be in file
argvenvp_misc.lua
- Rules are generated by sb2 script and placed under
$SBOX_SESSION_DIR/argvmods/*.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
"/share/scratchbox2" to make sb2 works also from other than /usr/bin directory.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
|
|
"SBOX_REDIRECT_IGNORE" is a feature from the old scratchbox 1: It can
be used to disable redirection of various paths during exec. This commit
adds a simplified, mostly compatible support to SB2. Since we don't have
a similar "redirector" as what the old SB1 had, this feature is implemented
by some special mapping rules in the devel mode and is only available
for two programs: : redirection of /usr/bin/perl and /usr/bin/python can
be disabled by this. For example, setting
SBOX_REDIRECT_IGNORE=/usr/bin/perl:/usr/bin/python
will force these two programs to be mapped to the rootstrap (while the
default is still to map them to tools_root)
Also included: new conditional action 'if_redirect_ignore_is_active = "path"'
makes all this possible (added to the rule execution engine in mapping.lua).
|
|
- scripts that are started from tools_root will use the script interpreter
from tools_root. For example, executing perl script
/usr/bin/dpkg-parsechagelog will use perl from tools_root. Same applies
to all other scripts (shell scripts, python programs, etc)
- perl & python will be started from tools_root or from the rootstrap depending
on exec policy of the active process: A process, which is running under
the "Tools" policy will find that /usr/bin/perl points to tools_root, while
a target binary running under the "Rootstrap" policy will see /usr/bin/perl
pointing to target_root (and the same applies to python, and libraries
of these two languages, but does not concern other scripting languages)
|
|
- new conditional action 'if_active_exec_policy_is = "policyname"'
- conditional actions in rules can now be used to select exec policy, too.
|
|
- set name of the selected exec policy to an environment
variable before every exec, and also added a lua function
which locates the currently active policy (soon to be used
by the "devel"mode..)
|
|
- this commit adds support for exec policy based mapping of script interpreter:
A script interpreter can be selected based on location of the script.
For example, perl scripts from tools_root may map /usr/bin/perl to
tools_root, while perl scripts from the target_root can map /usr/bin/perl
to target_root.
- This commit does not contain changes to the mapping rules => everything
still works just as before (related changes to the "devel" mode will be
added by another commit)
|
|
|
|
|
|
- reverse mapping has been disabled since /proc handling was added.
|
|
Variable is named as 'conf_(tools|target)_libsb2_dir' and it
is used in emulate mode to disable its mapping.
Signed-off-by: Lauri Aarnio <Lauri.Aarnio@iki.fi>
|
|
- Mapping rules can be automatically generated for all components of the
toolchain. for example, /usr/bin/gcc can be mapped to the real compiler.
- Currently "devel" mode is the only one which uses this.
- (previously, the toolchain components have been handled only by the exec
preprocessing code. Now normal filesystem accesses lead to the same files,
too)
|
|
Summary:
* Now it is possible to have several toolchains available simultaneously:
The primary gcc will be available as "gcc", while components of the secondary
toolchain(s) are available as "gcc-X.Y", etc.
* sb2-init now calls a new script, sb2-config-gcc-toolchain to set up
toolchain configurations
* Toolchain configuration variables were moved to new config files, two
files/toolchain
Some details:
- "sb2-upgrade-config" automatically upgrades existing config files
- "sb2-config-gcc-toolchain" was created by separating all target-gcc-related
actions from "sb2-init"; this was not as straightforward as it sounds.
All toolchain-related configuration variables had to be moved from
the old-style config file (sb2.config) to the new files, and then every
place where the variables were needed had to be checked. This turned out
to be more like a separation of siamese twins...but the result is that
it is possible to have more than one toolchain configured, finally!
|
|
|
|
- sb2-generate-locales has new switch '-T' that allows user
to generate localization files for tools.
- sb2-init calls sb2-generate-locales for given target
and also for tools if needed.
Signed-off-by: Lauri Aarnio <lauri@bar.research.nokia.com>
|
|
- fixed mapping of various files that came from packages debhelper, gnulib,
libltdl3-dev, libsndfile1-dev, xcb-proto, shared-mime-info
|