December 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1129036] New: bash: update-alternative handling causes errors
by bugzilla_noreply＠novell.com 04 Mar '22

04 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1129036 Bug ID: 1129036 Summary: bash: update-alternative handling causes errors 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: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Bash has been changed to take /bin/sh under control of update-alternatives. somewhat a noble goal, but while building live isos at leats, resulted in errors, as there is an install cycle between bash (requiring updtae-alternatives in the post script) and update-alternatives (requiring /bin/sh to execute its post script, migrating data) SO, unless u-a manages to run its post script as lua code without an external dependency on /bin/sh, there is no chance to get this /bin/sh update-alternative managed for the time being -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1111047] New: haveged crashes regular on openSUSE Kubic
by bugzilla_noreply＠novell.com 04 Mar '22

04 Mar '22

http://bugzilla.suse.com/show_bug.cgi?id=1111047 Bug ID: 1111047 Summary: haveged crashes regular on openSUSE Kubic Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: peter.simons(a)suse.com Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 785324 --> http://bugzilla.suse.com/attachment.cgi?id=785324&action=edit core.haveged haveged crashes regular on openSUSE Kubic, maybe because of the read-only root filesystem? I don't see this crashes on the tumbleweed installations at the same code level. Core was generated by `@usr/sbin/haveged -w 1024 -v 0 -F'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f5b60190d5d in havege_rng (h=0x5654533144b0, buffer=<optimized out>, sz=134217701) at havege.c:239 239 havege.c: No such file or directory. (gdb) back #0 0x00007f5b60190d5d in havege_rng (h=0x5654533144b0, buffer=<optimized out>, sz=134217701) at havege.c:239 #1 0x00005654527120fd in run_daemon (argv=0x7fffadef9c78, path=0x565453314260 "@usr/sbin/haveged", h=0x5654533144b0) at haveged.c:633 #2 main (argc=<optimized out>, argv=0x7fffadef9c78) at haveged.c:468 -- You are receiving this mail because: You are on the CC list for the bug.

2 10

[Bug 1132350] New: trackerbug: adapt all apparmor profiles containing /bin/bash after bash move
by bugzilla_noreply＠novell.com 03 Mar '22

03 Mar '22

http://bugzilla.suse.com/show_bug.cgi?id=1132350 Bug ID: 1132350 Summary: trackerbug: adapt all apparmor profiles containing /bin/bash after bash move 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: ro(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- just as a hint, looks like we want to change all packages with apparmor profiles /bin/bash rix, -> /{,usr/}bin/bash rix -- You are receiving this mail because: You are on the CC list for the bug.

2 28

[Bug 1042673] New: vsftpd fails to build with openssl-1.1
by bugzilla_noreply＠novell.com 02 Mar '22

02 Mar '22

http://bugzilla.suse.com/show_bug.cgi?id=1042673 Bug ID: 1042673 Summary: vsftpd fails to build with openssl-1.1 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: peter.simons(a)suse.com Reporter: tchvatal(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1042629 Found By: --- Blocker: --- The package fails to build with openssl-1.1. For more information see the blocker bug. Currently tested in Staging:I https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1135788] New: yast-python-bindings startup, then shutdown without error when there is a syntax error
by bugzilla_noreply＠novell.com 02 Mar '22

02 Mar '22

http://bugzilla.suse.com/show_bug.cgi?id=1135788 Bug ID: 1135788 Summary: yast-python-bindings startup, then shutdown without error when there is a syntax error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: david.mulder(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- No error message is logged to y2log when there is a syntax error in a python yast module. The module fails to load, but the log appears to show everything succeeded. 2019-05-21 08:08:38 <1> linux-0bgx(13335) [ui] YCP_UI.cc(SetApplicationTitle):1722 Setting application title to '"YaST2 - samba-internal-dns-manager @ linux-0bgx"' 2019-05-21 08:08:38 <1> linux-0bgx(13335) [ncurses] NCurses.cc(SetTitle):476 Draw title called 2019-05-21 08:08:38 <1> linux-0bgx(13335) [Interpreter] bin/y2start:58 Calling YaST client samba-internal-dns-manager 2019-05-21 08:08:38 <1> linux-0bgx(13335) [Interpreter] bin/y2start:58 Called YaST client returned. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1105654] New: mesa-dri-nouveau: Incorrect description when confirming the package license
by bugzilla_noreply＠novell.com 25 Feb '22

