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

[hutzdog]

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

publickey - hutzdog@proton.me - 0xD0A768D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Packaging Hyprland

[Lucy Coleclough]

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

Re: (almost) deterministic patchsets

[Development of GNU Guix and the GNU System distribution.]

This is basically done in
https://git.sr.ht/~ngraves/dotfiles/commit/bd542512dfad2beccb4a6cdb2468f79aa869a55b

Maybe some things need some polish, but the PoC is definitely here.
Feel free to reuse this in upstream guix if you want.

On 2024-02-13 14:35, Nicolas Graves wrote:

> Hi !
>
> I've written this (gpl3+) that should be able to fetch patchsets for
> both guix and rde. This should be robust enough for guix/rde use IMO.
>
> (define-module (guix mbox-download)
>   #:use-module (guix packages)
>   #:use-module ((guix self) #:select (make-config.scm))
>   #:use-module (guix modules)
>   #:use-module (guix monads)
>   #:use-module (gnu packages guile)
>   #:use-module (gnu packages tls)
>   #:use-module (gnu packages version-control)
>   #:use-module (guix store)
>   #:use-module (guix gexp)
>   #:use-module (guix records)
>   #:export (mbox-fetch
> mbox-reference))
>
> (define-record-type* 
>   mbox-reference make-mbox-reference
>   mbox-reference?
>   (type mbox-reference-type)
>   (id mbox-reference-id)
>   (version mbox-reference-version))
>
> (define* (mbox-fetch ref hash-algo hash #:optional name
>  #:key (system %current-system) guile)
>
>   (define uri
> (format
>  #f
>  (assoc-ref
>   '((gnu . 
> "https://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=~a;mbox=yes;)
> (rde . "https://lists.sr.ht/~~abcdw/rde-devel/patches/~a/mbox;))
>(mbox-reference-type ref))
>  (mbox-reference-id ref)))
>
>   (define modules
> (cons `((guix config) => ,(make-config.scm))
>   (delete '(guix config)
>   (source-module-closure '((guix build download)
>(guix build utils))
>
>   (define build
> (with-extensions (list guile-json-4 guile-gnutls)
>   (with-imported-modules modules
> #~(begin
> (use-modules (guix build utils) (guix build download))
> (let ((mbox #$(match-record ref 
> (type id version)
> (format #f "~a-~a-~a.mbx" type id version
>   (setenv "TMPDIR" (getcwd))
>   (setenv "XDG_DATA_HOME" (getcwd))
>   (invoke #$(file-append b4 "/bin/b4")
>   "-d" "-n" "--offline-mode" "--no-stdin"
>   "am" "--no-cover" "--no-cache"
>   "--use-local-mbox"
>   (url-fetch #$uri "mbox" #:verify-certificate? #f)
>   "--use-version"
>   (number->string #$(mbox-reference-version ref))
>   "--no-add-trailers"
>   "--outdir" "."
>   "--mbox-name" mbox)
>   (install-file mbox #$output))
>
>   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
>   system)))
> (gexp->derivation (or name
>   (match-record ref 
> (type id version)
> (format #f "~a-~a-~a-mbox" type id version)))
>   build
>   ;; Use environment variables and a fixed script name so
>   ;; there's only one script in store for all the
>   ;; downloads.
>   #:system system
>   #:local-build? #t ;don't offload repo cloning
>   #:hash-algo hash-algo
>   #:hash hash
>   #:recursive? #t
>   #:guile-for-build guile)))
>
>
> This can be used in such an example :
>
> (use-modules (guix mbox-download) (guix packages) (guix gexp)
>  (guix monads) (guix store) (guix derivations))
>
> (with-store store
>   (run-with-store store
> (mlet* %store-monad
> ((drv (origin->derivation
>(pk 'o (origin
> (method mbox-fetch)
> (uri (mbox-reference
>   (type 'rde)
>   (id 44893)
>   (version 4)))
> (sha256
>  (base32 
> "1rs09wxvdaxrk2zh6g23s9min76wjm9lw0a5pjklc7cfraasi7s9")))
>   (return drv
>
> Is guix interested in this, should I send a patch? What about renaming
> this to patchset-reference instead of mbox-reference?
>
> My end-goal here is to use this to extend channels to channels with
> patches, with something like this :
>
> (define* (instantiate-channel ch)
>   (match ch
> ((name url ref patches)
>  (primitive-eval
>   `(channel
> (name ',name)
> ,@(if (null? patches)
>   `((url ,(find-home url)))
>   `((url ,(patched-source
>(symbol->string name)
>(git-checkout
> (url (find-home url))
> (commit ref))
>(search-patches patches)
> ,@(if ((@ (guix git) commit-id?) ref)
>   `((commit ,ref))
>   `((branch ,ref)))
>  

Re: Packaging Hyprland

[hutzdog]

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

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

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

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

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

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

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

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.



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

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

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  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: Supporting sssd, preparing for nscd sunset

[Picnoir]

Hey Guix, Ludovic,

Some context: Flokli (CCd) and I are fighting the same issue on the
NixOS side.

There's two aspects in this migration story:

1. the daemon-side. IE. how to make sure a daemon is available on most
   distros to respond to the nscd socket
2. the client-side. IE. how to make sure we'll still have access to the
   glibc stubs sending queries to the daemon socket on the foreseeable
   future.

Let's talk about the daemon side first. As I was mentionning in the blog
post linked above, NixOS moved to Nsncd, a non caching re-implementation
of Nscd.

> I don’t see it helpful on other distros, at least not until/unless it
> becomes widespread. (We can’t really ship ourselves because it has to
> be linked against the host libc.)

Nsncd is already available in Debian[1] and Arch[2] (AUR). In reality,
some dowstreams, like Arch, are not distributing nscd anymore[3].
Meaning the only way to run Nix/Guix binaries on Arch without breaking
PAM is to go through Nsncd at the moment.

So, on the daemon side, on the long run, for us, the solution would be
to package Nsncd to Ubuntu and Fedora. We'd love to share that effort
with the Guix community.

Let's address the elephant in the room: Nsncd is written in Rust. I know
that language is not the most loved among the Guix crowd due to its
bootstrapping story. But looking at the amazing work Efraim put into the
toolchain, I don't think this should be a show stopper for Guix. We're
likely to get more Rust in core system parts in the future anyways.

Now, if you folks decide to part ways (sad), unscd[4] would likely be a
better starting point to implement a uncaching nscd daemon than the
current nscd implementation.

--

Client-side. There's two aspects to it:

1. keep the nscd stubs, hopefully without any patches in Glibc.
2. improve the current protocol.

For the stubs, let's take the worst-case scenario for us: upstream
decides to remove them. It seems like Carlos O'Donell[5] is up to
provide some guidance and support into hiding them behind a feature flag
and keep them in Glibc instead. So, even in our worst-case scenario, it
seems like we'll be okay-ish. We'll still need to put some people-hours
into it though.

>From my perspective, the current protocol is not entirely satisfactory.
Implementing it in Nsncd was clearly no fun. But even besides this
aspect, it's currently not good enough for IPv6.

>From the nscd protocol perspective, an IPv6 address is a serie of 16
octets. This is a fine representation for global and ULA addresses.
However, it's not good enough to fully qualify a link-local addresses:
you also need the scopeid (ie. interface id/interface name) that comes
with it .

This means that IPv6 local link-local addresses resolution is currently
broken for Guix/Nix programs. Such a resolution is sadly heavily used
in IPv6 mdns setups.

My point being: if we plan to keep using this nscd trick on the long run
(we currently do), and we end up doing a massive refactoring on the
Glibc side to hide the stubs, then it might be a good occasion to make
some improvements to the protocol itself at the same time. And who
knows, maybe we could make the bold move of redisiging altogether this
protocol.

For these protocol improvements, I definitely think our two communities
should sync and share notes.

Wow, that was long, sorry for the wall of text :)
Don't hesitate to Cc me and flokli for these Nscd discussions in the
future!

Picnoir

[1]: https://packages.debian.org/search?keywords=nsncd
[2]: https://aur.archlinux.org/packages/nsncd-git
[3]: 
https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/blob/main/PKGBUILD?ref_type=heads#L53
[4]: https://github.com/bytedance/unscd
[5]: https://fosstodon.org/@codonell/111981707970893154

Packaging Hyprland

[hutzdog]

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

publickey - hutzdog@proton.me - 0xD0A768D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: A friendlier API for operating-system declarations

[antlers]

Hi!

Just wanted to say that I really admire your take on end-user service 
configuration in the Beaver Labs channel.

I gravitated towards composing functions over `operating-systems` myself, 
though my config is probably only ""notable"" for the moderately-cursed 
`modify-record` macro that I use to derive/configure/wrap the services[1]:

```
(define (os-with-yubi parent users*)
  (modify-record parent
(groups -> (cons (user-group (name "plugdev")) <>))
(users  -> (map (lambda (user)
  (if (member (user-account-name user)
  users*)
  (modify-record user
(supplementary-groups -> (cons "plugdev" <>)))
  user))
<>))
(services => (append <> (list
  (service pcscd-service-type)
  (simple-service 'u2f-udev-rules udev-service-type
  (list (specification->package "libu2f-host")))
  (simple-service 'yubi-udev-rules udev-service-type
  (list (specification->package 
"yubikey-personalization"
```

It's like if `modify-services` was generalized over any kind of record, but 
instead of using pre-defined verbs like `remove`, the `body` component of each 
`(field-name -> body)` clause is wrapped in an implicit SRFI-26 `cut`-like[2] 
form to create an anonymous function that's applied to the field's value. It's 
a super leaky abstraction because I use a different symbol for `->` depending 
on whether that record-field is a plain value, a thunk, or a `delay`-ed form 
(and it could be implemented more efficiently), but it greatly reduces the 
length and indentation level of repeatedly nested, inherited record variations.

```
((compose os-with-yubi
  [...])
   [operative-system])
```

I only wrote a handful of top-level `operating-system transformation` 
functions, and IIRC I only composed them at that top level; I think the way 
that you've broken them up into smaller forms and composed them out of each 
other though deeper, standard-functional composition gives you that same 
additive benefit over would-be nested forms, with each definition roughly 
matching up to one my "anonymous" invocations.

What I still dwell on is whether there's a way to further minimize the 
code-volume of including additional functionality (as was pondered in a prior 
response, and as `modify-record` does in obsoleting `modify-services`'s verbs), 
and how best to avoid order-dependencies and expose inherit 
inter-service-configuration dependencies and conflicts. Tropin's RDE uses an 
emacs or systemd-esque `provides`/`requires` system which is satisfying, but 
introduces implicit standardization on the symbols associated with software 
roles and builds a significant graph of them, which I feel adds to the "bulk" 
of the (still very elegant) solution and embraces the need to wrap every 
service and transformation into their cohesive system-- that's part of what's 
kept me on plain Guix with my bandaid-solutions (in the spirit of learning the 
standard approach before exploring larger systems built on top of it).

Anyway, I like your take, just fount it today and got to thinking-- thanks for 
putting it out there~

1: From: 
https://github.com/AutumnalAntlers/old-guix-config/blob/main/modules/antlers/systems/transformations/yubi.scm
2: Like `cut`, but deeper: see the `<>` symbol nested deep within in the 
`users` clause of the Yubi example.

Re: A friendlier API for operating-system declarations

[antlers]

Oh, thank you! Don't study too closely-- I'm quite the novice myself,
having come upon your work in search of better solutions, and the
drawbacks I described are rather notable; but I appreciate that you
see what I was going for.

(I'd be much happier with it if I could interrogate `(guix record)`
structures for the `plain | thunked | delayed` distinction and hide
that from the user, as that's what really prevents me from
recommending wider use, but understanding of the module eludes me.)

On Mon, Feb 19, 2024, at 5:53 PM, Edouard Klein wrote:
> This is awesome. I need to study your macro to understand how you wrote
> it. I've only written a handful of macro in my life, and came to lisp
> via common lisp, from which I've learned quite a lot apprently bad
> habits, so I'm lost in scheme-land.
>
> I'll study your system, thant _you_ for your reply !
>
> Cheers,
>
> Edouard.
>
>
> antlers  writes:
>
>> Hi!
>>
>> Just wanted to say that I really admire your take on end-user service 
>> configuration in the Beaver Labs channel.
>>
>> I gravitated towards composing functions over `operating-systems` myself, 
>> though
>> my config is probably only ""notable"" for the moderately-cursed 
>> `modify-record`
>> macro that I use to derive/configure/wrap the services[1]:
>>
>> ```
>> (define (os-with-yubi parent users*)
>>   (modify-record parent
>> (groups -> (cons (user-group (name "plugdev")) <>))
>> (users  -> (map (lambda (user)
>>   (if (member (user-account-name user)
>>   users*)
>>   (modify-record user
>> (supplementary-groups -> (cons "plugdev" <>)))
>>   user))
>> <>))
>> (services => (append <> (list
>>   (service pcscd-service-type)
>>   (simple-service 'u2f-udev-rules udev-service-type
>>   (list (specification->package "libu2f-host")))
>>   (simple-service 'yubi-udev-rules udev-service-type
>>   (list (specification->package 
>> "yubikey-personalization"
>> ```
>>
>>
>> It's like if `modify-services` was generalized over any kind of record, but
>> instead of using pre-defined verbs like `remove`, the `body` component of 
>> each
>> `(field-name -> body)` clause is wrapped in an implicit SRFI-26 `cut`-like[2]
>> form to create an anonymous function that's applied to the field's value. 
>> It's a
>> super leaky abstraction because I use a different symbol for `->` depending 
>> on
>> whether that record-field is a plain value, a thunk, or a `delay`-ed form 
>> (and
>> it could be implemented more efficiently), but it greatly reduces the length 
>> and
>> indentation level of repeatedly nested, inherited record variations.
>>
>> ```
>> ((compose os-with-yubi
>>   [...])
>>[operative-system])
>> ```
>>
>> I only wrote a handful of top-level `operating-system transformation` 
>> functions,
>> and IIRC I only composed them at that top level; I think the way that you've
>> broken them up into smaller forms and composed them out of each other though
>> deeper, standard-functional composition gives you that same additive benefit
>> over would-be nested forms, with each definition roughly matching up to one 
>> my
>> "anonymous" invocations.
>>
>> What I still dwell on is whether there's a way to further minimize the
>> code-volume of including additional functionality (as was pondered in a prior
>> response, and as `modify-record` does in obsoleting `modify-services`'s 
>> verbs),
>> and how best to avoid order-dependencies and expose inherit
>> inter-service-configuration dependencies and conflicts. Tropin's RDE uses an
>> emacs or systemd-esque `provides`/`requires` system which is satisfying, but
>> introduces implicit standardization on the symbols associated with software
>> roles and builds a significant graph of them, which I feel adds to the 
>> "bulk" of
>> the (still very elegant) solution and embraces the need to wrap every service
>> and transformation into their cohesive system-- that's part of what's kept 
>> me on
>> plain Guix with my bandaid-solutions (in the spirit of learning the standard
>> approach before exploring larger systems built on top of it).
>>
>> Anyway, I like your take, just fount it today and got to thinking-- thanks 
>> for putting it out there~
>>
>> 1: From: 
>> https://github.com/AutumnalAntlers/old-guix-config/blob/main/modules/antlers/systems/transformations/yubi.scm
>> 2: Like `cut`, but deeper: see the `<>` symbol nested deep within in the 
>> `users` clause of the Yubi example.

Re: Google Season of Docs 2024

[Adam McCartney]

Hi Simon,

First, apologies for being a bit late to the party here!


2. Would one of you readers be interested by being technical writer?
3. Any for improving the documentation?


I'm quite new to guix, so reading through many docs for the first time and
trying out various workflows. I'm taking notes on the various things that work.
Happy to help with this in any way I can!

In the past I've enjoyed using tutorials like "vimtutor" or emacs' "M-x
help-with-tutorial" when trying to break the ice with a completely new piece of
software. Writing something similar for guix might be fun?



Last, keep in mind the deadline is less than 10 days from now.
1: https://developers.google.com/season-of-docs/docs/project-ideas
2: https://developers.google.com/season-of-docs/docs/case-study-example
3: https://developers.google.com/season-of-docs/docs/2022/participants


Maybe I'm not reading this correctly, but it looks like the application window
opened yesterday, 22nd February and will close for organizations on the 2nd
April 2024?


--
 Adam McCartney - https://admccartney.mur.at 
/

Building container images with nix2container

[Antoine Eiche]

Hello Guix,

Two years ago, i released nix2container [1], a Go library and binary to
build container images from Nix expressions.
However, this Go code is not tightly coupled with Nix and has been
designed to potentially work with Guix [2]!

nix2container offers the following main features:
- It uses a layering algorithm to group storepaths into layers [3]
- It avoids writing an image tarball in your Guix store (reduce IOs and storage)

Basically, to build a container image, nix2container relies on two steps:
1. The nix2container Go binary takes the reference graph [4]
   of the container image closure to generates a JSON file describing
   the image configuration and the layers.
2. This JSON file can then be consumed by a patched Skopeo version[5] to
   build or push an image [8].

In case you would like to try nix2container with Guix, in theory, you
would need to add the support of another input reference graph format
[6] and a write simple Guix derivations [7] calling the nix2container
binary.

Hoping it could be useful,
lewo.

[1] https://github.com/nlewo/nix2container
[2] 
https://github.com/nlewo/containers-image-nix/blob/e342762cf7274dd7449343f3488723898da63f00/nix/utils.go#L55
[3] https://grahamc.com/blog/nix-and-layered-docker-images/
[4] 
https://nixos.org/manual/nix/stable/language/advanced-attributes.html?highlight=exportReferencesGraph#adv-attr-exportReferencesGraph
[5] 
https://github.com/nlewo/containers-image-nix/blob/9d7f33ef0058f4df4c0912025f43c758a3289d76/default.nix#L31
[6] 
https://github.com/nlewo/containers-image-nix/blob/9d7f33ef0058f4df4c0912025f43c758a3289d76/data/closure-graph.json#L1
[7] 
https://github.com/nlewo/containers-image-nix/blob/9d7f33ef0058f4df4c0912025f43c758a3289d76/default.nix#L305
[8] 
https://github.com/nlewo/containers-image-nix/blob/9d7f33ef0058f4df4c0912025f43c758a3289d76/default.nix#L47

Re: Supporting sssd, preparing for nscd sunset

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hello Guix!
>
> Distros are increasingly relying on sssd, in particular Fedora and
> derivatives, as a replacement for nscd, which is either unavailable or
> deprecated.  The documented interface of Guix binaries to the host’s
> name service switch (NSS) is currently nscd:
>
>   
> https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Name-Service-Switch
>
> If sssd becomes dominant, we
> might just as well arrange to have NSS always load libnss_sss.so.
>
> Thoughts?

With nscd removed from glibc, can't we assume foreign distributions will
rely on sssd instead?  Do I understand correctly that the above
(configuring NSS to always load libnss_sss.so) would be a fine
replacement for our use of nscd?  If so, that seems the simplest/best
option to pursue to me.

-- 
Thanks,
Maxim

Re: February update on the Guile guix-daemon

[Ludovic Courtès]

Hello!

Thanks for the update!

Christopher Baines  skribis:

>  - Then there's the big areas to work on next:
>
>- I think I'm going to need to use thread pools for SQLite operations
>  in the daemon, as the build coordinator does.

I think we should refrain from using POSIX threads directly and instead
use Fibers to its full extent.  In this case, I’d use a resource pool as
done in Cuirass (and in the Coordinator too, no? maybe that’s what you
meant?).

>- There's the low level work of setting up the build environment, the
>  work on the guile-daemon branch helps a lot with this, but as
>  pointed out by Ludo, there might be some issues with fork and
>  similar operations in a Guile program using threads.

Right.  I think one of the things we discussed in Brussels is that,
since SQLite operations might block for a while, the daemon will have to
be multithreaded.  Which means no fork/clone, which in turn probably
means delegating forking/cloning to a separate helper process.  (That’s
also what bubblewrap does, IIUC.)

>- While I've implemented some of the server side protocol used by the
>  daemon, I'd like to extract that code in to a module so that it's
>  not wrapped up inside the daemon script

Wo0t!

Cheers,
Ludo’.

Re: [Cuirass] JavaScript work

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> I noticed that Cuirass bundles minified JavaScript.  I’ve started a new
> branch that replaces the minified JavaScript with readable source code
> and minifies the files as part of the build.
>
> I also tried to remove the need for jQuery, at least in our own
> JavaScript code.  (Datatables.js still uses jQuery.)
>
> Eventually, I’d like to remove Bootstrap (both CSS and JS) all together
> and switch to Pico.css for conventional default styles without the need
> for bootstrap classes everywhere.  I’d like to remove JS for thing that
> HTML+CSS can do just fine.
>
> (Pico is also used in mumi.)
>
> What do you think?

I’m all for it.  Thanks a lot for working on it!

Ludo’.

Re: Using gitlab-ci to maintain a channel?

[Ludovic Courtès]

Hi Hartmut!

Hartmut Goebel  skribis:

> I wonder whether it's possible to maintain a channel using gitlab-ci. Any 
> thought or experiences to share?

[...]

> * What version of guix shall be used? Always the latest one?

That’s the main conceptual issue: GitLab-CI only knows about the repo
it’s tracking, it doesn’t realize that whether the code therein builds
fine depends on the ‘guix’ channel.

To get that level of precision, you would need Cuirass, which is what we
use at work and for various scientific channels:
.

Now, GitLab integration is appealing, so it would still be nice to do CI
with a fixed revision of Guix, which you would occasionally manually
update.  It’s a tradeoff.

> * The runners need a docker image. Where to I get one? Possibly containing a 
> warmed-up cache? (Using a Debian docker image and
>  installing guix into it on every run sounds like a bad idea.)

As I mentioned on help-guix a few days (weeks?) ago, I haven’t found a
way to build such an image with Guix, but I’d like to find one!

Another option is to use, say, Debian as the base image, and to install
Guix on top of it.

> * OTOH /gnu/tore could be cached. How much data would this typically be?
> * How to clean the cache from unreachable items?
> * How to publish the substitutes?

I don’t think you could publish substitutes in that setup, unless
GitLab-CI offload builds to an actual machine that has ‘guix publish’
running on it.

HTH,
Ludo’.

Re: Debugging missing architecture support

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

> The problem in that case seems to be cross-compilation. The dependency
> of python-jupyterlab that fails to build is libwebp, whose build log
> says:
>
>@ unsupported-platform 
> /gnu/store/7fj9ckgxw27r196vkisc9cm3n8v9072x-libwebp-1.3.2.drv aarch64-linux
>while setting up the build environment: a `aarch64-linux' is required to
>build `/gnu/store/7fj9ckgxw27r196vkisc9cm3n8v9072x-libwebp-1.3.2.drv',

This shows an attempt to compile libwebp natively for aarch64-linux,
which fails on your machine.

To cross compile, you would run:

  guix build python-jupyterlab --target=aarch64-linux-gnu

… but I doubt this would succeed because that’s a huge pile of packages.

Ludo’.

Re: ice-9 match penalty depending on pattern?

[Ludovic Courtès]

Hey,

Simon Tournier  skribis:

> Re ‘match’ penalty: when using ellipses in patterns, the generated
> code checks for “proper lists”, which is O(n).  The trick is to
> instead match a pair:
>
> ✔ (match lst ((head . tail) …))
> ❎ (match lst ((head tail ...) …))

To clarify, my message should not be understood as “never use ellipses
in ‘match’ patterns”.

Whether using ellipses is a “penalty” depends on the context.  In some
cases I use ellipses anyway because it’s more accurate, more pleasant to
the eye, because the input list is small, and/or because this is not
performance-critical code.

Having a disjoint type for proper lists would avoid this problem, as I
mentioned on the Fediverse, but we’re not there yet…

Ludo’.

Re: Core-updates coordination and plans

[Ludovic Courtès]

Hello!

Josselin Poiret  skribis:

> Thanks for the feedback!  So in the meantime I chose to go ahead and try
> with 2.39 (how hard could it be?).

I’m glad you did that; at the same time, I feel like it’s delayed the
merge.  Maybe in the future we need a calendar-based schedule for
‘core-updates’ to help make decisions like this?

> Should commencement's guile-final be a minimal version of Guile without
> libcrypt, while guile-3.0 includes it?  Do we want to be able to use
> (crypt ...) in g-exps?  I don't really know what the answer to those
> questions should be, but it probably involves a world rebuild :(.
> Anyone have an idea/opinion about this conundrum?

As discussed on IRC, the ‘crypt’ procedure is documented in the Guix
manual as a way to provide an initial user account password, so it “has
to” be available in ‘guile-final’.

> Other than that, I think that branch is in a pretty ok shape, I've also
> included a couple of patches that were requested.

Yay!

Ludo’.

Re: Simple design question for schemers

[Hilton Chain]

Hi Hartmut,

On Sat, 24 Feb 2024 21:47:41 +0800,
Hartmut Goebel wrote:
>
> Hi,
>
> I'm about to refactor the Tryton packages to the (not so) new style. Now the 
> trytond-xxx modules all share a basic list of native
> inputs,like this:
>
> (native-inputs
>  `(,@(%standard-trytond-native-inputs)
>("trytond-account-fr" ,trytond-account-fr)
>("trytond-edocument-uncefact" ,trytond-edocument-uncefact)))
>
> Now I wonder what would be the most scheme-like way for doing this in new 
> style?
>
> Using "apply list":
>
> (native-inputs (apply list
>   trytond-account-fr
>   trytond-edocument-uncefact
>   %standard-trytond-native-inputs ))
>
> Using "append":
>
> (native-inputs (append %standard-trytond-native-inputs
>(list trytond-account-fr
>  trytond-edocument-uncefact)))
>
> Using a custom function "extend":
>
> (native-inputs
>  (extend %standard-trytond-native-inputs
>  trytond-account-invoice
>  trytond-purchase
>  trytond-sale))
>
> Using a custom function "@trytond-module-native-inputs":
>
> (native-inputs (@trytond-module-native-inputs
> trytond-account-invoice
> trytond-purchase
> trytond-sale))
>
> Opinions?

You may want to use ‘cons*’:
--8<---cut here---start->8---
(cons* trytond-account-fr
   trytond-edocument-uncefact
   %standard-trytond-native-inputs)
--8<---cut here---end--->8---


Thanks

Simple design question for schemers

[Hartmut Goebel]

  
  
Hi,
I'm about to refactor the Tryton packages to the (not so) new
  style. Now the trytond-xxx modules all share a basic list of
  native inputs,like this:
    (native-inputs
   `(,@(%standard-trytond-native-inputs)
     ("trytond-account-fr" ,trytond-account-fr)
     ("trytond-edocument-uncefact"
  ,trytond-edocument-uncefact)))

Now I wonder what would be the most scheme-like way for doing
  this in new style?
Using "apply list":

    (native-inputs (apply list
    trytond-account-fr
    trytond-edocument-uncefact
    %standard-trytond-native-inputs ))
Using "append":

    (native-inputs (append %standard-trytond-native-inputs
     (list trytond-account-fr
   trytond-edocument-uncefact)))

Using a custom function "extend":

    (native-inputs
   (extend %standard-trytond-native-inputs
   trytond-account-invoice
   trytond-purchase
   trytond-sale))
Using a custom function "@trytond-module-native-inputs":

    (native-inputs (@trytond-module-native-inputs
      trytond-account-invoice
      trytond-purchase
      trytond-sale))

Opinions?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |