Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.4.4.rc1)

[Teoh, Jay Shen]

Hi Everyone,

This is the full report for yocto-3.4.4.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
No high milestone defects.

No new issue found.

Thanks,
Jay

> -Original Message-
> From: yo...@lists.yoctoproject.org  On Behalf
> Of Pokybuild User
> Sent: Wednesday, 4 May, 2022 10:32 AM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [yocto] QA notification for completed autobuilder build (yocto-
> 3.4.4.rc1)
> 
> 
> A build flagged for QA (yocto-3.4.4.rc1) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.4.4.rc1
> 
> 
> Build hash information:
> 
> bitbake: c2d8f9b2137bd4a98eb0f51519493131773e7517
> meta-agl: 8543843eeb47fa9b45786d3e09bf497fcd5f95e0
> meta-arm: 2623e69db362b357db45c343e6d504909552c2d5
> meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
> meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
> meta-intel: daf5c125a744d45d8fa395b576147edd5a714f5c
> meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
> meta-openembedded: 9a0caf5b09e14a28a54c3f8524d97530aeb8152c
> meta-virtualization: bd7511c53b921c9ce4ba2fdb42778ca194ebc3e8
> oecore: 1a6f5e27249afb6fb4d47c523b62b5dd2482a69d
> poky: 780eeec8851950ee6ac07a2a398ba937206bd2e4
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165409): 
https://lists.openembedded.org/g/openembedded-core/message/165409
Mute This Topic: https://lists.openembedded.org/mt/90925536/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 v2] gnutls: Added fips support option.

[leimaohui]

Hi Alex

> You can issue this in poky/meta and plenty of examples will come up:
> [ak@fedora meta]$ grep -ir PACKAGECONFIG *|grep class-native

I'm afraid I'm not quite with you. Searched poky by the following command and 
there is no example about how to config PACKAGECONFIG[xxx] for target or native 
separately. 
The result is all about how to config PACKAGECONFIG for target or native. 

$ grep -ir PACKAGECONFIG *|grep class-native
meta/recipes-support/libcap/libcap_2.64.bb:PACKAGECONFIG:class-native ??= ""
meta/recipes-support/vim/vim_8.2.bb:PACKAGECONFIG:class-native = ""
meta/recipes-support/sqlite/sqlite3.inc:PACKAGECONFIG:class-native ?= "fts4 
fts5 rtree dyn_ext"
..


But I think you mean not PACKAGECONFIG but PACKAGECONFIG[fips]. For example, in 
libcap_2.64.bb file: 
$ cat meta/recipes-support/libcap/libcap_2.64.bb
..
PACKAGECONFIG ??= "libidn  ${@bb.utils.filter('DISTRO_FEATURES', 'seccomp', d)} 
"  //not here
..
PACKAGECONFIG[fips] = "--enable-fips140-mode 
--with-libdl-prefix=${STAGING_BASELIBDIR},--disable-fips140-mode"   //Your 
comment means modify here
...

Did I misunderstand? 

Best regards
Lei

> -Original Message-
> From: openembedded-core@lists.openembedded.org
>  On Behalf Of Alexander
> Kanavin
> Sent: Monday, May 9, 2022 4:44 PM
> To: Lei, Maohui 
> Cc: OE-core 
> Subject: Re: [OE-core] [PATCH v2] gnutls: Added fips support option.
> 
> On Mon, 9 May 2022 at 03:30, leimao...@fujitsu.com 
> wrote:
> > > PACKAGECONFIG[fips] = "--enable-fips140-mode
> > > --with-libdl-prefix=${STAGING_BASELIBDIR},--disable-fips140-mode,gnu
> > > tls-nativ
> > > e"
> > > PACKAGECONFIG[fips-native] = "--enable-fips140-mode
> > > --with-libdl-prefix=${STAGING_BASELIBDIR},--disable-fips140-mode"
> >
> > I'm sorry that this way doesn’t work, because PACKAGECONFIG[fips-native]
> means PACKAGECONFIG is set for fips-native not for fips.
> > And I don't find any existing recipes that config PACKAGECONFIG[xxx] for 
> > native
> or target separately.
> > I wonder If you can tell me any recipe for reference.
> > Thank you.
> 
> You can issue this in poky/meta and plenty of examples will come up:
> [ak@fedora meta]$ grep -ir PACKAGECONFIG *|grep class-native
> 
> Alex

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

[Khem Raj]

On Mon, May 9, 2022 at 2:39 PM Luca Ceresoli  wrote:
>
> Hi Khem,
>
> Il giorno Sat,  7 May 2022 17:38:20 -0700
> "Khem Raj"  ha scritto:
>
> > Major gcc release with lot of changes [2]
> >
> > - Add patch to re-shuffle include of sched.h to fix build on musl
> > - porting guide to gcc 12 [1]
> > - Fix version in maintainers entry
> >
> > [1] https://gcc.gnu.org/gcc-12/porting_to.html
> > [2] https://gcc.gnu.org/gcc-12/changes.html
> >
> > Signed-off-by: Khem Raj 
>
> We have a xen-tools build failure on meta-virt with this patch applied:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/60/steps/13/logs/stdio
>
> and the same build succeeds without that patch:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/61/steps/13/logs/stdio

yeah this has been taken care in meta-virtualization/master this
morning. So please give it another
spin.

>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165407): 
https://lists.openembedded.org/g/openembedded-core/message/165407
Mute This Topic: https://lists.openembedded.org/mt/90963542/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 1/5] recipetool-create: add ensure_native_cmd function

[Luca Ceresoli via lists.openembedded.org]

Hello Stefan,

Il giorno Fri,  6 May 2022 08:59:13 +0200
"Stefan Herbrechtsmeier" 
ha scritto:

> From: Lukas Funke 
> 
> Signed-off-by: Lukas Funke 
> Signed-off-by: Stefan Herbrechtsmeier
> 

Testing builds with your series trigger many build failures related to
recipetool. Can you check these logs?

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3557/steps/15/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/3506/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/3527/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/3566/steps/14/logs/stdio



-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Luca Ceresoli via lists.openembedded.org]

Hi Khem,

Il giorno Sat,  7 May 2022 17:38:20 -0700
"Khem Raj"  ha scritto:

> Major gcc release with lot of changes [2]
> 
> - Add patch to re-shuffle include of sched.h to fix build on musl
> - porting guide to gcc 12 [1]
> - Fix version in maintainers entry
> 
> [1] https://gcc.gnu.org/gcc-12/porting_to.html
> [2] https://gcc.gnu.org/gcc-12/changes.html
> 
> Signed-off-by: Khem Raj 

We have a xen-tools build failure on meta-virt with this patch applied:

https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/60/steps/13/logs/stdio

and the same build succeeds without that patch:

https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/61/steps/13/logs/stdio

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165405): 
https://lists.openembedded.org/g/openembedded-core/message/165405
Mute This Topic: https://lists.openembedded.org/mt/90963542/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][dunfell] linux-yocto/5.4: update to v5.4.192

[Bruce Ashfield]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

