Re: [OE-core] [PATCH] stress-ng: Do not enforce gold linker

2023-01-02 Thread Alexander Kanavin 
Can this be made a patch and submitted upstream? Patching like that
with sed is prone to silent regressions.

Alex

On Tue, 3 Jan 2023 at 08:31, Khem Raj  wrote:
>
> This can then be controlled by yocto environment through LDFLAGS if
> needed since we support multiple linkers and distro policy may want a
> different linker, moreover gold fails on ppc32 to link since its missing
>
> Fixes errors like below on ppc/gold + clang
>
> /usr/lib/clang/15.0.6/lib/linux/libclang_rt.builtins-powerpc.a(mulsc3.c.o): 
> unsupported -mbss-plt code
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb 
> b/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb
> index 38fd6698b3..72893e7893 100644
> --- a/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb
> +++ b/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb
> @@ -23,6 +23,8 @@ EXTRA_OEMAKE = "VERBOSE=1"
>  do_configure() {
>  mkdir -p configs
>  touch configs/HAVE_APPARMOR
> +# Disable forcing gold linker
> +sed -i -e '/LD_GOLD/{N;d;}' ${S}/Makefile.config
>  oe_runmake makeconfig
>  }
>
> --
> 2.39.0
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175336): 
https://lists.openembedded.org/g/openembedded-core/message/175336
Mute This Topic: https://lists.openembedded.org/mt/96024589/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 2/2] default-distrovars: Include "c" in IMAGE_LINGUAS for glibc

2023-01-02 Thread Alex Kiernan 
On Mon, Jan 2, 2023 at 11:03 PM Richard Purdie
 wrote:
>
> On Mon, 2023-01-02 at 22:47 +, Alex Kiernan wrote:
> > glibc 2.35 introduced C.UTF-8, we should include this by default.
> >
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> >  meta/conf/distro/include/default-distrovars.inc | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/conf/distro/include/default-distrovars.inc 
> > b/meta/conf/distro/include/default-distrovars.inc
> > index abf48f79f08a..5324bd543d22 100644
> > --- a/meta/conf/distro/include/default-distrovars.inc
> > +++ b/meta/conf/distro/include/default-distrovars.inc
> > @@ -5,6 +5,8 @@ KERNEL_CONSOLE ?= "ttyS0"
> >  KEEPUIMAGE ??= "yes"
> >
> >  IMAGE_LINGUAS ?= "en-us en-gb"
> > +IMAGE_LINGUAS:libc-glibc ?= "c en-us en-gb"
> > +
> >  ENABLE_BINARY_LOCALE_GENERATION ?= "1"
> >  LOCALE_UTF8_ONLY ?= "0"
> >  LOCALE_UTF8_IS_DEFAULT ?= "1"
>
> I suspect this will catch people out since if someone does:
>
> IMAGE_LINGUAS = "xxx"
>
> then it won't work for glibc due to the override. I suspect what we
> need will be more like:
>
> DEFAULT_IMAGE_LINGUAS = "en-us en-gb"
> DEFAULT_IMAGE_LINGUAS:libc-glibc = "c en-us en-gb"
> IMAGE_LINGUAS ?= "${DEFAULT_IMAGE_LINGUAS}"
>
> ?

I was slightly surprised when it did appear to work,expecting the
override to win - but I guess that's possibly because I've set it in
local.conf and not an image recipe:

#
# $IMAGE_LINGUAS [4 operations]
#   set /home/alexk/poky/build/conf/local.conf:303
# ""
#   set? /home/alexk/poky/meta/conf/distro/include/default-distrovars.inc:7
# "en-us en-gb"
#   set /home/alexk/poky/meta/conf/documentation.conf:218
# [doc] "Specifies the list of locales to install into the image
during the root filesystem construction process."
#   override[libc-glibc]:set?
/home/alexk/poky/meta/conf/distro/include/default-distrovars.inc:8
# "c en-us en-gb"
# pre-expansion value:
#   ""
IMAGE_LINGUAS=""

But the DEFAULT_IMAGE_LINGUAS is much more obvious and for some reason
simply didn't occur when I wrote this! I'll send a v2.

-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175335): 
https://lists.openembedded.org/g/openembedded-core/message/175335
Mute This Topic: https://lists.openembedded.org/mt/96018045/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] stress-ng: Do not enforce gold linker

2023-01-02 Thread Khem Raj 
This can then be controlled by yocto environment through LDFLAGS if
needed since we support multiple linkers and distro policy may want a
different linker, moreover gold fails on ppc32 to link since its missing

Fixes errors like below on ppc/gold + clang

/usr/lib/clang/15.0.6/lib/linux/libclang_rt.builtins-powerpc.a(mulsc3.c.o): 
unsupported -mbss-plt code

Signed-off-by: Khem Raj 
---
 meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb 
b/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb
index 38fd6698b3..72893e7893 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.15.01.bb
@@ -23,6 +23,8 @@ EXTRA_OEMAKE = "VERBOSE=1"
 do_configure() {
 mkdir -p configs
 touch configs/HAVE_APPARMOR
+# Disable forcing gold linker
+sed -i -e '/LD_GOLD/{N;d;}' ${S}/Makefile.config
 oe_runmake makeconfig
 }
 
-- 
2.39.0


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

[OE-core] NVD data format change and cve-check migration

