Re: Searxes in Icecat

[Mark H Weaver]

Hi Andreas,

I'm not subscribed to help-guix, so I saw this only by chance.
If you had filed a bug report, I would have seen it sooner.

Andreas Enge  wrote:
> since a recent update to icecat-68.12.0-guix0-preview1 (I do not know
> from which version), the "Searxes Third Party Request Blocker" add-on 
> is mentioned as enabled, but does not seem to work any more:
> There is no icon in the status bar to enable or disable third-party requests,
> and the pages I am visiting have filled up with ads. Has anyone else had
> this experience? Is there a setting I could change to make it work again?

See  for a description of the problem, and
how to get the bundled extensions working again at the cost of resetting
your preferences and addons to their defaults.  A proper fix will
require some coding that has not yet been done.

  Regards,
Mark

Re: Recipe for latest release of firefox?

[Mark H Weaver]

Hi Christopher,

Christopher Lemmer Webber  writes:
> Does someone have a recipe, or channel, for the latest release of
> Firefox?
>
> Mark Weaver was doing an amazing job of patching icecat to be up to date
> on security releases.  Since nobody is doing that work currently, I'm a
> bit worried about the security of my browsing...

FWIW, I'm still using IceCat 60.9, based on Firefox ESR 60.9, which was
released at the same time as Firefox ESR 68.1.  Those are the most
recent upstream ESR releases from Mozilla, so our IceCat package is
currently up to date.

The next IceCat update will be needed when you see a version number
newer than 68.1 on the following page:

  https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/

The next update is currently scheduled for October 22, when Firefox 70
and Firefox 68.2 ESR are due to be released.  Unless an especially
urgent issue is discovered, leading to an "out of band" release from
Mozilla, it's likely that no action will be needed until October 22.

  Regards,
Mark

Re: Ho to hide settings on a new tab Icecat

[Mark H Weaver]

Hello again,

Earlier, I wrote:

> zna...@disroot.org writes:
>
>> Hello! Need to set 'Search' and 'Top sites' blocks to the top of Icecat tab.
>> But there is 'Privacy settings' block in the top, screen: 
>> http://0x0.st/zOid.png
>> Please, how to hide or delete it at all?
>
> I don't know off-hand, but I would suggest asking the question on
> , the mailing list for IceCat.  This question is
> not specific to Guix.

FYI, the code that adds the "Privacy settings" block is here:

  https://git.sv.gnu.org/cgit/gnuzilla.git/tree/data/onboarding?h=v60.7.0

It is copied to the generated IceCat source tarball by this code:

  https://git.sv.gnu.org/cgit/gnuzilla.git/tree/makeicecat?h=v60.7.0#n574

and ends up in browser/extensions/onboarding in the source tarball, and
ultimately here in the build output:

  
/gnu/store/…-icecat-60.8.0-guix1/lib/icecat/browser/features/onboard...@mozilla.org.xpi

A comment in onboarding.js claims:

  The script won't be initialized if we turned off onboarding by
  setting "browser.onboarding.enabled" to false.

but that's apparently false, because "browser.onboarding.enabled" is
already set to false on my installation (although I do not remember
changing it), and yet I still see the "Privacy settings" block.

Further questions about this issue should go to ,
because as I wrote earlier, it is not specific to Guix.

 Regards,
   Mark

Re: network-manager-openconnect setup

[Mark H Weaver]

"Santana, Divan"  writes:

> Bonus points for anyone who knows why when I copy and paste into Emacs I
> get these weird characters.
>
>588:24  2 (inferior-package->manifest-entry "network-manager-ope…" …)

The weird characters above, "…", should be a "HORIZONTAL ELLIPSIS"
character "…" with unicode scalar value U+2026.  In the UTF-8 encoding,
the horizontal ellipsis is represented by three bytes with hex codes E2,
80, and A6.  The three weird characters "…" are what you get when
those three bytes are misinterpreted as Latin-1, a.k.a. ISO-8859-1
encoding.

Guile only outputs Unicode HORIZONTAL ELLIPSIS in backtraces if your
current locale has an encoding for that character.  Otherwise, it will
print three ASCII periods ("...") instead.  So, it appears that your
locale environment variables (the ones printed by the "locale" command)
are configured for a UTF-8 locale.

I guess that somewhere else in your system, something is configured to
use Latin-1 (ISO-8859-1) encoding.  It could be Emacs itself, or perhaps
your terminal emulator.

   Mark

Re: guix package conflict

[Mark H Weaver]

Pierre Neidhardt  writes:

> Carlo Zancanaro  writes:
>
>> It looks like `guix package -u` compares the version of the 
>> package, and only updates if the package's version has changed 
>> (and even then, only if it has increased).

What leads you to believe this?

I think you're mistaken, based both on past experience and also from
examining the current code.  The relevant procedure is
'transaction-upgrade-entry' in (guix scripts package), here:

  
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm?id=c383c36edeb7eb358f142c52276d6e5d32bda044#n225

You can see there where 'version-compare' is used to compare the
candidate version and the existing version.  If the version numbers are
equal, then the derivation output paths are compared.  If the output
paths differ, the new version will be reinstalled.

This is certainly the behavior I remember from using --upgrade myself
during the early years of Guix, although in recent years I've been
using the declarative approach to maintain my profile, using
"guix package --manifest".

>> This means that if a 
>> package's inputs (and thus its store hash) have changed, but its 
>> version has not, the version left in the profile will have 
>> outdated inputs, which can conflict if they are propagated. So 
>> `guix package -u` doesn't fix this problem.
>>
>> `guix package -i`, on the other hand, just installs whatever it's 
>> told to, so it will install the same package at the same version, 
>> but with updated inputs. Then all the propagated inputs end up 
>> being the same, so there is no conflict.
>
> I didn't know that! O.o
> Is this documented in the manual?

I hope not.  If it truly behaves the way Carlo described, it's a bug.

 Thanks,
   Mark

Re: Need help displaying Unicode fonts in Icecat

[Mark H Weaver]

Hi Gary,

Gary Johnson  writes:

>> Are you running Guix on top of another distribution? I had to add the
>> veriable XDG_DATA_DIRS to the environment, specifically
>> XDG_DATA_DIRS=$HOME/.guix-profile/share:/usr/share for Guix running on
>> Debian. The variable was set automagically full Guix systems.
>>
>> HTH,
>> jr
>
> Thanks, jr. I'm running GuixSD and I believe XDG_DATA_DIRS is set
> correctly:
>
> $ echo $XDG_DATA_DIRS
> /gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share:/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share:/gnu/store/l35xlc0hk86qw7kwli8lkskdkxskxsif-gtk+-3.24.9/share:/gnu/store/fbf0h779z46cl55vdciv00m8s0ccfnyb-emacs-26.2/share:/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share:/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share:/gnu/store/l35xlc0hk86qw7kwli8lkskdkxskxsif-gtk+-3.24.9/share:/gnu/store/fbf0h779z46cl55vdciv00m8s0ccfnyb-emacs-26.2/share:/home/gjohnson/.guix-profile/share:/home/gjohnson/.guix-profile/share:/run/current-system/profile/share:/home/gjohnson/.guix-profile/share:/run/current-system/profile/share
>
> I just see boxes in IceCat and Ungoogled-Chromium wherever Unicode
> symbols are supposed to appear, so I don't know if there is another font
> package that I need to install or some browser-specific configuration
> files that I need to edit.

Are you sure that the environment variables are set in the IceCat
process?  The most reliable way to find out is to look in
/proc//environ, where  is the process ID of the IceCat
process.

Note that environment variables are not global to your session.  In
general, each process has its own set of environment variables which are
typically passed down from parent processes to child processes.  So, it
could be that your shells have the XDG_DATA_DIRS environment variable
set, but that your graphical window manager (or equivalent) doesn't have
it set.

If all else fails, I would recommend running IceCat within strace, like
this:

  strace -o trace.out icecat

and wait until IceCat fully comes up, and then quit and look in
'trace.out', searching for "share/fonts".  The clues of what's going
wrong should be in there somewhere, buried in a mountain of other
output.  See below for the relevant lines that I see in my 'trace.out'.

  Mark


--8<---cut here---start->8---
stat("/home/mhw/.guix-profile/etc/xdg", {st_mode=S_IFDIR|0555, st_size=24, 
...}) = 0
stat("/run/current-system/profile/etc/xdg", {st_mode=S_IFDIR|0555, st_size=82, 
...}) = 0
stat("/gnu/store/xii7ibhwnxcb9wp4chrv5if675p54jlg-gtk+-3.24.9/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/v93ni4aqlbh05qas779i453p02nj8d3n-gtk+-3.24.9/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/hn6ndmw2ii8p7wr61bbv35wwa3898ikr-emacs-26.2/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/v93ni4aqlbh05qas779i453p02nj8d3n-gtk+-3.24.9/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/hn6ndmw2ii8p7wr61bbv35wwa3898ikr-emacs-26.2/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/7r9nnf297vsknl4cg02ymaszm79v6063-geocode-glib-3.26.0/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/x1ilifw5d41a81fpqbig1p0n268a7jq1-gtk+-3.24.9/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/qqaghlk7nvnjsrbdvpz7pkf1c8sffnrg-telepathy-logger-0.8.2/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/9jjnk994sg3kynx7w2p873x60yr27q1p-pulseaudio-12.2/share/fonts", 
0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/b20ijqhpzb6mm4qi1hk0s8cj448vyv67-network-manager-applet-1.8.14/share/fonts",
 0x7ffd2fa065b0) = -1 ENOENT (No such file or directory)
stat("/gnu/store/b9vc5f6ii59zh8z6cpl0j9cah84rpgqm-mutter-3.28.2/share/fonts", 
0x7ffd2fa065b0) 

Re: Ho to hide settings on a new tab Icecat

[Mark H Weaver]

Hi,

zna...@disroot.org writes:

> Hello! Need to set 'Search' and 'Top sites' blocks to the top of Icecat tab.
> But there is 'Privacy settings' block in the top, screen: 
> http://0x0.st/zOid.png
> Please, how to hide or delete it at all?

I don't know off-hand, but I would suggest asking the question on
, the mailing list for IceCat.  This question is
not specific to Guix.

   Mark

Re: IceWeasel-UXP and IceDove-UXP

[Mark H Weaver]

Hello,

guixuser  writes:
> Asking the new users to package what they want and suggesting
> alternative applications; is like passively showing middle finger to
> them.

This idea seems to pop up from time to time, and I think it deserves a
closer look.

First of all, we're not asking you to do anything.  Rather, you are
asking us to do something.  You are asking us to do the development work
to add the packages you need.

For what it's worth, I've spent hundreds of hours over the last few
years maintaining the GNU IceCat package in Guix, and at least 40 hours
trying to get IceDove working.  Sorry, but I got stuck and ran out of
energy.  I'm under no moral obligation to finish that work.  I'm not
standing in the way of someone else doing it, and I never promised
anyone that I'd finish it.  Also, incidentally, I've never made a penny
from working on Guix.

You seem to be suggesting that my failure to finish this work is
tantamount to showing you my middle finger (which is a strong insult in
my culture, for the benefit of those who might not know).  More to the
point, you seem to be implying that I have a moral obligation to add the
missing packages that you desire.

Please keep in mind that we are not a business who sold you a product.
We are a widely dispersed group of volunteers from around the world who
built this system to meet our own needs, and we decided to offer it as a
gift to anyone else who wants it.  Moreover, we have taken pains to
ensure that you have the freedom to change this gift as you wish, to
better meet your own needs.

You apparently find this gift intriguing in some ways, but also
disappointing in other ways.  I'm sincerely sorry if this gift is not
satisfactory to you, but please understand that we are under no
obligation to do anything more for you.  That's not an insult, it's
simply me saying that you have no right to demand more of me.  If you
don't like the gift, don't use it.  No one is pushing it on you.

If you invited me to your home for dinner, and I didn't like the food,
should I feel entitled to demand that you go back into the kitchen and
cook my chosen dish?  If you told me "you're free to use the kitchen to
cook it yourself", should I take that as an insult?

  Mark

Re: Compiling a linux kernel from git

[Mark H Weaver]

Hi Chris,

Christopher Lemmer Webber  writes:
> Thanks!  I got things working by going the tarball route, though
> slightly more indirectly than the approach you suggested here.  What I
> did was get the latest release-candidate tarball and list the patches I
> specifically needed in the package definition.  Happily this worked!
>
> Happy to say I'm on my way to the conference with a functioning laptop.

I'm very glad to hear it! :)

