May 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1051848] New: server:mail/cyrus-imapd: proxy segfault after upgrade to 2.4.19-149.1
by bugzilla_noreply＠novell.com 26 Feb '20

26 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1051848 Bug ID: 1051848 Summary: server:mail/cyrus-imapd: proxy segfault after upgrade to 2.4.19-149.1 Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: SLES 11 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: opensuse-communityscreening(a)forge.provo.novell.com Reporter: wullinger(a)rz.uni-kiel.de QA Contact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- We use cyrus imapd 2.4 in a proxy configuration for multiple mailbox storage servers. Since upgrading to 2.4.19-149.1, the frontend proxies (and only those) experience frequent segfaults of pop3d, proxyd, timsieved, and lmptproxyd: Aug 2 06:16:31 frontend3 kernel: [488770.024881] pop3d[XXXX]: segfault at 7f42ef735738 ip 00007f42ef546ca3 sp 00007ffdd7a45970 error 4 in ld-2.11.3.so[7f42ef539000+1f000] The problems disappears after downgrading back to cyrus-imapd-2.4.19-146.1. After such a crash, the BDB environment is often reported as needing recovery (we only use skiplist DBs, but BDB gets initialized nonetheless) As far as we can tell, there's no interruption of service associated with these crashes. For example, for lmtpproxyd, the problem seems to appear after the final QUIT, when the process is about to exit, anyway: write(13, "QUIT\r\n", 6) = 6 rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM CHLD], [], 8) = 0 pselect6(14, [13], NULL, NULL, {229, 0}, {[], 8}) = 1 (in [13], left {228, 999487532}) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(13, "221 2.0.0 bye\r\n", 4096) = 15 rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM CHLD], [], 8) = 0 pselect6(14, [13], NULL, NULL, {0, 0}, {[], 8}) = 1 (in [13], left {0, 0}) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 read(13, "", 4096) = 0 shutdown(13, 0 /* receive */) = 0 close(13) = 0 munmap(0x7f87be793000, 38608896) = 0 close(8) = 0 munmap(0x7f87c693f000, 40960) = 0 munmap(0x7f87c6873000, 98304) = 0 munmap(0x7f87c1aca000, 28131328) = 0 munmap(0x7f87c688b000, 671744) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- A slight hunch seems to suggest that there's a memory corruption issue that gets triggered during the final close of the BDB environment. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1071153] New: offlineimap needs python2-six
by bugzilla_noreply＠novell.com 25 Feb '20

25 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1071153 Bug ID: 1071153 Summary: offlineimap needs python2-six Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Ralf.Friedl(a)online.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- File /usr/lib/python2.7/site-packages/offlineimap/accounts.py:23 from package offlineimap-7.1.4-1.2.noarch contains "import six", but python2-six is not listed in the package requirements. As a consequence, just installing offlineimap if python2-six is not already installed leads to this error: > Traceback (most recent call last): > File "/usr/bin/offlineimap", line 20, in <module> > from offlineimap import OfflineImap > File "/usr/lib/python2.7/site-packages/offlineimap/__init__.py", line 20, in <module> > from offlineimap.init import OfflineImap > File "/usr/lib/python2.7/site-packages/offlineimap/init.py", line 34, in <module> > from offlineimap import threadutil, accounts, folder, mbnames > File "/usr/lib/python2.7/site-packages/offlineimap/accounts.py", line 23, in <module> > import six > ImportError: No module named six -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1086614] New: Duplicate / ambiguous desktop session selection entriesin sddm
by bugzilla_noreply＠novell.com 24 Feb '20

24 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1086614 Bug ID: 1086614 Summary: Duplicate / ambiguous desktop session selection entriesin sddm Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ## Observation in an installation of openSUSE Leap 15.0 installing many desktop managers, window managers, etc. I see the following entries in sddm: * Enlightenment * GNOME on Xorg * GNOME * IceWM Session * IceWM * LXDE * LXQt Desktop * MATE * Openbox * Plasma * TWM * Xfce Session * Enlightenment (Wayland) * GNOME (Wayland) * Plasma (Wayland) ## Problem I see the following issues: * What is "GNOME" when there is already "GNOME on Xorg", "GNOME (Wayland)"? * Can "GNOME on Xorg" and "GNOME (Wayland)" use a common naming scheme? E.g. "GNOME" (implicit Xorg) and "GNOME (Wayland)" or "GNOME (Xorg)", "GNOME (Wayland)"? * "IceWM Session" and "IceWM" duplicate? * Why the suffix "Desktop" in "LXQt Desktop" and "Session" on "Xfce" and and of the IceWM entry when others do not have that? -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1117323] New: when leap 15.1 as a kvm guest it could enable ibrs even host disable this mitigation with nospectre_v2
by bugzilla_noreply＠novell.com 24 Feb '20

