Re: LUKS2 support in Guix

[Oleg Pykhalov]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  writes:

> On Fri, Mar 01 2024, Fabio Natali wrote:
>
>> could it be worth to amend the manual to say that it has to be LUKS1
>
> Based on the many folks who trip over this, especially on IRC, that
> seems like a great idea!

I also lost some time due to this incorrect statement. Perhaps it would
be better to replace the LUKS creation step in the info manual with a
link to all the steps listed in gnu/tests/install.scm.


Regards,
Oleg.


signature.asc
Description: PGP signature

Re: Packaging Hyprland

[John Kehayias]

Hi Efraim,

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

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

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

On the xremap side, a service would be great, and luckily we have one
pending: .

John

Re: Packaging Hyprland

[John Kehayias]

Hi everyone,

Just a note on cairo below:

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

> Hi everyone,
>
> On Sun, 25 Feb 2024 08:32:27 +0800,
> Lucy Coleclough wrote:
>>
>>> On Sat, 24 Feb 2024 at 20:48, hutzdog  wrote:
>>>
[snip]
>>>  # New Patches
>>>  The following new patches will need to be created (I intend to submit these
>>>  at some point in the near future):
>>>  Cairo -> 1.18.0 (requires moving to Meson, I have a mostly complete set of
>>>  changes to make it work)
>
> I didn't take a closer look at cairo update, but yes, this may require some
> work, at least to be able to finish its tests.
>

I submitted the patches as 69495: 
It works for me locally in some limited tests (e.g. icecat).

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

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

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

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

John

Re: Contribute or create a channel?

[Ricardo Wurmus]

Hi Hartmut,

> I'm currently updating Tryton to version 7.0 and am wondering whether it's 
> better to contribute the change to Guix or to set up a
> channel for Tryton.
>
> WDYT? I'm eager to learn about your thoughts.
>
> Here is why I'm wondering:
>
> * Tryton consists of a client, a server and about 200 module/add-on providing 
> business logic.
> * Tryton publishes a LTS version every 2.5 years. Two LTS versions are 
> supported (currently 6.0 and 7.0) and bugfixes are backported
>  there for 5 years.

I think it would be preferable to have one LTS version in Guix.  If you
want to commit to maintaining the packages I think it would be worth
discussing whether to grant you commit rights to handle these upgrades
by yourself.

> OTOH in Guix, maintaining several version seems laborious.

What makes you say this?  What exactly is the obstacle here?

> Anyhow I'm unsure whether it's worth the effort maintaining three versions 
> and whether I'll be able to keep three version up to date -
> esp. given that I don't have much automation for this.

Personally, I don't think it makes sense to commit to maintaining there
separate versions.  It seems like a really big committment.

-- 
Ricardo

Re: Contribute or create a channel?

[Ricardo Wurmus]

Attila Lendvai  writes:

>> WDYT? I'm eager to learn about your thoughts.
>
> the patch inflow to the guix repo is currently overwhelming the
> available capacity for review and pushing.

With an email like the one sent by Hartmut we can better arrange for
shepherding this large submission.  (Nothing is to be gained from
repeatedly bemoaning well-known issues in the patch review processes
here and in other threads on the mailing list.)

-- 
Ricardo

Re: Guix Days: Patch flow discussion

[Attila Lendvai]

> Somehow, the reader will judge if Message-ID is smoothly supported. :-)


i regularly meet this most unfortunate attitude in the GNU circles, where 
oldtimers dismiss any discussion of friendlier defaults for newcomers with the 
"argument" that it's configurable, and therefore it's a non-issue.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The wise prince must provide in such a way that the citizens will always be in 
need of him and of his government.”
— Niccolo Machiavelli (1469–1527), 'The Prince' (1513)

Re: GNU and GSoC

[Pjotr Prins]

Thank you for the project idea. I will add it in.

More older proposals are listed here:

https://libreplanet.org/wiki/Group:Guix/GSoC-2023

any of these we want to submit again? New ideas welcome too!

