Re: [OE-core] [PATCH 2/2] wic/bootimg-efi: Add support for loading devicetree files

[Jan Kiszka]

On 01.08.22 16:12, Luca Ceresoli wrote:
> Hello Jan,
> 
> On Sat, 30 Jul 2022 10:24:43 +0200
> "Jan Kiszka"  wrote:
> 
>> From: Jan Kiszka 
>>
>> For device tree using systems, add support to set a custom devices tree
>> during UEFI boot. This requires to copy the DTB file to the boot
>> partition and to add the respective loader entries to the configuration
>> files.
>>
>> Both grub and systemd-boot support only loading a specific device tree.
>> Therefore refuse to work if the 'dtb' parameter contains more than one
>> entry.
>>
>> Out of scope for now are overlays (only supported by systemd-boot).
>>
>> Signed-off-by: Jan Kiszka 
>> ---
> 
> [...]
> 
>> @@ -327,11 +350,13 @@ class BootimgEFIPlugin(SourcePlugin):
>>  objcopy_cmd = "objcopy \
>>  --add-section .osrel=%s --change-section-vma 
>> .osrel=0x2 \
>>  --add-section .cmdline=%s --change-section-vma 
>> .cmdline=0x3 \
>> +%s \
>>  --add-section .linux=%s --change-section-vma 
>> .linux=0x200 \
>>  --add-section .initrd=%s --change-section-vma 
>> .initrd=0x300 \
>>  %s %s" % \
>>  ("%s/usr/lib/os-release" % staging_dir_host,
>>  cmdline.name,
>> +dtb_params,
>>  "%s/%s" % (staging_kernel_dir, kernel),
>>  initrd.name,
>>  efi_stub,
> 
> This hunk conflicts with the changes introduced by [0], which is
> already in my testing branch. I have applied your patch with a little
> change to resolve the conflict, can you please have a look at the result
> [1] to ensure I correctly followed the logic of your patch?
> 
> [0] https://lists.openembedded.org/g/openembedded-core/message/168553
> [1]
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=lucaceresoli/master-next&id=7547ec3e2065e55a8caa6118fc962130b8c6bd98
> 
> Best regards.

Looks good, thanks!

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168768): 
https://lists.openembedded.org/g/openembedded-core/message/168768
Mute This Topic: https://lists.openembedded.org/mt/92707147/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] wic/bootimg-efi: Add support for loading devicetree files

[Jan Kiszka]

From: Jan Kiszka 

For device tree using systems, add support to set a custom devices tree
during UEFI boot. This requires to copy the DTB file to the boot
partition and to add the respective loader entries to the configuration
files.

Both grub and systemd-boot support only loading a specific device tree.
Therefore refuse to work if the 'dtb' parameter contains more than one
entry.

Out of scope for now are overlays (only supported by systemd-boot).

Signed-off-by: Jan Kiszka 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 39 +++
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index aa76888c9b..eb48554e59 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -35,12 +35,12 @@ class BootimgEFIPlugin(SourcePlugin):
 name = 'bootimg-efi'
 
 @classmethod
-def _copy_additional_files(cls, hdddir, initrd):
-if initrd:
-bootimg_dir = get_bitbake_var("DEPLOY_DIR_IMAGE")
-if not bootimg_dir:
-raise WicError("Couldn't find DEPLOY_DIR_IMAGE, exiting")
+def _copy_additional_files(cls, hdddir, initrd, dtb):
+bootimg_dir = get_bitbake_var("DEPLOY_DIR_IMAGE")
+if not bootimg_dir:
+raise WicError("Couldn't find DEPLOY_DIR_IMAGE, exiting")
 
+if initrd:
 initrds = initrd.split(';')
 for rd in initrds:
 cp_cmd = "cp %s/%s %s" % (bootimg_dir, rd, hdddir)
@@ -48,6 +48,12 @@ class BootimgEFIPlugin(SourcePlugin):
 else:
 logger.debug("Ignoring missing initrd")
 
