Commit Graph

18 Commits

Author SHA1 Message Date
8ebb9cd592 build: Do away with older and newer deps
We copy the 'newer' variant to the canonical locations.
No need to implement manual branching, we have git since decades.

Part-of: <https://gitlab.gnome.org/World/Phosh/squeekboard/-/merge_requests/620>
2024-03-10 15:44:28 +00:00
7c17f64517 CI: target bookworm for "future" job
Bookworm will be the basis for the next PureOS.
Plus, there was some persistent network error when running sid jobs.
2022-09-02 10:20:30 +00:00
d19050e06d build: Replace missing crates.io dependency with Purism-hosted one 2022-04-04 17:48:54 +00:00
Tor
417fe35e91 Make compatible with latest cargo deps 2022-01-30 17:47:57 +00:00
dfee95430d Merge branch 'release' into 'master'
Reproducible build

See merge request Librem5/squeekboard!413
2020-12-03 17:18:50 +00:00
696d77293e d/rules: export RUSTFLAGS only on architecture that needs it
Altered from original to take reproducibility into account. Not tested on mips64el.
2020-12-03 14:34:38 +00:00
39a3c40d67 debian: Build reproducibly 2020-11-29 10:42:24 +00:00
540c4d9c05 d/rules: export RUSTFLAGS only on architecture that needs it 2020-11-23 14:10:09 +00:00
42483234e3 d/rules: fix an FTBFS on mips64el with GOT > 64kb 2020-11-23 14:09:37 +00:00
0299527700 debian: Add amber to legacy distro list 2020-06-25 11:29:47 +00:00
ecfc45c2de build: Make compatible with Debian Bullseye
This commit is a bit bigger than it could have: Meson changes could have gone in separately from CI and Debian.

This commit looks more complicated than it should reasonably be. Alas, Cargo is a piece of work, and it doesn't let honest people just choose different versions of dependencies, leading to a cascade of misery. Several things were tried to curb the disaster:

- Cargo [feature] supports choosing dependencies, but doesn't support specifying dependency versions
- Cargo has a cfg() syntax in sections for choosing dependencies by build options, but it explicitly doesn't support selecting on features…
- Cargo allows choosing different dependencies based on features, so perhaps dependencies with different versions could live in stub crates pulled in as needed? Nope! If a dependency doesn't exist in the repo (and that's the point here), Cargo throws up its hands.

This means Cargo.toml needs to be generated based on the build type. More misery:

- we lose the simplicity of just doing `cargo.sh` for simple housekeeping like deps updates. HACKING.md was updated to reflect that. Perhaps that's inevitable - build options need to be like this.
- Some flaky adjustments needed in `cargo.sh` because of an additional argument that can be mistaken for an argument to the exec in `cargo run`.
- Specifying a custom `Cargo.toml` means Cargo can no longer find any tests, examples, benchmarks, or binaries, because it searches relative to the directory of `Cargo.toml`, which is now the build dir. Extra care needed to not forget about them now.

As soon as Cargo allows anything better for managing deps versions, the above should be undone in its favor.

Good side is that a couple bugs went away:

- build flags not always making it to Cargo
- arm64 builds were optional while they shouldn't
- test layouts in unit tests are loaded from an explicit directory now

The Bullseye versions of dependencies are canonical now, Buster considered legacy.
2020-06-24 15:51:21 +00:00
e285ecce93 d/rules: Only remove Cargo.lock if it exists
This allows to invoke the build target twice in a row
2020-06-02 10:10:43 +02:00
4fee2fad01 debian: Fix build-arch
Some builds call the `build-arch` target instead of `build`. That causes the old `Cargo.lock` to be used.
2019-09-27 16:58:27 +00:00
a3e421db3d build: Fix Debian Cargo.toml mismatch
Debian uses a separate registry for the packages it distributes. Checksums for some Debian packages don't match anything that's available on crates.io, which is the default source of dependencies. *linked-hash-map* in particular doesn't provide any hash.

As a result, Debian's `Cargo.lock` and crates.io's `Cargo.lock` are not matching, and building is only possible with one or the other, depending on what's checked in.

As a separate issue, Debian packages are usually not checked in in multiple versions, so checking in Debian's `Cargo.lock` would result in the package not building whenever a bugfix is distributed (due to checksum changes).

This change removes the crates.io `Cargo.lock` so that a new one will be created whenever a .deb is built, solving the above. What keeps falsely passing builds from happening is `Cargo.toml` specifying no interface changes, as well as Build-Depends, which seem enough for any other Debian package.
2019-09-20 09:52:36 +00:00
7d0070a155 debian: Use CARGO_HOME more like librsvg does 2019-09-20 09:37:46 +00:00
6072e5768a build: Fix cargo behaviour
Cargo caused .deb builds to crash by storing its data in $HOME.

https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules says TMP_DIR may be used freely, so that's where Cargo will keep its stuff now.
2019-09-12 11:26:03 +00:00
a7c6597246 Specify the build system when building a package 2019-07-04 00:18:42 +02:00
fc338f5723 Add Debian packaging files 2019-06-29 10:10:15 +00:00