Hey Khem,
On 07/26/2018 08:36 PM, Khem Raj wrote:
On 7/25/18 9:05 AM, Alejandro Enedino Hernandez Samaniego wrote:
This patch enables multiconfig dependencies (mcdepends) to be used on
recipes using the following format:
task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-on"
On 07/31/2018 06:29 AM, Richard Purdie wrote:
On Mon, 2018-07-30 at 10:32 +0800, changqing...@windriver.com wrote:
From: Changqing Li
curl-config is generated to displays information about
the curl and libcurl installation. So the content is different
for 32bit and 64bit package. eg: maybe
Hi Richard
eSDK is actually a better technique for developers. But it’s only
suitable for those people who has experience on Yocto Project.
In the other hand, using dnf-nativesdk in meta-toolchain to customize
rootfs is easier fot those people who are familiar with dnf(I think
This patch causes a regression in multilib SDK for qemuarm64.
Error: Transaction check error:
file /usr/include/bits/wordsize.h conflicts between attempted installs of
lib32-libc6-dev-2.27-r0.armv7vet2hf_vfp and libc6-dev-2.27-r0.aarch64
Please consider sending a follow-up patch to fix this
The openssl Configure script will only select standalone makedepend
(vs running "$CC -M") when building with gcc < 3.x or with an Apple
Xcode version which predates the switch to clang (in approx 2010?).
Neither of these cases are possible when building under OE, therefore
the dependency on
On Mon, Jul 30, 2018 at 7:26 PM, wrote:
> On Thu, 2018-07-26 at 10:04 -0400, Bruce Ashfield wrote:
>> > https://autobuilder.yocto.io/builders/nightly-multilib/builds/1139/
>> > steps/BuildImages_4/logs/stdio
>> >
>> > Error: Transaction check error:
>> >file /usr/bin/libtool from install of
On Mon, Jul 30, 2018 at 3:23 PM, Richard Purdie
wrote:
> On Mon, 2018-07-30 at 14:44 -0700, Andre McCurdy wrote:
>> Currently the openssl 1.0 recipe defines a dependency on
>> hostperl-runtime-native and the openssl 1.1 recipe does not. Both run
>> "perl ./Configure ..." as part of
We keep breaking the preservation of hardlinks during the packaging process.
Add a selftest which tests this to try and prevent this breaking again.
Signed-off-by: Richard Purdie
---
.../selftest-hardlink/selftest-hardlink.bb| 19 +++
.../selftest-hardlink/hello.c
The devtool-source class moves all local files specified in SRC_URI to
an oe-local-files directory. When using devtool and a recipe space kernel-meta,
devtool modify throws an error because the paths the kernel-yocto class
is looking for feature directories in, don't include the oe-local-files
On 30 July 2018 at 23:29,
wrote:
> That said, is it not possible to just patch curl-config to use pkg-
> config instead and remove the differences between the two multilib
> cases, thereby solving this problem in a better way?
Prior art of this in Fedora:
Recent changes broke the preservation of hardlinks during processing due to a
missing index.
Fix this, reducing the size of the git recipe packages in particular (it
contains many hardlinks).
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 2 +-
1 file changed, 1
== Series Details ==
Series: "multilib_script: Add support f..." and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/13308/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
On Mon, 2018-07-30 at 10:32 +0800, changqing...@windriver.com wrote:
> From: Changqing Li
>
> curl-config is generated to displays information about
> the curl and libcurl installation. So the content is different
> for 32bit and 64bit package. eg: maybe for 32bit, use
> i686-linux-gnu-gcc, and
On Thu, 2018-07-26 at 10:04 -0400, Bruce Ashfield wrote:
> > https://autobuilder.yocto.io/builders/nightly-multilib/builds/1139/
> > steps/BuildImages_4/logs/stdio
> >
> > Error: Transaction check error:
> >file /usr/bin/libtool from install of libtool-2.4.6-r0.0.i586
> > conflicts with file
Whilst the package managers handle multilib ELF binaries well, they don't
handle scripts in the *bindir directories well. This adds support for
marking these up so that they can be handled using update-alternatives.
Its done this way so that non-multilib systems don't see any changes and
there is
Without this patch /usr/bin/libtoolize is different for each multilib
since their host-triplets are different, despite there being no difference in
the functionality of libtoolize itself.
This change just patches out the problematic line since its just a comment for
the user
in help text. Ugly
On Mon, 2018-07-30 at 14:44 -0700, Andre McCurdy wrote:
> Currently the openssl 1.0 recipe defines a dependency on
> hostperl-runtime-native and the openssl 1.1 recipe does not. Both run
> "perl ./Configure ..." as part of do_configure().
>
> Since hostperl-runtime-native is included in
== Series Details ==
Series: python2: Fix build with gcc8
Revision: 1
URL : https://patchwork.openembedded.org/series/13307/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the
From: Ross Burton
(From OE-Core rev: 910f68c9c8dc26e12d28ef29e956af63d100f121)
Signed-off-by: Ross Burton
Signed-off-by: Khem Raj
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
Signed-off-by: Martin Hundebøll
---
.../python/python-native_2.7.14.bb| 1 +
When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments that are
not necessarily in SRC_URI.
For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which
Currently the openssl 1.0 recipe defines a dependency on
hostperl-runtime-native and the openssl 1.1 recipe does not. Both run
"perl ./Configure ..." as part of do_configure().
Since hostperl-runtime-native is included in ASSUME_PROVIDED, is it
really useful for the openssl 1.0 recipe to list it
Add mtd-utils upstream patch that fixes a regression on the
mtd-utils tools such as ubinfo.
Details of the issue which affects mtd-utils 2.0.1 and 2.0.2:
http://lists.infradead.org/pipermail/linux-mtd/2018-June/081562.html
Upstream-Status: Accepted
Sure my builds with gold did not end up in the fails for qemuarm and thumb1
the setup is very similar but I might have been lucky let me know how it
goes
On Mon, Jul 30, 2018 at 7:53 AM Martin Jansa wrote:
> I'm not sure if it was caused by this change, but I've included it from
> patchwork on
We can and many toolchains do that especially in embedded targets but it
will cause more compile time to build binutils and size will grow a lot and
since we do not use universal binutils which can be shared across
architectures we will not benefit from this although it does mean our
binutils will
>> I have some questions, comments and suggestions about the
>> INCOMPATIBLE_LICENSE mechanism:
>>
>> 1. If I specify licenseX in INCOMPATIBLE_LICENSE then I get an error
>> when building a recipe with a package (packageA) that just
>> RRECOMMENDS a package (packageB) with licenceX, even if I add
== Series Details ==
Series: mtd-utils: Revert "Return correct error number in ubi_get_vol_in"
Revision: 1
URL : https://patchwork.openembedded.org/series/13302/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response.
On Mon, Jul 30, 2018 at 4:29 AM, Burton, Ross wrote:
> On 30 July 2018 at 08:55, Christopher Clark
> wrote:
> > Add x86_64-pep emulation support to the set enabled for x86_64 targets
> > to enable the linker to produce Portable Executables for EFI binaries.
> >
> > Enables building the x86-64
Add mtd-utils upstream patch that fixes a regression on the
mtd-utils tools such as ubinfo.
Details of the issue which affects mtd-utils 2.0.1 and 2.0.2:
http://lists.infradead.org/pipermail/linux-mtd/2018-June/081562.html
Upstream patch:
On 07/29/2018 10:10 PM, Joel Stanley wrote:
> v2: Add Upstream-Status tags
For sumo too ?
- armin
>
> This series has a pair of patches that we have been using in OpenBMC's
> Yocto tree for a few weeks. The build fix is required to compile from
> our ppc64le build machines.
>
> The std::pair
On 07/30/2018 08:55 AM, Burton, Ross wrote:
> Wouldn't it be better to fix bluez? It's crashing
The quick search I did over the weekend found Mips is not listed as a
supported platforms on bluez.org. So it may be a case of adding support
for Mips for bluez.
So are you going to hold up the
Wouldn't it be better to fix bluez? It's crashing
Ross
On 30 July 2018 at 16:04, Armin Kuster wrote:
> do_page_fault(): sending SIGSEGV to bluetoothd for invalid read access from
> 0030
> [ 21.402249] epc = 00852c3a0438 in libc-2.27.so[852c31+19b000]
> [ 21.402505]
All,
The triage team meets weekly and does its best to handle the bugs reported into
the bugzilla. The number of people attending that meeting has fallen, as have
the number of people available to help fix bugs. One of the things we hear
users report is they don't know how to help. We (the
do_page_fault(): sending SIGSEGV to bluetoothd for invalid read access from
0030
[ 21.402249] epc = 00852c3a0438 in libc-2.27.so[852c31+19b000]
[ 21.402505] ra = 00852c3ae0cc in libc-2.27.so[852c31+19b000]
This causes the xorg testcase to fail.
[Yocto #12845]
I'm not sure if it was caused by this change, but I've included it from
patchwork on Friday and since then I've seen 3 builds getting stuck in gcc
for 50 hours.
In all 3 cases it was qemuarm (with thumb and gold enabled), twice while
building bash and once building libjpeg-turbo. I will let you
Got it. Thank you for the prompt response.
On Mon, Jul 30, 2018 at 10:18 AM Burton, Ross wrote:
> devtool add's primary convenience is how it can examine the source and
> write the LICENSE correctly, the correct inherits, etc. If you're
> just going to install a few files then just write a
That's a complicated patch to enable tests that we don't enable. Can
you get it upstream first so we're not carrying this?
Ross
On 12 July 2018 at 09:46, wrote:
> From: Mingli Yu
>
> * When enable the test as below in nfs-utils recipe,
> do_compile_append_class-target () {
>
devtool add's primary convenience is how it can examine the source and
write the LICENSE correctly, the correct inherits, etc. If you're
just going to install a few files then just write a recipe from
scratch.
Ross
On 30 July 2018 at 15:10, Adam Lee wrote:
> Is it possible to run 'devtool add
Thank you. Both works well!
On Wed, Jul 25, 2018 at 12:34 PM Khem Raj wrote:
> On Tue, Jul 24, 2018 at 10:51 AM Andre McCurdy
> wrote:
>
>> On Tue, Jul 24, 2018 at 6:52 AM, Adam Lee wrote:
>> >
>> > How do I defined a custom include path for an autotools recipe?
>> >
>> > This may as well be
Is it possible to run 'devtool add [recipe-name]' without 'srctree' or
'fetchuri'?
I just want to add a simple recipe with a few files to be installed on the
target file system.
I can directly add a file in my meta-layer, but devtool is probably the
more correct approach.
Adam
--
2018-07-30 8:48 GMT+02:00 ChenQi :
> I just noticed that we are using sysklogd as the default syslog.
> meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb:VIRTUAL-RUNTIME_syslog
> ?= "sysklogd"
>
> sysklogd has stopped development for about 4 years, and as far as I can see,
>
Is just passing --enable-targets=all not an option?
Ross
On 30 July 2018 at 08:55, Christopher Clark
wrote:
> Add x86_64-pep emulation support to the set enabled for x86_64 targets
> to enable the linker to produce Portable Executables for EFI binaries.
>
> Enables building the x86-64 EFI
Hi Richard,
What is the current status of this upgrade? I have made same additional
syncing with master. So the question is, if there are some additional
issues... .
Cheers,
Andrej
On 07/17/18 11:10, Andrej Valek wrote:
> Changes:
>
> [v4]
> - just resend series
>
> [v5]
> - sync dofile.pl
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.
Signed-off-by: Chen Qi
---
meta/recipes-core/busybox/busybox/defconfig | 12 ++--
meta/recipes-core/busybox/busybox/init.cfg
The following changes since commit 1b56227d77d3113c9c17ec35cb7849a768078c4e:
classes/package: fix variable name in comment (2018-07-26 17:14:42 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/busybox-init
== Series Details ==
Series: "[sumo] linux-firmware: add ${P..." and 2 more
Revision: 1
URL : https://patchwork.openembedded.org/series/13295/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
If kdump.service is set to run on boot and dump-capture kernel isn't
placed in /dev/root, kdump.service will fail to load the kernel,
since other partitions are not mounted yet. Starting kdump.service
after basic.target guarantees dump-capture kernel can be loaded in
this situation.
* the license was updated
brcm/brcmfmac43430-sdio.bin:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=ec734a30
brcm/brcmfmac43340-sdio.bin:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=5ac5ad5c
* no changes in the content of previously existing packages
* include some silly commands I've used to "parse" WHENCE file to
generate these, some manual changes are still needed, like separating
cypress licensed files, removing duplicates when 2 files are included
in the same package
* this will break meta-raspberrypi once more, by including
${PN}-cypress-license package twice in PACKAGES
I've sent fix here:
https://github.com/agherzan/meta-raspberrypi/pull/295
Signed-off-by: Martin Jansa
---
.../linux-firmware/linux-firmware_git.bb | 12
1
Add x86_64-pep emulation support to the set enabled for x86_64 targets
to enable the linker to produce Portable Executables for EFI binaries.
Enables building the x86-64 EFI variant of the Xen hypervisor for
the OpenXT Project.
Signed-off-by: Christopher Clark
---
Changes in v6: added required
It can be compiled for aarch64, so deleted the limit for aarch64.
Signed-off-by: Lei Maohui
---
meta/recipes-kernel/sysprof/sysprof_3.26.1.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-kernel/sysprof/sysprof_3.26.1.bb
b/meta/recipes-kernel/sysprof/sysprof_3.26.1.bb
Hi All,
I just noticed that we are using sysklogd as the default syslog.
meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb:VIRTUAL-RUNTIME_syslog
?= "sysklogd"
sysklogd has stopped development for about 4 years, and as far as I can
see, nobody is maintaining it.
Is there
V2 is good to install
On Sun, Jul 29, 2018 at 9:42 PM Joel Stanley wrote:
> C++ applications that contain a specfic use of std::pair with tempates
> cause the build to require many gigabytes of RAM to build.
>
> This is a fix that was applied to the upstream GCC 7 branch.
>
> Change-Id:
53 matches
Mail list logo