+if dtb:
+if ';' in dtb:
+raise WicError("Only one DTB supported, exiting")
+cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir)
+exec_cmd(cp_cmd, True)
+
 @classmethod
 def do_configure_grubefi(cls, hdddir, creator, cr_workdir, source_params):
 """
@@ -67,8 +73,9 @@ class BootimgEFIPlugin(SourcePlugin):
"get it from %s." % configfile)
 
 initrd = source_params.get('initrd')
+dtb = source_params.get('dtb')
 
-cls._copy_additional_files(hdddir, initrd)
+cls._copy_additional_files(hdddir, initrd, dtb)
 
 if not custom_cfg:
 # Create grub configuration using parameters from wks file
@@ -102,6 +109,9 @@ class BootimgEFIPlugin(SourcePlugin):
 grubefi_conf += " /%s" % rd
 grubefi_conf += "\n"
 
+if dtb:
+grubefi_conf += "devicetree /%s\n" % dtb
+
 grubefi_conf += "}\n"
 
 logger.debug("Writing grubefi config %s/hdd/boot/EFI/BOOT/grub.cfg",
@@ -131,9 +141,10 @@ class BootimgEFIPlugin(SourcePlugin):
 loader_conf += "timeout %d\n" % bootloader.timeout
 
 initrd = source_params.get('initrd')
+dtb = source_params.get('dtb')
 
 if not unified_image:
-cls._copy_additional_files(hdddir, initrd)
+cls._copy_additional_files(hdddir, initrd, dtb)
 
 logger.debug("Writing systemd-boot config "
  "%s/hdd/boot/loader/loader.conf", cr_workdir)
@@ -181,6 +192,9 @@ class BootimgEFIPlugin(SourcePlugin):
 for rd in initrds:
 boot_conf += "initrd /%s\n" % rd
 
+if dtb:
+boot_conf += "devicetree /%s\n" % dtb
+
 if not unified_image:
 logger.debug("Writing systemd-boot config "
  "%s/hdd/boot/loader/entries/boot.conf", cr_workdir)
@@ -316,6 +330,15 @@ class BootimgEFIPlugin(SourcePlugin):
 shutil.copyfileobj(in_file, initrd)
 initrd.close()
 
+dtb = source_params.get('dtb')
+if dtb:
+if ';' in dtb:
+raise WicError("Only one DTB supported, exiting")
+dtb_params = '--add-section .dtb=%s/%s 
--change-section-vma .dtb=0x4' % \
+(deploy_dir, dtb)
+else:
+dtb_params = ''
+
 # Searched by systemd-boot:
 # 
https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images
 install_cmd = "install -d %s/EFI/Linux" % hdddir
@@ -327,11 +350,13 @@ class BootimgEFIPlugin(SourcePlugin):
 objcopy_cmd = "objcopy \
 --add-section .osrel=%s --change-section-vma 
.

[OE-core] [PATCH 1/2] wic/bootimg-efi: Factor out some common bits

[Jan Kiszka]

From: Jan Kiszka 

The paths for configuring grub and systemd-boot have some common bits
around copying the initrd files. This will even grow when adding dtb
support. Factor this out into a class function.

Along this, avoid evaluating 'create-unified-kernel-image' multiple
times in do_configure_systemdboot and suppress a bogus warning about
"Ignoring missing initrd" when it is turned on.

Signed-off-by: Jan Kiszka 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 46 +--
 1 file changed, 21 insertions(+), 25 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 0391aebdc8..aa76888c9b 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -34,6 +34,20 @@ class BootimgEFIPlugin(SourcePlugin):
 
 name = 'bootimg-efi'
 
+@classmethod
+def _copy_additional_files(cls, hdddir, initrd):
+if initrd:
+bootimg_dir = get_bitbake_var("DEPLOY_DIR_IMAGE")
+if not bootimg_dir:
+raise WicError("Couldn't find DEPLOY_DIR_IMAGE, exiting")
+
+initrds = initrd.split(';')
+for rd in initrds:
+cp_cmd = "cp %s/%s %s" % (bootimg_dir, rd, hdddir)
+exec_cmd(cp_cmd, True)
+else:
+logger.debug("Ignoring missing initrd")
+
 @classmethod
 def do_configure_grubefi(cls, hdddir, creator, cr_workdir, source_params):
 """
@@ -54,17 +68,7 @@ class BootimgEFIPlugin(SourcePlugin):
 
 initrd = source_params.get('initrd')
 
-if initrd:
-bootimg_dir = get_bitbake_var("DEPLOY_DIR_IMAGE")
-if not bootimg_dir:
-raise WicError("Couldn't find DEPLOY_DIR_IMAGE, exiting")
-
-initrds = initrd.split(';')
-for rd in initrds:
-cp_cmd = "cp %s/%s %s" % (bootimg_dir, rd, hdddir)
-exec_cmd(cp_cmd, True)
-else:
-logger.debug("Ignoring missing initrd")
+cls._copy_additional_files(hdddir, initrd)
 
 if not custom_cfg:
 # Create grub configuration using parameters from wks file
@@ -119,25 +123,17 @@ class BootimgEFIPlugin(SourcePlugin):
 
 bootloader = creator.ks.bootloader
 
+unified_image = source_params.get('create-unified-kernel-image') == 
"true"
+
 loader_conf = ""
-if source_params.get('create-unified-kernel-image') != "true":
+if not unified_image:
 loader_conf += "default boot\n"
 loader_conf += "timeout %d\n" % bootloader.timeout
 
 initrd = source_params.get('initrd')
 
-if initrd and source_params.get('create-unified-kernel-image') != 
"true":
-# obviously we need to have a common common deploy var
-bootimg_dir = get_bitbake_var("DEPLOY_DIR_IMAGE")
-if not bootimg_dir:
-raise WicError("Couldn't find DEPLOY_DIR_IMAGE, exiting")
-
-initrds = initrd.split(';')
-for rd in initrds:
-cp_cmd = "cp %s/%s %s" % (bootimg_dir, rd, hdddir)
-exec_cmd(cp_cmd, True)
-else:
-logger.debug("Ignoring missing initrd")
+if not unified_image:
+cls._copy_additional_files(hdddir, initrd)
 
 logger.debug("Writing systemd-boot config "
  "%s/hdd/boot/loader/loader.conf", cr_workdir)
@@ -185,7 +181,7 @@ class BootimgEFIPlugin(SourcePlugin):
 for rd in initrds:
 boot_conf += "initrd /%s\n" % rd
 
-if source_params.get('create-unified-kernel-image') != "true":
+if not unified_image:
 logger.debug("Writing systemd-boot config "
  "%s/hdd/boot/loader/entries/boot.conf", cr_workdir)
 cfg = open("%s/hdd/boot/loader/entries/boot.conf" % cr_workdir, 
"w")
-- 
2.35.3

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168678): 
https://lists.openembedded.org/g/openembedded-core/message/168678
Mute This Topic: https://lists.openembedded.org/mt/92707145/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 4/6] oe-git-proxy: disable shell pathname expansion for the whole script

[Jan Kiszka]

On 03.09.19 14:22, Henning Schild wrote:

From: Henning Schild 

This truly fixes the issue that cbc148d5d93d5f3531434fee7b234a16196b3088
wanted to solve, without breaking the iteration over multiple entries.

Signed-off-by: Henning Schild 
---
  scripts/oe-git-proxy | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/scripts/oe-git-proxy b/scripts/oe-git-proxy
index 10e6560da4..2f65f0c482 100755
--- a/scripts/oe-git-proxy
+++ b/scripts/oe-git-proxy
@@ -133,6 +133,9 @@ if [ -z "$ALL_PROXY" ]; then
exec $SOCAT STDIO $METHOD
  fi
  
