May 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1218274] New: xfreerdp 2.4.0 Release 150400.3.23.1 fails with [ERROR][com.freerdp.core.fastpath]
by bugzilla_noreply＠suse.com 09 Jun '24

09 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1218274 Bug ID: 1218274 Summary: xfreerdp 2.4.0 Release 150400.3.23.1 fails with [ERROR][com.freerdp.core.fastpath] Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: haenig(a)cosifan.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0 Build Identifier: after updating freerdp to Release 150400.3.23.1 I am no longer able to connect to rdp Servers. After entering my password a window showing a fancy MS image as well as my logon name opens for a short time and then closes again on its own. the update has been done yesterday (2023-12-19) via 'zypper up' and therefore changed/updated other packages as well. Reproducible: Always Steps to Reproduce: 1. launch new rdp session (see details) 2. enter password Actual Results: # initiate session openconnect-leap:~> xfreerdp /kbd:0x00000407 /u:myusername /d:mydomain /v:myserverip [13:43:00:529] [6614:6615] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state [13:43:00:529] [6614:6615] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr [13:43:00:529] [6614:6615] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd [13:43:00:529] [6614:6615] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [13:43:00:843] [6614:6615] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized [13:43:00:845] [6614:6615] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state [13:43:00:845] [6614:6615] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state [13:43:00:102] [6614:6615] [WARN][com.freerdp.crypto] - Certificate verification failure 'self signed certificate (18)' at stack position 0 [13:43:00:103] [6614:6615] [WARN][com.freerdp.crypto] - CN = myservername.mydomain Password: [13:43:07:261] [6614:6615] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32 [13:43:07:262] [6614:6615] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16 [13:43:07:279] [6614:6615] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem [13:43:07:287] [6614:6615] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd [13:43:14:705] [6614:6615] [ERROR][com.freerdp.core.fastpath] - Fastpath update Bitmap [1] failed, status 0 [13:43:14:705] [6614:6615] [ERROR][com.freerdp.core.fastpath] - fastpath_recv_update_data: fastpath_recv_update() - -1 [13:43:14:705] [6614:6615] [ERROR][com.freerdp.core.fastpath] - fastpath_recv_update_data() fail [13:43:14:706] [6614:6615] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -3 [13:43:14:706] [6614:6615] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0 [13:43:14:706] [6614:6615] [INFO][com.freerdp.client.common] - Network disconnect! [13:43:14:706] [6614:6615] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor Expected Results: working rdesktop session with freerdp 2.4.0 Release 150400.3.20.1 everything was working O.K. Example: lverm@openvpn-leap:~> xfreerdp /kbd:0x00000407 /u:myusername /d:mydomain /v:myserverip [13:49:37:746] [3026:3027] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state [13:49:37:746] [3026:3027] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr [13:49:37:746] [3026:3027] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd [13:49:37:746] [3026:3027] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr [13:49:37:066] [3026:3027] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized [13:49:37:068] [3026:3027] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state [13:49:37:068] [3026:3027] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state [13:49:37:274] [3026:3027] [WARN][com.freerdp.crypto] - Certificate verification failure 'self signed certificate (18)' at stack position 0 [13:49:37:274] [3026:3027] [WARN][com.freerdp.crypto] - CN = myservername.mydomain Password: [13:49:50:584] [3026:3027] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRX32 [13:49:50:584] [3026:3027] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16 [13:49:50:617] [3026:3027] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem [13:49:50:637] [3026:3027] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd [13:49:55:507] [3026:3027] [INFO][com.freerdp.client.x11] - Logon Error Info SESSION_ID [LOGON_MSG_SESSION_CONTINUE] => here I have window open with a working rdp session -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1222534] New: No wired network after hibernation
by bugzilla_noreply＠suse.com 09 Jun '24

09 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1222534 Bug ID: 1222534 Summary: No wired network after hibernation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: jonzn4suse(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Operating System: openSUSE Tumbleweed 20240405 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.4-rc1-1-default (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5825U with Radeon Graphics Memory: 62.1 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: HP Product Name: HP ProBook 455 15.6 inch G9 Notebook PC System Version: SBKPF I can turn on WiFi and it works, but to fix the wired issue, I have to reboot. The below logs keeps repeating until a reboot. LOGS: Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.4741] device (enp1s0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <warn> [1712657390.4744] device (enp1s0): Activation: failed for connection 'Wired Connection' Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.4744] device (enp1s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5233] dhcp4 (enp1s0): canceled DHCP transaction Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5233] dhcp4 (enp1s0): activation: beginning transaction (timeout in 45 seconds) Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5233] dhcp4 (enp1s0): state changed no lease Tuesday, April 9, 2024 6:09:50 AM EDT kernel r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon Files changed, reloading. Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon No service file found in /etc/avahi/services. Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5760] policy: auto-activating connection 'Wired Connection' (21000dbf-984d-4441-91e7-1f4c01a5b834) Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5763] device (enp1s0): Activation: starting connection 'Wired Connection' (21000dbf-984d-4441-91e7-1f4c01a5b834) Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5764] device (enp1s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5766] device (enp1s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT kernel r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5937] device (enp1s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Tuesday, April 9, 2024 6:09:50 AM EDT NetworkManager <info> [1712657390.5939] dhcp4 (enp1s0): activation: beginning transaction (timeout in 45 seconds) Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon Files changed, reloading. Tuesday, April 9, 2024 6:09:50 AM EDT avahi-daemon No service file found in /etc/avahi/services. I will also test sleep to see if it has the same issue. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1222761] New: wxWidgets needs to be compiled with spellcheck
by bugzilla_noreply＠suse.com 08 Jun '24

