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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is a follow-up to commit 77acf62. There, we added support for
rebasing from a local branch to another local branch. But in testing,
it's also really useful to be able to rebase from a remote-based refspec
to a local branch. We allow this here by slightly expanding the syntax
of allowed refspecs.
Now, we can use rpm-ostree all the time rather than fallback to `ostree
admin deploy`, which isn't pkg-aware.
Closes: #764
Approved by: cgwalters
Conceptually: we're going to move rpm-ostree and ostree at the same
cadence most of the time; for both releases *and* for git master.
The problem so far has been the latter part. Reusing FAHC
for the build gets us half of the problem.
The other trick I realized we can do - just pull ostree out from the build
container. This avoids fetching it from the internet, and makes my workflow for
hacking on both nicer - I just `sudo make install` in my build container for
ostree.
It's tempting to make the whole thing symmetric and require `sudo make install`
for rpm-ostree and not do the insttree thing but...perhaps after.
Closes: #758
Approved by: jlebon
This was argued on list a while ago: http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000391.html
Basically, every use of `%pretrans` is a workaround for some in-place
upgrade problem. But we never do inplace updates, we always assemble
a new tree. Hence, there is no point for us to ever execute these.
Let's stop erroring out on them. If there does turn out to be some problem with
a particular package (e.g. the `openjdk-copy-configs` or whatever), we would
likely end up needing to fix that package's `%post`, not start executing its
`%pretrans`.
Closes: #763
Approved by: jlebon
`Commit` is useful in cases where one wants to e.g. run `rpm-ostree db diff`.
`StateRoot` however is going to be in the vast majority of cases identical
across deployments.
Closes: #743
Approved by: jlebon
This is preparatory for future changes which will make use the newer sysroot
writing API. But in this change, we can drop all of our version ifdef'd code.
Closes: #740
Approved by: jlebon
I want to be able to debug a test by sshing in with the same setup;
right now the suite resets and reboots by default.
This also required fixing how we deal with `/etc/yum.repos.d`, since at the
start of the test it could be either pristine or not.
Closes: #578
Approved by: jlebon
I need to build ostree from git too. So now my workflow is:
```
export insttree=/srv/walters/tmp/rootfs
cd ostree
make && make install DESTDIR=${insttree}
cd rpm-ostree
make && make install DESTDIR=${insttree}
env VMCHECK_INSTTREE=${insttree} make vmoverlay
```
Closes: #705
Approved by: jlebon
Just like `rpm-ostree ex`, for things like `ex livefs` that have DBus
interfaces, we should segregate these off so that people know they're unstable.
And conversely that they can test for the presence of the method on the main
interface for stability.
I initially tried having the same `RpmostreeOS` object implement both
but couldn't work out how to do that; see https://mail.gnome.org/archives/gtk-app-devel-list/2017-March/msg00161.htmlCloses: #701
Approved by: jlebon
I originally thought there was a bug here, but missed we were skipping
symlinks earlier above. See [previous discussion][1].
Now, I'm not aware right now of something this patch actively fixes, but I think
it makes sense to be consistent in our handling of things here with respect to
symlinks.
1: 29dd1bd801..8158dcfb47 (r95017893)Closes: #689
Approved by: jlebon
There's no point to shipping these backup files in the base tree. We already had
code to delete them for the package layering case where they caused active harm.
At the point we added that code we really should have *also* changed treecompose
to delete them. Better late than never.
The reason I'm doing this now is because having them in the base tree causes `ex
livefs` to spuriously think that layering a package that *doesn't* change `/etc`
as if it does, because the layering code deletes the backup files.
Closes: #693
Approved by: jlebon
I built+installed ostree git master with
https://github.com/ostreedev/ostree/pull/723 in my dev container,
which broke the rpm-ostree tests. Kind of embarrassing that
I forgot to check rpm-ostree for usage of `ostree trivial-httpd`.
This is another thing that really wants a shared test container.
Anyways let's just use Python for this.
Closes: #684
Approved by: jlebon
I'd like to embed structured metadata about the originating git
repository. See [this example](https://pagure.io/fedora-atomic-host-continuous/c/142b12020d7efe18b56d039304efea102a210790?branch=master). However, I think what we really
want here is a *single* value which has subkeys.
One thing in the back of my mind too is...we could use this to
enhance our "change detection". Right now we checksum the sack,
treefile, and treecompose-post. But down the line, I'd
like to support more sophisticated postprocessing, where the
script might reference external files or the like.
In that case, we could stop checksumming the post script, and rely on whether or
not the git repo changed. (This would conversely mean we would do a build even
if e.g. the repo's `README.md` changed, but we can address that with a
post-assemble content check).
Anyways though, for now, this gets us the ability to more easily drop more
structured metadata in the commit, whether it's input git repos, tests that
passed, etc.
Note a trap that bit me here: since the metadata we write here is *host* endian,
but `ostree show --raw` byteswaps (it needs to since the core ostree variant
is always big endian), we get inverted numbers if the host is little.
I think we should probably canonicalize our metadata to big endian; this should
be pretty backwards compatible since I doubt anyone has been adding raw numbers
so far.
Closes: #676
Approved by: jlebon
Allow the `make vmcheck` target to take a HOSTS var, which is simply a
space-separated list of hosts on which we can run testsuites. Add a
multitest.py script that takes care of monitoring and scheduling the
tests onto the nodes.
The script itself is "dumb": we don't know how long each test can take,
so we can't do any smart/heuristic scheduling that could save more time.
Closes: #675
Approved by: cgwalters
1. Don't require an ssh-config
In the case of redhat-ci, the VMs are already fully configured for the
system (injected in the hosts file, host key accepted, etc...). So
there's no need to have an ssh-config there. In general, it should be
acceptable to run the vmcheck suite against a resolvable host without
having to create an ssh-config for it.
2. Make the host name configurable
Rather than hardcoding "vmcheck" as the hostname, allow overridding it
by specifying a VM env var directly. We also prepare the various scripts
to make use of the $VM variable whenever host-specific dirs/files are
created so that parallel runs won't step on each other.
Closes: #675
Approved by: cgwalters
We start by adding support in the core for installing packages strictly
from the cache repo. We fool the libdnf stack by re-exporting the header
as an RPM, and explicitly marking it for install. The treefile format
supports specifying the expected SHA-256 of the metadata header, in case
the cache for a specific NEVRA changed.
Closes: #657
Approved by: cgwalters
Pull #646 introduced a subtle regression: we went from always including
a "packages" entry to only including it if there are packages present.
Albeit it's easy to guard against, though to be nice, let's make it
easier for consumers by always including it.
Reported-by: Micah Abbott <miabbott@redhat.com>
Closes: #670
Approved by: cgwalters
While reading a recent conversation about GPG checking at treecompose
time, I had a sudden thought - were we actually doing verification
client side? Turned out, we aren't. That happens as part of
`dnf_transaction_commit()` which we don't use.
That function verifies every package at one go, but for us I think it's better
to do it before "importing". We shouldn't have untrusted bits that we've
unpacked (they might have suid binaries, for one thing).
This is an embarassing problem, but it's worth emphasizing that everyone should
be retrieving repodata at a minimum over TLS, which sets a baseline. On RHEL, we
already do pinned TLS, and there are discussions about extending that elsewhere.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1422157Closes: #656
Approved by: jlebon
We don't want to expose the host's `/tmp` since that means scripts could
potentially find things like the X11 socket or whatever.
To debug things better, add a quick bash script to run bwrap like the C code
does. Perhaps down the line we can add `rpm-ostree internals run-bwrap` or so.
Closes: #647
Approved by: jlebon
There are two main issues right now; first, we don't pick up manual changes to
`.origin` files, which occurs when one needs to sed it to remove `unconfigured`
for example. Second, we need to reload changes to the remotes.
Closes: #598
Approved by: jlebon
Clean up the output of vmcheck a bit by printing out ssh debug details
and rpm-ostree status output to the log file. This will help make it
easier to quickly see which tests failed (as well as helping satisfy my
OCD for a nice output).
Closes: #645
Approved by: cgwalters
On the first call to vmsync/vmoverlay, we do an immediate vm_ssh_wait()
to check if we have a live VM. However, we don't necessarily have a
working rpm-ostree in there if we're hacking on stuff. It gets annoying
to wait for the timeout there.
Let's just work around that by instead only calling status if we got
there through vm_reboot_cmd(), which is most likely when we're most
interested in the status output anyway.
Closes: #645
Approved by: cgwalters
See https://github.com/projectatomic/rpm-ostree/issues/233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).
Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.
Closes: #624
Approved by: jlebon
As part of an earlier cleanup of origin parsing, we started checking
the origin `unconfigured-state` even just starting the daemon, which
is kind of bad.
It's tempting to flip the default for the parser so that we *only* check
unconfigured state if we go to upgrade, but let's not do that in this patch.
Closes: #626
Approved by: jlebon
I'm not sure why we weren't doing this before, but we need to also
support files in /var and /run that are owned by root.
Related: RHBZ#1421781
Closes: #622
Approved by: cgwalters
We sometimes talk about using `ostree admin undeploy`, but that
doesn't know about the pkgcache, and hence space there leaks
until the next rpm-ostree operation.
Just for this, we need to expose a cleanup command (and API). But
we also need to support cleaning:
- repomd
- downloads (repo/tmp)
So let's start implementing that.
Closes: #614
Approved by: jlebon
I debated just putting this in the supported list, but decided against
it in the end. This really should be something that happens
transparently, and if it doesn't then something else is probably wrong.
Closes: #617
Approved by: cgwalters
Until now, we always used the booted deployment, and would
garbage collect the "pending" deployment. This is the
way OSTree was designed, but I think for rpm-ostree given
how mutable we are on the client side, there's a much stronger
argument for being more stateful too.
This is a relatively simple code change to split the "merge deployment"
concept into two. There's now the "config merge deployment" and the
"origin merge deployment".
Basically, `rpm-ostree install foo; rpm-ostree install bar` will
now install both `foo` and `bar`. But we will still use the booted
deployment for `/etc`.
Down the line, I think I'd like to drive into OSTree the concept of
a "staged" deployment, that has the hardlink checkout done, but doesn't
have the config merge.
But we don't need to change the OSTree core for this yet; we can
do it here in rpm-ostree, and this relatively simple code change
fixes many issues at once.
For example, `rpm-ostree upgrade && rpm-ostree install foo` now
does what you expect as well.
Obviously, we want to enable doing multiple things in *one* transaction,
and we're not far away, but I think this is also the right thing to do now.
I'm relatively confident it won't break anyone's workflow, as what
we did before wasn't generally that useful. However, people will
need to learn to `ostree admin undeploy 0` if they *don't* want
this behavior. (We need to have `rpm-ostree cleanup`).
Closes: https://github.com/projectatomic/rpm-ostree/issues/406Closes: #611
Approved by: jlebon
I'm watching https://github.com/rpm-software-management/libdnf/pull/199 and I
really don't like it. We already have a place to put out-of-rpmdb metadata,
which is in the ostree commit for imported packages. No need to involve a
relational database for this (and further, one that would need to learn about
multiple ostrees).
We're not yet *using* this information in the UI, but we could; imagine
changing the `status` `Packages:` to show packages-per-repo or so. We
could also expose an `rpm-ostree pkg-info foo`.
But for now, let's just start recording this.
Closes: #610
Approved by: jlebon
One thing that's very confusing about OSTree is there are two layers -
deployments and the refs/commits. If one does an `rpm-ostree upgrade`, but then
e.g. `ostree admin undeploy 0`, you still have the new revision in the repo.
We don't do a good job of displaying this state, or helping people clean
it up.
Down the line, I also want to better support something like `rpm-ostree pull` to
cache updates explicitly *without* deploying.
This commit just adds a bit of information to the status display. We might want
to have better formatting, but I think this an OK start.
Closes: #595
Approved by: jlebon
The actual problem I am trying to fix with this is fallout from the
introduction of `/usr/libexec/rpm-ostreed`, which required a SELinux
policy change. Specifically for CentOS, the base policy is rev'd
slowly.
My hope was that by merging the daemon code back into `/usr/bin/rpm-ostree`
which is labeled `install_exec_t`, starting via systemd would do
the right thing. It turns out that doesn't happen.
Now later, I'm picking this patch back up because I want to do multprocessing in
the daemon (and in the core), and it makes sense to share code between them,
because multiprocessing will need to go through a re-exec path.
Another benefit is we avoid duplicated text (libglnx, internal helpers) between
the two binaries.
Closes: #292
Approved by: jlebon
When we checked out the base tree for package layering, we would create
the directory in which ostree did the checkout. This meant however that
ostree wouldn't apply xattrs on the root directory itself. This would
cause the directory to be mislabeled (as system_conf_t instead of
root_t), which in turn cause SELinux violations on reboot when systemd
tried to make the root mount shared.
This patch fixes this by first settling on a permanent directory in
which to do checkouts -- really, we'll never have multiple package
layering operations going on at the same time. Once we know that we have
a reserved path, we can safely let ostree create it for us with the
proper xattrs.
Resolves: RHBZ#1318547
Closes: #605
Approved by: cgwalters
Currently we push for a model where the initramfs is
generated (in non-hostonly mode), and merely replicated.
However, to support a few unfortunate corner cases like dm-multipath which wants
to inject a config file into the initramfs, we need to support regenerating it
client side too.
Down the line, we'll need this to support overriding the kernel too.
This changes things in the core to add the concept of an "empty"
`RpmOstreeContext`. I initially tried skipping it, but that was too much
duplication. We still want all of the core ostree-related logic that lives in
that code too.
The treespec bits barfed if the spec didn't have a `tree/packages` key. It was
simplest to change that to allow it - and because that was the only case where
we errored out in parsing, I dropped the error handling.
There was another place in the upgrader that now needed to be fixed to handle
transitioning from just regenerating initramfs to not.
Closes: #574
Approved by: jlebon
Many projects do this, and it really helps debugging to know the
exact hash.
(Of course this is broken in traditional rpm builds from a tarball,
and rpmdistro-gitoverlay injects it into the Version field,
but it will help me for vmcheck debugging)
Closes: #584
Approved by: jlebon
I think since I landed a change to `--enable-new-name`, `/usr/bin/rpm-ostree`
became a symlink, and without the `-l` switch, rsync skips over them.
Hence, we have only been testing in vmcheck the old binaries, not new ones.
Oops.
Closes: #585
Approved by: jlebon
I don't see a reason not to require more stuff to execute tests,
and having it be optional reduces our coverage unnecessarily.
Closes: #580
Approved by: jlebon
Working on initramfs, I hit a subtle issue with the fact that
I was trying to "redeploy", but with the origin file changed
during the process.
Previously, it was a bit unclear which parts of the upgrader logic are operating
on the *new* origin versus the "original origin".
The package layering code in the upgrader explicitly carries a delta on top in
the "add/remove" hash sets, which means it isn't visible to
`rpmostree_origin_is_locally_assembled()`.
Whereas for initramfs, I set a new origin. This broke things since we were
expecting to find a parent commit, but the original origin wasn't locally
assembled.
When looking more at this, I realized there's a far simpler model -
rather than keeping track of commit + origin, and using the origin
to try to determine whether or not the commit is layered, we can
keep track of `base_revision` and `final_revision`, and the latter
is only set if we're doing layering.
The diff speaks for itself here - a lot of fragile logic looking at the origin
drops away.
The next step here is probably to drop away the package layering hash sets, but
I'm trying to not change everything at once.
Closes: #579
Approved by: jlebon
Our `make check` runs an unprivileged rpm-ostreed if run as non-root; this is a
feature. We didn't notice in the CI tests since those run as "docker-uid0". It
does break my local workflow though.
Closes: #573
Approved by: jlebon
We seem to have substantial infrastructure drift here between the two, and I was
*really* confused why `TEST_SKIP_CLEANUP` wasn't being honored. Turned out in
rpm-ostree we have tmpdir code in two places, not entirely sure why. Punting
full cleanup.
Closes: #566
Approved by: jlebon
First try to log in, and if we fail, retry with SSH debugging,
so we have a better idea what might be going wrong. This helped
me figure out that vmcheck's `-o User=root` assumption wasn't
working with my vagrant setup.
Closes: #560
Approved by: jlebon
Being able to just reuse metadata is especially helpful when trying to
debug things lower down that path, as well as cuts about 2 mins from the
compose test.
Closes: #561
Approved by: cgwalters
During a deploy operation, we would fetch commit objects from the remote
to resolve the version string. If gpg-verify was turned on, we would
fail to pull them if some of the commits were not signed. This is
because we pulled them in batches. We partially address this by only
fetching the HEAD commit on the first pass. This allows `upgrade`
operations to work just as well as `deploy` operations.
Though there is still an issue if we have to traverse farther back than
when signed commits become unsigned (unless they happen to fall on a
batch boundary). We leave that unsolved for now, since that would likely
require a more complex solution and it's not clear whether it's a real
world issue (signers can just retroactively sign commits).
Copy the gpghome from ostree so that we can test GPG-related cases in
our suite.
Closes: #527Closes: #557
Approved by: cgwalters
Expand the available options in the Rebase() D-Bus method to also have a
"revision" key. Its value has the same semantics as the "revision" key
in the Deploy() method (e.g. the "revision=" and "version=" prefixes are
also supported). Also expand the rebase CLI to allow for specifying the
revision as an additional argument.
This allows users to rebase to a specific version or checksum, rather
than only to the latest. Conceptually, this is the equivalent of doing a
rebase followed by a deploy. I.e. we specify an override-commit in the
origin and expect the same behaviours that apply after a deploy to also
apply here.
Closes: #212Closes: #555
Approved by: cgwalters
In the container build + vagrant test workflow, we have to run `make
vmsync` from the env in which autoconf was run, which is the container.
However, when using git worktrees (which is useful in this scenario to
avoid having to overwrite your local builds) and a CentOS build
container, the git inside is too old to understand worktrees, so let's
avoid invoking git in any of the test harness scripts.
Also make sure to restorecon after installing the new rpm-ostreed.
Closes: #555
Approved by: cgwalters
Add a few more tests to exercise some of the treefile options. We do
need to also expand test-basic.sh itself to sanity-check the structure
of a normal ostree compose. That's up next on the list.
Closes: #548
Approved by: cgwalters
Unsurprisingly, rebooting machines that are running in OpenStack is
not as reliable or as fast as a local VM, which is what vmcheck was
originally written for and tested against.
Replace the:
sleep 2 # give time for port to go down
which is rife with raciness, with a stronger boot_id-based check to
ensure we're in a new boot. Run "sync" before rebooting which sometimes
helps (though I didn't fully investigate why or whether it always helps,
there's probably something more subtle going on underneath). Increase
the timeout to 120s.
Closes: #543
Approved by: cgwalters
Our current compose tests only use a synthetic `empty.rpm`, but
this really limits usefulness.
Let's make a test suite that requires an internet connection and
downloads Fedora RPMs and does "real" tree composes.
See the updated `tests/README.md` for more information.
This is still a WIP.
Closes: #531
Approved by: jlebon
This is just the final bit required to make sure the vagrant and
non-vagrant paths can work happily together. It's mostly minor fixes,
though the most major change which also affects vagrant is that we now
sync to the root home dir, rather than ~vagrant.
Closes: #524
Approved by: cgwalters
My development environment is now using "pet" docker containers.
I use VMs for testing things that require that (like rpm-ostree).
This patch builds on work from @jlebon in
https://github.com/projectatomic/rpm-ostree/pull/509
to rework `vmcheck` such that it can work on any `ssh-config`. By
default we expect this to be Vagrant.
However, I go a lot farther and delete the `vmbuild` code that was
trying to do builds in a container on the target VM. I think this is
still worth pursuing at some point, but for now I think it's
reasonable to assume that the rpm-ostree developer audience uses Linux
as their host workstation and hence has containers.
(There's another important point here in that for developing lower
level things like rpm-ostree, there's a strong push to make the VM
disposable and not a pet)
Closes: #516
Approved by: jlebon
We further split libvm from vagrant. It no longer does 'vagrant
ssh-config'. Instead, it always assumes that an ssh-config is provided.
We now have complete separation of libvm from vagrant.
We change the ansible provisioner as follows:
- Allow passing in a VAGRANT_BOX env var to override the default
CentOS box.
- No longer assume that the root user account is unlocked and has a
valid 'vagrant' password. This worked for the centos box but isn't
sure to work on every box. Instead, we now just run ansible as the
default vagrant user, and during provisioning set up the root
account and generate an ssh-config so that libvm can connect
directly as root.
- No longer build the buildimg during provisioning. This actually
stopped working a while ago since the default rsync is disabled. We
can just let the buildimg get created on the first compilation. In
practice, the bigger issue isn't creating the buildimg, but being
able to easily update the host and buildimg pkgs.
Closes: #516
Approved by: jlebon
Thought it'd be fun to write a test for verifying proper handling of
scriptlets during package layering. There's obviously a lot more that
could go in here (patches welcome!), but it's a start.
Closes: #434
Approved by: cgwalters
This is a useless test for now since we should be able to test on a VM
even if there are updates available.
I initially had it just as an example of the vmcheck test harness,
without actually thinking too much into what it was testing. But we do
need a nice test-basic.sh that will give rpm-ostree a good general
workout.
Closes: #394
Approved by: cgwalters
We don't have a lot of outstanding changes to the C code, so now seems
like a good time to do this. I implemented this with some highly
sophisticated sed commands like:
```
find -name '*.c' | while read name; do sed -i -e 's,gs_unref_object \([A-Za-z]*\) \*,g_autoptr(\1),' ${name}; done
```
Part of dropping the dependency on libgsystem, same as what we're
doing in ostree.
Closes: #393
Approved by: jlebon
- Rename test-layering.sh to test-layering-basic.sh and make it test
both pkg-add and pkg-remove.
- Add test-layering-relayer.sh, which verifies that pkgs are properly
relayered during the creation of new deployments (e.g. upgrades,
rebases, deploys).
- Add test-layering-rpmdb.sh, which verifies that packages respect the
rpm requirements before being overlayed.
Closes: #371
Approved by: cgwalters
Print out a better summary that sums up the passes, failures, and skips.
Silence the restoring step at the end of the testsuite by only echo'ing
to the log file. Finally, add some colouring because colours are
awesome.
Closes: #371
Approved by: cgwalters
The test-basic.sh test was failing on machines that had jq installed.
Will have to make sure to add it to the PR tester.
Closes: #360
Approved by: cgwalters
We now make the test harness handle restoring the VM to the original
state. The wonderful thing about ostree here is that it's a perfect
shoo-in for this. We make a 'backup' of the current ref, and just have
to make sure that the VM is back on that ref after running each test.
This will allow us to write tests without worrying as much about
cleaning up in the event of an error.
Closes: #360
Approved by: cgwalters
This is a preliminary package layering test which simply installs the
foo package and verifies that it functions properly. A bunch of
primitives are added to libvm.sh to facilitate this and future tests.
Closes: #344
Approved by: cgwalters
We're going to be create many different packages in the future. Let's
refactor and generalize the targets so that they can build anything.
We also add a package foo, which will be used soon for a basic test of
package layering.
Closes: #344
Approved by: cgwalters
This is a very simple test harness inspired by the atomic one. It's a
simple bash script that sets up a permanent ssh connection to the host
and runs the test scripts. Also add a "demo" test-basic.sh test to make
sure that it works.
Closes: #344
Approved by: cgwalters
If the dir that was rsync'ed already contains build artifacts, we don't
want those contaminating our build process.
Closes: #336
Approved by: cgwalters
I really want a command to cancel the running transaction, but as a
preparatory step, let's display what's going on in `status`.
The text output here is really a demonstration - I'll improve it but I
want to rework the internals first.
Closes: #320
Approved by: jlebon
According to tmpfiles.d(5), files should follow the convention
<package>.conf or <package>-<part>.conf. So we rename
tmpfiles-ostree-integration.conf to rpm-ostree-0-integration.conf.
The 0 index is so that the autovar conf created by postprocess is
sourced *after* this one, so that `integration.conf` has higher
precedence if there are duplicate entries.
Closes: #325
Approved by: cgwalters
The `make vmshell` target makes it even easier to immediately try out
your changes in a live running Atomic Host. It will automatically
provision the VM, sync your latest changes, build, install in a new
deployment onto which the VM is rebooted, and drop you in the shell.
Closes: #321
Approved by: cgwalters
In order for vmcheck to be useful for testing, we need the machine to be
in a "clean" state. That is, sitting on a commit, ready for being
manipulated.
This is a small step towards this goal. Instead of overwriting the
files, we use rofiles-fuse to safely install and create a new
deployment.
Closes: #321
Approved by: cgwalters
It's really simple to reflect the DBus API into JSON, which tools like
Ansible or `jq` from the command line or whatever can parse to find
interesting things like the current version.
Closes: #301Closes: #315
Approved by: jlebon
I find myself not liking the name rpm-ostree anymore; it's
descriptive, but unfortunately we compete with other projects with
easier and sexier names.
Also, people continually find the ostree and rpm-ostree layering
unclear. It's *much* easier to say "nxs depends on ostree", even
though textually it's obvious "rpm-ostree depends on ostree".
Anyways, just an experiment for now.
Closes: #307
Approved by: giuseppe
This is infrastructure that's oriented around Vagrant, we do builds
inside the target VM (actually inside a Docker container), but then
directly `make install DESTDIR=/host/`.
The goal here is to have a convenient workflow for:
- dev -> hand testing
- dev -> run destructive tests
Closes: #303
Approved by: jlebon
Since we now run everything uninstalled, we can't expect the tmpfiles
conf file to be installed. We add an env var that will allow us to tell
rpm-ostree to look elsewhere. This is then used in test-compose.sh.
Closes: #304
Approved by: cgwalters
- Move all the uninstalled, non-destructive tests to check/
- Add a README
- Move utilities to utils/
- Move common files to common/
Closes: #304
Approved by: cgwalters
For now, we don't remove the ability to install tests (e.g. the
necessary blurbs in glib-tap.mk are still there), but we take out all
our previously installed tests from the list.
All the previously installed tests are then converted to work
uninstalled. This also allows us to do some simplifications in the test
cases.
Also do some cleanups in the Makefile to improve legibility.
Closes: #304
Approved by: cgwalters
This works around a potential issue with libsolv if we go down the
rpmostree_get_pkglist_for_root() path. Though rpm has been using the
/usr/share/rpm location (since the RpmOstreeContext set the _dbpath
macro), the /var/lib/rpm directory will still exist, but be empty.
libsolv gets confused because it sees the /var/lib/rpm dir and doesn't
even try the /usr/share/rpm location, and eventually dies when it tries
to load the data.
So we set the symlink now. This is also what we do on boot anyway for
compatibility reasons using tmpfiles.
This also means we don't have to do the /var/lib/rpm --> /usr/share/rpm
transition during the rootfs postprocess (but we still have to clean up
db and lock files).
Also get rid of the unused pkglist variable.
NB: I used the GFile & gs APIs to mesh with the surrounding code.
Closes: #290
Approved by: cgwalters
This comes from the tradition of yum repo files. It's significantly
easier for rpm-ostree users building multiple architectures if some
core templating for the treefiles is built in.
Otherwise, everyone needs to learn about a new wrapper tool for
rpm-ostree, and said tool would need to re-do the same "basearch"
evaluation that is already occuring inside libhif.
This commit also paves the way for introducing `${releasever}`
substitution.
NOTE: This depends on pending changes to libhif git.
Closes: #274
Approved by: jlebon
If one does `rpm-ostree foo --bar`, one would expect to see
`Unknown subcommand foo`, not `Unknown option --bar`.
Closes: #267Closes: #270
Approved by: jlebon
awk is already used by the tap driver, so it won't be an additional
dependency.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Closes: #263
Approved by: cgwalters
I was tracking another regression where we seem to have lost
`/usr/etc` contents which manifested as `Labeling with... (null)`
which was clearly wrong.
Now this change actually impacts the test suite - we now (again IMO
correctly) error out if `selinux: true`. The `no-selinux-tag` test
no longer makes sense, so delete it.
We do need more "real" tests that use selinux on and off.
Pull request: #243
Approved by: jlebon
When running the tests by hand, I wanted to be able to source
`libtest.sh` from a running shell. Make this slightly easier by
allowing one to set `SRCDIR`, since `$0` won't work.
The libtest.sh script is aware of whether a tmpdir needs to be created
or not for the test. Make use of this in setup-session.sh so that we're
sure we're in the right directory before creating the sysroot dir.
Running `make check` would fail because test-ucontainer.sh uses
test-repo, which points directly to the installed_testdir, where it is
not installed yet.
We make another processed version of test-repo.repo.in which instead
points to the repo in the srcdir and make use of that in
test-ucontainer.sh.
There are probably other ways of solving this, but this is the one that
jumped out at me.
For the same reasons as described in GNOME/ostree#187. In summary: we
want to make it easy for testers to clean up after we're done by not
setting the immutable flag.
Note that I had to also add it to setup-session.sh so that the daemon
inherited the env var. The libtest.sh hunk is redundant in that case,
but still necessary if the tests are run directly.
The assert[_not]_file_has_content functions used grep to check the
pattern against the content. This meant that the '.' characters are
interpreted as "any char". Yesterday, the date was 20150910 and thus the
otheros' tree's version was labelled as such. This date also happens to
match the 1.0.10 pattern, and thus caused the test to fail.
This patch makes sure this doesn't happen again by escaping all the dots
to make them literal.
Unfortunately RHEL 7 has an older version of dbus, and I use it as a
workstation. It's not a lot of code and only used for tests. We can
make it build time conditional down the line or something.
This is a *third* implementation of rpm database diffs in the code,
but it is now a public introspectable shared library API.
Further commits will change the command line tools to use this, and
then after that we'll further deduplicate the `db diff` from this
code.
The `QueryResult` class ended up being too awkward; having NEVRA
strings meant for example that clients would have to parse them. It
would be harder to present something like the current `rpm-ostree
upgrade` package diff output.
Now...I debated quite a while before doing this patch. The thing
that's really awful about creating this library is there are *SO MANY*
layers. rpm-ostree → libhif → hawkey → libsolv → librpm. It's enough
to make one question whether one is actually accomplishing anything or
just contributing to a collective insanity...
Let's pretend for now it's the former.
Closes: https://github.com/projectatomic/rpm-ostree/pull/136
This will help build release engineering and other types of tools;
for example, rather than parsing the output of `db diff`, one
should be able to call an API.
Initially, this adds the generic infrastructure for a public shared
library, with a new function call to do the equivalent of `rpm -qa` on
a particular OSTree commit.
Closes: https://github.com/projectatomic/rpm-ostree/issues/117
Closes: https://github.com/projectatomic/rpm-ostree/pull/124
A local yum repository, which contains a dummy .rpm package adding
support for programs needed by the post-process phase, is created as
part of the test.
Since no libc is present, the empty.c program (which is a no-op)
directly invokes the interrupt 0x80 to exit.
The test works only on x86_64, it is skipped on other architectures.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