+# disable pathname expansion, NO_PROXY fielnd could start with "*" or be it


field


+set -f


Ah, that's much better than any (mis-)quoting.

Jan


+
  # Connect directly to hosts in NO_PROXY
  for H in ${NO_PROXY//,/ }; do
if match_host $1 $H; then



--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] npm offline build for yocto

[Jan Kiszka]

On 07.03.19 15:22, Davis, Michael wrote:

Unfortunately no.  I could never get the cache to prefill correctly with node 8 
and haven't tried any of the newer versions.  The way they did the sha1/256/512 
sums made it impossible to prefill the cache, and the import of tars just 
didn’t work.


I suspect the cache does not match packages coming in via different channels 
(add tarball vs. fetch url).




I ended up using yarn and building the app outside of bitbake, though with yarn 
the offline problem would become much easier.   It has much better support for 
offline builds than node / npm does.  If I had to start again I would start 
with adding support for yarn and go from there.  Node appears to be a dead end 
unless / until they fix the offline build.


Simple guide I followed to get offline yarn working.  It shouldn't be hard to 
translate into a system much like the npm part of bitbake.
https://yarnpkg.com/blog/2016/11/24/offline-mirror/



Sounds reasonable. Let me play with that, maybe try an ad-hoc integration into 
our layer first.


Thanks,
Jan


Mike
-Original Message-----
From: Jan Kiszka 
Sent: Thursday, March 07, 2019 3:37 AM
To: Davis, Michael 
Cc: OE-core 
Subject: npm offline build for yocto

Hi Michael,

I found your progress report (and unanswered question) on that topic in 
http://lists.openembedded.org/pipermail/openembedded-core/2018-April/268639.html.
Did this effort go further?

I just ran into it again while updating https://github.com/siemens/meta-iot2000
to Node.js >v6. I also played with prefilling the cache, but likely in the 
wrong way.

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center 
Embedded Linux



--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] npm offline build for yocto

[Jan Kiszka]

Hi Michael,

I found your progress report (and unanswered question) on that topic in 
http://lists.openembedded.org/pipermail/openembedded-core/2018-April/268639.html. 
Did this effort go further?


I just ran into it again while updating https://github.com/siemens/meta-iot2000 
to Node.js >v6. I also played with prefilling the cache, but likely in the wrong 
way.


Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] wic: Ensure that sourceparams values can contain '='

[Jan Kiszka]

From: Jan Kiszka 

This allows '--sourceparams key1=val1=val11,key2=val2'.

Signed-off-by: Jan Kiszka 
---
 scripts/lib/wic/partition.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3da7e23e61..ca206ece02 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -173,7 +173,7 @@ class Partition():
 # Split sourceparams string of the form key1=val1[,key2=val2,...]
 # into a dict.  Also accepts valueless keys i.e. without =
 splitted = self.sourceparams.split(',')
-srcparams_dict = dict(par.split('=') for par in splitted if par)
+srcparams_dict = dict(par.split('=', 1) for par in splitted if par)
 
 plugin = PluginMgr.get_plugins('source')[self.source]
 plugin.do_configure_partition(self, srcparams_dict, creator,
-- 
2.16.4
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] oe-git-proxy: Avoid resolving NO_PROXY against local files

[Jan Kiszka]

From: Jan Kiszka 

NO_PROXY may contain * elements, and if we are unlucky (or want to match
all hosts with *), we will pick up local files rather than doing the
match in match_host. Quoting helps here.

Signed-off-by: Jan Kiszka 
---
 scripts/oe-git-proxy | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/oe-git-proxy b/scripts/oe-git-proxy
index 7a43fe6a6e..1800942f36 100755
--- a/scripts/oe-git-proxy
+++ b/scripts/oe-git-proxy
@@ -131,8 +131,8 @@ if [ -z "$ALL_PROXY" ]; then
 fi
 
 # Connect directly to hosts in NO_PROXY
