March 2018 - openSUSE Bugs - openSUSE Mailing Lists

[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 1084015] New: Include fixes from en_US "translation" to sources
by bugzilla_noreply＠novell.com 13 Feb '20

13 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1084015 Bug ID: 1084015 Summary: Include fixes from en_US "translation" to sources 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: sbrabec(a)suse.com QA Contact: jsrain(a)suse.com CC: locilka(a)suse.com, padraig.dillon(a)microfocus.com Found By: --- Blocker: --- Created attachment 762751 --> http://bugzilla.opensuse.org/attachment.cgi?id=762751&action=edit problems in en_US In past, strings were fixed in RC phase by introduction of and en_US translation. It was expected, that it will be incorporated back to the code after release. Years passed, and it did not happen. Some of these hotfixes are 16 years old. Now we have a bunch of strange en_US "translations" that needs to be reviewed and included. It consist of: 1. English typo and stylistic fixes. These should be included, and existing translations to other languages updated to keep them. Example: https://github.com/yast/yast-autoinstallation/blob/f93f318b744c21557201c278… en_US changed "Frametitle" to "Frame Title". All existing translations are probably OK. To keep existing translations, it requires coordinated merge of these changes and translation updates. 2. Formatting fixes. The good: English is OK. The bad: All translators translated the source string, not the fixed en_US string. With a bit of luck, it is possible to mass fix translations. Example: https://github.com/yast/yast-add-on/blob/0c44e966702b0aefc2439eb0da384260a4… en_US removed the trailing "\n" All translations have incorrect formatting. 3. Formatting fixes that change meaning of the string. The good: English is OK. The bad: All translators translated the source string with the incorrect meaning, not the fixed en_US string. Example: https://github.com/yast/yast-apparmor/blob/afd62f82724f750d7af850f60f6d52a2… en_US made a question from the sentence. All translators translated the source string, not the fixed en_US string. Impact on the translation meaning is unknown. 4. Hot fixes of apparent nonsense. All translators translated the source string, not the fixed en_US string. With a bit of luck, it is possible to mass fix translations. Example: https://github.com/yast/yast-apparmor/blob/afd62f82724f750d7af850f60f6d52a2… en_US removed the nonsense "? " at the beginning. Translators were not aware that "? " is a mistake, and used it in the translations. And finally, en_GB mixes all the above plus: 5. Changes for British English. As nobody actively maintains en_GB, it causes very strange result: I an few strings, AppArmor is called AppArmour, in all other "untranslated" strings, AppArmor is the name. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 966255] New: System does not boot
by bugzilla_noreply＠novell.com 09 Feb '20

09 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=966255 Bug ID: 966255 Summary: System does not boot Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: rjschwei(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- kernel 4.4.0.3 Has encrypted user partition. Hangs at Ignoring BGRT: Invalid version 0 (expected 1) This appears to happen right before the point where I would expect to enter my passphrase. -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 1068707] New: bcache broken on s390x
by bugzilla_noreply＠novell.com 08 Feb '20

08 Feb '20

http://bugzilla.suse.com/show_bug.cgi?id=1068707 Bug ID: 1068707 Summary: bcache broken on s390x Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: ro(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- trying to repeat on s390x what worked on aarch64 ... OBS_WORKER_DISK=/dev/mapper/3600a098051764b2d515d436d66416b4f wipefs -f -a $OBS_WORKER_DISK modprobe zram num_devices=1 modprobe bcache echo 8G > /sys/block/zram0/disksize wipefs -f -a /dev/zram0 make-bcache --wipe-bcache --block 4k --bucket 2M -B $OBS_WORKER_DISK -C /dev/zram0 # up to here it seemed to work, but: echo /dev/zram0 > /sys/fs/bcache/register -bash: echo: write error: Invalid argument in dmesg: [1256250.924470] zram: Added device: zram0 [1256258.363017] zram0: detected capacity change from 0 to 8589934592 [1256269.146000] bcache: register_bcache() error opening /dev/dm-2: Not a bcache superblock [1256275.462897] bcache: register_bcache() error opening /dev/zram0: Not a bcache superblock so the written superblock is not recognized ... endianess issue ? -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1052140] New: NetworkManager dispatcher script "nfs" is mounting nfs shares from fstab with option "noauto"
by bugzilla_noreply＠novell.com 01 Feb '20

