September 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1185043] New: url_handler.sh packaged with urlview does not open url in Firefox
by bugzilla_noreply＠suse.com 11 Oct '22

11 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1185043 Bug ID: 1185043 Summary: url_handler.sh packaged with urlview does not open url in Firefox Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dan(a)danrees.me QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 848567 --> http://bugzilla.opensuse.org/attachment.cgi?id=848567&action=edit Debian alternative url_handler.sh Urlview 0.9 has been installed and linked with mutt in muttrc. Mutt is capable of displaying urlview which successfully launches url_handler.sh located at /usr/bin/url_handler.sh with the selected url as the argument. url_handler.sh fails to launch firefox and there is no further output on the terminal. The behaviour is replicated by manually launching url_handler.sh from gnome-terminal. Manual inspection of url_handler.sh confirms that firefox is listed first in the variable 'x11browser' per the default installation. In contrast the default url_handler.sh script packaged with Debian and extracted from source works as fine when manually executed or included in a new '.urlview'. This script is attached for comparison. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 920901] New: USB mouse disconnects every 60 seconds without X
by bugzilla_noreply＠novell.com 11 Oct '22

11 Oct '22

http://bugzilla.suse.com/show_bug.cgi?id=920901 Bug ID: 920901 Summary: USB mouse disconnects every 60 seconds without X Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: oneukum(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Some mice need X to run or will disconnects and reconnect every 60 seconds. The fix is a new quirk to always poll. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1173829] New: WSL Leap 15.2 image log in as root instead of user
by bugzilla_noreply＠suse.com 11 Oct '22

11 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1173829 Bug ID: 1173829 Summary: WSL Leap 15.2 image log in as root instead of user Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: WSL Assignee: sle-ms(a)suse.de Reporter: guillaume.gardet(a)arm.com QA Contact: qa-c(a)suse.de CC: lnussel(a)suse.com Found By: --- Blocker: --- I installed WSL Leap 15.2 image on my windows laptop, YaST2-firstboot started properly, but the default login is 'root' instead of the user I created when prompted in YaST2-firstboot. Previous Leap versions logged me in as a user, not as root. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1180754] New: [Build 20210110] Upgrade of any Leap 42.x to TW not possible to start
by bugzilla_noreply＠suse.com 11 Oct '22

11 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180754 Bug ID: 1180754 Summary: [Build 20210110] Upgrade of any Leap 42.x to TW not possible to start Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1583321/modules/upgr ade_select/steps/4 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Upgrade Problems Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: jsrain(a)suse.com Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-NET-x86_64-upgrade_Leap_42.1_gnome@64bit fails in [upgrade_select](https://openqa.opensuse.org/tests/1583321/modules/upgrade_s… RPM seems to throw an exception: /var/log/YaST2/y2log:2021-01-11 00:37:54 <5> install(4060) [zypp] Exception.cc(log):166 librpmDb.cc(D):75 THROW: Failed to open database: Root: /mnt dbPath: /var/lib/rpm ## Test suite description ## Reproducible Fails since (at least) Build [20210110](https://openqa.opensuse.org/tests/1583321) (current job) ## Expected result Last good: [20210108](https://openqa.opensuse.org/tests/1581939) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1130084] New: openSUSE:Leap:15.1/piglit failed
by bugzilla_noreply＠novell.com 11 Oct '22

11 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1130084 Bug ID: 1130084 Summary: openSUSE:Leap:15.1/piglit failed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other URL: https://build.opensuse.org/package/live_build_log/open SUSE:Leap:15.1/piglit/standard/x86_64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: mimi.vx(a)gmail.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- openSUSE:Leap:15.1/piglit failed to build. Please see build log: https://build.opensuse.org/package/live_build_log/openSUSE:Leap:15.1/piglit… Job gets stuck, rebuild doesn't help -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1160059] New: openSUSE:Leap:15.2/ltrace failed
by bugzilla_noreply＠novell.com 11 Oct '22

11 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1160059 Bug ID: 1160059 Summary: openSUSE:Leap:15.2/ltrace failed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other URL: https://build.opensuse.org/package/live_build_log/open SUSE:Leap:15.2/ltrace/standard/x86_64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: matz(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: mischa.salle(a)gmail.com Found By: --- Blocker: --- openSUSE:Leap:15.2/ltrace failed to build. Please see build log: https://build.opensuse.org/package/live_build_log/openSUSE:Leap:15.2/ltrace… -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1183345] New: sudo not using /usr/etc/nsswitch.conf
by bugzilla_noreply＠suse.com 10 Oct '22

10 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1183345 Bug ID: 1183345 Summary: sudo not using /usr/etc/nsswitch.conf Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: peter.clark(a)ngic.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- sudo is successfully performs ldap reads using /etc/nsswitch.conf with sudoers: ldap but a similar entry in /usr/etc/nsswitch.conf not working tumbleweed# strace sudo -l 2>&1 | grep ldap.conf tumbleweed# cp /usr/etc/nsswitch.conf /etc/nsswitch.conf tumbleweed# strace sudo -l 2>&1 | grep ldap.conf openat(AT_FDCWD, "/etc/ldap.conf", O_RDONLY) = 7 tumbleweed# -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1096050] New: sudo doesn't work after upgrade from leap 42,3
by bugzilla_noreply＠novell.com 10 Oct '22

10 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1096050 Bug ID: 1096050 Summary: sudo doesn't work after upgrade from leap 42,3 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: alarrosa(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After upgrading to Leap 15.0 from 42.3, sudo shows an error in the first lines: sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted sudo: unable to open /var/lib/sudo/ts/antonio: Permission denied Then it asks for the root password as usual, but it doesn't accept it (I can log in as root, so I know it's correctly written). After writting it 3 times, it fails with: sudo: unable to send audit message: Operation not permitted sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted The user id output: uid=1000(antonio), gid=100(users) groups=100(users),10(wheel),485(kvm) The output from 'rpm -V sudo' is: .M....... g /var/lib/sudo .M....... g /var/lib/sudo/ts So I reinstalled the package and ran 'rpm --setperms sudo' with no change. Btw, the package seems to set the permissions of the /var/lib/sudo/ts directory to 000 but I had other working systems where the permissions are 700, so I set it to that. In any case, the owner is root:root. I also tried reinstalling pam and pam-config with no luck. Any idea of what to try? -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1187566] New: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot
by bugzilla_noreply＠suse.com 10 Oct '22

10 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1187566 Bug ID: 1187566 Summary: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: eecdc3.opensuse(a)coders-haven.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I am using a HP Elitebook 1040 G4 notebook connected to a HP Thunderbolt 3 Docking Station, which in turn is connected to multiple USB devices and an external monitor via DisplayPort. Unfortunately, I am experiencing issues with this configuration as described below. I am using boltd from the hardware repository to authorize my Thunderbolt 3 Docking Station during startup. (Boot ACLs are not supported by my BIOS, as far as I can tell.) While devices connected to the docking station via USB will work afterwards, my external monitor, which is connected via DisplayPort, will not be detected automatically. Only when I manually reconnect the docking station after startup has completed, it will finally be detected (and awoken from standby). This leads me to believe that this issue is boot order related. (Previously, I was using openSUSE Leap 15.2 and a custom udev rule to authorize the docking station via sysfs and I did not experience this issue but the system would occasionally hang while booting instead. I have already tried the udev rule with openSUSE Leap 15.3 but this made the issue worse as the display was then only detected if I reconnected the external monitor itself.) Any help investigating this issue is appreciated as I do not have in-depth knowledge of the kernel or its Thunderbolt subsystem and cannot really make any progress towards a resolution on my own. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1183133] New: gkrellm doesn't remember startup position with two instances
by bugzilla_noreply＠suse.com 10 Oct '22

10 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1183133 Bug ID: 1183133 Summary: gkrellm doesn't remember startup position with two instances Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: erbenton(a)comcast.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- openSUSE Tumbleweed 20210115 (x86_64) KDE 5.78.0 Plasma 5.20.5 Qt: 5.15.2 gkrellm 2.3.11 If I start 2 instances of gkrellm and put one on each monitor and then shut them down they only remember one position the next time they are started. Starting two instances results in both starting at the exact same position on screen, one on top of the other. "allow multiple instances" is checked in the configuration dialog. In $HOME/.gkrellm2/data/startup_position i only see one set of coordinates which correspond to the last instance to shutdown, but only if the last of the two instances is moved (on screen)first, otherwise it never writes to the file and the stored coordinates are from the first instance to shutdown. -- You are receiving this mail because: You are on the CC list for the bug.

1 5