2023-01-02 Thread Marta Rybczynska 
Hello all,
NVD (which we use for the cve-check database) has been working on the new
format for some time. What I understand is that they plan to retire old API
and all the feeds (like the one we use) by september 2023. Has anyone
started working on migration of the cve-check to this new format?

The current timeline: https://nvd.nist.gov/general/news/change-timeline

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175333): 
https://lists.openembedded.org/g/openembedded-core/message/175333
Mute This Topic: https://lists.openembedded.org/mt/96024052/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] librepo: upgrade 1.14.5 -> 1.15.1

2023-01-02 Thread wangmy 
From: Wang Mingyu 

Changelog:
===
 Adds API support for waiting on network in an event driven manner (new API 
function lr_handle_network_wait)
 OpenPGP API extension and fixes (new API functions lr_gpg_*)
 Update license format to "LGPL-2.1-or-later"

Signed-off-by: Wang Mingyu 
---
 .../librepo/{librepo_1.14.5.bb => librepo_1.15.1.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/librepo/{librepo_1.14.5.bb => librepo_1.15.1.bb} 
(94%)

diff --git a/meta/recipes-devtools/librepo/librepo_1.14.5.bb 
b/meta/recipes-devtools/librepo/librepo_1.15.1.bb
similarity index 94%
rename from meta/recipes-devtools/librepo/librepo_1.14.5.bb
rename to meta/recipes-devtools/librepo/librepo_1.15.1.bb
index 46cfce53ff..2c8d6fc719 100644
--- a/meta/recipes-devtools/librepo/librepo_1.14.5.bb
+++ b/meta/recipes-devtools/librepo/librepo_1.15.1.bb
@@ -10,7 +10,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/librepo.git;branch=master;pr

file://0004-Set-gpgme-variables-with-pkg-config-not-with-cmake-m.patch \
"
 
-SRCREV = "f4b915be5e04e88263097f65addfcac5919fef41"
+SRCREV = "5f4de4a4e85845d4184fbd30c03ff8a8ec7df4af"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175332): 
https://lists.openembedded.org/g/openembedded-core/message/175332
Mute This Topic: https://lists.openembedded.org/mt/96022566/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] btrfs-tools: upgrade 6.0.2 -> 6.1

2023-01-02 Thread wangmy 
From: Wang Mingyu 

Changelog:
==
* filesystem df: add json output
* qgroup show: add json output
* new command: 'inspect-internal map-swapfile' to check swapfile and its
  swapfile_offset value used for hibernation
* corrupt-block: fix parsing of option --root argument
* experimental (interfaces not finalized):
   * new command 'inspect-internal list-chunks'
   * new group reflink, command clone
* other:
   * synchronize some files with kernel versions
   * docs updates
   * build: use gnu11

Signed-off-by: Wang Mingyu 
---
 .../btrfs-tools/{btrfs-tools_6.0.2.bb => btrfs-tools_6.1.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/btrfs-tools/{btrfs-tools_6.0.2.bb => 
btrfs-tools_6.1.bb} (98%)

diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.0.2.bb 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.1.bb
similarity index 98%
rename from meta/recipes-devtools/btrfs-tools/btrfs-tools_6.0.2.bb
rename to meta/recipes-devtools/btrfs-tools/btrfs-tools_6.1.bb
index aa48422080..44ec2e1f16 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.0.2.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_6.1.bb
@@ -19,7 +19,7 @@ SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git;b

file://0001-Add-a-possibility-to-specify-where-python-modules-ar.patch \

file://0001-Use-pread-pwrite-ftruncate-stat-instead-of-64bit-equ.patch \
"
-SRCREV = "ff964ba6aef98bd1bafe8ff9b0088501b30bdd27"
+SRCREV = "cde5faa6787e6fa720c99d2f10caa187a493c13f"
 S = "${WORKDIR}/git"
 
 PACKAGECONFIG ??= " \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175331): 
https://lists.openembedded.org/g/openembedded-core/message/175331
Mute This Topic: https://lists.openembedded.org/mt/96022565/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 2/2] default-distrovars: Include "c" in IMAGE_LINGUAS for glibc

2023-01-02 Thread Richard Purdie 
On Mon, 2023-01-02 at 22:47 +, Alex Kiernan wrote:
> glibc 2.35 introduced C.UTF-8, we should include this by default.
> 
> Signed-off-by: Alex Kiernan 
> ---
> 
>  meta/conf/distro/include/default-distrovars.inc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/conf/distro/include/default-distrovars.inc 
> b/meta/conf/distro/include/default-distrovars.inc
> index abf48f79f08a..5324bd543d22 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -5,6 +5,8 @@ KERNEL_CONSOLE ?= "ttyS0"
>  KEEPUIMAGE ??= "yes"
>  
>  IMAGE_LINGUAS ?= "en-us en-gb"
> +IMAGE_LINGUAS:libc-glibc ?= "c en-us en-gb"
> +
>  ENABLE_BINARY_LOCALE_GENERATION ?= "1"
>  LOCALE_UTF8_ONLY ?= "0"
>  LOCALE_UTF8_IS_DEFAULT ?= "1"

I suspect this will catch people out since if someone does:

IMAGE_LINGUAS = "xxx"

then it won't work for glibc due to the override. I suspect what we
need will be more like:

DEFAULT_IMAGE_LINGUAS = "en-us en-gb"
DEFAULT_IMAGE_LINGUAS:libc-glibc = "c en-us en-gb"
IMAGE_LINGUAS ?= "${DEFAULT_IMAGE_LINGUAS}"

?

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175330): 
https://lists.openembedded.org/g/openembedded-core/message/175330
Mute This Topic: https://lists.openembedded.org/mt/96018045/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] default-distrovars: Include "c" in IMAGE_LINGUAS for glibc

2023-01-02 Thread Alex Kiernan 
glibc 2.35 introduced C.UTF-8, we should include this by default.

Signed-off-by: Alex Kiernan 
---

 meta/conf/distro/include/default-distrovars.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index abf48f79f08a..5324bd543d22 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -5,6 +5,8 @@ KERNEL_CONSOLE ?= "ttyS0"
 KEEPUIMAGE ??= "yes"
 
 IMAGE_LINGUAS ?= "en-us en-gb"
+IMAGE_LINGUAS:libc-glibc ?= "c en-us en-gb"
+
 ENABLE_BINARY_LOCALE_GENERATION ?= "1"
 LOCALE_UTF8_ONLY ?= "0"
 LOCALE_UTF8_IS_DEFAULT ?= "1"
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175329): 
https://lists.openembedded.org/g/openembedded-core/message/175329
Mute This Topic: https://lists.openembedded.org/mt/96018045/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] classes: image: Set empty weak default IMAGE_LINGUAS

2023-01-02 Thread Alex Kiernan 
This is already set in default-distrovars.inc and so this assignment
will almost never succeed. Rather than leaving it to confuse, set an
empty weak default.

Signed-off-by: Alex Kiernan 
---

 meta/classes-recipe/image.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes-recipe/image.bbclass 
b/meta/classes-recipe/image.bbclass
index e387645503ad..d4bf02784ab0 100644
--- a/meta/classes-recipe/image.bbclass
+++ b/meta/classes-recipe/image.bbclass
@@ -182,8 +182,7 @@ python () {
 
 IMAGE_POSTPROCESS_COMMAND ?= ""
 
-# some default locales
-IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
+IMAGE_LINGUAS ??= ""
 
 LINGUAS_INSTALL ?= "${@" ".join(map(lambda s: "locale-base-%s" % s, 
d.getVar('IMAGE_LINGUAS').split()))}"
 
-- 
2.39.0


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

[OE-core] Current high bug count owners for Yocto Project 4.2

2023-01-02 Thread Stephen Jolley 
All,

Below is the list as of top 31 bug owners as of the end of WW01 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 79
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

35


ross.bur...@arm.com

30


bruce.ashfi...@gmail.com

25


randy.macl...@windriver.com

25


david.re...@windriver.com

23


richard.pur...@linuxfoundation.org

23


jpewhac...@gmail.com

10


saul.w...@windriver.com

9


sakib.sa...@windriver.com

8


pa...@zhukoff.net

5


zheng@windriver.com

4


tim.orl...@konsulko.com

4


alexandre.bell...@bootlin.com

4


naveen.go...@windriver.com

2


s...@bigsur.com

2


jon.ma...@arm.com

2


hongxu@windriver.com

2


sundeep.kokko...@windriver.com

2


akuster...@gmail.com

2


bluelightn...@bluelightning.org

2


sundeep.kokko...@gmail.com

2


yashinde...@gmail.com

1


anton.anto...@arm.com

1


b...@pengutronix.de

1


tvgamb...@gmail.com

1


martin.bee...@online.de

1


martin.ja...@gmail.com

1


mathew.pro...@gmail.com

1


aeh...@gmail.com

1


thomas.per...@bootlin.com

1


mhalst...@linuxfoundation.org

1


Grand Total

