Instead of using RequiresMountsFor=/snap/fwupd/current, which will not
work since /snap/fwupd/current is a symlink [1].
This will work since the mount units generated by snapd all have
Before=snapd.service, so will be stopped after snapd.service during
shutdown.
With After=snapd.service, fwupd-activate.service will then stop before
snapd.service, at a point when all snap mount units are still running.
Fixes the issue where fwupd-activate.service hangs when stopped, causing
a stop job timeout during shutdown.
[1] See https://github.com/systemd/systemd/issues/8907Closes#1654
The systemd shutdown script gets called after /snap/fwupd/* gets
unmounted meaning it can't be used to do the activation.
Explicitly check that the symlink for /snap/fwupd/current is mounted
when calling the script.
If a device reports that qmi-pdc is supported (e.g. DW5821e that
supports both fastboot and qmi-pdc), we'll end up first running the
fastboot installation before doing the qmi-pdc installation procedure.
These changes also make sure that the MM device inhibition is kept for
as long as the whole process is ongoing. Only after the last method is
run, the inhibition will be removed.
In order to handle devices being exposed in the system while the MM
inhibition is in place, e.g. to be able to run qmi-pdc after fastboot,
a simple udev based watcher is included, which will take care of
creating the FuMmDevice that is not associated to any modem currently
exposed by MM, but that shares all the details of the original device.
This new logic assumes that the devices don't change their USB layout
during a firmware upgrade, which is not a very good assumption, but it
works for the case at hand. If this is not the case, we may need to
end up doing some custom AT port probing instead of relying on the
original one reported by MM being still valid (note that we don't rely
on the device name, as that may change if some other device is plugged
in the system while we're doing the update, we rely on the USB
interface number).
The snap build uses xmlb as a subproject. libxmlb actually does
need the uuid-dev dependency.
Resolves this failure:
```
Couldn't use fallback subproject in subprojects/libxmlb for the dependency xmlb
Reason: subprojects/libxmlb/meson.build:107: Native dependency 'uuid' not found
meson.build:158:0: ERROR: Native dependency 'xmlb' not found
```
This also allows us to write mixed-endian structures and adds tests. As part of
this commit we've also changed the API of something that's not yet been in any
tarball release, so no pitchforks please.
The current libxmlb dependency requires this and when run in subproject
mode will cause failures otherwise.
Also bump the snap to use meson 0.47.2 to fix snap build due to this
failure.
The libxmlb library is much faster to query, and does not require the daemon
to parse the XML metadata at startup. It's a zero-copy mmap design that is more
modern and less clunky.
RSS has reduced from 3Mb (peak 3.61Mb) to 1Mb (peak 1.07Mb) and the startup
time has gone from 280ms to 250ms.
Leading to this problem:
Building fwupd-wrappers
Failed to copy '/build/fwupd/parts/fwupd-wrappers/build/snapcraft-stable.yaml': it's a symlink pointing outside the snap.
Fix it to be valid when snapped and try again.
Build failed
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 229, in run
self.build()
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 218, in build
env=env)
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 75, in run_build_command
return self.backend.run(args, env=full_env, **kwargs)
File "/usr/lib/python2.7/dist-packages/lpbuildd/target/lxd.py", line 460, in run
subprocess.check_call(cmd, **kwargs)
File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
raise CalledProcessError(retcode, cmd)
Scanning for processes to kill in build SNAPBUILD-351860
Workaround for https://bugs.launchpad.net/launchpad/+bug/1797366
It was previously a symlink to contrib/snap/snapcraft-stable.yaml
however infrastructure changes in launchpad have caused this to break
automatic snap builds.
In Fedora the only user of libfwupdate is fwupd and the fwupdate command line
tool. It makes sense to absorb the libfwupdate library interface into the
uefi plugin in fwupd. Benefits I can see include:
* fwupd and fwupdate are very similar names; a lot of OEMs are confused
* fwupd already depends on efivar for other things
* We are maintaining an artificial library interface
* The CI and translation hooks are already in place for fwupd
* We don't need to check for features or versions in fwupd, we can just develop
the feature (e.g. BGRT) all in one place.
Since the snap is named fwupd, fwupdtool gets namespaced as
fwupd.fwupdtool so bash completion doesn't work properly.
Add a step to fixup bash completion paths
Per discussion in trying to get classic snap approved, snap security
audience would rather see all interfaces used by fwupd added into
snapd interfaces so proper confinement works.
This will require devmode for now until that has occurred.
Requiring colord to be built before fwupd makes it hard to build packages.
The HID-based flashing protocol is stable and documented, so there's no need
to use an external library for this now.
