Hi,
I have seen the two commits from meta-mingw layer upstream:
f49ac31f64a1adffaeb9706eb552dab66b4baff2
a07fe304228b7f41b5558de7d8f39fd5e8a430d2
, and I haven't updated the git repo for this layer in my local machine.
These two patches fixed the issue, so the patches from me are not needed
busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
Signed-off-by: Peter Kjellerstedt
---
meta/recipes-core/busybox/busybox.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index
Replaces usage of the deprecated oe.utils.getstatusoutput() with Python
subprocess calls.
Signed-off-by: Joshua Watt
---
meta/classes/package.bbclass | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/meta/classes/package.bbclass
On Sun, Aug 19, 2018 at 7:19 PM ChenQi wrote:
>
> There's a build failure on autobuilder.
>
> https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/700/steps/BuildImages/logs/stdio
>
I pushed a patch to pull branch which should fix it
From: Changqing Li
remove the indirect dependcy of autoconf-archive-native via
SSTATE_EXCLUDEDEPS_SYSROOT to avoid not needed .m4 installed
into sysroot, which may cause compile problem.
Signed-off-by: Changqing Li
---
meta/conf/layer.conf | 4 +++-
1 file changed, 3 insertions(+), 1
There's a build failure on autobuilder.
https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/700/steps/BuildImages/logs/stdio
| x86_64-poky-linux-musl-g++ -m64 -march=core2 -mtune=core2 -msse3
-mfpmath=sse
The requirement is to put logs into directories other than /var/log.
Could it be achieved by modifying the syslog daemon configuration file
(e.g. /etc/syslog.conf) to replace /var/log with the specified
directory. Maybe the corresponding logrotate configuration file also
needs to be modified.
== Series Details ==
Series: sstate: Avoid indirect autoconf-archive-native dependencies (via
SSTATE_EXCLUDEDEPS_SYSROOT)
Revision: 1
URL : https://patchwork.openembedded.org/series/13601/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
Signed-off-by: Hongxu Jia
---
...t-we-are-not-reading-past-end-of-a-buffer.patch | 65 ++
...001-asm-eval.c-Avoid-possible-divide-by-0.patch | 40 +
.../0001-assemble-Check-global-line-limit.patch| 50 +
From: Changqing Li
remove the indirect dependcy of autoconf-archive-native to avoid
not needed .m4 installed into sysroot, which may cause
compile problem.
Signed-off-by: Changqing Li
---
meta/conf/layer.conf | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
== Series Details ==
Series: deployed artifacts naming improvements
Revision: 1
URL : https://patchwork.openembedded.org/series/13599/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
* to avoid confusion with "type" command in shell
Signed-off-by: Martin Jansa
---
meta/classes/kernel.bbclass | 58 ++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index
* use the same naming scheme for fitImage files like all other deployed
artifacts
* remove unnecessary cd to DEPLOYDIR
* remove unnecessary cd to B
Signed-off-by: Martin Jansa
---
meta/classes/kernel-artifact-names.bbclass | 3 ++
meta/classes/kernel-fitimage.bbclass | 34
* this makes it easier to use different version string than DATETIME, e.g. set
from jenkins job
while keeping the suffix consistent across all artifacts stored in DEPLOYDIR
Signed-off-by: Martin Jansa
---
meta/classes/kernel-artifact-names.bbclass | 13 -
meta/conf/bitbake.conf
On Fri, 2018-08-17 at 15:37 +0800, Hongxu Jia wrote:
> On 2018年08月17日 15:32, Patchwork wrote:
> > == Series Details ==
> >
> > Series: "libxml2: fix CVE-2018-9251 and..." and 1 more
> > Revision: 1
> > URL : https://patchwork.openembedded.org/series/13574/
> > State : failure
> >
> > ==
* for consistency with other artifacts variables, include only the version
string, not the actual name or extension
* changing .tgz to something else in the MODULE_TARBALL_NAME variable only
wouldn't make much sense
because then kernel.bbclass still calls "tar -cvzf" to create it
This is just the preparation for last bigger change to have consistent
naming across all deployed artifacts. These 6 preparation commits
shouldn't change any names yet, verified with core-image-base for
qemux86 and raspberrypi3.
Using more variables allows to simplify appending some release
* some people don't like the ${MACHINE} in the symlink, because now the
DEPLOYDIR already
contains ${MACHINE} subdirectory, add KERNEL_ARTIFACT_LINK_NAME variable to
change it
in one place without the need to list all variables for various artifacts
Signed-off-by: Martin Jansa
---
* for consistency with IMAGE_NAME and IMAGE_LINK_NAME
and to avoid confusion with IMAGE_BASENAME (which is the
actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME
was only the version suffix)
Signed-off-by: Martin Jansa
---
meta/classes/kernel-artifact-names.bbclass | 22
On Sat, 2018-08-18 at 18:40 +0200, Paulo Neves wrote:
> Ping.
>
> Does anybody have any comments? Also I noticed that my commit once
> was in the master-next but it was removed. Without it being in master
> I cannot submit my changes to poky mailing list with the fixes for
> the remaining
Signed-off-by: Khem Raj
---
meta/recipes-graphics/cairo/cairo.inc | 3 ++-
meta/recipes-graphics/mesa/mesa.inc | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/cairo/cairo.inc
b/meta/recipes-graphics/cairo/cairo.inc
index 20e0d2c92a..7347f223ff
Signed-off-by: Khem Raj
---
meta/recipes-graphics/mesa/mesa.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 2671d4de4d..dd626d9f00 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gdb/{gdb-8.1.inc => gdb-8.1.1.inc} | 4 ++--
...{gdb-cross-canadian_8.1.bb => gdb-cross-canadian_8.1.1.bb} | 0
.../gdb/{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb} | 0
meta/recipes-devtools/gdb/{gdb_8.1.bb => gdb_8.1.1.bb}
- Import from meta-oe layer
- This is useful for many packages where CR-LF
needs to be adjusted, many recipes depend on it
e.g. meta-multimedia libebml and so on.
Signed-off-by: Khem Raj
---
meta/classes/dos2unix.bbclass | 14 ++
1 file changed, 14 insertions(+)
create mode
If not defined, llvm build system tries to build one
which then confuses the OE QA system since its building
native tool and target packages in same package build
moreover it is not required since we already have it via
llvm-native
Fixes
ERROR: llvm-6.0-r0 do_package_qa: QA Issue: llvm: The
llvm-config is a tool on similar veins as pkg-config but provides a lot
more information and packages which use llvm e.g. mesa use this tool to
poke for llvm related informaiton e.g. version, libpath, includepaths
to name a few, this has few challanges in cross build environments where
llvm-config
Original approach to add -no- flags cause link time behavior changes
where packages start to lose the -fPIC -DPIC in compiler cmdline and this
list keeps growing as we build more and more packages,
Instead lets just remove the options we dont need from SECURITY_CFLAGS
this makes it more robust
libunistring is one such library which many autotooled packages
mistake to use from build system if its installed on it. This
is specifically toxic when build host arch is same as target arch
since we only see the problem during runtime but thankfully OE
has build time QA which warns about it.
QA
list of changes in this rev bump
* a69de9c7cf ld-x86-64/pr23486b.d: Swap pr23486a.s and pr23486a.s
* 28a27bdbb9 x86: Properly add X86_ISA_1_NEEDED property
* d692290444 x86: Replace evex-no-scale.s with evex-no-scale-[32|64].s
* d55c3e3609 x86: Properly merge GNU_PROPERTY_X86_ISA_1_USED
*
This series fixes llvm build to support multilib configurations
Adds dos2unix bbclass to core from meta-oe
Fixes ppc security flags world builds
v2:
Upgrade binutils and gdb
Fix libidb2 cross build issue when build host == target host
The following changes since commit
2018-08-19 13:54 GMT+02:00 Isaac Nickaein :
> How such issues is prevented in openembedded (e.g. throughout review
> of new recipes)?
Basically yes. Note that we regularly find deficiencies in old recipes
as well. It's not the end of the world.
> Who is responsible in the cases that license is
On Sat, 2018-08-18 at 22:50 -0400, Bruce Ashfield wrote:
> [...]
>
> v5:
> - added failure catch for x86 purgatory files which changed in 4.18
> and hence are not universal across versions
> - added explicity bison and flex rdepends for mips64 prepare phase
> - added mips64 files
I was in middle of writing a recipe for a library which I wasn't sure
about its licensing. I wondered what if somebody get the licensing
incorrect and submit the recipe to open-embedded upstream.
Since Yocto doesn't enforce the presence of license text inside the
source code (which would be
On Fri, 2018-08-17 at 14:47 -0700, Andre McCurdy wrote:
> > I've not definitively narrowed it down to openssl but it has to be
> > one
> > of:
> >
> > kernel-devsrc: restructure for out of tree (and on target) module
> > openssl: update 1.1.0h -> 1.1.0i
> > openssl: update 1.0.2o -> 1.0.2p
> >
34 matches
Mail list logo
