[OE-core] [PATCH 0/1] man-db: remove '--disable-cache-owner' option

[Chen Qi]

*** BLURB HERE ***
The following changes since commit 2b2dfec80b6ce45325dfaa4bdf680ad0cd0a8460:

  libtool: Fix patch status tag (2018-08-01 10:28:05 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/man-db
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/man-db

Chen Qi (1):
  man-db: remove '--disable-cache-owner' option

 meta/recipes-extended/man-db/man-db_2.8.3.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1

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

[OE-core] [PATCH 1/1] man-db: remove '--disable-cache-owner' option

[Chen Qi]

The following error appeared at boot.

  systemd-tmpfiles[115]: [/usr/lib/tmpfiles.d/man-db.conf:1] Unknown user '1w'

By default cache owner is enabled and defaults to 'man'. Users could
supply '--enable-cache-owner=[ARG]' to change the default cache owner.
Using '--disable-cache-owner' leaves the ownership of system-wide
cache files unconstrained, and users will allowed to modify them.

We'd better keep the default behavior, just like other distros do.

I can guess that we used '--disable-cache-owner' to bypass the following
error at do_install.

  | chown: invalid user: ‘man:man’

The 'man' user is provided by base-passwd recipe, so add it to DEPENDS.

Signed-off-by: Chen Qi 
---
 meta/recipes-extended/man-db/man-db_2.8.3.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/man-db/man-db_2.8.3.bb 
b/meta/recipes-extended/man-db/man-db_2.8.3.bb
index 412e572..a214bd7 100644
--- a/meta/recipes-extended/man-db/man-db_2.8.3.bb
+++ b/meta/recipes-extended/man-db/man-db_2.8.3.bb
@@ -8,14 +8,14 @@ SRC_URI = 
"${SAVANNAH_NONGNU_MIRROR}/man-db/man-db-${PV}.tar.xz"
 SRC_URI[md5sum] = "6f3055e18fdd1ce5cbbdb30403991ec7"
 SRC_URI[sha256sum] = 
"5932a1ca366e1ec61a3ece1a3afa0e92f2fdc125b61d236f20cc6ff9d80cc4ac"
 
-DEPENDS = "libpipeline gdbm groff-native"
+DEPENDS = "libpipeline gdbm groff-native base-passwd"
 
 # | /usr/src/debug/man-db/2.8.0-r0/man-db-2.8.0/src/whatis.c:939: undefined 
reference to `_nl_msg_cat_cntr'
 USE_NLS_libc-musl = "no"
 
 inherit gettext pkgconfig autotools
 
-EXTRA_OECONF = "--with-pager=less --disable-cache-owner"
+EXTRA_OECONF = "--with-pager=less"
 
 do_install_append_libc-musl() {
 rm -f ${D}${libdir}/charset.alias
-- 
1.9.1

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

Re: [OE-core] [PATCH] devtool-source.bbclass: Support kernel fragments not in SRC_URI

[Anuj Mittal]

On 08/02/2018 07:30 AM, Alejandro Enedino Hernandez Samaniego wrote:
> Hey Anuj,
> 
> 
> On 08/01/2018 04:25 AM, Anuj Mittal wrote:
>> On 07/31/2018 05:21 AM, Jaewon Lee wrote:
>>> When using a recipe space kernel-meta, scc files are added through
>>> SRC_URI, but they may include corresponding kernel fragments that are
>>> not necessarily in SRC_URI.
>>>
>>> For bitbake, this is not a problem because the kernel-yocto class adds
>>> the path where the .scc file was found to includes which consequentially
>>> makes the .cfg file available to the kernel build.
>>>
>>> However, when using devtool, only files specified in SRC_URI are copied
>>> to oe-local-files in devtool's workspace. So if the cfg file is not in
>>> SRC_URI, it won't be copied, causing a kernel build failure when trying
>>> to find it.
>>>
>>> This fix parses local .scc files in SRC_URI, copies the corresponding .cfg
>>> file to devtool's workdir, and also adds it to local_files so it is
>>> available when doing a devtool build for the kernel.
>>>
>>> [YOCTO #12858]
>>>
>>> Signed-off-by: Jaewon Lee 
>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
>>> ---
>>>   meta/classes/devtool-source.bbclass | 12 
>>>   1 file changed, 12 insertions(+)
>>>
>>> diff --git a/meta/classes/devtool-source.bbclass 
>>> b/meta/classes/devtool-source.bbclass
>>> index 56882a4..c70fea2 100644
>>> --- a/meta/classes/devtool-source.bbclass
>>> +++ b/meta/classes/devtool-source.bbclass
>>> @@ -90,11 +90,23 @@ python devtool_post_unpack() {
>>>   fname in files])
>>>   return ret
>>>   
>>> +is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)
>>>   # Move local source files into separate subdir
>>>   recipe_patches = [os.path.basename(patch) for patch in
>>>   oe.recipeutils.get_recipe_patches(d)]
>>>   local_files = oe.recipeutils.get_recipe_local_files(d)
>>>   
>>> +if is_kernel_yocto:
>>> +  for key in local_files.copy():
>>> +if key.endswith('scc'):
>>> +  sccfile = open(local_files[key], 'r')
>>> +  for l in sccfile:
>>> +line = l.split()
>>> +if line and line[0] == 'kconf' and line[-1].endswith('.cfg'):
>>> +  local_files[line[-1]] = 
>>> os.path.join(os.path.dirname(local_files[key]), line[-1])
>>> +  shutil.copy2(os.path.join(os.path.dirname(local_files[key]), 
>>> line[-1]), workdir)
>>> +  sccfile.close()
>>> +
>> Would the patches included in these .scc files also need to be handled
>> in the same way? Would this also work if there are other scc files
>> included in a scc file?
> Yes, I believe that the same mechanism should be used for patch files as 
> well,
> basically anything that may be needed to build but that its not necessarily
> explicitly listed on SRC_URI.
> 
> I believe it will work for other scc files and it doesnt have to be 
> recursive,
> because while cfg files arent required to be in SRC_URI , scc files ARE 
> required
> to be SRC_URI, which means that this will eventually find the other scc 
> file on the list

I don't think they are required to be specified except for the top level
one. At least, when I test it, I see problems. kernel-tools spp script
parses them recursively and looks for a nested scc even if it is not
specified as part of SRC_URI. That is how the top level sccs from
kernel-cache are parsed too. Can you give it a try please?

Thanks,

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

[OE-core] [oe-core][PATCH 2/3] udev-extraconf/mount.sh: Fix the recursively dependency for the systemd-mount

[Hongzhi.Song]

If systemd is used, using the systemd-mount to mount the new added disk
partitions forgets to move the codes which tries to mount the partition
by using the configuration in /etc/fstab to the non-systemd function.

And it will cause the systemd-mount try to mount the partition
synchronously and trigger a recursively dependency like the following:
dev-sda1.device -> run-media-sda1.mount -> dev-sda1.device

Signed-off-by: Kevin Hao 
Signed-off-by: Hongzhi.Song 
---
 meta/recipes-core/udev/udev-extraconf/mount.sh | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index 3a72c455e0..816d975e5e 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -63,6 +63,16 @@ automount_systemd() {
 automount() {  
name="`basename "$DEVNAME"`"
 
+   if [ -x "$PMOUNT" ]; then
+   $PMOUNT $DEVNAME 2> /dev/null
+   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
+   grep -q "^$DEVNAME " /proc/mounts && return
+
! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
# Silent util-linux's version of mounting auto
if [ "x`readlink $MOUNT`" = "x/bin/mount.util-linux" ] ;
@@ -105,19 +115,13 @@ rm_dir() {
 name="`basename "$DEVNAME"`"
 [ -e /sys/block/$name/device/media ] && media_type=`cat 
/sys/block/$name/device/media`
 if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n "$ID_FS_TYPE" -o 
"$media_type" = "cdrom" ]; then
-   if [ -x "$PMOUNT" ]; then
-   $PMOUNT $DEVNAME 2> /dev/null
-   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)
+   # 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
if [ "`basename $MOUNT`" = "systemd-mount" ];then
-   grep -q "^$DEVNAME " /proc/mounts || automount_systemd
+   automount_systemd
else
-   grep -q "^$DEVNAME " /proc/mounts || automount
+   automount
fi
fi
 fi
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 3/3] udev-extraconf/mount.sh: Skip the entry in /etc/fstab when using the systemd-mount

[Hongzhi.Song]

When using systemd, the systemd-fstab-generator would parse the
/etc/fstab and create the corresponding unit dynamically. So we don't
need to handle the ADD action for the partitions in /etc/fstab.

Signed-off-by: Kevin Hao 
Signed-off-by: Hongzhi.Song 
---
 meta/recipes-core/udev/udev-extraconf/mount.sh | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index 816d975e5e..9796cd7b90 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -36,6 +36,15 @@ done
 automount_systemd() {
name="`basename "$DEVNAME"`"
 
+   # Skip the partition which are already in /etc/fstab
+   grep "^[[:space:]]*$DEVNAME" /etc/fstab && return
+   for n in LABEL PARTLABEL UUID PARTUUID; do
+   tmp="$(lsblk -o $n $DEVNAME | sed -e '1d')"
+   test -z "$tmp" && continue
+   tmp="$n=$tmp"
+   grep "^[[:space:]]*$tmp" /etc/fstab && return
+   done
+
 ! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
 # Silent util-linux's version of mounting auto
 MOUNT="$MOUNT -o silent"
-- 
2.11.0

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

[OE-core] [oe-core][PATCH v4 1/3] udev-extraconf/mount.sh: add support to systemd

[Hongzhi.Song]

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
/dev/sda1 contains a ext4 file system
last mounted on Tue Apr
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 | 55 +++---
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index d760328a09..3a72c455e0 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -4,10 +4,26 @@
 #
 # Attempt to mount any added block devices and umount any removed devices
 
+BASE_INIT="`readlink "/sbin/init"`"
+INIT_SYSTEMD="/lib/systemd/systemd"
+
+if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
+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"
+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,6 +33,33 @@ do
fi
 done
 
+automount_systemd() {
+   name="`basename "$DEVNAME"`"
+
+! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
+# Silent util-linux's version of mounting auto
+MOUNT="$MOUNT -o silent"
+
+# If filesystem type 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
+rm_dir "/run/media/$name"
+else
+logger "mount.sh/automount" "systemd-mount of 
[/run/media/$name] successful"
+touch "/tmp/.automount-$name"
+fi
+}
+
 automount() {  
name="`basename "$DEVNAME"`"
 
@@ -61,19 +104,21 @@ rm_dir() {
 # No ID_FS_TYPE for cdrom device, yet it should be mounted
 name="`basename "$DEVNAME"`"
 [ -e /sys/block/$name/device/media ] && media_type=`cat 
/sys/block/$name/device/media`
-
 if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n "$ID_FS_TYPE" -o 
"$media_type" = "cdrom" ]; then
if [ -x "$PMOUNT" ]; then
$PMOUNT $DEVNAME 2> /dev/null
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
+   if [ "`basename $MOUNT`" = "systemd-mount" ];then
+   grep -q "^$DEVNAME " /proc/mounts || automount_systemd
+   else
+   grep -q "^$DEVNAME " /proc/mounts || automount
+   fi
fi
 fi
 
-- 
2.11.0

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

[OE-core] [oe-core][PATCH v4 0/3] udev-extraconf/mount.sh: add support to systemd

[Hongzhi.Song]

v4:
Fix the recursively dependency for the systemd-mount
v3:
perfect syntax

Hongzhi.Song (3):
  udev-extraconf/mount.sh: add support to systemd
  udev-extraconf/mount.sh: Fix the recursively dependency for the
systemd-mount
  udev-extraconf/mount.sh: Skip the entry in /etc/fstab when using the
systemd-mount

 meta/recipes-core/udev/udev-extraconf/mount.sh | 84 ++
 1 file changed, 71 insertions(+), 13 deletions(-)

-- 
2.11.0

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

Re: [OE-core] [PATCH] devtool-source.bbclass: Support kernel fragments not in SRC_URI

[Alejandro Enedino Hernandez Samaniego]

Hey Anuj,


On 08/01/2018 04:25 AM, Anuj Mittal wrote:

On 07/31/2018 05:21 AM, Jaewon Lee wrote:

When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments that are
not necessarily in SRC_URI.

For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which consequentially
makes the .cfg file available to the kernel build.

However, when using devtool, only files specified in SRC_URI are copied
to oe-local-files in devtool's workspace. So if the cfg file is not in
SRC_URI, it won't be copied, causing a kernel build failure when trying
to find it.

This fix parses local .scc files in SRC_URI, copies the corresponding .cfg
file to devtool's workdir, and also adds it to local_files so it is
available when doing a devtool build for the kernel.

[YOCTO #12858]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
  meta/classes/devtool-source.bbclass | 12 
  1 file changed, 12 insertions(+)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 56882a4..c70fea2 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -90,11 +90,23 @@ python devtool_post_unpack() {
  fname in files])
  return ret
  
+is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)

  # Move local source files into separate subdir
  recipe_patches = [os.path.basename(patch) for patch in
  oe.recipeutils.get_recipe_patches(d)]
  local_files = oe.recipeutils.get_recipe_local_files(d)
  
+if is_kernel_yocto:

+  for key in local_files.copy():
+if key.endswith('scc'):
+  sccfile = open(local_files[key], 'r')
+  for l in sccfile:
+line = l.split()
+if line and line[0] == 'kconf' and line[-1].endswith('.cfg'):
+  local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
+  shutil.copy2(os.path.join(os.path.dirname(local_files[key]), 
line[-1]), workdir)
+  sccfile.close()
+

Would the patches included in these .scc files also need to be handled
in the same way? Would this also work if there are other scc files
included in a scc file?
Yes, I believe that the same mechanism should be used for patch files as 
well,

basically anything that may be needed to build but that its not necessarily
explicitly listed on SRC_URI.

I believe it will work for other scc files and it doesnt have to be 
recursive,
because while cfg files arent required to be in SRC_URI , scc files ARE 
required
to be SRC_URI, which means that this will eventually find the other scc 
file on the list


Cheers,

Alejandro



Thanks,

Anuj


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

Re: [OE-core] [PATCH] devtool-source.bbclass: Support kernel fragments not in SRC_URI

[Anuj Mittal]

On 08/02/2018 08:27 AM, Jaewon Lee wrote:
> Hi Anuj,
> 
> Thanks for the reply
> That is a good point, will send a v2 that also deals with patches.
> Regarding other scc files,  according to the kernel dev manual, 
> "It is only necessary to specify the .scc files on the SRC_URI."
> 
> So from my understanding all scc files will be in SRC_URI which means they 
> get parsed by this fix, 
> Is this not the case?
If a scc file, foo.scc, includes any other scc file say bar.scc, then it
isn't mandatory to specify bar.scc as part of SRC_URI I think.

You can give it a try by creating empty sccs and including a malformed
patch in a nested scc to see if you get an error while patching.

Thanks,

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

[OE-core] [PATCH] ffmpeg: Upgrade to 4.0.2

[mingli.yu]

From: Mingli Yu 

Signed-off-by: Mingli Yu 
---
 .../ffmpeg/{ffmpeg_4.0.bb => ffmpeg_4.0.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/ffmpeg/{ffmpeg_4.0.bb => ffmpeg_4.0.2.bb} (97%)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.0.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.0.2.bb
similarity index 97%
rename from meta/recipes-multimedia/ffmpeg/ffmpeg_4.0.bb
rename to meta/recipes-multimedia/ffmpeg/ffmpeg_4.0.2.bb
index e105ea2c00..57731e81e6 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.0.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.0.2.bb
@@ -26,8 +26,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
file://mips64_cpu_detection.patch \
"
-SRC_URI[md5sum] = "1cc9e8cb027b9fd4c54f598f51002c19"
-SRC_URI[sha256sum] = 
"ed945daf40b124e77a685893cc025d086f638bc703183460aff49508edb3a43f"
+SRC_URI[md5sum] = "ae0bfdf809306a212b4f0e6eb8d1c75e"
+SRC_URI[sha256sum] = 
"a95c0cc9eb990e94031d2183f2e6e444cc61c99f6f182d1575c433d62afb2f97"
 
 # Build fails when thumb is enabled: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
 ARM_INSTRUCTION_SET_armv4 = "arm"
-- 
2.17.1

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

[OE-core] [PATCH v2] devtool-source.bbclass: Support kernel-fragments/patch not in SRC_URI

[Jaewon Lee]

When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments or patches
that are not necessarily in SRC_URI.

For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which consequentially
makes the .cfg, .patch file available to the kernel build.

However, when using devtool, only files specified in SRC_URI are copied
to oe-local-files in devtool's workspace. So if the cfg/patch file is not in
SRC_URI, it won't be copied, causing a kernel build failure when trying
to find it.

This fix parses local .scc files in SRC_URI, copies the corresponding
.cfg/.patch file to devtool's workdir, and also adds it to local_files
so it is available when doing a devtool build for the kernel.

[YOCTO #12858]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 56882a4..623b335 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -90,11 +90,23 @@ python devtool_post_unpack() {
 fname in files])
 return ret
 
+is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)
 # Move local source files into separate subdir
 recipe_patches = [os.path.basename(patch) for patch in
 oe.recipeutils.get_recipe_patches(d)]
 local_files = oe.recipeutils.get_recipe_local_files(d)
 
+if is_kernel_yocto:
+  for key in local_files.copy():
+if key.endswith('scc'):
+  sccfile = open(local_files[key], 'r')
+  for l in sccfile:
+line = l.split()
+if line and line[0] in ('kconf', 'patch'):
+  local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
+  shutil.copy2(os.path.join(os.path.dirname(local_files[key]), 
line[-1]), workdir)
+  sccfile.close()
+
 # Ignore local files with subdir={BP}
 srcabspath = os.path.abspath(srcsubdir)
 local_files = [fname for fname in local_files if
-- 
2.7.4

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

Re: [OE-core] [PATCH 2/2] multiconfig: Enable multiconfig dependencies on oe-core

[Alejandro Enedino Hernandez Samaniego]

Hey Khem, Richard,


On 08/01/2018 10:44 AM, Khem Raj wrote:



On Tue, Jul 31, 2018 at 4:59 AM Richard Purdie 
> wrote:


On Mon, 2018-07-30 at 15:05 -0700, Alejandro Enedino Hernandez
Samaniego wrote:
> On 07/26/2018 08:36 PM, Khem Raj wrote:
> >
> > On 7/25/18 9:05 AM, Alejandro Enedino Hernandez Samaniego wrote:
> > > This patch enables multiconfig dependencies (mcdepends) to be
> > > used on
> > > recipes using the following format:
> > >
> > > task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-
> > > on"
> > >
> > > For the sake of simplicity consider the following example:
> > >
> > > Assuming we have set up multiconfig builds, one for qemux86 and
> > > one for
> > > qemuarm, named x86 and arm respectively.
> > >
> > > Adding the following line to an image recipe (core-image-sato):
> > > do_image[mcdepends] = "multiconfig:x86:arm:core-image-
> > > minimal:do_rootfs"
> > >
> >
> > Do we really need to add multiconfig to keyword namespace ? can we
> > deduce this from "arch1:arch2:..."
>
> Bitbake already uses this and I believed adopting it would make it
> easier for the user to understand its usage.
>
> For example, since the multiconfig names are also provided during
> setup, if you assume that someone set up the build and a different
> user is going through the recipe, arch1:arch2 wouldn't mean a
lot for
> that user because they may not map 1:1 to MACHINE names.

It is consistent with the rest of the system. I'm still torn on
whether
we should shorten "multiconfig:" to "mc:" but we need to be
consistent.


Given a choice I would suggest for using multiconfig for lesser chance 
of conflicts

I also agree here that its better to use multiconfig.



> > secondy, this need to be well documented, with examples for users
>
> I agree we could add more documentation to it, where do you
think it
> should go?

I'm going to queue the patches for testing in -next, they look good to
me just reading the patches.

Could you start to work with Scott (cc'd) to get this new dependency
type listed in the bitbake manual and anywhere else it needs to be
documented?


Sure, I'll sync with Scott

Thanks!,

Alejandro



Its great to see this finally working!

Cheers,

Richard



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

Re: [OE-core] Strip kernel modules and signatures

[Andre McCurdy]

On Wed, Aug 1, 2018 at 3:46 PM, Ocampo Coronado, Omar
 wrote:
> Hello OE,
>
> While attempting to sign our kernel modules (using the kernel configuration  
> CONFIG_MODULE_SIG) the drivers in our image did not have the signature, even 
> the certificate was being loaded by the kernel or the driver being signed 
> during do_install().
>
> Turns out package.bbclass, while it ignores to create debug info files it 
> does strips the kernel modules files:
>
> python split_and_strip_files () {
> ...
> ...
> for f in kernmods:
>   sfiles.append((f, 16, strip))
>
> oe.utils.multiprocess_exec(sfiles, oe.package.runstrip)
> #
> # End of strip
> #
> os.chdir(oldcwd)
> }
>
> The strip is required for many reasons yet it removes the signature which we 
> want to preserve in this scenario.
> To work around this issue add
>  INHIBIT_PACKAGE_STRIP = "1"
>  either on your virtual/kernel bb file or driver bb file.
>
> Hope this helps someone in the future when adding signature to files, perhaps 
> including this into the Yocto kernel development manual.

The better fix would perhaps be to determine which section the
signature information is stored in and then update the code which
strips kernel modules to specifically leave that section intact.

> Cheers
>
> P.S.
> In a linux-intel kernel (master) without stripped kernel modules the image 
> size increased in 650kb.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Strip kernel modules and signatures

[Ocampo Coronado, Omar]

Hello OE,

While attempting to sign our kernel modules (using the kernel configuration  
CONFIG_MODULE_SIG) the drivers in our image did not have the signature, even 
the certificate was being loaded by the kernel or the driver being signed 
during do_install().

Turns out package.bbclass, while it ignores to create debug info files it does 
strips the kernel modules files:

python split_and_strip_files () {
...
...
for f in kernmods:
  sfiles.append((f, 16, strip))

oe.utils.multiprocess_exec(sfiles, oe.package.runstrip)
#
# End of strip
#
os.chdir(oldcwd)
}

The strip is required for many reasons yet it removes the signature which we 
want to preserve in this scenario.
To work around this issue add
 INHIBIT_PACKAGE_STRIP = "1"
 either on your virtual/kernel bb file or driver bb file.

Hope this helps someone in the future when adding signature to files, perhaps 
including this into the Yocto kernel development manual.

Cheers

P.S.
In a linux-intel kernel (master) without stripped kernel modules the image size 
increased in 650kb. 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] machine: remove kernel-modules from RRECOMMENDS

[Burton, Ross]

I believe the rationale for genericx86 is "this BSP should boot on
most hardware, so build and ship all the modules".

Ross

On 1 August 2018 at 12:58, Maxin B. John  wrote:
> Hi Anuj,
>
> On Wed, Aug 01, 2018 at 10:43:03AM +0800, Anuj Mittal wrote:
>> On 07/31/2018 11:22 PM, openembedded-core-boun...@lists.openembedded.org
>> wrote:
>> > On Tue, 2018-07-31 at 17:15 +0300, Maxin B. John wrote:
>> >> qemumips,qemumips64 and x86 based machines include kernel-modules by
>> >> default. Remove the kernel modules from RRECOMMENDS to make it
>> >> consistent
>> >> across the machines.
>> >>
>> >> Tested using core-image-sato on qemumips, qemumips64, qemux86 and
>> >> qemux86-64
>> >>
>> >> [YOCTO #12383]
>> >>
>> >> Signed-off-by: Maxin B. John 
>> >> ---
>> >>  meta/conf/machine/include/x86-base.inc | 2 --
>> >>  meta/conf/machine/qemumips.conf| 2 --
>> >>  meta/conf/machine/qemumips64.conf  | 2 --
>> >>  3 files changed, 6 deletions(-)
>> >
>> > Looks good, do we need to add this to genericx86 or anything in meta-
>> > intel given its changing x86-base.inc?
>> >
>>
>> meta-intel explicitly includes the modules so no change needed there. I
>> have sent the patch for genericx86 where it should be included now.
>
> Thanks, Just curious why we need to change genericx86. Do we have a list
> of kernel modules which are required there ?
>
>> Thanks,
>> Anuj
>
> Best Regards,
> Maxin
> --
> ___
> 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] openssl_1.0: drop unnecessary dependency on makedepend-native

[Andre McCurdy]

On Wed, Aug 1, 2018 at 12:44 AM, Andrej Valek  wrote:
> If you are pretty sure, that makedepend command will available after
> makedepend-native package dropping, I am fine with that.

I am sure that the makedepend command will NOT be available after
removing the makedepend-native dependency.

Perhaps the explanation I tried to give in the git commit wasn't as
clear as I thought... could you please read it and let me know which
part doesn't make sense?

> Cheers,
> Andrej
>
> On 07/31/18 15:34, Andre McCurdy wrote:
>> On Tue, Jul 31, 2018 at 3:24 AM, Andrej Valek  
>> wrote:
>>> This program is required for "oe_runmake depend" command. It runs
>>> command in MAKEDEPPROG variable, which is set to makedepend. Makedepend
>>> consists from makedepend-native package.
>>
>> That's what you might guess from casually reading the Makefile. It's
>> not what actually happens.
>>
>>> Cheers,
>>> Andrej
>>>
>>> On 07/31/18 12:08, Richard Purdie wrote:
 On Mon, 2018-07-30 at 18:28 -0700, Andre McCurdy wrote:
> The openssl Configure script will only select standalone makedepend
> (vs running "$CC -M") when building with gcc < 3.x or with an Apple
> Xcode version which predates the switch to clang (in approx 2010?).
> Neither of these cases are possible when building under OE, therefore
> the dependency on makedepend-native can be dropped (ie align the
> openssl 1.0 recipe with the 1.1 recipe, which has dropped the
> makedepend-native dependency already).
>
> Signed-off-by: Andre McCurdy 
> ---
>  meta/recipes-connectivity/openssl/openssl_1.0.2o.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
> b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
> index f5d3274..78c8552 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
> @@ -8,7 +8,7 @@ SECTION = "libs/network"
>  LICENSE = "openssl"
>  LIC_FILES_CHKSUM =
> "file://LICENSE;md5=f475368924827d06d4b416111c8bdb77"
>
> -DEPENDS = "makedepend-native hostperl-runtime-native"
> +DEPENDS = "hostperl-runtime-native"
>  DEPENDS_append_class-target = " openssl-native"
>
>  PROVIDES += "openssl10"

 This was added quite 'recently' in:

 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=50c23e6c26a64b0c04e99abacb61ec00d1abace9

 I've cc'd Andrej in case he can tell us why that was needed?

 Cheers,

 Richard

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

Re: [OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?

[Andre McCurdy]

On Wed, Aug 1, 2018 at 1:35 PM, Ryan Pabis (pabisr) via
Openembedded-core  wrote:
> Alex,
>
> The library was precompiled by tail-f but I've also recompiled on Ubuntu 
> 16.04 with openssl 1.0.2n.  In both cases the library crypto.so and 
> libconfd.so refer to libcrypto.so.1.0.0.
>
> Having a pre-compiled library worked on krogoth and morty, but does not seem 
> to work on rocko.

You can often find the answer to questions like this by looking at the
git history and reading the comments from the commit which made a
particular change. In this case see:

  
http://git.openembedded.org/openembedded-core/commit/?id=1b430eef7131876bc735c22d66358379b0516821

ie the explanation given was that other distros are not consistent in
the soname they use and oe-core has chosen to follow Debian - which
apparently uses 1.0.2.

If you have a library which needs 1.0.0 then you can try to hack
around the mismatch by adding symlinks from libXXX.so.1.0.0 ->
libXXX.so.1.0.2 in the rootfs (and ignoring the file-rdeps QA test).

But as Alex mentions, be very careful about just copying binaries
created outside OE into an OE rootfs. By over-riding the soname you
are basically disabling sanity checks that prevent mismatches in
library APIs, so you could see crashes etc at runtime. The fact that
your preompiled library worked on krogoth and morty may just have been
luck.

If you have the source to (re)build under Ubuntu then why can't you
also build from an OE recipe? That would be the real solution.


> On 8/1/18, 3:47 PM, "Alexander Kanavin"  wrote:
>
> 2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core
> :
> > I have a library that uses libcrypto.so.1.0.0 from openssl 1.0.2n, 
> which is
> > the libcrypto.so version if you download the source code to ubuntu 16.04
> > from openssl and compile.  However, Yocto Rocko uses the same openssl 
> 1.0.2n
> > version but it uses libcrypto.so.1.0.2 and sets the FILERDEPENDS_ to the
> > same.  This causes a file_rdeps issue for me because it says
> > libcrypto.so.1.0.0()(64bit) is not provided.
> >
> >
> >
> > I’ve tried adding, DEPENDS += “openssl” and RPDEPENDS_confd += 
> “openssl”,
> > with no luck.  The only way I can get it to compile is if I manually 
> hack my
> > library and change from libcrypto.so.1.0.0 to libcrypto.so.1.0.2 (even
> > though it was really compiled with libcrypto.so.1.0.0 and that’s the
> > libcrypto version of openssl 1.0.2n).
> >
> >
> >
> > Can someone please advise?
>
> In which environment was the library built? You generally cannot take
> something that was compiled outside of Yocto. Write a recipe that
> builds the library from source code, or ask the provider of that
> library to do that.
>
> Alex
>
>
> --
> ___
> 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] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?

[Ryan Pabis (pabisr) via Openembedded-core]

Alex,

The library was precompiled by tail-f but I've also recompiled on Ubuntu 16.04 
with openssl 1.0.2n.  In both cases the library crypto.so and libconfd.so refer 
to libcrypto.so.1.0.0.

Having a pre-compiled library worked on krogoth and morty, but does not seem to 
work on rocko.

Ryan

On 8/1/18, 3:47 PM, "Alexander Kanavin"  wrote:

2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core
:
> I have a library that uses libcrypto.so.1.0.0 from openssl 1.0.2n, which 
is
> the libcrypto.so version if you download the source code to ubuntu 16.04
> from openssl and compile.  However, Yocto Rocko uses the same openssl 
1.0.2n
> version but it uses libcrypto.so.1.0.2 and sets the FILERDEPENDS_ to the
> same.  This causes a file_rdeps issue for me because it says
> libcrypto.so.1.0.0()(64bit) is not provided.
>
>
>
> I’ve tried adding, DEPENDS += “openssl” and RPDEPENDS_confd += “openssl”,
> with no luck.  The only way I can get it to compile is if I manually hack 
my
> library and change from libcrypto.so.1.0.0 to libcrypto.so.1.0.2 (even
> though it was really compiled with libcrypto.so.1.0.0 and that’s the
> libcrypto version of openssl 1.0.2n).
>
>
>
> Can someone please advise?

In which environment was the library built? You generally cannot take
something that was compiled outside of Yocto. Write a recipe that
builds the library from source code, or ask the provider of that
library to do that.

Alex


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

Re: [OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?

[Alexander Kanavin]

2018-08-01 20:20 GMT+02:00 Ryan Pabis (pabisr) via Openembedded-core
:
> I have a library that uses libcrypto.so.1.0.0 from openssl 1.0.2n, which is
> the libcrypto.so version if you download the source code to ubuntu 16.04
> from openssl and compile.  However, Yocto Rocko uses the same openssl 1.0.2n
> version but it uses libcrypto.so.1.0.2 and sets the FILERDEPENDS_ to the
> same.  This causes a file_rdeps issue for me because it says
> libcrypto.so.1.0.0()(64bit) is not provided.
>
>
>
> I’ve tried adding, DEPENDS += “openssl” and RPDEPENDS_confd += “openssl”,
> with no luck.  The only way I can get it to compile is if I manually hack my
> library and change from libcrypto.so.1.0.0 to libcrypto.so.1.0.2 (even
> though it was really compiled with libcrypto.so.1.0.0 and that’s the
> libcrypto version of openssl 1.0.2n).
>
>
>
> Can someone please advise?

In which environment was the library built? You generally cannot take
something that was compiled outside of Yocto. Write a recipe that
builds the library from source code, or ask the provider of that
library to do that.

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

[OE-core] Why does Openssl 1.0.2n use libcrypto.so.1.0.2 and not libcrypto.so.1.0.0?

[Ryan Pabis (pabisr) via Openembedded-core]

All,

I have a library that uses libcrypto.so.1.0.0 from openssl 1.0.2n, which is the 
libcrypto.so version if you download the source code to ubuntu 16.04 from 
openssl and compile.  However, Yocto Rocko uses the same openssl 1.0.2n version 
but it uses libcrypto.so.1.0.2 and sets the FILERDEPENDS_ to the same.  This 
causes a file_rdeps issue for me because it says libcrypto.so.1.0.0()(64bit) is 
not provided.

I’ve tried adding, DEPENDS += “openssl” and RPDEPENDS_confd += “openssl”, with 
no luck.  The only way I can get it to compile is if I manually hack my library 
and change from libcrypto.so.1.0.0 to libcrypto.so.1.0.2 (even though it was 
really compiled with libcrypto.so.1.0.0 and that’s the libcrypto version of 
openssl 1.0.2n).

Can someone please advise?

Regards,
Ryan



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

Re: [OE-core] [PATCH 2/2] multiconfig: Enable multiconfig dependencies on oe-core

[Khem Raj]

On Tue, Jul 31, 2018 at 4:59 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2018-07-30 at 15:05 -0700, Alejandro Enedino Hernandez
> Samaniego wrote:
> > On 07/26/2018 08:36 PM, Khem Raj wrote:
> > >
> > > On 7/25/18 9:05 AM, Alejandro Enedino Hernandez Samaniego wrote:
> > > > This patch enables multiconfig dependencies (mcdepends) to be
> > > > used on
> > > > recipes using the following format:
> > > >
> > > > task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-
> > > > on"
> > > >
> > > > For the sake of simplicity consider the following example:
> > > >
> > > > Assuming we have set up multiconfig builds, one for qemux86 and
> > > > one for
> > > > qemuarm, named x86 and arm respectively.
> > > >
> > > > Adding the following line to an image recipe (core-image-sato):
> > > > do_image[mcdepends] = "multiconfig:x86:arm:core-image-
> > > > minimal:do_rootfs"
> > > >
> > >
> > > Do we really need to add multiconfig to keyword namespace ? can we
> > > deduce this from "arch1:arch2:..."
> >
> > Bitbake already uses this and I believed adopting it would make it
> > easier for the user to understand its usage.
> >
> > For example, since the multiconfig names are also provided during
> > setup, if you assume that someone set up the build and a different
> > user is going through the recipe, arch1:arch2 wouldn't mean a lot for
> > that user because they may not map 1:1 to MACHINE names.
>
> It is consistent with the rest of the system. I'm still torn on whether
> we should shorten "multiconfig:" to "mc:" but we need to be consistent.
>

Given a choice I would suggest for using multiconfig for lesser chance of
conflicts

>
> > > secondy, this need to be well documented, with examples for users
> >
> > I agree we could add more documentation to it, where do you think it
> > should go?
>
> I'm going to queue the patches for testing in -next, they look good to
> me just reading the patches.
>
> Could you start to work with Scott (cc'd) to get this new dependency
> type listed in the bitbake manual and anywhere else it needs to be
> documented?
>
> Its great to see this finally working!
>
> Cheers,
>
> Richard
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] "make clean" on Weston

[Adam Lee]

Neither "bitbake -c clean weston" nor "bitbake -c cleanall weston" seems to
clean the build directory for me.
Is this how it is for autotool project? "make clean" doesn't work either
("no rule to make target clean").

I need my directory cleaned so I can commit only the necessary changes.

/build/workspace/sources/weston$ git status
On branch devtool
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   Makefile.am
modified:   Makefile.in
modified:   aclocal.m4
modified:   build-aux/compile
modified:   build-aux/config.guess
modified:   build-aux/config.sub
modified:   build-aux/depcomp
modified:   build-aux/install-sh
modified:   build-aux/ltmain.sh
modified:   build-aux/missing
modified:   build-aux/test-driver
modified:   clients/ivi-shell-user-interface.c
modified:   clients/simple-egl.c
modified:   clients/simple-touch.c
modified:   config.h.in
modified:   configure
modified:   ivi-shell/hmi-controller.c
modified:   ivi-shell/ivi-layout.c
modified:   ivi-shell/ivi-shell.c
modified:   libweston/input.c
modified:   libweston/libinput-device.c
modified:   m4/libtool.m4
modified:   m4/ltoptions.m4
modified:   m4/ltsugar.m4
modified:   m4/ltversion.m4
modified:   m4/lt~obsolete.m4

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

Re: [OE-core] [PATCH] machine: remove kernel-modules from RRECOMMENDS

[Maxin B. John]

Hi Anuj,

On Wed, Aug 01, 2018 at 10:43:03AM +0800, Anuj Mittal wrote:
> On 07/31/2018 11:22 PM, openembedded-core-boun...@lists.openembedded.org
> wrote:
> > On Tue, 2018-07-31 at 17:15 +0300, Maxin B. John wrote:
> >> qemumips,qemumips64 and x86 based machines include kernel-modules by
> >> default. Remove the kernel modules from RRECOMMENDS to make it
> >> consistent
> >> across the machines.
> >>
> >> Tested using core-image-sato on qemumips, qemumips64, qemux86 and
> >> qemux86-64
> >>
> >> [YOCTO #12383]
> >>
> >> Signed-off-by: Maxin B. John 
> >> ---
> >>  meta/conf/machine/include/x86-base.inc | 2 --
> >>  meta/conf/machine/qemumips.conf| 2 --
> >>  meta/conf/machine/qemumips64.conf  | 2 --
> >>  3 files changed, 6 deletions(-)
> > 
> > Looks good, do we need to add this to genericx86 or anything in meta-
> > intel given its changing x86-base.inc?
> > 
> 
> meta-intel explicitly includes the modules so no change needed there. I
> have sent the patch for genericx86 where it should be included now.

Thanks, Just curious why we need to change genericx86. Do we have a list
of kernel modules which are required there ?

> Thanks,
> Anuj

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

Re: [OE-core] [PATCH] devtool-source.bbclass: Support kernel fragments not in SRC_URI

[Anuj Mittal]

On 07/31/2018 05:21 AM, Jaewon Lee wrote:
> When using a recipe space kernel-meta, scc files are added through
> SRC_URI, but they may include corresponding kernel fragments that are
> not necessarily in SRC_URI.
> 
> For bitbake, this is not a problem because the kernel-yocto class adds
> the path where the .scc file was found to includes which consequentially
> makes the .cfg file available to the kernel build.
> 
> However, when using devtool, only files specified in SRC_URI are copied
> to oe-local-files in devtool's workspace. So if the cfg file is not in
> SRC_URI, it won't be copied, causing a kernel build failure when trying
> to find it.
> 
> This fix parses local .scc files in SRC_URI, copies the corresponding .cfg
> file to devtool's workdir, and also adds it to local_files so it is
> available when doing a devtool build for the kernel.
> 
> [YOCTO #12858]
> 
> Signed-off-by: Jaewon Lee 
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> ---
>  meta/classes/devtool-source.bbclass | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/meta/classes/devtool-source.bbclass 
> b/meta/classes/devtool-source.bbclass
> index 56882a4..c70fea2 100644
> --- a/meta/classes/devtool-source.bbclass
> +++ b/meta/classes/devtool-source.bbclass
> @@ -90,11 +90,23 @@ python devtool_post_unpack() {
>  fname in files])
>  return ret
>  
> +is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)
>  # Move local source files into separate subdir
>  recipe_patches = [os.path.basename(patch) for patch in
>  oe.recipeutils.get_recipe_patches(d)]
>  local_files = oe.recipeutils.get_recipe_local_files(d)
>  
> +if is_kernel_yocto:
> +  for key in local_files.copy():
> +if key.endswith('scc'):
> +  sccfile = open(local_files[key], 'r')
> +  for l in sccfile:
> +line = l.split()
> +if line and line[0] == 'kconf' and line[-1].endswith('.cfg'):
> +  local_files[line[-1]] = 
> os.path.join(os.path.dirname(local_files[key]), line[-1])
> +  shutil.copy2(os.path.join(os.path.dirname(local_files[key]), 
> line[-1]), workdir)
> +  sccfile.close()
> +

Would the patches included in these .scc files also need to be handled
in the same way? Would this also work if there are other scc files
included in a scc file?

Thanks,

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

[OE-core] [PATCH] mdadm: add init and systemd service scripts

[Zheng Ruoqin]

Add init script and service file for sysvinit and systemd.

Signed-off-by: Zheng Ruoqin 
---
 .../recipes-extended/mdadm/files/mdadm.conf.sample |  1 +
 meta/recipes-extended/mdadm/files/mdadm.default| 25 
 meta/recipes-extended/mdadm/files/mdadm.init   | 71 ++
 .../recipes-extended/mdadm/files/mdmonitor.service | 15 +
 meta/recipes-extended/mdadm/mdadm_4.0.bb   | 28 -
 5 files changed, 139 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/mdadm/files/mdadm.conf.sample
 create mode 100644 meta/recipes-extended/mdadm/files/mdadm.default
 create mode 100644 meta/recipes-extended/mdadm/files/mdadm.init
 create mode 100644 meta/recipes-extended/mdadm/files/mdmonitor.service

diff --git a/meta/recipes-extended/mdadm/files/mdadm.conf.sample 
b/meta/recipes-extended/mdadm/files/mdadm.conf.sample
new file mode 100644
index 000..b869d8f
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdadm.conf.sample
@@ -0,0 +1 @@
+MAILADDR r...@mydomain.com
diff --git a/meta/recipes-extended/mdadm/files/mdadm.default 
b/meta/recipes-extended/mdadm/files/mdadm.default
new file mode 100644
index 000..2e74fdb
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdadm.default
@@ -0,0 +1,25 @@
+# mdadm configuration
+#
+# You can run 'dpkg-reconfigure mdadm' to modify the values in this file, if
+# you want. You can also change the values here and changes will be preserved.
+# Do note that only the values are preserved; the rest of the file is
+# rewritten.
+#
+
+# AUTOCHECK:
+#   should mdadm run periodic redundancy checks over your arrays? See
+#   /etc/cron.d/mdadm.
+AUTOCHECK=true
+
+# START_DAEMON:
+#   should mdadm start the MD monitoring daemon during boot?
+START_DAEMON=true
+
+# DAEMON_OPTIONS:
+#   additional options to pass to the daemon.
+DAEMON_OPTIONS="--syslog"
+
+# VERBOSE:
+#   if this variable is set to true, mdadm will be a little more verbose e.g.
+#   when creating the initramfs.
+VERBOSE=false
diff --git a/meta/recipes-extended/mdadm/files/mdadm.init 
b/meta/recipes-extended/mdadm/files/mdadm.init
new file mode 100644
index 000..8a9fbe3
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdadm.init
@@ -0,0 +1,71 @@
+#!/bin/sh
+#
+# Start the MD monitor daemon for all active MD arrays if desired.
+#
+### BEGIN INIT INFO
+# Provides:  mdadm
+# Required-Start:$local_fs $syslog mdadm-raid
+# Required-Stop: $local_fs $syslog mdadm-raid
+# Default-Start: 2 3 4 5
+# Default-Stop:  0 1 6
+# Short-Description: MD monitoring daemon
+# Description:   mdadm provides a monitor mode, in which it will scan for
+#problems with the MD devices. If a problem is found, the
+#administrator is alerted via email, or a custom script is
+#run.
+### END INIT INFO
+#
+
+MDADM=/sbin/mdadm
+RUNDIR=/var/run/mdadm
+PIDFILE=$RUNDIR/monitor.pid
+DEBIANCONFIG=/etc/default/mdadm
+
+test -x "$MDADM" || exit 0
+
+test -f /proc/mdstat || exit 0
+
+START_DAEMON=true
+test -f $DEBIANCONFIG && . $DEBIANCONFIG
+
+. /lib/lsb/init-functions
+
+# Include functions
+. /etc/init.d/functions
+
+case "${1:-}" in
+  start)
+if is_true $START_DAEMON; then
+  log_daemon_msg "Starting MD monitoring service" "mdadm --monitor"
+  mkdir -p $RUNDIR
+  start-stop-daemon -S -p $PIDFILE -x $MDADM -- \
+--monitor --pid-file $PIDFILE --daemonise --scan ${DAEMON_OPTIONS:-}
+  RETVAL=$?
+  log_end_msg $RETVAL
+  exit $RETVAL
+fi
+;;
+  stop)
+if [ -f $PIDFILE ] ; then
+  log_daemon_msg "Stopping MD monitoring service" "mdadm --monitor"
+  start-stop-daemon -K -p $PIDFILE -x $MDADM
+  RETVAL=$?
+  rm -f $PIDFILE
+  log_end_msg $RETVAL
+  exit $RETVAL
+fi
+;;
+  status)
+status -p $PIDFILE "$MDADM" && exit 0 || exit $?
+;;
+  restart|reload|force-reload)
+${0:-} stop
+${0:-} start
+;;
+  *)
+echo "Usage: ${0:-} {start|stop|status|restart|reload|force-reload}" >&2
+exit 1
+;;
+esac
+
+exit 0
diff --git a/meta/recipes-extended/mdadm/files/mdmonitor.service 
b/meta/recipes-extended/mdadm/files/mdmonitor.service
new file mode 100644
index 000..cd6c865
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdmonitor.service
@@ -0,0 +1,15 @@
+[Unit]
+Description=Software RAID monitoring and management
+After=syslog.target
+ConditionPathExists=/etc/mdadm.conf
+
+[Service]
+Type=forking
+RuntimeDirectory=/run/mdadm
+PIDFile=/run/mdadm/mdadm.pid
+EnvironmentFile=-/etc/sysconfig/mdmonitor
+ExecStart=/sbin/mdadm --monitor --scan -f --pid-file=/run/mdadm/mdadm.pid
+ExecStopPost=/bin/rm -rf /run/mdadm/mdadm.pid
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/mdadm/mdadm_4.0.bb 
b/meta/recipes-extended/mdadm/mdadm_4.0.bb
index 226b974..bd3f710 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.0.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.0.bb
@@ -24,12 +24,20 @@ SRC_UR

[OE-core] [PATCH] wic/qemux86: don't pass ip parameter to kernel in wks

[Anuj Mittal]

Images that rely on dhcp being used won't have network setup properly
otherwise.

Fixes [YOCTO #12804]

Signed-off-by: Anuj Mittal 
---
 scripts/lib/wic/canned-wks/qemux86-directdisk.wks | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/canned-wks/qemux86-directdisk.wks 
b/scripts/lib/wic/canned-wks/qemux86-directdisk.wks
index cfa32bd38a..be51c4eb56 100644
--- a/scripts/lib/wic/canned-wks/qemux86-directdisk.wks
+++ b/scripts/lib/wic/canned-wks/qemux86-directdisk.wks
@@ -4,5 +4,5 @@
 
 include common.wks.inc
 
-bootloader  --timeout=0  --append="vga=0 rw mem=256M 
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 rootfstype=ext4 "
+bootloader  --timeout=0  --append="vga=0 rw mem=256M oprofile.timer=1 
rootfstype=ext4 "
 
-- 
2.17.1

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

[OE-core] [PATCH 4/4] e2fsprogs: 1.44.2 -> 1.44.3

[Robert Yang]

Rebased ptest.patch.

Signed-off-by: Robert Yang 
---
 .../e2fsprogs/e2fsprogs/ptest.patch| 49 --
 .../{e2fsprogs_1.44.2.bb => e2fsprogs_1.44.3.bb}   |  2 +-
 2 files changed, 29 insertions(+), 22 deletions(-)
 rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.44.2.bb => 
e2fsprogs_1.44.3.bb} (98%)

diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
index 7c4bb39..64a791d 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/ptest.patch
@@ -1,10 +1,10 @@
 Upstream-Status: Inappropriate
 
-Index: git/tests/Makefile.in
-===
 git.orig/tests/Makefile.in
-+++ git/tests/Makefile.in
-@@ -18,7 +18,7 @@ test_one: $(srcdir)/test_one.in Makefile
+diff --git a/tests/Makefile.in b/tests/Makefile.in
+index 8c4d204..e021af3 100644
+--- a/tests/Makefile.in
 b/tests/Makefile.in
+@@ -19,7 +19,7 @@ test_one: $(srcdir)/test_one.in Makefile mke2fs.conf
@echo "#!/bin/sh" > test_one
@echo "HTREE=y" >> test_one
@echo "QUOTA=y" >> test_one
@@ -13,20 +13,20 @@ Index: git/tests/Makefile.in
@echo "DIFF_OPTS=@UNI_DIFF_OPTS@" >> test_one
@echo "SIZEOF_TIME_T=@SIZEOF_TIME_T@" >> test_one
@echo "DD=@DD@" >>test_one
-@@ -28,7 +28,7 @@ test_one: $(srcdir)/test_one.in Makefile
- test_script: test_one test_script.in Makefile mke2fs.conf
+@@ -30,7 +30,7 @@ test_script: test_one test_script.in Makefile mke2fs.conf
@echo "Creating test_script..."
+   @[ -f test_script ] && chmod u+w test_script || true
@echo "#!/bin/sh" > test_script
 -  @echo "SRCDIR=@srcdir@" >> test_script
 +  @echo "SRCDIR=${prefix}${libdir}/e2fsprogs/ptest/test" >> test_script
@cat $(srcdir)/test_script.in >> test_script
-   @chmod +x test_script
+   @chmod +x-w test_script
  
-Index: git/tests/test_config
-===
 git.orig/tests/test_config
-+++ git/tests/test_config
-@@ -3,24 +3,24 @@
+diff --git a/tests/test_config b/tests/test_config
+index 1f146ca..52c453f 100644
+--- a/tests/test_config
 b/tests/test_config
+@@ -3,16 +3,16 @@
  #
  
  unset LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION 
LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE 
LC_TIME PAGER
@@ -40,8 +40,6 @@ Index: git/tests/test_config
 -E2IMAGE_EXE="../misc/e2image"
 -DEBUGFS="$USE_VALGRIND ../debugfs/debugfs"
 -DEBUGFS_EXE="../debugfs/debugfs"
--TEST_BITS="../debugfs/debugfs"
--RESIZE2FS_EXE="../resize/resize2fs"
 +FSCK="$USE_VALGRIND e2fsck"
 +MKE2FS="$USE_VALGRIND mke2fs"
 +DUMPE2FS="$USE_VALGRIND dumpe2fs"
@@ -49,28 +47,37 @@ Index: git/tests/test_config
 +CHATTR="$USE_VALGRIND chattr"
 +LSATTR="$USE_VALGRIND lsattr"
 +E2IMAGE="$USE_VALGRIND e2image"
-+E2IMAGE_EXE="/sbin/e2image"
++E2IMAGE_EXE=/sbin/e2image"
 +DEBUGFS="$USE_VALGRIND debugfs"
 +DEBUGFS_EXE="/sbin/debugfs"
-+TEST_BITS="/sbin/debugfs"
+ TEST_BITS="test_data.tmp"
+ if [ ! -s $TEST_BITS ]; then
+   # create a non-sparse test file if possible, since debugfs may be
+@@ -21,14 +21,14 @@ if [ ! -s $TEST_BITS ]; then
+   dd if=/dev/urandom of=$TEST_BITS bs=128k count=1 > /dev/null 2>&1 ||
+   TEST_BITS="$DEFBUGFS_EXE"
+ fi
+-RESIZE2FS_EXE="../resize/resize2fs"
 +RESIZE2FS_EXE="/sbin/resize2fs"
  RESIZE2FS="$USE_VALGRIND $RESIZE2FS_EXE"
 -E2UNDO_EXE="../misc/e2undo"
 +E2UNDO_EXE="/sbin/e2undo"
  E2UNDO="$USE_VALGRIND $E2UNDO_EXE"
+-E2MMPSTATUS="$USE_VALGRIND ../misc/dumpe2fs -m"
 -TEST_REL=../tests/progs/test_rel
 -TEST_ICOUNT=../tests/progs/test_icount
 -CRCSUM=../tests/progs/crcsum
++E2MMPSTATUS="$USE_VALGRIND dumpe2fs -m"
 +TEST_REL=./progs/test_rel
 +TEST_ICOUNT=./progs/test_icount
 +CRCSUM=./progs/crcsum
  CLEAN_OUTPUT="sed -f $cmd_dir/filter.sed"
  
LD_LIBRARY_PATH=../lib:../lib/ext2fs:../lib/e2p:../lib/et:../lib/ss:${LD_LIBRARY_PATH}
  
DYLD_LIBRARY_PATH=../lib:../lib/ext2fs:../lib/e2p:../lib/et:../lib/ss:${DYLD_LIBRARY_PATH}
-Index: git/tests/test_script.in
-===
 git.orig/tests/test_script.in
-+++ git/tests/test_script.in
+diff --git a/tests/test_script.in b/tests/test_script.in
+index 9959e30..442999d 100644
+--- a/tests/test_script.in
 b/tests/test_script.in
 @@ -39,7 +39,7 @@ for i; do
  done
  
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.2.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.3.bb
similarity index 98%
rename from meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.2.bb
rename to meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.3.bb
index f2537a5..d7391ee 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.2.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.3.bb
@@ -12,7 +12,7 @@ SRC_URI_append_class-native = " 
file://e2fsprogs-fix-missing-check-for-permi

[OE-core] [PATCH 1/4] python-pbr: 3.1.1 -> 4.2.0

[Robert Yang]

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/python/python-pbr.inc   | 4 ++--
 .../python/{python3-pbr_3.1.1.bb => python3-pbr_4.2.0.bb} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-pbr_3.1.1.bb => 
python3-pbr_4.2.0.bb} (100%)

diff --git a/meta/recipes-devtools/python/python-pbr.inc 
b/meta/recipes-devtools/python/python-pbr.inc
index 0b70883..5a295c5 100644
--- a/meta/recipes-devtools/python/python-pbr.inc
+++ b/meta/recipes-devtools/python/python-pbr.inc
@@ -5,8 +5,8 @@ SECTION = "devel/python"
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=1dece7821bf3fd70fe1309eaa37d52a2"
 
-SRC_URI[md5sum] = "4e82c2e07af544c56a5b71c801525b00"
-SRC_URI[sha256sum] = 
"05f61c71aaefc02d8e37c0a3eeb9815ff526ea28b3b76324769e6158d7f95be1"
+SRC_URI[md5sum] = "6619780896ca81c7cd19c6e2f439b6c9"
+SRC_URI[sha256sum] = 
"1b8be50d938c9bb75d0eaf7eda111eec1bf6dc88a62a6412e33bf077457e0f45"
 
 inherit pypi
 
diff --git a/meta/recipes-devtools/python/python3-pbr_3.1.1.bb 
b/meta/recipes-devtools/python/python3-pbr_4.2.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-pbr_3.1.1.bb
rename to meta/recipes-devtools/python/python3-pbr_4.2.0.bb
-- 
2.7.4

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

[OE-core] [PATCH 3/4] python3-testtools: 2.2.0 -> 2.3.0

[Robert Yang]

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/python/python-testtools.inc | 4 ++--
 .../python/{python3-testtools_2.2.0.bb => python3-testtools_2.3.0.bb} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-testtools_2.2.0.bb => 
python3-testtools_2.3.0.bb} (100%)

diff --git a/meta/recipes-devtools/python/python-testtools.inc 
b/meta/recipes-devtools/python/python-testtools.inc
index fe1d49a..1011c98 100644
--- a/meta/recipes-devtools/python/python-testtools.inc
+++ b/meta/recipes-devtools/python/python-testtools.inc
@@ -6,8 +6,8 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=e2c9d3e8ba7141c83bfef190e0b9379a"
 
 inherit pypi
 
-SRC_URI[md5sum] = "adef817b07ba24fd6d807fd41a4f1ef4"
-SRC_URI[sha256sum] = 
"80f606607a6e4ce4d0e24e5b786562aa42c581906f3c070607a4265f3da65810"
+SRC_URI[md5sum] = "0f0feb915497816cb99e39437494217e"
+SRC_URI[sha256sum] = 
"5827ec6cf8233e0f29f51025addd713ca010061204fdea77484a2934690a0559"
 
 DEPENDS += " \
 ${PYTHON_PN}-pbr \
diff --git a/meta/recipes-devtools/python/python3-testtools_2.2.0.bb 
b/meta/recipes-devtools/python/python3-testtools_2.3.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-testtools_2.2.0.bb
rename to meta/recipes-devtools/python/python3-testtools_2.3.0.bb
-- 
2.7.4

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

[OE-core] [PATCH 2/4] python3-subunit: 1.1.0 -> 1.3.0

[Robert Yang]

The license file changes from README to README.rst, and the lines which
contains license info is from 1 to 20. The license is still Apache-2.0.

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/python/python-subunit.inc | 6 +++---
 .../python/{python3-subunit_1.1.0.bb => python3-subunit_1.3.0.bb}   | 0
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/python/{python3-subunit_1.1.0.bb => 
python3-subunit_1.3.0.bb} (100%)

diff --git a/meta/recipes-devtools/python/python-subunit.inc 
b/meta/recipes-devtools/python/python-subunit.inc
index f893e7a..afaaa51 100644
--- a/meta/recipes-devtools/python/python-subunit.inc
+++ b/meta/recipes-devtools/python/python-subunit.inc
@@ -2,12 +2,12 @@ SUMMARY = "Python implementation of subunit test streaming 
protocol"
 HOMEPAGE = "https://pypi.python.org/pypi/python-subunit/";
 SECTION = "devel/python"
 LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://README;md5=e5b524e1b2c67c88fc64439ee4a850aa"
+LIC_FILES_CHKSUM = 
"file://README.rst;beginline=1;endline=20;md5=909c08e291647fd985fbe5d9836d51b6"
 
 PYPI_PACKAGE = "python-subunit"
 
-SRC_URI[md5sum] = "d2c09c93346077ced675c9f718e6a0f1"
-SRC_URI[sha256sum] = 
"d9a7606e9610828d68c1d2f0f5abbb421e34e518b8f4882c8b2e08176281bf88"
+SRC_URI[md5sum] = "16d468a3aeafe6c60a0c3b2b9132d65b"
+SRC_URI[sha256sum] = 
"9607edbee4c1e5a30ff88549ce8d9feb0b9bcbcb5e55033a9d76e86075465cbb"
 
 inherit pypi
 
diff --git a/meta/recipes-devtools/python/python3-subunit_1.1.0.bb 
b/meta/recipes-devtools/python/python3-subunit_1.3.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-subunit_1.1.0.bb
rename to meta/recipes-devtools/python/python3-subunit_1.3.0.bb
-- 
2.7.4

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

[OE-core] [PATCH 0/4] Recipes upgrade

[Robert Yang]

The following changes since commit 51a09ba2729a840a9f2f87b68c7f50a3e6ac0d04:

  gcc-7.3: Backport fixes for std::pair high memory usage (2018-07-31 22:55:31 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/pu
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/pu

Robert Yang (4):
  python-pbr: 3.1.1 -> 4.2.0
  python3-subunit: 1.1.0 -> 1.3.0
  python3-testtools: 2.2.0 -> 2.3.0
  e2fsprogs: 1.44.2 -> 1.44.3

 .../e2fsprogs/e2fsprogs/ptest.patch| 49 --
 .../{e2fsprogs_1.44.2.bb => e2fsprogs_1.44.3.bb}   |  2 +-
 meta/recipes-devtools/python/python-pbr.inc|  4 +-
 meta/recipes-devtools/python/python-subunit.inc|  6 +--
 meta/recipes-devtools/python/python-testtools.inc  |  4 +-
 .../{python3-pbr_3.1.1.bb => python3-pbr_4.2.0.bb} |  0
 ...3-subunit_1.1.0.bb => python3-subunit_1.3.0.bb} |  0
 ...sttools_2.2.0.bb => python3-testtools_2.3.0.bb} |  0
 8 files changed, 36 insertions(+), 29 deletions(-)
 rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.44.2.bb => 
e2fsprogs_1.44.3.bb} (98%)
 rename meta/recipes-devtools/python/{python3-pbr_3.1.1.bb => 
python3-pbr_4.2.0.bb} (100%)
 rename meta/recipes-devtools/python/{python3-subunit_1.1.0.bb => 
python3-subunit_1.3.0.bb} (100%)
 rename meta/recipes-devtools/python/{python3-testtools_2.2.0.bb => 
python3-testtools_2.3.0.bb} (100%)

-- 
2.7.4

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

Re: [OE-core] [PATCH] openssl_1.0: drop unnecessary dependency on makedepend-native

[Andrej Valek]

If you are pretty sure, that makedepend command will available after
makedepend-native package dropping, I am fine with that.

Cheers,
Andrej

On 07/31/18 15:34, Andre McCurdy wrote:
> On Tue, Jul 31, 2018 at 3:24 AM, Andrej Valek  
> wrote:
>> This program is required for "oe_runmake depend" command. It runs
>> command in MAKEDEPPROG variable, which is set to makedepend. Makedepend
>> consists from makedepend-native package.
> 
> That's what you might guess from casually reading the Makefile. It's
> not what actually happens.
> 
>> Cheers,
>> Andrej
>>
>> On 07/31/18 12:08, Richard Purdie wrote:
>>> On Mon, 2018-07-30 at 18:28 -0700, Andre McCurdy wrote:
 The openssl Configure script will only select standalone makedepend
 (vs running "$CC -M") when building with gcc < 3.x or with an Apple
 Xcode version which predates the switch to clang (in approx 2010?).
 Neither of these cases are possible when building under OE, therefore
 the dependency on makedepend-native can be dropped (ie align the
 openssl 1.0 recipe with the 1.1 recipe, which has dropped the
 makedepend-native dependency already).

 Signed-off-by: Andre McCurdy 
 ---
  meta/recipes-connectivity/openssl/openssl_1.0.2o.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
 b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
 index f5d3274..78c8552 100644
 --- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
 +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb
 @@ -8,7 +8,7 @@ SECTION = "libs/network"
  LICENSE = "openssl"
  LIC_FILES_CHKSUM =
 "file://LICENSE;md5=f475368924827d06d4b416111c8bdb77"

 -DEPENDS = "makedepend-native hostperl-runtime-native"
 +DEPENDS = "hostperl-runtime-native"
  DEPENDS_append_class-target = " openssl-native"

  PROVIDES += "openssl10"
>>>
>>> This was added quite 'recently' in:
>>>
>>> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=50c23e6c26a64b0c04e99abacb61ec00d1abace9
>>>
>>> I've cc'd Andrej in case he can tell us why that was needed?
>>>
>>> Cheers,
>>>
>>> Richard
>>>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core