Enable copr builds and add packit config

[dhodovsk]

Let us introduce packit service to you - the automation to integrate upstream open source projects into Fedora operating system.

After merging this PR, you are just a few steps away from RPM builds being automatically triggered on your PR's.
It means, that you'll be able to try and play with your change, packaged as an RPM.

But there is more. By using packit, you can for example enable adding new releases into Fedora Rawhide.

What are the next steps?

• Install Packit-as-a-Service github application in your repo
• In case you are first user, wait for account approval
• Enjoy the built RPMs!

For more info, please:

• check out the documentation: https://packit.dev/docs/
• contact @packit-service

The spec you see in this PR was fetched from your package's Fedora dist-git.

[openscap-ci]

Can one of the admins verify this patch?

[redhatrises]

@openscap-ci test this please

[matejak]

The only thing I don't like about this is the .spec file - why to have it here, as it is already publicly accessible?

The packit documentation mentions that synced_files are "copied to the dist-git", but the documentation doesn't clearly say what it implies - does running packit mean that the Fedora spec file will be effectively moved from Fedora dist-git here to the upstream?

[dahaic]

Hello @dhodovsk (or should I reference @packit-service ? :) ), can you take a look at what Matej posted above?

(And thank you for proactive PR, and congrats for having item with number 5000!)

[redhatrises]

The only thing I don't like about this is the .spec file - why to have it here, as it is already publicly accessible?

The packit service handles the the Fedora workflow for you. The reason that the spec file is upstream and downstream is because in many repos that keep their spec file upstream to mininize their workload downstream (except for changelog) means that changes made downstream can be synced upstream.

The packit documentation mentions that synced_files are "copied to the dist-git", but the documentation doesn't clearly say what it implies - does running packit mean that the Fedora spec file will be effectively moved from Fedora dist-git here to the upstream?

It means that the Fedora spec file will be kept "in sync" between dist-git and repo. https://packit.dev/docs/configuration/#more-examples-of-synced-files

[dhodovsk]

@redhatrises is right :)

There is an option to use packit actions to always just get the spec from the dist-git before attempting the srpm build, so it doesn't have to be specified here. - similarly as in this example. Would you be interested in that?

[matejak]

There is an option to use packit actions to always just get the spec from the dist-git before attempting the srpm build, ...

This sounds good - having the spec file here would open the possibility of having it modified by accident or by contributors not fully aware of Fedora packaging guidelines.

[dhodovsk]

The packit config is now changed, so before every build, it fetches newest spec from dist-git, instead of storing it in repo.

[shawndwells]

The only thing I don't like about this is the .spec file - why to have it here, as it is already publicly accessible?

As stewards of open source, it's important for projects that Red Hat participates in be upstream first.

Having build files buried/hidden in downstream places only encumbers the community. There seems no downside to bringing the .spec file upstream.

The packit documentation mentions that synced_files are "copied to the dist-git", but the documentation doesn't clearly say what it implies - does running packit mean that the Fedora spec file will be effectively moved from Fedora dist-git here to the upstream?

[redhatrises]

The only thing I don't like about this is the .spec file - why to have it here, as it is already publicly accessible?

As stewards of open source, it's important for projects that Red Hat participates in be upstream first.

Having build files buried/hidden in downstream places only encumbers the community. There seems no downside to bringing the .spec file upstream.

The packit documentation mentions that synced_files are "copied to the dist-git", but the documentation doesn't clearly say what it implies - does running packit mean that the Fedora spec file will be effectively moved from Fedora dist-git here to the upstream?

Especially as there are several in the community who are actual Fedora packagers.

[matejak]

I have sent an e-mail to the mailing list, and based on the feedback, we conclude this in the first week of December.

[yuumasato]

Loved the testing RPMs per PR and the capability to propose updates to Fedora.

We used to have the .spec file in upstream. It was used to allow community to build test RPMs, when CPack came in, we removed the spec file from upstream.
One of the burdens was synchronizing and keeping it working, as in the actual dist-git.
If Packit can keep them in sync, I don't mind having it upstream.

@dhodovsk If we have the .spec in upstream and "syncing it downstream" to Fedora. Would it mean that we would have to update Changelog in upstream before release and propose-downstream?

[redhatrises]

@openscap-ci test this please

[redhatrises]

/packit copr-build

[packit-as-a-service]

Neither account redhatrises nor owner ComplianceAsCode are on our whitelist!

[redhatrises]

/packit copr-build

[redhatrises]

/packit build

[packit-as-a-service]

There was an error while creating SRPM. You can re-trigger build by adding a comment (/packit copr-build) into this pull request.

Output:

An unexpected error occurred when creating the SRPM: Command failed (rc=1, reason={"metadata":{},"status":"Failure","message":"command terminated with non-zero exit code: Error executing in Docker Container: 1","reason":"NonZeroExitCode","details":{"causes":[{"reason":"ExitCode","message":"1"}]}})
error: Bad source: ./scap-security-guide-0.1.48-xml_parsing.patch: No such file or directory

[dhodovsk]

Sorry about the super late answer, here is an example of how the spec would change after propose -> https://src.fedoraproject.org/rpms/packit/pull-request/39#request_diff

[yuumasato]

@openscap-ci test this please

[yuumasato]

/packit build

[ggbecker]

I have pushed d4dcd60 and now the builds are passing. It was failing on creating the dir build because it already existed.

[ggbecker]

@openscap-ci test this please

[ggbecker]

I have pushed d4dcd60 and now the builds are passing. It was failing on creating the dir build because it already existed.

I think I fully understood what was the problem now.
The "scap-security-guide.spec" in the official fedora builds use the tar.bz2 compressed files found under artifact releases and those are generated by running cmake .. && make package_source which in the end doesn't contain the build directory, so that's why the spec file creates it before compiling the code.

And Packit creates the compressed file by running something like: git archive --output content-v0.1.47.tar.gz --prefix content-v0.1.47 HEAD and then generates the source rpm using content-v0.1.47.tar.gz. This tar.gz file contains the build directory thus leaving us with the necessity of using mkdir -p build as in d4dcd60.

IMO, I think we should also update the spec files under fedora channels, because if in the future we update the one which is added by this PR, it will start to fail again.

[shawndwells]

Closing this as abandoned PR. Perhaps someone will want to take this on in the future.