To properly look at this patch, you probably need a side-by-side diff viewing tool.
(From OE-Core rev: 65581c68d130fa74d703f6c3c92560e053857ac7)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously they were swapped, not sure why. Their meaning, as far as rpm
world goes, is different:
- Recommends is a soft dependency and will be installed by default; there is
an option not to do that.
- Suggests is a suggestion to be picked up and presented to end user by
package management tools; it has no special meaning otherwise.
OE packages use RRECOMMENDS, which should be mapped to Recommends rpm tag,
so that the packages will be picked up as dependencies.
(From OE-Core rev: 06270f20ba4312d20d0fd348595adf1b239bcac5)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
No need to store the configuration as class members,
just pass it directly into the method.
(From OE-Core rev: a5cc38481be3c5e6ccbecf951f9fdc049e5101d5)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Too many places in dnf/rpm4 stack make that assumption; let's not fight against it.
(From OE-Core rev: 341810aff923ace6b1cc1e15e19383c4f8773b51)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Version 6.x of Berkeley DB has been rejected by open source community due to its hostile
AGPLv3 license; both Fedora and Debian are sticking with db 5.x - and by extension,
all the open source projects are still developed and tested with db 5.x
In oe-core the only thing that was requiring db 6.x was rpm 5.x, and so there's no reason
to continue carrying db 6.x in oe-core. If someone needs API features that are only available in
db 6.x, it can be re-added to meta-oe.
(From OE-Core rev: 2694de76542840f79e3953c546d07b8ae479b8a1)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is replacing Smart package manager, which is unsupported upstream, and has a growing
amount of issues (lack of python 3.x support in particular). We identified dnf as
the only feasible replacement.
(From OE-Core rev: 2da1f03ad5957fc130f9d4fac30f0048873e9d7c)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libdnf is required by dnf.
(From OE-Core rev: 8ac3fb682928aeb076c8f78fb429936ae747bc77)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dnf stack is written and tested against rpm 4.x. So if we want to use dnf for packaging,
we should also use rpm 4 - there's simply too much work involved in making rpm 5 work with it due
to significant API differences, and supporting that going forward.
(From OE-Core rev: 2358e786ec8d1199d90e181eb5d8d00816f669b4)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the current C reimplementation/replacement of the original createrepo.
https://github.com/rpm-software-management/createrepo_c/wiki
(From OE-Core rev: 30e0bec70f7793a5f923fc22c56b12bc1d06027d)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The source code is incompatible with rpm4 API - let's use rpm
binary itself for now.
(From OE-Core rev: 127112fa05c7102dacda4173adf380c557bacecb)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is required by libdnf.
(From OE-Core rev: c1d008066f36701b8a8f36ddaeaa626ca6427aed)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rpm4 installs them in different locations than rpm5. This also replaces
our custom rpmdeps-oecore with standard rpmdeps; I'm not seeing a
significant performance penalty.
(From OE-Core rev: ec20cda53caeebfdf95e2871d5da8b926e84d2aa)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the regular expression for matching a variable name was amended
with allowing the ~ character as part of the variable name, this was
never done to the regular expression that matches export
lines. Similarly, the regular expression that was used for matching
unset variables also used the one without support for the ~ character.
This unifies the regular expressions. For good measures it also
corrects the regular expression used to match a variable flag name for
the unset command to match the one used when setting a variable flag.
(Bitbake rev: acd2fd74ed467dc85ec75d5d0815f43e493f29bf)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some reason, BBProgress.setextra() always adds a space at the end.
This prevents the task progress bars from filling the entire width of
the terminal, making them stop one character short. This looks odd
when shown together with the main progress bar, which does fill the
entire terminal width.
(Bitbake rev: 6540e98090d6a88607489a23c063be338bcc3b57)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For example:
$ bitbake core-image-minimal --runall unpack
...
NOTE: Tasks Summary: Attempted 326 tasks of which 88 didn't need to be rerun and all succeeded.
$ bitbake core-image-minimal --runall patch
NOTE: Tasks Summary: Attempted 453 tasks of which 332 didn't need to be rerun and all succeeded.
This can replace fetchall as well:
$ bitbake core-image-minimal --runall fetch
NOTE: Tasks Summary: Attempted 135 tasks of which 119 didn't need to be rerun and all succeeded.
(Bitbake rev: 7c0fa6ba66cdb956b37d94055307cde857633df9)
Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also fixes a use before defined bug with localdata.
(From OE-Core rev: 86b09a7ed67a43a45c805f44778bed0bfdf57361)
Signed-off-by: Jack Mitchell <jack@embed.me.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a race condition in the uboot-extlinux bbclass where
only a half written extlinux.conf would be put in the deploy
directory. Fix this by adding the deploy task after the do_install
rather than after the do_compile.
(From OE-Core rev: 60c90398580998b2379bb438f0f75b29285135a5)
Signed-off-by: Jack Mitchell <jack@embed.me.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we filter out PATH to only the utilities we rely upon, the devshel
terminal was broken since it can no longer find the terminals. Even if
we fix that, the user couldn't access any of their commands within
devshell which somewhat defeats its purpose.
Add the original PATH back to the environment to restore that behaviour
since this is more in line with user expectations and it wouldn't be possible
(or desireable) to whitelist all the commands a user might want to use from
the shell.
(From OE-Core rev: 67d7ea2db8bce766daf3419feae3cd8045af5114)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libcomps is required by dnf.
(From OE-Core rev: a47e64d985a610535449730806651f5bfd75d9ec)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
librepo is needed by dnf and libdnf.
(From OE-Core rev: 64dd708d14f8eadb25c3b590bfdc894e2cbb246e)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is needed by dnf, and only when using Python 2.x, so can
be dropped after moving dnf/rpm4 stack to Python 3.x.
(From OE-Core rev: e58f876acdac8fff24ecd3076287eda61ef1e4d3)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-iniparse is required by dnf.
(From OE-Core rev: 6c6f1b318005f4f2e21027b308ab6cb89aefdd19)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-pygpgme is required by dnf.
(From OE-Core rev: 20004b271eb4faf5f91f30ec3565a73ee62df7c6)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As of this commit:
39f5a05152aa0c3503735e18dd3b4c066b284107
patchelf no longer inflates file sizes. Since the files are no longer
inflated by patchelf, we can skip using cp with the --sparse option.
More details as to how patchelf has changed are available in that
commit log.
(From OE-Core rev: a2519a2f96bfea53a527c704e620e3584c97c67d)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is causing a problem in multilib where base-files and lib64/32-base-files
clash because they may have different dates. Also, if the package is coming
from sstate it has an incorrect date anyway.
(From OE-Core rev: 846c86ffc4574feafd89a028e50f7719075633f2)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As it varies from one machine to another.
(From OE-Core rev: e34ac7634a6d1f110ee4748de813e7b1fd89d119)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's a machine-specific script, which is causing conflicts
when multiple versions of bash are installed in multilib setting,
and it also does not really make sense for embedded systems anyway.
(From OE-Core rev: dbe57bd0aec855c81b03850367b3b483f622c328)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise it will cause conflicts in mutlilib setting, as it
varies from one machine to another.
(From OE-Core rev: a3b19882e2f50089c785b1e2591550356c12a175)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the GIO tests would be built or not depending on whether the host had
a dbus-daemon binary available. Fix this by seeding the AC_CHECK_PROGS check
with the right value, and adding a RDEPENDS for dbus-daemon on the target.
(From OE-Core rev: 1944c9a1764105c15844c7dbf1d430389c02b631)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This preserves the current behaviour because the auto
test by configure will never return yes. ./libtool is
needed by the test and it will never exist.
(From OE-Core rev: ad151cf2de2f1990297e7ba18fa78958b00a3dd3)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bump to latest revision so that update-alternatives could detect priority
conflict.
Also, we could remove the following patch because opkg-utils has already
fixed the problem in another way.
0001-Makefile-use-defined-bindir-and-mandir-as-installati.patch
[YOCTO #8314]
(From OE-Core rev: d6b04e12127dd65b96ac7f4509b829510ef21071)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we are both having a bootloader and a U-Boot environment file, we
can end up with two entries using "--source rawcopy" and "--no-table",
and since they reuse the same file [1], their cleanup handlers will
try to delete the same file twice. So make sure we only do it once.
[1] Although they reuse the same file, the resulting output is
correct, so it appears the file is accessed in properly sequential
order.
(From OE-Core rev: f1a3eac376c4600cdb128d870ad9b7e9d51ed9c0)
Signed-off-by: Kristian Amlie <kristian.amlie@mender.io>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it was used only by bison-2.3 which was moved to meta-gplv2 layer
(From OE-Core rev: 12aa82b8b07b03d20e63479469faca6562c78a05)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop 0001-Split-libsolvext-into-it-s-own-pkg-config-file.patch
(From OE-Core rev: 45de201af696aba70a1eba1573283790947efc54)
Signed-off-by: Alejandro del Castillo <alejandro.delcastillo@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libsolv backend is vastly superior than the currently enabled
internal ad-hoc solver. While the switch does have a small impact on
disk and memory footprint, it make sense to change the default as for
most cases the disk/memory footprint hit should be acceptable.
========================
Disk Footprint Increase
========================
qemux86-64 523K
qemuarm 445K
qemux86 576K
====================================================
Command [1] Libsolv Internal Solver
====================================================
opkg update 26.21 MB 26.21 MB
opkg list 29.87 MB 29.87 MB
opkg install procps 30.99 MB 27.33 MB
opkg remove procps 1.69 MB 1.69 MB
opkg update 30.97 MB 27.75 MB
[1] Profile done via 'valgrind --tool=massif <command>' in a feed with
~18K packages.
(From OE-Core rev: 1ff3de844c78e3766c7f92ca17c308ef3c9427e1)
Signed-off-by: Alejandro del Castillo <alejandro.delcastillo@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class lets you use BBCLASSEXTEND to add a variant of the recipe that
fetches from an alternative URI (such as git:) instead of a tarball.
For example:
BBCLASSEXTEND = "devupstream:target"
SRC_URI_class-devupstream = "git://git.example.com/example"
SRCREV_class-devupstream = "abcd1234"
This variant will have DEFAULT_PREFERENCE set to -1 so it needs to be selected
to be used, and any development-specific tweaks can be done with the
class-devupstream override, for example:
DEPENDS_append_class-devupstream = " gperf-native"
do_configure_prepend_class-devupstream() {
touch ${S}/README
}
It currently only supports creating a development variant of the target recipe,
not native or nativesdk. The BBCLASSEXTEND syntax (devupstream:target) was
chosen so that support for native and nativesdk can be added at a later date.
Support for other version control systems such as subversion is limited, as
bitbake's automatic fetch dependencies on for example subversion-native are not
generated.
[ YOCTO #10215 ]
(From OE-Core rev: c48ef2d7c7198232846f36a975c673cc57f4a090)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We currently have a determinism problem in that the host tools present
in PATH can influence the build. In particular, the presence of pkg-config
on the build host can mask missing pkgconfig class dependencies.
This adds in a new HOSTTOOLS variable and then uses it to set up a directory
of symlinks to the whitelisted host tools. This directory is placed as PATH
instead of the usual /usr/bin:/bin and so on.
This should improve determinism of builds and avoid the issues which have
been particularly obvious since the introduction of recipe specific sysroots.
If users find there is a tool missing, they can extend HOSTTOOLS from a global
class or global conf file.
Right now the settings should be enough to build everything in OE-Core.
(From OE-Core rev: fa764a403da34bb0ca9fa3767a9e9dba8d685965)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise cc may be used which isn't correct.
(From OE-Core rev: 30a9f0fcf608815cc920de4aba8ec0d1cf467b07)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE needs to be able to change the default compiler. If we pass in HOSTCC
through the make command, it overwrites not only this setting but also the
setting in tools/Makefile wrapped in ifneq ($(CROSS_BUILD_TOOLS),) which
breaks the build.
We therefore add a way of changing the default in the top level Makefile
without interfering with the other setting.
I've emailed this workaround to Masahiro Yamada for discussion.
(From OE-Core rev: e777d6873ce9a8a80288ecbcfc86239e0ed0e2f9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* This is converging the recipes for go from
meta-virtualization and oe-meta-go
* Add recipes for go 1.7
* go.bbclass is added to ease out writing
recipes for go packages
* go-examples: Add an example, helloworld written in go
This should serve as temlate for writing go recipes
* Disable for musl, at least for now
* Disable for x32/ppc32 which is not supported
(From OE-Core rev: 78615e9260fb5d6569de4883521b049717fa4340)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Figuring how the correct commandline isn't trivial, improve the help
text with RSS in mind.
(From OE-Core rev: 056a9da9f3ac2bc175f19243b11864ca90eee28b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alexander Kanavin
Peter Kjellerstedt
Matthew McClintock
Jack Mitchell
Richard Purdie
Stephano Cetola
Ross Burton
Fan Xin
Joe Slater
Chen Qi
Kristian Amlie
Martin Jansa
Alejandro del Castillo
Khem Raj