24 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1117323 Bug ID: 1117323 Summary: when leap 15.1 as a kvm guest it could enable ibrs even host disable this mitigation with nospectre_v2 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: jnwang(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I use a 4.4.162-78-default as a kvm host.(with nospectre_v2) lscpu can't dispaly 'ibrs' flag. and boot a kvm guest setup leap 15.1; The qemu cmdline is: /usr/bin/qemu-system-x86_64 -vga cirrus -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -soundhw ac97 -global isa-fdc.driveA= -m 1024 -cpu qemu64 -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -boot order=c,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :91,share=force-shared -device virtio-serial -chardev socket,path=virtio_console,server,nowait,id=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-overlay0-file,filename=/var/lib/openqa/pool/1/raid/hd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0-overlay0,file=hd0-overlay0-file,cache.no-flush=on -device virtio-blk,id=hd0-device,drive=hd0-overlay0,bootindex=0,serial=hd0 -blockdev driver=file,node-name=hd1-file,filename=/var/lib/openqa/pool/1/raid/hd1,cache.no-flush=on -blockdev driver=qcow2,node-name=hd1,file=hd1-file,cache.no-flush=on -device virtio-blk,id=hd1-device,drive=hd1,serial=hd1 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/var/lib/openqa/pool/1/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0 Guest could boot up, and lscpu can't display ibrs in guest. and then, I added spectre_v2=ibrs on command line. reboot guest. when guest start up with spectre_v2=ibrs, the dmesg tell me spectre_v2 enable mitigation is IBRS. but it's lscpu tell me no 'ibrs' flag. This inconsistent is a regression. I believe IBRS have been enable in Guest, even host disabled it. So there is two kep point, 1). QEMU pass-through the flag 'spec-ctrl' to guest, when host disable this feature. 2). For QEMU viewpoint, 'ibrs ibpb stibp' all in one feature 'spec-ctrl', but in linux kernel, 'nospectre_v2' only disable 'ibrs', 'ibpb' and 'stibp' still available at output of lscpu. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 917728] New: Obsolete/deprecated config option still enabled
by bugzilla_noreply＠novell.com 23 Feb '20

23 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=917728 Bug ID: 917728 Summary: Obsolete/deprecated config option still enabled Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: zaitor(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi Kernel people. Just installed the spiffy new 3.19 kernel from Kernel:stable, and when going through journald logs to see if there was something new and exciting I came over these warnings that I've seen for ages, but never cared for since it seem to do no harm. linux-ial4:~ # uname -r 3.19.0-1.g8a7d5f9-desktop linux-ial4:~ # journalctl -b | grep CONFIG_ACPI_PROCFS_POWER feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared linux-ial4:~ # ---- But today I took the time to google it, and found this bug from Arch https://bugs.archlinux.org/task/25845 Snip from bug ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared This was scheduled for removal in 2.6.39, but is still there. I suggest trying to disable it for 3.1, if for nothing else than to discover what problems this might cause so the appropriate bug reports can be filed. >From Documentation/feature-removal-schedule.txt: What: CONFIG_ACPI_PROCFS_POWER When: 2.6.39 Why: sysfs I/F for ACPI power devices, including AC and Battery, has been working in upstream kernel since 2.6.24, Sep 2007. In 2.6.37, we make the sysfs I/F always built in and this option disabled by default. Remove this option and the ACPI power procfs interface in 2.6.39. Who: Zhang Rui <rui.zhang(a)intel.com> ---- Short story this was disabled on Arch back in 2011 Could we do this for openSUSE too? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1105742] New: lpoptions are ignored by KDE apps
by bugzilla_noreply＠novell.com 20 Feb '20

20 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1105742 Bug ID: 1105742 Summary: lpoptions are ignored by KDE apps Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: morten(a)soeltoft.dk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- KDE apps are ignnoring default printer setting from ~/.cups/lpoptions. Gnome apps like gedit and Gimp are working ok. Worked fine at plasma 5.12.x -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1088249] New: Korganizer deletes caldav events only locally.
by bugzilla_noreply＠novell.com 19 Feb '20

19 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1088249 Bug ID: 1088249 Summary: Korganizer deletes caldav events only locally. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: dev(a)cyclinggeorgian.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Events created on the server side (web), or in other clients (mobile) are synced to the Korganizer. Events created in Korganizer synced to the server too, and they show up on all clients connected to caldav server as expected. But when i delete event in Korganizer event is removed only locally. Delete action is not transmitted to the server. (running latest Tumbleweed updates) -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1127766] New: installation aborted if snapper fails
by bugzilla_noreply＠novell.com 19 Feb '20

19 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1127766 Bug ID: 1127766 Summary: installation aborted if snapper fails Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- per bug#1048338, subvolume handing is (or was) suboptimal. Today I tried to upgrade an existing subvolume to 15.1. I set the default to this subvolume and booted with 'upgrade=1'. Since I do not use snapshots, there is no /.snapshots. Something does not like that fact: [Ruby] yast2/fs_snapshot.rb:317 Executing: "/usr/lib/snapper/installation-helper --step 5 --root-prefix=/mnt --snapshot-type pre --description before\ update --userdata "important=yes" --cleanup number" [bash] ShellCommand.cc(shellcommand):78 reading failed [bash] ShellCommand.cc(shellcommand):78 terminate called after throwing an instance of 'snapper::IOErrorException' [bash] ShellCommand.cc(shellcommand):78 what(): open failed path:/mnt//.snapshots errno:2 (No such file or directory) [Ruby] yast2/fs_snapshot.rb:323 Snapshot could not be created: /usr/lib/snapper/installation-helper --step 5 --root-prefix=/mnt --snapshot-type pre --description before\ update --userdata "important=yes" --cleanup number returned: {"exit"=>134, "stderr"=>"reading failed\nterminate called after throwing an instance of 'snapper::IOErrorException'\n what(): open failed path:/mnt//.snapshots errno:2 (No such file or directory)\n", "stdout"=>""} [Ruby] yast/builtins.rb:586 tostring builtin called on wrong type Class [Ruby] yast/wfm.rb:253 Client /mounts/mp_0001/usr/share/YaST2/clients/inst_update_partition.rb failed with 'Filesystem snapshot could not be created.' (Yast2::SnapshotCreationFailed). It seems the expectation is btrfs == snapshots. Did all of our fresh btrfs installs have a /.snapshots? If yes, the assumption might be valid, except for bug#1048338. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1133660] New: Balance operation renders BTRFS unmountable
by bugzilla_noreply＠novell.com 17 Feb '20

17 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1133660 Bug ID: 1133660 Summary: Balance operation renders BTRFS unmountable Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: richard(a)nod.at QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Yesterday my root filesystem became 100% full, after deleting multiple gigabytes of files "df" still reported 100% disk usage. I ran in this situation already a year ago and remembered that a btrfs balance operation will help. Like last year also btrfs balance was unable to start because no free space. So I followed the general advice and added a temporary device to my btrfs filesystem to make balance work. After adding another device, btrfs had free space and balance started. I expected the balance operation to finish soon such that I could remove the temporary device again. But after a few minutes I noticed that all IO on my workstaion blocked and btrfs hint an assertion. Please see attached photo crash_while_balance.jpg. At this point I was unable to cancel balance because the kernel oops returned to userspace with a lock held. So I rebooted the machine. But after the reboot btrfs hit a BUG() statement while mounting subvolumes. Please see photo crash_after_reboot.jpg. Side note: The temporary device was still present and btrfs found it. Next step was booting from an OpenSUSE LEAP 15.0 netinstall into recovery mode. To my surprise the recovery system mounted btrfs without any problem and I was able to read all files from all subvolumes. I double checked, the most recent LEAP 15.0 kernel still hit the BUG() as shown on crash_after_reboot.jpg. Again in the recovery system I canceled the balance operation, removed the temprary device, took a backup of all files and rebooted to my regular system. At this point it was again able to mount all btrfs subvolumes but after a few minutes it hit again the assertion as shown on crash_while_balance.jpg. There seems to be a problem with the recent kernel and btrfs balance. Is my filesystem now corrupted and I need to reinstal or is this "just" a runtime problem of btrfs? -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1100506] New: some searches routinely timeout or otherwise fail to return a result page
by bugzilla_noreply＠novell.com 16 Feb '20

16 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1100506 Bug ID: 1100506 Summary: some searches routinely timeout or otherwise fail to return a result page Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bugzilla Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mrmazda(a)earthlink.net QA Contact: novbugzilla-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- The following is a typical result: "Secure Connection Failed The document contains no data. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem." Example failing searches: https://bugzilla.opensuse.org/query.cgi?chfieldfrom=3y&chfieldto=Now&column… https://bugzilla.opensuse.org/query.cgi?no_redirect=1&query_format=advanced… -- You are receiving this mail because: You are on the CC list for the bug.

1 6