| Age | Commit message (Collapse) | Author |
|---|
|
It's handled by the rpm wrapper command, created in rpm recipe.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
To properly look at this patch, you probably need a side-by-side diff viewing tool.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
No need to store the configuration as class members,
just pass it directly into the method.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
instead of "all"
Too many places in dnf/rpm4 stack make that assumption; let's not fight against it.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
libdnf is required by dnf.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
This is the current C reimplementation/replacement of the original createrepo.
https://github.com/rpm-software-management/createrepo_c/wiki
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
The source code is incompatible with rpm4 API - let's use rpm
binary itself for now.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
This is required by libdnf.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
|
|
Also fixes a use before defined bug with localdata.
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.
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
libcomps is required by dnf.
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.
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.
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.
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.
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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.
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Alexander Kanavin <alexander.kanavin@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.
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.
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.
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.
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.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Fan Xin <fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Fan Xin <fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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]
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
* it was used only by bison-2.3 which was moved to meta-gplv2 layer
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Drop 0001-Split-libsolvext-into-it-s-own-pkg-config-file.patch
Signed-off-by: Alejandro del Castillo <alejandro.delcastillo@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Alejandro del Castillo <alejandro.delcastillo@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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 ]
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Otherwise cc may be used which isn't correct.
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.
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
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Avoids:
quilt-0.65-r0 do_package_qa: QA Issue: /usr/lib/quilt/ptest/quilt/scripts/edmail contained in package
quilt-ptest requires /media/build1/poky/build/tmp/hosttools/perl, but no providers found in
RDEPENDS_quilt-ptest? [file-rdeps]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If cc isn't in PATH, the recipe fails. Set a variable to avoid this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This triggers warnings about absolute symlink paths with the PATH changes.
In reality we simply don't need/care about these so just remove/disable
them.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Everything else in the system manages fine with rm, use rm instead of unlink
here too.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Alexander Kanavin
Jack Mitchell
Richard Purdie
Stephano Cetola
Ross Burton
Fan Xin
Joe Slater
Chen Qi
Martin Jansa
Alejandro del Castillo
Khem Raj