1d72b776f6dc Linux 5.4.192
aa2a047b5842 mm, hugetlb: allow for "high" userspace addresses
6a79b2433eb1 hugetlbfs: get unmapped area below TASK_UNMAPPED_BASE for 
hugetlbfs
b69e60f6fc00 tty: n_gsm: fix incorrect UA handling
0f4be29febdc tty: n_gsm: fix wrong command frame length field encoding
21cc640385b4 tty: n_gsm: fix wrong command retry handling
49c40febd45c tty: n_gsm: fix missing explicit ldisc flush
85522dcf0053 tty: n_gsm: fix insufficient txframe size
563bb0f794ca netfilter: nft_socket: only do sk lookups when indev is 
available
fae209521000 tty: n_gsm: fix malformed counter for out of frame data
cec2d0782a7b tty: n_gsm: fix wrong signal octet encoding in convergence 
layer type 2
a6d9847a4f82 x86/cpu: Load microcode during restore_processor_state()
9e9d12b81df6 net: ethernet: stmmac: fix write to sgmii_adapter_base
10ba1ac9a22a drivers: net: hippi: Fix deadlock in rr_close()
a8275219759e cifs: destage any unwritten data to the server before calling 
copychunk_write
5335370366a3 x86: __memcpy_flushcache: fix wrong alignment if size > 2^32
0ecc5304e80a ip6_gre: Avoid updating tunnel->tun_hlen in __gre6_xmit()
781571034993 ASoC: wm8731: Disable the regulator when probing fails
a71df406a6a5 tcp: fix F-RTO may not work correctly when receiving DSACK
a4ed61e30e32 ixgbe: ensure IPsec VF<->PF compatibility
406aaef0feae bnx2x: fix napi API usage sequence
c3e7ea58608a tls: Skip tls_append_frag on zero copy size
cd5cec3a0c8f drm/amd/display: Fix memory leak in dcn21_clock_source_create
ffce11a39102 net: dsa: lantiq_gswip: Don't set GSWIP_MII_CFG_RMII_CLK
3a179538bfd7 net: bcmgenet: hide status block before TX timestamping
8ef6d60aa2f1 clk: sunxi: sun9i-mmc: check return value after calling 
platform_get_resource()
194f474ad9b4 bus: sunxi-rsb: Fix the return value of 
sunxi_rsb_device_create()
e80054ea0cde tcp: fix potential xmit stalls caused by TCP_NOTSENT_LOWAT
685ff7d24487 ip_gre: Make o_seqno start from 0 in native mode
69555bb27b2e net/smc: sync err code when tcp connection was refused
daca23846eb3 net: hns3: add validity check for message data length
7763a7956632 cpufreq: fix memory leak in sun50i_cpufreq_nvmem_probe
f5bb5940d754 pinctrl: pistachio: fix use of irq_of_parse_and_map()
d22fc603694b arm64: dts: imx8mn-ddr4-evk: Describe the 32.768 kHz PMIC clock
68f5200a1f60 ARM: dts: imx6ull-colibri: fix vqmmc regulator
c45180375afd sctp: check asoc strreset_chunk in sctp_generate_reconf_event
2cba635570d8 tcp: ensure to use the most recently sent skb when filling the 
rate sample
3ea6190be92f tcp: md5: incorrect tcp_header_len for incoming connections
2b9a13d98dfc bpf, lwt: Fix crash when using bpf_skb_set_tunnel_key() from 
bpf_xmit lwt hook
2e7f70d324ef mtd: rawnand: Fix return value check of 
wait_for_completion_timeout
2a36ba067b36 ipvs: correctly print the memory size of ip_vs_conn_tab
abe86a10dc5c ARM: dts: logicpd-som-lv: Fix wrong pinmuxing on OMAP35
54212850e38f ARM: dts: am3517-evm: Fix misc pinmuxing
bba67fe6b022 ARM: dts: Fix mmc order for omap3-gta04
416e0f890732 phy: ti: Add missing pm_runtime_disable() in serdes_am654_probe
6ff7c1b827c8 phy: mapphone-mdm6600: Fix PM error handling in 
phy_mdm6600_probe
59bdaed5dd73 ARM: dts: at91: Map MCLK for wm8731 on at91sam9g20ek
dbce8fc16a08 phy: ti: omap-usb2: Fix error handling in 
omap_usb2_enable_clocks
b7fc45354be6 ARM: OMAP2+: Fix refcount leak in omap_gic_of_init
dd99939b70c4 phy: samsung: exynos5250-sata: fix missing device put in probe 
error paths
6331b77fdc17 phy: samsung: Fix missing of_node_put() in 
exynos_sata_phy_probe
fccbc3168e5e ARM: dts: imx6qdl-apalis: Fix sgtl5000 detection issue
b8f0c19d4864 USB: Fix xhci event ring dequeue pointer ERDP update issue
1f47c2625773 mtd: rawnand: fix ecc parameters for mt7622
0405bd7f1888 arm64: dts: meson: remove CPU opps below 1GHz for SM1 boards
5f80b5c5f406 arm64: dts: meson: remove CPU opps below 1GHz for G12B boards
f6db63819db6 video: fbdev: udlfb: properly check endpoint type
c00f3892f4f0 hex2bin: fix access beyond string end
15b78a8e38e8 hex2bin: make the function hex_to_bin constant-time
73f4668ee875 arch_topology: Do not set llc_sibling if llc_id is invalid
a3cdd33ca163 serial: 8250: Correct the clock for EndRun PTP/1588 PCIe device
89a5728b053c serial: 8250: Also set sticky MCR bits in console restoration
42f749f2232a serial: imx: fix overrun interrupts in DMA mode
d29c197df7fa usb: dwc3: gadget: Return proper request status
0f3d081315c5 usb: dwc3: core: Fix tx/rx threshold settings
e2ec7b1f6a06 usb: gadget: configfs: clear deactivation flag in 
configfs_composite_unbind()
debb276670b0 usb: gadget: uvc: Fix crash 

Re: [OE-core] [meta-oe][master][PATCH] tcpdump: Add fix for CVE-2018-16301

[Khem Raj]

send it to openembedded-devel mailing list please.

