bug#38946: guix import fails for cabal-helper

[Robert Vollmert]

It appears that the guix cabal parser (in guix/import/cabal.scm) isn’t aware
of `common` stanzas.

https://www.haskell.org/cabal/users-guide/developing-packages.html#pkg-section-common-common

Note that there’s quite a few issues with the cabal parser, and the format is 
pretty
baroque, to the extent that I wonder whether it wouldn’t be better to delegate 
the
parsing to cabal itself.

E.g.:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35743
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36690

I also remember some issue with braces instead of indentation, but can’t find a 
bug
report right now.

bug#39051: nginx caching headers are broken due to epoch store timestamps

[Robert Vollmert]

I don’t see anything here: 
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix;include=subject%3Anginx

> On 9. Jan 2020, at 12:00, Gábor Boskovits  wrote:
> 
> Hello,
> 
> Robert Vollmert  ezt írta (időpont: 2020. jan. 9., Cs, 
> 11:54):
>> 
>> I’ve been having hard-to-debug caching issues serving up static files
>> with nginx. It turns out this is due to nginx computing e-tag headers
>> from file timestamps, which are all epoch in the guix store.
>> 
>> I’ve fixed this on my server by applying a patch from Nix:
>> https://github.com/robx/guix/commit/4b406f5bc608b3c0e18e15795d8fe61d3477a3e2
> 
> this is a known issue. Could you look around the tracker and merge?
>> 
>> 
>> 
>> 
> 
> Also, on the long run it would be nice to contribute a working etags
> computation to nginx, that
> is based on the file content hash, or something like that. Does that make 
> sense?
> 
> Best regards,
> g_bor
> -- 
> OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#39051: nginx caching headers are broken due to epoch store timestamps

[Robert Vollmert]

I’ve been having hard-to-debug caching issues serving up static files
with nginx. It turns out this is due to nginx computing e-tag headers
from file timestamps, which are all epoch in the guix store.

I’ve fixed this on my server by applying a patch from Nix:
https://github.com/robx/guix/commit/4b406f5bc608b3c0e18e15795d8fe61d3477a3e2

bug#38471: meta: I don't receive follow-ups to bug reports I submitted

[Robert Vollmert]

I remarked on this before: 
https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00315.html

It seems that I don’t get follow-up emails to bug reports I submitted unless
people explicitly put me in CC (presumably by reply to all in the original email
thread). I’ve failed to answer follow-up queries to a number of bugs due to 
this;
assuming this doesn’t affect only me, this seems to be quite bad for dealing 
with
bugs effectively.

Recent example: I did not receive Guillaume’s first reply in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38469

Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439 (against debbugs).

I might report this against debbugs itself instead, but to me the bug is more
“the Guix bug tracker doesn’t send follow-ups” rather than the specific debbugs
issue. E.g. fixing this by using a different bug tracker would be great! :)

bug#38469: guix gc should keep around recent intermediate build

[Robert Vollmert]

> Have you tried passing the options '--gc-keep-derivations=yes’ and
> '--gc-keep-outputs=yes' to guix-daemon?

I had not. I added that right now, and first tests seem to indicate
that this helps. Thanks!

Would it be a bad idea to make this the default?

Alternatively, how about some kind of developer config fragment that
would modify a system configuration with settings that are a good
idea for Guix development, if not general use? That might also include
things like setting the $%!^@!*^% guile backtrace columns variable
for guix-daemon.

bug#38469: guix gc should keep around recent intermediate build ingredients by default

[Robert Vollmert]

[ This is a user/developer friendliness feature request. I’m not arguing
  that `guix gc` should do anything differently on a technical level, I’m
  just trying to argue that the default experience should be different. ]

Current situation:
  I use a forked guix repository as my default channel, which
  includes a number of slow-to-build Haskell packages. Now and
  then, I run out of disk space. So I call `guix gc`, which invariably
  removes the store paths involved in building my current system generation,
  so the next call to `guix system reconfigure` takes hours.

Desired situation:
  After calling `guix gc`, the paths that were involved in my last system
  build are still around, so reconfiguring doesn’t result in everything
  being rebuilt.

(If there’s some way I can achieve that now, perhaps by explicitly managing
some roots, or passing specific arguments to `guix gc`, I’d be happy to
know! I’d still argue that we should try to make this the default behaviour,
though.)

bug#38444: sshd / login segmentation faults

[Robert Vollmert]

I just had to restart my Guix VPS because both ssh as well as console login
were failing. Rebooting fixed the issue (for now). I haven’t seen such issues
before. The system was pulled and reconfigured from master in the last couple
days, and recently added docker-related services. I hadn’t rebooted into updated
kernels in the last few weeks.

Other services were still running successfully, so it seems unlikely that there
was some out-of-resources thing going on, but hard to say.

Logs for sshd:

Dec  1 14:55:00 localhost vmunix: [1549839.654228] sshd[15465]: segfault at 
7fcf0008 ip 7fcfe9257278 sp 7ffe164811c0 error 4 in 
ld-2.28.so[7fcfe9249000+1e000]
Dec  1 14:55:00 localhost vmunix: [1549839.654259] Code: 8b 1b 48 03 5a 08 48 
8b 40 08 48 c1 e8 03 85 c0 74 23 83 e8 01 4c 8d 74 c3 08 0f 1f 84 00 00 00 00 
00 4c 89 ea 4c 89 e6 89 ef  13 48 83 c3 08 49 39 de 75 ed 5b 5d 41 5c 41 5d 41 5e c3 0f 1f
Dec  1 14:55:00 localhost vmunix: [1549839.684596] audit: type=1326 
audit(1575208500.500:114): auid=4294967295 uid=989 gid=983 ses=4294967295 
subj==unc
onfined pid=15466 comm="sshd" 
exe="/gnu/store/l02fsn5jln4jrbsc28yr26abi0lqxz97-openssh-8.0p1/sbin/sshd" 
sig=31 arch=c03e syscall=41 compat=0 ip=0x7fcfe8d22f27 code=0x0

Logs for console login:

Dec  1 14:53:55 localhost vmunix: [1549774.678304] login[15437]: segfault at 
7f58 ip 7f5013855278 sp 7ffd42e196f0 error 4 in 
ld-2.28.so[7f5013847000+1e000]
Dec  1 14:53:55 localhost vmunix: [1549774.678343] Code: 8b 1b 48 03 5a 08 48 
8b 40 08 48 c1 e8 03 85 c0 74 23 83 e8 01 4c 8d 74 c3 08 0f 1f 84 00 00 00 00 
00 4c 89 ea 4c 89 e6 89 ef  13 48 83 c3 08 49 39 de 75 ed 5b 5d 41 5c 41 5d 41 5e c3 0f 1f
Dec  1 14:53:55 localhost shepherd[1]: Respawning term-tty1. 
Dec  1 14:53:55 localhost shepherd[1]: Service term-tty1 has been started. 

bug#37237: mcron randomly stops running jobs

[Robert Vollmert]

This is the third time I’ve seen this, and this time I’m
sure that nothing else happened.

I have numerous mcron jobs configured, many of which run every 15 minutes,
and one which runs once a minute. Just now, at 19:22, I noticed the minutely
cron job didn’t seem to run, and saw that one every-15-minute job which always
logs to mcron.log had last run at 18:00. I restarted mcron, and jobs started
running again. There is no timezone confusion either: That every-15-minute job
logged its first run at 19:30.

bug#37071: guix import pypi httpie fails

[Robert Vollmert]

