Re: [OE-core] tinymembench: fix patch fuzz

[Mircea Carausu via lists.openembedded.org]

Hi Alex,
many thanks for your reply. Will follow it.
-Mircea

On Tue, Jul 14, 2020 at 2:22 PM Alexander Kanavin 
wrote:

> You can start here:
> https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
>
> Alex
>
> On Tue, 14 Jul 2020 at 20:50, Mircea Carausu via lists.openembedded.org
>  wrote:
>
>> Hello,
>> I am new to the list and up-streaming activities.
>> Could you please kindly guide me how to submit a fix for the existing
>> tinymembench.patch
>>
>> (meta-openembedded/meta-oe/recipes-benchmark/tinymembench/tinymembench/0001-asm-Delete-.func-.endfunc-directives.patch)
>> Problem:
>>
>> tinymembench patch does not apply cleanly (it succeeds with warnings -
>> fuzz detected). Used devtool to fix:
>>
>> devtool modify tinymembench devtool finish --force-patch-refresh
>> tinymembench ../meta-openembedded/meta-oe
>>
>> I already generated the new patch.
>>
>> What are the next steps (other than local verification).
>>
>> Should I just upload it here for review once I consider it ready for
>> review?
>>
>> Sorry for asking such basic questions
>>
>> Many thanks,
>>
>> Mircea
>>
>>
>> 
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140637): 
https://lists.openembedded.org/g/openembedded-core/message/140637
Mute This Topic: https://lists.openembedded.org/mt/75505558/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] tinymembench: fix patch fuzz

[Alexander Kanavin]

You can start here:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

Alex

On Tue, 14 Jul 2020 at 20:50, Mircea Carausu via lists.openembedded.org
 wrote:

> Hello,
> I am new to the list and up-streaming activities.
> Could you please kindly guide me how to submit a fix for the existing
> tinymembench.patch
>
> (meta-openembedded/meta-oe/recipes-benchmark/tinymembench/tinymembench/0001-asm-Delete-.func-.endfunc-directives.patch)
> Problem:
>
> tinymembench patch does not apply cleanly (it succeeds with warnings -
> fuzz detected). Used devtool to fix:
>
> devtool modify tinymembench devtool finish --force-patch-refresh
> tinymembench ../meta-openembedded/meta-oe
>
> I already generated the new patch.
>
> What are the next steps (other than local verification).
>
> Should I just upload it here for review once I consider it ready for
> review?
>
> Sorry for asking such basic questions
>
> Many thanks,
>
> Mircea
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140636): 
https://lists.openembedded.org/g/openembedded-core/message/140636
Mute This Topic: https://lists.openembedded.org/mt/75505558/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/4] qemu: fix CVE-2020-13659

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2020-13659.patch| 58 +++
 2 files changed, 59 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13659.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 98bdff7ac6..a9ef3b78bf 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -33,6 +33,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://find_datadir.patch \
   file://CVE-2020-10761.patch \
   file://CVE-2020-13362.patch \
+  file://CVE-2020-13659.patch \
   "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13659.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13659.patch
new file mode 100644
index 00..4d12ae8f16
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13659.patch
@@ -0,0 +1,58 @@
+From 77f55eac6c433e23e82a1b88b2d74f385c4c7d82 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Tue, 26 May 2020 16:47:43 +0530
+Subject: [PATCH] exec: set map length to zero when returning NULL
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When mapping physical memory into host's virtual address space,
+'address_space_map' may return NULL if BounceBuffer is in_use.
+Set and return '*plen = 0' to avoid later NULL pointer dereference.
+
+Reported-by: Alexander Bulekov 
+Fixes: https://bugs.launchpad.net/qemu/+bug/1878259
+Suggested-by: Paolo Bonzini 
+Suggested-by: Peter Maydell 
+Signed-off-by: Prasad J Pandit 
+Message-Id: <20200526111743.428367-1-ppan...@redhat.com>
+Reviewed-by: Philippe Mathieu-Daudé 
+Signed-off-by: Paolo Bonzini 
+
+Upstream-Status: Backport [77f55eac6c433e23e82a1b88b2d74f385c4c7d82]
+CVE: CVE-2020-13659
+Signed-off-by: Sakib Sajal 
+---
+ exec.c| 1 +
+ include/exec/memory.h | 3 ++-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/exec.c b/exec.c
+index 9cbde85d8c..778263f1c6 100644
+--- a/exec.c
 b/exec.c