On Mon, May 9, 2022 at 12:21 AM Riyaz  wrote:
>
> From: Riyaz Ahmed Khan 
>
> Add patch for CVE issue: CVE-2018-16301
> Link: 
> https://github.com/the-tcpdump-group/tcpdump/commit/8ab211a7ec728bb0ad8c766c8eeb12deb0a13b86
>
> Signed-off-by: Riyaz Ahmed Khan 
> ---
>  .../tcpdump/tcpdump/CVE-2018-16301.patch  | 111 ++
>  .../recipes-support/tcpdump/tcpdump_4.9.3.bb  |   1 +
>  2 files changed, 112 insertions(+)
>  create mode 100644 
> meta-networking/recipes-support/tcpdump/tcpdump/CVE-2018-16301.patch
>
> diff --git 
> a/meta-networking/recipes-support/tcpdump/tcpdump/CVE-2018-16301.patch 
> b/meta-networking/recipes-support/tcpdump/tcpdump/CVE-2018-16301.patch
> new file mode 100644
> index 0..5f5c68ccd
> --- /dev/null
> +++ b/meta-networking/recipes-support/tcpdump/tcpdump/CVE-2018-16301.patch
> @@ -0,0 +1,111 @@
> +From 8ab211a7ec728bb0ad8c766c8eeb12deb0a13b86 Mon Sep 17 00:00:00 2001
> +From: Guy Harris 
> +Date: Wed, 30 Sep 2020 11:37:30 -0700
> +Subject: [PATCH] Handle very large -f files by rejecting them.
> +
> +_read(), on Windows, has a 32-bit size argument and a 32-bit return
> +value, so reject -f files that have more than 2^31-1 characters.
> +
> +Add some #defines so that, on Windows, we use _fstati64 to get the size
> +of that file, to handle large files.
> +
> +Don't assume that our definition for ssize_t is the same size as size_t;
> +by the time we want to print the return value of the read, we know it'll
> +fit into an int, so just cast it to int and print it with %d.
> +
> +(cherry picked from commit faf8fb70af3a013e5d662b8283dec742fd6b1a77)
> +
> +CVE: CVE-2022-25308
> +Upstream-Status: Backport 
> [https://github.com/the-tcpdump-group/tcpdump/commit/8ab211a7ec728bb0ad8c766c8eeb12deb0a13b86]
> +
> +Signed-off-by: Riyaz Ahmed Khan 
> +
> +---
> + netdissect-stdinc.h | 16 +++-
> + tcpdump.c   | 15 ---
> + 2 files changed, 27 insertions(+), 4 deletions(-)
> +
> +diff --git a/netdissect-stdinc.h b/netdissect-stdinc.h
> +index 8282c5846..9941c2a16 100644
> +--- a/netdissect-stdinc.h
>  b/netdissect-stdinc.h
> +@@ -149,10 +149,17 @@
> + #ifdef _MSC_VER
> + #define stat _stat
> + #define open _open
> +-#define fstat _fstat
> + #define read _read
> + #define close _close
> + #define O_RDONLY _O_RDONLY
> ++
> ++/*
> ++ * We define our_fstat64 as _fstati64, and define our_statb as
> ++ * struct _stati64, so we get 64-bit file sizes.
> ++ */
> ++#define our_fstat _fstati64
> ++#define our_statb struct _stati64
> ++
> + #endif  /* _MSC_VER */
> +
> + /*
> +@@ -211,6 +218,13 @@ typedef char* caddr_t;
> +
> + #include 
> +
> ++/*
> ++ * We should have large file support enabled, if it's available,
> ++ * so just use fstat as our_fstat and struct stat as our_statb.
> ++ */
> ++#define our_fstat fstat
> ++#define our_statb struct stat
> ++
> + #endif /* _WIN32 */
> +
> + #ifndef HAVE___ATTRIBUTE__
> +diff --git a/tcpdump.c b/tcpdump.c
> +index 043bda1d7..8f27ba2a4 100644
> +--- a/tcpdump.c
>  b/tcpdump.c
> +@@ -108,6 +108,7 @@ The Regents of the University of California.  All rights 
> reserved.\n";
> + #endif /* HAVE_CAP_NG_H */
> + #endif /* HAVE_LIBCAP_NG */
> +
> ++#include "netdissect-stdinc.h"
> + #include "netdissect.h"
> + #include "interface.h"
> + #include "addrtoname.h"
> +@@ -861,15 +862,22 @@ read_infile(char *fname)
> + {
> +   register int i, fd, cc;
> +   register char *cp;
> +-  struct stat buf;
> ++  our_statb buf;
> +
> +   fd = open(fname, O_RDONLY|O_BINARY);
> +   if (fd < 0)
> +   error("can't open %s: %s", fname, pcap_strerror(errno));
> +
> +-  if (fstat(fd, ) < 0)
> ++  if (our_fstat(fd, ) < 0)
> +   error("can't stat %s: %s", fname, pcap_strerror(errno));
> +
> ++  /*
> ++   * Reject files whose size doesn't fit into an int; a filter
> ++   * *that* large will probably be too big.
> ++   */
> ++  if (buf.st_size > INT_MAX)
> ++  error("%s is too large", fname);
> ++
> +   cp = malloc((u_int)buf.st_size + 1);
> +   if (cp == NULL)
> +   error("malloc(%d) for %s: %s", (u_int)buf.st_size + 1,
> +@@ -878,7 +886,8 @@ read_infile(char *fname)
> +   if (cc < 0)
> +   error("read %s: %s", fname, pcap_strerror(errno));
> +   if (cc != buf.st_size)
> +-  error("short read %s (%d != %d)", fname, cc, 
> (int)buf.st_size);
> ++  error("short read %s (%d != %d)", fname, (int) cc,
> ++  (int)buf.st_size);
> +
> +   close(fd);
> +   /* replace "# comment" with spaces */
> diff --git a/meta-networking/recipes-support/tcpdump/tcpdump_4.9.3.bb 
> b/meta-networking/recipes-support/tcpdump/tcpdump_4.9.3.bb
> index 2ea493863..66bf21775 100644
> --- a/meta-networking/recipes-support/tcpdump/tcpdump_4.9.3.bb
> +++ b/meta-networking/recipes-support/tcpdump/tcpdump_4.9.3.bb
> @@ -18,6 +18,7 @@ SRC_URI = " \
> 

Re: [OE-core] gcc12 testing results

[Khem Raj]

On Mon, May 9, 2022 at 9:34 AM  wrote:
>
> On Mon, 2022-05-09 at 09:24 -0400, Bruce Ashfield wrote:
> > On Fri, May 6, 2022 at 11:14 AM Richard Purdie
> >  wrote:
> > >
> > > I reran the gcc 12 testing. We still have an issue with linux-yocto
> > > 5.10 and edgerouter:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/3046
> >
> > I just sent the yocto-bsp bump to 5.10.113, which had the identified
> > -stable fix for gcc12. I can't say it is 100% complete at runtime for
> > gcc12, but this moves us along.
> >
> > >
> > > and meta-virtualization has a couple of issues:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/46
> > >
> >
> > I pushed the patch that Ross found on opensuse for gcc12 and Xen. I
> > can only say that it doesn't break gcc11 at the moment, but again, it
> > moves us along.
>
> Thanks, that looks like it fixes xen but xen-tools still has an issue:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/60/steps/13/logs/stdio

yeah I have sent a patch for xen-tools too

>
> Cheers,
>
> Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165402): 
https://lists.openembedded.org/g/openembedded-core/message/165402
Mute This Topic: https://lists.openembedded.org/mt/90935511/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] gcc12 testing results

[Richard Purdie]

On Mon, 2022-05-09 at 09:24 -0400, Bruce Ashfield wrote:
> On Fri, May 6, 2022 at 11:14 AM Richard Purdie
>  wrote:
> > 
> > I reran the gcc 12 testing. We still have an issue with linux-yocto
> > 5.10 and edgerouter:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/3046
> 
> I just sent the yocto-bsp bump to 5.10.113, which had the identified
> -stable fix for gcc12. I can't say it is 100% complete at runtime for
> gcc12, but this moves us along.
> 
> > 
> > and meta-virtualization has a couple of issues:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/46
> > 
> 
> I pushed the patch that Ross found on opensuse for gcc12 and Xen. I
> can only say that it doesn't break gcc11 at the moment, but again, it
> moves us along.

Thanks, that looks like it fixes xen but xen-tools still has an issue:

https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/60/steps/13/logs/stdio

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165401): 
https://lists.openembedded.org/g/openembedded-core/message/165401
Mute This Topic: https://lists.openembedded.org/mt/90935511/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] gcc12 testing results

[Khem Raj]

On Mon, May 9, 2022 at 6:24 AM Bruce Ashfield 
wrote:

> On Fri, May 6, 2022 at 11:14 AM Richard Purdie
>  wrote:
> >
> > I reran the gcc 12 testing. We still have an issue with linux-yocto
> > 5.10 and edgerouter:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/3046
>
> I just sent the yocto-bsp bump to 5.10.113, which had the identified
> -stable fix for gcc12. I can't say it is 100% complete at runtime for
> gcc12, but this moves us along.
>
> >
> > and meta-virtualization has a couple of issues:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/46
> >
>
> I pushed the patch that Ross found on opensuse for gcc12 and Xen. I
> can only say that it doesn't break gcc11 at the moment, but again, it
> moves us along.


Thanks I will test it locally as well since I have xen workspace handy atm

>
>
> Bruce
>
> > Build is still going.
> >
> > Cheers,
> >
> > Richard
> >
> > 
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165400): 
https://lists.openembedded.org/g/openembedded-core/message/165400
Mute This Topic: https://lists.openembedded.org/mt/90935511/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] freetype: Upgrade 2.12.0 -> 2.12.1

[Marta Rybczynska]

On Mon, May 9, 2022 at 12:40 PM Marta Rybczynska 
wrote:

>
>
> On Sun, May 8, 2022 at 6:45 PM Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
>> On Sun, 2022-05-08 at 13:34 +0100, Richard Purdie via
>> lists.openembedded.org wrote:
>> > Includes fixes for CVE-2022-27404, CVE-2022-27405, CVE-2022-27406.
>> >
>> >
>>
>> I'm amending this to "Include fix for CVE-2022-27404" since CVE-2022-
>> 27405 and CVE-2022-27406 were already in 2.12.0.
>>
>> I don't think the CVE checker is going to like these as they're using
>> dates for these for reasons I don't understand.
>>
>>
> They also include versions in the NVD, but there is no version "
> non-afected"
> as of today for CVE-2022-27404. I'll figure out the exact versions for
> those
> CVEs and update the NVD in the next hours.
>
> Kind regards,
> Marta
>

Update: the message to NVD has been sent. According to my analysis all three
CVEs have been fixed in 2.12.0.

Regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165399): 
https://lists.openembedded.org/g/openembedded-core/message/165399
Mute This Topic: https://lists.openembedded.org/mt/90973332/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] gcc12 testing results

[Bruce Ashfield]

On Fri, May 6, 2022 at 11:14 AM Richard Purdie
 wrote:
>
> I reran the gcc 12 testing. We still have an issue with linux-yocto
> 5.10 and edgerouter:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/3046

I just sent the yocto-bsp bump to 5.10.113, which had the identified
-stable fix for gcc12. I can't say it is 100% complete at runtime for
gcc12, but this moves us along.

>
> and meta-virtualization has a couple of issues:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/46
>

I pushed the patch that Ross found on opensuse for gcc12 and Xen. I
can only say that it doesn't break gcc11 at the moment, but again, it
moves us along.

Bruce

> Build is still going.
>
> Cheers,
>
> Richard
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165398): 
https://lists.openembedded.org/g/openembedded-core/message/165398
Mute This Topic: https://lists.openembedded.org/mt/90935511/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] gcc12 testing results

[Ross Burton]

> On 6 May 2022, at 17:08, Bruce Ashfield via lists.openembedded.org 
>  wrote:
>
> On Fri, May 6, 2022 at 11:41 AM Khem Raj  wrote:
>>
>> yeah meta-virt is seemingly a new addition. Adding Bruce also about
>> the failures.
>
> The Xen guys will hopefully get around to it shortly, but we are still
> going through significant work to get kirkstone stabilized and
> released for meta-virt, so there's unlikely to be anything specific
> done on it for a bit yet.
>
> I'm sure Xen upstream has already addressed it, but our Xen upgrades
> are in place for the release (Which is where the stabilization effort
> is happening), so we can peek for incremental fixes as appropriate.

At least OpenSuse has a workaround patch:

https://build.opensuse.org/package/view_file/openSUSE:Factory/xen/gcc12-fixes.patch?expand=1

I’m pretty sure we can’t expect to see that upstreamed, but its likely good 
enough for the short term.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165397): 
https://lists.openembedded.org/g/openembedded-core/message/165397
Mute This Topic: https://lists.openembedded.org/mt/90935511/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] linux-firmware: replace mkdir by install

[Konrad Weihmann]

if a setup is using RPM for packaging and there are multiple
recipes that install to ${nonarch_base_libdir}/firmware by using
install -d ${nonarch_base_libdir}/firmware, it will create installation
clashes on image install, as linux-firmware in before this patch
used mkdir -p, which creates different file mode bits (depending
on the current user's settings).

In a particular example
linux-fimware created /lib/firmware with 0600
while other-firmware-package created it with 0644
making the combination not installable by rpm backend

Signed-off-by: Konrad Weihmann 
---
v2: - add ML link for Submission status
- rebase on latest master

 ...01-Makefile-replace-mkdir-by-install.patch | 84 +++
 .../linux-firmware/linux-firmware_20220411.bb |  5 +-
 2 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch

diff --git 
a/meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch
 
b/meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch
new file mode 100644
index 00..b1ac5a16ab
--- /dev/null
+++ 
b/meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch
@@ -0,0 +1,84 @@
+From 71514e74f35f2b51ca24062573d6d913525b30db Mon Sep 17 00:00:00 2001
+From: Konrad Weihmann 
+Date: Mon, 9 May 2022 12:57:57 +0200
+Subject: [PATCH] Makefile: replace mkdir by install
+
+mkdir -p creates paths that are bound to user's settings and therefore
+can lead to different file mode bits of the base paths accross different
+machines.
+Use install instead, as this tool is not prone to such behavior.
+
+Signed-off-by: Konrad Weihmann 
+Upstream-Status: Submitted 
[https://lore.kernel.org/linux-firmware/pr2pr09mb310088ea719e6d7ca5c268f1a8...@pr2pr09mb3100.eurprd09.prod.outlook.com/]
+---
+ Makefile  | 2 +-
+ carl9170fw/toolchain/Makefile | 4 ++--
+ copy-firmware.sh  | 6 +++---
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index e1c362f..83a0ec6 100644
+--- a/Makefile
 b/Makefile
+@@ -9,5 +9,5 @@ check:
+   @./check_whence.py
+ 
+ install:
+-  mkdir -p $(DESTDIR)$(FIRMWAREDIR)
++  install -d $(DESTDIR)$(FIRMWAREDIR)
+   ./copy-firmware.sh $(DESTDIR)$(FIRMWAREDIR)
+diff --git a/carl9170fw/toolchain/Makefile b/carl9170fw/toolchain/Makefile
+index 2b25ffe..aaea8e8 100644
+--- a/carl9170fw/toolchain/Makefile
 b/carl9170fw/toolchain/Makefile
+@@ -46,14 +46,14 @@ src/gcc-$(GCC_VER): src/$(GCC_TAR) src/newlib-$(NEWLIB_VER)
+   ln -s $(BASEDIR)/src/newlib-$(NEWLIB_VER)/libgloss $@
+ 
+ binutils: src/binutils-$(BINUTILS_VER)
+-  mkdir -p build/binutils
++  install -d build/binutils
+   cd build/binutils; \
+   $(BASEDIR)/$ //g' 
| while read f d; d
+ if test -L "$f"; then
+ test -f "$destdir/$f" && continue
+ $verbose "copying link $f"
+-mkdir -p $destdir/$(dirname "$f")
++install -d $destdir/$(dirname "$f")
+ cp -d "$f" $destdir/"$f"
+ 
+ if test "x$d" != "x"; then
+@@ -63,7 +63,7 @@ grep -E '^Link:' WHENCE | sed -e's/^Link: *//g' -e's/-> //g' 
| while read f d; d
+ fi
+ else
+ $verbose "creating link $f -> $d"
+-mkdir -p $destdir/$(dirname "$f")
++install -d $destdir/$(dirname "$f")
+ ln -sf "$d" "$destdir/$f"
+ fi
+ done
+-- 
+2.25.1
+
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20220411.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20220411.bb
index 89e1b8cbaf..19b970c091 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20220411.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20220411.bb
@@ -203,7 +203,10 @@ NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
 PE = "1"
 
-SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz"
+SRC_URI = "\
+  ${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz \
+  file://0001-Makefile-replace-mkdir-by-install.patch \
+"
 
 SRC_URI[sha256sum] = 
"020b11f6412f4956f5a6f98de7d41867d2b30ea0ce81b1e2d206ec9840363849"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165396): 
https://lists.openembedded.org/g/openembedded-core/message/165396
Mute This Topic: https://lists.openembedded.org/mt/90986447/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] linux-firmware: replace mkdir by install

[Richard Purdie]

On Mon, 2022-05-09 at 12:45 +0200, Alexander Kanavin wrote:
> On Mon, 9 May 2022 at 12:42, Konrad Weihmann  wrote:
> > +Upstream-Status: Submitted
> 
> Submitted [where] please. If it's to a mailing list, link to the
> message on some web archive.

Patch also doesn't apply against master as I think the version may have
been upgraded.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165395): 
https://lists.openembedded.org/g/openembedded-core/message/165395
Mute This Topic: https://lists.openembedded.org/mt/90986193/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] linux-firmware: replace mkdir by install

[Alexander Kanavin]

On Mon, 9 May 2022 at 12:42, Konrad Weihmann  wrote:
> +Upstream-Status: Submitted

Submitted [where] please. If it's to a mailing list, link to the
message on some web archive.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165394): 
https://lists.openembedded.org/g/openembedded-core/message/165394
Mute This Topic: https://lists.openembedded.org/mt/90986193/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] pciutils: Add make-native dependency

[Richard Purdie]

A change in behaviour in make between 4.2.1 and 4.3 on how whitespace
and appends are handled[1] causes changes in lib/libpci.pc and leads
to non-reproducible builds.

Add a dependency on make-native to resovle this as a least invasive
and least worse solution for now.

[1] 
https://git.savannah.gnu.org/cgit/make.git/commit/?id=b90fabc8d6f34fb37d428dc0fb1b8b1951a9fbed

Signed-off-by: Richard Purdie 
---
 meta/recipes-bsp/pciutils/pciutils_3.8.0.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/pciutils/pciutils_3.8.0.bb 
b/meta/recipes-bsp/pciutils/pciutils_3.8.0.bb
index 8455b286a820..f3a67d97e445 100644
--- a/meta/recipes-bsp/pciutils/pciutils_3.8.0.bb
+++ b/meta/recipes-bsp/pciutils/pciutils_3.8.0.bb
@@ -6,7 +6,10 @@ SECTION = "console/utils"
 
 LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
-DEPENDS = "zlib kmod"
+# Can drop make-native when all systems have make 4.3
+# 
https://git.savannah.gnu.org/cgit/make.git/commit/?id=b90fabc8d6f34fb37d428dc0fb1b8b1951a9fbed
+# causes space issues in lib/libpci.pc
+DEPENDS = "zlib kmod make-native"
 
 SRC_URI = "${KERNELORG_MIRROR}/software/utils/pciutils/pciutils-${PV}.tar.xz \
file://configure.patch"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165393): 
https://lists.openembedded.org/g/openembedded-core/message/165393
Mute This Topic: https://lists.openembedded.org/mt/90986200/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] linux-firmware: replace mkdir by install

[Konrad Weihmann]

if a setup is using RPM for packaging and there are multiple
recipes that install to ${nonarch_base_libdir}/firmware by using
install -d ${nonarch_base_libdir}/firmware, it will create installation
clashes on image install, as linux-firmware in before this patch
used mkdir -p, which creates different file mode bits (depending
on the current user's settings).

In a particular example
linux-fimware created /lib/firmware with 0600
while other-firmware-package created it with 0644
making the combination not installable by rpm backend

Signed-off-by: Konrad Weihmann 
---
 ...01-Makefile-replace-mkdir-by-install.patch | 84 +++
 .../linux-firmware/linux-firmware_20220209.bb |  5 +-
 2 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch

diff --git 
a/meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch
 
b/meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch
new file mode 100644
index 00..16e0fa8986
--- /dev/null
+++ 
b/meta/recipes-kernel/linux-firmware/files/0001-Makefile-replace-mkdir-by-install.patch
@@ -0,0 +1,84 @@
+From 81bbf4495ab59979948043fa13f1c18db249fbdd Mon Sep 17 00:00:00 2001
+From: Konrad Weihmann 
+Date: Mon, 9 May 2022 12:23:28 +0200
+Subject: [PATCH] Makefile: replace mkdir by install
+
+mkdir -p creates paths that are bound to user's settings and therefore
+can lead to different file mode bits of the base paths accross different
+machines.
+Use install instead, as this tool is not prone to such behavior.
+
+Signed-off-by: Konrad Weihmann 
+Upstream-Status: Submitted
+---
+ Makefile  | 2 +-
+ carl9170fw/toolchain/Makefile | 4 ++--
+ copy-firmware.sh  | 6 +++---
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index e1c362f..83a0ec6 100644
+--- a/Makefile
 b/Makefile
+@@ -9,5 +9,5 @@ check:
+   @./check_whence.py
+ 
+ install:
+-  mkdir -p $(DESTDIR)$(FIRMWAREDIR)
++  install -d $(DESTDIR)$(FIRMWAREDIR)
+   ./copy-firmware.sh $(DESTDIR)$(FIRMWAREDIR)
+diff --git a/carl9170fw/toolchain/Makefile b/carl9170fw/toolchain/Makefile
+index 2b25ffe..aaea8e8 100644
+--- a/carl9170fw/toolchain/Makefile
 b/carl9170fw/toolchain/Makefile
+@@ -46,14 +46,14 @@ src/gcc-$(GCC_VER): src/$(GCC_TAR) src/newlib-$(NEWLIB_VER)
+   ln -s $(BASEDIR)/src/newlib-$(NEWLIB_VER)/libgloss $@
+ 
+ binutils: src/binutils-$(BINUTILS_VER)
+-  mkdir -p build/binutils
++  install -d build/binutils
+   cd build/binutils; \
+   $(BASEDIR)/$ //g' 
| while read f d; d
+ if test -L "$f"; then
+ test -f "$destdir/$f" && continue
+ $verbose "copying link $f"
+-mkdir -p $destdir/$(dirname "$f")
++install -d $destdir/$(dirname "$f")
+ cp -d "$f" $destdir/"$f"
+ 
+ if test "x$d" != "x"; then
+@@ -63,7 +63,7 @@ grep -E '^Link:' WHENCE | sed -e's/^Link: *//g' -e's/-> //g' 
| while read f d; d
+ fi
+ else
+ $verbose "creating link $f -> $d"
+-mkdir -p $destdir/$(dirname "$f")
++install -d $destdir/$(dirname "$f")
+ ln -sf "$d" "$destdir/$f"
+ fi
+ done
+-- 
+2.25.1
+
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20220209.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20220209.bb
index fe51892eb4..4758466aa9 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20220209.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20220209.bb
@@ -203,7 +203,10 @@ NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
 PE = "1"
 
-SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz"
+SRC_URI = "\
+  ${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz \
+  file://0001-Makefile-replace-mkdir-by-install.patch \
+"
 
 SRC_URI[sha256sum] = 
"e2e46fa618414952bbf2f6920cd3abcddbef45bfb7d1352994b4bfc35394d177"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165392): 
https://lists.openembedded.org/g/openembedded-core/message/165392
Mute This Topic: https://lists.openembedded.org/mt/90986193/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] freetype: Upgrade 2.12.0 -> 2.12.1

[Marta Rybczynska]

On Sun, May 8, 2022 at 6:45 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Sun, 2022-05-08 at 13:34 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > Includes fixes for CVE-2022-27404, CVE-2022-27405, CVE-2022-27406.
> >
> >
>
> I'm amending this to "Include fix for CVE-2022-27404" since CVE-2022-
> 27405 and CVE-2022-27406 were already in 2.12.0.
>
> I don't think the CVE checker is going to like these as they're using
> dates for these for reasons I don't understand.
>
>
They also include versions in the NVD, but there is no version "non-afected"
as of today for CVE-2022-27404. I'll figure out the exact versions for those
CVEs and update the NVD in the next hours.

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165391): 
https://lists.openembedded.org/g/openembedded-core/message/165391
Mute This Topic: https://lists.openembedded.org/mt/90973332/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] Revert "image.bbclass: allow overriding dependency on virtual/kernel:do_deploy"

[Jacob Kroon]

As pointed out in
https://lists.openembedded.org/g/openembedded-core/message/165058
https://lists.openembedded.org/g/openembedded-core/message/165216
this patch sets KERNELDEPLOYDEPEND but then uses KERNELDEPMODDEPEND.

Revert the changes since no one seems interested enough to fix it.
If someone wants this then make the variable name readable by
adding underscores where appropriate, for example by calling it
KERNEL_DEPLOY_DEPEND.

This reverts commit dcf9dfa4e6305786cd713aa28deda94a50bd6635.

Signed-off-by: Jacob Kroon 
---
 meta/classes/image.bbclass | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 47776db2b0..7f1f6f80a4 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -132,12 +132,7 @@ def rootfs_variables(d):
 
 do_rootfs[vardeps] += "${@rootfs_variables(d)}"
 