> On 18. Aug 2019, at 13:49, Robert Vollmert  wrote:
> 
> 
> 
>> On 18. Aug 2019, at 13:28, Nicolas Goaziou  wrote:
>> Robert Vollmert  writes:
>> 
>>> $ guix import pypi httpie
>>> …0.2.tar.gz  83KiB   291KiB/s 00:00 [##] 
>>> 100.0%
>>> ….py3-none-any.whl  58KiB201KiB/s 00:00 [##] 
>>> 100.0%
>>> guix import: warning: Failed to extract file: 
>>> httpie-1.0.2.dist-info/METADATA from wheel.
>>> Backtrace:
>> 
>> [...]
>> 
>>> 
>>> guix/build/download.scm:728:8: In procedure maybe-expand-mirrors:
>>> In procedure struct_vtable: Wrong type argument in position
>>> 1 (expecting struct): #f
>> 
>> FWIW, I cannot reproduce it. I get
> 
> Thanks for looking into this!
> 
> I’ll try making sure everything is up to date, and try again.

Just to note that the error persists after guix pull. Weird.

@Nicolas: Did your test use a recently pulled guix?

bug#37071: guix import pypi httpie fails

[Robert Vollmert]

> On 18. Aug 2019, at 13:28, Nicolas Goaziou  wrote:
> Robert Vollmert  writes:
> 
>> $ guix import pypi httpie
>> …0.2.tar.gz  83KiB   291KiB/s 00:00 [##] 
>> 100.0%
>> ….py3-none-any.whl  58KiB201KiB/s 00:00 [##] 
>> 100.0%
>> guix import: warning: Failed to extract file: 
>> httpie-1.0.2.dist-info/METADATA from wheel.
>> Backtrace:
> 
> [...]
> 
>> 
>> guix/build/download.scm:728:8: In procedure maybe-expand-mirrors:
>> In procedure struct_vtable: Wrong type argument in position
>> 1 (expecting struct): #f
> 
> FWIW, I cannot reproduce it. I get

Thanks for looking into this!

I’ll try making sure everything is up to date, and try again.

bug#37071: guix import pypi httpie fails

[Robert Vollmert]

$ guix import pypi httpie
 …0.2.tar.gz  83KiB   291KiB/s 00:00 [##] 100.0%
 ….py3-none-any.whl  58KiB201KiB/s 00:00 [##] 100.0%
guix import: warning: Failed to extract file: httpie-1.0.2.dist-info/METADATA 
from wheel.
Backtrace:
  15 (primitive-load "/home/rob/.config/guix/current/bin/guix")
In guix/ui.scm:
  1692:12 14 (run-guix-command _ . _)
In guix/scripts/import.scm:
   115:11 13 (guix-import . _)
In guix/scripts/import/pypi.scm:
   102:23 12 (guix-import-pypi . _)
In guix/memoization.scm:
 98:0 11 (_ # ("httpie") _)
In unknown file:
  10 (_ # …)
In ice-9/boot-9.scm:
829:9  9 (catch _ _ # …)
In guix/utils.scm:
635:8  8 (call-with-temporary-output-file _)
In guix/import/pypi.scm:
   384:25  7 (_ "/tmp/guix-file.A9OwRK" _)
In guix/utils.scm:
635:8  6 (call-with-temporary-output-file #)
In guix/import/utils.scm:
   133:10  5 (_ "/tmp/guix-file.jFzPxe" _)
123:4  4 (url-fetch _ _)
In guix/build/download.scm:
763:4  3 (url-fetch "/tmp/guix-file.A9OwRK" "/tmp/guix-file.jFz…" …)
In srfi/srfi-1.scm:
   679:15  2 (append-map _ _ . _)
   592:17  1 (map1 (#f))
In guix/build/download.scm:
728:8  0 (maybe-expand-mirrors _ _)

guix/build/download.scm:728:8: In procedure maybe-expand-mirrors:
In procedure struct_vtable: Wrong type argument in position 1 (expecting 
struct): #f

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

[Robert Vollmert]

On 8. Aug 2019, at 18:40, Chris Marusich  wrote:
> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
> 
>> 'switch-to-system-generation' doesn't call out to
>> 'upgrade-shepherd-services'. I'm not sure if this was an intentional
>> decision or not
> 
> It is intentional, but only because there is currently no way to call
> upgrade-shepherd-services when switching system generations.

How does shepherd work on a non-guix system? Can’t be it be configured
like other daemons to read its configuration from a file, e.g. from

   /run/current-system/etc/shepherd.conf

and be told via signal to reload its configuration from disk?

…

(I feel a bit cheated right now. This behaviour makes Guix System entirely
unsuitable for server use. It shouldn’t be advertised as supporting
transactional upgrades and rollbacks if those require a reboot.)

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

[Robert Vollmert]

Could we get some input on this bug?

Maybe I’m misunderstanding something, but it seems that a core guix
feature (atomic rollbacks) doesn’t work…

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

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

[Robert Vollmert]

Could we get some input on this bug?

Maybe I’m misunderstanding something, but it seems that a core guix
feature (atomic rollbacks) doesn’t work…

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

bug#36878: guix system reconfigure broken

[Robert Vollmert]

> On 31. Jul 2019, at 20:16, Jakob L. Kreuze  
> wrote:
> 
> Hi Robert,
> 
> Robert Vollmert  writes:
> 
>> The concrete problem is this:
>> 
>> 1. nginx is running with config file A
>> 2. make some change to nginx config
>> 3. run guix system reconfigure (which builds a new nginx config file B)
>> 4. run herd restart nginx
>> 5. nginx is still running with config file A
>> 
>> After reverting this commit, if I perform these steps, I end up with
>> nginx running with config file B in 5.
> 
> Okay, I see now. Thank you clarifying. Would you be willing to see if
> the patch provided by #36880 fixes this issue?

Yes, it seems it does!

bug#36878: guix system reconfigure broken

[Robert Vollmert]

> On 31. Jul 2019, at 18:45, Jakob L. Kreuze  
> wrote:
> Robert Vollmert  writes:
> 
>> Hi,
>> 
>> it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012
>> 
>>  guix system: Reimplement 'reconfigure’.
>> 
>> breaks guix system reconfigure. In particular, after reconfiguring,
>> shepherd doesn’t know about the updated versions of services.
>> 
>> The usual output below is missing; after reverting the commit it’s
>> fine again.
> 
> Could you please elaborate on what you mean by this? I can see that the
> ouput has changed, but is Shepherd doing something that indicates that
> it doesn't know about the new services?

The concrete problem is this:

1. nginx is running with config file A
2. make some change to nginx config
3. run guix system reconfigure (which builds a new nginx config file B)
4. run herd restart nginx
5. nginx is still running with config file A

After reverting this commit, if I perform these steps, I end up with
nginx running with config file B in 5.

> And is the line regarding
> bootloader installation also missing from 'guix system reconfigure'
> post-5c8c8c455?

I still get a bootloader line.

Cheers
Robert

bug#36878: guix system reconfigure broken

[Robert Vollmert]

Hi,

it appears that commit 5c8c8c455420af27189d6045b3599fe6e27ad012

  guix system: Reimplement 'reconfigure’.

breaks guix system reconfigure. In particular, after reconfiguring,
shepherd doesn’t know about the updated versions of services.

The usual output below is missing; after reverting the commit it’s
fine again.

guix system: loading new services: …
To complete the upgrade, run 'herd restart SERVICE' to stop,
upgrade, and restart each service that was not automatically restarted.
shepherd: Evaluating user expression (let* ((services (map primitive-load (?))) 
# ?) ?).
shepherd: Service user-homes has been started.
shepherd: Service term-auto could not be started.
bootloader successfully installed on '/dev/sda’

I see that some system tests for “guix system reconfigure” were added
after this change. Might I suggest adding them before the change next
time around, and making sure they pass both before and after?

Cheers
Robert

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

[Robert Vollmert]

What I see:

1. edit ~/pzprnode/pzprnode

rob@garp ~/pzprnode$ git diff
diff --git a/pzprnode b/pzprnode
index 612e6a8..d8ef0ea 100755
--- a/pzprnode
+++ b/pzprnode
@@ -190,5 +190,6 @@ const server = http.createServer((req, res) => {
 });
 
 server.listen(port, hostname, () => {
+   console.log("updated version");
console.log(`Server running at http://${hostname}:${port}/`);
 });

2. sudo guix system reconfigure -L ~/garp-config ~/garp-config/config.scm
3. sudo herd restart pzprnode
4. less /var/log/messages

Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been stopped. 
Jul 30 11:46:57 localhost shepherd[1]: Service pzprnode has been started. 
Jul 30 11:46:58 localhost pzprnode[4954]: updated version 
Jul 30 11:46:58 localhost pzprnode[4954]: Server running at 
http://127.0.0.1:3456/ 

5. sudo guix system list-generations

Generation 151  Jul 30 2019 10:37:06
  file name: /var/guix/profiles/system-151-link
  canonical file name: /gnu/store/jis33accsfpa068aps0a9mrycmjzfm4m-system
  label: GNU with Linux-Libre 5.2.1
  bootloader: grub
  root device: label: "guix-root"
  kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage
Generation 152  Jul 30 2019 11:43:13(current)
  file name: /var/guix/profiles/system-152-link
  canonical file name: /gnu/store/3z3wmaj0399kihqc372y91nzcjxc1myl-system
  label: GNU with Linux-Libre 5.2.1
  bootloader: grub
  root device: label: "guix-root"
  kernel: /gnu/store/fp6wsvn10h1is0wkz8l2sbzjmjbzi7vr-linux-libre-5.2.1/bzImage

6. sudo guix system switch-generation 151

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv
building /gnu/store/qvxbl3gm6406dbbkm8jigmpc8zi42lfw-grub.cfg.drv...
switched from generation 152 to 151

7. sudo herd restart pzprnode
8. less /var/log/messages

Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been stopped. 
Jul 30 11:48:02 localhost shepherd[1]: Service pzprnode has been started. 
Jul 30 11:48:03 localhost pzprnode[4994]: updated version 
Jul 30 11:48:03 localhost pzprnode[4994]: Server running at 
http://127.0.0.1:3456/ 

The line with “updated version” should not be there.

Presumably, this is due to switch-generations not calling 
upgrade-shepherd-services.

bug#36838: mcron leaves zombies around

[Robert Vollmert]

It seems that mcron doesn’t clean up after itself. I regularly see
some zombie processes around, presumably left over by each of my
two 15-minute cron jobs:

root 21285  0.0  0.3  24124  3248 ?Ss   11:05   0:00 
/gnu/store/mamwayq00mqs85kgs6ibww7xw6dy776s-mcron-1.1.1/bin/mcron 
/gnu/store/rdi71izz4d16v77hb8h2jks0s3q9zini-mcron-job 
/gnu/store/k7dn1v7qpi4kz183glmbgsf1c7pj19xx-mcron-job 
/gnu/store/lfyj23bzhc14y5rqi91g493jql9dphxk-mcron-job 
/gnu/store/mx9k5n92kmhryn3vh4607hrmnkjb8dl6-mcron-job 
/gnu/store/l4nxmajr0i5g07fxvrgnaw29zd1jq0qw-mcron-job
root 26611  0.0  0.0  0 0 ?Z17:29   0:00 [mcron] 

root 26612  0.0  0.0  0 0 ?Z17:29   0:00 [mcron] 


In case that matters, they’re defined using the following:

(define puzzledb-tweets-pzv-job
  (let* ((exp
  (with-imported-modules '((helpers))
#~(begin
(use-modules (helpers))
(let ((backend (read-secret "tools.jwt"))
  (twitter (read-secret "twitter.token")))
  (runl (string-append #$puzzledb-tools "/bin/tweets")
"-backend_token" backend
"-token" twitter
"-deletes")
 (script (program-file "puzzledb-tweets-pzv-job" exp)))
#~(job "*/15 * * * *" ; every fifteen minutes
   #$script)))

where the module helpers contains:

(define-module (helpers)
  #:use-module (ice-9 textual-ports)
  #:export (runl read-secret))

(define* (runl prog . args)
  (apply execl prog prog args))

(define* (read-secret file)
  (string-trim-both
(get-string-all
  (open-input-file
(string-append "/etc/puzzledb/secrets/" file)

bug#36772: feature request: checked variant of "substitute*"

[Robert Vollmert]

> On 23. Jul 2019, at 15:35, Ricardo Wurmus  wrote:
> 
> 
> Hi Robert,
> 
>> I think it would be great to have the following variant of substitute*:
>> 
>> (substitute*-once filename (pattern vars) body)
>> 
>> which acts like the usual substitute-*, except it also asserts that the
>> substitution applies to exactly one line in the file, causing a build
>> failure otherwise.
> 
> I agree that the effect of substitute* should be checked.  I think
> substitute* should fail when one of its clauses failed to match
> anything.
> 
> Each clause could also accept an optional argument to make them only
> match one location.  We wouldn’t have to duplicate the macro for that
> and it’s a simple extension to failing on zero matches.
> 
> What do you think?

That sounds like a good improvement, too. I think the important part is
ensuring the substitution matches at all, maybe we could leave out the
“at most once” part. (I doubt it would be used a lot if it’s not the default.)

Cheers
Robert

bug#36772: feature request: checked variant of "substitute*"

[Robert Vollmert]

I think it would be great to have the following variant of substitute*:

(substitute*-once filename (pattern vars) body)

which acts like the usual substitute-*, except it also asserts that the
substitution applies to exactly one line in the file, causing a build
failure otherwise.

In the cases where this is sufficient (I believe most), it would make
substitution work quite a bit more reliably, making it both easier to
debug substitution when first packaging, and noticing more easily when
they need to be adapted on upgrades.

(It would be possible to make the signature a bit more flexible and to
allow multiple files or patterns as in substitute*, but that would
make the meaning of “applies exactly once” a bit unclear, so I’d prefer
to not do that. Similarly, I find it cleaner to potentially call
substitute*-once several times in a row with different substitutions to
make the ordering of effects explicit.)

(I’d be happy to supply a patch myself eventually, but the syntax rule
business is a bit out of reach at this point.)

bug#24076: gnupg [-agent]: when signing [commits], it claims that there is no pinentry - but there is

[Robert Vollmert]

Just to note that this is still a problem. I just installed
gnupg (via guix install gnupg), and gpg --generate-keys fails
due to missing pinentry. I had to find this bug report to
work around this.

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

> On 20. Jul 2019, at 15:47, Ludovic Courtès  wrote:
> 
> Hi Mark,
> 
> Mark H Weaver  skribis:
> 
>> Ludovic Courtès  wrote:
>> 
>>> Robert Vollmert  skribis:
> 
> [...]
> 
>>>> Great find! Indeed, lspci lists
>>>> 
>>>> 00:02.0 VGA compatible controller: Cirrus Logic GD 5446
>>>> 
>>>> Is this something that could be fixed by including a driver for that
>>>> card in the kernel?
>>> 
>>> I suppose so.
>>> 
>>> Mark, WDYT about adding support for Cirrus VGA cards to the kernel?
>>> What would it take to do so?
>> 
>> I know of two kernel configuration options for Cirrus video cards:
>> 
>>  CONFIG_DRM_CIRRUS_QEMU: Cirrus driver for QEMU emulated device
>>  CONFIG_FB_CIRRUS: Cirrus Logic support
>> 
>> CONFIG_DRM_CIRRUS_QEMU is enabled as a module in all of our
>> configurations except for 5.2-arm-veyron.conf.  CONFIG_FB_CIRRUS is
>> enabled as a module in all of our x86_64 and i686 configurations.
>> 
>> Is there something else I've overlooked?
> 
> Oh, I see.
> 
> Robert and Björn, could you check if adding the ‘cirrus’ and possibly
> the ‘cirrusfb’ module(s) to ‘initrd-modules’ in the image you run at
> your VPS solves the issue?

It would need to be added to the installer. Is there a way to add it
via grub command line? Alternatively, is there a way to test this from
a regular guix system console?

(I’m not sure to what extent I’ll be able to do that — my VPS is now
serving “important” things. Note that the bug is reproducible on QEMU
by passing “-vga cirrus”.)

bug#36731: shepherd lost track of nginx

[Robert Vollmert]

> On 20. Jul 2019, at 00:49, Ludovic Courtès  wrote:
> 
> Hello,
> 
> Robert Vollmert  skribis:
> 
>> Not sure who’s at fault here, but without doing anything weird,
>> I ended up with a system where shepherd thought that nginx was
>> stopped, while there was still an nginx process around. I
>> certainly didn’t start it by hand.
> 
> Did you try “herd status nginx” to see shepherd’s notion of the nginx
> process?

Not at the time, no.

> 
>> The result was this:
>> 
>> $ sudo herd restart nginx
>> Service nginx is not running.
>> herd: exception caught while executing 'start' on service 'nginx':
>> Throw to key `srfi-34' with args `("#> \"/gnu/store/mlg0xfbiq03s812rm3v7mrlhyngas4xp-nginx-1.17.1/sbin/nginx\" 
>> arguments: (\"-c\" 
>> \"/gnu/store/r6gl9n7pwf4npiri05qxr40vdihdm2yy-nginx.conf\" \"-p\" 
>> \"/var/run/nginx\") exit-status: 1 term-signal: #f stop-signal: #f] 
>> 147e000>")’.
> 
> Do you use an “opaque” nginx config file, or do you use 
> records?

The latter I think:

 (service nginx-service-type
  (nginx-configuration
   (extra-content “…”)))

bug#36731: shepherd lost track of nginx

[Robert Vollmert]

Not sure who’s at fault here, but without doing anything weird,
I ended up with a system where shepherd thought that nginx was
stopped, while there was still an nginx process around. I
certainly didn’t start it by hand.

The result was this:

$ sudo herd restart nginx
Service nginx is not running.
herd: exception caught while executing 'start' on service 'nginx':
Throw to key `srfi-34' with args `("#")’.

That error message could also be clearer about what’s going on. At any
rate, after I killed the nginx process, “herd start nginx” worked fine.

I should add that nginx was still doing its job fine before I killed it.

bug#36380: related article (Debian)

[Robert Vollmert]

Just ran across this article about Debian dealing with similar issues.

https://daniel-lange.com/archives/152-hello-buster.html

One of the suggested work-arounds is to rely on virtio_rng on
virtual machines, but it seems Guix already uses that on my machine,
so perhaps it doesn’t help:

rob@garp ~$ cat /sys/devices/virtual/misc/hw_random/rng_available 
virtio_rng.0 
rob@garp ~$ cat /sys/devices/virtual/misc/hw_random/rng_current 
virtio_rng.0

bug#36084: not really fixed?

[Robert Vollmert]

It seems the two clock packages are still subtly different, apparently
due to the tested variant pulling in a dependency on the test libraries.

Compare https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36705.

Configuring tasty-hspec-1.1.5.1...
Warning:
This package indirectly depends on multiple versions of the same package. 
This is very likely to cause a compile failure.
  package hspec-core (hspec-core-2.5.5-H06vLnMfEeIEsZFdji6h0O) requires 
clock-0.7.2-9qwmBbNbGzEOSffjlyarp
  package tasty (tasty-1.1.0.3-I8Vu9v0lHj8Jlg3jpKXavp) requires 
clock-0.7.2-Cf9UTsaN2AjEpBnoMpmgkU

It’s possible that this warning is really just a warning, and that there’s
no real problem here because the packages are really the same, but… I
don’t like it.

bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken

[Robert Vollmert]

> On 16. Jul 2019, at 17:08, Timothy Sample  wrote:
> 
> Hi Robert,
> 
> After looking at this and your patch at ,
> I’m wondering if it works as long as we make sure the versions match.
> Can we just inherit the current “ghc-clock”, disable its tests, and call
> it “ghc-clock-bootstrap”?  Is the Cabal consistency checking too clever
> for that?
> 
> If that doesn’t work, can you explain why the method you proposed above
> doesn‘t work?  It seems a little simpler than your patch.  In fact,
> maybe we could live with the main “ghc-tasty” package being built
> without “ghc-clock” (via the flag you mentioned).

I tried the direct approach again, and this time it worked. Posted an
updated patch.

I believe this should be fine, since GHCs builds should be deterministic.

Cheers
Robert

bug#36690: guix import hackage fails on key:value

[Robert Vollmert]

Apparently, it’s valid for a cabal file to have key-value pairs
without a space, e.g.

benchmark benchmarks
  type: exitcode-stdio-1.0
  main-is:Speed.hs
  hs-source-dirs:test
  default-language: Haskell2010
  build-depends:
base < 5,
criterion,
diagrams-core,
diagrams-lib

from http://hackage.haskell.org/package/diagrams-lib-1.4.2.3/revision/2.cabal

guix import hackage breaks on this:

$ guix import hackage diagrams-lib
Importing `diagrams-lib` from hackage
Syntax error: unexpected token : main-is:Speed.hs (at line 175, column 2)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package 'diagrams-lib'

bug#36640: guix pull compile-files failure doesn't identify failed file

[Robert Vollmert]

Specifically, building guix-packages.drv locally, I got the output below.
As far as I can tell, the problematic file’s name is not contained in the
output at all. The file is certainly available where we call compile-file
— no idea whether it would be better to print the filename while handling
the exception in. guix/build/compile.scm, or whether guile should print
a better error here.

[ snip progress output ]

 29.1% of 203 files^M[ 60/406] loading...29.6% of 203 files^M[ 61/406] 
loading...30.0% of 203 files^M[ 62/406] loading...30.5% of 203 
files^M[ 63/406] loading...31.0% of 203 files^M[ 64/406] loading... 
   31.5% of 203 files^M[ 65/406] loading...32.0% of 203 files^M[ 
66/406] loading...32.5% of 203 files^M[ 67/406] loading...33.0% 
of 203 files^M[ 68/406] loading...33.5% of 203 files^M[ 69/406] 
loading...34.0% of 203 files^M[ 70/406] loading...34.5% of 203 
files^M[ 71/406] loading...35.0% of 203 files^M[ 72/406] loading... 
   35.5% of 203 files^M[ 73/406] loading...36.0% of 203 files^M[ 
74/406] loading...36.5% of 203 filesBacktrace:
In ice-9/psyntax.scm:
  1235:36 19 (expand-top-sequence _ _ _ #f _ _ _)
  1182:24 18 (parse _ (("placeholder" placeholder)) ((top) #(ribcage () () ())) 
_ e (eval) (hygiene #{ g670}#))
   285:10 17 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) (hygiene 
#{ g670}#))
In ice-9/eval.scm:
   293:34 16 (_ #)
In ice-9/boot-9.scm:
   2874:4 15 (define-module* _ #:filename _ #:pure _ #:version _ #:imports _ 
#:exports _ #:replacements _ #:re-exports _ #:autoloads _ #:duplicates _ 
#:transformer _)
  2071:24 14 (call-with-deferred-observers _)
  2887:24 13 (_)
   222:17 12 (map1 (((gnu)) ((guix)) ((guix git-download)) ((guix build-system 
haskell)) ((guix build-system elm)) ((guix licenses)) ((guix licenses) #:prefix 
license:) ((guix packages)) ((# ?)) ?))
  2800:17 11 (resolve-interface (gnu) #:select _ #:hide _ #:prefix _ #:renamer 
_ #:version _)
In ice-9/threads.scm:
390:8 10 (_ _)
In ice-9/boot-9.scm:
  2726:13  9 (_)
In ice-9/threads.scm:
390:8  8 (_ _)
In ice-9/boot-9.scm:
  2994:20  7 (_)
   2312:4  6 (save-module-excursion _)
  3014:26  5 (_)
In unknown file:
   4 (primitive-load-path "gnu" #)
In ice-9/boot-9.scm:
   260:13  3 (for-each # ((gnu 
system) (gnu system mapped-devices) (gnu system file-systems) (gnu bootloader) 
(gnu bootloader grub) (gnu system #) ?))
In ice-9/eval.scm:
159:9  2 (_ #(#(# #) (gnu 
system)))
In ice-9/boot-9.scm:
   2803:6  1 (resolve-interface _ #:select _ #:hide _ #:prefix _ #:renamer _ 
#:version _)
In unknown file:
   0 (scm-error misc-error #f "~A ~S" ("no code for module" (gnu 
system)) #f)

ERROR: In procedure scm-error:
no code for module (gnu system)

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

[Robert Vollmert]

> On 9. Jul 2019, at 17:45, Robert Vollmert  wrote:
> 
> I’ve applied your patch and am testing it now. At first glance it doesn’t
> improve the situation, compare the output below of running `guix build -L .`
> similar to before, after having edited check.scm.

Things do seem to work stably with the patch, although I still don’t see an
improvement. I do repeatedly get the following warnings now, though they don’t
seem to break things:

[ 75%] GUILEC   guix/build/elm-build-system.go
warning: unknown warning type `shadowed-toplevel'
[ 88%] GUILEC   guix/import/elm.go
warning: unknown warning type `shadowed-toplevel'
[100%] GUILEC   guix/config.go
warning: unknown warning type `shadowed-toplevel'

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

[Robert Vollmert]

One further data-point, not immediately related to the recompile spam,
but to the proposed work-around when working within the guix repository:

The suggestion was that the default workflow should be to compile the
scheme files using `make`. That does avoid the recompile spam, but:

- adding a scheme file requires going through
  1. edit Makefile.am
  2. call bootstrap
  3. call configure, remembering the mystery localstatedir argument
  4. call make, waiting through documentation and nix-daemon compiles

- I get random mysterious documentation builds throughout. E.g. just now:

$ make
make  all-recursive
make[1]: Entering directory '/home/rob/guix'
Making all in po/guix
make[2]: Entering directory '/home/rob/guix/po/guix'
make[2]: Leaving directory '/home/rob/guix/po/guix'
Making all in po/packages
make[2]: Entering directory '/home/rob/guix/po/packages'
make[2]: Leaving directory '/home/rob/guix/po/packages'
make[2]: Entering directory '/home/rob/guix'
Updating ./doc/version.texi
Updating ./doc/version-de.texi
Updating ./doc/version-es.texi
Updating ./doc/version-fr.texi
Updating ./doc/version-ru.texi
Updating ./doc/version-zh_CN.texi
  CXX  nix/nix-daemon/guix_daemon-nix-daemon.o
[…]
  CXXLDguix-daemon
  GEN  scripts/guix
Compiling Scheme modules...
[ 12%] LOAD guix/build-system/elm.scm
;;; note: source file ./guix/config.scm
;;;   newer than compiled /home/rob/guix/guix/config.go
;;; note: source file ./guix/config.scm
;;;   newer than compiled /home/rob/guix/guix/config.go
[ 25%] LOAD guix/build/elm-build-system.scm
guix/build/elm-build-system.scm:127:1: missing closing parenthesis

## call make again with no edits

$ make
make  all-recursive
make[1]: Entering directory '/home/rob/guix'
Making all in po/guix
make[2]: Entering directory '/home/rob/guix/po/guix'
make[2]: Leaving directory '/home/rob/guix/po/guix'
Making all in po/packages
make[2]: Entering directory '/home/rob/guix/po/packages'
make[2]: Leaving directory '/home/rob/guix/po/packages'
make[2]: Entering directory '/home/rob/guix'
  MAKEINFO doc/guix.info
  MAKEINFO doc/guix.de.info
  MAKEINFO doc/guix.es.info
  MAKEINFO doc/guix.fr.info
  MAKEINFO doc/guix.ru.info
./doc/guix.ru.texi:913: warning: accent command `@,' must not be followed by 
whitespace
Wide character in warn at 
/gnu/store/yrgwwr35l01qvnlqgr6d4wbwky3b1d74-profile/bin/makeinfo line 720.
./doc/guix.ru.texi:3881: warning: `.' or `,' must follow @xref, not д
  MAKEINFO doc/guix.zh_CN.info
Compiling Scheme modules...
[ 12%] LOAD guix/build-system/elm.scm
;;; note: source file ./guix/config.scm
;;;   newer than compiled /home/rob/guix/guix/config.go
;;; note: source file ./guix/config.scm
;;;   newer than compiled /home/rob/guix/guix/config.go
[ 25%] LOAD guix/build/elm-build-system.scm
guix/build/elm-build-system.scm:127:1: missing closing parenthesis

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


Let me know if these should be considered separate bugs worth filing.

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

[Robert Vollmert]

Hi Ludo’,

thanks for looking into this!

On 9. Jul 2019, at 00:15, Ludovic Courtès  wrote:
> Robert Vollmert  skribis:
>> Here’s another example, while working on a local checkout of a channel.
>> Calling `guild compile` just makes things worse.
>> 
>> $ rm -rf ~/.cache/guile
>> $ guix build -L . -L ../guix-postgrest puzzledb-frontend
>> ;;; note: source file ../guix-postgrest/bytestring.scm
>> ;;;   newer than compiled 
>> /gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/bytestring.go
>> ;;; note: source file ../guix-postgrest/check.scm
>> ;;;   newer than compiled 
>> /gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/check.go
> 
> That’s bad (it’s even worse than having to type ‘make’ in the
> development environment IMO because it’s a “user-facing” interface.)
> 
> How about the patch below?  That turns on auto-compilation, which is
> probably a good thing in this context; as a side-effect, messages like
> those above should disappear.
> 
> The only downside is ABI breakage: if we change the ABI of the 
> record type (which is quite rare), then your channel code will no longer
> run; you’ll get a message like:
> 
>  ": record ABI mismatch; recompilation needed"
> 
> and you’ll have to “rm -rf ~/.cache/guile”.
> 
> Actually we could probably catch ‘record-abi-mismatch-error’ and
> auto-compile when that happens.


I’ve applied your patch and am testing it now. At first glance it doesn’t
improve the situation, compare the output below of running `guix build -L .`
similar to before, after having edited check.scm.

$ guix build -L . postgrest
;;; note: source file ./bytestring.scm
;;;   newer than compiled 
/gnu/store/v5a8qdcpp32ymfdasfql6n0g13zjkrb9-postgrest/lib/guile/2.2/site-ccache/bytestring.go
;;; found fresh local cache at 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix-postgrest/bytestring.scm.go
;;; note: source file ./check.scm
;;;   newer than compiled 
/gnu/store/v5a8qdcpp32ymfdasfql6n0g13zjkrb9-postgrest/lib/guile/2.2/site-ccache/check.go
;;; note: source file ./check.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix-postgrest/check.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling ./check.scm
;;; note: source file ./control.scm
;;;   newer than compiled 
/gnu/store/v5a8qdcpp32ymfdasfql6n0g13zjkrb9-postgrest/lib/guile/2.2/site-ccache/control.go
;;; found fresh local cache at 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix-postgrest/control.scm.go
;;; note: source file ./text.scm
[…]

Cheers
Robert

bug#36547: expect an earlier/clearer error when trying to splice(?) a function into a gexp

[Robert Vollmert]

I tried to use a function in a gexp along the lines of

(define* (f x) …)

#~(begin
 (#$f x)
 …)

This resulted in the following error:

ERROR: In procedure primitive-load:
In procedure scm_lreadr: 
/gnu/store/wcw0fii855axkiqfz05283rwl7nlrb3i-puzzledb-blogs-job-builder:1:254: 
Unknown # object: #\<

where the referenced builder file contains

… (let ((backend (# "tools.token"))) …

It seems to me that whatever code writes the builder file should already 
complain at the point
where it substitutes # — is that possible?

bug#36546: herd restart mcron appears to wipe /var/log/mcron.log

[Robert Vollmert]

It appears that old mcron log output is lost when the service is
restarted. That’s not good.

See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36510 for
another issue related to mcron logging.

bug#36430: mcron would benefit from a better way to test jobs

[Robert Vollmert]

One related issue that I just ran into, while trying out the gexp approach:

mcron jobs take an optional third naming argument, which are again better
not used because they replace the store filename in the “schedule”
output.

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

[Robert Vollmert]

> On 8. Jul 2019, at 12:03, Ludovic Courtès  wrote:
> 
> Robert Vollmert  skribis:
> 
>>> On 5. Jul 2019, at 22:40, Ludovic Courtès  wrote:
>>> 
>>> Hi,
>>> 
>>> Robert Vollmert  skribis:
>>> 
>>>> rob@garp ~/guix$ nano gnu/packages/haskell.scm 
>>>> rob@garp ~/guix$ ./pre-inst-env guix build ghc-ansi-wl-pprint
>>> 
>>> I’d suggest running “make” once you’ve edited a file.
>>> 
>>> It’s not strictly necessary (Guile then simply evaluates code instead of
>>> running compiled code), but it will allow you to get rid of these
>>> warnings, the compiler might warn you ahead of time of possible
>>> mistakes, and the whole thing will be slightly faster.
>>> 
>>> Does that make sense?
>> 
>> It does make sense. However once again my complaint is a bit more about the
>> developer experience than how to work around the current state. I feel that
>> a situation where the obvious thing works but is painful (guile debug spam,
>> slowness) and you need to learn to do things differently (always run make 
>> first,
>> which frequently causes work you don’t even care about, such as a guix-daemon
>> recompile or po-file work) could be improved upon.
> 
> Yes I agree.  Things to have to be compiled at one point though.  We
> could let Guile auto-compile code, but unfortunately that comes with its
> own warts: the equivalent of “make clean-go”, for instance when an ABI
> incompatibility pops up, is “rm -rf ~/.cache/guile/ccache”, and that too
> is something a developer has too learn, and one could argue that it’s
> less familiar than “make” or “make clean.”
> 
> So, I’m not satisfied with the ./pre-inst-env and ‘make’ workflow, but
> we have yet to come up with a concrete proposal for a better workflow.
> 
>> Concretely, this bug report is in response to
>> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg9.html
>> 
>> In that spirit, “you should run make first” is not answer I’m completely
>> happy with. :)
> 
> I was trying to address the “I see recompilation messages” issue that
> you raised in the current framework.  I didn’t initially interpret the
> bug report as a call for a new workflow.

It’s not meant to be a call for a new workflow, either. The original
suggestion from the “beyond 1.0” thread was a request for a focus on
the developer experience by working on the quality of error messages and
command output. One of the instances where that applies is with respect
to guile recompile scam, as I remarked there.

This bug report specifically is in response to this part of the exchange:

>> — currently it’s very easy to miss the
>> actual cause of an error between a lot of noise, e.g. all those “recompiling
>> scheme module” messages

> When do you see “recompiling” messages?
>
> It looks like a bug we could address soonish, not a long-term task.  :-)

As a concrete proposal, I’d be perfectly happy if, instead of printing
a screen full of guile recompile notifications, I’d get a clear warning
that I should run make instead.


Here’s another example, while working on a local checkout of a channel.
Calling `guild compile` just makes things worse.

$ rm -rf ~/.cache/guile
$ guix build -L . -L ../guix-postgrest puzzledb-frontend
;;; note: source file ../guix-postgrest/bytestring.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/bytestring.go
;;; note: source file ../guix-postgrest/check.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/check.go
;;; note: source file ../guix-postgrest/control.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/control.go
;;; note: source file ../guix-postgrest/text.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/text.go
;;; note: source file ../guix-postgrest/data.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/data.go
;;; note: source file ../guix-postgrest/more-data.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/more-data.go
;;; note: source file ../guix-postgrest/containers.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/containers.go
;;; note: source file ../guix-postgrest/core.scm
;;;   newer than compiled 
/gnu/store/sk1j6fkh855cm6ypp6799pgf8wvnlk76-postgrest/lib/guile/2.2/site-ccache/core.go
;;; note: source file ../guix-postgrest/postgrest-deps.scm
;;;   newer than compiled 
/g

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

[Robert Vollmert]

> On 5. Jul 2019, at 22:40, Ludovic Courtès  wrote:
> 
> Hi,
> 
> Robert Vollmert  skribis:
> 
>> rob@garp ~/guix$ nano gnu/packages/haskell.scm 
>> rob@garp ~/guix$ ./pre-inst-env guix build ghc-ansi-wl-pprint
> 
> I’d suggest running “make” once you’ve edited a file.
> 
> It’s not strictly necessary (Guile then simply evaluates code instead of
> running compiled code), but it will allow you to get rid of these
> warnings, the compiler might warn you ahead of time of possible
> mistakes, and the whole thing will be slightly faster.
> 
> Does that make sense?

It does make sense. However once again my complaint is a bit more about the
developer experience than how to work around the current state. I feel that
a situation where the obvious thing works but is painful (guile debug spam,
slowness) and you need to learn to do things differently (always run make first,
which frequently causes work you don’t even care about, such as a guix-daemon
recompile or po-file work) could be improved upon.

Concretely, this bug report is in response to
https://lists.gnu.org/archive/html/guix-devel/2019-07/msg9.html

In that spirit, “you should run make first” is not answer I’m completely
happy with. :)

Cheers
Robert

bug#36430: mcron would benefit from a better way to test jobs

[Robert Vollmert]

> On 7. Jul 2019, at 16:24, Ludovic Courtès  wrote:
> 
> Hi Robert,
> 
> Robert Vollmert  skribis:
> 
>> Defined a mcron job in config.scm scheduled to run once a day,
>> with a scheme expression. How do I test this?
>> 
>> herd schedule mcron lists the job as merely a “Lambda expression”.
>> I learned how to give it a descriptive name, but still there’s
>> no script linked that I can run by hand.
> 
> Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
> in a simple way so we see an actual command rather than “Lambda
> expression”.  I would recommend using this style to improve
> transparency.

I understand that passing an executable works better. But that also
loses the feature of allowing to write a script in place advertised by
the lambda variant.

I find that kind of “feature that doesn’t actually work” to be quite
painful.

A way to get the best of both worlds (within guix) would be to use
program-file / gexp, so maybe that’s what should be advertised in the
guix manual?


>> One major improvement would be to have:
>> 
>> 1. `herd schedule mcron` lists jobs with some kind of id
>> 2. `herd execute mcron ` runs the specific mcron job
>> 
>> Or perhaps, any mcron job could be turned into a simple argument-less
>> guile or shell script that’s shown in the schedule listing?
> 
> The commit I’m referring to above does exactly that.
> 
> Perhaps as a first step we could recommend this style more prominently
> in the manual?

I’ll see if I can get the gexp variant to work, and would provide
a manual patch if successful.

> Further improvements should probably go into mcron itself.  It’s a
> rather small and simple code base, so if you were looking for a
> rewarding hacking session for the week-end, it’s probably a good
> candidate.  ;-)

At this stage, there’s just too many small hacking sessions required
all over the place :). I’ll stick with filing bug reports for the
clear pain points if that’s ok?

Robert

bug#36510: confusing mcron logging

[Robert Vollmert]

> On 5. Jul 2019, at 22:37, Ludovic Courtès  wrote:
> Something that can help debugging to some extent (but is definitely no
> substitute for what you suggest above!) is ‘sudo herd schedule mcron’.
> I use that to manually run jobs that appear not to work as expected.

That only works for non-guile jobs though as far as I understand, where
'herd schedule mcron' prints a store path.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36430

bug#36511: extraneous recompiles of scm files while editing gnu/packages/

[Robert Vollmert]

I’ve just been working on a local guix clone, tried building a package
which failed, but not after lots of the usual “newer than compiled”
messages, but fine, I pulled a while earlier and hadn’t rebuilt. But then,
after editing just a few lines in a single file (gnu/packages/haskell.scm),
the following happened, which seems wrong:

rob@garp ~/guix$ nano gnu/packages/haskell.scm 
rob@garp ~/guix$ ./pre-inst-env guix build ghc-ansi-wl-pprint
;;; note: source file /home/rob/guix/guix/ui.scm
;;;   newer than compiled /home/rob/guix/guix/ui.go
;;; note: source file /home/rob/guix/guix/ui.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/ui.go
;;; note: source file /home/rob/guix/guix/store.scm
;;;   newer than compiled /home/rob/guix/guix/store.go
;;; note: source file /home/rob/guix/guix/store.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/store.go
;;; note: source file /home/rob/guix/guix/store.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/guix/store.scm.go
;;; note: source file /home/rob/guix/guix/build/syscalls.scm
;;;   newer than compiled /home/rob/guix/guix/build/syscalls.go
;;; note: source file /home/rob/guix/guix/build/syscalls.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/build/syscalls.go
;;; note: source file /home/rob/guix/guix/build/syscalls.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/guix/build/syscalls.scm.go
;;; note: source file /home/rob/guix/guix/derivations.scm
;;;   newer than compiled /home/rob/guix/guix/derivations.go
;;; note: source file /home/rob/guix/guix/derivations.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/derivations.go
;;; note: source file /home/rob/guix/guix/derivations.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/guix/derivations.scm.go
;;; note: source file /home/rob/guix/guix/grafts.scm
;;;   newer than compiled /home/rob/guix/guix/grafts.go
;;; note: source file /home/rob/guix/guix/grafts.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/grafts.go
;;; note: source file /home/rob/guix/guix/grafts.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/guix/grafts.scm.go
;;; note: source file /home/rob/guix/guix/profiles.scm
;;;   newer than compiled /home/rob/guix/guix/profiles.go
;;; note: source file /home/rob/guix/guix/profiles.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/profiles.go
;;; note: source file /home/rob/guix/guix/build/download.scm
;;;   newer than compiled /home/rob/guix/guix/build/download.go
;;; note: source file /home/rob/guix/guix/build/download.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/build/download.go
;;; note: source file /home/rob/guix/guix/build/download.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/guix/build/download.scm.go
;;; note: source file /home/rob/guix/gnu/packages.scm
;;;   newer than compiled /home/rob/guix/gnu/packages.go
;;; note: source file /home/rob/guix/gnu/packages.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages.go
;;; note: source file /home/rob/guix/guix/download.scm
;;;   newer than compiled /home/rob/guix/guix/download.go
;;; note: source file /home/rob/guix/guix/download.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/download.go
;;; note: source file /home/rob/guix/guix/download.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/guix/download.scm.go
;;; note: source file /home/rob/guix/gnu/packages/perl.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/perl.go
;;; note: source file /home/rob/guix/gnu/packages/perl.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/perl.go
;;; note: source file /home/rob/guix/gnu/packages/compression.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/compression.go
;;; note: source file /home/rob/guix/gnu/packages/compression.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/compression.go
;;; note: source file /home/rob/guix/gnu/packages/admin.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/admin.go
;;; note: source file /home/rob/guix/gnu/packages/admin.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/admin.go
;;; note: source file /home/rob/guix/guix/build-system/python.scm
;;;   newer than compiled /home/rob/guix/guix/build-system/python.go
;;; note: source file /home/rob/

bug#36510: confusing mcron logging

[Robert Vollmert]

I have two mcron jobs on my system, certbot renewal and
a handwritten and currently buggy guile job. This is an
excerpt from /var/log/mcron.log:

>

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal; no action taken.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Acquiring or renewing certificate: garp.vllmrt.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal; no action taken.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Acquiring or renewing certificate: garp.vllmrt.net
Backtrace:
   9 (apply-smob/1 #)
In ice-9/boot-9.scm:
829:9  8 (catch mcron-error # ?)
In mcron/scripts/mcron.scm:
 99:7  7 (_)
In mcron/base.scm:
   234:12  6 (_ #)
In srfi/srfi-1.scm:
640:9  5 (for-each # (#< user: #(?>))
In mcron/base.scm:
   186:10  4 (run-job #< user: #("root" "x" 0 0 "System adminis?>)
In ice-9/eval.scm:
   293:34  3 (_ #(#(#)))
   182:19  2 (proc #(#(#)))
   142:16  1 (compile-top-call _ (7 . get-string-all) ((10 (# . #) ?)))
In unknown file:
   0 (%resolve-variable (7 . get-string-all) #)

ERROR: In procedure %resolve-variable:
Unbound variable: get-string-all
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal; no action taken.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Acquiring or renewing certificate: garp.vllmrt.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate not yet due for renewal; no action taken.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Acquiring or renewing certificate: garp.vllmrt.net

<

It’s impossible to tell what output is from which job; which jobs succeeded or
didn’t; when they ran.

Suggestions:
- mcron should log the timestamp and a job id of every job when it starts
- mcron should log the timestamp and status and job id of every job when it 
finishes
- job output should be prefixed by some job id

bug#36509: guix pull: too many substitute updates, or bad log messages

[Robert Vollmert]

When running `guix pull`, output like the following is common
for me:

$ guix pull
Updating channel 'puzzlink' from Git repository at '/home/rob/guix-puzzlink'…
[…]
Building from these channels:
  guix  https://github.com/robx/guix.git11f68b3
[…]
Computing Guix derivation for 'x86_64-linux'... |
The following derivations will be built:
   /gnu/store/ym0l8rvnh3aa3qv8g3xgh1mszbhww8c2-elm.drv
[…]
   /gnu/store/dcxwfh37bn8r3h8s9w7wfq8yhzynqxx5-profile.drv
The following profile hooks will be built:
   /gnu/store/biw1n2a956skpaa4m7rmka6j8h1clhmv-guix-package-cache.drv
[…]
   /gnu/store/kxrkynck33ypwyy09ypi2qm7737fsw28-fonts-dir.drv
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/wxfi8mdp11l5k4ngkbsy9apcg9h74jfk-guix-system.drv…

Either guix is making useless extra downloads or:

(a) the substitute log message should be changed to differentiate between
the different calls
(b) there should be extra log messages before the substitute messages to
indicate what guix is doing that causes the individual substitue messages.

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

[Robert Vollmert]

> On 4. Jul 2019, at 09:59, Ludovic Courtès  wrote:
> 
> Hi,
> 
> “Impossible” is an exaggeration, but when you source the
> ‘environment-variables’ file, for example, PWD and other variables will
> refer to /tmp/guix-build-….drv, which won’t exist.  Likewise, generated
> files such as Makefiles would have captured the ….drv name.

But, wait, won’t they refer to /tmp/guix-build-0.drv? So debugging a build
from /tmp/guix-build-1.drv will use a mix of both directories?

> Like Mark writes, it’s not the end of the world: you can simply rename
> /tmp/guix-build-….drv-0 to /tmp/guix-build-….drv.  However, it means
> that things would be inconvenient by default, which doesn’t sound great
> to me.
> 
> WDYT?

I don't particularly care anymore. I think it’s a confusing mess, but for
myself I’ve learnt this wart and won’t run into the problem anymore.

Cheers
Robert

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

[Robert Vollmert]

> On 2. Jul 2019, at 15:37, Ludovic Courtès  wrote:
> 
>> /* In a sandbox, for determinism, always use the same temporary
>>directory. */
>> -tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" 
>> + drvName + "-0" : tmpDir;
>> +tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" 
>> + drvName : tmpDir;
> 
> The result would be that the temporary directory would always have a
> different name inside and outside the container.  Consequently,
> debugging along the lines of what the manual suggests (info "(guix)
> Debugging Build Failures") would become pretty much impossible.

Why do you think it would become impossible?

bug#35863: fixed by patch

[Robert Vollmert]

This was fixed by

commit 3149c002644b927e0245d237cdda3a6aeca00e4a
Author: Robert Vollmert 
Date:   Sun Jun 16 16:18:29 2019 +0200

utils: canonical-newline-port: Fix handling of carriage return at buffer 
end.

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

[Robert Vollmert]

Hi Mark,

> On 30. Jun 2019, at 19:43, Mark H Weaver  wrote:
> 
> retitle 36443 Canonicalized build directory name in container leads to 
> confusion
> thanks
> 
> Hi Robert,
> 
> Robert Vollmert  writes:
>> Thanks for clarifying. Do you have an idea how to make this less confusing?
>> 
>> In my follow-up to the bug report I suggested
>> 
>>> E.g. instead of saying “keeping build directory ” say
>>> “Keeping a copy of the build directory at ”.
>> 
>> But I feel that might be improved upon. “Copied build directory to …”?
>> What do you think?
> 
> The directory is not copied.  It is the same directory, but with a
> different name in the build container's namespace.  You can see this by
> examining the contents of the directory while the build is in progress.
> 
> I agree that it would be good to eliminate this potential source of
> confusion, but it's not yet clear to me how to do it.
> 
> Any other ideas?

I see, thanks for clarifying.

How about dropping the “-0” suffix inside the container? The major part
of my confusion was that the directory “-0” actually existed in /tmp
from a previous failed build; this change might avoid that.

Cheers
Robert

bug#36443: guix build mixes build dirs?

[Robert Vollmert]

> On 30. Jun 2019, at 19:18, Mark H Weaver  wrote:
> 
> Robert Vollmert  writes:
> 
>> So this is pretty bizarre, and I haven’t managed to cut it down
>> to a smaller example yet, but it seems pretty clear that something
>> is broken:
>> 
>> $ guix build -K some-package
>> -> error, referencing /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0
>> note: keeping build directory 
>> `/tmp/guix-build-puzzledb-frontend-20190625-git.drv-0’
>> $ guix build -K some-package
>> -> same error, again referencing 
>> /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0
>> note: keeping build directory 
>> `/tmp/guix-build-puzzledb-frontend-20190625-git.drv-1’
> 
> This is known behavior, and intentional.  The build is done within a
> container, and the directory name within the container is canonicalized.

Thanks for clarifying. Do you have an idea how to make this less confusing?

In my follow-up to the bug report I suggested

> E.g. instead of saying “keeping build directory ” say
> “Keeping a copy of the build directory at ”.

But I feel that might be improved upon. “Copied build directory to …”?
What do you think?

bug#36443: suspicion

[Robert Vollmert]

My suspicion right now is that there’s not any real mixup
happening, but that guix-daemon runs the build in a
different environment in the directory

/tmp/derivation-name.drv-0

which gets copied to

/tmp/derivation-name.drv-5

in the root filesystem by `guix build -K`, if directories
-0, -1, …, -4 already exist. In which case I’d suggest doing
something to the messages and/or documentation to make this
clearer.

E.g. instead of saying “keeping build directory ” say
“keeping a copy of the build directory at ”.

bug#36443: guix build mixes build dirs?

[Robert Vollmert]

So this is pretty bizarre, and I haven’t managed to cut it down
to a smaller example yet, but it seems pretty clear that something
is broken:

$ guix build -K some-package
-> error, referencing /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0
note: keeping build directory 
`/tmp/guix-build-puzzledb-frontend-20190625-git.drv-0’
$ guix build -K some-package
-> same error, again referencing 
/tmp/guix-build-puzzledb-frontend-20190625-git.drv-0
note: keeping build directory 
`/tmp/guix-build-puzzledb-frontend-20190625-git.drv-1’

My concrete packaging setup is a bit more complicated. I’m working with elm, and
faking the build directory as the home directory. The error message mentioned 
above
is

> The binary data at
> /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0/.elm/0.19.0/package/versions.dat
> is corrupt.

Elm caches build artifacts in the following directories:

/tmp/guix-build-puzzledb-frontend-20190625-git.drv-0/.elm
elm-stuff/

while the package definition uses the trivial build system as such:

(arguments
 `(#:modules ((guix build utils) (build-elm) (json parser) (versions))
   #:builder
 (begin
 …
 (setenv "HOME" (getcwd))
 (setenv "HTTP_PROXY" ".”) ; break http access
 (copy-recursively (assoc-ref %build-inputs "source") "src")
 (with-directory-excursion “src"
   …
   (invoke elm "make" "--output=../all.js" "src/All.elm”)))

The path in the error above comes from $HOME — is there a chance that this gets 
saved
somewhere? Other parts of the build script appear to work with the -1 directory 
as
expected.

I’m not at all sure that my package definition is even close to correct, but as 
far
as I can tell, a mix-up as above should be impossible.

bug#36430: mcron would benefit from a better way to test jobs

[Robert Vollmert]

My issue:

Defined a mcron job in config.scm scheduled to run once a day,
with a scheme expression. How do I test this?

herd schedule mcron lists the job as merely a “Lambda expression”.
I learned how to give it a descriptive name, but still there’s
no script linked that I can run by hand.

One major improvement would be to have:

1. `herd schedule mcron` lists jobs with some kind of id
2. `herd execute mcron ` runs the specific mcron job

Or perhaps, any mcron job could be turned into a simple argument-less
guile or shell script that’s shown in the schedule listing?

Thoughts?

bug#36380: service urandom-seed takes too long on boot

[Robert Vollmert]

> On 27. Jun 2019, at 21:03, Leo Famulari  wrote:

> Perhaps, but if the reason for the slowness on their first boot was a
> suboptimal /dev/hwrng source, I would expect it to be equally slow for
> each boot, since we unconditionally read 64 bytes each time.

It’s 512 bytes, not that that should fundamentally change anything.

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

> On 26. Jun 2019, at 22:23, pelzflorian (Florian Pelz) 
>  wrote:
> 
> On Wed, Jun 26, 2019 at 06:51:41PM +0200, Björn Höfling wrote:
>> What's the conclusion? Maybe that Guix is fine and the VNC-clients are
>> also fine. It might just be a matter of configuration or using an older
>> version with bugs?
>> 
> 
> Passing “-vga cirrus” reduces the display size.
> 
> The command “man qemu” says:
> 
> -vga type
>Select type of VGA card to emulate. Valid values for type
>are
> 
>cirrus
>Cirrus Logic GD5446 Video card. All Windows versions
>starting from Windows 95 should recognize and use
>this graphic card. For optimal performances, use 16
>bit color depth in the guest and the host OS.  (This
>card was the default before QEMU 2.2)
> 
> So presumably the VPS is using an old QEMU or passes -vga cirrus.

Great find! Indeed, lspci lists

00:02.0 VGA compatible controller: Cirrus Logic GD 5446

Is this something that could be fixed by including a driver for that
card in the kernel?

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

> On 26. Jun 2019, at 18:51, Björn Höfling  
> wrote:

> In that way, I have the QEMU console in my terminal and I can call the
> "system_reset" command: I suspected that the bug would only appear when
> the VNC-Client is connected WHILE the installer start up. Usually the
> startup would be fast and the VNC-client connects only when the
> installer is already visible.

It seems I can rule that out. I see the bug also when disconnecting directly
after the grub screen and reconnecting after some time. Similarly, the
screen is still messed up when I disconnect and connect again while the
menu is showing.

bug#36388: activation?

[Robert Vollmert]

Could it be that the errors happen in the activation script,
but not when actually starting nginx? I see in the code that
we appear to pass a “-p” flag already when starting nginx;
maybe we should simply do the same when testing the config
during activation?

bug#36389: odd

[Robert Vollmert]

I agree that it sounds odd, and some of my original diagnostic
must be skewed. After several configuration changes and
system reconfigurations and nginx restarts, I do appear to
have a sensible state currently, and I can’t reliably
reproduce the problems I had before. I’m also pretty sure I
didn’t imagine it all, though.


Here’s something else I ran into while getting there:

At some point, nginx was running, even after calling

# herd stop nginx

and herd did list it as stopped. That nginx instance that got
away from shepherd might have been involved in the earlier
trouble. (Is it ok for shepherd to lose track of a child like
that?)

Another thing was that I got a failed nginx configuration test
that didn’t make sense. Notably, it complained that

(a) the user directive `user nginx nginx;` is ineffective when
when not running as root and
(b) it didn’t have permission to access the letsencrypt keys.

Both of these indicate that the configuration test was not run
as root. I don’t see any reason in the code why that would
happen…


I’ll keep an eye on it and see if something similar occurs
again.

bug#30939: still relevant

[Robert Vollmert]

This came up again recently, compare the discussion here:

https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00186.html

Here’s some code to wrap an executable manually to capture its output
and send it to syslog:

(define* (logger-wrapper name exec . args)
  "Return a derivation that builds a script to start a process with
standard output and error redirected to syslog via logger."
  (define exp
#~(begin
(use-modules (ice-9 popen))
(let* ((pid(number->string (getpid)))
   (logger #$(file-append inetutils "/bin/logger"))
   (args   (list "-t" #$name (string-append "--id=" pid)))
   (pipe   (apply open-pipe* OPEN_WRITE logger args)))
  (dup pipe 1)
  (dup pipe 2)
  (execl #$exec #$exec #$@args
  (program-file (string-append name "-logger") exp))

bug#36380: service urandom-seed takes too long on boot

[Robert Vollmert]

> On 26. Jun 2019, at 17:47, Leo Famulari  wrote:
> 
> On Tue, Jun 25, 2019 at 08:12:28PM +0200, Robert Vollmert wrote:
>> On my VPS, booting takes forever (long enough that for a long
>> time I thought the install had failed). I just rebooted again,
>> and it took over 7 minutes, see attached screenshot.
> 
> Yikes, that's way too long. Can you say what VPS it is?

It’s with arpnetworks.com, their default “small" VPS. I don’t
really know more; here’s some dmesg output that might be relevant,
happy to provide more info.

[0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1.1 04/01/2014
[0.00] Hypervisor detected: KVM
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 2a782001, primary cpu clock
[0.00] kvm-clock: using sched offset of 1160634602574609 cycles
[0.02] clocksource: kvm-clock: mask: 0x max_cycles: 
0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.04] tsc: Detected 3066.774 MHz processor

bug#36389: nginx/certbot interaction doesn't work as documented

[Robert Vollmert]

I’ve tried setting up nginx with certbot on guix. Two immediate issues:

- certbot extends the nginx service to serve challenge files. It appears
  that this nginx service extension conflicts (silently) with an independently
  configured nginx service. I.e., I had nginx previously configured, and
  after adding certbot, my previous nginx kept running with the previous
  configuration (even after herd restart nginx), while there was an additional
  nginx config in the gnu store with the certbot-specific fragments. certbot
  activation called nginx to test that fragment, but apparently never started
  nginx (successfully?). There were no errors.

  After removing the stand-alone nginx service and restarting nginx, it started
  with the certbot configuration.

- After this, /var/lib/certbot/renew worked successfully to register a
  certificate, but then failed when calling the nginx deploy hook that I’d
  copied from the guix certbot documentation, because /var/run/nginx/pid
  doesn’t exist. That might be a bug in the nginx package, not sure. I can’t
  find an nginx pid file anywhere, and no other errors related to it either,
  even though the config file includes
pid /var/run/nginx/pid;

bug#36388: nginx startup logging error, at odds with documentation

[Robert Vollmert]

The documentation states:

   At startup, ‘nginx’ has not yet read its configuration file, so it
uses a default file to log error messages.  If it fails to load its
configuration file, that is where error messages are logged.  After the
configuration file is loaded, the default error log file changes as per
configuration.  In our case, startup error messages can be found in
‘/var/run/nginx/logs/error.log’, and after configuration in
‘/var/log/nginx/error.log’.  The second location can be changed with the
LOG-DIRECTORY configuration option.

But I see:

creating nginx log directory '/var/log/nginx'
creating nginx run directory '/var/run/nginx'
creating nginx temp directories 
'/var/run/nginx/{client_body,proxy,fastcgi,uwsgi,scgi}_temp'
nginx: [alert] could not open error log file: open() 
"/gnu/store/byd116qs89b0am4zwjf4vjai7qlskvaw-nginx-1.17.0/logs/error.log" 
failed (2: No such file or directory)

It seems the documentation assumes nginx’s prefix directory is /var/run/nginx
instead of in the store. Some likely ways to improve this would be to pass
`-p /var/run/nginx` or `-g “error_log /var/log/nginx/error.log”` as command
line flags when starting nginx:

$ /gnu/store/byd116qs89b0am4zwjf4vjai7qlskvaw-nginx-1.17.0/sbin/nginx -h
nginx version: nginx/1.17.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:
  -?,-h : this help
  -v: show version and exit
  -V: show version and configure options then exit
  -t: test configuration and exit
  -T: test configuration, dump it and exit
  -q: suppress non-error messages during configuration testing
  -s signal : send signal to a master process: stop, quit, reopen, reload
  -p prefix : set prefix path (default: 
/gnu/store/byd116qs89b0am4zwjf4vjai7qlskvaw-nginx-1.17.0/)
  -c filename   : set configuration file (default: conf/nginx.conf)
  -g directives : set global directives out of configuration file

bug#36380: service urandom-seed takes too long on boot

[Robert Vollmert]

On my VPS, booting takes forever (long enough that for a long
time I thought the install had failed). I just rebooted again,
and it took over 7 minutes, see attached screenshot.

I would suggest skipping the seeding from /dev/hwrng by default
if /var/lib/random-seed is available. I’m assuming here that my
problem is not too rare — if it is, an option to disable the
seeding from /dev/hwrng seems like a good idea.

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

> On 25. Jun 2019, at 17:54, pelzflorian (Florian Pelz) 
>  wrote:
> 
> On Tue, Jun 25, 2019 at 05:06:03PM +0200, Björn Höfling wrote:
>> I guess you (Ludovic) have tried the installer with QEMU and its
>> VNC-Server, maybe even with different VNC-clients?
>> 
> 
> It works with
> 
> qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -drive 
> file=Downloads/guix-system-install-1.0.1.x86_64-linux.iso -vnc :0
> 
> as the VNC server and vinagre as the VNC client.
> 
> Sadly novnc and guacamole clients are not packaged.  I do not know if
> your errors are with the server or the client side.
> 
> Regards,
> Florian

I just gave my VPS another try; it turns out I can connect directly
to their VNC server. Using the macos built in VNC client I have the
same problem as before, so it appears to not be a client side issue.

The connection is titled “QEMU (server-specific-stuff)”, so this is
probably also a QEMU VNC server.

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

Hi,

> On 25. Jun 2019, at 15:59, Ludovic Courtès  wrote:
> 
> Hi,
> 
> Björn Höfling  skribis:
> 
>> On Mon, 3 Jun 2019 11:35:17 +0200
>> Robert Vollmert  wrote:
>> 
>>> There seems to be some conflict between the “graphical” installer’s
>>> idea of the console size and VNC’s (which appears to be noVNC
>>> https://novnc.com/info.html). As you can see in the attached
>>> screenshot, the screen is cropped on all sides, particularly making
>>> the menu choices unviewable.
>> 
>> Today I installed Guix on a Server which uses Guacamole as a web-based
>> VNC-client according to the HTML code, see 
>> https://guacamole.apache.org/
>> 
>> I also had the problem that the screen of the installer was too small,
>> I'm attaching two screenshots: Of the normal GRUB startup and the
>> unreadable installer. 
> 
> I think Robert concluded that the bug was in noVNC.

Rather, I couldn’t prove the bug was anywhere else.

> What we’d need is either something to fix on our side (but there’s
> apparently nothing), or something to report to noVNC, or a workaround we
> could have on our side specifically for this use case.

It seems noVNC isn’t involved here, though, with the only clearly common
factor being Guix, so maybe the bug is there after all? (At least, as
far as I can tell, Guacamole does not involve noVNC.)

Robert

bug#36373: failed copy-file should print path

[Robert Vollmert]

I just ran into this error while trying to build a go package. There’s no
obvious way to figure out which file caused “permission denied”. I’d like
to both see the non-truncated filename in the backtrace, as well as in
the error message below.

Backtrace:
  10 (primitive-load "/gnu/store/zgwm1vv4vb5i91iphzs8wdqwpxr…")
In ice-9/eval.scm:
   191:35  9 (_ _)
In srfi/srfi-1.scm:
   863:16  8 (every1 # …)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/gnu-build-system.scm:
   799:28  7 (_ _)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/go-build-system.scm:
187:8  6 (unpack #:source _ #:import-path _ #:unpack-path _)
In ice-9/ftw.scm:
   452:32  5 (loop _ _ #(2050 670124 16749 19 0 0 0 4096 # 1 # # 8 …) …)
In srfi/srfi-1.scm:
   466:18  4 (fold # …)
In unknown file:
   3 (_ # # …)
In ice-9/ftw.scm:
   482:39  2 (loop _ _ #(2050 1721126 16749 2 0 0 0 4096 # 1 # # 8 …) …)
In 
/gnu/store/zmc0hcmdfg5n4kl32vcla4cg9c9bspfg-module-import/guix/build/utils.scm:
   312:27  1 (_ "/gnu/store/69hmclpsln83ldh9c94c0iygj4ajiyrl-go-x-t…" …)
In unknown file:
   0 (copy-file "/gnu/store/69hmclpsln83ldh9c94c0iygj4ajiyr…" …)

ERROR: In procedure copy-file:
In procedure copy-file: Permission denied

bug#36282: shepherd appears to delete log-file instead of appending

[Robert Vollmert]

This is from reading the shepherd code, not verified by test currently.
Apologies if I’m missing something.

The documentation claims that log-file is appended to:

When @var{log-file} is true, it names the file to which the service's
standard output and standard error are redirected.  @var{log-file} is
created if it does not exist, otherwise it is appended to.

However, in modules/shepherd/service.scm:

   889  (define make-forkexec-constructor
[…]
   923  (lambda args
   924(define (clean-up file)
   925  (when file
   926(catch 'system-error
   927  (lambda ()
   928(delete-file file))
   929  (lambda args
   930(unless (= ENOENT (system-error-errno args))
   931  (apply throw args))
   932  
   933(clean-up pid-file)
   934(clean-up log-file)
   935  
   936(let ((pid (fork+exec-command command

bug#36264: shepherd doesn't capture service stdout/stderr

[Robert Vollmert]

On a pretty fresh Guix System install, I see some regular
sshd error messages on tty1 (which I guess means they’re
written to /dev/console). Also, setting up a regular
shepherd service via make-forkexec-constructor for a
program that logs to stderr (postgrest which I’m in the
process of packaging), all output goes to tty1.

Compare the discussion at

https://lists.gnu.org/archive/html/guix-devel/2019-06/msg00186.html

bug#36248: poor error tracing

[Robert Vollmert]

I’m not sure if this lies more with guile or with guix, but there’s definitely
room for improvment either way.

I was working on https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36084,
haskell-check.scm was changed as follows:

-   ("ghc-clock-bootstrap" ,ghc-clock-bootstrap)
+   ("ghc-clock-bootstrap" ,(@@ (gnu packages haskell) ghc-clock-bootstrap))

In haskell.scm I had a working package definition for ghc-clock-bootstrap,
and added a definition for ghc-clock along these lines:

+(define-public ghc-clock
+  (package
+(inherit ghc-clock-bootstrap)
+(name "ghc-clock")
+;;(version "0.7.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://hackage.haskell.org/package/";
+ "clock/"
+ "clock-" version ".tar.gz"))
+   (sha256
+(base32 "07v91s20halsqjmziqb1sqjp2sjpckl9by7y28aaklwqi2bh2rl8"))
+   (patches
+(search-patches
+ "ghc-clock-disable-library.patch"
+(inputs
+ `(("ghc-tasty" ,ghc-tasty)
+   ("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)))
+(arguments
+ `(#:tests? #t
+

This is broken due to the reference to version, fixed by uncommenting the
version field. The problem is with the error messages:

  guix build ghc-clock

gave pages of warnings, ending with a plain

  guix build: error: ghc-clock: unknown package

Knowing I’d edited haskell.scm and it worked fine before, I ran

  guild compile haskell.scm

which hung.

Finally

  guild compile haskell-check.scm

very subtly pointed me at some issue with version in haskell.scm. Full
output below.


~/guix [env]$ ./pre-inst-env guix build ghc-clock
;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/haskell.go
;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/haskell.go
;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/gnu/packages/haskell.scm.go
;;; note: source file /home/rob/guix/gnu/packages/haskell-check.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/haskell-check.go
;;; note: source file /home/rob/guix/gnu/packages/haskell-check.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/haskell-check.go
guix build: warning: failed to load '(gnu packages abiword)':
In procedure string-append: Wrong type (expecting string): #
guix build: warning: failed to load '(gnu packages android)':
In procedure module-lookup: Unbound variable: googletest
guix build: warning: failed to load '(gnu packages antivirus)':
In procedure module-lookup: Unbound variable: bzip2
guix build: warning: failed to load '(gnu packages avr)':
In procedure module-lookup: Unbound variable: binutils
guix build: warning: failed to load '(gnu packages axoloti)':
In procedure module-lookup: Unbound variable: gcc-4.9
guix build: warning: failed to load '(gnu packages benchmark)':
In procedure module-lookup: Unbound variable: openmpi
guix build: warning: failed to load '(gnu packages bioconductor)':
In procedure module-lookup: Unbound variable: perl-module-build
guix build: warning: failed to load '(gnu packages bootloaders)':
no binding `bc' in module (gnu packages algebra)
guix build: warning: failed to load '(gnu packages chemistry)':
In procedure module-lookup: Unbound variable: python2-numpy
guix build: warning: failed to load '(gnu packages commencement)':
In procedure module-lookup: Unbound variable: gnu-make
guix build: warning: failed to load '(gnu packages debug)':
In procedure module-lookup: Unbound variable: gnu-make
guix build: warning: failed to load '(gnu packages games)':
In procedure module-lookup: Unbound variable: python
guix build: warning: failed to load '(gnu packages image-viewers)':
In procedure module-lookup: Unbound variable: curl
guix build: warning: failed to load '(gnu packages julia)':
In procedure module-lookup: Unbound variable: libuv
guix build: warning: failed to load '(gnu packages kodi)':
In procedure module-lookup: Unbound variable: libdvdnav
guix build: warning: failed to load '(gnu packages license)':
In procedure module-lookup: Unbound variable: perl
guix build: warning: failed to load '(gnu packages make-bootstrap)':
In procedure module-lookup: Unbound variable: coreutils
guix build: warning: failed to load '(gnu packages maven)':
In procedure module-lookup: Unbound variable: java-plexus-container-default
guix build: warning: failed to load '(gnu packages profiling)':
In procedure module-lookup: Unbound variable: openmpi
guix build: warning: failed to load '(gnu packages syndication)':
In procedure module-lookup: Unbound variable: curl
guix build: error: ghc-clock: unknown package

~/guix [env]$ ./pre-inst-env guild compile gnu/packages/haskell.scm 
;;; note: source fi

bug#23961: fixed a while back

[Robert Vollmert]

commit 314b63e0b4372681aec165113ae2a0349eaaa357
Author: Danny Milosavljevic 
Date:   Wed Jul 11 11:02:51 2018 +0200

import: hackage: Support "custom-setup" field.

Fixes .

* guix/import/cabal.scm (make-cabal-parser): Modify.
(is-custom-setup): New variable.
(lex-custom-setup): New procedure.
(is-id): Modify.
(lex-version): Modify.
(): New record type.
(eval-cabal): Modify.
(dependencies): Add parameter.

bug#36240: indent-code.el is not aware of (package (inherit ...)) style

[Robert Vollmert]

When encountering a package definition that starts

  (package (inherit other-package))

etc/indent-code.el will indent the rest of the package body
to align with the start of (inherit. That seems to be a
common idiom, used in roughly half of the instances:

guix/gnu/packages$ git grep '(inherit ' | wc -l
905
guix/gnu/packages$ git grep '(inherit ' | grep package | wc -l
425

bug#36231: haskell-build-system: patches conflict with cabal revisions

[Robert Vollmert]

The cabal revision mechanism replaces the cabal file after any patches
have been applied, making it impossible to patch the cabal file via the
regular patching mechanism.

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

> On 5. Jun 2019, at 23:14, Ludovic Courtès  wrote:
> 
> Robert Vollmert  skribis:
> 
>>> On 5. Jun 2019, at 12:39, Ludovic Courtès  wrote:
>>> 
>>> I’ve never used noVNC, but doesn’t it allow you to zoom out or
>>> something?  The kernel (KMS) knows what it’s doing, so it seems to me
>>> that the problem is that noVNC doesn’t realize what the actual screen
>>> size is.  Does the Internet have something to say wrt. noVNC vs. kmscon?
>> 
>> I don’t seem to get any controls to resize the display; in previous
>> situations it has seemed to switch modes correctly automatically. That
>> said, I’m happy to believe that the bug is with noVNC — I’ve reported
>> it with arpnetworks and will pass it on to noVNC once I know which
>> version is running.
> 
> Alright, let us know how it goes so we can happily close the bug.  :-)

It turns out arpnetworks are running an older forked version of noVNC,
so this might well have been fixed in the meantime. Not solved, but I
don’t intend to pursue this further at this point, will close. At least
it’s on record if it shows up again.

Cheers
Rob

bug#36069: Menu-based installer unusable through noVNC

[Robert Vollmert]

Hello Ludo,

thanks for looking into this.

> On 5. Jun 2019, at 12:39, Ludovic Courtès  wrote:
> 
> I’ve never used noVNC, but doesn’t it allow you to zoom out or
> something?  The kernel (KMS) knows what it’s doing, so it seems to me
> that the problem is that noVNC doesn’t realize what the actual screen
> size is.  Does the Internet have something to say wrt. noVNC vs. kmscon?

I don’t seem to get any controls to resize the display; in previous
situations it has seemed to switch modes correctly automatically. That
said, I’m happy to believe that the bug is with noVNC — I’ve reported
it with arpnetworks and will pass it on to noVNC once I know which
version is running.

> BTW, for your VPS, wouldn’t it be easier to bypass the installation
> altogether?  That is, you write a config that you want to use, you
> create a QCOW2 image or whatever is suitable for your VPS, and you boot
> that directly.

That’s a nice idea; it turns out that this provider does not appear to
give access to the disk images.

Thanks,
Robert

bug#36084: ghc-tasty/ghc-clock circular dependency breaking is broken

[Robert Vollmert]

ghc-tasty depends via “inputs” on ghc-clock-bootstrap (v0.5) which is built 
without tests,
while ghc-clock (v0.7) depends via “native-inputs” on ghc-tasty for tests.

This means that any package which depends on ghc-tasty and ghc-clock is 
potentially broken,
e.g.:

Warning:
This package indirectly depends on multiple versions of the same package. 
This is very likely to cause a compile failure.
  package tasty (tasty-1.1.0.3-98rSghuW4l26JGzzQLN3ha) requires 
clock-0.5.1-KAiVgaxjUlIIuEB7RoOIe6
  package hspec-core (hspec-core-2.5.5-BSfG8Pnx1al9rTpu1j0PaW) requires 
clock-0.7.2-JStwYFlKVmNHl0K1ll1Mx5

I’d suggest breaking the cycle instead by

1. introducing tasty-bootstrap which builds against the `time` module via the 
cabal flags:

flag clock
  description:
Depend on the clock package for more accurate time measurement
  default: True

This could be done via
  (arguments `(#:configure-flags (“—flag=-clock”)))
as far as I understand.

2. changing ghc-clock to test via tasty-bootstrap (and possibly some more 
variant testing
packages that would be changed to depend on tasty-bootstrap)

3. changing tasty to test via ghc-clock.


(I gave this approach a shot myself, but I’m running into mysterious silently 
hanging guild and guix build
processes — possibly some cyclic dependencies which are noticed?)

bug#35942: guix install: environment variable message is very confusing

[Robert Vollmert]

When installing a package that needs an environment variaible to be set for
use, `guix install` prints e.g.:

$ guix install python
...
The following environment variable definitions may be needed:
   export 
PYTHONPATH="/home/rob/.guix-profile/lib/python3.7/site-packages${PYTHONPATH:+:}$PYTHONPATH"

I understand that the variable will be set in a new shell, but not in the 
current shell.
But as it stands, the message serves to confuse even users that are somewhat 
experienced
with unix-like systems.

Suggestion to instead print:

Set the following environment variables to use  right away:
   export 
PYTHONPATH="/home/rob/.guix-profile/lib/python3.7/site-packages${PYTHONPATH:+:}$PYTHONPATH"

bug#35743: applies more widely

[Robert Vollmert]

The problem seems more wide-spread, so should probably be fixed within 
import/cabal.scm.

E.g. warp:

http://hackage.haskell.org/package/warp-3.2.27/warp.cabal
http://hackage.haskell.org/package/streaming-commons-0.2.1.0/streaming-commons.cabal

contain things along the following lines:

benchmark builder-to-bytestring-io
...
build-depends:  base
  , bytestring >= 0.10.2
  , gauge
  , deepseq
  , streaming-commons

  if flag(use-bytestring-builder)
build-depends: bytestring < 0.10.2.0
 , bytestring-builder

This kind of out-dented conditional seems not very rare.

bug#35883: guix import hackage: recursive import fails silently on errors

[Robert Vollmert]

$ guix import hackage not-a-package
guix import: error: failed to download cabal file for package 'not-a-package’
$ echo $?
1
$ guix import hackage -r not-a-package
$ echo $?
0

It might be argued that the error code is fine, since in general it could be
useful for the recursive import to keep going past failures. However it seems
such failures should be logged, and ideally written to standard output in some
form like

(error “import failed: ”)

so they could be found clearly in the generated expression.

bug#35881: guix import hackage: option -r and -s interact poorly

[Robert Vollmert]

Recursive import from a cabal file on standard input doesn’t work,
since imports of dependencies are attempted from standard input.
This typically fails due to EOF.

The sensible behaviour would probably be to only read the initial
package from standard input, and then fall back to hackage.

Alternatively, the options could be made to conflict.

bug#35863: `guix import hackage random` fails due to mysterious CRLF-related trouble

[Robert Vollmert]

$ curl http://hackage.haskell.org/package/random-1.1/random.cabal > random.cabal
$ guix import hackage -s < random.cabal
 (at line 49, column 0)d token : 
Syntax error: unexpected end of input
guix import: error: failed to import cabal file from standard input
$ tr -d '\r'  < random.cabal | guix import hackage -s
(package …)

There’s nothing obviously wrong in the cabal file around line 49. The file seems
to have consistent CRLF line endings and doesn’t seem to have any non-ASCII
characters. (I can see that `canonical-newline-port` might well be buggy around
UTF8.)

bug#25138: updated import error

[Robert Vollmert]

These days it’s:

Syntax error: unexpected token : (buildable (False)) (at line 471, column 4)
Syntax error: unexpected end of input

Relevant cabal extract:

   469  Executable  darcs
   470if !flag(executable)
   471  buildable: False
   472else
   473  buildable: True
   474  

bug#35743: fixed upstream

[Robert Vollmert]

This specific case has been fixed upstream, and should eventually
make it to hackage:

https://github.com/yesodweb/wai/pull/748

The issue does remain in the sense that `guix import` doesn’t parse
some such cabal files that `cabal` is happy with — mark done anyway?

bug#23961: seems to be fixed

[Robert Vollmert]

This seems to be fixed. With current guix, both

guix import hackage gtk3

and the duplicate’s

guix import hackage monadplus

work.

bug#35754: guix build silent failure for unterminated string

[Robert Vollmert]

I suspect this had to do with the size of the file, but I’m not really sure 
what was going on.

$ guix build -f postgrest.scm
$ echo $?
1

The unterminated string is within the definition of `ghc-string-conversions`, 
line 1169. File attached.



postgrest.scm
Description: Binary data

bug#35750: `guix import hackage` is unaware of metadata revisions

[Robert Vollmert]

As far as I can tell, `guix import hackage` imports the first revision of a 
hackage
release.

I suggest aiming to import the latest cabal revision from hackage, as
already supported by haskell-build-system via the #:cabal-version
argument.

In the meantime, documenting this in the `guix import hackage` documentation
would be much appreciated, it took me quite a long time to figure out what
was going wrong here.

bug#35743: indentation error

[Robert Vollmert]

I learned about `guix import hackage --stdin`, and it turns out the problem is 
with bad indentation in the cabal file. (The offending line is indented by two 
spaces instead of four spaces for the block before.) It’s unclear to me whether 
this is a “valid” cabal file as it is.

bug#35743: guix import hackage wai-app-static fails (comment syntax?)

[Robert Vollmert]

$ guix import hackage wai-app-static
Syntax error: unexpected token : (ghc-options (-Wall)) (at line 106, column 2)

The relevant extract of the cabal file is:

test-suite runtests
[…]
build-depends:   base  >= 4&& < 5
[…]
   , mockery
   -- , containers
  ghc-options:   -Wall

Presumably the double dash comment is tripping `guix import` up.

bug#35735: guix import hackage cassava fails (cabal brace syntax)

[Robert Vollmert]

$ guix import hackage cassava
…
Syntax error: unexpected token : { (at line 8, column 0)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package ‘cassava’

The same happens with stackage import.

The reason seems to be unusal syntax in the description field, grouped by {}:


Description: {

@cassava@ is a library for parsing and encoding [RFC 
4180](https://tools.ietf.org/html/rfc4180)
…
}