Lyude / neovim-gtk

gtk ui for neovim
GNU General Public License v3.0
158 stars 10 forks source link

Packages for Fedora #93

Open yorickpeterse opened 1 year ago

yorickpeterse commented 1 year ago

I'm currently in the process of switching my computers over to Fedora Silverblue. Unfortunately there are no up-to-date packages for neovim-gtk for Fedora. I did find this copr repository, but it's not active.

Having an up-to-date copr repository for both stable releases and the main branch would be nice. :smile: I started creating a few of my own packages (https://copr.fedorainfracloud.org/coprs/yorickpeterse/) so I'd be happy to help where necessary. Creating a package for stable releases should be pretty easy, though I'm not sure how to best do this for every Git commit; from what I gather you'd have to use rpkg-util and put the .spec file in the source repository, as it derives data from the current repository.

yorickpeterse commented 1 year ago

I managed to cobble together two spec files: one for building stable releases, and one for building from Git main. The stable spec is as follows:

%global debug_package %{nil}

Name:    neovim-gtk
Version: 1.0.4
Release: 1%{dist}
Summary: A GTK4 UI for NeoVim, written in Rust

License: GPLv3
URL:     https://github.com/Lyude/neovim-gtk
Source:  https://github.com/Lyude/neovim-gtk/archive/refs/tags/v%{version}.tar.gz

BuildRequires: rust cargo pkgconfig(gtk4)
Requires:      neovim glib2 gtk4 pango
Conflicts:     neovim-gtk-git

%description
A GTK4 UI for NeoVim, written in Rust. Originally this project started as a fork
of daa84's neovim-gtk project. There are a very large number of improvements
from daa84's version, including lots of bugfixes, using GTK4, smooth resizing,
and more.

%files -n %{name}
%{_bindir}/nvim-gtk
%{_datadir}/*

%prep
%autosetup -n %{name}-%{version_no_tilde} -p0

%build
cargo build --release

%install
%make_install PREFIX=/usr
%{__install} -D -m644 LICENSE %{buildroot}%{_datadir}/licenses/%{name}/LICENSE
rm -f %{buildroot}/%{_prefix}/.crates.toml %{buildroot}/%{_prefix}/.crates2.json

%changelog
%autochangelog

The Git main spec is as follows:

%global debug_package %{nil}

Name:    neovim-gtk-git
Version: {{{ git_dir_version }}}
Release: 1%{dist}
Summary: A GTK4 UI for NeoVim, written in Rust

License: GPLv3
URL:     https://github.com/Lyude/neovim-gtk
VCS:     {{{ git_dir_vcs }}}
Source:  {{{ git_dir_pack }}}

BuildRequires: rust cargo pkgconfig(gtk4)
Requires:      neovim glib2 gtk4 pango
Conflicts:     neovim-gtk

%description
A GTK4 UI for NeoVim, written in Rust. Originally this project started as a fork
of daa84's neovim-gtk project. There are a very large number of improvements
from daa84's version, including lots of bugfixes, using GTK4, smooth resizing,
and more.

%files -n %{name}
%{_bindir}/nvim-gtk
%{_datadir}/*

%prep
{{{ git_dir_setup_macro }}}

%build
cargo build --release

%install
%make_install PREFIX=/usr
%{__install} -D -m644 LICENSE %{buildroot}%{_datadir}/licenses/%{name}/LICENSE
rm -f %{buildroot}/%{_prefix}/.crates.toml %{buildroot}/%{_prefix}/.crates2.json

%changelog
{{{ git_dir_changelog }}}

The regular spec can be built using spectool and rpmbuild. The Git main spec must be processes using rpkg-util, e.g. rpkg local --spec neovim-gtk-git.spec. While rpkg-util is no longer maintained per their own README, I don't think there's any other way of dynamically generating .spec files short of doing the entire process manually/by cobbling together a bunch of scripts.

@Lyude Is this something you'd want in this repository, or track it elsewhere? If the former I'd happily set up a pull request to add the files.

yorickpeterse commented 1 year ago

Note for the above spec files: IIRC %autochangelog only works if you opt-in to %autorelease. I haven't actually used this yet so I'm not sure that is desired or not.

yorickpeterse commented 1 year ago

In the mean time I've set up a copr repository at https://copr.fedorainfracloud.org/coprs/yorickpeterse/neovim-gtk/. I don't think I can automate building from main though, so I'll probably have to run those builds manually every now and then.

Lyude commented 1 year ago

Thank you so much for doing this! JFYI: I was hoping to get to this at some point but never really found the motivation myself haha (it was probably obvious, but I am also a Fedora user myself :). I think the main/stable split you envisioned here is exactly what we'd want as well.

Anyway yes - I'd be fine with having this as part of the repository for the time being. Fun fact though, I am also a Fedora package maintainer :), so I'd also be happy to work with you to get this into Fedora's actual package repo if you'd be interested in that (presumably we could both handle maintaining that as time permits us).

Lyude commented 1 year ago

Note for the above spec files: IIRC %autochangelog only works if you opt-in to %autorelease. I haven't actually used this yet so I'm not sure that is desired or not.

Yeah, I think using these macros would be a good idea for this

Lyude commented 1 year ago

In the mean time I've set up a copr repository at https://copr.fedorainfracloud.org/coprs/yorickpeterse/neovim-gtk/. I don't think I can automate building from main though, so I'll probably have to run those builds manually every now and then.

BTW, I assume this has something to do with the limitations of the automation scripts for building off Github? I can't remember if copr has scripts for this specifically… it's been a while since I've played around with that.

yorickpeterse commented 1 year ago

@Lyude I don't know shit just yet about the process of maintaining a package in the Fedora repositories themselves, but I'd be happy to help out/co-maintain. In that case the stable .spec wouldn't need to be tracked in this repository, though the neovim-gtk-git one should be; that way webhooks can be used to trigger copr builds automatically upon pushing.