[yocto] install -m 0644 ${S}/lib/systemd/system/${PN}.service ${D}/${systemd_system_unitdir} failed to add service file to ${systemd_system_unitdir}

[JH]

Hi,

I set up the configuration for service files at following:

SYSTEMD_SERVICE_${PN} = "${PN}.service bootstrap.service"

do_install() {
..
install -d ${D}/${systemd_system_unitdir}
install -m 0644 ${S}/lib/systemd/system/*.service
${D}/${systemd_system_unitdir}
}

Despite both service files are in build directory, the final image
installation does not include those service files, appreciate anyone
help.

Thank you.

Kind regards,

- jh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minutes: Yocto Project Monthly Meeting 7/23/2019

[Reyna, David]

Yocto Project Monthly Meeting
MINUTES: 7/23/2019

Attendees: Richard, JoshuaW, Bruce, Tim, Vineela, David, Trevor, Jan-Simon (at 
end)

Note: consolidated bridge for Tuesday meetings: https://zoom.us/j/990892712

RP:
  * Weekly status update will go out later today
  * 2.7.1 out last week
  * 2.6.3. due out Wednesday
  * Autobuilder performance issues finally found and fixed
  * Some issues with default poky init system (sysv vs. system)

Richard: Runqueue optimizations appear to be working, though some performance 
issues (sometimes 3 minute break for calculations). Example of feature, if 
“m4-native” has change but do_populate_sstate same then sstate left the same 
and no cascade of rebuilds to rest of packages. Richard quite excited about 
this, especially having this early in the development cycle.

Joshua: What about non-local implementations? Richard: focusing on local hash 
state equivalency first. Good step towards reproducibility. Next would then be 
non-local support. Goal is less duplicated in sstate-caches, which will help 
with sstate-cache mirrors. Joshua: would appear that non-local users would 
still need the sstate and database together.

Richard: runqueue api clunky in that it supports multiple tasked formats. Would 
like to consolidate them but that would require a “flag day” for everyone to 
make the transition.

Richard: changes could run against earlier releases like Warrior/Thud with 
minor patches if we would want to do so.

Bruce: 5.3 kernel dropped, so he is busy with that.

- David


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta][PATCH] qemu: add a patch fixing the native build on newer kernels

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

The build fails on qemu-native if we're using kernels after commit
0768e17073dc527ccd18ed5f96ce85f9985e9115. This adds an upstream
patch that fixes the issue.

Signed-off-by: Bartosz Golaszewski 
---
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 ...o-handle-variably-sized-SIOCGSTAMP-w.patch | 339 ++
 2 files changed, 340 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 7f0b3a7a73..46c40b7d4f 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -24,6 +24,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \

file://0009-linux-user-Fix-webkitgtk-hangs-on-32-bit-x86-target.patch \

file://0010-Revert-linux-user-fix-mmap-munmap-mprotect-mremap-sh.patch \
file://0013-target-arm-Fix-vector-operation-segfault.patch \
+   
file://0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch \
   file://CVE-2019-12155.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
 
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
new file mode 100644
index 00..2feb567f1c
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0014-linux-user-fix-to-handle-variably-sized-SIOCGSTAMP-w.patch
@@ -0,0 +1,339 @@
+From 8104018ba4c66e568d2583a3a0ee940851ee7471 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski 
+Date: Tue, 23 Jul 2019 17:50:00 +0200
+Subject: [PATCH] linux-user: fix to handle variably sized SIOCGSTAMP with new
+ kernels
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The SIOCGSTAMP symbol was previously defined in the
+asm-generic/sockios.h header file. QEMU sees that header
+indirectly via sys/socket.h
+
+In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
+the asm-generic/sockios.h header no longer defines SIOCGSTAMP.
+Instead it provides only SIOCGSTAMP_OLD, which only uses a
+32-bit time_t on 32-bit architectures.
+
+The linux/sockios.h header then defines SIOCGSTAMP using
+either SIOCGSTAMP_OLD or SIOCGSTAMP_NEW as appropriate. If
+SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
+on 32-bit architectures
+
+To cope with this we must now convert the old and new type from
+the target to the host one.
+
+Signed-off-by: Daniel P. Berrangé 
+Signed-off-by: Laurent Vivier 
+Reviewed-by: Arnd Bergmann 
+Message-Id: <20190718130641.15294-1-laur...@vivier.eu>
+Signed-off-by: Laurent Vivier 
+Signed-off-by: Bartosz Golaszewski 
+---
+Uptream-status: Backport (upstream commit: 
6d5d5dde9adb5acb32e6b8e3dfbf47fff0f308d2)
+
+ linux-user/ioctls.h|  21 +-
+ linux-user/syscall.c   | 140 +
+ linux-user/syscall_defs.h  |  30 +++-
+ linux-user/syscall_types.h |   6 --
+ 4 files changed, 159 insertions(+), 38 deletions(-)
+
+diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
+index ae8951625f..e6a27ad9d6 100644
+--- a/linux-user/ioctls.h
 b/linux-user/ioctls.h
+@@ -219,8 +219,25 @@
+   IOCTL(SIOCGRARP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_arpreq)))
+   IOCTL(SIOCGIWNAME, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_char_ifreq)))
+   IOCTL(SIOCGPGRP, IOC_R, MK_PTR(TYPE_INT)) /* pid_t */
+-  IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
+-  IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))
++
++  /*
++   * We can't use IOCTL_SPECIAL() because it will set
++   * host_cmd to XXX_OLD and XXX_NEW and these macros
++   * are not defined with kernel prior to 5.2.
++   * We must set host_cmd to the same value as in target_cmd
++   * otherwise the consistency check in syscall_init()
++   * will trigger an error.
++   * host_cmd is ignored by the do_ioctl_XXX() helpers.
++   * FIXME: create a macro to define this kind of entry
++   */
++  { TARGET_SIOCGSTAMP_OLD, TARGET_SIOCGSTAMP_OLD,
++"SIOCGSTAMP_OLD", IOC_R, do_ioctl_SIOCGSTAMP },
++  { TARGET_SIOCGSTAMPNS_OLD, TARGET_SIOCGSTAMPNS_OLD,
++"SIOCGSTAMPNS_OLD", IOC_R, do_ioctl_SIOCGSTAMPNS },
++  { TARGET_SIOCGSTAMP_NEW, TARGET_SIOCGSTAMP_NEW,
++"SIOCGSTAMP_NEW", IOC_R, do_ioctl_SIOCGSTAMP },
++  { TARGET_SIOCGSTAMPNS_NEW, TARGET_SIOCGSTAMPNS_NEW,
++"SIOCGSTAMPNS_NEW", IOC_R, do_ioctl_SIOCGSTAMPNS },
+ 
+   IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+   IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(TYPE_INT))
+diff --git a/linux-user/syscall.c b/linux-user/syscall.c
+index 96cd4bf86d..6df480e13d 100644
+--- a/linux-user/syscall.c
 b/linux-user/syscall.c
