Re: [OE-core] [PATCH 6/7] linux-yocto/4.14: update to v4.14.30

How annoying. That is twice that this has happened to the tiny/* branches. yow-bashfiel-d4 [/home/bruc...-yocto.git]> git branch --contains 40adf66d7c45b8252a1d3f904b5027a495e41725 v4.14/standard/tiny/base * v4.14/standard/tiny/common-pc Should be fixed now. Bruce On Tue, Mar 27, 2018 at 6:

Re: [OE-core] [PATCH] oe-selftest: crosstap: add tests for crosstap script

Hi Alex, Yes, reusing existing runqemu made this testcase more concise and easier to maintain. Thank you very much for your inputs and sharing! Thanks, Ee Peng -Original Message- From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] Sent: Tuesday, March 27, 2018 6:32 PM T

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Tue, Mar 27, 2018 at 8:48 AM, Ross Burton wrote: > coreutils is now using renameat2() in mv(1) but as this syscall isn't in most > glibc headers yet it falls back to directly calling syscall(), which pseudo > doesn't intercept. This results in permission problems as files mysteriously > move w

Re: [OE-core] [PATCH 6/7] linux-yocto/4.14: update to v4.14.30

Sorry but this is failing for poky-tiny: ERROR: linux-yocto-tiny-4.14.30+gitAUTOINC+f8232ce8e9_40adf66d7c-r0 do_fetch: Fetcher failure: Unable to find revision 40adf66d7c45b8252a1d3f904b5027a495e41725 in branch v4.14/standard/tiny/common-pc even from upstream ERROR: linux-yocto-tiny-4.14.30+gitAUT

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 13:52:28 -0700 Andre McCurdy wrote: > On Tue, Mar 27, 2018 at 1:20 PM, Seebs wrote: > > My concern is that, strictly speaking, this is nearly all undefined > > behavior, and that reading more arguments than you were passed > > *does* explode on some C implementations. > Can

Re: [OE-core] pseudo: host user contamination

On Tue, Mar 27, 2018 at 1:20 PM, Seebs wrote: > > My concern is that, strictly speaking, this is nearly all undefined > behavior, and that reading more arguments than you were passed *does* > explode on some C implementations. Can you give some examples? For every architecture I'm aware of that

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 13:12:19 -0700 Andre McCurdy wrote: > If you mean forwarding arguments through a wrapper without > interpreting them then I don't know what your concern is. Forwarding > arguments can be handled completely generically - for any architecture > and any syscall. See the musl impl

Re: [OE-core] pseudo: host user contamination

On Tue, Mar 27, 2018 at 12:22 PM, Seebs wrote: > > I was wondering about 64-bit EABI. The man page didn't say "32-bit > EABI", it said "EABI". EABI is just a name (Embedded ABI) which on ARM is used to distinguish between the original ABI (now referred to as OABI, or Old ABI) and the current one.

Re: [OE-core] pseudo: host user contamination

Seebs writes: > On Tue, 27 Mar 2018 21:20:24 +0200 > Enrico Scholz wrote: > >> SYS_readahead is one of a few syscalls which pass 64 bit arguments on >> 32 bit architectures. Without the manual splitting, the ABI will >> cause the compiler to insert a dummy argument so that registers are >> alig

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 21:20:24 +0200 Enrico Scholz wrote: > SYS_readahead is one of a few syscalls which pass 64 bit arguments on > 32 bit architectures. Without the manual splitting, the ABI will > cause the compiler to insert a dummy argument so that registers are > aligned for 64 bit values. I

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 12:11:22 -0700 Andre McCurdy wrote: > In the readahead example, the first syscall argument is the > 32bit file descriptor (which will be passed to the kernel in r0), > therefore a padding argument is required to fill r1 and ensure that > the first word of the 64bit offset gets

Re: [OE-core] pseudo: host user contamination

Seebs writes: >> There are no 64 bit arguments (on 32 bit platforms) which might >> require a special treatment as described in [1] >> "Architecture-specific requirements". > > Okay, ignore the pointer case, and pretend it's the 64-bit value case, > since we have specific-ish documentation for th

Re: [OE-core] pseudo: host user contamination

On Mon, Mar 26, 2018 at 9:41 PM, Seebs wrote: > >> The syscall manpage is from the kernel manpages, not glibc. > >> http://man7.org/linux/man-pages/man2/syscall.2.html > > And yet! glibc is setting those registers in its code. Why? If that's a > kernel thing and libc doesn't need to do it, why i

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 18:26:05 +0200 Enrico Scholz wrote: > Perhaps we have different man pages but e.g. [1] mentions only > registers in the context of the kernel interface but not when > entering/leaving syscall(2) itself. And yet, it's syscall(2) doing the thing... or possibly it's not, because

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 18:35:32 +0200 Enrico Scholz wrote: > Does this really matter here? Because the caller has to set them > accordingly the ABI, you can extract the arguments by > > int olddirfd= va_arg(ap, int); > char const *oldpath = va_arg(ap, char consr *); > int

Re: [OE-core] pseudo: host user contamination

Seebs writes: > On Tue, 27 Mar 2018 16:42:03 +0200 > Enrico Scholz > wrote: > >> will work to wrap syscall(2). Params for _renameat2_syscall() can be >> extracted by va_args. > > Does anyone have access to an actual 64-bit EABI ARM system to verify > the argument passing for renameat2 there?

Re: [OE-core] pseudo: host user contamination

Seebs writes: >> >> Since the man page gave the ia64 example, I went and checked, and >> >> it is indeed the case that calls other than syscall(2) will >> >> clobber r10 after system calls, >> >> I think you are misinterpreting the man-page. In "Architecture >> calling conventions" it documents

[OE-core] ✗ patchtest: failure for pseudo: intercept syscall() and return ENOTSUP for renameat2

== Series Details == Series: pseudo: intercept syscall() and return ENOTSUP for renameat2 Revision: 1 URL : https://patchwork.openembedded.org/series/11590/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several te

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 16:42:03 +0200 Enrico Scholz wrote: > will work to wrap syscall(2). Params for _renameat2_syscall() can be > extracted by va_args. Does anyone have access to an actual 64-bit EABI ARM system to verify the argument passing for renameat2 there? > Code generated above is very

Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

On Tue, 27 Mar 2018 16:48:02 +0100 Ross Burton wrote: > This patch intercepts syscall() and returns ENOTSUP if renameat2() is > being called. I am inclined to NAK this until we have a clearer understanding of the mechanics observed in glibc's syscall implementation; it's doing magic that this wi

Re: [OE-core] pseudo: host user contamination

On Tue, 27 Mar 2018 15:06:40 +0200 Enrico Scholz wrote: > Andre McCurdy > writes: > > >> Since the man page gave the ia64 example, I went and checked, and > >> it is indeed the case that calls other than syscall(2) will > >> clobber r10 after system calls, > > I think you are misinterpreting t

[OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

coreutils is now using renameat2() in mv(1) but as this syscall isn't in most glibc headers yet it falls back to directly calling syscall(), which pseudo doesn't intercept. This results in permission problems as files mysteriously move without pseudo knowing. This patch intercepts syscall() and r

[OE-core] [PATCH 7/7] linux-yocto/4.15: update to v4.15.13

Integrating the korg stable updates comprising the following commits: eb666a896f99 Linux 4.15.13 7717224bbcbb RDMA/ucma: Don't allow join attempts for unsupported AF family 93462def6848 RDMA/ucma: Fix access to non-initialized CM_ID object 7ea20f4df7fc clk: migrate the count of orphaned clocks at

[OE-core] [PATCH 6/7] linux-yocto/4.14: update to v4.14.30

Integrating the korg -stable releases for v4.14, which comprise the following commits: de8cdc557231 Linux 4.14.30 5019b23699f4 RDMA/vmw_pvrdma: Fix usage of user response structures in ABI file 957435b566c9 kbuild: fix linker feature test macros when cross compiling with Clang e82496

[OE-core] [PATCH 2/7] mpc8315e-rdb: fix broken ethernet

Integrating the following commits to fix the ethernet on the mpc8315e-rdb: 12f3957167b0 net: phy: realtek: Use the dummy stubs for MMD register access for rtl8211b c986bc511c18 net: phy: Add general dummy stubs for MMD register access Signed-off-by: Bruce Ashfield --- meta/recipes-kernel/l

[OE-core] [PATCH 4/7] linux-yocto/meta: improve wifi driver granularity

Integrating the following commit for the 4.12+ kernels: Author: Nathan Rossi Date: Wed Mar 21 00:10:02 2018 +1000 features/wifi: Add WiFi driver fragments for various vendors/interfaces This change adds WiFi driver configuration fragments. The fragments are split into vendor

[OE-core] [PATCH 5/7] linux-yocto/4.12: intel-socfpga, intel-pmc-core and ish support for CoffeeLake board

Integrating a series of mainline backports to allow better 4.12 support for the coffeelake board: 97e710ef0545 driver: clk: socfpga: remove unused variable 2852089a6b7f x86/cpu: Add Cannonlake to Intel family 1af96090b1f4 ACPI / LPIT: Export lpit_read_residency_count_address() 1e85b644

[OE-core] [PATCH 3/7] linux-yocto/4.12: add ssl and utils native dependencies

Via the -stable updates, and other configuration changes the 4.12 kernel has the same dependency on openssl headers as 4.14+. So we add the same DEPENDS line that we already have in newer kernels to avoid the following error: | HOSTCC scripts/sign-file | build/tmp/work-shared/qemux86-64

[OE-core] [PATCH 1/7] linux-yocto/4.12: update to v4.12.21

Integrating Paul Gortmaker's stable update to 4.12, this includes CVE fixes for meltdown and spectre: 3bb926457832 Linux 4.12.21 76781f72ce64 lguest: disable it vs. removing it. 6ab3176bb365 x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL efa97ecdf026 x86/pti: Mark constan

[OE-core] [PATCH 0/7] linux-yocto: consolidated pull request

Hi all, This pull request is a series of -stable updates (more Spectre/meltdown included), and some fixes for the fsl_mpc h/w reference board that will allow us to update the reference to v4.14+. We also have a configuration tweak to the wifi fragments, which will result in more reuse, but won't

Re: [OE-core] pseudo: host user contamination

Seebs writes: > And so far as I know, it's not actually *possible* to in the general > case. I really don't think it's safe to try to catch syscall(). I think, something like static void (*orig_syscall)(); long syscall(long number, ...) { switch (number) { case __NR_renamea

Re: [OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

On 3/27/18 5:37 AM, Alexander Kanavin wrote: > On 03/26/2018 06:28 PM, Mark Hatle wrote: >> I want a multilib_exec that can be used to generate a wrapper. The recipe >> will >> have to pass in the name of what is being wrapped, and how to determine the >> correct 'default'. The scripting should

Re: [OE-core] [pyro][rocko][PATCH] base.bbclass: fix do_unpack[cleandirs] varflag handling

On 03/27/2018 03:40 AM, Enrico Joerns wrote: > Ping! > > If there should be severe changes in the recent base / kernel class > code that might make this useless, this is at least a candidate for > backporting! This has to be in master first before  I can back port. Since you have the setup that

[OE-core] [V4][PATCH] libshmfence: update to 1.3

From: Armin Kuster refreshed patch [v2] Remove dangling space in patch [v3] remove patch as changes on in update [v4] Remove SRC_URI Signed-off-by: Armin Kuster --- .../xorg-lib/libxshmfence/extensions.patch | 17 - .../{libxshmfence_1.2.bb => libxshmfence_1.3.b

Re: [OE-core] [V3][PATCH] libshmfence: update to 1.3

On 03/27/2018 07:19 AM, Martin Jansa wrote: > Looks like you have forgot to remove it from SRC_URI. That is too funny. I am not trying to make to v100 ; ) - armin > > On Tue, Mar 27, 2018 at 4:13 PM, Armin Kuster > wrote: > > From: Armin Kuster mailto:akus...@mv

Re: [OE-core] [V3][PATCH] libshmfence: update to 1.3

Looks like you have forgot to remove it from SRC_URI. On Tue, Mar 27, 2018 at 4:13 PM, Armin Kuster wrote: > From: Armin Kuster > > refreshed patch > > [v2] > Remove dangling space in patch > > [v3] > remove patch as changes on in update > > Signed-off-by: Armin Kuster > --- > .../xorg-lib/li

[OE-core] [V3][PATCH] libshmfence: update to 1.3

From: Armin Kuster refreshed patch [v2] Remove dangling space in patch [v3] remove patch as changes on in update Signed-off-by: Armin Kuster --- .../xorg-lib/libxshmfence/extensions.patch | 17 - .../{libxshmfence_1.2.bb => libxshmfence_1.3.bb}| 4 ++--

Re: [OE-core] pseudo: host user contamination

Andre McCurdy writes: >> Since the man page gave the ia64 example, I went and checked, and it >> is indeed the case that calls other than syscall(2) will clobber r10 >> after system calls, I think you are misinterpreting the man-page. In "Architecture calling conventions" it documents the calli

Re: [OE-core] [PATCH] package.bbclass: Include dbgsrc for static libs

ping? -- Ola Nilsson From: openembedded-core-boun...@lists.openembedded.org on behalf of Ola x Nilsson Sent: Friday, February 23, 2018 08:46 To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH] package.bbclass: Include dbgsrc for sta

[OE-core] CPU Load

Hi y'all, I have some questions about CPU load and performance, but first some background information. We have small embedded system running an openembedded classic (Angström) distro. Now to get ourselves up-to-date we started working on a new iteration of the OS based on openembedded core a

[OE-core] Yocto rocko ssh fetcher error: scp not found

Hi, I have a recipe which uses the ssh fetcher: SRC_URI = "ssh://username@sshserver/~/demo-${PV}.zip" I'm trying to upgrade from pyro to rocko, and now I'm getting errors ERROR: demo-2.0.47.0-r0 do_fetch: Fetcher failure: Fetch command export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-X

Re: [OE-core] [pyro][rocko][PATCH] base.bbclass: fix do_unpack[cleandirs] varflag handling

Ping! If there should be severe changes in the recent base / kernel class code that might make this useless, this is at least a candidate for backporting! /Enrico On 01/31/2018 10:49 AM, Enrico Joerns wrote: Hey, any comments on that? Not using this patch currently disturbs our companies Y

Re: [OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

On 03/26/2018 06:28 PM, Mark Hatle wrote: I want a multilib_exec that can be used to generate a wrapper. The recipe will have to pass in the name of what is being wrapped, and how to determine the correct 'default'. The scripting should handle everything else. Like multilib_header it needs to

Re: [OE-core] [PATCH] oe-selftest: crosstap: add tests for crosstap script

On 03/27/2018 04:37 AM, Yeoh Ee Peng wrote: QA team were testing crosstap script manually. Add automated tests and systemtap file to test that crosstap script will instructs SystemTap to print hello world in qemu. This test will first built core-image-minimal image with tools-profile & ssh-server

[OE-core] [PATCH v3] libpcre: 8.41 -> 8.42

License-Update: The checksum of LIC_FILES_CHKSUM has been changed due to time update of copyright LICENCE to 2018. The content of LICENCE has no change. Signed-off-by: Andrej Valek --- meta/recipes-support/libpcre/{libpcre_8.41.bb => libpcre_8.42.bb} | 6 +++--- 1 file changed, 3 insertions(+)

Re: [OE-core] Question about how to get package included in SDK

Hi, Thanks for your response. BR Mans Zigher 2018-03-27 11:03 GMT+02:00 Burton, Ross : > The main problem is that protoc isn't in the protobuf packages, but > protobuf-compiler (as can be seen with oe-pkgdata-util list-pkg-files > -p protobuf). > > Add nativesdk-protobuf-compiler to TOOLCHAIN_H

[OE-core] ✗ patchtest: failure for libpcre: 8.41 -> 8.42 (rev2)

== Series Details == Series: libpcre: 8.41 -> 8.42 (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/11585/ 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 pr

[OE-core] [PATCH v2] libpcre: 8.41 -> 8.42

1. Upgrade libpcre2 from 8.41 to 8.42 2. Update the checksum of LIC_FILES_CHKSUM - The copyright time of LICENCE is updated to 2018, the content of LICENCE has no change. Signed-off-by: Andrej Valek --- meta/recipes-support/libpcre/{libpcre_8.41.bb => libpcre_8.42.bb} | 6 +++--- 1 file chan

[OE-core] ✗ patchtest: failure for libpcre: 8.41 -> 8.42

== Series Details == Series: libpcre: 8.41 -> 8.42 Revision: 1 URL : https://patchwork.openembedded.org/series/11585/ 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 proposed

Re: [OE-core] Question about how to get package included in SDK

The main problem is that protoc isn't in the protobuf packages, but protobuf-compiler (as can be seen with oe-pkgdata-util list-pkg-files -p protobuf). Add nativesdk-protobuf-compiler to TOOLCHAIN_HOST_TASK. You'll also want to use _append instead of += so you don't remove more than you add. Ros

[OE-core] [PATCH] oe-selftest: crosstap: add tests for crosstap script

QA team were testing crosstap script manually. Add automated tests and systemtap file to test that crosstap script will instructs SystemTap to print hello world in qemu. This test will first built core-image-minimal image with tools-profile & ssh-server-openssh features and build systemtap-native o

[OE-core] [PATCH] libpcre: 8.41 -> 8.42

- The LIC_FILES_CHKSUM is changed since it has updated the date from 2017 to 2018, the contents are the same. Signed-off-by: Andrej Valek --- meta/recipes-support/libpcre/{libpcre_8.41.bb => libpcre_8.42.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-suppo

[OE-core] Question about how to get package included in SDK

Hi, I have package that require protobuf and the compiler protoc. I have included the following DEPENDS += " protobuf protobuf-native" and RDEPENDS_${PN} += " protobuf" The build works as intended the problem now is that the protoc is not included in the SDK. In the Yocto ref manual I found th

[OE-core] [oe-core] network error

Hi, I am trying to do a pip install on poky for one of the python package and it is resulting in this error, do help Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after connection broken by 'NewConnectionError'('': Failed to establish a new connection: [Errno -2] Name or serv

[OE-core] [PATCH] glibc-package: fix locale cleanup logic

If ${libdir} is a subdirectory of ${prefix}/lib, e.g. /usr/lib/aarch64-linux, the cleanup logic will delete libc.so. This bit of code was added in 2012 (git show b744f4cc) to remove /usr/lib/locale, this commit makes it remove that directory recursively and afterwards remove /usr/lib, erroring