231

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 (#175327): 
https://lists.openembedded.org/g/openembedded-core/message/175327
Mute This Topic: https://lists.openembedded.org/mt/96016768/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2023-01-02 Thread Stephen Jolley 
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 419
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "4.2", "4.3", "4.99" and "Future", the more pressing/urgent
issues being in "4.2" and then "4.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

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 (#175326): 
https://lists.openembedded.org/g/openembedded-core/message/175326
Mute This Topic: https://lists.openembedded.org/mt/96016746/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] rust: Fix build with 64bit time_t

2023-01-02 Thread Khem Raj 
The vendored copy of zlib undefines _FILE_OFFSET_BITS when
_LARGEFILE64_SOURCE is defined and enabling 64bit time_t requires 64bit
off_t ( _FILE_OFFSET_BITS=64 ), therefore remove this from the
zlib module

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/rust/rust-source.inc|  1 +
 .../rust/rust/zlib-off64_t.patch  | 31 +++
 2 files changed, 32 insertions(+)
 create mode 100644 meta/recipes-devtools/rust/rust/zlib-off64_t.patch

diff --git a/meta/recipes-devtools/rust/rust-source.inc 
b/meta/recipes-devtools/rust/rust-source.inc
index 643494b37e..bfb625fb36 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -9,6 +9,7 @@ SRC_URI:append:class-target:pn-libstd-rs = "\
 SRC_URI:append:class-target:pn-rust = " \
 file://getrandom-open64.patch \
 file://0001-Do-not-use-LFS64-on-linux-with-musl.patch \
+file://zlib-off64_t.patch \
 file://hardcodepaths.patch \
 file://crossbeam_atomic.patch"
 SRC_URI:append:class-nativesdk:pn-nativesdk-rust = " 
file://hardcodepaths.patch"
diff --git a/meta/recipes-devtools/rust/rust/zlib-off64_t.patch 
b/meta/recipes-devtools/rust/rust/zlib-off64_t.patch
new file mode 100644
index 00..78c8a2a1fb
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust/zlib-off64_t.patch
@@ -0,0 +1,31 @@
+Do not undefine _FILE_OFFSET_BITS when
+_LARGEFILE64_SOURCE is defined. This ends up
+causing 64bit time_t to fail the build because
+it needs 64 bit off_t
+
+Upstream-Status: Submitted [https://github.com/madler/zlib/pull/764]
+Signed-off-by: Khem Raj 
+--- a/vendor/libz-sys/src/zlib/gzguts.h
 b/vendor/libz-sys/src/zlib/gzguts.h
+@@ -3,15 +3,6 @@
+  * For conditions of distribution and use, see copyright notice in zlib.h
+  */
+ 
+-#ifdef _LARGEFILE64_SOURCE
+-#  ifndef _LARGEFILE_SOURCE
+-#define _LARGEFILE_SOURCE 1
+-#  endif
+-#  ifdef _FILE_OFFSET_BITS
+-#undef _FILE_OFFSET_BITS
+-#  endif
+-#endif
+-
+ #ifdef HAVE_HIDDEN
+ #  define ZLIB_INTERNAL __attribute__((visibility ("hidden")))
+ #else
+--- a/vendor/libz-sys/.cargo-checksum.json
 b/vendor/libz-sys/.cargo-checksum.json
+@@ -1 +1 @@

[OE-core] [PATCH 1/2] time64.conf: Add GLIBC_64BIT_TIME_FLAGS on ppc/x86 as well

2023-01-02 Thread Khem Raj 
Make mips expression across all 32bit mips architectures

Signed-off-by: Khem Raj 
---
 meta/conf/distro/include/time64.inc | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/time64.inc 
b/meta/conf/distro/include/time64.inc
index c6a3b682c2..5c53356d4f 100644
--- a/meta/conf/distro/include/time64.inc
+++ b/meta/conf/distro/include/time64.inc
@@ -1,9 +1,12 @@
 GLIBC_64BIT_TIME_FLAGS = "-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
 
-# TODO: Only for 32-bit architectures?
+# Only needed for some 32-bit architectures, some relatively newer
+# architectures do not need it ( e.g. riscv32 )
 TARGET_CC_ARCH:append:arm = " ${GLIBC_64BIT_TIME_FLAGS}"
 TARGET_CC_ARCH:append:armeb = " ${GLIBC_64BIT_TIME_FLAGS}"
-TARGET_CC_ARCH:append:mips32el = " ${GLIBC_64BIT_TIME_FLAGS}"
+TARGET_CC_ARCH:append:mipsarcho32 = " ${GLIBC_64BIT_TIME_FLAGS}"
+TARGET_CC_ARCH:append:powerpc = " ${@bb.utils.contains('TUNE_FEATURES', 'm32', 
'${GLIBC_64BIT_TIME_FLAGS}', '', d)}"
+TARGET_CC_ARCH:append:x86 = " ${@bb.utils.contains('TUNE_FEATURES', 'm32', 
'${GLIBC_64BIT_TIME_FLAGS}', '', d)}"
 
 GLIBC_64BIT_TIME_FLAGS:pn-glibc = ""
 GLIBC_64BIT_TIME_FLAGS:pn-glibc-tests = ""
@@ -23,4 +26,3 @@ INSANE_SKIP:librsvg[_usr_lib_librsvg-2.so.2.48.0] = "fcntl 
lstat64 setsockopt se
 # libpulsedsp.so is a preload-library that hooks libc functions
 INSANE_SKIP:pulseaudio[_usr_lib_pulseaudio_libpulsedsp.so] = "setsockopt fcntl"
 
-
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175324): 
https://lists.openembedded.org/g/openembedded-core/message/175324
Mute This Topic: https://lists.openembedded.org/mt/96013278/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] C.UTF-8 in glibc

2023-01-02 Thread Alex Kiernan 
On Mon, Jan 2, 2023 at 4:28 PM Richard Purdie
 wrote:
>
> On Sun, 2023-01-01 at 18:32 +, Alex Kiernan wrote:
> > glibc got an official C.UTF-8 in 2.35, but we don't appear to install
> > it by default... if I add "c" to IMAGE_LINGUAS then it gets installed,
> > but it feels like this ought to be default? Or even stronger and have
> > it separate from IMAGE_LINGUAS so even if that's set to "" you still
> > get it?
> >
> > I tripped over it because I was trying to get the ostree ptest suite
> > to pass and it ended up with a time formatting failing a test because
> > it wasn't running in C.UTF-8.
>
> Making it even stronger might be tricky given how our variables work
> but we definitely should have that in the default locales list.
>

My original thinking on trying to make it stronger was I expect you
really want this, but given everyone's managed so far without, I guess
if they need it now they can add it back in if they're overriding
IMAGE_LINGUAS.

Just thinking about this more, we can't specify it for musl, the
obvious way would be a glibc specific append, which would then mean
that setting IMAGE_LINGUAS = "" you still get it, which doesn't
immediately feel right (plus the general wish to avoid append in
core), which I guess means it needs something with more trickery...
I'll go play.

