May 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1027448] New: Please use key release event for bracket completion plugin
by bugzilla_noreply＠novell.com 15 Dec '21

15 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1027448 Bug ID: 1027448 Summary: Please use key release event for bracket completion plugin Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: hillwoodroc(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 715892 --> http://bugzilla.opensuse.org/attachment.cgi?id=715892&action=edit bracketcompletion: use key release event to work with input method From: bgo#778737 https://bugzilla.gnome.org/show_bug.cgi?id=778737 Some user reported that ibus-libpinyin/ibus-pinyin doesn't work with gedit plugin bracket completion. I tried to modify the gedit plugin code, it seems work now. Please review it, thanks! How to reproduce it: 1. Switch to C/C++ mode, press "(", bracket completion works. 2. Switch input method to "Intelligent Pinyin" or "Pinyin", it doesn't work. -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1159131] New: icu: follow upstream soname again?
by bugzilla_noreply＠novell.com 14 Dec '21

14 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1159131 Bug ID: 1159131 Summary: icu: follow upstream soname again? Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: jengelh(a)inai.de Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: qzhao(a)suse.com Found By: --- Blocker: --- according to bug 824262 from 2013 icu was switched to a custom soname as upstream was not considered reliable enough to get it right. Looks like meanwhile it's safe when they release a .something version: https://abi-laboratory.pro/?view=timeline&l=icu4c So can we go back to using the upstream soname? -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 1098245] New: gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used
by bugzilla_noreply＠novell.com 14 Dec '21

14 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1098245 Bug ID: 1098245 Summary: gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Linux Status: NEW Severity: Minor Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: jmader2(a)gmu.edu QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- starting `gnome-session` there is the console message, gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used I am currently working around this with, setcap cap_ipc_lock=+ep /usr/bin/gnome-keyring-daemon -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1002875] New: plymouth boot splash not working in tumbleweed
by bugzilla_noreply＠novell.com 12 Dec '21

