September 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1190346] New: Thunderbird cannot connect after re-connecting to network or after resume from suspend
by bugzilla_noreply＠suse.com 05 Aug '22

05 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190346 Bug ID: 1190346 Summary: Thunderbird cannot connect after re-connecting to network or after resume from suspend 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: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: obs(a)akr.yagii.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 852399 --> http://bugzilla.opensuse.org/attachment.cgi?id=852399&action=edit Partial TB log. From 15:25:51 on, the WLAN has been operational Reproduction: 1) Disconnect WLAN with KDE Network Manager 2) Start Thunderbird 3) Wait until it gives the "cannot connect" message 4) Connect WLAN with KDE Network Manager 5) Press "Get Messages" in Thunderbird 6) Expect "cannot connect" message, goto step 5) ad infinitum The issue also occurs after resuming from suspend state, or on a fresh login where Thunderbird is auto-started in the background and KDE is waiting for wallet credentials, before it connects to a WLAN with user specific credentials. Sometimes Firefox exhibits the same problem, however, I did not try to reproduce this, as for me the issue with Thunderbird is far more annoying. The problem existed throughout Leap 15.2, 15.3 on this system. I have attached a TB log, slightly censored for privacy. Workaround: - Restart Thunderbird -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1179539] New: cryfs crashes with "Illegal hardware instruction"
by bugzilla_noreply＠suse.com 04 Aug '22

04 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1179539 Bug ID: 1179539 Summary: cryfs crashes with "Illegal hardware instruction" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: trmdi(a)yandex.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Install cryfs from the official repo, when I run it from the terminal, it crashes with the error: Illegal hardware instruction - Upstream bug report: https://github.com/cryfs/cryfs/issues/348 When I try compiling it without some flags set by openSUSE, it runs. - See this diff: https://build.opensuse.org/package/rdiff/home:trmdi/cryfs?opackage=cryfs&op… -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1180132] New: roundcubemail should recommend httpd, not require lighttpd
by bugzilla_noreply＠suse.com 03 Aug '22

03 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180132 Bug ID: 1180132 Summary: roundcubemail should recommend httpd, not require lighttpd Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Apache Assignee: bnc-team-apache(a)forge.provo.novell.com Reporter: jimc(a)jfcarter.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Versions: roundcubemail-1.4.9-2.1.noarch (updated 2020-12-15, yesterday) lighttpd-1.4.55-4.1.x86_64 apache2-2.4.46-9.1.x86_64 roundcubemail newly requires lighttpd by name. On my webserver, Apache is the HTTP infrastructure that sends out RoundCube. I hit some snarl-ups with both lighttpd and apache2 installed together (my hacks, not your fault). I wanted to just de-install lighttpd, but roundcubemail has a hard requirement for it. So instead I'm fixing the snarl-up and letting lighttpd sit unused, until it's no longer required. Lighttpd is a nice package and I used it on a project where a lightweight webserver was needed, but in this case roundcubemail needs to defer to the sysop's choice of webserver. Could you please refer to "httpd" as the facility needed by roundcubemail rather than picking a specific one of the various available webservers? Both apache2 and lighttpd provide this generic facility, and I assume that nginx does also. Also, it's a little bizarre and inefficient to install roundcubemail on a different host from the webserver and then make it available to the webserver on a SAN-like kludge like NFS, but that kind of baroque storage architecture seems to be the name of the game in the enterprise today. I'd also like you to change "require" to "recommend" to accommodate situations like that. I'm surprised not to see any hits in a bug search for "roundcubemail lighttpd" that I could add a "mee too" comment to. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1187513] New: Spanish keyboard randomly stops working in some applications
by bugzilla_noreply＠suse.com 03 Aug '22

