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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In some cases such as backups or mirroring you may want to pull commits
from one repo to another even if there commits that have incorrect
bindings. Fixing the commits in the source repository to have correct
bindings may not be feasible, so provide a pull option to disable
verification.
For Endless we have several repositories that predate collection IDs and
ref bindings. Later these repositories gained collection IDs to support
the features they provide and ref bindings as the ostree tooling was
upgraded. These repositories contain released commits that were valid to
the clients they were targeting at the time. Correcting the bindings is
not really an option as it would mean invalidating the repository
history.
If this is not done, the test can fail when the temporary directory is
a tmpfs: for example this happens during build-time testing with /var/tmp
on tmpfs or TEST_TMPDIR pointing to a tmpfs, or installed-tests with
gnome-desktop-testing-runner allocating the test directory on a tmpfs.
In particular, many of Debian's official autobuilders now do the entire
build and test procedure in a chroot hosted on a tmpfs, to improve build
performance and prevent fsync overhead.
In this situation, it appears that overwriting summary.sig with a copy
of summary.sig.2 is not sufficient for the web server to tell the
libostree client that it needs to be re-downloaded. I'm not completely
sure why, because tmpfs does appear to have sub-second-resolution
timestamps, but forcing a distinct mtime is certainly enough to
resolve it.
Resolves: https://github.com/ostreedev/ostree/issues/2245
Bug-Debian: https://bugs.debian.org/975418
Signed-off-by: Simon McVittie <smcv@collabora.com>
This tweaks the release GH workflow further so that it only triggers
when the `configure.ac` file (which owns the version) changes.
Plus it properly checkouts the PR branch to avoid wrongly looking
at a synthetic merge commit.
The cache shouldn't be affected by the user passing in some other
summary as it may not be the "official one".
I ran into this in flatpak where the passed summary was correct, but
the re-saving of the cache updated the mtime of the cached file which
led to later http If-Modified-Since calls failing to update.
As detailed in
gitlab.gnome.org/GNOME/glib/-/issues/600#note_877282, volatile
isn't actually needed in these contexts because the atomic operations
already give us strong enough guarantees. In GCC 11, this triggers a
diagnostic due to the volatile qualifier getting dropped anyway.
There is a WIP to do the same in glib:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719
This obsoletes this downstream patch:
https://src.fedoraproject.org/rpms/ostree/c/b8c5a6fb
I got:
src/libostree/ostree-repo.c:5232: Warning: OSTree: ostree_repo_gpg_sign_data: unknown parameter 'out_signature' in documentation comment, should be 'out_signatures'
The timeout timer should always be one-shot, so let's just always
destroy it in the callback. The main context has its own ref on it, so
it won't be freed behind its back.
This *should* fix a leak that was brought up in
https://bugzilla.redhat.com/show_bug.cgi?id=1891761.
Reported-by: Milan Crha <mcrha@redhat.com>
I've made this use functions to make it easier to add support for more
bootloaders. Seeing as there will be a big diff anyway I've also adjusted
the formatting to make it pep8 compliant.
...with the `sysroot.bootloader` configuration option. This can be useful
when converting a system to use `ostree` which doesn't currently have a
bootloader configuration that `ostree` can automatically detect, and is
also useful in combination with the `--sysroot` option when provisioning a
rootfs for systems other than the one you're running `ostree admin deploy`
on.
It's easier to extend and it centralises the config parsing. In other
places we will no longer need to use `g_str_equal` to match these values,
a `switch` statement will be sufficient.
