-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip excluded architectures #2769
Conversation
I am updating the existing tools to still run only for RPM builds, so this commit changes nothing, only allows for creating automation that can be hooked after SRPM builds.
srpm = locate_srpm(self.resultdir) | ||
hdr = get_rpm_header(srpm) | ||
keys = ["name", "exclusivearch", "excludearch"] | ||
return {key: hdr[key] for key in keys} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know we agreed on using python3-specfile
but I tried it and couldn't easily get the exclusivearch
from it so I used python3-rpm
instead. We already use it on some places, so it was trivial to use here.
IMHO there is no advantage in using one over the other, so I would just pick whatever is easiest to use. But if we really want specfile
, I can try to figure out how to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like OK for the first step at least. specfile could resolve some some issues like
%if 0%{?fedora} > 39
ExcludeEarch: x86_64
%endif
Now thinking again, are such spec files actually resolvable on the single builder that did source build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO there is no advantage in using one over the other, so I would just pick whatever is easiest to use.
With specfile
you can get ExclusiveArch
like this:
spec = Specfile(...)
with spec.tags() as tags:
try:
exclusivearch = tags.exclusivearch.value
except AttributeError:
exclusivearch = None
or (to get all of them):
spec = Specfile(...)
with spec.tags() as tags:
exclusivearches = [t.value for t in tags if t.normalized_name == "Exclusivearch"]
IMHO there is no advantage in using one over the other, so I would just pick whatever is easiest to use.
There is a difference, with specfile
you can access all tags, even those that are enclosed in conditions that would resolve to false on the system where the code is running, while rpm
gives you only resolved tags.
BTW, you can use specfile
and still access the underlying rpm.spec
object with Specfile.rpm_spec
property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I affect the conditions, to get the answer to question like "What is the ExclusiveArch value for Fedora 38+"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, expanded_value
is fine, but that doesn't answer the question; we want expanded_value
on specific distribution (e.g. RHEL 9). Can we use python-specfile for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. You can specify macros you want to be defined before every expansion (you can't delete macros loaded from macro files, but you can redefine them):
spec = Specfile("python-specfile.spec", macros=[("fedora", "39"), ("rhel", "")])
# explicitly specify parsed preamble section here, so that macros and conditions are resolved
# be aware though that if you make any changes the original section will be overwritten
with spec.tags(spec.parsed_sections.package) as tags:
try:
exclusivearch = tags.exclusivearch.expanded_value
except AttributeError:
exclusivearch = None
# for read-only access it's probably better to avoid the context manager
tags = spec.tags(spec.parsed_sections.package).content
try:
exclusivearch = tags.exclusivearch.expanded_value
except AttributeError:
exclusivearch = None
You can do the same thing with rpm
, but it would be rather cumbersome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way of working with spec files is quite revolutionary, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the code example @nforro, worked for me perfectly.
I updated the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I submitted a documentation request packit/specfile#243
I agree, and I have no problem to add it to this PR or to create a follow-up PR for it. But first, let's figure out the exclude-arch part. |
This is needed because otherwise backend can set some chroots as skipped after the SRPM build is completed but then DistGit imports the package and sets all (even the skipped) chroots as pending.
@tstellar, if the results for your package looked like this, would that be okay? |
The UI looks good, what will the json returned by the monitor API call look like? |
Like this: [
{
"build_id": 2914549,
"chroot": "fedora-37-ppc64le",
"name": "biosdevname",
"pkg_version": "0.7.3-11",
"state": "skipped"
}
,
{
"build_id": 2914549,
"chroot": "fedora-37-x86_64",
"name": "biosdevname",
"pkg_version": "0.7.3-11",
"state": "succeeded"
}
,
{
"build_id": 2914549,
"chroot": "fedora-37-aarch64",
"name": "biosdevname",
"pkg_version": "0.7.3-11",
"state": "skipped"
}
,
{
"build_id": 2914549,
"chroot": "fedora-37-s390x",
"name": "biosdevname",
"pkg_version": "0.7.3-11",
"state": "skipped"
}
,
{
"build_id": 2914549,
"chroot": "fedora-37-armhfp",
"name": "biosdevname",
"pkg_version": "0.7.3-11",
"state": "skipped"
}
] Please ignore the build ID difference from the screenshot. |
@FrostyX That looks great. Thank You! |
# PURPOSE. See the GNU General Public License for more details. | ||
# | ||
# You should have received a copy of the GNU General Public License | ||
# along with this program. If not, see http://www.gnu.org/licenses/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copyright year does not match. And the header is too long. Can you either omit it or use the two-liner from https://github.com/david-a-wheeler/spdx-tutorial#spdx-license-expressions-in-source-code-files ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
chroots+=" --chroot fedora-$FEDORA_VERSION-s390x" | ||
|
||
rlRun "copr-cli create ${NAME_PREFIX}ExclusiveArch $chroots" | ||
rlRun "copr-cli build-distgit ${NAME_PREFIX}ExclusiveArch --name biosdevname --commit $BRANCH" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this testing both excludearch and exclusivearch? It would be nice to have both tested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test was only for ExclusivAarch. I added another one for ExcludeArch
spec_path = locate_spec(self.resultdir) | ||
spec = Spec(spec_path) | ||
keys = ["name", "exclusivearch", "excludearch"] | ||
return {key: getattr(spec, key) for key in keys} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The exclusive arch is a bit different, I think it can be specified per subpackage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a tip for any package that does either of those per subpackage, please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
binutils has ExcludeArch for sub-packages, but it's hidden behind the --with crossbuilds flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lammps package also has this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
procyon package has ExclusiveArch for its sub-packages, so that should give you test cases for both ExcludeArch and ExclusiveArch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, procyon
is even more specific - that's the variant of package with BuildArch: noarch
with ExclusiveArch
for sub-packages. https://bugzilla.redhat.com/show_bug.cgi?id=1394853
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rpmbuild/copr_rpmbuild/helpers.py
Outdated
|
||
def __init__(self, path): | ||
try: | ||
macros = [("fedora", "39"), ("rhel", "")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should loop over all chroots in the future. For now, we should have macros = []
and put a TODO into the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
I finally created an issue for rpm.org, to have the macros documented for sub-packages |
Fix #2137