Skip to content

Conversation

@bkmgit
Copy link
Contributor

@bkmgit bkmgit commented Jun 5, 2025

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
Copy link
Owner

vkbo commented Jun 5, 2025

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
Copy link
Owner

vkbo commented Jun 5, 2025

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

@bkmgit
Copy link
Contributor Author

bkmgit commented Jun 5, 2025

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
Copy link
Contributor Author

bkmgit commented Jun 5, 2025

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

@vkbo
Copy link
Owner

vkbo commented Jun 5, 2025

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
Copy link
Contributor Author

bkmgit commented Jun 5, 2025

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
Copy link
Contributor Author

bkmgit commented Jun 9, 2025

An example:
stephenberry/glaze#1795 (comment)

There are several configuration options for notifications and build triggers.

@vkbo
Copy link
Owner

vkbo commented Jun 9, 2025

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

@vkbo
Copy link
Owner

vkbo commented Jun 13, 2025

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
Copy link
Owner

vkbo commented Jun 13, 2025

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
Copy link
Contributor Author

bkmgit commented Jun 20, 2025

Thanks for the feedback. Will make the changes.

@vkbo
Copy link
Owner

vkbo commented Jun 21, 2025

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
Copy link
Contributor Author

bkmgit commented Jul 5, 2025

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
Copy link
Owner

vkbo commented Jul 5, 2025

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
Copy link
Owner

vkbo commented Jul 5, 2025

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