12 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1002875 Bug ID: 1002875 Summary: plymouth boot splash not working in tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: cristian_anita(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi All, I recently made a fresh install of Tumbleweed 20160924 and plymouth splash screen does not appear at startup (only blinking cursor between grub2 and sddm) and shutdown (only some message about watchdog). plymouth-0.9.2-2.4 plymouth-branding-openSUSE-13.3-4.3 grub2-2.02~beta3-11.1 Same with latest TW update (20161003) Regards, Cristian ANITA -- You are receiving this mail because: You are on the CC list for the bug.

2 111

[Bug 1168611] New: With AMD Picasso APU system hangs during boot with kernel 5.6.2 (5.6.0 works)
by bugzilla_noreply＠novell.com 09 Dec '21

09 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1168611 Bug ID: 1168611 Summary: With AMD Picasso APU system hangs during boot with kernel 5.6.2 (5.6.0 works) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: kaykaykay123(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- System hangs with normal and recovery mode. Updated kernel is needed to use builtin graphics. AMD Picasso = AMD Raven2 APU = AMD Ryzen 3 3200G, 3200GE | AMD Ryzen 5 3400G, 3400GE Looks like system hangs trying to initialise builtin graphics. -- You are receiving this mail because: You are on the CC list for the bug.

2 30

[Bug 1137058] New: Desktop item editor adds junk
by bugzilla_noreply＠novell.com 06 Dec '21

06 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1137058 Bug ID: 1137058 Summary: Desktop item editor adds junk Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xfce Assignee: bnc-team-xfce(a)forge.provo.novell.com Reporter: mistresssilvara(a)hotmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When using the build-in XFCE editor to create a new .desktop file, after entering data, and leaving the "Comment" field blank, it gets populated with a long garbage string. It turned out it comes from the "" entry in the desktop_translations.mo file. Steps to reproduce: 1. Right-click the XFCE desktop and select "Create new launcher..." 2. Enter the name, "Test", and the command, "true" 3. Click OK 4. Mouse over the new launcher and see its tooltip. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1160604] New: BTRFS related kernel NULL pointer dereference
by bugzilla_noreply＠novell.com 03 Dec '21

03 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1160604 Bug ID: 1160604 Summary: BTRFS related kernel NULL pointer dereference Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 827267 --> http://bugzilla.opensuse.org/attachment.cgi?id=827267&action=edit kernel 5.4 traces On OBS while building JeOS images based on BTRFS filesystem, kernel crashes with a kernel NULL pointer dereference. There was no problem kernel 5.3, only with 5.4. Traces are in attachment. -- You are receiving this mail because: You are on the CC list for the bug.

2 26

[Bug 1171882] New: mgetty: probably long dead directory /var/spool/fax/outgoing/locks in permissions profiles
by bugzilla_noreply＠suse.com 02 Dec '21

02 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1171882 Bug ID: 1171882 Summary: mgetty: probably long dead directory /var/spool/fax/outgoing/locks in permissions profiles Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: sbrabec(a)suse.com Reporter: matthias.gerstner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: dmueller(a)suse.com, security-team(a)suse.de Found By: --- Blocker: --- The security team is currently sanity checking the profiles in the Base:System/permissions package. In this context we've come across the following entries related to the mgetty package: permissions.paranoid: /var/spool/fax/outgoing/locks fax:trusted 0755 permissions.easy: /var/spool/fax/outgoing/locks fax:root 0755 permissions.secure: /var/spool/fax/outgoing/locks fax:root 0755 This directory doesn't seem to be part of mgetty (sendfax) for a long time any more. Upstream commit bac8e5efeeb19ef5bef44ff1d76b73816218936b seems to have removed this in the year 2002 (upstream git repository is at git://github.greenie.net/mgetty/) If you can confirm this I'd like to remove the entries listed above from all permissions profiles. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1171879] New: screen: /var/run/uscreens conflict between systemd-tmpfiles and permissions entries
by bugzilla_noreply＠suse.com 02 Dec '21

02 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1171879 Bug ID: 1171879 Summary: screen: /var/run/uscreens conflict between systemd-tmpfiles and permissions entries Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: mls(a)suse.com Reporter: matthias.gerstner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: alexander_naumov(a)opensuse.org, security-team(a)suse.de Found By: --- Blocker: --- There is an ongoing effort to cleanup the entries in the permissions profiles. In this context we found out that the screen package is currently using two different mechanisms for setting the permissions of /var/run/uscreens. Original the permissions have been set via the permissions package which uses the following paths and settings in its different profiles: permissions.paranoid: /var/run/uscreens/ root:trusted 1775 permissions.paranoid: /run/uscreens/ root:trusted 1775 permissions.easy: /var/run/uscreens/ root:root 1777 permissions.easy: /run/uscreens/ root:root 1777 permissions.secure: /var/run/uscreens/ root:root 1777 permissions.secure: /run/uscreens/ root:root 1777 For a long time already screen also ships a tmpfiles.d entry which currently looks like this: $ cat /usr/lib/tmpfiles.d/screen.conf # Screen needs some files in /run: d /run/screens 0755 root root - d /run/uscreens 1777 root root - Luckily the permissions are the same for the easy and secure permissions profiles. If anybody is using the paranoid profile then `systemd-tmpfiles` and `chkstat` will fight against each other and switch the directory's mode back and forth. I suggest to rely only on the tmpfiles.d entry in the future. Therefore I'd remove the above entries from all permissions profiles. For this I'd like to get your input if this is okay for you. Furthermore you need to remove the invocations of `%set_permissions` and `%verify_permissions` from the screen package's spec file. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1163588] New: AUDIT-FIND: chromium: chrome_sandbox shouldn't be packaged any more
by bugzilla_noreply＠novell.com 02 Dec '21

02 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1163588 Bug ID: 1163588 Summary: AUDIT-FIND: chromium: chrome_sandbox shouldn't be packaged any more Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: tchvatal(a)suse.com Reporter: matthias.gerstner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- I just noticed that on openSUSE we're shipping the chromium browser still with the setuid-root sandbox in /usr/lib/chrome_sandbox. This should NOT be necessary any more, since chromium uses Linux namespaces these days for sandboxing. The chome_sandbox binary should not need to be built and shipped at all. Upstream worked for years on making this possible: https://bugs.chromium.org/p/chromium/issues/detail?id=312380 By now it is possible for a longer time already to run without this setuid-root binary. Since openSUSE kernels should all support namespaces there should be no compelling reason to keep this setuid program around. Please adjust the packaging accordingly. Afterwards the security team can remove the entry from the permissions package. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

2 13