Re: Dependency cycle between certbot and nginx is not obvious.

[Jack Hill]

On Fri, 3 May 2024, MSavoritias wrote:


Hey,


I spent the better part of the day today trying to debug an error that was 
happening while deploying a server with two server names in the nginx field.


My config was:

 (service certbot-service-type
      (certbot-configuration
       (certificates
    (list
     (certificate-configuration
      ;; The first domain provided will be the subject CN of the 
certificate, and all domains will be Subject Alternative Names on the 
certificate.

      (domains '("joinxmpp.org" "www.joinxmpp.org")))
 (service nginx-service-type
      (nginx-configuration
       (server-blocks
    (list (nginx-server-configuration
       (server-name '("joinxmpp.org www.joinxmpp.org"))
       (ssl-certificate "/etc/certs/joinxmpp.org/fullchain.pem")
       (ssl-certificate-key "/etc/certs/joinxmpp.org/privkey.pem")
       (locations
        (list
         (nginx-location-configuration
          (uri "/support")
          (body '("return 302 
\"https://chat.joinjabber.org/#/guest?join=support\";";)))



turns out that this cant be deployed at once on the server. although it is 
correct. The reason is that certbot/letsencrypt will complain with the 
message:


Hint: The Certificate Authority failed to download the temporary challenge 
files created by Certbot. Ensure that the listed domains serve their content 
from the provided --webroot-path/-w and that files created there can be 
downloaded from the internet.



Mind you this error appeared on only one of the domains not both.

This was solved by running the system once with certbot. Then rebooting with 
the nginx service. That idea appear to me after i found a mailing list thread 
from 5 years ago saying that there is a dependency cycle between nginx and 
certbot and they cant run at the same time the first time.



The reason I am sending an email is because I am not sure if this is 
something that could be fixed somehow, or if this is unavoidable and i should 
just send a patch revising the docs slightly to suggest that if an nginx 
service is used with multiple domains in the server name, you should start 
the system once with certbot and then reboot with nginx.


Hi,

Indeed, this has been an annoyance. However, if I understand your problem 
correctly, I'm happy to report that it has now been fixed [0]! The 
start-self-signed? filed in certificate-configuration [1] should allow 
nginx to start before certbot has had a chance to get a proper cert signed 
by providing a structurally valid one for nginx to use. From the 
documentation:



start-self-signed? (default: #t)
 Whether to generate an initial self-signed certificate during system
 activation. This option is particularly useful to allow nginx to start
 before certbot has run, because certbot relies on nginx running to perform
 HTTP challenges.


However, that says that the default is #t, but it still doesn't work 
for you. I wonder what I'm missing.


Best,
Jack

[0] https://issues.guix.gnu.org/46961#1
[1] https://guix.gnu.org/en/manual/devel/en/html_node/Certificate-Services.html

Re: Troublshooting guix-publish make-systemd-constructor

[Jack Hill]

On Thu, 1 Feb 2024, Felix Lechner wrote:


Hi Jack,

On Thu, Feb 01 2024, Jack Hill wrote:


I could use some tips on what's wrong with guix-publish, and more
generally how to troubleshoot systemd services.


I use this [1] and also have (service avahi-service-type) [2] but do not
know how to troubleshoot. It just worked.


Thanks! I found the problem, and it didn't have anything to do with the 
service. I did have an older system generation where it worked, and I 
determined that the difference was switching iptables v. nftables for a 
firewall, and an oversight in the iptables config that was dropping 
packets on the loopback interface. Oops! It is nice that Guix makes it 
easy to switch back and forth like that. Thanks again for your reply.


Best,
Jack

Troublshooting guix-publish make-systemd-constructor

[Jack Hill]

Hi Guix,

I have the following in my operating system services:

(service guix-publish-service-type
 (guix-publish-configuration
  (port 9090)
  (host "localhost")))


However, trying to connect to port 9090 from localhost hangs.

`ss -tunlp | grep 9090` shows shepherd listening however:

tcp   LISTEN 0  128  127.0.0.1:9090   0.0.0.0:*
users:(("shepherd",pid=1,fd=23))

I could use some tips on what's wrong with guix-publish, and more 
generally how to troubleshoot systemd services.


Thanks!
Jack

Re: Docker image format with services

[Jack Hill]

On Sun, 30 Apr 2023, Markku Korkeala wrote:


Hi all,

just joined here, so I couldn't reply to the actual actual email, I copied 
the below message from the archive to this email


On 4/18/23 02:05, Jack Hill wrote:
I then load that into docker: `docker load < /gnu/store/…tar.gz`, and run 
it with `docker run guix`.


So far, so good. However, ssh-daemon and postgres don't start. If I then 
get a shell in the running container with `docker exec -ti … /bin/sh`, I 
can see that `herd status` reports that those services are stopped. Trying 
to start either service fails:



```
sh-5.1# herd start ssh-daemon
herd: exception caught while executing 'start' on service 'loopback':
Throw to key `%exception' with args `("#<&netlink-response-error errno: 
1>")'.

sh-5.1# herd start postgres
herd: exception caught while executing 'start' on service 'loopback':
Throw to key `%exception' with args `("#<&netlink-response-error errno: 
1>")'.


I tried something similar and got the same error message, though I used 
podman instead of docker. But anyways, I was able to get it to work by 
building the container image with --network flag:


guix system image --network --image-type=docker filename.scm

Hope this helps.


That does help, thanks!

I used the same scm file, including the (shared-network? #t) image filed, 
but added the --network cli switch, and the images are working for me now 
too. I thought that the cli switch and field were supposed to do the same 
thing.


I guess this is a bug. However, I'm not sure yet if it's in my understand 
or in Guix 😁.


Thanks!
Jack

Docker image format with services

[Jack Hill]

Hi Guix,

I have a need to build some Docker images (well, really OCI-compliant 
images) to run some service on computing systems that I don't manage. I 
thought I would use `guix system image` to build these images. In order to 
get a feel for it, I'm testing it out with the docker service running on 
my Guix System (commit 50dd91bc30634c75c0001cfd38bbcc2fbbeb894e).


So far, I've created an image from this file with `guix system image 
filename.scm`:

```
(use-modules (gnu)
 (gnu image)
 (gnu system image))
(use-service-modules databases ssh)
(use-package-modules databases linux)

(define container-os
  (operating-system
   (host-name "container")
   (timezone "America/New_York")
   (kernel linux-libre)
   (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(targets '("/dev/sdX"
   (file-systems '())
   (packages %base-packages)
   (users (cons* (user-account
  (name "jackhill")
  (comment "Jack Hill")
  (group "users")
  (supplementary-groups '("wheel" )))
 %base-user-accounts))
   (services
(cons* (service openssh-service-type
(openssh-configuration
 (port-number )
 (password-authentication? #f)
 (authorized-keys
  `(("jackhill" ,(local-file 
"/home/jackhill/.ssh/id_ed25519.pub"))

   (service postgresql-service-type
(postgresql-configuration
 (postgresql postgresql-14)
 (config-file
  (postgresql-config-file
   (log-destination "stderr")
   (hba-file
(plain-file "pg_hba.conf"
"
local all all trust
host all all 172.17.0.1/32 trust"))
   (extra-config
'(("listen_addresses" "*")
  ("log_directory""/var/log/postgresql")))
   (service postgresql-role-service-type
(postgresql-role-configuration
 (roles
  (list (postgresql-role
 (name "test")
 (create-database? #t))
   %base-services

(define container-image
  (image
   (format 'docker)
   (operating-system container-os)
   (shared-network? #t)))

container-image
```

I then load that into docker: `docker load < /gnu/store/…tar.gz`, and run 
it with `docker run guix`.


So far, so good. However, ssh-daemon and postgres don't start. If I then 
get a shell in the running container with `docker exec -ti … /bin/sh`, I 
can see that `herd status` reports that those services are stopped. Trying 
to start either service fails:


```
sh-5.1# herd start ssh-daemon
herd: exception caught while executing 'start' on service 'loopback':
Throw to key `%exception' with args `("#<&netlink-response-error errno: 1>")'.
sh-5.1# herd start postgres
herd: exception caught while executing 'start' on service 'loopback':
Throw to key `%exception' with args `("#<&netlink-response-error errno: 1>")'.
```

What's going on here? Is this a disagreement between shepherd and docker 
about who's in charge of the networking? What's the right way to create a 
docker system image that can run services?


Or, alternatively, is system image the way to go here? I haven't yet 
explored running these services from a `guix pack` produced image, but I 
suppose that could work as well?


Thanks!
Jack

Re: "user with UID not found" error

[Jack Hill]

On Mon, 1 Aug 2022, Christopher Batten wrote:


On Jul 27, 2022, at 8:44 AM, Ricardo Wurmus  wrote:

Hi Christopher,


Turns out we are using SSSD not NCSD on our Linux systems. It seems to be 
working fine:


You will need to run NSCD if you want Guix software to be able to talk
to the system’s SSSD.  The reason is that SSSD works by having
applications load a library whereas NSCD implements a network protocol.
Software built with Guix cannot load the system libary due to ABI
conflict, but it *can* talk to NSCD over the network.

The system NSCD talks to the system SSSD, so there’s no problem there.

--
Ricardo


On Wed, Jul 27, 2022 at 12:51 PM Christopher Batten  wrote:

Hmmm ... this made me think that running both was not a great idea?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/usingnscd-sssd

But I am not an expert on any of this :) I guess the key is to just make sure 
you only enable caching for hosts in /etc/nscd.conf?

Best,
Chris


On Jul 28, 2022, at 9:14 PM, Chris Marusich  wrote:

FYI: https://lists.gnu.org/archive/html/guix-devel/2022-02/msg00263.html


Thanks for everyone's help! I think I understand now: the key is if we want to 
use guix, then we really do want to run NSCD and SSSD on these RHEL/CentOS 
systems if at all possible.

So I think we just now need to follow the instructions here?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/usingnscd-sssd

Or do you recommend a different way to run NSCD and SSSD at the same time on 
RHEL/CentOS systems?

Once we figure this out maybe we should add a note about this in the Guix docs 
here:

https://guix.gnu.org/manual/en/html_node/Application-Setup.html

Especially if Fedora is intending to remove NSCD?

Thanks!
Chris


I think I've run into a similar issue trying to run packs as well (in my 
case on AlmaLinux 9). I produced a pack with


`guix pack -f tarball -RR -S /bin=bin screen sssd glibc`

and running screen from the pack reports:

"getpwuid() can't identify your account!"

screen might be a special-case of program, but it seems the problem exists 
in some way even when not trying to install Guix.


Best,
Jack

Re: was I hacked?

[Jack Hill]

On Thu, 14 Apr 2022, jgart wrote:


What I not sure of is what path on my system to find the suspicious
branch/git repo pulled down by `git/guix pull` so I can push it somewhere.

In other words, where does `guix pull` clone the git repo to?


~/.cache/guix/checkouts

~/.cache/guix/authentication may be interesting as well.

(I bet (hope?) it's actually XDG_CACHE_DIR/guix but you get the idea)

Sorry I don't have insight in to what went wrong.

Take care,
Jack

Re: Corrupt/missing store items

[Jack Hill]

On Tue, 22 Jun 2021, Ricardo Wurmus wrote:


Jack Hill  writes:

What happens if you try “guix build --check --no-grafts 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv” or similar? 
The database probably states that 
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16 has already been 
built, so with “--check” you might be able to make it build it again.


`guix gc --verify=repair` fixed the problem, so I won't be able to test 
this (unless this recurs, but I hope it doesn't).



So Guix think's it's sucessfully built gnutls, but it's still not
present in the store. I've also tried copying the store items from
other hosts. No luck so far…


How did that fail?


I didn't capture verbose output, but I believe nothing was sent because 
the problematic host reported it already had that item.


How could the directory have disappeared?  Guix appears to be very surprised 
that the directory is missing.


Apologies for leaving out more details about this host earlier. The 
filesystem is btrfs and its a virtual machine running in someone else's VM 
cluster. I had to reset and boot into older generations a few times before 
I noticed the problem because of a misconfiguration I made. Some of these 
older generation involved downgrading the kernel from 5.12 to 5.11. I 
suppose that could have caused file system corruption, although I would 
not have expected the store to be written to at the time of the resets.


Best,
Jack

Re: Corrupt/missing store items

[Jack Hill]

On Tue, 22 Jun 2021, Jack Hill wrote:


On Tue, 22 Jun 2021, Christopher Baines wrote:



Jack Hill  writes:


Given what i know about the problem: substitute operations are failing
because gnutls is not available, I tried:

jackhill@kalessin ~$ guix build --substitute-urls=http://ci.guix.gnu.org 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv

/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug
/gnu/store/ads39f4czri8s1k43qd0qpxi6dr3w0zn-gnutls-3.6.16-doc
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
jackhill@kalessin ~$ ls -l 
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
ls: cannot access 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16': No such file 
or directory


So Guix think's it's sucessfully built gnutls, but it's still not
present in the store. I've also tried copying the store items from
other hosts. No luck so far…


Does guix gc --verify=repair say anything?


It fails, becasue without gnutls my substitute servers can't be contacted. I 
also can't reconfigure with http:// substitute servers. Unfortunatley, gc 
doesn't accept a substitute-urls option.


Ok, I started the daemon by hand with http-only substitute servers, and 
--verify=repair appears to have solved my problem as far as I can tell so 
far.


Thanks to you and nckx!
Jack

Re: Corrupt/missing store items

[Jack Hill]

On Tue, 22 Jun 2021, Christopher Baines wrote:



Jack Hill  writes:


Given what i know about the problem: substitute operations are failing
because gnutls is not available, I tried:

jackhill@kalessin ~$ guix build --substitute-urls=http://ci.guix.gnu.org 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug
/gnu/store/ads39f4czri8s1k43qd0qpxi6dr3w0zn-gnutls-3.6.16-doc
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
jackhill@kalessin ~$ ls -l 
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
ls: cannot access '/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16': 
No such file or directory

So Guix think's it's sucessfully built gnutls, but it's still not
present in the store. I've also tried copying the store items from
other hosts. No luck so far…


Does guix gc --verify=repair say anything?


It fails, becasue without gnutls my substitute servers can't be contacted. 
I also can't reconfigure with http:// substitute servers. Unfortunatley, 
gc doesn't accept a substitute-urls option.


jackhill@kalessin ~$ sudo guix gc --verify=repair
reading the store...
checking path existence...
path `/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16' disappeared, 
but it still has valid referrers!
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   
0.0%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   15 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 724:2 14 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 13 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:   2147:12 12 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:757:18  9 (_)
substitute:348:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:358:27  7 (lookup-narinfos/diverse _ _ # …)
substitute:315:31  6 (lookup-narinfos "https://ci.guix.gnu.org"; _ # _ # _)
substitute:238:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1685:16  4 (raise-exception _ #:continuable? _)
substitute:   1685:16  3 (raise-exception _ #:continuable? _)
substitute:   1780:13  2 (_ #<&compound-exception components: (#<&error> 
#<&orig…>)
substitute:   1685:16  1 (raise-exception _ #:continuable? _)
substitute:   1685:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
substitute: no code for module (gnutls)
warning: 
`/gnu/store/3qbmgxrgml2bbi2hzg61nq0amyvg9sgq-guix-1.3.0-4.4985a42/bin/guix 
substitute' died unexpectedly

Thanks!
Jack

Re: Corrupt/missing store items

[Jack Hill]

Given what i know about the problem: substitute operations are failing 
because gnutls is not available, I tried:


jackhill@kalessin ~$ guix build --substitute-urls=http://ci.guix.gnu.org 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug
/gnu/store/ads39f4czri8s1k43qd0qpxi6dr3w0zn-gnutls-3.6.16-doc
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
jackhill@kalessin ~$ ls -l 
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
ls: cannot access '/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16': 
No such file or directory

So Guix think's it's sucessfully built gnutls, but it's still not present 
in the store. I've also tried copying the store items from other hosts. No 
luck so far…

Corrupt/missing store items

[Jack Hill]

Hi Guix,

I could use some help figuring out what's happened to my store and how to 
recover.


I first noticed the problem when trying to check if a package build 
reproducably. Unfortunately, I did not capture the output from that, but 
did capture subsequent commands. It seems as if the metadata has gotten 
out of sync with the store:


jackhill@kalessin ~$ guix gc --verify
reading the store...
checking path existence...
path `/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16' disappeared, 
but it still has valid referrers!

jackhill@kalessin ~$ guix build 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
The following graft will be made:
   /gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
applying 1 graft for 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv ...
grafting '/gnu/store/199npi1hcv7zn0r19vl29np6ccshii4p-gnutls-3.6.16-debug' -> 
'/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug'...
grafting '/gnu/store/8ixa3p7hwb26warjinffcrvzl064wbcg-gnutls-3.6.16-doc' -> 
'/gnu/store/ads39f4czri8s1k43qd0qpxi6dr3w0zn-gnutls-3.6.16-doc'...
grafting '/gnu/store/akc7l65z459pnifrr6bcm97cjvmpvp9k-gnutls-3.6.16' -> 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16'...
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/certtool'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/gnutls-cli'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/gnutls-cli-debug'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/gnutls-serv'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/ocsptool'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/psktool'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/bin/srptool'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/lib/guile/3.0/extensions/guile-gnutls-v-2.so.0.0.0'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/lib/guile/3.0/site-ccache/gnutls.go'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/lib/guile/3.0/site-ccache/gnutls/extra.go'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/lib/libgnutls.so.30.28.2'
updating '.gnu_debuglink' CRC in 
'/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16/lib/libgnutlsxx.so.28.1.0'
successfully built /gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug
/gnu/store/ads39f4czri8s1k43qd0qpxi6dr3w0zn-gnutls-3.6.16-doc
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
jackhill@kalessin ~$ guix gc --verify   
   reading the store...
checking path existence...
path `/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16' disappeared, 
but it still has valid referrers!
jackhill@kalessin ~$ ls -l /gnu/store/^C
^C^C
jackhill@kalessin ~$ ls -l 
/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16
ls: cannot access '/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16': 
No such file or directory

Then, I ran `guix gc` to collect all the garbage. Trying to rebuild the gnutls 
derivation results in:

jackhill@kalessin ~$ guix build 
/gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
18.6 MB will be downloaded:
   /gnu/store/2wrp7x9aclqsapm58dz5i654qds8nbb8-guile-2.0.14
   /gnu/store/mz5fvdfks10rmwxf29n95bp9bim6wq7g-nettle-3.5.1
   /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31
   /gnu/store/s3dcqzwqaakv1yx37by9chksdbkgih17-glibc-2.31-static
   /gnu/store/199npi1hcv7zn0r19vl29np6ccshii4p-gnutls-3.6.16-debug
   /gnu/store/8ixa3p7hwb26warjinffcrvzl064wbcg-gnutls-3.6.16-doc
   /gnu/store/akc7l65z459pnifrr6bcm97cjvmpvp9k-gnutls-3.6.16
The following graft will be made:
   /gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv
substituting /gnu/store/2wrp7x9aclqsapm58dz5i654qds8nbb8-guile-2.0.14...
Backtrace:
In ice-9/boot-9.scm:
  1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10 18 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
   771:15 17 (_)
In ice-9/exceptions.scm:
   406:15 16 (process-substitution # _ "/gnu/store/…" …)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
479:9 14 (_)
In ice-9/boot-9.scm:
  1747:15 13 (with-exception-handler # …)
In guix/scripts/substitute.scm:
   408:14 12 (_)
   382:28 11 (_ #< scheme: https userinfo: #f host: "ci.guix.g…> …)
In guix/build/download.scm:
453:4 10 (open-connection-for-uri _ #:timeout _ # _)
251:2  9 (tls-wrap # "ci.guix.gnu.org" # …)
   164:15  8 (load-gnutl

Re: problem with flatpak and ssl and certificates

[Jack Hill]

On Wed, 21 Apr 2021, maxxcan--- via wrote:


Hello Guix!

I´m try to install flatpak apps and many works corretly, but others don't.

My problems is with apps like Steam, Stremio, discord. They show me problems 
with ssl, o autentications.


For example:

With Discord the error is:

did-fail-load -202 ERR_CERT_AUTHORITY_INVALID retry in 2173.1183791934736 ms

The app works fine but don't connect to the server.

With Stremio:

:ERROR:ssl_client_socket_impl.cc(959)] handshake failed; returned -1, SSL 
error code 1, net_error -202


With Steam:

Invalid SSL Certificate
The SSL certificate for  is invalid and the 
page will not be loaded.


:ssl_client_socket_impl.cc(935)] handshake failed; returned -1, SSL error 
code 1, net_error -202


I installed openssl, nss, and p11-kit. And the problem is the same.

Any suggestions?

Thanks!!!


Hi,

Unfortunately, I don't have any suggestions, but I've also experienced 
this problem. I don't know that there is a Guix bug for this issue, and I 
haven't determined if this is a Guix-specific issue or a Flatpak one. 
Other people have reported a similar problem with other distributions [0], 
but perhaps it's time to create a Guix issue as well.


[0] https://github.com/flathub/org.chromium.Chromium/issues/77

It's probably not an org.chromium.Chromium issue, but I didn't know that 
when I originally reported the problem.


Best,
Jack

ProxyJump and offload

[Jack Hill]

Hi Guix,

I'm tryng to set up offloading to a remote machine on a different network. 
The preffered way to access machines on the remote network is via 
openssh's ProxyJump option (as I understand it, this does some automated 
port forwarding to access the eventual remote host via the proxy host). To 
that end I've set up the following root ssh config in /root/.ssh/config:


```
Host proxy.remote.jackhill.us
 User jackhill

Host builder.jackhill.us
 User install
 ProxyJump proxy.remote.jackhill.us
```

and /etc/guix/machines.scm:

```
(list
(build-machine
  (name "builder.jackhill.us")
  (systems '("x86_64-linux"))
  (user "install")
  (host-key "ssh-ed25519 
C3NzaC1lZDI1NTE5IHls4Zn3WmWBdBCO43gmwJSd2afVzr980nQV4RLH/tw8 root@builder")
  (private-key "/root/.ssh/id_ed25519")))
```

With this configuration `sudo -E guix offload test` suceeds:

```
$ sudo -E guix offload test
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: Guix is usable on 'builder.jackhill.us' (test returned 
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'builder.jackhill.us' is running GNU Guile 3.0.5
guix offload: sending 1 store item (0 MiB) to 'builder.jackhill.us'...
exporting path `/gnu/store/xv5y6vb5rqivpgg8c23mmyifnbjx4zkg-export-test'
guix offload: 'builder.jackhill.us' successfully imported 
'/gnu/store/xv5y6vb5rqivpgg8c23mmyifnbjx4zkg-export-test'
retrieving 1 store item from 'builder.jackhill.us'...
guix offload: successfully imported 
'/gnu/store/0p7dz3ynp51qk4q9nvbscl5bv0hvfcsh-import-test' from 
'builder.jackhill.us'
```

However, actually trying to build something that is not in my store fails:

```
$ guix build --no-substitutes okular
The following derivation will be built:
   /gnu/store/gcbhh3rbpmcr4p4rdvsj9cw48gwkhnlf-okular-20.12.1.drv
process 18275 acquired build slot '/var/guix/offload/builder.jackhill.us:22/0'
guix offload: error: failed to connect to 'builder.jackhill.us': Socket error: 
Connection reset by peer
waiting for locks or build slots...
^C
```

If I temporarily disable the need to use a proxy host and remove the ProxyJump 
line from my ssh config, then it works as expected:

```
$ guix build --no-substitutes okular
The following derivation will be built:
   /gnu/store/gcbhh3rbpmcr4p4rdvsj9cw48gwkhnlf-okular-20.12.1.drv
process 18551 acquired build slot '/var/guix/offload/builder.jackhill.us:22/0'
normalized load on machine 'builder.jackhill.us' is 0.01
building /gnu/store/gcbhh3rbpmcr4p4rdvsj9cw48gwkhnlf-okular-20.12.1.drv...
guix offload: sending 294 store items (286 MiB) to 'builder.jackhill.us'...
exporting path 
`/gnu/store/36dq4d3dba7z2vjiqsqphndn7sb2wmyj-kconfig-5.70.0-guile-builder'
…
```

What am I doing wrong?

Best,
Jack

Re: curl server certificate verification failed for a few sites

[Jack Hill]

On Thu, 4 Jun 2020, Giovanni Biscuolo wrote:


Hello Guix,

--8<---cut here---end--->8---

I'm having a strange error with curl from Guix (on a foreign distro):

--8<---cut here---start->8---
giovanni@roquette: curl -I https://voices.transparency.org
curl: (60) server certificate verification failed. CAfile: 
/home/giovanni/.guix-extra-profiles/emacs/emacs/etc/ssl/certs/ca-certificates.crt
 CRLfile: none
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
--8<---cut here---end--->8---


Giovanni,

I think that this is due to the recent AdTrust Root CA cert expiration 
[0]. The error wget gives is a little bit better, but you know about the 
situation to interpret it correctly:


"""
$ wget "https://voices.transparency.org"; -O /dev/null
--2020-06-04 10:37:29--  https://voices.transparency.org/
Resolving voices.transparency.org (voices.transparency.org)... 
52.4.225.124, 52.4.240.221, 52.1.119.170, ...
Connecting to voices.transparency.org 
(voices.transparency.org)|52.4.225.124|:443... connected.

ERROR: The certificate of ‘voices.transparency.org’ is not trusted.
ERROR: The certificate of ‘voices.transparency.org’ has expired.
"""

In my experience, sometimes this cert expiration is easy to miss by site 
administrators or others connecting to the site if they have one of the 
intermediate certificates in their trust store. Our nss-certs package 
tends not to have such intermediates.


Therefore, I think the fix is for voices.transparency.org to update the 
certificate chain/bundle that they are sending.


[0] https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l0117LT

Best,
Jack

Re: core-updates merged!

[Jack Hill]

On Fri, 8 May 2020, Marius Bakke wrote:


Guix,

The mythical 'core-updates' branch was just merged to 'master'!


Yay! Thanks Marius for shepherding this through.

Best,
Jack

Re: GNU Guix maintainer collective update

[Jack Hill]

On Mon, 4 May 2020, sirgazil wrote:


 On Mon, 04 May 2020 13:31:46 + Maxim Cournoyer 
 wrote 
> Let's take a moment to thank Ricardo for his time as a Guix
> co-maintainer.  He's been immensely useful to the project and I hope
> we'll continue to see him around.


Hey, Wurmus, thanks a million. I really appreciate your help and the work you 
have done.


Indeed, thanks Ricardo. Guix is great technology, but what I particularly 
love about it is the great community of people thanks to your kind 
leadership. Hope to see you around and best wishes!



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

Great! Welcome, Mathieu :)


Huzzah! Welcome!

Best,
Jack

Re: core-updates call for testing

[Jack Hill]

On Sat, 25 Apr 2020, sirgazil wrote:


 On Sat, 25 Apr 2020 21:19:26 + Jack Hill  wrote 

> Does GNOME-Web work for you? I'm wondering if others can reproduce the
> problem I'm seeing: https://issues.guix.gnu.org/40837

No it doesn't.


Hi all,

Unfortunately, I think I'm current stuck on fixing this bug. Any help of 
ideas would be appreciated.


Best,
Jack

Re: core-updates call for testing

[Jack Hill]

On Sat, 25 Apr 2020, sirgazil wrote:


 On Sat, 25 Apr 2020 03:02:23 + Jack Hill  wrote 

> I have not done extensive testing, but so far the desktop itself seems to
> be in working order, including cursory use of the GNOME settings dialog.

Same here. So far, things are working normally.


sirgazil,

Does GNOME-Web work for you? I'm wondering if others can reproduce the 
problem I'm seeing: https://issues.guix.gnu.org/40837


Best,
Jack

Re: core-updates call for testing

[Jack Hill]

On Fri, 24 Apr 2020, Marius Bakke wrote:


The "core-updates" branch is ready for testing!


Hi,

I've reconfigured my user profile and system from the core-updates branch. 
I use a GNOME desktop session. However, I don't use too many fancy 
features. I mostly use GNOME-Terminal, GNOME-Web, and Emacs. I also use 
some GNOME shell extensions.


I have not done extensive testing, but so far the desktop itself seems to 
be in working order, including cursory use of the GNOME settings dialog.


I have opened a bug, 40837, for GNOME-Web/epiphany, which is not working 
for me currently.


Best,
Jack

Re: core-updates call for testing

[Jack Hill]

On Fri, 24 Apr 2020, Marius Bakke wrote:


The "core-updates" branch is ready for testing!


pdfpc currently fails to build on core-updates. Upgrading to the latest 
pdfpc release fixes the issue.


Patch upgrading pdfpc is at: https://issues.guix.gnu.org/issue/40829

Best,
Jack

Re: core-updates call for testing

[Jack Hill]

On Fri, 24 Apr 2020, Marius Bakke wrote:


The "core-updates" branch is ready for testing!


Thanks Marius and others who have worked on core-updates. It's exciting to 
see these updates nearing completion.


In my testing so far, I've noticed that font-gnu-freefont fails to build: 
https://issues.guix.gnu.org/issue/40819


Best,
Jack

Re: qtwebengine support/security status

[Jack Hill]

On Mon, 20 Jan 2020, Jack Hill wrote:


Hi Guix,

Thanks to Mike and everyone for working on qtwebengine and qutebrowser. I'm 
happy and thankful that Guix's features and the community's commitment allow 
packaging these in a principled way.


Before I use these packages to browse untrusted websites, I wanted to double 
check that it is safe to do so. According to [0] we are using Qt 5.12.6 which 
is the latest LTS. I agree with the assessment there that that's pretty good. 
However the messaging from Qt, "We do update to the latest Chromium version 
in use before a Qt release. After a release some bug fixes and security 
patches are backported. For LTS releases of Qt we might also update Chromium 
in a patch level release," [1] makes me less sure that qtwebengine will 
continue to be secure over the lifetime of a Qt release. qtwebengine at 
69.0.3497.128 already seems to be behind our ungoogled-chromium package at 
78.0.3904.108.


[0] https://issues.guix.gnu.org/issue/38148#5
[1] https://wiki.qt.io/QtWebEngine

I'm also curious how Qt releases will be handled in Guix. Can they go 
directly to master, or will they need to go through a staging or core-updates 
cycles.


So summarize, do we think it's prudent to expose our qtwebengine to random 
web pages? Thanks for your thoughts and all the hard work!


I also asked about this on the #qutebrowser IRC channel as well. 
The_Compiler, qutebrowser's primary developer said,


"""
< The-Compiler> jackhill: they do backport security fixes since Qt 
5.12 is an LTS release, but it's mostly a "best effort" kind of thing


< The-Compiler> jackhill: I use (and recommend) the latest Qt 
release as soon as show-stopper bugs are fixed, usually in the .1 release 
(and for Archlinux I ask the packager to backport patches)

"""

Does this mean that we should keep the latest qtwebengine for web browsers 
as well?


Best,
Jack

qtwebengine support/security status

[Jack Hill]

Hi Guix,

Thanks to Mike and everyone for working on qtwebengine and qutebrowser. 
I'm happy and thankful that Guix's features and the community's commitment 
allow packaging these in a principled way.


Before I use these packages to browse untrusted websites, I wanted to 
double check that it is safe to do so. According to [0] we are using Qt 
5.12.6 which is the latest LTS. I agree with the assessment there that 
that's pretty good. However the messaging from Qt, "We do update to the 
latest Chromium version in use before a Qt release. After a release some 
bug fixes and security patches are backported. For LTS releases of Qt we 
might also update Chromium in a patch level release," [1] makes me less 
sure that qtwebengine will continue to be secure over the lifetime of a Qt 
release. qtwebengine at 69.0.3497.128 already seems to be behind our 
ungoogled-chromium package at 78.0.3904.108.


[0] https://issues.guix.gnu.org/issue/38148#5
[1] https://wiki.qt.io/QtWebEngine

I'm also curious how Qt releases will be handled in Guix. Can they go 
directly to master, or will they need to go through a staging or 
core-updates cycles.


So summarize, do we think it's prudent to expose our qtwebengine to random 
web pages? Thanks for your thoughts and all the hard work!


Best,
Jack

Re: How to present Guix to a wider audience

[Jack Hill]

On Tue, 14 Jan 2020, Pierre Neidhardt wrote:


Thanks, glad you liked it!
I'd be happy to get feedback from your presentation!


It's not until March 26th (it's part of a series of lunchtime 
discussions), but I'm happy to write a summary and report back.


Best,
Jack

Re: How to present Guix to a wider audience

[Jack Hill]

On Tue, 14 Jan 2020, Pierre Neidhardt wrote:


I just wrote a short draft which hopefully should explain in layman
terms why Guix matters.

I tried to keep short (< 1000 words) and to stick to non-technical vocabulary.

Let me know what you think!


On my initial reading, I think it's great, thank you! Unfortunately, I 
don't have any ideas for improvements right now, but I have been asked to 
talk about Guix at the library where I work in March, and perhaps that 
will bubble up other questions that people have.


This has helped me tremendously in thinking about how to frame Guix for 
non-hackers. Thank you.


Jack

Re: Install image with custom services

[Jack Hill]

On Thu, 19 Dec 2019, Jack Hill wrote:


I created a more minimal operating system definition:

```scheme
(define my-installation-os
 (operating-system
   (inherit installation-os)
   (packages (cons package:network-manager
 (operating-system-packages installation-os)))
   (services (operating-system-services installation-os
```

To my surprise, this also fails with

```
guix system: error: more than one target service of type 'account'
```


However, replacing

(operating-system-services installation-os)

with

(@@ (gnu system install) %installation-services)

works.

What am I not understanding about how the former works?

Best,
Jack

Install image with custom services

[Jack Hill]

Hello Guix,

I'm trying to create an installation image that uses Network Manager to 
configure networking (For use at a site with WPA-Enterprise networks). I 
came up with the following:


```scheme
(define-module (jackhill system install)
  #:use-module ((gnu packages gnome) #:select (network-manager) #:prefix 
package:)
  #:use-module (gnu services)
  #:use-module (gnu services networking)
  #:use-module (gnu system)
  #:use-module (gnu system install)
  #:use-module (srfi srfi-1)
  #:export (my-installation-os))

(define my-installation-os
  (operating-system
(inherit installation-os)
(packages (cons package:network-manager
 (operating-system-packages installation-os)))
(services (cons (service network-manager-service-type)
(remove (lambda (service)
  (eq? (service-kind service) connman-service-type))
(operating-system-services installation-os))

my-installation-os
```

However, passing that to guix system disk-image results in:

```
guix system: error: more than one target service of type 'shepherd-root'
```

Thinking that I had done something wrong with removing the connman-service 
and adding the network-manager-service, I created a more minimal operating 
system definition:


```scheme
(define my-installation-os
  (operating-system
(inherit installation-os)
(packages (cons package:network-manager
 (operating-system-packages installation-os)))
(services (operating-system-services installation-os
```

To my surprise, this also fails with

```
guix system: error: more than one target service of type 'account'
```

However,

```scheme
(define my-installation-os
  (operating-system
(inherit installation-os)
(packages (cons package:network-manager
 (operating-system-packages installation-os)
```

sucseeds.

Should these last two operating system definitions not be equivalent? 
What's going on here?


Thanks,
Jack

Re: Creating local variation of match-theme

[Jack Hill]

Thanks Marius!

On Wed, 18 Dec 2019, Marius Bakke wrote:


It's not pretty, but you could create a package that takes "match-theme"
as an input and makes the necessary adjustments.

See the 'mariadb/fixed-install-db' variant added in
9077cf68ec57c0303ef7746e203c3fe5ed041add for an example.


I tried this approach first, and find the results acceptable for this 
purpose. This technique seems most applicable when what needs to modified 
is a text file. I ended up with this package definition:


```
(package
 (inherit matcha-theme)
 (native-inputs '())
 (inputs `(("matcha-theme" ,matcha-theme)))
 (outputs '("out"))
 (build-system trivial-build-system)
 (arguments
  `(#:modules ((guix build utils))
#:builder
(begin
  (use-modules ((guix build utils)))
  (let ((upstream-theme (assoc-ref %build-inputs "matcha-theme"))
(out (assoc-ref %outputs "out")))
(copy-recursively upstream-theme out)
(substitute* (find-files out "\\.css$")
  (("abb9b6") "859900"))
 (synopsis "jackhill's version of the matcha-theme"))
```

Another "cleaner" approach could be to use 'computed-file' to create a
patched source tarball, and pass that as the source in your local
variant.


I have not yet tried this. I should because, as you point out, this is 
"cleaner", and would work in situations where what needs to be modified in 
compiled into an opaque object in the output.


However, without trying this, I don't see how it would work better than 
using a snippet in the origin definition. Or perhaps you meant to created 
the patched source tarball from the output of the upstream matcha-theme 
package?


Either way, I think I'm still left with the question of how can we make 
modifying packages easier without the need to resort to kludges.


Best,
Jack

Re: Creating local variation of match-theme

[Jack Hill]

Hi,

It's been a few days, so I was wondering if anyone had thoughts on the 
following:


Best,
Jack

On Sun, 8 Dec 2019, Jack Hill wrote:


Hi Guix,

I'd like to create a local variation of the matcha-theme package with one of 
the colors changed to suit my taste. Rather than make the change in my clone 
of the git repository, which could then become outdated, I thought I would 
try to make the change programatically as part of the package definition. I 
decided to make my change in a snippet as part of the origin specification 
because that seemed to logically fit with what I was trying to do (build a 
package with modified source) and because matcha-theme uses the trivial build 
system, which I don't believe has the concept of phases, so it wasn't clear 
how I would add a phase to make my change during the build. I came up with 
the following package definition:


```
(package
 (inherit matcha-theme)
 (source (origin
   (inherit (package-source matcha-theme))
   (modules '((guix build utils)))
   (snippet
 '(begin
(substitute* (find-files "." "\\.css$")
  (("abb9b6") "859900"))
 (synopsis "jackhill's version of the matcha-theme"))
```

Unfortunately, after building my modified source tarball correctly, the 
package build fails. I believe this is because matcha-theme's 
trivial-build-system recipe expects a source checkout and not a tarball, and 
doesn't have the logic to expand the tarball that, e.g., the gnu-build-system 
provides.


The build log contains the following:

```
@ build-started 
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv - 
x86_64-linux 
/var/log/guix/drvs/rq//x5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv.bz2 
28285

Backtrace:
  4 (primitive-load "/gnu/store/j01a49zzlrn7fyr2x7ibxyqsph5?")
In ice-9/eval.scm:
  191:35  3 (_ #f)
   619:8  2 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
In 
/gnu/store/ygivy1fvr7gbyva4z22b7vzzps1krbq5-module-import/guix/build/utils.scm:

  343:27  1 (_ "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha?" ?)
In unknown file:
  0 (copy-file "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj0?" ?)

ERROR: In procedure copy-file:
In procedure copy-file: Is a directory
`/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha-theme-2019-11-02.tar.xz' 
-> `/tmp/guix-build-matcha-theme-2019-11-02.drv-0'
builder for 
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv - 1 
builder for 
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv' 
failed with exit code 1

```

For reference, matcha-theme's builder is:

```
(arguments
'(#:modules ((guix build utils))
  #:builder
  (begin
(use-modules (guix build utils))
(let* ((out (assoc-ref %outputs "out"))
   (source (assoc-ref %build-inputs "source"))
   (bash (assoc-ref %build-inputs "bash"))
   (coreutils (assoc-ref %build-inputs  "coreutils"))
   (themesdir (string-append out "/share/themes")))
  (setenv "PATH"
  (string-append coreutils "/bin:"
 (string-append bash "/bin:")))
  (copy-recursively source (getcwd))
  (patch-shebang "Install")
  (mkdir-p themesdir)
  (invoke "./Install" "-d" themesdir)
  #t
```

This leaves me with two questions:

How should I accomplish what I want to do (change one of the colors in 
matcha-theme for local use)?


If I am right about trivial-build-system (that it makes it more difficult to 
create modified packages compared to other build systems), should we try to 
avoid using it in gnu/packages to ensure people have the easiest time 
exercising their software freedom?


Best,
Jack

Creating local variation of match-theme

[Jack Hill]

Hi Guix,

I'd like to create a local variation of the matcha-theme package with one 
of the colors changed to suit my taste. Rather than make the change in my 
clone of the git repository, which could then become outdated, I thought I 
would try to make the change programatically as part of the package 
definition. I decided to make my change in a snippet as part of the origin 
specification because that seemed to logically fit with what I was trying 
to do (build a package with modified source) and because matcha-theme uses 
the trivial build system, which I don't believe has the concept of phases, 
so it wasn't clear how I would add a phase to make my change during the 
build. I came up with the following package definition:


```
(package
  (inherit matcha-theme)
  (source (origin
(inherit (package-source matcha-theme))
(modules '((guix build utils)))
(snippet
  '(begin
 (substitute* (find-files "." "\\.css$")
   (("abb9b6") "859900"))
  (synopsis "jackhill's version of the matcha-theme"))
```

Unfortunately, after building my modified source tarball correctly, the 
package build fails. I believe this is because matcha-theme's 
trivial-build-system recipe expects a source checkout and not a tarball, 
and doesn't have the logic to expand the tarball that, e.g., the 
gnu-build-system provides.


The build log contains the following:

```
@ build-started 
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv - 
x86_64-linux 
/var/log/guix/drvs/rq//x5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv.bz2
 28285
Backtrace:
   4 (primitive-load "/gnu/store/j01a49zzlrn7fyr2x7ibxyqsph5?")
In ice-9/eval.scm:
   191:35  3 (_ #f)
619:8  2 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
In 
/gnu/store/ygivy1fvr7gbyva4z22b7vzzps1krbq5-module-import/guix/build/utils.scm:
   343:27  1 (_ "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha?" ?)
In unknown file:
   0 (copy-file "/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj0?" ?)

ERROR: In procedure copy-file:
In procedure copy-file: Is a directory
`/gnu/store/ajbvkiw30mmfhj8mpjfyvnxpjl0ycj07-matcha-theme-2019-11-02.tar.xz' -> 
`/tmp/guix-build-matcha-theme-2019-11-02.drv-0'
builder for 
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv - 1 
builder for 
`/gnu/store/rqx5yqh4ncj02rxzfwvp9jcqv9dk8l1g-matcha-theme-2019-11-02.drv' 
failed with exit code 1
```

For reference, matcha-theme's builder is:

```
(arguments
 '(#:modules ((guix build utils))
   #:builder
   (begin
 (use-modules (guix build utils))
 (let* ((out (assoc-ref %outputs "out"))
(source (assoc-ref %build-inputs "source"))
(bash (assoc-ref %build-inputs "bash"))
(coreutils (assoc-ref %build-inputs  "coreutils"))
(themesdir (string-append out "/share/themes")))
   (setenv "PATH"
   (string-append coreutils "/bin:"
  (string-append bash "/bin:")))
   (copy-recursively source (getcwd))
   (patch-shebang "Install")
   (mkdir-p themesdir)
   (invoke "./Install" "-d" themesdir)
   #t
```

This leaves me with two questions:

How should I accomplish what I want to do (change one of the colors in 
matcha-theme for local use)?


If I am right about trivial-build-system (that it makes it more difficult 
to create modified packages compared to other build systems), should we 
try to avoid using it in gnu/packages to ensure people have the easiest 
time exercising their software freedom?


Best,
Jack

Re: reconfigure in failure

[Jack Hill]

On Thu, 24 Oct 2019, Marius Bakke wrote:


Hello Pierre,

pirboazo  writes:


for several days I can no longer update my system.

with the last guix : 4c46356
The update fails during the check phase of the jimtcl-0.77 package.


Where is this package from?  I can not find it in Guix.


I believe this is 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/embedded.scm?id=4c463569b7af3ee064d323691bc0284155f9a85d#n331 
. However, I have that in my store as


$ guix build jimtcl
/gnu/store/mica4mip3mdcp7wfmdnbynwm8p2bbwq2-jimtcl-0.77

So it at least built one time.

Sorry to not have more insight

Best,
Jack

Re: Who is sending my Guix System to sleep?

[Jack Hill]

I also found a related Debian bug for gdm settings: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896083

Re: Who is sending my Guix System to sleep?

[Jack Hill]

On Fri, 11 Oct 2019, Ludovic Courtès wrote:


Konrad Hinsen  skribis:


The only problem is that after 20 minutes, the virtual machine
seems to freeze.


I've experienced unwanted suspends as well on a desktop system when not 
logged in graphically.



I found the cause in /var/log/messages:

Sep 26 08:54:40 localhost NetworkManager[282]:   [1569480880.2246] 
manager: sleep: sleep requested (sleeping: no  enabled: yes)
Sep 26 08:54:40 localhost NetworkManager[282]:   [1569480880.2247] 
manager: NetworkManager state is now ASLEEP
Sep 26 08:54:40 localhost NetworkManager[282]:   [1569480880.2248] 
device (enp0s3): state change: activated -> deactivating (reason 'sleeping', 
sys-iface-state: 'managed')
Sep 26 08:54:40 localhost NetworkManager[282]: 
[1569480880.2293] device (enp0s3): state change: deactivating ->
disconnected (reason 'sleeping', sys-iface-state: 'managed')

Something requests NetworkManager to go to sleep, which is obviously not
good for my ssh connection. But what?


I believe that NetworkManager is more of a symptom than a cause, and it is 
not really related to networking, but NetworkManager happens to be the 
most helpful thing by printing the error messages.



I think elogind is the thing you’d want to configure to turn off
automatic standby when the machine is idle, presumably by changing the
‘idle-action’ field of ?

logind.conf(5) is not entirely clear, though:


Also, it looks like we're already setting idle-action to ignore by 
default[0], so I was skeptical that this is what was triggering the 
suspend.


[0] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/desktop.scm?id=cdc81ccedb332fb297f6100ccd99eaf13d161ada#n618

My particular symptoms are that when I log into a graphical GNOME session 
from gdm, the machine does not suspend unexpectedly, and follows the 
settings that I have configured in GNOME Settings. However, if I'm not 
logged in, and the computer is waiting at the gdm greater, the unwanted 
suspension happens.


I believe what is happening is when a user is logged in, their settings 
are in force, but when no user is logged in, it is the gdm user's settings 
that are effective.


After some searching online [1][2][3], it appears that the following dconf 
settings are the important ones:


/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type
/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout

[1] 
https://unix.stackexchange.com/questions/361214/disable-gdm-suspend-on-lock-screen
[2] https://bbs.archlinux.org/viewtopic.php?id=132376
[3] https://wiki.archlinux.org/index.php/GNOME#Login_screen

I changed sleep-inactive-ac-type imperatively by becoming the gdm user 
and then running dconf command as follows


```
# su - gdm -s /run/current-system/profile/bin/sh
-sh-5.0$ export $(dbus-launch)
-sh-5.0$ dconf write /org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type 
"'blank'"
```

Note the double quoting around blank. This is important when running at 
the shell because the single quotes are part of the value so that its type 
can determined.


After running the dconf command a /var/lib/gdm/.config/dconf/user file is 
created to hold this setting, and (at least after restarting the host, I 
don't know if this is necessary, but it's what I did) the computer no 
longer suspends while waiting for a user to login.


It would be great to be able to handle dconf settings in the gdm-service. 
It would be even greater to have general dconf settings mechanisms to 
handle settings stored in that database for any service that uses it. I 
could see this being useful to guix home as well as any work to clean up 
stateful system directories [4]. Perhaps the dconf settings mechanisms 
could even look at schemas to aid in generating code and only provide the 
user with ways to write correct configuration.


[4] https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html

Best,
Jack

guix copy connection problems

[Jack Hill]

Hello Guix,

I'm trying to use `guix copy` to copy some store items from a more 
powerful computer to my laptop. I've tried to set everything up correctly 
with ssh-agent, and I can ssh without being prompted for credentials, but 
guix-initiated connections are timing out, so clearly I'm missing 
something, but I don't know what. Perhaps the following session transcript 
with show what I'm missing:


```
$ env|grep -i ssh
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
jackhill@alperton ~$ ssh-add -l
256 SHA256:g7qjlV99AHx3R2/ZlkeMGPqnYGzwPJjhVY5y7WX1a/E jackhill@alperton 
(ED25519)
jackhill@alperton ~$ ssh jackhill@remote
Last login: Fri Jul 26 21:38:23 2019 from 107.15.18.231
jackhill@remote ~$ logout
Connection to remote closed.
jackhill@alperton ~$ guix copy --from="jackhill@remote" icecat
guix copy: error: SSH connection to 'remote' failed: Timeout connecting to 
remote
```

Best,
Jack

Re: GuixSD doesn't boot on UEFI

[Jack Hill]

On Fri, 26 Jul 2019, luka...@tutanota.com wrote:


I it freezes my UEFI so it doesn't boot... No GRUB, no GNU Shepard, nothing...
:(


Lukas,

Wow, when it fails that early in the process, there is not that much to go 
on. Have you tried booting other other (non-Guix) media. It would be 
interesting to know if other live media (e.g. 
https://wiki.parabola.nu/Get_Parabola ) works for you.


How are you loading Guix unto your boot media? It might be interesting to 
try a CD or USB if you've only tried one so far.


This might be getting ahead of ourselves, but even if you can't get the 
Guix installer to boot, you may still be able to get Guix installed on 
your computer. Options are to connect the disk to a different computer and 
use Guix (potentially installed on a foreign distro) there to do the 
installation on the disk, and move it to the target computer once 
installed. I had to do this recently for a host that would not boot from 
external media. A variation on this theme would be to install use the Guix 
binary distribution on different live media that you are able to boot.


Also, if you hava way to do it, updating to the latest version of your 
UEFI code might be a good idea.


What computer and UEFI are you using?

Best,
Jack

Re: grub with encrpted root no longer automatically loads luks

[Jack Hill]

On Fri, 28 Jun 2019, Mark H Weaver wrote:


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?


Mark,

Thanks for your reply. I've finally had a chance to try without a separate 
/boot, and indeed it works as expected like it does for you. Since I don't 
think I was getting any benefit from having a separate /boot, I'm content 
to leave it without one. However, perhaps there is a bug here, and we 
should support a separate /boot?


As for why I started getting this problem, it appears it is because I 
didn't have a separate /boot, but then added one. Trying to remember why I 
did that, I think it was because grub-install failed at some point, and 
worked when I added a /boot. However, I didn't reboot right away, and had 
reconfigured a few more times before I rebooted and noticed the problem. 
At that point I didn't remember that I had changed the configuration with 
regards to /boot. Of course it was the thing I changed that caused the 
problem, if only I had remembered! ☺


Best,
Jack

Re: grub with encrpted root no longer automatically loads luks

[Jack Hill]

Thanks for you reply.

On Fri, 21 Jun 2019, Giovanni Biscuolo wrote:


Hello Jack,

I don't have a Guix machine using root on encrypted LUKS now, but I
tested this non so long ago and it worked well

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.


Are you able to boot to a previous Guix System generation and try to
find the one that introduced this behaviour?


No, I can't boot into a previous generation, as the problem seems to be 
with grub reading from the store. I have not yet tried reconfiguring with 
an older version of Guix.



Are you sure you did not reconfigured your device mapping meanwhile?


I am reasonable certain that I have not done this.


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.


I imagine you are entering the grub CLI because you get some error:
what's the error please?


no such file /gnu/store/…/bzImage.
error: try loading kernel first

That's not the exact error, but pretty close.


AFAIU (mapped-device ..(target "name") (type luks-device-mapping)))
creates the mapped device /dev/mapper/name; file-system should be:

--8<---cut here---start->8---

(file-system
 (device "/dev/mapper/alperton_root")
 (mount-point "/")
 (type "ext4")
 (dependencies mapped-devices))
%base-file-systems))

--8<---cut here---end--->8---


Making the this change unfortunately did not help. Once I get the system 
booted, the root file system is mounted correctly with both configs.



Did your configuration worked in a prior Guix System generation?


Yes, but I haven't yet had a chance to try it again with an older version 
of Guix.


Best,
Jack

grub with encrpted root no longer automatically loads luks

[Jack Hill]

Hi Guix,

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. 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: btrfs mount options not used

[Jack Hill]

On Thu, 20 Jun 2019, Jack Hill wrote:


Hi Guix,

I'm trying to mount my btrfs root filesystem with the compress=lzo option. 
Following Section 8.3 or the manual (System Configuration → File Systems, I 
added (options "compress=lzo") to my file system definition. However, when I 
reconfigure and reboot, it does not appear that the file system is mounted 
with this option. When I mount the filesystem manually with `mount -o 
compress=lzo …` it works correctly. Full operating system config below. What 
am I missing?


Best,
Jack

from /proc/mounts:
```
/dev/nvme0n1p2 / btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 
0 0

```


I forgot to mention: the gerated /etc/fstab looks correct


```
LABEL=lib-its13_nvme_btrfs	/	btrfs	compress=lzo 
LABEL=EFI	/boot/efi	vfat	defaults 
```


So that made me think that maybe the initramfs was the source of the 
problem, but that too looks correct. /gnu/store/-init in the 
initramfs looks fine as well:


```
(begin (use-modules (gnu build linux-boot)
(gnu system file-systems)
(guix build utils)
(guix build bournish)
(srfi srfi-26)
((gnu build file-systems) #:select 
(find-partition-by-luks-uuid))
(rnrs bytevectors))
   (with-output-to-port (%make-void-port "w")
 (lambda ()
   (set-path-environment-variable "PATH"
  (quote ("bin" "sbin"))
  (quote 
("/gnu/store/cxka7q519j6x26dqd2dv47vccbj7vmwd-btrfs-progs-static-5.1")
   (boot-system #:mounts (map spec->file-system
  (quote (((file-system-label "lib-its13_nvme_btrfs") 
"/"
   "btrfs"
   (no-atime)
   "compress=lzo"
   #t#:pre-mount
   (lambda ()
 (and))
   #:linux-modules (quote ("ahci" "usb-storage" "uas" 
"usbhid" "hid-generic"
   "hid-apple" "dm-crypt" 
"xts" "serpent_generic"
   "wp512" "nls_iso8859-1" 
"pata_acpi" "pata_atiixp"
   "isci" "virtio_pci" 
"virtio_balloon" "virtio_blk"
   "virtio_net" 
"virtio_console" "virtio-rng"
   
"btrfs"))#:linux-module-directory
   (quote 
"/gnu/store/2ayjrg59m7kkjsbjp3akqz4sr467dd8j-linux-modules")
   
#:keymap-file #f#:qemu-guest-networking? #f#:volatile-root? (quote #f)#:on-error
   (quote 
debug)))
```

btrfs mount options not used

[Jack Hill]

Hi Guix,

I'm trying to mount my btrfs root filesystem with the compress=lzo option. 
Following Section 8.3 or the manual (System Configuration → File Systems, 
I added (options "compress=lzo") to my file system definition. However, 
when I reconfigure and reboot, it does not appear that the file system is 
mounted with this option. When I mount the filesystem manually with `mount 
-o compress=lzo …` it works correctly. Full operating system config below. 
What am I missing?


Best,
Jack

from /proc/mounts:
```
/dev/nvme0n1p2 / btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
 0 0
```

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 ssh)
 (gnu services xorg)
 (guix-at-duke services endpoint-management))
(use-service-modules desktop)
(use-package-modules certs fonts gnome linux security-token)

(operating-system
 (host-name "lib-its13")
 (timezone "America/New_York")
 (locale "en_US.utf8")

 ;; Use the UEFI variant of GRUB with the EFI System
 ;; Partition mounted on /boot/efi.
 (bootloader (bootloader-configuration
  (bootloader grub-efi-bootloader)
  (target "/boot/efi")))

 (file-systems (cons* (file-system
   (device (file-system-label "lib-its13_nvme_btrfs"))
   (mount-point "/")
   (type "btrfs")
   (flags '(no-atime))
   (options "compress=lzo"))
  (file-system
   (device (file-system-label "EFI"))
   (mount-point "/boot/efi")
   (type "vfat"))
  %base-file-systems))

 (swap-devices (list "/root/swap"))

 (users (cons (user-account
   (name "install")
   (comment "installation user")
   (group "users")
   (supplementary-groups '("wheel" "netdev"
   "audio" "video"))
   (home-directory "/home/install"))
  %base-user-accounts))

 ;; This is where we specify system-wide packages.
 (packages (cons* nss-certs ;for HTTPS access
  btrfs-progs
  gvfs  ;for user mounts
  font-google-noto  ;(full) unicode font
  %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 openssh-service-type (openssh-configuration))
  (service gnome-desktop-service-type)
  (service planisphere-report-service-type)
  (simple-service 'custom-udev-rules udev-service-type (list 
libu2f-host))
  %desktop-services))

 ;; Allow resolution of '.local' host names with mDNS.
 (name-service-switch %mdns-host-lookup-nss))
```

Re: Problem with building service from my channel

[Jack Hill]

On Tue, 11 Jun 2019, Jack Hill wrote:


Here's where I define a service that extends mcron-service-type


I copied the code for this service from my channel into an arbitrary 
service file in the guix repository, hoping for a different message that 
would provide more insight. To my surprise, it build sucessfully, and I as 
able to sucessfully search for my service using `./pre-inst-env guix 
system search`.


Ideas?

Here's the patch that I added to guix:


From c91455049a4bd5eca9f3128135c000d6d881a23a Mon Sep 17 00:00:00 2001

From: Jack Hill 
Date: Wed, 12 Jun 2019 20:38:13 -0400
Subject: [PATCH] test commit

---
 gnu/services/certbot.scm | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index ae34ad17bb..ecca5f360b 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -27,6 +27,7 @@
   #:use-module (gnu services web)
   #:use-module (gnu system shadow)
   #:use-module (gnu packages tls)
+  #:use-module (gnu packages certs)
   #:use-module (guix i18n)
   #:use-module (guix records)
   #:use-module (guix gexp)
@@ -35,7 +36,10 @@
   #:export (certbot-service-type
 certbot-configuration
 certbot-configuration?
-certificate-configuration))
+certificate-configuration
+planisphere-report-configuration
+   planisphere-report-configuration?
+   planisphere-report-service-type))

 ;;; Commentary:
 ;;;
@@ -190,3 +194,29 @@
  "Automatically renew @url{https://letsencrypt.org, Let's
 Encrypt} HTTPS certificates by adjusting the nginx web server configuration
 and periodically invoking @command{certbot}.")))
+
+(define-record-type* 
+  planisphere-report-configuration make-planisphere-report-configuration
+  planisphere-report-configuration?
+  (certs planisphere-report-certs
+(default nss-certs))
+  (package planisphere-report-package
+  (default nss-certs))
+  (schedule planisphere-report-schedule
+   (default '(quote (next-minute-from (next-hour '(0 12)) (list 
(random 60)))
+
+(define (planisphere-report-jobs config)
+  (let ((sched-spec (planisphere-report-schedule config))
+   (certs (file-append (planisphere-report-certs config) "/etc/ssl/certs"))
+   (cmd (file-append (planisphere-report-package config) 
"/bin/planisphere-report")))
+(list
+ #~(append-environment-mods "SSL_CERT_DIR" #$certs)
+ #~(job #$sched-spec #$cmd
+
+(define planisphere-report-service-type
+  (service-type
+   (name 'planisphere-report)
+   (extensions
+(list (service-extension mcron-service-type planisphere-report-jobs)))
+   (default-value (planisphere-report-configuration))
+   (description "Periodically run @command{planisphere-report} to update the OIT 
endpoint database.")))
--
2.21.0

compared to the service in my channel

(define-module (guix-at-duke services endpoint-management)
  #:use-module (gnu services)
  #:use-module (gnu services mcron)
  #:use-module (guix gexp)
  #:use-module (guix records)
  #:use-module (guix-at-duke packages endpoint-management)
  #:export (planisphere-report-configuration
planisphere-report-configuration?
planisphere-report-service-type))

(define-record-type* 
  planisphere-report-configuration make-planisphere-report-configuration
  planisphere-report-configuration?
  (package planisphere-report-package
   (default planisphere-report))
  (schedule planisphere-report-schedule
(default '(quote (next-minute-from (next-hour '(0 12)) (list 
(random 60)))

(define (planisphere-report-jobs config)
  (let ((sched-spec (planisphere-report-schedule config))
(cmd (file-append (planisphere-report-package config) 
"/bin/planisphere-report")))
(list
 #~(job #$sched-spec #$cmd

(define planisphere-report-service-type
  (service-type
   (name 'planisphere-report)
   (extensions
(list (service-extension mcron-service-type planisphere-report-jobs)))
   (default-value (planisphere-report-configuration))
   (description "Periodically run @command{planisphere-report} to update the OIT 
endpoint database.")))

Re: Problem with building service from my channel

[Jack Hill]

On Tue, 11 Jun 2019, Ludovic Courtès wrote:


Jack Hill  skribis:


```
(repl-version 0 0)
(exception misc-error (value #f) (value "Unbound variable: ~s") (value 
(mcron-service-type)) (value #f))
```


The Guile exception possibly means that code in your channel refers to
‘mcron-service-type’, but that this variable is unbound.  It could be
because one of your modules lacks #:use-module (gnu services mcron).


Ludo’,

That makes sense, except, I don't see where I have used 
mcron-service-type, but not used the (gnu services mcron) module, and the 
same channel code was working as of 
31775e400e05fb05fff0de4d3ffbf9549fe20994, so I think it that means it has 
to be something else.


Here's where I define a service that extends mcron-service-type

```
(define-module (guix-at-duke services endpoint-management)
  #:use-module (gnu packages certs)
  #:use-module (gnu services mcron)
  #:use-module (gnu services)
  #:use-module (guix gexp)
  #:use-module (guix records)
  #:use-module (guix-at-duke packages endpoint-management)
  #:export (planisphere-report-configuration
planisphere-report-configuration?
planisphere-report-service-type))

…[snip]…

(define planisphere-report-service-type
  (service-type
   (name 'planisphere-report)
   (extensions
(list (service-extension mcron-service-type planisphere-report-jobs)))
   (default-value (planisphere-report-configuration))
   (description "Periodically run @command{planisphere-report} to update the OIT 
endpoint database.")))
```

Best,
Jack

Problem with building service from my channel

[Jack Hill]

Hi Guix,

I have defined the planisphere-report-service-type in my channel 



This has been working well for me, and I have most recently been able to 
build my channel with `guix pull` with the following version of guix:


```
$ guix describe
Generation 5Jun 10 2019 13:44:44(current)
  guix 31775e4
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 31775e400e05fb05fff0de4d3ffbf9549fe20994
  guix-at-duke 363d627
repository URL: https://gitlab.oit.duke.edu/jackhill/guix-at-duke.git
branch: master
commit: 363d6270d5e3505c34aa0dbfa221f64421497587
```

However, when I try to pull the most recent guix, 
aec9bb8793ca75a5bbc1731460ed4eb388764202, the build of my channel fails:


```
building /gnu/store/hycfgn8iiy9z205zi1174sgcgs0vnm5r-guix-at-duke.drv...
|builder for `/gnu/store/hycfgn8iiy9z205zi1174sgcgs0vnm5r-guix-at-duke.drv' 
failed to produce output path 
`/gnu/store/kd88fi3fsbghnscxp0ccjrzh0si055mg-guix-at-duke'
build of /gnu/store/hycfgn8iiy9z205zi1174sgcgs0vnm5r-guix-at-duke.drv failed
View build log at 
'/var/log/guix/drvs/hy/cfgn8iiy9z205zi1174sgcgs0vnm5r-guix-at-duke.drv.bz2'.
```

The build log is;

```
(repl-version 0 0)
(exception misc-error (value #f) (value "Unbound variable: ~s") (value 
(mcron-service-type)) (value #f))
```

Presumably there was some change to the mcron-service-type recently that 
requires changes in my channel, but I don't see what they could be or how 
to fix my channel.


What's going on here? What is the Guile exception trying to tell me?

Best,
Jack

Re: Why are these derivations different?

[Jack Hill]

On Mon, 10 Jun 2019, Marius Bakke wrote:


What's really going on with --no-grafts. Is it that guix on my less
powerful host has never seen the the ungoogled-chromium version build
against the older dependencies, so doesn't accept the older version that
could be grafted? I guess, I'm not sure exactly what you mean by "fails to
realize the grafted derivation". Is that a bug?


Sorry, just a lazy and poor attempt at explaining what's going on...  :-)


No worries, I appreciate you taking the time to help me understand.


Sorry, I don't think that question was very clear. It probably means that
while I think I know what grafts are, I don't know enough about what's
going on to ask the question properly. I think this all could be summarized
as, "please explain more."


Grafts are are ignored in some parts of Guix.  In this case, if you
inspect the profile derivation when doing 'guix install -n
ungoogled-chromium', you can see that the computed profile.drv needs to
produce the ungrafted ungoogled-chromium-x.y.z.drv, because the
profile-builder references the _ungrafted_ package.

I'm not sure of the exact mechanics that follow, but I guess grafts are
only computed afterwards, recursively, for the generated profile.


Ok, thank help. Thank you.

Jack

Re: Why are these derivations different?

[Jack Hill]

On Sat, 8 Jun 2019, Marius Bakke wrote:


Jack Hill  writes:


Hi Guix,

I'm trying to copy the store items for ungoogled-chromium from one of my
hosts that has many computational resources to another one that does not,
so that I do not have to build ungoogled-chromium on the less powerful
host.

However, even after copying the store items using guix archive --export |
guix archive --import, the less powerful host wants to build
ungoogled-chromium because the derivations differ (see attachments).


I suspect this has to do with grafts.  Guix is missing a substitute for
the 'ungrafted' package and fails to realize the grafted derivation.

Exporting with --no-grafts should do the trick.


Marius,

Thanks! That was it.

If you don't mind, I have a few follow up question to help me understand 
how everything works:


How is guix archive --no-grafts different from guix build --no-grafts? Oh, 
or after reading the manual for --no-grafts again, maybe I used the wrong 
incantation (guix build --no-grafts package-name instead of guix build 
package-name --no-grafts)?


What's really going on with --no-grafts. Is it that guix on my less 
powerful host has never seen the the ungoogled-chromium version build 
against the older dependencies, so doesn't accept the older version that 
could be grafted? I guess, I'm not sure exactly what you mean by "fails to 
realize the grafted derivation". Is that a bug?


Sorry, I don't think that question was very clear. It probably means that 
while I think I know what grafts are, I don't know enough about what's 
going on to ask the question properly. I think this all could be summarized 
as, "please explain more."


Many thanks,
Jack

Why are these derivations different?

[Jack Hill]

Hi Guix,

I'm trying to copy the store items for ungoogled-chromium from one of my 
hosts that has many computational resources to another one that does not, 
so that I do not have to build ungoogled-chromium on the less powerful 
host.


However, even after copying the store items using guix archive --export | 
guix archive --import, the less powerful host wants to build 
ungoogled-chromium because the derivations differ (see attachments).


How can I go about seeing why the derivations differ?

Both hosts are using the same version of guix:

$ guix describe
Generation 35   Jun 07 2019 21:49:47(current)
  guix 07023eb
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 07023ebc1892a559cad1f80235a4afb0955b29ab

and

$ guix describe
Generation 3Jun 06 2019 16:39:40(current)
  guix 07023eb
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 07023ebc1892a559cad1f80235a4afb0955b29ab

Best,
JackDerive([("out","/gnu/store/kpbfydvf16vvva7gy56p1d85b2ry9dgn-ungoogled-chromium-74.0.3729.169-0.d2beaef","","")],[("/gnu/store/05g7z2cndn7snvwmhb0ghjxd7bscdzr5-cups-2.2.11.drv",["out"]),("/gnu/store/0hg04ci30k9f46lycq3a38k5jnd6pkpv-cairo-1.16.0.drv",["out"]),("/gnu/store/0pqbf0jy7h29p7hm02a8lya8c6wgwrya-ffmpeg-4.1.3.drv",["out"]),("/gnu/store/0pswzqisl4frkahc8n25v0khzm5qwk9q-libjpeg-turbo-2.0.1.drv",["out"]),("/gnu/store/13lni3376l0asaryf5v7yx1pkclg724c-pango-1.42.4.drv",["out"]),("/gnu/store/14zh54fjfnrjm108mj857l4ckgn3w0wa-fontconfig-2.13.1.drv",["out"]),("/gnu/store/16i2br91zcamkq08jazhy0lxa0dxmlwg-openjpeg-2.3.1.drv",["out"]),("/gnu/store/1ywcgh6rwvjhs6qqj1h8izcg22idl2x3-module-import-compiled.drv",["out"]),("/gnu/store/2yzhaf13j1nrcag78y683z6kdnnnpmr0-cairo-1.16.0.drv",["out"]),("/gnu/store/37qkp6861qnmx2ixy7jg51jg1dywd9m2-harfbuzz-2.2.0.drv",["out"]),("/gnu/store/3r8d3h2l1dwbvad4p20bchk3ljlwqh6i-gtk+-3.24.7.drv",["out"]),("/gnu/store/5dl6856mpvqv1qwdp5vmri76ab8x4acz-nss-3.43.drv",["out"]),("/gnu/store/5q3kdzj1hq85i9a5nr6z8yl54xigjcc2-openjpeg-2.3.0.drv",["out"]),("/gnu/store/6343p3yq191mc8cxrz1y8jrm840v2whj-fontconfig-2.13.1.drv",["out"]),("/gnu/store/8ha35c10aghpwwd2v0c8xk46vlppbz19-lcms-2.9.drv",["out"]),("/gnu/store/9i3iz56a403km3b97mwvdavyi488yhpf-ffmpeg-4.1.3.drv",["out"]),("/gnu/store/bmgyx3il9i3qvwr2wyi4ak7my59dl5nk-libwebp-1.0.2.drv",["out"]),("/gnu/store/bp7hq2bwcy9d8937814c5gr15ylgp5k6-harfbuzz-2.2.0.drv",["out"]),("/gnu/store/c83y8vza2x19w03cav577a3mq4h80w81-gtk+-3.24.7.drv",["out"]),("/gnu/store/f1ajr6s8gy4ldmiaqr5s9i9m724r5a5r-freetype-2.9.1.drv",["out"]),("/gnu/store/fqg9n41z2ca66r9m6dcy2b1kmz2gpx7i-guile-2.0.14.drv",["out"]),("/gnu/store/ivighhym2js9xpj77c27qg4gfw16xxwr-freetype-2.9.1.drv",["out"]),("/gnu/store/js4ix1yhhhk2j184bc19ynq3cap1f3a5-gdk-pixbuf-2.38.1.drv",["out"]),("/gnu/store/kwnn6x7z45g8j1iha1087mpiv48pwz3j-cups-2.2.11.drv",["out"]),("/gnu/store/lkhd8g814l0c9wy9h4dii9gw44vi964f-libva-2.4.0.drv",["out"]),("/gnu/store/n07vg2agjv9m7yg6dyi59ys65aaqxjkv-lcms-2.9.drv",["out"]),("/gnu/store/nr087v1hy3x2byjvvvmbqk6nhrzcxrmg-libpng-1.6.34.drv",["out"]),("/gnu/store/qk80f8arfbsmsxrx0f7645ph5y3nrwnr-mesa-18.3.5.drv",["out"]),("/gnu/store/qr4vv4br4sspi1sllzzaqn7fiilbxg9f-pango-1.42.4.drv",["out"]),("/gnu/store/qz49ik2lvbff7xrl5685kvng6iv6qa7x-libpng-1.6.37.drv",["out"]),("/gnu/store/s9w71hlp4xaw65hn027gnbir6rl2pp3x-ungoogled-chromium-74.0.3729.169-0.d2beaef.drv",["out"]),("/gnu/store/shmm2wml357xpwyzl42hkl6wzjsw7jws-libwebp-1.0.2.drv",["out"]),("/gnu/store/svylcniwjvpv1hm12pbf0zrxp224pshz-libva-2.4.0.drv",["out"]),("/gnu/store/v9chjkf5fgqdm7igikszxm9y5zc6chdx-gdk-pixbuf-2.38.1.drv",["out"]),("/gnu/store/vhkrlh8g2jjrjpcr53w455297z8fqzn7-libevent-2.1.10.drv",["out"]),("/gnu/store/vq1alsi8yh55h4y4ggjqp1w8vp3prswf-nss-3.43.drv",["out"]),("/gnu/store/wq0v31rj2lbs63hvi9gg1dm27rck3mx8-libevent-2.1.10.drv",["out"]),("/gnu/store/x0v5hll1sw6sqf9wjclkw526hflaar1x-module-import.drv",["out"]),("/gnu/store/y7z4g1gf9knrjb44yspvsfab0ksfvjwy-libjpeg-turbo-2.0.2.drv",["out"]),("/gnu/store/ziyqnilzi6is9g79blw8q820liddfjf5-mesa-18.3.5.drv",["out"])],["/gnu/store/41wxjzb4yhwdqbn4bwjqprb8l5di34dc-ungoogled-chromium-74.0.3729.169-0.d2beaef-guile-builder"],"x86_64-linux","/gnu/store/1fl9vk8fpafkws4qyy25vcdfpybxyh1k-guile-2.0.14/bin/guile",["--no-auto-compile","-L","/gnu/store/d84nbv6r94i8ixvz7f6g22pwdyvnnx6g-module-import","/gnu/store/41wxjzb4yhwdqbn4bwjqprb8l5di34dc-ungoogled-chromium-74.0.3729.169-0.d2beaef-guile-builder"],[("GUILE_LOAD_COMPILED_PATH","/gnu/store/gza8djv7fmxh60pdh8jkkjj7shy3mnsz-module-import-compiled"),("allowSubstitutes","0"),("guix
 properties","((type . graft) (graft (count . 
18)))"),("out","/gnu/store/kpbfydvf16vvva7gy56p1d85b2ry9dgn-ungoogled-chromium-74.0.3729.169-0.d2beaef"),("preferLocalBuild","1")])Derive([("out","/gnu/store/k1q4n62ph77vj24vbkkz5caibf6hakri-ungoogled-chromium-74.0.3729.169-0.d2beaef","","")],[("/gnu/store/0ag86rz9dz3v4z0dw7xvcwiqvww395c9-openssl-1.0.2p.drv",["out"]),("/gnu/store/0hg04ci30k9f46lycq3a38k5

Re: warning: setlocale: LC_ALL: cannot change locale on foreign distro

[Jack Hill]

On Mon, 3 Jun 2019, Josh Holland wrote:


Hi Guix,

It's only now I reply to this that I notice that it wasn't my thread I
was responding to, since I was having exactly the same problem.


I'm always releived to see other people having the same problem, and I'm 
not lost in some dark corner of computer problems where no one else 
ventures :)



On Mon, Jun 03, 2019 at 02:01:50PM -0400, Jack Hill wrote:

1) The default locale in the provided systemd unit, en_US.utf8, is not
provided by the glibc-locales package but rather only by the
glibc-utf8-locales package.


Installing glibc-utf8-locales has made the errors go away.


Yay!


2) The quoting in systemd unit is wrong. Changing

```
Environment=GUIX_LOCPATH='/var/guix/profiles/per-user/root/guix-profile/lib/locale'
 LC_ALL=en_US.utf8
```

to


```
Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
 LC_ALL=en_US.utf8
```

fixed the problem.


I've made this change too, though it appeared to be fixed just by
installing glibc-utf8-profiles.


What foreign distro are you using? I wonder if the former works with some 
systemd versions, but not all.




I'll open bugs for each of these issues.


Glad that these won't be a problem any more; thanks a lot!


To close the loop, those issues are

https://issues.guix.info/issue/36074 and
https://issues.guix.info/issue/36076

While poking around the bugtracker, I noticed another one which is related 
to the whole situation:


https://issues.guix.info/issue/35671

Best,
Jack

Re: Help with writing custom boot-loader configuration

[Jack Hill]

On Mon, 3 Jun 2019, Raghav Gururajan wrote:


On Thu, 2019-05-30 at 10:11 +, Raghav Gururajan wrote:

Hello Guix!

If I want to make the "grub-bootloader" to invoke ONLY "grub-mkconfig" 
and NOT "grub-install", how should I modify the "bootloader" part of 
"operating-system" section of system configuration (config.scm)? I am 
looking for exact Guile Scheme Code to achieve the same.


Thank you!

Regards,
RG.



RG,

My first thought after reading your question was 
. 
However, I guess you need something else, but I'm not sure what it is. Can 
you explain more what you're trying to do? Thanks!


Best,
Jack

Re: warning: setlocale: LC_ALL: cannot change locale on foreign distro

[Jack Hill]

On Mon, 3 Jun 2019, Jack Hill wrote:


Hello Guix,

I'm setting up Guix on a foreign distro (CentOS 7). I'm working on getting 
locales right per section 2.6.1 of the manual. I have installed the 
guix-locales package in buth my user's and root's profile, and have restarted 
guix-daemon. However, when I run package installation opterations, I see the 
following message,


```
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)

```


There appears to be two things going on here:

1) The default locale in the provided systemd unit, en_US.utf8, is not 
provided by the glibc-locales package but rather only by the 
glibc-utf8-locales package.


I think the fix for this would be to clarify which package should be 
installed in root's profile when installing on a systemd foreign distro.


2) The quoting in systemd unit is wrong. Changing

```
Environment=GUIX_LOCPATH='/var/guix/profiles/per-user/root/guix-profile/lib/locale'
 LC_ALL=en_US.utf8
```

to


```
Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
 LC_ALL=en_US.utf8
```

fixed the problem.

I'll open bugs for each of these issues.

Best,
Jack

warning: setlocale: LC_ALL: cannot change locale on foreign distro

[Jack Hill]

Hello Guix,

I'm setting up Guix on a foreign distro (CentOS 7). I'm working on getting 
locales right per section 2.6.1 of the manual. I have installed the 
guix-locales package in buth my user's and root's profile, and have 
restarted guix-daemon. However, when I run package installation 
opterations, I see the following message,


```
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
```

GUIX_LOCPATH is set to /home/jackhill/.guix-profile/lib/locale

What am I missing?

```
$ guix describe
Generation 2Jun 03 2019 10:54:12(current)
  guix 3092f1b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 3092f1b835d79655eecb2f8a79dda20ad9ba6bd6
```

Thanks,
Jack

Re: Possible store corrumption

[Jack Hill]

On Tue, 21 May 2019, Giovanni Biscuolo wrote:


Could be a full disk issue?


In this case that was not true. It turned out to be bad memory. When I ran 
a memory test, it aborted do to too many errors, which is not a good sign 
☺. Therefore, I expect what was happening was that data was being 
corrupted in memory, and the bad data was begin written to disk.


Thanks for your help,
Jack

Possible store corrumption

[Jack Hill]

Hi Guix,

I've run guix gc --verify and received the following output:

$ guix gc --verify
reading the store...
checking path existence...
path `/gnu/store/k5qxpr9wswli6lskpp433mrk0ffvxa9q-gcc-6.5.0.tar.xz.drv' 
disappeared, but it still has valid referrers!
path `/gnu/store/k5vl8jfhjasarib3ya4zpimxb1qm5hbj-expat-2.2.6-guile-builder' 
disappeared, but it still has valid referrers!
path 
`/gnu/store/k8r5c77rqzi2jg70x4sk2bf79q9gqbxn-python-minimal-wr?pper-3.7.0.drv' 
disappeared, removing from database...
path `/gnu/store?k8jx7nmx92dpr65gg2l3avajq4ngwxs7-zlib-1.2.11-guile-builder' is 
not in the store
path `/gn?/store/k681wjynl5pkmi8bdbbxxvdn2ljvq854-gnome-disk-utility-3.28.3' is 
not in the store
path `26478' is not in the store

At firt I suspected filesystem corruption, but my store is on btrfs and 
btrfs scrub reports no errors:


$ sudo ./btrfs scrub status /
scrub status for ffa898fe-cd24-400e-8bc7-1865643a2d45
scrub started at Mon May 20 16:15:36 2019 and finished after 00:00:42
total bytes scrubbed: 19.20GiB with 0 errors

guix gc fails with:

$ guix gc
finding garbage collector roots...
deleting garbage...
guix gc: error: executing SQLite query: database or disk is full

What might be causing these symptoms and how might I resolve them?

Best,
Jack

Re: Debugging an mcron job

[Jack Hill]

On Mon, 1 Apr 2019, Ludovic Courtès wrote:


Jack Hill  skribis:

I've solved this for my service by adding SSL_CERT_DIR to the environment:

https://gitlab.oit.duke.edu/jackhill/guix-at-duke/blob/a9674ec7b0decac94745c91df886817e2fc8a91b/guix-at-duke/services/endpoint-management.scm

Is that a reasonable solution?


I’m (very) late to the party but what you did looks like the right thing
to me.


No worries, I still find the sanity check helpful.


PS: Good to see you’re building interesting stuff with this!


Me too :) I've really enjoyed working with the Guix and mcron building 
blocks.


Best,
Jack

Re: checking out a shebang-patched package source

[Jack Hill]

On Tue, 26 Mar 2019, Brett Gilio wrote:


It has been a few days, so I am bumping this. Thanks :)


Brett,

Unfortunately, I don't know how to solve your problem. However, I think 
that your question is appropriate for the guix-de...@gnu.org list, and I 
anticipate that you'll see more replies there.


Best,
Jack

Re: Color calibrating scanner with GNOME

[Jack Hill]

On Sat, 16 Mar 2019, Jack Hill wrote:

I can see the scanner from my unprivileged user, and it shows up the the 
GNOME hardware/calibration dialog. Unfortunately, clicking on the 
"calibrate" button does nothing. On Debian buster with GNOME 3.30, doing 
so brings up a calibration wizard.


I believe that I have determined why this is so. There is needed software 
which is not yet packaged for Guix. The calibration wizard is provided by 
gnome-color-manager [0]. Gnome-color-manager depends on argyllcms [1], 
which is also not yet packaged. Argyllcms in turn requires the Jam build 
tool [2][3] or the Jam fork by FreeType, ftjam [4]. Jam is also not yet 
packaged. As a little twist for Jam, it looks like Perforce upstream 
stopped developing it in 2014, and the FreeType fork's latest release 
seems even older. It is still available in modern Debian, so hopefully 
this won't be too much of hurdle.


[0] https://gitlab.gnome.org/GNOME/gnome-color-manager
[1] https://www.argyllcms.com/
[2] https://www.perforce.com/documentation/jam-documentation
[3] 
https://swarm.workshop.perforce.com/projects/perforce_software-jam/files/main
[4] https://www.freetype.org/jam/index.html

Best,
Jack

Re: Color calibrating scanner with GNOME

[Jack Hill]

On Sat, 16 Mar 2019, Jack Hill wrote:

On Guix, when the scanner is connected via USB it cannot be found by my 
user's scanning programs (or, therefore, the GNOME hardware/calibration 
dialog). However, it can be found as root. I suspect the problem is a missing 
udev rule. What is the right way to proceed?


Indeed, it was a udev problem. Adding:

(simple-service 'sane-udev-rules udev-service-type (list sane-backends))

to my services solves the problem and I can see the scanner from my 
unprivileged user, and it shows up the the GNOME hardware/calibration 
dialog. Unfortunately, clicking on the "calibrate" button does nothing. On 
Debian buster with GNOME 3.30, doing so brings up a calibration wizard.


I also noticed since adding this rule that, I get messages like:

udevd[3658]: specified group 'scanner' unknown

in dmesg. Should adding the sane udev rules also create a scanner POSIX 
group? Thoughts? I'll have to check out how Debian handles this.


Best,
Jack

Re: Color calibrating scanner with GNOME

[Jack Hill]

On Sat, 16 Mar 2019, Jack Hill wrote:


Hi Guix,

I'm trying to color calibrate my scanner while running GNOME by following 
these instructions: 
https://help.gnome.org/users/gnome-help/stable/color-calibrate-scanner.html.en


I have produced a tiff of my calibration target, but my scanner doesn't show 
up in the GNOME settings color submenu. The only device show is my laptop 
screen.


GNOME's simple-scan and sane-backend's* scanimage can use the scanner, and 
scanimage reports it as:


$ scanimage -L
device `pixma:MF4800_Canon5e5c59' is a CANON Canon i-SENSYS MF4800 Series 
multi-function peripheral


The device is connected over the network.

What should I do to try to calibrate my scanner?


I've done some more troubleshooting:

I installed GNOME 3.30 (newer GNOME than current Guix master) on a Debian 
10 (buster, testing) host. The scanner did not show up in the calibration 
dialog when connecting over the network. I suspect that this is because 
GNOME hardware/calibration does not trigger the search of the network for 
scanners. When I plugged it in via USB, it did show up in the calibration 
dialog. (Unfortunately, it doesn't scan over USB because of some as yet 
undetermined bug in sane or the device firmware (I'm extra suspicious of 
it because it is a multi-function device, so I imagine is more complex.).)


On Guix, when the scanner is connected via USB it cannot be found by my 
user's scanning programs (or, therefore, the GNOME hardware/calibration 
dialog). However, it can be found as root. I suspect the problem is a 
missing udev rule. What is the right way to proceed?


Best,
Jack

Color calibrating scanner with GNOME

[Jack Hill]

Hi Guix,

I'm trying to color calibrate my scanner while running GNOME by following 
these instructions: 
https://help.gnome.org/users/gnome-help/stable/color-calibrate-scanner.html.en


I have produced a tiff of my calibration target, but my scanner doesn't 
show up in the GNOME settings color submenu. The only device show is my 
laptop screen.


GNOME's simple-scan and sane-backend's* scanimage can use the scanner, and 
scanimage reports it as:


$ scanimage -L
device `pixma:MF4800_Canon5e5c59' is a CANON Canon i-SENSYS MF4800 Series 
multi-function peripheral

The device is connected over the network.

What should I do to try to calibrate my scanner?

Best,
Jack

* The name of this package is slightly confusing, since it also contains 
the front-end tools like scanimage. I don't know if it makes sense to make 
a change here or not.

Re: Debugging an mcron job

[Jack Hill]

On Tue, 12 Mar 2019, Jack Hill wrote:

I've figured out what was going wrong with my job (by redirecting the output 
to a file). It couldn't verify the remote host's certificate:


urllib2.URLError: verify failed (_ssl.c:726)>


Now to figure out why. I have nss-certs in my system packages.


I've solved this for my service by adding SSL_CERT_DIR to the environment:

https://gitlab.oit.duke.edu/jackhill/guix-at-duke/blob/a9674ec7b0decac94745c91df886817e2fc8a91b/guix-at-duke/services/endpoint-management.scm

Is that a reasonable solution?

Best,
Jack

Re: Debugging an mcron job

[Jack Hill]

I've figured out what was going wrong with my job (by redirecting the 
output to a file). It couldn't verify the remote host's certificate:


urllib2.URLError: 

Now to figure out why. I have nss-certs in my system packages.

Best,
Jack

Re: Debugging an mcron job

[Jack Hill]

On Mon, 11 Mar 2019, Jack Hill wrote:


Hi Guix,

I'm looking for help or tips on debugging an mcron job.


I haven't yet solved this, but have some done some more (potentially 
interesting) troubleshooting.


The problem only seems to present itself, when mcron is run from Shepherd. 
For testing purposes, I changed the schedule to run every minute. This is 
how mcron is being called from Shepherd:


# ps -ef|grep mcron
root 32463 1  0 15:11 ?00:00:00 
/gnu/store/mamwayq00mqs85kgs6ibww7xw6dy776s-mcron-1.1.1/bin/mcron 
/gnu/store/0h36hing715c57k9xz5f6fgm77krq4p7-mcron-job

If I then run the same thing from a root shell:

# /gnu/store/mamwayq00mqs85kgs6ibww7xw6dy776s-mcron-1.1.1/bin/mcron 
/gnu/store/0h36hing715c57k9xz5f6fgm77krq4p7-mcron-job
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/0h36hing715c57k9xz5f6fgm77krq4p7-mcron-job
;;; compiled 
/root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/0h36hing715c57k9xz5f6fgm77krq4p7-mcron-job.go

it works. What could be causing this?

The contents of the job file are:

(job "* * * * *" 
"/gnu/store/61692zjpkhy3jqv4a7jk1k8a14k6yn8k-planisphere-report-0-0.1b606af/bin/planisphere-report")

Best,
Jack

Debugging an mcron job

[Jack Hill]

Hi Guix,

I'm looking for help or tips on debugging an mcron job. My goal is to run 
a site-specific telemetry script that I have packaged [0] in my channel. 
The script collects some information and sends it to a remote server. I am 
trying to run the script as an mcron job via a service I created in my 
channel [1].


[0] 
https://gitlab.oit.duke.edu/jackhill/guix-at-duke/blob/0ed0a8e7530ef32b9e268d43b36944e38defa5f1/guix-at-duke/packages/endpoint-management.scm#L98-140
[1] 
https://gitlab.oit.duke.edu/jackhill/guix-at-duke/blob/0ed0a8e7530ef32b9e268d43b36944e38defa5f1/guix-at-duke/services/endpoint-management.scm

So far, this looks good, and after pulling my channel, reconfiguring, and 
restarting mcron, I can see my job in herd schedule mcron:


"""
# herd schedule mcron
Tue Mar 12 00:51:00 2019 -0400
/gnu/store/61692zjpkhy3jqv4a7jk1k8a14k6yn8k-planisphere-report-0-0.1b606af/bin/planisphere-report
…
"""

However, this doesn't appear to work because after the appointed time, the 
remote server is not updated. If I run the planisphere-report command by 
hand, the remote server is updated.


If I replace the planisphere-report command in my job with 
"/run/current-system/profile/bin/touch /tmp/test-file", test-file is 
indeed touched, so I know that the jobs are running.


Being fairly new to Guix, and extremely new to mcron, I don't know how to 
debug further. Are jobs run in such a way that they don't have network 
access? How can I see any errors or output?


Best,
Jack

P.S. I'm happy to accept any comments about how to improve the code in my 
channel as well ☺.

Re: Need help porting eDuke32

[Jack Hill]

On Tue, 26 Feb 2019, HiPhish wrote:


Ken Silverman is an asshole and an idiot for writing his own license instead
of using an existing one, or letting an actual lawyer write it. And in 2000 he
didn't even have the "dumb teenager" excuse.


While non-free software is frustrating (and I'm sure is even more 
frustrating after having done some work on it assuming it was free), there 
is no need for name calling. I love that Guix is a community devoted to 
both software freedom and being an open an welcoming community full of 
respect and free of insults. Let's not lose sight of one of these goals in 
pursuit of the other.


Ken,

If you would like your software included in GNU Guix, I invite you to work 
the the community to find a mutually acceptable license. I expect that if 
you choose to do so the experience will be rewarding.


For all the rest of us,

Perhaps this is a blessing in disguise, and we can have the joy of working 
on a free software replacement engine.


All the best,
Jack

Re: grub.cfg does not have luks module for encrypted root

[Jack Hill]

On Fri, 1 Feb 2019, Joshua Branson wrote:


Jack Hill  writes:


Ahoy,

I'm using the attached config.scm for a host with an encrypted gpt
root partition while booking with bios-grub. It produces the attached
grub.cfg, which lacks the luks module, thus grub cannot find the
kernel.

If I enter the grub command line and manually insmod luks and
cryptomount, I can then boot correction.


Out of curiosity how do you boot GuixSD on the grub command line?

The only way I know how to do it is:

set root=(hd0,1)  ; wherever your root partition is
linux /gnu/path/to/vmlinuz-linux-libre root=/dev/sda1
initrd /gnu/path/to/initramfs-linux-libre.img
boot

In arch linux, I know where those paths are: /boot, but it GuixSD those
paths are usually buried in /gnu/some/crazy/path...


Once I ran 'insmod luks' and 'crytomount (hd0,gpt2)', the filesystem 
containing the store became available to Grub. I then ran 'configfile 
(hd0,gpt1)/boot/grub/grub.cfg' to have Grub reprocess the config file that 
Guix wrote for it. Since the store was now available, Grub was able to 
load its theme, kernel, and initramfs. Sorry for admitting that step in my 
summary.


Best,
Jack

Re: grub.cfg does not have luks module for encrypted root

[Jack Hill]

I have solved my problem, and now have Grub working with an encrypted /. 
The config I had before had a gpt partitioned disk, with bios boot. I had 
an encrypted / and a separate, unencrypted /boot.


When I changed the configuration to not use a separate /boot filesystem, 
and put /boot on the encrypted root, Grub dutifully prompts me for a 
password, and is then able to boot the system normally.


Is it a bug that a separate /boot doesn't work? Is it worth mentioning in 
the manual that a separate /boot isn't needed?


As a side note: I had been expecting 'insmod luks' and 'cryptomount …' 
lines in the grub.cfg. They don't appear even with the working setup, but 
we are running grub-install with the GRUB_ENABLE_CRYPTODISK environment 
variable set. I couldn't find a mention of this variable in the Grub 
manual. What's going on here/how do all the pieces fit together?


Best,
Jack

grub.cfg does not have luks module for encrypted root

[Jack Hill]

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

  (users (cons (user-account
(name "jackhill")
(comment "Jack Hill")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video"))
(home-directory "/home/jackhill"))
   %base-user-accounts))

  ;; This is where we specify system-wide packages.
  (packages (cons* nss-certs ;for HTTPS access
   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* (gnome-desktop-service)
   %desktop-services))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

Re: List of installed package, version pairs

[Jack Hill]

On Wed, 16 Jan 2019, Gábor Boskovits wrote:



Hello Jack,
you could also try to make sense of the individual profile generation
manifests.

The union of those should give a farily comprehensive list, and it comes with 
versions.


Yes, this looks pretty good, thanks. I think that this gets me all the 
surface packages exposed in all the profiles. However, I believe that it 
is still missing the packages installed as dependencies.


One thought is to drop back to manipulating store objects. I can get a 
list of references using query-path-info from the guix store module, and 
recurse down those references to build the graph. In the end I have to 
then guess the package names and versions from the store paths.


From my experimentation, it seems that store paths/objects are really what 
Guix works with and is aware of, and not package names and version that 
are reported as what's installed on traditional distributions. Perhaps I 
can convince our security office to be happy with store paths.


Thoughts?
Jack

Re: List of installed package, version pairs

[Jack Hill]

Thanks! I'm still not quite there, but the suggestion below have been 
quite helpful in my thinking and experimentation.


On Thu, 10 Jan 2019, Efraim Flashner wrote:


For packages you have installed in your profile
'guix package -I | cut -f1,2 --output-delimiter=@ | sort -u' gives a
nice list. Perhaps someone else has an idea for the list from your
os-config.


I think I have an answer for the OS config: pass the --profile option to 
guix package, so the guix package command becomes 'guix package 
--profile=/var/guix/profiles/system/profile -I'



Although the code above doesn't take into account build inputs and
packages that are in your binaries' paths. For that my two initial ideas
are 'guix package -I | cut -f1 | sort -u | xargs guix size' or
'guix package -I | cut -f1 | sort -u | guix refresh --list-transitive'
and some more shell scripting to get the package and version.


Yes, I did want to inputs in the list as well. However, I worry that 
calculating these by passing package names to the current guix may 
inadvertently list newer inputs than were used by the, potentially older, 
guix that instantiated the profile.


Best,
Jack

List of installed package, version pairs

[Jack Hill]

Hi,

It seems that work has noticed the GuixSD host that I brought into the 
office. The security office maintains a risk profile be collecting lists 
of installed packages, so I've been asked to produce one for the GuixSD 
host. I assume that the garbage collector's live-paths is roughly 
equivalent to what they want.


However, I've become stuck developing this report as both "guix gc 
--list-live" and the live-paths function in the (guix store) Guile module 
produce a list of store paths. I would like to get the package name and 
version. Is there a good way to do this without resorting to string 
manipulation?


Best,
Jack

Re: How/When will guix pull stop to compile the 616 files?

[Jack Hill]

On Wed, 9 Aug 2017, Ricardo Wurmus wrote:


Before a substitute can be requested, Guix will have to compute a
derivation locally.  In the case of Guix itself this is rather
expensive.

Once we have the derivation we can ask substitute servers if they have a
binary substitute for performing the work the derivation describes.

So, local *computation* cannot be avoided, but local building should be
avoidable for most packages — here the problem is that hydra isn’t fast
enough yet.  I’ve been preparing an alternative build farm at the
institute where I work, which will hopefully soon be powerful enough to
build packages more quickly than our current Hydra does.


Thanks!!

Re: How/When will guix pull stop to compile the 616 files?

[Jack Hill]

On Tue, 8 Aug 2017, Ricardo Wurmus wrote:



Paul Dufresne  writes:


It takes 45 mins. on my relatively old dual core to guix-pull


Yeah, this isn’t great.  Since 0.13.0 compilation is slower and requires
a whole lot more memory.  That’s a known problem.

There are some ideas to reduce the amount of compilation that has to
happen locally, but it isn’t quite as simple as a first look may
suggest.


Could building be avoided entirely with substitutes? Are substitutes not 
appropriate for some reason, or is it just that substitutes are not 
produced on Hydra for every guix commit?


Thanks for clearing this up for a Guix beginner.

Jack