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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
So that it's easier to build bubblewrap as `Source1` in an RPM
embedded (flatpak is using a git submodule, but for this I think
`Source1` is better).
Closes: #384
Approved by: jlebon
dockerwait: if we're running on a freshly booted VM, we want to make
sure that docker is running before trying to spawn the container.
check: runs the same target inside the container; this is useful for
coverage analysis, where we want the same binaries to run both the `make
check` and `make vmcheck` testsuites.
clean: for convenience.
Also make sure we pass CFLAGS to both the configure (to propagate to
libhif's cmake) and the make steps. This is also of use for coverage
analysis, where we want to compile with `--coverage`.
Closes: #378
Approved by: cgwalters
Add a clean hook so that `make clean` on the top dir also cleans the
libhif artifacts.
Add -f to `ln` -- Make marks the target as out-of-date if the symlink
breaks (which will happen if you just `make clean` in the libhif-build
dir), but the `ln` will cause the build to fail since it already exists.
Closes: #377
Approved by: cgwalters
For some reason, the VM would sometimes take a very long time to reboot
after deploying the new commit. Adding a sync before rebooting fixes
this, though I'm not sure why the filesystem doesn't sync itself as fast
without it.
Closes: #371
Approved by: cgwalters
- 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
