[GH-ISSUE #369] Publish ntfy RPMs on Fedora COPR

BreizhHardware commented

2026-05-07 00:22:36 +02:00

Owner

Originally created by @christophehenry on GitHub (Jul 24, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/369

The RPM package is provided — which is nice — but only through manual download which doesn't allow to follow update. Would you consider publishing it on COPR too, and then, maybe Fedora's official repositories?

Originally created by @christophehenry on GitHub (Jul 24, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/369 The RPM package is provided — which is nice — but only through manual download which doesn't allow to follow update. Would you consider publishing it [on COPR](https://copr.fedorainfracloud.org/) too, and then, maybe Fedora's official repositories?

BreizhHardware

2026-05-07 00:22:36 +02:00

closed this issue
added the
build

enhancement
labels

BreizhHardware commented

2026-05-07 00:22:37 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jul 26, 2022):

I have no idea how to do that, but of course I'd consider it. Maybe @Conan-Kudo can help?

@binwiederhier commented on GitHub (Jul 26, 2022): I have no idea how to do that, but of course I'd consider it. Maybe @Conan-Kudo can help?

BreizhHardware commented

2026-05-07 00:22:37 +02:00

Author

Owner

@christophehenry commented on GitHub (Jul 27, 2022):

You can find the documentation here. There is even a section on how to automatically build the package on COPR via GH webhooks. But I couldn't find the spec file in this repo. Is it auto-generated?

@christophehenry commented on GitHub (Jul 27, 2022): You [can find the documentation here](https://docs.pagure.org/copr.copr/user_documentation.html#quick-start). There is even a section on [how to automatically build the package on COPR via GH webhooks](https://docs.pagure.org/copr.copr/user_documentation.html#github-webhooks). But I couldn't find the spec file in this repo. Is it auto-generated?

BreizhHardware commented

2026-05-07 00:22:37 +02:00

Author

Owner

@Conan-Kudo commented on GitHub (Jul 27, 2022):

There is no spec file at this time. It would have to be contributed.

@Conan-Kudo commented on GitHub (Jul 27, 2022): There is no spec file at this time. It would have to be contributed.

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@christophehenry commented on GitHub (Jul 27, 2022):

Then how do you generate the RPM package without a .spec ?

@christophehenry commented on GitHub (Jul 27, 2022): Then how do you generate the RPM package without a `.spec` ?

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jul 27, 2022):

The entire build process is driven by goreleaser, which has packaging abilities. It's fantastic! There are various hooks, but I have no idea if a spec file is absolutely necessary.

@binwiederhier commented on GitHub (Jul 27, 2022): The entire build process is driven by [goreleaser](https://goreleaser.com/), which has [packaging abilities](https://goreleaser.com/customization/nfpm/). It's fantastic! There are various hooks, but I have no idea if a spec file is absolutely necessary.

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jul 27, 2022):

@binwiederhier commented on GitHub (Jul 27, 2022): Related: https://github.com/goreleaser/goreleaser/issues/3136

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@Conan-Kudo commented on GitHub (Jul 27, 2022):

goreleaser works by taking the artifact built and using a trivial spec to wrap the binary in a package. It's not a true package build process where the build process is entirely orchestrated from the spec file (which is what COPR generally expects).

@Conan-Kudo commented on GitHub (Jul 27, 2022): goreleaser works by taking the artifact built and using a trivial spec to wrap the binary in a package. It's not a true package build process where the build process is entirely orchestrated from the spec file (which is what COPR generally expects).

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@binwiederhier commented on GitHub (Nov 19, 2022):

Is this it?

I think @cyqsimon did it for us. I'm happy to somehow embed this into the repo if it is desired.

@binwiederhier commented on GitHub (Nov 19, 2022): Is this it? - https://copr.fedorainfracloud.org/coprs/cyqsimon/ntfysh/ - https://github.com/cyqsimon/ntfysh-spec I think @cyqsimon did it for us. I'm happy to somehow embed this into the repo if it is desired.

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@cyqsimon commented on GitHub (Nov 19, 2022):

Thanks for pinging me.

First of all, if anyone wants a continuously-updated build on Redhat distros right now, go ahead and use my COPR repo. Currently the builds are triggered manually, but I have set up notification using newreleases.io. So it's usually updated within a day or two of a Github release.

As of moving the SPEC file into tree, I'm all for it. If properly done, it's going to be a cleaner solution and more automated.

That being said, it might take a bit more work than you might expect. Right now the SPEC file is hand-written and manually updated, but if you want to do it "properly" (which I assume everyone here would prefer), you would use tito. See tutorial. Frankly I am not familiar with this tool at all, so either I have to take some time to study and investigate, or someone more proficient than me can volunteer. In addition, whoever ends up doing this also needs to figure out the best way to integrate this stuff with CICD. It's not difficult, just extremely tedious.

And finally some project-specific problems: if you look at my current SPEC file, you'll see that tests are disabled because a few were erroring. Less than 5 if I recall correctly, but errors nonetheless. For some unknown reasons, these errors only happen when building on COPR, so currently what I do is I manually run the tests in VMs for each release. If we completely automate the whole COPR build process using tito, we definitely should figure out what's going on and actually fix the tests. I actually know very little about programming in Go (Rust is better; change my mind 😜), so I wouldn't be very helpful here, sorry ¯\_(ツ)_/¯.

Anyways, my point is that it's a lot of work for relatively little gain. If any of you want to give it a shot, feel free to go ahead; for this purpose you have my permission to use cyqsimon/ntfysh-spec under MIT. On the other hand, if you just want something right now, go use my COPR repo. I'm committed to keep it up to date in the foreseeable future, unless I die in a car accident or something.

@cyqsimon commented on GitHub (Nov 19, 2022): Thanks for pinging me. First of all, if anyone wants a continuously-updated build on Redhat distros **right now,** go ahead and use my COPR repo. Currently the builds are triggered manually, but I have set up notification using [newreleases.io](https://newreleases.io/). So it's usually updated within a day or two of a Github release. As of moving the SPEC file into tree, I'm all for it. If properly done, it's going to be a cleaner solution and more automated. That being said, it might take a bit more work than you might expect. Right now the SPEC file is hand-written and manually updated, but if you want to do it "properly" (which I assume everyone here would prefer), you would use tito. See [tutorial](https://docs.fedoraproject.org/en-US/quick-docs/publish-rpm-on-copr/). Frankly I am not familiar with this tool at all, so either I have to take some time to study and investigate, or someone more proficient than me can volunteer. In addition, whoever ends up doing this also needs to figure out the best way to integrate this stuff with CICD. It's not difficult, just extremely tedious. And finally some project-specific problems: if you look at my current SPEC file, you'll see that tests are disabled because a few were erroring. Less than 5 if I recall correctly, but errors nonetheless. For some unknown reasons, these errors only happen when building on COPR, so currently what I do is I manually run the tests in VMs for each release. If we completely automate the whole COPR build process using tito, we definitely should figure out what's going on and actually fix the tests. I actually know very little about programming in Go (Rust is better; change my mind 😜), so I wouldn't be very helpful here, sorry ¯\\\_(ツ)\_/¯. Anyways, my point is that it's a lot of work for relatively little gain. If any of you want to give it a shot, feel free to go ahead; for this purpose you have my permission to use [cyqsimon/ntfysh-spec](https://github.com/cyqsimon/ntfysh-spec) under MIT. On the other hand, if you just want something right now, go use my COPR repo. I'm committed to keep it up to date in the foreseeable future, unless I die in a car accident or something.

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@binwiederhier commented on GitHub (Nov 20, 2022):

Thank you for the detailed answer. I looked at the spec file and I have no problem including it in-tree, but I see your point about automating it. Introducing another tool, on the other hand, is annoying and probably over the top for this tiny spec file.

I can't really maintain it myself, because I don't use it and won't know if it's broken or not.

That leaves us with these options:

Option 0: Leave spec file in your repo and as is. Maybe add a section in the "install" docs to link to it.

Option 1: Move spec file in-tree, but continue to manually update it. That way it's "official" in a sense, but @cyqsimon would have to create PRs to update it, which is quite annoying I'm sure. Maybe I could write some tooling to semi-automate the changelog and such.

Option 2: Move spec file in-tree and do the thing with tito.

I have no big stake in the spec file or COPR myself, so I don't really care either way. I think at the very least we should add some install instructions, though.

@binwiederhier commented on GitHub (Nov 20, 2022): Thank you for the detailed answer. I looked at the spec file and I have no problem including it in-tree, but I see your point about automating it. Introducing another tool, on the other hand, is annoying and probably over the top for this tiny spec file. I can't really maintain it myself, because I don't use it and won't know if it's broken or not. That leaves us with these options: Option 0: Leave spec file in your repo and as is. Maybe add a section in the "install" docs to link to it. Option 1: Move spec file in-tree, but continue to manually update it. That way it's "official" in a sense, but @cyqsimon would have to create PRs to update it, which is quite annoying I'm sure. Maybe I could write some tooling to semi-automate the changelog and such. Option 2: Move spec file in-tree and do the thing with `tito`. I have no big stake in the spec file or COPR myself, so I don't really care either way. I think at the very least we should add some install instructions, though.

BreizhHardware commented

2026-05-07 00:22:38 +02:00

Author

Owner

@cyqsimon commented on GitHub (Nov 20, 2022):

So I did some investigating regarding alternate ways to automate the build without using tito. It turns out COPR does support generating a SPEC file using an arbitrary script. See here. That makes life much easier. So I think the best solution would be the following:

Commit a template SPEC file and its rendering script (or just a Makefile target) into tree.

The template file is mostly static (except for changelog, which is a bit tricky), and should have placeholder fields for version, commit, and release.
The rendering script should replace placeholders using Git information.

The COPR build script (COPR just gives you a big text box for it) simply clones the repo, runs the rendering script, then outputs the SPEC file.
Set up a webhook on Github (see here) to automatically issue a rebuild to COPR on new releases.

As mentioned above, the changelog is quite tricky because it's incremental (COPR actually mandates dates too, otherwise build would fail), and thus presumably requires direct modification of the template file itself. Do you have any ideas on a workflow that would ensure it's up to date?

@cyqsimon commented on GitHub (Nov 20, 2022): So I did some investigating regarding alternate ways to automate the build without using tito. It turns out COPR does support generating a SPEC file using an arbitrary script. See [here](https://docs.pagure.org/copr.copr/custom_source_method.html). That makes life much easier. So I think the best solution would be the following: 1. Commit a template SPEC file and its rendering script (or just a Makefile target) into tree. - The template file is mostly static (except for `changelog`, which is a bit tricky), and should have placeholder fields for `version`, `commit`, and `release`. - The rendering script should replace placeholders using Git information. 2. The COPR build script (COPR just gives you a big text box for it) simply clones the repo, runs the rendering script, then outputs the SPEC file. 3. Set up a webhook on Github (see [here](https://docs.pagure.org/copr.copr/user_documentation.html#github-webhooks)) to automatically issue a rebuild to COPR on new releases. As mentioned above, the changelog is quite tricky because it's incremental (COPR actually mandates dates too, otherwise build would fail), and thus presumably requires direct modification of the template file itself. Do you have any ideas on a workflow that would ensure it's up to date?

BreizhHardware commented

2026-05-07 00:22:39 +02:00

Author

Owner

@binwiederhier commented on GitHub (Nov 24, 2022):

Do you have any ideas on a workflow that would ensure it's up to date?

I maintain a changelog in the releases.md file, but that is manually updated and contains markdown. The only (bad) option I see is to generate the spec changelog from that, which would involve stripping of markdown, and a somewhat structured releases.md file. I don't like it.

I already do "double-changelogging" for Android (F-Droid), and I don't really want to add another one. Though I suppose if this is the only blocker, I could manually update it ... So if you do the PR and it involves manually updating the changelog, I'll be ok with that.

@binwiederhier commented on GitHub (Nov 24, 2022): > Do you have any ideas on a workflow that would ensure it's up to date? I maintain a changelog in the [releases.md](https://github.com/binwiederhier/ntfy/blob/main/docs/releases.md) file, but that is manually updated and contains markdown. The only (bad) option I see is to generate the spec changelog from that, which would involve stripping of markdown, and a somewhat structured releases.md file. I don't like it. I already do "double-changelogging" for Android (F-Droid), and I don't really want to add another one. Though I suppose if this is the only blocker, I could manually update it ... So if you do the PR and it involves manually updating the changelog, I'll be ok with that.

BreizhHardware commented

2026-05-07 00:22:39 +02:00

Author

Owner

@cyqsimon commented on GitHub (Nov 24, 2022):

So if you do the PR and it involves manually updating the changelog, I'll be ok with that.

Sounds good. Honestly, for the SPEC file changelog, the following would suffice:

* Thu Nov 24 2022 USER <user@example.org> - 1.2.3-1
- Release 1.2.3
- See <link to changelog on Github>

COPR doesn't really care what's in your changelog, as long as there exists an entry with the correct format and matching version and release number.

I'll try to find time to put together a PR, but honestly I'm looking at a really busy week ahead, so I might not have enough time.

@cyqsimon commented on GitHub (Nov 24, 2022): > So if you do the PR and it involves manually updating the changelog, I'll be ok with that. Sounds good. Honestly, for the SPEC file changelog, the following would suffice: ``` * Thu Nov 24 2022 USER <user@example.org> - 1.2.3-1 - Release 1.2.3 - See <link to changelog on Github> ``` COPR doesn't really care what's in your changelog, as long as there exists an entry with the correct format and matching version and release number. I'll try to find time to put together a PR, but honestly I'm looking at a really busy week ahead, so I might not have enough time.

BreizhHardware commented

2026-05-07 00:22:39 +02:00

Author

Owner

@binwiederhier commented on GitHub (Nov 24, 2022):

Honestly, for the SPEC file changelog, the following would suffice:

Even easier. That can totally be generated.

I'll try to find time to put together a PR, but honestly I'm looking at a really busy week ahead, so I might not have enough time.

No rush. The ticket is half a year old. :-D

@binwiederhier commented on GitHub (Nov 24, 2022): > Honestly, for the SPEC file changelog, the following would suffice: Even easier. That can totally be generated. > I'll try to find time to put together a PR, but honestly I'm looking at a really busy week ahead, so I might not have enough time. No rush. The ticket is half a year old. :-D

BreizhHardware commented

2026-05-07 00:22:39 +02:00

Author

Owner

@christophehenry commented on GitHub (Nov 24, 2022):

No rush. The ticket is half a year old. :-D

Already? Damn, time passes 🤔

@christophehenry commented on GitHub (Nov 24, 2022): > No rush. The ticket is half a year old. :-D Already? Damn, time passes :thinking:

BreizhHardware commented

2026-05-07 00:22:39 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 2, 2026):

This ticket is over 3 years old now. I'll close it, but I am happy to re-open if there is still interest and there is a path forward on how to do this.

@binwiederhier commented on GitHub (Feb 2, 2026): This ticket is over 3 years old now. I'll close it, but I am happy to re-open if there is still interest and there is a path forward on how to do this.

BreizhHardware commented

2026-05-07 00:22:39 +02:00

Author

Owner

@cyqsimon commented on GitHub (Feb 5, 2026):

Yeah sorry. Too many commitments and not enough time. Ain't that a problem for us all 😅

If anyone wants to take on this, you have my explicit permission to relicense everything in https://github.com/cyqsimon/ntfysh-spec to whatever license this project sees fit. (Not that it really matters in this new age of "copyright infringement is legal as long as it's an AI doing it" but whatever)

@cyqsimon commented on GitHub (Feb 5, 2026): Yeah sorry. Too many commitments and not enough time. Ain't that a problem for us all 😅 If anyone wants to take on this, you have my explicit permission to relicense everything in https://github.com/cyqsimon/ntfysh-spec to whatever license this project sees fit. (Not that it really matters in this new age of "copyright infringement is legal as long as it's an AI doing it" but whatever)

Rows
Columns

[GH-ISSUE #369] Publish ntfy RPMs on Fedora COPR #283