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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Move hashing to the Rust side so that we can easily hash over the final
set of inputs after parsing. This means that we now hash over all the
externals, like `add-files` references, any `postprocess-script` script,
and `passwd` and `group` files.
The original motivation for this was that hashing over a reserialized
version of the treefile was not deterministic now that treefiles include
hash tables (i.e. `add-commit-metadata`). So I initially included each
individual treefile as part of the hash.
I realized afterwards that just switching to `BTreeMap` fixes this, so
we can keep hashing only the final flattened reserialized treefile so we
ignore comments and whitespace too. But since I already wrote the patch,
and it fixes a real issue today... here we are.
One notable change though is that we now hash the treefile in non-pretty
mode to increase the chances that the serialized form remains stable.
Ironically, this change is likely to cause a no-op commit once it gets
to pipelines which iterate quickly. All for the greater good though.
Closes: #1865
Approved by: cgwalters
We were hitting the classic "negative test passes for the wrong reason".
It was failing not because it didn't have a parent, but because we
didn't pass `--repo`. Fix this and also explicitly check for the error
message we expect.
Closes: #1865
Approved by: cgwalters
Add support for a new `add-commit-metadata` key in the treefile so that
we can directly specify commit metadata we want to inject from there.
This will be useful in Fedora CoreOS, where we'll have separate
treefiles for each streams, each with stream-specific metadata values
required.
Closes: #1865
Approved by: cgwalters
Move up the setting of the treefile JSON object to right after parsing,
and move down the populating of the metadata hash table to after setting
the treefile JSON object. This is pure code block moves; there's no
functional change otherwise.
Prep for future patch.
Closes: #1865
Approved by: cgwalters
Split out from `rpmostree_composeutil_read_json_metadata_from_file` the
part that actually converts to `GVariant` and inserts into the hash
table.
Closes: #1865
Approved by: cgwalters
Instead of relying on `rpmostree_composeutil_read_json_metadata` to
initialize the metadata hash table, initialize it explicitly in
`context_new()` function and only call the util function if we were
passed a file with `--add-metadata-from-json`.
Accordingly rename the function
`rpmostree_composeutil_read_json_metadata_from_file`.
Closes: #1865
Approved by: cgwalters
Besides allowing ${releasever}, only do the substitution as the final
pass after merging the treefiles for all the keys (currently ${basearch}
and ${releasever}) instead of doing it per parse. This way we have the
expected semantics where one could do:
```
include: "fedora-coreos.yaml"
releasever: "42"
```
and have that releasever used.
Fixes#1809
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1848
Approved by: cgwalters
The same way we abbreviate ReplacedBasePackages when there are matching
EVR diffs, let's do something similar for RemovedBasePackages for
matching EVRs.
Solves #1784
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1852
Approved by: jlebon
Using glib_json to parse the lockfile yields some oddities like
everything being wrapped in a GVariant. Let's leave the parsing to serde
in the Rust side of things. Hopefully that'll make the lockfile easier
to extend in the future.
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1851
Approved by: jlebon
And render it in status, so if the daemon is doing something
we know who started it. I'm doing this specifically because
gnome-software defaults to running `RefreshMd` but it's not
obvious that is happening.
Closes: #1859
Approved by: jlebon
This has been dead code since we merged the pkgcache into the main
repo. I noticed that the daemon is holding open two instances
of the system repo and came across this while trying to figure out
why.
Closes: #1853
Approved by: jlebon
I was reading this code for a different bug and noticed that
the dict wasn't always initialized if we happened to exit early
due to error.
Closes: #1856
Approved by: jlebon
Drop the use of Ansible everywhere. In the few cases where we really
Python, just spawn a container instead.
This is required to be able to hack on Fedora CoreOS.
Closes: #1850
Approved by: jlebon
The use case for `ostree-layers` is to support injecting non-RPM
content in a more flexible way than can be done with `add-files`,
and also without dropping all the way to split composes.
This starts with support on the `compose tree` side but down the
line I'd like to make it more convenient to do *client* side too.
For `ostree-override-layers` this is mainly a development thing
for tools like coreos-assembler. Rather than building an RPM
we just `make install DESTDIR` then commit and add to
`ostree-override-layers`.
Closes: #1830
Approved by: jlebon
One problem with how we use lockfiles right now is that we don't enforce
them for dependencies. That is, if `foo` requires `bar`, but only `foo`
is in the manifest, then while `foo` will be locked, `bar` will never
be checked against the lockfile because it was never explicitly
requested.
Higher-level though, I don't like how indirect the locking here feels.
See some comments about that in:
https://github.com/projectatomic/rpm-ostree/pull/1745#discussion_r288772527https://github.com/projectatomic/rpm-ostree/pull/1745#discussion_r289419017
Essentially, the manifest is an input file of patterns, and all we
really know from the lockfile output is that the set of packages in
there satisfies this input in some way. But:
1. there are multiple ways to satisfy the same input (hence why hints
like `SOLVER_FAVOR` exist)
2. the solution is dependent on how the solver is implemented (i.e.
different libsolv versions might yield different solutions)
3. the solution is dependent on flags fed to the solver (i.e. different
libdnf versions might yield different solutions)
So any attempt at cross-checking between the input file and the lockfile
is going to be very hard. Using a stricter mode as I suggested in #1745
of only allowing pure pkgnames or NEVRAs would help, but it wouldn't
address the dependency issue. (Though I'm still thinking about possibly
doing this anyway.)
The solution I propose here is instead to take the nuclear approach: we
completely exclude from the sack all packages of the same name as
packages in our lockfiles, but which do not match the NEVRA. Therefore,
any possible solution has to also satisfy our lockfile (or error out).
Closes: #1849
Approved by: cgwalters
Fixes#1670
This patch introduces a new `compose tree
--ex-write-lockfile-to=manifest.lock` argument and a new `compose tree
--ex-lockfile=manifest.lock` to read it back for subsequent invocations.
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1745
Approved by: jlebon
Of course, update agents driving rpm-ostree know exactly to which commit
they want the system to upgrade, so `upgrade --lock-finalization` is not
helpful. Teach `deploy` the `--lock-finalization` switch too.
Closes: #1846
Approved by: lucab
Had to track down via strace that it was this that was failing
in my toolbox container.
Really need to merge the unified-core-only PR.
Closes: #1845
Approved by: jlebon
The `old` and `new` naming is odd. It implies a temporal relationship
between the two commits. Just rename those to the more apt "from" and
"to".
The difference is mostly cosmetic, but I didn't want to inherit this in
the new JSON interface. It does technically breaks the `diff` output
which is a somewhat machine-compatible interface, though the "ostree
diff commit" headers have been pretty freeform anyway, so I doubt anyone
is actually trying to read those.
Closes: #1844
Approved by: cgwalters
Add a new "json" output format. The "diff" format is also a mostly
machine-compatible one. But JSON is much more ubiquitous and easier to
consume.
Closes: #1844
Approved by: cgwalters
Right now, after calling `rpm-ostree finalize-deployment`, we update the
`DefaultDeployment` property so that its `finalization-locked` key is
updated. This allows update agents like zincati to correctly understand
the current state if the reboot is locking/inhibited.
The issue though is that this property is accessible through D-Bus only,
and current plans for zincati is to just use the CLI for now.
Unfortunately, the output of `status --json` doesn't correctly get
updated since the deployments array comes from the sysroot interface.
Just use the nuclear mtime bump instead to force a reload. Another
approach long term is to formalize the set of paths/attributes libostree
clients should be monitoring, though having a single API is nice too.
Closes: #1842
Approved by: cgwalters
1. Allow deleting keys without values (e.g. `nosmt`) if such a key
variant exists (i.e. this won't work if there are only e.g.
`nosmt=foo` and `nosmt=bar` variants).
2. Allow deleting duplicate `keys[=val]` kargs.
Closes: #1834Closes: #1835
Approved by: cgwalters
Prep for adding support for injecting native ostree layers; we still
want to run posttrans scripts (and file triggers) after these so
that adding a shared library will still have `ldconfig` run.
Closes: #1836
Approved by: jlebon
The Unix tradition is generally not to add English text unless
necessary.
This makes the output of this command more obviously parsable,
although I'm not entirely sure we should do this versus adding
`--json` or so, but eh, it's also not wrong.
Closes: #1833
Approved by: jlebon
This allows one to run the tests from a container using overlay +
SELinux protection by running the actual compose into a non-overlay
bind-mount. Otherwise, we'll hit `ENOTSUP` when trying to set labels on
various checkouts.
Closes: #1829
Approved by: cgwalters
There are cases where we do want all the things that specifying a ref
provides (e.g. change detection, version incrementing, SELinux labeling
optimizations, and of course writing the ref) but we *don't* want the
new commit to have a parent. Add a new `--no-parent` option to
accommodate this.
This will be used by coreos-assembler. See discussions at
https://github.com/coreos/coreos-assembler/issues/159.
Closes: #1829
Approved by: cgwalters
We had a subtest that wasn't actually part of the `basic_test()` and so
was being executed when the file gets sourced instead of the function
being explicitly called.
Closes: #1829
Approved by: cgwalters
Switch the Docker + Vagrant development docs to use a Fedora 29
build container, and a Fedora 29 Atomic Host Vagrant box. CentOS
7-based testing was recently removed (#1785) - let's have the
documented development pattern reflect this.
Also no longer enables the EPEL7 repo in the Vagrant VM, as needed
dependencies are available in Fedora Atomic Host.
A note is left to later switch to Fedora CoreOS as the documented
Vagrant box to use, once Fedora CoreOS boxes are produced.
Alternatively, one may use [cosa](https://github.com/coreos/coreos-assembler).
A few notes are also added to vagrant/README.md in places where
the reader may hit problems.
squash
Closes: #1826
Approved by: cgwalters
Add a link to tests/README.md to point readers to additional
information on where to find different types of tests.
Closes: #1826
Approved by: cgwalters
In the app, rebuild the exact command-line that the client used and pass
that to the daemon to be used as the transaction title. Especially in
transactions like `UpdateDeployment()`, we can avoid reverse-engineering
what the original command used was.
This will be used by the upcoming history feature to record the
command-line used in the journal.
Closes: #1824
Approved by: rfairley
This bumps the requirement on the controlling host to Python 3 only.
It also bumps the requirement on the target host to Python 3 as well
since FCOS doesn't ship Python 2 right now.
Though we'll need to eventually drop all Python usage anyway, but at
least let's get tests passing on FCOS first. (See related previous
patch).
Closes: #1828
Approved by: cgwalters
Also switch to using `jq` on the controlling host instead of Python.
This is also prep for switching CI to FCOS which is likely to not ship
Python at all. There are still spots a bit everywhere where we currently
assume Python on the target host. We'll have to address those soon.
Closes: #1828
Approved by: cgwalters
In Fedora 29, and Fedora 30 Silverblue, I have come across the
following error when executing `make vmsync` from my build container
(also on Fedora 29 and Fedora 30 images respectively):
```
...
Failed to connect to new control master
...
Control socket connect(/var/tmp/ssh-vmcheck-1556768111752693879.sock): Connection refused
Failed to connect to new control master
...
```
Previously this worked with Fedora 28 as the host.
After changing the socket to be in /dev/shm, the SSH connection to
the `vmcheck` VM is successful and the sources sync over.
The cause of this seems to be a problem with overlayfs and unix
sockets: https://github.com/moby/moby/issues/12080
Since overlayfs is the default graph driver in Fedora now, work
around this by switching the socket to be in /dev/shm.
Closes: #1827
Approved by: jlebon
Instead of doing a bunch of work before setting the transaction title,
set it upfront.
Also make more explicit how we determine whether we're doing an upgrade.
Closes: #1825
Approved by: rfairley
Make it use the `deploy()` function like the others instead of having a
separate function that sets kargs and then automatically deploys.
Prep for future patches.
Closes: #1825
Approved by: rfairley
For the history work, I'd like to be able to retrieve the full GVariant,
which includes the whole unfiltered layered and base commit metadata. So
let's add an argument to allow not filtering those.
Closes: #1823
Approved by: mike-nguyen