-for H in ${NO_PROXY//,/ }; do
-   if match_host $1 $H; then
+for H in "${NO_PROXY//,/ }"; do
+   if match_host $1 "$H"; then
exec $SOCAT STDIO $METHOD
fi
 done
-- 
2.16.4
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] rng-tools fixes and enhancements

[Jan Kiszka]

See patches for details.

Jan Kiszka (3):
  rng-tools: Start as early as possible
  rng-tools: Don't use /dev/urandom as rngd default source
  rng-tools: Add support for Atheros 9170 hwrng

 meta/recipes-support/rng-tools/rng-tools/default | 11 +--
 meta/recipes-support/rng-tools/rng-tools/init|  3 +++
 meta/recipes-support/rng-tools/rng-tools_5.bb|  2 +-
 3 files changed, 13 insertions(+), 3 deletions(-)

-- 
2.12.3

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

[OE-core] [PATCH 2/3] rng-tools: Don't use /dev/urandom as rngd default source

[Jan Kiszka]

From: Jan Kiszka 

Big no-no when you want to have more than a toy device, so let's not
make this a default. See also https://lwn.net/Articles/525459.

Signed-off-by: Jan Kiszka 
---
 meta/recipes-support/rng-tools/rng-tools/default | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools/default 
b/meta/recipes-support/rng-tools/rng-tools/default
index 7aede9be03..b968f2b789 100644
--- a/meta/recipes-support/rng-tools/rng-tools/default
+++ b/meta/recipes-support/rng-tools/rng-tools/default
@@ -1,3 +1,6 @@
 # Specify rng device
-#RNG_DEVICE=/dev/hwrng
-RNG_DEVICE=/dev/urandom
+RNG_DEVICE=/dev/hwrng
+
+# Don't use urandom as source unless you fully understood what that does to
+# your system security!
+#RNG_DEVICE=/dev/urandom
-- 
2.12.3

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

[OE-core] [PATCH 1/3] rng-tools: Start as early as possible

[Jan Kiszka]

From: Jan Kiszka 

This helps systems with little architectural entropy to initialize the
random pool earlier. We just need to wait for udev so that drivers have
been probed already.

Signed-off-by: Jan Kiszka 
---
 meta/recipes-support/rng-tools/rng-tools_5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools_5.bb 
b/meta/recipes-support/rng-tools/rng-tools_5.bb
index de6e5f9a76..ba5076204c 100644
--- a/meta/recipes-support/rng-tools/rng-tools_5.bb
+++ b/meta/recipes-support/rng-tools/rng-tools_5.bb
@@ -41,4 +41,4 @@ do_install_append() {
 }
 
 INITSCRIPT_NAME = "rng-tools"
-INITSCRIPT_PARAMS = "start 30 2 3 4 5 . stop 30 0 6 1 ."
+INITSCRIPT_PARAMS = "start 05 S 0 6 . stop 30 0 6 1 ."
-- 
2.12.3

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

[OE-core] [PATCH 3/3] rng-tools: Add support for Atheros 9170 hwrng

[Jan Kiszka]

From: Jan Kiszka 

Useful only on devices with no other sources: USB WLAN sticks based on
the Atheros 9170 (carl9170 kernel driver) provide a hardware random
generator. However, the interface needs to be up in order to is the
generator. That's not the case until ifup ran, but wpa_supplicant will
block this until the random pool is initialized.

Signed-off-by: Jan Kiszka 
---
 meta/recipes-support/rng-tools/rng-tools/default | 4 
 meta/recipes-support/rng-tools/rng-tools/init| 3 +++
 2 files changed, 7 insertions(+)

diff --git a/meta/recipes-support/rng-tools/rng-tools/default 
b/meta/recipes-support/rng-tools/rng-tools/default
index b968f2b789..85c5833a32 100644
--- a/meta/recipes-support/rng-tools/rng-tools/default
+++ b/meta/recipes-support/rng-tools/rng-tools/default
@@ -4,3 +4,7 @@ RNG_DEVICE=/dev/hwrng
 # Don't use urandom as source unless you fully understood what that does to
 # your system security!
 #RNG_DEVICE=/dev/urandom
