January 2025 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1234858] New: Intel hybrid driver "hybrid_drv_video.so" for VA API (VAAPI) does not work
by bugzilla_noreply＠suse.com 15 Feb '25

15 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1234858 Bug ID: 1234858 Summary: Intel hybrid driver "hybrid_drv_video.so" for VA API (VAAPI) does not work Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 3rd Party Driver Assignee: gfx-bugs(a)suse.de Reporter: kaykaykay123(a)gmail.com QA Contact: sndirsch(a)suse.com Target Milestone: --- Found By: Community User Blocker: --- Intel hybrid driver "hybrid_drv_video.so" for VA API (VAAPI) does not work. It provides VP9 decoding for Intel GPUs from Haswell (maybe Ivy Bridge) till Skylake by using CPU together with GPU shaders. Package intel-hybrid-driver installs "hybrid_drv_video.so", requires package libcmrt1 to work. Link to package: https://software.opensuse.org/package/intel-hybrid-driver Intel-hybrid-driver is available for Leap - backported from SLE (bp156, bp155 prefixes). OpenSUSE uses 2 from 5 available patches. Possibly patch "U_Update-the-dependency-to-libva-2.0.patch" is not needed any more. https://build.opensuse.org/projects/X11:XOrg/packages/intel-hybrid-driver/f… Intel hybrid driver versions: https://repology.org/project/intel-hybrid-driver/versions Intel hybrid driver patches from Gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/intel-hybrid-code… After applying all 5 patches driver can be versioned as 2.0.0. To test intel-hybrid-driver you need to explicitly require it by using environment variable: "LIBVA_DRIVER_NAME=hybrid": Now it is :~> LIBVA_DRIVER_NAME=hybrid vainfo libva info: VA-API version 1.16.0 libva info: User environment variable requested driver 'hybrid' libva info: Trying to open /usr/lib64/dri/hybrid_drv_video.so libva error: /usr/lib64/dri/hybrid_drv_video.so has no function __vaDriverInit_1_0 libva info: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit Output for working driver radeonsi_drv_video.so: :~> vainfo libva info: VA-API version 1.16.0 libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_16 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.16 (libva 2.15.0) vainfo: Driver version: Mesa Gallium driver 22.3.5 for AMD Radeon Graphics (raven, LLVM 15.0.7, DRM 3.49, 5.14.21-150500.55.88-default) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileVP9Profile0 : VAEntrypointVLD VAProfileVP9Profile2 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc Output for working hybrid_drv_video.so on some old system: timo@Zeo ~ % export LIBVA_DRIVER_NAME=hybrid timo@Zeo ~ % vainfo libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 0 libva info: User requested driver 'hybrid' libva info: Trying to open /usr/lib64/va/drivers/hybrid_drv_video.so libva info: Found init function __vaDriverInit_0_34 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.38 (libva 1.6.1.pre1) vainfo: Driver version: Intel hybrid driver - 1.0.1.pre1 vainfo: Supported profile and entrypoints VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileVP9Profile0 : VAEntrypointVLD Exploring error "libva error: /usr/lib64/dri/hybrid_drv_video.so has no function __vaDriverInit_1_0" -> Finding vaDriverInit in intel-hybrid-driver driver: :~> /usr/bin/nm --demangle -D /home/mypc/Temp/intel-hybrid-driver-1.0.2-bp156.4.4.x86_64/usr/lib64/dri/hybrid_drv_video.so | grep vaDriverInit 000000000001c530 T __vaDriverInit_0_34 Finding vaDriverInit in radeonsi_drv_video.so driver from Mesa 22.3.5: :~> /usr/bin/nm --demangle -D /home/mypc/Temp/radeonsi_drv_video.so | grep vaDriverInit 0000000000068a90 T __vaDriverInit_1_16 ILL patch https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/intel-hybrid-code… is needed to solve that error. Conclusion: please apply all 5 patches: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/intel-hybrid-code… -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1236380] New: BUG: Unable to handle kernel data access on read at 0x17f9eb0000
by bugzilla_noreply＠suse.com 15 Feb '25

