November 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1192183] YaST2 internal error in forwardable.rb:227 'connected?' during "saving network configuration" step
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192183 https://bugzilla.suse.com/show_bug.cgi?id=1192183#c4 Knut Alejandro Anderssen Gonz�lez <kanderssen(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #4 from Knut Alejandro Anderssen Gonz�lez <kanderssen(a)suse.com> --- Fix has been created for this issue (https://github.com/yast/yast-network/pull/1263) (yast2-network-4.3.78) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192330] binutils: man pages are empty
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192330 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs(a)suse.de |matz(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1187915] VUL-0: CVE-2021-36082: ndpi: stack-based buffer overflow in processClientServerHello.
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1187915 https://bugzilla.suse.com/show_bug.cgi?id=1187915#c2 --- Comment #2 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- The Factory package by now is fixed via version update to 4.0. Leap:15.2 is still affected, though. Backporting the bugfix should not be a big thing and this issue is pretty serious, so please do it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1098219] python-bugzilla cannot auth at bugzilla.suse.com anymore
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1098219 https://bugzilla.suse.com/show_bug.cgi?id=1098219#c36 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(meissner(a)suse.com | |) | --- Comment #36 from Marcus Meissner <meissner(a)suse.com> --- openqa fail is unrelated. openqa does not test python-bugzilla I will just override opnqa for this -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192282] New: dnsmasq 2.86 does not handle DNSSEC well
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1192282 Bug ID: 1192282 Summary: dnsmasq 2.86 does not handle DNSSEC well Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Currently I can not resolve hosts which requires DNSSEC by configuration, first shown is the output of journalctl -b 0 --unit dnsmasq.service next is the resolve of www.heise.de: Nov 03 08:24:01 boole dnsmasq[21209]: reading /etc/dnsmasq.d/resolv.conf.dnsmasq Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain arch.suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain arch.suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.6#53 for domain nue.suse.com (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.70#53 for domain nue.suse.com (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain openvpn.suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain openvpn.suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.162.0.1#53 for domain qa.suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain qa.suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain suse.de (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain 10.in-addr.arpa (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain 10.in-addr.arpa (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain 16.172.in-addr.arpa (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain 16.172.in-addr.arpa (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain 168.192.in-addr.arpa (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain 168.192.in-addr.arpa (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.100.2.10#53 for domain suse.cz (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.70#53 for domain suse.cz (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 for domain opensuse.org (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 for domain opensuse.org (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.67.0.8#53 for domain suse.asia (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.70#53 for domain suse.asia (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.84.2.20#53 for domain suse.net (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.70#53 for domain suse.net (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.6#53 for domain suse.com (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.156.86.70#53 for domain suse.com (no DNSSEC) Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 2620:113:80c0:8080:10:160:0:1#53 Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 2620:113:80c0:8080:10:160:2:88#53 Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.2.88#53 Nov 03 08:24:01 boole dnsmasq[21209]: using nameserver 10.160.0.1#53 Nov 03 08:24:01 boole dnsmasq[21209]: read /etc/hosts - 18 addresses boole:~ # host www.heise.de 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: Host www.heise.de not found: 2(SERVFAIL) .... and now the journal again: Nov 01 08:20:40 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:40 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:48 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:48 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:48 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:50 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:50 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:50 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:50 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:51 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:51 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:58 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:58 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:20:58 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:05 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:05 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:14 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:14 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:21 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:21 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:27 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:27 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support Nov 01 08:21:36 boole dnsmasq[25233]: Insecure DS reply received for com, check domain configuration and upstream DNS server DNSSEC support -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1192091] 5.14.14 assumes USB controller as dead
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192091 https://bugzilla.suse.com/show_bug.cgi?id=1192091#c9 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(stigpro(a)outlook.f | |r) --- Comment #9 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Nicolas FORMICHELLA from comment #8) > Thanks for that info, will try compiling my kernel from scratch and post > upstream if it is still broken Thanks! Meanwhile, I'm building three kernels to identify which patch breaks. OBS home:tiwai:bsc1192091-1 repo is with the revert of patches.kernel.org/5.14.12-007-usb-typec-tcpci-don-t-handle-vSafe0V-event-i…, OBS home:tiwai:bsc1192091-2 repo is with the revert of patches.kernel.org/5.14.12-008-usb-typec-tcpm-handle-SRC_STARTUP-state-if-c…, OBS home:tiwai:bsc1192091-3 repo is with the revert of patches.kernel.org/5.14.12-009-usb-typec-tipd-Remove-dependency-on-connecto…. Once when those get ready, please try one by one. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192288] amd64_edac_mod does not load after CPU upgrade
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192288 https://bugzilla.suse.com/show_bug.cgi?id=1192288#c15 --- Comment #15 from Borislav Petkov <bpetkov(a)suse.com> --- (In reply to Olav Reinert from comment #13) > Because of all this variety, any Leap user who invests in ECC memory really > really wants to see the line in the log stating that it is in fact enabled. And what happens if dmesg is overwritten because the ring buffer is too small or some kernel printk is too chatty? That line is gone so Leap user won't see a thing. > Forcing Leap users to turn on kernel debug info to get it completely voids > your intention of trimming down log noise (which is why you downgraded the > messages, I assume). > > Please undo that downgrade. I can (and will) file a separate bug report > about it, if you prefer. So all you want to know is whether your box has ECC enabled, correct? Two ways: 1. amd64_edac loads *only* when it has detected ECC - not otherwise. So the simple $ lsmod | grep amd64_edac amd64_edac 49152 0 already says that you have ECC. 2. Then, you can always do $ grep -r . /sys/devices/system/edac/ 2>/dev/null | grep -i edac_mode /sys/devices/system/edac/mc/mc0/rank7/dimm_edac_mode:SECDED /sys/devices/system/edac/mc/mc0/rank5/dimm_edac_mode:SECDED /sys/devices/system/edac/mc/mc0/csrow2/edac_mode:SECDED /sys/devices/system/edac/mc/mc0/rank6/dimm_edac_mode:SECDED /sys/devices/system/edac/mc/mc0/rank4/dimm_edac_mode:SECDED /sys/devices/system/edac/mc/mc0/csrow3/edac_mode:SECDED And that tells you, Single Error Correction, Double Error Detection which is the type of ECC supported by those DIMMs. And you can do that regardless of whether the dmesg circular buffer has been overwritten or not. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1098219] python-bugzilla cannot auth at bugzilla.suse.com anymore
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1098219 https://bugzilla.suse.com/show_bug.cgi?id=1098219#c35 Julio Gonz�lez Gil <jgonzalez(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(meissner(a)suse.com | |) --- Comment #35 from Julio Gonz�lez Gil <jgonzalez(a)suse.com> --- Marcus, it seems some openQA failed at https://build.opensuse.org/request/show/927740#comment-1541054, but I don't think they are related to the MU? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c17 --- Comment #17 from Alberto Planas Dominguez <aplanas(a)suse.com> --- (In reply to Hans-Peter Jansen from comment #16) > If it's, after all, "just" an "impedance mismatch" between llvm 13 and rust > 1.55, something in the interface logic between them is broken, and the > lesson learned from this should be at least: build rust only with the llvm, > that upstream uses. I made this suggestion in the PR that fixed the issue, but they make me to understand that: 1. llvm is very slow to compile, so when compiling rustc / cargo is good to use the llvm from the system to gain some speed. 2. rustc is expected to work with some range of llvm versions I think that they are fair points, and TW can help in detecting early issues. But still I think that there should be an outcome of this bug, like working on enabling the tests inside the %check section on the rust package. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192067] Rust1.55 miscompiles Firefox on Tumbleweed
by bugzilla_noreply＠suse.com 04 Nov '21

04 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192067 https://bugzilla.suse.com/show_bug.cgi?id=1192067#c16 Hans-Peter Jansen <hp.jansen(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hp.jansen(a)suse.com --- Comment #16 from Hans-Peter Jansen <hp.jansen(a)suse.com> --- Thanks guys, this is one of the most helpful bug records ever. @Manfred: I depend so much on Firefox for my daily work (the company driven with 1000 portals), that I've postponed any tests to the weekend, where I plan to test your builds. Thank you very much for providing them (including ESR builds). Because of https://bugzilla.mozilla.org/show_bug.cgi?id=1716989, I'm still on 91, but your builds might even make a difference in this respect as well, therefor I will gradually upgrade to your 91 build and (after another day with backup) to 94. @Aaron, @William, @Wolfgang: one thing, that makes me nervous is the errors behavior. In Firefox, it seems to be sandbox related, but no real failure there, apart from some hints of failing access to /dev/random. Why/how does this break specific areas like WebRTC only, while most of the rest is acting fine? Without understanding, what and how it is going wrong, we'll have a hard time to look for similar issues in other packages. If it's, after all, "just" an "impedance mismatch" between llvm 13 and rust 1.55, something in the interface logic between them is broken, and the lesson learned from this should be at least: build rust only with the llvm, that upstream uses. -- You are receiving this mail because: You are on the CC list for the bug.

1 0