08 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1222761 Bug ID: 1222761 Summary: wxWidgets needs to be compiled with spellcheck Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: aaron.w2(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I am trying to build an updated kiCad 8.0 and it requires wxWidgets and wxPython with Python > 3.6. Kicad requires wxWidgets >= 3.0.5 so I am trying to build with wxWidgets 3.2. Unfortunately, the wxWidgets supplied with OpenSUSE is not built with spellcheck enabled which is required for wxPython. Can wxWidgets be built with --enable-spellcheck in the configure phase? -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1224457] New: Kernel: Sound: AMD cpu with graphics + ASUS motherboard with ALC 887
by bugzilla_noreply＠suse.com 07 Jun '24

07 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1224457 Bug ID: 1224457 Summary: Kernel: Sound: AMD cpu with graphics + ASUS motherboard with ALC 887 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: andrwlms(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Installation of Leap 15.5 or Tumbleweed on a machine with an AMD APU on an ASUS Prime B550-Plus (uses Realtek ALC 887 for sound) results in no sound from the motherboard. This is discussed in a thread on openSuSE forums: English language, Hardware forum, "5700G+ALC887" thread title. This has been explored with aplay -l, inxi -Axx, dmesg | grep snd_hda, lsmod and modprobe. It is apparently a matter of detection of the motherboard sound "card" in the presence of the CPU's integrated sound "card". This is apparently a bug in the kernel, not openSuSE, since installation of Linux Mint on the same hardware causes exactly the same problem, including identical output from aplay -l, inxi -Axx and dmesg | grep snd_hda. -- You are receiving this mail because: You are on the CC list for the bug.

1 45

[Bug 1213370] New: tesseract-ocr should not be built with experimantal opencl support
by bugzilla_noreply＠suse.com 07 Jun '24

07 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1213370 Bug ID: 1213370 Summary: tesseract-ocr should not be built with experimantal opencl support Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)titlis.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- opencl in tesseract-ocr is considered experimental, according to this thread (https://groups.google.com/g/tesseract-ocr/c/eIQbsurfSEM/m/mVb_4GF1BgAJ) it is considered just an entry point for possible developers. Their own doucmentantion (https://tesseract-ocr.github.io/tessdoc/TesseractOpenCL.html) states: "Important note: OpenCL support in Tesseract is still considered experimental. There are some major bugs associated with it (see issue 837). Building Tesseract with OpenCL support is not recommended (for any version of Tesseract), unless you are a developer and want to improve the OpenCL code" Please remove the flag "--enable-opencl" from https://build.opensuse.org/package/view_file/openSUSE:Factory/tesseract-ocr… This would also resolve https://bugzilla.opensuse.org/show_bug.cgi?id=1207570 PS: I indeed encounter problems with the opencl code path -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1225296] New: Dual monitor not recognised after upgrade 15.5 to 15.6
by bugzilla_noreply＠suse.com 07 Jun '24

07 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1225296 Bug ID: 1225296 Summary: Dual monitor not recognised after upgrade 15.5 to 15.6 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: martin.schmidt(a)io-warnemuende.de QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Moin, moin, I am using openSUSE 15.5 on an old intel based x86 PC, equipped with a simple nvidia gforce and two monitors. The monitors are using a displayport connnection from the graphics card to the monitors via an Y-shaped cable. Both monitors are recognised correctly and can be configured to form a single graphical work space, when the system is up and running. After upgrading to openSUSE 15.6 this does not work any more. When booting, monitor 1 shows some firmware screen and the openSUSE boot screen, where the OS version (several subversions of 15.6 and frozen snapshots of 15.5) can be selected. Using the default option (15.6 from harddrive), the output of the boot process is moving to monitor 2, but monitor 1 is going to a "power saving sleep mode" and stays inactive frome here on. The boot process is finished correctly with monitor 2 as the only graphical device. Monitor 1 cannot be activated again. Switching off monitor 2 before booting, the system comes up without any valid output device. Monitor 1 goes to sleep after the system boot started. I did not check the system status with a remote ssh-connection yet. Switching off monitor 1 before booting, lets the system come up completely with monitor 2. Also the initial hardware screen is diplayerd there. In turn, booting from a read-only snapshot with openSUSE 15.5, both monitors are used as before. The nouveau-dri drivers are used, no propriatary nvidia driver is installed. Some upgrade history: - just to test, if the few graphic card cores could be used in a cuda environment, cuda was installed under 15.5. This failed and cuda was deinstalled. However, when upgrading later from 15.5 to 15.6 the cuda development environment was reinstalled automatically together with nvidia drivers. As a result the nvidia drivers allowed only for a single low resolution vga monitor. May be, this happened, since the nvidia repository was not deleted and there was some leftover from the cuda test. - with the ascii-yast the nvidia drivers (gforce003/004) and cuda could be removed and the nouveau-dri drivers where reinstalled - together with dependencies. This allows for a single monitor OS_15.6 system with high resolution, but the second monitor (monitor 1) is lost during the boot process as described above. Before I try to install from scratch just with the hope that the error goes away, I am reporting this strange behaviour here. May be, this helps to streamline the distribution. Any hints are very welcome - especially how to modify the bootloader options. Cheers, Martin Schmidt -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1224165] New: AUDIT-0: openSUSE Leap 15.6 Gold Master security audit
by bugzilla_noreply＠suse.com 07 Jun '24

