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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I previously ran out of steam in the switch and wanted to
get the PR out for feedback before continuing, but it turns
out I basically stopped 2 meters from the finish line. Completing
the switch from `failure` → `anyhow` was quite easy.
The failure crate isn't actively developed anymore. The
main benefit of `anyhow` is it uses the standard error type.
More info:
https://docs.rs/crate/anyhow/1.0.28
Start the porting process.
Note that the `envsubst` crate has a public dependency on
`failure`, so we need to start mapping its errors.
This way we handle filenames with spaces in `/var` in general,
like `/var/app/foo bar`, but *also* the special `/opt/foo bar`
translation bits.
I saw this bug and thought "oh that'd be easy". But hoo boy
did it take me down a rat's nest. The first thing was verifying
that `systemd-tmpfiles` supports any kind of quotation/escaping; it does.
The next thing was figuring out *exactly* what the syntax for that
is and how it works, as it's obviously not widely used.
Writing tests for this ended up being a painful exercise because
of the multiple levels of shell script, e.g. our `build_rpm` shell
script ends up being inlined into RPM specs, which then interprets
again...and not to mention the usual annoying issues with `ssh`
eating quotes.
Anyways, all that and:
Closes: https://github.com/coreos/rpm-ostree/issues/2029
Seeing this in the FCOS pipeline:
```
Downloading from 'fedora-coreos-pool'... done
error: cannot open Packages database in /proc/self/fd/21/usr/share/rpm
Importing packages... done
error: Can't stat fd 38
```
The first error is librpm...which, is somehow not fatal? It
also appears to be swallowing the underlying real error.
For the second had to Google search it but the main hit for `Can't stat fd` is
in libarchive which led me to this code, which is probably right.
But let's be sure by adding some error prefixing.
I was getting a dreaded not-quite-specific `syscore cleanup: No such file or directory`
error when hacking on the ostree tests. I am pretty sure it's the history
code, but let's just do the usual thing and spread the error-prefixing love
in the whole area.
The ostree test suite was creating deployments manually
(skipping the rpm-ostree upgrader layer which would write history)
and then calling `rpm-ostree cleanup` which tried to open the
history dir and failed.
Just return early if there's no history directory when we're
asked to clean up.
In the large majority of cases, the `"Bus owner changed"` error is due
to something going wrong with the daemon rather than D-Bus itself. Let's
give a hint to check the journal so that users can investigate and e.g.
just paste the journal output as part of the initial issue report.
We need to adapt some of our tests here which assume that `/sysroot` is
writable. However, in FCOS this is no longer the case now that we enable
`sysroot.readonly`.
We only remount rw for the couple of operations that need it so that we
still retain coverage for the ro path everywhere else.
FAHC is super out of date now. The way to have access to newer packages
is via the continuous tag, which is still manual for now, but at least
targets the right Fedora release.
The current `rpm-ostree-2020.1-1.fc31.x86_64` in Fedora
was [built with a truly ancient libostree](https://kojipkgs.fedoraproject.org//packages/rpm-ostree/2020.1/1.fc31/data/logs/x86_64/root.log)
because Fedora's build system is weird and only adds packages
released after "gold" into the buildroot via an override
that times out.
This actively breaks things because rpm-ostree isn't
detecting the read-only sysroot.
Let's bump our hard requirement.
Mostly minor tweaks to adapt to the new custom steps. We have a pretty
involved pipeline here so we don't actually use the higher-level steps
like `fcosBuild`.
This is the second half of the previous commit. We check if the
canonical dracut args are available in the commit metadata, and prefer
those over using `--rebuild`. The latter is delegated as a backcompat
fallback.
Keep the base initramfs arguments used in the commit metadata. The
reasoning for this is that when regenerating the initramfs locally with
`rpm-ostree initramfs --enable`, we want to match how it was built in
the treecompose. This is important because the rest of the treecompose
assumes that e.g. certain dracut modules are included or omitted.
Right now, the way we achieve this is with using `dracut --rebuild`.
However, we no longer have access to the base initramfs when replacing
the kernel. Another issue with `--rebuild` is that when we *do* use it,
dracut just dumbly appends the arguments to the base args. So we then
end up with e.g. two `--kver` args, two `--add ostree`, two `--tmpdir`,
etc...
Another way to look at at this patch is that it unifies client-side and
server-side paths when generating the initramfs. The only difference
then is that we use the local `/etc` in the case of
`rpm-ostree initramfs --enable`.
It's the latest, and matches the rest of the host we're running on. But
also, pulling f30 is hitting 503s from the Fedora registry:
https://pagure.io/releng/issue/9282
We're hitting issues with packages getting tagged out of the pool:
https://pagure.io/releng/issue/9281
This in turn means we can't reliably recompose older builds right now,
which breaks our CI. For now at least, let's compose from the latest.
(Note we were already also composing the latest FCOS in the vmcheck
branch.)
Instead of basing our decision to use the local `/etc` on whether we're
using `dracut --rebuild`, base it directly on a boolean parameter.
This is relevant in the client-side when initramfs regeneration is
requested as well as a kernel override. In such cases, we do want to use
the local `/etc`, but we'd skip that path because we didn't also use
`dracut --rebuild`.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1806588
We don't support `/etc/dnf/dnf.conf`, so tell libdnf to not look for it.
This squashes warnings from libdnf (which turn into hard errors when
hacking locally with `G_DEBUG=fatal-warnings`).
As mentioned in the comment, the reason for putting this in `main.c` is
that it controls a global variable, which is used in a few places in
libdnf. So rather than duplicating this across callsites, just set it
upfront. And yeah... we should improve that API.
Doing builddep once based on the baked config and then once more from
the spec file can cause issues sometimes. For example, right now the
latest rpm-ostree release uses libmodulemd1, but we want to rebase to
libmodulemd (2.0). And `dnf` will get confused trying to move from one
to the other.
Really, we don't need to builddep from the last release at all, so just
drop that and rely only on the spec file.
Adapt `pkg_install_builddeps` to allow no args to mean only installing
the basic buildroot stuff like `dnf builddep` and `@buildsys-build`.
We need `cargo` in our `PATH` and we already do the `PATH=...` dance in
`ci/msrv.sh`. This only worked before because we were inadvertedly
re-installing cargo when calling `ci/build.sh`, which was fixed in the
previous commit.
We've already manually installed dependencies higher up. This saves us
some time, but also we don't want the script to e.g. re-install cargo.
(This also works as a short term hack we need to adapt to libdnf moving
to `libmodulemd-2.0` due to `ci/installdeps.sh` not being entirely
idempotent).