+@@ -37,6 +37,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -1139,8 +1140,9 @@ static inline abi_long copy_from_user_timeva

[yocto] Recommended practice to live together hardcoded Linux GIDs with dynamic GIDs

[Javier Tiá]

Hi,

On a random manner, these errors appear:

ERROR: do_install: groupadd command did not succeed
ERROR: do_install: Function failed: useradd_sysroot

It's hard to reproduce. Tried several times to reproduce the error with 
`bitbake -c install ` and `bitbake -C install `. It is 
the only information we have from the build logs. Sounds like a race 
condition.


The recipe is creating several hardcoded Linux groups (GID) with useradd 
class.


In this thread [1] from 2014, there is a practice to the limitation of 
users/groups creation dependency.


[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2014-June/211737.html


Is there to this date a better practice to make work together the Linux 
hardcoded GIDs with the dynamic GID?


Should be all the GIDs be created dynamically?

Poky 2.1 is being used.


Thanks,

--
Javier Tiá

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW30'19

[sjolley.yp.pm]

Current Dev Position: YP 2.8 M2

Next Deadline: YP 2.8 Milestone 2 Cutoff July 14th, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Anuj 
*   SWAT team rotation: Anuj -> Paul on July 26, 2019
*   SWAT team rotation: Paul -> Ross on Aug. 2, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 25th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday August 6th at 8am PDT (
 https://zoom.us/j/990892712) 
*   Twitch - Next event is Tuesday August 6th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   2.7.1 was released
*   2.6.3 has patches pending review and then will be built
*   We have a new "newcomer" bug category which are bugs suited to
someone new to the project. These can be seen here:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
*   There are ongoing discussions on a few key topics which are
summarized here for convenience. Please contribute if you have an interest
in these areas:

*   Running the testsuites for glibc/binutils/gcc
*   Moving lsb to its own layer
*   Removing poky-lsb in favour of some configuration fragments
*   Reproducibility
*   Minimizing python2 dependencies
*   Configuration of init systems

*   Changing poky's init system default to systemd is running into a
large number of testing failures on the autobuilder which puts that change
at risk.
*   The autobuilder performance problem when stopping builds has been
tracked down and fixed. The controller was also upgraded for some
performance improvements (thanks Michael).
*   There are patches available which enable runqueue optimisations
based on output comparisons of tasks. This removes the need to run later
tasks if the output is unchanged and is based upon the previous hash
equivalence server work. This feature should be a significant win for the
users and is now working to a level where we'll likely make this a key
feature of the next release.

 

Planned Releases for YP 2.8:

*   M2 Cutoff 14th July
*   M2 Release 26th July
*   M3 Cutoff (Feature Freeze) 25th Aug
*   M3 Release 6th Sept
*   M4 Cutoff 30th Sept
*   2.8 (M4) Final Release 25th Oct

 

Planned upcoming dot releases:

*   YP 2.7.1 (Warrior) is released.
*   YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
before 2.8 M2.

 

Tracking Metrics:

*   WDD 2483 (last week 2498) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1499 (last week 1502)
*   Patches in the Pending State: 623 (42%) [last week 630 (42%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW30'19

[Alexander Kanavin]

On Tue, 23 Jul 2019 at 20:49,  wrote:

>
>- There are patches available which enable runqueue optimisations
>based on output comparisons of tasks. This removes the need to run later
>tasks if the output is unchanged and is based upon the previous hash
>equivalence server work. This feature should be a significant win for the
>users and is now working to a level where we’ll likely make this a key
>feature of the next release.
>
> This is going to be awesome! Maybe this achievement should get wider
exposure via a LWN article? (provided they accept the submission)

Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] PREMIRROR

[Russell Peterson]

Hello,

I am looking to have bitbake pick up files for a particular recipe from a
local git repository using the PREMIRROR functionality.

Basically, the recipe (bb file) points to github but in my local build I
add PREMIRROR_prepend = "git://.*/.*
git:///local/path/BASENAME;protocol=file\n"

I will probably make the git regular expression more exact for my specific
github repo but this works for now.

This all works (as I deleted the github download from the local download
directory) because I can see in the do_fetch log and the correct (local)
repo was found and placed in the DL_DIR.

Problem is, do_unpack fails because it appears to be looking for the
original (github) SRC_URI.  Then it complains about "no up to date source
found: clone or directory not available or not up to date (shallow clone
not enabled)"

Any help on what I am missing would be appreciated.

Regards,

Russell
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto