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

96 lines
2.6 KiB
TOML
Raw Normal View History

build-sys: Explicit workspace, move libdnf deps to crate First explicitly state that we're a workspace. AIUI this is actually implicit today via our use of a `path` dependency, but in the future we may have other sub-crates. So let's make it explicit now. Also move the libdnf dependencies directly to that sub-crate.
2021-02-02 02:33:55 +03:00
# Explicitly create a workspace since we have libdnf-sys as a path
# dependency, and in the future we may use other sub-crates.
[workspace]
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"
ci: Drop custom msrv checking The way this tries to replace the system Rust is hacky and actually I realized belatedly I may have broken it recently; basically `installdeps.sh` re-adds the system one, and it's hard to be sure with our current buildsystem we're using the newer one from `$PATH`. What we really want to do here is use a CentOS8 buildroot, which will automatically enforce this in a better way along with solving other problems. But right now we've broken that because libdnf requires a too-new libmodulemd. So let's just rely on the Fedora rust for now.
2021-01-29 20:54:07 +03:00
# See https://rust-lang.github.io/rfcs/2495-min-rust-version.html
# Usually, we try to keep this to no newer than current RHEL8 rust-toolset version.
# You can find the current versions from here:
# https://access.redhat.com/documentation/en-us/red_hat_developer_tools/1/
# However, right now we are bumping to 1.48 so we can use https://cxx.rs
#rust = "1.48"
rust: Link to our C/C++ dependencies and internal library This allows us to fully use cxx-rs with `extern "C++"`. Now we do call back into the C/C++ today, but it only works outside of cargo/Rust's knowledge. Most notably, it means we can't use our C code in `cargo test`. And that's a problem for moving some C/C++ code to Rust, because we want to port the unit tests too. For now, re-declare our dependencies and part of the build system inside the Cargo build. However, this is also an important step towards using Cargo as our *sole* build system. We don't add build dependencies too often, so the short term duplication should be OK. However, a major unfortunate side effect of this is that we now need to serialize the build process; almost all the C/C++ comes first (`librpmostreeinternals.la`) and then the Rust build, then we finally generate the executable with both. The only way out of this really is to move more of the C/C++ build into Cargo, and we probably want to refactor into internal crates.
2021-01-23 18:32:05 +03:00
links = "rpmostreeinternals"
# This currently needs to duplicate the libraries in configure.ac
# until we unify on Cargo as our build system
[package.metadata.system-deps]
jsonglib = { name = "json-glib-1.0", version = "1" }
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
libarchive = "3.0"
libcurl = "7"
rust: Link to our C/C++ dependencies and internal library This allows us to fully use cxx-rs with `extern "C++"`. Now we do call back into the C/C++ today, but it only works outside of cargo/Rust's knowledge. Most notably, it means we can't use our C code in `cargo test`. And that's a problem for moving some C/C++ code to Rust, because we want to port the unit tests too. For now, re-declare our dependencies and part of the build system inside the Cargo build. However, this is also an important step towards using Cargo as our *sole* build system. We don't add build dependencies too often, so the short term duplication should be OK. However, a major unfortunate side effect of this is that we now need to serialize the build process; almost all the C/C++ comes first (`librpmostreeinternals.la`) and then the Rust build, then we finally generate the executable with both. The only way out of this really is to move more of the C/C++ build into Cargo, and we probably want to refactor into internal crates.
2021-01-23 18:32:05 +03:00
polkitgobject = { name = "polkit-gobject-1", version = "0" }
rpm = "4"
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]
build(deps): bump anyhow from 1.0.35 to 1.0.38 Bumps [anyhow](https://github.com/dtolnay/anyhow) from 1.0.35 to 1.0.38. - [Release notes](https://github.com/dtolnay/anyhow/releases) - [Commits](https://github.com/dtolnay/anyhow/compare/1.0.35...1.0.38) Signed-off-by: dependabot[bot] <support@github.com>
2021-01-25 12:18:15 +03:00
anyhow = "1.0.38"
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
c_utf8 = "0.1.0"
chrono = { version = "0.4.19", features = ["serde"] }
rust: Update deps ``` $ cargo upgrade $ cargo update ```
2020-10-19 17:58:26 +03:00
clap = "2.33.3"
curl = "0.4.34"
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
cxx = "1.0.32"
envsubst = "0.2.0"
gio = "0.9.1"
gio-sys = "0.10.1"
glib = "0.10.3"
glib-sys = "0.10.1"
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"
rust: Update deps ``` $ cargo upgrade $ cargo update ```
2020-10-19 17:58:26 +03:00
lazy_static = "1.4.0"
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
libc = "0.2.86"
Move the main Rust infra (i.e. Cargo.toml) to the toplevel I think we should have done this as soon as it was clear that Rust was sticking and not just an optional thing. Reasons to make this change now: - More clear that Rust is going to be the majority of code in the future - `cargo build` and `cargo test` in a fresh git clone Just Work - Paves the way for using `cargo` to build C/C++ instead of Automake
2020-12-08 21:29:05 +03:00
libdnf-sys = { path = "rust/libdnf-sys", version = "0.1.0" }
cargo: add maplit
2021-03-01 18:22:36 +03:00
maplit = "1.0"
build(deps): bump memfd from 0.3.0 to 0.4.0 Bumps [memfd](https://github.com/lucab/memfd-rs) from 0.3.0 to 0.4.0. - [Release notes](https://github.com/lucab/memfd-rs/releases) - [Commits](https://github.com/lucab/memfd-rs/compare/v0.3.0...v0.4.0) Signed-off-by: dependabot[bot] <support@github.com>
2021-02-17 03:31:25 +03:00
memfd = "0.4.0"
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
nix = "0.20.0"
openat = "0.1.19"
openat-ext = "^0.1.12"
countme: Add DNF Count Me support Add support for the DNF Count Me feature [1,2,3] as a standalone rpm-ostree subcommand called weekly via a systemd timer. [1] https://fedoraproject.org/wiki/Changes/DNF_Better_Counting [2] https://dnf.readthedocs.io/en/latest/conf_ref.html?highlight=countme#options-for-both-main-and-repo [3] https://github.com/rpm-software-management/ci-dnf-stack/blob/master/dnf-behave-tests/features/countme.feature
2020-10-13 18:46:00 +03:00
os-release = "0.1.0"
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
ostree = { version = "0.9.1", features = ["v2020_4"] }
ostree-sys = "0.7.1"
paste = "1.0"
phf = { version = "0.8", features = ["macros"] }
rand = "0.8.3"
rayon = "1.5.0"
Add an rpmostree-client sub-crate This is intended to be published to https://crates.io/crates/rpmostree-client Part of https://github.com/coreos/rpm-ostree/issues/2389 This directly imports the code from https://github.com/ostreedev/ostree/blob/5551c54c6e6eba8145b95bd3b28223f1941a9e8d/tests/inst/src/rpmostree.rs Once merged and released I'll try converting the ostree test suite over as well as Zincati. Internally add a testutils helper to validate it works.
2021-02-12 21:47:36 +03:00
rpmostree-client = { path = "rust/rpmostree-client", version = "0.1.0" }
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
rust-ini = "0.16.1"
serde = { version = "1.0.123", features = ["derive"] }
serde_derive = "1.0.118"
serde_json = "1.0.64"
serde_yaml = "0.8.17"
structopt = "0.3.21"
subprocess = "0.2.6"
systemd = "0.8.2"
tempfile = "3.2.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
Rework bindgen/cxx.rs usage and CI build cxx.rs (aka cxxbridge) and cbindgen are both generating source code. Since the last release we've introduced the former, and we need to ensure that the generated cxx.rs source ends up in release tarballs the same way as the cbindgen code. Rationalize and clean up the binding infrastructure. Drop support for the vendored cbindgen which we weren't actually using: Closes: https://github.com/coreos/rpm-ostree/issues/2392 Move the cxx-rs and cbindgen bits into the same place, and update our CoreOS CI build to use a separate `Makefile.bindings` that just generates the code, so our CI still "works like" a main Koji RPM build.
2020-12-31 19:55:19 +03:00
[build-dependencies]
cargo: sort dependencies
2021-03-01 18:21:22 +03:00
anyhow = "1.0"
build(deps): bump cbindgen from 0.16.0 to 0.18.0 Bumps [cbindgen](https://github.com/eqrion/cbindgen) from 0.16.0 to 0.18.0. - [Release notes](https://github.com/eqrion/cbindgen/releases) - [Changelog](https://github.com/eqrion/cbindgen/blob/master/CHANGES) - [Commits](https://github.com/eqrion/cbindgen/compare/v0.16.0...v0.18.0) Signed-off-by: dependabot[bot] <support@github.com>
2021-03-01 10:03:07 +03:00
cbindgen = "0.18.0"
build(deps): bump system-deps from 2.0.3 to 3.0.0 Bumps [system-deps](https://github.com/gdesmott/system-deps) from 2.0.3 to 3.0.0. - [Release notes](https://github.com/gdesmott/system-deps/releases) - [Commits](https://github.com/gdesmott/system-deps/compare/v2.0.3...v3.0.0) Signed-off-by: dependabot[bot] <support@github.com>
2021-02-18 02:21:53 +03:00
system-deps = "3.0"
Rework bindgen/cxx.rs usage and CI build cxx.rs (aka cxxbridge) and cbindgen are both generating source code. Since the last release we've introduced the former, and we need to ensure that the generated cxx.rs source ends up in release tarballs the same way as the cbindgen code. Rationalize and clean up the binding infrastructure. Drop support for the vendored cbindgen which we weren't actually using: Closes: https://github.com/coreos/rpm-ostree/issues/2392 Move the cxx-rs and cbindgen bits into the same place, and update our CoreOS CI build to use a separate `Makefile.bindings` that just generates the code, so our CI still "works like" a main Koji RPM build.
2020-12-31 19:55:19 +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"
Move the main Rust infra (i.e. Cargo.toml) to the toplevel I think we should have done this as soon as it was clear that Rust was sticking and not just an optional thing. Reasons to make this change now: - More clear that Rust is going to be the majority of code in the future - `cargo build` and `cargo test` in a fresh git clone Just Work - Paves the way for using `cargo` to build C/C++ instead of Automake
2020-12-08 21:29:05 +03:00
path = "rust/src/lib.rs"
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
[[bin]]
name = "rpm-ostree"
path = "rust/src/main.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
[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
rust: Enable lto by default This avoids us leaking all of the Rust symbols as public into our shared library. Came up in team chat since one person tried to copy just `/usr/bin/rpm-ostree` from the dev container into a target and got a linker crash; but really we want to avoid all the duplicated symbols entirely. (And we should investigate cross-language LTO because that's the only way to get full savings)
2020-10-28 23:06:26 +03:00
# We need this to avoid leaking symbols, see
# https://internals.rust-lang.org/t/rust-staticlibs-and-optimizing-for-size/5746
lto = true
Default to sqlite rpmdb backend on f34 There won't be any support for writing to the bdb backend in f34, so e.g. pkglayering won't work (and obviously even composes wouldn't work once the buildroot moves to f34). Instead of requiring the whole world to add an `rpmdb` key in their manifests, let's just add a compile flag for it, and tweak the spec file to use this flag on f34.
2020-12-22 01:27:52 +03:00
[features]
sqlite-rpmdb-default = []
Add fedora-integration: Support `override replace https://bodhi/...` This adds support for e.g.: ``` $ rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2020-2908628031 ``` This will find the Koji builds from the listed update, download all the RPMs (that aren't debuginfo) and pass them for overrides in the same way we support `override replace http://somewebserver/foo.rpm` now. We also support directly linking a Koji build: ``` $ rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=1625029 ``` Bodhi has a modern HTTP+JSON API, and the lack of a Koji equivalent drove me to create https://github.com/cgwalters/koji-sane-json-api and we currently depend on an instance set up in the OpenShift CI cluster. I hope it shouldn't take long to deploy this in Fedora Infra, but I don't want to block on it. Also notably this still downloads *all* the other RPMs even ones that aren't installed. Handling that truly correctly would require moving this logic to the daemon and core. All of this functionality is keyed off a `cfg(feature = "fedora-integration")` that is detected by a Rust `build.rs` which parses the build environment's `/etc/os-release` for now.
2020-12-28 17:16:32 +03:00
fedora-integration = []
Add --enable-sanitizers (not on by default yet) This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: https://github.com/rust-lang/rust/issues/39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
2021-02-03 00:54:38 +03:00
# ASAN+UBSAN
sanitizers = []
Default to sqlite rpmdb backend on f34 There won't be any support for writing to the bdb backend in f34, so e.g. pkglayering won't work (and obviously even composes wouldn't work once the buildroot moves to f34). Instead of requiring the whole world to add an `rpmdb` key in their manifests, let's just add a compile flag for it, and tweak the spec file to use this flag on f34.
2020-12-22 01:27:52 +03:00
default = []
Reference in New Issue Copy Permalink