I'll add the Guix-based build tool again (to replace autoconf and
friends) if nothing better comes along. Any Hurd ideas out there? How
about improved Guix support and test coverage?  Or Mes - Ekaitz? 

GSoC gives extra helpers.

Pj.

On Fri, Feb 23, 2024 at 06:15:39PM -0500, Kierin Bell wrote:
> 
> Hey Guix,
> 
> Pjotr Prins  writes:
> 
> > The GNU project is a GSoC org again. Last year Sarthak did a great job
> > working on parameterization of Guix. It works, and you can try the
> > code. See
> >
> > => https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix/
> > => https://blog.lispy.tech/
> >
> > For this year GNU can propose projects again. We should suggest Guix,
> > Mes and Hurd projects in the coming two weeks. Ping Gábor, Sarthak,
> > Arun, Efraim or me if you are interested in co-mentoring an effort.
> >
> 
> Please forgive my ignorance, but are non-mentors/prospective mentees
> allowed to suggest GSoC project ideas here?
> 
> I have been wanting to work on implementing a general purpose
> pretty-printing/formatting module for Guix that services (and Guix
> system, style, Home, etc.) could use to serialize their given
> configuration languages.  It would be better than manually formatting
> raw strings as is done now by most services.  Ludo' first broached the
> topic in a patch review[1].
> 
> The project feels to me like it would be much more attainable with
> advice from a seasoned Schemer/Guixer.  So a mentor-mentee program could
> be a good fit.
> 
> Again, I'm unsure exactly how this fits into the larger goals of the
> project.  I suspect that services-related stuff like this may be lower
> on the hierarchy of priorities.
> 
> [ Regardless, even if it turns out not to be a good fit for GSoC, I'd be
> delighted to work on this with a bit of help and advice as time
> allows. ]
> 
> Best,
> Kierin
> 
> [1]  https://issues.guix.gnu.org/64620#15

-- 

Re: Contribute or create a channel?

[Attila Lendvai]

> WDYT? I'm eager to learn about your thoughts.


the patch inflow to the guix repo is currently overwhelming the available 
capacity for review and pushing.

if you want an agile experience, i.e. where you can quickly fix/update this and 
that, then i suggest your own channel (unless you have the commit bit for the 
guix repo... or there's a committed maintainer who is a regular user, and as 
such will fast-track your patches).

otherwise you'll end up using a channel anyway (i.e. your fork of the guix repo 
while your patches are waiting in the queue to be reviewed and pushed).

PS: i don't mean to sound cynical here, just matter-of-factly.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Opportunity is missed by most people because it comes dressed in overalls and 
looks like work.”
— Thomas A. Edison (1847–1931)

Re: You're invited to the first patch review session!

[Suhail]

Tomas Volf <~@wolfsden.cz> writes:

> On 2024-02-22 23:27:31 +, Steve George wrote:
>> Hi
>>
>> We're going to run some online patch review sessions. The first one is on 
>> *Thursday, 7th March* and you can sign-up here:
>>
>>   https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024
>>
>> ...
>>
>> Each session will be hour 1:30 and they are rotating through the week, so 
>> there should be plenty of opportunities to come along. We're using the Guix 
>> London's Meet-up and the sessions run on Jitsi.
>
> Will the Jitsi link be shared somewhere (here, irc, ...) for those of us who 
> are
> not able to sign up on the page?

Could the Jitsi link also be shared on the mailing list and/or noted on
the libreplanet wiki?

-- 
Suhail

Re: Contribute or create a channel?

[Saku Laesvuori]

> I'm currently updating Tryton to version 7.0 and am wondering whether 
> it's better to contribute the change to Guix or to set up a channel for 
> Tryton.

As a general rule: it is always better to contribute a change instead of
maintaining a separate channel for it if the change could be accepted in
Guix.

>   * Bugfixes happens rather often and per-module, since they are
> published even for smaller fixes. Upstream promises to not contain
> functional changes or change requirements. Each bugfix could be
> implemented as a graft, since .

I don't think it would make much sense to implement bugfixes as grafts
if the package isn't depended on by a huge number of other packages.