+
+# Specify wlan interface to enable if rngd should use Atheros 9170 as source.
+# See kernel config help for the security limitations of this.
+#CARL9170_HWRNG_INTERFACE="wlan0"
diff --git a/meta/recipes-support/rng-tools/rng-tools/init 
b/meta/recipes-support/rng-tools/rng-tools/init
index 7cf78393a4..30cfc0f3d5 100644
--- a/meta/recipes-support/rng-tools/rng-tools/init
+++ b/meta/recipes-support/rng-tools/rng-tools/init
@@ -20,6 +20,9 @@ fi
 case "$1" in
   start)
 echo -n "Starting random number generator daemon"
+if [ -n "$CARL9170_HWRNG_INTERFACE" ]; then
+ip link set $CARL9170_HWRNG_INTERFACE up
+fi
 start-stop-daemon -S -q -x $rngd $EXTRA_ARGS
 echo "."
 ;;
-- 
2.12.3

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

[OE-core] [PATCH] tzdata: Install zone1970.tab

[Jan Kiszka]

The modern version of zone.tab is required by tzselect e.g.

Signed-off-by: Jan Kiszka 
---
 meta/recipes-extended/tzdata/tzdata_2017b.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/tzdata/tzdata_2017b.bb 
b/meta/recipes-extended/tzdata/tzdata_2017b.bb
index 2e4277f794..55e89767fc 100644
--- a/meta/recipes-extended/tzdata/tzdata_2017b.bb
+++ b/meta/recipes-extended/tzdata/tzdata_2017b.bb
@@ -45,6 +45,7 @@ do_install () {
 cp -pPR ${S}/$exec_prefix ${D}/
 # libc is removing zoneinfo files from package
 cp -pP "${S}/zone.tab" ${D}${datadir}/zoneinfo
+cp -pP "${S}/zone1970.tab" ${D}${datadir}/zoneinfo
 cp -pP "${S}/iso3166.tab" ${D}${datadir}/zoneinfo
 
 # Install default timezone
@@ -206,6 +207,7 @@ FILES_${PN} += "${datadir}/zoneinfo/Pacific/Honolulu \
 ${datadir}/zoneinfo/WET  \
 ${datadir}/zoneinfo/Zulu \
 ${datadir}/zoneinfo/zone.tab \
+${datadir}/zoneinfo/zone1970.tab \
 ${datadir}/zoneinfo/iso3166.tab  \
 ${datadir}/zoneinfo/Etc/*"
 
-- 
2.12.3
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fun with npm shrinkwrap

[Jan Kiszka]

On 2017-06-07 16:09, Davis, Michael wrote:
> If offline builds, license checking, or stable dependency versions are not 
> important to you then you can use the meta-nodejs layer.  It just uses the 
> yarn tool directly https://github.com/imyller/meta-nodejs.
> 

In fact, meta-nodejs is already in use here, and I've been told to give
"inherit npm-base" a try. Is that what you mean?

How "unreproducible" will builds become? The license checks are not that
critical as I wouldn't trust them right now anyway. Offline builds
correlate with reproduciblilty - we need to archive the artifacts and
generate images with changes later on, independent of what happened
outside meanwhile. Not a killer right now, but not an option on the long
run.

> 
> On a hijacked side note has yarn been considered as a solution to some of our 
> npm issues?
> It seems to be npm with built in licnese checking and better version 
> determination.
> Might not cover 100% of our use cases, but then npm only seems to work 50% of 
> the time without tweaking something anyways.
> 

Can't comment on yarn, but another colleague pointed out that the
machinery of arch-linux may also be worth a look, not only for the
nodejs/npm galaxy.

Thanks,
Jan

PS: Top-posting is considered evil.

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Jan Kiszka]

