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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- 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 `rpmostreed_refspec_parse_partial` method would only work with
refspecs that include a remote. This was causing rebases to fail when
specifying a local ref. However, it should be perfectly valid to do
this. Adapt the function.
Closes: #371
Approved by: cgwalters
We would unconditionally call ostree's pull() regardless of whether the
branch we were tracking was remote or not. We need this to work to make
it easier to write tests, though it's a worthy addition on its own.
Closes: #371
Approved by: cgwalters
The origin might have an empty "requested" key in the "packages"
section, which is probably an indication that packages were once added
but were then removed.
Explicitly check the length of the pkg array in case it's actually
empty before adding the base-checksum to the deployment variant.
Closes: #371
Approved by: cgwalters
Add some notes in the manual about package layering. Would be nice to
have `ostree admin unlock` also be part of the ostree manual for a
better contrast of the two.
Looking at the other snippets in the document, this makes me think we
probably should also add wrappers in `/usr/bin/atomic` for the new
commands. Or maybe we should wait until they're not in preview mode
anymore.
Closes: #374
Approved by: cgwalters
Tests were failing because we were silently falling back to the system
libhif, which, as of PR #158, changed a string from non-const to const,
which meant we were double free-ing strings.
Closes: #373
Approved by: cgwalters
I'm thinking this list of things actually needs to live outside of the
source code and be more obvious (and we should file bugs to get the
packages fixed), but in the short term my demo today uses Vagrant and
it'd be nice if it was installable.
Closes: #364
Approved by: jlebon
I was hitting a strange segfault when trying to add a package,
and it ended up being that `krb5-libs` was in the transaction,
but its `rpmteKey()` was `NULL`.
It took me a while to realize that the reason this was happening is
`krb5-libs` was in the base, but there was a newer `krb5-workstation`
package wants a newer version.
We're going to encounter interesting issues with packages that have
hard version locking, where one half of the package is in the base and
the other half is layered.
It works for me to drop out `UPGRADE` etc. from the transaction. In
this case, what will happen is libsolv seems to silently avoid
upgrading to the newer version of `krb5-workstation`.
In general, we're going to need `pkg-add` to be able to upgrade as
well at the same time, but that's for a later patch.
Closes: #362
Approved by: jlebon
So I was trying to hack on my host's copy of rpm-ostree inside a pet
docker container, but ran into a conflict with libhif since dnf uses
it. I think we basically need to *always* build the bundled path,
rather than what I'm doing with CAHC and FADC where it's built as a
regular RPM.
It's not really sustainable right now for us to have both bundled and
not-bundled build paths - and we need to support co-installation with
dnf.
Another major issue is that we want to version lock with libhif -
right now our CI and both CAHC/FADC track libhif master, but that
means everything breaks if libhif breaks and we don't immediately
port.
git submodules solve all of these problems - the same as we're doing
with libglnx.
libglnx is *designed* for use as a git submodule, where as libhif
needs to support being both bundled and not-bundled. So we end up
with some hacks on our side, but I think it's all not too bad. I've
marked build rules with `# bundled libhif` so we know where to find
them later when libhif is stable.
Closes: #357
Approved by: jlebon
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
For the regular hack/build/test cycles, creating a new deployment each
time becomes overkill. We add a new `make vmoverlay` target which
directly overlays the newly built binaries on an unlocked system.
We also make rsync smarter so that we can afford to not `make clean`
everytime while still allowing the host's repo to be fully configured.
Closes: #360
Approved by: cgwalters
I noticed that actually `hif_package_get_nevra()` mallocs, but a bunch
of this core code seems to assume it's const.
Actually, I suspect there's no good reason for it to strdup, so I'll
fix that too.
But in the meantime, we actually don't need to indirect through the
nevra, we can just store the `HifPackage` that we wanted anyways as
the key.
Now, the *real* reason I wrote this is right now rpm-ostreed is
segfaulting due to failing to look up the key, and I can't figure
out why...this doesn't fix it, but it makes the code better.
Closes: #359
Approved by: jlebon
Let's say package layering is "preview" - we show it in help, but
marked `(preview)`.
Whereas the `container` and `internals` builtins this patch calls
"experimental" - we don't show them in help even.
Both get a warning message when executed.
Closes: #354
Approved by: jlebon
I was trying to upgrade my desktop today and hit errors due
the fact I was apparently only upgrading the base, and not
layered packages. (Due to a newer shared library in the base
needing to be version locked with a layered package).
It turns out we were keeping the cache forever, which is really quite
the opposite of what we want here.
I haven't looked if librepo is doing If-Modified-Since etc. updates or
not, but if it isn't we need to fix that.
Closes: #355
Approved by: jlebon
During the initialization of the daemon, it would try to load the
deployments and cache a few things. One of these steps wanted to look up
the rev of the deployment. However, if the rev no longer exists (e.g. we
just did a rebase, purged the ref, and rebooted), this would error out.
Replace the lookup by simply directly using the csum from the
deployment.
Closes: #353
Approved by: cgwalters
Rebasing on a new branch should not in any way care about which commit
we're currently overridden on.
Also fix a typo which would cause override-commit keys to not be
deleted from the origin.
Closes: #353
Approved by: cgwalters
Now that the `status` command learned a `--json` option, we can pretty
much avoid parsing human-readable output. The only piece of information
that is missing from the JSON output compared to the output for humans
is *which* deployment we're currently booted in.
This patch fixes that shortcoming by adding a "booted" boolean variant
to the deployment variant.
Closes: #350
Approved by: cgwalters
In order to make many things work, we need to run scripts. Short version:
For now, we:
- Run `%posttrans`
- Treat most `%post` as the same as `%posttrans`
- Ignore `%preun` and such since we never uninstall
Most importantly though, we start to build up an "override" list
for script handling. Currently it's just a blacklist of scripts
we don't need.
Significant work here would be needed to run Lua scripts, so far I've
been able to just skip them.
Closes: #338
Approved by: jlebon
We don't currently expect people to sign commits locally.
However, long term, I would like to support a verified boot model
where we still support layered packages. A system administrator could
log in and perform changes, and possibly use a remote hardware token
to sign the commit. Anyways that's for the future.
Closes: #346
Approved by: jlebon
I've found it's a lot less code to have multiple builtins share live
in the same `.c` file where they can share things like options.
Also, rename `pkg-delete` -> `pkg-remove` since the canonical antonym
of `add` is `remove`.
Closes: #345
Approved by: jlebon
By far the longest step in provisioning a new VM is the building of the
container. This helps alleviate things a little by caching it on the
host. It's not a complete solution however. We also need to make it easy
to update an existing container.
Closes: #344
Approved by: cgwalters
From Vagrantfile:
It's just easier to have ssh set up as root from the start so that tests
don't need to sudo, which can sometimes cause issues. If we need to test
any unprivileged things, we can still just sudo back into the vagrant
user.
Closes: #344
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
Add a HACKING.md document detailing how to get started and test
rpm-ostree using the vagrant box.
Fix the CONTRIBUTING.md link and add a link to HACKING.md in README.md.
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
Link to the Fedora bug that introduced this, and also change things so
it's also used for the "compose" case because:
- Again it doesn't add security
- Tools that operate on "compose" repos have to work around this
when doing checkouts, see e.g. https://lists.freedesktop.org/archives/xdg-app/2016-June/000241.htmlCloses: #335
Approved by: jlebon
I was in the process of trying to support `%post` scripts, and I
wanted to use `rpm-ostree container` for convenient and safe testing.
However the recent package layering changes broke it to error out
on perms like `filesystem`'s `root:mail` on `/var/mail`.
I decided to introduce a new `rpmostree_context_new_compose` which had
the current behavior, switch `compose tree` to use it, and then change
`_new_unprivileged` to *really* be unprivileged. Specifically we
ignore file ownership (and fix dir owners) because we assume we'll be
operating with `bare-user` repos.
Closes: #327
Approved by: jlebon
We need the ability to both add and remove packages as one
transaction in the general case (`Conflicts:`), plus it'd
be quite nice to allow users to do multiple package things
before rebooting.
And finally, this deletes a lot of duplicate code.
Where I'm really thinking this should go is we only have one
transaction type internally for at least upgrade/pkg as a group.
Closes: #326
Approved by: jlebon
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
In the future I want to add more content in the status such
as active operations, so let's make the "deployments" just
one entry in an object.
Closes: #320
Approved by: jlebon
Really...we should have done this since day zero. Given that the
final integration of package layering/compose/rpm caching is finally
over the horizion but not yet here, let's still do this now.
I plan to backport this patch to the 2016.3-fixes branch.
Closes: #332
Approved by: jlebon
