Re: Packaging Hyprland

[Hilton Chain]

Hi everyone,

On Sun, 25 Feb 2024 08:32:27 +0800,
Lucy Coleclough wrote:
>
>> On Sat, 24 Feb 2024 at 20:48, hutzdog <hutzdog@proton.me> wrote:
>>
>>  Hi all,
>>
>>  I've been working on moving over to GNU Guix recently, and have hit a
>>  roadblock: there is no package for Hyprland (the one WLRoots based
>>  compositor with single window capture and automatic window swallowing that I
>>  know of). I've taken the liberty of packaging the latest version (see
>>  
>> https://git.sr.ht/~hutzdog/patchwork/tree/master/item/patchwork/packages/desktop.scm
>>  for the package), but there are some changes that need to happen in order
>>  for it to be upstreamed (as of v0.35.0).

Thanks for the work!  I think John (Cc-ed) is going to update dependencies for
Hyprland in next mesa-updates, so the libdrm patch will likely be picked by
them.

In terms of ‘hyprland’ and ‘xdg-desktop-portal-hyprland’, these two packages in
my channel are made ready for upstreaming to Guix (but not their dependencies).

hyprland:
https://github.com/rakino/Rosenthal/blob/trunk/rosenthal/packages/wm.scm#L162
xdg-desktop-portal-hyprland:
https://github.com/rakino/Rosenthal/blob/trunk/rosenthal/packages/wm.scm#L287

>>  # Pending Patches
>>  The following existing patches need to be merged:
>>  LibInput -> 1.25.0 (https://issues.guix.gnu.org/68844)

libinput 1.24.0 is currently available in core-updates:
https://issues.guix.gnu.org/65525

>>  LibDRM -> 2.4.120 (https://issues.guix.gnu.org/68845)
>>
>>  # New Patches
>>  The following new patches will need to be created (I intend to submit these
>>  at some point in the near future):
>>  Cairo -> 1.18.0 (requires moving to Meson, I have a mostly complete set of
>>  changes to make it work)

I didn't take a closer look at cairo update, but yes, this may require some
work, at least to be able to finish its tests.

>>  Toml++ (package will be sent as a patch soon)
>>  Hyprlang (for xdg-desktop-portal-hyprland, will publish after Hyprland)
>>
>>  ## HWData
>>  As with packages using the release versions of WLRoots, due to how Guix
>>  packages HWData a patch is needed to make Meson find it. We have a few
>>  options: maintain a parallel package which simply farms all outputs of
>>  HWData as symlinks and adds the pkg-config file, maintain a patch on a much
>>  more volatile version of WLRoots, or find some other solution.

hwdata with a pkg-config file is in core-updates too:
https://issues.guix.gnu.org/64228

>>  # Hyprland
>>  This will allow me to submit packages for Hyprland and its XDG Desktop
>>  Portal at version 0.35.0 (the latest release). As it's one of the more
>>  popular Wayland compositors out there, I think it is worth adding it to the
>>  repos. For now, the package is available through my Guix channel (fair
>>  warning, it is still very WIP and I wouldn't recommend using it yet outside
>>  of maybe pulling the Hyprland packages). I look forward to working with Guix
>>  (Scheme is certainly a breath of fresh air after dealing with Nix for a
>>  while) and contributing to its ecosystem.
>
> Hey there, have been working on hyprland recently, I have got plugins working
> in my hyprland service, Each plugin can be built to a shared object and then
> referenced in the config plugins:
> https://gitlab.com/lucyCole/GuixChannel/-/blob/main/lucyChannel/packages/hyprlandPlugins.scm?ref_type=heads
> service:
> https://gitlab.com/lucyCole/GuixConfig/-/blob/main/variationAndSource/existingSystemOperation/home/services/temporary.scm?ref_type=heads#L278
>
> I also made a tomlplusplus package and submitted it to the rosenthal repo but
> yh could probably just go in guix
> https://github.com/rakino/Rosenthal/pull/13/files#diff-43c57fc1a44f0d3b5b7642f365df293ffada6ebe4e756ac1ce08ba849f38e361R155

The main issue with hyprpm (plugin manager distributed with Hyprland, depends on
tomlplusplus, I removed it in my definition) is that it shells out to download
and build Hyprland and its plugins, making it work out of the box needs some
effort, and shipping yet another package manager is not what we want.

Hyprland plugins are not hard to package, we just need a loading mechanism.
Adding a search path may be a solution, but this requires some work and is
better done in upstream.

At least for me to accept hyprpm, it should work either out of the box (without
requiring users to install any extra package), or keep only the plugin loading
functionality.


Thanks