@jcerny I downloaded the openscap git repo with fedpkg clone openscap --branch f29 -a . I installed thsoe build requirements in openscap.spec I didn't already have. I changed change all of the Requires lines in openscap.spec matching Requires: %{name} = %{version}-%{release} to Requires: %{name}= %{epoch}:%{version}-%{release}. I built the openscap packages using fedpkg --release f29 local which showed many gcc warnings, but the packages were all built correctly. I used sudo dnf upgrade on the packages I built, and they upgraded without any errors. I could provide more information if that would help.

4.18.14 has run normally.

I haven't seen the denials of send_msg between boltd and fwupd on dbus noted in #1632230 or of mounton between boltd and /run/systemd/unit-root/run/boltd in #1636823 since I've updated to 3.14.2-40 when starting gnome or gnome software. I haven't got any other denials with 3.14.2-40.

Adding "Epoch: 1" did solve the original problem of dnf considering 1.3.0_alpha2 to be a higher version number than 1.3.0. A possible way to resolve the new dnf errors would be to change all of those requires lines in openscap.spec at https://src.fedoraproject.org/rpms/openscap/blob/f29/f/openscap.spec like Requires: %{name}%{?_isa} = %{version}-%{release} to Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release}

For example, bind.spec at https://src.fedoraproject.org/rpms/bind/blob/f29/f/bind.spec uses lines like Requires: bind%{?_isa} = %{epoch}:%{version}-%{release}

You could alternatively revert the commit adding "Epoch: 1" and then change the version to something like 1.3.0_final which dnf might consider to be higher than 1.3.0_alpha2. You could create a scratch build on Koji, which I could test. I'm not sure how to create a scratch build though since I haven't been a package maintainer.

When I tried to run dnf upgrade on the 1.3.0-2 packages from Koji I got the following errors: Problem 1: cannot install the best update candidate for package openscap-containers-1.3.0_alpha2-2.fc29.noarch - nothing provides openscap = 1.3.0-2.fc29 needed by openscap-containers-1:1.3.0-2.fc29.noarch Problem 2: cannot install the best update candidate for package openscap-devel-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-devel-1:1.3.0-2.fc29.i686 Problem 3: cannot install the best update candidate for package openscap-engine-sce-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-engine-sce-1:1.3.0-2.fc29.i686 Problem 4: cannot install the best update candidate for package openscap-engine-sce-devel-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap-devel(x86-32) = 1.3.0-2.fc29 needed by openscap-engine-sce-devel-1:1.3.0-2.fc29.i686 - nothing provides openscap-engine-sce(x86-32) = 1.3.0-2.fc29 needed by openscap-engine-sce-devel-1:1.3.0-2.fc29.i686 Problem 5: cannot install the best update candidate for package openscap-perl-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-perl-1:1.3.0-2.fc29.i686 Problem 6: cannot install the best update candidate for package openscap-python3-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-python3-1:1.3.0-2.fc29.i686 Problem 7: cannot install the best update candidate for package openscap-scanner-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-scanner-1:1.3.0-2.fc29.i686 Problem 8: cannot install the best update candidate for package openscap-utils-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-utils-1:1.3.0-2.fc29.i686 - nothing provides openscap-scanner(x86-32) = 1.3.0-2.fc29 needed by openscap-utils-1:1.3.0-2.fc29.i686 Problem 9: problem with installed package openscap-utils-1.3.0_alpha2-2.fc29.i686 - package openscap-utils-1.3.0_alpha2-2.fc29.i686 requires openscap(x86-32) = 1.3.0_alpha2-2.fc29, but none of the providers can be installed - cannot install both openscap-1:1.3.0-2.fc29.i686 and openscap-1.3.0_alpha2-2.fc29.i686 - cannot install the best update candidate for package openscap-1.3.0_alpha2-2.fc29.i686 - nothing provides openscap(x86-32) = 1.3.0-2.fc29 needed by openscap-utils-1:1.3.0-2.fc29.i686 - nothing provides openscap-scanner(x86-32) = 1.3.0-2.fc29 needed by openscap-utils-1:1.3.0-2.fc29.i686 =================================================================================== Package Arch Version Repository Size =================================================================================== Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): openscap i686 1:1.3.0-2.fc29 @commandline 3.3 M Skipping packages with broken dependencies: openscap-containers noarch 1:1.3.0-2.fc29 @commandline 23 k openscap-devel i686 1:1.3.0-2.fc29 @commandline 1.4 M openscap-engine-sce i686 1:1.3.0-2.fc29 @commandline 25 k openscap-engine-sce-devel i686 1:1.3.0-2.fc29 @commandline 12 k openscap-perl i686 1:1.3.0-2.fc29 @commandline 319 k openscap-python3 i686 1:1.3.0-2.fc29 @commandline 338 k openscap-scanner i686 1:1.3.0-2.fc29 @commandline 57 k openscap-utils i686 1:1.3.0-2.fc29 @commandline 24 k

Updating the requires to include the new epoch 1 such as openscap = 1:1.3.0-2.fc29 in each of the subpackages might resolve those dependency problems.

3.14.2-37 seems to be functioning normally except for the following boltd denials which occurred when gnome and gnome software started boltd. Those denials were described in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=1632230 https://bugzilla.redhat.com/show_bug.cgi?id=1636823

type=AVC msg=audit(1539573288.602:334): avc: denied { mounton } for pid=4420 comm="(boltd)" path="/run/systemd/unit-root/run/boltd" dev="tmpfs" ino=114171 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:boltd_var_run_t:s0 tclass=dir permissive=0

type=USER_AVC msg=audit(1539573288.895:336): pid=682 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.513 spid=4420 tpid=4415 scontext=system_u:system_r:boltd_t:s0 tcontext=system_u:system_r:fwupd_t:s0 tclass=dbus permissive=1 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

@kalev The crashes in #1638767 and #1638784 still occurred after I downgraded to appstream-data-29-6 so they are unrelated to this update. The appstream data shows up normally in gnome software. The full traces of #1638767 show that the function gs_plugin_add_category_apps at ../plugins/core/gs-plugin-desktop-categories.c:100 has the pointer category=0x0 and desktop_groups = gs_category_get_desktop_groups (category); so desktop_groups = 0x0. The line where the segmentation fault occurred was if (desktop_groups->len > 0) which might have been due to a null pointer dereference. I'll add additional information on those entries with the full traces.

I updated to appstream-0.12.2-2. I ran sudo dnf reinstall appstream-data which didn't show the core dumps in appstreamcli I commented on earlier. I tried to test gnome software, which crashed once on the main screen and once on the Updates screen after pressing the refresh button. I didn't see any mention of appstream in the traces and journal messages right before the crashes. I filed the following bugzilla entries about the crashes https://bugzilla.redhat.com/show_bug.cgi?id=1638767 https://bugzilla.redhat.com/show_bug.cgi?id=1638784

I got the following errors running sudo dnf upgrade --refresh Problem 1: cannot install the best update candidate for package nodejs-1:10.11.0-1.fc29.i686 - nothing provides libuv >= 1:1.23.2 needed by nodejs-1:10.12.0-1.fc29.i686 Problem 2: package npm-1:6.4.1-1.10.12.0.1.fc29.i686 requires nodejs = 1:10.12.0-1.fc29, but none of the providers can be installed - cannot install the best update candidate for package npm-1:6.4.1-1.10.11.0.1.fc29.i686 - nothing provides libuv >= 1:1.23.2 needed by nodejs-1:10.12.0-1.fc29.i686

The libuv-1.23.2-1.fc29 packages on Koji might need to be added to this update to resolve the dependency problems.

4.18.13 has been functioning normally. The default tests passed or skipped.

openscap-1.3.0-1 isn't being installed when I run sudo dnf upgrade --refresh because I have openscap-1.3.0_alpha2-2.fc29 installed and dnf considers 1.3.0_alpha2 to be a higher version number than 1.3.0. When I tried to install openscap*-1.3.0-1 from Koji , dnf gives messages of the form "Package openscap of higher version already installed, cannot update it." for each openscap subpackage. The version or epoch might need to be changed to allow the updating of openscap-1.3.0-1.