25 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1105654 Bug ID: 1105654 Summary: mesa-dri-nouveau: Incorrect description when confirming the package license Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: lgrimmer(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- During the initial installation on my physical system using the openSUSE-Tumbleweed-NET-x86_64-Snapshot20180818-Media.iso image, I receive a popup window with the following title: "Confirm Package License: Mesa-dri-nouveau" The last paragraph of the message that is displayed here (which isn't actually a "license", but rather a warning/disclaimer) reads: 'Please click "Accept" if you accept the risks that may come with the installation of this driver. Choose "Cancel" to prevent installation of the driver and use software emulation instead.' However, the popup window does not provide any buttons with these labels - they are labeled "I Agree" and "I Disagree". I guess the text of that message should probably be updated to reflect this change (and eventually any other package that contains a similar message?). -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1154733] New: pam_mount isn't installed by default on enlightenment systems
by bugzilla_noreply＠novell.com 25 Feb '22

25 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1154733 Bug ID: 1154733 Summary: pam_mount isn't installed by default on enlightenment systems Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: simonf.lees(a)suse.com Reporter: simonf.lees(a)suse.com QA Contact: bnc-team-screening(a)forge.provo.novell.com Found By: --- Blocker: --- As per title. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1042287] New: [Build 20170601] openQA test fails in enlightenment_first_start
by bugzilla_noreply＠novell.com 25 Feb '22

25 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1042287 Bug ID: 1042287 Summary: [Build 20170601] openQA test fails in enlightenment_first_start Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: http://openqa.opensuse.org/tests/413072/modules/enligh tenment_first_start/steps/12 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The description text is missing. ## Observation openQA test in scenario opensuse-Tumbleweed-NET-x86_64-otherDE_enlightenment@64bit fails in [enlightenment_first_start](http://openqa.opensuse.org/tests/413072/modules/… ## Reproducible Fails since (at least) Build [20170601](http://openqa.opensuse.org/tests/412884) ## Expected result Last good: [20170529](http://openqa.opensuse.org/tests/411282) (or more recent) ## Further details Always latest result in this scenario: [latest](http://openqa.opensuse.org/tests/latest?machine=64bit&flavor=NET&te… -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1122683] New: osc: deprecate insecure APIs
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.suse.com/show_bug.cgi?id=1122683 Bug ID: 1122683 Summary: osc: deprecate insecure APIs Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: osc Assignee: adrian(a)suse.com Reporter: malte.kraus(a)suse.com QA Contact: adrian(a)suse.com Found By: --- Blocker: --- >From bnc#1119444: > > The OSC client has some vulnerable code in it, that it doesn't use itself but provides as a library to plugins. In one case there's even a comment explicitly marking this as insecure, but are not removed due to compatibility concerns. If not breaking backwards compatibility under any circumstances is that important, I recommend adding deprecation warnings (https://docs.python.org/2.6/library/warnings.html#temporarily-suppressing-w…) to move plugins over to secure APIs. > > Can you create a dedicated request for this? Specifically, the 'unpack_srcrpm' function has such a warning as a comment. Also, 'Ar.saveTo', 'CpioRead.copyin' can be made to store files in arbitrary locations if the archive they parsed contain a filename starting with a "/". -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1158470] New: synergy: Mouse pointer can't be moved back to server after switching to neighbor
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.suse.com/show_bug.cgi?id=1158470 Bug ID: 1158470 Summary: synergy: Mouse pointer can't be moved back to server after switching to neighbor Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X11 Applications Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm observing erratic behavior of synergy in my setup under Leap. TL;DR: It's fixed by upgrading to synergy-1.9.1-lp151.61.3 from X11:Utilities. Setup: server "artemis", left: > eDP-1 connected primary 1368x768+0+1152 (normal left inverted right x axis y axis) 294mm x 165mm > DP-1-1 connected 1200x1920+1368+0 left (normal left inverted right x axis y axis) 518mm x 324mm This is the laptop screen plus one monitor in "portrait" orientation. client "apollon", right: > DP1-1 connected primary 1080x1920+1200+0 left (normal left inverted right x axis y axis) 530mm x 300mm > eDP1 connected 1368x768+2280+1016 (normal left inverted right x axis y axis) 310mm x 170mm Another vertical monitor plus the screen of the 2nd laptop. >From left to right, I have "artemis" laptop screen, portrait monitor of "artemis", portrait monitor of "apollon", "apollon" laptop screen. The links section in synergy.conf looks like this: > section: links > artemis: > right = apollon > down = zeus > apollon: > left = artemis > down = zeus > zeus: > up = artemis > left = artemis > right = apollon > end (computer "zeus" is switched off). Now I start synergys on artemis, synergyc is running on apollon. I slowly move the pointer on artemis from left to right until it reaches the right edge of the portrait monitor. I'd expect the cursor to move on "apollon" now, but this does not happen. It vanishes on "artemis", but it's not visible on "apollon". When I move the mouse back left, still nothing happens. I can't get the mouse pointer to move back to "artemis" screen. I have to ssh to artemis and kill synergys to get a working mouse pointer back. Here's what happens in the synergys debug log when moving the mouse from left to right: > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2563,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2565,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2566,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2567,1158 at this point the right screen border of "artemis" is reached, now we start generating events for "apollon": > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:18] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:18] DEBUG2: move on apollon to 84,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1369,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1369,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: onMouseMoveSecondary +85,+0 > [2019-12-04T22:54:19] DEBUG2: move on apollon to 169,1158 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:19] DEBUG2: move on apollon to 253,1158 "onMouseMoveSecondary" gets basically the same relative step over and over again, causing the pointer to move monotonically to the right (I made but minimal movements with the mouse at this point), until... > [2019-12-04T22:54:22] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:22] DEBUG2: move on apollon to 3622,1155 > [2019-12-04T22:54:22] DEBUG2: warped to 1284,960 > [2019-12-04T22:54:22] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:22] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:22] DEBUG2: find neighbor on right of "apollon" > [2019-12-04T22:54:22] DEBUG2: no neighbor on right of "apollon" > [2019-12-04T22:54:22] DEBUG1: try to leave "apollon" on right > [2019-12-04T22:54:22] DEBUG1: no neighbor right > [2019-12-04T22:54:22] DEBUG2: clamp to right of "apollon" Here, the *right* edge of apollon's monitor is reached although I sure as hell didn't move the mouse there. Comparing the same log for synergy 1.9.1: > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 2549,1705 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 2564,1691 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 2567,1683 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 844,1440 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 689,1531 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 705,1518 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 725,1505 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 746,1492 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 775,1479 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 807,1461 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 844,1440 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary +160,-96 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 160,1587 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary -155,+91 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 5,1678 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary -5,+5 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 0,1683 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary +21,-18 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 21,1665 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary -21,+18 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 0,1683 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary +41,-31 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 41,1652 Here it seems that right after entering "apollon"'s screen, a number of MotionNotify events is discarded, and later on, onMouseMoveSecondary() calls seem to "correct" previous movements. For the user, this feels correct. Also, the mouse pointer is well visible in on "apollon", moves as expeted, and can be moved back to the "artemis" screen just fine. I've been trying to figure out which commits changed this behavior between v1.8.8-stable and v1.9.1-stable, but nothing caught my eye. The 1.9.1 version has already been submitted and accepted to Leap 15.2. I'd like to suggest to submit it to 15.1, too. -- You are receiving this mail because: You are on the CC list for the bug.

2 16