+@@ -3540,6 +3540,7 @@ void *address_space_map(AddressSpace *as,
+ 
+ if (!memory_access_is_direct(mr, is_write)) {
+ if (atomic_xchg(_use, true)) {
++*plen = 0;
+ return NULL;
+ }
+ /* Avoid unbounded allocations */
+diff --git a/include/exec/memory.h b/include/exec/memory.h
+index bd7fdd6081..af8ca7824e 100644
+--- a/include/exec/memory.h
 b/include/exec/memory.h
+@@ -2314,7 +2314,8 @@ bool address_space_access_valid(AddressSpace *as, hwaddr 
addr, hwaddr len,
+ /* address_space_map: map a physical memory region into a host virtual address
+  *
+  * May map a subset of the requested range, given by and returned in @plen.
+- * May return %NULL if resources needed to perform the mapping are exhausted.
++ * May return %NULL and set *@plen to zero(0), if resources needed to perform
++ * the mapping are exhausted.
+  * Use only for reads OR writes - not for read-modify-write operations.
+  * Use cpu_register_map_client() to know when retrying the map operation is
+  * likely to succeed.
+-- 
+2.20.1
+
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140634): 
https://lists.openembedded.org/g/openembedded-core/message/140634
Mute This Topic: https://lists.openembedded.org/mt/75506943/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 3/4] qemu: fix CVE-2020-13800

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2020-13800.patch| 63 +++
 2 files changed, 64 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13800.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index a9ef3b78bf..618cc50180 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -34,6 +34,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://CVE-2020-10761.patch \
   file://CVE-2020-13362.patch \
   file://CVE-2020-13659.patch \
+  file://CVE-2020-13800.patch \
   "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13800.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13800.patch
new file mode 100644
index 00..52bfafbbae
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13800.patch
@@ -0,0 +1,63 @@
+From a98610c429d52db0937c1e48659428929835c455 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Thu, 4 Jun 2020 14:38:30 +0530
+Subject: [PATCH] ati-vga: check mm_index before recursive call
+ (CVE-2020-13800)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+While accessing VGA registers via ati_mm_read/write routines,
+a guest may set 's->regs.mm_index' such that it leads to infinite
+recursion. Check mm_index value to avoid such recursion. Log an
+error message for wrong values.
+
+Reported-by: Ren Ding 
+Reported-by: Hanqing Zhao 
+Reported-by: Yi Ren 
+Message-id: 20200604090830.33885-1-ppan...@redhat.com
+Suggested-by: BALATON Zoltan 
+Suggested-by: Philippe Mathieu-Daudé 
+Signed-off-by: Prasad J Pandit 
+Signed-off-by: Gerd Hoffmann 
+
+Upstream-Status: Backport [a98610c429d52db0937c1e48659428929835c455]
+CVE: CVE-2020-13800
+Signed-off-by: Sakib Sajal 
+---
+ hw/display/ati.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/hw/display/ati.c b/hw/display/ati.c
+index 065f197678..67604e68de 100644
+--- a/hw/display/ati.c
 b/hw/display/ati.c
+@@ -285,8 +285,11 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr, 
unsigned int size)
+ if (idx <= s->vga.vram_size - size) {
+ val = ldn_le_p(s->vga.vram_ptr + idx, size);
+ }
+-} else {
++} else if (s->regs.mm_index > MM_DATA + 3) {
+ val = ati_mm_read(s, s->regs.mm_index + addr - MM_DATA, size);
++} else {
++qemu_log_mask(LOG_GUEST_ERROR,
++"ati_mm_read: mm_index too small: %u\n", s->regs.mm_index);
+ }
+ break;
+ case BIOS_0_SCRATCH ... BUS_CNTL - 1:
+@@ -520,8 +523,11 @@ static void ati_mm_write(void *opaque, hwaddr addr,
+ if (idx <= s->vga.vram_size - size) {
+ stn_le_p(s->vga.vram_ptr + idx, size, data);
+ }
+-} else {
++} else if (s->regs.mm_index > MM_DATA + 3) {
+ ati_mm_write(s, s->regs.mm_index + addr - MM_DATA, data, size);
++} else {
++qemu_log_mask(LOG_GUEST_ERROR,
++"ati_mm_write: mm_index too small: %u\n", s->regs.mm_index);
+ }
+ break;
+ case BIOS_0_SCRATCH ... BUS_CNTL - 1:
+-- 
+2.20.1
+
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140635): 
https://lists.openembedded.org/g/openembedded-core/message/140635
Mute This Topic: https://lists.openembedded.org/mt/75506944/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 1/4] qemu: fix CVE-2020-13362

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2020-13362.patch| 55 +++
 2 files changed, 56 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13362.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index d41cc8f200..98bdff7ac6 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -32,6 +32,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://CVE-2020-13361.patch \
   file://find_datadir.patch \
   file://CVE-2020-10761.patch \
+  file://CVE-2020-13362.patch \
   "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13362.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13362.patch
new file mode 100644
index 00..af8d4ba8f4
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13362.patch
@@ -0,0 +1,55 @@
+From f50ab86a2620bd7e8507af865b164655ee921661 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Thu, 14 May 2020 00:55:38 +0530
+Subject: [PATCH] megasas: use unsigned type for reply_queue_head and check
+ index
+
+A guest user may set 'reply_queue_head' field of MegasasState to
+a negative value. Later in 'megasas_lookup_frame' it is used to
+index into s->frames[] array. Use unsigned type to avoid OOB
+access issue.
+
+Also check that 'index' value stays within s->frames[] bounds
+through the while() loop in 'megasas_lookup_frame' to avoid OOB
+access.
+
+Reported-by: Ren Ding 
+Reported-by: Hanqing Zhao 
+Reported-by: Alexander Bulekov 
+Signed-off-by: Prasad J Pandit 
+Acked-by: Alexander Bulekov 
+Message-Id: <20200513192540.1583887-2-ppan...@redhat.com>
+Signed-off-by: Paolo Bonzini 
+
+Upstream-Status: Backport [f50ab86a2620bd7e8507af865b164655ee921661]
+CVE: CVE-2020-13362
+Signed-off-by: Sakib Sajal 
+---
+ hw/scsi/megasas.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
+index af18c88b65..6ce598cd69 100644
+--- a/hw/scsi/megasas.c
 b/hw/scsi/megasas.c
+@@ -112,7 +112,7 @@ typedef struct MegasasState {
+ uint64_t reply_queue_pa;
+ void *reply_queue;
+ int reply_queue_len;
+-int reply_queue_head;
++uint16_t reply_queue_head;
+ int reply_queue_tail;
+ uint64_t consumer_pa;
+ uint64_t producer_pa;
+@@ -445,7 +445,7 @@ static MegasasCmd *megasas_lookup_frame(MegasasState *s,
+ 
+ index = s->reply_queue_head;
+ 
+-while (num < s->fw_cmds) {
++while (num < s->fw_cmds && index < MEGASAS_MAX_FRAMES) {
+ if (s->frames[index].pa && s->frames[index].pa == frame) {
+ cmd = >frames[index];
+ break;
+-- 
+2.20.1
+
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140633): 
https://lists.openembedded.org/g/openembedded-core/message/140633
Mute This Topic: https://lists.openembedded.org/mt/75506942/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 4/4] qemu: fix CVE-2020-13791

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2020-13791.patch| 53 +++
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 618cc50180..57619e8668 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -35,6 +35,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://CVE-2020-13362.patch \
   file://CVE-2020-13659.patch \
   file://CVE-2020-13800.patch \
+  file://CVE-2020-13791.patch \
   "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
new file mode 100644
index 00..049dab914d
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
@@ -0,0 +1,53 @@
+From f7d6a635fa3b7797f9d072e280f065bf3cfcd24d Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Thu, 4 Jun 2020 17:05:25 +0530
+Subject: [PATCH] pci: assert configuration access is within bounds
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+While accessing PCI configuration bytes, assert that
+'address + len' is within PCI configuration space.
+
+Generally it is within bounds. This is more of a defensive
+assert, in case a buggy device was to send 'address' which
+may go out of bounds.
+
+Suggested-by: Philippe Mathieu-Daudé 
+Signed-off-by: Prasad J Pandit 
+Message-Id: <20200604113525.58898-1-ppan...@redhat.com>
+Reviewed-by: Michael S. Tsirkin 
+Signed-off-by: Michael S. Tsirkin 
+
+Upstream-Status: Backport [f7d6a635fa3b7797f9d072e280f065bf3cfcd24d]
+CVE: CVE-2020-13791
+Signed-off-by: Sakib Sajal 
+---
+ hw/pci/pci.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/hw/pci/pci.c b/hw/pci/pci.c
+index 70c66965f5..7bf2ae6d92 100644
+--- a/hw/pci/pci.c
 b/hw/pci/pci.c
+@@ -1381,6 +1381,8 @@ uint32_t pci_default_read_config(PCIDevice *d,
+ {
+ uint32_t val = 0;
+ 
++assert(address + len <= pci_config_size(d));
++
+ if (pci_is_express_downstream_port(d) &&
+ ranges_overlap(address, len, d->exp.exp_cap + PCI_EXP_LNKSTA, 2)) {
+ pcie_sync_bridge_lnk(d);
+@@ -1394,6 +1396,8 @@ void pci_default_write_config(PCIDevice *d, uint32_t 
addr, uint32_t val_in, int
+ int i, was_irq_disabled = pci_irq_disabled(d);
+ uint32_t val = val_in;
+ 
++assert(addr + l <= pci_config_size(d));
++
+ for (i = 0; i < l; val >>= 8, ++i) {
+ uint8_t wmask = d->wmask[addr + i];
+ uint8_t w1cmask = d->w1cmask[addr + i];
+-- 
+2.20.1
+
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140632): 
https://lists.openembedded.org/g/openembedded-core/message/140632
Mute This Topic: https://lists.openembedded.org/mt/75506941/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ERROR: ruby-2.7.1-r0 do_compile: oe_runmake failed

[Pankaj Vinadrao Joshi]

Hi.
i am trying to build sato-image on RPI but i am getting following error w.r.t 
ruby.i have added ruby & ruby-dev package via image_install,what wrong could be 
happened with this can someone help??

:~/ORASP$ bitbake core-image-sato
Parsing recipes: 100% 
|##|
 Time: 0:02:31
Parsing of 2279 .bb files complete (0 cached, 2279 parsed). 3439 targets, 132 
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "aarch64-oe-linux"
MACHINE              = "raspberrypi4-64"
DISTRO               = "exaleap-arm-linux"
DISTRO_VERSION       = "exaleap-arm-linux-r1.0.0"
TUNE_FEATURES        = "aarch64 cortexa72 crc crypto"
TARGET_FPU           = ""
meta                 = "master:982b7f98b8423236cc986346379b1bde3694f131"
meta-oe
meta-python
meta-networking
meta-multimedia
meta-perl            = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"
meta-pankaj          = ":"

Initialising tasks: 100% 
|###|
 Time: 0:00:05
Sstate summary: Wanted 1633 Found 0 Missed 1633 Current 973 (0% match, 37% 
complete)
NOTE: Executing Tasks
ERROR: ruby-2.7.1-r0 do_compile: oe_runmake failed
ERROR: ruby-2.7.1-r0 do_compile: Execution of 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/temp/run.do_compile.4394'
 failed with exit code 1:
BASERUBY = 
/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/recipe-sysroot-native/usr/bin/ruby
 --disable=gems
CC = aarch64-oe-linux-gcc  -mcpu=cortex-a72+crc+crypto 
--sysroot=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/recipe-sysroot
LD = aarch64-oe-linux-ld 
--sysroot=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/recipe-sysroot
LDSHARED = aarch64-oe-linux-gcc  -mcpu=cortex-a72+crc+crypto 
--sysroot=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/recipe-sysroot
 -shared
CFLAGS = -O2 -pipe -g -feliminate-unused-debug-types 
-fmacro-prefix-map=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0=/usr/src/debug/ruby/2.7.1-r0
                      
-fdebug-prefix-map=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0=/usr/src/debug/ruby/2.7.1-r0
                      
-fdebug-prefix-map=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/recipe-sysroot=
                      
-fdebug-prefix-map=/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/recipe-sysroot-native=
  -fPIC
XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow 
-fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT 
-DCANONICALIZATION_FOR_MATHN -I. -I.ext/include/aarch64-linux-gnu 
-I../ruby-2.7.1/include -I../ruby-2.7.1 -I../ruby-2.7.1/enc/unicode/12.1.0
CPPFLAGS =
DLDFLAGS = -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-Wl,--compress-debug-sections=zlib -Wl,-soname,libruby.so.2.7  -L. -Wl,-O1 
-Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -rdynamic 
-Wl,-export-dynamic -fstack-protector-strong
SOLIBS = -lz -lpthread -lrt -lrt -ldl -lm
LANG =
LC_ALL = en_US.UTF-8
LC_CTYPE =
MFLAGS = -j --jobserver-fds=4,5
aarch64-oe-linux-gcc (GCC) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

../ruby-2.7.1/revision.h unchanged
generating enc.mk
making srcs under enc
making enc
make[1]: Entering directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
make[1]: Nothing to be done for 'enc'.
make[1]: Leaving directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
make[1]: Entering directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
make[1]: Nothing to be done for 'srcs'.
make[1]: Leaving directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
generating transdb.h
transdb.h unchanged
making trans
generating makefiles ext/configure-ext.mk
make[1]: Entering directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
make[1]: Nothing to be done for '../ruby-2.7.1/enc/trans'.
make[1]: Leaving directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
making encs
make[1]: Entering directory 
'/home/pankaj/ORASP/tmp-glibc/work/aarch64-oe-linux/ruby/2.7.1-r0/build'
make[1]: Nothing to be done for 'encs'.
make[1]: Leaving directory 

[OE-core] tinymembench: fix patch fuzz

[Mircea Carausu via lists.openembedded.org]

Hello,
I am new to the list and up-streaming activities.
Could you please kindly guide me how to submit a fix for the existing
tinymembench.patch
(meta-openembedded/meta-oe/recipes-benchmark/tinymembench/tinymembench/0001-asm-Delete-.func-.endfunc-directives.patch)
Problem:

tinymembench patch does not apply cleanly (it succeeds with warnings - fuzz
detected). Used devtool to fix:

devtool modify tinymembench devtool finish --force-patch-refresh
tinymembench ../meta-openembedded/meta-oe

I already generated the new patch.

What are the next steps (other than local verification).

Should I just upload it here for review once I consider it ready for review?

Sorry for asking such basic questions

Many thanks,

Mircea
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140630): 
https://lists.openembedded.org/g/openembedded-core/message/140630
Mute This Topic: https://lists.openembedded.org/mt/75505558/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 v3] ppp: Allow arbitrary interface names to be specified in pppd config

[Mark Deneen]

Nope.

However, I want to throw this whole thing away.  The patches in question have 
been merged upstream in 2.4.8, and I don't know how I missed that.  I was 
building from dunfell, which is at 2.4.7.

Sorry for the noise, everyone.

Best Regards,
Mark Deneen
Saucon Technologies

- On Jul 14, 2020, at 1:10 PM, Khem Raj raj.k...@gmail.com wrote:

are you aware of any of these platforms being supported by OE ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140629): 
https://lists.openembedded.org/g/openembedded-core/message/140629
Mute This Topic: https://lists.openembedded.org/mt/75503520/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for ppp: Allow arbitrary interface names to be specified in pppd config

[Patchwork]

== Series Details ==

Series: ppp: Allow arbitrary interface names to be specified in pppd config
Revision: 1
URL   : https://patchwork.openembedded.org/series/25133/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140628): 
https://lists.openembedded.org/g/openembedded-core/message/140628
Mute This Topic: https://lists.openembedded.org/mt/75503974/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 v3] ppp: Allow arbitrary interface names to be specified in pppd config

[Khem Raj]

On 7/14/20 10:08 AM, Mark Deneen wrote:
> pppd is patched in most Linux distributions to allow arbitrary naming
> of ppp interfaces, allowing users to create consistent firewall rules
> rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
> missing this option.
> 
> This patch, originally from SUSE, adds this option to pppd. It is not
> included upstream because there are some pppd-supported platforms which
> lack the ability to rename interfaces.
> 

are you aware of any of these platforms being supported by OE ?

> This is the same as the previous patch, but I messed up the subject line.
> 
> Upstream-Status: Inappropriate [not all platforms supported by pppd can 
> rename interfaces]
> 
> Signed-off-by: Mark Deneen 
> ---
>  .../ppp/ppp/0002-pppd-add-ifname-option.patch | 214 ++
>  meta/recipes-connectivity/ppp/ppp_2.4.8.bb|   1 +
>  2 files changed, 215 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
> 
> diff --git 
> a/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch 
> b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
> new file mode 100644
> index 00..8e54024d15
> --- /dev/null
> +++ b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
> @@ -0,0 +1,214 @@
> +From bbcdc4366bbee6c3f4e1ddda31e4eec8c1b3ccc2 Mon Sep 17 00:00:00 2001
> +From: Paul Mackerras 
> +Date: Tue, 23 Aug 2016 16:10:21 +1000
> +Subject: [PATCH 13/16] pppd: allow use of arbitrary interface names
> +
> +This is a modified version of a patch from openSUSE that enables PPP 
> interfaces
> +to be called arbitrary names, rather than simply pppX where X is the unit
> +number.
> +
> +The modifications from the stock openSUSE patch are:
> +- refresh patch on top of 018_ip-up_option.diff
> +- fix a printf format-string vulnerability in pppd/main.c:set_ifunit()
> +- clarify the pppd.8 manpage additions
> +- patch pppstats/pppstats.c to query renamed interfaces without complaint
> +
> +Origin: SUSE
> +Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458646
> +Forwarded: no
> +Reviewed-by: Chris Boot 
> +Signed-off-by: Paul Mackerras 
> +---
> + pppd/main.c | 16 ++--
> + pppd/options.c  |  5 +
> + pppd/pppd.8 |  8 +++-
> + pppd/pppd.h | 11 +++
> + pppd/sys-linux.c| 15 +++
> + pppstats/pppstats.c | 12 ++--
> + 6 files changed, 50 insertions(+), 17 deletions(-)
> +
> +diff --git a/pppd/main.c b/pppd/main.c
> +index 6d50d1bac1d9..f1986ed68d0b 100644
> +--- a/pppd/main.c
>  b/pppd/main.c
> +@@ -124,7 +124,7 @@
> + static const char rcsid[] = RCSID;
> + 
> + /* interface vars */
> +-char ifname[32];/* Interface name */
> ++char ifname[MAXIFNAMELEN];  /* Interface name */
> + int ifunit; /* Interface unit number */
> + 
> + struct channel *the_channel;
> +@@ -298,13 +298,6 @@ struct protent *protocols[] = {
> + NULL
> + };
> + 
> +-/*
> +- * If PPP_DRV_NAME is not defined, use the default "ppp" as the device name.
> +- */
> +-#if !defined(PPP_DRV_NAME)
> +-#define PPP_DRV_NAME"ppp"
> +-#endif /* !defined(PPP_DRV_NAME) */
> +-
> + int
> + main(argc, argv)
> + int argc;
> +@@ -737,8 +730,11 @@ void
> + set_ifunit(iskey)
> + int iskey;
> + {
> +-info("Using interface %s%d", PPP_DRV_NAME, ifunit);
> +-slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
> ++if (req_ifname[0] != '\0')
> ++slprintf(ifname, sizeof(ifname), "%s", req_ifname);
> ++else
> ++slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
> ++info("Using interface %s", ifname);
> + script_setenv("IFNAME", ifname, iskey);
> + if (iskey) {
> + create_pidfile(getpid());   /* write pid to file */
> +diff --git a/pppd/options.c b/pppd/options.c
> +index c06a2b4ad8ed..177488ca6813 100644
> +--- a/pppd/options.c
>  b/pppd/options.c
> +@@ -114,6 +114,7 @@ char linkname[MAXPATHLEN];   /* logical name for 
> link */
> + booltune_kernel;/* may alter kernel settings */
> + int connect_delay = 1000;   /* wait this many ms after connect script */
> + int req_unit = -1;  /* requested interface unit */
> ++charreq_ifname[MAXIFNAMELEN];   /* requested interface name */
> + boolmultilink = 0;  /* Enable multilink operation */
> + char*bundle_name = NULL;/* bundle name for multilink */
> + booldump_options;   /* print out option values */
> +@@ -284,6 +285,10 @@ option_t general_options[] = {
> +   "PPP interface unit number to use if possible",
> +   OPT_PRIO | OPT_LLIMIT, 0, 0 },
> + 
> ++{ "ifname", o_string, req_ifname,
> ++  "Set PPP interface name",
> ++  OPT_PRIO | OPT_PRIV | OPT_STATIC, NULL, MAXIFNAMELEN },
> ++
> + { "dump", o_bool, _options,
> +   "Print out option values after parsing all options", 1 },
> + { 

[OE-core] [PATCH v3] ppp: Allow arbitrary interface names to be specified in pppd config

[Mark Deneen]

pppd is patched in most Linux distributions to allow arbitrary naming
of ppp interfaces, allowing users to create consistent firewall rules
rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
missing this option.

This patch, originally from SUSE, adds this option to pppd. It is not
included upstream because there are some pppd-supported platforms which
lack the ability to rename interfaces.

This is the same as the previous patch, but I messed up the subject line.

Upstream-Status: Inappropriate [not all platforms supported by pppd can rename 
interfaces]

Signed-off-by: Mark Deneen 
---
 .../ppp/ppp/0002-pppd-add-ifname-option.patch | 214 ++
 meta/recipes-connectivity/ppp/ppp_2.4.8.bb|   1 +
 2 files changed, 215 insertions(+)
 create mode 100644 
meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch

diff --git 
a/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch 
b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
new file mode 100644
index 00..8e54024d15
--- /dev/null
+++ b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
@@ -0,0 +1,214 @@
+From bbcdc4366bbee6c3f4e1ddda31e4eec8c1b3ccc2 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras 
+Date: Tue, 23 Aug 2016 16:10:21 +1000
+Subject: [PATCH 13/16] pppd: allow use of arbitrary interface names
+
+This is a modified version of a patch from openSUSE that enables PPP interfaces
+to be called arbitrary names, rather than simply pppX where X is the unit
+number.
+
+The modifications from the stock openSUSE patch are:
+- refresh patch on top of 018_ip-up_option.diff
+- fix a printf format-string vulnerability in pppd/main.c:set_ifunit()
+- clarify the pppd.8 manpage additions
+- patch pppstats/pppstats.c to query renamed interfaces without complaint
+
+Origin: SUSE
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458646
+Forwarded: no
+Reviewed-by: Chris Boot 
+Signed-off-by: Paul Mackerras 
+---
+ pppd/main.c | 16 ++--
+ pppd/options.c  |  5 +
+ pppd/pppd.8 |  8 +++-
+ pppd/pppd.h | 11 +++
+ pppd/sys-linux.c| 15 +++
+ pppstats/pppstats.c | 12 ++--
+ 6 files changed, 50 insertions(+), 17 deletions(-)
+
+diff --git a/pppd/main.c b/pppd/main.c
+index 6d50d1bac1d9..f1986ed68d0b 100644
+--- a/pppd/main.c
 b/pppd/main.c
+@@ -124,7 +124,7 @@
+ static const char rcsid[] = RCSID;
+ 
+ /* interface vars */
+-char ifname[32];  /* Interface name */
++char ifname[MAXIFNAMELEN];/* Interface name */
+ int ifunit;   /* Interface unit number */
+ 
+ struct channel *the_channel;
+@@ -298,13 +298,6 @@ struct protent *protocols[] = {
+ NULL
+ };
+ 
+-/*
+- * If PPP_DRV_NAME is not defined, use the default "ppp" as the device name.
+- */
+-#if !defined(PPP_DRV_NAME)
+-#define PPP_DRV_NAME  "ppp"
+-#endif /* !defined(PPP_DRV_NAME) */
+-
+ int
+ main(argc, argv)
+ int argc;
+@@ -737,8 +730,11 @@ void
+ set_ifunit(iskey)
+ int iskey;
+ {
+-info("Using interface %s%d", PPP_DRV_NAME, ifunit);
+-slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++if (req_ifname[0] != '\0')
++  slprintf(ifname, sizeof(ifname), "%s", req_ifname);
++else
++  slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++info("Using interface %s", ifname);
+ script_setenv("IFNAME", ifname, iskey);
+ if (iskey) {
+   create_pidfile(getpid());   /* write pid to file */
+diff --git a/pppd/options.c b/pppd/options.c
+index c06a2b4ad8ed..177488ca6813 100644
+--- a/pppd/options.c
 b/pppd/options.c
+@@ -114,6 +114,7 @@ char   linkname[MAXPATHLEN];   /* logical name for 
link */
+ bool  tune_kernel;/* may alter kernel settings */
+ int   connect_delay = 1000;   /* wait this many ms after connect script */
+ int   req_unit = -1;  /* requested interface unit */
++char  req_ifname[MAXIFNAMELEN];   /* requested interface name */
+ bool  multilink = 0;  /* Enable multilink operation */
+ char  *bundle_name = NULL;/* bundle name for multilink */
+ bool  dump_options;   /* print out option values */
+@@ -284,6 +285,10 @@ option_t general_options[] = {
+   "PPP interface unit number to use if possible",
+   OPT_PRIO | OPT_LLIMIT, 0, 0 },
+ 
++{ "ifname", o_string, req_ifname,
++  "Set PPP interface name",
++  OPT_PRIO | OPT_PRIV | OPT_STATIC, NULL, MAXIFNAMELEN },
++
+ { "dump", o_bool, _options,
+   "Print out option values after parsing all options", 1 },
+ { "dryrun", o_bool, ,
+diff --git a/pppd/pppd.8 b/pppd/pppd.8
+index c508d277df3a..06e945fce998 100644
+--- a/pppd/pppd.8
 b/pppd/pppd.8
+@@ -1079,7 +1079,13 @@ under Linux and FreeBSD 2.2.8 and later.
+ .TP
+ .B unit \fInum
+ Sets the ppp unit number (for a ppp0 or ppp1 etc interface name) for outbound
+-connections.
++connections.  If the unit is already in use a 

Re: [OE-core] [PATCH 2/2] insane: improve arch test messages

[Khem Raj]

On 7/14/20 10:02 AM, Ross Burton wrote:
> From: Ross Burton 
> 
> The messages from the ELF 'arch' test are not obvious, clarify the
> messages and prune output paths.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/insane.bbclass | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 89a516882b..ee19ef673e 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -364,14 +364,14 @@ def package_qa_check_arch(path,name,d, elf, messages):
>  target_os == "linux-gnu_ilp32" or re.match(r'mips64.*32', 
> d.getVar('DEFAULTTUNE')))
>  is_bpf = (oe.qa.elf_machine_to_string(elf.machine()) == "BPF")
>  if not ((machine == elf.machine()) or is_32 or is_bpf):
> -package_qa_add_message(messages, "arch", "Architecture did not match 
> (%s, expected %s) on %s" % \
> - (oe.qa.elf_machine_to_string(elf.machine()), 
> oe.qa.elf_machine_to_string(machine), package_qa_clean_path(path,d)))
> +package_qa_add_message(messages, "arch", "Architecture did not match 
> (%s, expected %s) in %s" % \

Should this be called CPU architecture as well.

> + (oe.qa.elf_machine_to_string(elf.machine()), 
> oe.qa.elf_machine_to_string(machine), package_qa_clean_path(path, d, name)))
>  elif not ((bits == elf.abiSize()) or is_32 or is_bpf):
> -package_qa_add_message(messages, "arch", "Bit size did not match (%d 
> to %d) %s on %s" % \
> - (bits, elf.abiSize(), bpn, package_qa_clean_path(path,d)))
> +package_qa_add_message(messages, "arch", "Bit size did not match 
> (%d, expected %d) in %s" % \

Bit size perhaps should be called Word size to use more familiar term
for this.

> + (elf.abiSize(), bits, package_qa_clean_path(path, d, name)))
>  elif not ((littleendian == elf.isLittleEndian()) or is_bpf):
> -package_qa_add_message(messages, "arch", "Endiannes did not match 
> (%d to %d) on %s" % \
> - (littleendian, elf.isLittleEndian(), 
> package_qa_clean_path(path,d)))
> +package_qa_add_message(messages, "arch", "Endiannes did not match 
> (%d, expected %d) in %s" % \

typo, it should be Endianness

> + (elf.isLittleEndian(), littleendian, 
> package_qa_clean_path(path,d, name)))
>  
>  QAPATHTEST[desktop] = "package_qa_check_desktop"
>  def package_qa_check_desktop(path, name, d, elf, messages):
> 
> 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140625): 
https://lists.openembedded.org/g/openembedded-core/message/140625
Mute This Topic: https://lists.openembedded.org/mt/75503366/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] insane: improve arch test messages

[Ross Burton]

From: Ross Burton 

The messages from the ELF 'arch' test are not obvious, clarify the
messages and prune output paths.

Signed-off-by: Ross Burton 
---
 meta/classes/insane.bbclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 89a516882b..ee19ef673e 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -364,14 +364,14 @@ def package_qa_check_arch(path,name,d, elf, messages):
 target_os == "linux-gnu_ilp32" or re.match(r'mips64.*32', 
d.getVar('DEFAULTTUNE')))
 is_bpf = (oe.qa.elf_machine_to_string(elf.machine()) == "BPF")
 if not ((machine == elf.machine()) or is_32 or is_bpf):
-package_qa_add_message(messages, "arch", "Architecture did not match 
(%s, expected %s) on %s" % \
- (oe.qa.elf_machine_to_string(elf.machine()), 
oe.qa.elf_machine_to_string(machine), package_qa_clean_path(path,d)))
+package_qa_add_message(messages, "arch", "Architecture did not match 
(%s, expected %s) in %s" % \
+ (oe.qa.elf_machine_to_string(elf.machine()), 
oe.qa.elf_machine_to_string(machine), package_qa_clean_path(path, d, name)))
 elif not ((bits == elf.abiSize()) or is_32 or is_bpf):
-package_qa_add_message(messages, "arch", "Bit size did not match (%d 
to %d) %s on %s" % \
- (bits, elf.abiSize(), bpn, package_qa_clean_path(path,d)))
+package_qa_add_message(messages, "arch", "Bit size did not match (%d, 
expected %d) in %s" % \
+ (elf.abiSize(), bits, package_qa_clean_path(path, d, name)))
 elif not ((littleendian == elf.isLittleEndian()) or is_bpf):
-package_qa_add_message(messages, "arch", "Endiannes did not match (%d 
to %d) on %s" % \
- (littleendian, elf.isLittleEndian(), 
package_qa_clean_path(path,d)))
+package_qa_add_message(messages, "arch", "Endiannes did not match (%d, 
expected %d) in %s" % \
+ (elf.isLittleEndian(), littleendian, 
package_qa_clean_path(path,d, name)))
 
 QAPATHTEST[desktop] = "package_qa_check_desktop"
 def package_qa_check_desktop(path, name, d, elf, messages):
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140624): 
https://lists.openembedded.org/g/openembedded-core/message/140624
Mute This Topic: https://lists.openembedded.org/mt/75503366/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 1/2] init-ifupdown: always make machine-specific

[Ross Burton]

From: Ross Burton 

We make this recipe machine-specific for all qemu targets, but otherwise
defaults to tune-specific.

However the network configuration is typically machine-specific, so do
this in the recipe directly so that BSPs don't need to do it themselves.

Signed-off-by: Ross Burton 
---
 meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb 
b/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
index 733ae41f20..b6fc8a4d41 100644
--- a/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
+++ b/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
@@ -34,7 +34,7 @@ do_install_append_qemuall () {
touch ${D}${sysconfdir}/network/nm-disabled-eth0
 }
 
-PACKAGE_ARCH_qemuall = "${MACHINE_ARCH}"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 RDEPENDS_${PN} = "netbase"
 RCONFLICTS_${PN} = "netbase (< 1:5.0)"
 
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140623): 
https://lists.openembedded.org/g/openembedded-core/message/140623
Mute This Topic: https://lists.openembedded.org/mt/75503365/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 v2] ppp: Allow arbitrary interface names to be specified in pppd config

[Mark Deneen]

pppd is patched in most Linux distributions to allow arbitrary naming
of ppp interfaces, allowing users to create consistent firewall rules
rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
missing this option.

This patch, originally from SUSE, adds this option to pppd. It is not
included upstream because there are some pppd-supported platforms which
lack the ability to rename interfaces.

Upstream-Status: Inappropriate [not all platforms supported by pppd can rename 
interfaces]

Signed-off-by: Mark Deneen 
---
 .../ppp/ppp/0002-pppd-add-ifname-option.patch | 214 ++
 meta/recipes-connectivity/ppp/ppp_2.4.8.bb|   1 +
 2 files changed, 215 insertions(+)
 create mode 100644 
meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch

diff --git 
a/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch 
b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
new file mode 100644
index 00..8e54024d15
--- /dev/null
+++ b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
@@ -0,0 +1,214 @@
+From bbcdc4366bbee6c3f4e1ddda31e4eec8c1b3ccc2 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras 
+Date: Tue, 23 Aug 2016 16:10:21 +1000
+Subject: [PATCH 13/16] pppd: allow use of arbitrary interface names
+
+This is a modified version of a patch from openSUSE that enables PPP interfaces
+to be called arbitrary names, rather than simply pppX where X is the unit
+number.
+
+The modifications from the stock openSUSE patch are:
+- refresh patch on top of 018_ip-up_option.diff
+- fix a printf format-string vulnerability in pppd/main.c:set_ifunit()
+- clarify the pppd.8 manpage additions
+- patch pppstats/pppstats.c to query renamed interfaces without complaint
+
+Origin: SUSE
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458646
+Forwarded: no
+Reviewed-by: Chris Boot 
+Signed-off-by: Paul Mackerras 
+---
+ pppd/main.c | 16 ++--
+ pppd/options.c  |  5 +
+ pppd/pppd.8 |  8 +++-
+ pppd/pppd.h | 11 +++
+ pppd/sys-linux.c| 15 +++
+ pppstats/pppstats.c | 12 ++--
+ 6 files changed, 50 insertions(+), 17 deletions(-)
+
+diff --git a/pppd/main.c b/pppd/main.c
+index 6d50d1bac1d9..f1986ed68d0b 100644
+--- a/pppd/main.c
 b/pppd/main.c