> Given this, it might be interesting to have three versions of Tryton 
> available: the two LTS versions and the latest version.
> 
> Now the idea is to provide a channel which provides a branch for each 
> LTS version and a "main" branch for the latest release. This would allow 
> to checkout the respective branch and refresh the packages of the 
> respective version semi-automatically.
> 
> OTOH in Guix, maintaining several version seems laborious.

It just requires a different updating method. The different versions can
just be defined as separate packages (see postgresql for an example) and
the user the defines which one they want to use. They can either refer
to the package variable directly in scheme (e.g. postgresql-15) or on
the command line with the name@version syntax (e.g. postgresql@15).

> Some more background-info:
> 
>   * Within each version, there is guarantee that the database schema
> will not be changed. Anyhow between versions the db schema might
> change, requiring manual migration steps.

This is the case with postgresql, too. (which is why I chose it as the
example before)

- Saku


signature.asc
Description: PGP signature

Re: A friendlier API for operating-system declarations

[Hartmut Goebel]

Hi,

Am 19.02.24 um 23:25 schrieb antlers:

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


I'd appreciate such a mechanism, as it fits my mental model of how to 
compose a system out of reusable components (much like "roles" in 
Ansible resp. Debop).


--
Regards
Hartmut Goebel

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

Contribute or create a channel?

[Hartmut Goebel]

Hi,

I'm currently updating Tryton to version 7.0 and am wondering whether 
it's better to contribute the change to Guix or to set up a channel for 
Tryton.


WDYT? I'm eager to learn about your thoughts.

Here is why I'm wondering:

 * Tryton consists of a client, a server and about 200 module/add-on
   providing business logic.
 *

   Tryton publishes a LTS version every 2.5 years. Two LTS versions are
   supported (currently 6.0 and 7.0) and bugfixes are backported there
   for 5 years.

 *

   Every 6 month a new release is crafted (x.2, x.4, x.6, x,8) which
   will get bugfixes for1 year. Releases typically provide new modules
   (which is why updating is of interest) , might change inputs and
   might require database updates.

 * Bugfixes happens rather often and per-module, since they are
   published even for smaller fixes. Upstream promises to not contain
   functional changes or change requirements. Each bugfix could be
   implemented as a graft, since .

Given this, it might be interesting to have three versions of Tryton 
available: the two LTS versions and the latest version.


Now the idea is to provide a channel which provides a branch for each 
LTS version and a "main" branch for the latest release. This would allow 
to checkout the respective branch and refresh the packages of the 
respective version semi-automatically.


OTOH in Guix, maintaining several version seems laborious.

Anyhow I'm unsure whether it's worth the effort maintaining three 
versions and whether I'll be able to keep three version up to date - 
esp. given that I don't have much automation for this.


Some more background-info:

 * Within each version, there is guarantee that the database schema
   will not be changed. Anyhow between versions the db schema might
   change, requiring manual migration steps.
 * Debian as of now provides packages for 6.0 only (7.0 was released )


--
Regards
Hartmut Goebel

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

Re: Using gitlab-ci to maintain a channel?

[Hartmut Goebel]

Hi Ludo,

thanks for the answer. Looks like I need to go with Cuirass. But more 
probably I'll abandon the idea for now since its a spare-time project only.



--
Regards
Hartmut Goebel

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

Re: Simple design question for schemers

[Hartmut Goebel]

Hi both of you,

Am 25.02.24 um 11:05 schrieb Ricardo Wurmus:

We have a macro called MODIFY-INPUTS, which you could use, but CONS* is
probably enough in your case.


Thanks. I'm using cons* now.

cons* basically is the same the "extend" I'm used to from Python - sadly 
the Guile manual is so terrible to understand that I did not get that.



--
Regards
Hartmut Goebel

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

Bugs and Patches---or rather, bugs or patches?

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

Hi,

We track bugs and patches separately.  Does the distinction serve a
purpose?  May I combine them?

Thanks!

Kind regards
Felix

Re: LUKS2 support in Guix

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

Hi Fabio,

On Fri, Mar 01 2024, Fabio Natali wrote:

> could it be worth to amend the manual to say that it has to be LUKS1

