A handful of interface names got updated but the XML and implementations got
out of sync. This fixes that, as well as adding some missing comments and
fixing formatting in the XML.
Instead of using steamos-factory-reset-config which resets both
the OS and the user home partitions use steamos-reset-tool which
has arguments for each or resetting both.
Since new rustc warns that ! will not decay into () anymore, we need
to help the compiler know what types it will be getting from method!
macro in 2 places where we call it from set_wifi_debug_mode.
https://doc.rust-lang.org/edition-guide/rust-2024/never-type-fallback.html
has information about the new warning.
Here's the warning we hit without this change:
warning: this function depends on never type fallback being `()`
--> src/manager/user.rs:189:5
|
189 | / async fn set_wifi_debug_mode(
190 | | &self,
191 | | mode: u32,
192 | | buffer_size: u32,
193 | | #[zbus(signal_context)] ctx: SignalContext<'_>,
194 | | ) -> fdo::Result<()> {
| |________________________^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748>
= help: specify the types explicitly
note: in edition 2024, the requirement `!: zbus::zvariant::Type` will fail
--> src/manager/user.rs:40:14
|
40 | .call($method, &($($args,)*))
| ^^^^
...
195 | method!(self, "SetWifiDebugMode", mode, buffer_size)?;
| ---------------------------------------------------- in this macro invocation
= note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default
= note: this warning originates in the macro `method` (in Nightly builds, run with -Z macro-backtrace for more info)
Previously there was a half-baked parser that looked for a fixed value in a
fixed place, but this was not robust. This approach is properly robust, in case
various different files set or override it.
It is currently unused and unknown if it will be used. We can add it back later
if we need to, but cannot remove it after stabilizing the API, so let's just
remove it for now
