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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- Was using the wrong metadata key
- We were missing setting the canonical commit args which assigns
e.g. owner uid 0, which is important for reproducibility
- Use the new --print-hex to make things easier to read
This reverts commit 4e61e6f7d0d6aebd6abcdc455ec53164afe39e8d
and re-instates the fix for ensuring that we download temporary
files into the repository location.
However in order to ensure we don't re-introduce
https://github.com/ostreedev/ostree/issues/2900
we detect the case where we're writing to a FUSE mount
and keep the prior behavior.
I've verified that this works with flatpak.
Note a downside of this is the change needs to be triplicated
across the 3 http backends.
This then again
Closes: https://github.com/ostreedev/ostree/issues/2571
See https://github.com/ostreedev/ostree/issues/1593
Basically this makes it easier for people packaging, as the trivial-httpd
is only for tests, and this way the binary will live with the tests.
Also at this point nothing should depend on `ostree trivial-httpd`.
Since we've split off the "prepare root as init" code
into a separate file, we can now use glib to parse
the config file again, which is a lot less hacky.
This is particularly motivated by composefs, where
we want to do more in the initramfs. Future patches
may also link to parts of libostree.
We should have done this a long time ago. We don't have any test
coverage for the no-initramfs path, and I think it's not long
term supportable as we want to add more features like composefs.
Particularly now that there's good support for embedding an
initramfs in a kernel image, I see little value in a path for
having custom static linking for this prepare root flow.
That said, we will continue to make a best-effort "it compiles"
attempt to support it.
Fork the "pid 1" prepare root code into a new
`ostree-prepare-root-static.c` file, and drop the runtime conditionals.
We can drop the composefs logic from `-static.c` which ends up
keeping that file much smaller.
A further next step here will be to actually fold the
`prepare-root.c` logic into the main `ostree` binary which we
can then just include in the initramfs.
I think this just accidentally was never enabled.
While looking at the code, add a sleep here to be resilient to
filesystems with only second mtime granularity.
I am not sure why this is failing on older Debian systems,
but I'm wildly guessing that something being done in `libtest.sh`
is setting up automake in a way that we need. This is done
in other tests.
Or maybe it's the missing `$CMD_PREFIX`? Let's see...
Commit aa72caffb540114a0e8635ab2990b9c8b0b8f9db
regressed the `ostree-system-generator` on non-ostree systems.
If there's no `ostree=` karg, we need to just exit 0.
Closes: https://github.com/ostreedev/ostree/issues/2909
Fixes: aa72caffb540114a0e8635ab2990b9c8b0b8f9db
Our `install` target doesn't depend on `all` unlike the
rpm-ostree version; not doing so is arguably better, so let's
explicitly build before installing.
This reverts commit f7f6f87c513c9f35bc24f35e909779c19cb49d3a.
This seems to have broken flatpak, so we'll revert and then
investigate.
Closes: https://github.com/ostreedev/ostree/issues/2900
This fixes a regression from the latest composefs submodule update in
1582edd1d4a6b26874d3897de8a5586f979a0715. In composefs commit
7560a4fd388481f479c0b3fc2e6d20c6321d9b74 the struct field was changed
from the generic `expected_digest` with the thought that there may be
other signatures or digests in the future.
aboot-deploy must know where the next root filesystem to boot is to set
up a symlink /ostree/root.a or /ostree/root.b , this location is in the
ostree= part of these passed in options.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Not clear why this was __off_t which is the sole appearance in the code
base, but it breaks musl builds.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
I want to gain testing over the composefs path; but without
yet changing the main Jenkins build. Because we have duplicate/overlapping
CI systems, we can take advantage of this by testing the composefs
flow via Prow.
Sync the Prow build scripts with what's in coreos/rpm-ostree
right now.
Then let's test the composefs flow a bit more e2e there.
