mirror of
https://git.proxmox.com/git/fwupd
synced 2025-08-05 12:12:48 +00:00
fc8093626c
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). |
||
|---|---|---|
| .. | ||
| arch.sh | ||
| centos.sh | ||
| check_missing_translations.sh | ||
| debian_s390x.sh | ||
| debian.sh | ||
| dependencies.xml | ||
| Dockerfile-arch.in | ||
| Dockerfile-centos.in | ||
| Dockerfile-debian.in | ||
| Dockerfile-fedora.in | ||
| Dockerfile-flatpak.in | ||
| Dockerfile-snap.in | ||
| Dockerfile-ubuntu.in | ||
| fedora.sh | ||
| flatpak.py | ||
| generate_debian.py | ||
| generate_docker.py | ||
| README.md | ||
| s390x_cross.txt | ||
| snap.sh | ||
| snapcraft-wrapper | ||
| ubuntu.sh | ||
Continuous Integration
Continuous integration for fwupd is provided by Travis CI.
By using Travis CI, builds are exercised across a variety of environments attempting to maximize code coverage. For every commit or pull request 6 builds are performed:
Fedora (x86_64)
- A fully packaged RPM build with all plugins enabled
- Compiled under gcc with AddressSanitizer
- Tests with -Werror enabled
- Tests with the built in local test suite for all plugins.
- All packages are installed
- An installed testing run with the "test" plugin and pulling from LVFS.
- With modem manager disabled
Debian testing (x86_64)
- A fully packaged DEB build with all plugins enabled
- Compiled under gcc
- Tests with -Werror enabled
- Tests with the built in local test suite for all plugins.
- All packages are installed
- An installed testing run with the "test" plugin and pulling from LVFS.
- All packages are removed
Debian testing (i386)
- A fully packaged DEB build with all plugins enabled
- Compiled under gcc
- Tests with -Werror enabled
- Tests with the built in local test suite for all plugins.
- All packages are installed
- An installed testing run with the "test" plugin and pulling from LVFS.
- All packages are removed
Ubuntu devel release (x86_64)
- A fully packaged DEB build with all plugins enabled
- Compiled under clang
- Tests without -Werror enabled
- Tests with the built in local test suite for all plugins.
- All packages are installed
- An installed testing run with the "test" plugin and pulling from LVFS.
- All packages are removed
Debian testing (cross compile s390x)
- Not packaged
- Tests for missing translation files
- No redfish support
- Compiled under gcc
- Tests with -Werror enabled
- Runs local test suite using qemu-user
- Modem manager disabled
Arch Linux (x86_64)
- A fully packaged pkg build with all plugins enabled
- Compiled under gcc
- Tests with -Werror enabled
- Compile with the deprecated USB plugin enabled
- Tests with the built in local test suite for all plugins.
- All packages are installed
Flatpak
- A flatpak bundle with all plugins enabled
- Compiled under gcc with the org.gnome.Sdk/x86_64/3.28 runtime
- Builds without the daemon, so only fwupdtool is available
- No GPG, PKCS-7, GObjectIntrospection, systemd or ConsoleKit support
- No tests
Adding a new target
Dockerfiles are generated dynamically by the python script generate_dockerfile.py.
The python script will recognize the environment variable OS to determine what target to generate a Dockerfile for.
dependencies.xml
Initially the python script will read in dependencies.xml to generate a dependency list for that target. The XML is organized by a top level element representing the dependencies needed for building fwupd.
The child elements represent individual dependencies for all distributions.
- This element has an attribute id that represents the most common package name used by distributions
- This element has an attribute type that reprsents if the package is needed at build time or runtime.
Each dependency then has a mapping to individual distributions (distro).
- This element has an attribute id that represents the distribution.
Each distribution will have package elements and control elements. Package elements represent the name of the package needed for the distribution.
- An optional attribute variant represents one deviation of that distribution. For example building a specific architecture or with a different compiler.
- If the package element is empty the id of the element will be used. Control elements represent specific requirements associated to a dependency. They will contain elements with individual details.
- version elements represent a minimum version to be installed
- inclusive elements represent an inclusive list of architectures to be installed on
- exclusive elements represent an exclusive list of architectures to not be installed on
Dockerfile.in
The Dockerfile.in file will be used as a template to build the container. No hardcoded dependencies should be put in this file. They should be stored in dependencies.xml.