15 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1236380 Bug ID: 1236380 Summary: BUG: Unable to handle kernel data access on read at 0x17f9eb0000 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: PowerPC-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: gaurav.pathak(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 879937 --> https://bugzilla.suse.com/attachment.cgi?id=879937&action=edit hwinfo The issue is happening on POWER8E (PowerNV 8247-22L) running Kernel 6.4.0-150600.23.33-default causing the machine unreachable. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1225296] New: Dual monitor not recognised after upgrade 15.5 to 15.6
by bugzilla_noreply＠suse.com 15 Feb '25

15 Feb '25

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 34

[Bug 1221224] New: java-21-openjdk build-time race
by bugzilla_noreply＠suse.com 15 Feb '25

15 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1221224 Bug ID: 1221224 Summary: java-21-openjdk build-time race Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: fstrba(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1102408 Target Milestone: --- Found By: --- Blocker: --- Created attachment 873384 --> https://bugzilla.suse.com/attachment.cgi?id=873384&action=edit diff from build-compare While working on reproducible builds for openSUSE, I found that our java-21-openjdk binaries vary between 1-core and 4-core builds. https://rb.zq1.de/compare.factory-20240228/diffs/java-21-openjdk-compare.out has the diff (also attached) There may be additional issues from ASLR that I am still investigating. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1218136] New: Add Turkish F layout
by bugzilla_noreply＠suse.com 14 Feb '25

14 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1218136 Bug ID: 1218136 Summary: Add Turkish F layout Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: emir_sari(a)icloud.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Whilst installing Krypton, in the installer, there is no Turkish F layout, which also a common layout in Turkey, and used alongside the Q layout. Please add it as another option in the drop-down list. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1232744] New: Swedish keyboard layout dead-keys not working during password prompts
by bugzilla_noreply＠suse.com 14 Feb '25

14 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1232744 Bug ID: 1232744 Summary: Swedish keyboard layout dead-keys not working during password prompts Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Minor Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: paul.zeiger(a)physics.uu.se QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Running GDM and GNOME on OpenSuse Tumbleweed, I encounter a problem when entering characters ^, ¨, ~, ` or ´ in the GNOME password prompt such as during login or when I execute programs requiring root privileges on the command line. I have leanrt with the help of the OpenSuse Forum that all of these keys are entered using dead-keys in the Swedish keyboard layout and we have determined that this is probably a bug. You can find more information under this link: https://forums.opensuse.org/t/cannot-type-tilde-character-in-gnome-password… I don't encounter the same issue with other keyboard layouts such as the German or English layouts. My current workaround is to switch to one of these layouts for the password prompt or enter the character in question using the onscreen keyboard. Another fix seems to be to set the keyboard variant with the "nodeadkeys" option as suggested by arvidjaar in the forums: tw:/usr/share/X11/xkb # localectl --no-convert set-x11-keymap se "" nodeadkeys tw:/usr/share/X11/xkb # localectl System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: se X11 Variant: nodeadkeys tw:/usr/share/X11/xkb # I have not been able to verify this workaround for now, but will try it later today. It would be nice if this was fixed properly in the right place, but I have lived with this situation for a few months and I can use my system without a fix for now. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1231795] New: python3-config contains some garbage flags
by bugzilla_noreply＠suse.com 14 Feb '25

14 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1231795 Bug ID: 1231795 Summary: python3-config contains some garbage flags Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Python Assignee: python-maintainers(a)suse.com Reporter: jengelh(a)inai.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- OS: openSUSE Tumbleweed 20241016 Version: python311-devel-3.11.10-1.2.x86_64 Observed: $ >x.c; gcc `python3-config --cflags` -c x.c -Wmissing-include-dirs cc1: warning: Vendor/: No such file or directory [-Wmissing-include-dirs] Expected: Don't let -IVendor escape from the python internal build into the python3-config script. Since python3.pc does not have the problem, I wonder if anyone should even ever use python3-config to begin with. Opinions? -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1228165] New: Position of SUSE Python interpreters on Externally managed environments
by bugzilla_noreply＠suse.com 14 Feb '25

14 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1228165 Bug ID: 1228165 Summary: Position of SUSE Python interpreters on Externally managed environments 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 CC: dmueller(a)suse.com Target Milestone: --- Found By: --- Blocker: --- https://packaging.python.org/en/latest/specifications/externally-managed-en… This linked specification presents the use case rather well. Unlimited installation of Python packages can cause a serious damage, when the system component imports incompatible version of Python package instead of the intended one. (A parallel thought: are there any initiatives to port low-level components like firewalld to compiled languages? I know about firewalld-recode [1], but it seems to be quite dead). This specification tries to alleviate the problem by making it more difficult and painfully obvious that installing packages outside of the using system package manager is a wrong idea. That might be a good idea for normal users, but it seems like quite a bother for people who create containers, where the designers of such systems usually know what they are doing and who can check and test that nothing has been broken. The purpose of this bug is to discuss, whether we could produce some better solution to the problem, which wouldn’t be that obnoxious to our customers. One possible improvement would be to change our default hashbang to include `-s` parameter to calling our Python interpreters, so that modules in `$HOME` are not considered. Any possible improvements? [1] https://web.archive.org/web/20160318144103/https://fedorahosted.org/firewal… -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1236116] New: python-numpy: unreliable dot product calculation
by bugzilla_noreply＠suse.com 14 Feb '25

14 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1236116 Bug ID: 1236116 Summary: python-numpy: unreliable dot product calculation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Python Assignee: python-maintainers(a)suse.com Reporter: lpechacek(a)gmx.com QA Contact: qa-bugs(a)suse.de CC: eich(a)suse.com, stefan.bruens(a)rwth-aachen.de Target Milestone: --- Found By: --- Blocker: --- [CCing Egbert for HPC as the bug may be related to LAPACK and BLAS and Stefan who also maintains Rasterio] I've just spent two afternoons staring into Rasterio tests to root-cause its post-build test failures on i586 [1]. Rasterio uses Numpy for geodetic transformations and there are tests implemented in the package to ensure accuracy. All the tests pass on x86_64 but 15 tests fail on i586. All the test failures boil down to inaccurate calculation of one affine transformation. The minimal test case showing the failure is as follows: [newlines added for easier reading] -----------------------8<--------------------------- fmn:~ # chroot /var/tmp/build-root/openSUSE_Tumbleweed-i586 fmn:/ # python3 Python 3.11.11 (main, Dec 04 2024, 21:44:34) [GCC] on linux Type "help", "copyright", "credits" or "license" for more information. Could not open PYTHONSTARTUP FileNotFoundError: [Errno 2] No such file or directory: '/etc/pythonstart' >>> from numpy import (array, float64) >>> array([0.0033329119791008304, -339.9070281885982]) @ array([101985.0, 1]) np.float64(-2.275957200481571e-15) >>> float64(0.0033329119791008304) * float64(101985.0) + float64(-339.9070281885982) np.float64(0.0) ----------------------->8--------------------------- According to documentation, the dot product calculation performed by numpy.matmul (the @ operator) is accelerated with help of BLAS/LAPACK [2] but I don't see into the details as I never dealt with Numpy and LAPACK before. IMHO the inaccuracy in calculation is worth attention, and depending on the status of i586 in the openSUSE world, might be worth fixing. I'm filing the bug report in case someone has seen similar symptoms and/or knows what might be the cause. Thanks! [1] https://build.opensuse.org/package/show/Application:Geo/python-rasterio (will build again as soon as upgrade to 1.4.3 is accepted) [2] https://numpy.org/doc/stable/reference/generated/numpy.matmul.html -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1233732] New: plasmashell uses 100% cpu for wait pointer
by bugzilla_noreply＠suse.com 14 Feb '25

14 Feb '25

https://bugzilla.suse.com/show_bug.cgi?id=1233732 Bug ID: 1233732 Summary: plasmashell uses 100% cpu for wait pointer Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: jcarricksmith(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I have a Clevo laptop with both nvidia and intel graphics. Output from inxi -G follows: Graphics: Device-1: Intel CometLake-H GT2 [UHD Graphics] driver: i915 v: kernel Device-2: NVIDIA TU106BM [GeForce RTX 2070 Mobile] driver: nvidia v: 550.127.05 Device-3: Chicony USB2.0 Camera driver: uvcvideo type: USB Display: x11 server: X.Org v: 1.21.1.11 with: Xwayland v: 24.1.1 driver: X: loaded: intel,nvidia unloaded: modesetting dri: iris gpu: i915,nvidia,nvidia-nvswitch resolution: 1920x1080~144Hz API: OpenGL v: 4.6.0 NVIDIA 550.127.05 renderer: NVIDIA GeForce RTX 2070/PCIe/SSE2 This bug is new in openSUSE 15.6. When using the nvidia graphics the "wait pointer" spins at such a rate that it is a blur and plasmashell consumes 100% CPU as reported by top. This does not happen with intel graphics active. This is not a problem normally but on certain networks Network Manager's "Checking further connectivity" can last 10 minutes or so, with the circulating indicator spinning madly around the taskbar icon for Network Manager. Another manifestation of the problem is visible after logging in and before the desktop is displayed the "cog" indicator is a blur or appears to run backwards and then disappears and there is no indication of system activity except via the HDD activity light. Thanks John -- You are receiving this mail because: You are on the CC list for the bug.

1 1