- Moved version discovery routine to PKGBUILD
- Set PKGEXT to .pkg.tar to avoid the package being compressed
- Added --needed to pacman arguments when installing the dependencies to
avoid reinstalling packages
Signed-off-by: Filipe Laíns <lains@archlinux.org>
The test is run if a physical TPM is available or if the environment
variable "TPM_SERVER_RUNNING" is set. In the latter case, the user is
expected to start a TPM simulator on their own, like we do in the Arch
Linux CI script here.
Using the library instead of the command line tools provides a more
stable interface. This implementation only fetches PCR 0 for all
available hash algorithms since this is the only PCR that is actually
used in fwupd.
Since https://fwupd.github.io is now a thing, people can be directed there
rather than relying upon locally built documentation by default.
Also this will mean one less dependency to install for people who build
from source.
Lastly this finally means that I can do this set of actions without failure:
```
meson build
ninja -C build
ninja -C build install (PK prompts for password)
rm -rf build
```
Previously gtkdoc stuff was built as root due to the PK prompt and removing
it would lead to stuff like this:
```
rm: cannot remove 'build/docs/libfwupd/html/libfwupd-FwupdClient.html': Permission denied
```
For now this is happening on every master build, but in the future
after it's working reliably it should be restricted to only tagged
builds.
To accomplish this, swap a build from circlei and travisci that
will save docs to publish.
This adds a script which can check for ABI breaks between two Git
revisions:
$ ./contrib/ci/check-abi.sh
The CI is set up to run it automatically between the tip of the branch
being tested and the last release tag.
Based on the work by Mathieu Bridon <bochecha@daitauha.fr>, many thanks.
On Fedora 30 x86_64 I got:
docker run --privileged -t -v `pwd`:/build fwupd-fedora
...
Complete!
+ cp /root/rpmbuild/RPMS/noarch/fwupd-tests-1.2.10-0.1alpha.fc29.noarch.rpm /root/rpmbuild/RPMS/x86_64/fwupd-1.2.10-0.1alpha.fc29.x86_64.rpm /root/rpmbuild/RPMS/x86_64/fwupd-debuginfo-1.2.10-0.1alpha.fc29.x86_64.rpm /root/rpmbuild/RPMS/x86_64/fwupd-debugsource-1.2.10-0.1alpha.fc29.x86_64.rpm /root/rpmbuild/RPMS/x86_64/fwupd-devel-1.2.10-0.1alpha.fc29.x86_64.rpm dist
cp: target 'dist' is not a directory
This also means we now include a flashrom subproject as no distro currently has
a flashrom new enough to build the plugin.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Artur Raglis <artur.raglis@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
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).
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.
Similar to NVME, ATA drives distributed by Dell have special values
that should be used to designate fwupd GUIDs and only run correct
firmware.
When detecting Dell GUIDs remove the standard fwupd GUIDs. "Generic"
firmware targeted to those GUIDs will fail to install.
This speeds up matching for GUIDs by about 90%, taking the query from 3.17ms to
about 0.33ms on my Thinkpad. This is more important for slow ARM hardware,
where strcmp() is more expensive than on x64.
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.
