February 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1177260] Switching python-numpy to plain BLAS causes significant performance regression
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1177260 https://bugzilla.suse.com/show_bug.cgi?id=1177260#c46 --- Comment #46 from Egbert Eich <eich(a)suse.com> --- (In reply to Stefan Br�ns from comment #45) > > I think for Leap/SLE 15, the old SONAME is actually the better option. > Otherwise, you need a full rebuild (at least the parts which directly or > indirectly use openblas), othwerwise you may end up with a binary which > links to openblas.so and openblas_pthreads.so at the same time. > > If you don't do a rebuild, you may end up with a user using the openmp > openblas.so via update alternatives, and openblas_pthreads.so. I a quite > sure this will not work. Well, the old SONAME scheme would require even more %if ... %endif mess in the spec file. All standard binaries are built for openblas_pthreads.so.0. If we provide a compatibility link, why would a user end up with two openblas libraries? Because of a binary requiring two libs that themselves require openblas - one of which has been rebuilt and one hasn't? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1208567] qemu-system-x86_64: Failed to lock byte 100
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1208567 https://bugzilla.suse.com/show_bug.cgi?id=1208567#c11 James Fehlig <jfehlig(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ddiss(a)suse.com |jfehlig(a)suse.com Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #11 from James Fehlig <jfehlig(a)suse.com> --- I've reproduced the issue and verified adding the lock access mode to /usr/share/qemu/** rule fixes it. David, no need for you to waste more time on this bug. But thanks for investigating and providing a fix! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1177260] Switching python-numpy to plain BLAS causes significant performance regression
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1177260 https://bugzilla.suse.com/show_bug.cgi?id=1177260#c45 --- Comment #45 from Stefan Br�ns <stefan.bruens(a)rwth-aachen.de> --- (In reply to Egbert Eich from comment #44) > (In reply to Stefan Br�ns from comment #42) > > (In reply to Egbert Eich from comment #29) > > > @Stefan Br�ns: I've finally fixed what you've suggested in comment #4 - all > > > flavors of OpenBLAS use the same SONAME so they can be used as plug-in > > > replacements. > > > You can find this in my home on OBS: home:eeich:branches:science/openblas - > > > this also contains some cleanups. If I don't hear any objections I will > > > submit it and later on push it to Factory. > > > > > > What hasn't been done, yet, is to combine the lapack[e] & [c]blas libraries > > > to a block as you've suggested in comment #11. This would again require to > > > touch lapack and openblas. > > > > This broke building for a lot of packages in SLE/Leap in the science > > project, as numpy is not build with the changed SONAME, and thus becomes > > unresolvable (the openblas from the science project shadows the package from > > the regular repository). > > > > IMHO, this is an ABI breakage which has to be conditional. Only SLE/Leap > > 16/ALP should use the new name (and TW, of course). > > > > For the time being, I have disabled openblas' "use_for_build" for Leap 15.4. > > > We can only have one thing: either retain the old SONAMEs or have a working > update-alternatives on Leap. > The only alternative I can thin of and hat I could look into is to create a > libopenblas_pthread_compat package for SLE/Leap, with a > libopenblas_pthread.so.0 created from openblas-pthread/libopenblas.so.0 and > using patchelf to 'fix' the SONAME. > The default has been to use the pthread variant of openblas. Since the > dependency is on libopenblas_pthreads.so.0, it should be pulled in by zypper. I think for Leap/SLE 15, the old SONAME is actually the better option. Otherwise, you need a full rebuild (at least the parts which directly or indirectly use openblas), othwerwise you may end up with a binary which links to openblas.so and openblas_pthreads.so at the same time. If you don't do a rebuild, you may end up with a user using the openmp openblas.so via update alternatives, and openblas_pthreads.so. I a quite sure this will not work. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1207727] New: Latest update breaks MATE desktop
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1207727 Bug ID: 1207727 Summary: Latest update breaks MATE desktop Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Critical Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: llrainey15(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This weeks update breaks the Mate GUI. It says the window manger is not supported and all the executions pop up in the upper left hand corner and disappear if you move them. Going to reinstall 15.5 to see if that fixes the problem. The lastest DVD image has the same problem My config is: Install with plain desktop (not kde, gnome or xfce) network in network manager sshd is enabled no firewall MATE gui choosen in software setup /boot/efi partition / partition formated ext4 swap partition 16mb it says Window Manager is not supported if you attempt to set any defaults I have put back the vdi image from 1/24/23. I have chmod 000 zypper to prevent breaking 15.5. I don't know if it is MATE or the window manager is no longer supported. I can teamviewer or anydesk someone to watch - I can create a new one from the DVD image. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1200290] New: kerberized nfs mounts on a client-only config due not work due to rpc.gssd not being started
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1200290 Bug ID: 1200290 Summary: kerberized nfs mounts on a client-only config due not work due to rpc.gssd not being started Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: mephisto(a)gmx.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Build Identifier: I installed a fresh version of OpenSUSE Leap 15.4 RC, and tried to mount kerberized nfs mounts. After configuring the mount in the yast2 nfs-client module, it fails to mount. The documentation gives the hint to execute systemctl start rpc-gssd.service after which the mount succeeds. However, this does not survive a reboot, rpc.gssd does not get startet. systemctl enable rpc-gssd.service fails. The only workaround I found was to install the nfs-server component as well, and to start the nfs kernel server with no exports. This actually brings up rpc.gssd, and mounts succeed. Please fix. Reproducible: Always Steps to Reproduce: 1. Setup kerberized NFS server 2. install fresh version of OpenSUSE Leap 15.4 3. install yast2-nfs-client + dependencies, but not nfs-kernel-server 4. configure the GSS-secured mount in yast2 nfs-client module Actual Results: mount fails with error message mount.nfs: an incorrect mount option was specified Expected Results: mount succeeds When manually starting rpc.gssd by systemctl start rpc-gssd.service, and mounting afterwards, the mount succeeds. After a reboot, rpc-gssd.service is again not running, and mount fails. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1208645] New: Multiple screens stopped working with latest update
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208645 Bug ID: 1208645 Summary: Multiple screens stopped working with latest update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: X11 3rd Party Driver Assignee: gfx-bugs(a)suse.de Reporter: rosuna(a)suse.com QA Contact: sndirsch(a)suse.com Found By: Customer Blocker: --- Created attachment 865109 --> http://bugzilla.opensuse.org/attachment.cgi?id=865109&action=edit logs I've found this issue several times, last one happened in late January or early February. I'm using G06 nvidia propietary drivers, having a Lenovo Thinkpad P15 gen2 laptop. The laptop is using 3 external screens connected through a Dell dock station. Latest working snapshot is dated from February 10th, I can roll back to this one and everything will work well. First time I detected this problem was around the upgrade released on February 13th or 14th, with new nvidia drivers. I think there were newer ones released on 14th, but those have not helped either. I've just tried the upgrade again today, with the same symptoms: I'm using sssd and X11 (Tumbleweed defaults anyway), and I've lost one of my screens, and none of them is the main one any more (no menu bar). Right click on the desktop to set up screen preferences from plasma menu doesn't really make things better, it does detect the 3 screens + laptop screen (which I usually turn off), but one of the screens will never turn on, and no matter which one I select as primary, neither takes that setting (so as a result I'm still with no menu-bar in Plasma). Alt-tab does work and fortunately at least I have a console open to fetch some logs. I've tried to set up the monitors with nvidia-settings, but that did not work either. Last time I had this issue (or similar), it was solved by forcing remove the nvidia G06 driver, reinstalling it in a multi-user target and making sure prime-select would use nvidia. This time that did not do the trick. I'm attaching a few logs, but probably less than needed. Let me know if you need any other file, or if any other information is needed (because I know the bug description is not the best). -- You are receiving this mail because: You are on the CC list for the bug.

