June 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1119895] Factory: kmod fails to build on s390x
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=1119895 http://bugzilla.suse.com/show_bug.cgi?id=1119895#c4 --- Comment #4 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #3) > This should fix it. Let's see what upstream says. https://lore.kernel.org/lkml/20190605111416.13341-1-jslaby@suse.cz/T/#u -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1119895] Factory: kmod fails to build on s390x
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=1119895 http://bugzilla.suse.com/show_bug.cgi?id=1119895#c3 --- Comment #3 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #2) > We can also try pinging upstream about this, so that autogenerated headers > are not removed on make clean... This should fix it. Let's see what upstream says. --- linux-5.2-rc3-master.orig/arch/s390/tools/Makefile +++ linux-5.2-rc3-master/arch/s390/tools/Makefile @@ -7,6 +7,7 @@ kapi := arch/$(ARCH)/include/generated/a kapi-hdrs-y := $(kapi)/facility-defs.h $(kapi)/dis-defs.h targets += $(addprefix ../../../,$(kapi-hdrs-y)) +no-clean-files += $(targets) PHONY += kapi kapi: $(kapi-hdrs-y) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1137332] New: VUL-0: chromium: multiple security issues fixed in 75.0.3770.80
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1137332 Bug ID: 1137332 Summary: VUL-0: chromium: multiple security issues fixed in 75.0.3770.80 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: tchvatal(a)suse.com Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: Community User Blocker: --- https://chromereleases.googleblog.com/2019/06/stable-channel-update-for-des… Fixed in Chromium 75.0.3770.80: CVE-2019-5828: Use after free in ServiceWorker CVE-2019-5829: Use after free in Download Manager CVE-2019-5830: Incorrectly credentialed requests in CORS CVE-2019-5831: Incorrect map processing in V8 CVE-2019-5832: Incorrect CORS handling in XHR CVE-2019-5833: Inconsistent security UI placemen CVE-2019-5835: Out of bounds read in Swiftshader CVE-2019-5836: Heap buffer overflow in Angle CVE-2019-5837: Cross-origin resources size disclosure in Appcache CVE-2019-5838: Overly permissive tab access in Extensions CVE-2019-5839: Incorrect handling of certain code points in Blink CVE-2019-5840: Popup blocker bypass Various fixes from internal audits, fuzzing and other initiatives Other platforms: CVE-2019-5834: URL spoof in Omnibox on iOS -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1119895] Factory: kmod fails to build on s390x
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=1119895 http://bugzilla.suse.com/show_bug.cgi?id=1119895#c2 Jiri Slaby <jslaby(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby(a)suse.com, | |msuchanek(a)suse.com Flags| |needinfo?(msuchanek(a)suse.co | |m) --- Comment #2 from Jiri Slaby <jslaby(a)suse.com> --- Our rpm/kernel-binary.spec.in does: make clean $MAKE_ARGS prior to: find . ! -type d ! -name 'Module.base' ! -name 'Module.*-kmp' -printf '%%P\n' \ > %my_builddir/obj-files s390 does this on clean: archclean: $(Q)$(MAKE) $(clean)=$(boot) $(Q)$(MAKE) $(clean)=$(tools) But these two headers are generated in arch/s390/tools/: kapi-hdrs-y := $(kapi)/facility-defs.h $(kapi)/dis-defs.h So they are not a part of kernel-default-devel (and they should). We should perhaps add them to this list in the spec file: # These files are required for building external modules for FILE in arch/powerpc/lib/crtsavres.o arch/arm64/kernel/ftrace-mod.o arch/*/kernel/macros.s; do ... We can also try pinging upstream about this, so that autogenerated headers are not removed on make clean... What do you think? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1136601] Installed grub (grubaa64.efi) is not signed - Yast-bootloader does not support SecureBoot on aarch64
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=1136601 http://bugzilla.suse.com/show_bug.cgi?id=1136601#c13 Michael Chang <mchang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(guillaume.gardet@ | |arm.com) --- Comment #13 from Michael Chang <mchang(a)suse.com> --- Hi Guillaume, I renamed the option from --signed-grub to --suse-signed-grub, as conventionally we used suse prefix to distinguish with upstream options. The development of the patch enabling --suse-signed-grub support to grub2-install took place in the obs project. > https://build.opensuse.org/package/show/home:michael-chang:bsc:1136601/grub2 The patch name is grub2-secureboot-add-option-to-install-signed-grub.patch > https://build.opensuse.org/package/view_file/home:michael-chang:bsc:1136601… Use tab_size=8 for better viewing of the indention. You can branch from it to build your own test package, or you could use the published repository from the development project for testing. > https://download.opensuse.org/repositories/home:/michael-chang:/bsc:/113660… To test installing signed grub, run > grub2-install --suse-signed-grub or in addition with whatever options you may want to test altogether, for eg "--removable --no-nvram". The pubkey certificate exported from the development project which can be enrolled to Secure Boot's db to validate the signed image is located in > /usr/share/efi/x86_64/grub.der You may have to refer to firmware's manual for how-to enroll certificates, or the booting will fail with security violation if the grub.der is missing from firmware key store thus not trusted. So far I have done most testing on x64 with Secure Boot enabled, in combination with a handful of different setup to make sure the grub.cfg doing the right thing for the signed grub to find the real grub.cfg in the linux partition. Now it looks to me good enough for new test round on arm64, I planned to do it tomorrow, but we can work in parallel to speed things up. Please help to test on arm64. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1136927] [Build 20190528] System does not use same network names after update
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=1136927 Thomas Blume <thomas.blume(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dimstar(a)opensuse.org Flags| |needinfo?(dimstar@opensuse. | |org) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1110259] btrfsmaintenance update hangs waiting for job restarts
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.suse.com/show_bug.cgi?id=1110259 http://bugzilla.suse.com/show_bug.cgi?id=1110259#c11 --- Comment #11 from Stefan Seyfried <seife(a)novell.slipkontur.de> --- (In reply to Stefan Seyfried from comment #6) > \_ /usr/bin/systemctl try-restart btrfsmaintenance-refresh.service > btrfsmaintenance-refresh.path btrfs-balance.service btrfs-balance.timer > btrfs-defrag.service btrfs-defrag.timer btrfs-scrub.service > btrfs-scrub.timer btrfs-trim.service btrfs-trim.timer BTW: WTH do we restart the "services" on update? They are usually only triggered by timers anyway, so restarting the timers should be more than enough? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1137317] New: YaST doesn’t create HOME directory, missing Btrfs
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1137317 Bug ID: 1137317 Summary: YaST doesn’t create HOME directory, missing Btrfs Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: rolf.rudat(a)clintworld.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134 Build Identifier: Using ext3 on partitions /boot and /. Creating new users with yast works as long as yast assignes the UID on its own one after the other beginning with 1000. On the other hand, the command # useradd -u 1022 -g 100 -m -d /home/testuser testuser works fine. Trying to assing a specific UID during the creation prozess results in an error and the HOME directory will not be created. Reproducible: Always Steps to Reproduce: 1. Start yast or yast2 2. Start creating a new user 3. Chose a specific UID below or above 1000 (e.g. 1022) 4. The user is created and will be usable but missing a HOME directory. Actual Results: The user will be created but his HOME directory not. The Message is: "Error. Cannot create home directory /home/<username>. Parent directory is not a Btrfs volume." Expected Results: YaST should create the HOME directory too, like it did all versions before openSUSE Leap 15.1 I did the Online Update, tested several new installations and reboots, but this behavior is reproducible with yast1 and yast2. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1133181] New: putty: Xresources support broken, no X11 support
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1133181 Bug ID: 1133181 Summary: putty: Xresources support broken, no X11 support Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: manfred99(a)gmx.ch QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- 1) putty 0.71 is built with -DNOT_X_WINDOWS, this is because of Bug 1098962. However this bug seems to be fixed in the 0.71 release, see https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7fee4e9b43ea7d72… This commit is incuded in 0.71, so this setting is probably not needed any more. It seems upstream is willing to support multiple backends and seems willing to fix wayland bugs as they appear, so it would be great if there would be some collaboration with upstream and not to resolve to cheap band-aids by disabling features. It seems this bug was fixed almost 2 months before bug report 1098962 was raised ... 2) in putty 0.71 Xresources support is completely broken, which is most obvious in the pterm application, simply try #> pterm -xrm 'TermWidth: 20' which does nothing at all. This bug is fixed by https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=39c20d4819794417… It would be great if this commit could be picked and included into the opensuse releases. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1107337] New: wxWidgets: Restore Webkit support for wxGTK3
by bugzilla_noreply＠novell.com 05 Jun '19

05 Jun '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1107337 Bug ID: 1107337 Summary: wxWidgets: Restore Webkit support for wxGTK3 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: j.v.dijk(a)tue.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Not so long ago, webview support was dropped from the wxWidgets packages. The reason appears to be that there were various issues with the older webkit versions that the wx-GTK2 packages relied upon. I understand that, although this is a major issue for us and has rendered the OpenSuse wx packages usable. I think the problem started between 42.3 and 15.0. At home I compiled wxWidgets with the --gtk=3 option, using webkit2, which *is* still offered by OpenSuse and does not have the unresolved security issues. I did not see any problem and everything works like a charm. So my friendly request is: Please, please, compile the wxGTK3* packages with webview (->webkit) enabled, so we do not need to tell our OpenSuse users to compile wxWidgets themselves or move to another distro. I duly note that there are already more custom wx reps for OpenSuse than I believe is desirable. Thank you in advance. -- You are receiving this mail because: You are on the CC list for the bug.

1 5