This fixes issues mainly seen when mounting eMMC devices:
The wildcard /sys/block/${DEVBASE}/${DEVBASE}*1 matches both "mmcblk0p1"
and "mmcblk0boot1" for example, and this results in syntax errors. Fix this
by searching for a "partition" file instead, which only exists for real
partitions and not 'fakes' like the eMMC extra's.
When mount fails, the mountpoint file is left behind, causing later attempts
at auto-mounting it to fail. If mount fails, remove the mountpoint, leaving
the system in the state as it was before the mount attempt.
(From OE-Core rev: 8645c0419456c1bd3ae15a9a7dd2b2e9a960eaf4)
(From OE-Core rev: 38f1648f1472f70a3e747f270cc3230b5993d94b)
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move init related configs to init.cfg.
These config items do not make much sense unless busybox is selected
as the init manager. They should belong to init.cfg.
(From OE-Core rev: 4af10fe67a31368163bb5d468ee2c5a85ce0fff3)
(From OE-Core rev: 996247ba7dfffbeb444f793f7e105fcfb5ffa939)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If CONFIG_KLOGD is not enabled, then the related service file should
not be installed, The error message is below:
Cannot add dependency job for unit busybox-klogd.service,
ignoring: Unit busybox-klogd.service failed to load:
No such file or directory.
So we should first check the configuration before we install these
service files.
(From OE-Core rev: c3cc402df996654bf6f838b1e79e16a8bdd6d4d7)
(From OE-Core rev: df1cd90140456dbed0c1bd29ead7c1c81f498b99)
Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use == instead of = when comparing task outcome to OUTCOME_FAILED.
Prior to this fix the recipe template would cause a TemplateSyntaxError
exception.
(Bitbake rev: a53ffec4ed3d0f9221bca398e20e8f480fb2b325)
(Bitbake rev: bef6ef1a79b2d5a3688ae845824f722c332d7f19)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The local layer info (provided through custom fixtures) should
not be hidden. It is better to handle it in the same manner
as an imported layer, otherwise the layer path and dependency
info is not shown. The layer editing fields are handled in the
html side of things appropriately so this does not harm that
implementation.
[YOCTO #12891]
(Bitbake rev: 75918405346abde6055658372c1a954a214001cc)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a case where the layer source is local only and the recipe
is not yet built, we can search for the path with layer's
local_source_dir, and if available that should be used rather
than just skipping the scenario.
[YOCTO #12891]
(Bitbake rev: 30f622dbd874b800c5bbdbeac992dd7783092928)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change allows the CUSTOM_XML_ONLY toaster setting to be
provided through the environment so the user can do this without
mingling with the settings.xml, for scenarios where modifying
settings.xml is not achievable.
[YOCTO #12891]
(Bitbake rev: 87060a84e74125be10db062da3032e9b01f5dc96)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The release drop down divs are not being closed
appropriately, which showed adverse reactions on
the UI that aligned the "Create project" button
with the left edge of the screen without any
margins. This fixes these divs which in turn
aligns the button appropriately.
[YOCTO #12891]
(Bitbake rev: bc6a137f4f8193cadfa8a8d0e43875991d47a818)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There can be cases where the variables being used
to divide in build percentage expressions can be
zero. For example, a setup consisting of only local
repos will have repos_to_clone=0 and will generate
a divide by zero scenario.
Fix this by checking the divisor in such cases.
[YOCTO #12891]
(Bitbake rev: 30702f29928c3b088f199bf8b1609b2956f8c47a)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
TOASTER_DIR is used for higher level toaster artifacts
such the SQL DB and creating toaster internal build
directories for projects. Prior to this change it was
evaluated as `dirname $BUILDDIR` and user had no control
over it. This change allows to override this variable
from the command line for more flexibility. The variable
defaults to its original setting if the optional argument
is not passed.
[YOCTO #12891]
(Bitbake rev: e073775d3b6980fc8004ae28a3ccc3c5bbf50fb2)
(Bitbake rev: 486e571b1caaf7f86f8f969c512566487bcd9841)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current mechanism for finding the bitbake binary
assumes a directory structure which is identical to
poky, where oe-core's meta and bitbake directories are
at the same level. There can be a case where bitbake
is used from elsewhere and in such cases the above
mentioned assumption fails to hold, whereas this is
totally allowed by the oe-init-build-env script which
can take bitbakedir as an argument.
The better approach is to allow bitbake to be derived
from PATH, while keeping the older mechanism in place so
it can be removed after tests are done in various
environments. This makes more sense as toaster has
also been launched from the same bitbake instance
that is the one in PATH.
[YOCTO #12891]
(Bitbake rev: 15340edce23e63b060c75114d508e1f76757239c)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Toaster depends on pokydirname for identifying the location of
the oe-init-build-env script (and there might be other purposes
in the future). The problem with current approach is that it
only checks/sets the variable with git based repos, whereas
toaster provides mechanisms to allow having layers that are all
locally available. The evaluation of the variable fails in such
scenarios, so use a more flexible mechanism in this case and
try to locate poky in the local layers as well, if not already
set.
[YOCTO #12891]
(Bitbake rev: 971c728075af05e71edfd8e5212728c3dd0787b6)
Signed-off-by: Awais Belal <awais.belal@mentor.com>
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case something goes tragically wrong, catch a request to checksum / and
refuse.
(Bitbake rev: 7444419b7fda34e14d653ba8470f5dfabb5da4f3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Opening a file in binary mode and iterating it seems like the simple solution
but will still break on newlines, which for binary files isn't really useful as
the size of the chunks could be huge or tiny.
Instead, let's be a bit more clever: we'll be MD5ing lots of files, but we don't
want to fill up memory: use mmap() to open the file and read the file in 8k
blocks.
(Bitbake rev: 41e6161c8ce8cc90ebc93d72852673ae60fac923)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The actual dependency on native Python and is handled by inheriting
python3native
(From OE-Core rev: 115a6dea664c9b18fd19b79659029afb52b1a660)
(From OE-Core rev: 82b018956763bf85b90d512c8a6bc96d59fa67fd)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(perl #131844) fix various space calculation issues in
pp_pack.c
- for the originally reported case, if the start/cur pointer is in the
top 75% of the address space the add (cur) + glen addition would
overflow, resulting in the condition failing incorrectly.
- the addition of the existing space used to the space needed could
overflow, resulting in too small an allocation and a buffer overflow.
- the scaling for UTF8 could overflow.
- the multiply to calculate the space needed for many items could
overflow.
For the first case, do a space calculation without making new pointers.
For the other cases, detect the overflow and croak if there's an
overflow.
Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.
For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.
Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.
One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.
Note: changed
plan tests => 14713;
to
plan tests => 14712;
in a/t/op/pack.t
to apply this patch on perl 5.24.1.
Affects perl < 5.26.2
(From OE-Core rev: 0542779d2f1a8977a732800a8998fd88971c0c1d)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(perl #132227) restart a node if we change to uni rules within the node and encounter...
This could lead to a buffer overflow.
(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)
Affects perl >= 5.18 && perl <= 5.26
(From OE-Core rev: 109ffd1b3d10753bfd711a14ad59b194ca3ce831)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* CVE-2018-6798-1
The proximal cause is several instances in regexec.c of the code
assuming that the input was valid UTF-8, whereas the input was too short
for what the start byte claimed it would be.
I grepped through the core for any other similar uses, and did not find
any.
(cherry picked from commit fe7d8ba0a1bf567af8fa8fea128e2b9f4c553e84)
* CVE-2018-6798-2
The first patch for 132063 prevented the buffer read overflow when
dumping the warning but didn't fix the underlying problem.
The next change treats the supplied buffer correctly, preventing the
non-UTF-8 SV from being treated as UTF-8, preventing the warning.
(cherry picked from commit 1e8b61488f195e1396aa801c685340b156104f4f)
Affects perl >= 5.22 && perl <= 5.26
(From OE-Core rev: 4aaf09b9d657b1c2df85bf509008beacd6a00342)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qga: check bytes count read by guest-file-read
While reading file content via 'guest-file-read' command,
'qmp_guest_file_read' routine allocates buffer of count+1
bytes. It could overflow for large values of 'count'.
Add check to avoid it.
Affects qemu < v3.0.0
(From OE-Core rev: a11c8ee86007f7f7a34b9dc29d01acc323b71873)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* CVE-2018-1000030-1
[2.7] bpo-31530: Stop crashes when iterating over a file on multiple threads
* CVE-2018-1000030-2
Multiple threads iterating over a file can corrupt the file's internal readahead
buffer resulting in crashes. To fix this, cache buffer state thread-locally for
the duration of a file_iternext call and only update the file's internal state
after reading completes.
No attempt is made to define or provide "reasonable" semantics for iterating
over a file on multiple threads. (Non-crashing) races are still
present. Duplicated, corrupt, and missing data will happen.
This was originally fixed by 6401e56, which
raised an exception from seek() and next() when concurrent operations were
detected. Alas, this simpler solution breaks legitimate use cases such as
capturing the standard streams when multiple threads are logging.
Affects python <= 2.7.14
(From OE-Core rev: 4b6c84e0f950f839bfb8c40f197197f838d8b733)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
proc/readproc.c: Fix bugs and overflows in file2strvec().
Note: this is by far the most important and complex patch of the whole
series, please review it carefully; thank you very much!
For this patch, we decided to keep the original function's design and
skeleton, to avoid regressions and behavior changes, while fixing the
various bugs and overflows. And like the "Harden file2str()" patch, this
patch does not fail when about to overflow, but truncates instead: there
is information available about this process, so return it to the caller;
also, we used INT_MAX as a limit, but a lower limit could be used.
The easy changes:
- Replace sprintf() with snprintf() (and check for truncation).
- Replace "if (n == 0 && rbuf == 0)" with "if (n <= 0 && tot <= 0)" and
do break instead of return: it simplifies the code (only one place to
handle errors), and also guarantees that in the while loop either n or
tot is > 0 (or both), even if n is reset to 0 when about to overflow.
- Remove the "if (n < 0)" block in the while loop: it is (and was) dead
code, since we enter the while loop only if n >= 0.
- Rewrite the missing-null-terminator detection: in the original
function, if the size of the file is a multiple of 2047, a null-
terminator is appended even if the file is already null-terminated.
- Replace "if (n <= 0 && !end_of_file)" with "if (n < 0 || tot <= 0)":
originally, it was equivalent to "if (n < 0)", but we added "tot <= 0"
to handle the first break of the while loop, and to guarantee that in
the rest of the function tot is > 0.
- Double-force ("belt and suspenders") the null-termination of rbuf:
this is (and was) essential to the correctness of the function.
- Replace the final "while" loop with a "for" loop that behaves just
like the preceding "for" loop: in the original function, this would
lead to unexpected results (for example, if rbuf is |\0|A|\0|, this
would return the array {"",NULL} but should return {"","A",NULL}; and
if rbuf is |A|\0|B| (should never happen because rbuf should be null-
terminated), this would make room for two pointers in ret, but would
write three pointers to ret).
The hard changes:
- Prevent the integer overflow of tot in the while loop, but unlike
file2str(), file2strvec() cannot let tot grow until it almost reaches
INT_MAX, because it needs more space for the pointers: this is why we
introduced ARG_LEN, which also guarantees that we can add "align" and
a few sizeof(char*)s to tot without overflowing.
- Prevent the integer overflow of "tot + c + align": when INT_MAX is
(almost) reached, we write the maximal safe amount of pointers to ret
(ARG_LEN guarantees that there is always space for *ret = rbuf and the
NULL terminator).
Affects procps-ng < 3.3.15
(From OE-Core rev: 82d873a1b73da25ae415afe0e6203693f78b88c9)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
newgidmap: enforce setgroups=deny if self-mapping a group
This is necessary to match the kernel-side policy of "self-mapping in a
user namespace is fine, but you cannot drop groups" -- a policy that was
created in order to stop user namespaces from allowing trivial privilege
escalation by dropping supplementary groups that were "blacklisted" from
certain paths.
This is the simplest fix for the underlying issue, and effectively makes
it so that unless a user has a valid mapping set in /etc/subgid (which
only administrators can modify) -- and they are currently trying to use
that mapping -- then /proc/$pid/setgroups will be set to deny. This
workaround is only partial, because ideally it should be possible to set
an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
administrators to further restrict newgidmap(1).
We also don't write anything in the "allow" case because "allow" is the
default, and users may have already written "deny" even if they
technically are allowed to use setgroups. And we don't write anything if
the setgroups policy is already "deny".
Ref: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
Fixes: CVE-2018-7169
Affects shadow <= 4.5
(From OE-Core rev: a875522540372a4fa6658885692e564dfd729f54)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
submodule-config: verify submodule names as paths
Submodule "names" come from the untrusted .gitmodules file,
but we blindly append them to $GIT_DIR/modules to create our
on-disk repo paths. This means you can do bad things by
putting "../" into the name (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Affects: git < 2.13.7 and git < 2.14.4 and git < 2.15.2 and git < 2.16.4 and
git < 2.17.1
(From OE-Core rev: 229bb7cd70c79944d54696d50f4f34df85a5804a)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2017-18018-1:
doc: clarify chown/chgrp --dereference defaults
* doc/coreutils.texi: the documentation for the --dereference
flag of chown/chgrp states that it is the default mode of
operation. Document that this is only the case when operating
non-recursively.
CVE-2017-18018-2:
doc: warn about following symlinks recursively in chown/chgrp
In both chown and chgrp (which shares its code with chown), operating
on symlinks recursively has a window of vulnerability where the
destination user or group can change the target of the operation.
Warn about combining the --dereference, --recursive, and -L flags.
* doc/coreutils.texi (warnOptDerefWithRec): Add macro.
(node chown invocation): Add it to --dereference and -L.
(node chgrp invocation): Likewise.
Affects coreutils <= 8.29
(From OE-Core rev: a523bc6a2ff7d5b5415a789de02fb055ccd2c077)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
double64_init: Check psf->sf.channels against upper bound
This prevents division by zero later in the code.
While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.
CVE-2017-14634
Closes: #318
Affects libsndfile1 = 1.0.28
(From OE-Core rev: 00da7bad24cf78c9dba091b9e480515f25886b48)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sfe_copy_data_fp: check value of "max" variable for being normal
and check elements of the data[] array for being finite.
Both checks use functions provided by the <math.h> header as declared
by the C99 standard.
Fixes#317
CVE-2017-14245
CVE-2017-14246
Affects libsndfile1 = 1.0.28
(From OE-Core rev: 39b1dc89ce2870d1a2630b2319783a6203cbcb08)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patch original c_rehash script with Debian patch instead
of overriding it with own version.
Error output from c_reshah without patching:
Unknown regexp modifier "/b" at ./c_rehash line 15, at end of line
Unknown regexp modifier "/W" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/3" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/2" at ./c_rehash line 28, at end of line
No such class installdir at ./c_rehash line 63, near "Prefix our
installdir"
(Might be a runaway multi-line // string starting on line 28)
syntax error at ./c_rehash line 63, near "Prefix our installdir"
Can't redeclare "my" in "my" at ./c_rehash line 68, near ""
Execution of ./c_rehash aborted due to compilation errors.
(From OE-Core rev: f8a826f497073533a3e4c390255ae197d65d6ef3)
(From OE-Core rev: 4524d1f916b55db6d280ff51a41933b8ec9046b0)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Marko Peter <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The perlpath.pl script is used to patch the #! lines in all perl
scripts in the utils directory. However, as these scripts are run via
e.g. "perl foo.pl", they don't actually rely on the #! path to be
correct (which can be confirmed by the observation that the path is
currently being set to ${STAGING_BINDIR_NATIVE}/perl, which doesn't
exist).
(From OE-Core rev: ba88fe46d47846042518a5a1017d782ba548202c)
(From OE-Core rev: 1b0dcca0f083081295f32f09b408ab6c6c10f66f)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