03 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1187513 Bug ID: 1187513 Summary: Spanish keyboard randomly stops working in some applications Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: teo8976(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On Spanish keyboards (among others, I guess), you type accented characters such as "��" or "��" by hitting the key for the accent ("`" or "��" in the examples above) followed by the letter. This normally works in all applications that I've ever tried in OpenSUSE. Starting recently, it sometimes randomly happens that this suddenly stops working in some applications but not others. When this happens, hitting the accent key followed by a letter results in just the plain unaccented letter. For example, "`"+"e" results in "e" instead of "��". Until today (and since it started happening a few days ago), I had only seen this in Kate. It would stop working in Kate while still working in other applications (usually I would try Chrome) and more importantly, it would get fixed by restarting Kate. Today it happened once more but it also started failing in Konsole and Telegram Desktop. This time, restarting any of the affected application would NOT fix that application. And even restarting all the apparently affected applications didn't. Rebooting did. I reported this to KDE because initially I was observing it only in Kate but they told me: """" Looks like the Qt key composition is broken for you. That would explain why this fails for Qt applications (Telegram Desktop is Qt based, too). I would propose to report this upstream to openSUSE. This seems to be no KDE/Kate specific issue. """" https://bugs.kde.org/show_bug.cgi?id=438820 Operating System: openSUSE Tumbleweed 20210612 KDE Plasma Version: 5.22.0 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.9-1-default (64-bit) Graphics Platform: X11 Processors: 8 �� Intel�� Core�� i7-1065G7 CPU @ 1.30GHz Memory: 7.3 GiB of RAM Graphics Processor: Mesa DRI Intel�� Iris�� Plus Graphics -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1186870] New: python-rpm-macros different dependency generated python-six
by bugzilla_noreply＠suse.com 02 Aug '22

02 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1186870 Bug ID: 1186870 Summary: python-rpm-macros different dependency generated python-six Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: rpm(a)fthiessen.de QA Contact: qa-bugs(a)suse.de CC: mcepl(a)suse.com Found By: --- Blocker: --- I am not sure if this is an issue with the python-rpm-macros package or python-six. If you use the dependency generator and your package uses python-six it will generate a dependency like this: > python3.6dist(six) >= 1.10 But this can not be satisfied, as python-six only provides > python36-six = 1.16.0-103.2 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1191088] New: perl-Bootloader: finish UsrMerge, install to /usr
by bugzilla_noreply＠suse.com 02 Aug '22

02 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1191088 Bug ID: 1191088 Summary: perl-Bootloader: finish UsrMerge, install to /usr Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: snwint(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1191054 Found By: --- Blocker: --- Following up on the discussion on the Factory list https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message… All packages installing files into /bin, /sbin, /lib and /lib64 should change the location to the counterpart in /usr instead. Please consider doing that for perl-Bootloader. If perl-Bootloader still needs to build for released distros you may keep the legacy locations within a "%if %suse_version < 1550" block of course. If you do that, please do *NOT* install symlinks from/to /usr as it was done with some packages in the past. Move the files in question instead. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1191074] New: makedev: finish UsrMerge, install to /usr
by bugzilla_noreply＠suse.com 02 Aug '22

02 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1191074 Bug ID: 1191074 Summary: makedev: finish UsrMerge, install to /usr Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: puzel(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1191054 Found By: --- Blocker: --- Following up on the discussion on the Factory list https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message… All packages installing files into /bin, /sbin, /lib and /lib64 should change the location to the counterpart in /usr instead. Please consider doing that for makedev. If makedev still needs to build for released distros you may keep the legacy locations within a "%if %suse_version < 1550" block of course. If you do that, please do *NOT* install symlinks from/to /usr as it was done with some packages in the past. Move the files in question instead. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1190649] New: go1.17 release tracking
by bugzilla_noreply＠suse.com 01 Aug '22

01 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190649 Bug ID: 1190649 Summary: go1.17 release tracking Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: jkowalczyk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- go1.17 (released 2021-08-16) is a major release of Go. Minor releases of go1.17.x will be provided through August 2022. This issue tracks go1.17.x releases packaged and submitted initially to openSUSE:Factory and can be referenced in submissions to additional repositories. Go Release Cycle https://github.com/golang/go/wiki/Go-Release-Cycle Go Release history https://golang.org/doc/devel/release.html -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1191047] New: sssd: use %_pam_moduledir
by bugzilla_noreply＠suse.com 01 Aug '22

