Comments

1410 Comments

Here's dig @127.0.0.53 output for a name that doesn't work (www.google.com), then one that does (fedoraproject.org):

; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @127.0.0.53 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32195
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.            IN  A

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Mar 23 22:20:19 EDT 2021
;; MSG SIZE  rcvd: 32


; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @127.0.0.53 fedoraproject.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9540
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fedoraproject.org.     IN  A

;; ANSWER SECTION:
fedoraproject.org.  60  IN  A   10.3.163.76
fedoraproject.org.  60  IN  A   10.3.163.75
fedoraproject.org.  60  IN  A   10.3.163.74

;; Query time: 5 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Mar 23 22:20:23 EDT 2021
;; MSG SIZE  rcvd: 83

Here's resolvectl query output for the same two:

?[0;1;31mwww.google.com: resolve call failed: 'www.google.com' does not have any RR of the requested type?[0m

fedoraproject.org: 10.3.163.74                              -- link: ens4
                   10.3.163.75                              -- link: ens4
                   10.3.163.76                              -- link: ens4

-- Information acquired via protocol DNS in 3.3ms.
-- Data is authenticated: no
karma

I revoked this because of the openQA results. It seems to have broken name resolution really badly in openQA. All the failures failed on DNS lookups.

Note, the openQA test failures here are failing because dnf isn't happy with things when upgrading from F33 and winds up installing the -3 builds from stable, not the -6 builds from the update.

If I tweak the test to exclude the -3 builds from the calculation, though, the tests pass. So I think if we actually push this update stable, and the -3 build goes away entirely (as it would), there wouldn't be a problem.

@clnetbox the iptables-legacy subpackage contains /usr/sbin/iptables. It doesn't obsolete iptables, though, so it may not be pulled in on update if nothing explicitly depends on it or something it contains. Perhaps something in libvirt should explicitly depend on /usr/bin/iptables.

@psutter , what do you think? Did you actually intend to pull this much change into F34 post-Beta, even? The update description doesn't really match the amount of change in the package build.

This update bumps the soname of libgnome-bluetooth.so to libgnome-bluetooth.so.14(), but gnome-control-center-40~rc-1.fc34.x86_64 still requires libgnome-bluetooth.so.13(). That's why several openQA tests fail.

In isolation, I'd say gnome-control-center needs rebuilding and adding to this update, but there is also a GNOME 40 megaupdate pending. It might make more sense to put gnome-bluetooth in that, and rebuild gnome-control-center and anything else that needs rebuilding in the same megaupdate. That may require a bump and rebuild of gnome-bluetooth though.

@kalev

sorry about the stable push, I did not mean for this to be pushed but didn't realize it had been auto-submitted before any negative karma came in :(

I'm going to edit the rc4 update to include a build with caching disabled.

I also hit the crash on unlock. I also saw a constantly reoccurring crash in gsd-usb-protection which also seems to have gone away since the gjs downgrade.

I'm gonna blind karma this as we put it in Beta so it needs pushing stable regardless.

openQA test shows GNOME Software fails to run, user journal shows these messages around the time of the failure:

Mar 16 16:40:04 fedora gnome-shell[1453]: Received error from D-Bus search provider org.gnome.Software.desktop during GetResultMetas: Gio.IOErrorEnum: Timeout was reached
Mar 16 16:40:04 fedora gnome-shell[1453]: Wrong number of result metas returned by search provider org.gnome.Software.desktop: expected 3 but got 0
Mar 16 16:40:04 fedora gnome-shell[1453]: Object St.BoxLayout (0x55d9f4521550), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Mar 16 16:40:04 fedora gnome-shell[1453]: == Stack trace for context 0x55d9f2dc8180 ==
Mar 16 16:40:04 fedora gnome-shell[1453]: #0   55d9f33f45d8 i   resource:///org/gnome/shell/ui/search.js:331 (10b533eed600 @ 22)
Mar 16 16:40:04 fedora gnome-shell[1453]: #1   55d9f33f4548 i   resource:///org/gnome/shell/ui/search.js:275 (10b533eed7e0 @ 26)
Mar 16 16:40:04 fedora gnome-shell[1453]: #2   55d9f33f4498 i   resource:///org/gnome/shell/ui/search.js:240 (10b533eed920 @ 242)
Mar 16 16:40:04 fedora gnome-shell[1453]: #3   55d9f33f43d0 i   resource:///org/gnome/shell/ui/remoteSearch.js:278 (10b533ef0240 @ 149)
Mar 16 16:40:04 fedora gnome-shell[1453]: #4   55d9f33f4330 i   resource:///org/gnome/shell/ui/remoteSearch.js:304 (10b533ef0150 @ 23)
Mar 16 16:40:04 fedora gnome-shell[1453]: #5   55d9f33f4278 i   resource:///org/gnome/gjs/modules/core/overrides/Gio.js:117 (228c5d3a4c90 @ 347)
Mar 16 16:40:04 fedora gnome-shell[1453]: clutter_actor_remove_all_children: assertion 'CLUTTER_IS_ACTOR (self)' failed

Well, this was in Beta RC2 and it doesn't seem to have broken anything. There's https://bugzilla.redhat.com/show_bug.cgi?id=1937783 which @lruzicka says goes away with selinux in permissive mode, but I can't reproduce that...

Fix looks good in RC2.

BZ#1930401 No update notifications shown when updates available (F34, Rawhide)
karma

Well, it's in Beta RC2 and nothing seems to have exploded.

Sorry, thought we'd pushed this stable already :(

karma

I tweaked openQA to not work around the bug by disabling oomd.service any more, and the update succeeded, so I think this is good.

BZ#1931034 systemd pid-1 crashed during update of systemd

Note, we pulled this into RC1 and I was waiting to make sure it didn't cause any problems there before submitting it for push. It'll go in the next one.

This looks to be working fine in RC1, and the bug fixes were verified.

BZ#1933520 gdm login stuck in fingerprint authentication loop
BZ#1935331 unable to login on laptop with fingerprint reader

tested and confirmed the fix.

BZ#1937550 Crash reporting does not work in text installer mode due to missing report-cli

The lorax build in this update needs to be replaced with lorax-34.9-5.fc34, but a Bodhi bug is preventing me from doing that at present.

@jpenala OK, thanks for testing. I think we'll have to push this in anyway, but can you please file a bug for it with details, so @stransky can see if we can do anything about it? Thanks!