January 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1178489] Enchant 2 Voikko backend does not work in eg gspell
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1178489 https://bugzilla.suse.com/show_bug.cgi?id=1178489#c9 Timo Jyrinki <tjyrinki(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #9 from Timo Jyrinki <tjyrinki(a)suse.com> --- Now fixed and tested to be working in Leap 15.2 too! -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1178489] Enchant 2 Voikko backend does not work in eg gspell
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1178489 https://bugzilla.suse.com/show_bug.cgi?id=1178489#c8 --- Comment #8 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-RU-2021:0028-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1178489 CVE References: JIRA References: Sources used: openSUSE Leap 15.2 (src): enchant-2.2.5-lp152.3.3.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[opensuse-bugs] [Bug 1178797] New: YaST2 still rely on elevator kernel boot parameter which is obsoleted
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1178797 Bug ID: 1178797 Summary: YaST2 still rely on elevator kernel boot parameter which is obsoleted Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: anton.smorodskyi(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- I am running Leap 15.2 ( latest updates ) and in "Kernel Settings" and "Boot loader" Yast2 modules attempt to set scheduler will add kernel boot parameter "elevator=SCHEDULER" which would cause kernel 5.3.18-lp152.47 to throw warning in logs "Kernel parameter elevator= does not have any effect anymore. Please use sysfs to set IO scheduler for individual devices." -- You are receiving this mail because: You are on the CC list for the bug.

1 26

[Bug 1179904] /usr/sbin/alsactl spuriously fails reloading saved settings
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1179904 https://bugzilla.suse.com/show_bug.cgi?id=1179904#c26 --- Comment #26 from Swamp Workflow Management <swamp(a)suse.de> --- openSUSE-RU-2021:0030-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1179904 CVE References: JIRA References: Sources used: openSUSE Leap 15.2 (src): alsa-utils-1.1.5-lp152.6.3.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1004049] New: /usr/bin/socat ... openpty() is not allowd to do chown of resulting /dev/pts/ device
by bugzilla_noreply＠novell.com 08 Jan '21

08 Jan '21

http://bugzilla.suse.com/show_bug.cgi?id=1004049 Bug ID: 1004049 Summary: /usr/bin/socat ... openpty() is not allowd to do chown of resulting /dev/pts/ device Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: All OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Even with apparmor disabled I see in the strace close(8) = 0 close(7) = 0 chown("/dev/pts/8", 223, 5) = -1 EPERM (Operation not permitted) close(6) = 0 which makes this tool useless for normal users. Beside this: why we do have setcap/getcap installed by default? With this we would be able to set permissions based on capabilities for tools like setcap and ping, ping6, ... in the %post install section of the rpm of the affected tools -- You are receiving this mail because: You are on the CC list for the bug.

2 16

[Bug 942108] perl-Net-IP - ipcount doesn't work due to '+'
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=942108 Maintenance Robot <maint-coord+maintenance_robot(a)suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:2282:low | |ibs:running:2281:low | -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180501] frequent sshd coredumps
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180501 https://bugzilla.suse.com/show_bug.cgi?id=1180501#c11 Hans Petter Jansson <hpj(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Flags|needinfo?(paka(a)opensuse.org | |) | --- Comment #11 from Hans Petter Jansson <hpj(a)suse.com> --- (In reply to Cristian Rodr��guez from comment #10) > On sshd.c > > 2042 -->ssh_packet_close(ssh); on line 2402 .. gabage because it has been > messed up earlier by,, > > 2383 ��/* The connection has been terminated. */ > 2384 ��packet_destroy_all(ssh, 1, 1); > 2385 ��destroy_sensitive_data(ssh, 1); > > > where packet_destroy_all invokes packet_destroy_state which cipher_free's > first ... > > this is a bug in the audit patch. > > That's the anaylsis I could afford doing on my limited time to deal with > this annoying crash. Good analysis. I think the reason it doesn't always show up is that cipher_free() clears the struct with freezero(), and on the second call trying to free it again it will bail out on the cc->cipher == NULL precondition. However, if the allocator happens to reuse the memory range in between the two calls it will contain something else resulting in a bad deref or double free. The fix is to zero the pointers in packet_destroy_state() so they won't be followed later. I submitted rq#861491. I couldn't find any issues in my smoke test, but then I wasn't seeing the crash before either. Feel free to run your own tests with the origin project (home:hpjansson:branches:network/openssh). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180363] New: gimp-plugins-python is missing dependency from python-xml
by bugzilla_noreply＠suse.com 08 Jan '21

