jay: Add at v1.14.0

[witchlliee]

aerynOS New Package Pull Request

Summary

Another lightweight but powerful wayland compositor written in Rust. I really think this one deserves a spot.

Testing Performed

• I have tested the package and can confirm that just build completes successfully, the package installs via moss and that the application functions as expected
• No obvious security or stability concerns or any regressions observed in testing
• The package was tested against the volatile stream

Additional testing notes:

Nothing. Just build, install and log in into it.

Checklist

• An approved package request issue exists (fixes: [Package Request]: jay #2217)
• I have read and conformed to both the Package Addition Policy, and the Contributing Guidelines. I also confirm that this is my own work or properly attributed
• No sensitive credentials, API keys, or secrets are included in this PR
• I am willing to act as the primary maintainer for this package (optional but recommended)
• This change could gainfully be highlighted in the Stream Update notes once merged

If you did NOT link to an approved issue, please explain why in the Additional Context section below.

Additional Context

There is no really package request for this one. It's not "very known" which is weird because it's really feature-rich. It has HDR, low-latency input, among other things for gaming.

https://mahkoh.github.io/jay/book/features.html

Screenshots / Output (if applicable)

Jay with noctalia:

[Jaredy899]

This looks neat! However we now need a package addition request prior to making a PR for it. For now I'll make this a draft if you will put in an addition request for it.

[witchlliee]

Do I need to also open a issue requesting the package? What is the difference tho?

[Jaredy899]

Yes. We'll need to approve a package request before a PR is put in.

[khaga87]

Do I need to also open a issue requesting the package? What is the difference tho?

Hey Ellie,

We had noticed lately that we had been getting more and more PRs where there hadn't been any prior engagement with the team as to the contributors intention to submit the PR before it landed.

There were cases where the team can't currently accept the PR (for any given number of reasons) and so it was adding up to lost time for all parties involved.

As the project grows, we do need to add a little formality into the process so everyone is clear on where they stand and what's expected of them.

You're catching us right in the middle of this process where we are fine-tuning everything.

For new packages, the process flow will be:

1. Request a new package addition via the issues template
2. The team will review and either approve or reject (if rejected, we will give a reason)
3. Once approved, either the original requester or any contributor is free to create the recipe and submit it as a PR

I need to continue refining our documentation across the board in line with this latest position, so I don't begrudge that you submitted a new package PR as the guidance wasn't yet clear.

I can see that you've already submitted the request so I appreciate you for engaging with the process!

[witchlliee]

Ah sorry. I thought just making the PR was enough. Will remember this for future packages I may want to PR.

[mauvray]

@witchlliee Hey, I also had a package on my side for jay but I don't have the same build deps. Are you interested in discussing them ?

I found that building with only

builddeps   :
    - pkgconfig(cairo)
    - pkgconfig(gbm)
    - pkgconfig(libinput)
    - pkgconfig(pango)

seems enough

[witchlliee]

Ah, I think I got some dependencies wrong anyway which led to some problems in my testing. Will check it soon.

Here is the dependencies which the package needs:

https://mahkoh.github.io/jay/book/installation.html

[witchlliee]

Will reopen this again since package request was approved. Thank you <3

[mauvray]

Ah, I think I got some dependencies wrong anyway which led to some problems in my testing. Will check it soon.

Here is the dependencies which the package needs:

https://mahkoh.github.io/jay/book/installation.html

I know about this page, I started to create my stone a while ago and I went with a whack a mole approach to add only needed dependency to build jay, and to run, I guess my AerynOS with desktop mode (and sway on the side) was enough to run it. You can find my package here.

For the rundeps, I think gnome-keyring would not be needed, maybe as a desktop package built around jay. I wonder how moss could support optionnal deps, for exemple pipewire for screen recording, or sqlite libs to have session restore, or opengl renderer.

What do you think?

[witchlliee]

Ah, I think I got some dependencies wrong anyway which led to some problems in my testing. Will check it soon.
Here is the dependencies which the package needs:
https://mahkoh.github.io/jay/book/installation.html

I know about this page, I started to create my stone a while ago and I went with a whack a mole approach to add only needed dependency to build jay, and to run, I guess my AerynOS with desktop mode (and sway on the side) was enough to run it. You can find my package here.

For the rundeps, I think gnome-keyring would not be needed, maybe as a desktop package built around jay. I wonder how moss could support optionnal deps, for exemple pipewire for screen recording, or sqlite libs to have session restore, or opengl renderer.

What do you think?

gnome-keyring is needed in order for some applications to work properly. Niri also includes it, so I thought it wouldn't hurt including it here as well. And moss still doesn't handle optional deps

[mauvray]

gnome-keyring is needed in order for some applications to work properly. Niri also includes it, so I thought it wouldn't hurt including it here as well.

I think this is to provide a backend for the secret xdg portal, but currently you can choose between kdewallet or gnome-keyring, and if someone is to build a desktop with more kde apps than gnome, the kdewallet would be the obvious choice (I like kde looks more than gnome's ^^')

Maybe standalone compositors should come barebones, and let the user setup the component while we miss optional dependencies, or abstract one (we could imagine that jay requires a xdg-desktop-portal-secret-backend that would be provided by kdewallet, gnome-keyring or whatever someone could come up with). When I look at sway's stone, it comes with a few dependencies including the terminal emulator of the default config. Maybe we could simply check what is in jay's default config and only add this as runtime dependencies for now.

[Jaredy899]

I've had to research this a bit. I think we should drop gnome-keyring to keep it minimal so those can build their desktop the way they want it. If someone wants something that can "just work", we have other options for DE's. That being said, we'll need to include a terminal. binary(mako), as jay has it for default config. Then pipewire for reasons above. I think that keeps things minimal while still functioning for the user to configure things. alacritty is the terminal of choice https://mahkoh.github.io/jay/book/running.html.

EDIT: Oh. And jay expects bemenu to be installed too, which we don't have so we'd have to package that. (same PR)

[witchlliee]

I've had to research this a bit. I think we should drop gnome-keyring to keep it minimal so those can build their desktop the way they want it. If someone wants something that can "just work", we have other options for DE's. That being said, we'll need to include a terminal. binary(mako), as jay has it for default config. Then pipewire for reasons above. I think that keeps things minimal while still functioning for the user to configure things. alacritty is the terminal of choice https://mahkoh.github.io/jay/book/running.html.

EDIT: Oh. And jay expects bemenu to be installed too, which we don't have so we'd have to package that. (same PR)

I don't think we should include any that. Other WMs here also don't do that. This can added for a pkgset for Jay later on. I will probably work on it myself if approved. About gnome-keyring, it's because is needed for some applications to work properly, and niri also include it for example.

[witchlliee]

Actually, alacritty at least is a good idea. Still, I feel bad adding programs, since there is no way they can remove it afterwards if they prefer another program

[mauvray]

I keep my stance about not adding gnome-keyring. The other apps need it, not jay. As long as moss does not have a more evolved model to handle more abstract dependencies, I think that we should keep dependencies as minimal as possible. Here, pipewire ts optional for jay but considering the feature it provides and how someone using AerynOS as desktop would end up with pipewire installed, it is okay. Allacritty would allow to open a terminal to customize config, but we could argue that someone that install jay probably knows how to switch tty to do the same actions (but maybe jay could be patched to use $EDITOR instead of alacritty). And sqlite could be added for session restore.

[Jaredy899]

I think we need to keep in the spirit of the upstream as far as what they require. I think adding sqlite is appropriate as well. But since jay references alacritty and bemenu, we need those as well. If someone is looking at jay's documentation, they will be expecting those. Adding Pipewire and sqlite will be helpful for the experience and it's probably something users expect while keeping as minimal as possible.

[mauvray]

For now, this would be enough I think. Maybe this could be revised in the future when AerynOS comes production ready.

[witchlliee]

I think we need to keep in the spirit of the upstream as far as what they require. I think adding sqlite is appropriate as well. But since jay references alacritty and bemenu, we need those as well. If someone is looking at jay's documentation, they will be expecting those. Adding Pipewire and sqlite will be helpful for the experience and it's probably something users expect while keeping as minimal as possible.

Shouldn't we expect the people to install the programs they already use together with jay (terminal, launcher, or even shell)? Pipewire is already the default on AerynOS as well

[witchlliee]

Not even their AUR package installs all of this:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=jay

[Jaredy899]

@witchlliee you're giving me a headache. 🙃 As I said before, let's include what's expected upstream, sqlite, alacritty. bemenu. I honestly don't know if Pipewire is included automatically or if we need to explicitly include it but I'll leave that up to you to figure out.

[witchlliee]

@witchlliee you're giving me a headache. 🙃 As I said before, let's include what's expected upstream, sqlite, alacritty. bemenu. I honestly don't know if Pipewire is included automatically or if we need to explicitly include it but I'll leave that up to you to figure out.

Okey dokey.

Bemenu is being a pain in the ass to package, the recipe is simple but when I install it to test, it doesn't launch unless I force the wayland backend with BEMENU_RENDERER=/usr/lib/bemenu/bemenu-renderer-wayland.so bemenu-run. (It's not aware of its own lib???)

