[OE-core] [PATCH V3] perf: make a copy of kernel source to perf workdir

[Hongxu Jia]

Since perf contaminates linux shared workdir, it probably caused
kernel-devsrc compile failure at world build.
...
|0 blocks
|cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat:
No such file or directory
|0 blocks
...
cpio tried to find a file at ${S}/tools/perf and failed
if the input list is not valid.

Make a copy of kernel shared source directory into a perf workdir
could fix the issue.

Drop `Fix for rebuilding' which is obsolete

[YOCTO #10880]

Signed-off-by: Hongxu Jia 
---
 meta/recipes-kernel/perf/perf.bb | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 872b5f0..fb4e3ac 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -61,7 +61,7 @@ export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
 
 inherit kernelsrc
 
-B = "${WORKDIR}/${BPN}-${PV}"
+S = "${WORKDIR}/${BP}"
 SPDX_S = "${S}/tools/perf"
 
 # The LDFLAGS is required or some old kernels fails due missing
@@ -97,6 +97,16 @@ EXTRA_OEMAKE += "\
 'infodir=${@os.path.relpath(infodir, prefix)}' \
 "
 
+PERF_SRC ?= "Makefile \
+ tools/arch \
+ tools/build \
+ tools/include \
+ tools/lib \
+ tools/Makefile \
+ tools/perf \
+ tools/scripts \
+"
+
 PERF_EXTRA_LDFLAGS = ""
 
 # MIPS N32
@@ -119,11 +129,22 @@ do_install() {
fi
 }
 
-do_configure_prepend () {
-# Fix for rebuilding
-rm -rf ${B}/
-mkdir -p ${B}/
+do_configure[prefuncs] += "copy_perf_source_from_kernel"
+python copy_perf_source_from_kernel() {
+sources = (d.getVar("PERF_SRC") or "").split()
+src_dir = d.getVar("STAGING_KERNEL_DIR")
+dest_dir = d.getVar("S")
+bb.utils.mkdirhier(dest_dir)
+for s in sources:
+src = oe.path.join(src_dir, s)
+dest = oe.path.join(dest_dir, s)
+if os.path.isdir(src):
+oe.path.copyhardlinktree(src, dest)
+else:
+bb.utils.copyfile(src, dest)
+}
 
+do_configure_prepend () {
 # If building a multlib based perf, the incorrect library path will be
 # detected by perf, since it triggers via: ifeq ($(ARCH),x86_64). In a 32 
bit
 # build, with a 64 bit multilib, the arch won't match and the detection of 
a 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] perf: make a copy of kernel source to perf workdir

[Hongxu Jia]

On 2018年04月24日 08:45, Bruce Ashfield wrote:



On Mon, Apr 23, 2018 at 6:05 PM, Richard Purdie 
> wrote:


On Mon, 2018-04-23 at 13:51 -0400, Bruce Ashfield wrote:
> On 2018-04-23 4:13 AM, Hongxu Jia wrote:
> >
> > Since perf modify kernel source which shared by multiple
> > recipes, it probably caused kernel-devsrc compile failure
> > at world build.
> > ...
> > >
> > > 0 blocks
> > > cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat:
> > No such file or directory
> > >
> > > 0 blocks
> > ...
> > cpio tried to find a file at ${S}/tools/perf and failed
> > if the input list is not valid.
> >
> > Make a copy of kernel shared source directory into a perf workdir
> > could fix the issue.
> >
> > Drop `Fix for rebuilding' which is obsolete
> >
> > Signed-off-by: Hongxu Jia >
> > ---
> >   meta/recipes-kernel/perf/perf.bb  | 11
++-
> >   1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/perf/perf.bb 
b/meta/recipes-
> > kernel/perf/perf.bb 
> > index 872b5f0..8b40806 100644
> > --- a/meta/recipes-kernel/perf/perf.bb 
> > +++ b/meta/recipes-kernel/perf/perf.bb 
> > @@ -61,7 +61,7 @@ export PERL_ARCHLIB =
"${STAGING_LIBDIR}${PERL_OW
> > N_DIR}/perl/${@get_perl_version
> >
> >   inherit kernelsrc
> >
> > -B = "${WORKDIR}/${BPN}-${PV}"
> > +S = "${WORKDIR}/${BP}"
> >   SPDX_S = "${S}/tools/perf"
> >
> >   # The LDFLAGS is required or some old kernels fails due missing
> > @@ -119,11 +119,12 @@ do_install() {
> >     fi
> >   }
> >
> > -do_configure_prepend () {
> > -# Fix for rebuilding
> > -rm -rf ${B}/
> > -mkdir -p ${B}/
> > +do_configure[prefuncs] += "git_clone_kernel_source"
> > +git_clone_kernel_source () {
> > +git clone --single-branch ${STAGING_KERNEL_DIR} ${S}
> I probably would have used "cp -a -r", or similar. Since it
> is possible that a kernel may not actually be a git repo
(linux-yocto
> always is, but that is just one data point).
>
> Also, did you try just copying the tools SRC dir + whatever
> infrastructure is needed to build ? That will save us a LOT
> of i/o when moving the source around for perf to build.
>



OK, I will copy the perf used src dir rather than the entire project source.


> But outside of those details/mechanics, the approach is sound.

Our "copy hardlink tree" function, whatever its called is sometimes of
use in these cases...



Got it, I will use oe.path.copyhardlinktree

//Hongxu


I think I'm the current owner of a bug in this area which I've sadly
not gotten to yet :(.

Also, have we considered the alternative - not copying tools/perf for
the kernel devsrc?


We could, but sometimes the devsrc is actually used to build the tools.
I know that I have used it to build perf in the past.

It is mostly skipped in my rewritten version (which I'll resubmit 
after 2.5

releases). So for now, I'm thinking the smallest footprint change makes
the most sense (as to which that is, that is probably not black and 
white).


Bruce


Cheers,

Richard
-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core





--
"Thou shalt not follow the NULL pointer, for chaos and madness await 
thee at its end"



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] perf: make a copy of kernel source to perf workdir

[Bruce Ashfield]

On Mon, Apr 23, 2018 at 6:05 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2018-04-23 at 13:51 -0400, Bruce Ashfield wrote:
> > On 2018-04-23 4:13 AM, Hongxu Jia wrote:
> > >
> > > Since perf modify kernel source which shared by multiple
> > > recipes, it probably caused kernel-devsrc compile failure
> > > at world build.
> > > ...
> > > >
> > > > 0 blocks
> > > > cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat:
> > > No such file or directory
> > > >
> > > > 0 blocks
> > > ...
> > > cpio tried to find a file at ${S}/tools/perf and failed
> > > if the input list is not valid.
> > >
> > > Make a copy of kernel shared source directory into a perf workdir
> > > could fix the issue.
> > >
> > > Drop `Fix for rebuilding' which is obsolete
> > >
> > > Signed-off-by: Hongxu Jia 
> > > ---
> > >   meta/recipes-kernel/perf/perf.bb | 11 ++-
> > >   1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-
> > > kernel/perf/perf.bb
> > > index 872b5f0..8b40806 100644
> > > --- a/meta/recipes-kernel/perf/perf.bb
> > > +++ b/meta/recipes-kernel/perf/perf.bb
> > > @@ -61,7 +61,7 @@ export PERL_ARCHLIB = "${STAGING_LIBDIR}${PERL_OW
> > > N_DIR}/perl/${@get_perl_version
> > >
> > >   inherit kernelsrc
> > >
> > > -B = "${WORKDIR}/${BPN}-${PV}"
> > > +S = "${WORKDIR}/${BP}"
> > >   SPDX_S = "${S}/tools/perf"
> > >
> > >   # The LDFLAGS is required or some old kernels fails due missing
> > > @@ -119,11 +119,12 @@ do_install() {
> > > fi
> > >   }
> > >
> > > -do_configure_prepend () {
> > > -# Fix for rebuilding
> > > -rm -rf ${B}/
> > > -mkdir -p ${B}/
> > > +do_configure[prefuncs] += "git_clone_kernel_source"
> > > +git_clone_kernel_source () {
> > > +git clone --single-branch ${STAGING_KERNEL_DIR} ${S}
> > I probably would have used "cp -a -r", or similar. Since it
> > is possible that a kernel may not actually be a git repo (linux-yocto
> > always is, but that is just one data point).
> >
> > Also, did you try just copying the tools SRC dir + whatever
> > infrastructure is needed to build ? That will save us a LOT
> > of i/o when moving the source around for perf to build.
> >
> > But outside of those details/mechanics, the approach is sound.
>
> Our "copy hardlink tree" function, whatever its called is sometimes of
> use in these cases...
>
> I think I'm the current owner of a bug in this area which I've sadly
> not gotten to yet :(.
>
> Also, have we considered the alternative - not copying tools/perf for
> the kernel devsrc?
>

We could, but sometimes the devsrc is actually used to build the tools.
I know that I have used it to build perf in the past.

It is mostly skipped in my rewritten version (which I'll resubmit after 2.5
releases). So for now, I'm thinking the smallest footprint change makes
the most sense (as to which that is, that is probably not black and white).

Bruce


>
> Cheers,
>
> Richard
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] toolchain-scripts: preserve host path in environment setup script

[Chin Huat Ang]

The environment setup script generated in the build directory sets the PATH
variable by expanding ${PATH} which would have host paths filtered. Sourcing
this script to run runqemu will not work as it complains host stty (/bin/stty)
cannot be found.

To resolve this, the script no longer expands ${PATH} during generation time,
instead it will now source oe-init-build-env to initialize the build
environment, followed by extending the PATH variable and including additional
environment variables for the build directory toolchain.

[YOCTO #12695]

Signed-off-by: Chin Huat Ang 
---
 meta/classes/toolchain-scripts.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index eeb320d..1f6d1aa 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -62,7 +62,8 @@ toolchain_create_tree_env_script () {
script=${TMPDIR}/environment-setup-${REAL_MULTIMACH_TARGET_SYS}
rm -f $script
touch $script
-   echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script
+   echo ". ${COREBASE}/oe-init-build-env ${TOPDIR}" >> $script
+   echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:$PATH' >> $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> 
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] perf: make a copy of kernel source to perf workdir

[Richard Purdie]

On Mon, 2018-04-23 at 13:51 -0400, Bruce Ashfield wrote:
> On 2018-04-23 4:13 AM, Hongxu Jia wrote:
> > 
> > Since perf modify kernel source which shared by multiple
> > recipes, it probably caused kernel-devsrc compile failure
> > at world build.
> > ...
> > > 
> > > 0 blocks
> > > cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat:
> > No such file or directory
> > > 
> > > 0 blocks
> > ...
> > cpio tried to find a file at ${S}/tools/perf and failed
> > if the input list is not valid.
> > 
> > Make a copy of kernel shared source directory into a perf workdir
> > could fix the issue.
> > 
> > Drop `Fix for rebuilding' which is obsolete
> > 
> > Signed-off-by: Hongxu Jia 
> > ---
> >   meta/recipes-kernel/perf/perf.bb | 11 ++-
> >   1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-
> > kernel/perf/perf.bb
> > index 872b5f0..8b40806 100644
> > --- a/meta/recipes-kernel/perf/perf.bb
> > +++ b/meta/recipes-kernel/perf/perf.bb
> > @@ -61,7 +61,7 @@ export PERL_ARCHLIB = "${STAGING_LIBDIR}${PERL_OW
> > N_DIR}/perl/${@get_perl_version
> >   
> >   inherit kernelsrc
> >   
> > -B = "${WORKDIR}/${BPN}-${PV}"
> > +S = "${WORKDIR}/${BP}"
> >   SPDX_S = "${S}/tools/perf"
> >   
> >   # The LDFLAGS is required or some old kernels fails due missing
> > @@ -119,11 +119,12 @@ do_install() {
> >     fi
> >   }
> >   
> > -do_configure_prepend () {
> > -# Fix for rebuilding
> > -rm -rf ${B}/
> > -mkdir -p ${B}/
> > +do_configure[prefuncs] += "git_clone_kernel_source"
> > +git_clone_kernel_source () {
> > +git clone --single-branch ${STAGING_KERNEL_DIR} ${S}
> I probably would have used "cp -a -r", or similar. Since it
> is possible that a kernel may not actually be a git repo (linux-yocto
> always is, but that is just one data point).
> 
> Also, did you try just copying the tools SRC dir + whatever
> infrastructure is needed to build ? That will save us a LOT
> of i/o when moving the source around for perf to build.
> 
> But outside of those details/mechanics, the approach is sound.

Our "copy hardlink tree" function, whatever its called is sometimes of
use in these cases...

I think I'm the current owner of a bug in this area which I've sadly
not gotten to yet :(.

Also, have we considered the alternative - not copying tools/perf for
the kernel devsrc?

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] udev-extraconf: Add systemd-mount to udev-extraconf/mount.sh

[Randy MacLeod]

On 2018-04-22 11:37 PM, Hongzhi, Song wrote:

ping


Please be patient.

0e-core-2.5 rc1 is being tested now and only critical blocking fixes are 
being accepted.


Once the results of 2.5 tests are good, then commits such as this one
can be added to the master[-next] branch and then later cherry-picked 
back to 2.5.1

if needed.

Give people a few days (or more if things don't go well) to get 2.5 out 
the door.


../Randy



// Hongzhi


On 2018年04月17日 15:03, Hongzhi.Song wrote:
Udev-extraconf works correctly with sysvinit in the aspect of 
automounting
block devices. But it has a serious problem in case of systemd. Block 
devices

automounted by udev is unaccessible to host space(out of udevd's private
namespace). For example, we cannot format those block devices.

e.g.
 root@qemux86:~# mkfs.ext4 /dev/sda1
 mke2fs 1.43.8 (1-Jan-2018)
 /dev/sda1 contains a ext4 file system
 last mounted on Tue Apr  3 06:22:41 2018
 Proceed anyway? (y,N) y
 /dev/sda1 is apparently in use by the system; will not make a 
filesystem here!


Other distributions has no such problem, because they use a series of 
rules to
manager block devices. Different types of block devices match 
different rules.
But udev-extraconf just use one rule, automount.rules, which results 
in this

problem.

The 'systemd-mount' command is recommended by the systemd community 
to solve such

problems.

This patch makes use of 'systemd-mount' to solve the above problem.

[YOCTO #12644]

Signed-off-by: Hongzhi.Song 
---
  meta/recipes-core/udev/udev-extraconf/mount.sh | 83 
--

  meta/recipes-core/udev/udev-extraconf_1.1.bb   |  3 +
  2 files changed, 69 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh

index d760328..067d4e2 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -4,10 +4,28 @@
  #
  # Attempt to mount any added block devices and umount any removed 
devices

  +BASE_INIT="`readlink "@base_sbindir@/init"`"
+INIT_SYSTEMD="@systemd_unitdir@/systemd"
+
+if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
+    # systemd as init uses systemd-mount to mount block devices
+    MOUNT="/usr/bin/systemd-mount"
+    UMOUNT="/usr/bin/systemd-umount"
+
+    if [ -x $MOUNT ] && [ -x $UMOUNT ];
+    then
+    logger "Using systemd-mount to finish mount"
+    else
+    logger "Linux init is using systemd, so please install 
systemd-mount to finish mount"

+    exit 1
+    fi
+else
+    MOUNT="/bin/mount"
+    UMOUNT="/bin/umount"
+fi
  -MOUNT="/bin/mount"
  PMOUNT="/usr/bin/pmount"
-UMOUNT="/bin/umount"
+
  for line in `grep -h -v ^# /etc/udev/mount.blacklist 
/etc/udev/mount.blacklist.d/*`

  do
  if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ];
@@ -17,7 +35,35 @@ do
  fi
  done
  -automount() {
+automount_systemd() {
+    name="`basename "$DEVNAME"`"
+
+    [ -d "/run/media/$name" ] || mkdir -p "/run/media/$name"
+
+    MOUNT="$MOUNT -o silent"
+
+    # If filesystemtype is vfat, change the ownership group to 
'disk', and

+    # grant it with  w/r/x permissions.
+    case $ID_FS_TYPE in
+    vfat|fat)
+    MOUNT="$MOUNT -o umask=007,gid=`awk -F':' '/^disk/{print 
$3}' /etc/group`"

+    ;;
+    # TODO
+    *)
+    ;;
+    esac
+
+    if ! $MOUNT --no-block -t auto $DEVNAME "/run/media/$name"
+    then
+    #logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME 
\"/run/media/$name\" failed!"

+    rm_dir "/run/media/$name"
+    else
+    logger "mount.sh/automount" "Auto-mount of 
[/run/media/$name] successful"

+    touch "/tmp/.automount-$name"
+    fi
+}
+
+automount() {
  name="`basename "$DEVNAME"`"
    ! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
@@ -26,7 +72,7 @@ automount() {
  then
  MOUNT="$MOUNT -o silent"
  fi
-
+
  # If filesystem type is vfat, change the ownership group to 
'disk', and

  # grant it with  w/r/x permissions.
  case $ID_FS_TYPE in
@@ -68,23 +114,26 @@ if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && 
[ -n "$ID_FS_TYPE" -o "$media_t

  elif [ -x $MOUNT ]; then
  $MOUNT $DEVNAME 2> /dev/null
  fi
-
+
  # If the device isn't mounted at this point, it isn't
  # configured in fstab (note the root filesystem can show up as
  # /dev/root in /proc/mounts, so check the device number too)
-    if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
-    grep -q "^$DEVNAME " /proc/mounts || automount
-    fi
+    if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
+    if [ "`basename $MOUNT`" = "systemd-mount" ];then
+    grep -q "^$DEVNAME " /proc/mounts || automount_systemd
+    else
+    grep -q "^$DEVNAME " /proc/mounts || automount
+    fi
+    fi
  fi
  -
  if [ "$ACTION" = "remove" ] || [ "$ACTION" = "change" ] && [ -x 
"$UMOUNT" ] && [ -n 

Re: [OE-core] [PATCH v2 1/1] recipes-core: breakout hwclock.sh from busybox

[Alex Stewart]

Bump x2.

On 04/09/2018 02:57 PM, Alex Stewart wrote:

Bump.

Did this patch get blacklisted for inclusion or does anyone have any 
outstanding concerns about it?


On 03/21/2018 01:55 PM, Alex Stewart wrote:

* Move the hwclock.sh initscript from busybox into its own package and
   recipe (hwclock-init). This script is generally useful for distros
   that get their hwclock implementation from sources other than
   busybox (like util-linux).

:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
   RDEPEND on hwclock-init.

:util-linux/*
* util-linux-hwclock RDEPENDS on hwclock-init for its initscript.

Signed-off-by: Alex Stewart 
---
  meta/recipes-core/busybox/busybox.inc  | 16 +++--
  meta/recipes-core/busybox/busybox_1.27.2.bb    |  1 -
  meta/recipes-core/busybox/files/hwclock.sh | 83 
--
  meta/recipes-core/hwclock-init/files/hwclock.sh    | 83 
++

  meta/recipes-core/hwclock-init/hwclock-init_1.0.bb | 31 
  meta/recipes-core/util-linux/util-linux.inc    |  1 +
  6 files changed, 124 insertions(+), 91 deletions(-)
  delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
  create mode 100644 meta/recipes-core/hwclock-init/files/hwclock.sh
  create mode 100644 meta/recipes-core/hwclock-init/hwclock-init_1.0.bb

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc

index d1675c37aa..50cc837335 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
    EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} 
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' 
HOSTCPP='${BUILD_CPP}'"
  -PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog 
${PN}-mdev ${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog 
${PN}-mdev"

    FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
  FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog* 
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf* 
${systemd_unitdir}/system/syslog.service 
${sysconfdir}/default/busybox-syslog"
  FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev 
${sysconfdir}/mdev.conf ${sysconfdir}/mdev/*"

  FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
  FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
  -INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd 
${PN}-mdev ${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd 
${PN}-mdev"

    INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
  INITSCRIPT_NAME_${PN}-mdev = "mdev"
  INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
  INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -284,9 +282,6 @@ do_install () {
  if grep "CONFIG_UDHCPD=y" ${B}/.config; then
  install -m 0755 ${WORKDIR}/busybox-udhcpd 
${D}${sysconfdir}/init.d/

  fi
-    if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
-    install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
-    fi
  if grep "CONFIG_UDHCPC=y" ${B}/.config; then
  install -d ${D}${sysconfdir}/udhcpc.d
  install -d ${D}${datadir}/udhcpc
@@ -375,6 +370,13 @@ python do_package_prepend () {
  else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid", 
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid", 
"${base_bindir}/busybox.suid")

+
+    # If busybox is configured to provide a hwclock implementation, 
add a

+    # package dependency on hwclock-init for the /etc/init.d/hwclock.sh
+    # initscript.
+    with open(d.getVar('B') + '/.config', 'r') as fp_conf:
+    if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+    d.appendVar('RDEPENDS_busybox', ' hwclock-init ')
  }
    pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb 
b/meta/recipes-core/busybox/busybox_1.27.2.bb

index 36a6342aaf..78d8e14a6b 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \

 file://busybox-udhcpd \
 file://default.script \
 file://simple.script \
-   file://hwclock.sh \
 file://mount.busybox \
 file://syslog \
 file://syslog-startup.conf \
diff --git a/meta/recipes-core/busybox/files/hwclock.sh 
b/meta/recipes-core/busybox/files/hwclock.sh

deleted file mode 100644
index be5f94d86c..00
--- a/meta/recipes-core/busybox/files/hwclock.sh
+++ /dev/null
@@ -1,83 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides:  hwclock
-# Required-Start:
-# Required-Stop: $local_fs
-# 

Re: [OE-core] [PATCH V2] perf: make a copy of kernel source to perf workdir

[Bruce Ashfield]

On 2018-04-23 4:13 AM, Hongxu Jia wrote:

Since perf modify kernel source which shared by multiple
recipes, it probably caused kernel-devsrc compile failure
at world build.
...
|0 blocks
|cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat:
No such file or directory
|0 blocks
...
cpio tried to find a file at ${S}/tools/perf and failed
if the input list is not valid.

Make a copy of kernel shared source directory into a perf workdir
could fix the issue.

Drop `Fix for rebuilding' which is obsolete

Signed-off-by: Hongxu Jia 
---
  meta/recipes-kernel/perf/perf.bb | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 872b5f0..8b40806 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -61,7 +61,7 @@ export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
  
  inherit kernelsrc
  
-B = "${WORKDIR}/${BPN}-${PV}"

+S = "${WORKDIR}/${BP}"
  SPDX_S = "${S}/tools/perf"
  
  # The LDFLAGS is required or some old kernels fails due missing

@@ -119,11 +119,12 @@ do_install() {
fi
  }
  
-do_configure_prepend () {

-# Fix for rebuilding
-rm -rf ${B}/
-mkdir -p ${B}/
+do_configure[prefuncs] += "git_clone_kernel_source"
+git_clone_kernel_source () {
+git clone --single-branch ${STAGING_KERNEL_DIR} ${S}


I probably would have used "cp -a -r", or similar. Since it
is possible that a kernel may not actually be a git repo (linux-yocto
always is, but that is just one data point).

Also, did you try just copying the tools SRC dir + whatever
infrastructure is needed to build ? That will save us a LOT
of i/o when moving the source around for perf to build.

But outside of those details/mechanics, the approach is sound.

Bruce



+}
  
+do_configure_prepend () {

  # If building a multlib based perf, the incorrect library path will be
  # detected by perf, since it triggers via: ifeq ($(ARCH),x86_64). In a 32 
bit
  # build, with a 64 bit multilib, the arch won't match and the detection 
of a



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] python3-native: correctly invoke regen-importlib make target

[Joe Slater]

Redefiine regen-all in Makefile to invoke regen-importlib after
building other regen- targets.  Change the recipe to not build it
before regen-all.  This avoids trying to build it multiple times,
which can occasionally fail.

Signed-off-by: Joe Slater 
---
 .../python/python3-native_3.5.5.bb |  5 +++--
 .../python/python3/regen-all.patch | 25 ++
 2 files changed, 28 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python3/regen-all.patch

diff --git a/meta/recipes-devtools/python/python3-native_3.5.5.bb 
b/meta/recipes-devtools/python/python3-native_3.5.5.bb
index 962ccfc..3098027 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.5.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.5.bb
@@ -25,6 +25,7 @@ file://sysconfig.py-add-_PYTHON_PROJECT_SRC.patch \
 file://setup.py-check-cross_compiling-when-get-FLAGS.patch \
 file://0001-Do-not-use-the-shell-version-of-python-config-that-w.patch \
 file://support_SOURCE_DATE_EPOCH_in_py_compile.patch \
+file://regen-all.patch \
 "
 
 SRC_URI[md5sum] = "f3763edf9824d5d3a15f5f646083b6e0"
@@ -62,9 +63,9 @@ do_configure_append() {
 
 # Regenerate all of the generated files
 # This ensures that pgen and friends get created during the compile phase
+#
 do_compile_prepend() {
-# Has to be done ahead of other regen- targets due to 
https://bugs.python.org/issue33080
-oe_runmake regen-importlib
+# Assuming https://bugs.python.org/issue33080 has been addressed in 
Makefile.
 oe_runmake regen-all
 }
 
diff --git a/meta/recipes-devtools/python/python3/regen-all.patch 
b/meta/recipes-devtools/python/python3/regen-all.patch
new file mode 100644
index 000..36b9d9d
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/regen-all.patch
@@ -0,0 +1,25 @@
+python3-native: run regen-importlib target correctly
+
+regen-importlib depends on other regen- targets, so we must be sure to
+run it after (most of) the others.  In reality, we do not need to run it
+at all since "make" will invoke it, if necessary.  We do not want to
+rely on that, though.
+
+Upstream-Status: Pending
+
+Signed-off-by: Joe Slater 
+
+
+
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -709,7 +709,8 @@ regen-importlib: Programs/_freeze_import
+ 
+ # Regenerate all generated files
+ 
+-regen-all: regen-opcode regen-opcode-targets regen-typeslots regen-grammar 
regen-ast regen-importlib
++regen-all: regen-opcode regen-opcode-targets regen-typeslots regen-grammar 
regen-ast
++  $(MAKE) regen-importlib
+ 
+ 
+ # Special rules for object files
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW17’18

[Jordan, Robin L]

Current Dev Position: YP 2.5 M4 final close out.

Next Deadline: YP 2.5 M4 release is 4/27/18


SWAT Team Rotation:

SWAT lead is currently: Tracy.

SWAT team rotation: Stephano -> Maxin on April 27, 2018

SWAT team rotation: Maxin -> Rebecca on March 4, 2018

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

  *   Several key uninative issues were identified and fixed which should mean 
uninative is much more reliable than previously as there were some rare but 
problematic corner cases which are now fixed.
  *   Other potentially 2.5 blocking changes such as timezone issues were fixed.
  *   We have documented sstate mirror setup for poky as opt-in, not by default 
and will monitor the usage of this to see how sustainable it is.
  *   Assuming the current test build succeeds, 2.5 rc1 will be built today.
  *   An email about 2.6 planning was sent out and people are invited to the 
next monthly technical call 
(https://www.yoctoproject.org/monthly-technical-call/). The email details the 
planning process we will be following along with some of the possible ideas for 
2.6. The email is: 
http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150040.html
  *   We are now tracking patch status in the tracking metrics below. The 
percentage of patches with Upstream-Status should stay at 100% now with our 
monitoring. Over time we want to reduce the percentage in the “Pending” state 
and the overall number of patches.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built after 2.5

YP 2.2.4 (Morty) will be built after 2.5

YP 2.4.3 (Rocko) is planned for post YP 2.5


Key YP 2.5 Dates are:

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

  *   WDD 2486 (last week 2573) 
(https://wiki.yoctoproject.org/charts/combo.html)
  *   Patches
 *   Total patches found: 1635
 *   Percentage of patches in the Pending State: 46%


Key Status Links for YP:

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

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

https://wiki.yoctoproject.org/wiki/Yocto_2.5_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!]

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] State of Sumo

[Peter Kjellerstedt]

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: den 21 april 2018 10:08
> To: Peter Kjellerstedt 
> Cc: OE-core 
> Subject: Re: [OE-core] State of Sumo
> 
> On 20 April 2018 at 23:42, Peter Kjellerstedt
>  wrote:
> > Not sure what the status is for patches for bitbake itself, but I
> have
> > one pending ("lib/bb/utils: prevent movefile from changing dest dir
> > permissions" sent to bitbake-devel on April 10), which I was hoping
> > would make it into Sumo. The effect when the bug strikes is pretty
> > weird, in our case it causes /etc to end up with mode 644 rather than
> > 755 when building an SDK in a Docker container...
> 
> I wouldn't call that a release blocker, so if we're good to go on
> Monday that can go to master instead and be backported to the Sumo
> branch asap.
> 
> Ross

Well, I cannot disagree with you on the status of the patch vs the 
release state of OE-Core. However, it has been a little bit 
disappointing to see more invasive patches being posted to the mailing 
list and subsequently being integrated, while this quite trivial patch 
has been neglected.

//Peter

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] perf: make a copy of kernel source to perf workdir

[Hongxu Jia]

Since perf modify kernel source which shared by multiple
recipes, it probably caused kernel-devsrc compile failure
at world build.
...
|0 blocks
|cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat:
No such file or directory
|0 blocks
...
cpio tried to find a file at ${S}/tools/perf and failed
if the input list is not valid.

Make a copy of kernel shared source directory into a perf workdir
could fix the issue.

Drop `Fix for rebuilding' which is obsolete

Signed-off-by: Hongxu Jia 
---
 meta/recipes-kernel/perf/perf.bb | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 872b5f0..8b40806 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -61,7 +61,7 @@ export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version
 
 inherit kernelsrc
 
-B = "${WORKDIR}/${BPN}-${PV}"
+S = "${WORKDIR}/${BP}"
 SPDX_S = "${S}/tools/perf"
 
 # The LDFLAGS is required or some old kernels fails due missing
@@ -119,11 +119,12 @@ do_install() {
fi
 }
 
-do_configure_prepend () {
-# Fix for rebuilding
-rm -rf ${B}/
-mkdir -p ${B}/
+do_configure[prefuncs] += "git_clone_kernel_source"
+git_clone_kernel_source () {
+git clone --single-branch ${STAGING_KERNEL_DIR} ${S}
+}
 
+do_configure_prepend () {
 # If building a multlib based perf, the incorrect library path will be
 # detected by perf, since it triggers via: ifeq ($(ARCH),x86_64). In a 32 
bit
 # build, with a 64 bit multilib, the arch won't match and the detection of 
a 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] package.bbclass: Make staticlib problems non-fatal

[Ola x Nilsson]

Allow debugsource listing using dwarfsourcefiles to fail for static
libraries when the archive content is not as expected.

Signed-off-by: Ola x Nilsson 
---
 meta/classes/package.bbclass | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 0436d919e7..d61b4ce8ca 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -344,12 +344,15 @@ def 
parse_debugsources_from_dwarfsrcfiles_output(dwarfsrcfiles_output):
 
 return debugfiles.keys()
 
-def append_source_info(file, sourcefile, d):
+def append_source_info(file, sourcefile, d, fatal=True):
 cmd = "'dwarfsrcfiles' '%s'" % (file)
 (retval, output) = oe.utils.getstatusoutput(cmd)
 # 255 means a specific file wasn't fully parsed to get the debug file 
list, which is not a fatal failure
 if retval != 0 and retval != 255:
-bb.fatal("dwarfsrcfiles failed with exit code %s (cmd was %s)%s" % 
(retval, cmd, ":\n%s" % output if output else ""))
+msg = "dwarfsrcfiles failed with exit code %s (cmd was %s)%s" % 
(retval, cmd, ":\n%s" % output if output else "")
+if fatal:
+bb.fatal(msg)
+bb.note(msg)
 
 debugsources = parse_debugsources_from_dwarfsrcfiles_output(output)
 # filenames are null-separated - this is an artefact of the previous use
@@ -1052,7 +1055,7 @@ python split_and_strip_files () {
 
 if debugsrcdir and not targetos.startswith("mingw"):
 for file in staticlibs:
-append_source_info(file, sourcefile, d)
+append_source_info(file, sourcefile, d, fatal=False)
 
 # Hardlink our debug symbols to the other hardlink copies
 for ref in inodes:
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core