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
Introduce packit support #6649
Introduce packit support #6649
Conversation
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 can see the SRPM build failed due to infra problem - I'll investigate tomorrow what the problem was.
# add or remove files that should be synced | ||
synced_files: | ||
- scap-security-guide.spec | ||
- .packit.yaml |
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.
these are actually defaults, so you can drop these 4 lines if you want
downstream_package_name: scap-security-guide | ||
|
||
actions: | ||
post-upstream-clone: "wget https://src.fedoraproject.org/rpms/scap-security-guide/raw/rawhide/f/scap-security-guide.spec -O scap-security-guide.spec" |
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.
happy to see this! I hope that you don't change dependencies often so that you don't run into "I need to fix the spec in downstream in order to have passing builds in the upstream"
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 won't be a problem here - required dependencies don't change often.
/retest |
okay, I can see the problem now, we failed to pull image from docker.io due to quota; sorry about that |
/packit build |
I can see the RPM failed to be built due to cmake - is there some special way to create archives or doing |
@TomasTomecek Only the F32 build fails. For some reason it tries to use the Rawhide spec file on F32. Do you have any ideas why it didn't use the F32 spec file on F32? |
Aha I can see what can be the problem, it's in the pull request description:
You can't use the Rawhide spec file to build RPM on F32 because we use CMake and the RPM macro If you are curious you can read details about this F33 change: https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds @matejak Please change your "setup" so that a correct spec according to the Fedora version is used. |
That's not a bug, it's a feature - the point is to use the Rawhide spec file for everything. You are right that it doesn't work for Fedora 32, and it also doesn't work for RHEL8 due to the cmake build issue as well, but it will work for anything newer than Fedora 33 and derived. @TomasTomecek could you please suggest the most elegant way how to disable Packit builds for F32? |
I think that maybe you can add an if else construction that depend on the system version to the rawhide spec |
I don't think that a product that will be EOLed in two months deserves to have an |
The easiest solution is to configure
we also have aliases for development and stable versions of Fedora Linux: https://packit.dev/docs/configuration/#available-copr-build-targets Let me know if this is acceptable for you. |
.packit.yaml
Outdated
post-upstream-clone: "wget https://src.fedoraproject.org/rpms/scap-security-guide/raw/rawhide/f/scap-security-guide.spec -O scap-security-guide.spec" | ||
|
||
|
||
# TODO: Remove the "jobs" key as soon as F34 is out |
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.
My understanding was that this key disables F32 builds so I would say that it should be disabled after F32 is removed from the infrastructure. Am I correct or are you correct?
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.
Also, is F33 under fedora-development?
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 think that both of us are correct - when F34 is released, F32 will disappear, and we can return to default jobs.
F33 is clearly not a development version, as you can see when you check out test results. I have tried to avoid mentioning explicit version numbers, so things work even if nobody removes the jobs
key.
@matejak: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
@matejak Any updates? |
I would say that it simply works, so we can merge it. If we wait until the F34 release, we can simplify the config even further. |
@matejak Fedora 34 was released in April |
The setup uses the Rawhide spec file to create an srpm.
Time flies, it's actually really F35 which is around the corner |
And it doesn't work because of patches in the Fedora spec file, so let's close the PR. |
Packit enables integration with downstream Fedora packaging, and potentially with packaging of derived systems.
The setup uses the Rawhide spec file to create the srpm, so the upstream project doesn't require any adjustments.