Re: RISCV porting effort

[Christopher Lemmer Webber]

Exciting... thanks for this update!  Even if not "usable" quite yet,
it's thrilling to see progress on this. :)


Efraim Flashner writes:

> Last week my HiFive Umatched¹ board came and was quite the object of
> interest at the local computer store as I picked up a case, PSU and
> graphics card.
>
> Couple of observations about the board first:
> It boots very slowly. I think it takes about 5 minutes from power-on to
> being able to sign in at TTY1.
> It has an NVMe slot which I haven't populated yet.
> Ubuntu has an image for the board² which booted up just fine and I'm
> using, since I didn't want to spend too long getting Debian to run on
> the board.
> Upstream u-boot support was merged days ago³ so we should be able to add
> support to our u-boot package soon-ish™.
>
> Porting Guix comes with two parts: building the bootstrap-tarballs and
> adding support for the new architecture in (gnu packages bootstrap).
> Support for riscv was added to GCC with 7.1.0 so I had to bump the
> bootstrap GCC to 7 (and adjust some inputs), and guile-2.0.14 didn't
> known the endianness of riscv64 so instead of patching it I bumped the
> bootstrap guile to 3.0. I uploaded my bootstrap-tarballs to my regular
> spot after signing them and switched over to the riscv machine.
>
> Building Guix from sources is much easier thanks to the work of Vagrant,
> I was able to apt install most of the dependencies on riscv. The
> packaged version of guile-zlib was too old in 21.04 so I built that from
> source (0.1.0 is available in Debian experimental), and I also had to
> build gnutls from source for the guile-3.0 bindings. I added the riscv
> binaries to (gnu packages bootstrap) and temporarily switched the
> raw-build function to look for 3.0 guile libraries instead of 2.0.
>
> Where I'm at right now:
> Downloading using the daemon (builtin:download) fails currently, it says
> it doesn't have permissions to open-file to write downloaded files to
> the store.
> I haven't built anything using the bootstrap binaries to see if they
> actually work yet.
>
>
> (ins)efraim@unmatched:~$ neofetch --off
> efraim@unmatched
> 
> OS: Ubuntu 21.04 riscv64
> Host: SiFive HiFive Unmatched A00
> Kernel: 5.11.0-1007-generic
> Uptime: 3 days, 15 hours, 57 mins
> Packages: 782 (dpkg)
> Shell: bash 5.1.4
> Terminal: /dev/pts/0
> CPU: (4)
> GPU: NVIDIA GeForce GT 730
> Memory: 350MiB / 15995MiB
>
> (ins)efraim@unmatched:~$ lscpu
> Architecture:riscv64
> Byte Order:  Little Endian
> CPU(s):  4
> On-line CPU(s) list: 0-3
> Thread(s) per core:  4
> Core(s) per socket:  1
> Socket(s):   1
> L1d cache:   32 KiB
> L1i cache:   32 KiB
> L2 cache:2 MiB
>
>
> ¹https://www.sifive.com/boards/hifive-unmatched
> ²http://cdimage.ubuntu.com/releases/21.04/release/
> ³https://source.denx.de/u-boot/u-boot/-/commit/d8729a114e1e98806cffb87d2dca895f99a0170a

Re: What’s next?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Hi,
>
> Off the top of my head:
>
> - Optimize the man page database update during profile builds.
>
> - File search.
>
>   (I did work on it a year ago, it's stuck, would need help from people
>   familiar with Cuirass.)

That sounds interesting.  What does it mean?  Would it help me figure
out which commands come from which package?

A feature I remember being cool they had enabled by default on Ubuntu
back in the day was:

  $ crawl-tiles
  Not found.  Maybe "sudo apt-get install crawl-tiles"?

So for us:

  $ crawl-tiles
  Not found.  Maybe "guix package -i crawl-tiles"?

The curious thing about this though... it seems to require knowledge of
the *outputs*.

To invoke this manually, a user could type:

  # Queries curiass or some sort of build system, similar to guix weather
  $ guix search --binary crawl-tiles
  Found in:
   - crawl-tiles

> - A GUI.
>
>   https://gitlab.com/daym/guix-gui.git seems to be a good starting point.

Oh wow!  I'm going to give this a try.

> Maxim Cournoyer  writes:
>
>> * Add .deb and .rpm formats for 'guix pack'.
> [...]
>> * guix environment --fhs (file hierachy standard)
>
> Oh my, awesome ideas!!!  (These 2 in particular.)
>
> Cheers!

I'll add one that I *should* finish: I should get the setuid stuff
done.  IIRC it's like, two minor tweaks away from being done and
bitrotting... I've been busy...

Maybe I could do it towards the end of the following week?  Would be
good to get the damned thing done... and then finally get postfix in,
too.

Re: Changes to the branching workflow

[Christopher Lemmer Webber]

zimoun writes:

> Hi, Chris,
>
> On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber 
>  wrote:
>
>> I wonder if we should formalize it.  What about adding a section to the 
>> "Contributing" section of the manual explaining what the different
>> branches are, and when you have a patch that's been approved, when to
>> push it to which branch?
>
> Do you mean something like #8 in [1] and then [2]?
>
> 1: <https://guix.gnu.org/manual/en/guix.html#Submitting-Patches>
> 2: <https://guix.gnu.org/manual/en/guix.html#Commit-Access>
>
> In [2], it reads:
>
> For patches that just add a new package, and a simple one, it’s
> OK to commit, if you’re confident (which means you successfully
> built it in a chroot setup, and have done a reasonable copyright
> and license auditing). Likewise for package upgrades, except
> upgrades that trigger a lot of rebuilds (for example, upgrading
> GnuTLS or GLib).
>
> which I understand as: the ’staging’ or ’core-update’ patches should go
> to guix-patches and not be pushed directly.  Especially when one has
> commit access and does not follow closely enough to know the status of
> the very branch.

I don't think the quoted part fully answered it, but the following part
does answer it:

 Depending on the number of dependent packages and thus the amount
 of rebuilding induced, commits go to different branches, along
 these lines:

 300 dependent packages or less
  ‘master’ branch (non-disruptive changes).

 between 300 and 1,800 dependent packages
  ‘staging’ branch (non-disruptive changes).  This branch is
  intended to be merged in ‘master’ every 6 weeks or so.
  Topical changes (e.g., an update of the GNOME stack) can
  instead go to a specific branch (say, ‘gnome-updates’).

 more than 1,800 dependent packages
  ‘core-updates’ branch (may include major and potentially
  disruptive changes).  This branch is intended to be merged in
  ‘master’ every 6 months or so.

I guess I hadn't read that part of the manual.  Oops!  So it does seem
well answered.  Good!

 - Chris

Re: Changes to the branching workflow

[Christopher Lemmer Webber]

Hello,

As someone who jumps in and out of Guix development occasionally but who
does have commit access (probably for grantparented-in reasons, heh),
sometimes I don't know where I should commit code or what the current
branching policy is, and I might miss emails like this.

I wonder if we should formalize it.  What about adding a section to the 
"Contributing" section of the manual explaining what the different
branches are, and when you have a patch that's been approved, when to
push it to which branch?

I think that would help me, and maybe it would help others.  Thoughts?

 - Chris

Leo Famulari writes:

> Based on experiences with the last "staging" cycle and discussions at
> the most recent Guix Day meeting [0], we've changed the branching
> workflow.
>
> The default branch names remain "core-updates" and "staging".
>
> When we begin actively building and testing the branches, they will be
> renamed to "core-updates-frozen" and "staging-frozen", respectively.
>
> This will indicate that they are closed to any changes except for bug
> fixes and merges of the master branch.
>
> During those periods, new patches can be pushed to "core-updates-next"
> and "staging-next".
>
> Hopefully these changes will clarify the status of the branches and
> reduce confusion.
>
> [0] https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00163.html

Re: Potential security weakness in Guix services

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> I think it’s a good endeavor, but it’s a longer-term one since it’ll
> take some time before this new version is in use by all the Guix code.
>
> The difficulty in designing such an interface is that the Scheme API is
> more about ports than it’s about file names and file descriptors.
>
> Thanks!
>
> Ludo’.

In the long run, that might end up being safer.
In the meanwhile, we suffer the world of ACLs. ;)

(From my read, this is practically exactly the scenario from Norm
Hardy's original Confused Deputy paper...)

Re: Guix in Debian!

[Christopher Lemmer Webber]

This.  Is.  Huge.

THANK YOU for all your hard work here!

I wrote out why I think this is big news:

  https://octodon.social/@cwebber/105612900114421037

Vagrant Cascadian writes:

> So, a while back I mentioned that Guix was present in Debian
> "experimental":
>
>   https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00254.html
>
> And it was useable for a brief window of time, but was broken due to
> some issues with guile-gnutls and guile-3.0:
>
>   https://bugs.debian.org/964284
>
> Somewhat deterred, I back-burnered it for a while while I focused on
> other things...
>
>
> Just a few days ago, I decided to attempt to get Guix into Debian's next
> release, and went with the fallback plan of building it against
> guile-2.2, and a few disabled tests later...
>
>   https://tracker.debian.org/guix
>
>
> If all goes well, it should migrate to "bullseye" in a few
> days. Hopefully in a few months "bullseye" will become Debian's stable
> release shipping with guix! Presumeably Guix will also eventually find
> itself in Ubuntu and other Debian derivatives...
>
>
> Now on Debian you should be able to:
>
>   apt install guix
>   guix install dpkg
>   guix environment --ad-hoc dpkg -- dpkg -i ./guix_1.2.0-3_amd64.deb
>
> It is almost like symmetry!
>
>
> Thanks for all the help and encouragement along the way, everyone!
>
>
> live well,
>   vagrant

Re: Setuid programs

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> I've attached a patch that includes my plan for the setuid stuff.  I
> could submit this to guix-patches I suppose if that would be better.
> But I wonder if I should actually just rebase the wip-postfix on top of
> master, apply this, and then start working on setting up postfix to make
> use of it.

I changed my mind since the setuid stuff is more general, is not blocked
by the postfix work.  Thus bug #44700 is tracking this.

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi!
>
> Christopher Lemmer Webber  writes:
> [...]
>> It sounds like you're already putting together the work to do it.  If
>> you don't mind doing it that would save me a lot of time right
>> now... I'm quite swamped!  I'd be very grateful!
>
> No problem, I just didn't want to end up with two reports for the same
> issue.  It's already open as <https://bugs.gnu.org/44698>.
>
>>>[...]
>> I've pushed the fix to master.  I also did the setq-local thing as
>> another commit.
>
> Thanks.
>
>> However, since Miguel is the one submitting the upstream report, I left
>> a TODO item to link to that once done.  Miguel, do you mind committing
>> that once done?
>
> Pushed the update for the TODO line to master as
> 3428c66c5a4d5f1a5fd2f1ad4cd3105993ae8e6d.

Great, thank you! :)

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Miguel Ángel Arruga Vivas writes:
>
>> I haven't reported it yet, but as you can see I have a reproducer script
>> attached.  I haven't seen anything in vc-code that points in that
>> direction, surely though Emacs people will have a better understanding.
>>
>> Christopher, would you mind to CC me if you open the bug?  I can do it
>> too if you tell me to, but I don't want to create a duplicate entry if
>> we do it roughly at the same time.
>
> It sounds like you're already putting together the work to do it.  If
> you don't mind doing it that would save me a lot of time right
> now... I'm quite swamped!  I'd be very grateful!
>
>> Apart from the tracking reference, I agree that it's worth applying it.
>> And also, thank you both for making easier to work on guix. :-)
>
> Okay cool; since you two have already basically reviewed this code I'll
> just make the suggested change and push it to the master branch.  Thank
> you!

I've pushed the fix to master.  I also did the setq-local thing as
another commit.

However, since Miguel is the one submitting the upstream report, I left
a TODO item to link to that once done.  Miguel, do you mind committing
that once done?

Re: Setuid programs

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Ludovic Courtès writes:
>
>> Hi,
>>
>> Gábor Boskovits  skribis:
>>
>>> I have two reasons for that: backwards compatibility is really
>>> important, so we should not break it, and I believe this would not be
>>> hard to do.
>>> On the other hand it would be nice to have a more integrated backend,
>>> and move as many things into the services infrastructure as practical,
>>> and I think this is a good candidate for that. Wdyt?
>>
>> There’s already ‘setuid-program-service-type’.  I think the way forward
>> would be to:
>>
>>   1. Define the  record type you propose.
>>
>>   2. Have ‘setuid-program-service-type’ accept that through its
>>  extensions.  When it receives something else, it should
>>  transparently turn it into a  record, for backward
>>  compatibility, and emit a deprecation warning.
>>
>>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>>  records.
>>
>> How does that sound?
>>
>> Thanks,
>> Ludo’.
>
> This sounds like a good plan.  I'm taking a stab at it, but there's a
> good chance I'll get it wrong, so review will be seriously needed.
> Let's find out how I do!

I've attached a patch that includes my plan for the setuid stuff.  I
could submit this to guix-patches I suppose if that would be better.
But I wonder if I should actually just rebase the wip-postfix on top of
master, apply this, and then start working on setting up postfix to make
use of it.

What do you think of this approach?

>From cab9f7c017fb2ea0c8dc80084c3c269fa8e85378 Mon Sep 17 00:00:00 2001
From: Christopher Lemmer Webber 
Date: Sun, 15 Nov 2020 16:58:52 -0500
Subject: [PATCH] services: setuid: More specific setuid support.

New record  with fields for setting the specific user and
group, as well as specifically selecting the setuid and setgid bits, for a
program within the setuid-program-service.

* gnu/services.scm (): New record type.
  (setuid-program, make-setuid-program, setuid-program?)
  (setuid-program-program, stuid-program-setuid?, setuid-program-setgid?)
  (setuid-program-user, setuid-program-group): New variables, export them.
  (setuid-program-entry): New variable, a procedure used for the
  service-extension of activation-service-type as set up by
  setuid-program-service-type.  Unpacks the  record,
  handing off within the gexp to activate-setuid-programs.
  (setuid-program-service-type): Make use of setuid-program-entry.
* gnu/build/activation.scm (activate-setuid-programs): Update to expect a
  ftagged list for each program entry, pre-unpacked from the 
  record before being handed to this procedure.
---
 gnu/build/activation.scm | 40 
 gnu/services.scm | 49 +---
 2 files changed, 67 insertions(+), 22 deletions(-)

diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index 4b67926e88..a2bdfd5aa5 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -229,13 +229,6 @@ they already exist."
 (define (activate-setuid-programs programs)
   "Turn PROGRAMS, a list of file names, into setuid programs stored under
 %SETUID-DIRECTORY."
-  (define (make-setuid-program prog)
-(let ((target (string-append %setuid-directory
- "/" (basename prog
-  (copy-file prog target)
-  (chown target 0 0)
-  (chmod target #o6555)))
-
   (format #t "setting up setuid programs in '~a'...~%"
   %setuid-directory)
   (if (file-exists? %setuid-directory)
@@ -247,18 +240,27 @@ they already exist."
  stringhttps://bugs.gnu.org/38800>.
-  (format (current-error-port)
-  "warning: failed to make '~a' setuid-root: ~a~%"
-  program (strerror (system-error-errno args))
+  (for-each (match-lambda
+  [('setuid-program src-path setuid? setgid? uid gid)
+   (catch 'system-error
+ (lambda ()
+   (let ((target (string-append %setuid-directory
+"/" (basename src-path)))
+ (mode (+ #o0555   ; base permissions
+  (if setuid? #o4000 0); setuid bit
+  (if setgid? #o2000 0 ; setgid bit
+ (copy-file src-path target)
+ (chown target uid gid)
+ (chmod target mode)))
+ (lambda args
+   ;; If we fail to create a setuid program, better keep going
+   ;; so that we don't leave %SETUID-DIRECTORY empty or
+   ;; half-populated.  Thi

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi Maxim and Christopher,
>
> Maxim Cournoyer  writes:
>>[...]
>> Christopher Lemmer Webber  writes:
>> [...]
>>> I figured out what was happening!  The bug is *technically* in vc-mode.
>>> However, nontheless it manifested here...
>>>
>>> Here's what happened.  vc-mode has some various hacks, as you can see
>>> above with "hack-local-variables-apply"... which traverses the dirlocals
>>> stuff.  (Not sure what the purpose is, didn't look too long.)
>
> The file where these functions are located is lisp/files.el, right on
> the Emacs core.  Some modes add hooks there, like flyspell or cc, but
> not vc, so I don't really think the problem is exclusive from that mode
> after some debugging.
>
> This code ends up in file-local-variables-alist, even though
> dir-local-variables-alist contains the correct values for some reason I
> still don't really understand.
>
>>> However for whatever reason, vc-mode also seems to be reusing buffers
>>> such as `*vc-diff*'... and somehow still is left in the directory
>>> context it *first* was used in.
>
> This may be the culprit but I think it isn't the issue, as
> file-local-variables-alist accumulates every eval marked as nil, not
> only the first/last one... when it fails, as we've seen.
>
>>> Thus if I C-x v = in a guix-oriented buffer first, and then switch to
>>> another completely different project and do the same, it's loading the
>>> dirlocals from Guix(...)
>>>
>>> This is clearly a bug in vc-mode, I'll try to report it as such.
>
>> Thank you for the investigation.  I'd be really happy if you could
>> report the problem upstream (M-x report-emacs-bug) aznd link to it here!
>
> I haven't reported it yet, but as you can see I have a reproducer script
> attached.  I haven't seen anything in vc-code that points in that
> direction, surely though Emacs people will have a better understanding.
>
> Christopher, would you mind to CC me if you open the bug?  I can do it
> too if you tell me to, but I don't want to create a duplicate entry if
> we do it roughly at the same time.

It sounds like you're already putting together the work to do it.  If
you don't mind doing it that would save me a lot of time right
now... I'm quite swamped!  I'd be very grateful!

>> [..] Miguel had written in IRC at the time of the initial report, but
>> to no avail.
>
> Maxim, could you test the script to check if we can narrow the cases?
> It shows the README in the emacs it opens, so it should be
> straight-forward.
>
>>> In the meanwhile, I used this hacky "fix".  Maybe worth applying for the
>>> moment... what do you think of it?
>>
>> I'd like to have the upstream bug linked in that fix rather than the
>> Guix one; that way it'll be possible to track upstream resolution and
>> know when the workaround can be removed.
>
> Apart from the tracking reference, I agree that it's worth applying it.
> And also, thank you both for making easier to work on guix. :-)

Okay cool; since you two have already basically reviewed this code I'll
just make the suggested change and push it to the master branch.  Thank
you!

Re: Setuid programs

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hi,
>
> Gábor Boskovits  skribis:
>
>> I have two reasons for that: backwards compatibility is really
>> important, so we should not break it, and I believe this would not be
>> hard to do.
>> On the other hand it would be nice to have a more integrated backend,
>> and move as many things into the services infrastructure as practical,
>> and I think this is a good candidate for that. Wdyt?
>
> There’s already ‘setuid-program-service-type’.  I think the way forward
> would be to:
>
>   1. Define the  record type you propose.
>
>   2. Have ‘setuid-program-service-type’ accept that through its
>  extensions.  When it receives something else, it should
>  transparently turn it into a  record, for backward
>  compatibility, and emit a deprecation warning.
>
>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>  records.
>
> How does that sound?
>
> Thanks,
> Ludo’.

This sounds like a good plan.  I'm taking a stab at it, but there's a
good chance I'll get it wrong, so review will be seriously needed.
Let's find out how I do!

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi Christopher,
>
> First of all I want to say sorry: I've tested this and reviewed the
> patch, and this is the second issue that already has caused, so yes, my
> tests weren't enough at all.
>
> Christopher Lemmer Webber  writes:
>
>> Also, I hope this email isn't interpreted as being dismissive or negative
>> about what looks like it's probably a real usability improvement for
>> hacking on Guix!  I just thought my experience indicated maybe there are
>> additional considerations to address.
>
> At least from my side I see your report as something positive, I cannot
> see how could it be negative at all, and I'd like to thank you for it.
>
>> Christopher Lemmer Webber writes:
>>> I'm a bit unsure what the implications fully are with this change, but
>>> here was my user experience:
>>>
>>>  - Did a pull using magit to guix
>
> I use magit too, so I guess this isn't the source of the error.
>
>>>  - Suddenly every file I open in Guix is prompting me if I want to
>>>enable these dir-locals, I notice some have "eval" and I don't know
>>>what it's doing so I say no
>
> Saying no here shouldn't be a problem, as the variables should always be
> optional.
>
>>>  - But it's asking me every file
>
> If every file means "every file on guix project" that should be the
> normal behavior of Emacs for .dir-locals.el since this file was
> introduced long before the patch: you can mark the 'eval' lines to be
> accepted, or to be rejected always, but they're loaded with each file.
> A problem could be that the UI shows the ones you have already accepted
> too, and simply marks with * the new ones.
>
> If it means "every other file too", I'm unable to reproduce that with a
> fresh Emacs session.
>
>>>  - And oh no, it's asking me about ten times for every magit operation!
>>>(Presumably due to the reload operation.)  Fine okay fine, YES, okay
>>>cool it's quiet now... I hope that was safe.
>
> The only effects of the new code should be:
>
>   * First eval: Set guix-directory for emacs-guix to the folder where
> .dir-locals.el is located.  This affects the whole emacs-guix, but
> AFAIU this isn't your issue.
>
>   * Second eval:
> - Make geiser-guile-load-path buffer-local, and optionally define it
>   as empty if it was void.
> - Add the directory where .dir-locals.el is located to
>   geiser-guile-load-path.
>
>>> Later...
>>>
>>>  - I'm hacking on another file in another repo
>>>  - C-x v = (check to see a diff of the work-in-progress changes of the
>>>file I'm working on)
>
> Thanks, with that I reproduce the problem, but I cannot debug it right
> now.  I'll be available in some hours, as soon as I have anything I'll
> update about this.
>
>>>  - Error in the minibuffer!  "Wrong type argument: stringp, nil"
>>>  - wtf, okay M-x toggle-debug-on-error
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>>   expand-file-name(nil)
>>>   (let* ((root-dir (expand-file-name (locate-dominating-file 
>>> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
>>> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
>>> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
>>> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
>>> #'string-equal))
>>>   eval((let* ((root-dir (expand-file-name (locate-dominating-file 
>>> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
>>> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
>>> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
>>> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
>>> #'string-equal)))
>>>   hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
>>> (locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
>>> (directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
>>> (defvar geiser-guile-load-path 'nil)) (make-local-variable 
>>> 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
>>> geiser-guile-load-path :test #'string-equal)))
>>>   hack-local-variables-apply()
>>>   hack-dir-local-variables-non-file-buffer()
>>>   diff-mode()
>>>   vc-diff-internal(t (Git 
>>> ("/home/cwebber/devel/scribble/scribble-lib/scribble...&quo

Re: Guix now in Debian experimental!

[Christopher Lemmer Webber]

This!  Is!  Awesome!

I think Guix in Debian could be huge and help both massively.  Well,
I've said so more than once in the past.  I believe it!  What's easy to
package in one tends to be easy to package in the other.  Just imagine
if we encouraged more developers using Debian as their host OS to use
"guix environment" (or eventually "guix shell") for their development
environments instead of one million incompatible language package
managers!

Vagrant Cascadian writes:

> It's been a long haul getting all the build dependencies of guix into
> Debian, but it has finally paid off:
>
>https://tracker.debian.org/pkg/guix
>
> So now you can install guix from Debian's experimental distribution!
>
> It is not well tested, in fact, I had to disable many tests, because in
> Debian it is a policy violation to download from the network during a
> build, but unlike guix, the policy is not necessarily enforced in any
> technical way!
>
> Many of the tests call out to the network in one way or another... So,
> this lead to:
>
>   Support GUIX_DISABLE_NETWORK_TESTS environment variable
>   https://issues.guix.gnu.org/44491
>
> Though I since learned about RES_OPTIONS=attempts:0 to disable name
> resolution in glibc instead, still working on refactoring tests/*.sh to
> make use of some common functions.
>
>
> There are many tests that make use of bootstrap binaries which attempt
> to download them during running the tests, despite networking not being
> available. I have patched these tests to also not run when the network
> is unreachable:
>
>   https://salsa.debian.org/debian/guix/-/tree/debian/devel/debian/patches
>
> My guess is these bootstrap binaries are available as inputs during the
> guix package builds of guix?
>
>
> I've also patched out a few tests that seemed non-deterministic, and a
> few that were simply inscrutible as to why they failed. Probably need to
> file bugs about those at some point... :)
>
>
> I also switched the packages to only run the tests in series, just in
> case parallelism was triggering issues with the tests:
>
>   https://issues.guix.gnu.org/21097
>
>
> In all, this ends up disabling about 200 out of 1100 tests in the Debian
> packages. I will explore another option to run those tests outside of
> the build, where network can be used, against the installed package
> using:
>
>   https://ci.debian.net
>
>
> It actually builds on both amd64 and i386 with some of the above
> mentioned tests disabled:
>
>   https://buildd.debian.org/status/package.php?p=guix=experimental
>
> On armhf (ARMv7), it successfully built, but failed some test suites
> that passed on amd64/i386.
>
> On armel (ARMv4t?), where it probably shouldn't even attempt to build,
> it failed in the same way it failed on armhf...
>
> On arm64, guile-gnutls isn't available for guile-3.0, so it cannot
> build:
>
>   https://bugs.debian.org/966714
>
> An alternative would be to build guix against guile-2.2, which has
> guile-gnutls, although I did manage to find... more test suite failures
> on guile-2.2 (tests/lint.scm), including one which seemed to run
> indefinitely(tests/swh.scm), an infinitely thorough test!
>
> If the guile-gnutls issues do not get sorted out soon, building against
> guile-2.2 is a plausible backup plan for getting guix 1.2 into the next
> Debian release (speculated to be released mid 2021)...
>
>
> For other architectures, it would require considerably more courage,
> though there has been work on a few of those architectures in guix
> recently (e.g. hurd-i386, mips64el, powerpc, ppc64, ppc64el, and even
> talk of riscv64).  Would it be interesting to run guix on one of the
> more exotic architectures, Debian GNU/kFreeBSD? :)
>
>
> Well, thanks for reading the status update from your entirely unofficial
> Debian-Guix or Guix-Debian ambassador.
>
>
> live well,
>   vagrant

Re: Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber 
> writes:
>
>> Dimos Dimakakos writes:
>>
>>> Bonface M. K. writes:
>>>
>>>> To simply put it, AFAIU updating a package would
>>>> require racket to update it's references(either
>>>> links, and other references that I won't go into),
>>>> hence creating some form of "global state";
>>>> thereby if you use raco, every package updated
>>>> would lead to some update with racket's search
>>>> paths or dirs somewhere. Any ideas to overcome
>>>> this wall? (or anything I've got wrong somewhere?)
>>>
>>> This was one of the main problems that I also encountered when working
>>> on this. racket2nix solves this by generating a temporary environment
>>> (by coping most of the racket folders and the deps needed as writable
>>> folders) where it installs with raco and then tries to update the global
>>> state of racket.
>>>
>>> To be honest this solution is kinda hacky and also slow, but I couldn't
>>> think of another one at the time I tried to work on the issue. It's a
>>> reality that the racket install system is quite stateful and also many
>>> operations seem to try to touch files. Installing with raco for example
>>> will try to recompile the dependencies of the new package and other such
>>> examples.
>>>
>>> Anyway, I hope you can find a way to move this forward!
>>
>> I wonder if it would be a good idea to copy many of the points from this
>> email and the parent to racket-users or racket-dev and see if someone
>> more familiar with the structure of the system can provide guidance from
>> there?
>>
>
> This is a good idea IMHO. I'll go ahead and do
> this. Perhaps there's something more important
> we've missed or aren't seeing.
>
>> If we have to go the racket2nix route, it would be better than nothing I
>> guess.
>>
>
> Yeah. I'm considering going though this route as a
> last resort. I don't understand the nix DSL
> syntax(though it reads alot like Haskell!).
>
>> Another possible route: don't use the Racket installer tooling.
>> Instead, read the info.rkt file of the package to understand what raco
>> *probably would* do, and then do it in a more Guix way instead.
>>
>> What do you think of that route?
>
> I've considered doing this... studying raco's source and seeing how it
> actually does and sets up things. I'd rather do this than the above,
> but it would take more time and would lead to alot more boiler plate I
> think... I'm not entirely sure about how to work around the global
> state though...

Regarding the boilerplate, not sure it needs to from a
package-definitions perspective... if the info.rkt can be read in the
general case, this could be the racket-build-system that does most of
the work (probably even by reading the very same info.rkt) rather than
it being output'ed from an importer definition.

> First, let's consult with the racket-devel and racket-user ML and see
> what those communities have to suggest...

Yes, good idea.

Re: Racket packages / build system

[Christopher Lemmer Webber]

Dimos Dimakakos writes:

> Bonface M. K. writes:
>
>> To simply put it, AFAIU updating a package would
>> require racket to update it's references(either
>> links, and other references that I won't go into),
>> hence creating some form of "global state";
>> thereby if you use raco, every package updated
>> would lead to some update with racket's search
>> paths or dirs somewhere. Any ideas to overcome
>> this wall? (or anything I've got wrong somewhere?)
>
> This was one of the main problems that I also encountered when working
> on this. racket2nix solves this by generating a temporary environment
> (by coping most of the racket folders and the deps needed as writable
> folders) where it installs with raco and then tries to update the global
> state of racket.
>
> To be honest this solution is kinda hacky and also slow, but I couldn't
> think of another one at the time I tried to work on the issue. It's a
> reality that the racket install system is quite stateful and also many
> operations seem to try to touch files. Installing with raco for example
> will try to recompile the dependencies of the new package and other such
> examples.
>
> Anyway, I hope you can find a way to move this forward!

I wonder if it would be a good idea to copy many of the points from this
email and the parent to racket-users or racket-dev and see if someone
more familiar with the structure of the system can provide guidance from
there?

If we have to go the racket2nix route, it would be better than nothing I
guess.

Another possible route: don't use the Racket installer tooling.
Instead, read the info.rkt file of the package to understand what raco
*probably would* do, and then do it in a more Guix way instead.

What do you think of that route?

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Ludovic Courtès  ezt írta (időpont: 2020. szept. 16., Sze, 
> 15:25):
>>
>> Hi,
>>
>> Gábor Boskovits  skribis:
>>
>> > I have two reasons for that: backwards compatibility is really
>> > important, so we should not break it, and I believe this would not be
>> > hard to do.
>> > On the other hand it would be nice to have a more integrated backend,
>> > and move as many things into the services infrastructure as practical,
>> > and I think this is a good candidate for that. Wdyt?
>>
>> There’s already ‘setuid-program-service-type’.  I think the way forward
>> would be to:
>>
>>   1. Define the  record type you propose.
>>
>>   2. Have ‘setuid-program-service-type’ accept that through its
>>  extensions.  When it receives something else, it should
>>  transparently turn it into a  record, for backward
>>  compatibility, and emit a deprecation warning.
>>
>>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>>  records.
>>
>> How does that sound?
>
> Sounds good to me. I will have a look.
>
>>
>> Thanks,
>> Ludo’.
>
> Best regards,
> g_bor

Hi!  It's been a bit since progress has been made on this, and I wonder
if I can help?

Getting Postfix included in Guix is my last step before moving my main
servers from Debian -> Guix so I'm feeling motivated. ;)

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi Christopher,
>
> First of all I want to say sorry: I've tested this and reviewed the
> patch, and this is the second issue that already has caused, so yes, my
> tests weren't enough at all.
>
> Christopher Lemmer Webber  writes:
>
>> Also, I hope this email isn't interpreted as being dismissive or negative
>> about what looks like it's probably a real usability improvement for
>> hacking on Guix!  I just thought my experience indicated maybe there are
>> additional considerations to address.
>
> At least from my side I see your report as something positive, I cannot
> see how could it be negative at all, and I'd like to thank you for it.

Thanks.  I don't have time to fully respond inline to your comments
right now, but I appreciate the emails and work of both you and Maxim.
Thank you both, and glad we haven't had a miscommunication where we
mistakenly thought we were at odds. :)

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Also, I hope this email isn't interpreted as being dismissive or negative
about what looks like it's probably a real usability improvement for
hacking on Guix!  I just thought my experience indicated maybe there are
additional considerations to address.

Christopher Lemmer Webber writes:

> Maxim Cournoyer writes:
>
>> Hello Guix!
>>
>> I've been experimenting with the following modification to the
>> .dir-locals file shipped with Guix, that allows setting per-buffer
>> variables within Emacs when visiting a file in the same directory (or in
>> one of its sub-directories).
>>
>> This makes life a bit easier, by ensuring that a Geiser REPL started
>> with C-c C-a in a file of either the main 'guix' checkout, a
>> 'guix-core-updates' worktree or a 'guix-staging' worktree will set up
>> the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH correctly (via the
>> `geiser-guile-load-path' Elisp variable).
>>
>> The only requirement for it to work reliably is that any Guix checkout
>> or worktree name should start with "guix".
>>
>> It doesn't require Geiser to be installed (it will just set the above
>> variable uselessly if it isn't used -- not a big deal).
>>
>> What do you think?  Is it useful?  Should we include this as part of the
>> default .dir-locals of Guix?
>>
>> Patch to follow!
>>
>> Thanks,
>>
>> Maxim
>
> I'm a bit unsure what the implications fully are with this change, but
> here was my user experience:
>
>  - Did a pull using magit to guix
>  - Suddenly every file I open in Guix is prompting me if I want to
>enable these dir-locals, I notice some have "eval" and I don't know
>what it's doing so I say no
>  - But it's asking me every file
>  - And oh no, it's asking me about ten times for every magit operation!
>(Presumably due to the reload operation.)  Fine okay fine, YES, okay
>cool it's quiet now... I hope that was safe.
>
> Later...
>
>  - I'm hacking on another file in another repo
>  - C-x v = (check to see a diff of the work-in-progress changes of the
>file I'm working on)
>  - Error in the minibuffer!  "Wrong type argument: stringp, nil"
>  - wtf, okay M-x toggle-debug-on-error
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil)
>   (let* ((root-dir (expand-file-name (locate-dominating-file 
> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
> #'string-equal))
>   eval((let* ((root-dir (expand-file-name (locate-dominating-file 
> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
> #'string-equal)))
>   hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
> (locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
> (directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
> (defvar geiser-guile-load-path 'nil)) (make-local-variable 
> 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
> geiser-guile-load-path :test #'string-equal)))
>   hack-local-variables-apply()
>   hack-dir-local-variables-non-file-buffer()
>   diff-mode()
>   vc-diff-internal(t (Git 
> ("/home/cwebber/devel/scribble/scribble-lib/scribble...")) nil nil t)
>   vc-diff(nil t)
>   funcall-interactively(vc-diff nil t)
>   call-interactively(vc-diff nil nil)
>   command-execute(vc-diff)
>  
>  - Oh... it's whatever thing I enabled earlier in the guix repo.  Well
>now my vc-diff is broken outside of there... :\
>
> I'm presuming that if I understood whatever this is doing, it's probably
> something that gives me a better user experience if I accept it while
> working on Guix.  But a) for whatever reason Emacs' dir-locals stuff is
> written in such a way that it antagonizes me for not accepting it and I
> didn't know what it eval was (maybe this is a lack of understanding in
> how to "say no and get it to listen to me"... I didn't resist for too
> long) and b) it seems like this change isn't scoped to Guix's checkout
> itself somehow...

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Maxim Cournoyer writes:

> Hello Guix!
>
> I've been experimenting with the following modification to the
> .dir-locals file shipped with Guix, that allows setting per-buffer
> variables within Emacs when visiting a file in the same directory (or in
> one of its sub-directories).
>
> This makes life a bit easier, by ensuring that a Geiser REPL started
> with C-c C-a in a file of either the main 'guix' checkout, a
> 'guix-core-updates' worktree or a 'guix-staging' worktree will set up
> the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH correctly (via the
> `geiser-guile-load-path' Elisp variable).
>
> The only requirement for it to work reliably is that any Guix checkout
> or worktree name should start with "guix".
>
> It doesn't require Geiser to be installed (it will just set the above
> variable uselessly if it isn't used -- not a big deal).
>
> What do you think?  Is it useful?  Should we include this as part of the
> default .dir-locals of Guix?
>
> Patch to follow!
>
> Thanks,
>
> Maxim

I'm a bit unsure what the implications fully are with this change, but
here was my user experience:

 - Did a pull using magit to guix
 - Suddenly every file I open in Guix is prompting me if I want to
   enable these dir-locals, I notice some have "eval" and I don't know
   what it's doing so I say no
 - But it's asking me every file
 - And oh no, it's asking me about ten times for every magit operation!
   (Presumably due to the reload operation.)  Fine okay fine, YES, okay
   cool it's quiet now... I hope that was safe.

Later...

 - I'm hacking on another file in another repo
 - C-x v = (check to see a diff of the work-in-progress changes of the
   file I'm working on)
 - Error in the minibuffer!  "Wrong type argument: stringp, nil"
 - wtf, okay M-x toggle-debug-on-error

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  (let* ((root-dir (expand-file-name (locate-dominating-file default-directory 
".dir-locals.el"))) (root-dir* (directory-file-name root-dir))) (unless (boundp 
'geiser-guile-load-path) (defvar geiser-guile-load-path 'nil)) 
(make-local-variable 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew 
root-dir* geiser-guile-load-path :test #'string-equal))
  eval((let* ((root-dir (expand-file-name (locate-dominating-file 
default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
(require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
#'string-equal)))
  hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
(locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
(directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
(defvar geiser-guile-load-path 'nil)) (make-local-variable 
'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
geiser-guile-load-path :test #'string-equal)))
  hack-local-variables-apply()
  hack-dir-local-variables-non-file-buffer()
  diff-mode()
  vc-diff-internal(t (Git 
("/home/cwebber/devel/scribble/scribble-lib/scribble...")) nil nil t)
  vc-diff(nil t)
  funcall-interactively(vc-diff nil t)
  call-interactively(vc-diff nil nil)
  command-execute(vc-diff)
 
 - Oh... it's whatever thing I enabled earlier in the guix repo.  Well
   now my vc-diff is broken outside of there... :\

I'm presuming that if I understood whatever this is doing, it's probably
something that gives me a better user experience if I accept it while
working on Guix.  But a) for whatever reason Emacs' dir-locals stuff is
written in such a way that it antagonizes me for not accepting it and I
didn't know what it eval was (maybe this is a lack of understanding in
how to "say no and get it to listen to me"... I didn't resist for too
long) and b) it seems like this change isn't scoped to Guix's checkout
itself somehow...

Re: Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber 
> writes:
>
> [...]
>
>>> Can I volunteer on this task? There's some work in
>>> my team done in Racket; and it would be of great
>>> interest to us to have a working Racket build
>>> system. I can set apart some time to work on
>>> this. I'd ask for alot of guidance/ review on this
>>> though :)
>>
>> YES!  Please do.  Let's talk.  You can ping me on IRC also, dustyweb on
>> freenode.
>>
>
> Thanks! I'm called bonz060 on FreeNode; though nowadays I've
> grown to be an e-mail person.
>
> [...]
>
>>> Please do share the notes! I can try to hack
>>> something up \m/\m/.
>>
>> I looked at the email that Dimos sent to me (also the email I had was
>> apparently not the most recent email that they are using, corrected in
>> the addressing this time), and they had asked me if they should post it
>> to the mailing list, so I think that's consent to post it since they
>> expressed consideration in doing so in our exchange... so I'm attaching
>> it.
>>
>
> [...]
>
> Thanks for the notes. I've skimmed through them
> and they seem sensible. I'll look at how other
> build systems are written as a first step, then
> get my hands wet.
>
> Do I open an issue for this---I can't see anything
> that tracks this even in archived issues--- then
> send patches there? Or do I send patches off the
> list and then submit the final drafts(if we get
> there) on the list later?

That sounds like a great plan!

Re: Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber 
> writes:
>
>> Bonface M. K. writes:
>>
>>> Christopher Lemmer Webber  writes:
>>>
>>>> Just a heads up that right now you *can* run Racket-on-Chez, but soon
>>>> Racket-on-Chez will be the "default"... maybe it's a good idea to see
>>>> how hard it will be to make a racket-on-chez package variant.
>>>>
>>>> I'm interested in looking at that but it'll probably have to be a while
>>>> before I can do so... if someone does so before me, I'll be interested
>>>> in beta testing at least.
>>>>
>>>> But also leaving this here as a self-reminder so we aren't surprised
>>>> when it becomes a more important thing to deal with :)
>>>>
>>>>
>>>
>>> Also, since we are talking about Racket, what
>>> happened to having a racket build system?
>>
>> There's interest in it, and Dimos made interesting progress towards
>> figuring out some of the key problems... there's been interest beyond
>> that but sadly it seems like organizing the energy to work on it hasn't
>> happened for whatever reason yet.
>>
>
> Can I volunteer on this task? There's some work in
> my team done in Racket; and it would be of great
> interest to us to have a working Racket build
> system. I can set apart some time to work on
> this. I'd ask for alot of guidance/ review on this
> though :)

YES!  Please do.  Let's talk.  You can ping me on IRC also, dustyweb on
freenode.

>> I've offered to throw money at the problem if someone's willing to take
>> it on btw... not much, but some money.  I've talked to a couple of
>> people about that but it stalled in each iteration I don't think
>> it's impossible but I guess it's one of those tasks that for whatever
>> reason seems difficult to get going on because there are some
>> complexities around the way Racket builds "collections" that eg don't
>> seem to show up in Python.  Anyway that's not a judgement because
>> despite wanting it fairly badly clearly I haven't made progress on it.
>>
>> I have the notes that Dimos wrote up not long ago in case anyone is
>> interested.  Dimos, do you mind if I post them to the list?
>>
> Please do share the notes! I can try to hack
> something up \m/\m/.

I looked at the email that Dimos sent to me (also the email I had was
apparently not the most recent email that they are using, corrected in
the addressing this time), and they had asked me if they should post it
to the mailing list, so I think that's consent to post it since they
expressed consideration in doing so in our exchange... so I'm attaching
it.

* Basics of Racket packaging system

Racket provides three abstractions of how to reuse and move around modules of 
code. These are:
** Libraries

A library in Racket is a single file module that can be used in other files. 
Libraries that are
serving some higher purpose are organised together in Collections.

Documentation can be found 
[[https://docs.racket-lang.org/reference/collects.html][here]].

** Collections

Collections are a number of libraries bundled together. They can be added to 
the system through
packages. Racket gets informed for presence of collections through collection 
link files.

In the filesystem collections are directories that include library files. The 
default path they are
stored is #. The corresponding link file is 
located at
# and includes a list as illustrated below:

#+begin_src racket
((root "pkgs/racket-lib")
 (root "pkgs/main-distribution")
 (root "pkgs/2d"))
#+end_src

More specifics about link files and their structure can be found 
[[https://docs.racket-lang.org/reference/collects.html#%28tech._collection._links._file%29][here]].
 More links can be added to
arbitary directories through 'raco link'. This file informs racket where a 
collection resides in the
# directory.

** Packages

Packages in Racket are the abstractions used to share and move around modules 
of code. The include a
number of libraries in a collection, or more collections. They are the means 
through which
dependencies are defined. The main entry for managing them is 'raco pkg'.

The tool for installing packages is 'raco pkg install' that takes as an 
argument a package source
(name of package in a catalog, directory, tar or zip file etc). How it will act 
is defined by the
"info.rkt" file included in the package source. 

Documentation for 
[[https://docs.racket-lang.org/pkg/cmdline.html#%28part._raco-pkg-install%29]['raco
 pkg install']] and 
[[https://docs.racket-lang.org/pkg/metadata.html]["info.rkt;]].

Racket can be configured for where to install and search for packages through a 
confing fi

Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber  writes:
>
>> Just a heads up that right now you *can* run Racket-on-Chez, but soon
>> Racket-on-Chez will be the "default"... maybe it's a good idea to see
>> how hard it will be to make a racket-on-chez package variant.
>>
>> I'm interested in looking at that but it'll probably have to be a while
>> before I can do so... if someone does so before me, I'll be interested
>> in beta testing at least.
>>
>> But also leaving this here as a self-reminder so we aren't surprised
>> when it becomes a more important thing to deal with :)
>>
>>
>
> Also, since we are talking about Racket, what
> happened to having a racket build system?

There's interest in it, and Dimos made interesting progress towards
figuring out some of the key problems... there's been interest beyond
that but sadly it seems like organizing the energy to work on it hasn't
happened for whatever reason yet.

I've offered to throw money at the problem if someone's willing to take
it on btw... not much, but some money.  I've talked to a couple of
people about that but it stalled in each iteration I don't think
it's impossible but I guess it's one of those tasks that for whatever
reason seems difficult to get going on because there are some
complexities around the way Racket builds "collections" that eg don't
seem to show up in Python.  Anyway that's not a judgement because
despite wanting it fairly badly clearly I haven't made progress on it.

I have the notes that Dimos wrote up not long ago in case anyone is
interested.  Dimos, do you mind if I post them to the list?

 - Chris

Racket will move on top of Chez soon

[Christopher Lemmer Webber]

Just a heads up that right now you *can* run Racket-on-Chez, but soon
Racket-on-Chez will be the "default"... maybe it's a good idea to see
how hard it will be to make a racket-on-chez package variant.

I'm interested in looking at that but it'll probably have to be a while
before I can do so... if someone does so before me, I'll be interested
in beta testing at least.

But also leaving this here as a self-reminder so we aren't surprised
when it becomes a more important thing to deal with :)

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Christopher Lemmer Webber  ezt írta (időpont:
> 2020. szept. 10., Cs, 0:52):
>>
>> Christopher Lemmer Webber writes:
>>
>> > Gábor Boskovits writes:
>> >
>> >> Hello,
>> >>
>> >> Christopher Lemmer Webber  ezt írta (időpont:
>> >> 2020. szept. 9., Sze, 21:00):
>> >>>
>> >>> Maxim Cournoyer writes:
>> >>>
>> >>> > Hello Gabor!
>> >>> >
>> >>> > Gábor Boskovits  writes:
>> >>> >
>> >>> >> Hello guix,
>> >>> >>
>> >>> >> I would like to propose an extension to how setuid programs are
>> >>> >> currently handled. The last time I checked it could only do setuid and
>> >>> >> setgid root. Some services, such as postfix need a more fine grained
>> >>> >> setuid setup. I would propose a record type, such as:
>> >>> >> (setuid
>> >>> >> (program setuid-program)
>> >>> >> (setuid setuid-setuid)
>> >>> >> (setgid setuid-setgid)
>> >>> >> (user setuid-user)
>> >>> >> (group setuid-group))
>> >>> >>
>> >>> >> So that there is more fine grained control.
>> >>> >>
>> >>> >> I would also propose to move this to the services framework, so that
>> >>> >> services could extend this field on demand.
>> >>> >>
>> >>> >> Wdyt?
>> >>> >
>> >>> > This sounds great!  I also encountered such limitation and tried to
>> >>> > fixing it in https://issues.guix.info/41763, with some success (and an
>> >>> > unresolved limitation pointed by Chriistopher) but I agree that using a
>> >>> > record makes more sense and is more future proof.
>> >>> >
>> >>> > Maxim
>> >>>
>> >>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
>> >>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
>> >>> necessary it already makes it a good idea.
>> >>>
>> >>> However I don't fully understand the syntax of what you proposed.  Let's
>> >>> see if I can guess with a fake entry
>> >>>
>> >>> #~(setuid
>> >>>;; The program to run, from the shady package
>> >>>(program (string-append #$shady "/bin/scaryfoo")
>> >>>;; Would this be a boolean?  If so should it be `setuid?`
>> >> yes, this should be a bool, studi? looks good to me.
>> >>>(setuid setuid-setuid)
>> >>>;; Likewise?
>> >>>(setgid setuid-setgid)
>> >> yes, the same thing applies here.
>> >>>;; Presumably the use we want to set this to
>> >>>(user setuid-user)
>> >> yes, this should just be the uid of the owner
>> >>>;; Presumably the group we want to se this to
>> >> this should be the gid.
>> >>>(group setuid-group))
>> >>>
>> >>> ... right?
>> >>>
>> >>> I guess this could be done in a backwards compatible way;
>> >>> %setuid-programs could either evaluate to strings or records, so the
>> >>> "simpler" version can remain an option?
>> >> Yes, it can be done this way. Actually I had a bit more general
>> >> solution in mind,
>> >> I feel there should be service to install a file from a store to a
>> >> given place, and with all the access control available,
>> >> like acl-s, if supported. And then provide the whole setuid thing as a
>> >> backwards compatibility layer, somehow like you described.
>> >> For now I guess creating this record type and implementing the
>> >> extended setuid functionality would be a good first step.
>> >
>> > A service seems like a really good idea to me in that it feels the most
>> > composable with how Guix currently approaches things.
>>
>> I feel like this one needs more "Guix maintainer" overview.
> I agree, this would be nice.
>
>   The current
>> setuid-programs could be kept as legacy behavior that installs an
>> additional service.  Thoughts?
>
> I believe it should be kept and install an additional service.
>
> I have two reasons for that: backwards compatibility is really
> important, so we should not break it, and I believe this would not be
> hard to do.
> On the other hand it would be nice to have a more integrated backend,
> and move as many things into the services infrastructure as practical,
> and I think this is a good candidate for that. Wdyt?
>
> Best regards,
> g_bor

That's fine by me.  I don't feel like I'm the right one to make the call though!

Re: Setuid programs

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Gábor Boskovits writes:
>
>> Hello,
>>
>> Christopher Lemmer Webber  ezt írta (időpont:
>> 2020. szept. 9., Sze, 21:00):
>>>
>>> Maxim Cournoyer writes:
>>>
>>> > Hello Gabor!
>>> >
>>> > Gábor Boskovits  writes:
>>> >
>>> >> Hello guix,
>>> >>
>>> >> I would like to propose an extension to how setuid programs are
>>> >> currently handled. The last time I checked it could only do setuid and
>>> >> setgid root. Some services, such as postfix need a more fine grained
>>> >> setuid setup. I would propose a record type, such as:
>>> >> (setuid
>>> >> (program setuid-program)
>>> >> (setuid setuid-setuid)
>>> >> (setgid setuid-setgid)
>>> >> (user setuid-user)
>>> >> (group setuid-group))
>>> >>
>>> >> So that there is more fine grained control.
>>> >>
>>> >> I would also propose to move this to the services framework, so that
>>> >> services could extend this field on demand.
>>> >>
>>> >> Wdyt?
>>> >
>>> > This sounds great!  I also encountered such limitation and tried to
>>> > fixing it in https://issues.guix.info/41763, with some success (and an
>>> > unresolved limitation pointed by Chriistopher) but I agree that using a
>>> > record makes more sense and is more future proof.
>>> >
>>> > Maxim
>>>
>>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
>>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
>>> necessary it already makes it a good idea.
>>>
>>> However I don't fully understand the syntax of what you proposed.  Let's
>>> see if I can guess with a fake entry
>>>
>>> #~(setuid
>>>;; The program to run, from the shady package
>>>(program (string-append #$shady "/bin/scaryfoo")
>>>;; Would this be a boolean?  If so should it be `setuid?`
>> yes, this should be a bool, studi? looks good to me.
>>>(setuid setuid-setuid)
>>>;; Likewise?
>>>(setgid setuid-setgid)
>> yes, the same thing applies here.
>>>;; Presumably the use we want to set this to
>>>(user setuid-user)
>> yes, this should just be the uid of the owner
>>>;; Presumably the group we want to se this to
>> this should be the gid.
>>>(group setuid-group))
>>>
>>> ... right?
>>>
>>> I guess this could be done in a backwards compatible way;
>>> %setuid-programs could either evaluate to strings or records, so the
>>> "simpler" version can remain an option?
>> Yes, it can be done this way. Actually I had a bit more general
>> solution in mind,
>> I feel there should be service to install a file from a store to a
>> given place, and with all the access control available,
>> like acl-s, if supported. And then provide the whole setuid thing as a
>> backwards compatibility layer, somehow like you described.
>> For now I guess creating this record type and implementing the
>> extended setuid functionality would be a good first step.
>
> A service seems like a really good idea to me in that it feels the most
> composable with how Guix currently approaches things.

I feel like this one needs more "Guix maintainer" overview.  The current
setuid-programs could be kept as legacy behavior that installs an
additional service.  Thoughts?

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Christopher Lemmer Webber  ezt írta (időpont:
> 2020. szept. 9., Sze, 21:00):
>>
>> Maxim Cournoyer writes:
>>
>> > Hello Gabor!
>> >
>> > Gábor Boskovits  writes:
>> >
>> >> Hello guix,
>> >>
>> >> I would like to propose an extension to how setuid programs are
>> >> currently handled. The last time I checked it could only do setuid and
>> >> setgid root. Some services, such as postfix need a more fine grained
>> >> setuid setup. I would propose a record type, such as:
>> >> (setuid
>> >> (program setuid-program)
>> >> (setuid setuid-setuid)
>> >> (setgid setuid-setgid)
>> >> (user setuid-user)
>> >> (group setuid-group))
>> >>
>> >> So that there is more fine grained control.
>> >>
>> >> I would also propose to move this to the services framework, so that
>> >> services could extend this field on demand.
>> >>
>> >> Wdyt?
>> >
>> > This sounds great!  I also encountered such limitation and tried to
>> > fixing it in https://issues.guix.info/41763, with some success (and an
>> > unresolved limitation pointed by Chriistopher) but I agree that using a
>> > record makes more sense and is more future proof.
>> >
>> > Maxim
>>
>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
>> necessary it already makes it a good idea.
>>
>> However I don't fully understand the syntax of what you proposed.  Let's
>> see if I can guess with a fake entry
>>
>> #~(setuid
>>;; The program to run, from the shady package
>>(program (string-append #$shady "/bin/scaryfoo")
>>;; Would this be a boolean?  If so should it be `setuid?`
> yes, this should be a bool, studi? looks good to me.
>>(setuid setuid-setuid)
>>;; Likewise?
>>(setgid setuid-setgid)
> yes, the same thing applies here.
>>;; Presumably the use we want to set this to
>>(user setuid-user)
> yes, this should just be the uid of the owner
>>;; Presumably the group we want to se this to
> this should be the gid.
>>(group setuid-group))
>>
>> ... right?
>>
>> I guess this could be done in a backwards compatible way;
>> %setuid-programs could either evaluate to strings or records, so the
>> "simpler" version can remain an option?
> Yes, it can be done this way. Actually I had a bit more general
> solution in mind,
> I feel there should be service to install a file from a store to a
> given place, and with all the access control available,
> like acl-s, if supported. And then provide the whole setuid thing as a
> backwards compatibility layer, somehow like you described.
> For now I guess creating this record type and implementing the
> extended setuid functionality would be a good first step.

A service seems like a really good idea to me in that it feels the most
composable with how Guix currently approaches things.

Re: Setuid programs

[Christopher Lemmer Webber]

Maxim Cournoyer writes:

> Hello Gabor!
>
> Gábor Boskovits  writes:
>
>> Hello guix,
>>
>> I would like to propose an extension to how setuid programs are
>> currently handled. The last time I checked it could only do setuid and
>> setgid root. Some services, such as postfix need a more fine grained
>> setuid setup. I would propose a record type, such as:
>> (setuid
>> (program setuid-program)
>> (setuid setuid-setuid)
>> (setgid setuid-setgid)
>> (user setuid-user)
>> (group setuid-group))
>>
>> So that there is more fine grained control.
>>
>> I would also propose to move this to the services framework, so that
>> services could extend this field on demand.
>>
>> Wdyt?
>
> This sounds great!  I also encountered such limitation and tried to
> fixing it in https://issues.guix.info/41763, with some success (and an
> unresolved limitation pointed by Chriistopher) but I agree that using a
> record makes more sense and is more future proof.
>
> Maxim

I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
sense of the weird DSL that opensmtpd uses) so I guess if that's what's
necessary it already makes it a good idea.

However I don't fully understand the syntax of what you proposed.  Let's
see if I can guess with a fake entry

#~(setuid
   ;; The program to run, from the shady package
   (program (string-append #$shady "/bin/scaryfoo")
   ;; Would this be a boolean?  If so should it be `setuid?`
   (setuid setuid-setuid)
   ;; Likewise?
   (setgid setuid-setgid)
   ;; Presumably the use we want to set this to
   (user setuid-user)
   ;; Presumably the group we want to se this to
   (group setuid-group))

... right?

I guess this could be done in a backwards compatible way;
%setuid-programs could either evaluate to strings or records, so the
"simpler" version can remain an option?

 - Chris

Pushed a fix (?) for ACL key location

[Christopher Lemmer Webber]

Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
of Guix, and it looks like it wasn't possible to build new systems from
that because the filename for the "Berlin ACL key" changed.  (Or at
least, I couldn't run "guix system vm".)

I pushed out a "fix" for this.  I hope it's ok.

I'm presuming this was expected to change given
ec4c404c0575b340a04b3922fb828ac5417832dd appearing to try to compensate
in the other direction *before* the new "guix" package version was
pushed.

If I made things worse, sorry in advance.  It fixes things here, but I
don't know the full context of what was going on.

 - Chris

Re: Racket packages: formerly Move DrRacket to a separate output?

[Christopher Lemmer Webber]

Dimakakos Dimos writes:

> Pierre Neidhardt writes:
>
>> I've (finally) pushed racket-minimal.
>> Hooray!
>>
>> Now to the Racket importer... Anyone?
>> Dimakakos? :)
>
> Nice! It will be very useful. I've put some research into a build system
> for racket, and sadly it isn't trivial to match the racket package
> system to guix.
>
> There is a lot of state handling in racket specific files, since every
> package is indexed by linking the specific folder of a package. Right
> now I'm creating these files ad-hoc but it doens't seem the best
> approach, since racket is really slow searching for the dependencies in
> many folders. At the same time, racket tries sometims to rebuild
> packages that are passed as inputs. There are also circular dependencies
> and other stuff that need to be ironed out.
>
> I'm also talking with the creator of racket2nix, a similar project for
> nix and he had the same problems, so we discussed about working for a
> solution for both package managers.
>
> So in conclusion, I don't have a specific roadmap, but I'm still working
> on it.

Would you mind sharing what you have so far?  Even just a complete
braindump of notes or WIP code could be helpful to move this along!

I've started reading some for the docs over at:

  https://docs.racket-lang.org/pkg/index.html

I'm getting an idea of some things but it would be useful to hear what
you and Claes have explored so far!

Installing packages auto-container'ed

[Christopher Lemmer Webber]

Would it be possible to make launching applications in Guix with minimum
permissions even easier?  Here's just a sketch of an idea.

Borrowing from the new containerizing an application example in the
manual...

In my manifest.scm, what if instead of listing the browser package
eolie, I listed the following:

  (define containerized-eolie
(wrap-containerized eolie
#:network? #t
;; Not sure if this line would be needed.
#:other-packages (list coreutils nss-certs dbus)
#:expose '("/etc/machine-id")
#:share '(("/home/cwebber/tmp/shared-with-browser"
   . "/home/cwebber/shared"))
#:share-env '("DISPLAY")))

  ;; now here's my list of packages
  (list emacs
containerized-eolie
...)

The idea here is that containerized-eolie actually generates a new
package that "wraps" every binary that would be installed, as well as
all common launchers, to use a script that actually launches them in a
container with the above restrictions.
  
I'm not sure how feasible or easy this is, but it seems like a good
idea.

If the process of containerizing something tricky like icecat is fairly
common, we could abstract that into a procedure, like
(make-containerized-icecat ...) or something.

Thoughts?

 - Chris

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

Carlo Zancanaro writes:

> Hey Chris,
>
> On Wed, May 27 2020, Christopher Lemmer Webber wrote:
>> However, I wonder if, with a matter of just two patches, this could be
>> resolved:
>>
>>  - Patch out the automatic download of Cisco's h.264 plugin.
>>  - Add a warning banner *above* the extensions page, or simply switch it
>>to the same one that Icecat already uses.
>>
>> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
>> It strikes me that with those two changes, the criteria would be met.
>
> We would need to watch out for Mozilla's requirements to use the
> "Firefox" trademark[1]. Of particular note is the section titled
> "Modified Versions Require Prior Written Permission":
>
>   The open source nature of Firefox and other Mozilla software allows
>   you to freely download and modify the source code. However, if you
>   make any changes to Firefox or other Mozilla software, you may not
>   redistribute that product using any Mozilla trademark without
>   Mozilla’s prior written consent and, typically, a distribution
>   agreement with Mozilla. For example, you may not distribute a
>   modified form of Firefox and continue to call it Firefox.
>
>   Changes requiring Mozilla’s prior written permission include (but are not 
> limited to):
>- Changing the default home page or adding bookmarks,
>- Adding, modifying, or deleting source files,
>- Adding, modifying, or deleting content from installer files,
>- File location changes,
>- Adding extensions, add-ons or plugins, or
>- Installing themes other than those available in the most recent
>  stable version of Firefox available at Mozilla.org.
>
>   If you wish to distribute a modified version of Firefox or other
>   Mozilla software with Mozilla trademarks please contact us with your
>   request at trademark-permissi...@mozilla.com.
>
> Carlo
>
> [1]: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/

I agree this is a concern and is in the list of things to address.

I forget, but I remember reading somewhere that Firefox's codebase does
ship in such a way where rebranding it isn't as hard as it used to be,
or that the development version already did have some of this branding
stripped out.  

Am I misremembering?
 - Chris

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

(An obvious win from this also being that we will be able to have more
Guix users running, on average, a more up-to-date on security browser
more often.)

Christopher Lemmer Webber writes:

> [moving from help-guix to guix-devel]
>
> On help-guix this exchange occured when discussing trying to install
> Vanilla Firefox... two things struck me:
>
>  - Firefox's source code is itself free, but it doesn't follow the FSDG
>(An assertion was made that Firefox was itself nonfree software,
>but this seems like an inaccurate characterization.  I agree it
>doesn't follow the FSDG, however.)
>  - It is probably possible, with minimal changes, to resolve that.
>
> So this page explains the problem:
>
>   
> https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
>
> "Problem: Recommends non-free addons and plugins; automatically downloads 
> cisco's binary h.264 codecs"
>
> I agree the latter is a problem.  The former is kind of maybe a problem,
> but mostly because it isn't clear that it's happening to the user.
>
> However, I wonder if, with a matter of just two patches, this could be
> resolved:
>
>  - Patch out the automatic download of Cisco's h.264 plugin.
>  - Add a warning banner *above* the extensions page, or simply switch it
>to the same one that Icecat already uses.
>
> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
> It strikes me that with those two changes, the criteria would be met.
>
> (Yes, I know that IceCat also provides LibreJS and some other plugins,
> and that's nice to have, but Guix already ships several other browsers
> that do not have those plugins, so this does not seem to be a strict
> impediment and I don't think it should be either.  We could change the
> default Firefox homepage to point at one that recommends installing some
> of these plugins, if that would be helpful.)
>
>  - Chris
>
>
> Christopher Lemmer Webber writes:
>
>> I'm not sure it's really accurate to categorize asking for a vanilla
>> copy of firefox, which might not comply with the FSDG, as nonfree
>> software.  The primary issue with Firefox that makes it qualify as
>> "nonfree" is that the add-ons tool brings you to something that might
>> guide a user towards nonfree software right?  Thus I think this isn't
>> exactly correct framing, since firefox itself isn't nonfree?  There is a
>> difference if I, as a user, install Firefox as free software, and I am
>> aware of the issue with the default extensions kit, and end up
>> installing no nonfree software on my computer, right?
>>
>> Am I missing something?  What makes Firefox itself nonfree (which I
>> think is not quite the same thing as not compliant with the FSDG)?
>>
>>
>> Adonay Felipe Nogueira via writes:
>>
>>> I came late to this issue, but I think this should have been posted on
>>> development mailing list. It's not good if we use the general help list
>>> to foster non-free software like Firefox or those which are third-party
>>> package managers with no default repository explicitly commited to
>>> following the GNU FSDG.
>>>
>>> Furthermore, to ease the sides of both the thread starter and the
>>> community, I'm taking a simplification in that I'm considering the use
>>> of such non-free software for purpose of developing or improving a free
>>> replacement. That means I'm not discussing the merit of whether the
>>> question should or shouldn't have been answered the way it was.
>>>
>>> One must be remind though, that the GNU FSDG isn't only about the
>>> packages distributed (software, documentation, text fonts, etc), but
>>> also about the community, and this is one of the things that keep Debian
>>> out of the list of free system distributions.
>>>
>>> Em 12/05/2020 16:23, Efraim Flashner escreveu:
>>>> On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:
>>>>>
>>>>> Christopher Lemmer Webber  skribis:
>>>>>
>>>>>> Anyone have a package definition (or channel) for a recent vanilla
>>>>>> firefox?
>>>>>>
>>>>>> I understand the decision to prefer distributing Icecat instead in Guix
>>>>>> proper, but I need a more recent version of things... I suspect others
>>>>>> sometimes do too.  I have a feeling at least someone in the community
>>>>>> has written such a definition... would you mind sharing?
>>>>>>
>>>>>> Thanks!
>>>>>>  - Chris
>>>>>
>>>>> Hi,
>>>>>
>>>>> There is a channel at
>>>>> https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
>>>>> definition for Firefox 74.0.1. I haven't tested it though.
>>>>
>>>> Other options include using the now official flatpak copy of firefox. If
>>>> you do go that route make sure to use the '--user' flag for flatpak so
>>>> it doesn't segfault while trying to write to /var/lib/flatpak.
>>>>

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

[moving from help-guix to guix-devel]

On help-guix this exchange occured when discussing trying to install
Vanilla Firefox... two things struck me:

 - Firefox's source code is itself free, but it doesn't follow the FSDG
   (An assertion was made that Firefox was itself nonfree software,
   but this seems like an inaccurate characterization.  I agree it
   doesn't follow the FSDG, however.)
 - It is probably possible, with minimal changes, to resolve that.

So this page explains the problem:

  
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines

"Problem: Recommends non-free addons and plugins; automatically downloads 
cisco's binary h.264 codecs"

I agree the latter is a problem.  The former is kind of maybe a problem,
but mostly because it isn't clear that it's happening to the user.

However, I wonder if, with a matter of just two patches, this could be
resolved:

 - Patch out the automatic download of Cisco's h.264 plugin.
 - Add a warning banner *above* the extensions page, or simply switch it
   to the same one that Icecat already uses.

Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
It strikes me that with those two changes, the criteria would be met.

(Yes, I know that IceCat also provides LibreJS and some other plugins,
and that's nice to have, but Guix already ships several other browsers
that do not have those plugins, so this does not seem to be a strict
impediment and I don't think it should be either.  We could change the
default Firefox homepage to point at one that recommends installing some
of these plugins, if that would be helpful.)

 - Chris


Christopher Lemmer Webber writes:

> I'm not sure it's really accurate to categorize asking for a vanilla
> copy of firefox, which might not comply with the FSDG, as nonfree
> software.  The primary issue with Firefox that makes it qualify as
> "nonfree" is that the add-ons tool brings you to something that might
> guide a user towards nonfree software right?  Thus I think this isn't
> exactly correct framing, since firefox itself isn't nonfree?  There is a
> difference if I, as a user, install Firefox as free software, and I am
> aware of the issue with the default extensions kit, and end up
> installing no nonfree software on my computer, right?
>
> Am I missing something?  What makes Firefox itself nonfree (which I
> think is not quite the same thing as not compliant with the FSDG)?
>
>
> Adonay Felipe Nogueira via writes:
>
>> I came late to this issue, but I think this should have been posted on
>> development mailing list. It's not good if we use the general help list
>> to foster non-free software like Firefox or those which are third-party
>> package managers with no default repository explicitly commited to
>> following the GNU FSDG.
>>
>> Furthermore, to ease the sides of both the thread starter and the
>> community, I'm taking a simplification in that I'm considering the use
>> of such non-free software for purpose of developing or improving a free
>> replacement. That means I'm not discussing the merit of whether the
>> question should or shouldn't have been answered the way it was.
>>
>> One must be remind though, that the GNU FSDG isn't only about the
>> packages distributed (software, documentation, text fonts, etc), but
>> also about the community, and this is one of the things that keep Debian
>> out of the list of free system distributions.
>>
>> Em 12/05/2020 16:23, Efraim Flashner escreveu:
>>> On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:
>>>>
>>>> Christopher Lemmer Webber  skribis:
>>>>
>>>>> Anyone have a package definition (or channel) for a recent vanilla
>>>>> firefox?
>>>>>
>>>>> I understand the decision to prefer distributing Icecat instead in Guix
>>>>> proper, but I need a more recent version of things... I suspect others
>>>>> sometimes do too.  I have a feeling at least someone in the community
>>>>> has written such a definition... would you mind sharing?
>>>>>
>>>>> Thanks!
>>>>>  - Chris
>>>>
>>>> Hi,
>>>>
>>>> There is a channel at
>>>> https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
>>>> definition for Firefox 74.0.1. I haven't tested it though.
>>>
>>> Other options include using the now official flatpak copy of firefox. If
>>> you do go that route make sure to use the '--user' flag for flatpak so
>>> it doesn't segfault while trying to write to /var/lib/flatpak.
>>>

Re: Towards a graphical installer?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Errr... Sorry, I was distracted yesterday, the NLNet grant is actually
> for a graphical _package manager_, not an installer! :p
>
> That said, I'm interested in helping with it too! :)

Still awesome :)

I'm looking forward to seeing your work evolve! :)

 - Chris

Re: Towards a graphical installer?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Nice!
>
> I'm planning to work on a probably-GTK graphical installer as part of
> the NLNet grant I've received in the coming month.  Let's keep in touch!
>
> Let's get started with a simple question: guile-gi or g-golf?

This is awesome!

Re: GNU Guix maintainer collective update

[Christopher Lemmer Webber]

Jack Hill writes:

> On Mon, 4 May 2020, sirgazil wrote:
>
>>  On Mon, 04 May 2020 13:31:46 + Maxim Cournoyer 
>>  wrote 
>> > Let's take a moment to thank Ricardo for his time as a Guix
>> > co-maintainer.  He's been immensely useful to the project and I hope
>> > we'll continue to see him around.
>>
>>
>> Hey, Wurmus, thanks a million. I really appreciate your help and the work 
>> you have done.
>
> Indeed, thanks Ricardo. Guix is great technology, but what I
> particularly love about it is the great community of people thanks to
> your kind leadership. Hope to see you around and best wishes!

Absolutely sharing the same.  Guix has always been one of the warmest
and friendliest communities in my experience of FOSS, and Ricardo has
consistently been a stand-up role model in that regard.

>> > Let's also welcome Mathieu Othacehe in his new role!  Congratulations,
>> > Mathieu!  :-)
>>
>> Great! Welcome, Mathieu :)
>
> Huzzah! Welcome!

Yes!

Re: Medium-term road map

[Christopher Lemmer Webber]

Andy Wingo writes:

> On Sat 25 Apr 2020 15:37, Ludovic Courtès  writes:
>
>>   2. Performance.  There are many things we can improve there, first and
>>  foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>>  compiler terrible time and space requirements
>
> I think I have a solution here, as discussed on IRC.  Basic idea is to
> make a direct compiler from Tree-IL to bytecode, skipping the CPS step.
> The result won't be optimal in terms of generated code quality (I
> estimate on average 2x slowdown) but it will be very cheap to produce (I
> estimate 10x improvement in time, and going from O(n log n) space to
> O(n), with better constant factors.  We'd use this compiler for -O0 or
> maybe even -O1 code.
>
> Got to spend a few days working it up tho!
>
> Andy

That sound like a nice path to an improvement!

Re: Hyperlinks!

[Christopher Lemmer Webber]

This is very nice.  The rainbow parenthesis matching is really excellent
too.

Guix has managed to make Texinfo html export look really nice!  I admit
I expressed skepticism in this endeavour a number of years back and am
happy to be incorrect.


Ludovic Courtès writes:

> Hello Guix!
>
> Scheme code snippets in the on-line manual now have hyperlinks for all
> the symbols documented in the manual:
>
>   
> https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html
>   https://guix.gnu.org/manual/devel/en/html_node/Defining-Packages.html
>
> Hyperlinks are such an amazing invention!
>
> (If anyone knows how to get ‘a.syntax-symbol’ CSS different from just
> ‘a’, I’m all ears!)
>
> This is happening in ‘doc/build.scm’ as a post-processing step on the
> makeinfo-generated HTML (along with the syntax-highlighting
> post-processing step).  It works well but there can be false positives
> because it matches on identifiers, without taking scope etc. into
> account—e.g., anytime “service” appears, it’ll link to the ‘service’
> procedure.
>
> I’d like to extend it to include references to the Guile manual, so that
> one could click on, say, ‘append’, but there might be too many false
> positives at that point.  And then we would need DrRacket fanciness to
> be able to determine what an identifier really refers to…
>
> Feedback welcome!
>
> Ludo’.

[GSOC 2020] Guix Deploy, round 2!

[Christopher Lemmer Webber]

Hello,

I'd be interested in doing a round 2 of mentoring for Guix Deploy.
The previous student (Jakob L. Kreuze) will not be a GSoC student this
year but is willing to co-mentor.  (Maybe David Thompson is as well but
I won't speak for him since we haven't discussed it yet.)

I don't know what the situation with Outreachy slots are, but I'd also
be happy to mentor this for there as well, obviously.

I think there's probably more that can be done to improve environments.
This includes initial bootstrapping of environments, making more
environments available, etc.

Let me also put out a goal for the Guix community: I think we'll see
Guix Deploy as a success if a bunch of us can switch over to using it on
our own servers (that includes me).  To that end, I'd love to know, how
many people are doing so, or have attempted to do so?  What features
would you like/need?

 - Chris

Re: [GSOC 2020] Idea: Guile based build-tool

[Christopher Lemmer Webber]

There have been some conversations about using Guix's tooling as a build
tool in the past.

Personally, what I would prefer to see is a Guile-based build tool that
is standalone; an alternative for autotools basically.  That then could
be used *in combination with* Guix quite nicely... use the Guile-based
build tool for describing how to build your packages, use "guix
environment" to pull in all the dependencies and create the dev
environment, and of course this tool would then be used for package
definitions too.

However I think this is not a small task, and would take someone who is
willing to do a fair amount of research, or is already familiar with the
problem domain.  It may be hard to finish in a single summer.


Leandro Doctors writes:

> Hi, all,
>
> I am starting to do some research on this idea.
>
> Even though I haven't checked Guix's code yet (I plan to flickr it in
> the upcoming days), I am thinking on getting some inspiration from the
> architecture of similar Clojure-focused tools (which, as I stated
> earlier, is what I know).
>
> I know about three such tools: leiningen[1], boot[2], and clojure.deps[3].
>
> I plan to flickr over their code, and see what architectural decitions
> could be proposed.
> What do you think about this?
>
> Best,
> Leandro
>
> [1] leiningen: https://github.com/technomancy/leiningen
> [2] boot: https://github.com/boot-clj/boot
> [3] clojure.deps: https://github.com/clojure/tools.deps.alpha

Re: Racket packages: formerly Move DrRacket to a separate output?

[Christopher Lemmer Webber]

Dimakakos Dimos writes:

> Pierre Neidhardt writes:
>
>> I've (finally) pushed racket-minimal.
>> Hooray!
>>
>> Now to the Racket importer... Anyone?
>> Dimakakos? :)
>
> Nice! It will be very useful. I've put some research into a build system
> for racket, and sadly it isn't trivial to match the racket package
> system to guix.
>
> There is a lot of state handling in racket specific files, since every
> package is indexed by linking the specific folder of a package. Right
> now I'm creating these files ad-hoc but it doens't seem the best
> approach, since racket is really slow searching for the dependencies in
> many folders. At the same time, racket tries sometims to rebuild
> packages that are passed as inputs. There are also circular dependencies
> and other stuff that need to be ironed out.
>
> I'm also talking with the creator of racket2nix, a similar project for
> nix and he had the same problems, so we discussed about working for a
> solution for both package managers.
>
> So in conclusion, I don't have a specific roadmap, but I'm still working
> on it.

Am I right then that the challenge is less an "importer" from the Racket
package repository and more to do with how Racket actually installs its
package outputs?  Or is it both?

Thanks for your hard work!

Re: Thank you, Guix! [I Love Free Software Day]

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Arun Isaac  writes:
>
>> Hi,
>>
>> It's February 14, I Love Free Software Day[1]. Instead of the usual bug
>> report, feature request or some other form of complaint, today I would
>> like to show some gratitude. :-) I wish to thank the Guix community for
>> pouring so much of their free time into making Guix as great as it is
>> today.
>>
>> I would like to thank the Guix community for being a warm and welcoming
>> crowd. I joined the community as a newbie who knew very little. And, if
>> I have stayed this long, it is only because of the friendly and amicable
>> culture of the Guix community.
>>
>> I want to thank our packagers who take on the enormous task of packaging
>> all known software in the universe and the often Sisyphean task of
>> maintaining all those packages. Even more so, I would like to thank our
>> selfless patch reviewers who take on the unglamorous work of reviewing
>> the ever increasing torrent of patches Guix receives these days.
>>
>> Hope to meet you all in person some day! :-)
>>
>> Thank you!
>> Arun.
>>
>> [1]: https://fsfe.org/campaigns/ilovefs/
>>
>
> Here, here! Thank you to all involved in Guix. The time I am able to
> contribute back ebbs and flows, but I find myself continually
> appreciating the effort, kindness, and thought everyone puts into the
> project.
>
> Thank you all!

Likewise!  Guix remains one of my favorite communities in free software.

Re: Racket packages: formerly Move DrRacket to a separate output?

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Dimakakos Dimos  ezt írta (időpont: 2019. okt. 5.,
> Szo 0:57):
>
>>
>> Christopher Lemmer Webber writes:
>>
>> > I think nobody has written a Racket importer.  I have it as a
>> > longstanding background TODO task but clearly haven't found the
>> > time... despite the fact that I desperately want the feature.
>>
>> I could start working on this, starting tomorrow. I will need a bit of
>> guidance though, shall I open a new thread or use this one?
>>
> Thanks for taking the initiative here. I would start a new thread, as this
> is misleadingly titled right now, and add
> please add a summary about the current status, so interested parties can
> get involved more easily. Thanks.

+1!  And please Cc me on it!

I may have a few good example packages to start testing it against and
can provide the (very limited) amount of info I know.

Re: Racket packages: formerly Move DrRacket to a separate output?

[Christopher Lemmer Webber]

I think nobody has written a Racket importer.  I have it as a
longstanding background TODO task but clearly haven't found the
time... despite the fact that I desperately want the feature.

I'm just desperate for a lot of things right now! ;)

 - Chris

Pjotr Prins writes:

> What is the status of creating Racket packages. For a REST API server
> I have two dependencies:
>
> : raco pkg install https://github.com/dmac/spin.git
> : raco pkg install https://github.com/BourgondAries/memo.git
>
> what is the recommended way of packaging them in GNU Guix?
>
> Pj.
>
> On Fri, Sep 14, 2018 at 01:44:37PM -0400, Christopher Lemmer Webber wrote:
>> Ludovic Courtès writes:
>> 
>> > Hello Pierre,
>> >
>> > Pierre Neidhardt  skribis:
>> >
>> >> Wouldn't it make sense to move DrRacket to a separate output?  I take
>> >> that most advanced users use something else (who said Emacs?) and
>> >> DrRacket might eat up a decent amount of disk space + extra dependencies
>> >> by itself.
>> >
>> > I don’t think it’s a matter of being an “advanced” user or not (DrRacket
>> > is really impressive, with a macro stepper and all sorts of bells and
>> > whistles), but I agree with the rationale.  :-)
>> >
>> >> Arch Linux provides racket and racket-minimal: the latter is stripped
>> >> from DrRacket:
>> >>
>> >>   https://www.archlinux.org/packages/?q=racket
>> >
>> > Such a split sounds good to me.  What do Chris and other Racketeers
>> > think?
>> >
>> > Cheers,
>> > Ludo’.
>> 
>> I'm ok with splitting out racket-minimal and racket, which is a common
>> convention these days... even Racket's download page provides "Racket"
>> and "Minimal Racket":
>> 
>> https://download.racket-lang.org/
>> 
>> I'd take the least effort route to doing that though... we aren't ready
>> to break each of the Racket "core" packages into their own packages and
>> I don't think that would need to hold this back.
>> 
>>  - Chris
>> 
>> 
>> 

Re: Maintainer needed for Linux-libre and IceCat packages

[Christopher Lemmer Webber]

Thanks for all the work you've done on this, Mark!

Mark H Weaver writes:

> Hello,
>
> I need to take a break from Guix.  I'm not sure if I'll be back or not.
> Someone else should take over maintenance of the Linux-libre and IceCat
> packages, starting with the recent kernel updates for 4.4.192, 4.9.192,
> 4.14.143, 4.19.72, and 5.2.14.
>
>   Thanks,
> Mark

Re: GSoC 2019 Recap

[Christopher Lemmer Webber]

Hi Jakob,

I've already said this off-list, but I feel it's worth repeating
on-list: thank you for making "guix deploy" a reality.  So many of us
have wanted it for so long, but you did the really important thing: you
put in the work, and clearly with great care.  We're glad to have you as
part of our community; please do stick around! :)

 - Chris

Re: bug#36855: guix system switch-generation doesn't

[Christopher Lemmer Webber]

Could you look at bug #36878 and commit 1db6f137d... as of latest
master, is this fixed?

Robert Vollmert writes:

> Could we get some input on this bug?
>
> Maybe I’m misunderstanding something, but it seems that a core guix
> feature (atomic rollbacks) doesn’t work…
>
>> On 30. Jul 2019, at 12:00, Robert Vollmert  wrote:
>> 
>> What I see:
>> 
>> 1. edit ~/pzprnode/pzprnode
>> 
>> rob@garp ~/pzprnode$ git diff
>> diff --git a/pzprnode b/pzprnode
>> index 612e6a8..d8ef0ea 100755
>> --- a/pzprnode
>> +++ b/pzprnode
>> @@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {
>> });
>> 
>> server.listen(port, hostname, () => {
>> +   console.log("updated version");
>>   console.log(`Server running at http://${hostname}:${port}/`);
>> });
>> 
>> 2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm
>> 3. sudo herd restart pzprnode
>> 4. less /var/log/messages
>> 
>> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped. 
>> Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started. 
>> Jul 30 11:46:58 localhost pzprnode[4954]: updated version 
>> Jul 30 11:46:58 localhost pzprnode[4954]: Server running at 
>> http://127.0.0.1:3456/ 
>> 
>> 5. sudo guix system list-generations
>> 
>> Generation 151   Jul 30 2019 10:37:06
>> file name: /var/guix/profiles/system-151-link
>> canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system
>> label: GNU with Linux-Libre 5.2.1
>> bootloader: grub
>> root device: label: "guix-root"
>> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
>> Generation 152   Jul 30 2019 11:43:13(current)
>> file name: /var/guix/profiles/system-152-link
>> canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system
>> label: GNU with Linux-Libre 5.2.1
>> bootloader: grub
>> root device: label: "guix-root"
>> kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
>> 
>> 6. sudo guix system switch-generation 151
>> 
>> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> The following derivation will be built:
>>  /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv
>> building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...
>> switched from generation 152 to 151
>> 
>> 7. sudo herd restart pzprnode
>> 8. less /var/log/messages
>> 
>> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped. 
>> Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started. 
>> Jul 30 11:48:03 localhost pzprnode[4994]: updated version 
>> Jul 30 11:48:03 localhost pzprnode[4994]: Server running at 
>> http://127.0.0.1:3456/ 
>> 
>> The line with “updated version” should not be there.
>> 
>> Presumably, this is due to switch-generations not calling 
>> upgrade-shepherd-services.
>> 

Re: On maintaining GNU Guix

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> This would allow each of the maintainers to better concentrate on
> selected sub-projects, and to increase the likelihood of having an
> active co-maintainer around when other co-maintainers are unavailable.
> We also hope that this change will decrease the importance of any
> individual maintainer’s presence and attention, and eventually lead to a
> more collective and perhaps representative way of arriving at decisions
> and breaking ties when necessary.

+1!

In addition... I think we aren't at the point where it's applicable, but
in considering the point where Guix's community grows big enough where
many people contributing to the main repository is untenable, I think a
move to something like what the Linux kernel does (different people
responsible for certain trees) might make sense.

I don't think we're there yet though.

Re: "guix deploy" is in git master

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> Hi Dave,
>
> "Thompson, David"  writes:
>
>> Agreed. Also this should be done in parallel eventually because
>> updating 24 machines serially is silly.
>
> Good idea. Do we have a Guix-specific API for parallelism, or should I
> look to the Guile manual section on Futures?

You can spawn a bunch of threads, then use Guile's channels to
synchronize with the main thread.  (Not to be confused with Guix's
channels!)

Re: Website translation (was: Re: Guix beyond 1.0: let’s have a roadmap!)

[Christopher Lemmer Webber]

pelzflorian (Florian Pelz) writes:

> On Sun, Jul 07, 2019 at 04:20:59PM +0200, Ludovic Courtès wrote:
>> Thanks for bringing this up.  I’m very much convinced this is an
>> important task, and I’m happy there’s already a team of dedicated
>> volunteers who’ve worked hard translating the manual and messages!
>>
>
> Yes. :)
>
>> The next obvious step is to translate the web site.  There were open
>> questions as to how to do it, but I think Julien and Florian had more or
>> less found a way forward, so I hope we can work on it soonish.
>> 
>
> The method I use is the _ macro at
> 
> (Guix sensibly would call such a macro G_).  It simply calls setlocale
> once for each string that needs to be translated.

Maybe see also the conversation about a i18n quasiquote here:

https://lists.gnu.org/archive/html/guile-user/2017-12/msg00050.html

Re: "guix deploy" is in git master

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> Hi Mark,
>
>> Ricardo Wurmus  writes:
>>
>>> Christopher Lemmer Webber  writes:
>>>
>>>> Ricardo, can you see if 834b8a4110 fixes the problem?
>>>
>>> It does not seem to fix this problem.
>>> “gnu/machine/ssh.scm” still isn’t included.
>>
>> The problem is that (guix self) has its own logic, independent of the
>> *.am files, to determine the set of modules to be compiled and
>> installed.  That logic needs to be updated when adding a new module
>> directory.
>>
>> I just pushed commit 079c93e1c1dd93639417095000d5e56d8db62d61, which
>> should hopefully fix the problem.
>
> Thank you, this fixes it.

Yes, thank you so much Mark! :)

Re: "guix deploy" is in git master

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> Christopher Lemmer Webber  writes:
>
>> Ricardo, can you see if 834b8a4110 fixes the problem?
>
> It does not seem to fix this problem.
> “gnu/machine/ssh.scm” still isn’t included.

Unfortunately my ability to debug autotools problems is... almost
nonexistant.  Any autotools-savvy people willing to take a look?

Re: "guix deploy" is in git master

[Christopher Lemmer Webber]

Ricardo, can you see if 834b8a4110 fixes the problem?

Jakob L. Kreuze writes:

> Hi, Ricardo!
>
> Ricardo Wurmus  writes:
>
>> Me!  I tried to use it on ci.guix.gnu.org to upgrade a node, but it
>> failed like this:
>>
>> rekado@berlin /root/maintenance/hydra$ guix deploy deploy-berlin-node.scm
>> Backtrace:
>>8 (primitive-load "/home/rekado/.config/guix/current/bin/��")
>> In guix/ui.scm:
>>   1655:12  7 (run-guix-command _ . _)
>> In guix/scripts/deploy.scm:
>> 78:33  6 (guix-deploy . _)
>> 69:16  5 (load-source-file "deploy-berlin-node.scm")
>> In guix/ui.scm:
>> 149:4  4 (make-user-module _)
>> In srfi/srfi-1.scm:
>> 640:9  3 (for-each # ��)
>> In guix/ui.scm:
>>150:36  2 (_ (gnu machine ssh))
>> In ice-9/boot-9.scm:
>>2803:6  1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ��)
>> In unknown file:
>>0 (scm-error misc-error #f "~A ~S" ("no code for modu��" ��) ��)
>>
>> ERROR: In procedure scm-error:
>> no code for module (gnu machine ssh)
>>
>>
>> Looks like (gnu machine ssh) is not installed.  I only see
>> “~/.config/guix/current/share/guile/site/2.2/gnu/machine.scm”, but not
>> “gnu/machine/ssh.scm”.
>>
>> “deploy-berlin-node.scm” is not special.  It just uses a procedure to
>> generate the system configuration:
>>
>> (use-service-modules networking ssh)
>> (use-package-modules bootloaders)
>>
>> (use-modules (sysadmin build-machines)
>>  (sysadmin people))
>>
>> (define %id 14)
>>
>> (define %system
>>   (berlin-build-machine-os %id))
>>
>> (define (id->ip id)
>>   (format #f "141.80.167.~d" (+ 131 id)))
>>
>> (list (machine
>>(system %system)
>>(environment managed-host-environment-type)
>>(configuration (machine-ssh-configuration
>>(host-name (id->ip %id))
>>(identity "./id_rsa")
>>(port 22)
>>
>>
>> --
>> Ricardo
>
> Thanks for trying it out! I'm realizing that 'guix pull' didn't install
> it for me, either, yet 'gnu/machine/ssh.scm' is in the source tree and
> there's a line for it in 'gnu/local.mk'[1]. Does anyone know what's
> happening here?
>
> Regards,
> Jakob
>
> [1]: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/local.mk#n569

I didn't break guix in the way I thought

[Christopher Lemmer Webber]

Okay, the main things that are broken are my laptop situation and my
brain.  No hope for the latter, but as for the former, I got stressed
and didn't notice that I am in fact between laptop setups and the guix
checkout I had on one machine isn't the same that I had on the other.
So there were problems, but not quite the ones I described.

Anyway, I pushed a patch that Jakob submitted to guix-devel, probably
that fixes things.

I broke guix (no code for module (guix remote))

[Christopher Lemmer Webber]

Looks like the most recent failure is my own fault:

error: failed to load 'gnu/machine/ssh.scm':
ice-9/eval.scm:293:34: no code for module (guix remote)

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
make[2]: *** [Makefile:5761: make-go] Error 1
make[2]: Leaving directory '/home/cwebber/devel/guix'
make[1]: *** [Makefile:4832: all-recursive] Error 1
make[1]: Leaving directory '/home/cwebber/devel/guix'
make: *** [Makefile:3222: all] Error 2

I swear I read that Ludovic pushed remote-eval, and then I did a fresh
compile before I pushed the patches and everything seemed fine.  But I
guess that was just cached stuff, because when I wiped my guix
environment and freshly compiled it I got this error.

Oops :(

I hope the remote-eval stuff really is ready, because probably the
easiest fix is to push it to master...!

 - Chris

"guix deploy" is in git master

[Christopher Lemmer Webber]

Huge congratulations to Jakob in that "guix deploy" has just hit git
master!  There's a new section of the manual, "8.15 Invoking ‘guix
deploy’"; see that for details.

Please play with it and let us know what your experiences are!

MANY THANKS and HUGE CONGRATS to Jakob for getting this key piece in of
their GSoC project already this summer!  More cool stuff is ahead, I
understand :)

Now who's going to be the first brave soul to use this for server
deployment? ;)
 - Chris

Re: BTRFS, LVM, LUKS

[Christopher Lemmer Webber]

Alexandre Oliva writes:

> Full-disk encryption (LUKS) is also a strict requirement for me, and so
> is multi-disk BTRFS.

Note that full disk encryption does work without LVM in Guix, though you
do need to then pretty much put everything on one partition :)

I think you can also do full disk encryption from libreboot by
decrypting the whole disk from GRUB.  I forget how that works, though.

Welcome to Guix, btw!

Re: Suggest another way of importing GNU Guix GPG key

[Christopher Lemmer Webber]

That's probably the right way to do it for now.

Alex Vong writes:

> Hello,
>
> One solution would be to download the keyring from
>  and verify the signature in
> the following way:
>
>   $ gpg --keyring ./gnu-keyring.gpg --verify guix-1.0.1.tar.gz.sig 
> guix-1.0.1.tar.gz
>
> Cheers,
> Alex
>
> dftxb...@free.fr writes:
>
>> Hello,
>>
>> SKS keyservers are currently under attack
>> (https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f) - 
>> the attack can cause a GPG client to freeze completely and mess the
>> GPG installation completely.
>>
>> I suggest GNU Guix proposes another way of importing the GPG keys so
>> that users will not suffer from this problem.
>>
>> There's another, newer, keyserver, proposed in this gist, that is run
>> by new software that doesnt suffer from this attack. See:
>> https://keys.openpgp.org/about/news#2019-06-12-launch
>>
>> However, that keyserver is not replicated. You could either use that
>> one or simply offer a download of the key over TLS with verification
>> against installed CAs, as secure as this can get.
>>
>> Regards

New episode of Libre Lounge out interviewing Ludovic about Guix!

[Christopher Lemmer Webber]

Hey all!  I'm really excited to say that there's a new episode of Libre
Lounge out (a podcast I co-host) and we interview Ludovic Courtès about
Guix!  There's a lot of cool stuff in here, including some discussion
about reproducibily, Mes, etc.

  
https://librelounge.org/episodes/episode-23-guix-with-ludovic-court%C3%A8s.html

Have a listen!  Tell your friends!
 - Chris

Re: Progress on 'guix deploy'

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> Hello, Guix!
>
> Apart from a few patches and my introductory email about a month ago,
> I've been pretty silent. I feel it's time to finally break that silence,
> let people know where progress has been made, and request some feedback
> on the code I've written so far.

Hi Jakob!  Thanks for sending this to the list. :)

> As a quick refresher, my GSoC project this summer is 'guix deploy', a
> deployment automation tool for GuixSD that's been discussed more
> thoroughly in [1] and [2]. Development has taken place on my personal
> branch of Guix, specifically the 'wip-deploy' branch [3], and is
> represented by three new Scheme source files:
>
> - 'gnu/machine.scm', which provides an abstraction for /something/ that
>   can be deployed to in a heterogeneous deployment. Currently, the only
>   concrete implementation of this is the simple case of in-place updates
>   to machines running SSH whose names and IP addresses we know.
> - 'gnu/tests/machine.scm', which implements some tests for
>   'gnu/machine.scm'. This is where I'm most interested in receiving
>   feedback. More on that later.
> - 'guix/scripts/deploy.scm', which implements the rudimentary
>   command-line interface for 'guix deploy'.
>
> The command-line interface hasn't really been fleshed out yet, but if
> you'd like to play around with it, it takes a "deployment" file as a
> parameter, which is a Scheme file looking something like the following:
>
> #+BEGIN_SRC scheme
> (use-modules ...)
>
> (define %system
>   (operating-system
>(host-name "gnu-deployed")
>(timezone "Etc/UTC")
>(bootloader (bootloader-configuration
> (bootloader grub-bootloader)
> (target "/dev/sda")
> (terminal-outputs '(console
>(file-systems (cons (file-system
> (mount-point "/")
> (device "/dev/vda1")
> (type "ext4"))
>%base-file-systems))
>(services
> (append (list (service dhcp-client-service-type)
>   (service openssh-service-type
>(openssh-configuration
> (permit-root-login #t)
> (allow-empty-passwords? #t
> %base-services
>
> (list (make 
> #:host-name "localhost"
> #:ssh-port 5556
> #:system %system))
> #+END_SRC
>
> Basically, you attach an 'operating-system' declaration to a 'machine'.
> In this case, 'sshable-machine' is the specific type of 'machine' that
> we're deploying to (one that's running an SSH daemon and has a known IP
> + port + hostname).
>
> I've found that the GuixSD QEMU images work well for playing around with
> this, provided that you add the SSH service to the system configuration
> and start it. In the case of this deployment file, I had a GuixSD guest
> with port 22 forwarded to my host's port 5556. You'll also need to set
> up some sort of public key auth in your SSH config. The current code
> isn't capable of handling other forms of SSH authentication.
>
> In terms of implementation, GOOPS feels like a bit of an unusual choice
> when juxtaposed with the rest of the Guix codebase, but I've come to
> really enjoy it. I'll roll with it for now, since I think it will make
> it easier to flesh out the vocabulary for specifying deployments.

I also want to clarify: I know that GOOPS code isn't quite contemporary
style for Guix, but David Thompson and I encouraged Jakob to spend the
minimal amount of time necessary focusing on doing polymorphism in a
clever way, as this is what Dave and I found was slowing us down in our
initial prototype code.

It's possible we could/should move to something else, but that's the
motivation there.

> The implementation of '' is doing what
> 'switch-to-system' and 'install-bootloader' in 'guix/scripts/system.scm'
> do, but in terms of data that can be sent with 'remote-eval'. I imagine
> the code will make more sense if you read both simultaneously.
>
> Okay, on to the test suite.
>
> My understanding of the system test suite (tests run with 'check-system'
> as opposed to those run with 'check') is that the meat of the test code
> exists in a G-Expression and should _not_ be interacting with the store
> of the machine running the test suite (i.e. that's the reason we're
> using marionettes in the first place). 'gnu/tests/install.scm' seems to
> be somewhat of an exception, and because the code in '(gnu machine)'
> depends heavily on having access to a store, I've tried to extend what's
> done in 'gnu/tests/install.scm' so that my tests have access to store
> while instrumenting the marionettes.
>
> To be specific, the chicken and egg scenario I'm working around is that
> the SSH daemon on the marionette needs to be running in order for
> 'deploy-os' to work, but I can't call 'deploy-os' from the test
> G-Expression because the store wouldn't be accessible then.
>
> My gut is 

Re: Introducing myself

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> Hello, guix-devel!
>
> My name is Jakob L. Kreuze, and I was accepted into Google's Summer of
> Code program this year to work on "guix deploy," the deployment
> automation tool for GuixSD that's been discussed in [1] and [2]. I just
> wanted to briefly introduce myself to the list, as you'll likely be
> seeing postings from me about "guix deploy" on a regular basis.
>
> Officially, my work doesn't start until the 27th of this month; the next
> few days will be spent ensuring that I have a working development
> environment and familiarizing myself with both the code and the
> development practices of Guix.
>
> I look forward to working with all of you.
>
> Jakob
>
> [1]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00145.html
> [2]: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00114.html

Hi Jakob!  Fancy seeing you here ;)

As said in person today, the vision of "guix deploy" is what originally
got me interested in Guix.  I'm so thrilled you're going to be working
this summer on making that a reality.

Welcome aboard!
 - cwebb

Re: GNU Guix 1.0.0 released

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> We are thrilled to announce the release of GNU Guix 1.0.0!

Massive congrats to the whole Guix community!  Woohoo :)

Re: Guix on Purism's Librems?

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Hey all,

Hi Katherine!

> I brought this up in IRC tonight, and I thought I'd cast a net on the
> mailing list to collect experiences. I am considering purchasing a
> Librem laptop, and I was curious how Guix runs on it. Would anyone who
> has these laptops (especially if you have a version with the TPM and
> head) care to write up an experience-report?

I have a LibreM laptop.  I'm not using it at the moment because I need
to send it in for repairs (and keep procrastinating on that) but I'll
say that GuixSD worked just fine out of the box.

> Also, would it make sense for us to have a package specifically for
> hardware like this to make it easier to build install images for the
> machines? Even if the packages don't do much, there is still value in
> declaring that the specific configuration of hardware has been
> investigated, and is supported.

I'm happy to publish my guix configuration if it helps, though I think
it isn't anything particularly special for the laptop to work.

That said I think I'd love more reports about what laptops/machines
people have gotten to work with GuixSD and what challenges they've run
into in general.  It would be nice to collect that.

 - Chris

Should we upgrade openssl?

[Christopher Lemmer Webber]

>From the openssl website:

> Note: The latest stable version is the 1.1.1 series. This is also our
> Long Term Support (LTS) version, supported until 11th September
> 2023. Our previous LTS version (1.0.2 series) will continue to be
> supported until 31st December 2019 (security fixes only during the
> last year of support). The 1.1.0 series is currently only receiving
> security fixes and will go out of support on 11th September 2019. All
> users of 1.0.2 and 1.1.0 are encouraged to upgrade to 1.1.1 as soon as
> possible. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support
> and should not be used.

I know, everyone's going to groan hearing this, but maybe given the
above it would make sense to upgrade to the openssl 1.1.0 series before
Guix 1.0 gets out the door?

I guess that would probably require a massive rebuild of core packages
though.

 - cwebb

Re: What is the philosophy behind shepherd?

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> I must preface this email with the assurance that there is no agenda
> behind my questions; only ignorance and curiosity. Please read it with
> that in mind!
>
> A couple weeks ago, I was watching a video called "The Tragedy of
> Systemd"[1]. In it, Benno Rice discusses the need for a so-called
> "system layer" which is responding to the many complicated signals
> coming into a system from thing happening (e.g. networks becoming
> available/unavailable, VPNs mucking with DNS and routing tables, etc.).
> He characterizes systemd and things like it as something that lives
> between kernel-space and user-space.
>
> It really opened my eyes to why something like systemd exists rather
> than sticking with the old-style init systems.
>
> Does Shepherd take the stance that it is, or is to become a "system
> layer"?
>
> If so, one of the criticisms he has for systemd is that instead of
> pulling in protocols for things (e.g. DNS), and allowing best-of-breed
> software to handle the implementation, it has pulled in the
> responsibility for implementation as well. Any thoughts on that?
>
> [1] - https://www.youtube.com/watch?v=o_AIw9bGogo

I think one interesting thing, to me, is that I agree that this is
desirable, but I think a microkernel + services approach would be much
better architecture.  In such a world then shepherd's role would be to
bootstrap the key services needed to talk to each other.

In other words, I think systemd exists in many ways to make up for the
limitations of a monolithic kernel approach.  In that way, it makes
sense, but I think we could do better with a different fundamental
infrastructure.

But maybe I am wrong!

 - Chris

Re: Raco importer

[Christopher Lemmer Webber]

Brett Gilio writes:

> Pierre Neidhardt writes:
>
>> That'd be awesome!
>
>
> Maybe i'm jumping the gun here. But once I get a working raco importer,
> would there be any objection to moving racket from scheme.scm to
> racket.scm, and subsequently placing raco derived imports in
> racket-xyz.scm?
>
> Brett Gilio

This would be extremely awesome, and is actually something I really need
myself.  I'd be willing to test and assist with implementation where I
can if you can take the lead!

 - Chris

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Christopher Lemmer Webber]

Julie Marchant writes:

> I don't understand what's so complicated about this issue. In justice
> systems, we adopt an "innocent until proven guilty" system because you
> can't really prove innocence, only guilt.

I agree with Julie's point here.  The fear that "there might be
something nonfree in there"... well, that's true for our entire system.
We also have a similar issue with security vulnerabilities... there are
almost certainly security vulnerabilities in the sum total of our
packages.  Which packages though?  And what are they?  We don't know the
answer to either of those.  Our response is to take action if and when
problems are found.  That's the same approach we should take here.

 - Chris

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Thompson, David writes:

> Hi Chris,
>
> Here we go again, eh? :)
>
>>   https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
>>   https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html
>>
>> There is a heavily, heavily bitrotted branch named "wip-deploy" where
>> David originally started exploring these ideas.  Conveniently, it's all
>> in one commit:
>>
>>   
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy=fcd6fc84e493d05be1f7590ee77509c81ac315c2
>
> Useful for context, but the code can probably be tossed at this point.

OK!

>> That seems like a good starting point.  But I know David feels that with
>> real-world experience in devops type work that actually things would be
>> a bit different than what's described in his original email.  I'm not
>> sure myself what would be different.  It would be helpful to hear Dave
>> weigh in on that point.
>
> Sure, since 2015 I've become the lead devops person at my company, so
> I like to think I'm a bit wiser now.

:)

>> Maybe Dave and I can meet up IRL now that we're close enough to each
>> other to chat about it.  But I know it's less fun than it used to be for
>> Dave to consider this because now that's Dave's actual job... but all
>> the more reason we need Dave's wisdom! :)
>
> We could meet up IRL about this and I can try to make an earnest
> effort to deal with this. I think what has stopped me in the past is
> the sheer size of this project, and maybe dramatically scaling down
> the scope will allow us to get *something* out the door.

Yes I think we shouldn't allow ourselves to get too overwhelmed!  We
should give the warnings that this is an alpha system in alpha (soon
beta?) software and we don't guarantee that the api will be stable :)

Furthermore, I think if we put an emphasis on composable layers, and
start with the simplest lower layers, and then add some other layers
above it (and actually the different use cases you lay out may actually
swap out which layers are above this), then I think we could be good?

> Here are some general use-cases I know about for deployments, roughly
> ordered from small scale to large scale, and least complex to most
> complex:
>
> * Managing a physical machine or two that have been given memorable
> names that you update in-place (home scale)
> * Managing a virtual machine or two that have been given memorable
> names that you update in-place (blog scale)

In the past we have discussed storing "deployment state", and where and
how we would store it.  I will make the argument that for these two
cases, we actually don't need state!  We can just do the simplest thing
possible: build the system derivation for each of these machines, log in
and see if the system already has that derivation running, and if not
copy over the closure and install it as the system state.  This could
be entirely declarative.

I think initially we can ignore entirely the issue of provisioning an
initial guix image.  We can also ignore things like getting the right
public keys and configuring the initial authority of how you can be
authorized to copy over that data.

> * Managing a large number of virtual machines whose names don't matter
> that you update in-place (proto-cloud scale)
> * Managing a large number of virtual machines whose names don't matter
> that are replaced when there is an update (cloud scale)
> * Managing 1 or more clusters of physical machines (datacenter scale)
> * Managing 1 or more clusters of physical machines and virtual
> machines ("corporation with a datacenter that is moving some stuff to
> the cloud" scale)

For all these, I think there can be one or more abstraction layers that
build on top of the same declarative primitives described above.  And
this may be where state comes in; since you don't really know what the
identifiers are ahead of time, but you do need to keep track of them,
yes we do want to serialize the state somewhere.

> There are, of course, more scenarios to consider (haven't even touched
> upon things like a Kubernetes cluster), but this is enough to
> illustrate the point that is a great diversity in setups.  How many
> machines are there? Are the bare metal, virtual machines, or a mix of
> both? In the case of virtual machines, are updates applied in an
> immutable fashion or not?  If immutable, which technique (blue-green,
> rolling release, etc.)?  It makes my head spin to think about all the
> use-cases.

... I don't know anything about the things you said above so I guess
that would be nice to go over in person :)

I think maybe my ignorance is helpful for optimism in this case!

> So... let's start small. Can we write a tool that handles in-place
> updates to machines (physical or virtual) whose name and IP address we
> know well (our special pet servers) without precluding the possibility
> of scaling up to more sophisticated architectures?  This would address
> the "home" and "blog" scale items above, which is probably what most
> of the 

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Pjotr Prins writes:

> I am also interested in 'guix deploy', especially if it can run on top
> of Debian and handle HOME directories.

I should also say: I'm not considering how "guix deploy" could or would
handle running on top of Debian *or* handle HOME directories.  Both of
those feel out of scope to me, but for different reasons:

 - "guix deploy" would deploy by, well, building guix system profiles
   and then pushing them out.  So I'm not sure how Debian would fit in
   there...
 - Mutable state of the system is hard to tackle.  We might need to
   tackle some degree of it, but I think that would be in
   post-install-hooks type things which might sometimes do that
   on server?

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Pjotr Prins writes:

> I am also interested in 'guix deploy', especially if it can run on top
> of Debian and handle HOME directories. Currently using a mixture of
> sysadmin heroics and my own cfengine style Ruby deploy tool ;). Happy
> to switch, test and hack. But not enough time to run with it.
>
> Pj.

I am trying to think, "what can I do to help advance things further",
and maybe my best next step is to write minimalist user stories with
mockups of configurations and deployments based off of davexunit's old
branch?  That way I can think through what's there and what I need yet.

 - Chris

It's time to build "guix deploy"

[Christopher Lemmer Webber]

Hi,

This has come up several times.  A lot of us want "guix deploy".
Personally, I'm running a variety of Debian servers and one Guix server
and I am terrible at maintaining all of them.

It's time for Guix Deploy... or it's time for me to give up and use
something like Ansible + Debian.  (Egads!  I don't want to do that.)

David's thoughts on this are below, and here's the original thread:

Original thread can be found at the links below:
  https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html
  https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
  https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html

There is a heavily, heavily bitrotted branch named "wip-deploy" where
David originally started exploring these ideas.  Conveniently, it's all
in one commit:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy=fcd6fc84e493d05be1f7590ee77509c81ac315c2

That seems like a good starting point.  But I know David feels that with
real-world experience in devops type work that actually things would be
a bit different than what's described in his original email.  I'm not
sure myself what would be different.  It would be helpful to hear Dave
weigh in on that point.

Maybe Dave and I can meet up IRL now that we're close enough to each
other to chat about it.  But I know it's less fun than it used to be for
Dave to consider this because now that's Dave's actual job... but all
the more reason we need Dave's wisdom! :)


David Thompson writes:

> Hey folks,
>
> I'm writing this in an attempt to "think out loud" about a deployment
> automation tool for GuixSD.
>
> Guix needs a NixOps[0] equivalent.  NixOps is the Nix project's
> deployment automation tool.  I read the source code[1] a bit, and here's
> what I've learned about it:
>
> * The central data type is a "deployment", which is a Nix expression
>   consisting of one or more named OS configs
>
> * The OS configs contain extra data that specifies the target platform:
>   VirtualBox, EC2, NixOS container, etc.  Each platform implements the
>   generic MachineDefinition and MachineState interfaces.
>
> * The 'nixops' command is stateful.  It stores necessary state about
>   deployed systems in a special directory ($HOME/.nixops by default),
>   such as the IP addresses of the deployed systems.  Because of this,
>   each deployment needs a unique identifier.
>
> * Deployments may be parameterized by values known only at deploy time.
>   This covers cases such as a web application server needing to know the
>   IP address of the database server.
>
> * There are useful subcommands to check the status of each system or ssh
>   into one of them.
>
> Here's a rough outline of how I'm thinking of implementing similar
> features in Guix:
>
> * Introduce new data types:
>
>   * : The generic interface type for implementing deployment
> targets.  Its fields hold procedures for various actions like
> 'provision', 'destroy', 'boot', or 'reboot'.  I haven't determined
> the precise list of actions needed, but it will become apparent as
> platforms are added.
>
>   * : Describes a single system in the deployment.  Contains a
> name string, an , and a .
>
>   * : Contains a name string and a list of  and
> procedures.  Procedures in the list should accept an argument
> containing the deployment results of the non-parameterized machines
> and return a .
>
> * Use a simple s-exp deployment state format.  Store the state in
>   $HOME/.config/guix by default.
>
> * Implement a 'guix ops' subcommand roughly the same actions as NixOps:
>   create, deploy, start, stop, destroy, list, info, check, ssh, etc.
>
> * The bulk of the work will be creating  objects that actually
>   provision various types of resources.  For prototyping, a
>   'local-vm-platform' would be enough to test that the whole system
>   works.
>
> Anyone want to join in on this brainstorming party?  Your thoughts are
> appreciated!
>
> [0] http://nixos.org/nixops/
> [1] https://github.com/NixOS/nixops

Re: [PATCH] gnu: Add ungoogled-chromium.

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hi bill-auger,
>
> bill-auger  skribis:
>
>> re: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg9.html
>>
>> i would like to remind readers of the guix-devel list that it was
>> discussed some months ago, why no FSDG distros currently distribute
>> chromium[1] - it appeared at that time, that most people in that
>> discussion were in agreement that chromium should not be included in
>> guix; and marius was instead hosting it in a private repo, as not to
>> taint the main guix repos with dubious software - has there been a
>> notable break-through since then?
>
> It’s not entirely clear to me what the problems are, to be honest.
> Marius listed specific issues that were addressed by the patches; others
> then pointed out at additional issues that ungoogled-chromium fixes,
> which Marius took into account; what’s left now?
>
> I understand you’re skeptical about Chromium, but we cannot base
> decisions based on vague skepticism.  If you know of issues that are
> still unaddressed, please do list them.
>
> I’d also like to stress that, if Chromium is eventually included in
> Guix, we are committed to fixing it or removing it should someone later
> discover that it does not comply with the FSDG (that’s the “Commitment
> to Correct Mistakes” section of FSDG.)

+1 ... If concrete problems are found, by all means those should be
raised and addressed.  Otherwise I really think we ought to merge this
work.

Re: FOSDEM 2019: Thank you!

[Christopher Lemmer Webber]

I'm sorry I missed the Guix days, it seems like it was quite an event!
But all the Guile stuff in the minimalist languages room was great.
Clearly 2018 was a great year for Guile and Guix... I'll place a bet
that 2019 will be just as great or better :)

Pjotr Prins writes:

> Thank you everyone for this great FOSDEM with the GNU Guix days: it
> was just great to see everyone and all the interactions! I feel much
> inspired to try GNU Hurd, new Guix features, the new Guile build
> system and even Racket (oops).
>
> A special thank you to the speakers and everyone who helped out!
>
> People came from really far, e.g., Argentina, USA (4x!), Canada,
> Israel.  Wonderful to have you with us! Thanks you so much for making
> the effort!
>
> Especially I wish to thank Manolis Ragkousis for doing so many of the
> preparations and dealing with the ungrateful job of organizing the
> programme and chasing speakers.
>
> I wish to thanks Andreas Enge, Efraim Flashner and Chris Marusich:
> thank you so much for helping out with the minimalistic languages
> devroom! We have run one of the most intense devrooms with so many
> back-to-back talks and no pauses.
>
> And finally I wish to thank all the people working on GNU Guix and GNU
> Mes. You make it all so interesting :). I feel 2019 is going to be an
> exceptional year.
>
> The videos should be coming online in the coming days (see the
> schedule
>
> https://fosdem.org/2019/schedule/track/minimalistic_languages/
>
> If you were a speaker, please click the link that was sent to you to
> release the video. Slides can still be uploaded through pentabarf.
>
> For those still heading back: safe travels! And hope to see everyone
> next year in health and great spirits!
>
> Pj.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

Adonay Felipe Nogueira writes:

> Em 24/09/2018 11:14, Ludovic Courtès escreveu:
>> Christopher Lemmer Webber  skribis:
>>>- There's also Google's recent work with Magenta/Fuschia.  From what
>>>  I've read, architecturally this looks right.  I think the reason
>>>  for worry here is the same difficulty the community has had to
>>>  build actual community and libre distributions on top of the
>>>  Android ecosystem could apply here.
>> 
>> Indeed.
>> 
>> We could also mention MINIX, which many of us are already using daily.
>> :-)
>> 
>> Putting aside Fuschia, I think the Hurd and MINIX are by far the
>> solutions that require the less work to be in a state where people with
>> “regular needs” like the rest of us to switch (MINIX is probably in that
>> state already.)
>> 
>> The Hurd already has a very advanced POSIX C library, which is not
>> negligible, especially compared to the other OSes.  Much progress has
>> been made in recent years wrt. drivers (using the Rump kernel in
>> particular.)  There are of course serious shortcomings, in particular
>> lack of 64-bit and SMP support.  But fixing these is relatively “little
>> work” in the grand scheme of things.
>> 
>> To put this in perspective, consider Linux namespaces: they have already
>> seen years of evolution, and the story of user namespaces shows that
>> it’s far from complete.
>
> I don't know if what I'll say will be off-topic here given that this
> list is about Guix development, not on general free/libre software
> activism, but please forgive me anyways.
>
> So, my worry is that if we somehow were to support Fuchsia and if it
> were to be not strong auto-upgradable copyleft with community-oriented
> enforcement, then we could actually loose the freedoms of the software
> for the end user. This thought was initially presented by Eben Moglen
> during one of his talks[1], but I just tried to bring the issue to Guix.
>
> [1]
> https://media.libreplanet.org/u/libreplanet/m/the-free-software-movement-in-the-age-of-trump/

It's a valid concern, and one that applies to seL4 which I have
advocated on this thread as well.  However, I think we've seen a big
difference in "community-run" free software projects under a lax license
(which tend to stay free and good for the users) and "corporate-run"
throw-the-code-over-the-wall projects (which tend to be less so, and
Android is a great example).

However in a sense this is why we need to push, as a community, to get
our feet into the door of a secure, ocap-powered system for users.
Because users *need* and will want that security; systems are just so
dangerously insecure.  If we don't get the community in there, we'll
leave it up to and Android-like sorry state where you've just got some
large powers and users and communities desparately trying to figure out
how to stay free underneath them, and most users not even trying or know
how they could.

Re: Re-approaching package tagging

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> zimoun  skribis:
>
>>> And how the regexp works ?
>>> I am not able to find some doc... I am diving in the code but it is
>>> not easy to find. :-)
>>
>> If I understand well, basically the code is here, right?
>> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm#n754
>>
>> And the regexp engine comes from the module (ice-9 regex), right?
>> Documented there:
>> https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html#Regular-Expressions
>
> Yes, just plain POSIX regexps.
>
>>> For example, how to search package with the name emacs and not the name 
>>> emacs-
>>> or how to search package with the name emacs and with the decription GNU?
>>> The '-s foo -s bar' is OR. What about the AND?
>>> etc.
>>
>> This needs more than the actual implementation, right?
>
> Having multiple -s flags makes it an “or” but it influences the
> relevance score:
>
>   
> https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html#index-searching-for-packages
>
> So if you take the results with the highest score, that’ll probably be
> those that match all the regexps.
>
> HTH!
>
> Ludo’.

I wonder for keywords that would be awkward to "force" into the
description if we could have an "extra keywords" section?  Then we can
skip tagging, but in case a package's description didn't comfortably fit
that word, you can still find it by it.  Then it's not separate tagging,
just extra words to find a package by that the description didn't say.

WDYT?

Re: Re-approaching package tagging

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> I’m surprised you don’t mention --search, which is more appropriate than
> -A (‘-A’ is here only to search among package names):
>
> --8<---cut here---start->8---
> $ guix package -s roguelike | recsel -p name,relevance
> name: roguebox-adventures
> relevance: 7
>
> name: tome4
> relevance: 5
>
> name: crawl
> relevance: 5
>
> name: crawl-tiles
> relevance: 5
>
> name: cataclysm-dda
> relevance: 5
>
> name: angband
> relevance: 5
> --8<---cut here---end--->8---
>
> I’m very much in favor of improving ‘--search’ until we’re happy with
> the results it gives.
>
> WDYT?
>
> Ludo’.

I'm embarassed to say I didn't know about --search :)

What's up with the .texi files always "changing"?

[Christopher Lemmer Webber]

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   doc/contributing.de.texi
modified:   doc/contributing.fr.texi
modified:   doc/guix.de.texi
modified:   doc/guix.fr.texi

Why does this keep happening?  If these are autogenerated, why are they
committed into git?  If they aren't autogenerated, why are they changing?

Re-approaching package tagging

[Christopher Lemmer Webber]

Hello,

In the past when we've discussed package tagging, I think Ludo' has been
against it, primarily because it's a giant source of bikeshedding.  I
agree that it's a huge space for bikeshedding... no space provides more
bikeshedding than naming things, and tagging things is a many to many
naming system.

However, I will say that finding packages based on topical interest is
pretty hard right now.  If I want to find all the available roguelikes:

cwebber@jasmine:~$ guix package -A rogue
hyperrogue  10.5out gnu/packages/games.scm:3652:2
roguebox-adventures 2.2.1   out gnu/packages/games.scm:1047:2

Hm, that's strange, there's definitely more roguelikes that should show
up than that!  A more specific search is even worse:

cwebber@jasmine:~$ guix package -A roguelike
cwebber@jasmine:~$

What I should have gotten back:
 - angband
 - cataclysm-dda
 - crawl
 - crawl-tiles
 - hyperrogue
 - nethack
 - roguebox-adventures
 - tome4

So I only got 1/4 of the entries I was interested in in my first query.
Too bad!

I get that we're opening up space for bikeshedding and *that's true*.
But it seems like not doing so makes things hard on users.

What do you think?  Is there a way to open the (pandora's?) box of tags
safely?

 - Chris

Re: Guix receives donation from the Hanshake project!

[Christopher Lemmer Webber]

Leo Famulari writes:

> On Mon, Dec 03, 2018 at 10:34:23PM +0100, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> We have some good news: the Hanshake project donated to GNU and the FSF,
>> and part of that goes to us!
>> 
>>   
>> https://gnu.org/s/guix/blog/2018/gnu-guix-receives-donation-from-the-handshake-project/
>> 
>> Concretely that’ll be 90KUSD for Guix (the FSF keeps 10% of the 100K we
>> got).  As we wrote in the blog post above, that opens the door to quite
>> a few things and I’m sure we’ll put the money to good use.  Now we need
>> your help to carry out projects such as an expansion of the build farm!
>
> Wow, that's awesome!
>
>> A big thanks to Handshake for this awesome gift and to the FSF for
>> handling it!
>
> Yes, thanks very much to all involved!

That's incredible!

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Christopher Lemmer Webber]

Mark H Weaver writes:

> Christopher Lemmer Webber  writes:
>
>> Thorsten Wilms writes:
>>
>>> On 29/10/2018 09.59, Björn Höfling wrote:
>>>> In law, there is the term of "conduct implying an intent". So even not
>>>> signing anything you could argue that by sending a bug or a patch you
>>>> silently agree with the community guidelines, CoC, etc. You enter the
>>>> community be interacting the first time. And will be judged by their
>>>> guidelines.
>>>
>>> It used to be that you could pick a Free Software project and send a patch.
>>>
>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>> an EULA? Everyone is expected to welcome that as progress?
>>
>> Submitting code to a project under a copyleft license is also agreeing
>> to policy.
>
> What is the basis for this claim?
>
> While I'm generally in favor of the CoC, I strongly oppose the idea that
> submitting a patch or communicating with us implies automatic agreement
> to our policies.
>
> We should not claim that someone has "agreed" to anything without their
> conscious knowledge and consent.  Even if the law would allow us to make
> such a claim, we should not do it because it would be unjust.
>
> Please, it is enough to make our policies clear and highly visible, to
> encourage people to read them, and to give the lead project maintainers
> the authority to issue warnings, and if deemed necessary, to ban people
> from our communication channels who repeatedly or severely violate our
> CoC.  I support that practice, as long as it's used judiciously, and I
> have every confidence in Ludovic and Ricardo to do so.
>
> We do _not_ need to extract promises from contributors ahead of time
> that they will follow our policies, and I think it's a bad idea to ask
> them to.  It's a worse idea to claim that they've done so implicitly
> without their knowledge or consent.
>
>   Mark

I suspect we do not disagree Mark, but the way in which you replied to
me makes it sound like we do, so let me clarify. :)  My short reply was
because I was trying to demonstrate, in few words, that the message I
was replying to was introducing an inaccuracy.  I did not clarify what
that was, but I will below.

We accept many patches from users where the user does not sign an actual
document, but their patch and their name applied on the top is
considered sufficient evidence that they have declared their code to be
licensed under the GPL.

But I should clarify the claim I was making, since I was not trying to
say that the legal or mechanistic aspects of this were equivalent.  Let
me quote what was I was replying to:

>>> It used to be that you could pick a Free Software project and send a patch.
>>>
>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>> an EULA? Everyone is expected to welcome that as progress?

The statement above makes it sound like the Code of Conduct is
dramatically new.  My claim here was that in both cases, there is a
policy the community has adopted.  One is legal and copyleft, the other
is behavioral and a code of conduct.  In both cases, your participation
in this community is dependent on your willingness to agree to respect
the policies and norms that the group upholds.

What's interesting to me is that this isn't new at all, it's just
codified for some specific things.  The Code of Conduct is not a legal
document, it is a set of policies about community norms.  Many of these
norms already existed, and the same process (speak to the person, ask
them to change their behavior, if we can't fix it, yes they may be
banned) has existed for a long time in free software circles.  What is
new from the code of conduct perspective is making explicit what some of
those norms are, and what participants can expect if they are not
upheld.

I have seen some accusations that this is censorship or an overreach or
equivalent to an EULA to have these norms enforced.  And yet the free
software community, and especially GNU projects, have long been
enforcing of policies.  Copyleft is a mechanism for enforcement of
policies by law, but even beyond that, I think most of the members of
this group would find it perfectly acceptable to ban someone who began
to post patches to the list under a license that was incompatible with
the GPL and which "poisoned" our ability to use them upon seeing them.
The former is a legal agreement, the latter is a norms agreement, but
they are both policy, and by participating in our group in general you
have an understanding that these policies exist.  The code of conduct
does not provide a legal enforcement mechanism, so the EULA comment in
that sense does not hold up; this is just a codification o

Re: Promoting the GNU Kind Communication Guidelines?

[Christopher Lemmer Webber]

Thorsten Wilms writes:

> On 29/10/2018 09.59, Björn Höfling wrote:
>> In law, there is the term of "conduct implying an intent". So even not
>> signing anything you could argue that by sending a bug or a patch you
>> silently agree with the community guidelines, CoC, etc. You enter the
>> community be interacting the first time. And will be judged by their
>> guidelines.
>
> It used to be that you could pick a Free Software project and send a patch.
>
> Now sending a patch is supposed to imply agreeing to the equivalent of
> an EULA? Everyone is expected to welcome that as progress?

Submitting code to a project under a copyleft license is also agreeing
to policy.

Re: openssh vulnerability

[Christopher Lemmer Webber]

Leo Famulari writes:

> On Wed, Oct 17, 2018 at 12:47:26AM -0400, Mike Gerwitz wrote:
>> On Tue, Oct 16, 2018 at 21:20:30 -0400, Christopher Lemmer Webber wrote:
>> > https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/
>> >
>> > seems serious?
>> 
>> Very... Fortunately that's libssh and not OpenSSH[0], but with that said,
>> it does appear to be packaged in Guix and there are a couple packages
>> that use it.

Ha, sorry for the scare.

> Patch at <https://bugs.gnu.org/33067>

Yay, thanks Leo!

openssh vulnerability

[Christopher Lemmer Webber]

https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/

seems serious?

Re: SeaGL 2018 Accepts Guix-Themed Talk: "Everyday Use of GNU Guix"

[Christopher Lemmer Webber]

Chris Marusich writes:

> Hi Guix!
>
> I recently submitted a Guix-themed talk proposal for SeaGL 2018 [1], a
> local GNU/Linux conference that takes place in November here in Seattle,
> and I'm happy to report that it was accepted!  Here's the link:
>
> "Everyday Use of GNU Guix"
> https://osem.seagl.org/conferences/seagl2018/program/proposals/526
>
> I'm very excited about it!  I've been to SeaGL before as an attendee,
> but this is the first time I'll try my hand as a presenter.  It's a
> great opportunity to promote and share Guix within my local community.
>
> I'll do my best to introduce Guix to the attendees!  If even one person
> from Seattle decides to give Guix or GuixSD a try, I'll consider that a
> success!  I need more Guix here on my home turf.  :-)
>
> Footnotes: 
> [1]  http://seagl.org/

Hey this is great news!  I've been to SeaGL before and it was great.

Enjoy your talk!  I'm sure it'll go great.

Re: Racket: Move DrRacket to a separate output?

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello Pierre,
>
> Pierre Neidhardt  skribis:
>
>> Wouldn't it make sense to move DrRacket to a separate output?  I take
>> that most advanced users use something else (who said Emacs?) and
>> DrRacket might eat up a decent amount of disk space + extra dependencies
>> by itself.
>
> I don’t think it’s a matter of being an “advanced” user or not (DrRacket
> is really impressive, with a macro stepper and all sorts of bells and
> whistles), but I agree with the rationale.  :-)
>
>> Arch Linux provides racket and racket-minimal: the latter is stripped
>> from DrRacket:
>>
>>  https://www.archlinux.org/packages/?q=racket
>
> Such a split sounds good to me.  What do Chris and other Racketeers
> think?
>
> Cheers,
> Ludo’.

I'm ok with splitting out racket-minimal and racket, which is a common
convention these days... even Racket's download page provides "Racket"
and "Minimal Racket":

https://download.racket-lang.org/

I'd take the least effort route to doing that though... we aren't ready
to break each of the Racket "core" packages into their own packages and
I don't think that would need to hold this back.

 - Chris

Re: Changes in the spending committee for the FSF Fund

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Thanks Mark for your time on the spending committee, and welcome Tobias!

Yes, thank you both!

Re: Firefox 52's end of life, packaging Chromium

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> Benjamin Slade  skribis:
>
>> Speaking from a user-perspective, I would be very much in favour of
>> having modern Firefox and Chromium (appropriately de-Googled as much as
>> possible, of course) as actual Guix offerings.
>>
>> And while there are lots of objectionable things about the www in 2018,
>> I don't think being a GNU follower is likely to strongly correlate with
>> being anti-web (I suspect the opposite, if anything).
>
> I agree with both statements.  I do see things in today’s www that I’m
> unhappy with, but I think it’s important to provide our users with a
> recent browser.
>
> I have to say that Andreas, Mark, Marius, and others who worked on
> IceCat and Chromium packaging are heroes: it’s a huge effort and we can
> be grateful for that!
>
> Ludo’.

Hear hear!  (Or is it "Here here?")

Re: bootstrap: i686-linux now builds without binutils, gcc, and glibc seeds

[Christopher Lemmer Webber]

Jan Nieuwenhuizen writes:

> Jan Nieuwenhuizen writes:
> Feeling slightly discouraged, but I will hammer on.  We're getting
> closer and closer...
>
> janneke

You really are!  Go team bootstrap!

Re: Heads-up: New dependency on Guile-Gcrypt

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello Guix!
>
> Coming soon: Guix will no longer provide its own crypto modules and will
> instead depend on Guile-Gcrypt:
>
>   https://issues.guix.info/issue/32606
>
> ‘guix pull’ will happily perform the transition.
>
> If you’re used to working on a Git checkout with “guix environment
> guix”, you’ll have to add ‘guile-gcrypt’ to the environment.  If your
> “guix” is too old and lacks the ‘guile-gcrypt’ package, you have a
> chicken-and-egg problem that you can solve either by running ‘guix pull’
> or by running this from your checkout:
>
>   $(make as-derivation)/bin/guix environment guix
>
> or:
>
>   $(make as-derivation)/bin/guix package -i guile-gcrypt
>
> Besides, our friends at openSuSE have already created a ‘guile-gcrypt’
> package.  :-)
>
> Ludo’.

Woohoo!  Really nice to see that package put to good use!

Re: [rb-general] A major milestone in bootstrapping

[Christopher Lemmer Webber]

Orians, Jeremiah (DTMB) writes:

>> Interesting... I'm looking at
>> https://github.com/oriansj/M2-Planet/blob/master/seed.M1
>> How was it written?  It seems like a monumental task to write all
>> that and keep enough context in one's head!  > Then again, I have
>> never written assembly before...
>
> If you'll notice https://github.com/oriansj/M2-Planet/blob/master/seed.M1#L2
>
> It explicitly says it was generated from stage0 
> https://savannah.nongnu.org/projects/stage0/
> Specifically cc_x86 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s
> Which was built by M0: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/M0-macro.hex2
> Which was built by hex2: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-2.hex1
> Which was built by hex1: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-1.hex0
> Which was built by hex0: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-0.hex0
> Which was the 250byte seed used
>
> Well the work started back in 2016 with 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.s
> and 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.hex
>
> It was written one function at a time, with the arguments passed in registers 
> and careful preservation of everything passed.
>
> - Jeremiah Orians

Ah very interesting!  Thanks for the history :)

Re: Firefox 52's end of life, packaging Chromium

[Christopher Lemmer Webber]

Clément Lassieur writes:

> Hi,
>
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).
>
> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].  It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?

+1 on this.  Considering how well attacked browsers are, not providing a
generally usable recent browser is putting our users at risk.

Re: A major milestone in bootstrapping

[Christopher Lemmer Webber]

jerem...@pdp10.guru writes:

> Today I am proud to announce a combo of releases with major milestones.
>
> First stage0, reached Release version 0.2.0; which includes the following:
> A 250byte hex0 bootstrap binary that is self-hosting and builds hex1,
> which builds hex2, which bootstraps M0 macro assembly which has been
> used to make:
>
> The world's FIRST C compiler written in M0 macro assembly, supporting:
> structs
> unions
> inline assembly
> function pointers
>
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s
>
> which is capable of compiling reproducibly:
>
> The newly released M2-Planet V1.0
> https://github.com/oriansj/M2-Planet
>
> Which is a self-hosting C compiler which is 100% deterministic by design
> with support for all the features needed to build the pieces of:
>
> mescc-tools
> https://savannah.nongnu.org/projects/mescc-tools
>
> which is capable of building M2-Planet from it's M1 macro seed.
>
> Soon we hope to finish the MesCC bootstrap from M2-Planet and then we
> will have a complete bootstrap path from 250byte hex0 all the way up to
> gcc ^_^
>
> -Jeremiah Orians

Interesting... I'm looking at

  https://github.com/oriansj/M2-Planet/blob/master/seed.M1

How was it written?  It seems like a monumental task to write all that
and keep enough context in one's head!  Then again, I have never written
assembly before...

Should *.fr.texi be committed in git?

[Christopher Lemmer Webber]

I frequently find that my git repo says:

Unstaged changes (2)
modified   doc/contributing.fr.texi
modified   doc/guix.fr.texi

And then I need to revert them before doing a pull.

These files are autogenerated from translations, right?  Shouldn't they
be gitignore'd and not committed to git at all?

Re: FOSDEM 2019

[Christopher Lemmer Webber]

Manolis Ragkousis writes:

> Hello everyone,
>
> It's that time of the year again we need to start organizing about
> FOSDEM. We have a deadline for the 20th of September[1] to apply for a
> devroom. We also need to start looking for a place for this year's
> fringe event!
>
> I created a libreplanet page[2] to start writing possible talk ideas in
> case we get a devroom.

Thanks for everyone is doing organizing, especially Manolis for kicking
this off!

I added a talk topic: "A Guiler's Year of Racket".  I think there's a
lot we could learn from our fellow friends in Racket-land, and I'd like
to share some of that!

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

First off, I should mention that rain1 reminded me about OpenBSD's
Capsicum and the Capsicum for Linux project, which I had mostly
forgotten about:
  http://www.capsicum-linux.org/

Capsicum brings file descriptor based capabilities, and this is a
reasonable intermediate approach.

Shill is an ocap (object capability) supporting shell using Capsicum:
  http://shill.seas.harvard.edu/

Ricardo Wurmus writes:

> Hey,
>
>>  - In terms of software, currently we run on ACL-heavy systems, which
>>are well known to be insecure designs:
>>  http://waterken.sourceforge.net/aclsdont/current.pdf
>>If a computer program behaves badly, it shouldn't be able to do any
>>more damage than the smallest amount of authority it should need to
>>run.  Currently programs run with the full authority of the user.
>>This means that a tiny code flaw in even the most trivial package
>>can lead to complete user compromise.
>>
>>In the long run, we'll want to support object capability based OS
>>designs which follow the principle of least authority, so a program's
>>vulnerabilities will be limited in scope.
>
> I agree, which is why I think that in the short term we should look into
> doing more work on SELinux policies (hear me out, please).  SELinux
> already exists and it provides an implementation of mandatory access
> control.  The big picture idea is: processes and files are assigned to
> certain domains where only certain access types are permitted and the
> kernel enforces these declarations.  Processes can transition from one
> domain to another only according to policies.
>
> SELinux certainly isn’t pretty, but it isn’t quite as complicated as the
> bad documentation out there makes it seem.
>
> I was thinking that we could have an internship (GSoC or Outreachy)
> project to implement support for SELinux in Guix, including the design
> of an extensible policy scheme.  I think Guix is uniquely suited as the
> foundation of an understandable SELinux system.  (Think of how the
> existing system service framework could be extended to provide
> context-specific SELinux policies.)

I'm not a big fan of SELinux because it's using an RBAC style system,
which is like a more fine grained ACL.  It's still a centralized
authority model, non-composable, and isn't as secure as a capability
security type approach.

I said this on IRC but:

 E in a Walnut has something to say about that
 > With tools like access control lists and firewalls, we engage in
   "perimeter defense", which is more correctly described as "eggshell
   defense". It is like an eggshell for the following reason: while an
   eggshell may seem pretty tough when you tap on it, if you can get a
   single pinhole anywhere in the surface, you can suck out the entire
   yoke.

Source: http://www.skyhunter.com/marcs/ewalnut.html

My personal view is that ACL'ish / RBAC'ish systems are the wrong
approach.  I suppose if someone wants to put effort into this direction
I don't object, unless it starts to complicate our tooling.  But for
focusing our efforts what I think we should do is work towards a better
long-term security approach of supporting object capability operating
system ideas.

>>- Well, GNU Hurd is a microkernel + ocap system (while also trying
>>  to be POSIX compatible).  Manolis has done much good work in
>>  helping to make that a more feasible option for Guix users.
>
> I’d love to get us closer to being able to run the GNU system with the
> Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
> priority by GNU, which shows in the lack of support for modern hardware.

Yes, this is unfortunate.

>> As a side note, if we don't have both together (libre hardware + ocap)
>> and we just have microkernel + ocap systems on top of proprietary
>> hardware, especially heavily "vendor controlled" systems, we could end
>> up much more screwed than we are even in our current systems, which is
>> why I think it's critical that we engage these things.
>
> I don’t understand this.  Why would the situation with microkernel +
> ocap on top of proprietary hardware be *worse* than the current
> situation of a monolithic ACL-based system on top of equally proprietary
> hardware?

The problem is that a much better implemented system will be harder to
break out of.  Right now many people "jailbreak" systems so they can
install free software on them.  We want to build watertight security
systems so that when users *control their hardware*, the programs on
their machines cannot do damage that they shouldn't be able to do.

But if the same watertight security system was applied but the lowest
capability layers were out of the user control, it might not be possible
to break free.

We can already see some of this today.  My understanding of why Intel
won't release a chip without ME, for instance, is that it's key to the
DRM systems that enforce playback of blue-ray players.  The 

Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

Hello... reading over a few articles this morning:

 - Researchers Blame ‘Monolithic’ Linux Code Base for Critical
   Vulnerabilities
   
https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-critical-vulnerabilities/136785/
 - Its associated paper:
   "The Jury Is In: Monolithic OS Design Is Flawed"
   http://ts.data61.csiro.au/publications/csiro_full_text/Biggs_LH_18.pdf
 - Brains behind seL4 secure microkernel begin RISC-V chip port
   https://www.theregister.co.uk/2018/04/23/risc_v_sel4_port/

I'm bringing this up because I want to plant the seed for some thinking
and conversation:

 - It's getting hard to trust our computers as in terms of our physical
   hardware.  Companies like Purism are helping to build blobless
   systems, but even then the hardware is built on un-auditable and
   with growing apparent insecurity (Spectre, Meltdown) with little
   chance of fixing things.  RISC-V has a libre instruction set, and in
   the long term I think we want to support that.

 - In terms of software, currently we run on ACL-heavy systems, which
   are well known to be insecure designs:
 http://waterken.sourceforge.net/aclsdont/current.pdf
   If a computer program behaves badly, it shouldn't be able to do any
   more damage than the smallest amount of authority it should need to
   run.  Currently programs run with the full authority of the user.
   This means that a tiny code flaw in even the most trivial package
   can lead to complete user compromise.

   In the long run, we'll want to support object capability based OS
   designs which follow the principle of least authority, so a program's
   vulnerabilities will be limited in scope.

 - What paths do we have forward on that last one?

   - Well, GNU Hurd is a microkernel + ocap system (while also trying
 to be POSIX compatible).  Manolis has done much good work in
 helping to make that a more feasible option for Guix users.

   - There's also seL4 which has a verified security kernel, possibly
 even seL4 with Genode.  I'm not sure how hard it will be to run
 POSIX type things on Genode.

   - There's also Google's recent work with Magenta/Fuschia.  From what
 I've read, architecturally this looks right.  I think the reason
 for worry here is the same difficulty the community has had to
 build actual community and libre distributions on top of the
 Android ecosystem could apply here.

 - It's also worth noting that the most common class of serious
   application / library vulnerabilities that we have to deal with is C
   / C++ memory management issues.  I'm not saying we should embrace
   everything getting ported to Rust, but I do think it's important to
   note that we're finally seeing paths out of that nightmare.

As a side note, if we don't have both together (libre hardware + ocap)
and we just have microkernel + ocap systems on top of proprietary
hardware, especially heavily "vendor controlled" systems, we could end
up much more screwed than we are even in our current systems, which is
why I think it's critical that we engage these things.  In the book
Rainbow's End (minor spoilers here) it's hinted that all the users are
running computers which have object capaiblity security and are thus
much more resilient to attacks, except that the bottom most layer of the
system is intentionally government compromised so that all systems are
effectively backdoored.  So, your sustem is secure... except for the
backdoor.

Anyway... the goal of this email was mostly just to try to get people
thinking about the direction we want to go long term.  Hope that's
useful/interesting even if it isn't an actual contribution of code
towards it ;)

Re: Graft hooks

[Christopher Lemmer Webber]

Ludovic Courtès writes:

>
>> Here’s a draft patch (it’s mercifully small).  I have a few questions
>> about it, but if it looks like the right approach, I will clean it up
>> and submit it.
>>
>> Basically, it checks if we are grafting Racket, and then adds some code
>> to the build expression to run the hook.
>
> OK.  In theory, should it be just for Racket, or should it also be for
> Racket libraries (we don’t have any currently AFAIK)?

That's something I'd like to change soon :)

Re: Graft hooks

[Christopher Lemmer Webber]

Timothy Sample writes:

> Hi Guix,
>
> I just submitted a patch for , but now I’m
> wondering if there isn’t a more general way to solve the problem.
>
> The bug has to do with grafting and checksums.  I know three bugs that
> follow this theme: the one above (Racket), 
> (GDB), and  (Go).  The basic problem is that
> these packages store checksums of files during build time.  If they get
> updated due to grafting, the files change, but the checksums do not.
> The checksums become invalid, which causes other problems like trying to
> update files in the store or asserting that debugging information is
> invalid.
>
> The patch I submitted makes Racket assume that files in the store are
> good.  It patches Racket to skip checksum validation if it is checking a
> file in the store.  A similar approach could be taken for GDB and Go.
>
> It occurs to me that if we had some way to run package-specific code
> during grafting we could solve problems like this easily and without
> patching software that is not broken.
>
> The basic idea would be to add a field (or use a property) to the
> package record.  Let’s call it “graft-hook”.  It would be Scheme code
> that gets run after grafting takes place, giving us a chance to patch
> special things like checksums.  The hook would be passed the list of
> files that were been modified during grafting.  Then, in the Racket
> package for example, I could write a graft-hook that updates the SHA-1
> hash of each of the modified source files.

This seems like a really good approach to me and seems also much nicer /
safer in the long run than the solution in #30680 since it wouldn't just
patch out the package in question's checks, it would correct them.  That
seems very good indeed to me.

> Since grafting is done at the derivation level, the hook code would have
> to be propagated down from the package level.  I haven’t looked at all
> the details yet, because maybe this is a bad idea and I shouldn’t waste
> my time!  :)  My first impression is that it is not too tricky.
>
> Are these problems too specialized to deserve a general mechanism like
> this?  Let me know what you think!
>
>
> -- Tim

As said, it seems good to me.  But I would be interested in what Mark
would think, since he is mostly responsible for the grafts design.

Re: Update on GuixSD containers

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Definitely.  Another application I’ve always wanted is a least-authority
> shell, like Plash [0].
>
> (Speaking of which, I just found Shill [1], which seems similar to Plash
> and even has a to-do item regarding package management [2] and is
> written in Racket; unfortunately it runs on FreeBSD, for Capsicum.)

As a side note, yesterday I learned about Capsicum for Linux:

  https://github.com/google/capsicum-linux

Unfortunately it has not seen commits this last year.  A shame; it would
really be nice to get such ocap support in GNU/Linux.