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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Recently we have noticed exceedingly long execution times
for multiple invocations of ostree prune. This is a result of
calculating full reachability on each invocation.
The --commit-only flag provides an alternative strategy. It will only
traverse and delete commit objects to avoid the more expensive
reachability calculations. This allows us to chain multiple --commit-only
commands cheaply, and then follow with a more expensive ostree prune
invocation at the end to clean up orphaned meta and content objects.
This patch makes it so that we mark the .commit file from a static delta
as partial before writing the commit to the staging directory. This
exactly mirrors what we do in meta_fetch_on_complete() when writing the
commit on that codepath, which should lend some credibility to the
correctness of this patch.
I have checked that this fixes an issue Flatpak users have been
encountering (https://github.com/flatpak/flatpak/issues/3479) which
results in error messages like "error: Failed to install
org.freedesktop.Sdk.Extension.texlive: Failed to read commit
c7958d966cfa8b80a42877d1d6124831d7807f93c89461a2a586956aa28d438a: No
such metadata object
8bdaa943b957f3cf14d19301c59c7eec076e57389e0fbb3ef5d30082e47a178f.dirtree"
Here's the sequence of events that lead to the error:
1. An install operation is started that fetches static deltas.
2. The fetch is interrupted for some reason such as network connectivity
dropping.
3. The .commit and .commitmeta files for the commit being pulled are
left in the staging dir, e.g.
"~/.local/share/flatpak/repo/tmp/staging-dfe862b2-13fc-49a2-ac92-5a59cc0d8e18-RURckd"
4. There is no `.commitpartial` file for the commit in
"~/.local/share/flatpak/repo/state/"
5. The next time the user attempts the install, libostree reuses the
existing staging dir, pulls the commit and commitmeta objects into
the repo from the staging dir on the assumption that it's a complete
commit.
6. Flatpak then tries to deploy the commit but fails in
ostree_repo_read_commit() in flatpak_dir_deploy(), leading to the
error message "Failed to read commit ..."
7. This happens again any subsequent time the user attempts the install,
until the incomplete commit is removed with "flatpak repair --user".
I will try to also add a workaround in Flatpak so this is fixed even
when Flatpak links against affected versions of libostree.
I'm working on enhancing the ostree-rs-ext test suite and I hit
a bug where walking a mtree and creating a parent would fail to
load lazy intermediate directories, e.g.:
/ -> usr -> bin
If we walked we'd load `/` but keep `usr` lazy, and then invalidation
would crash because it wasn't loaded.
If we're going to mutate a subdir, we need to have all the parents
loaded.
I know this is missing tests, but...it's a bit tedious to do with
the existing C tests. Eventually soon we'll execute on merging
all 3 repos, and better share test suites.
This is failing for me as of recently but only when I build
without optimization. I don't think we've ever written any
code that returned a large structure by value.
Let's just drop this one.
Since Ubuntu 18.04, libgpgme-dev is the real package and libgpgme11-dev
is a virtual package provided by it. Apparently LGTM running on Ubuntu
20.04 no longer resolves the virtual package:
```
WARNING: Package 'libgpgme11-dev' requested by configuration file was not found
```
That ends up causing the build to fail:
```
configure: error: Need GPGME_PTHREAD version 1.1.8 or later
```
This allows to use Secure Execution with LUKS encrypted boot disk,
key and cryptab are stored only in 'sd-boot' encrypted image.
Signed-off-by: Nikita Dubrovskii <nikita@linux.ibm.com>
If system contains ibm-z-hostkey (fetched during ignition), than
ostree generates 'sd-boot' image and reboots into Secure Execution
Signed-off-by: Nikita Dubrovskii <nikita@linux.ibm.com>
I think I'm hitting issues due to this while using the Rust bindings:
https://github.com/coreos/rpm-ostree/pull/3406#issuecomment-1033084956
The bindings for those APIs use `from_glib_full` which says:
> Because ownership can only be transferred if something is already
> referenced, this is unsuitable for floating references.
The commit metadata `version` key is well established but getting it for
a remote commit is cumbersome since the commit object needs to be
fetched and loaded. Including it in the summary additional metadata
allows a much more convenient view of what each of the remote refs
represents.
`dnf` is present in all the platforms we care about now, and the CentOS
bit is out of date. We can re-add it if we add e.g. C[89]S support with
the updated list of packages.
Motivated by noticing that the `yum` symlink isn't always present.
This aligns all the assertion in the module. In particular, it gets
rid of all `g_return_val_if_fail` instances which may fail without
properly setting GError to the caller.
When we clean up from an error, for example copy_file_range() failing
while we generate a static delta (perhaps caused by
https://gitlab.gnome.org/GNOME/libglnx/-/issues/3 or by a
genuine write error), we might free a variant builder that has a
non-null parent. Previously, this caused infinite recursion and a stack
overflow, repeatedly freeing the same object, but Luca Bruno suggested
that the intention here appears to have been to free the parent object.
Partially resolves https://github.com/ostreedev/ostree/issues/2525
(the other bug reported in that issue needs to be resolved by updating
libglnx to a version where libglnx#3 has been fixed).
Signed-off-by: Simon McVittie <smcv@collabora.com>
`kola` now follows symlinks when archiving an external test's `data/`
dir. So the recursive `data` symlink we have here breaks it.
Let's just move the shared files in its own directory and update the
symlinks.
This tightens up the logic for opening a file while inspecting its
xattrs. The only codepath fetching xattrs from a FD is the one
handling 'bare' mode.
It also rearranges the else-assert flow, mostly for future-proofing.
Support for that file was added previously, but the testing lived in
rpm-ostree only. Let's add it here too.
In the process add a hidden `--lock-finalization` to `ostree admin
deploy` to make testing easier (though it could also be useful to update
managers driving OSTree via the CLI).
Otherwise, any future staged deployment will also automatically be
locked even if not requested. Likely we should fold the locking into the
primary `staged-deployment` serialized GVariant instead.