I removed scap-workbench in F28 before upgrading to F29 due to dnf errors I noted in https://bugzilla.redhat.com/show_bug.cgi?id=1626801 specifically Problem 15: cannot install both openscap-1.3.0_alpha2-1.fc29.i686 and openscap-1.2.17-1.fc28.i686 - package scap-workbench-1.2.0-1.fc29.i686 requires libopenscap.so.8, but none of the providers can be installed - package openscap-perl-1.3.0_alpha2-1.fc29.i686 requires libopenscap.so.24, but none of the providers can be installed - problem with installed package scap-workbench-1.2.0-1.fc28.i686 - problem with installed package openscap-perl-1.2.17-1.fc28.i686 - scap-workbench-1.2.0-1.fc28.i686 does not belong to a distupgrade repository - openscap-perl-1.2.17-1.fc28.i686 does not belong to a distupgrade repository ... When I ran sudo dnf install scap-workbench in F29 I got Error: Problem: conflicting requests - nothing provides libopenscap.so.8 needed by scap-workbench-1.2.0-1.fc29.i686

scap-workbench might need to be rebuilt to use libopenscap.so.25 provided by openscap-1.3.0-1.fc29 and added to this update.

60.2.1 has functioned normally.

I got the following post-cleanup scriptlet appstream-data-29-7 errors when running sudo dnf upgrade --refresh

/var/tmp/rpm-tmp.UCQ1Y8: line 1: 28041 Trace/breakpoint trap (core dumped) /usr/bin/appstreamcli refresh --force &> /dev/null /var/tmp/rpm-tmp.MVC6uh: line 1: 28130 Trace/breakpoint trap (core dumped) /usr/bin/appstreamcli refresh &> /dev/null

I can try to get the full traces from the core dumps with debugging info if that would help.

I didn't see the xdg-desktop-portal-kde core dumps or errors I noted in #1627935 after updating to 5.13.5-2 when using simple scan. simple scan scanned a document correctly. Thanks for the update.

Running sudo dnf upgrade --refresh gave me the following errors

Problem 1: package libreswan-3.25-3.fc29.1.i686 requires libunbound.so.2, but none of the providers can be installed - cannot install both unbound-libs-1.8.1-1.fc29.i686 and unbound-libs-1.7.3-9.fc29.i686 - cannot install both unbound-libs-1.7.3-9.fc29.i686 and unbound-libs-1.8.1-1.fc29.i686 - cannot install the best update candidate for package unbound-libs-1.7.3-9.fc29.i686 - cannot install the best update candidate for package libreswan-3.25-3.fc29.1.i686 Problem 2: problem with installed package libreswan-3.25-3.fc29.1.i686 - package libreswan-3.25-3.fc29.1.i686 requires libunbound.so.2, but none of the providers can be installed - cannot install both unbound-libs-1.8.1-1.fc29.i686 and unbound-libs-1.7.3-9.fc29.i686 - cannot install both unbound-libs-1.7.3-9.fc29.i686 and unbound-libs-1.8.1-1.fc29.i686 - package gnutls-dane-3.6.4-2.fc29.i686 requires libunbound.so.8, but none of the providers can be installed - cannot install the best update candidate for package gnutls-dane-3.6.4-1.fc29.i686 ... Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): unbound-libs i686 1.8.1-1.fc29 updates-testing 498 k Skipping packages with broken dependencies: gnutls-dane i686 3.6.4-2.fc29 updates-testing 25 k

libreswan might need to be rebuilt to use libunbound.so.8 provided by unbound-libs-1.8.1-1 and added to this update. libreswan-3.27-1 is available for F27, F28, and F30 but doesn't appear to have been built for F29 on Koji.

Plasma, ksysguard, kinfocentre and others have functioned normally. The pam-kwallet error messages I noted on the lightdm-1.28.0-2 Bodhi page related to #1581495 are still present.

60.2.1-2 from Koji has been running normally.

4.18.12 has run normally.

This version's been running normally. The default tests passed or skipped.

1.28.0-2 has been functioning normally except for the following. I installed pam-kwallet-5.13.4-1 to test #1581495. After rebooting and logging into Plasma from 1.28.0-2, I saw the journal message "pam_kwallet5-kwalletd: Couldn't listen in socket" which was noted in #1581495 followed by "pam_kwallet5(lightdm:session): pam_kwallet5: Couldn't fork to execv kwalletd" which I couldn't find in #1581495. I didn't see the selinux denials involving lightdm mentioned in #1581495. I'm unsure if the change in 1.28.0-2 fixed #1581495.