feat: allow to build using Guix

[4zv4l]

I added a mangowc.scm that allow to build the file using Guix in a reproducible way.

This file would be better hosted on a Guix channel (I sent a patch to GNU Guix channel and my personal channel) but I believe it is also nice to have it available directly in the repo.

(I started using it on my personal Guix laptop and it is truely amazing, thank you!).

[DreamMaoMao]

Does it need to fix these Hashes here? Can't it be specified by the user side?

[4zv4l]

The hash is to protect against tempering with the source code (to be sure its not building a modified version). So it will be different for each release. Although its also possible to skip that part when building by changing the version guix build mangowc --with-latest.

[DreamMaoMao]

I think it's better to use the latest submission by default, just as the aur package does. Then, if a fixed version operation is needed, it's up to the user to decide

[Yappaholic]

I think it would be better to reference git repository as a source instead of using git-fetch, you can check how quickshell does that:
https://github.com/quickshell-mirror/quickshell/blob/master/quickshell.scm

[ch4og]

I think it would be better to reference git repository as a source instead of using git-fetch, you can check how quickshell does that: https://github.com/quickshell-mirror/quickshell/blob/master/quickshell.scm

That would prevent this repository from being used as a channel (see my MR to the Quickshell documentation). This is a significant limitation, because the entire purpose of adding a package definition to this repository is precisely to enable its use as a Guix channel.

To be honest, I have not verified whether Guix handles this case differently now, but as of July it was not possible when the package's source code resides within the channel itself.

A more robust solution to this issue would be the implementation of a CI action to automatically update the package hash whenever new release happens. Having channel with -git version seems impossible.

[Yappaholic]

I think it would be better to reference git repository as a source instead of using git-fetch, you can check how quickshell does that: https://github.com/quickshell-mirror/quickshell/blob/master/quickshell.scm

That would prevent this repository from being used as a channel (see my MR to the Quickshell documentation). This is a significant limitation, because the entire purpose of adding a package definition to this repository is precisely to enable its use as a Guix channel.

To be honest, I have not verified whether Guix handles this case differently now, but as of July it was not possible when the package's source code resides within the channel itself.

A more robust solution to this issue would be the implementation of a CI action to automatically update the package hash whenever new release happens. Having channel with -git version seems impossible.

That's unfortunate. For example, nix flake will build from current git source instead of pinned version, which is more preferable IMO.

Also mango currently uses git version of scenefx (with some drawbacks introduced). I did bump scenefx version to 4.1 in Guix a while ago, but we would need to introduce with-latest transformation to scenefx input.