07 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1224165 Bug ID: 1224165 Summary: AUDIT-0: openSUSE Leap 15.6 Gold Master security audit Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello team this is a request to audit openSUSE:Leap:15.6 GoldMaster code deadline is same as for SLES 15 SP6 GM (May 16th). Our roadmap says: Wed, May 16, 2022 Gold Master code submission deadline built should be within a week from there. However it's all driven by GMC acceptance for SUSE Linux Enterprise 15 SP6 The poo tracker: https://progress.opensuse.org/issues/131864 Leap 15.6 Schedule https://en.opensuse.org/openSUSE:Roadmap#Schedule_for_openSUSE_Leap_15.6 -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1224781] New: VUL-0: CVE-2024-35192: trivy: credential leak via malicious registry
by bugzilla_noreply＠suse.com 07 Jun '24

07 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1224781 Bug ID: 1224781 Summary: VUL-0: CVE-2024-35192: trivy: credential leak via malicious registry Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/406773/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: dmueller(a)suse.com Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: carlos.lopez(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- Trivy is a security scanner. Prior to 0.51.2, if a malicious actor is able to trigger Trivy to scan container images from a crafted malicious registry, it could result in the leakage of credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR). These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. Systems are not affected if the default credential provider chain is unable to obtain valid credentials. This vulnerability only applies when scanning container images directly from a registry. This vulnerability is fixed in 0.51.2. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-35192 https://www.cve.org/CVERecord?id=CVE-2024-35192 https://github.com/aquasecurity/trivy/commit/e7f14f729de259551203f313e57d2d… https://github.com/aquasecurity/trivy/security/advisories/GHSA-xcq4-m2r3-cm… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1212909] New: unstripped-binary-or-object for binary libraries in Python directories
by bugzilla_noreply＠suse.com 07 Jun '24

07 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1212909 Bug ID: 1212909 Summary: unstripped-binary-or-object for binary libraries in Python directories Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Python Assignee: python-maintainers(a)suse.com Reporter: mcepl(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- There is a zillion packages which end up with the warning like python311-scipy.x86_64: W: unstripped-binary-or-object /usr/lib64/python3.11/site-packages/scipy/spatial/_qhull.cpython-311-x86_64-linux-gnu.so (this is from https://build.opensuse.org/package/live_build_log/home:gladiac:mailman/pyth…) Interestingly the same package in the devel project doesn’t seem to present the same problem (https://build.opensuse.org/build/devel:languages:python:numeric/openSUSE_Tu…). Could we find out why these happen and do something about it? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1225298] New: systemd-boot fails to boot 6.9.1
by bugzilla_noreply＠suse.com 06 Jun '24

06 Jun '24

https://bugzilla.suse.com/show_bug.cgi?id=1225298 Bug ID: 1225298 Summary: systemd-boot fails to boot 6.9.1 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: db(a)mail25.net QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 875116 --> https://bugzilla.suse.com/attachment.cgi?id=875116&action=edit screen photo Installed TW with systemd-boot about a month ago, updated today to 20240523, rebooted, everything seemed to work but noticed it was still on 6.8.8. Rebooted, selected 6.9.1 from the systemd-boot menu and it gets stuck while booting. Reaches target Initrd File System Times out waiting for device /dev/gpt-auto-root Attached a photo of the screen with boot messages. -- You are receiving this mail because: You are on the CC list for the bug.

1 1