keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
be54e81a7a
rpm-ostree/rust/Cargo.toml

53 lines
1.3 KiB
TOML
Raw Normal View History

Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
[package]
build-sys: Make Rust library naming/entrypoint more generic Prep for adding more functionality beyond treefile bits. Closes: #1444 Approved by: jlebon
2018-07-04 21:50:40 +03:00
name = "rpmostree-rust"
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
version = "0.1.0"
status: Detect if staging failed in previous boot Sample output: ``` $ rpm-ostree status State: idle Warning: failed to finalize previous deployment check `journalctl -b -1 -u ostree-finalize-staged.service` AutomaticUpdates: disabled ... ``` (Though open to tweaking it). I also played with directly invoking `journalctl` for the user, but that can get really spammy with e.g. `os-prober` output and such. I wrote this in Rust using journal API wrappers because I also plan to implement the `history` command in Rust and will also enhance that new `journal` module there for that. Requires: https://github.com/ostreedev/ostree/pull/1750 Requires: https://github.com/jmesmon/rust-systemd/pull/54 (Though I've pointed the manifest at my branch for now for CI). Closes: #1567 Closes: #1601 Approved by: cgwalters
2018-10-05 19:57:00 +03:00
authors = ["Colin Walters <walters@verbum.org>", "Jonathan Lebon <jonathan@jlebon.com>"]
rust: Update to 2018 edition This mostly involves adjusting our path uses to be anchored, e.g. at `self::` or `crate::`. I took the opportunity to also tweak `use` ordering so that we consistently list modules in external crates first before our own. Closes: #1812 Approved by: lucab
2019-04-14 21:54:32 +03:00
edition = "2018"
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
[dependencies]
rust: Start porting from failure to anyhow The failure crate isn't actively developed anymore. The main benefit of `anyhow` is it uses the standard error type. More info: https://docs.rs/crate/anyhow/1.0.28 Start the porting process. Note that the `envsubst` crate has a public dependency on `failure`, so we need to start mapping its errors.
2020-03-31 18:30:31 +03:00
anyhow = "1.0"
build(deps): bump serde from 1.0.115 to 1.0.116 in /rust Bumps [serde](https://github.com/serde-rs/serde) from 1.0.115 to 1.0.116. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.115...v1.0.116) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-14 10:16:40 +03:00
serde = "1.0.116"
build(deps): bump serde_derive from 1.0.115 to 1.0.116 in /rust Bumps [serde_derive](https://github.com/serde-rs/serde) from 1.0.115 to 1.0.116. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.115...v1.0.116) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-16 02:54:42 +03:00
serde_derive = "1.0.116"
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
serde_json = "1.0"
rust: Bump dependencies This leaves only indicatif outdated (see link in diff). Closes: #1720 Approved by: cgwalters
2018-12-19 23:33:17 +03:00
serde_yaml = "0.8"
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
libc = "0.2"
build(deps): bump nix from 0.17.0 to 0.18.0 in /rust Bumps [nix](https://github.com/nix-rust/nix) from 0.17.0 to 0.18.0. - [Release notes](https://github.com/nix-rust/nix/releases) - [Changelog](https://github.com/nix-rust/nix/blob/master/CHANGELOG.md) - [Commits](https://github.com/nix-rust/nix/compare/v0.17.0...v0.18.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-07-27 18:29:05 +03:00
nix = "0.18.0"
build(deps): bump glib-sys from 0.10.0 to 0.10.1 in /rust Bumps [glib-sys](https://github.com/gtk-rs/sys) from 0.10.0 to 0.10.1. - [Release notes](https://github.com/gtk-rs/sys/releases) - [Commits](https://github.com/gtk-rs/sys/compare/glib-sys-0.10.0...glib-sys-0.10.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-21 10:22:04 +03:00
glib-sys = "0.10.1"
Use ostree-rs, and oxidize more treefile checksumming The main goal here is simply to start the ball rolling in having rpm-ostree use the ostree-rs crate, so we can use it for other code in the future. We also bump the glib crate to a new major, but no code changes were required for that. I spent a bit of time looking through our C code for an example to oxidize, but almost all of our C code using libostree also has calls back into other nontrivial rpm-ostree C code. To make a lot more oxidation progress I think we need to invent an internal `librpmostree-sys` crate so we can have Rust -> C calls. I found this bit of treefile code computing the checksum that we can oxidize - and as soon as we have more libdnf bindings we can move all of the checksumming into Rust too.
2020-08-24 16:01:39 +03:00
glib = "0.10"
gio-sys = "0.10.0"
gio = "0.9"
ostree = { version = "0.9.0", features = ["v2020_4"] }
ostree-sys = "0.7.0"
rust: Rework treefile to be an object In a later patch I'm going to add more API; basically rather than doing the JSON parsing from C, we can add APIs to directly access the treefile object. This also demonstrates how we can do more extensive APIs, in particular implement an "object" in Rust. The ownership across the FFI boundary becomes nicer here too, we don't need to do a dance with the fd. For writing this I found http://jakegoulding.com/rust-ffi-omnibus/objects/ quite useful, as well as https://github.com/rust-lang/regex/blob/master/regex-capi/src/rure.rs Closes: #1474 Approved by: jlebon
2018-07-28 00:36:34 +03:00
tempfile = "3.0.3"
build(deps): bump clap from 2.32.0 to 2.33.0 in /rust Bumps [clap](https://github.com/clap-rs/clap) from 2.32.0 to 2.33.0. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](https://github.com/clap-rs/clap/commits) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-29 00:46:36 +03:00
clap = "~2.33"
build(deps): bump structopt from 0.2.18 to 0.3.8 in /rust Bumps [structopt](https://github.com/TeXitoi/structopt) from 0.2.18 to 0.3.8. - [Release notes](https://github.com/TeXitoi/structopt/releases) - [Changelog](https://github.com/TeXitoi/structopt/blob/master/CHANGELOG.md) - [Commits](https://github.com/TeXitoi/structopt/compare/v0.2.18...v0.3.8) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-01-29 10:35:32 +03:00
structopt = "0.3"
build(deps): bump openat from 0.1.18 to 0.1.19 in /rust Bumps [openat](https://github.com/tailhook/openat) from 0.1.18 to 0.1.19. - [Release notes](https://github.com/tailhook/openat/releases) - [Commits](https://github.com/tailhook/openat/compare/v0.1.18...v0.1.19) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 21:32:40 +03:00
openat = "0.1.19"
build(deps): bump openat-ext from 0.1.4 to 0.1.5 in /rust Bumps [openat-ext](https://github.com/cgwalters/openat-ext) from 0.1.4 to 0.1.5. - [Release notes](https://github.com/cgwalters/openat-ext/releases) - [Commits](https://github.com/cgwalters/openat-ext/commits/v0.1.5) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-28 10:21:33 +03:00
openat-ext = "0.1.5"
build(deps): bump curl from 0.4.31 to 0.4.33 in /rust Bumps [curl](https://github.com/alexcrichton/curl-rust) from 0.4.31 to 0.4.33. - [Release notes](https://github.com/alexcrichton/curl-rust/releases) - [Commits](https://github.com/alexcrichton/curl-rust/compare/curl-sys-0.4.31...curl-sys-0.4.33) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-08-24 10:11:51 +03:00
curl = "0.4.33"
build(deps): bump rayon from 1.3.1 to 1.4.0 in /rust Bumps [rayon](https://github.com/rayon-rs/rayon) from 1.3.1 to 1.4.0. - [Release notes](https://github.com/rayon-rs/rayon/releases) - [Changelog](https://github.com/rayon-rs/rayon/blob/master/RELEASES.md) - [Commits](https://github.com/rayon-rs/rayon/compare/v1.3.1...rayon-core-v1.4.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-08 20:04:48 +03:00
rayon = "1.4"
rust/treefile: Use the c_utf8 crate The advantage of this over CStr is that Rust knows it's UTF-8 too. I also tweaked our path code to use String, and only view it as a `Path`. This avoids having to `unwrap()` later back to a `str`. Closes: #1588 Approved by: jlebon
2018-09-27 16:31:50 +03:00
c_utf8 = "0.1.0"
Add testutils generate-synthetic-upgrade We want to test upgrades that actually change files as a general rule; in some cases we want to test "large" upgrades to validate performance. This code generates a "synthetic" upgrade that adds an ELF note to a percentage of ELF files (randomly selected). By doing it this way we are only actually testing one version of the code. Migrated from https://github.com/coreos/coreos-assembler/pull/1635/ using the Rust code from https://github.com/ostreedev/ostree/pull/2127
2020-08-17 21:12:29 +03:00
rand = "0.7.3"
build(deps): bump systemd from 0.5.0 to 0.6.0 in /rust Bumps [systemd](https://github.com/jmesmon/rust-systemd) from 0.5.0 to 0.6.0. - [Release notes](https://github.com/jmesmon/rust-systemd/releases) - [Commits](https://github.com/jmesmon/rust-systemd/compare/v0.5.0...v0.6.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-14 10:15:56 +03:00
systemd = "0.6.0"
build(deps): bump indicatif from 0.14.0 to 0.15.0 in /rust Bumps [indicatif](https://github.com/mitsuhiko/indicatif) from 0.14.0 to 0.15.0. - [Release notes](https://github.com/mitsuhiko/indicatif/releases) - [Commits](https://github.com/mitsuhiko/indicatif/compare/0.14.0...0.15.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-06-15 12:31:43 +03:00
indicatif = "0.15.0"
Use indicatif for progress This turned out to be messier than I thought, because of two primary factors; the biggest mess here of course is the indirection through the DBus API. The other problem is that previously we passed the string to render each time, and with current indicatif that'd trigger a rerender. Since (usually) don't change the "prefix string", rework the API. Change the "percent/n_items" bits to use autocleanups as well, and to take the prefix string as an initial argument. Since the state expands to multiple components, also change the API to use the `0-initialized` pattern rather than trying to return an aggregate. We also gain a "sub message" which we use to display e.g. package names as we're doing checkouts. Note this ends up at the end, since otherwise everything else jumps around. Closes: #1661 Approved by: rfairley
2018-10-23 17:31:57 +03:00
lazy_static = "1.1.0"
build(deps): bump envsubst from 0.1.1 to 0.2.0 in /rust Bumps [envsubst](https://github.com/lucab/envsubst-rs) from 0.1.1 to 0.2.0. - [Release notes](https://github.com/lucab/envsubst-rs/releases) - [Commits](https://github.com/lucab/envsubst-rs/compare/0.1.1...v0.2.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-04-06 17:53:34 +03:00
envsubst = "0.2.0"
build(deps): bump chrono from 0.4.15 to 0.4.18 in /rust Bumps [chrono](https://github.com/chronotope/chrono) from 0.4.15 to 0.4.18. - [Release notes](https://github.com/chronotope/chrono/releases) - [Changelog](https://github.com/chronotope/chrono/blob/main/CHANGELOG.md) - [Commits](https://github.com/chronotope/chrono/compare/v0.4.15...v0.4.18) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-09-28 10:22:24 +03:00
chrono = { version = "0.4.18", features = ["serde"] }
rust: move libdnf-sys module to its own crate This is just a cleaner arrangement to make the separation more explicit. It also matches what most other wrapper crates do. One advantage of this is that we can tell cbindgen directly that we don't want it to ever export symbols from `libdnf-sys`. Related discussions in: https://github.com/coreos/rpm-ostree/pull/2047
2020-04-07 18:09:17 +03:00
libdnf-sys = { path = "libdnf-sys", version = "0.1.0" }
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
rust: Start porting from failure to anyhow The failure crate isn't actively developed anymore. The main benefit of `anyhow` is it uses the standard error type. More info: https://docs.rs/crate/anyhow/1.0.28 Start the porting process. Note that the `envsubst` crate has a public dependency on `failure`, so we need to start mapping its errors.
2020-03-31 18:30:31 +03:00
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
[lib]
build-sys: Make Rust library naming/entrypoint more generic Prep for adding more functionality beyond treefile bits. Closes: #1444 Approved by: jlebon
2018-07-04 21:50:40 +03:00
name = "rpmostree_rust"
rust: Split out treefile into its own module Further prep for adding more code here. The `lib.rs` then is the collection of glue functions; perhaps in some ideal future it could be generated even. Closes: #1444 Approved by: jlebon
2018-07-04 22:17:51 +03:00
path = "src/lib.rs"
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
crate-type = ["staticlib"]
[profile.release]
build-sys: Turn Rust LTO off by default, add --enable-lto flag For us, this is primarily right now a size issue. See: https://internals.rust-lang.org/t/rust-staticlibs-and-optimizing-for-size/5746 For more information, there are these two issues: https://github.com/rust-lang/cargo/issues/4349 https://bugzilla.mozilla.org/show_bug.cgi?id=1386371 The basic issue here is that a build with LTO off (and a trivial change to add a `println!` takes 14s here, and with it on takes 38s. However, with LTO off the stripped size of `librpmostree_rust.a` is `6M`, with LTO on it's `1.1M`. I named this `--enable-lto` as I'd like to investigate doing this for the C code too. Closes: #1664 Approved by: jlebon
2018-11-05 18:50:24 +03:00
# Unwinding across FFI boundaries is undefined behavior, and anyways, we're
# [crash-only](https://en.wikipedia.org/wiki/Crash-only_software)
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
panic = "abort"
build-sys: Turn Rust LTO off by default, add --enable-lto flag For us, this is primarily right now a size issue. See: https://internals.rust-lang.org/t/rust-staticlibs-and-optimizing-for-size/5746 For more information, there are these two issues: https://github.com/rust-lang/cargo/issues/4349 https://bugzilla.mozilla.org/show_bug.cgi?id=1386371 The basic issue here is that a build with LTO off (and a trivial change to add a `println!` takes 14s here, and with it on takes 38s. However, with LTO off the stripped size of `librpmostree_rust.a` is `6M`, with LTO on it's `1.1M`. I named this `--enable-lto` as I'd like to investigate doing this for the C code too. Closes: #1664 Approved by: jlebon
2018-11-05 18:50:24 +03:00
# We assume we're being delivered via e.g. RPM which supports split debuginfo
rust: Use debug=true for release builds Because our primary delivery vechicle uses RPM which supports separate debuginfo, there's no reason not to build release builds with debuginfo, so that one can use gdb on them just like we do with C. Closes: #1550 Approved by: jlebon
2018-09-10 20:50:24 +03:00
debug = true
build-sys: Turn Rust LTO off by default, add --enable-lto flag For us, this is primarily right now a size issue. See: https://internals.rust-lang.org/t/rust-staticlibs-and-optimizing-for-size/5746 For more information, there are these two issues: https://github.com/rust-lang/cargo/issues/4349 https://bugzilla.mozilla.org/show_bug.cgi?id=1386371 The basic issue here is that a build with LTO off (and a trivial change to add a `println!` takes 14s here, and with it on takes 38s. However, with LTO off the stripped size of `librpmostree_rust.a` is `6M`, with LTO on it's `1.1M`. I named this `--enable-lto` as I'd like to investigate doing this for the C code too. Closes: #1664 Approved by: jlebon
2018-11-05 18:50:24 +03:00
# For true release builds, we do suggest you enable LTO via e.g.
# env RUSTFLAGS='-C lto=true' as part of the outer build. It's just
# off by default because it's quite slow and the default is more oriented
# towards local development.
Reference in New Issue Copy Permalink