October 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 997317] New: grub2-branding lacks posttrans
by bugzilla_noreply＠novell.com 07 Sep '22

07 Sep '22

http://bugzilla.suse.com/show_bug.cgi?id=997317 Bug ID: 997317 Summary: grub2-branding lacks posttrans Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: ohering(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- grub2-branding creates a grub2.cfg in its %post. this is a very expensive operation, in combination with os-prober. there is nothing in that pkg which requires immediate action. cumulate the required steps and do it once in a single %posttrans. -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1187656] New: mdadm: mdcheck_start.state is in "activating" for up to 6 hrs
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1187656 Bug ID: 1187656 Summary: mdadm: mdcheck_start.state is in "activating" for up to 6 hrs Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: daniel.molkentin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The /usr/lib/systemd/system/mdcheck_start.service file states the following: [Service] Type=oneshot Environment="MDADM_CHECK_DURATION=6 hours" "oneshot" implies that the service will remain in "activating" state for the entire duration (long, up to the stated 6 hours. It would be better to use Type=simple, which does not keep the unit in "activating" mode. This is an important difference in semantics, because monitoring tools (e.g. prometheus) tend to alert if a unit is stuck in "activating" for more than (typically) 5 minutes (which usually makes sense, but not here). The only side effect that I could find is that systemd will not wait for follow-up units to start, but since this is a timer-triggered unit, I would not expect anyone else to depend on this service. Verified by adding an override file. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1047852] New: knotify_libjack audio kcrash on pthread_key_create() at ../common/JackError.cpp:88
by bugzilla_noreply＠novell.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1047852 Bug ID: 1047852 Summary: knotify_libjack audio kcrash on pthread_key_create() at ../common/JackError.cpp:88 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE3 Assignee: anixx(a)opensuse.org Reporter: drankinatty(a)suddenlinkmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 731684 --> http://bugzilla.opensuse.org/attachment.cgi?id=731684&action=edit knotify_libjack wdebug kcrash file (the 6 is just the 6th one I saved) A knotify/libjack.so.0 crash will regularly occur once during a session. It may take a day or two for the bug to appear, but on access to sound theme sound (no one in particular, e.g. dialog-open, minimize, etc.) a kcrash report appears and the desktop sounds no longer play until you restart the desktop. This time it took 2 days 5:29 minutes under heavy use to occur. It is strangely random when it happens, but very consistent that it *will* happen. This is not new and has been around at least since 13.1 (it may go back to 11.4). I have experiences this on two separate laptops with 13.1 and Leap 42.2. (I really think it was there in 11.4, but I'm far too old to remember) I have attached a wdebug.kcrash that details the error. -- You are receiving this mail because: You are on the CC list for the bug.

2 33

[Bug 1185657] New: [Tracker] Packages installing rpm macro files to /etc/rpm instead of /usr/lib/rpm/macros.d
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1185657 Bug ID: 1185657 Summary: [Tracker] Packages installing rpm macro files to /etc/rpm instead of /usr/lib/rpm/macros.d Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- RPM reads its macro definitions from various places Packages are supposed to install their data to /usr/lib/rpm/macros.d A few legacy packages still use /etc/rpm for this though. Changing the location is in line with the goal of an empty /etc to reset a system state -- You are receiving this mail because: You are on the CC list for the bug.

1 46

[Bug 1185669] New: openstack-macrosl: rpm macro files installed to /etc/rpm
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1185669 Bug ID: 1185669 Summary: openstack-macrosl: rpm macro files installed to /etc/rpm Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: OpenStack Assignee: cloud-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The package openstack-macros installs the files /etc/rpm/macros.openstack-{common,singlespec,suse} RPM packages though are supposed to install their macro files to /usr/lib/rpm/macros.d (use the variable %{_rpmmacrodir}) This in order to further work towards the goal of 'empty /etc' for a default setup. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1185700] New: Digikam 7.2.0 failing to launch.
by bugzilla_noreply＠suse.com 06 Sep '22

06 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1185700 Bug ID: 1185700 Summary: Digikam 7.2.0 failing to launch. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: paul.pgp-7(a)gmx.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Following an update of Digikam to 7.2.0-214.19 ( from http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed ) it's failing to launch. Attempting to start from the command line the following is output: paul@Orion-15:~$ digikam No protocol specified QCommandLineParser: already having an option named "h" QCommandLineParser: already having an option named "help-all" QCommandLineParser: already having an option named "v" digikam: symbol lookup error: /usr/lib64/libdigikamgui.so.7.2.0: undefined symbol: _ZN2cv3dnn14dnn4_v202103013NetC1Ev paul@Orion-15:~$ -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 952799] New: bogofilter-{db,sqlite3} insists on using wordlist.tc
by bugzilla_noreply＠novell.com 06 Sep '22

06 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=952799 Bug ID: 952799 Summary: bogofilter-{db,sqlite3} insists on using wordlist.tc Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gour(a)atmarama.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- In the past, when using other Linux distros I was mostly using bogofilter with sqlite3 back-end, but after switching to openSUSE I've decided to convert to 'default' (Berkeley) DB backend. Unfortunately, after bogofilter package was updated in openSUSE, it looks it does insist on using $HOME/.bogofilter/wordlist.tc for the database name even if one uses Berkeley DB or Sqlite3 back-ends? When I try to use my old wordlist.db, Bogofilter plugin (Claws & Evolution) starts from the scratch and creates wordlist.tc. I wonder about this line in *.spec: %if 0%{?suse_version} > 1320 iow. whether the new Bogofilter package is ready to use existing setup with appropriate back-end (not equal to TokyoCabinet)? -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 1107615] New: sysconfig requires ifup
by bugzilla_noreply＠novell.com 06 Sep '22

06 Sep '22

http://bugzilla.suse.com/show_bug.cgi?id=1107615 Bug ID: 1107615 Summary: sysconfig requires ifup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: mt(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- sysconfig requires ifup and that pulls in wicked. For a basic container chroot that is not needed actually. Can we drop requiring ifup? Alternatively or in addition is it safe to not install sysconfig at all? netconfig which is needed for /etc/resolv.conf is separate anyways so sysconfig basically just provides some skeletons for ppp/ip-up and config files. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1191064] New: ipvsadm: finish UsrMerge, install to /usr
by bugzilla_noreply＠suse.com 06 Sep '22

06 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1191064 Bug ID: 1191064 Summary: ipvsadm: 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: mt(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 ipvsadm. If ipvsadm 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 1

[Bug 1190340] New: armv7hl 5.14 kernel build fails for Leap 15.4
by bugzilla_noreply＠suse.com 06 Sep '22

06 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1190340 Bug ID: 1190340 Summary: armv7hl 5.14 kernel build fails for Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: tiwai(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Now we start building the armv7hl kernel for Leap 15.4, and it fails as: [ 9793s] GEN modules.builtin [ 9793s] LD .tmp_vmlinux.btf [ 9827s] BTF .btf.vmlinux.bin.o [ 9884s] [4957384] STRUCT thread_info's field 'vfpstate' offset=2048 bit_size=0 type=4957356 Error emitting field [ 9884s] Encountered error while encoding BTF. .... [ 9994s] FAILED: load BTF from vmlinux: No such file or directory [ 9994s] make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-default-5.14.2/linux-5.14/Makefile:1200: vmlinux] Error 255 My initial attempt worked because BTF wasn't enabled due to the old tools. OTOH, the same 5.14 build is OK with stable branch, so there is still some missing piece, supposedly. -- You are receiving this mail because: You are on the CC list for the bug.

1 11