+@@ -124,7 +124,7 @@
+ static const char rcsid[] = RCSID;
+ 
+ /* interface vars */
+-char ifname[32];  /* Interface name */
++char ifname[MAXIFNAMELEN];/* Interface name */
+ int ifunit;   /* Interface unit number */
+ 
+ struct channel *the_channel;
+@@ -298,13 +298,6 @@ struct protent *protocols[] = {
+ NULL
+ };
+ 
+-/*
+- * If PPP_DRV_NAME is not defined, use the default "ppp" as the device name.
+- */
+-#if !defined(PPP_DRV_NAME)
+-#define PPP_DRV_NAME  "ppp"
+-#endif /* !defined(PPP_DRV_NAME) */
+-
+ int
+ main(argc, argv)
+ int argc;
+@@ -737,8 +730,11 @@ void
+ set_ifunit(iskey)
+ int iskey;
+ {
+-info("Using interface %s%d", PPP_DRV_NAME, ifunit);
+-slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++if (req_ifname[0] != '\0')
++  slprintf(ifname, sizeof(ifname), "%s", req_ifname);
++else
++  slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++info("Using interface %s", ifname);
+ script_setenv("IFNAME", ifname, iskey);
+ if (iskey) {
+   create_pidfile(getpid());   /* write pid to file */
+diff --git a/pppd/options.c b/pppd/options.c
+index c06a2b4ad8ed..177488ca6813 100644
+--- a/pppd/options.c
 b/pppd/options.c
+@@ -114,6 +114,7 @@ char   linkname[MAXPATHLEN];   /* logical name for 
link */
+ bool  tune_kernel;/* may alter kernel settings */
+ int   connect_delay = 1000;   /* wait this many ms after connect script */
+ int   req_unit = -1;  /* requested interface unit */
++char  req_ifname[MAXIFNAMELEN];   /* requested interface name */
+ bool  multilink = 0;  /* Enable multilink operation */
+ char  *bundle_name = NULL;/* bundle name for multilink */
+ bool  dump_options;   /* print out option values */
+@@ -284,6 +285,10 @@ option_t general_options[] = {
+   "PPP interface unit number to use if possible",
+   OPT_PRIO | OPT_LLIMIT, 0, 0 },
+ 
++{ "ifname", o_string, req_ifname,
++  "Set PPP interface name",
++  OPT_PRIO | OPT_PRIV | OPT_STATIC, NULL, MAXIFNAMELEN },
++
+ { "dump", o_bool, _options,
+   "Print out option values after parsing all options", 1 },
+ { "dryrun", o_bool, ,
+diff --git a/pppd/pppd.8 b/pppd/pppd.8
+index c508d277df3a..06e945fce998 100644
+--- a/pppd/pppd.8
 b/pppd/pppd.8
+@@ -1079,7 +1079,13 @@ under Linux and FreeBSD 2.2.8 and later.
+ .TP
+ .B unit \fInum
+ Sets the ppp unit number (for a ppp0 or ppp1 etc interface name) for outbound
+-connections.
++connections.  If the unit is already in use a dynamically allocated number 
will
++be used.
++.TP
++.B ifname \fIstring
++Set the 

[OE-core] ✗ patchtest: failure for Allow arbitrary interface names to be specified in pppd config

[Patchwork]

== Series Details ==

Series: Allow arbitrary interface names to be specified in pppd config
Revision: 1
URL   : https://patchwork.openembedded.org/series/25131/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* PatchAllow arbitrary interface names to be specified in pppd 
config
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140621): 
https://lists.openembedded.org/g/openembedded-core/message/140621
Mute This Topic: https://lists.openembedded.org/mt/75502719/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] Allow arbitrary interface names to be specified in pppd config

[Mark Deneen]

pppd is patched in most Linux distributions to allow arbitrary naming
of ppp interfaces, allowing users to create consistent firewall rules
rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
missing this option.

This patch, originally from SUSE, adds this option to pppd. It is not
included upstream because there are some pppd-supported platforms which
lack the ability to rename interfaces.

Signed-off-by: Mark Deneen 
---
 .../ppp/ppp/0002-pppd-add-ifname-option.patch | 214 ++
 meta/recipes-connectivity/ppp/ppp_2.4.8.bb|   1 +
 2 files changed, 215 insertions(+)
 create mode 100644 
meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch

diff --git 
a/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch 
b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
new file mode 100644
index 00..8e54024d15
--- /dev/null
+++ b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
@@ -0,0 +1,214 @@
+From bbcdc4366bbee6c3f4e1ddda31e4eec8c1b3ccc2 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras 
+Date: Tue, 23 Aug 2016 16:10:21 +1000
+Subject: [PATCH 13/16] pppd: allow use of arbitrary interface names
+
+This is a modified version of a patch from openSUSE that enables PPP interfaces
+to be called arbitrary names, rather than simply pppX where X is the unit
+number.
+
+The modifications from the stock openSUSE patch are:
+- refresh patch on top of 018_ip-up_option.diff
+- fix a printf format-string vulnerability in pppd/main.c:set_ifunit()
+- clarify the pppd.8 manpage additions
+- patch pppstats/pppstats.c to query renamed interfaces without complaint
+
+Origin: SUSE
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458646
+Forwarded: no
+Reviewed-by: Chris Boot 
+Signed-off-by: Paul Mackerras 
+---
+ pppd/main.c | 16 ++--
+ pppd/options.c  |  5 +
+ pppd/pppd.8 |  8 +++-
+ pppd/pppd.h | 11 +++
+ pppd/sys-linux.c| 15 +++
+ pppstats/pppstats.c | 12 ++--
+ 6 files changed, 50 insertions(+), 17 deletions(-)
+
+diff --git a/pppd/main.c b/pppd/main.c
+index 6d50d1bac1d9..f1986ed68d0b 100644
+--- a/pppd/main.c
 b/pppd/main.c
+@@ -124,7 +124,7 @@
+ static const char rcsid[] = RCSID;
+ 
+ /* interface vars */
+-char ifname[32];  /* Interface name */
++char ifname[MAXIFNAMELEN];/* Interface name */
+ int ifunit;   /* Interface unit number */
+ 
+ struct channel *the_channel;
+@@ -298,13 +298,6 @@ struct protent *protocols[] = {
+ NULL
+ };
+ 
+-/*
+- * If PPP_DRV_NAME is not defined, use the default "ppp" as the device name.
+- */
+-#if !defined(PPP_DRV_NAME)
+-#define PPP_DRV_NAME  "ppp"
+-#endif /* !defined(PPP_DRV_NAME) */
+-
+ int
+ main(argc, argv)
+ int argc;
+@@ -737,8 +730,11 @@ void
+ set_ifunit(iskey)
+ int iskey;
+ {
+-info("Using interface %s%d", PPP_DRV_NAME, ifunit);
+-slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++if (req_ifname[0] != '\0')
++  slprintf(ifname, sizeof(ifname), "%s", req_ifname);
++else
++  slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++info("Using interface %s", ifname);
+ script_setenv("IFNAME", ifname, iskey);
+ if (iskey) {
+   create_pidfile(getpid());   /* write pid to file */
+diff --git a/pppd/options.c b/pppd/options.c
+index c06a2b4ad8ed..177488ca6813 100644
+--- a/pppd/options.c
 b/pppd/options.c
+@@ -114,6 +114,7 @@ char   linkname[MAXPATHLEN];   /* logical name for 
link */
+ bool  tune_kernel;/* may alter kernel settings */
+ int   connect_delay = 1000;   /* wait this many ms after connect script */
+ int   req_unit = -1;  /* requested interface unit */
++char  req_ifname[MAXIFNAMELEN];   /* requested interface name */
+ bool  multilink = 0;  /* Enable multilink operation */
+ char  *bundle_name = NULL;/* bundle name for multilink */
+ bool  dump_options;   /* print out option values */
+@@ -284,6 +285,10 @@ option_t general_options[] = {
+   "PPP interface unit number to use if possible",
+   OPT_PRIO | OPT_LLIMIT, 0, 0 },
+ 
++{ "ifname", o_string, req_ifname,
++  "Set PPP interface name",
++  OPT_PRIO | OPT_PRIV | OPT_STATIC, NULL, MAXIFNAMELEN },
++
+ { "dump", o_bool, _options,
+   "Print out option values after parsing all options", 1 },
+ { "dryrun", o_bool, ,
+diff --git a/pppd/pppd.8 b/pppd/pppd.8
+index c508d277df3a..06e945fce998 100644
+--- a/pppd/pppd.8
 b/pppd/pppd.8
+@@ -1079,7 +1079,13 @@ under Linux and FreeBSD 2.2.8 and later.
+ .TP
+ .B unit \fInum
+ Sets the ppp unit number (for a ppp0 or ppp1 etc interface name) for outbound
+-connections.
++connections.  If the unit is already in use a dynamically allocated number 
will
++be used.
++.TP
++.B ifname \fIstring
++Set the ppp interface name for outbound connections.  If the interface name is
++already in use, or 

Re: [OE-core] [PATCH] ppp: Add support for setting ifname in ppp options

[Mark Deneen]

Quentin,

Thanks for the feedback, and I will resend this.  I started off with a
patch which contained the original authors, but that was lost in the
process of applying the patch, since it is a patch of a patch.  I was
attempting to avoid patch fuzzing, since it had previously been
applied to pppd 2.4.8.  Is a small amount of fuzz acceptable?

-M

On Tue, Jul 14, 2020 at 11:14 AM Quentin Schulz
 wrote:
>
> Hi Mark,
>
> On Tue, Jul 14, 2020 at 11:04:41AM -0400, Mark Deneen wrote:
> > pppd is patched in most Linux distributions to allow arbitrary naming
> > of ppp interfaces, allowing users to create consistent firewall rules
> > rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
> > missing this option.
> >
> > This patch, originally from SUSE, adds this option to pppd. It is not
> > included upstream because there are some pppd-supported platforms which
> > lack the ability to rename interfaces.
> >
> > Signed-off-by: Mark Deneen 
>
> Please follow guidelines from:
> https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
> to know how to contribute in a way that is matching OE patch management.
>
> Your mail content should probably be the content of the commit log. Your
> mail should directly be the output of git format-patch (send it with
> git send-email), the patch shouldn't be attached to the mail but rather
> "be" the mail.
>
> On the content of the patch, it'd be nice to take the patch with the
> authors, commit title and log from the original place where you took it
> from.
>
> It probably is:
> https://sources.debian.org/patches/ppp/2.4.6-3.1/ppp-2.4.2-ifname.diff/
> ?
>
> No author, no commit log :/ Though, I could find
> https://sources.debian.org/patches/ppp/2.4.6-3.1/ppp-2.4.2-ifname.diff/
> which is slightly different and the changelog seems decent between
> Suse's and debian's patch.
>
> Thanks,
> Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140619): 
https://lists.openembedded.org/g/openembedded-core/message/140619
Mute This Topic: https://lists.openembedded.org/mt/75500647/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for ppp: Add support for setting ifname in ppp options

[Patchwork]

== Series Details ==

Series: ppp: Add support for setting ifname in ppp options
Revision: 1
URL   : https://patchwork.openembedded.org/series/25130/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch)

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140618): 
https://lists.openembedded.org/g/openembedded-core/message/140618
Mute This Topic: https://lists.openembedded.org/mt/75501239/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] ppp: Add support for setting ifname in ppp options

[Quentin Schulz]

Hi Mark,

On Tue, Jul 14, 2020 at 11:04:41AM -0400, Mark Deneen wrote:
> pppd is patched in most Linux distributions to allow arbitrary naming
> of ppp interfaces, allowing users to create consistent firewall rules
> rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
> missing this option.
> 
> This patch, originally from SUSE, adds this option to pppd. It is not
> included upstream because there are some pppd-supported platforms which
> lack the ability to rename interfaces.
> 
> Signed-off-by: Mark Deneen 

Please follow guidelines from:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
to know how to contribute in a way that is matching OE patch management.

Your mail content should probably be the content of the commit log. Your
mail should directly be the output of git format-patch (send it with
git send-email), the patch shouldn't be attached to the mail but rather
"be" the mail.

On the content of the patch, it'd be nice to take the patch with the
authors, commit title and log from the original place where you took it
from.

It probably is:
https://sources.debian.org/patches/ppp/2.4.6-3.1/ppp-2.4.2-ifname.diff/
?

No author, no commit log :/ Though, I could find
https://sources.debian.org/patches/ppp/2.4.6-3.1/ppp-2.4.2-ifname.diff/
which is slightly different and the changelog seems decent between
Suse's and debian's patch.

Thanks,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140617): 
https://lists.openembedded.org/g/openembedded-core/message/140617
Mute This Topic: https://lists.openembedded.org/mt/75500647/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] How to install individual -lic packages

[Christian Eggers]

In the meantime I could answer the question myself:

Am Freitag, 10. Juli 2020, 23:16:39 CEST schrieb Christian Eggers:
> [...]
> I think this is not what I require. How can I install -lic packages
> directly?

In order to known by other (image) recipes, -lic packages must be
added to PACKAGES_DYNAMIC. This is done in my distro.conf but should also work
from local.conf:

# Create separate ${PN}-lic packages for all recipes
LICENSE_CREATE_PACKAGE = "1"
# -lic packages are created dynamically. Satisfy dependencies to it (required
# if a -lic package needs to be installed directly (e.g. via IMAGE_INSTALL)
# instead of being installed due to RRECOMMENDS_${PN}).
PACKAGES_DYNAMIC += "^${PN}-lic"

After adding ${PN}-lic to PACKAGES_DYNAMIC, arbitrary -lic packages
can be added to an image recipe by using IMAGE_INSTALL. As an alternative,
other packages can RDEPEND on them.

regards
Christian




 
[http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg] 


Get all the latest information from www.arri.com, 
Facebook, 
Twitter, Instagram 
and YouTube.

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: 
HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: 
HRB 54477
Geschäftsführer: Dr. Michael Neuhäuser; Stephan Schenk; Walter Trauninger; 
Markus Zeiler
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140616): 
https://lists.openembedded.org/g/openembedded-core/message/140616
Mute This Topic: https://lists.openembedded.org/mt/75394824/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] ppp: Add support for setting ifname in ppp options

[Mark Deneen]

pppd is patched in most Linux distributions to allow arbitrary naming
of ppp interfaces, allowing users to create consistent firewall rules
rather than having interfaces named "ppp0", "ppp1", etc.  Yocto is
missing this option.

This patch, originally from SUSE, adds this option to pppd. It is not
included upstream because there are some pppd-supported platforms which
lack the ability to rename interfaces.

Signed-off-by: Mark Deneen 
From bec9545448a2ae8ce4bdf4738f38734f44643aa6 Mon Sep 17 00:00:00 2001
From: Mark Deneen 
Date: Tue, 14 Jul 2020 10:41:41 -0400
Subject: [PATCH] allow setting ifname in ppp config options, patch originally
 from SUSE.

---
 .../ppp/ppp/0002-pppd-add-ifname-option.patch | 182 ++
 meta/recipes-connectivity/ppp/ppp_2.4.8.bb|   1 +
 2 files changed, 183 insertions(+)
 create mode 100644 meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch

diff --git a/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
new file mode 100644
index 00..29e50cb949
--- /dev/null
+++ b/meta/recipes-connectivity/ppp/ppp/0002-pppd-add-ifname-option.patch
@@ -0,0 +1,182 @@
+diff --git a/pppd/main.c b/pppd/main.c
+index 6d50d1b..f1986ed 100644
+--- a/pppd/main.c
 b/pppd/main.c
+@@ -124,7 +124,7 @@
+ static const char rcsid[] = RCSID;
+ 
+ /* interface vars */
+-char ifname[32];		/* Interface name */
++char ifname[MAXIFNAMELEN];	/* Interface name */
+ int ifunit;			/* Interface unit number */
+ 
+ struct channel *the_channel;
+@@ -298,13 +298,6 @@ struct protent *protocols[] = {
+ NULL
+ };
+ 
+-/*
+- * If PPP_DRV_NAME is not defined, use the default "ppp" as the device name.
+- */
+-#if !defined(PPP_DRV_NAME)
+-#define PPP_DRV_NAME	"ppp"
+-#endif /* !defined(PPP_DRV_NAME) */
+-
+ int
+ main(argc, argv)
+ int argc;
+@@ -737,8 +730,11 @@ void
+ set_ifunit(iskey)
+ int iskey;
+ {
+-info("Using interface %s%d", PPP_DRV_NAME, ifunit);
+-slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++if (req_ifname[0] != '\0')
++	slprintf(ifname, sizeof(ifname), "%s", req_ifname);
++else
++	slprintf(ifname, sizeof(ifname), "%s%d", PPP_DRV_NAME, ifunit);
++info("Using interface %s", ifname);
+ script_setenv("IFNAME", ifname, iskey);
+ if (iskey) {
+ 	create_pidfile(getpid());	/* write pid to file */
+diff --git a/pppd/options.c b/pppd/options.c
+index f66b765..91da515 100644
+--- a/pppd/options.c
 b/pppd/options.c
+@@ -114,6 +114,7 @@ char	linkname[MAXPATHLEN];	/* logical name for link */
+ bool	tune_kernel;		/* may alter kernel settings */
+ int	connect_delay = 1000;	/* wait this many ms after connect script */
+ int	req_unit = -1;		/* requested interface unit */
++char	req_ifname[MAXIFNAMELEN];	/* requested interface name */
+ bool	multilink = 0;		/* Enable multilink operation */
+ char	*bundle_name = NULL;	/* bundle name for multilink */
+ bool	dump_options;		/* print out option values */
+@@ -283,6 +284,10 @@ option_t general_options[] = {
+   "PPP interface unit number to use if possible",
+   OPT_PRIO | OPT_LLIMIT, 0, 0 },
+ 
++{ "ifname", o_string, req_ifname,
++  "Set PPP interface name",
++  OPT_PRIO | OPT_PRIV | OPT_STATIC, NULL, MAXIFNAMELEN },
++
+ { "dump", o_bool, _options,
+   "Print out option values after parsing all options", 1 },
+ { "dryrun", o_bool, ,
+diff --git a/pppd/pppd.8 b/pppd/pppd.8
+index c8b595d..0acd493 100644
+--- a/pppd/pppd.8
 b/pppd/pppd.8
+@@ -1085,7 +1085,13 @@ under Linux and FreeBSD 2.2.8 and later.
+ .TP
+ .B unit \fInum
+ Sets the ppp unit number (for a ppp0 or ppp1 etc interface name) for outbound
+-connections.
++connections.  If the unit is already in use a dynamically allocated number will
++be used.
++.TP
++.B ifname \fIstring
++Set the ppp interface name for outbound connections.  If the interface name is
++already in use, or if the name cannot be used for any other reason, pppd will
++terminate.
+ .TP
+ .B unset \fIname
+ Remove a variable from the environment variable for scripts that are
+diff --git a/pppd/pppd.h b/pppd/pppd.h
+index 8ade4d8..7495df6 100644
+--- a/pppd/pppd.h
 b/pppd/pppd.h
+@@ -80,6 +80,16 @@
+ #define MAXARGS		1	/* max # args to a command */
+ #define MAXNAMELEN	256	/* max length of hostname or name for auth */
+ #define MAXSECRETLEN	256	/* max length of password or secret */
++#define MAXIFNAMELEN	32	/* max length of interface name; or use IFNAMSIZ, can we
++   always include net/if.h? */
++
++/*
++ * If PPP_DRV_NAME is not defined, use the default "ppp" as the device name.
++ * Where should PPP_DRV_NAME come from? Do we include it here?
++ */
++#if !defined(PPP_DRV_NAME)
++#define PPP_DRV_NAME	"ppp"
++#endif /* !defined(PPP_DRV_NAME) */
+ 
+ /*
+  * Option descriptor structure.
+@@ -318,6 +328,7 @@ extern bool	tune_kernel;	/* May alter kernel settings as necessary */
+ extern int	connect_delay;	/* Time to delay after 

[OE-core] Yocto Project Status WW28'20

[Stephen Jolley]

Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 16th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Aug. 4th at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday July 14th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   A key autobuilder race has been identified as a race around the
bitbake lock file which will hopefully continue to reduce the number of
intermittent failures being seen. It potentially explains a number of the
open bugs. You can see the list of failures we're continuing to see by
searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
*   We are struggling with maintainers for some key components of the
system/infrastructure such as devtool, wic, buildhistory and
patchwork/patchtest. If anyone can help in these areas please contact
Richard.
*   Another way to help the project is to help us with bugs that are
currently unassigned but ideally needed during 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   We're planning to migrate the project documentation from docbook to
sphinx. If you're interested/able to help with this please join the
discussion over on the docs mailing list.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M2 build date 2020/7/27
*   YP 3.2 M2 Release date 2020/8/7
*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/9/14
*   YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2465 (last week 2485) (

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

*   Total patches found: 1269 (last week 1268)
*   Patches in the Pending State: 498 (39%) [last week 497 (39%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140614): 
https://lists.openembedded.org/g/openembedded-core/message/140614
Mute This Topic: https://lists.openembedded.org/mt/75500073/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] [yocto] Stable Warrior branch

[Adrian Bunk]

On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote:
> Hello,
> 
> The Warrior branch of Poky has had its last official dot release. It
> will be moving to Community support and EOL within 6 weeks if no one
> steps up.
> If someone is interested in taking on the responsibilities of
> maintaining the "Warrior" branch moving forward, please email this list.

I have an interest in keeping warrior branch alive in poky and meta-oe,
and I'll take this responsibility since noone else seems to be interested.

> Please look at the
> https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what will
> be expected.

I have some ideas, but not yet a fixed plan how I will set this up.

> regards,
> Armin

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140613): 
https://lists.openembedded.org/g/openembedded-core/message/140613
Mute This Topic: https://lists.openembedded.org/mt/75499040/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][dunfell 08/15] kernel.bbclass: make dependency on lzop-native conditional

[Max Krummenacher]

Note that the kernel config CONFIG_KERNEL_LZO must also be present to
have the compressed part in the zImage using LZO compression.

E.g. the i.MX defconfig uses that:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/imx_v6_v7_defconfig?h=v5.8-rc5#n1

I personally don't mind adding the dependency in the same place where I set
the
defconfig, but having the dependency removal trickle down to older releases
seems to not merit the build time gain.

Am Di., 14. Juli 2020 um 01:59 Uhr schrieb Khem Raj :

>
>
> On 7/13/20 2:29 PM, Max Krummenacher wrote:
> > Hi
> >
> > Can we drop this one from the backports?
> >
> > The patch possibly reduces a bit of build time if lzop-native is not used
> > by any other recipe, but does not fix anything.
> >
> > One can build a zImage which is compressed with lzo. For a kernel recipe
> which
> > does use a zImage with lzo and relies on the kernel.bbclass to add a
> depend on
> > lzop-native the build breaks.
> >
>
> it seems original patch is not adequate yet, perhaps it should also
> check for KERNEL_IMAGETYPE to have lzo before dropping this dependency,
> once thats taken care, both together are good for dunfell too.
>
> > Cheers
> > Max
> >
> > Am Montag, den 13.07.2020, 04:16 -1000 schrieb Steve Sakoman:
> >> From: Timon Ulrich 
> >>
> >> a native lzop is only needed when an lzo compressed initramfs is
> actually present
> >>
> >> Signed-off-by: Timon Ulrich 
> >> Signed-off-by: Richard Purdie 
> >> (cherry picked from commit 1217ddf070261c5fe523729b2a833bd38f1e4ccd)
> >> Signed-off-by: Steve Sakoman 
> >> ---
> >>   meta/classes/kernel.bbclass | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> >> index 9e3c34ad48..af7e88b380 100644
> >> --- a/meta/classes/kernel.bbclass
> >> +++ b/meta/classes/kernel.bbclass
> >> @@ -4,7 +4,8 @@ KERNEL_PACKAGE_NAME ??= "kernel"
> >>   KERNEL_DEPLOYSUBDIR ??= "${@ "" if (d.getVar("KERNEL_PACKAGE_NAME")
> == "kernel") else
> >> d.getVar("KERNEL_PACKAGE_NAME") }"
> >>
> >>   PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME")
> == "kernel") else "" }"
> >> -DEPENDS += "virtual/${TARGET_PREFIX}binutils
> virtual/${TARGET_PREFIX}gcc kmod-native bc-native
> >> lzop-native bison-native"
> >> +DEPENDS += "virtual/${TARGET_PREFIX}binutils
> virtual/${TARGET_PREFIX}gcc kmod-native bc-native
> >> bison-native"
> >> +DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo",
> "lzop-native", "", d)}"
> >>   DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lz4",
> "lz4-native", "", d)}"
> >>   PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
> >>
> >>
> >
> >
> > 
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140612): 
https://lists.openembedded.org/g/openembedded-core/message/140612
Mute This Topic: https://lists.openembedded.org/mt/75477721/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] [RFC PATCH] devtool: remove _PYTHON_SYSCONFIGDATA_NAME to fix do_unpack

[Alexander Kanavin]

On Tue, 14 Jul 2020 at 03:47, Taras Kondratiuk (takondra) <
takon...@cisco.com> wrote:

> 2. If a recipe needs python3-native only, then it inherits
> python3native which exports _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata.
> This doesn't work, because python3-native will fail to
> find _sysconfigdata.py in recipe-sysroot (because there is no python3
> in DEPENDS). As a workaround several recipes started to unset
> _PYTHON_SYSCONFIGDATA_NAME (glib [1], mesa [2], scons class [3]).
>

This is not the case. There are plenty of recipes which inherit
python3native, and do not need to unset anything.
The reason glib or mesa have to do it is that they use meson build system
to find the python3 binary (only to run
some scripts; target configuration is not used), and meson always probes
into target config, even when that config is
simply thrown away. Adding target python3 to DEPENDS is undesirable as that
will lengthen the build dependency chain
without any actual need for the target python3.

Chris' approach [6] would address case #3, but not #2. I'm not sure yet
> what is the best way to address #2. Maybe export
> _PYTHON_SYSCONFIGDATA_NAME only if DEPENDS has python3?
>

I am not sure either. I do not have a clear idea how to sort this mess.
Maybe we should talk to python upstream and ask
how cross-compilation is supposed to work.

Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140611): 
https://lists.openembedded.org/g/openembedded-core/message/140611
Mute This Topic: https://lists.openembedded.org/mt/75425436/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for [zeus] nss: Fix CVE-2020-12399

[Patchwork]

== Series Details ==

Series: [zeus] nss: Fix CVE-2020-12399
Revision: 1
URL   : https://patchwork.openembedded.org/series/25124/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[zeus,1/1] nss: Fix CVE-2020-12399
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140610): 
https://lists.openembedded.org/g/openembedded-core/message/140610
Mute This Topic: https://lists.openembedded.org/mt/75494752/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [zeus][PATCH 1/1] nss: Fix CVE-2020-12399

[Ovidiu Panait]

Master (nss version 3.54) is not affected by this issue. This is a backport
from nss version 3.54.

NSS has shown timing differences when performing DSA signatures, which was
exploitable and could eventually leak private keys. This vulnerability affects
Thunderbird < 68.9.0, Firefox < 77, and Firefox ESR < 68.9.

Upstream patch:
https://hg.mozilla.org/projects/nss/rev/daa823a4a29bcef0fec33a379ec83857429aea2e

Signed-off-by: Ovidiu Panait 
---
 ...e-a-fixed-length-for-DSA-exponentiat.patch | 110 ++
 meta/recipes-support/nss/nss_3.45.bb  |   1 +
 2 files changed, 111 insertions(+)
 create mode 100644 
meta/recipes-support/nss/nss/0001-Bug-1631576-Force-a-fixed-length-for-DSA-exponentiat.patch

diff --git 
a/meta/recipes-support/nss/nss/0001-Bug-1631576-Force-a-fixed-length-for-DSA-exponentiat.patch
 
b/meta/recipes-support/nss/nss/0001-Bug-1631576-Force-a-fixed-length-for-DSA-exponentiat.patch
new file mode 100644
index 00..517c277ae0
--- /dev/null
+++ 
b/meta/recipes-support/nss/nss/0001-Bug-1631576-Force-a-fixed-length-for-DSA-exponentiat.patch
@@ -0,0 +1,110 @@
+From 5942c26888ba12ad5e0d92fb62f23d7cde6dc159 Mon Sep 17 00:00:00 2001
+From: Ovidiu Panait 
+Date: Mon, 13 Jul 2020 06:25:56 +
+Subject: [PATCH] Bug 1631576 - Force a fixed length for DSA exponentiation
+ r=pereida,bbrumley
+
+Differential Revision: https://phabricator.services.mozilla.com/D72011
+
+Upstream-Status: Backport 
[https://hg.mozilla.org/projects/nss/rev/daa823a4a29bcef0fec33a379ec83857429aea2e]
+
+Authored-by: Robert Relyea 
+Signed-off-by: Ovidiu Panait 
+---
+ nss/lib/freebl/dsa.c | 45 ++--
+ 1 file changed, 35 insertions(+), 10 deletions(-)
+
+diff --git a/nss/lib/freebl/dsa.c b/nss/lib/freebl/dsa.c
+index aef3539..389c9de 100644
+--- a/nss/lib/freebl/dsa.c
 b/nss/lib/freebl/dsa.c
+@@ -313,13 +313,14 @@ DSA_NewKeyFromSeed(const PQGParams *params,
+ 
+ static SECStatus
+ dsa_SignDigest(DSAPrivateKey *key, SECItem *signature, const SECItem *digest,
+-   const unsigned char *kb)
++   const unsigned char *kbytes)
+ {
+ mp_int p, q, g; /* PQG parameters */
+ mp_int x, k;/* private key & pseudo-random integer */
+ mp_int r, s;/* tuple (r, s) is signature) */
+ mp_int t;   /* holding tmp values */
+ mp_int ar;  /* holding blinding values */
++mp_digit fuzz;  /* blinding multiplier for q */
+ mp_err err = MP_OKAY;
+ SECStatus rv = SECSuccess;
+ unsigned int dsa_subprime_len, dsa_signature_len, offset;
+@@ -373,6 +374,7 @@ dsa_SignDigest(DSAPrivateKey *key, SECItem *signature, 
const SECItem *digest,
+ CHECK_MPI_OK(mp_init());
+ CHECK_MPI_OK(mp_init());
+ CHECK_MPI_OK(mp_init());
++
+ /*
+ ** Convert stored PQG and private key into MPI integers.
+ */
+@@ -380,14 +382,28 @@ dsa_SignDigest(DSAPrivateKey *key, SECItem *signature, 
const SECItem *digest,
+ SECITEM_TO_MPINT(key->params.subPrime, );
+ SECITEM_TO_MPINT(key->params.base, );
+ SECITEM_TO_MPINT(key->privateValue, );
+-OCTETS_TO_MPINT(kb, , dsa_subprime_len);
++OCTETS_TO_MPINT(kbytes, , dsa_subprime_len);
++
++/* k blinding  create a single value that has the high bit set in
++ * the mp_digit*/
++if (RNG_GenerateGlobalRandomBytes(, sizeof(mp_digit)) != SECSuccess) 
{
++PORT_SetError(SEC_ERROR_NEED_RANDOM);
++rv = SECFailure;
++goto cleanup;
++}
++fuzz |= 1ULL << ((sizeof(mp_digit) * PR_BITS_PER_BYTE - 1));
+ /*
+ ** FIPS 186-1, Section 5, Step 1
+ **
+ ** r = (g**k mod p) mod q
+ */
+-CHECK_MPI_OK(mp_exptmod(, , , )); /* r = g**k mod p */
+-CHECK_MPI_OK(mp_mod(, , )); /* r = r mod q*/
++CHECK_MPI_OK(mp_mul_d(, fuzz, )); /* t = q*fuzz */
++CHECK_MPI_OK(mp_add(, , )); /* t = k+q*fuzz */
++/* length of t is now fixed, bits in k have been blinded */
++CHECK_MPI_OK(mp_exptmod(, , , )); /* r = g**t mod p */
++/* r is now g**(k+q*fuzz) == g**k mod p */
++CHECK_MPI_OK(mp_mod(, , )); /* r = r mod q*/
++
+ /*
+ ** FIPS 186-1, Section 5, Step 2
+ **
+@@ -411,15 +427,24 @@ dsa_SignDigest(DSAPrivateKey *key, SECItem *signature, 
const SECItem *digest,
+ /* Using mp_invmod on k directly would leak bits from k. */
+ CHECK_MPI_OK(mp_mul(, , ));   /* k = k * ar */
+ CHECK_MPI_OK(mp_mulmod(, , , )); /* k = k * t mod q */
+-CHECK_MPI_OK(mp_invmod(, , )); /* k = k**-1 mod q */
++/* k is now k*t*ar */
++CHECK_MPI_OK(mp_invmod(, , )); /* k = k**-1 mod q */
++/* k is now (k*t*ar)**-1 */
+ CHECK_MPI_OK(mp_mulmod(, , , )); /* k = k * t mod q */
+-SECITEM_TO_MPINT(localDigest, );   /* s = HASH(M) */
++/* k is now (k*ar)**-1 */
++SECITEM_TO_MPINT(localDigest, ); /* s = HASH(M) */
+ /* To avoid leaking secret bits here the addition is blinded. */
+-CHECK_MPI_OK(mp_mul(, , ));/* x = x * ar */
+-

Re: [OE-core] [PATCH v4 01/12] Move rpm manifest to its own subdir

[Fredrik Gustafsson]

Thank you, just let me know if I can make it any easier to review this,
I know it's a big patch.

BR
Fredrik

From: Paul Barker 
Sent: Thursday, July 9, 2020 6:19 PM
To: Fredrik Gustafsson
Cc: openembedded-core@lists.openembedded.org; tools-cfpbuild-internal; Richard 
Purdie
Subject: Re: [PATCH v4 01/12] Move rpm manifest to its own subdir

On Thu, 9 Jul 2020 at 11:42, Fredrik Gustafsson
 wrote:
>
> Hi,
> is there something I can do to make this series move forward?
>

I guess it's waiting for at least one person to review it in detail.
It's in my backlog, I should get to it on Monday.

--
Paul Barker
Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140608): 
https://lists.openembedded.org/g/openembedded-core/message/140608
Mute This Topic: https://lists.openembedded.org/mt/75277396/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-