Bug 2173022 - Discover (KDE software app) shows "user agent unset" error on startup with fwupd-1.8.11-1.fc39
Summary: Discover (KDE software app) shows "user agent unset" error on startup with fw...
Keywords:
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-discover
Version: 39
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-23 18:01 UTC by Adam Williamson
Modified: 2023-08-16 08:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
KDE GitLab plasma discover merge_requests 486 0 None opened fwupd: do fwupd_client_connect before setting user agent 2023-02-23 20:07:13 UTC
KDE Software Compilation 466318 0 NOR UNCONFIRMED fwupd backend errors on startup with fwupd 1.8.11: "user agent unset" 2023-02-23 19:21:03 UTC

Description Adam Williamson 2023-02-23 18:01:45 UTC
After fwupd-1.8.11-1.fc39 appeared in Rawhide, KDE's software app, Discover, is showing an error "user agent unset" on startup. This error message comes from fwupd, in libfwupd/fwupd-client.c . It doesn't seem to be new in 1.8.11, but somehow Discover is triggering it where it wasn't before, with no change on the Discover side.

Discover source is at https://invent.kde.org/plasma/discover/ .

I haven't checked yet if the app is usable (perhaps without firmware update working) if you close the dialog (the failure was caught by openQA, which can't improvise like that, I'll have to reproduce it manually to check).

Comment 1 Adam Williamson 2023-02-23 18:04:06 UTC
Discover does set the agent at https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/backends/FwupdBackend/FwupdBackend.cpp#L31 ...

Comment 2 Adam Williamson 2023-02-23 18:09:05 UTC
I notice that 34743ff6f48510839ca3ef5f4ad6fe51ffd3425c adds an additional failure case to `fwupd_client_set_user_agent_for_package`:

+       g_return_if_fail(priv->daemon_version != NULL);

maybe that's the problem here, somehow? Can't see anything else relevant that's changed...

Comment 3 Adam Williamson 2023-02-23 18:35:49 UTC
Digging a bit further, that does seem plausible. gnome-software seems to do `fwupd_client_set_user_agent_for_package` rather later in its overall flow than Discover does, and explicitly does it *after* it "knows" the daemon version:

https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/plugins/fwupd/gs-plugin-fwupd.c#L285-286

	/* we know the runtime daemon version now */
	fwupd_client_set_user_agent_for_package (self->client, PACKAGE_NAME, PACKAGE_VERSION);

whereas in Discover it's the first thing that happens in setup of its FwupdBackend class.

Digging through all the async callback stuff, it looks like the difference boils down to: gnome-software sets client feature flags before doing fwupd_client_set_user_agent_for_package. That's the only substantive thing that actually *happens* before the /* we know the runtime daemon version now */ comment, AFAICS. So presumably, setting client feature flags is enough to get the daemon version set. So...we could make Discover do that too, I guess? But was it intended/known/documented that doing `fwupd_client_set_user_agent_for_package` at the start of client setup worked before but is broken by 1.8.11?

Comment 4 Adam Williamson 2023-02-23 19:22:25 UTC
Assigning to Discover, as on the whole it looks like it'll make sense to fix this there, even though it was the added check in fwupd 1.8.11 that "broke" it. Discover probably should've been making sure the daemon version was available before setting the user agent all along, per the commit message on https://github.com/fwupd/fwupd/commit/34743ff6f48510839ca3ef5f4ad6fe51ffd3425c .

Comment 5 Adam Williamson 2023-02-23 20:45:56 UTC
We should also fix this across all releases because, per hughsie, LVFS will no longer offer updates to clients that don't set the agent string correctly.

Comment 6 Adam Williamson 2023-02-23 22:09:46 UTC
So I've done plasma-discover builds for all releases now. I edited the builds for F36 and F37 into the pending Plasma 5.27.1 updates for those releases. For Rawhide it just went out directly, of course. I'm not sure what to do for F38 because there is no fwupd 1.8.11 build/update for F38 yet; it seems to have been overlooked. Ideally we'd have an update containing both fwupd 1.8.11 and the fixed plasma-discover.

Richard, do you want to create one? Or you can create an fwupd one and I can edit plasma-discover into it, if you don't have the necessary permissions?

Thanks!

Comment 7 Richard Hughes 2023-02-24 14:24:58 UTC
> Richard, do you want to create one?

Yes, I'll do that -- I'm going to do a new fwupd upstream release with the regression fixed too -- maximally fix in all directions! :)

Comment 8 Richard Hughes 2023-02-24 16:17:33 UTC
Okay, maximally fixed. Thanks Adam, team QA ++.

Comment 9 Adam Williamson 2023-02-24 17:14:15 UTC
That's awesome, thanks! It'll be helpful for other distros as Plasma aren't updating releases before 5.27 any more. So if other distros update fwupd now, their older Discover version will magically work properly, which is great. Thanks a lot for doing that.

Comment 10 Adam Williamson 2023-02-24 18:08:24 UTC
oh, and since the fwupd update fixes things so the older Discover should work, we don't really need to co-ordinate the updates either. I'll put the F38 discover update in with the rest of plasma, I guess.

Comment 11 Adam Williamson 2023-02-24 18:09:34 UTC
oh, I see you already included it. well, no harm done :D

Comment 12 Fedora Release Engineering 2023-08-16 08:07:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.


Note You need to log in before you can comment on or make changes to this bug.