Re: Add the librewolf webbrowser to the guix packages

[Brett Gilio]

romulasry  writes:

> A fork of Firefox, focused on privacy, security and freedom.
>
> https://gitlab.com/librewolf-community/browser/common
>
> Sent with ProtonMail Secure Email.
>

Have you taken a crack at trying to package it? If so, perhaps it would
best to submit a patch and host it from a channel in the meantime.
Otherwise, please feel free to submit it to our wishlist [0]. I am not
familiar with this browser, so hopefully it is fully compliant with our
requirements (sic. the FSDG) [1], which means removing DRM. Is that the case?

-- 
Brett M. Gilio

https://brettgilio.com

[0] https://libreplanet.org/wiki/Group:Guix/Wishlist
[1] https://www.gnu.org/distros/free-system-distribution-guidelines.en.html

Re: Call for 1.2 installer testing.

[Brendan Tildesley]

On October 12, 2020 7:32:08 AM GMT+11:00, "pelzflorian (Florian Pelz)" 
 wrote:
>On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote:
>> Hi, I went through the installer looking for anything negative I
>could say
>> about it :) hope there is something helpful here:
>
>Thank you for testing!
>
>
>> Unrelated driver bug: installer was just a black screen until I
>rebooted
>> with nomodeset:  https://paste.debian.net/1166581/
>> Even with nomodeset, I get an error about no UMS supported in radeon,
>but it
>> doesn't stop anything.
>
>This black screen regression should be “fixed” now (commit
>34d436a4082b5c5f23b00e13eb8e5a92d957d704) by passing a kernel argument
>“modprobe.blacklist=radeon” which disables the radeon driver.
>
>(This was also blacklisted in the last release 1.1.0 of Guix, see
>.  I had removed
>“modprobe.blacklist=radeon” because it was for some time no longer
>needed on one of my machines.)
>
>Some users will have a black screen in the installed system as well
>(if they use Linux-libre).  I don’t think we can do much about that.
>Niels  only had trouble with the
>installer but did not on the installed system.  It seems not feasible
>to predict which users would have a black screen in the installed
>system, so we cannot add instructions only for them.
>
>
>
>> Languages listed in the language selection are sometimes in English,
>Rarely
>> in the native language. […]
>> Random thought: could we adapt the installer to use the same
>sentences from
>> an existing installer, like the ubuntu one, so that all the
>translations can
>> be copied in for free? All the basic quesions like please choose a
>password
>> are surely shared between these installers.
>
>Yes, we could copy translations without understanding the language (at
>least after our planned switch from the Translation Project to our own
>hosted Weblate translation infrastructure).
>
>Regards,
>Florian

I forgot to mention that the trisquel 8.0 installer did in fact work on the 
same computer. I was able to boot to the desktop, so it doesn't seem like a 
Linux libre issue. I wonder where the bug is introduced, and how I could 
isolate the bug. Maybe I could build versions of the installer with the LTS 
Linux or other versions to see if they work. Could the use of kmscon  possibly 
be related?

Add the librewolf webbrowser to the guix packages

[romulasry]

A fork of Firefox, focused on privacy, security and freedom.

https://gitlab.com/librewolf-community/browser/common

Sent with [ProtonMail](https://protonmail.com) Secure Email.

New Spanish PO file for 'guix-manual' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Call for 1.2 installer testing.

[Marinus Savoritias]

Hi,

I also encountered an issue with the latest iso just one day before the 
call for testing.


I have already filed the bug here: https://issues.guix.gnu.org/43879

Marinus Savoritias

On 10/11/20 10:32 PM, pelzflorian (Florian Pelz) wrote:

On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote:

Hi, I went through the installer looking for anything negative I could say
about it :) hope there is something helpful here:

Thank you for testing!



Unrelated driver bug: installer was just a black screen until I rebooted
with nomodeset:  https://paste.debian.net/1166581/
Even with nomodeset, I get an error about no UMS supported in radeon, but it
doesn't stop anything.

This black screen regression should be “fixed” now (commit
34d436a4082b5c5f23b00e13eb8e5a92d957d704) by passing a kernel argument
“modprobe.blacklist=radeon” which disables the radeon driver.

(This was also blacklisted in the last release 1.1.0 of Guix, see
.  I had removed
“modprobe.blacklist=radeon” because it was for some time no longer
needed on one of my machines.)

Some users will have a black screen in the installed system as well
(if they use Linux-libre).  I don’t think we can do much about that.
Niels  only had trouble with the
installer but did not on the installed system.  It seems not feasible
to predict which users would have a black screen in the installed
system, so we cannot add instructions only for them.




Languages listed in the language selection are sometimes in English, Rarely
in the native language. […]
Random thought: could we adapt the installer to use the same sentences from
an existing installer, like the ubuntu one, so that all the translations can
be copied in for free? All the basic quesions like please choose a password
are surely shared between these installers.

Yes, we could copy translations without understanding the language (at
least after our planned switch from the Translation Project to our own
hosted Weblate translation infrastructure).