On 2017-06-07 18:33, Martin Kelly wrote:
> On 06/07/2017 09:08 AM, Burton, Ross wrote:
>>
>> On 6 June 2017 at 18:28, Martin Kelly > > wrote:
>>
>> I sent a separate patch for fixing the systemd issue, so I think we
>> can merge the two patches separately (they're both needed):
>>
>> https://patchwork.openembedded.org/patch/140355/
>> 
>>
>> Neither of our patches have been merged yet.
>>
>>
>> Sorry, somehow slipped through the net.
>>
>> This patch doesn't apply as it's been corrupted by the mailer.  Please
>> use git-send-email instead of copy/pasting (I've managed to apply it
>> manually as it's a simple patch this time).
>>
>> Ross
>>
> 
> Which patch are you referring to? I used git send-email for the systemd
> patch, and it applies just fine for me on OE-core master (using patch -p1).

Wasn't you, was mine. :)

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Jan Kiszka]

On 2017-06-07 18:08, Burton, Ross wrote:
> 
> On 6 June 2017 at 18:28, Martin Kelly  > wrote:
> 
> I sent a separate patch for fixing the systemd issue, so I think we
> can merge the two patches separately (they're both needed):
> 
> https://patchwork.openembedded.org/patch/140355/
> 
> 
> Neither of our patches have been merged yet.
> 
> 
> Sorry, somehow slipped through the net.
> 
> This patch doesn't apply as it's been corrupted by the mailer.  Please
> use git-send-email instead of copy/pasting (I've managed to apply it
> manually as it's a simple patch this time).

GnuPG signatures cause troubles... I added to my blacklist.

Sorry,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fun with npm shrinkwrap

[Jan Kiszka]

On 2017-06-07 13:43, Alexander Kanavin wrote:
> On 06/06/2017 06:14 PM, Jan Kiszka wrote:
> 
>> Yeah, good points. Probably this problem is also related to OE
>> reimplementing parts of the npm logic.
>>
>> But I suppose those concepts won't materialize very soon, will they? I'm
>> also looking for a short-term solution, at least some reasonable tactic
>> to generate such recipes in the meantime. Is there something in that
>> thread I should dig into?
> 
> What I am getting at is that it would be awesome if you convince your
> management that npm support in Yocto is a problem that needs a better
> solution and work on it. Yes, this means you can't work on product
> development for quite some time; this is the price for using open source
> projects without a commercial support contract :)

We are such a instance support :) - but we also need to get paid / pay
our contractors.

> 
> My apologies if this is not the answer you were seeking.
> 

I'm getting your point, even more now as I ran into a package that does
not even install at all (node-red-contrib-opcua). Can't promise anything
at this point, but I will carry this forward, in all directions.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fun with npm shrinkwrap

[Jan Kiszka]

On 2017-06-06 16:12, Alexander Kanavin wrote:
> On 06/06/2017 01:17 PM, Jan Kiszka wrote:
>> devtool add / recipetool create do not work properly /wrt shrinkwrap
>> when it comes to node-red-node-serialport. npm shrinkwrap finds a number
>> of extraneous packages and refuses to generate an output.
>>
>> There are various workarounds discussed in [1]. For me this seems to
>> work:
> 
> You forgot to include the actual [1] :)

Ah, sorry: https://github.com/npm/npm/issues/4435

> 
>> But it may have unwanted side effects. So, what would be the proper way
>> to address this issue?
> 
> A few months ago we had a long, big discussion about how to support
> these kinds of language environments in a way that is sustainable (I
> personally do not think the current approach with npm is viable in the
> long term). Here's the initial couple of emails:
> 
> http://lists.openembedded.org/pipermail/openembedded-architecture/2017-March/000480.html
> 
> 
> http://lists.openembedded.org/pipermail/openembedded-architecture/2017-March/000481.html
> 

Yeah, good points. Probably this problem is also related to OE
reimplementing parts of the npm logic.

