Comments

23 Comments

@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. :-)

karma

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.

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

karma

Update works and fixes the desired BZ. \o/

BZ#1770296 GNOME on F31: Switching Workspace results in "Ctrl+Alt+Up" key press getting sent to active application

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
BZ#1783311 RFE - build a python-astroid package for EPEL8
BZ#1787911 Missing dependency on `six~=1.12` and `lazy_object_proxy==1.4.*`
BZ#1788084 python3-astroid-2.3.3-2.gitace7b29.fc31 breaks pylint

+1

BZ#1787911 Missing dependency on `six~=1.12` and `lazy_object_proxy==1.4.*`
BZ#1788084 python3-astroid-2.3.3-2.gitace7b29.fc31 breaks pylint

Tested in F29 container, building JSS with CMAC support.

-- Looking for CKM_AES_CMAC
-- Looking for CKM_AES_CMAC - found

+1.

BZ#1757995 nss-3.47 is available
-- Looking for CKM_AES_CMAC
-- Looking for CKM_AES_CMAC - found

and

45/67 Test #52: CMAC_Test .........................................   Passed    0.33 sec

Thanks again @ueno!

BZ#1757995 nss-3.47 is available
-- Looking for CKM_AES_CMAC
-- Looking for CKM_AES_CMAC - found

\o/ Whee it builds JSS with CMAC support. Thanks @ueno!

BZ#1757995 nss-3.47 is available

Tested with linux-firmware upgrade on x1c 7th gen FEDORA-2019-2e80f01a93, looks good.

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).

BZ#1733369 Updating to iwl7260-firmware-25.30.13.0-99.fc30.noarch breaks intel wifi
karma

Cool, thanks for pushing this out! Works for me.

(In the last paragraph, s/Bodhi/OpenQA/g, sorry).

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 $CURRENT_VERSION of $PKG and package $CURRENT_VERSION+1 as $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).

This is a weird error, mostly because the IPA version is less than our minimum. I think we need to wait for FreeIPA to update and then we can retest.