1 20

[Bug 1208636] New: [Build 20230223] sqlite 3.41.0: openQA test fails in __sqlite3_run-tests_t
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208636 Bug ID: 1208636 Summary: [Build 20230223] sqlite 3.41.0: openQA test fails in __sqlite3_run-tests_t Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/3141458/modules/__sq lite3_run-tests_t/steps/1 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation The test tries to run: sqlite3 --list --header /root/sqlite3/movies.db < /root/sqlite3/init-tables.sql init_tables.sql is the file as received from https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data… So essentially it does: CREATE TABLE directors (did integer primary key, name varchar(32)); CREATE TABLE movies (mid integer primary key, name varchar(64), year integer); --Rename tables here before adding FOREIGN KEYs. Older versions of sqlite3 --don't update the FKs when renaming tables ALTER TABLE movies RENAME TO movie; ALTER TABLE directors RENAME TO director; CREATE TABLE director_movie ( did integer, mid integer, FOREIGN KEY(did) REFERENCES director(did), FOREIGN KEY(mid) REFERENCES movie(mid) ); CREATE UNIQUE INDEX movie_dirx on director_movie(did,mid); INSERT INTO director (name) VALUES ("Jim Jarmusch"), ( "Tim Burton"); This test worked until sqlite 3.40, now with 3.41 it fails with: Parse error near line 17: no such column: Tim Burton T INTO director (name) VALUES ("Jim Jarmusch"), ( "Tim Burton"); error here ---^ openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_webserver@64bit fails in [__sqlite3_run-tests_t](https://openqa.opensuse.org/tests/3141458/modules/__… ## Test suite description ## Reproducible Fails since (at least) Build [20230223](https://openqa.opensuse.org/tests/3141458) (current job) ## Expected result Last good: [20230222](https://openqa.opensuse.org/tests/3139245) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1195633] New: Installing local RPM packages fails if /usr/bin/find is not installed
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1195633 Bug ID: 1195633 Summary: Installing local RPM packages fails if /usr/bin/find is not installed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: mls(a)suse.com Found By: --- Blocker: --- Installing local RPM files with either a dir:/foo repository or referring to the .rpm file directly does not work: 90d2e3700912:/ # zypper in rpms/libalternatives1-1.2+3.b848aad-2.2.x86_64.rpm Loading repository data... Reading installed packages... '_tmpRPMcache_:libalternatives1=0:1.2+3.b848aad-2.2' not found in package names. Trying capabilities. No provider of '_tmpRPMcache_:libalternatives1=0:1.2+3.b848aad-2.2' found. Resolving package dependencies... Nothing to do. 90d2e3700912:/ # zypper ar dir:/rpms dir Adding repository 'dir' ....................................................................................................................................................................................................................[done] Repository 'dir' successfully added URI : dir:/rpms Enabled : Yes GPG Check : Yes Autorefresh : No Priority : 99 (default priority) Repository priorities are without effect. All enabled repositories share the same priority. 90d2e3700912:/ # zypper in libalternatives1 Building repository 'dir' cache ............................................................................................................................................................................................................[done] Loading repository data... Reading installed packages... 'libalternatives1' not found in package names. Trying capabilities. No provider of 'libalternatives1' found. Resolving package dependencies... Nothing to do. 90d2e3700912:/ # zypper se -r dir Loading repository data... Reading installed packages... No matching items found. 2022-02-07 12:54:48 <1> 90d2e3700912(358) [DEFINE_LOGGROUP++] abstractspawnengine.cc(initEngineFromEnv):24 Starting processes via posix fork 2022-02-07 12:54:48 <1> 90d2e3700912(358) [DEFINE_LOGGROUP++] forkspawnengine.cc(start):186 Executing 'repo2solv' '-o' '/var/tmp/zypp.C5F1lq/zypper/_tmpRPMcache_/%SLV%/solv' '-X' '-R' '/var/tmp/zypp.C5F1lq/zypper/_tmpRPMcache_/%CLI%' 2022-02-07 12:54:48 <1> 90d2e3700912(358) [DEFINE_LOGGROUP++] forkspawnengine.cc(start):338 pid 360 launched 2022-02-07 12:54:48 <2> 90d2e3700912(358) [zypp] RepoManager.cc(buildCache):1401 /usr/bin/find: No such file or directory 2022-02-07 12:54:48 <2> 90d2e3700912(358) [zypp] RepoManager.cc(buildCache):1401 find: exit status 1 2022-02-07 12:54:48 <1> 90d2e3700912(358) [DEFINE_LOGGROUP++] abstractspawnengine.cc(checkStatus):180 Pid 360 successfully completed Looks like repo2solv needs a Requires: /usr/bin/find and proper error handling. After installing findutils, both work: 90d2e3700912:/ # zypper in rpms/libalternatives1-1.2+3.b848aad-2.2.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: libalternatives1 ... 90d2e3700912:/ # zypper -v ref -f dir ... 90d2e3700912:/ # zypper in libalternatives1 Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: libalternatives1 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1207724] gpg key generation must be aborted after having entered mismatches pass phrases
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1207724 https://bugzilla.suse.com/show_bug.cgi?id=1207724#c8 Pedro Monreal Gonzalez <pmonrealgonzalez(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #8 from Pedro Monreal Gonzalez <pmonrealgonzalez(a)suse.com> --- Thanks for the info, I can reproduce it in 15.4 but not in Factory, it seems only related to pinentry-gnome3. And, yes, the timeout can be short in some cases. We can increase it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1208660] New: opencores: Disable fbdev driver
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208660 Bug ID: 1208660 Summary: opencores: Disable fbdev driver Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: tzimmermann(a)suse.com Reporter: tzimmermann(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1193250 Found By: --- Blocker: --- Disable the fbdev driver for Opencores VGA chips, a homebrew, opensource HW design. Only affects ppc64/ppc64le. -- You are receiving this mail because: You are on the CC list for the bug.

1 1