But I suppose those concepts won't materialize very soon, will they? I'm
also looking for a short-term solution, at least some reasonable tactic
to generate such recipes in the meantime. Is there something in that
thread I should dig into?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Fun with npm shrinkwrap

[Jan Kiszka]

Hi all,

devtool add / recipetool create do not work properly /wrt shrinkwrap
when it comes to node-red-node-serialport. npm shrinkwrap finds a number
of extraneous packages and refuses to generate an output.

There are various workarounds discussed in [1]. For me this seems to
work:

diff --git a/scripts/lib/recipetool/create_npm.py 
b/scripts/lib/recipetool/create_npm.py
index cb8f338b8b..8ce952bb4c 100644
--- a/scripts/lib/recipetool/create_npm.py
+++ b/scripts/lib/recipetool/create_npm.py
@@ -68,6 +68,8 @@ class NpmRecipeHandler(RecipeHandler):
 def _shrinkwrap(self, srctree, localfilesdir, extravalues, lines_before, 
d):
 try:
 runenv = dict(os.environ, PATH=d.getVar('PATH'))
+bb.process.run('rm -rf node_modules', cwd=srctree, 
stderr=subprocess.STDOUT, env=runenv, shell=True)
+bb.process.run('npm install', cwd=srctree, 
stderr=subprocess.STDOUT, env=runenv, shell=True)
 bb.process.run('npm shrinkwrap', cwd=srctree, 
stderr=subprocess.STDOUT, env=runenv, shell=True)
 except bb.process.ExecutionError as e:
 logger.warn('npm shrinkwrap failed:\n%s' % e.stdout)


But it may have unwanted side effects. So, what would be the proper way
to address this issue?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Jan Kiszka]

On 2017-06-01 02:17, Martin Kelly wrote:
> On 05/02/2017 01:41 AM, Martin Kelly wrote:
>> On 04/30/2017 08:28 AM, Jan Kiszka wrote:
>>> From: Jan Kiszka 
>>>
>>> The upstream init script uses SIGUSR2 to terminate that daemon because
>>> SIGTERM is ignored. As the killproc function does not support specifying
>>> a signal, switch to start-stop-daemon. Drop the retry loop because
>>> SIGUSR2 is lethal for agent.
>>>
>>> Signed-off-by: Jan Kiszka 
>>
>> Thanks! I noticed this bug and was planning to look into it, but it
>> looks like you found the issue first! This was bringing shutdowns to a
>> crawl for me.
> 
> I just noticed, I think we need to fix the same bug in the systemd
> service script too.

Does this block this patch, or should this be done in a separate one? I
noticed that it's still not merged.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tcf-agent: Fix daemon termination

[Jan Kiszka]

From: Jan Kiszka 

The upstream init script uses SIGUSR2 to terminate that daemon because
SIGTERM is ignored. As the killproc function does not support specifying
a signal, switch to start-stop-daemon. Drop the retry loop because
SIGUSR2 is lethal for agent.

Signed-off-by: Jan Kiszka 
---
 meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init 
b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init
index 6303280aae..bd602c67cb 100755
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init
@@ -33,16 +33,7 @@ case "$1" in
 
 stop)
 echo -n "Stopping $DAEMON_NAME: "
-count=0
-while [ -n "`/bin/pidof $DAEMON_PATH`" -a $count -lt 10 ] ; do
-killproc $DAEMON_PATH >& /dev/null
-sleep 1
-RETVAL=$?
-if [ $RETVAL != 0 -o -n "`/bin/pidof $DAEMON_PATH`" ] ; then
-sleep 3
-fi
-count=`expr $count + 1`
-done
+start-stop-daemon -K -q -x $DAEMON_PATH -s USR2
 rm -f /var/lock/subsys/$DAEMON_NAME
 if [ -n "`/bin/pidof $DAEMON_PATH`" ] ; then
 echo "FAIL"



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core