recipe:

# SPDX-FileCopyrightText: 2026 aerynOS Developers
# SPDX-License-Identifier: MPL-2.0

name        : bemenu
version     : "0.6.23"
release     : 1
homepage    : https://github.com/Cloudef/bemenu
upstreams   :
    - https://github.com/Cloudef/bemenu/releases/download/0.6.23/bemenu-0.6.23.tar.gz : 7cd336fb827b50a12c398a5daf6d2e6a07e291217116e725e7f1e021d9e0cdd9
summary     : Dynamic menu library and client program inspired by dmenu
description : |
    Dynamic menu library and client program inspired by dmenu.
license     :
    - GPL-3.0-or-later
    - LGPL-3.0-or-later
builddeps   :
    - pkgconfig(pango)
    - pkgconfig(scdoc)
    - pkgconfig(wayland-client)
    - pkgconfig(wayland-protocols)
    - pkgconfig(xkbcommon)
build       : |
    %make clients wayland
install     : |
    %make_install PREFIX=/usr

[K1ngfish3r]

Bemenu is being a pain in the ass to package, the recipe is simple but when I install it to test, it doesn't launch unless I force the wayland backend with BEMENU_RENDERER=/usr/lib/bemenu/bemenu-renderer-wayland.so bemenu-run. (It's not aware of its own lib???)