FYI, I filed a bug to discuss the underlying issue that led to this
surprising breakage: 

 Best,
  Mark

Re: Compiling a linux kernel from git

[Mark H Weaver]

Hi Chris,

I wrote earlier:
> My first guess is that '/gnu/store/…-linux-next-…-checkout/include'
> should not be in the C include path while compiling that file, but that
> it's getting added.  The difference might be due to the fact that the
> 'source' in this case is a directory instead of a tarball.

I see now what's happening more precisely.  Our gcc-7 package inherits
from gcc-6 'native-search-paths' for the CPATH variable.  Because of
this, the 'set-paths' phase in 'gnu-build-system' sets the CPATH to
include /include for all native inputs that are
directories with an 'include' subdirectory.

The 'source' is itself a native input.  When it's a tarball, it will not
be included, but when it's a source checkout, it _is_ included, although
it shouldn't be.

> For now, I would try packing the git checkout as a tarball, and then
> using that tarball as your 'source'.

I'm now fairly confident that this workaround would work.  Another
workaround would be to add another phase that removes the CPATH
component corresponding to 'source', as Tobias does.

  Mark

Re: Compiling a linux kernel from git

[Mark H Weaver]

Hi Chris,

Christopher Lemmer Webber  writes:

> Unfortunately my laptop was failing and I needed to pick up a new one
> asap before a conference I leave for tomorrow morning, so I bought one
> off the shelf from a retail store.  Also unfortunately, while the
> hardware is supported in upstream linux, it isn't in any of the released
> tarballs yet.  I thought I'd try to make a package derivative:
>
> (define linux-next
>   (package
>(inherit linux-libre)
>(name "linux-next")
>(version "22c45ec32b4a9fa8c48ef4f5bf9b189b307aae12")
>(source
> (origin
>  (method git-fetch)
>  (uri (git-reference
>(url (string-append "https://git.kernel.org/pub/scm/linux/;
>"kernel/git/next/linux-next.git"))
>(commit version)))
>  (file-name (string-append "linux-next-" version "-checkout"))
>  (sha256
>   (base32
>"1f3fn2mcfa213vb0d40386533dy4nll9v9d2jc6bi7gd38z2rc18"))
>
> Unfortunately an extra step seems to be necessary, or something.  It's
> failing at the "make oldconfig" stage:
>
>
> patch-shebang: ./tools/usb/usbip/autogen.sh: changing `/bin/sh' to 
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> patch-shebang: ./tools/usb/usbip/cleanup.sh: changing `/bin/sh' to 
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> patch-shebang: ./tools/usb/usbip/vudc/vudc_server_example.sh: changing 
> `/bin/bash' to 
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash'
> patch-shebang: ./tools/virtio/ringtest/run-on-all.sh: changing `/bin/sh' to 
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> patch-shebang: ./tools/vm/slabinfo-gnuplot.sh: changing `/bin/bash' to 
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash'
> patch-shebang: ./usr/gen_initramfs_list.sh: changing `/bin/sh' to 
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> phase `patch-source-shebangs' succeeded after 4.8 seconds
> starting phase `work-around-gcc-7-include-path-issue'
> phase `work-around-gcc-7-include-path-issue' succeeded after 0.0 seconds
> starting phase `configure'
> `ARCH' set to `x86_64'
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/kconfig/conf.o
> In file included from 
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/stdlib.h:394:0,
>  from scripts/kconfig/conf.c:9:
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/sys/types.h:42:18:
>  error: conflicting types for 'loff_t'
>  typedef __loff_t loff_t;
>   ^~
> In file included from 
> /gnu/store/3qbgfljvmyi12df4yiwjnlg7mwkc4z1y-linux-next-22c45ec32b4a9fa8c48ef4f5bf9b189b307aae12-checkout/include/linux/limits.h:6:0,
>  from 
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/bits/local_lim.h:38,
>  from 
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/bits/posix1_lim.h:161,
>  from 
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/limits.h:183,
>  from 
> /gnu/store/rvv5rw5gcrpmbgnvhb60f7czk0m0h2qp-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed/limits.h:194,
>  from 
> /gnu/store/rvv5rw5gcrpmbgnvhb60f7czk0m0h2qp-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed/syslimits.h:7,
>  from 
> /gnu/store/rvv5rw5gcrpmbgnvhb60f7czk0m0h2qp-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed/limits.h:34,
>  from scripts/kconfig/conf.c:7:
> /gnu/store/3qbgfljvmyi12df4yiwjnlg7mwkc4z1y-linux-next-22c45ec32b4a9fa8c48ef4f5bf9b189b307aae12-checkout/include/linux/types.h:46:26:
>  note: previous declaration of 'loff_t' was here
>  typedef __kernel_loff_t  loff_t;
>   ^~

My first guess is that '/gnu/store/…-linux-next-…-checkout/include'
should not be in the C include path while compiling that file, but that
it's getting added.  The difference might be due to the fact that the
'source' in this case is a directory instead of a tarball.  For now, I
would try packing the git checkout as a tarball, and then using that
tarball as your 'source'.

   Mark

Re: Consider the package expr evaluates to.

[Mark H Weaver]

Hi,

zna...@disroot.org writes:

> 'Expression is evaluated'??
> Maybe better is 'the package that matches expression'?

No, that's definitely not right.  That wording suggests some kind of
pattern matching, which is not what's happening at all.  Evaluation is a
process that takes an expression and produces a value.  For example,
(+ 1 2) is an expression that evaluates to 3.  The expression is a list
with three elements: the symbol +, the number 1, and the number 2.  The
result of evaluating that expression is the number 3.

> 'Consider' - here it means 'to use'. But dictionary meaning of
> 'consider' is 'think about', 'regard' [1], so this is hard for
> understanding.

I agree that the word "consider" is a bad choice in that sentence.
It would be better to change "consider" to "use".

 Thanks,
   Mark

Re: grub with encrpted root no longer automatically loads luks

[Mark H Weaver]

Hi Jack,

Jack Hill  writes:

> I've noticed that recently (unfortunately, I don't know exactly when
> it started), that grub no longer prompts me to enter my password to
> unlock my root filesystem.

FWIW, I also use an encrypted root filesystem on my Guix system, and
I've updated Guix since you reported the problem, and it works for me.
GRUB continues to prompt me for the LUKS passphase at boot.

One notable difference between our system configurations is that you
have a separate /boot filesystem, and I don't.  All I have is a single
encrypted root filesystem, plus %base-file-systems.  I wonder if this
might be the relevant difference?

 Regards,
   Mark

> I notice that at the grub command line, if
> I enter `cryptomount -a`, I am not prompted for a password, and the
> root filesystem does not become available. However, if I first run
> `insmod luks` and then `cryptomount -a`, I am prompted for my
> password, and the root filesystem become available and I can boot
> normally.
>
> Therefore, it seem like grub is not auto-loading the luks module for
> some reason. Why might this be the case? What needs to be changed so
> that luks is auto loaded?
>
> Best,
> Jack
>
> my config.scm:
>
> ;; This is an operating system configuration template
> ;; for a "desktop" setup with GNOME and Xfce where the
> ;; root partition is encrypted with LUKS.
>
> (use-modules (gnu) (gnu system nss) (gnu services xorg)
>(gnu packages linux))
> (use-service-modules desktop)
> (use-package-modules certs gnome scanner security-token)
>
> (operating-system
>  (host-name "alperton")
>  (timezone "America/New_York")
>  (locale "en_US.utf8")
>
>  (bootloader (bootloader-configuration
> (bootloader grub-bootloader)
> (target "/dev/sda")))
>
>  ;; Specify a mapped device for the encrypted root partition.
>  ;; The UUID is that returned by 'cryptsetup luksUUID'.
>  (mapped-devices
>   (list (mapped-device
>(source (uuid "f7776767-70c9-44e3-9973-c1334d301348"))
>(target "alperton_root")
>(type luks-device-mapping
>
>  (file-systems (cons*
>   (file-system
>(device (file-system-label "boot"))
>(mount-point "/boot")
>(type "ext4"))
>   (file-system
>(device (file-system-label "alperton_root"))
>(mount-point "/")
>(type "ext4")
>(dependencies mapped-devices))
>   %base-file-systems))
>
>  (swap-devices (list "/root/swap"))
>
>  (users (cons (user-account
>  (name "jackhill")
>  (comment "Jack Hill")
>  (group "users")
>  (supplementary-groups '("wheel" "netdev"
>  "audio" "lp" "video"))
>  (home-directory "/home/jackhill"))
> %base-user-accounts))
>
>  ;; This is where we specify system-wide packages.
>  (packages (cons* nss-certs ;for HTTPS access
> fuse-exfat
> gvfs  ;for user mounts
> %base-packages))
>
>  ;; Add GNOME and/or Xfce---we can choose at the log-in
>  ;; screen with F1.  Use the "desktop" services, which
>  ;; include the X11 log-in service, networking with
>  ;; NetworkManager, and more.
>  (services (cons* (service gnome-desktop-service-type)
> (bluetooth-service)
> (simple-service 'custom-udev-rules udev-service-type (list 
> sane-backends libu2f-host))
> %desktop-services))
>
>  ;; Allow resolution of '.local' host names with mDNS.
>  (name-service-switch %mdns-host-lookup-nss))

Re: How to configure Xorg to use [proprietary] Sis 771 driver on Guix?

[Mark H Weaver]

zna...@disroot.org writes:
> Mark, this is my lspci, lsmod, guix describe:

Can you share the contents of your /var/log/Xorg.0.log ?  That should
show us which video driver(s) were loaded and any relevant error
messages.

   Mark

Re: How to configure Xorg to use [proprietary] Sis 771 driver on Guix?

[Mark H Weaver]

Tobias Geerinckx-Rice  writes:

> Mark H Weaver wrote:
>> Guix already has 'xf86-video-sis', and it's already included in
>> %default-xorg-modules in (gnu services xorg).  So, now we just need
>> to
>> find out why it's not working.
>
> Is this even the same driver?

I don't understand the question.  Same driver as what?

  Mark

Re: How to configure Xorg to use [proprietary] Sis 771 driver on Guix?

[Mark H Weaver]

Hello,

Tobias Geerinckx-Rice  writes:

> On a more positive note: have you looked at
>
>  https://aur.archlinux.org/packages/xf86-video-sisimedia/
>  (or https://aur.archlinux.org/packages/xf86-video-sis/)?

Guix already has 'xf86-video-sis', and it's already included in
%default-xorg-modules in (gnu services xorg).  So, now we just need to
find out why it's not working.  Maybe one of the other video modules
guesses that it can support the hardware, but it actually fails?  In
that case, it might help to move 'xf86-video-sis' higher up in the list
of modules to try.

  Regards,
Mark

Re: Computer suspends even when I tell it not to

[Mark H Weaver]

Hi Chris,

Chris Marusich  writes:

> I've noticed that my Guix System computer suspends if I leave it alone
> for a couple hours.  It's plugged in.  This is annoying, since sometimes
> I want to SSH into this computer, and I can't do that if it's suspended.
>
> I don't understand why it suspends.  I've run guix pull recently, so
> it's up to date.  I use GNOME.  In the GNOME settings' "Power" section,
> I've explicitly set "Automatic suspend" to "Off".  However, it still
> suspends automatically after a while.

FWIW, I've never seen this on my Thinkpad X200 running Guix.  I also use
GNOME, although I use it under Wayland, by running

  XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session

from within a text console.  I don't use GDM, because our GDM package
does not yet support Wayland.

Note that GDM is enabled in my OS config and gets launched on every
boot, but I then shut it down manually using "herd stop xorg-server".
After doing so, I need to type "Alt+SysRq+r" to recover the use of my
keyboard.

> Does anyone else experience this?  What else can I try?

It might be worth trying to do what I describe above, to rule out the
possibility that GDM is responsible.

What kind of machine is it?  If it's a laptop, I wonder if your laptop's
embedded controller is entering suspend mode automatically.

  Regards,
Mark

Re: IceCat from Guix all monospaced font – Summary

[Mark H Weaver]

Zelphir Kaltstahl  writes:

> Ah it could be, that a package changed something in `~/.profile`. I will
> check … No it still looks the same as before.

Guix never modifies your ~/.profile.  The relevant file is:
~/.guix-profile/etc/profile, which is generated each time you update
your user profile.  On a Guix system, it is sourced from /etc/profile.

On other systems, you should arrange to source that file in your login
shell with GUIX_PROFILE set appropriately, e.g. with the following code
in your ~/.bash_profile or equivalent:

  GUIX_PROFILE="$HOME/.guix-profile" ; \
  source "$HOME/.guix-profile/etc/profile"

This is recommended in section 4.2 of the Guix manual, here:

  
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html

> Also I think any installation adding something to my `~/.profile`
> should tell the user about such a change.

Again, Guix will never do this.  However, 'guix package' should tell you
if you're missing environment variable settings that are needed by the
newly installed packages.

> No package I installed yesterday did so.

Hmm.  Are you confident about this?  If so, that casts doubt on my
hypothesis that this was about missing environment variable settings.
Unfortunately, I currently have no other hypothesis to explain why a
reboot was required to fix your IceCat.

Mark

Re: Guix System 1.0: No audio

[Mark H Weaver]

Hi sirgazil,

sirgazil  writes:

> I installed the GNU system with GNOME using the ISO installer 
> (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz).
>
> When I play video or audio in the browser or in the desktop, I get no
> audio. The volume controls in the browser and desktop show the sound
> is not disabled.

Have you been able to get any sound to come out of the speakers at all
in Guix?  For example, when you change the volume using the slider in
the menu from the top-right corner in GNOME Shell, do you hear the sound
effects when you let go of the slider at a high volume level?

Which browser(s) did you try?

> There are no errors about missing codecs or anything
> like that. The media plays, but there is no audio coming out from the
> speakers (which are on). Audio and speakers worked fine in the distro
> I was using before installing GNU with Guix.
>
> Maybe I need additional packages or services?

Quite possibly.  I include the following packages in my user profile:

   gstreamer
   gst-plugins-base
   gst-plugins-good
   gst-libav

Specifically, the addition of 'gst-libav' adds plugins for many popular
codecs that would otherwise be unavailable.  The 'gstreamer' package
needs to be in the same profile as the 'gst-*' packages, or else
GST_PLUGIN_SYSTEM_PATH might not be set appropriately to find the
plugins.

These codecs are needed by Epiphany (a.k.a. GNOME Web) and many other
GNOME applications.  However, they shouldn't be needed by IceCat, which
links directly with ffmpeg and doesn't use gstreamer.

   Mark

Re: GNOME Desktop

[Mark H Weaver]

Hi Dexter,

"Dexter Morgan"  writes:
>How can I use GNOME Core Applications
>(https://en.wikipedia.org/wiki/GNOME_Core_Applications) that are
>missing in Guix System? I am quite frusturated and disappointed with
>the GNOME Desktop in Guix. I can't even use a music player or a
>calendar.

I'm sorry to hear it.

FWIW, we have a large selection of music players in Guix.  Two that are
built on GNOME libraries include 'rhythmbox' and 'lollypop', but there
are many others, too many to list here.

For calendaring programs, we currently have 'gnome-calendar' and
'evolution', and possibly others.

>I thought I do not have deal with additional applications if
>I use a Desktop Environment, but it seems GNOME Desktop in Guix is
>incomplete. :(. Are there any tricks to enable and use these missing
>applications please?

Simply install your preferred applications to your user profile, or
alternatively you could add them to the 'packages' field of your system
profile.

It's possible that our GNOME desktop should include more programs by
default.  Can you tell us specifically which programs you think should
be added?

In the area of music players and calendars, I suspect that no matter
what choices we make here, a large percentage of our users will not want
our default choices.  Most people seem to have specific programs that
they prefer to use, and there's not much agreement in these areas.

Moreover, sadly, I get the impression that most of the younger
generation prefer to use web-based Services as a Software Substitute
(SaaSS)[1] for their music and calendaring needs.

So, if we add a default music player and calendar, I suspect that for
many (if not most) users, those defaults will merely be unwanted bloat.
Some users will ask how to remove the defaults, to avoid repeatedly
downloading substitutes for programs they don't want, which will be
awkward.

Given this, it seems a reasonable choice to let users explicitly install
their preferred programs.  Does that make sense?

What do you think?

Regards,
  Mark

[1] https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

Re: IceCat from Guix all monospaced font – Summary

[Mark H Weaver]

Giovanni Biscuolo  writes:

> HWRoitzsch  writes:
>
>> So apparently all that was needed after the steps suggested on the
>> mailing list was a restart of my machine or possibly a re-login.
>
> may it be connected to the evironment?
>
> I guess you are using Guix System on bare metal or VM, I'm using Guix on
> a foreign distro instead
>
> sometime installing new software updates $GUIX_PROFILE/etc/profile [1]
> adding needed env variables, those variables are usually loaded via
> ~/.profile when using Guix on foreign distro so sometimes I have to
> reload ~/.profile to get an updated environment
>
> I have not enough experience with a full Guix System: could it be the
> same? this would explain why you had to logout/login for IceCat to use
> the right fonts

This sounds very plausible to me.  My guess is that one of the packages
that Zelphir installed added new environment variable settings that are
needed for IceCat to find its fonts.

  Mark

Re: IceCat from Guix all monospaced font

[Mark H Weaver]

Hi Zelphir,

Zelphir Kaltstahl  writes:
> The problem is solved for me now. Would an "strace" still be helpful?

I'm not sure.  It depends on whether we're able to understand from your
upcoming email what went wrong and how to fix it properly.

> I will write another mail to the list, summarizing what I have tried and
> that it works now.

Please do send that email when you can.  I'm glad it's working for you
now, but it would also be good to fix it properly so that other users
will not hit the same bug.

> Thank you for your detailed idea about how to progress nevertheless.

Glad to help.  Thanks for reporting the issue.

  Mark

Re: IceCat from Guix all monospaced font

[Mark H Weaver]

Hi Zelphir,

Zelphir Kaltstahl  writes:

> Today I installed GNU Icecat from Guix and everything works fine, except
> for one thing:
>
> The whole Icecat UI uses a monospaced font and on every website
> everything is monospaced. I've tried for hours to change fonts using
> userChrome.css to no avail. I also tried inspecting the UI using the
> browser toolbox and it shows, that my userChrome.css set values are used
> for the UI. Although in that inspector I see font family values like
> "Liberation Sans" and "DejaVu Sans" and "sans-serif", the UI _actually_
> still is monospaced.
>
> While I generally like "monospaced-ness", the problem is, that it breaks
> Icecat's UI in many places, as the UI is not flexible enough to render
> all texts and often cuts text overflow, as the monospaced font is wider
> than what one would usually have.
>
> My guess is, that somehow Icecat installed via Guix is not able to pick
> up system wide installed fonts and always, no matter what I set, falls
> back to a monospaced font. Following this guess, I installed Liberation
> fonts and DejaVu fonts in Guix. However, still everything is monospaced.

It might be helpful to run "strace -f -o trace.out icecat" until the
problem is apparent, then quit, and look in "trace.out" for clues.
I just did that on my Guix system where IceCat works well, and I've
included the relevant excerpt below.

Can you find the corresponding excerpt from your trace.out, and show it
to us?  Please don't send the whole thing, partly because it's huge, and
partly because it might include information that should be kept private.

FYI, on my Guix system I have GNOME in my system profile, and in my user
profile I have IceCat, font-dejavu, freetype, and fontconfig, among many
others.  I didn't install 'fontconfig' explicitly, but it was added
implicitly to my user profile as a propagated-input.

Presumably our IceCat package implicitly depends on some other package.
If we can find out what that is, we can probably fix this issue with a
suitable wrapper.

 Thanks,
   Mark


--8<---cut here---start->8---
5233  stat("/home/mhw/.guix-profile/etc/xdg", {st_mode=S_IFDIR|0555, 
st_size=24, ...}) = 0
5233  stat("/run/current-system/profile/etc/xdg", {st_mode=S_IFDIR|0555, 
st_size=82, ...}) = 0
5233  
stat("/gnu/store/9v1505spjs16icl5v2y76dbp4504yvn1-gtk+-3.24.7/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/2d1iqzza547320wrfg6yvsr54j5hfw3c-gtk+-3.24.7/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/cgwlg3q40znx0rwjan0b3jn38x31hldn-emacs-26.2/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/2d1iqzza547320wrfg6yvsr54j5hfw3c-gtk+-3.24.7/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/cgwlg3q40znx0rwjan0b3jn38x31hldn-emacs-26.2/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/vkn4l06y4932i81zs68yig238hvhnvwx-geocode-glib-3.26.0/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/daxn8m96wk2d2jnz4mxllhk34iv5gjqp-shared-mime-info-1.9/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/2d1iqzza547320wrfg6yvsr54j5hfw3c-gtk+-3.24.7/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/l2bkkzvzxbfw81i364f2mm6cb8sdk1y8-telepathy-logger-0.8.2/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/s795jav4270x940spl48a885nhw4axnx-pulseaudio-12.2/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/6c153g3cfrz7qr3jrfdn38fssh6axhhm-network-manager-applet-1.8.14/share/fonts",
 0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  
stat("/gnu/store/jzyfi0aq3qmyk0y2am25z8h07gr1h204-mutter-3.28.2/share/fonts", 
0x7ffd9f2521c0) = -1 ENOENT (No such file or directory)
5233  

Re: GuixSD on a laptop with Heads

[Mark H Weaver]

Hi Jonathan,

"Jonathan Frederickson"  writes:

> Hey - so I'm trying to get GuixSD running on a Thinkpad X230 running Heads.
> (https://github.com/osresearch/heads) For some background: this system boots
> into a Linux environment, has scripts that parse the GRUB config, and boots
> into the final system using kexec.
>
> The Heads boot scripts do not currently support booting from a system with
> full disk encryption, so I'm attempting to boot manually to start (after which
> I can patch the scripts to replicate what I did). However, I'm running into
> some issues when attempting to boot into the new kernel - the moment I run
> kexec, I get no output onscreen from the new kernel:
>
> https://imgur.com/a/r2lFD7k

I was unable to easily find a way to view this image without running
nonfree Javascript code on my machine.  Can you please send the image in
an attachment?

Also, what was the precise kexec command that you used?

 Thanks,
   Mark

Re: sha256 hash mismatch for mozjs-38.2.1.rc0

[Mark H Weaver]

Hi,

Platoxia  writes:

> After successfully doing "guix pull" as root, GuixSD fails to update from 
> /gnu/store/nbpba96q5vjhr64c91s788109mj7f3y6-system (kernel 4.20.1) 
> to current with "guix system reconfigure" due to an sha256 hash mismatch 
> after downloading mozjs-38.2.1.rc0.  
>
> I have attempted this system reconfiguration 3 times in as many weeks and 
> this failure always occurs for me. I am uncertain if this issue is unique 
> to me which is why I am posting here rather than making a bug report. It 
> could simply be a case of the mozjs-38 hash needing to be updated
> in gnuzilla.scm.
>
> From Guix System Reconfigure log:
>
> building 
> /gnu/store/x1k7m8k5n39ydbayh2mn57514sh77jyp-mozjs-38.2.1.rc0.tar.bz2.drv...
> downloading from 
> https://people.mozilla.org/~sstangl/mozjs-38.2.1.rc0.tar.bz2...

Indeed, the URL above is no longer valid.  It returns some kind of error
page.  In general, when this happens, you can work around the problem by
finding another copy of the same file somewhere else.  Often it is
sufficient to type the file name into a search engine.  I found this:

  http://anduin.linuxfromscratch.org/BLFS/mozjs/mozjs-38.2.1.rc0.tar.bz2

Now, if you type "guix download ", it will download the file and
add it to your store.  If it has the correct hash, it will be used
automatically when you repeat the "guix system reconfigure" command.

(If it has the wrong hash, it will be ignored and eventually removed the
next time you perform a garbage collection with "guix gc").

> The mozjs-38 definition as found in gnuzilla.scm:
> (define-public mozjs-38
>   (package
> (inherit mozjs)
> (name "mozjs")
> (version "38.2.1.rc0")
> (source (origin
>   (method url-fetch)
>   (uri (string-append
> "https://people.mozilla.org/~sstangl/;
> name "-" version ".tar.bz2"))

Indeed, in order to properly fix this problem, the code above needs to
be updated.

Clément: I see that you added our 'mozjs-38' package about a year ago.
Would you be willing to find a new source URL for it, and possibly to
update to a newer 38.x version?  It might be easier to find a stable URL
for a non-RC version, and it looks like several other distros now have
mozjs-38.8.0.

   Mark

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Hello again,

"Raghav Gururajan"  writes:

> Ah I see. Thanks for raising the issue. Yes, we'll move on to "Stylus Input" 
> :)
>
> April 16, 2019 4:22 PM, "Mark H Weaver"  wrote:
>
>> Hi Raghav,
>> 
>> "Raghav Gururajan"  writes:
>> 
>>> I made the changes you told me. Now the error is "guix system: error:
>>> /etc/rg-secondary.scm:49:24: no value specified for service of type
>>> 'fprintd'"
>> 
>> Sorry, this looks like a genuine bug in Guix's fingerprint service,
>> which was added relatively recently, and apparently has not yet seen
>> much use. I've just raised the issue with the author of that service,
>> so hopefully it'll be fixed soon. In the meantime, I would suggest
>> removing:
>> 
>> (service fprintd-service-type)

The author of 'fprintd-service-type' has pushed a fix.  After a fresh
"guix pull", you could try adding the line above to your OS config, and
it might work now.

  Regards,
Mark

Re: Way to synchronize files like Dropbox

[Mark H Weaver]

Please do not post instructions for installing nonfree software on
official Guix project forums.

 Thanks,
   Mark


Meiyo Peng  writes:

> You should not run non free software on your computer.  But if you have
> to use Dropbox for whatever reason, there is actually a way to run
> Dropbox on Guix.
>
> Disclaimer: I don't run Dropbox on my computer now.  This is a generic
> method to run binary-distributed dynamically-linked foreign apps on
> Guix.  THIS IS DEFINITELY NOT OFFICIALLY SUPPORTED BY THE GUIX
> MAINTAINERS TEAM.  YOU SHALL FIX ANY BUGS BY YOURSELF WHILE DOING SO.
>
>
> Instructions for running Dropbox on Guix system x86_64:
>
> 0. Pray with me.
>
> #+BEGIN_QUOTE
>   Forgive me Stallman for I have sinned.
> #+END_QUOTE
>
>
> 1. Download Dropbox for Linux from https://www.dropbox.com/install-linux.
[...]

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Hi Raghav,

"Raghav Gururajan"  writes:

> I made the changes you told me. Now the error is "guix system: error:
> /etc/rg-secondary.scm:49:24: no value specified for service of type
> 'fprintd'"

Sorry, this looks like a genuine bug in Guix's fingerprint service,
which was added relatively recently, and apparently has not yet seen
much use.  I've just raised the issue with the author of that service,
so hopefully it'll be fixed soon.  In the meantime, I would suggest
removing:

  (service fprintd-service-type)

and hopefully we can progress on the other issues.

 Regards,
   Mark

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Hi Raghav,

"Raghav Gururajan"  writes:

> So my latest config is:
>
> (use-modules
> (gnu)
> (gnu system nss)
> (gnu services fingerprint)
> (use-service-modules desktop)
> (use-package-modules certs gnome)

[...]

> For the above, the error is:
>
> guix system: error: failed to load '/etc/rg-secondary.scm':
> ice-9/boot-9.scm:2803:6: In procedure resolve-interface:
> no code for module (gnu services fingerprint)

Please remove (gnu services fingerprint) from your 'use-modules' form.
Sorry, I had asked you to add it, but it was a mistake from the manual,
which gives the wrong module name.

The correct module name is:

  (gnu services authentication)

which you can import by adding "authentication" to the
'use-service-modules' form.  This should fix the "unbound variable"
error.

In an earlier message you spoke of another error:

> but then new error regarding specifying values. :(

If you're still getting that error, can you show us the exact error
message and the configuration file that caused it?

 Regards,
   Mark

Re: kicking off nm again

[Mark H Weaver]

Hi,

zna...@disroot.org writes:

> Hello! I need your advise in my `holly war` for guix purity in my 
> low-capacity Laptop.
>
> While `guix pull && guix system reconfigure
> config-znavko-12-04-2019.scm` worked, Network-Manager and some other
> stuff have pervaded.

[...]

> 1) Let me know how to delete nm, if I've removed it from services in
> %desktop-services, but gdm or gnome pulled it into my system.
>
> 2) libgweather. Also, I do not need lbgweather. arc-theme depends on
> it again? Sorry, I do not use gnome.
>
> 3) geocode-glib. Gnome is so fat. How to cut it off? Can I have gdm
> without gnome?
>
> 4) gnome-online-accounts
>
> 5) evolution-data-server
>
> 6) network-manager-applet
>
> 7) mutter, what's this? I think xfce4 does not use it. How to kick it out?

One reason that all of this stuff is being pulled in is because you're
using GDM as your display manager:

> (services (cons* 
>(service xfce-desktop-service-type)
>(service dhcp-client-service-type)
>
>(modify-services  
> (remove (lambda (service)
>   (member (service-kind service)
>   (list ntp-service-type 
> avahi-service-type 
> bluetooth-service 
> network-manager-service-type)))
> %desktop-services) ;end of remove lambda 
> services
>
> (wpa-supplicant-service-type config =>
>  
> (wpa-supplicant-configuration
>   (interface "wlp2s0")
>   (config-file 
> "/etc/wpa_supplicant/wpa_supplicant.conf")))
>
> (gdm-service-type config =>
>   (gdm-configuration
>(xorg-configuration
> (xorg-configuration
>  (extra-config  
>   '("Section \"InputClass\"
> Identifier \"touchpad\"
> Driver \"libinput\"
> MatchIsTouchpad \"on\"
> Option \"Tapping\" \"on\"
> EndSection")
>   )

If you don't want GNOME, then you must not use GDM.  GDM actually runs a
little GNOME 3 session even before you log in.  It will pull in much of
the GNOME 3 stuff.

If you want a lightweight system, add 'gdm-service-type' to the list of
things to remove from %desktop-services, and use 'slim-service-type'
instead.

   Mark

Re: Unexpected XDG and GTK+ with system reconfigure

[Mark H Weaver]

Hi,

mikadoZero  writes:

> I am seeing some unexpected activity listed in the output of
> `guix system reconfigure`.
>
> I am not expecting to see:
>
> * XDG activity as the system configuration does not include anything
>   related to xorg 
> * GTK+ activity as there are no graphical programs in the system
>   configuration
>
> The four unexpected activities are:
>
> creating GTK+ icon theme cache...
> building cache files for GTK+ input methods...

These two are done whenever GTK is in the transitive inputs of the
packages installed in the profile.

> building XDG desktop file cache...
> building XDG MIME database...

These two are done whenever GLib is in the transitive inputs of the
packages installed in the profile.

> The services and packages part of my system configuration are:
>
> ...
> (use-service-modules networking ssh virtualization)
> ...
> (use-package-modules certs virtualization)
> ...
>   (packages (cons* nss-certs qemu %base-packages))

Both GTK and GLib are in the (direct) inputs of QEMU.

Even if you removed QEMU, GLib is also in the transitive inputs of Guix
itself, via the dependency path Guix -> Graphviz -> GTS -> GLib.

There's probably room for improvement here, but it's not entirely clear
how to make an optimal decision about when these profile hooks are
needed.

   Mark

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Hi Raghav,

Raghav Gururajan  writes:

> In continuation to my previous email, I tried to fix the error. But the old 
> error is gone and I am getting new ones.
>
> The errors are:
> /etc/rg-secondary.scm:47:24: warning: 'gnome-desktop-service' is deprecated, 
> use 'gnome-desktop-service-type' instead
> /etc/rg-secondary.scm:47:24: warning: 'gnome-desktop-service' is deprecated, 
> use 'gnome-desktop-service-type' instead

You could eliminate this warning by changing:

  (gnome-desktop-service)

to:

  (service gnome-desktop-service-type)

> ice-9/eval.scm:223:20: In procedure proc:
> error: fprintd-service-type: unbound variable
> hint: Did you forget a `use-modules' form?

Ah, my mistake; you also need to import the 'fingerprint' service
module, so change

  (use-service-modules desktop xorg)

to:

  (use-service-modules desktop xorg fingerprint)

  Regards,
Mark

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Earlier, I wrote:

>> 2) Input using stylus pen.
>
> The touch screen is apparently a Wacom device.  From GNOME, you might be
> able to easily set it up from the "Wacom" section of GNOME settings.  I
> don't know about other desktop environments off-hand.

[...]

> To set it up permanently, it *might* be sufficient to add something like
> the following to your OS configuration, merging it with your existing
> 'services' field if needed:
>
> (services (append (list ;; other services go here
> (set-xorg-configuration
>  (xorg-configuration
>   (modules (cons xf86-input-wacom
>  %default-xorg-modules)
>   %desktop-services))
>
> with at least the following imports near the top of the file:
>
>   (use-service-modules desktop xorg)
>   (use-package-modules xdisorg)

On second thought, it seems likely that the "permanent" approach
suggested above is the only way to make this work on Guix.

   Mark

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Hi Raghav,

Raghav Gururajan  writes:
> What and how should I do to enable the following in my Thinkpad X200T (X200 
> Tablet)?

As far as I know, we don't yet have "out of the box" support for the
Thinkpad X200 Tablet.  Since I don't have one myself, I can only give
you some pointers.

> 1) Buttons on the lid like screen rotation, lock screen etc.

Those buttons act like special keys on your keyboard.  The following web
page lists their scancodes, and gives some advice on how to set things
up so that the buttons behave as expected:

  https://www.thinkwiki.org/wiki/Tablet_Hardware_Buttons

The page recommends using xbindkeys, which is provided by the Guix
"xbindkeys" package, but depending on which desktop environment you use,
there might be a more straightforward way to arrange for a script to be
run when you press a key.

For example, in GNOME, if you go into the "Keyboard" section of GNOME
settings, scroll down to the bottom of the list of keyboard shortcuts,
and press the "+" at the bottom, you can arrange for a script to be run
when you press a given key.  It might work for these special keys as
well, although GNOME probably won't know the proper name of the key.

> 2) Input using stylus pen.

The touch screen is apparently a Wacom device.  From GNOME, you might be
able to easily set it up from the "Wacom" section of GNOME settings.  I
don't know about other desktop environments off-hand.

I will note, however, that the "xsetwacom" program, which apparently can
be used to enable the Wacom device within an Xorg session, should be
provided by our "xf86-input-wacom" package.  You might find other useful
information on ,
although note that "permanent configuration" will be much different on a
Guix system than on Arch.

To set it up permanently, it *might* be sufficient to add something like
the following to your OS configuration, merging it with your existing
'services' field if needed:

(services (append (list ;; other services go here
(set-xorg-configuration
 (xorg-configuration
  (modules (cons xf86-input-wacom
 %default-xorg-modules)
  %desktop-services))

with at least the following imports near the top of the file:

  (use-service-modules desktop xorg)
  (use-package-modules xdisorg)

> 3) Fringerprint scanner for authentication.

I've never tried to use a fingerprint scanner, but I see that Guix does
provide a "Fingerprint Service", which "provides a DBus service to read
and identify fingerprints via a fingerprint sensor."  To enable it, add
the following service:

  (service fprintd-service-type)

Please let us know how it goes.  With your help, we may be able to make
this nicer for the next X200 Tablet user.

  Regards,
Mark

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Mark H Weaver]

Giovanni Biscuolo  writes:

> OK, so my problem getting ungoogled-chromium installed is not related to
> the 504 gateway timeout from the web API
>
> unfortunately I'm still having problems installing it since my client
> does not download the substitute but starts building the derivation:
>
> $ guix package -i ungoogled-chromium
> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
> building 
> /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
> \ 'set-paths' phase^C

I don't know about berlin, but hydra.gnu.org has *never* successfully
built ungoogled-chromium.  So far, it has made 3 attempts on
x86_64-linux and 5 attempts on i686-linux:

  https://hydra.gnu.org/build/3387889 (x86_64-linux)
  https://hydra.gnu.org/build/3381436 (x86_64-linux)
  https://hydra.gnu.org/build/3380876 (x86_64-linux)
  https://hydra.gnu.org/build/3386821 (i686-linux)
  https://hydra.gnu.org/build/3385227 (i686-linux)
  https://hydra.gnu.org/build/3381453 (i686-linux)
  https://hydra.gnu.org/build/3380895 (i686-linux)
  https://hydra.gnu.org/build/3379818 (i686-linux)

If the same is true on berlin.guixsd.org, that would explain the lack of
binary substitutes.

Mark

Re: GC hints

[Mark H Weaver]

Chris Marusich  writes:

> Mark H Weaver  writes:
>
>> Hi Ludovic,
>>
>> Ludovic Courtès  writes:
>>
>>> Actually, I was also wondering whether we should provide a configurable
>>> mechanism that would, by default, automatically delete old GC roots and
>>> maybe even run the GC automatically when needed—similar to what Git
>>> does.
>>>
>>> Thoughts?
>>
>> I think it's reasonable to automatically run GC by default, but I would
>> strongly advise against deleting GC roots automatically by default
>> without the user's knowledge and consent.
>
> Just to be clear, I agree with you, Mark.  Guix shouldn't delete GC
> roots automatically by default.  I think we were just saying that it
> might be nice if a user could configure Guix to automatically delete GC
> roots according to some policy (e.g., retain the last 2, and delete any
> others older than 1 month).  Guix would only delete the GC roots
> according to the policy that the user has set, and if no policy has been
> set, the default would be not to delete any of the GC roots.

As long as it's not the default behavior, I think this would be a nice
feature to have.

   Thanks!
 Mark

Re: Unable to Install Rust 1.20.0 and Beyond

[Mark H Weaver]

Hi Brian,

Brian Woodcox  writes:

> I’m not able to install rust.  Initially, I was having problems with
> 1.19.0 because of memory issues.  I fixed that by increasing the
> memory and now 1.19.0 is installed.
>
> Now that I have lots of memory 16GB, and lots of hard disk space, I cannot 
> get 1.20.0 to install.
>
> I am installing it via:
>
> guix package -i rust
>
> It appears to be hung.
>
> guixbui+ 10572 0.0 0.2 127308 38260 ?  Ssl 01:03 0:17 guile
> --no-auto-compile -L
> /gnu/store/27qw1zxljzylvm9b3jbi343gh6cngazq-module-import
> /gnu/store/iw20znxa586mkrv0156paq7z1ya9vcbq-rust-1.20.0-guile-builder
>
> The cpu just sits at 0.0 for this process.  Normally it should be close to 
> 100.

FWIW, I've built rust-1.20.0 locally on my x86_64 GuixSD system several
times without running into this issue.  My system has only 4 GB of RAM
and 8 GB of swap.  On this system, I build everything locally.

Hydra.gnu.org, our older build farm, has not run into this issue while
building rust-1.20.0.  Binary substitutes for rust-1.20.0 are currently
available from hydra.gnu.org, so you should simply be able to download
them.

Are you attempting to perform these builds within a VM?  If so, are you
using QEMU, VirtualBox, or something else?

I'm reminded of another unusual build failure that you encountered in
'guile' when you were first experimenting with Guix, when hydra.gnu.org
was temporarily offline.  The failure was one that I'd not seen reported
before or since.  As I recall, in that case you were attempting the
build within VirtualBox.

With this in mind, I wonder if the virtualization is imperfect in some
way that the rust-1.20.0 test suite is sensitive to.

> My var/log/guix/drvs/av/xcyxs39bdzs28kya500s4kpv0xvb9p-rust-1.20.0.drv.bz2 
> file has the following at the end:
>
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1260)
> ... ignored test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1273) ... ok
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1306) ... ok
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1321) ... ok
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1338) ... ok
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1358) ... ok
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1409) ... ok
> test
> /tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
> - Standard_library_traits_used_for_error_handling (line 1440) ... ok
> test /tmp/guix-build-rust-1.20.0.drv-0/rustc-

FYI, here's the most recent build of rust-1.20.0 on x86_64 on
hydra.gnu.org:

  https://hydra.gnu.org/build/3218738

>From there, you can retrieve the build log.  Here's an excerpt of the
rust-1.20.0 build log from my own local system, including the point
where your build gets stuck:

--8<---cut here---start->8---
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1321) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1338) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1358) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1409) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1440) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1466) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - Standard_library_traits_used_for_error_handling (line 1500) ... ok
test 
/tmp/guix-build-rust-1.20.0.drv-0/rustc-1.20.0-src/src/doc/book/first-edition/src/error-handling.md
 - 

Re: GC hints

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Actually, I was also wondering whether we should provide a configurable
> mechanism that would, by default, automatically delete old GC roots and
> maybe even run the GC automatically when needed—similar to what Git
> does.
>
> Thoughts?

I think it's reasonable to automatically run GC by default, but I would
strongly advise against deleting GC roots automatically by default
without the user's knowledge and consent.

It's certainly true that git performs GC automatically, but does it
automatically delete GC roots by default?  I've never seen it do this,
and I would be surprised and angry if it did.

I consider Guix GC roots to be potentially valuable user data,
regardless of age.  For example, an old GC root might be valuable
because it was used to perform an experiment that should be repeatable,
or because it is known to work reliably for a given job, and newer
versions have not yet been tested.

I, for one, expect my old profiles, system generations, and other GC
roots to be kept unless I explicitly delete them, and I suspect I'm not
alone.  If I hadn't been paying close attention to Guix development, and
later discovered that Guix had deleted my GC roots without my consent, I
would be surprised and angry.

For these reasons, I think we should not automatically delete GC roots
without the user's knowledge and consent.  User consent could be
inferred by a configuration change, or perhaps obtained interactively by
printing a warning and asking the user to give their explicit consent.

What do you think?

Thanks,
  Mark

Re: guix gc, any way to delete only packages that aren't required to build anything?

[Mark H Weaver]

George Clemmer  writes:

> Mark H Weaver  writes:
>
>> On my GuixSD system where substitutes are completely disabled and I
>> build everything locally, I've been running my Guix daemon with both
>> --gc-keep-derivations=yes and --gc-keep-outputs=yes for years.  Here's
>> the relevant excerpt of my OS config:
> ...
>
> Thanks. Very cool to see.  IIUC there is a Guix "bootstrap" component.
> Using this config, where does that come from?

The bootstrap binaries currently consist of statically-linked
executables for 'bash', 'tar', 'xz', and 'mkdir', which are included in
the Guix source tree in the gnu/packages/bootstrap/ directory:

  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootstrap

and also a few additional tarballs of statically-linked binaries
downloaded from:

  https://alpha.gnu.org/gnu/guix/bootstrap/

which includes guile, gcc, binutils, glibc, and a "static-binaries"
tarball with coreutils, tar, gzip, bzip2, xz, patch, sed, grep, and
gawk.

These bootstrap binaries were generated by the code in
gnu/packages/make-bootstrap.scm in the past, and are rarely changed.
They are fetched/imported into the store by code in
gnu/packages/bootstrap.scm.

The current bootstrap binaries for x86_64-linux and i686-linux were
generated in November 2013, although there is ongoing work to replace
these with a reduced set of bootstrap binaries:

  https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20181020/

It is likely that our 'master' branch will be based on these reduced
bootstrap tarballs, or similar ones, within a few months.

  Mark

Re: guix gc, any way to delete only packages that aren't required to build anything?

[Mark H Weaver]

Hi Joshua,

Joshua Branson  writes:

> Mark H Weaver  writes:
>
>> Pierre Neidhardt  writes:
>>
>> On my GuixSD system where substitutes are completely disabled and I
>> build everything locally, I've been running my Guix daemon with both
>> --gc-keep-derivations=yes and --gc-keep-outputs=yes for years.  Here's
>> the relevant excerpt of my OS config:
>>
>
> May I ask why you choose not to use substitutes? 

It's part of a (likely futile) effort to protect the integrity of my
laptops from powerful adversaries, to prevent my private cryptographic
keys from being stolen, and to try to prevent my machine from being used
to insert vulnerabilities into the source code of projects that I
contribute to.  I also keep my laptops with me at all times.

Unfortunately, the US government claims the authority to secretly demand
physical access to servers, and to forbid those coerced from telling
anyone what happened.  See:

  https://en.wikipedia.org/wiki/National_security_letter

I'm not sure about the policies of other governments, but even without
such policies, there are probably windows of time where the physical
security of colocated servers could be breached by bribing employees at
the hosting site.  I doubt there is much restraint in the use of these
methods today, besides a desire to avoid detection.  As a result, any
traditional build farm based on colocated servers is vulnerable to
compromise by powerful adversaries.

There are some additional benefits to building everything locally and
passing using the 'guix-daemon' options above.  It means that my
/gnu/store always contains the complete source code of everything on my
system, including everything needed the bootstrap from the bootstrap
binaries.  It also means that I always have a complete set of build logs
for everything on my system.

  Mark

Re: guix gc, any way to delete only packages that aren't required to build anything?

[Mark H Weaver]

Pierre Neidhardt  writes:

>> Contrary to what Pierre wrote above, I've found that the use of these
>> flags certainly does _not_ lead to an ever-growing store.
>
> According to the discussion I linked above, The reason behind the ever-growing
> store are substitutes.  So if you don't use them, then the store size should 
> be
> stable indeed.

I re-read the thread that you linked to, and I cannot find anything to
suggest that "The reason behind the ever-growing store are substitutes".
Can you cite the specific message that says so?

 Thanks,
   Mark

Re: guix gc, any way to delete only packages that aren't required to build anything?

[Mark H Weaver]

Pierre Neidhardt  writes:

> I've been bugged by this as well (see
> https://lists.gnu.org/archive/html/help-guix/2018-09/msg00028.html).  There 
> are
> a few options beside Ricardo's suggestion:
>
> - You can start the Guix daemon with --gc-keep-outputs (see "(guix) Invoking
>   guix-daemon" in the manual).  This will never delete anything that is still
>   required, but this leads to an ever-growing store.  If you've got limited
>   storage space, you might not want this.

On my GuixSD system where substitutes are completely disabled and I
build everything locally, I've been running my Guix daemon with both
--gc-keep-derivations=yes and --gc-keep-outputs=yes for years.  Here's
the relevant excerpt of my OS config:

  (services (cons* <... my custom services here ...>
   (modify-services (remove (lambda (svc)
  (eq? (service-kind svc)
   wicd-service-type))
%base-services)
 (guix-service-type
  config =>
  (guix-configuration
(inherit config)
(use-substitutes? #f)
(authorized-keys '())
(substitute-urls '())
(extra-options '("--gc-keep-derivations=yes"
 "--gc-keep-outputs=yes")))

This configuration allows me to run "guix gc" without losing the
dependencies that are needed to build the packages that are currently
protected by GC roots, e.g. the packages in my profiles and system
generations.  It's not perfect: I lose a few packages apparently related
to grafts, but it's not too much in practice, and I can manually add
more GC roots to handle those cases.

Contrary to what Pierre wrote above, I've found that the use of these
flags certainly does _not_ lead to an ever-growing store.  On my GNOME 3
GuixSD system, my store requires ~30 gigabytes, and as long as I trim my
older profiles and system generations regularly, the space requirements
are fairly stable over time.

  Regards,
Mark

Re: Ever-growing store with --gc-keep-outputs?

[Mark H Weaver]

swedebugia  writes:

> On 2018-09-14 19:46, Mark H Weaver wrote:
>> Hi Pierre,
>>
>> Pierre Neidhardt  writes:
>>
>>>> If, say, “coreutils” is live, then the corresponding “coreutils.drv”
>>>> will be considered live as well when you pass --gc-keep-derivations.
>>> Is the .drv live forever then?  Even when all the corresponding outputs have
>>> been deleted from all profiles / generations?
>> No, certainly not.  To expand on what Ludovic wrote, by passing
>> --gc-keep-derivations, you are providing an additional way for a .drv to
>> be reachable from your GC roots.  The .drv file will be kept alive for
>> as long as any of its outputs are kept alive.  More generally, it will
>> be kept alive as long as anything that was built upon it is kept alive.
>> That does not imply that .drv files are kept alive forever.
>>
>> I've been using --gc-keep-derivations=yes and --gc-keep-outputs=yes for
>> a long time, and it works well in my preferred mode of operation where I
>> build everything locally and never use substitutes.  It ensures that
>> everything needed to build my GC-root-protected store items will be kept
>> alive.
>
> Interesting setup. Would you be willing to share the amount of space
> consumed by this mode?

My /gnu/store uses approximately 30 GB.

> How many packages do you use?

It's mostly GNOME 3 plus Emacs and IceCat, and a few other applications
that bring in qtbase, wxwidgets, etc.

> Are you willing to share your config also?

My config is somewhat messy, not worthy of emulation at this time, and
mostly not relevant to this thread.

However, for those who want to build everything locally, the relevant
bit is this, which disables substitutes in the daemon:

--8<---cut here---start->8---
(services
 (cons* ...
(modify-services %base-services
  (guix-service-type config =>
 (guix-configuration
   (inherit config)
   (use-substitutes? #f)
   (authorized-keys '())
   (substitute-urls '())
   (extra-options '("--gc-keep-derivations=yes"
"--gc-keep-outputs=yes")))
--8<---cut here---end--->8---

I also deleted /etc/guix/acl on my system.

>> When I want to free up some disk space, I do the following steps:
>>
>> (1) update my user profiles and delete old generations
>> (2) delete older generations in /var/guix/profiles (but always
>>  keeping the one referenced by /run/booted-system!)
>> (3) reconfigure the system to remove the old system profiles from
>>  grub.cfg
>> (4) guix gc
> This would be nice to have in the manual I think.

Would you like to propose a patch?

 Mark

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***

[Mark H Weaver]

Hi Brian,

Earlier, I wrote:
> (1) You could wait until hydra.gnu.org comes back online, which I expect
> to happen sometime next week.  Hydra has a full set of substitutes for
> 0.15.0, so you shouldn't need to build Guile at that point.

hydra.gnu.org is now back up, so this would be a good time to try again.

 Mark

Re: Where is the best place to download texlive-20170524-extra.tar.xz ?

[Mark H Weaver]

Hi Brian,

When looking for a file that Guix is trying to download but which is no
longer available at the expected URL, I normally just do a web search
for the file name, in this case "texlive-20170524-extra.tar.xz".  Any
site will do.  It needn't be a site you trust, because Guix always
checks the sha256 hash anyway.

If you "guix download" a file with the right name but the wrong
contents, it will be successfully added to the store, but with the wrong
hash string in the file name in /gnu/store, so nothing will ever use it.
When you attempt to restart the build that failed, it will again try to
download it, because the file it needs is not in the store.  The bogus
file will be deleted the next time to run "guix gc".

I did a web search for this file name, and found this:

ftp://tug.org/texlive/historic/2017/texlive-20170524-extra.tar.xz

  Mark

Re: guixsd 0.15.0 install failure

[Mark H Weaver]

Brian Woodcox  writes:

> I posted before I saw Leo’s reply at any rate his method is probably better.
>
> In my case, from the /gnu/store directory, I entered:
>
> nano ./59pqd1d0ihqxx0i64yxk335vjmw78wmh-bzip2-1.0.6.tar.gz.drv
>
> and at the end of the line, I changed url from 
> http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz to
> https://github.com/past-due/bzip2-mirror/releases/download/v1.0.6/bzip2-1.0.6.tar.gz

It's important to never edit files in /gnu/store.  Everything in that
directory is assumed to be immutable, and if that assumption is
violated, Guix may later misbehave in non-obvious ways.

Please use Leo's method instead.

  Thanks,
Mark

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***

[Mark H Weaver]

Brian Woodcox  writes:
> Just to avoid me having to search, what command would I use to get the
> tail of the build log file.

If you know the file name in /gnu/store of one of the build's outputs,
you can pass that file name, e.g.:

  guix build --log-file /gnu/store/1mr5izrbxwd7cbq8m1xrqm45rzkibpsj-guile-2.2.3

If you know the file name of the derivation (/gnu/store/….drv) of the
build you're looking for, then you can use "guix build --log-file
/gnu/store/….drv".

If you built the package locally, another useful trick is to look for
the newest files in /var/log/guix/drvs/*/*, which you can list by
running "ls -ltr */* | tail" or "ls -ltr */*-guile-* | tail" from
/var/log/guix/drvs.

In some cases, it is sufficient to pass the package name with optional
version, e.g. "guix build --log-file guile@2.2.3", but not always.
Roughly, that command finds the log for the derivation that would have
been built right now if you ran the same command without "--log-file".
Note that this won't be the build you're looking for if you've run "guix
pull" since the relevant build was fresh, if either the package or one
of its transitive dependencies have changed.  Passing a simple package
name also won't work if the derivation you're looking for is a special
variant package which is hidden or not bound to a public variable.

For example, 'guile-final' in gnu/packages/commencement.scm is one such
variant.  It is one of the products of the early bootstrap, and the
Guile variant used to build most of the other packages in Guix.  This is
not the same guile that you get by running "guix build guile".

'guile-final' is a "hidden" package, but it can be specified using the
more general "--expression=" syntax:

  guix build --log-file --expression="(@@ (gnu packages commencement) \
  guile-final)"

Also note that there is a very simple mapping between build log file
names and derivation file names, perhaps best shown by example:

__/var/log/guix/drvs/wc/47q5cw4b23gy9hzzhxp09b804nippx-guile-2.2.3.drv.bz2
___/gnu/store/wc47q5cw4b23gy9hzzhxp09b804nippx-guile-2.2.3.drv

   Mark

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***

[Mark H Weaver]

George Clemmer  writes:

> Brian Woodcox  writes:
>
>> I think I’ve had it sitting like that for hours.
>>
>> The reason I think it’s hung in VirtualBox is the fact that within
>> about 45 seconds there is no longer any activity on the hard disk
>> icon.
>>
>> I am currently installing in Qemu and will see how that goes.
>
> Dunno about VirtualBox. But I just did 'guix pull' on a fresh 'guix
> system vm-image' running on GuixSD in QEMU. It looks the same: 4 CPUs
> howling and the hard drive doing hardly anything.  But I see this in
> /tmp
>
> g1@sysi53 ~$ ls /tmp
> guix-build-guile-2.2.3.drv-0/
>
> ... and BOOTSTRP GUILEC steps are trickling out. So even thought it
> feels like it, it's not hung.

That's during the 'build' phase.  The problem Brian is seeing is during
the 'check' phase, at a place where there is not normally any
significant delay.

I already told you this in my last message, but I guess it wasn't clear.

   Mark

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***

[Mark H Weaver]

Hi Brian,

Brian Woodcox  writes:

> This is what is displaced on the screen when the hang occurs:
>
> …
> make  check-TESTS
> make[3]: Entering directory ‘/tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3’
> Testing /tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3/meta/guile …
> with GUILE_LOAD_PATH=/tmp/guix-guild-guile-2.2.3.drv-0/guile-2.2.3/test-suite

Thanks.  These last messages were printed by the 'check-guile' script,
just before it passes control to test-suite/guile-test, which runs the
tests in test-suite/tests/*.test.  I guess it's getting stuck during the
initialization of 'guile-test', because it prints a message before
running each test.

At this point, I see a few possible next steps, from easy to harder:

(1) You could wait until hydra.gnu.org comes back online, which I expect
to happen sometime next week.  Hydra has a full set of substitutes for
0.15.0, so you shouldn't need to build Guile at that point.

(2) You could try QEMU instead.  I suspect that Guix has seen far more
testing under QEMU than VirtualBox, because QEMU is in Guix and not
VirtualBox.  If it fails in QEMU, then we will have a test case that
Guix developers can try to reproduce on their own systems.

(3) If you felt like getting your hands dirty and digging deeper to
investigate this problem and find its source, read on:

You could try the same build with "--keep-failed" added to the Guix
command line, and interrupt it after it gets stuck.  At that point, you
should have write access to /tmp/guix-guild-guile-2.2.3.drv-0, and you
can enter that directory and try various experiments.

/tmp/guix-guild-guile-2.2.3.drv-0/environment-variables will contain the
environment variable settings that were passed to the top-level build
commands, including "make check".  In that directory, run:

  env -i `which bash`

or a similar command to clear the environment, and then "source
environment-variables" to load the environment settings.  Then 'cd' into
the guile source directory and run ./check-guile.

Hopefully it will get stuck here as well.  If so, you could use GDB to
attach to the stuck guile process and obtain a backtrace.  It might also
be useful to see the output of "strace -f ./check-guile".

There are many other things that could be tried at this point, such as
removing the "--debug" flag passed to guile at the end of 'check-guile',
inserting debugging print statements at various points in the
'guile-test' script, etc.

Hopefully one of these options is workable.  Sorry for the bother.

 Regards,
   Mark

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***

[Mark H Weaver]

George Clemmer  writes:
> Brian, I believe that what you are experiencing as a "hang" is actually
> the incredibly long time that it takes for guile to bootstrap itself.

That's not what's happening here, because this hang is happening during
"make check".  Thanks anyway :)

   Mark

Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***

[Mark H Weaver]

Brian Woodcox  writes:

> So I have been trying to install GuixSD 0.15.0 for a few days now.
>
> My first problem was not setting
> —substitutes-urls=“https://berlin.guixsd.org.  So that fixed one
> problem.
>
> My other problem is try as I might, I cannot get either guile-2.2.3 or
> guile-2.2.4 to install.
>
> It always hangs when trying to do the tests after writing all the *.go
> files, (which by the way takes a long time).

What are the last messages visible at the point where it gets stuck?
It would be helpful to see the tail of the build log.

Since I've not seen other reports of this problem, my first guess is
that the problem is specific to builds done within VirtualBox, for some
reason.  It would be useful to know which test is getting stuck.  Since
VirtualBox requires a non-free compiler for part of its build, I don't
use it myself.  I use QEMU instead.

Also, normally you would not need to build Guile, but would simply
download a binary substitute for Guile.  However, our primary build farm
is currently offline due to a recent disk failure, and our newer build
farm (berlin.guixsd.org) unfortunately does not have a complete set of
substitutes for 0.15.0, but only for the most popular or most recently
built ones.

So, this is a temporary issue while we wait for the FSF sysadmins to
finish migrating hydra.gnu.org to a new disk array, which will probably
be another few days.  I'm sorry for the inconvenience.

> So are there any work arounds to disable the tests for guile-2.2.x so
> I can get this operating system operational?

In theory it could be done, but disabling tests would be a change to the
Guile package, and therefore a change to the derivations of all packages
built on top of Guile, which in Guix is *everything* because Guile is
used to execute our build recipes.

As a result, if you did this, you would not be able to find *any* binary
substitutes from our official servers, because you'd be asking for
different derivations than the ones built by our build farm.

Re: Frequent git repository corruptions

[Mark H Weaver]

Tobias Geerinckx-Rice  writes:

> Mark H. Weaver wrote:
>> Tobias Geerinckx-Rice  writes:
>>> Only the old, unmaintained (and notably non-UEFI) version 4 is
>>> GPL2. Newer versions are mystery meat.[1]
>>
>> Oh, that's unfortunate :-(
>
> Indeed: I think I've packaged memtest86+, but have no machine upon
> which to run my brand-new package. That does not inspire confidence.

If you send me a patch to add 'memtest86+', I'd be glad to test it on my
Thinkpad X200.

> I'll give memtester a try. Thanks!

Thank you, Tobias!

 Mark

Re: Frequent git repository corruptions

[Mark H Weaver]

Tobias Geerinckx-Rice  writes:

> Tobias Geerinckx-Rice wrote:
>> Pierre Neidhardt wrote:
>>> Yup, that's what I've found out as well.
>>>
>>> There is an AUR package for memtest86 (no +) on EFI:
>>>
>>> https://aur.archlinux.org/packages/memtest86-efi/
>
> I stand by my initial pronouncement:
>
>> Say no more :-) That is proprietary software.
>
> Only the old, unmaintained (and notably non-UEFI) version 4 is
> GPL2. Newer versions are mystery meat.[1]

Oh, that's unfortunate :-(

Does anyone know of free software that can test all of the RAM in a
machine and that runs on systems with UEFI?

Failing that, there's 'memtester' which runs as a normal program under
Linux (the kernel).  This method is unable to test RAM that's allocated
to the kernel or to other processes, but if you stop as many services as
possible and run it from a text terminal, it should be able to test most
of the RAM.

We don't yet have 'memtester' in Guix, but it looks like it should be
easy to package.

  Mark

Re: Frequent git repository corruptions

[Mark H Weaver]

Pierre Neidhardt  writes:

> This might be unrelated to Guix but since I'm in the dark here, I
> figured I'd rather ask, maybe someone ran into a similar issue.
>
> For the past 2-4 weeks I've had at least 4 Git repositories that got
> corrupted for no apparent reason.  Even a checkout that I had never
> touched.

I would test the machine's RAM, preferably with a tool like memtest86
that runs directly from GRUB.  Alas, we do not yet have a package for it
in Guix.

   Mark

Re: damaged installation

[Mark H Weaver]

carl hansen  writes:

> I installed guix 0.15 on Debian testing system
> Power went out while 'guix pull'ing or something.
> Now, show stopper error. Attached. How to proceed?

I would move .config/guix to another location (or simply delete it),
optionally run "guix gc --verify=contents", and then rerun "guix pull".

  Mark

Re: Other web-browser for tor

[Mark H Weaver]

znavko  writes:

> Hello! I am using GNU IceCat, that has Network Settings for using
> proxy. I can use tor with it. I was using Abrowaser on trisquel, but
> GuixSD repository has no such:
>
> $ guix package -s abrowser
> $
>
> I've found other browsers with `guix package -s 'web browser'` but all
> of that I've installed has no Network configurations . Epiphany,
> Dillo, Conkeror can't.  Netsurf browser has network settings, but
> there is only http proxy, and I get this when type proxy:
> 127.0.0.1:9050 : "This is a SOCKs proxy, not an HTTP proxy."
>
> Which other free software browser can work on socks4 proxy? On
> trisquel I had Abrowser, but here it is only Icecat.

Epiphany can be configured to use a SOCKs proxy via the "Network"
section of GNOME settings.

Conkeror can be configured to use a SOCKs proxy.  See
.

For software that does not support SOCKs proxies, you can use 'privoxy'
as a gateway.  'privoxy' presents itself as an HTTP/HTTPS proxy, and it
can be configured to use a SOCKs proxy.  See
.

Dillo can be configured to use an HTTP/HTTPS proxy in its
~/.dillo/dillorc.

Wget and some other command-line utilities will honor the http_proxy and
https_proxy environment variables.  Alternatively, you can configure
wget to use a proxy via ~/.wgetrc.

I do not know off-hand whether these programs leak information in
practice (e.g. by making untorified DNS requests) when configured in
this way.

  Mark

Re: Ever-growing store with --gc-keep-outputs?

[Mark H Weaver]

Pierre Neidhardt  writes:

>> it works well in my preferred mode of operation where I
>> build everything locally and never use substitutes.
>
> Do substitutes change the way GC behaves?  I use substitutes.

No.  However, if you build everything locally, it becomes more important
to avoid deleting store items that will be needed to build your next
system update, and so the --gc-keep-* flags become important.

>> (1) update my user profiles and delete old generations
>> (2) delete older generations in /var/guix/profiles (but always
>> keeping the one referenced by /run/booted-system!)
>
> You mean system generations?  I did that.

Right.

>> (3) reconfigure the system to remove the old system profiles from
>> grub.cfg
>> (4) guix gc
>
> I did all this.  Then ghc-pandoc and all the ghc dependencies did not go.

What is the output of "guix gc --referrers /gnu/store/x.drv" when
applied to the .drv file for ghc-pandoc?

  Mark

Re: installing guixsd on an arm device

[Mark H Weaver]

Hi Julien,

Julien Lepiller  writes:

> I'm trying to install GuixSD on a cubietruck. For that, I installed a
> foreign distro, installed guix using the binary method, pulled to the
> latest version and I eventually ran "guix system init /etc/config.scm 
> /".
>
> After that, I rebooted and I can use the HDMI cable to see what's
> happening. The uboot screen appears and boots my kernel alright. The
> issue I have is that, a few seconds after the kernel is booted, it
> freezes. I tried to use a usb keyboard, but it wasn't recognised (it
> didn't light up and nothing appeared on the screen). Here is a photo of
> what is on the screen when it is frozen:
>
> http://rennes.lepiller.eu/cubietruck.jpg [732 KB]
>
> and here is the config file I tried to use:
>
> http://rennes.lepiller.eu/cubietruck.scm
>
> I don't see any error message. I've tried letting the server powered on
> for a few hours, and nothing happened.

It might be worth trying an older kernel, specifically linux-libre-4.14,
by adding (kernel linux-libre-4.14) to the OS config and making sure to
import (gnu packages linux).  I just recently updated the kernel to
4.18.x, but I don't know if anyone has tried it on ARM yet.

  Mark

Re: Guix on aarch64

[Mark H Weaver]

Hi Benjamin,

Benjamin Slade  writes:

> Though, unfortunately, when I try `guix package -i hello` (or any other
> package), I get the following error:
>
> 
> 
> /gnu/store/qzdabl7b02cp4xsfkz4znxpy482gsgh8-bootstrap-binaries-0/bin/tar: 
> /gnu/store/4ka60wq7j51ywy7pmpwy7fqqnzk12ay6-binutils-2.30.tar.xz: Wrote only 
> 4096 of 10240 bytes
> /gnu/store/qzdabl7b02cp4xsfkz4znxpy482gsgh8-bootstrap-binaries-0/bin/tar: 
> Child died with signal 9
> /gnu/store/qzdabl7b02cp4xsfkz4znxpy482gsgh8-bootstrap-binaries-0/bin/tar: 
> Error is not recoverable: exiting now
[...]
> ./guix/build/utils.scm:616:6: In procedure invoke:
> ./guix/build/utils.scm:616:6: Throw to key `srfi-34' with args `(#  [program: 
> "/gnu/store/qzdabl7b02cp4xsfkz4znxpy482gsgh8-bootstrap-binaries-0/bin/tar" 
> arguments: ("cvf" 
> "/gnu/store/4ka60wq7j51ywy7pmpwy7fqqnzk12ay6-binutils-2.30.tar.xz" 
> "--use-compress-program=/gnu/store/qzdabl7b02cp4xsfkz4znxpy482gsgh8-bootstrap-binaries-0/bin/xz
>  --threads=0" "--mtime=@0" "--owner=root:0" "--group=root:0" "--sort=name" 
> "binutils-2.30") exit-status: 2 term-signal: #f stop-signal: #f] d7ff00>)'.
> builder for 
> `/gnu/store/8bkfchbibkfflp72vvdf39hdbv362vm7-binutils-2.30.tar.xz.drv' failed 
> with exit code 1

I looked in the GNU tar source code to see what could produce that
message during archive creation.  The message would seem to indicate
that an error occurred during a kernel-level 'write' call to the archive
file.  The code is written to retry in case of short writes or EINTR.

What kind of filesystems are running on /tmp and /gnu?  How much free
space is on those filesystems?

   Mark

Re: racket patch not found

[Mark H Weaver]

Hi,

Marco van Hulten  writes:

> When I install the package `racket' through
>
> guix pull &&\
> guix package -i racket
>
> I get this error:
>
> guix package: error: racket-fix-xform-issue.patch: patch not found

This was fixed in commit 57ac5261fec345b16cf80f87aa03212abc2c5a11,
pushed a few days ago.

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=57ac5261fec345b16cf80f87aa03212abc2c5a11

If you "guix pull" and try again, hopefully it will work now.

  Mark

Re: root certificate

[Mark H Weaver]

Hi Chris,

Chris Marusich  writes:

> Mark H Weaver  writes:
>
>>;; Create hash symlinks suitable for OpenSSL ('SSL_CERT_DIR' and
>>;; similar.)
>>(chdir (string-append %output "/etc/ssl/certs"))
>>(invoke (string-append perl "/bin/perl")
>>(string-append openssl "/bin/c_rehash")
>>".")
>
> I didn't know about c_rehash until now.  Interesting!  In the past, I've
> defined my own certificate packages as described in my own separate
> replies to this thread, and they worked even though I didn't invoke
> c_rehash.  Could this simply have been because the software I use
> happens to work even when the symlinks created by c_rehash don't exist?

According to the c_rehash man page, "many programs that use OpenSSL
require directories to be set up like this in order to find
certificates."  I'm not sure, but I guess that programs based on GnuTLS
do not need the symlinks.

> It looks like the ca-certificate-bundle profile hook (defined in
> guix/profiles.scm) doesn't currently invoke c_rehash.  Should it?

If I understand correctly, as long as each certificate package runs
'c_rehash' individually, then running 'c_rehash' during the profile hook
should have no effect, because all of the certificates will already have
their associated hash symlinks installed.

 Regards,
   Mark

Re: root certificate

[Mark H Weaver]

Mark H Weaver  writes:

> Something like this (untested):
>
> (define-public my-root-cert
>   (package
> (name "my-root-cert")
> (version "0")
> (source #f)
> (build-system trivial-build-system)
> (arguments
>  '(#:modules ((guix build utils))
>#:builder
>(begin
>  (use-modules (guix build utils))
>  (let ((root (assoc-ref %build-inputs "my-root-cert.pem"))

Sorry, that 'root' in the line above should be 'cert'.

  Mark

Re: root certificate

[Mark H Weaver]

Hi Divan,

Divan Santana  writes:

> How does one import a root certificate for GuixSD?
>
> I didn't see it in the manual.

You didn't see it because we don't yet have a polished way to do this,
unfortunately.  The good news is that we've already laid the groundwork
for supporting local certificate stores.

Our 'le-certs' package in gnu/packages/certs.scm is a good template for
making custom certificate packages, and can be easily adapted to your
needs.

For now, you could simply make a copy of the 'le-certs' package, but
with a different package name and different certificate inputs.

Something like this (untested):

--8<---cut here---start->8---
(define-public my-root-cert
  (package
(name "my-root-cert")
(version "0")
(source #f)
(build-system trivial-build-system)
(arguments
 '(#:modules ((guix build utils))
   #:builder
   (begin
 (use-modules (guix build utils))
 (let ((root (assoc-ref %build-inputs "my-root-cert.pem"))
   (out (string-append (assoc-ref %outputs "out") "/etc/ssl/certs"))
   (openssl (assoc-ref %build-inputs "openssl"))
   (perl (assoc-ref %build-inputs "perl")))
   (mkdir-p out)
   (copy-file cert (string-append out "/" (strip-store-file-name cert)))

   ;; Create hash symlinks suitable for OpenSSL ('SSL_CERT_DIR' and
   ;; similar.)
   (chdir (string-append %output "/etc/ssl/certs"))
   (invoke (string-append perl "/bin/perl")
   (string-append openssl "/bin/c_rehash")
   ".")
(native-inputs
 `(("openssl" ,openssl)
   ("perl" ,perl)))   ;for 'c_rehash'
(inputs
 `(("my-root-cert.pem"
,(origin
   (method url-fetch)
   (uri "https://example.com/certs/my-root-cert.pem;)
   (sha256
(base32
 ""))
(home-page "https://example.com/certs/my-root-cert.pem;)
(synopsis "My self-signed root certificate")
(description "This package provides my self-signed root certificate.")
(license license:public-domain)))
--8<---cut here---end--->8---

and then you would need to add this package to the 'packages' field of
your OS configuration, and reconfigure your system.

However, it would be good to provide a way to more easily create custom
certificate packages from a set of .pem files, perhaps by changing the
above package definition into a procedure that accepts a list of root
certificates and dynamically creates a certificate package.  If you'd
like to work on this, I'd be glad to discuss it further.

Regards,
  Mark

Re: Guix "days old" variable

[Mark H Weaver]

Jone  writes:

> Hello. I check updates:
>
> guix refresh emacs
>   gnu/packages/emacs.scm:116:13: emacs would be upgraded from 25.3 to 26.1
>
> and would like to install only this one update:
>
> guix package -u emacs
>   guix package: warning: Your Guix installation is 16 days old
>   ...
>
> Can I change threshold for this ("NN days old")? What is this variable?

You can set the GUIX_DISTRO_AGE_WARNING environment variable to a string
like "9d" for 9 days.  The suffix can also be "w" or "m" for weeks or
months.

   Mark

Re: bug#31268: 'guix system vm-image' hangs

[Mark H Weaver]

George myglc2 Clemmer <myg...@gmail.com> writes:

> On 04/26/2018 at 03:37 Eric Bavier writes:
>
>> Hi George,
>>
>> I've seen the same lately with 'guix system vm':
>>
>> On Wed, 25 Apr 2018 21:39:30 -0400
>> George myglc2 Clemmer <myg...@gmail.com> wrote:
>>
>>> 'guix system vm-image' hangs on guix (GNU Guix) 0.14.0.4439-eb88e built
>>> from source today. Please see log except below. It worked on guix (GNU
>>> Guix) 0.14.0.4196-2c92a. built <2018-04-18 Wed>

[...]

>> I bisected the git repo to commit:
>>
>> ```
>> commit ba39d3280759fb20a4ff0092a5afac721a5fa769
>> Author: Mark H Weaver <m...@netris.org>
>> Date:   Tue Apr 24 16:51:45 2018 -0400
>>
>> gnu: linux-libre: Update to 4.16.4.
>>
>> * gnu/packages/linux.scm (%linux-libre-version): Update to 4.16.4.
>> (%linux-libre-hash): Update hash.

FYI, I just pushed commit 8c21c64e59d3f4d223d8aeef91f06fdde7de1ab7 which
updates linux-libre to 4.16.6.  Would you like to see if the problem
still persists?

   Mark

Re: Multilib support: running 32-bit binaries on 64-bit systems

[Mark H Weaver]

Hi Pierre,

Pierre Neidhardt  writes:

> Guix already supports cross-compilation out of the box of 32-bit
> packages on any architecture:
>
>   guix build --system=i686-linux PACKAGES...
>
> Now the question is: is it possible to run the produced binaries
> directly (no VM)?

Yes.

> Many other distributions have support for the so-called "multilibs",
> that is, a separate 32-bit library tree with the 32-bit linker
> configured to load those instead of their 64-bit counterparts.
>
> Does Guix have any provision for multilibs?

Yes, in fact Guix's support for multilibs is far more general.  Guix
supports not only 32-bit and 64-bit libraries on the same system, but an
arbitrary number of variants of C libraries.

For example, right now my x86_64 GuixSD system has one set of
libraries/executables based on glibc-2.26.105-g0890d5379c (from our
'master' branch), and one set of libraries/executables based on
glibc-2.27 (from our 'core-updates' branch), and I can use all of these
binaries freely on the same system without any conflicts or wrappers.

This works because instead of having a small ad-hoc set of global
locations where a few variants of the C library, dynamic linker, etc,
are stored (e.g. /lib, /lib64, etc), in Guix all of these components are
stored in /gnu/store, each with a unique hash.  Every executable and
every library in Guix has embedded within the absolute file name of all
of the components it depends on, including its dynamic linker, C
library, C runtime, bourne shell, etc.

Does that make sense?

   Mark

Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'

[Mark H Weaver]

Joshua Branson  writes:

> I guess I'm still a little confused. Suppose that I want to update all
> packages, on my system.  The ones owned by root, and the ones owned by
> all other users.  Then I'd do this?
>
> $ guix pull && guix package -u
>
> $ logout
>
> $ login DifferentUser
>
> $ guix pull && guix package -u
>
>  ...repeat for all other users...
>
> $ su
>
> # guix pull && guix package -u && guix system reconfigure /etc/config.scm
>
> Does that look right?

Yes, exactly.

I should also mention that if you'd like to avoid some or all of these
'guix pull's, you can arrange for user B to always track user A's copy
of Guix like this:

  ln -sf {~A,~B}/.config/guix/latest

However, manually fiddling with these symlinks is not officially
supported and might stop working in a future version of Guix.  Also,
beware that if you accidentally run "guix pull" as user B, it will
overwrite the symlink, and henceforth user B will no longer track user A
until you re-run the above command.

Alternatively, if you don't want user B to _track_ user A, but you just
ran "guix pull" as user A and now you want to quickly update user B to
the same copy of Guix, you can do this:

  cp -a {~A,~B}/.config/guix/latest

  Mark

Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'

[Mark H Weaver]

Hi Joshua,

Joshua Branson  writes:
> Maybe I'm being really silly, but don't you just do a guix pull as a
> root user not as a normal user?

No.  Guix is not like most distros where you have to be root to update
the package list, and where root's package list is used by all other
users.

In the Guix model, each user has their own version of Guix and its
package list.  When a user runs "guix pull", it only updates Guix for
that particular user, by changing the symlink ~/.config/guix/latest.

If root runs "guix pull", it only updates the package list for root, by
changing the symlink ~root/.config/guix/latest.

Regards,
  Mark

Re: Missing platform_device.h in linux-libre-headers

[Mark H Weaver]

Hi,

Eleven  writes:
> I’m trying to compile some extra kernel module for my guixsd, however
> the headers files needed, `modules.h` and `platform_device.h` was not
> found. After redefining the linux-libra-headers package, update the
> version to 4.15.13 which is the version of the kernel I’m currently
> running, I get `modules.h` but `platform_device.h` still
> missing. What’s the problem and how can I fix it?

platform_device.h is not part of the user API, so it's not installed by
the "headers_install" make target in linux-libre.

I would recommend against changing the 'linux-libre-headers' package
itself.  The contents of 'linux-libre-headers' is included in our
default C headers used to build the entire system.  Updating it entails
a full system rebuild from the toolchain up.  Even if not for this
practical problem, I would argue that private kernel driver interfaces
do not belong in our default C headers.

The headers needed to build kernel modules should be a separate package,
maybe called 'linux-libre-kernel-headers' or
'linux-libre-internal-headers'.  It could be almost the same as
'linux-libre-headers', except that it should use the current kernel
version (using the %linux-libre-version and %linux-libre-hash variables)
and it should use different make targets in the 'build' and 'install'
phases, namely "headers_check_all" and "headers_install_all".

  Mark

Re: Application Setup on Trisquel

[Mark H Weaver]

"Caleb Herbert"  writes:
>   * Trisquel does not have xset

On Debian-derived systems, 'xset' is part of the
'x11-xserver-utils' package.  I found this by visiting:

  https://packages.debian.org/file:xset

or see the "Search the contents of packages" section of
https://packages.debian.org/

 Mark

Re: starting a window manager with xinitrc

[Mark H Weaver]

Hi,

Andrew Erlanger  writes:

> Hello, Guix users. I've managed to get GuixSD running and am enjoying it
> so far. To begin learning about the system, though, I am trying to set
> up a minimal environment, and am having some trouble figuring things out.
>
> Specifically, I use the Emacs X Window Manager (found at
> https://github.com/ch11ng/exwm), usually called exwm. What I can't
> figure out is how to ``properly'' get exwm to be my primary window
> manager, and to start from the login manager. Usually setting up exwm is
> as simple as installing it from elpa, and then copying/linking the
> provided xinitrc to the user's home directory. But I can't figure out
> the equivalent method for GuixSD. Can someone point me in the right
> direction? Thank you.

If you create ~/.xsession, making sure that it has a proper shebang and
is executable, it will be run when you log into X, ignoring whatever
window manager selection was made within SLiM.  The last thing
~/.xsession should do is to run your window manager in the foreground.

   Mark

Re: Manual pages for glibc.

[Mark H Weaver]

Hi Ricardo,

Ricardo Wurmus  writes:

>> Which package do I need to install to be able to read the man pages of
>> functions in glibc like 'snprintf' and 'malloc'?
>>
>> I installed glibc, but that does not seem to provide the man pages.
>
> Here’s what I did:
>
> unionfs $(printf "%s:" /gnu/store/*/share/info) ~/tmp/info
>
> This gives me a union of all the beautiful info manuals in the store.
> To read the GNU libc’s info manual I do this in Emacs:
>
>C-u C-h i ~/tmp/info/libc.info.gz RET

This awkward solution should not be needed.  I simply installed
'gcc-toolchain' in my user profile and access the info manuals in Emacs
using C-h i.  Does that not work for you?

 Mark

Re: Enable modules in Linux configuration.

[Mark H Weaver]

Hi again,

Dmitry Nikolaev  writes:

> How do I enable Reiser4 module in Linux configuration? As far as I
> know I need to add "REISER4_FS=m" to .config after running "make
> defconfig", but before "make".

Sorry, I realize that I didn't answer this question in my last message.
It might be sufficient to merely add "REISER4_FS=m" to

  gnu/packages/aux-files/linux-libre/-.conf

in the Guix source tree.  However, if there are other configuration
options that need to be changed to accommodate Reiser4, then this might
not be enough.

The more general method is to unpack a copy of the linux-libre source
tree, copy the appropriate config file from the Guix source tree to
.config in the top-level linux-libre source, run "make oldconfig" (or
whichever *config target you prefer) to update the config, and then copy
the updated .config file back to the Guix source tree.

A good way to unpack the source is to run "guix build -S linux-libre"
(or your own variant package), and then "tar xf" on the returned file
name.

A good way to make sure you have the necessary software in your
environment to run "make oldconfig" is to run "guix environment
linux-libre" and then work within the spawned shell.

  Mark

Re: Enable modules in Linux configuration.

[Mark H Weaver]

Hi,

Dmitry Nikolaev  writes:

> I'm trying to set up GuixSD on Reiser4 file system. I've succeeded
> with patching and compiling Linux with Reiser4 patch, but I've found
> that reiser4 module is disabled by default. Everything I did was
> pointless 8-]
>
> How do I enable Reiser4 module in Linux configuration? As far as I
> know I need to add "REISER4_FS=m" to .config after running "make
> defconfig", but before "make".

You would also need to add Reiser4-related code to (gnu system
linux-initrd) and (gnu build file-systems).  Search for "btrfs" in our
source tree to get an idea of what code needs to be added.

> One more question for GuixSD maintainers: will you add
> linux-libre-reiser4, libaal and reiser4progs packages to main package
> repository if I'll send you patches?

As long as the licenses comply with the GNU FSDG, I see no obstacle to
merging 'libaal' and 'reiser4progs' to the main repository.

However, 'linux-libre-reiser4' makes me a bit nervous.  As the de-facto
maintainer of our linux-libre packages, my main concern is the
additional maintenance burden going forward.  Every time a new major
version of 'linux-libre' is released, the job of updating and testing
the reiser4 patch would fall on my shoulders.

However, I can tell you from personal experience that it is quite easy
to run GuixSD from your own private git branch, and to periodically
rebase your local changes on our upstream master branch (or, if you
prefer, to merge upstream master into your local branch).  I've been
doing this for a long time.  My method is to have a git checkout in my
home directory that is always kept in good working order, and then to
put the following script in ~/bin/guix and ~root/bin/guix:

  #!/bin/sh
  exec /home/mhw/guix/pre-inst-env guix "$@"

I also add "PATH=/home/mhw/bin:$PATH" to my .bash_profile, and the
analogous thing for root.  Let me know if you need help setting this up.

 Regards,
   Mark

Re: Implement power management (suspend, hibernate, resume) in Shepherd?

[Mark H Weaver]

Mekeor Melire  writes:

> As far as I understand, currently GuixSD uses elogind (“systemd
> project's ‘logind’, extracted to a standalone package”) to suspend,
> hibernate and resume when some events happen, like pressing the
> suspend-key etc.
>
> Is there any nice way to suspend GuixSD by command? (I didn't yet try
> out ‘echo mem > /sys/power/state’.)

"loginctl suspend" will do it, optionally with "-i" added to ignore
inhibitors.  See "loginctl --help" for more.

  Mark

Re: youtube in Web

[Mark H Weaver]

Ricardo Wurmus  writes:

> Catonano  writes:
>
>> Youtube doesn't work anymore in Web
>>
>> It works like a charm in Icecat though
>
> You need to install some gstreamer plugins, such as the following:
>
> "gst-plugins-base"
> "gst-plugins-good"
> "gst-plugins-ugly"
> "gst-libav"

gst-plugins-ugly should not be needed, and is better left out IMO, since
it's more likely to contain codecs with security flaws.

  Mark

Re: tree doesn't get called

[Mark H Weaver]

Catonano  writes:
> So here's the package
> http://paste.lisp.org/display/345871
>
> What is wrong with it ?

Please always include the relevant code snippets in the email itself,
rather than using a paste site.  Paste sites are useful for contexts
such as IRC where pasting more than a few lines is inconvenient and
generally frowned upon, and where the discussions are ephemeral.

On the other hand, these email lists are archived and we would like the
archives to be comprehensible to future readers.  That will not be
possible for the emails in this thread after the code under discussion
has been deleted from the paste site, or the paste site goes offline.

There are also privacy implications to forcing the readers of your email
to click on a link, thus creating network traffic and a log on someone's
server, in order to see the core content of your message.

What do you think?

Regards,
  Mark

Re: Not booting

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Kete Foy  skribis:
>
>> Kete Foy:
>>> 
>>> I need to do this:
>>> https://libreboot.org/docs/gnulinux/grub_cbfs.html#option1_dont_reflash
>>> 
>> This worked for me by just copying grub.cfg to libreboot_grub.cfg. (in
>> /boot/grub after mounting /dev/sda1 using installation drive)
>
> That rings a bell.  I think Mark (Cc’d) had a patch so that ‘guix
> system’ would do that automatically on LibreBoot systems.  Mark?

I never produced a patch, I just created the symlink manually on my
Libreboot systems during the initial install.  However, looking at the
current libreboot git sources, it seems that this is no longer needed.
If grub.cfg is found, it should auto-load that in the default entry.

If I'm mistaken, please let me know :)

  Mark

Re: Guix unmounted my /home, while -i hello

[Mark H Weaver]

Louis  writes:

> Yes, I have tried it again, and it happened again, on the
> second time I have sent a bug. It looks to me dangerous to
> try it third time.

I have only one idea what could cause something like this.

Did you add any users to the 'guix-builder' group other than the users
dedicated for that purpose?  If so, that's a problem.

guix-daemon considers all of the users in that group to be exclusively
for its use.  When asked to build something, it chooses a user from that
group to do the build, and then after the build it *kills* all processes
owned by that user.

Every once in a while, someone decides to add their normal user account
to that group, and discovers that after every build guix-daemon kills
all of their user processes.  If you added more users to that group,
perhaps guix-daemon is killing some process that causes your encrypted
/home to become unmounted?

   Mark