-# This is needed to have kernel image in DEPLOY_DIR.
-# This follow many common usecases and user expectations.
-# But if you are building an image which doesn't need the kernel image at all,
-# you can unset this variable manually.
-KERNELDEPLOYDEPEND ?= "virtual/kernel:do_deploy"
-do_build[depends] += "${KERNELDEPMODDEPEND}"
+do_build[depends] += "virtual/kernel:do_deploy"
 
 
 python () {

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

[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 418
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.1", "4.2", "4.99" and "Future", the more pressing/urgent
issues being in "4.1" and then "4.2".

 

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 (#165389): 
https://lists.openembedded.org/g/openembedded-core/message/165389
Mute This Topic: https://lists.openembedded.org/mt/90985835/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 v2] gnutls: Added fips support option.

[Alexander Kanavin]

On Mon, 9 May 2022 at 03:30, leimao...@fujitsu.com
 wrote:
> > PACKAGECONFIG[fips] = "--enable-fips140-mode
> > --with-libdl-prefix=${STAGING_BASELIBDIR},--disable-fips140-mode,gnutls-nativ
> > e"
> > PACKAGECONFIG[fips-native] = "--enable-fips140-mode
> > --with-libdl-prefix=${STAGING_BASELIBDIR},--disable-fips140-mode"
>
> I'm sorry that this way doesn’t work, because PACKAGECONFIG[fips-native] 
> means PACKAGECONFIG is set for fips-native not for fips.
> And I don't find any existing recipes that config PACKAGECONFIG[xxx] for 
> native or target separately.
> I wonder If you can tell me any recipe for reference.
> Thank you.

You can issue this in poky/meta and plenty of examples will come up:
[ak@fedora meta]$ grep -ir PACKAGECONFIG *|grep class-native

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165388): 
https://lists.openembedded.org/g/openembedded-core/message/165388
Mute This Topic: https://lists.openembedded.org/mt/90926966/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] meta: rust - Bug fix for target definitions returning 'NoneType' for arm

[Sundeep KOKKONDA]

Hello Richard,

On 05/05/22 19:02, Richard Purdie wrote:

On Thu, 2022-05-05 at 16:41 +0530, Sundeep KOKKONDA wrote:

Hello Richard,

On 19-04-2022 13:10, Richard Purdie wrote:
  

On Sun, 2022-04-10 at 23:00 -0700, Sundeep KOKKONDA wrote:
  

The build shows below error while building for arm machines.
Exception: TypeError: int() argument must be a string, a bytes-like object
or a number, not 'NoneType'
Detailed error info :

Steps to reproduce:
1. Set MACHINE ?= "qemuarm" in local.conf & add 'TOOLCHAIN_HOST_TASK:append
= " packagegroup-rust-cross-canadian-${MACHINE}"'
2. bitbake core-image-minimal -cpopulate_sdk

Complete Error:
ERROR: rust-cross-canadian-arm-1.59.0-r0 do_rust_gen_targets: Error
executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:do_rust_gen_targets(d)
  0003:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-
cross-canadian-common.inc', lineno: 31, function: do_rust_gen_targets
  0027:
  0028:LLVM_TARGET[x86_64] = "${RUST_HOST_SYS}"
  0029:python do_rust_gen_targets () {
  0030:wd = d.getVar('WORKDIR') + '/targets/'
  *** 0031:rust_gen_target(d, 'TARGET', wd,
d.getVar('TARGET_LLVM_FEATURES') or "", d.getVar('TARGET_LLVM_CPU'),
d.getVar('TARGET_ARCH'))
  0032:rust_gen_target(d, 'HOST', wd, "", "generic",
d.getVar('HOST_ARCH'))
  0033:rust_gen_target(d, 'BUILD', wd, "", "generic",
d.getVar('BUILD_ARCH'))
  0034:}
  0035:
File: '/ala-lpggp31/skokkonda/yocto/poky/meta/recipes-devtools/rust/rust-
common.inc', lineno: 330, function: rust_gen_target
  0326:# build tspec
  0327:tspec = {}
  0328:tspec['llvm-target'] = d.getVarFlag('LLVM_TARGET', arch_abi)
  0329:tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
  *** 0330:tspec['max-atomic-width'] =
int(d.getVarFlag('MAX_ATOMIC_WIDTH', arch_abi))
  0331:tspec['target-pointer-width'] =
d.getVarFlag('TARGET_POINTER_WIDTH', arch_abi)
  0332:tspec['target-c-int-width'] =
d.getVarFlag('TARGET_C_INT_WIDTH', arch_abi)
  0333:tspec['target-endian'] = d.getVarFlag('TARGET_ENDIAN',
arch_abi)
  0334:tspec['arch'] = arch_to_rust_target_arch(rust_arch)
Exception: TypeError: int() argument must be a string, a bytes-like object
or a number, not 'NoneType'

Below are the local variables from rust_gen_target function for arm and
aarch64 targets. Refer below, the tspec varibles for 'arm' generated with
NoneType.
(a) Locals at rust_gen_target for arm::
tspec['data-layout'] =  None, Type of tspec['data-layout'] =  
tspec['data-layout'] =  None, Type of tspec['data-layout'] =  
DEBUG: Python function do_rust_gen_targets finished
(b) Locals at rust_gen_target  for aarch64::
tspec['data-layout'] =  aarch64-unknown-linux-gnu, Type of tspec['data-
layout'] =  
tspec['max-atomic-width'] =  128, Type of tspec['max-atomic-width'] =


Reason for changing arm-eabi to arm: The previous change introduced this
bug, so reverting the change 'arm-eabi' to 'arm' fixed the issue.

Signed-off-by: Sundeep KOKKONDA
---
  meta/recipes-devtools/rust/rust-common.inc | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust-common.inc b/meta/recipes-
devtools/rust/rust-common.inc
index 310aecef22..230d78237f 100644
--- a/meta/recipes-devtools/rust/rust-common.inc
+++ b/meta/recipes-devtools/rust/rust-common.inc
@@ -119,13 +119,13 @@ def llvm_features(d):
  
  
  ## arm-unknown-linux-gnueabihf

-DATA_LAYOUT[arm-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
-LLVM_TARGET[arm-eabi] = "${RUST_TARGET_SYS}"
-TARGET_ENDIAN[arm-eabi] = "little"
-TARGET_POINTER_WIDTH[arm-eabi] = "32"
-TARGET_C_INT_WIDTH[arm-eabi] = "32"
-MAX_ATOMIC_WIDTH[arm-eabi] = "64"
-FEATURES[arm-eabi] = "+v6,+vfp2"
+DATA_LAYOUT[arm] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
+LLVM_TARGET[arm] = "${RUST_TARGET_SYS}"
+TARGET_ENDIAN[arm] = "little"
+TARGET_POINTER_WIDTH[arm] = "32"
+TARGET_C_INT_WIDTH[arm] = "32"
+MAX_ATOMIC_WIDTH[arm] = "64"
+FEATURES[arm] = "+v6,+vfp2"
  
  ## armv7-unknown-linux-gnueabihf

  DATA_LAYOUT[armv7-eabi] = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"

We've dropped this patch from testing. Why? It has been sent in a few
different
forms and testing shows there are deeper problems which need to be solved
including that the automated testing results are erratic.

The big issue is that changes here don't seem to invalidate the sstate cache.
This means that tests "pass" on the autobuilder initially but then when some
later change does cause a rebuild of this code, it then fails.

As such I have no confidence this change is correct, tested or won't cause
future failures.

The issue is that changes to the data above are not being reflected in task
sstate signatures. We need to debug and fix the 

[OE-core] [meta][dunfell][PATCH] fribidi: Add fix for CVE-2022-25308, CVE-2022-25309 and CVE-2022-25310

[Pawan Badganchi]

From: Pawan Badganchi 

Add below patches to fix CVE-2022-25308, CVE-2022-25309 and CVE-2022-25310

CVE-2022-25308.patch
Link: 
https://github.com/fribidi/fribidi/commit/ad3a19e6372b1e667128ed1ea2f49919884587e1

CVE-2022-25309.patch
Link: 
https://github.com/fribidi/fribidi/commit/f22593b82b5d1668d1997dbccd10a9c31ffea3b3

CVE-2022-25310.patch
Link:https://github.com/fribidi/fribidi/commit/175850b03e1af251d705c1d04b2b9b3c1c06e48f

Signed-off-by: Pawan Badganchi 
---
 .../fribidi/fribidi/CVE-2022-25308.patch  | 50 +++
 .../fribidi/fribidi/CVE-2022-25309.patch  | 31 
 .../fribidi/fribidi/CVE-2022-25310.patch  | 30 +++
 meta/recipes-support/fribidi/fribidi_1.0.9.bb |  3 ++
 4 files changed, 114 insertions(+)
 create mode 100644 meta/recipes-support/fribidi/fribidi/CVE-2022-25308.patch
 create mode 100644 meta/recipes-support/fribidi/fribidi/CVE-2022-25309.patch
 create mode 100644 meta/recipes-support/fribidi/fribidi/CVE-2022-25310.patch

diff --git a/meta/recipes-support/fribidi/fribidi/CVE-2022-25308.patch 
b/meta/recipes-support/fribidi/fribidi/CVE-2022-25308.patch
new file mode 100644
index 00..8f2c2ade0e
--- /dev/null
+++ b/meta/recipes-support/fribidi/fribidi/CVE-2022-25308.patch
@@ -0,0 +1,50 @@
+From ad3a19e6372b1e667128ed1ea2f49919884587e1 Mon Sep 17 00:00:00 2001
+From: Akira TAGOH 
+Date: Thu, 17 Feb 2022 17:30:12 +0900
+Subject: [PATCH] Fix the stack buffer overflow issue
+
+strlen() could returns 0. Without a conditional check for len,
+accessing S_ pointer with len - 1 may causes a stack buffer overflow.
+
+AddressSanitizer reports this like:
+==1219243==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ffdce043c1f at pc 0x00403547 bp 0x7ffdce0
+43b30 sp 0x7ffdce043b28
+READ of size 1 at 0x7ffdce043c1f thread T0
+#0 0x403546 in main ../bin/fribidi-main.c:393
+#1 0x7f226804e58f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
+#2 0x7f226804e648 in __libc_start_main_impl (/lib64/libc.so.6+0x2d648)
+#3 0x4036f4 in _start (/tmp/fribidi/build/bin/fribidi+0x4036f4)
+
+Address 0x7ffdce043c1f is located in stack of thread T0 at offset 63 in frame
+#0 0x4022bf in main ../bin/fribidi-main.c:193
+
+  This frame has 5 object(s):
+[32, 36) 'option_index' (line 233)
+[48, 52) 'base' (line 386)
+[64, 65064) 'S_' (line 375) <== Memory access at offset 63 underflows this 
variable
+[65328, 130328) 'outstring' (line 385)
+[130592, 390592) 'logical' (line 384)
+
+This fixes https://github.com/fribidi/fribidi/issues/181
+
+CVE: CVE-2022-25308
+Upstream-Status: Backport 
[https://github.com/fribidi/fribidi/commit/ad3a19e6372b1e667128ed1ea2f49919884587e1]
+Signed-off-by: Pawan Badganchi 
+
+---
+ bin/fribidi-main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bin/fribidi-main.c b/bin/fribidi-main.c
+index 3cf9fe1..3ae4fb6 100644
+--- a/bin/fribidi-main.c
 b/bin/fribidi-main.c
+@@ -390,7 +390,7 @@ FRIBIDI_END_IGNORE_DEPRECATIONS
+   S_[sizeof (S_) - 1] = 0;
+   len = strlen (S_);
+   /* chop */
+-  if (S_[len - 1] == '\n')
++  if (len > 0 && S_[len - 1] == '\n')
+ {
+   len--;
+   S_[len] = '\0';
diff --git a/meta/recipes-support/fribidi/fribidi/CVE-2022-25309.patch 
b/meta/recipes-support/fribidi/fribidi/CVE-2022-25309.patch
new file mode 100644
index 00..0efba3d05c
--- /dev/null
+++ b/meta/recipes-support/fribidi/fribidi/CVE-2022-25309.patch
@@ -0,0 +1,31 @@
+From f22593b82b5d1668d1997dbccd10a9c31ffea3b3 Mon Sep 17 00:00:00 2001
+From: Dov Grobgeld 
+Date: Fri, 25 Mar 2022 09:09:49 +0300
+Subject: [PATCH] Protected against garbage in the CapRTL encoder
+
+CVE: CVE-2022-25309
+Upstream-Status: Backport 
[https://github.com/fribidi/fribidi/commit/f22593b82b5d1668d1997dbccd10a9c31ffea3b3]
+Signed-off-by: Pawan Badganchi 
+
+---
+ lib/fribidi-char-sets-cap-rtl.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/lib/fribidi-char-sets-cap-rtl.c b/lib/fribidi-char-sets-cap-rtl.c
+index b0c0e4a..f74e010 100644
+--- a/lib/fribidi-char-sets-cap-rtl.c
 b/lib/fribidi-char-sets-cap-rtl.c
+@@ -232,7 +232,12 @@ fribidi_cap_rtl_to_unicode (
+   }
+   }
+   else
+-  us[j++] = caprtl_to_unicode[(int) s[i]];
++  {
++if ((int)s[i] < 0)
++  us[j++] = '?';
++else
++  us[j++] = caprtl_to_unicode[(int) s[i]];
++  }
+ }
+ 
+   return j;
diff --git a/meta/recipes-support/fribidi/fribidi/CVE-2022-25310.patch 
b/meta/recipes-support/fribidi/fribidi/CVE-2022-25310.patch
new file mode 100644
index 00..d79a82d648
--- /dev/null
+++ b/meta/recipes-support/fribidi/fribidi/CVE-2022-25310.patch
@@ -0,0 +1,30 @@
+From 175850b03e1af251d705c1d04b2b9b3c1c06e48f Mon Sep 17 00:00:00 2001
+From: Akira TAGOH 
+Date: Thu, 17 Feb 2022 19:06:10 +0900
+Subject: [PATCH] Fix SEGV issue in fribidi_remove_bidi_marks
+
+Escape from 

[OE-core] [meta][dunfell][PATCH] libinput: Add fix for CVE-2022-1215

[Pawan Badganchi]

From: Pawan Badganchi 

Add below patch to fix CVE-2022-1215

CVE-2022-1215.patch
Link: 
https://gitlab.freedesktop.org/libinput/libinput/-/commit/2a8b8fde90d63d48ce09ddae44142674bbca1c28

Signed-off-by: Pawan Badganchi
---
 .../wayland/libinput/CVE-2022-1215.patch  | 361 ++
 .../wayland/libinput_1.15.2.bb|   1 +
 2 files changed, 362 insertions(+)
 create mode 100644 meta/recipes-graphics/wayland/libinput/CVE-2022-1215.patch

diff --git a/meta/recipes-graphics/wayland/libinput/CVE-2022-1215.patch 
b/meta/recipes-graphics/wayland/libinput/CVE-2022-1215.patch
new file mode 100644
index 00..5f8f7a9894
--- /dev/null
+++ b/meta/recipes-graphics/wayland/libinput/CVE-2022-1215.patch
@@ -0,0 +1,361 @@
+From 2a8b8fde90d63d48ce09ddae44142674bbca1c28 Mon Sep 17 00:00:00 2001
+From: Peter Hutterer 
+Date: Wed, 30 Mar 2022 09:25:22 +1000
+Subject: [PATCH] evdev: strip the device name of format directives
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This fixes a format string vulnerabilty.
+
+evdev_log_message() composes a format string consisting of a fixed
+prefix (including the rendered device name) and the passed-in format
+buffer. This format string is then passed with the arguments to the
+actual log handler, which usually and eventually ends up being printf.
+
+If the device name contains a printf-style format directive, these ended
+up in the format string and thus get interpreted correctly, e.g. for a
+device "Foo%sBar" the log message vs printf invocation ends up being:
+  evdev_log_message(device, "some message %s", "some argument");
+  printf("event9 - Foo%sBar: some message %s", "some argument");
+
+This can enable an attacker to execute malicious code with the
+privileges of the process using libinput.
+
+To exploit this, an attacker needs to be able to create a kernel device
+with a malicious name, e.g. through /dev/uinput or a Bluetooth device.
+
+To fix this, convert any potential format directives in the device name
+by duplicating percentages.
+
+Pre-rendering the device to avoid the issue altogether would be nicer
+but the current log level hooks do not easily allow for this. The device
+name is the only user-controlled part of the format string.
+
+A second potential issue is the sysname of the device which is also
+sanitized.
+
+This issue was found by Albin Eldstål-Ahrens and Benjamin Svensson from
+Assured AB, and independently by Lukas Lamster.
+
+Fixes #752
+
+Signed-off-by: Peter Hutterer 
+(cherry picked from commit a423d7d3269dc32a87384f79e29bb5ac021c83d1)
+
+CVE: CVE-2022-1215
+Upstream Status: Backport 
[https://gitlab.freedesktop.org/libinput/libinput/-/commit/2a8b8fde90d63d48ce09ddae44142674bbca1c28]
+Signed-off-by: Pawan Badganchi 
+
+---
+ meson.build|  1 +
+ src/evdev.c| 31 +++--
+ src/evdev.h|  6 ++--
+ src/util-strings.h | 30 
+ test/litest-device-format-string.c | 56 ++
+ test/litest.h  |  1 +
+ test/test-utils.c  | 26 ++
+ 7 files changed, 139 insertions(+), 12 deletions(-)
+ create mode 100644 test/litest-device-format-string.c
+
+diff --git a/meson.build b/meson.build
+index 90f528e6..1f6159e7 100644
+--- a/meson.build
 b/meson.build
+@@ -787,6 +787,7 @@
+   'test/litest-device-dell-canvas-totem-touch.c',
+   'test/litest-device-elantech-touchpad.c',
+   'test/litest-device-elan-tablet.c',
++  'test/litest-device-format-string.c',
+   'test/litest-device-generic-singletouch.c',
+   'test/litest-device-gpio-keys.c',
+   'test/litest-device-huion-pentablet.c',
+diff --git a/src/evdev.c b/src/evdev.c
+index 6d81f58f..d1c35c07 100644
+--- a/src/evdev.c
 b/src/evdev.c
+@@ -2356,19 +2356,19 @@ evdev_device_create(struct libinput_seat *seat,
+   struct libinput *libinput = seat->libinput;
+   struct evdev_device *device = NULL;
+   int rc;
+-  int fd;
++  int fd = -1;
+   int unhandled_device = 0;
+   const char *devnode = udev_device_get_devnode(udev_device);
+-  const char *sysname = udev_device_get_sysname(udev_device);
++  char *sysname = str_sanitize(udev_device_get_sysname(udev_device));
+ 
+   if (!devnode) {
+   log_info(libinput, "%s: no device node associated\n", sysname);
+-  return NULL;
++  goto err;
+   }
+ 
+   if (udev_device_should_be_ignored(udev_device)) {
+   log_debug(libinput, "%s: device is ignored\n", sysname);
+-  return NULL;
++  goto err;
+   }
+ 
+   /* Use non-blocking mode so that we can loop on read on
+@@ -2382,13 +2382,15 @@ evdev_device_create(struct libinput_seat *seat,
+sysname,
+devnode,
+