About CI: I am not sure when or even if we could introduce CI to the repo (I don't know GH Actions, not sure about @DreamMaoMao or other contributors, so it might take time), but it could benefit both nix and guix packages.

[ch4og]

Good news: the git version of quickshell can now be built as a Guix channel. A previous issue has been fixed.

The Quickshell channel approach is now functional with the latest Guix:

$ guix time-machine -C /tmp/channels.scm -- shell --container  --manifest=/tmp/quickshell.scm -- quickshell --version
quickshell 0.2.1, revision , distributed by: "In-tree Guix channel"

$ cat /tmp/channels.scm
  (list (channel
          (name 'guix)
          (url "https://git.guix.gnu.org/guix.git")
          (branch "master")
          (introduction
           (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
             "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
        (channel
         (name 'quickshell)
         (url "https://github.com/ch4og/quickshell")
         (branch "master")))
         
$ cat /tmp/quickshell.scm
(use-modules (quickshell)
             (gnu packages))

(packages->manifest
 (list quickshell-git))

I submitted a PR to quickshell to fix the modules error introduced by the recent package definition changes.

@4zv4l, are you planning to update your PR with an approach similar to the quickshell channel? The current package definition is still a work in progress, it needs to also override the default config path.

If you're no longer interested in working on this, I'd be happy to submit a new PR that implements that approach.

Also, a question for @Yappaholic regarding mango: I haven't looked into it deeply, but does Mango have a good way to set a default config path that can be overridden from a directory /etc/mango? On Guix, that directory is not writable. When I packaged the mwc compositor, it used an environment variable MWC_DEFAULT_CONFIG_PATH to set the default path, while mwc still giving preference to the config in XDG_CONFIG_HOME. Is there a similar mechanism for Mango?

If not I think we can patch source for Guix package.

[ch4og]

I would like to edit meson.build itself, but sadly in guix builder there is no /etc/os-release, so way like with Nix is not possible here

[ch4og]

The only way I found of knowing we are in guix builder is this env var.

[Yappaholic]

It is also possible to pass -Dc_args="-DSYSCONFDIR=$output" or CFLAGS="-DSYSCONFDIR=$output" but then meson puts its own variable (-DSYSCONFDIR="/etc") at the end of build.ninja instructions, so I don't know if that will work

[ch4og]

It is also possible to pass -Dc_args="-DSYSCONFDIR=$output" or CFLAGS="-DSYSCONFDIR=$output" but then meson puts its own variable (-DSYSCONFDIR="/etc") at the end of build.ninja instructions, so I don't know if that will work

Tried it and yes, flags appended at the end so it doesn't work

[Yappaholic]

Tried it and yes, flags appended at the end so it doesn't work

That is unfortunate. You should patch meson.build to remove line 75 and then pass -DSYSCONFDIR manually in configure phase

[ch4og]

Tried it and yes, flags appended at the end so it doesn't work

That is unfortunate. You should patch meson.build to remove line 75 and then pass -DSYSCONFDIR manually in configure phase

That's what I did in commit I linked above (ch4og@8a79830)

[ch4og]

Also there I am patching "sysconfdir = sysconfdir.substring\(prefix.length\(\)\)" to "" which is L20

mangowc/meson.build

Line 20 in 1b7e998

sysconfdir = sysconfdir.substring(prefix.length())

I am not very familiar with meson so I didn't really understand why there is error without such patch:

../source/meson.build:25:43: ERROR: Unknown method "length" in object <[OptionStringHolder] holds [OptionString]: '/gnu/store/5ng1q293abp4x9srib8y8yq532bmws68-mangowc-git'> of type OptionStringHolder.

As I understand it is not string for some reason, prefix is set by guix build system itself

[Yappaholic]

Also there I am patching "sysconfdir = sysconfdir.substring(prefix.length())" to "" which is L20

mangowc/meson.build

Line 20 in 1b7e998

sysconfdir = sysconfdir.substring(prefix.length())

I am not very familiar with meson so I didn't really understand why there is error without such patch:

../source/meson.build:25:43: ERROR: Unknown method "length" in object <[OptionStringHolder] holds [OptionString]: '/gnu/store/5ng1q293abp4x9srib8y8yq532bmws68-mangowc-git'> of type OptionStringHolder.

As I understand it is not string for some reason, prefix is set by guix build system itself

It is not because you treat an option like a string when you need to use get_option() or something

[4zv4l]

I guess that could be a nice feature but compared to "vanilla mango" why changing the config file location ? If it's to add it in the store, it's pretty easy (at least with Guix) with the dot-file home service.

[ch4og]

I guess that could be a nice feature but compared to "vanilla mango" why changing the config file location ? If it's to add it in the store, it's pretty easy (at least with Guix) with the dot-file home service.

That is required feature since mango will try to load default config from /etc/mango, which doesn't exist. Of course that doesn't matter in case user has config in ~/.config/mango, but we must point mangowc to correct store location of default config.

[ch4og]

To test this: If you will set HOME env var to random dir like /tmp you will boot into mango without any default keybinds and no way to even close it without accessing another tty/ssh

[4zv4l]

To test this: If you will set HOME env var to random dir like /tmp you will boot into mango without any default keybinds and no way to even close it without accessing another tty/ssh

Oh I havent thought of that indeed. I am also not very experienced with Guix packaging, I saw people doing magic with some packages but thats about it. I am not sure how to retrieve the store location of the config (in the package definition itself) and then to add it in place of the sysconfdir.

[ch4og]

To test this: If you will set HOME env var to random dir like /tmp you will boot into mango without any default keybinds and no way to even close it without accessing another tty/ssh

Oh I havent thought of that indeed. I am also not very experienced with Guix packaging, I saw people doing magic with some packages but thats about it. I am not sure how to retrieve the store location of the config (in the package definition itself) and then to add it in place of the sysconfdir.

If you are ok with this you can just pick and push my commit on your branch (ch4og@ef2f771) it is fully working like this

If you'd like to add my commit into your branch, here are the Git commands in case you need help with it:

git remote add ch4og https://github.com/ch4og/mangowc.git
git fetch ch4og
git cherry-pick ef2f7715237a1a78f7566243788059c6605060eb

[4zv4l]

done, thanks for the help ! 🙏

[ch4og]

Confirming it builds fine on currently latest guix commit

ch@noko ~$ guix time-machine -C /tmp/channels.scm -- build -m /tmp/manifest.scm
/gnu/store/3gyyphwrjgzl8jl3p4cqykq02ji9kqyz-mangowc-git

ch@noko ~$ cat /tmp/channels.scm
(list (channel
        (name 'mangowc)
        (url "https://github.com/4zv4l/mangowc")
        (commit "09e461f51df660066783505d16695a07fd3efc21")
        (branch "master"))
      (channel
        (name 'guix)
        (url "https://git.guix.gnu.org/guix.git")
        (branch "master")
        (commit "9436acc15cde742c08a1d45576780e0189dee504")
        (introduction
         (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad"
          (openpgp-fingerprint
           "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

ch@noko ~$ cat /tmp/manifest.scm
(use-modules (mangowc) (gnu packages))
(packages->manifest `(,mangowc-git))

Also I can confirm it does load default config from Guix store

For me it seems like this PR is ready to be merged now.

[Yappaholic]

Good job making Guix package work!

I can't test it right now (since I'm not running GuixSD), but the PR changes look good to me.

Also I need to mention that scenefx package in main Guix repositories is not updated that often, so if there would be compilation issues because of that, feel free to send a PR directly to https://codeberg/guix/guix.

[ch4og]

After looking at the package with fresh eyes, I noticed a couple of small improvements might be needed:

1. meson and ninja should be dropped from native-inputs, the build system already provides the correct versions automatically, and specifying them again can lead to conflicts in future.

2. wayland-protocols belongs in native-inputs, since it's only required during building and not at runtime.

For reference here is what it looks like: ch4og@0a6ed5c

(These aren't blockers at all)

[4zv4l]

After looking at the package with fresh eyes, I noticed a couple of small improvements might be needed:

1. `meson` and `ninja` should be dropped from native-inputs, the build system already provides the correct versions automatically, and specifying them again can lead to conflicts in future.

2. `wayland-protocols` belongs in native-inputs, since it's only required during building and not at runtime.

For reference here is what it looks like: ch4og@0a6ed5c

(These aren't blockers at all)

I did the change and tried to build and it worked, all good for now ?

[ch4og]

Package definition now looks perfect!

[Yappaholic]

Nice, Looks Good To Me