Packaging Hyprland

Packaging Hyprland

[hutzdog]

[-- Attachment #1.1: Type: text/plain, Size: 1978 bytes --]

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

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

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

--Hutzdog

[-- Attachment #1.2: publickey - hutzdog@proton.me - 0xD0A768D6.asc --]
[-- Type: application/pgp-keys, Size: 2446 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 680 bytes --]

Re: Packaging Hyprland

[John Kehayias]

Hi Hutzdog,

On Fri, Feb 23, 2024 at 01:20 AM, hutzdog wrote:

> Hi all,
>
> I've been working on moving over to GNU Guix recently, and have hit a

Welcome to Guix! (For the first part, not the roadblock part...)

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

Funny enough, I just decided to take the plunge and try out Wayland
finally with Hyprland, as a sucker for eye candy. I do miss using Lisp
more (coming from lots of StumpWM time) and easy emacs keybindings
everywhere.

I'm using a package from a channel, I believe, of one of our
committers, who I'm cc'ing as I was just about to ask them about
upstreaming.

<https://codeberg.org/hako/Rosenthal/src/branch/trunk/rosenthal/packages/wm.scm>

Works great on my end, thanks to them!

> for the package), but there are some changes that need to happen in
> order for it to be upstreamed (as of v0.35.0).
>
> # Pending Patches
> The following existing patches need to be merged:
> LibInput -> 1.25.0 (<https://issues.guix.gnu.org/68844>)

I could take this on mesa-updates as I was going to be doing some
updates so might as well take this. I'll add it locally and send a
message to the bug number. Part of my motivation was to be able to
upstream Hyprland as well.

If this fits better on another existing branch, please let me know,
someone.

> LibDRM -> 2.4.120 (<https://issues.guix.gnu.org/68845>)
>

I have this locally on my mesa-updates. I'll send a message to that
bug number.

> # 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 have this locally as well and will send some patches for review. It
took a bit more work, though the final result is pretty simple, it
needed a hidden cairo and a new cairo-with-documentation to build the
docs. I built up to icecat locally and all was good from what I could
see.

Sorry for any duplicate work, perhaps your version can add something
to mine.

> Toml++ (package will be sent as a patch soon)
> Hyprlang (for xdg-desktop-portal-hyprland, will publish after Hyprland)
>

I believe we'll need a more current version than the released wlroots
as well. Possibly others based on the channel I referenced above, but
the big update is libdrm and cairo, in terms of rebuilds.

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

Was this handled already in <https://issues.guix.gnu.org/68146> for
wlroots? Which has been merged.

>
> # 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.
>
> --Hutzdog
>

Thanks for your efforts and helping get this conversation started! I
think we can handle the bigger updates on the mesa-updates branch. I
was planning on pushing that to get builds going once I send the cairo
patch and have people take a look at that. Despite the big changes,
I'm fairly confident in it since it seems pretty much everything we
need is built by default now.

And agreed that Hyprland has been pretty nice so far as my first step
into Wayland. Though if anyone can point me to the best way to get
emacs keys everywhere I will be forever thankful. Seems xremap can do
it (which we have packaged) except it doesn't pick up different
applications for where keys apply on Hyprland. I do miss in Stump how
easy that was right in the config.

John

Re: Packaging Hyprland

[hutzdog]

[-- Attachment #1.1: Type: text/plain, Size: 7473 bytes --]

Hi,

> Hi Hutzdog,
> 

> On Fri, Feb 23, 2024 at 01:20 AM, hutzdog wrote:
> 

> > Hi all,
> >
> > I've been working on moving over to GNU Guix recently, and have hit a
> 

> Welcome to Guix! (For the first part, not the roadblock part...)
Thanks, so far I'm enjoying the experience

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

> Funny enough, I just decided to take the plunge and try out Wayland
> finally with Hyprland, as a sucker for eye candy. I do miss using Lisp
> more (coming from lots of StumpWM time) and easy emacs keybindings
> everywhere.
> 

> I'm using a package from a channel, I believe, of one of our
> committers, who I'm cc'ing as I was just about to ask them about
> upstreaming.
> 

> <https://codeberg.org/hako/Rosenthal/src/branch/trunk/rosenthal/packages/wm.scm>
Cool, it looks like we did things slightly differently but it looks like we've reached similar outputs (though mine does keep bundled WLRoots due to the fact that having a wlroots-git package for all compositors could cause issues as APIs change over time. Their package definitely seems like a better base (partly because I'm new to packaging with Guix and thus don't know how to do it well yet), though there are a few things in mine that might make it worthwhile.

> Works great on my end, thanks to them!
> 

> > for the package), but there are some changes that need to happen in
> > order for it to be upstreamed (as of v0.35.0).
> >
> > # Pending Patches
> > The following existing patches need to be merged:
> > LibInput -> 1.25.0 (<https://issues.guix.gnu.org/68844>)
> 

> I could take this on mesa-updates as I was going to be doing some
> updates so might as well take this. I'll add it locally and send a
> message to the bug number. Part of my motivation was to be able to
> upstream Hyprland as well.
Cool, I don't know much about the various development branches so I can't say whether or not that's the correct branch.

> If this fits better on another existing branch, please let me know,
> someone.
> 

> > LibDRM -> 2.4.120 (<https://issues.guix.gnu.org/68845>)
> >
> 

> I have this locally on my mesa-updates. I'll send a message to that
> bug number.
Alright, that merging will be good

> > # 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 have this locally as well and will send some patches for review. It
> took a bit more work, though the final result is pretty simple, it
> needed a hidden cairo and a new cairo-with-documentation to build the
> docs. I built up to icecat locally and all was good from what I could
> see.
> 

> Sorry for any duplicate work, perhaps your version can add something
> to mine.
Actually, from what I can tell my repo's version handles the documentation problem (I move it to the correct output after the install step), but otherwise either will work fine.

> > Toml++ (package will be sent as a patch soon)
> > Hyprlang (for xdg-desktop-portal-hyprland, will publish after Hyprland)
> >
> 

> I believe we'll need a more current version than the released wlroots
> as well. Possibly others based on the channel I referenced above, but
> the big update is libdrm and cairo, in terms of rebuilds.
Yeah, Hyprland depends on the Git version of WLRoots. I've chosen to use their bundled version in my package to avoid breakage from changes to WIP WLRoots APIs. Actually, I think that I did miss a different package (udis86), but that can be added.

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

> Was this handled already in <https://issues.guix.gnu.org/68146> for
> wlroots? Which has been merged.
This is an interesting case, where applying a patch to the wlroots Git package would work. What I (and, as it seems, the developer of the other channel) seem to have come to is that maintaining a package that adds the pkg-config file to hwdata (correct me if I'm wrong on what their package is doing) will be less of a burden than maintaining a patch for an ever changing version of WLRoots.

> > # 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.
> >
> > --Hutzdog
> >
> 

> Thanks for your efforts and helping get this conversation started! I
> think we can handle the bigger updates on the mesa-updates branch. I
> was planning on pushing that to get builds going once I send the cairo
> patch and have people take a look at that. Despite the big changes,
> I'm fairly confident in it since it seems pretty much everything we
> need is built by default now.
> 

> And agreed that Hyprland has been pretty nice so far as my first step
> into Wayland. Though if anyone can point me to the best way to get
> emacs keys everywhere I will be forever thankful. Seems xremap can do
> it (which we have packaged) except it doesn't pick up different
> applications for where keys apply on Hyprland. I do miss in Stump how
> easy that was right in the config.
> John
I'm just glad to hear there's interest in it, and hope to see Hyprland in upstream soon. I can send in patches if needed, though I am busy getting my configs ironed out (currently, I'm on a temporary River setup that has some fundamental design flaws which I intend to work around this time), but I should be able to make time to work on packaging what's needed.

Unfortunately, I don't know how to get Emacs keys to work everywhere (apparently, key chords can be handled by submaps, but I'm not entirely sure if that's what you mean). There is a way to passthrough keys as well (https://wiki.hyprland.org/Configuring/Advanced-config/#global-keybinds) otherwise, if that's what you're looking for.

If Hyprland does get merged, I'd be happy to try to co-maintain it (seeing as the configuration framework I'm making uses it as one of the available options, I should be fairly invested in keeping it up-to-date). I'm still learning, but I think I should be capable of keeping it up to date. Let me know if I'm doing anything wrong with the packaging (again, completely new to Guix), and I look forward to working with Guix.

Thanks,
--Hutzdog


[-- Attachment #1.2: publickey - hutzdog@proton.me - 0xD0A768D6.asc --]
[-- Type: application/pgp-keys, Size: 2446 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 680 bytes --]

Re: Packaging Hyprland

[Lucy Coleclough]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

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

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).
>
> # Pending Patches
> The following existing patches need to be merged:
> LibInput -> 1.25.0 (https://issues.guix.gnu.org/68844)
> 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)
> 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.
>
> # 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.
>
> --Hutzdog

[-- Attachment #2: Type: text/html, Size: 3905 bytes --]

Re: Packaging Hyprland

[hutzdog]

[-- Attachment #1.1: Type: text/plain, Size: 3483 bytes --]

Hey,

I should also note that my PatchworkOS repo also has a Hyprland service, though it's integrated with Patchwork-specific infrastructure that gives control over which compositor is used to each user, provides a full Base16-derived theming system, provides an opinionated starter config to give a usable out of the box experience, and supports starting a pseudo-service that spawns in everything that would normally be manually run by the config. It doesn't have the plugin system supported, though.

--Hutzdog

On Saturday, February 24th, 2024 at 5:32 PM, Lucy Coleclough <coleclough.lucy@gmail.com> wrote:

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

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

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

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

> > --Hutzdog

[-- Attachment #1.2: publickey - hutzdog@proton.me - 0xD0A768D6.asc --]
[-- Type: application/pgp-keys, Size: 2446 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 680 bytes --]

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

Re: Packaging Hyprland

[John Kehayias]

Hi everyone,

Just a note on cairo below:

On Sun, Feb 25, 2024 at 10:39 AM, Hilton Chain wrote:

> 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:
>>>
[snip]
>>>  # 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.
>

I submitted the patches as 69495: <https://issues.guix.gnu.org/69495>
It works for me locally in some limited tests (e.g. icecat).

Hutzdog: you mentioned getting the docs built and put in the output,
but I didn't see that in your linked repo. The issue is that gtk-doc
is needed which depends on cairo. I worked around the dependency cycle
by hiding cairo and making a new cairo-with-documentation (the first
is used for packages and hidden, the second with docs and public).
Thanks to lilyp on #guix for pointing me to glib with a similar issue
and workaround.

But maybe I missed something if you didn't need to do this?

Once cairo is approved I'll get mesa-updates building with libdrm,
cairo, vulkan, and mesa updates. It would be nice to grab the libinput
update so we don't have to wait for core-updates, but I didn't look if
that make sense. Otherwise we could have just a libinput-next for
hyprland, for instance (though I don't know where it fits in the
dependency graph here).

More updates soon, and thanks everyone! Cool to see about plugin
systems and services, haven't looked at that yet.

John

Re: Packaging Hyprland

[John Kehayias]

Slightly off topic, but for anyone wondering about my emacs keys issue:

On Sat, Feb 24, 2024 at 04:01 PM, John Kehayias wrote:

> Seems xremap can do it (which we have packaged) except it doesn't
> pick up different applications for where keys apply on Hyprland. I
> do miss in Stump how easy that was right in the config.

It does work! Slight difficulty since I had already set capslock to
control in my Hyprland settings (via xkb I believe). So I still had to
map capslock to control in xremap as well, and then the provided
example of emacs keybindings works (with the modification that on my
system at least it is 'emacs' (lowercase) for the application name to
make sure xremap doesn't apply there as well.)

Guess I can continue with Hyprland!

Re: Packaging Hyprland

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Sat, Feb 24, 2024 at 10:32:29PM +0000, John Kehayias wrote:
> Slightly off topic, but for anyone wondering about my emacs keys issue:
> 
> On Sat, Feb 24, 2024 at 04:01 PM, John Kehayias wrote:
> 
> > Seems xremap can do it (which we have packaged) except it doesn't
> > pick up different applications for where keys apply on Hyprland. I
> > do miss in Stump how easy that was right in the config.
> 
> It does work! Slight difficulty since I had already set capslock to
> control in my Hyprland settings (via xkb I believe). So I still had to
> map capslock to control in xremap as well, and then the provided
> example of emacs keybindings works (with the modification that on my
> system at least it is 'emacs' (lowercase) for the application name to
> make sure xremap doesn't apply there as well.)
> 
> Guess I can continue with Hyprland!

The README and Cargo.toml disagree about what commands to call, but I
can add a hyprland variant of the xremap package if there's interest.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Packaging Hyprland

[John Kehayias]

Hi Efraim,

On Sun, Feb 25, 2024 at 12:42 PM, Efraim Flashner wrote:

> On Sat, Feb 24, 2024 at 10:32:29PM +0000, John Kehayias wrote:
>> Slightly off topic, but for anyone wondering about my emacs keys issue:
>>
>> On Sat, Feb 24, 2024 at 04:01 PM, John Kehayias wrote:
>>
>> > Seems xremap can do it (which we have packaged) except it doesn't
>> > pick up different applications for where keys apply on Hyprland. I
>> > do miss in Stump how easy that was right in the config.
>>
>> It does work! Slight difficulty since I had already set capslock to
>> control in my Hyprland settings (via xkb I believe). So I still had to
>> map capslock to control in xremap as well, and then the provided
>> example of emacs keybindings works (with the modification that on my
>> system at least it is 'emacs' (lowercase) for the application name to
>> make sure xremap doesn't apply there as well.)
>>
>> Guess I can continue with Hyprland!
>
> The README and Cargo.toml disagree about what commands to call, but I
> can add a hyprland variant of the xremap package if there's interest.

Yeah, I'm not sure the difference of xremap wlroots or hyprland
variant. I'm just using our packaged wlroots one and it is working
great now. I suppose we should add the hyprland one, at least when we
have hyprland. Thanks in advance Efraim!

On the xremap side, a service would be great, and luckily we have one
pending: <https://issues.guix.gnu.org/66932>.

John