01 Feb '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1052140 Bug ID: 1052140 Summary: NetworkManager dispatcher script "nfs" is mounting nfs shares from fstab with option "noauto" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The NetworkManager dispatcher script "nfs" is mounting nfs shares from fstab, which have set option "noauto". In my environment this is a good thing, but it is not the expected behaviour. Perhaps we could have a new fstab option like "x-nm.mount" for nfs shares to explicitly control this behaviour? The reason for experimenting with fstab options for nfs shares is the really strange "cooperation" of systemd and NetworkManager. Having the "auto" option set and nfs.service is active, systemd tries to mount the shares on boot, before network is available. This gives lots of errors in the log, although NetworkManager succeeds in mounting the share, when running the dispatcher script. With "auto" in fstab and a deactivated nfs.service neither systemd nor NetworkManager are trying to mount nfs shares. With "noauto" in fstab and an activated nfs.service systemd ignores the shares, but NetworkManager's nfs dispatcher is mounting them nevertheless. I tried x-systemd.automount, too. This worked generally, but after a hibernate/resume cycle all nfs shares were inaccessible. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1077870] New: librsvg-2-2-2.42.0-1.1.i586 contains SSE2 instructions
by bugzilla_noreply＠novell.com 30 Jan '20

30 Jan '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1077870 Bug ID: 1077870 Summary: librsvg-2-2-2.42.0-1.1.i586 contains SSE2 instructions Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i686 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: jan.kiszka(a)web.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since that revision, the library will crash on old i686 machines (Athlon XP) with illegal opcode because it tries to use SSE2. Regression over 2.40.20-1.1. Currently running 2.40.18-1.3 again because that's the only one I found in some archive. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1069396] New: sddm cannot be updated
by bugzilla_noreply＠novell.com 29 Jan '20

29 Jan '20

http://bugzilla.suse.com/show_bug.cgi?id=1069396 Bug ID: 1069396 Summary: sddm cannot be updated Classification: openSUSE Product: openSUSE Backports Version: SLE-12-SP3 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Packages Assignee: packagehub-bugs(a)suse.com Reporter: kukuk(a)suse.com QA Contact: packagehub-bugs(a)suse.com Found By: --- Blocker: --- If you try to update to the latest sddm version: Problem: nothing provides sddm-theme-openSUSE needed by sddm-branding-openSUSE-0.14.0-2.1.x86_64 Solution 1: deinstallation of sddm-branding-SLE-0.13.0-5.1.x86_64 Solution 2: do not install sddm-0.14.0-2.1.x86_64 Solution 3: break sddm-branding-openSUSE-0.14.0-2.1.x86_64 by ignoring some of its dependencies Reproduceable on SLES12 SP2 and SLES12 SP3. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1087277] New: Upgrade from Leap 42.3 to 15.0 Beta gives segmentation fault when trying to start KDE session
by bugzilla_noreply＠novell.com 29 Jan '20

29 Jan '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1087277 Bug ID: 1087277 Summary: Upgrade from Leap 42.3 to 15.0 Beta gives segmentation fault when trying to start KDE session Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: freek(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 765230 --> http://bugzilla.opensuse.org/attachment.cgi?id=765230&action=edit ksmserver.kcrash.txt First I describe the test setup, second the results. I have two spare ext4 partitions on my multi boot system with Leap 42.3, Tumbleweed and a newly installed Leap 15.0 Beta. I copied the home and system partition of 42.3 to the two spare partitions, each with a new label. The spare partitions are newly formatted with ext4 and both got a new unique label. I copied, using "rsync -a .." the root and home partition of the existing 42.3 to these new partitions. On the new system partition I changed in /etc/fstab the labels for / and /home to the new assigned labels. All partitions are mounted by label in /etc/fstab. I booted the latest image of Leap 15.0 Beta from a USB disk and performed an upgrade on the new partition with the copied 42.3 system. The old 42.3 system is still intact. The 42.3 system also has repository Education, KDE:Extra and Packman, so I had to resolve some conflicts and delete unavailable packages. But all in all I ended with an upgraded 42.3 to 15.0 Beta. However the bootloader showed some problems. Error message about /boot/grub2/device.map, which contained twice hd0. After the reboot only the old 42.3 system was bootable, the other three were not, although mentioned in the GRUB menu. I inspected /boot/grub2/ device.map and removed double entries, not only hd0, but also hd3, I used yast->bootloader to generate a new grub. I was able to boot all 4 systems. The upgraded 42.3 to 15.0 system showed a login screen and I entered the password. However after that, two application showed a segmentation fault, kdmserver and akonadictl. I was unable to use drkonqi to make a traceback, but some information about a traceback could be saved (see attachement). Apparently some information on the home partition causes this. The solution I found was to delete /home/<user>/.cache, after which I was able to login. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1082023] New: git send-email fails to authenticate with SMTP server
by bugzilla_noreply＠novell.com 29 Jan '20

