Publish RPMs on Fedora COPR?

[christophehenry]

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?

[binwiederhier]

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

[christophehenry]

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?

[Conan-Kudo]

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

[christophehenry]

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

[binwiederhier]

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]

Related: goreleaser/goreleaser#3136

[Conan-Kudo]

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).

[binwiederhier]

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.

[cyqsimon]

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.

[binwiederhier]

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.

[cyqsimon]

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:

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) 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?

[binwiederhier]

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.

[cyqsimon]

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.

[binwiederhier]

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

[christophehenry]

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

Already? Damn, time passes 🤔