https://bugzilla.suse.com/show_bug.cgi?id=1198668
Bug ID: 1198668
Summary: Tumbleweed: Purge old kernels service block during
boot
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: petr.vorel(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Sometimes "Purge old kernels" service does not run after booting, but during
boot, which slows down boot:
$ LC_ALL=C journalctl -b 0 |grep -i purge
Apr 20 08:16:01 dell5510 systemd[1]: Starting Purge old kernels...
Apr 20 08:16:02 dell5510 zypper[1546]: Preparing to purge obsolete kernels...
Apr 20 08:17:09 dell5510 systemd[1]: purge-kernels.service: Deactivated
successfully.
Apr 20 08:17:09 dell5510 systemd[1]: Finished Purge old kernels.
Apr 20 08:17:09 dell5510 systemd[1]: purge-kernels.service: Consumed 53.594s
CPU time.
It started few weeks ago, it does not happen every boot, but maybe once a week.
But bothered me enough to report the problem.
$ LC_ALL=C rpm -qi purge-kernels-service
Name : purge-kernels-service
Version : 0
Release : 8.4
Architecture: noarch
Install Date: Tue Feb 22 11:51:00 2022
Group : Unspecified
Size : 346
License : MIT
Signature : RSA/SHA256, Sat Feb 19 22:50:00 2022, Key ID b88b2fd43dbdc284
Source RPM : purge-kernels-service-0-8.4.src.rpm
Build Date : Sat Feb 19 22:37:41 2022
...
$ lsb_release -a
LSB Version: n/a
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
Release: 20220415
Codename: n/a
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1191381
Bug ID: 1191381
Summary: gnu-compilers-hpc: Move rpm macros to %_rpmmacrodir
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: eich(a)suse.com
Reporter: lnussel(a)suse.com
QA Contact: qa-bugs(a)suse.de
Blocks: 1191379
Found By: ---
Blocker: ---
rpm macros aren't config files for the administrator, as such they
should be installed into %_rpmmacrodir (ie /usr/lib/rpm/macros.d)
instead of /etc/rpm.
Please consider adjusting gnu-compilers-hpc
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1175587
Bug ID: 1175587
Summary: windows:mingw:win{32|64}/mingw{32|64}-filesystem:
Deprecated external dependency generator is used
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: 3rd party software
Assignee: fstrba(a)suse.com
Reporter: ralf.habacker(a)freenet.de
QA Contact: screening-team-bugs(a)suse.de
CC: fridrich.strba(a)bluewin.ch, hib(a)hiberis.nl,
idonmez(a)suse.com, mkbosmans(a)gmail.com
Found By: ---
Blocker: ---
On building packages there is always a message printed that a 'Deprecated
external dependency generator is used'.
The reason for this message is located in macros.mingw32
(https://build.opensuse.org/package/view_file/windows:mingw:win32/mingw32-fi…)
%_mingw32_package_header \
%global __strip %{_mingw32_strip} \
%global __objdump %{_mingw32_objdump} \
%global _use_internal_dependency_generator 0 \
%global __find_requires %{_mingw32_findrequires} \
%global __find_provides %{_mingw32_findprovides} \
%global __os_install_post %{_mingw32_install_post}
by specifing '_use_internal_dependency_generator 0' and overriding the
__find_requires and __find_provides.
Recent obs dependency support uses *.attr file as shown below:
cat /usr/lib/rpm/fileattrs/cmake.attr
%__cmake_provides %{_rpmconfigdir}/cmake.prov
%__cmake_path
^/usr/lib(64)?/cmake/.*/.*(Config\.cmake|-config\.cmake)
where the mentioned file cmake.prov does the work of generating a list of
packages that are provided by cmake configuration files.
Similar files exists for debuginfo
cat /usr/lib/rpm/fileattrs/debuginfo.attr
%__debuginfo_provides %{_rpmconfigdir}/debuginfo.prov
%__debuginfo_path ^/usr/lib/debug/
for pkgconfig files
cat /usr/lib/rpm/fileattrs/pkgconfig.attr
%__pkgconfig_provides %{_rpmconfigdir}/pkgconfigdeps.sh --provides
%__pkgconfig_requires %{_rpmconfigdir}/pkgconfigdeps.sh --requires
%__pkgconfig_path
^((%{_libdir}|%{_datadir})/pkgconfig/.*\.pc|%{_bindir}/pkg-config)$
for executables
cat /usr/lib/rpm/fileattrs/elf.attr
%__elf_provides %{_rpmconfigdir}/elfdeps --provides
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elf_requires %{_rpmconfigdir}/elfdeps --requires
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elf_magic ^(setuid,? )?(setgid,? )?(sticky )?ELF
(32|64)-bit.*executable
%__elf_flags exeonly
%__elf_exclude_path ^/usr/lib/debug/
for shared libraries
cat /usr/lib/rpm/fileattrs/elflib.attr
%__elflib_provides %{_rpmconfigdir}/elfdeps --assume-exec --provides
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elflib_requires %{_rpmconfigdir}/elfdeps --assume-exec --requires
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elflib_magic ^(setuid )?(setgid )?(sticky )?ELF (32|64)-bit.*shared
object
%__elflib_exclude_path ^/usr/lib/debug/
and others.
To take advantage of this type of support, the currently used files
mingw32-find-provides.sh and mingw32-find-requres.sh must be split into
implementations that handle a single category of corresponding files.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166537
Bug ID: 1166537
Summary: osc rq accept - forwarding request causes backtrace
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: marco.strigl(a)suse.com
Reporter: suse-beta(a)cboltz.de
QA Contact: qa-bugs(a)suse.de
CC: suse-tux(a)gmx.de
Found By: ---
Blocker: ---
When accepting a SR to a devel project, osc asks if I want to forward the SR to
Factory. I answered "y", but got this nice backtrace instead of a SR to
Factory:
# osc rq accept 784420
Result of change request state: ok
openSUSE:Factory
Forward this submit to it? ([y]/n)y
Traceback (most recent call last):
File "/usr/bin/osc", line 41, in <module>
r = babysitter.run(osccli)
File "/usr/lib/python3.8/site-packages/osc/babysitter.py", line 64, in run
return prg.main(argv)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 344, in main
return self.cmd(args)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 367, in cmd
retval = self.onecmd(argv)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 501, in onecmd
return self._dispatch_cmd(handler, argv)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 1232, in
_dispatch_cmd
return handler(argv[0], opts, *args)
File "/usr/lib/python3.8/site-packages/osc/commandline.py", line 2652, in
do_request
project, package, html.escape(msg, quote=False))
NameError: name 'html' is not defined
Wild guess: missing "import html"?
Note: commandline.py has an "import html" in do_submitrequest(), but this
import isn't visible to do_request(). Also note that there are more functions
in this file that call html.escape() without importing html before and will
probably break in a similar way. Doing the "import html" in the file header
instead of inside the functions might be a good idea.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195395
Bug ID: 1195395
Summary: hardware/wpa_supplicant: Not able to connect to WLAN
after wpa_supplicant update to version 2.10
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Major
Priority: P5 - None
Component: 3rd party software
Assignee: karol(a)babioch.de
Reporter: reiokorn(a)tutanota.com
QA Contact: screening-team-bugs(a)suse.de
CC: cfamullaconrad(a)suse.com
Found By: ---
Blocker: ---
Created attachment 855766
--> http://bugzilla.opensuse.org/attachment.cgi?id=855766&action=edit
log file of wpa_supplicant
Hello,
after the recent update to Tumbleweed, and the wpa_supplicant to version 2.10,
I'm no longer able to connect to my home WLAN with my laptop.
I've included the wpa_supplicant.log file for diagnosis.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1195634
Bug ID: 1195634
Summary: Base Report does not work
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: LibreOffice
Assignee: screening-team-bugs(a)suse.de
Reporter: hd(a)swiateck.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 855943
--> http://bugzilla.opensuse.org/attachment.cgi?id=855943&action=edit
Error after open
to start a report the error message appears
See attachment
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1199618
Bug ID: 1199618
Summary: [Build 20220516] openQA test fails in fanotify16 (LTP)
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: aarch64
URL: https://openqa.opensuse.org/tests/2353240/modules/fano
tify16/steps/7
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: guillaume.gardet(a)arm.com
QA Contact: qa-bugs(a)suse.de
Found By: openQA
Blocker: Yes
## Observation
openQA test in scenario
opensuse-Tumbleweed-JeOS-for-AArch64-aarch64-jeos-ltp-syscalls@aarch64-HD24G
fails in
[fanotify16](https://openqa.opensuse.org/tests/2353240/modules/fanotify16/st…
Error log:
fanotify.h:336: TBROK: fanotify_mark (3, FAN_MARK_ADD, ..., AT_FDCWD, ".")
failed: EXDEV (18)
Test process returned unkown none zero value (2).
Test took approximately 0.581575272008195 seconds
Some test output could not be parsed: 9 lines were ignored.
## Test suite description
## Reproducible
Fails since (at least) Build
[20220302](https://openqa.opensuse.org/tests/2224057)
## Expected result
Last good: (unknown) (or more recent)
## Further details
Always latest result in this scenario:
[latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu…
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1197556
Bug ID: 1197556
Summary: gnome42 completely unusable on Lenovo P15
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: GNOME
Assignee: gnome-bugs(a)suse.de
Reporter: donald.vosburg(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Logging into GNOME on Lenovo P15 with DockStation results in hung system unable
to launch applications.
Keyboard and mouse become unresponsive, networking on dock gets disabled, and
the only alternative is hard power-off.
Using plasma on the same OS on the same hardware works perfectly.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1198547
Bug ID: 1198547
Summary: power-profiles-daemon package is missing in Leap 15.4
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.4
Hardware: x86-64
OS: openSUSE Leap 15.4
Status: NEW
Severity: Normal
Priority: P5 - None
Component: KDE Workspace (Plasma)
Assignee: opensuse-kde-bugs(a)opensuse.org
Reporter: opendreas(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
One of the main features of the new LTS Plasma was power profiles, but this
package is missing in Leap 15.4.
Is it possible to add it?
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1176566
Bug ID: 1176566
Summary: Installing ignition leads to unbootable system
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: MicroOS
Assignee: kubic-bugs(a)opensuse.org
Reporter: rombert(a)apache.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I've installed ignition locally on Tumbleweed, to be able to validate ignition
files locally. After a reboot I was presented with an emergency shell, leading
down a wild goose chase for disabling ignition permanently.
It all went away after setting up a chroot and removing all traces of ignition,
but it would be much much better if installing it would not lead to a broken
system by default.
I saw some errors related to the ignition generator, and the systemd unit file
was broken, but could not save any logs unfortunately. But it should be easy
enough to reproduce if anyone cares:
# zypper in ignition
# reboot
(Might be related to #1172592)
--
You are receiving this mail because:
You are on the CC list for the bug.