Regards,
Florian

Re: Call for 1.2 installer testing.

[pelzflorian (Florian Pelz)]

On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote:
> Hi, I went through the installer looking for anything negative I could say
> about it :) hope there is something helpful here:

Thank you for testing!


> Unrelated driver bug: installer was just a black screen until I rebooted
> with nomodeset:  https://paste.debian.net/1166581/
> Even with nomodeset, I get an error about no UMS supported in radeon, but it
> doesn't stop anything.

This black screen regression should be “fixed” now (commit
34d436a4082b5c5f23b00e13eb8e5a92d957d704) by passing a kernel argument
“modprobe.blacklist=radeon” which disables the radeon driver.

(This was also blacklisted in the last release 1.1.0 of Guix, see
.  I had removed
“modprobe.blacklist=radeon” because it was for some time no longer
needed on one of my machines.)

Some users will have a black screen in the installed system as well
(if they use Linux-libre).  I don’t think we can do much about that.
Niels  only had trouble with the
installer but did not on the installed system.  It seems not feasible
to predict which users would have a black screen in the installed
system, so we cannot add instructions only for them.



> Languages listed in the language selection are sometimes in English, Rarely
> in the native language. […]
> Random thought: could we adapt the installer to use the same sentences from
> an existing installer, like the ubuntu one, so that all the translations can
> be copied in for free? All the basic quesions like please choose a password
> are surely shared between these installers.

Yes, we could copy translations without understanding the language (at
least after our planned switch from the Translation Project to our own
hosted Weblate translation infrastructure).

Regards,
Florian

New Russian PO file for 'guix-manual' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: Release v1.2 and Translation

[Miguel Ángel Arruga Vivas]

Hi everybody,

I've noticed that at least the pot file for the manual has to be updated
again, as some fragments of guix.texi has been modified since the the
pre-release was generated (e.g. section 2.4.2 Using the Offload
Facility), therefore they cannot be translated.

I've open http://issues.guix.gnu.org/issue/43934 with some minor details
I've found during translation, but I'd recommend to perform a complete
string freeze at some point before of the release to avoid these issues.

WDYT?

Happy hacking!
Miguel

Re: Guix Europe yearly assembly minutes increasing membership

[Joshua Branson]

That sounds about right.

-- 
Joshua Branson
Sent from Emacs and Gnus
https://gnucode.me
https://video.hardlimit.com/accounts/joshua_branson/video-channels
"You can have whatever you want, as long as you help enough other people get 
what they want." - Zig Ziglar

Re: File search progress: database review and question on triggers

[zimoun]

On Sun, 11 Oct 2020 at 16:25, Pierre Neidhardt  wrote:

> Maybe you misunderstood a point: the filesearch database is not a
> database of _all store items_, but only of the items that correspond to
> the packages of a given Guix generation.

Yes, it is clear for me.  I meant: “all the store items of one specific
Guix generation/revision”.  So all the outputs files of ~15k packages.


>> Well, I think it will be more with all the items of all the packages.
>
> No, the 8 MiB include _all the packages_ of a Guix generation.
> We never include the complete store, it would not make sense for filesearch.

[...]

> --8<---cut here---start->8---
>   The database will all package descriptions and synopsis is 46 MiB and
>   compresses down to 11 MiB in zstd.
> --8<---cut here---end--->8---

Sorry, I have overlooked the code.  All is fine. :-)


I will try to adapat the “guix search” to use the database instead.


Cheers,
simon

Re: Manual license (was Re: Translating the web site)

[Julien Lepiller]

Thank you! I think it's alright (it says guix manual package because po4a 
enforces "package" at the end).

Le 11 octobre 2020 09:57:25 GMT-04:00, "Miguel Ángel Arruga Vivas" 
 a écrit :
>Hi, everybody!
>
>Ludovic Courtès  writes:
>> Those at 
>have
>> the same statement, but it should rather be the same license as the
>> manual (GFDL).  Perhaps a ‘Makevars’ issue too?
>
>Sorry for bringing up this old issue so late, but I've just confirmed
>that the sentence is enforced by TP's robot, as the pot file contains
>literally this:
>--
>This file is distributed under the same license as the guix manual
>package.
>--
>
>Nonetheless I've tried to change the sentence in the po file to that
>and
>it complained.  As the current phrasing is not really wrong (it says
>guix package and the package includes the manual) I've sent the file
>with these two lines instead:
>--
>This file is distributed under the same license as the guix package.
>Note: The contents of this file are licensed under GNU FDL v1.3.
>--
>
>I hope this is enough clarification on the legal side.
>
>Best regards,
>Miguel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: First impressions from delving into Guix

[Julien Lepiller]

From what I understand, outreachy has a contribution period during which you 
need to register at least one successful contribution with the project. Out of 
the potential interns who submitted a contribution, we then have to select one 
to work on the project. Well if you can finish the project before it even 
starts it's great, but you'll be left with nothing to do ^^"

