January 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1177260] Switching python-numpy to plain BLAS causes significant performance regression
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1177260 https://bugzilla.suse.com/show_bug.cgi?id=1177260#c17 --- Comment #17 from Egbert Eich <eich(a)suse.com> --- (In reply to Stefan Br�ns from comment #16) > > life would be easier if 'osc build' would allow to pick up from and rerun later stages of the build process without having to go thru the 'build' stage every time :( > > ccache definitely helps. > > You can also "osc chroot" and rerun make after monkeypatching. Yes, I know, but it is clumsy and there is always the risk of forgetting to copy the specfile changes back from the chroot. After being sufficiently annoyed, I've addressed this issue now: https://github.com/openSUSE/obs-build/pull/647 https://github.com/openSUSE/osc/pull/887 Back to our topic: I've submitted the changes we've discussed just now: SR#860438 (openblas) SR#860439 (lapack) @Stefan - maybe you can give them a try. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1169874] [Build 20200417] Failure to boot due to resume=/dev/disk/by-path
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1169874 https://bugzilla.suse.com/show_bug.cgi?id=1169874#c26 --- Comment #26 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Josef Reidinger from comment #25) > (In reply to Fabian Vogt from comment #24) > > (In reply to Fabian Vogt from comment #23) > > > (In reply to Fabian Vogt from comment #22) > > > > (In reply to Josef Reidinger from comment #21) > > > > I tried the "generic desktop" role and even checked the "expand swap to ram" > > > > box, > > > > but didn't get "resume=". In openQA, it doesn't seem to be in any test, so > > > > also GNOME, > > > > KDE and so on, with several file systems. > > > > > > I found "# Do not propose resume on virtuals (jsc#SLE-12280)", so it's > > > probably > > > expected that it doesn't work in VMs. I'll try to fake real HW. > > > > Still didn't work. It seems like "propose_hibernation" is only enabled on > > SLED? > > that is strange, default should be true and base for SLE specify it false > and SLED then re-enable it. Are you sure that you have swap partition at > all? Or if you can, provide logs from your attempt and I can check it. Kernel.propose_hibernation? has: return false unless ProductFeatures.GetBooleanFeature("globals", "propose_hibernation") Wouldn't that have to be the following? return false unless ProductFeatures.GetBooleanFeatureWithFallback("globals", "propose_hibernation", true) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180568] New: Build for SLE_12_SP3_Backports/x86_64 fails with generic error "fg: no job control"
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180568 Bug ID: 1180568 Summary: Build for SLE_12_SP3_Backports/x86_64 fails with generic error "fg: no job control" Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: BuildService Assignee: screening-team-bugs(a)suse.de Reporter: piny(a)gmx.com QA Contact: adrian.schroeter(a)suse.com Found By: --- Blocker: --- As per [Build Log for SLE_12_SP3_Backports/x86_64] (https://build.opensuse.org/package/live_build_log/home:piny:branches:openSU…) (please check last view lines) the build fails with the generic error ``` [ 199s] + %make_build [ 199s] /var/tmp/rpm-tmp.5ieoez: line 56: fg: no job control [ 199s] error: Bad exit status from /var/tmp/rpm-tmp.5ieoez (%build) ``` All other build targets have completed successfully. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180493] MultiOS Flatpak Installation
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180493 https://bugzilla.suse.com/show_bug.cgi?id=1180493#c8 --- Comment #8 from Lukas Ocilka <locilka(a)suse.com> --- Hint: Automounting, and auto-creation of custom install configuration could be "easily" done via udev rules, see https://linux.die.net/man/7/udev Check /lib/udev/rules.d/* for examples. These rules can be very powerful. Ideally they are part of the Flatpak itself. PS: Some people label they disk (partition) as "FLATPAK". -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1169874] [Build 20200417] Failure to boot due to resume=/dev/disk/by-path
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1169874 https://bugzilla.suse.com/show_bug.cgi?id=1169874#c25 --- Comment #25 from Josef Reidinger <jreidinger(a)suse.com> --- (In reply to Fabian Vogt from comment #24) > (In reply to Fabian Vogt from comment #23) > > (In reply to Fabian Vogt from comment #22) > > > (In reply to Josef Reidinger from comment #21) > > > > (In reply to Fabian Vogt from comment #20) > > > > > (In reply to Ancor Gonzalez Sosa from comment #18) > > > > > > We have still not unified the YaST Bootloader and YaST Storage code, as we > > > > > > stated we should do in several comments. But we have implemented something > > > > > > that should fix the main problem described in this bug report. > > > > > > > > > > > > Starting with yast2-storage-ng 4.3.34, new swap devices will have a > > > > > > pre-generated UUID, which means that UUID will be used by the YaST > > > > > > Bootloader proposal if that's the default method. See more details at > > > > > > https://github.com/yast/yast-storage-ng/pull/1192 > > > > > > > > > > > > Submitted to TW as https://build.opensuse.org/request/show/858102 > > > > > > > > > > I'm trying to verify that this is fixed, but apparently none of the openQA > > > > > tests has "resume=" as part of the kernel cmdline or embedded in the initrd > > > > > at all anymore. I verified that with a local install. > > > > > > > > > > Is that intentional? > > > > > > > > Well, we have now flag that decide if we propose resume or not. But for > > > > opensuse it should propose it for x86_64 for non server roles if I remember > > > > correctly. > > > > It is part of feature to not propose hibernation on servers. > > > > > > I tried the "generic desktop" role and even checked the "expand swap to ram" > > > box, > > > but didn't get "resume=". In openQA, it doesn't seem to be in any test, so > > > also GNOME, > > > KDE and so on, with several file systems. > > > > I found "# Do not propose resume on virtuals (jsc#SLE-12280)", so it's > > probably > > expected that it doesn't work in VMs. I'll try to fake real HW. > > Still didn't work. It seems like "propose_hibernation" is only enabled on > SLED? that is strange, default should be true and base for SLE specify it false and SLED then re-enable it. Are you sure that you have swap partition at all? Or if you can, provide logs from your attempt and I can check it. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1179935] wpa_ supplicant option -u for dbus support seem to disable socket communication for e.g. wpa_cli
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1179935 https://bugzilla.suse.com/show_bug.cgi?id=1179935#c1 --- Comment #1 from Clemens Famulla-Conrad <cfamullaconrad(a)suse.com> --- right it doesn't work, even if we have ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel in our /etc/wpa_supplicant/wpa_supplicant.conf configuration. For me it worked to add `-O /var/run/wpa_supplicant` to the wpa_supplicant.service file. Let me double check why the ctrl_interface option is omitted, when passed via config, but not if we add it with the command line. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1169874] [Build 20200417] Failure to boot due to resume=/dev/disk/by-path
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1169874 https://bugzilla.suse.com/show_bug.cgi?id=1169874#c24 --- Comment #24 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Fabian Vogt from comment #23) > (In reply to Fabian Vogt from comment #22) > > (In reply to Josef Reidinger from comment #21) > > > (In reply to Fabian Vogt from comment #20) > > > > (In reply to Ancor Gonzalez Sosa from comment #18) > > > > > We have still not unified the YaST Bootloader and YaST Storage code, as we > > > > > stated we should do in several comments. But we have implemented something > > > > > that should fix the main problem described in this bug report. > > > > > > > > > > Starting with yast2-storage-ng 4.3.34, new swap devices will have a > > > > > pre-generated UUID, which means that UUID will be used by the YaST > > > > > Bootloader proposal if that's the default method. See more details at > > > > > https://github.com/yast/yast-storage-ng/pull/1192 > > > > > > > > > > Submitted to TW as https://build.opensuse.org/request/show/858102 > > > > > > > > I'm trying to verify that this is fixed, but apparently none of the openQA > > > > tests has "resume=" as part of the kernel cmdline or embedded in the initrd > > > > at all anymore. I verified that with a local install. > > > > > > > > Is that intentional? > > > > > > Well, we have now flag that decide if we propose resume or not. But for > > > opensuse it should propose it for x86_64 for non server roles if I remember > > > correctly. > > > It is part of feature to not propose hibernation on servers. > > > > I tried the "generic desktop" role and even checked the "expand swap to ram" > > box, > > but didn't get "resume=". In openQA, it doesn't seem to be in any test, so > > also GNOME, > > KDE and so on, with several file systems. > > I found "# Do not propose resume on virtuals (jsc#SLE-12280)", so it's > probably > expected that it doesn't work in VMs. I'll try to fake real HW. Still didn't work. It seems like "propose_hibernation" is only enabled on SLED? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180493] MultiOS Flatpak Installation
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180493 https://bugzilla.suse.com/show_bug.cgi?id=1180493#c7 Lukas Ocilka <locilka(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lubos.kocman(a)suse.com --- Comment #7 from Lukas Ocilka <locilka(a)suse.com> --- OK, then I was looking at it from the opposite side of the problem. My understanding was that the partition, volume or whatever should be recognized by any Linux distribution as a Flatpak installation automatically. This can works smoothly only when the installation contains some identification method. Something in a way "hey, I'm a Flatpak installation!" (your forum post even contains an idea about autodetection at system install time). The only pice of information which I was missing is that you want to use custom Flatpak installation for the trick. That's actually an interesting idea as you don't need to modify the default partitioning of the system - you can keep it and just add one more mount point. Anyway, there are some issues to solve: 1. How to identify a Flatpak installation? We definitely can't rely on the content in the partition / disks / ... Now it contains some directory structure, but that can change later. 2. Where to mount this automatically? As you want to use the custom installation feature, it can be mounted anywhere and every system that wants to use that installation needs to create a mount point and then create some new configuration file under /etc/flatpak/installations.d/ plus filling up some details about it it there. Both looks like something to be decided on openSUSE level or rather even by Flatpak developers. For that, you better open an Issue at their GitHub: https://github.com/flatpak/flatpak/issues Some people have already tried to solve similar problem, but they never got that far as having an automatic / semi-automatic support in any installer. See, for instance: https://github.com/flatpak/flatpak/issues/3620 https://github.com/flatpak/flatpak/issues/2337 https://github.com/flatpak/flatpak/issues/1224 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1174495] New: Vidcutter does not edit the outputfile
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1174495 Bug ID: 1174495 Summary: Vidcutter does not edit the outputfile Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: stakanov(a)freenet.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Vidcutter does, with the current edition, produce an output file that is twice the size of the m2t (as m2t edit) and does contain all cut out selections, so the file is simply doubled in size but not edited. The program is currently worthless. The program runs normally and does not through any error. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[opensuse-bugs] [Bug 1179284] New: Version 20201027 from UCODE-INTEL completely blocks booting
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1179284 Bug ID: 1179284 Summary: Version 20201027 from UCODE-INTEL completely blocks booting Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Major Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: ygrosjean(a)belgacom.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After applying update 2020-1923 of ��ucode-intel�� version 20201027, my laptop ASUS ZenBook UX305 (with 4 Intel processors) completely blocks at ��Loading initial ramdisk��: nothing at all happens. All the other updates could be installed without any problems, including kernel 5.3.18-lp152.50-default. Former versions of ��ucode-intel�� did not block booting. -- You are receiving this mail because: You are on the CC list for the bug.

1 5