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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add the OSTREE_REPO_REMOTE_CHANGE_REPLACE operation to the
OstreeRepoRemoteChange enum. This operation will add a remote or replace
an existing one. It respects the location of the remote configuration
file when replacing and the remotes config dir settings when adding a
new remote.
Closes: #1166
Approved by: cgwalters
We have a `http2=[0|1]` remote config option; let's have the
`--disable-http2` build option define the default for that. This way
it's easy to still enable http2 for testing even if
we have it disabled by default.
Closes: #1798
Approved by: jlebon
Similar as available for u-boot (ce2995e1dc)
and syslinux (c5112c25e4), enable parsing
and writing devicetree filename into grub.cfg.
This is required by arm64-based devices running edk2 instead of u-boot
as the main bootloader (e.g. 96boards HiKey and HiKey960).
Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
Closes: #1790
Approved by: cgwalters
Even with the previous docstring, I didn't understand at first the
relationship between the `ostree-grub-generator` script and
`ostree-bootloader-grub2.c`. Throw some more docs to clarify things a
bit.
Closes: #1791
Approved by: cgwalters
We want a case where we can disable the min-free-space check. Initially,
it felt like to add a OSTREE_REPO_PULL_FLAGS_DISABLE_FREE_SPACE_CHECK but
the problem is prepare_transaction() does not have a OstreeRepoPullFlags
parameter which we can parse right here. On top of it, prepare_transaction()
enforces min-free-space check and won't let the transaction proceed if
the check failed.
This is pretty bad in conjunction with "inherit-transaction" as what
Flatpak uses. There is no way to disable this check unless we remove
it altogether from prepare_transaction.
This issue came out to light when flatpak wasn't able to write metadata
after fetching from remote:
[uajain@localhost ~]$ flatpak remote-info flathub org.kde.Platform//5.9
error: min-free-space-size 500MB would be exceeded
Metadata objects helps in housekeeping and restricting them means
restricting crucial UX (like search, new updates) functionalities
in clients like gnome-software. The error banners originated from
these issues are also abrupt and not much helpful to the user. This
is the specific instance of the issue this patches tries to address.
See https://github.com/flatpak/flatpak/issues/2139 for discussion.
Closes: #1779
Approved by: mwleeds
This didn't quite work out, and is now always failing because Ansible
changed.
For now we have some OK coverage via the rpm-ostree suite, let's just
drop this and revisit later.
Closes: #1783
Approved by: jlebon
The way _ostree_repo_import_object() is written, a hardlink copy is only
attempted if the source repo is trusted, so update the docs for
ostree_repo_import_object_from_with_trust() to reflect that.
Closes: #1777
Approved by: cgwalters
This allows specifying gpgpath as list of
paths that can point to a file or a directory. If a directory path
is given, paths to all regular files in the directory are added
to the remote as gpg ascii keys. If the path is not a directory,
the file is directly added (whether regular file, empty - errors
will be reported later when verifying gpg keys e.g. when pulling).
Adding the gpgkeypath property looks like:
ostree --repo=repo remote add --set=gpgpath="/path/key1.asc,/path/keys.d" R1 https://example.com/some/remote/ostree/repoCloses#773Closes: #1773
Approved by: cgwalters
When falling back to copying objects when importing them into a
bare-user repo, we only actually need to transfer over the
`user.ostreemeta` xattr.
This allows the destination repo to be on a separate filesystem that
might not even support `security.selinux`. (I hit this while importing
over virtio-9p).
Closes: #1771
Approved by: cgwalters
I found this useful while hacking on rpm-ostree but I think it might be
useful enough to upstream. This stat is really helpful for validating
that a pipeline is hitting the devino cache sweet spot.
Closes: #1772
Approved by: cgwalters
It might be "local", but e.g. we may be crossing filesystems. So there
are valid use cases for only wanting to pull the commit metadata with
`pull-local`.
Closes: #1769
Approved by: cgwalters
This is the alias version of #1749. I.e. we want to make sure that one
can't even create an alias which would end up dangling.
See also: https://pagure.io/releng/issue/7891Closes: #1768
Approved by: sinnykumari
if a file ".wh..wh..opq" is present in a directory, delete anything
from lower layers that is already in that directory.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #1486
Approved by: cgwalters
I personally am very opposed to the entire idea of `make distcheck`;
I think source code should canonically be *git* and not tarballs.
See e.g. https://github.com/cgwalters/git-evtag for some
rationale.
But anyways we are uploading classic tarballs since today that
what Debian/Fedora/etc consume sadly, so we need to test it.
We explicitly skip `make distcheck` since we don't want to rerun
the test suite.
Closes: #1766
Approved by: jlebon
Wrap the `Version` key in the YAML-compatible output of
`ostree --version` with quotes so that it's parsed as a string. The
issues with the previous approach in a nutshell:
```
In [5]: yaml.load("asdf: 2018.10")
Out[5]: {'asdf': 2018.1}
```
It's treating the version number as a floating-point. Now, this is
technically a backwards incompatible change, but given that the previous
approach is inherently broken for our needs, I don't see a way around
breaking it now.
Closes: #1761
Approved by: cgwalters
This renames a config key to make its semantics more obvious. Despite
what the commit message says, it only applies when a set of repo finders
is not specified (either on the command line or in a library API call).
This also renames the corresponding ostree_repo_get function. We can do
this since it hasn't been released yet.
Closes: #1763
Approved by: pwithnall
Rather than manually starting the `ostree-finalize-staged.service` unit,
we can leverage systemd's path units for this. It fits quite nicely too,
given that we already have a path we drop iif we have a staged
deployment.
To give some time for the preset to make it to systems, we don't yet
drop the explicit call to `systemctl start`. Though we do make it
conditional based on a DEBUG env var so that we can actually test it in
CI for now. Once we're sure this has propagated, we can drop the
`systemctl start` path and the env var together.
Closes: #1740
Approved by: cgwalters
This commit disables searching on the local network for refs, unless
explicitly requested by the user either by changing the value of the
"core.repo-finders" config option, or by passing an OstreeRepoFinderAvahi to
ostree_repo_find_remotes_async() / ostree_repo_finder_resolve_async(),
or by specifying "lan" in the --finders option of the find-remotes
command.
The primary reason for this is that ostree_repo_find_remotes_async()
takes about 40% longer to complete with the LAN finder enabled, and that
API is used widely (e.g. in every flatpak operation). It's also probable
that some users don't want ostree doing potentially unexpected traffic
on the local network, even though everything pulled from a peer is GPG
verified.
Flathub will soon deploy collection IDs to everyone[1] so these code
paths will soon see a lot more use and that's why this change is being
made now.
Endless is the only potential user of the LAN updates feature, and we
can revert this patch on our fork of ostree. For it to be used outside
Endless OS we will need to upstream eos-updater-avahi and
eos-update-server into ostree.
[1] https://github.com/flathub/flathub/issues/676Closes: #1758
Approved by: cgwalters
Currently libostree essentially has two modes when it's pulling refs:
the "legacy" code paths pull only from the Internet, and the code paths
that are aware of collection IDs try to pull from the Internet, the
local network, and mounted filesystems (such as USB drives). The problem
is that while we eventually want to migrate everyone to using collection
IDs, we don't want to force checking LAN and USB sources if the user
just wants to pull from the Internet, since the LAN/USB code paths can
have privacy[1], security[2], and performance[3] implications.
So this commit implements a new repo config option called "repo-finders"
which can be configured to, for example, "config;lan;mount;" to check
all three sources or "config;mount;" to disable searching the LAN. The
set of values mirror those used for the --finders option of the
find-remotes command. This configuration affects pulls in three places:
1. the ostree_repo_find_remotes_async() API, regardless of whether or
not the user of the API provided a list of OstreeRepoFinders
2. the ostree_repo_finder_resolve_async() /
ostree_repo_finder_resolve_all_async() API
3. the find-remotes command
This feature is especially important right now since we soon want to
have Flathub publish a metadata key which will have Flatpak clients
update the remote config to add a collection ID.[4]
This effectively fixes https://github.com/flatpak/flatpak/issues/1863
but I'll patch Flatpak too, so it doesn't pass finders to libostree only
to then have them be removed.
[1] https://github.com/flatpak/flatpak/issues/1863#issuecomment-404128824
[2] https://github.com/ostreedev/ostree/issues/1527
[3] Based on how long the "ostree find-remotes" command takes to
complete, having the LAN finder enabled slows down that step of the
pull process by about 40%. See also
https://github.com/flatpak/flatpak/issues/1862
[4] https://github.com/flathub/flathub/issues/676Closes: #1758
Approved by: cgwalters
Previously, we were preparing the root very late in the boot process;
right before we switch root. The issue with that is that most services
in the initrd that run `After=initrd-root-fs.target` expect that
`/sysroot` already points to the rootfs we'll be pivoting to. Running
this late violates that assumption.
This patch fixes this by making `ostree-prepare-root.service` instead
run right after `sysroot.mount` (the physical sysroot mounted by
systemd) but still before `initrd-root-fs.target` (which is the target
signalling that `/sysroot` is now valid and ready).
This should make it easier to integrate OSTree with other initrd
services such as Ignition.
Related: https://github.com/dustymabe/ignition-dracut/issues/20Closes: #1759
Approved by: cgwalters
For the same reasons as #1697. This is especially important in services
that are likely to be used as an `After/Before=` target in other units.
`ostree-prepare-root.service` is one such service.
Closes: #1759
Approved by: cgwalters
See https://github.com/projectatomic/rpm-ostree/issues/1568
Basically for people on e.g. rotational media, the default 90
second timeout can be too small.
We're in a tough situation here, because delaying shutdown
can be problematic too if the user is trying to shut down their
laptop to put in a backpack, etc.
There's potential optimizations here to make; I think we
could pre-copy the kernel/initramfs for example.
I suspect for some people the grub2 os-prober is a factor here too,
if that tries to e.g. inspect attached USB rotational hard drives.
But hopefully we'll get rid of that soon.
Closes: #1755
Approved by: jlebon
