[bodhi-updates] manifest: drop fedora-coreos-pool repo #335
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So... one thing I just realized is that now that we have a bunch of f32 packages in the pool, we really can't have `bodhi-updates` picking up packages from there unlocked. So this is sort of forcing our hand to get coreos/fedora-coreos-tracker#293 fixed very soon so that we can unblock package bumps again. As a first step and to prevent `testing-devel` ending up with a bunch of f32 packages, let's remove the pool from the list of repos here.
|
And ahhh yup, bodhi-updates is failing now. The reason is that the python-less crypto-policies only exists in f32 and we have an One thing we could do is have an FCOS-only f31 version of that crypto-policies package with the Python-less patch backported. (That's probably what we would've done anyway instead of pulling in the f32 version directly if it had other changes incompatible with f31). Another approach is enhancing lockfiles to allow cherry-picking only some packages from a specific repo. Or maybe... once we have coreos/fedora-coreos-tracker#293, we could just get rid of Anyway, we can keep discussing this, but for now I'm just going to merge this to prevent |
|
with coreos/rpm-ostree#1847 we should just be able to link directly to koji urls for packages as a short term workaround for this. |
jlebon
added a commit
to jlebon/fedora-coreos-pipeline
that referenced
this pull request
Apr 9, 2020
There's more work needed before we can unblock those. For background, on bodhi-updates, see: coreos/fedora-coreos-config#335 (comment) For the next-devel stream, see: coreos/fedora-coreos-tracker#283 (comment)
jlebon
added a commit
to jlebon/fedora-coreos-pipeline
that referenced
this pull request
Apr 9, 2020
There's more work needed before we can unblock those. For background, on bodhi-updates, see: coreos/fedora-coreos-config#335 (comment) For the next-devel stream, see: coreos/fedora-coreos-tracker#283 (comment)
jlebon
added a commit
to coreos/fedora-coreos-pipeline
that referenced
this pull request
Apr 9, 2020
There's more work needed before we can unblock those. For background, on bodhi-updates, see: coreos/fedora-coreos-config#335 (comment) For the next-devel stream, see: coreos/fedora-coreos-tracker#283 (comment)
jlebon
added a commit
to jlebon/fedora-coreos-releng-automation
that referenced
this pull request
Apr 14, 2020
bodhi-updates is down, so disable lockfile syncing so we don't override manual lockfile bumps we will do for now. coreos/fedora-coreos-config#335 (comment)
jlebon
added a commit
to jlebon/coreos-assembler
that referenced
this pull request
Apr 22, 2020
I'm working on a lockfile updater[1], and I'd like it to just be able to do `cosa fetch --update-lockfile` the same way a human would. This normally would run `rpm-ostree compose tree` without passing any lockfiles and blocking out the pool so that all packages come from the base repo. Sadly, that doesn't currently work for FCOS right now we have an override for crypto-policies from f32 so that we don't pull in Python, and also have an `exclude-packages` for Python. Which means that without the f32 crypto-policies, we can't get a depsolve from just the base f31 repos. (This is the same issue that killed bodhi-updates[2].) As a short-term hack, just include the overrides for now. This dillutes the meaning of a "base" lockfile of course, because it will now will include the same packages as the overrides. We can drop this hack once we move to f32, though I have some ideas too on how to solve this more correctly. [1] coreos/fedora-coreos-tracker#293 [2] coreos/fedora-coreos-config#335 (comment)
jlebon
added a commit
to jlebon/coreos-assembler
that referenced
this pull request
Apr 22, 2020
I'm working on a lockfile updater[1], and I'd like it to just be able to do `cosa fetch --update-lockfile` the same way a human would. This normally would run `rpm-ostree compose tree` without passing any lockfiles and blocking out the pool so that all packages come from the base repo. Sadly, that doesn't currently work for FCOS right now because we have an override for crypto-policies from f32 so that we don't pull in Python. And because we also have an `exclude-packages` for Python, without the f32 crypto-policies, we can't get a depsolve from just the base f31 repos. (This is the same issue that killed bodhi-updates[2].) As a short-term hack, just include the overrides for now. This dillutes the meaning of a "base" lockfile of course, because it will now will include the same packages as the overrides. We can drop this hack once we move to f32, though I have some ideas too on how to solve this more correctly. [1] coreos/fedora-coreos-tracker#293 [2] coreos/fedora-coreos-config#335 (comment)
jlebon
added a commit
to jlebon/coreos-assembler
that referenced
this pull request
Apr 22, 2020
I'm working on a lockfile updater[1], and I'd like it to just be able to do `cosa fetch --update-lockfile` the same way a human would. This normally would run `rpm-ostree compose tree` without passing any lockfiles and blocking out the pool so that all packages come from the base repo. Sadly, that doesn't currently work for FCOS right now because we have an override for crypto-policies from f32 so that we don't pull in Python. And because we also have an `exclude-packages` for Python, without the f32 crypto-policies, we can't get a depsolve from just the base f31 repos. (This is the same issue that killed bodhi-updates[2].) As a short-term hack, just include the overrides for now. This dillutes the meaning of a "base" lockfile of course, because it will now include the packages from the overrides. I don't think this really matters for now though (it does make the checking for whether overrides are still needed harder, but I'd like to automate dropping overrides eventually too). Anyway, we can drop this hack once we move to f32, though I have some ideas too on how to solve this more correctly. [1] coreos/fedora-coreos-tracker#293 [2] coreos/fedora-coreos-config#335 (comment)
openshift-merge-robot
pushed a commit
to coreos/coreos-assembler
that referenced
this pull request
Apr 23, 2020
I'm working on a lockfile updater[1], and I'd like it to just be able to do `cosa fetch --update-lockfile` the same way a human would. This normally would run `rpm-ostree compose tree` without passing any lockfiles and blocking out the pool so that all packages come from the base repo. Sadly, that doesn't currently work for FCOS right now because we have an override for crypto-policies from f32 so that we don't pull in Python. And because we also have an `exclude-packages` for Python, without the f32 crypto-policies, we can't get a depsolve from just the base f31 repos. (This is the same issue that killed bodhi-updates[2].) As a short-term hack, just include the overrides for now. This dillutes the meaning of a "base" lockfile of course, because it will now include the packages from the overrides. I don't think this really matters for now though (it does make the checking for whether overrides are still needed harder, but I'd like to automate dropping overrides eventually too). Anyway, we can drop this hack once we move to f32, though I have some ideas too on how to solve this more correctly. [1] coreos/fedora-coreos-tracker#293 [2] coreos/fedora-coreos-config#335 (comment)
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this pull request
Apr 30, 2020
With coreos#355, the pool is now used for fetching lockfiles only. This broke multi-arch builds though because although there are no lockfiles there and it's currently not possible to get a depsolve without at least locking crypto-policies: coreos#335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix multi-arch builds.
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this pull request
Apr 30, 2020
With coreos#355, the pool is now used for fetching lockfiles only. This however broke multi-arch builds because although there are no lockfiles there and it's currently not possible to get a depsolve without at least locking crypto-policies: coreos#335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix multi-arch builds.
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this pull request
Apr 30, 2020
With coreos#355, the pool is now used for fetching lockfiles only. This however broke multi-arch builds because although there are no lockfiles, it's currently not possible to get a depsolve without at least locking crypto-policies: coreos#335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix multi-arch builds.
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this pull request
Apr 30, 2020
With coreos#355, the pool is now used for fetching lockfiles only. This however broke multi-arch builds because although there are no lockfiles, it's currently not possible to get a depsolve without at least locking crypto-policies: coreos#335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix builds there.
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this pull request
May 1, 2020
With coreos#355, the pool is now used for fetching lockfiles only. This however broke multi-arch builds because although there are no lockfiles, it's currently not possible to get a depsolve without at least locking crypto-policies: coreos#335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix builds there.
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this pull request
May 1, 2020
With coreos#355, the pool is now used for fetching lockfiles only. This however broke multi-arch builds because although there are no lockfiles, it's currently not possible to get a depsolve without at least locking crypto-policies: coreos#335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix builds there.
jlebon
added a commit
that referenced
this pull request
May 1, 2020
With #355, the pool is now used for fetching lockfiles only. This however broke multi-arch builds because although there are no lockfiles, it's currently not possible to get a depsolve without at least locking crypto-policies: #335 (comment) While we can't yet maintain base lockfiles for other arches, we can at least start maintaining overrides. This will also in the process fix builds there.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So... one thing I just realized is that now that we have a bunch of f32
packages in the pool, we really can't have
bodhi-updatespicking uppackages from there unlocked.
So this is sort of forcing our hand to get
coreos/fedora-coreos-tracker#293 fixed very
soon so that we can unblock package bumps again.
As a first step and to prevent
testing-develending up with a bunch off32 packages, let's remove the pool from the list of repos here.