Skip to content

Enable builds on Fedora CI#2383

Draft
bkmgit wants to merge 1 commit into
vkbo:mainfrom
bkmgit:packit
Draft

Enable builds on Fedora CI#2383
bkmgit wants to merge 1 commit into
vkbo:mainfrom
bkmgit:packit

Conversation

@bkmgit

@bkmgit bkmgit commented Jun 5, 2025

Copy link
Copy Markdown
Contributor

Summary:

Additional tests that will make distributing RPMs easier.

To get it to work, someone with commit access will need to agree to make a Fedora account at:
https://accounts.fedoraproject.org/

and agree to Fedora Code of Conduct, then follow the steps at:

http://packit.dev/docs/guide#1-set-up-packit-integration

Related Issue(s):

Closes #2372

Reviewer's Checklist:

  • The header of all files contain a reference to the repository license
  • The overall test coverage is increased or remains the same as before
  • All tests are passing
  • All linting checks are passing and the style guide is followed
  • Documentation (as docstrings) is complete and understandable
  • Only files that have been actively changed are committed

@vkbo

vkbo commented Jun 5, 2025

Copy link
Copy Markdown
Owner

Thanks! I'll have a look at it.

How does it work? Will the service poll the repo for changes, or does it need a hook?

@vkbo vkbo added the packaging Component: Packaging and installing label Jun 5, 2025
@vkbo

vkbo commented Jun 5, 2025

Copy link
Copy Markdown
Owner

I also see there is a version number set in the spec file. Does that need to be updated?

@bkmgit

bkmgit commented Jun 5, 2025

Copy link
Copy Markdown
Contributor Author

The service will run on every commit, bot is activated for this.

Version number should be updated, maybe worth adding something in pkgutils.py
or creating a utils/build_fedora.py

At the moment, doing release builds separately.

@bkmgit

bkmgit commented Jun 5, 2025

Copy link
Copy Markdown
Contributor Author

It will run with the current version number. Can perhaps decide on how to update it for
the next release.

@vkbo

vkbo commented Jun 5, 2025

Copy link
Copy Markdown
Owner

It will run with the current version number. Can perhaps decide on how to update it for the next release.

Well, the main branch is on the next release cycle for 2.8 now.

@vkbo vkbo removed the packaging Component: Packaging and installing label Jun 5, 2025
@bkmgit

bkmgit commented Jun 5, 2025

Copy link
Copy Markdown
Contributor Author

The Debian packaging changelog is updated at:
https://github.com/vkbo/novelWriter/blob/main/utils/build_debian.py#L108

Maybe it is worth doing something similar in a file utils/build_fedora.py which is run when creating a new release?

From https://github.com/vkbo/novelWriter/blob/main/novelwriter/__init__.py#L52 the current version is 2.8a0 so
would want to automate updating the version in the spec file whenever that line is changed.

@bkmgit

bkmgit commented Jun 9, 2025

Copy link
Copy Markdown
Contributor Author

An example:
stephenberry/glaze#1795 (comment)

There are several configuration options for notifications and build triggers.

@vkbo

vkbo commented Jun 9, 2025

Copy link
Copy Markdown
Owner

Sure, I'll get to this. I'm trying to resolve issues with the AppImage build at the moment.

@vkbo

vkbo commented Jun 13, 2025

Copy link
Copy Markdown
Owner

The Debian packaging changelog is updated at: https://github.com/vkbo/novelWriter/blob/main/utils/build_debian.py#L108

Maybe it is worth doing something similar in a file utils/build_fedora.py which is run when creating a new release?

Sure, but the generated files are not committed, only generated on the fly when the package is built. The version number is extracted from novelwriter/__init__.py.

If an external build system is reading these, it must run that script. But if that's ok, I don't mind adding a command to pkgutils.py that can generate a fedora spec file at the root of the repo when run, which inserts all the dynamic values.

@vkbo

vkbo commented Jun 13, 2025

Copy link
Copy Markdown
Owner

As for the build pipelines, I don't like external pipelines posting to PR threads. If it can return a status in the workflow list, like codecov does, that's fine.

@bkmgit

bkmgit commented Jun 20, 2025

Copy link
Copy Markdown
Contributor Author

Thanks for the feedback. Will make the changes.

@vkbo

vkbo commented Jun 21, 2025

Copy link
Copy Markdown
Owner

I can easily make the changes to the pkgutils script to produce a spec file with the correct details. What I'm mostly wondering about is if running this script as part of the build process is possible. A chicken and egg sort of thing since the spec defines the build process?

I'm not very familiar with Fedora, so ... 😄

@bkmgit bkmgit marked this pull request as draft July 5, 2025 06:15
@bkmgit

bkmgit commented Jul 5, 2025

Copy link
Copy Markdown
Contributor Author

Will update once Remix icon license is updated as at present, these will need to be removed when packaging for Fedora.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/669#note_2604435568

@vkbo

vkbo commented Jul 5, 2025

Copy link
Copy Markdown
Owner

I replied to the thread, but I still don't see the problem as the icons are part of a larger project, which they do allow.

In any case, I see no reason to remove them from the main source, so this would have to be done by the fork. The icon themes do not exist in the 2.6.x versions of the source. They were added in 2.7.

@vkbo

vkbo commented Jul 5, 2025

Copy link
Copy Markdown
Owner

Will update once Remix icon license is updated

Not sure what you mean here ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Testing on Fedora GNU/Linux

2 participants