a stateless patch to read BEMENU_RENDEDERER from /usr/lib/bemenu/bemenu-renderer-wayland.so should fix this

[witchlliee]

Bemenu is being a pain in the ass to package, the recipe is simple but when I install it to test, it doesn't launch unless I force the wayland backend with BEMENU_RENDERER=/usr/lib/bemenu/bemenu-renderer-wayland.so bemenu-run. (It's not aware of its own lib???)

a stateless patch to read BEMENU_RENDEDERER from /usr/lib/bemenu/bemenu-renderer-wayland.so should fix this

Okay, I have no idea how to patch that. From what I can see from their code, it should be searching for a renderer in that path.

[K1ngfish3r]

BEMENU_RENDERER=/usr/lib/bemenu/bemenu-renderer-wayland.so bemenu-run

build       : |
    %make clients wayland PREFIX=%(prefix)
install     : |
    %make_install PREFIX=%(prefix)

prefix defaults to /usr/local, at build time so need to add that during build as well

[witchlliee]

BEMENU_RENDERER=/usr/lib/bemenu/bemenu-renderer-wayland.so bemenu-run

build       : |
    %make clients wayland PREFIX=%(prefix)
install     : |
    %make_install PREFIX=%(prefix)

prefix defaults to /usr/local, at build time so need to add that during build as well

This worked. Thanks!!!

[witchlliee]

This should be ready now. Sorry for being a bit stubborn. I just want the best for the end user

[Jaredy899]

We all understand. Give me a day to look over this and audit it.

[Jaredy899]

Jay’s session is just Exec=jay run and does not start a secrets daemon. niri pulls gnome-keyring because niri-session actually uses it. That does not apply here. Drop binary(gnome-keyring)