Based on the many folks who trip over this, especially on IRC, that
seems like a great idea!

Kind regards
Felix

Re: A basic Shepherd bug?

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

Hi Attila,

On Fri, Mar 01 2024, Attila Lendvai wrote:

> you `guix system reconfigure` into a new shepherd version, and after
> that the currently running shepherd init process went 100% CPU,
> i.e. it was busy looping in one thread?

Yes, I used 'guix deploy.' I did so several times before noticing the
unusual load.

I don't usually reboot when changing services, but have to when adding
new ones.  I'm so lazy about it, sometimes it seems we should keep track
of kernel and Shepherd versions separately from other features of the
system. In effect, we would have two types of "system generations,"
namely:

  A. Kernel/PID 1 generation
  B. Features generation (not using the word "services" here)

> a quick and dirty solution

It was just a thought. Ideally, it would appear in a bug tracker so
someone can think about it with the benefit of hindsight later.

> interesting thoughts on migration and staged computation

I just wished for an alert when the code deployed as PID 1 had changed,
but no worries, please. There is so much to do.

Thanks for your (and Ludo's) hard work on the Shepherd. I love it!

Kind regards
Felix

Re: A basic Shepherd bug?

[Attila Lendvai]

hi Felix,


> > you should follow the instructions in [1]; namely:
> > 
> > https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00018.html
> > 
> > together with "Installing development snapshots with Guix" in
> > shepherd's README to add shepherd's channel.
> 
> 
> I did so on a production system which I do not reboot often. Two days
> ago, I reconfigured and saw a new Shepherd version being deployed. It
> used up a lot of CPU cycles until I rebooted.


just to clarify: you `guix system reconfigure` into a new shepherd version, and 
after that the currently running shepherd init process went 100% CPU, i.e. it 
was busy looping in one thread?


> It makes sense that upgrading the Shepherd requires a reboot, but maybe
> a warning somewhere would be appropriate, if possible. Maybe an email to
> root?


unfortunately a lot of the infrastructure around guix is lacking explicit 
formal description of dependencies/requirements. e.g. there's nothing (that i 
know of) in the shepherd config files (which are generated by `guix system 
reconfigure`) about what shepherd version they require/assume.

a quick and dirty solution here could be to manually emit an assert into the 
config file that there's an exact match between the shepherd that generated the 
config file, and the shepherd process trying to load it. a warning could be 
issued that the shepherd process is unable to load/process the generated config 
file until a reboot... which would probably be overkill in most cases.

https://ngnghm.github.io/

this^ blog has interesting thoughts on migration and staged computation. it's a 
most interesting vision of how these abstractions could be formally captured, 
and what the resulting computing system would look like.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Love and do what you will.”
— Augustine of Hippo (354–430), 'A sermon on love'

LUKS2 support in Guix

[Fabio Natali]

Hi ,

I wasn't able to use a LUKS2+PBKDF2 encrypted partition when setting up
a machine recently. I understand this isn't supported by the version of
GRUB currently shipped in Guix.

Basically, with a LUKS2+PBKDF2 drive, you get stuck at boot with no
chance for GRUB to detect the relevant partitions. Or, at least, that
was my experience with that setup.

The Guix manual would indicate that LUKS2 is actually supported, when
used in combination with PBKDF2⁰:

> Note that GRUB can unlock LUKS2 devices since version 2.06, but only
> supports the PBKDF2 key derivation function, which is not the default
> for cryptsetup luksFormat. You can check which key derivation function
> is being used by a device by running cryptsetup luksDump device, and
> looking for the PBKDF field of your keyslots.

If I'm right in thinking that LUKS2+PBKDF2 is not supported and there's
no clear timeline for a fix yet, could it be worth to amend the manual
to say that it has to be LUKS1 at this stage?

Glad to amend the manual in case, but I might as well be missing
something here, so I wanted to check with you first.

Thanks, best wishes, Fabio.


⁰ 
https://guix.gnu.org/manual/devel/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html#Disk-Partitioning


-- 
Fabio Natali
https://fabionatali.com