29 Jan '20

http://bugzilla.suse.com/show_bug.cgi?id=1082023 Bug ID: 1082023 Summary: git send-email fails to authenticate with SMTP server Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ohering(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With current Tumbleweed git send-email fails to authenticate with the SMTP server. This used to work. since I rarly use git send-email I cant say when it started. The username/password combination works with mutt. Send this email? ([y]es|[n]o|[q]uit|[a]ll): y Net::SMTP>>> Net::SMTP(3.10) Net::SMTP>>> Net::Cmd(3.10) Net::SMTP>>> Exporter(5.72) Net::SMTP>>> IO::Socket::IP(0.38) Net::SMTP>>> IO::Socket(1.38) Net::SMTP>>> IO::Handle(1.36) Net::SMTP=GLOB(0x55b5df986d00)<<< 220 smtp.strato.de ESMTP RZmta (P7 -) Net::SMTP=GLOB(0x55b5df986d00)>>> EHLO sender Net::SMTP=GLOB(0x55b5df986d00)<<< 250-smtp.strato.de greets 2001:a62:816:91ff:a572:884d:f51d:1a86 Net::SMTP=GLOB(0x55b5df986d00)<<< 250-ENHANCEDSTATUSCODES Net::SMTP=GLOB(0x55b5df986d00)<<< 250-PIPELINING Net::SMTP=GLOB(0x55b5df986d00)<<< 250-8BITMIME Net::SMTP=GLOB(0x55b5df986d00)<<< 250-DELIVERBY Net::SMTP=GLOB(0x55b5df986d00)<<< 250-SIZE 104857600 Net::SMTP=GLOB(0x55b5df986d00)<<< 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN Net::SMTP=GLOB(0x55b5df986d00)<<< 250-STARTTLS Net::SMTP=GLOB(0x55b5df986d00)<<< 250-BURL imap Net::SMTP=GLOB(0x55b5df986d00)<<< 250-CHUNKING Net::SMTP=GLOB(0x55b5df986d00)<<< 250 HELP Net::SMTP=GLOB(0x55b5df986d00)>>> STARTTLS Net::SMTP=GLOB(0x55b5df986d00)<<< 220 Ready to start TLS Net::SMTP::_SSL=GLOB(0x55b5df986d00)>>> EHLO sender Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-smtp.strato.de greets 2001:a62:816:91ff:a572:884d:f51d:1a86 Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-ENHANCEDSTATUSCODES Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-PIPELINING Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-8BITMIME Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-DELIVERBY Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-SIZE 104857600 Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-BURL imap Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-CHUNKING Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250 HELP Net::SMTP::_SSL=GLOB(0x55b5df986d00)>>> EHLO sender Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-smtp.strato.de greets 2001:a62:816:91ff:a572:884d:f51d:1a86 Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-ENHANCEDSTATUSCODES Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-PIPELINING Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-8BITMIME Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-DELIVERBY Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-SIZE 104857600 Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-BURL imap Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250-CHUNKING Net::SMTP::_SSL=GLOB(0x55b5df986d00)<<< 250 HELP Net::SMTP::_SSL=GLOB(0x55b5df986d00)>>> AUTH DIGEST-MD5 ... -- You are receiving this mail because: You are on the CC list for the bug.

1 25

[Bug 1072274] New: network/tor: replace torctl with systemd service file
by bugzilla_noreply＠novell.com 13 Jan '20

13 Jan '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1072274 Bug ID: 1072274 Summary: network/tor: replace torctl with systemd service file Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: astieger(a)suse.com Reporter: opensuse-bz(a)riseup.net QA Contact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- Created attachment 752465 --> http://bugzilla.opensuse.org/attachment.cgi?id=752465&action=edit /usr/lib/systemd/system/tor-master.service (from Fedora) The current tor.service systemd file is a wrapper around torctl instead of being a native service file. This ticket is about making tor.service a native systemd service file. I'm attaching the following files: /usr/lib/systemd/system/tor.service /usr/lib/systemd/system/tor-master.service /usr/share/tor/defaults-torrc /etc/logrotate.d/tor These files are mostly copies from the Fedora package with very minor changes to the specifics in openSUSE (i.e. tor username). I tested them briefly on openSUSE Leap 42.3. This is related to #1071981 -- You are receiving this mail because: You are on the CC list for the bug.

1 9