-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175323): 
https://lists.openembedded.org/g/openembedded-core/message/175323
Mute This Topic: https://lists.openembedded.org/mt/95993257/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 2/2] cve-update-db-native: avoid partial updates

2023-01-02 Thread Marta Rybczynska 
On Mon, Jan 2, 2023 at 2:14 PM Jose Quaresma 
wrote:

> Hi Marta,
>
> Marta Rybczynska  escreveu no dia segunda,
> 2/01/2023 à(s) 07:03:
>
>> The database update has been done on the original file. In case of
>> network connection issues, temporary outage of the NVD server or
>> a similar situation, the function could exit with incomplete data
>> in the database. This patch solves the issue by performing the update
>> on a copy of the database. It replaces the main one only if the whole
>> update was successful.
>>
>> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929
>>
>> Reported-by: Alberto Pianon 
>> Signed-off-by: Marta Rybczynska 
>> ---
>>  .../recipes-core/meta/cve-update-db-native.bb | 81 +--
>>  1 file changed, 56 insertions(+), 25 deletions(-)
>>
>> diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
>> b/meta/recipes-core/meta/cve-update-db-native.bb
>> index 642fda5395..89804b9e5c 100644
>> --- a/meta/recipes-core/meta/cve-update-db-native.bb
>> +++ b/meta/recipes-core/meta/cve-update-db-native.bb
>> @@ -21,6 +21,8 @@ CVE_DB_UPDATE_INTERVAL ?= "86400"
>>  # Timeout for blocking socket operations, such as the connection attempt.
>>  CVE_SOCKET_TIMEOUT ?= "60"
>>
>> +CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
>> +
>>  python () {
>>  if not bb.data.inherits_class("cve-check", d):
>>  raise bb.parse.SkipRecipe("Skip recipe when cve-check class is
>> not loaded.")
>> @@ -32,19 +34,15 @@ python do_fetch() {
>>  """
>>  import bb.utils
>>  import bb.progress
>> -import sqlite3, urllib, urllib.parse, gzip
>> -from datetime import date
>> +import shutil
>>
>>  bb.utils.export_proxies(d)
>>
>> -YEAR_START = 2002
>> -
>>  db_file = d.getVar("CVE_CHECK_DB_FILE")
>>  db_dir = os.path.dirname(db_file)
>> +db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
>>
>> -cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
>> -
>> -cleanup_db_download(db_file)
>> +cleanup_db_download(db_file, db_tmp_file)
>>
>>  # The NVD database changes once a day, so no need to update more
>> frequently
>>  # Allow the user to force-update
>> @@ -62,9 +60,55 @@ python do_fetch() {
>>  pass
>>
>>  bb.utils.mkdirhier(db_dir)
>> +if os.path.exists(db_file):
>> +shutil.copy2(db_file, db_tmp_file)
>> +
>> +if update_db_file(db_tmp_file, d) == True:
>> +# Update downloaded correctly, can swap files
>> +shutil.move(db_tmp_file, db_file)
>> +else:
>> +# Update failed, do not modify the database
>> +bb.note("CVE database update failed")
>> +os.remove(db_tmp_file)
>> +}
>> +
>> +do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
>> +do_fetch[file-checksums] = ""
>> +do_fetch[vardeps] = ""
>> +
>> +def cleanup_db_download(db_file, db_tmp_file):
>> +"""
>> +Cleanup the download space from possible failed downloads
>> +"""
>> +if os.path.exists("{0}-journal".format(db_file)):
>> +# If a journal is present the last update might have been
>> interrupted. In that case,
>> +# just wipe any leftovers and force the DB to be recreated.
>> +os.remove("{0}-journal".format(db_file))
>> +
>> +if os.path.exists(db_file):
>> +os.remove(db_file)
>> +
>> +if os.path.exists("{0}-journal".format(db_tmp_file)):
>> +# If a journal is present the last update might have been
>> interrupted. In that case,
>> +# just wipe any leftovers and force the DB to be recreated.
>> +os.remove("{0}-journal".format(db_tmp_file))
>> +
>> +if os.path.exists(db_tmp_file):
>> +os.remove(db_tmp_file)
>> +
>>
>
> It seems to me that this function is a duplication of the old version with
> an extra argument.
> So I think that using the old function version and call it with the proper
> argument does the same:
>
> cleanup_db_download(db_file)
> cleanup_db_download(db_tmp_file)
>
>
Hi Jose,
Thanks for looking into that. The function is not a total duplicate: the
difference is that
the it always removes the db_tmp_file, not only if the journal file exists
(Python code
formatting!).

I was hesitating on this part a bit, because with the old path could be
taken only in some
specific situations: at the code update and if you share the DL_DIR and
some of the builds
use the old code, some the new version. I think we should keep both for now
for safety.

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175322): 
https://lists.openembedded.org/g/openembedded-core/message/175322
Mute This Topic: https://lists.openembedded.org/mt/96002809/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] C.UTF-8 in glibc

2023-01-02 Thread Richard Purdie 
On Sun, 2023-01-01 at 18:32 +, Alex Kiernan wrote:
> glibc got an official C.UTF-8 in 2.35, but we don't appear to install
> it by default... if I add "c" to IMAGE_LINGUAS then it gets installed,
> but it feels like this ought to be default? Or even stronger and have
> it separate from IMAGE_LINGUAS so even if that's set to "" you still
> get it?
> 
> I tripped over it because I was trying to get the ostree ptest suite
> to pass and it ended up with a time formatting failing a test because
> it wasn't running in C.UTF-8.

Making it even stronger might be tricky given how our variables work
but we definitely should have that in the default locales list.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175321): 
https://lists.openembedded.org/g/openembedded-core/message/175321
Mute This Topic: https://lists.openembedded.org/mt/95993257/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] Toaster: where are variable descriptions used?

2023-01-02 Thread Richard Purdie 
On Mon, 2023-01-02 at 17:12 +0100, Michael Opdenacker via
lists.openembedded.org wrote:
> Hello,
> 
> I'm checking for Bitbake variables which should be documented in 
> meta/conf/documentation.conf, but before that, I'd like to check how 
> such information is used.
> 
> In the "Bitbake variables" section, I can see help information about 
> some variables, as in the attached screenshot.
> 
> However, if I add a new variable such as "NO_RECOMMENDATIONS", no help 
> information is provided about it, even though it is described in 
> meta/conf/documentation.conf.
> 
> It also turns out that the help information I get on this section comes 
> from bitbake/lib/toaster/toastergui/templates/projectconf.html instead.
> 
> So, where are variable descriptions in meta/conf/documentation.conf 
> actually used?

I have a suspicion that the html may be generated by a script from
documentation.conf but I don't really remember. Adding David Reyna to
cc in case he knows.

Cheers,

Richard

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

[OE-core] Struggling to get QEMU sound working on core-image-base

2023-01-02 Thread Mark Jonas 
Hi,

I have difficulties getting core-image-base and QEMU x86-64 sound
output working. I do not even get to the point of having a visible
ALSA sound device.

What part of the puzzle am I missing?

Alternatively, can someone point me to a (simple) YP image where sound
works with QEMU x86 or x86-64?

I built a core-image-base image from latest YP Poky [dunfell,langdale]
with the following additions in a default local.conf:

MACHINE = "qemux86-64"

# Load kernel modules matching QEMU audio support
KERNEL_MODULE_AUTOLOAD += "snd-ens1370"

# Check ALSA cards available
IMAGE_INSTALL:append = " alsa-utils"

EXTRA_IMAGE_FEATURES += "debug-tweaks"

Then I start the core-image-base with "runqemu core-image-base kvm
serial slirp audio nographic".

In the running system I can see that the kernel modules are loaded.

root@qemux86-64:~# uname -a
Linux qemux86-64 5.19.17-yocto-standard #1 SMP PREEMPT_DYNAMIC Fri Nov
18 21:13:18 UTC 2022 x86_64 GNU/Linux

root@qemux86-64:~# lsmod
Module  Size  Used by
bnep   20480  2
snd_ens137028672  0
snd_pcm   102400  1 snd_ens1370
snd_timer  32768  1 snd_pcm
snd_rawmidi28672  1 snd_ens1370
snd_seq_device 16384  1 snd_rawmidi
snd73728  5
snd_seq_device,snd_timer,snd_ens1370,snd_pcm,snd_rawmidi
soundcore  16384  1 snd

But the /proc/asound/cards is empty and aplay does not find soundcards as well.

root@qemux86-64:~# cat /proc/asound/cards
--- no soundcards ---

root@qemux86-64:~# aplay -l
aplay: device_list:275: no soundcards found...

For easy reproduction of the problem I created a KAS yaml file. You
can find it at
https://gitlab.com/toertel/meta-qemusound

Thanks in advance,
Mark

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175318): 
https://lists.openembedded.org/g/openembedded-core/message/175318
Mute This Topic: https://lists.openembedded.org/mt/96009159/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] [langdale][kirkstone][PATCH] go-mod.bbclass: Allow network in do_compile

2023-01-02 Thread Stefan Herbrechtsmeier 

Hi Martin,

Am 26.12.2022 um 10:59 schrieb Martin Jansa via lists.openembedded.org:
On Mon, Dec 26, 2022 at 10:38 AM Vyacheslav Yurkov 
 wrote:


Martin, I did see that patch series, but I was not sure about its
state, therefore I didn't try it. If I understood correctly, that
partially solves the issue, but the proper solution should involve
the fetcher, that's why it's not yet merged to master. Am I
missing something?


That's not my understanding.

The proposed changes for recipetool had some cosmetic and functional 
review comments and it doesn't work correctly for every possible go 
dependency (e.g. the 3 issues I've mentioned from telegram recipe), 
but it's very good starting point and we should be able to get it 
merged in master (and then everybody can more easily contribute fixes 
for the corner cases where it might not work well yet).


Even missing documentation IMHO shouldn't block merging it at this 
point, because there is a clear need this (as there are already 3 
partial implementations to fix this issue, neither 100% complete and 
nothing merged in master - the recipetool changes are IMHO the best of 
3 as it integrates with devtool as well and seems to be most complete).


go fetcher in bitbake is another possibility for future, but 
generating the long deps in SRC_URI is much better solution then 
enabling network in every go-mod recipe.


Does an agreement exist if we should use a package manager class which 
creates a wget fetcher URI (ex. pipi) or a specific fetcher (ex. crate 
and npm)? At the moment both specific fetchers have different URI 
styles, create their specific tar commands and doesn't reuse the wget 
fetcher. Furthermore, the crate fetcher doesn't check the integrity 
during fetch. The fetcher inside bitbake have the advantage that you can 
fetch the latest version (ex. AUTOREV), but it brings the risk of code 
duplication and missing features. If we have an agreement and a common 
style its easy to replace the function with a specific fetcher.


Regards
  Stefan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175317): 
https://lists.openembedded.org/g/openembedded-core/message/175317
Mute This Topic: https://lists.openembedded.org/mt/95827446/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] cairo: fix CVE patches assigned wrong CVE number

2023-01-02 Thread Quentin Schulz 
From: Quentin Schulz 

CVE-2019-6461 and CVE-2019-6462 are fixed, but the reporting is
incorrect as the patch for CVE-2019-6461 is actually for CVE-2019-6462
and vice-versa.

This swaps both files and edit the CVE field to report the correct
identifier.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
Changes in v2:
- Rebased on top of master
- Link to v1: 
https://lore.kernel.org/r/20221214-cairo-cve-typo-v1-1-8ecb1bf8f...@theobroma-systems.com
---
 .../cairo/cairo/CVE-2019-6461.patch| 46 ++
 .../cairo/cairo/CVE-2019-6462.patch| 46 --
 2 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
index 0b7d9a0c36..a2dba6cb20 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6461.patch
@@ -1,40 +1,20 @@
-CVE: CVE-2019-6461
-Upstream-Status: Backport
-Signed-off-by: Quentin Schulz 
-
-From ab2c5ee21e5f3d3ee4b3f67cfcd5811a4f99c3a0 Mon Sep 17 00:00:00 2001
-From: Heiko Lewin 
-Date: Sun, 1 Aug 2021 11:16:03 +
-Subject: [PATCH] _arc_max_angle_for_tolerance_normalized: fix infinite loop
+There is an assertion in function _cairo_arc_in_direction().
 

- src/cairo-arc.c | 4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
+CVE: CVE-2019-6461
+Upstream-Status: Pending
+Signed-off-by: Ross Burton 
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..1c891d1a0 100644
+index 390397bae..1bde774a4 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -90,16 +90,18 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
-   { M_PI / 11.0,  9.81410988043554039085e-09 },
- };
- int table_size = ARRAY_LENGTH (table);
-+const int max_segments = 1000; /* this value is chosen arbitrarily. this 
gives an error of about 1.74909e-20 */
+@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
+ if (cairo_status (cr))
+ return;
  
- for (i = 0; i < table_size; i++)
-   if (table[i].error < tolerance)
-   return table[i].angle;
+-assert (angle_max >= angle_min);
++if (angle_max < angle_min)
++   return;
  
- ++i;
-+
- do {
-   angle = M_PI / i++;
-   error = _arc_error_normalized (angle);
--} while (error > tolerance);
-+} while (error > tolerance && i < max_segments);
- 
- return angle;
- }
--- 
-2.38.1
-
+ if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
+   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
diff --git a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch 
b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
index 4e4598c5b5..7c3209291b 100644
--- a/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
+++ b/meta/recipes-graphics/cairo/cairo/CVE-2019-6462.patch
@@ -1,20 +1,40 @@
-There is an assertion in function _cairo_arc_in_direction().
-
 CVE: CVE-2019-6462
-Upstream-Status: Pending
-Signed-off-by: Ross Burton 
+Upstream-Status: Backport
+Signed-off-by: Quentin Schulz 
+
+From ab2c5ee21e5f3d3ee4b3f67cfcd5811a4f99c3a0 Mon Sep 17 00:00:00 2001
+From: Heiko Lewin 
+Date: Sun, 1 Aug 2021 11:16:03 +
+Subject: [PATCH] _arc_max_angle_for_tolerance_normalized: fix infinite loop
+
+---
+ src/cairo-arc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/cairo-arc.c b/src/cairo-arc.c
-index 390397bae..1bde774a4 100644
+index 390397bae..1c891d1a0 100644
 --- a/src/cairo-arc.c
 +++ b/src/cairo-arc.c
-@@ -186,7 +186,8 @@ _cairo_arc_in_direction (cairo_t *cr,
- if (cairo_status (cr))
- return;
+@@ -90,16 +90,18 @@ _arc_max_angle_for_tolerance_normalized (double tolerance)
+   { M_PI / 11.0,  9.81410988043554039085e-09 },
+ };
+ int table_size = ARRAY_LENGTH (table);
++const int max_segments = 1000; /* this value is chosen arbitrarily. this 
gives an error of about 1.74909e-20 */
  
--assert (angle_max >= angle_min);
-+if (angle_max < angle_min)
-+   return;
+ for (i = 0; i < table_size; i++)
+   if (table[i].error < tolerance)
+   return table[i].angle;
  
- if (angle_max - angle_min > 2 * M_PI * MAX_FULL_CIRCLES) {
-   angle_max = fmod (angle_max - angle_min, 2 * M_PI);
+ ++i;
++
+ do {
+   angle = M_PI / i++;
+   error = _arc_error_normalized (angle);
+-} while (error > tolerance);
++} while (error > tolerance && i < max_segments);
+ 
+ return angle;
+ }
+-- 
+2.38.1
+

---
base-commit: 3a8654b860fa98f94e80c3c3fff359ffed14bbe7
change-id: 20221214-cairo-cve-typo-fd0d89835d77

Best regards,
-- 
Quentin Schulz 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175316): 
https://lists.openembedded.org/g/openembedded-core/message/175316
Mute This Topic: https://lists.openembedded.org/mt/96007428/21656
Group Owner:

Re: [OE-core] [PATCH 2/2] cve-update-db-native: avoid partial updates

2023-01-02 Thread Jose Quaresma 
Hi Marta,

Marta Rybczynska  escreveu no dia segunda, 2/01/2023
à(s) 07:03:

> The database update has been done on the original file. In case of
> network connection issues, temporary outage of the NVD server or
> a similar situation, the function could exit with incomplete data
> in the database. This patch solves the issue by performing the update
> on a copy of the database. It replaces the main one only if the whole
> update was successful.
>
> See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14929
>
> Reported-by: Alberto Pianon 
> Signed-off-by: Marta Rybczynska 
> ---
>  .../recipes-core/meta/cve-update-db-native.bb | 81 +--
>  1 file changed, 56 insertions(+), 25 deletions(-)
>
> diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
> b/meta/recipes-core/meta/cve-update-db-native.bb
> index 642fda5395..89804b9e5c 100644
> --- a/meta/recipes-core/meta/cve-update-db-native.bb
> +++ b/meta/recipes-core/meta/cve-update-db-native.bb
> @@ -21,6 +21,8 @@ CVE_DB_UPDATE_INTERVAL ?= "86400"
>  # Timeout for blocking socket operations, such as the connection attempt.
>  CVE_SOCKET_TIMEOUT ?= "60"
>
> +CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
> +
>  python () {
>  if not bb.data.inherits_class("cve-check", d):
>  raise bb.parse.SkipRecipe("Skip recipe when cve-check class is
> not loaded.")
> @@ -32,19 +34,15 @@ python do_fetch() {
>  """
>  import bb.utils
>  import bb.progress
> -import sqlite3, urllib, urllib.parse, gzip
> -from datetime import date
> +import shutil
>
>  bb.utils.export_proxies(d)
>
> -YEAR_START = 2002
> -
>  db_file = d.getVar("CVE_CHECK_DB_FILE")
>  db_dir = os.path.dirname(db_file)
> +db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
>
> -cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
> -
> -cleanup_db_download(db_file)
> +cleanup_db_download(db_file, db_tmp_file)
>
>  # The NVD database changes once a day, so no need to update more
> frequently
>  # Allow the user to force-update
> @@ -62,9 +60,55 @@ python do_fetch() {
>  pass
>
>  bb.utils.mkdirhier(db_dir)
> +if os.path.exists(db_file):
> +shutil.copy2(db_file, db_tmp_file)
> +
> +if update_db_file(db_tmp_file, d) == True:
> +# Update downloaded correctly, can swap files
> +shutil.move(db_tmp_file, db_file)
> +else:
> +# Update failed, do not modify the database
> +bb.note("CVE database update failed")
> +os.remove(db_tmp_file)
> +}
> +
> +do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
> +do_fetch[file-checksums] = ""
> +do_fetch[vardeps] = ""
> +
> +def cleanup_db_download(db_file, db_tmp_file):
> +"""
> +Cleanup the download space from possible failed downloads
> +"""
> +if os.path.exists("{0}-journal".format(db_file)):
> +# If a journal is present the last update might have been
> interrupted. In that case,
> +# just wipe any leftovers and force the DB to be recreated.
> +os.remove("{0}-journal".format(db_file))
> +
> +if os.path.exists(db_file):
> +os.remove(db_file)
> +
> +if os.path.exists("{0}-journal".format(db_tmp_file)):
> +# If a journal is present the last update might have been
> interrupted. In that case,
> +# just wipe any leftovers and force the DB to be recreated.
> +os.remove("{0}-journal".format(db_tmp_file))
> +
> +if os.path.exists(db_tmp_file):
> +os.remove(db_tmp_file)
> +
>

It seems to me that this function is a duplication of the old version with
an extra argument.
So I think that using the old function version and call it with the proper
argument does the same:

cleanup_db_download(db_file)
cleanup_db_download(db_tmp_file)

Jose


> +def update_db_file(db_tmp_file, d):
> +"""
> +Update the given database file
> +"""
> +import bb.utils, bb.progress
> +from datetime import date
> +import urllib, gzip, sqlite3
> +
> +YEAR_START = 2002
> +cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
>
>  # Connect to database
> -conn = sqlite3.connect(db_file)
> +conn = sqlite3.connect(db_tmp_file)
>  initialize_db(conn)
>
>  with bb.progress.ProgressHandler(d) as ph,
> open(os.path.join(d.getVar("TMPDIR"), 'cve_check'), 'a') as cve_f:
> @@ -82,7 +126,7 @@ python do_fetch() {
>  except urllib.error.URLError as e:
>  cve_f.write('Warning: CVE db update error, Unable to
> fetch CVE data.\n\n')
>  bb.warn("Failed to fetch CVE data (%s)" % e.reason)
> -return
> +return False
>
>  if response:
>  for l in response.read().decode("utf-8").splitlines():
> @@ -92,7 +136,7 @@ python do_fetch() {
>  break
>  else:
>  bb.warn("Cannot parse CVE metadata, update failed")
> -return
> +