IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We need to do the same `cmp` dance for the generated `.cxx` file
as for the source, because `make` only works on timestamps.
Currently every time one edits the rust code and types `make`
we end up re-building that object, which also forces a re-link
of the `librpmostreeinternals.la` library.
As rpm-ostree is transitioning to a primarily-Rust project,
our dependency on running `make` to generate `.gitignore` is a
problem.
For example, just opening the project in an IDE that runs rust-analyzer,
the latter will start a build and generate files in the `target/` directory,
but because r-a doesn't know to run `make` we won't have `.gitignore` yet.
I think further what we should do is try changing the C/Automake side
to write generated files into `target/` too.
We went through a lot of gyrations on this one. It's only
relevant to server side composes, so having the core parse
the treefile for it directly just makes sense.
The intention here was to distinguish between server composes
and client side layering. But that doesn't work today because
we we call`_new_system()`; probably a result of refactoring.
Doesn't matter too much because we only checked it to
throw an error if we failed to load the policy.
And now add a check for `is_system` instead of checking whether
a treefile is present.
This is prep for converting the origin to a treefile and
using that as our standard format.
Remove the unnecessary builder causing memory leaks like this one:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f60bd2fe3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
#1 0x7f60bca6cbb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
#2 0x7f60bcaa54f2 in g_variant_type_copy (/lib64/libglib-2.0.so.0+0x944f2)
#3 0x7f60bcaa3384 in g_variant_builder_init (/lib64/libglib-2.0.so.0+0x92384)
#4 0x55e5bb3120d3 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
#5 0x7f60bc89cb38 (/lib64/libostree-1.so.1+0x49b38)
#6 0x7f60bc8a5e1a (/lib64/libostree-1.so.1+0x52e1a)
#7 0x7f60bc8a622b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
#8 0x55e5bb307e6e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1551
#9 0x7f60bca92401 (/lib64/libglib-2.0.so.0+0x81401)
#10 0x7f60bc12d3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
#11 0x7f60bc05ab52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Figuring out that we can't `fchmod()` on an `O_PATH` descriptor
took me a while =(
As part of that I discovered the `nix` crate grew a `Dir`
abstraction too. But I think we still probably want to be using
https://docs.rs/cap-std/0.13.7/cap_std/fs/index.html
Even more fallout of the buildroot change to stop deriving from
cosa. The new buildroot doesn't have `pygobject3`.
We could convert this to an installed test but...blah.
Not worth it.
Previously we carefully ported functionality bit by bit here.
Now take the last step and move it all in to Rust.
A reason I didn't do this in one go before is around the
incredibly twisted handling of the `/etc` vs `/usr/etc`.
I think longer term we should aim to basically have all
of our code keep it as `/etc` up until the very end. For
now we just do a rename dance around some of the add/remove
files code.
There are a lot of use cases for this, notably:
- This allows us to display advisories without fetching updateinfo
metadata in the pure OSTree case.
- It allows pipelines to fetch and display this information to
sanity-check builds.
- It makes it much easier to fix the "intermediate CVEs" issue described
in https://github.com/coreos/rpm-ostree/issues/1696#issuecomment-443861107.
This patch just adds the advisory information to the commit metadata.
There's follow-up work to make the client-side of rpm-ostree use this
data.
Also, remove the newly added metadata from the output of `rpm-ostree
status --json` for the same reason we remove the rpmdb. A follow-up
patch will teach `rpm-ostree db list/diff` to output advisories.
Closes: #1696
