Re: [OE-core] [PATCH] busybox: add devmem
On Wed, Jan 30, 2019 at 02:18:06PM -0800, Khem Raj wrote: > On Wed, Jan 30, 2019 at 12:31 PM Adrian Bunk wrote: > > > On Wed, Jan 30, 2019 at 08:50:02AM -0800, Khem Raj wrote: > > > On Wed, Jan 30, 2019 at 1:34 AM Adrian Bunk wrote: > > > > > > > > This is a tiny but pretty useful tool. > > > > > > > > > > question is, do we need this enabled in default config, or could be add > > it via > > > some DISTRO_FEATURE meant for validation etc. May be if you explain your > > > usecase then we might be able to make a better assessment. > > > > Sorry for being too terse. > > > > devmem allows reading and writing hardware configuration registers, > > which is useful both for debugging and for scripts. > > > > Thanks for the info this seems useful can you also report how much does it > increase size of busybox In a -O2 build for arm64 busybox.nosuid grows 4 kB. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base-passwd: Add kvm group
On Thu, Jan 31, 2019 at 07:15:32PM +, Jacob Kroon wrote:
> Fixes the following warning when starting eudev:
>
> udevd[]: specified group 'kvm' unknown
>
> Signed-off-by: Jacob Kroon
> ---
> .../base-passwd/base-passwd/kvm.patch | 23 +++
> .../base-passwd/base-passwd_3.5.29.bb | 3 ++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-core/base-passwd/base-passwd/kvm.patch
>
> diff --git a/meta/recipes-core/base-passwd/base-passwd/kvm.patch
> b/meta/recipes-core/base-passwd/base-passwd/kvm.patch
> new file mode 100644
> index 00..113d5151e7
> --- /dev/null
> +++ b/meta/recipes-core/base-passwd/base-passwd/kvm.patch
> @@ -0,0 +1,23 @@
> +From 6355278b9f744291864c373a32a8da8f84aaaf37 Mon Sep 17 00:00:00 2001
> +From: Jacob Kroon
> +Date: Wed, 30 Jan 2019 04:53:48 +
> +Subject: [PATCH] Add kvm group
> +
> +Upstream-Status: Pending
> +Signed-off-by: Jacob Kroon
> +---
> + group.master | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/group.master b/group.master
> +index cea9d60..5b62284 100644
> +--- a/group.master
> b/group.master
> +@@ -34,6 +34,7 @@ utmp:*:43:
> + video:*:44:
> + sasl:*:45:
> + plugdev:*:46:
> ++kvm:*:47:
I wasn't sure which number to pick, is there a recommended one for kvm ?
My Arch Linux has it set to 992.
> + staff:*:50:
> + games:*:60:
> + shutdown:*:70:
> diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
> b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
> index c6be1c1d08..d1aab09181 100644
> --- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
> +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
> @@ -12,7 +12,8 @@ SRC_URI =
> "https://launchpad.net/debian/+archive/primary/+files/${BPN}_${PV}.tar
> file://noshadow.patch \
> file://input.patch \
> file://disable-docs.patch \
> - "
> + file://kvm.patch \
> + "
>
> SRC_URI[md5sum] = "6beccac48083fe8ae5048acd062e5421"
> SRC_URI[sha256sum] =
> "f0b66388b2c8e49c15692439d2bee63bcdd4bbbf7a782c7f64accc55986b6a36"
> --
> 2.18.1
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] glibc: Update to 2.29 release
Signed-off-by: Khem Raj
Signed-off-by: Martin Jansa
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
...2.28.bb => cross-localedef-native_2.29.bb} | 8 +-
meta/recipes-core/glibc/glibc-collateral.inc | 1 +
...bc-locale_2.28.bb => glibc-locale_2.29.bb} | 0
...bc-mtrace_2.28.bb => glibc-mtrace_2.29.bb} | 0
...-scripts_2.28.bb => glibc-scripts_2.29.bb} | 0
...Look-for-host-system-ld.so.cache-as-.patch | 10 +-
...Fix-buffer-overrun-with-a-relocated-.patch | 10 +-
...Raise-the-size-of-arrays-containing-.patch | 26 +-
...k-glibc-Allow-64-bit-atomics-for-x86.patch | 39 ++-
...Make-relocatable-install-for-locales.patch | 13 +-
...5500-e6500-603e-fsqrt-implementation.patch | 7 +-
...RE_KNOWN_INTERPRETER_NAMES-to-known-.patch | 10 +-
...undefined-reference-to-__sqrt_finite.patch | 7 +-
...-are-now-inline-functions-and-call-o.patch | 9 +-
...443-which-explains-what-the-patch-do.patch | 10 +-
...m-err-tab.pl-with-specific-dirs-in-S.patch | 21 +-
...-are-now-inline-functions-and-call-o.patch | 9 +-
...igure.ac-handle-correctly-libc_cv_ro.patch | 7 +-
.../glibc/0014-Add-unused-attribute.patch | 9 +-
...the-path-sets-wrong-config-variables.patch | 7 +-
...zone-re-written-tzselect-as-posix-sh.patch | 13 +-
...bash-dependency-for-nscd-init-script.patch | 7 +-
...ss-building-and-testing-instructions.patch | 7 +-
...glibc-Help-bootstrap-cross-toolchain.patch | 9 +-
...0-eglibc-Clear-cache-lines-on-ppc8xx.patch | 11 +-
...eglibc-Resolve-__fpscr_values-on-SH4.patch | 9 +-
...port-cross-locale-generation-support.patch | 45 +--
...Define-DUMMY_LOCALE_T-if-not-defined.patch | 9 +-
...archive-uses-a-hard-coded-locale-pa.patch} | 29 +-
...e-_dl_build_local_scope-breadth-fir.patch} | 9 +-
...le-fix-hard-coded-reference-to-gcc-E.patch | 35 ---
...set-dl_load_write_lock-after-forking.patch | 9 +-
...ck-before-switching-to-malloc_atfork.patch | 9 +-
...sts.h-enum-definition-for-TRAP_HWBKP.patch | 66 -
...t-no-lines-in-bison-generated-files.patch} | 9 +-
...029-inject-file-assembly-directives.patch} | 172 +++-
...ybe-uninitialized-errors-with-Os-BZ.patch} | 36 +--
...prevent-maybe-uninitialized-errors-w.patch | 258 --
...soft-fp-ignore-maybe-uninitialized-w.patch | 100 ---
.../glibc/{glibc_2.28.bb => glibc_2.29.bb}| 36 ++-
41 files changed, 367 insertions(+), 716 deletions(-)
rename meta/recipes-core/glibc/{cross-localedef-native_2.28.bb =>
cross-localedef-native_2.29.bb} (90%)
rename meta/recipes-core/glibc/{glibc-locale_2.28.bb => glibc-locale_2.29.bb}
(100%)
rename meta/recipes-core/glibc/{glibc-mtrace_2.28.bb => glibc-mtrace_2.29.bb}
(100%)
rename meta/recipes-core/glibc/{glibc-scripts_2.28.bb =>
glibc-scripts_2.29.bb} (100%)
rename
meta/recipes-core/glibc/glibc/{0029-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch
=> 0024-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch} (80%)
rename
meta/recipes-core/glibc/glibc/{0024-elf-dl-deps.c-Make-_dl_build_local_scope-breadth-fir.patch
=> 0025-elf-dl-deps.c-Make-_dl_build_local_scope-breadth-fir.patch} (88%)
delete mode 100644
meta/recipes-core/glibc/glibc/0025-locale-fix-hard-coded-reference-to-gcc-E.patch
delete mode 100644
meta/recipes-core/glibc/glibc/0028-bits-siginfo-consts.h-enum-definition-for-TRAP_HWBKP.patch
rename
meta/recipes-core/glibc/glibc/{0030-intl-Emit-no-lines-in-bison-generated-files.patch
=> 0028-intl-Emit-no-lines-in-bison-generated-files.patch} (83%)
rename
meta/recipes-core/glibc/glibc/{0034-inject-file-assembly-directives.patch =>
0029-inject-file-assembly-directives.patch} (78%)
rename
meta/recipes-core/glibc/glibc/{0033-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch
=> 0030-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch} (64%)
delete mode 100644
meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-errors-w.patch
delete mode 100644
meta/recipes-core/glibc/glibc/0032-sysdeps-ieee754-soft-fp-ignore-maybe-uninitialized-w.patch
rename meta/recipes-core/glibc/{glibc_2.28.bb => glibc_2.29.bb} (88%)
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 812b923fa2..cd6acf3219 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -22,7 +22,7 @@ GCCVERSION ?= "8.%"
SDKGCCVERSION ?= "${GCCVERSION}"
BINUVERSION ?= "2.31%"
GDBVERSION ?= "8.2%"
-GLIBCVERSION ?= "2.28%"
+GLIBCVERSION ?= "2.29%"
LINUXLIBCVERSION ?= "4.19%"
QEMUVERSION ?= "3.1%"
GOVERSION ?= "1.11%"
diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.28.bb
b/meta/recipes-core/glibc/cross-localedef-native_2.29.bb
similarity index 90%
rename from meta/recipes-core/glibc/cross-localedef-native_2.28.bb
rename to meta/recipes-core/glibc/cross-localedef-native_2.29.bb
index a05b94e3b3..edb4fd40dc 100644
---
Re: [OE-core] [PATCH] busybox: add devmem
On Thu, Jan 31, 2019 at 09:04:53PM +0200, Adrian Bunk wrote: > On Wed, Jan 30, 2019 at 05:47:03PM -0500, Tom Rini wrote: > > > > I would also ask if we should be enabling more stuff in busybox, period. > > I don't think the current status quo would be a good starting point for that. > > Before submitting I saw CONFIG_PATCH=y, which is a lot more of a > "Why would I ever need this on an embedded device?". > > Not saying that you are wrong, but the starting point should be a review > of the current config. Yes, somewhere between an audit of busybox and making it easier / clearer on how to remove busybox on a "regular" image (core-image-*, etc) are on my TODO list. You might also get surprised btw where things like patch get, erm, differently-used in systems in automated ways. > > Customizing busybox for what you're trying to _do_ with a custom setup > > is one of those top 5 TODO items with making a cut down image and > > customizing the kernel config. Outside of -tiny and initramfs/similar > > cases, there's not a great reason to use > > almost-but-not-quite-complete-busybox-applet compared with the regular > > app. > > I frequently end up in projects where I do have great reason for that: > > For root filesystems of the 32-64 MB size it is not necessary to use a > different libc or use -Os, but using the busybox applets when they are > sufficient saves > 10% filesystem size compared to the full versions. > > E.g. 0.45 MB for a standalone tar is much when the little functionality > you actually need is also provided by the busybox applet. > > Plus there is also the convenience point that most of the tools you need > are already installed just by adding busybox with the default config. Right. This is the -tiny and similar cases. Busybox is great for a lot of things. But there's also common cases where it's not. But the reasons I object here are, aside from what others have brought up about devmem vs devmem2 vs putting stuff in DTS files, etc, is that I really don't want to see more implicit deps to busybox added in. busybox is in virtually every single OE fs image, so I am going to argue that every new utility we add there needs a real good justification. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On Wed, Jan 30, 2019 at 05:47:03PM -0500, Tom Rini wrote: > > I would also ask if we should be enabling more stuff in busybox, period. I don't think the current status quo would be a good starting point for that. Before submitting I saw CONFIG_PATCH=y, which is a lot more of a "Why would I ever need this on an embedded device?". Not saying that you are wrong, but the starting point should be a review of the current config. > Customizing busybox for what you're trying to _do_ with a custom setup > is one of those top 5 TODO items with making a cut down image and > customizing the kernel config. Outside of -tiny and initramfs/similar > cases, there's not a great reason to use > almost-but-not-quite-complete-busybox-applet compared with the regular > app. I frequently end up in projects where I do have great reason for that: For root filesystems of the 32-64 MB size it is not necessary to use a different libc or use -Os, but using the busybox applets when they are sufficient saves > 10% filesystem size compared to the full versions. E.g. 0.45 MB for a standalone tar is much when the little functionality you actually need is also provided by the busybox applet. Plus there is also the convenience point that most of the tools you need are already installed just by adding busybox with the default config. > Tom cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Always install initramfs-framework-base in case of linux-yocto & INITRAMFS_IMAGE_BUNDLE=1
On Tue, Jan 29, 2019 at 9:01 PM Alexey Brodkin wrote: > --->8-- > /dev/console is missing or not a character device! > Please ensure your rootfs is properly configured > --->8-- I thought /dev/console could also be created by the kernel itself onto a "temporary filesystem for device nodes" (DEVTMPFS). I am not sure, but here is a similar case: http://lists.busybox.net/pipermail/buildroot/2015-March/123309.html Is your (other) kernel configured with CONFIG_DEVTMPFS=y? Regards, Leon. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] base-passwd: Add kvm group
Fixes the following warning when starting eudev:
udevd[]: specified group 'kvm' unknown
Signed-off-by: Jacob Kroon
---
.../base-passwd/base-passwd/kvm.patch | 23 +++
.../base-passwd/base-passwd_3.5.29.bb | 3 ++-
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-core/base-passwd/base-passwd/kvm.patch
diff --git a/meta/recipes-core/base-passwd/base-passwd/kvm.patch
b/meta/recipes-core/base-passwd/base-passwd/kvm.patch
new file mode 100644
index 00..113d5151e7
--- /dev/null
+++ b/meta/recipes-core/base-passwd/base-passwd/kvm.patch
@@ -0,0 +1,23 @@
+From 6355278b9f744291864c373a32a8da8f84aaaf37 Mon Sep 17 00:00:00 2001
+From: Jacob Kroon
+Date: Wed, 30 Jan 2019 04:53:48 +
+Subject: [PATCH] Add kvm group
+
+Upstream-Status: Pending
+Signed-off-by: Jacob Kroon
+---
+ group.master | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/group.master b/group.master
+index cea9d60..5b62284 100644
+--- a/group.master
b/group.master
+@@ -34,6 +34,7 @@ utmp:*:43:
+ video:*:44:
+ sasl:*:45:
+ plugdev:*:46:
++kvm:*:47:
+ staff:*:50:
+ games:*:60:
+ shutdown:*:70:
diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
index c6be1c1d08..d1aab09181 100644
--- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
+++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
@@ -12,7 +12,8 @@ SRC_URI =
"https://launchpad.net/debian/+archive/primary/+files/${BPN}_${PV}.tar
file://noshadow.patch \
file://input.patch \
file://disable-docs.patch \
- "
+ file://kvm.patch \
+ "
SRC_URI[md5sum] = "6beccac48083fe8ae5048acd062e5421"
SRC_URI[sha256sum] =
"f0b66388b2c8e49c15692439d2bee63bcdd4bbbf7a782c7f64accc55986b6a36"
--
2.18.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On Thu, Jan 31, 2019 at 11:06:22AM +0100, Philip Balister wrote: > On 01/30/2019 05:50 PM, Khem Raj wrote: > > On Wed, Jan 30, 2019 at 1:34 AM Adrian Bunk wrote: > >> > >> This is a tiny but pretty useful tool. > > Also there is http://layers.openembedded.org/layerindex/recipe/1069/ > > I was told a while ago the busybox version has some issues. Hunting > through brain cells, I think it always does a read back after writing > which can be bad for some hardware. So I've always used the recipe from > meta-oe instead. The broken one for that is actually devmem2, the busybox copy of the code has the read back commented out. > Philip cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2 v5] resultstool: enable merge, store, report and regression analysis
On Thu, 2019-01-31 at 05:23 +, Yeoh, Ee Peng wrote: > Hi RP, > > I looked into ptest and regression. The existing "resultstool > regression" can be used to perform regression on ptest, since the > testresults.json capture ptest status. I had executed regression > script for the below 2 ptest testresults.json. Attached was the > regression report for ptest. > > https://autobuilder.yocto.io/pub/releases/yocto-2.7_M2.rc1/testresults/qemux86-64-ptest/testresults.json > https://autobuilder.yocto.io/pub/releases/yocto-2.7_M1.rc1/testresults/qemux86-64-ptest/testresults.json > > The only challenges now was since ptest result set was relatively > large, it was taking some time for computing the regression. Also > there was this "ptestresult.rawlogs" testcase that does not contain > status but the large rawlog. > > I did an experiment where I run the regression on testresults.json > with and without the ptest rawlog. It shows the time taken for > regression was significantly larger when it contain the rawlog. I > will try to improve the regression time by throw away the rawlog at > runtime when perform computing. > testresults.json with rawlog > Regression start time: 20190131122805 > Regression end time: 20190131124425 > Time taken: 16 mins 20 sec > > testresults.json without rawlog > Regression start time: 20190131124512 > Regression end time: 20190131124529 > Time taken: 17 sec Analysing the rawlog makes no sense so the tool needs to simply ignore that. 16 minutes is far too long! I've just merged some changes which mean there are probably some other sections it will need to ignore now too since the logs are now being split out per ptest (section). I've left rawlogs in as its useful for debugging but once the section splits are working we could remove it. This adds in timing data so we know how long each ptest took to run (in seconds), it also adds in exit code and timeout data. These all complicate the regression analysis but the fact that lttng has been timing out (for example) has been overlooked until now and shows we need to analyse these things. I'm considering whether we should have a command in resulttool which takes json data and writes it out in a "filesystem" form. The code in logparser.py already has a rudimentary version of this for ptest data. It could be extended to write out a X.log for each ptest based on the split out data and maybe duration and timeout information in some form too. The idea behind flat filesystem representations of the data is that a user can more easily explore or compare them, they also show up well in git. Its also worth thinking about how we'll end up using this. testresult will get called at the end of builds (particularly) release builds and we'll want it to generate a QA report for the automated test data. The autobuilder will likely put an http link in the "release build ready" email to an html like report stored alongside the testresults json files. I'm still trying to figure out how to make this all fit together and allow automated comparisons but the build performance data would also fit into this (and already has html reports). Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] go, go-common: Add missing quotes in shell variable assignment
On Thu, 2019-01-31 at 12:43 +, Phil Blundell wrote:
> Otherwise we will lose if ${BUILD_CC} happens to contain a space.
>
> Signed-off-by: Phil Blundell
> ---
> meta/recipes-devtools/go/go-common.inc | 2 +-
> meta/recipes-devtools/go/go_1.9.bb | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Its been a while since we saw you! :)
The patch came through in one of the weirdest formats I've seen,
couldn't get the mail client to give me a plain text version of it. It
says its plain text but the client wants to use HTML.
I forced something to apply since it was a simple patch but it wouldn't
work for a more complex one. Not sure why this is behaving so oddly as
I can usually get most emails to work...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] Revert "gcc-cross-canadian: Add symlink to real-ld alongside other symlinks"
This reverts commit cdd86896c8d29135f937968e9aa07f919cf543d3.
real-ld is always used if that is found, which means you cannot
switch between bfd and gold linkers using -fuse-ld=gold.
Signed-off-by: Samuli Piippo
---
meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index e7c08d3a61..ececec4965 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -137,8 +137,6 @@ do_install () {
ln -sf ${BINRELPATH}/${TARGET_PREFIX}$t$suffix $dest$t$suffix
done
- t=real-ld
- ln -sf ${BINRELPATH}/${TARGET_PREFIX}ld$suffix $dest$t$suffix
# libquadmath headers need to be available in the gcc libexec dir
install -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] core-image-sato-sdk-ptest: Increase qemu memory to 1GB
Signed-off-by: Richard Purdie --- meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb index 531571ee877..7e3152b4a11 100644 --- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb +++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb @@ -9,3 +9,6 @@ IMAGE_FEATURES += "ptest-pkgs" # box) and explicitly add just 500MB. IMAGE_OVERHEAD_FACTOR = "1.0" IMAGE_ROOTFS_EXTRA_SPACE = "524288" + +# ptests need more memory than standard to avoid the OOM killer +QB_MEM = "-m 1024" -- 2.19.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] oeqa/runtime/ptest: Ensure OOM errors are logged
Currently processed being killed by the OOM killer may not be spotted by
ptest-runner. After we complete the tests, check the logs and report if there
were any. This ensures the user is aware of OOM conditions affecting the
ptest results.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/runtime/cases/ptest.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/runtime/cases/ptest.py
b/meta/lib/oeqa/runtime/cases/ptest.py
index 6ae951356d8..2a28ca59a8e 100644
--- a/meta/lib/oeqa/runtime/cases/ptest.py
+++ b/meta/lib/oeqa/runtime/cases/ptest.py
@@ -70,5 +70,13 @@ class PtestRunnerTest(OERuntimeTestCase):
if failed_testcases:
failed_tests[section] = failed_testcases
+failmsg = ""
+status, output = self.target.run('dmesg | grep "Killed process"', 0)
+if output:
+failmsg = "ERROR: Processes were killed by the OOM Killer:\n%s\n"
% output
+
if failed_tests:
-self.fail("Failed ptests:\n%s" % pprint.pformat(failed_tests))
+failmsg = failmsg + "Failed ptests:\n%s" %
pprint.pformat(failed_tests)
+
+if failmsg:
+self.fail(failmsg)
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ruby.inc: Add dependency on readline-native
Add dependency on readline-native to fix the following issue
uninitialized constant Logfile
| Check ext/fiddle/mkmf.log for more details.
| readline:
| Could not be configured. It will not be installed.
|
build/tmp/work/x86_64-linux/ruby-native/2.5.1-r0/ruby-2.5.1/ext/readline/extconf.rb:62:
Neither readline nor libedit was found
| Check ext/readline/mkmf.log for more details.
| *** Fix the problems, then remove these directories and try again if
you want.
Signed-off-by: Manjukumar Matha
---
meta/recipes-devtools/ruby/ruby.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/ruby/ruby.inc
b/meta/recipes-devtools/ruby/ruby.inc
index 5a5bef2..eaf5d13 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -15,7 +15,7 @@ LIC_FILES_CHKSUM = "\
"
DEPENDS = "ruby-native zlib openssl tcl libyaml gdbm readline"
-DEPENDS_class-native = "openssl-native libyaml-native"
+DEPENDS_class-native = "openssl-native libyaml-native readline-native"
SHRT_VER = "${@oe.utils.trim_version("${PV}", 2)}"
SRC_URI = "http://cache.ruby-lang.org/pub/ruby/${SHRT_VER}/ruby-${PV}.tar.gz \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glibc-collateral: Update PV to 2.29
On 1/31/19 10:12 PM, Khem Raj wrote:
> Signed-off-by: Khem Raj
> ---
> meta/recipes-core/glibc/glibc-collateral.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-collateral.inc
> b/meta/recipes-core/glibc/glibc-collateral.inc
> index b370df314f..3379270566 100644
> --- a/meta/recipes-core/glibc/glibc-collateral.inc
> +++ b/meta/recipes-core/glibc/glibc-collateral.inc
> @@ -21,4 +21,4 @@ do_install[depends] +=
> "virtual/${MLPREFIX}libc:do_stash_locale"
>
> COMPATIBLE_HOST_libc-musl_class-target = "null"
>
> -PV = "2.28.9000"
> +PV = "2.29"
I see you caught it : )
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] glibc-collateral: Update PV to 2.29
Signed-off-by: Khem Raj
---
meta/recipes-core/glibc/glibc-collateral.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/glibc/glibc-collateral.inc
b/meta/recipes-core/glibc/glibc-collateral.inc
index b370df314f..3379270566 100644
--- a/meta/recipes-core/glibc/glibc-collateral.inc
+++ b/meta/recipes-core/glibc/glibc-collateral.inc
@@ -21,4 +21,4 @@ do_install[depends] +=
"virtual/${MLPREFIX}libc:do_stash_locale"
COMPATIBLE_HOST_libc-musl_class-target = "null"
-PV = "2.28.9000"
+PV = "2.29"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3] multilib_header: Place a #include guard to avoid infinite inclusion of headers
In cases where extra preprocessing tools are used such as clang-tidy
e.g. and these tools are not passed the knowledge about architecture
then a corner case comes where we enter into include loop for
bits/wordsize.h, since this template does explicitly include
bits/wordsize.h
so it synthesized a guard out of file name e.g.
bits/wordsize.h -> __OE_BITS_WORDSIZE_H__
and emits the guard at beginning of file
Signed-off-by: Khem Raj
---
v2: Drop space changes, not needed, and fix a typo > to >>
v3: Prepend `OE` to include guard to make it not conflict with other headers
meta/classes/multilib_header.bbclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/multilib_header.bbclass
b/meta/classes/multilib_header.bbclass
index e03f5b13b2..2036dc8594 100644
--- a/meta/classes/multilib_header.bbclass
+++ b/meta/classes/multilib_header.bbclass
@@ -33,10 +33,13 @@ oe_multilib_header() {
continue
fi
stem=$(echo $each_header | sed 's#\.h$##')
+ include_guard=$(echo $each_header | tr '/.' '_' | tr '[a-z]' '[A-Z]'
| sed 's/^/__OE_/' | sed 's/$/__/')
# if mips64/n32 set ident to n32
mv ${D}/${includedir}/$each_header
${D}/${includedir}/${stem}-${ident}.h
-
- sed -e "s#ENTER_HEADER_FILENAME_HERE#${stem}#g"
${COREBASE}/scripts/multilib_header_wrapper.h > ${D}/${includedir}/$each_header
+ echo "#ifndef $include_guard" > ${D}/${includedir}/$each_header
+ echo "#define $include_guard" >> ${D}/${includedir}/$each_header
+ sed -e "s#ENTER_HEADER_FILENAME_HERE#${stem}#g"
${COREBASE}/scripts/multilib_header_wrapper.h >> ${D}/${includedir}/$each_header
+ echo "#endif /* $include_guard */" >> ${D}/${includedir}/$each_header
done
}
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 00/12] util-linux: one package per binary
On Wed, 2019-01-16 at 12:51 +, André Draszik wrote: > v4: > * update patch 06/15 > * unconditionally assign PACKAGE_PREPROCESS_FUNCS > * update patch 07/15 > * introduce update_files() helper function Ran this in -next but we saw things like: ERROR: util-linux-2.32.1-r0 do_package: QA Issue: util-linux: Files/directories were installed but not shipped in any package: /usr/bin/x86_64 /usr/bin/i386 Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install (from https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/267662/raw ) qemuarm was similar: https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/267853/raw so something isn't quite right :( I'll retry with a small subset of the series of patches until we figure this out. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] multilib_header: Place a #include guard to avoid infinite inclusion of headers
In cases where extra preprocessing tools are used such as clang-tidy
e.g. and these tools are not passed the knowledge about architecture
then a corner case comes where we enter into include loop for
bits/wordsize.h, since this template does explicitly include
bits/wordsize.h
so it synthesized a guard out of file name e.g.
bits/wordsize.h -> __BITS_WORDSIZE_H__
and emits the guard at beginning of file
Signed-off-by: Khem Raj
---
meta/classes/multilib_header.bbclass | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/meta/classes/multilib_header.bbclass
b/meta/classes/multilib_header.bbclass
index e03f5b13b2..959e9cac74 100644
--- a/meta/classes/multilib_header.bbclass
+++ b/meta/classes/multilib_header.bbclass
@@ -18,9 +18,9 @@ oe_multilib_header() {
case ${TARGET_ARCH} in
mips*) case "${MIPSPKGSFX_ABI}" in
"-n32")
- ident=n32
+ ident=n32
;;
-*)
+*)
ident=${SITEINFO_BITS}
;;
esac
@@ -33,10 +33,13 @@ oe_multilib_header() {
continue
fi
stem=$(echo $each_header | sed 's#\.h$##')
+ include_guard=$(echo $each_header | tr '/.' '_' | tr '[a-z]' '[A-Z]'
| sed 's/^/__/' | sed 's/$/__/')
# if mips64/n32 set ident to n32
mv ${D}/${includedir}/$each_header
${D}/${includedir}/${stem}-${ident}.h
-
- sed -e "s#ENTER_HEADER_FILENAME_HERE#${stem}#g"
${COREBASE}/scripts/multilib_header_wrapper.h > ${D}/${includedir}/$each_header
+ echo "#ifndef $include_guard" > ${D}/${includedir}/$each_header
+ echo "#define $include_guard" >> ${D}/${includedir}/$each_header
+ sed -e "s#ENTER_HEADER_FILENAME_HERE#${stem}#g"
${COREBASE}/scripts/multilib_header_wrapper.h >> ${D}/${includedir}/$each_header
+ echo "#endif /* $include_guard */" > ${D}/${includedir}/$each_header
done
}
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] multilib_header: Place a #include guard to avoid infinite inclusion of headers
In cases where extra preprocessing tools are used such as clang-tidy
e.g. and these tools are not passed the knowledge about architecture
then a corner case comes where we enter into include loop for
bits/wordsize.h, since this template does explicitly include
bits/wordsize.h
so it synthesized a guard out of file name e.g.
bits/wordsize.h -> __BITS_WORDSIZE_H__
and emits the guard at beginning of file
Signed-off-by: Khem Raj
---
v2: Drop space changes, not needed, and fix a typo > to >>
meta/classes/multilib_header.bbclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/multilib_header.bbclass
b/meta/classes/multilib_header.bbclass
index e03f5b13b2..70b7117da8 100644
--- a/meta/classes/multilib_header.bbclass
+++ b/meta/classes/multilib_header.bbclass
@@ -33,10 +33,13 @@ oe_multilib_header() {
continue
fi
stem=$(echo $each_header | sed 's#\.h$##')
+ include_guard=$(echo $each_header | tr '/.' '_' | tr '[a-z]' '[A-Z]'
| sed 's/^/__/' | sed 's/$/__/')
# if mips64/n32 set ident to n32
mv ${D}/${includedir}/$each_header
${D}/${includedir}/${stem}-${ident}.h
-
- sed -e "s#ENTER_HEADER_FILENAME_HERE#${stem}#g"
${COREBASE}/scripts/multilib_header_wrapper.h > ${D}/${includedir}/$each_header
+ echo "#ifndef $include_guard" > ${D}/${includedir}/$each_header
+ echo "#define $include_guard" >> ${D}/${includedir}/$each_header
+ sed -e "s#ENTER_HEADER_FILENAME_HERE#${stem}#g"
${COREBASE}/scripts/multilib_header_wrapper.h >> ${D}/${includedir}/$each_header
+ echo "#endif /* $include_guard */" >> ${D}/${includedir}/$each_header
done
}
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glibc: Update to 2.29 release
On 1/31/19 10:11 AM, Khem Raj wrote:
> Signed-off-by: Khem Raj
> Signed-off-by: Martin Jansa
> ---
> meta/conf/distro/include/tcmode-default.inc | 2 +-
> ...2.28.bb => cross-localedef-native_2.29.bb} | 8 +-
> meta/recipes-core/glibc/glibc-collateral.inc | 1 +
> ...bc-locale_2.28.bb => glibc-locale_2.29.bb} | 0
> ...bc-mtrace_2.28.bb => glibc-mtrace_2.29.bb} | 0
> ...-scripts_2.28.bb => glibc-scripts_2.29.bb} | 0
> ...Look-for-host-system-ld.so.cache-as-.patch | 10 +-
> ...Fix-buffer-overrun-with-a-relocated-.patch | 10 +-
> ...Raise-the-size-of-arrays-containing-.patch | 26 +-
> ...k-glibc-Allow-64-bit-atomics-for-x86.patch | 39 ++-
> ...Make-relocatable-install-for-locales.patch | 13 +-
> ...5500-e6500-603e-fsqrt-implementation.patch | 7 +-
> ...RE_KNOWN_INTERPRETER_NAMES-to-known-.patch | 10 +-
> ...undefined-reference-to-__sqrt_finite.patch | 7 +-
> ...-are-now-inline-functions-and-call-o.patch | 9 +-
> ...443-which-explains-what-the-patch-do.patch | 10 +-
> ...m-err-tab.pl-with-specific-dirs-in-S.patch | 21 +-
> ...-are-now-inline-functions-and-call-o.patch | 9 +-
> ...igure.ac-handle-correctly-libc_cv_ro.patch | 7 +-
> .../glibc/0014-Add-unused-attribute.patch | 9 +-
> ...the-path-sets-wrong-config-variables.patch | 7 +-
> ...zone-re-written-tzselect-as-posix-sh.patch | 13 +-
> ...bash-dependency-for-nscd-init-script.patch | 7 +-
> ...ss-building-and-testing-instructions.patch | 7 +-
> ...glibc-Help-bootstrap-cross-toolchain.patch | 9 +-
> ...0-eglibc-Clear-cache-lines-on-ppc8xx.patch | 11 +-
> ...eglibc-Resolve-__fpscr_values-on-SH4.patch | 9 +-
> ...port-cross-locale-generation-support.patch | 45 +--
> ...Define-DUMMY_LOCALE_T-if-not-defined.patch | 9 +-
> ...archive-uses-a-hard-coded-locale-pa.patch} | 29 +-
> ...e-_dl_build_local_scope-breadth-fir.patch} | 9 +-
> ...le-fix-hard-coded-reference-to-gcc-E.patch | 35 ---
> ...set-dl_load_write_lock-after-forking.patch | 9 +-
> ...ck-before-switching-to-malloc_atfork.patch | 9 +-
> ...sts.h-enum-definition-for-TRAP_HWBKP.patch | 66 -
> ...t-no-lines-in-bison-generated-files.patch} | 9 +-
> ...029-inject-file-assembly-directives.patch} | 172 +++-
> ...ybe-uninitialized-errors-with-Os-BZ.patch} | 36 +--
> ...prevent-maybe-uninitialized-errors-w.patch | 258 --
> ...soft-fp-ignore-maybe-uninitialized-w.patch | 100 ---
> .../glibc/{glibc_2.28.bb => glibc_2.29.bb}| 36 ++-
> 41 files changed, 367 insertions(+), 716 deletions(-)
> rename meta/recipes-core/glibc/{cross-localedef-native_2.28.bb =>
> cross-localedef-native_2.29.bb} (90%)
> rename meta/recipes-core/glibc/{glibc-locale_2.28.bb =>
> glibc-locale_2.29.bb} (100%)
> rename meta/recipes-core/glibc/{glibc-mtrace_2.28.bb =>
> glibc-mtrace_2.29.bb} (100%)
> rename meta/recipes-core/glibc/{glibc-scripts_2.28.bb =>
> glibc-scripts_2.29.bb} (100%)
> rename
> meta/recipes-core/glibc/glibc/{0029-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch
> => 0024-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch} (80%)
> rename
> meta/recipes-core/glibc/glibc/{0024-elf-dl-deps.c-Make-_dl_build_local_scope-breadth-fir.patch
> => 0025-elf-dl-deps.c-Make-_dl_build_local_scope-breadth-fir.patch} (88%)
> delete mode 100644
> meta/recipes-core/glibc/glibc/0025-locale-fix-hard-coded-reference-to-gcc-E.patch
> delete mode 100644
> meta/recipes-core/glibc/glibc/0028-bits-siginfo-consts.h-enum-definition-for-TRAP_HWBKP.patch
> rename
> meta/recipes-core/glibc/glibc/{0030-intl-Emit-no-lines-in-bison-generated-files.patch
> => 0028-intl-Emit-no-lines-in-bison-generated-files.patch} (83%)
> rename
> meta/recipes-core/glibc/glibc/{0034-inject-file-assembly-directives.patch =>
> 0029-inject-file-assembly-directives.patch} (78%)
> rename
> meta/recipes-core/glibc/glibc/{0033-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch
> => 0030-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch} (64%)
> delete mode 100644
> meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-errors-w.patch
> delete mode 100644
> meta/recipes-core/glibc/glibc/0032-sysdeps-ieee754-soft-fp-ignore-maybe-uninitialized-w.patch
> rename meta/recipes-core/glibc/{glibc_2.28.bb => glibc_2.29.bb} (88%)
>
> diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> index 812b923fa2..cd6acf3219 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -22,7 +22,7 @@ GCCVERSION ?= "8.%"
> SDKGCCVERSION ?= "${GCCVERSION}"
> BINUVERSION ?= "2.31%"
> GDBVERSION ?= "8.2%"
> -GLIBCVERSION ?= "2.28%"
> +GLIBCVERSION ?= "2.29%"
> LINUXLIBCVERSION ?= "4.19%"
> QEMUVERSION ?= "3.1%"
> GOVERSION ?= "1.11%"
> diff --git a/meta/recipes-core/glibc/cross-localedef-native_2.28.bb
> b/meta/recipes-core/glibc/cross-localedef-native_2.29.bb
>
Re: [OE-core] [PATCH] busybox: add devmem
On 01/30/2019 05:50 PM, Khem Raj wrote: > On Wed, Jan 30, 2019 at 1:34 AM Adrian Bunk wrote: >> >> This is a tiny but pretty useful tool. Also there is http://layers.openembedded.org/layerindex/recipe/1069/ I was told a while ago the busybox version has some issues. Hunting through brain cells, I think it always does a read back after writing which can be bad for some hardware. So I've always used the recipe from meta-oe instead. Philip >> > > question is, do we need this enabled in default config, or could be add it via > some DISTRO_FEATURE meant for validation etc. May be if you explain your > usecase then we might be able to make a better assessment. > >> Signed-off-by: Adrian Bunk >> --- >> meta/recipes-core/busybox/busybox/defconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-core/busybox/busybox/defconfig >> b/meta/recipes-core/busybox/busybox/defconfig >> index d11707abc3..1519159a49 100644 >> --- a/meta/recipes-core/busybox/busybox/defconfig >> +++ b/meta/recipes-core/busybox/busybox/defconfig >> @@ -791,7 +791,7 @@ CONFIG_DC=y >> # CONFIG_DEVFSD_FG_NP is not set >> # CONFIG_DEVFSD_VERBOSE is not set >> # CONFIG_FEATURE_DEVFS is not set >> -# CONFIG_DEVMEM is not set >> +CONFIG_DEVMEM=y >> # CONFIG_EJECT is not set >> # CONFIG_FEATURE_EJECT_SCSI is not set >> # CONFIG_FBSPLASH is not set >> -- >> 2.11.0 >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On 01/30/2019 09:09 PM, Scott Ellis wrote: > Is the busybox devmem functionally different then the standalone devmem2 > package? Replying again I've been told they are functionally different and to use devmem2. I think the issue with the busybox version is that it does a readback when writing, this can be bad for some hardware. Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [master][PATCH] ref-manual: Update the default value for PACKAGE_DEBUG_PACKAGE_SPLIT
Doc patches to yo...@lists.yoctoproject.org please.
Ross
On Wed, 30 Jan 2019 at 19:30, Joshua Watt wrote:
>
> The new default is "debug-with-srcpkg"
>
> Signed-off-by: Joshua Watt
> ---
> documentation/ref-manual/ref-variables.xml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 4b243a12dd6..8e30f47bafd 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -9976,7 +9976,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
> "${INC_PR}.3"
> /bin/.debug.
> Source files are placed in
> /usr/src/debug.
> -This is the default behavior.
>
>
> "debug-file-directory": Debug symbol files are
> @@ -1,6 +,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
> "${INC_PR}.3"
> ".debug" previously described with the exception
> that all source files are placed in a separate
> *-src pkg.
> +This is the default behavior.
>
>
>
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA
On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner wrote: > > We're excited to announce the inaugural "OpenEmbedded Summit" taking place > Sunday March 10th 2019 as part of the Southern California Linux Expo > (SCaLE) 17x at the Pasadena Convention Center. > > For the past few years there's been an ever-growing OpenEmbedded event as > part of SCaLE. This year, with the missing Spring ELC, we felt it was time > to do something more "formally" so OE enthusiasts could get together > without having to wait until August. > > The initial suggestion for this summit came at last year's OEDEM in > Edinburgh. At that time an idea was also floated to hold this year's OEDAM > at the same time. Just to be absolutely clear: this suggestion was > rejected; there will be no OEDAM at the OE Summit at SCaLE 17x. However, > this summit is taking place with the full approval of the OpenEmbedded > Board of Directors, many of whom have also been helping out with its > organization. > > The schedule for the OE Summit has been posted: > https://www.socallinuxexpo.org/scale/17x/schedule/sunday > https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 To whoever can double check and fix the schedule... it looks like there's a typo at the second link, where Alistair's talk is listed twice. From the first link "Lokesh Kumar Goel OpenEmbedded in LG Products" should be at 11.30am instead. > > So if you're in the Southern California area, or are generally interested > in hanging out with some OpenEmbedded people, please join us in Pasadena on > March 10th! > > Your OE Summit organizing committee: > Tom King > Behan Webster > Trevor Woerner > -- > ___ > Openembedded-devel mailing list > openembedded-de...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image_types.bbclass: add support for multiply ubifs volumes in ubi image
On Mon, Oct 29, 2018 at 10:04:23AM +0100, Maksym Komar wrote:
Request for feedback, please :)
> Add the ability to create additional ubifs volumes inside ubi volume.
>
> For example this code create empty 2MiB volume named "config".
> ===
> MKUBIFS_ARGS = "-m 1 -e 65408 -c 958 -F"
> UBINIZE_ARGS = "-m 1 -p 64KiB"
>
> MKUBIFS_VOLUMES="config rootfs"
> MKUBIFS_VOLUME_SIZE[config] = "2MiB"
> MKUBIFS_VOLUME_ARGS[config] = "-m 1 -e 65408 -c 22 -F"
> ===
> As result system will be have /dev/ubi0_0 as "config" and
> /dev/ubi0_1 as "rootfs".
>
> Can be used with FSTYPE ubi and multiubi
>
> Signed-off-by: Maksym Komar
> ---
> meta/classes/image_types.bbclass | 67 +---
> 1 file changed, 53 insertions(+), 14 deletions(-)
>
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index e881d0cc2d..726760d99b 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -174,28 +174,67 @@ multiubi_mkfs() {
> local vname="_$3"
> fi
>
> - echo \[ubifs\] > ubinize${vname}-${IMAGE_NAME}.cfg
> - echo mode=ubi >> ubinize${vname}-${IMAGE_NAME}.cfg
> - echo
> image=${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubifs >>
> ubinize${vname}-${IMAGE_NAME}.cfg
> - echo vol_id=0 >> ubinize${vname}-${IMAGE_NAME}.cfg
> - echo vol_type=dynamic >> ubinize${vname}-${IMAGE_NAME}.cfg
> - echo vol_name=${UBI_VOLNAME} >> ubinize${vname}-${IMAGE_NAME}.cfg
> - echo vol_flags=autoresize >> ubinize${vname}-${IMAGE_NAME}.cfg
> - mkfs.ubifs -r ${IMAGE_ROOTFS} -o
> ${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubifs
> ${mkubifs_args}
> - ubinize -o
> ${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubi ${ubinize_args}
> ubinize${vname}-${IMAGE_NAME}.cfg
> + if [ -z "$4" ]; then
> + MKUBIFS_VOLUMES="rootfs"
> + fi
> +
> + local vol_id=0
> + echo -n > ubinize${vname}-${IMAGE_NAME}.cfg
> + for volume in ${MKUBIFS_VOLUMES}; do
> + echo \[${volume}\] >> ubinize${vname}-${IMAGE_NAME}.cfg
> + echo mode=ubi >> ubinize${vname}-${IMAGE_NAME}.cfg
> + echo vol_id=$vol_id >> ubinize${vname}-${IMAGE_NAME}.cfg
> + echo vol_type=dynamic >> ubinize${vname}-${IMAGE_NAME}.cfg
> +
> + # workaround to get Variable Flag
> MKUBIFS_VOLUME_SIZE[volume_name]
> + eval ${@' '.join(['size_' + k + '=\\"' + v + '\\"' for k,v in
> d.getVarFlags('MKUBIFS_VOLUME_SIZE').items()])}
> + eval size=\"\$size_$volume\"
> +
> + if [ -z "$size" ]; then
> + echo vol_flags=autoresize >>
> ubinize${vname}-${IMAGE_NAME}.cfg
> + else
> + echo vol_size=$size >> ubinize${vname}-${IMAGE_NAME}.cfg
> + fi
> +
> + if [ "${volume}" = "rootfs" ]; then
> + echo
> image=${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubifs >>
> ubinize${vname}-${IMAGE_NAME}.cfg
> + echo vol_name=${UBI_VOLNAME} >>
> ubinize${vname}-${IMAGE_NAME}.cfg
> + mkfs.ubifs -r ${IMAGE_ROOTFS} -o
> ${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubifs
> ${mkubifs_args}
> + else
> + echo
> image=${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}.${volume}.ubifs >>
> ubinize${vname}-${IMAGE_NAME}.cfg
> + echo vol_name=${volume} >>
> ubinize${vname}-${IMAGE_NAME}.cfg
> +
> + # workaround to get Variable Flag
> MKUBIFS_VOLUME_ARGS[volume_name]
> + eval ${@' '.join(['args_' + k + '=\\"' + v + '\\"' for
> k,v in d.getVarFlags('MKUBIFS_VOLUME_ARGS').items()])}
> + eval args=\"\$args_$volume\"
> +
> + # create empty volume
> + mkdir -p empty
> + mkfs.ubifs -r empty -o
> ${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}.${volume}.ubifs $args
> + rmdir empty
> + fi
> + vol_id=$(expr $vol_id + 1)
> + done
> +
> + # if variable IMAGE_NAME_SUFFIX is weak, set suffix with names of all
> volumes
> + image_name_suffix=$IMAGE_NAME_SUFFIX
> + if [ -n "${MKUBIFS_VOLUMES}" -a -z "${@d.getVar('IMAGE_NAME_SUFFIX',
> noweakdefault=True) or ''}" ]; then
> + image_name_suffix=${@'.' +
> '-'.join(d.getVar('MKUBIFS_VOLUMES').split())}
> + fi
> + ubinize -o
> ${IMGDEPLOYDIR}/${IMAGE_NAME}${vname}${image_name_suffix}.ubi ${ubinize_args}
> ubinize${vname}-${IMAGE_NAME}.cfg
>
> # Cleanup cfg file
> mv ubinize${vname}-${IMAGE_NAME}.cfg ${IMGDEPLOYDIR}/
>
> # Create own symlinks for 'named' volumes
> - if [ -n "$vname" ]; then
> + if [ -n "$vname" -o "${IMAGE_NAME_SUFFIX}" != "${image_name_suffix}" ];
> then
> cd ${IMGDEPLOYDIR}
> if [ -e ${IMAGE_NAME}${vname}${IMAGE_NAME_SUFFIX}.ubifs ]; then
>
Re: [OE-core] [PATCH] busybox: add devmem
On Thu, Jan 31, 2019 at 11:16 AM Philip Balister wrote: > > On 01/30/2019 09:09 PM, Scott Ellis wrote: > > Is the busybox devmem functionally different then the standalone devmem2 > > package? > > Replying again > > I've been told they are functionally different and to use devmem2. I > think the issue with the busybox version is that it does a readback when > writing, this can be bad for some hardware. > And the fact that the devmem2 tool is written with no fixed integer width. You have to understand that on a 64-bit system, reading a "word" from a 32-bit hardware peripheral (most are), you are touching two registers. case 'h': read_result = *((unsigned short *) virt_addr); break; case 'w': read_result = *((unsigned long *) virt_addr); break; I rewrote it once to use uint_t but I do not think there is a proper upstream repository / maintenance going on. Not sure about devmem in Busybox. Anyway, devmem being useful for development, I do not see why it should be in BusyBox by default. We are not shipping devmem2 and should not. We can have such reasoning for every tool out there. I rather would have a single switch to include tools like these. I disagree that devmem(2) should be included for purposes such as pin-muxing. Yes, I use it weekly for that during bring-up, but the released result should be in DTS or DTS overlays, or boot loader code in the end. Regards, -- Leon Woestenberg http://www.sidebranch.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 0/6] systemd patches
Hi Richard, On 30/01/2019 22:54, Richard Purdie wrote: On Mon, 2019-01-28 at 21:58 +0100, Jonas Bonn wrote: Changed in v4: - add patch to make systemd-firstboot a non-default option to systemd to prevent unexpected prompts at runtime There were still some failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/237 (steps 5c, 6c and 7c) OK, thanks. I looked into these failures and have a couple of comments: i) There are seemingly two failures here: unable to sync time and unable to connect to network (by looks of things). These are related because the network failure leads to the timesync failure, AFAICT. ii) I have seen these failures locally; however, I even get these failures on origin/master, i.e. without any of my systemd patches. iii) The failure behaviour on this end is strange: sometimes I get warnings from the ethernet driver about "incomplete frames" being detected. Same kernel on the same hardware with Thud doesn't produce these warnings (with or without the systemd patches in this series). iv) connman-1.36 crashes (something about Wispr despite 'wispr' being disabled in my connman build... it seems bits of wispr are built despite this) immediately after getting a DHCP address and is unable to get an address when it's restarted. v) Disabling connman altogether and things work much better. systemd-network can bring up the network without ethernet driver frame errors, strangely enough. So with that: a) Does buildbot use connman, systemd-networkd, both, or something else? How do I find this out? b) I'll poke at the patch series again once I get a working origin/master build so that I have sane state to work from. The systemd patches work fine on Thud... I suspect the problem lies elsewhere. c) Are others seeing similar errors with connman? Thanks, /Jonas Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] go, go-common: Add missing quotes in shell variable assignment
Otherwise we will lose if ${BUILD_CC} happens to contain a space.
Signed-off-by: Phil Blundell --- meta/recipes-
devtools/go/go-common.inc | 2 +- meta/recipes-
devtools/go/go_1.9.bb | 2 +- 2 files changed, 2 insertions(+), 2
deletions(-)
diff --git a/meta/recipes-devtools/go/go-common.inc b/meta/recipes-
devtools/go/go-common.incindex 11d55c4d36..d6dc455813 100644---
a/meta/recipes-devtools/go/go-common.inc+++ b/meta/recipes-
devtools/go/go-common.inc@@ -29,5 +29,5 @@ export GOCACHE = "off"
export CGO_ENABLED = "1" do_compile_prepend() {- BUILD_CC=${BUIL
D_CC}+ BUILD_CC="${BUILD_CC}" }diff --git a/meta/recipes-
devtools/go/go_1.9.bb b/meta/recipes-devtools/go/go_1.9.bbindex
ec5a314e7d..e121e2790f 100644--- a/meta/recipes-
devtools/go/go_1.9.bb+++ b/meta/recipes-devtools/go/go_1.9.bb@@ -9,7
+9,7 @@ export CXX_FOR_TARGET = "${CXX}" do_compile() { export
GOBIN="${B}/bin"export TMPDIR="$GOTMPDIR"- export
CC=$BUILD_CC+ export CC="$BUILD_CC" cd src ./make.bash-- 2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Drop util-linux-native-qsort.patch
This is already part of my util-linux cleanup:
http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278074.html
The issue is more grave than just compatibility, it would appear that it
introduces random memory access.
Cheers,
Andre'
On Wed, 2019-01-30 at 11:34 +0200, Adrian Bunk wrote:
> CentOS 5.x is no longer supported for 2 years,
> and uninative being default since Yocto 2.1 should
> in any case already cover this issue better.
>
> Signed-off-by: Adrian Bunk
> ---
> .../util-linux/util-linux-native-qsort.patch | 33 ---
> ---
> meta/recipes-core/util-linux/util-linux_2.32.1.bb | 6
> 2 files changed, 39 deletions(-)
> delete mode 100644 meta/recipes-core/util-linux/util-linux/util-linux-
> native-qsort.patch
>
> diff --git a/meta/recipes-core/util-linux/util-linux/util-linux-native-
> qsort.patch b/meta/recipes-core/util-linux/util-linux/util-linux-native-
> qsort.patch
> deleted file mode 100644
> index 68bf22de8c..00
> --- a/meta/recipes-core/util-linux/util-linux/util-linux-native-
> qsort.patch
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -From f220d809be1baa654503bf6ff52f3630b0d7015c Mon Sep 17 00:00:00 2001
> -From: Robert Yang
> -Date: Wed, 26 Mar 2014 01:30:29 +
> -Subject: [PATCH] sun.c: use qsort() to instead of qsort_r()
> -
> -qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on
> -the host like CentOS 5.x.
> -
> -Upstream-Status: Inappropriate [Other]
> -
> -Signed-off-by: Robert Yang
>
> - libfdisk/src/sun.c | 5 ++---
> - 1 file changed, 2 insertions(+), 3 deletions(-)
> -
> -Index: util-linux-2.24.2/libfdisk/src/sun.c
> -===
> util-linux-2.24.2.orig/libfdisk/src/sun.c
> -+++ util-linux-2.24.2/libfdisk/src/sun.c
> -@@ -431,10 +431,9 @@ static int sun_verify_disklabel(struct f
> - }
> - verify_sun_starts = starts;
> -
> --qsort_r(array,ARRAY_SIZE(array),sizeof(array[0]),
> -- (int (*)(const void *,const void *,void *)) verify_sun_cmp,
> -- verify_sun_starts);
> --
> -+qsort(array,ARRAY_SIZE(array),sizeof(array[0]),
> -+ (int (*)(const void *,const void *)) verify_sun_cmp);
> -+
> - if (array[0] == -1) {
> - fdisk_info(cxt, _("No partitions defined."));
> - return 0;
> diff --git a/meta/recipes-core/util-linux/util-linux_2.32.1.bb
> b/meta/recipes-core/util-linux/util-linux_2.32.1.bb
> index c909836cbb..0ba218b8f2 100644
> --- a/meta/recipes-core/util-linux/util-linux_2.32.1.bb
> +++ b/meta/recipes-core/util-linux/util-linux_2.32.1.bb
> @@ -1,15 +1,9 @@
> MAJOR_VERSION = "2.32"
> require util-linux.inc
>
> -# To support older hosts, we need to patch and/or revert
> -# some upstream changes. Only do this for native packages.
> -OLDHOST = ""
> -OLDHOST_class-native = "file://util-linux-native-qsort.patch"
> -
> SRC_URI += "file://configure-sbindir.patch \
> file://runuser.pamd \
> file://runuser-l.pamd \
> -${OLDHOST} \
> file://ptest.patch \
> file://run-ptest \
> file://display_testname_for_subtest.patch \
> --
> 2.11.0
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA
On Thu, Jan 31, 2019 at 5:40 AM Andrea Galbusera wrote: > On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner wrote: > > The schedule for the OE Summit has been posted: > > https://www.socallinuxexpo.org/scale/17x/schedule/sunday > > https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 > > To whoever can double check and fix the schedule... it looks like > there's a typo at the second link, where Alistair's talk is listed > twice. From the first link "Lokesh Kumar Goel > OpenEmbedded in LG Products" should be at 11.30am instead. > Thanks. There are a bunch of other snafus with the webpages (i.e. the title of Alistair's talk is actually "RISC-V and OpenEmbedded", and some of the links to the speakers' bios doesn't seem to work properly). I had notified the organizers even before I sent out this email, but didn't want to wait even longer to let everyone know about this event. Hopefully the organizers can get around to fixing them soon-ish. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python2-manifest: Add missing xmlrpclib.py
The manifest creation bug that was masking this file was fixed, rerun and add
the missing file to fix:
File "/usr/lib64/python2.7/SimpleXMLRPCServer.py", line 102, in
import xmlrpclib
ImportError: No module named xmlrpclib
[YOCTO #12814]
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/python/python/python2-manifest.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python/python2-manifest.json
b/meta/recipes-devtools/python/python/python2-manifest.json
index 4fff54a95bf..81f1c24f97a 100644
--- a/meta/recipes-devtools/python/python/python2-manifest.json
+++ b/meta/recipes-devtools/python/python/python2-manifest.json
@@ -1122,7 +1122,8 @@
],
"files": [
"${libdir}/python2.7/DocXMLRPCServer.py",
-"${libdir}/python2.7/SimpleXMLRPCServer.py"
+"${libdir}/python2.7/SimpleXMLRPCServer.py",
+"${libdir}/python2.7/xmlrpclib.py"
]
},
"zlib": {
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 0/6] systemd patches
On Thu, 2019-01-31 at 14:19 +0100, Jonas Bonn wrote: [...] > So with that: > > a) Does buildbot use connman, systemd-networkd, both, or something > else? How do I find this out? We're building standard poky so there are no non-standard settings, other than for those images, enabling systemd. You can see the configuration and revisions used in the logs. On the host side, the autobuilders are configured with static tap devices which the user running the build has permissions for. > b) I'll poke at the patch series again once I get a working > origin/master build so that I have sane state to work from. The > systemd patches work fine on Thud... I suspect the problem lies > elsewhere. > > c) Are others seeing similar errors with connman? Our builds work fine with current master, as soon as we add the patches they break. They break even with just the machineid changes. I haven't looked into why, I just know our regression tests go red with your patches :(. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