08 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180363 Bug ID: 1180363 Summary: gimp-plugins-python is missing dependency from python-xml Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: yaroslav.kurlaev(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- If I install gimp and gimp-plugins-python and than run gimp from the terminal, I get this error on startup: Traceback (most recent call last): File "/usr/lib64/gimp/2.0/plug-ins/file-openraster/file-openraster.py", line 17, in <module> import xml.etree.ElementTree as ET ImportError: No module named xml.etree.ElementTree gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error After installing python-xml python-xml package the error is gone. gimp starts fine even with the error so it probably can be Recommends and not Requires. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1180592] Qt plug-in could not be loaded.
by bugzilla_noreply＠suse.com 07 Jan '21

07 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180592 https://bugzilla.suse.com/show_bug.cgi?id=1180592#c8 --- Comment #8 from Stefan Hundhammer <shundhammer(a)suse.com> --- So, does your system have any zypper locks? This is the libzypp / zypper equivalent of the YaST package selector "taboo" and "protected" package states. "taboo" sets a lock on a not-installed package, i.e. it will never be installed. "protected" sets a lock on an installed package, i.e. it will remain on the system in the current version. In some pathological cases, any of those can trigger a cascade of dependencies that may ultimately lead to the dependency resolver choosing to remove a package to satisfy all package dependencies. That can also happen in other difficult package dependency problems; the sort where the dependency resolver asks you to choose one from a number of available options. We do have package dependencies on our YaST and libyui packages, of course, but they are set up in a way that allows users to get rid of optional parts if desired: YaST needs some kind of user interface (UI). We have two officially supported ones (libyui-qt and libyui-ncurses) and one community-supported (libyui-gtk). Any of them is sufficient to satisfy the dependency. Most average users will prefer to have libyui-qt, but some users actually don't want anything Qt on their systems, so only having libyui-ncurses is a viable option as well. To get libyui-qt installed in standard installations, that package is part of software patterns that involve graphical desktops; but that works with a soft dependency, an RPM "recommends". That means if possible, it is installed, but if for some reason this doesn't work, it's okay to not install it. So for example if you choose to install Qt 6 from some other repository, and that Qt 6 hypothetically conflicts with the Qt 5 that is required by our libyui-qt, you won't get libyui-qt because Qt 5 cannot be installed because you prefer Qt 6. You get the idea. And there may be any number of more dependency indirections leading to even more complicated scenarios. In any case, you will still have libyui-ncurses, so you can always open a shell window and run "/sbin/yast repositories". It's not graphical, but it works. So, without further information, we can only speculate what exactly happened in your scenario. So far, we haven't heard of any similar cases, so AFAICS this is not a general problem affecting all TW users. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 954603] New: Leap lacks tomcat
by bugzilla_noreply＠novell.com 07 Jan '21

07 Jan '21

http://bugzilla.suse.com/show_bug.cgi?id=954603 Bug ID: 954603 Summary: Leap lacks tomcat Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Java Assignee: bnc-team-java(a)forge.provo.novell.com Reporter: tchvatal(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Leap lacks tomcat as it didn't build. I will submit fixed dbcp that should go later as maint-update to SLE12 directly and for tomcat we can grab 1:1 the SLE-12:SP1 counterpart. -- You are receiving this mail because: You are on the CC list for the bug.

2 11