Le 11 octobre 2020 09:18:41 GMT-04:00, Lulu  a écrit :
>> On 2020-10-11 14:46 zimoun  wrote:
>> 
>> What do you mean?  What do you feel that is missing?
>
>This one was a mistake on my part; I thought the module layout was much
>more
>rigid than it actually is, due to informal conventions, and the
>Emacs-style
>Commentary and Code sections threw me off. :-P
>
>> Do you have a wording suggestion?
>
>Hmm, you could say outright in the beginning of "(guix)System
>Configuration"
>that configuration isn't kept in specific magic files, unlike most
>other
>operating systems, and that configuration happens atomically and
>endures until
>the next reconfiguration. (So that's what instantiation means here!)
>
>Other operating systems I've used that had a unified high-level CLI
>over
>existing system configuration still had configuration files to be
>parsed at
>startup, so I was a bit lost. :-)
>
>> If you have time, I would be interested by these issues; if you
>remember.
>
>Someone in #guix said the SELinux policy module dated to Fedora 23
>times, so
>that's probably why. (I was on Fedora 31.)
> 
>> What do you mean?  “guix show guile” lists all the available
>versions.
>> 
>> Which Guile have you patched?  The Guile that Arch provides, right?
> 
>Arch doesn't provide a Guile 3.0 package and the user-provided script
>on AUR is
>broken, so I had to patch that to get it to play nice with the native
>package
>manager. I'm not quite sure why but my attempts at introducing Guile
>into the
>environment through Guix failed. I'll try again later to investigate.
>
>> So I am not convinced that the “and” is really required. ;-)  But
>“more
>> is less”. :-)
> 
>Ah, that makes sense. I tried the -utf8- one at first, then installed
>the other
>one. Now I see!
>
>> I suggest to read [1, 2, 3, 4, 5, 6, 7] and try to package something.
>> Easy and good candidates for first packages are CRAN or BioConductor
>> packages:
>>
>> You can pick unpackaged one from the list [8].  Do not hesitate to
>ask
>> me if you do not find an obvious one –– it should a good occasion to
>> show you “guix repl”. :-)
>
>Sure thing! But shouldn't I finish the Git log subcommand first? Or
>should I
>leave it to last?
>
>--
>Lulu

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Manual license (was Re: Translating the web site)

[Miguel Ángel Arruga Vivas]

Hi, everybody!

Ludovic Courtès  writes:
> Those at  have
> the same statement, but it should rather be the same license as the
> manual (GFDL).  Perhaps a ‘Makevars’ issue too?

Sorry for bringing up this old issue so late, but I've just confirmed
that the sentence is enforced by TP's robot, as the pot file contains
literally this:
--
This file is distributed under the same license as the guix manual package.
--

Nonetheless I've tried to change the sentence in the po file to that and
it complained.  As the current phrasing is not really wrong (it says
guix package and the package includes the manual) I've sent the file
with these two lines instead:
--
This file is distributed under the same license as the guix package.
Note: The contents of this file are licensed under GNU FDL v1.3.
--

I hope this is enough clarification on the legal side.

Best regards,
Miguel

[PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hi,

> The 1.2 release is on its way. So here's the traditional call for
> installer testing. This time, the CI is building latest installer
> images, which should ease testing.

It works for me; I found Emacs EXWM missing however.  After zenny also
asked about that this morning, I decided to create a patch.

Greetings,
Janneke

>From 130480c4e76d7133f32a83cb1fa30aa171944383 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" 
Date: Sun, 11 Oct 2020 12:45:00 +0200
Subject: [PATCH] installer: Add Emacs EXWM desktop environment.
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

Suggested by zenny via IRC.

* gnu/installer/services.scm (%system-services): Add emacs, emacs-exwm,
emacs-desktop-environment.
* etc/release-manifest.scm (%system-packages): Likewise.
* gnu/system/examples/lightweight-desktop.tmpl: Likewise.
* gnu/installer/newt/services.scm (run-desktop-environments-cbt-page): Make
one entry taller.
---
 etc/release-manifest.scm | 2 ++
 gnu/installer/newt/services.scm  | 3 ++-
 gnu/installer/services.scm   | 6 ++
 gnu/system/examples/lightweight-desktop.tmpl | 3 ++-
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/etc/release-manifest.scm b/etc/release-manifest.scm
index caa200c673..7f54fe8768 100644
--- a/etc/release-manifest.scm
+++ b/etc/release-manifest.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2020 Ludovic Courtès 
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -53,6 +54,7 @@ TARGET."
   (append (map specification->package
'("xorg-server" "xfce" "gnome" "mate" "enlightenment"
  "openbox" "awesome" "i3-wm" "ratpoison"
+ "emacs" "emacs-exwm" "emacs-desktop-environment"
  "xlockmore" "slock" "libreoffice"
  "connman" "network-manager" "network-manager-applet"
  "openssh" "ntp" "tor"
diff --git a/gnu/installer/newt/services.scm b/gnu/installer/newt/services.scm
index 4f32d9077b..6d431cb4bb 100644
--- a/gnu/installer/newt/services.scm
+++ b/gnu/installer/newt/services.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2018 Mathieu Othacehe 
 ;;; Copyright © 2019 Ludovic Courtès 
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -40,7 +41,7 @@ choose the one to use on the log-in screen.")
  #:items items
  #:selection (map system-service-recommended? items)
  #:item->text system-service-name ;no i18n for DE names
- #:checkbox-tree-height 8
+ #:checkbox-tree-height 9
  #:exit-button-callback-procedure
  (lambda ()
(raise
diff --git a/gnu/installer/services.scm b/gnu/installer/services.scm
index dbac79196d..ec5ea30594 100644
--- a/gnu/installer/services.scm
+++ b/gnu/installer/services.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2018 Mathieu Othacehe 
 ;;; Copyright © 2019 Ludovic Courtès 
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -82,6 +83,11 @@
   (name "ratpoison")
   (packages '((specification->package "ratpoison")
   (specification->package "xterm"
+ (desktop-environment
+  (name "Emacs EXWM")
+  (packages '((specification->package "emacs")
+  (specification->package "emacs-exwm")
+  (specification->package "emacs-desktop-environment"
 
  ;; Networking.
  (system-service
diff --git a/gnu/system/examples/lightweight-desktop.tmpl b/gnu/system/examples/lightweight-desktop.tmpl
index b4037d4f79..8e38095a03 100644
--- a/gnu/system/examples/lightweight-desktop.tmpl
+++ b/gnu/system/examples/lightweight-desktop.tmpl
@@ -4,7 +4,7 @@
 
 (use-modules (gnu) (gnu system nss))
 (use-service-modules desktop)
-(use-package-modules bootloaders certs ratpoison suckless wm xorg)
+(use-package-modules bootloaders certs emacs-xyz ratpoison suckless wm xorg)
 
 (operating-system
   (host-name "antelope")
@@ -43,6 +43,7 @@
   (packages (append (list
  ;; window managers
  ratpoison i3-wm i3status dmenu
+ emacs-exwm emacs-desktop-environment
  ;; terminal emulator
  xterm
  ;; for HTTPS access
-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com


-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

New Spanish PO file for 'guix-manual' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New Spanish PO file for 'guix-manual' (version 1.2.0-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Spanish team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/es.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: First impressions from delving into Guix

[Lulu]

> On 2020-10-11 13:37 Pierre Neidhardt  wrote:
> 
> In particular, I didn't know that Guile was out of date on Arch Linux.
> Now I understand why many Arch Linux users struggle installing Guix... :p

Yeah, the `guile' package has been marked out-of-date in /January/. Fortunately
it's very easy to build it from scratch, with a `./configure 
--program-suffix=3.0'
to make it play nice with the existing Guile 2.2.

--
Lulu

Re: First impressions from delving into Guix

[Lulu]

> On 2020-10-11 14:46 zimoun  wrote:
> 
> What do you mean?  What do you feel that is missing?

This one was a mistake on my part; I thought the module layout was much more
rigid than it actually is, due to informal conventions, and the Emacs-style
Commentary and Code sections threw me off. :-P

> Do you have a wording suggestion?

Hmm, you could say outright in the beginning of "(guix)System Configuration"
that configuration isn't kept in specific magic files, unlike most other
operating systems, and that configuration happens atomically and endures until
the next reconfiguration. (So that's what instantiation means here!)

Other operating systems I've used that had a unified high-level CLI over
existing system configuration still had configuration files to be parsed at
startup, so I was a bit lost. :-)

> If you have time, I would be interested by these issues; if you remember.

Someone in #guix said the SELinux policy module dated to Fedora 23 times, so
that's probably why. (I was on Fedora 31.)
 
> What do you mean?  “guix show guile” lists all the available versions.
> 
> Which Guile have you patched?  The Guile that Arch provides, right?
 
Arch doesn't provide a Guile 3.0 package and the user-provided script on AUR is
broken, so I had to patch that to get it to play nice with the native package
manager. I'm not quite sure why but my attempts at introducing Guile into the
environment through Guix failed. I'll try again later to investigate.

> So I am not convinced that the “and” is really required. ;-)  But “more
> is less”. :-)
 
Ah, that makes sense. I tried the -utf8- one at first, then installed the other
one. Now I see!

> I suggest to read [1, 2, 3, 4, 5, 6, 7] and try to package something.
> Easy and good candidates for first packages are CRAN or BioConductor
> packages:
>
> You can pick unpackaged one from the list [8].  Do not hesitate to ask
> me if you do not find an obvious one –– it should a good occasion to
> show you “guix repl”. :-)

Sure thing! But shouldn't I finish the Git log subcommand first? Or should I
leave it to last?

--
Lulu

Re: File search progress: database review and question on triggers

[zimoun]

Hi Pierre,

I am trying to resume the work on "guix search" to improve it (faster).
That's why I am asking the details.  :-)
Because with the introduction of this database, as mentioned earlier,
2 annoyances could be fixed at once.


On Sun, 11 Oct 2020 at 13:19, Pierre Neidhardt  wrote:

> > --8<---cut here---start->8---
> > echo 3 > /proc/sys/vm/drop_caches
> > time updatedb --output=/tmp/store.db --database-root=/gnu/store/
> >
> > real0m19.903s
> > user0m1.549s
> > sys 0m4.500s
>
> I don't know the size of your store nor your hardware.  Could you
> benchmark against my filesearch implementation?

30G as I reported in my previous email. ;-)


> > From my point of view, yes.  Somehow “filesearch” is a subpart of
> > “search”.  So it should be the machinery.
>
> I'll work on it.  I'll try to make the code flexible enough so that it
> can be moved to another command easily, should we decide that "search"
> is not the right fit.

UI does not matter so much at this point, I guess.  But the nice final
UI should be:

   guix search --file=


> > For example, I just did “guix pull” and “–list-generation” says from
> > f6dfe42 (Sept. 15) to 4ec2190 (Oct. 10)::
> >
> >39.9 MB will be download
> >
> > more the tiny bits before “Computing Guix derivation”.  Say 50MB max.
> >
> > Well, the “locate” database for my “/gnu/store” (~30GB) is already to
> > ~50MB, and ~20MB when compressed with gzip.  And Pierre said:
> >
> >   The database will all package descriptions and synopsis is 46 MiB
> >   and compresses down to 11 MiB in zstd.
>
> I should have benchmarked with Lzip, it would have been more useful.  I
> think we can get it down to approximately 8 MiB in Lzip.

Well, I think it will be more with all the items of all the packages.
My point is: the database will be comparable in size with the bits of
"guix pull"; it is not much but still something.


> > which is better but still something.  Well, it is not affordable to
> > fetch the database with “guix pull”, In My Humble Opinion.
>
> We could send a "diff" of the database.

This means to setup server side, right?  So implement the "diff" in
"guix publish", right?  Hum? I feel it is overcomplicated.


> For instance, if the user already has a file database for the Guix
> generation A, then guix pulls to B, the substitute server can send the
> diff between A and B.  This would probably amount to less than 1 MiB if
> the generations are not too far apart.  (Warning: actual measures needed!)

Well, what is the size of for a full /gnu/store/ containing all the
packages of one specific revision?  Sorry if you already provided this
information, I have missed it.


> > Therefore, the database would be fetched at the first “guix search”
> > (assuming point above).  But now, how “search” could know what is custom
> > build and what is not?  Somehow, “search” should scan all the store to
> > be able to update the database.
> >
> > And what happens each time I am doing a custom build then “filesearch”.
> > The database should be updated, right?  Well, it seems almost unusable.
>
> I mentioned this previously: we need to update the database on "guix
> build".  This is very fast and would be mostly transparent to the user.
> This is essentially how "guix size" behaves.

Ok.


> > The model “updatedb/locate” seems better.  The user updates “manually”
> > if required and then location is fast.
>
> "manually" is not good in my opinion.  The end-user will inevitably
> forget.  An out-of-sync database would return bad results which is a
> big no-no for search.  On-demand database updates are ideals I think.

The tradeoff is:
  - when is "on-demand"?  When updates the database?
  - still fast when I search
 - do not slow down other guix subcommands


What you are proposing is:

 - when "guix search --file":
 + if the database does not exist: fetch it
 + otherwise: use it
 - after each "guix build", update the database

Right?

I am still missing the other update mechanism for updating the database.

(Note that the "fetch it" could be done at "guix pull" time which is
more meaningful since pull requires network access as you said.  And
the real computations for updating could be done at the first "guix
search --file" after the pull.)


> Possibly using a "diff" to shrink the download size.
>
> >  - otherwise: use this database
> >  - optionally update the database if the user wants to include new
> >  custom items.
>
> No need for the optional point I believe.

Note that since the same code is used on build farms and their store
is several TB (see recent discussion about "guix gc" on Berlin that
takes hours), the build and update of the database need some care. :-)


> >> - Find a way to garbage-collect the database(s).  My intuition is that
> >>   we should have 1 database per Guix checkout and when we `guix gc` a
> >>   Guix checkout we collect the corresponding database.
> >
> > Well, the exact same strategy as

Re: First impressions from delving into Guix

[zimoun]

Dear,

Thank you for the feedback.


On Sun, 11 Oct 2020 at 04:14, Lulu  wrote:

> I've been navigating Guix for the past couple days. Here's how it
> went:

Nice!


> At first, I added a skeleton for `guix git log' by copying from
> `guix git authenticate'. It might be useful to have a generic template for 
> Guix
> scripts, with conventions and all, by the way, because there isn't much in
> "(guix)Coding Style".

What do you mean?  What do you feel that is missing?


> I figured it would make things easier to use Guix System in a VM, so I booted
> the QCOW2 image using the given libvirt config in "(guix)Running Guix in a VM"
> (although there were some typos and grammar errors, maybe I should send a 
> patch
> for them).

Neat!  Please raise the hand on #guix or guix-devel if you need help.

You could be interested by:

   


>It worked without a hitch, but I got stumped when it came to
> configuration. I scanned through the info page to no avail. It's not exactly
> clear from the documentation that there are no configuration in the Unix 
> sense,
> but rather single-use configuration scripts (which is admittedly really cool).
> I spent some time trying to find where the `operating-system' variable is
> defined, but people helpfully clarified in #guix that I need to make a script
> declaratively defining the setup I have in mind, then let Guix adapt itself to
> that automatically. Equipped with that knowledge, I decided I'm better off
> generating my own VM image once I have a better idea of what sort of Guix 
> setup
> I want. It might be a good idea to clarify this in the info page.

Do you have a wording suggestion?


> Next, I went back to installing Guix normally on Arch Linux (I tried
> it on

AFAIK, it is always cumbersome to install Guix using other distro
package managers.  From my experience, it is easier to use the Binary
Script that Guix provides.


> Fedora previously and ran into SELinux issues). The AUR script is a
> bit wonky

If you have time, I would be interested by these issues; if you remember.


> due to dependencies so I just used the official binary installer. When
> I tried

Cool!

Then I am not following what you did if you used the Binary Script that
Guix provides for foreign distro.


> to bootstrap Guile, I ran into the problem that Guile 3.0 is unavailable.
> Indeed, Arch developers have been neglecting to add Guile 3.0 to the official
> repos. (Scheme is a bit neglected in this respect. The MIT/GNU Scheme package
> has been broken for a while as well.) So I got a build script off AUR 
> (although
> I had to patch it because it tried to replace Guile 2.2, which breaks programs
> like `make' that are linked to libguile2.2) and built Guile.

What do you mean?  “guix show guile” lists all the available versions.

Which Guile have you patched?  The Guile that Arch provides, right?


> Now that I had a working Guix + Guile 3 setup, I ran into the seemingly common
> `setlocale' issue which was quickly solved by installing both `glibc-locales`
> /and/ `glibc-utf8-locales` (and updating them with each glibc update), then
> setting `$GUILE_LOCPATH' accordingly for both root and my user. I did a
> `guix pull' and everything was dandy.

The package ’glibc-utf8-locales’ is a subset of ’glibc-locales’.
Basically, ’glibc-utf8-locales’ provides these locales, only:

--8<---cut here---start->8---
   ;; These are the locales commonly used for
   ;; tests---e.g., in Guile's i18n tests.
   '("de_DE" "el_GR" "en_US" "fr_FR" "tr_TR"))
--8<---cut here---end--->8---

So I am not convinced that the “and” is really required. ;-)  But “more
is less”. :-)


> With no more yaks to shave, I ran finished bootstrapping, ran the post install
> environment and my subcommand works! Now I can go back to add the functional
> parts of the script. I'll keep you updated!

Cool!

I suggest to read [1, 2, 3, 4, 5, 6, 7] and try to package something.
Easy and good candidates for first packages are CRAN or BioConductor
packages:

   guix import cran 
   guix import cran -a bioconductor 

You can pick unpackaged one from the list [8].  Do not hesitate to ask
me if you do not find an obvious one –– it should a good occasion to
show you “guix repl”. :-)


1: https://guix.gnu.org/manual/devel/en/guix.html#The-Perfect-Setup
2: https://guix.gnu.org/manual/devel/en/guix.html#Defining-Packages
3: 
https://guix.gnu.org/cookbook/en/html_node/Packaging-Tutorial.html#Packaging-Tutorial
4: https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines
5: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-import
6: https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-refresh
7: https://guix.gnu.org/manual/devel/en/guix.html#Building-from-Git
8: 

Re: File search progress: database review and question on triggers

[Pierre Neidhardt]

Hi Zimoun,

Thanks for the feedback!

> --8<---cut here---start->8---
> echo 3 > /proc/sys/vm/drop_caches
> time updatedb --output=/tmp/store.db --database-root=/gnu/store/
>
> real0m19.903s
> user0m1.549s
> sys 0m4.500s

I don't know the size of your store nor your hardware.  Could you
benchmark against my filesearch implementation?

> And then “locate” support regexp and regex and it is fast enough.

But locate does not support word permutations, which is a very important
feature for filesearch in my opinion.

> The only point is that regexp is always cumbersome for me.  Well: «Some
> people, when confronted with a problem, think "I know, I'll use regular
> expressions." Now they have two problems.» :-) [1]

Exactly.  Full text search is a big step forward for usability I think.

> From my point of view, yes.  Somehow “filesearch” is a subpart of
> “search”.  So it should be the machinery.

I'll work on it.  I'll try to make the code flexible enough so that it
can be moved to another command easily, should we decide that "search"
is not the right fit.

> From my point of view, how to transfer the database from substitutes to
> users and how to locally update (custom channels or custom load path) are
> not easy.  Maybe the core issues.

Absolutely.

> For example, I just did “guix pull” and “–list-generation” says from
> f6dfe42 (Sept. 15) to 4ec2190 (Oct. 10)::
>
>39.9 MB will be download
>
> more the tiny bits before “Computing Guix derivation”.  Say 50MB max.
>
> Well, the “locate” database for my “/gnu/store” (~30GB) is already to
> ~50MB, and ~20MB when compressed with gzip.  And Pierre said:
>
>   The database will all package descriptions and synopsis is 46 MiB
>   and compresses down to 11 MiB in zstd.

I should have benchmarked with Lzip, it would have been more useful.  I
think we can get it down to approximately 8 MiB in Lzip.

> which is better but still something.  Well, it is not affordable to
> fetch the database with “guix pull”, In My Humble Opinion.

We could send a "diff" of the database.

For instance, if the user already has a file database for the Guix
generation A, then guix pulls to B, the substitute server can send the
diff between A and B.  This would probably amount to less than 1 MiB if
the generations are not too far apart.  (Warning: actual measures needed!)

> Therefore, the database would be fetched at the first “guix search”
> (assuming point above).  But now, how “search” could know what is custom
> build and what is not?  Somehow, “search” should scan all the store to
> be able to update the database.
>
> And what happens each time I am doing a custom build then “filesearch”.
> The database should be updated, right?  Well, it seems almost unusable.

I mentioned this previously: we need to update the database on "guix
build".  This is very fast and would be mostly transparent to the user.
This is essentially how "guix size" behaves.

> The model “updatedb/locate” seems better.  The user updates “manually”
> if required and then location is fast.

"manually" is not good in my opinion.  The end-user will inevitably
forget.  An out-of-sync database would return bad results which is a
big no-no for search.  On-demand database updates are ideals I think.

> To me, each time I am using “filesearch”:
>
>  - first time: fetch the database corresponding the Guix commit and then
>  update it with my local store

Possibly using a "diff" to shrink the download size.

>  - otherwise: use this database
>  - optionally update the database if the user wants to include new
>  custom items.

No need for the optional point I believe.

> We could imagine a hook or option to “guix pull” specifying to also
> fetch the database and update it at pull time instead of “search” time.
> Personally, I prefer longer “guix pull” because it is already a bit long
> and then fast “search” than half/half (not so long pull and longer
> search).

I suggest we do it at pull time so that =guix search= does not need an
online network.  =guix pull= requires networking anyways.

>> - Find a way to garbage-collect the database(s).  My intuition is that
>>   we should have 1 database per Guix checkout and when we `guix gc` a
>>   Guix checkout we collect the corresponding database.
>
> Well, the exact same strategy as
> ~/.config/guix/current/lib/guix/package.cache can be used.

Oh!  I didn't know about this file!  What is it used for?

> BTW, thanks Pierre for improving the Guix discoverability. :-)

Thank you! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Declarative /etc/guix/acl?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> For some reason, /etc/guix/acl is not declarative on Guix System: we let
> users modify it and assume it’s stateful, which can surprise users as in
> .
>
> Should we make it declarative, just like most of /etc?  I think so.

Yes, I think so too.  However, if you have your own substitute server,
you now can run guix archive --authorize < ..., e.g. at
bootstrap/install time.  For such cases, IWBN to have a --authorized-key
argument to guix build / guix system.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: bug#39819: Declarative /etc/guix/acl?

[Efraim Flashner]

On Sun, Oct 11, 2020 at 12:39:17PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> For some reason, /etc/guix/acl is not declarative on Guix System: we let
> users modify it and assume it’s stateful, which can surprise users as in
> .
> 
> Should we make it declarative, just like most of /etc?  I think so.  For
> a build farm like berlin, it would force admins to explicitly list all
> the authorized keys in their config—annoying change, but not a bad
> thing.
> 
> WDYT?

I've been surprised by it at least once. (That it was more than once is
on me...)

> The problem is the transition.  We would need to at least create a
> backup of /etc/guix/acl on the next activation, or better yet, warn
> users or error out at reconfigure time.
> 
> Thoughts?
> 
> Ludo’.
> 

activation script: (when (file-exists? "/etc/guix/acl")
 (rename-file "/etc/guix/acl"
  "/etc/guix/acl-old"))

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Declarative /etc/guix/acl?

[Ludovic Courtès]

Hi!

For some reason, /etc/guix/acl is not declarative on Guix System: we let
users modify it and assume it’s stateful, which can surprise users as in
.

Should we make it declarative, just like most of /etc?  I think so.  For
a build farm like berlin, it would force admins to explicitly list all
the authorized keys in their config—annoying change, but not a bad
thing.

WDYT?

The problem is the transition.  We would need to at least create a
backup of /etc/guix/acl on the next activation, or better yet, warn
users or error out at reconfigure time.

Thoughts?

Ludo’.

Re: First impressions from delving into Guix

[Pierre Neidhardt]

Great feedback, thanks for sharing!

In particular, I didn't know that Guile was out of date on Arch Linux.
Now I understand why many Arch Linux users struggle installing Guix... :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Call for 1.2 installer testing.

[Efraim Flashner]

On Sun, Oct 11, 2020 at 05:23:30PM +1100, Brendan Tildesley wrote:
> Hi, I went through the installer looking for anything negative I could say
> about it :) hope there is something helpful here:
> 
> 
> Unrelated driver bug: installer was just a black screen until I rebooted
> with nomodeset:  https://paste.debian.net/1166581/
> Even with nomodeset, I get an error about no UMS supported in radeon, but it
> doesn't stop anything.
> 
> 
> Languages listed in the language selection are sometimes in English, Rarely
> in the native language. What's the difference between "Mandarin Chinese" and
> "Chinese"?. I guess this just requires translation data. The names of
> languages in their respective languages is something that already exists in
> a million different projects already, can we just copy them in?
> Even when choosing Mandarin Chinese, nothing in the installer is in
> Mandarin. I guess one also needs to choose the final system language too.
> Random thought: could we adapt the installer to use the same sentences from
> an existing installer, like the ubuntu one, so that all the translations can
> be copied in for free? All the basic quesions like please choose a password
> are surely shared between these installers.
> 
> The installer allows choosing the installation USB its self as a target,
> which I imagine would result in a disaster? People can shoot themselves in
> the foot if they want I guess?

Having somewhat recently played with them, I don't remember if Debian
allows that, I'm pretty sure NetBSD does. In any case, that's exactly
what I would want on an ARM device.

> No indication of what buttons one needs to use what: space, enter, tab, nor
> that there are other TTYs with documentation and how to get to them.
> 
> Enter selects and takes you to the next line when its an input box, but it
> does not select and take you out of it to the button below if it is the
> bottom most checkbox. one must then move to the tab button.
> 
> Down arrow in a checkbox list takes you down to the bottom of the list, but
> then it will not jump out to the button below. It does take you from Ok to
> Exit though, like left-right, but it wont cross the barriers.
> 
> space doesnt select menu items, but does select and move down checkbox
> lists, and selects buttons
> 
> I found my self switching between enter, tab, and space to get through, by
> going of intuition and thinking "do what i mean".
> 
> Perhaps Esc should escape when it makes sense.
> 
> 
> After getting through the install with encrypted root, The install finally
> fails trying to install grub with:
> 
> |Installing for i386-pc platform. grub-install: warning: this GPT partition
> label contains no BIOS Boot Partition; embedding won't be possible.
> grub-install: error: embedding is not possible, but this is required for
> RAID and LVM install. |
> 
> 

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Call for 1.2 installer testing.

[Brendan Tildesley]

Hi, I went through the installer looking for anything negative I could 
say about it :) hope there is something helpful here:



Unrelated driver bug: installer was just a black screen until I rebooted 
with nomodeset:  https://paste.debian.net/1166581/
Even with nomodeset, I get an error about no UMS supported in radeon, 
but it doesn't stop anything.



Languages listed in the language selection are sometimes in English, 
Rarely in the native language. What's the difference between "Mandarin 
Chinese" and "Chinese"?. I guess this just requires translation data. 
The names of languages in their respective languages is something that 
already exists in a million different projects already, can we just copy 
them in?
Even when choosing Mandarin Chinese, nothing in the installer is in 
Mandarin. I guess one also needs to choose the final system language too.
Random thought: could we adapt the installer to use the same sentences 
from an existing installer, like the ubuntu one, so that all the 
translations can be copied in for free? All the basic quesions like 
please choose a password are surely shared between these installers.


The installer allows choosing the installation USB its self as a target, 
which I imagine would result in a disaster? People can shoot themselves 
in the foot if they want I guess?


No indication of what buttons one needs to use what: space, enter, tab, 
nor that there are other TTYs with documentation and how to get to them.


Enter selects and takes you to the next line when its an input box, but 
it does not select and take you out of it to the button below if it is 
the bottom most checkbox. one must then move to the tab button.


Down arrow in a checkbox list takes you down to the bottom of the list, 
but then it will not jump out to the button below. It does take you from 
Ok to Exit though, like left-right, but it wont cross the barriers.


space doesnt select menu items, but does select and move down checkbox 
lists, and selects buttons


I found my self switching between enter, tab, and space to get through, 
by going of intuition and thinking "do what i mean".


Perhaps Esc should escape when it makes sense.


After getting through the install with encrypted root, The install 
finally fails trying to install grub with:


|Installing for i386-pc platform. grub-install: warning: this GPT 
partition label contains no BIOS Boot Partition; embedding won't be 
possible. grub-install: error: embedding is not possible, but this is 
required for RAID and LVM install. |