libsolv-0.7.17-1.fc33 failure tracker #2548
Labels
jira
for syncing to jira
Comments
|
This might somehow be specific to locally layered packages which would explain how it got by the main kola tests, which only do basic remote package sanity tests. |
|
Here is a forum post that describes a temporary fix and has some other discussion: https://discussion.fedoraproject.org/t/cannot-upgrade-silverblue/26652/5?u=nickavem |
Do you have a link to the test failures? |
|
See the CI job in #2545 |
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 8, 2021
We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to our path. (So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it.) In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 8, 2021
We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to our path. (So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it.) In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 8, 2021
We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to our path. (So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it.) In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 8, 2021
We need to make sure that we can work with newer libsolv, which changed how the rpmdb is found (see coreos#2548).
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 8, 2021
We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to /usr/lib/sysimage/rpm (which currently is a symlink to /usr/share/rpm, but eventually will become the canonical location). So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it. In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 8, 2021
…ib/sysimage/rpm We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to /usr/lib/sysimage/rpm (which currently is a symlink to /usr/share/rpm, but eventually will become the canonical location). So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it. In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
jlebon
added a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 9, 2021
…hare/rpm We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to /usr/share/rpm. So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it. In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
cgwalters
pushed a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 9, 2021
We need to make sure that we can work with newer libsolv, which changed how the rpmdb is found (see coreos#2548).
cgwalters
pushed a commit
to jlebon/rpm-ostree
that referenced
this issue
Feb 9, 2021
…hare/rpm We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to /usr/share/rpm. So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it. In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: coreos#2548
openshift-merge-robot
pushed a commit
that referenced
this issue
Feb 9, 2021
We need to make sure that we can work with newer libsolv, which changed how the rpmdb is found (see #2548).
openshift-merge-robot
pushed a commit
that referenced
this issue
Feb 9, 2021
…hare/rpm We trigger a librpm macro file load in many of our paths. Since the default value shipped by rpm's macro file sets `_dbpath` to `/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm` in those paths. This became more problematic recently with libsolv v0.7.17 which fully keys off of `_dbpath` to find the rpmdb path to load: openSUSE/libsolv@04d4d03 And it's not technically wrong; we really should make that macro not lie. This is what this patch does by injecting an RPM macro file in our composes which sets it to /usr/share/rpm. So then e.g. the `rpm` CLI doesn't actually need the `/var/lib/rpm` backcompat link anymore, though there's no harm in leaving it. In the future, we should be able to drop this once we move all of Fedora to `/usr/lib/sysimage/rpm` (see coreos/fedora-coreos-tracker#639). Closes: #2548
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have multiple issues resulting from the libsolv-0.7.17-1.fc33 update. They seem to be related to the database path. The first is fedora-silverblue/issue-tracker#124 but we fixed that with #2490
But we're still seeing some test failures and I think the root cause is
Feb 06 19:08:41 qemu0 rpm-ostree[673]: Failed to find any packages in rootwhich also leads to the segfault we're seeing at #2545The text was updated successfully, but these errors were encountered: