Comments
martinpitt
stransky: The cockpit fix landed in stable. I asked Adam in https://bugzilla.redhat.com/show_bug.cgi?id=2136876 to re-run the OpenQA tests here.
Ah, found it in the bugzilla. about:config, set widget.use-xdg-desktop-portal.file-picker back to 2. The XDG portals don't work for me for some reason (even though xdg-desktop-portal-wlr is running).
This version breaks the "Open file" dialog. On websites with an upload button, or simply with Menu File → Open File (aka Ctrl+O). This seems to be related to "Build fix, disabled portals on F37+". Is there any workaround?
[1] https://src.fedoraproject.org/rpms/firefox/c/c93bbf6684daad651035b4420743f5d41e8f2288?branch=f37
Hmm, so I tried to drop FEDORA-2022-3527307c7f this morning, but failed. I'm afraid with the (failed) unpush and then repush I only made the process longer, sorry. However, it has been submitted for stable at last, so hopefully it'll be available on the mirrors tomorrow?
Meh, I can't actually delete this (probably because I didn't create it?), or remove the build. Unpushing didn't help either. I'll just ask another colleague today to check it, then it has enough Karma to land today, and then OpenQA tests can re-run in Firefox.
This update has been unpushed.
Integration tests and OpenQA tests also succeeded, in particular the failed OpenQA test that broke the firefox bodhi update.
I started a standard F35 cloud VM, installed the currently released cockpit 275-1. I get the "too old" login page with current Firefox 106. I then updated to 275.1-1.fc35 (with the above "how to install" command), refreshed the browser, and can log in normally again. All the pages work. This was a cherry-picked fix (essentially two characters) which only affected the login page, so I claim with high confidence that this works.
stransky: If you prefer, I'm happy to drop FEDORA-2022-3527307c7f and you can add the fixed cockpit build to this bodhi update?
@adamwill: I suppose we could still do that? I can't edit the firefox bodhi update, but I suppose @stransky could add this cockpit build? I'll also validate that it fixes the bug, then we'll have at least one karma.
Tested with cockpit's unit tests, works fine now. Thanks!
I tested this new version with cockpit's tests. My previously reported regression (dispatcher denials for mv) does not happen any more. Thanks!
Actually, we do have the "installability" tests, and they did run -- so waiving them was premature. However, they failed with "Error: Unknown repo: 'brew-90145609'", not in an useful way.
Hmmm... How is it that we still allow obviously uninstallable packages through bodhi? I don't blame humans -- errors happen. I blame the apparent total lack of automated install tests/gating for such easy-to-detect, but critical failures.
$ sudo dnf install nodejs-devel
Last metadata expiration check: 0:00:05 ago on Wed Aug 3 07:15:53 2022.
Error:
Problem: conflicting requests
- nothing provides nodejs-libs(x86-32) = 1:18.6.0-1.fc37 needed by nodejs-devel-1:18.6.0-1.fc37.1.i686
- nothing provides nodejs(x86-32) = 1:18.6.0-1.fc37 needed by nodejs-devel-1:18.6.0-1.fc37.1.i686
- nothing provides nodejs(x86-64) = 1:18.6.0-1.fc37 needed by nodejs-devel-1:18.6.0-1.fc37.1.x86_64
- nothing provides nodejs-libs(x86-64) = 1:18.6.0-1.fc37 needed by nodejs-devel-1:18.6.0-1.fc37.1.x86_64
@zpytela: No, the tests themselves were okay. Just the many avcs.
@g6avk, can you please file a report at https://github.com/cockpit-project/cockpit/issues ? Let's investigate that. Thanks!
See here: https://github.com/cockpit-project/bots/pull/3627 Lots of tests fail with
audit: type=1400 audit(2114380829.764:191): avc: denied { search } for pid=813 comm="mv" name="contexts" dev="vda5" ino=16829 scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:object_r:default_context_t:s0 tclass=dir permissive=0
audit: type=1400 audit(2114380829.770:192): avc: denied { sys_admin } for pid=813 comm="mv" capability=21 scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tclass=capability permissive=0
audit: type=1400 audit(2114380829.770:193): avc: denied { sys_admin } for pid=813 comm="mv" capability=21 scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tclass=capability permissive=0
NetworkManager did not change in this image, just
- selinux-policy (36.11-1.fc36 -> 36.12-1.fc36)
- kernel-core (5.18.10-200.fc36 -> 5.18.11-200.fc36)
and some others which sound less relevant.
This caused a regression with pylint: https://bugzilla.redhat.com/show_bug.cgi?id=2101222
This breaks python-dbusmock in weird ways, and it seems I'm not alone -- https://bugzilla.redhat.com/show_bug.cgi?id=2021897.
Hmm, this broke gcovr at least with meson. I'll create a smaller reproducer (avoiding the container if possible) and file a bugzilla.