Report forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Mon, 10 Mar 2025 04:26:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Andrew Wong <wongandj@icloud.com>:
New bug report received and forwarded. Copy sent to guix-patches@gnu.org.
(Mon, 10 Mar 2025 04:26:02 GMT) (full text, mbox, link).
This new version updates hyprscroller and hy3 to be compatible with the latest 0.48.0 release of Hyprland.
Andrew Wong (4):
gnu: Add Hyprland plugins.
gnu: Add hyprscroller.
gnu: Add hy3.
gnu: Add hypr-darkwindow.
gnu/packages/wm.scm | 209 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 209 insertions(+)
base-commit: ce086e31f0f5c78be76fd228dfd7718ff6df584e
--
2.49.0
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 08:35:02 GMT) (full text, mbox, link).
The policy for Guix is one package per commit.
Even with the use of a helper like hyprland-plugin,
wouldn't that also apply here?
If you end up deciding to change that, here is a tip:
In the git-rebase-todo file, you can change the order of
the commits by rearranging their lines. If you use Magit,
you can do that by dragging the commit with M-n and M-p.
That way, you could modify your hyprland-plugin to
be the first, and have the other packages come next.
If you allow me to submit a v3, I think I could do that.
--
Gabriel Santos
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 14:00:03 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 14:18:02 GMT) (full text, mbox, link).
On 3/29/25 8:06a, Gabriel Santos wrote> Would it be ok if I added
hypr-dynamic-cursors[1] to it by
> sending a V3?
Sure, go ahead! While you're at it, could you add both of our names and
addresses to the copyright at the top of the file? I keep forgetting to
do it :p
On 3/29/25 9:58a, Gabriel Santos wrote:
> The policy for Guix is one package per commit.
>
> Even with the use of a helper like hyprland-plugin,
> wouldn't that also apply here?
I thought about it, but I have submitted similar patches in the past[1]
without any hangups, so I did the same here for the sake of simplicity.
> If you allow me to submit a v3, I think I could do that.
Sure, go ahead. I'm not attached to any particular commit arrangement.
On 3/29/25 9:51a, Gabriel Santos wrote:
> I noticed that the Flake for this plugin and for
> hypr-dynamic-cursors prefix the compiled file with
> "lib"[1, 2].
>
> Do you know why that is? Would it also be necessary
> for Guix?
I'm not sure why. It's not a requirement for the plugins to work, so I'd
guess it's just a convention of Nix or the packager.
[1] a9a13ebccc (gnu: Add libretro-beetle-psx., 2025-01-04)
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 14:18:03 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 15:07:02 GMT) (full text, mbox, link).
>Sure, go ahead! While you're at it, could you add both of our names and addresses to the copyright at the top of the file? I keep forgetting to do it :p
I wonder if the function for that could be loaded with
.dir-locals.el, but it probably has existed for a long
time, so maybe someone already tried that.
>I thought about it, but I have submitted similar patches in the past[1] without any hangups, so I did the same here for the sake of simplicity.
>Sure, go ahead. I'm not attached to any particular commit arrangement.
If there's no issues, I think it would be best to leave
it that way.
--
Gabriel Santos
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 15:07:03 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 16:21:01 GMT) (full text, mbox, link).
This new revision add in a missing copyright statement, and a new plugin,
hypr-dynamic-cursors.
Andrew Wong (4):
gnu: Add Hyprland plugins.
gnu: Add hyprscroller.
gnu: Add hy3.
gnu: Add hypr-darkwindow.
Gabriel Santos (1):
gnu: Add hypr-dynamic-cursors.
gnu/packages/wm.scm | 258 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 258 insertions(+)
base-commit: 3746dcae31730ff405f49e1a32b506bfa827a3ea
--
2.49.0
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sat, 29 Mar 2025 16:21:02 GMT) (full text, mbox, link).
To: Gabriel Santos <gabriel.santos.smtp@gmail.com>, 76910@debbugs.gnu.org
Cc: Gabriel Santos <gabrielsantosdesouza@disroot.org>
Subject: Re: [bug#76910] Plugin Build Conundrum
Date: Sat, 29 Mar 2025 20:46:59 -0400
I took a closer look at how Hyprland plugins are built, and I think more
work will need to be done on their build system. Outside of Guix,
plugins are built and installed by hyprland's userspace package manager,
hyprpm, which reads a .toml file in the repository root, finds the
plugin commit corresponding to the installed Hyprland's commit (or the
latest commit, if there are no corresponding commits), and checks it out
before compiling[1].
Meaning, our latest version (v3) of the patch series still has some
issues: for one, they are all currently pulling from the incorrect
commits, as they should be pulling from the commit specified in each
plugin's .toml file corresponding to the currently packaged Hyprland, or
from the latest git. For two, they will be a chore to maintain, as
updating them correctly will involve going into each repo and checking
their .toml file. Finally, they cannot be versioned easily, since we
would have the (often missing) version of the plugin as well as the
version the package is to be compiled for to contend with[2].
There are a few ways I've thought up for us to do this better:
1. We can create a "hyprland-plugin-build-system" or
"hyprland-plugin-phases" that emulates hyprpm by retreiving the commit
hash of the input hyprland package (my initial thought is that we could
use the full commit hash presented by `hyprland --systeminfo`), parsing
the .toml file, and switching to the correct commit before building
(maybe even parsing the build instructions given in the files?)
2. We can package (and heavily patch to run in build-space) hyprpm to
be used directly in the build process for plugins. Or, we could ask
hyprpm's developers to add features to let it be used in this way (e.g.
allowing the directories it uses to be customized) to reduce Guix'
maintenance load, but it may be a tough sell.
3. We can package hyprpm as a userspace tool and let it do its thing.
It's not like it provides nonfree binaries, anyways (but it does seem to
ask that the user pollute their profile with whatever build tools a
plugin uses--nothing `guix shell` can't smooth over.) This is what the
developers advise[3]. It feels very "un-guix" to let any binary build
happen outside of a hermetically-sealed build bubble, though, let alone
the idea of running software compiled from the "latest git".
Options 1 and 2 would make maintenance and versioning of the packages
much easier, as you'd just have to keep them on their latest git (or
version if they have their own version numbers) and the build system
would take care of the rest. Option 3 would mean having no plugin
packages to maintain in the first place.
Let me know what you all think, or if you have any ideas of your own.
- Andrew Wong
[1]
https://wiki.hyprland.org/Plugins/Development/Plugin-Guidelines/#commit-pins
[2] I used to think I could version them with just the Hyprland
version they're meant for, but then I realized that later versions of
the plugins can change the commits corresponding to each version, so
e.g. the Jan. 2026 version of hyprscroller for hyprland 0.51.1 could be
different from the Mar. 2026 version of hyprscroller for hyprland
0.51.1. I mean, I guess it could be solved with some funky extended
version number scheme, but it wouldn't be elegant.
[3] https://github.com/hyprwm/hyprland-plugins/issues/312
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Sun, 30 Mar 2025 01:09:02 GMT) (full text, mbox, link).
From: Gabriel Santos <gabrielsantosdesouza@disroot.org>
To: Andrew Wong <wongandj@icloud.com>,
Gabriel Santos <gabriel.santos.smtp@gmail.com>, 76910@debbugs.gnu.org
Subject: Re: [bug#76910] Plugin Build Conundrum
Date: Sat, 29 Mar 2025 22:08:43 -0300
>hyprland's userspace package manager, hyprpm
Not /another/ one!
>1. We can create a "hyprland-plugin-build-system" or "hyprland-plugin-phases"
>that emulates hyprpm by retreiving the commit hash of
>the input hyprland package (my initial thought is that
>we could use the full commit hash presented by
>`hyprland --systeminfo`), parsing the .toml file,
>and switching to the correct commit before building
>(maybe even parsing the build instructions given in
>the files?)
This is the option I prefer. It is future-proof,
as it makes adding newer plugins a simpler process.
Though, couldn't we take over the package manager, as is
done in other build systems, such as cargo, go and node?
Even the main one, gnu-build-system, uses a command for
building, such as Make, instead of doing everything
manually.
I'm not sure I could help with this though, I don't think
I'm practical with Guix/Scheme to the point of creating a
whole new build system.
>3. We can package hyprpm as a userspace tool and let it
>do its thing. It's not like it provides nonfree binaries,
>anyways (but it does seem to ask that the user pollute
>their profile with whatever build tools a plugin
>uses—nothing `guix shell` can't smooth over.) This
>is what the developers advise[3]. It feels very "un-guix"
>to let any binary build happen outside of a
>hermetically-sealed build bubble, though, let alone the
>idea of running software compiled from the "latest git".
This seems to be the most likely option. And it's not
/that/ strange for Guix, as we have a well functioning
version of Nix here, which I use with home-managr
to install whatever might not be available here.
Also, from the issue you linked, it would repsect the
author's wishes.
>[3] <https://github.com/hyprwm/hyprland-plugins/issues/312>
--
Gabriel Santos
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 07:55:02 GMT) (full text, mbox, link).
After investigatory efforts into each of the three options discussed earlier, I
have decided that it would be best to manually maintain the "compilation commit"
of each plugin for now, according to the plan laid out in the final patch of
this series. This decision was made after observing how 'hyprpm' is, at current,
simultaneously too lacking in features and flexibility to be integrated as a
guix-contolled build tool while also developing too fast to have confidence that
a re-implementation of its behavior won't be either obsoleted by changes in that
behavior or by hyprpm becoming a better implementation in a matter of months. I
also attempted to prepare hyprpm for straightforward user-land use just as it
is, but it seems to assume a more FHS-compliant filesystem than Guix provides;
not that I'd discourage a more experienced contributor from trying to adapt
it. I've written more about the specifics of how these packages will be
maintained and why in a comment added in the final patch of this series.
Also, I've removed hypr-dynamic-cursors, as I couldn't find a commit for it that
both builds and loads for Hyprland versions 0.48.0 and 0.48.1. Gabriel, if you
have any advice regarding this, it would be appreciated.
Let me know what you think,
Andrew Wong
Andrew Wong (5):
gnu: Add Hyprland plugins.
gnu: Add hyprscroller.
gnu: Add hy3.
gnu: Add hypr-darkwindow.
gnu: Add hyprland plugin maintainer note
gnu/packages/wm.scm | 238 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 238 insertions(+)
base-commit: bcd207005c4ae1b0ae11ebe932047218ffe6ee83
--
2.49.0
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 07:55:03 GMT) (full text, mbox, link).
Change-Id: I971940d515b1820532abbc31754d31d6f2efd515
---
gnu/packages/wm.scm | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index 537150e138..03ccc0dce6 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -447,6 +447,33 @@ (define-public hyprland
`((upstream-name . "source")))
(license license:bsd-3)))
+
+;; READ THIS regarding Hyprland plugin versioning
+;;
+;; Each Hyprland plugin contains a .toml file with an entry called `commit_pins'
+;; containing pairs of commit hashes. The first hash is Hyprland's commit hash, and
+;; the second hash is the hash of the plugin repository which hyprpm would switch to
+;; before compiling the plugin[1]. Therefore, to remain consistent with hyprpm, when
+;; upgrading a plugin, maintainers should check its .toml file and use the hash
+;; corresponding to the packaged Hyprland version. If Hyprland's packaged commit is
+;; not listed, packagers should use the latest working commit. For plugins that lack
+;; their own version numbers, we will use git-version, with the newest supported
+;; Hyprland version as the VERSION argument.
+;;
+;; A flaw with this way of doing things is that the correct version of a plugin will
+;; not automatically be built if a transformation is used to select a different
+;; version of Hyprland from what is packaged, or if Hyprland is updated without its
+;; plugins. However, with the rapid pace (as of 1 Apr 2025) of Hyprland and related
+;; softwares, we can reasonably hope that soon, either A) hyprpm will develop enough
+;; to become usable as a Guix-managed build tool, or B) hyprpm will become obsolete
+;; by the introduction of a stable, versioned Hyprland API.
+;;
+;; You can safely test plugins by launching hyprland from a shell (wayland sessions
+;; can run within each other) and loading the plugin into it using hyprctl's
+;; '--instance' option and 'plugin load' command.
+;;
+;; [1] https://wiki.hyprland.org/Plugins/Development/Plugin-Guidelines/#commit-pins
+
(define hyprland-plugin
(lambda (plugin-name plugin-provision)
"Generate a packaged plugin from Hyprland's official plugin repository."
--
2.49.0
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 09:30:03 GMT) (full text, mbox, link).
>Also, I've removed hypr-dynamic-cursors, as I couldn't find a commit for it that
>both builds and loads for Hyprland versions 0.48.0 and 0.48.1. Gabriel, if you
>have any advice regarding this, it would be appreciated.
I don't really have any advice on this.
If it fails to build and load, it's best to wait until a
version for 0.48.1 is released to add it back.
--
Gabriel Santos
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 09:30:03 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 12:25:04 GMT) (full text, mbox, link).
>If it fails to build and load, it's best to wait until a
>version for 0.48.1 is released to add it back.
Actially, I just had an idea: why not just patch the TOML file
to support 0.48.1? That's what I'm trying right now, will
report on results later.
--
Gabriel Santos
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 12:26:05 GMT) (full text, mbox, link).
Information forwarded
to guix-patches@gnu.org: bug#76910; Package guix-patches.
(Tue, 01 Apr 2025 12:51:03 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.