Installing python3-modules should install *all* of the Python standard library,
not just most of it.
(From OE-Core rev: b2c1c48d90aa9a94f90836557856e0319ddcb524)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This removes unnecessary spaces inserted before semicolons in the
modified USERADD_PARAM_${PN} and GROUPADD_PARAM_${PN} variables. This
should not affect the handling of the variables as the only one that
actually sees the semicolons is the code in useradd.bbclass that uses
cut to split the variables at them, and any whitespace preceeding or
following the semicolons will be properly ignored.
(From OE-Core rev: acc17ef91a6f506e3cacdc0d4ebfa268b3f3affd)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Read and merge the passwd/group files before parsing the user and
group definitions. This means they will only be read once per
recipe. This solves a problem where if a user was definied in multiple
files, it could generate group definitions for groups that should not
be created. E.g., if the first passwd file read defines a user as:
foobar:🔢:::
and the second passwd file defines it as:
foobar:::nogroup:The foobar user:/:/bin/sh
then a foobar group would be created even if the user will use the
nogroup as its primary group.
(From OE-Core rev: 3149319ad997379a01d87f2b1b5d14f66541997f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original code was near impossible to follow, and missed a couple
of cases. For example, if one added the following line to the passwd
file specified in USERADD_UID_TABLES:
foobar❌12345:nogroup::/:/bin/sh
and then specified the user as:
USERADD_PARAM_${PN} = "--system foobar"
one would then assume that the foobar user would be created with the
primary group set to nogroup. However, it was not (the primary group
would be foobar), and the only way to get it correct was to explicitly
add --gid nogroup to the USERADD_PARAM_${PN}.
(From OE-Core rev: e98e98ce65cf9ffdef29462310a622ffddd1412b)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The [<on_true>, <on_false>][not <condition>] construct may solve the
problem of implementing a conditional operator, but it is not very
readable. At least I find this:
uaargs.groupid = field[3] or uaargs.gid or uaargs.groupname
a lot more readable than this:
uaargs.groupid = [uaargs.gid, uaargs.groupname][not uaargs.gid]
uaargs.groupid = [field[3], uaargs.groupid][not field[3]]
Also, the official conditional operator since Python 2.5 (<on_true> if
<condition> else <on_false>) does not evaluate both <on_false> and
<on_true> as [<on_true>, <on_false>][not <condition>] does.
(From OE-Core rev: 274d38a6e2183ec88335a08b963f26c34b328558)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If --no-user-group is specified in USERADD_PARAM_${PN} for a user and
no --gid is specified, then we should not assume that the group name
for the user is the user name.
(From OE-Core rev: 0e5402c433739a416a76df532378533cb25365c7)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The useradd options --create-home/--no-create-home and
--user-group/--no-user-group are mutually exclusive and should be
treated as such.
(From OE-Core rev: 908eca7fb4af8a60026f53e2bb2cf1d5daf089ab)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog: http://alsa-project.org/main/index.php/Changes_v1.0.29_v1.1.0
The most significant change is probably the addition of the "topology
API", which is used to change the DSP topology from userspace. My
understanding is that the API is (or will be) needed to support some
new hardware, but I don't know any specifics about that.
Rebased Check-if-wordexp-function-is-supported.patch.
Dropped 0001-build-Do-not-try-to-detect-cross-compiler.patch, since it
is included in the new release.
(From OE-Core rev: 13a2786493bd91a54e3a5342da11c06a9b6c99b8)
Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit in gtk+ moved the cache files below <libdir>
"
commit c8849046860a9b17fa943247d85ddadb29262b48
Author: Matthias Clasen <mclasen@redhat.com>
Date: Thu Jul 4 09:27:17 2013 -0400
Move the module cache files below libdir
These files contain architecture-dependent paths, and thus placing
them into sysconfdir causes unnecessary hassle. Now the immodule cache
file is looked for in libdir/gtk-2.0/2.10.0/immodules.cache.
Belated backport of a change that was done in the run-up to 3.0.
"
Since gtk-immodules-cache.bbclass creates the cache file in
"/etc/gtk-2.0/gtk.immodules", the environment variable "GTK_IM_MODULE_FILE"
can be set to point GTK+ at the file.
[YOCTO #6774]
(From OE-Core rev: d83d6ef50e6736d3c5f75050a01d5811a2a668f7)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License checksum changed because text layout changed.
(From OE-Core rev: 243ccaceee9bab9c8f1021a1502c07e1055614e6)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License checksum changed because of text layout change.
(From OE-Core rev: 5afb75e552573dda6770c59b5eed2d1be0bb26f7)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 4.4 kernel has been under test via linux-yocto-dev, and is the next
LTS/LTSI kernel.
So we take our -dev support and created a named/versioned recipe for use
in upcoming releases.
(From OE-Core rev: 2dbc788bc3988532f0932e8e51e24ba702c28f6a)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade to 1.43 (master) to make "mke2fs -d" support xattr, so that the
layer which requires xattr such as meta-selinux can populate images
easily.
* Remove the following patches since they are alredy in the source.
0001-e2fsprogs-fix-cross-compilation-problem.patch
0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch
0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch
0002-misc-create_inode.c-copy-files-recursively.patch
0003-misc-create_inode.c-create-special-file.patch
0004-misc-create_inode.c-create-symlink.patch
0005-misc-create_inode.c-copy-regular-file.patch
0006-misc-create_inode.c-create-directory.patch
0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch
0008-mke2fs.c-add-an-option-d-root-directory.patch
0009-misc-create_inode.c-handle-hardlinks.patch
0010-debugfs-use-the-functions-in-misc-create_inode.c.patch
0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch
0012-Fix-musl-build-failures.patch
CVE-2015-0247.patch
copy-in-create-hardlinks-with-the-correct-directory-.patch
fix-icache.patch
misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch
* Remove cache_inode.patch since it is not needed any more
* Updated mkdir.patch and ptest.patch
* Add --enable-libblkid to EXTRA_OECONF since libblkid is not created by
default.
* Time of core-image-sato-sdk do_rootfs:
- Before upgrade
real 3m18.508s
user 7m42.088s
sys 1m1.984s
- After upgrade
real 3m21.552s
user 7m38.496s
sys 1m0.644s
The are nearly the same
* The "fsck -f" shows the image is OK, and also can boot.
[YOCTO #8622]
(From OE-Core rev: a1f235ad736d322bb50eb4a4293b6b2f4e5200aa)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in native.bbclass adds -native suffix to the package
names that don't have it.
Renamed python-native-runtime -> hostpython-runtime-native to avoid
mangling it and to conform with the naming convetion for native
packages.
(From OE-Core rev: 8a474057d86b3ebf6271656d6b9adf384ea9ad6d)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When set PATCHTOOL = "patch" in conf/local.conf an error will occur
in the step of do_patch.
The error is: "quilt: command not found", so fix the missing
dependency.
(From OE-Core rev: 3cc6b73f9feaa1f09edd649060e63f5143d7cd15)
Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To be compatible with ncurses 5, add option '--with-abi-version=5' to EXTRA_OECONF
(From OE-Core rev: 743e97cc80744ca88d72b8db0ee95bb58f350ef9)
Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The absolute path (/path/to/configure) caused VPATH in Makefile to be an
absolute path, and then it will be in elf files, use relative path to
run configure can fix the problem.
This will reduce a lot of buildpaths QA issues in a world buld.
[YOCTO #8894]
(From OE-Core rev: 2c6ad43af0a0c4db5d7fd342be8585bec66debfb)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For a bare-bone kernel recipe which specifies 32 bit x86 target,
a 64 bit .config will be generated from do_configure task when
building 32-bit qemux86, once all of these conditions are true:
* arch of host is x86_64
* kernel source tree used in build has commit ffee0de41 which
actually chooses i386 or x86_64 defconfig by asking host when
ARCH is "x86" (arch/x86/Makefile)
* bare-bone kernel recipe inherits directly from kernel without
other special treatments.
Build will fail because of the mismatched kernel architecture.
The patch sets ARCH i386 or x86_64 explicitly to configure
task to avoid this host contamination. Kernel artifact is also
changed so that it can map i386 and x64 back to arch/x86 when
needed.
(From OE-Core rev: 8d310b24927d0f348fb431895f0583733db2aad0)
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
IMAGE_TYPES_MASKED support was accidentally removed. The original
idea behind it was to remove some of the hardcoding in the core
image code, so do that for image-live and ensure the dependency
and masked variables correctly reflect the needs of the class.
This means we can remove all the hardcoded special cases since
image-vm already has the needed markup.
(From OE-Core rev: 9a2d4a3b8d7bb1cf7f1fb7fe47d5c002d9941c89)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a base image type has an implicit dependency (from IMAGE_TYPEDEP)
this has to be taken into account. This is a regression introduced by
OE-Core:c2dab18 (image: Create separate tasks for rootfs construction).
The issue has been found when building meta-fsl-arm based images which
does not include the rootfs image type explicitly in IMAGE_FSTYPES but
instead is added, using IMAGE_TYPEDEP, for the 'sdcard.gz' image.
Reported-by: Fabio Berton <fabio.berton@ossystems.com.br>
(From OE-Core rev: 191c7be3a6cc52911f244323072433f6a1172bf1)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The autoscan script uses the File.pm module which was missing in the
list of RDEPENDS. This caused autoscan to fail with
% autoscan
[...]
Can't locate File/Find.pm in @INC [...]
(From OE-Core rev: a13fb3c193199e06bc36613eee3db7b028595015)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE checksum changed due to an updated file listing in debian/copyright
(From OE-Core rev: 1b9e9e5086998fdd0ef92e300148234cd99c5f42)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a separate task where we can just have the recursive dependencies
for the tasks corresponding to constructing the SDK content (i.e. from
the image contents). This avoids us recursing into dependencies from
buildtools and getting a bunch of nativesdk stuff, for example.
(This isn't an ideal way to have to implement it, but without
overcomplicating things on the BitBake side just for this use-case I
can't see a better way.)
(From OE-Core rev: eabeb26335b1a4eb1e68218160dbdbe8fdf36272)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using package_qa_handle_error(), we need to check QA_SANE and
give a fatal error if issues were raised. The main insane checks do
this, the anonymous python in insane does not, nor does the code in
package.bbclass. This was likely missed when the function was
introduced to package.bbclass.
The impact is that errors can be shown but don't stop the build
(do_package succeeds), the initial build fails due to the errors
shown but subsequent builds succeed. This is clearly broken.
The solution is to check QA_SANE in places we use the handle_error
function.
[YOCTO #8907]
(From OE-Core rev: 7e36d13212763fe409747aba011c020c9aeba6d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the change to use --setscene-only when running bitbake to prepare
the SDK at the end of installation, add a check that the SDK got
prepared correctly by doing a dry-run and looking at the output for any
real tasks that we don't expect. In order to make this easier, the
preparation shell script was rewritten in python.
(From OE-Core rev: 2306683634435b990e63020fc5cf91753bbaf7b6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These form part of the configuration for the extensible SDK, we should
really be recording what goes into them.
(From OE-Core rev: bd1557bfd726e44c23ab6220867119c57ac6b596)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If auto.conf exists in the user's configuration we need to also run it
through the same filter and write the result into the ext SDK, or we
risk missing configuration applied on an autobuilder.
Fixes [YOCTO #8904].
(From OE-Core rev: fb0a34a00f3eb10935a3fca4d0af74ae4de4f9a5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there is no newline at the end of local.conf, appending
INHERIT = "uninative" won't work, it will corrupt the line and the
installed eSDK will build things, making the "Preparing build system..."
step take an age.
Fixes [YOCTO #8897].
(From OE-Core rev: 1e641f09e8cf0ba716c3d2aade0845abecc27827)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If pam is not present in DISTRO_FEATURES, then exclude
util-linux-runuser from PACKAGES to avoid its libpam dependency.
(From OE-Core rev: 9ba9807fc7c19938022c37641b171464699fc742)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove fix-build-command-line-argument-with-gnutls.patch which is
already in the source.
* Add libgcrypt to DEPENDS since it depends on it.
(From OE-Core rev: 119a121e4dbf48db67544c4c7fca40a1abcf1146)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove fix_makefile.patch, it is already in the source.
(From OE-Core rev: f2a4a5e7e237fd0a3ab13a16f2674c41e1a3c853)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