01 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1191047 Bug ID: 1191047 Summary: sssd: use %_pam_moduledir Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: scabrero(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1190946 Found By: --- Blocker: --- The pam package offers a number of macros to avoid hardcoding directory names in spec files: https://build.opensuse.org/package/view_file/openSUSE:Factory/pam/macros.pam Please consider using at least the %_pam_moduledir macro in order to have the package follow UsrMerge. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1160019] New: "Metadata corruption detected at xfs_inode_buf_verify"
by bugzilla_noreply＠novell.com 31 Jul '22

31 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1160019 Bug ID: 1160019 Summary: "Metadata corruption detected at xfs_inode_buf_verify" 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: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This happened on a fresh Leap15.1 installation on a laptop, SATA SSD, /home file system. Kernel 4.12.14-lp151.28.36-default. > Dec 28 19:02:47 pallas kernel: XFS (dm-0): Metadata corruption detected at xfs_inode_buf_verify+0x72/0xf0 [xfs], xfs_inode block 0x4b860 > Dec 28 19:02:47 pallas kernel: XFS (dm-0): Unmount and run xfs_repair > Dec 28 19:02:47 pallas kernel: XFS (dm-0): First 64 bytes of corrupted metadata buffer: > Dec 28 19:02:47 pallas kernel: ffff8801f164f000: 49 4e 41 ed 03 01 00 00 00 00 04 58 00 00 00 64 INA........X...d > Dec 28 19:02:47 pallas kernel: ffff8801f164f010: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ > Dec 28 19:02:47 pallas kernel: ffff8801f164f020: 5e 01 34 bd 25 b4 38 63 5d ff e7 a6 01 cc 26 9e ^.4.%.8c].....&. > Dec 28 19:02:47 pallas kernel: ffff8801f164f030: 5d ff e7 a6 01 cc 26 9e 00 00 00 00 00 00 00 34 ].....&........4 The same message is repeated a few times, eventually the FS is mounted r/o, and all kinds of weird failures result. AFAICS in the code in fs/xfs/libxfs/xfs_inode_buf.c, the 15.1 kernel tests nothing but the magic number (byte 0-1, 49 4e) and version (byte 4, 03), so the pattern dumped should be correct. But this is only the 1st inode in the buffer, so subsequent inodes might be bad. However I dumped a full 4k block att offset 0x4b860 and all inode headers seem to be ok so that far. The FS couldn't be umounted, so I rebooted into single-user mode, umounted /home, and ran xfs_repair, which showed nothing of interest: > Phase 1 - find and verify superblock... > - block cache size set to 374008 entries > Phase 2 - using internal log > - zero log...u > zero_log: head block 55736 tail block 55736 > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - process newly discovered inodes... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 3 > - agno = 2 > - agno = 1 > Phase 5 - rebuild AG headers and trees... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - traversing filesystem ... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - traversal finished ... > - moving disconnected inodes to lost+found ... > Phase 7 - verify and correct link counts... > > XFS_REPAIR Summary Sat Dec 28 21:02:45 2019 > > Phase Start End Duration > Phase 1: 12/28 21:02:44 12/28 21:02:45 1 second > Phase 2: 12/28 21:02:45 12/28 21:02:45 > Phase 3: 12/28 21:02:45 12/28 21:02:45 > Phase 4: 12/28 21:02:45 12/28 21:02:45 > Phase 5: 12/28 21:02:45 12/28 21:02:45 > Phase 6: 12/28 21:02:45 12/28 21:02:45 > Phase 7: 12/28 21:02:45 12/28 21:02:45 > > Total run time: 1 second > done A very similar was observed some days later after only a couple of minutes of uptime. > Jan 02 10:35:10 pallas.mittagstun.de kernel: XFS (dm-0): Metadata corruption detected at xfs_inode_buf_verify+0x72/0xf0 [xfs], xfs_inode block 0x746b180 > Jan 02 10:35:10 pallas.mittagstun.de kernel: XFS (dm-0): Unmount and run xfs_repair > Jan 02 10:35:10 pallas.mittagstun.de kernel: XFS (dm-0): First 64 bytes of corrupted metadata buffer: > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d000: 49 4e 81 a4 03 02 00 00 00 00 04 58 00 00 00 64 IN.........X...d > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d010: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d020: 5e 07 ba 06 1c 4b f6 68 5e 07 ba 04 18 7a e7 4b ^....K.h^....z.K > Jan 02 10:35:11 pallas.mittagstun.de kernel: ffff8801dd24d030: 5e 07 ba 04 18 7a e7 4b 00 00 00 00 00 00 09 e8 ^....z.K........ I wonder if this is an indication of corrupt hardware, and if yes, what (SSD? CPU? Memory? Other?). The SSD in the laptop is brand new; the respective statement by the vendor is corroborated by SMART data (power-on hours). I have run a simple "surface test" (write pattern & verify) on the affected logical volume with fio, and found no errors (only a single test pass thus far). Perhaps noteworthy, I saw also some BTRFS checksum errors in the logs (from root file system): > Dec 28 19:04:17 pallas kernel: BTRFS warning (device sda2): sda2 checksum verify failed on 158384128 wanted D1502CDD found 7F3B5CF3 level 0 > > Jan 02 10:18:00 pallas.mittagstun.de kernel: BTRFS warning (device sda2): csum failed root 267 ino 232862 off 16384 csum 0xed735e63 expected csum 0x7e1dece1 mirror 1 > > Jan 02 10:28:27 pallas.mittagstun.de kernel: BTRFS warning (device sda2): csum failed root 267 ino 248644 off 0 csum 0x347357c0 expected csum 0x2e8516b0 mirror 1 -- You are receiving this mail because: You are on the CC list for the bug.

2 16