Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages for Fedora #93

Open
yorickpeterse opened this issue Mar 1, 2023 · 7 comments
Open

Packages for Fedora #93

yorickpeterse opened this issue Mar 1, 2023 · 7 comments
Labels
enhancement New feature or request

Comments

@yorickpeterse
Copy link

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. 😄 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
Copy link
Author

yorickpeterse commented Mar 2, 2023

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

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

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

Lyude commented Mar 5, 2023

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 Lyude added the enhancement New feature or request label Mar 5, 2023
@Lyude
Copy link
Owner

Lyude commented Mar 5, 2023

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

Lyude commented Mar 5, 2023

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.

@Lyude Lyude added fix posted A fix has been posted or pushed, but we're waiting for confirmation it works before closing and removed fix posted A fix has been posted or pushed, but we're waiting for confirmation it works before closing labels Mar 5, 2023
@yorickpeterse
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants