@kparal the very first question is "Karma: is the update generally functional" -- I replied as much, as it is not functional and is broken.
When I first posted, there were nearly 50% failed OpenQA tests. This is not a sign of a stable update that should be pushed out to users; negative karma is the right answer in either case, if nothing else, so the maintainer is aware. The failing OpenQA appear to have been fixed since.
In general, I agree if it was a random library with fewer users and infrequent releases. But this is a critpath core system package that has seen four updates (just to F34 alone!) in three weeks, causing regressions for users. And I do understand, mistakes happen as a packager. I've made them myself. But perhaps we should take the users (myself included) up on their offer of debugging, and make a single, solid update rather than continuing to push half-broken updates every couple of weeks. :-)
Additionally... How do I, as someone who has installed this advisory and tested it, know whether it isn't broken in some other way, obscured by the symptoms of the above BZ? Just curious. :-) Should users who aren't happy with the current version not test future advisories unless it and all intermediate versions fully work for them?
My 2c., but there is value in the "Is this update generally functional?" question independent of the test cases and independent of current/previous version. Not everyone will have updated from the same immediate version prior, especially at this pace of updates. At that point, it would become a value call to the maintainer as to whether or not to push, and if as a maintainer, you wish to ignore the negative karma, that is fine. But telling users not to use this avenue of feedback, IMO, is wrong.
Perhaps devel@ would be a better place for this discussion. :-)
This update is still broken (regressed in 54).
https://bugzilla.redhat.com/show_bug.cgi?id=1965585 is still broken by 55; see also https://bugzilla.redhat.com/show_bug.cgi?id=1968699#c2 for further symptoms.
Dowgrading to dracut 53 is the only working solution at this time.
@robbiethek -- this isn't a support forum. This update has already been released. The backtrace looks different than the linked BZ. See the linked BZ for more details.
Please file a new BZ, but note that this version has been superseded by v10.10.x.
Appears to do useful things. Didn't test smb shares though.
[root@rawhide-freeipa-bodhi ~]# ipa-server-install <snip> [root@rawhide-freeipa-bodhi ~]# klist -A [root@rawhide-freeipa-bodhi ~]# kinit admin@EXAMPLE.COM Password for admin@EXAMPLE.COM: [root@rawhide-freeipa-bodhi ~]# klist -A Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 01/29/2020 14:01:40 01/30/2020 14:01:37 krbtgt/EXAMPLE.COM@EXAMPLE.COM [root@rawhide-freeipa-bodhi ~]# rpm -qa | grep -i '\(freeipa\|krb5\|samba\)' krb5-libs-1.18-0.beta1.1.fc32.x86_64 freeipa-server-4.8.4-4.fc32.x86_64 samba-client-libs-4.12.0-0.1.rc1.fc32.x86_64 freeipa-client-4.8.4-4.fc32.x86_64 samba-common-4.12.0-0.1.rc1.fc32.noarch freeipa-client-common-4.8.4-4.fc32.noarch krb5-workstation-1.18-0.beta1.1.fc32.x86_64 sssd-krb5-common-2.2.2-5.fc32.x86_64 sssd-krb5-2.2.2-5.fc32.x86_64 freeipa-server-common-4.8.4-4.fc32.noarch krb5-pkinit-1.18-0.beta1.1.fc32.x86_64 samba-common-libs-4.12.0-0.1.rc1.fc32.x86_64 freeipa-common-4.8.4-4.fc32.noarch krb5-server-1.18-0.beta1.1.fc32.x86_64
Tested on both an x1c 4th gen (unaffected by attached BZ) and an x1c 7th gen (affected by BZ, workaround effective), works for us (in conjunction with kernel upgrade).
Sure, but I think calling this a "weird error" is acceptable as you just pointed out: we're doing a bad thing, and the error we see isn't that we're doing a bad thing, its that something else, later, way down the line, is broken.
In OpenQA, after the bodhi update installation stage, I'd expect to verify at least that the packages in this bodhi update were installed at the versions in the update. e.g.,
rpm -qa shows them as being installed at the versions here.
Put another way, if I take
$PKG and package
$CURRENT_VERSION with a new line
Conflicts: $something_else < k in the spec file, and
$something_else >= k hasn't been released and so we get
$CURRENT_VERSION installed in Bodhi (instead of
$CURRENT_VERSION+1), I'd expect Bodhi to fail with a package version error. I would not expect it to pass (assuming that
$PKG @ $CURRENT_VERSION passes Bodhi previously and will pass again).