Use --repo={fedora,updates}{,-source} --releasever XX --latest=1
instead of --repo=rawhide{,-source}
for older releases.
XXX: what does --latest=1
mean?
Always use the package name for this, not a virtual provide.
Note that the --recursive
flag might give an enormous list of packages (e.g. for python3-setuptools), so feel free to not always use it.
RE: https://github.com/fedora-python/pull-request-review-guide/blob/main/fedora-pr-review-guide.md#impact-check–-when-to-do-it
This is a big hack to find any build or runtime dependencies such as BuildRequires: foo < 4
or Requires: foo < 4
. It gets all requirements of your package and greps them for <
(packages with an upper limit to the version). Note that the '\bfoo\b'
regex will not work correctly for your package (unless named foo). The idea is to grep for all requires of your package, so it must match both python3-foo
and python3.Xdist(foo)
etc. Replace it with a regex that fits your use case. False matches are not that bad, unless there is too many of them, so the regex does not usually need to be very specific.
Does not reveal affected package names, but can be used for a quick check to see if the slow check is even neccessary
(Reminder: Use --repo={fedora,updates}{,-source} --releasever XX --latest=1
instead of --repo=rawhide{,-source}
for older releases.)
Runs potentially many repoqueries in a loop, so it's slow, but shows affected packages, if any
(Reminder: Use --repo={fedora,updates}{,-source} --releasever XX --latest=1
instead of --repo=rawhide{,-source}
for older releases.)
Push the updated package to your fork on https://src.fedoraproject.org and run the following.
For older releases:
If you don't want to push to your fork yet, instead do:
Wait for the build to finish and succeed.
See also https://docs.pagure.org/copr.copr/user_documentation.html#mass-rebuilds
Using parallel
from the moreutils-parallel
package.
For older releases:
For older releases:
(If you get more than is easy to inspect manually, you better resubmit those to the new copr in case it was a transient issue.)
Sometimes, copr replies with:
And a build might have been skipped. Especially with a large dep-list, it's hard to check manually what package was not submitted. You can use:
Copr has a functionality called directories.
tl;dr Builds are by default built in the directory named after the copr project. However, builds can be submitted to be built in a different directory. Directories other than the default don't create DNF repositories and hence "don't see each other". When you use this feature packages won't fail to build just because you built something in your copr that was not yet built in Fedora proper.
For example: A package maintainer committed an update of python-itsdangerous to version 6.6.6 to Fedora dist-git. But they have not built it yet in Fedora, for whatever reason. You are performing an impact check for an update of python-setuptools. Once you build python-itsdangerous 6.6.6 in your copr (as it requires setuptools), other packages in your copr that depend on itsdangerous might start to fail, but not because of setuptools update, but because of itsdangerous update. Following the steps bellow will spare you from this unfortunate situation.
Follow the normal impact check guide with the following modifications (both for the impact check copr and the control copr):
$COPR:custom:isolated
as the copr name. This is the directory name and all packages can share the same one, as builds in directories other than the default don't have a DNF repository attached to them. (We've been asked to use whatever name we want as long as it is prefixed by $COPR:custom:
, $COPR:custom:isolated
is just what Miro uses, it works the same with $COPR:custom:platypus
or $COPR:custom:666
.)copr monitor
add --dir $COPR:custom:isolated
. Note that if $COPR
contains an owner (such as @python/wheel-0.40
or churchyard/setuptools-85
), the --dir
argument must be without it – e.g. copr monitor @python/wheel-0.40 --dir wheel-0.40:custom:isolated ...
.