bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> I pushed the revised commits to 'core-updates', but something seems to
>> have gone wrong with the new evaluation on Berlin:
>>
>>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>   https://ci.guix.gnu.org/eval/7008
>>
>> The first URL above shows a big "X" in the "Success" column for
>> evaluation 7008, which corresponds to the new commits I just pushed, to
>> switch to the new bootstrap tarballs.
>
> We had a Bison build failure:
>
>   https://ci.guix.gnu.org/log/4rvzs59q3smm4kwyfnf7m58a48rql0fs-bison-3.4.1
>
> Excerpt:
>
> --8<---cut here---start->8---
> make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
> rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
> /gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p 
> examples/c/reccalc
> /gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p 
> examples/c/reccalc
> touch examples/c/reccalc/scan.stamp.tmp
> touch examples/c/reccalc/scan.stamp.tmp
> : -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h 
> ./examples/c/reccalc/scan.l
> : -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h 
> ./examples/c/reccalc/scan.l
> mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
> mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
> make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> mv: cannot stat 'examples/c/reccalc/scan.stamp.tmp': No such file or directory
> make[1]: *** [Makefile:6855: examples/c/reccalc/scan.stamp] Error 1
> make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
> make: *** [Makefile:6847: examples/c/reccalc/scan.h] Error 2
> command "make" "-j" "8" "ARFLAGS=crD" "RANLIB=ranlib" "V=1" failed with 
> status 2
> builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' 
> failed with exit code 1
> @ build-failed /gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv - 
> 1 builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' 
> failed with exit code 1
> --8<---cut here---end--->8---
>
> I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957.
>
>> The second URL above returns "500 Internal Server Error".
>
> Bah, that’s another thing in Cuirass that we kind of fixed in Git but we
> still need to reconfigure I guess.  Ricardo, is that correct?

We use a very slightly modified Cuirass at commit
6cf84a43bb6160e11ede96820a8bc563aa7461ef on berlin.

I confirm that visiting this URL still results in an error:

   https://ci.guix.gnu.org/eval/7008

(Looks like the cuirass-web service still writes to the same log file,
so I can’t actually see the message amidst all the build logs…)

--
Ricardo

bug#37164: Generated installation image does not include grub.

[Jesse Gibbons]

On Thu, 2019-08-29 at 02:34 +0200, Danny Milosavljevic wrote:
> > Jesse Gibbons  skribis:
> > 
> > > 1. generate the install image
> > >  guix system disk-image --file-system-type=iso9600 --verbosity=3
> > > --
> > > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@
> > > (gnu
> > > system install) installation-os)'
> 
> There's a typo there :)
> 
> You wrote: iso9600
> It should be: iso9660
> 
> But the error message could be vastly improved O_o
It looks like this solves the issue. 

bug#37164: Generated installation image does not include grub.

[Danny Milosavljevic]

> Jesse Gibbons  skribis:
> 
> > 1. generate the install image
> >  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> > root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> > system install) installation-os)'

There's a typo there :)

You wrote: iso9600
It should be: iso9660

But the error message could be vastly improved O_o


pgp59ypZi3xfq.pgp
Description: OpenPGP digital signature

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

[Jakob L. Kreuze]

Hi Mark,

Mark H Weaver  writes:

> Hi Jakob,
>
> zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
>> Thanks for the input; I wasn't aware that the activation process was
>> taking so long for some people. One of Ludovic's suggestions was to
>> create a single derivation, rather than three, to speed up system
>> activation. I'll look into this further.
>
> To be clear, I don't care how long it takes to build these
> derivations. However, I think they should all be built before starting
> to activate the system. Does that make sense?

Yes, and I agree that it would be ideal to have the derivations built
prior to system activation -- that way, the activation scripts could be
included in 'show-what-to-build*'.

> On a side note, what would happen if one of those builds failed? Would
> the system activation be left half-done?

Yes. You raise another very good reason for why system activation should
be carried out by a single, atomic activation script :)

Regards,
Jakob


signature.asc
Description: PGP signature

bug#37164: Generated installation image does not include grub.

[Danny Milosavljevic]

And also the volume uuid passed to xorriso is:

"\x0eJ)\x90ö± bn\x00\x19y+u\x90ê"


pgpOF9Ol4V96q.pgp
Description: OpenPGP digital signature

bug#37164: Generated installation image does not include grub.

[Danny Milosavljevic]

I also see in the VM:

file-size: 
/gnu/store/kw357rqfm7kw4rhx1sbakw3jc4zpi6gy-nss-certs-3.45/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem:
 Noy
file-size: 
/gnu/store/vysii5zxdaxiz4pmb468rpn7i4x08qga-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem:
 No such fy


(garbagge in the original)


pgpMsfrU4h0Eo.pgp
Description: OpenPGP digital signature

bug#37164: Generated installation image does not include grub.

[Danny Milosavljevic]

> Then I tried the invocation I usually use and it's the same, funny characters
> and the image is without grub.

Debugging it some further, it's trying to format an iso9660 partition inside 
the VM.

There's an (error ...) inside the VM and the later Guix parts say "successfully 
built". WTF?!



pgpTqVtG5XhCw.pgp
Description: OpenPGP digital signature

bug#37164: Generated installation image does not include grub.

[Danny Milosavljevic]

Hi Jesse,

On Wed, 28 Aug 2019 11:11:45 -0600
Jesse Gibbons  wrote:

> Did you follow the instructions in the manual calling the file to
> generate that (as the manual specifies) or did you include the option:
> 
> -e '(@ (gnu system install) installation-os)'
> 
> to specify the os configuration?

The former.  I've now tried the invocation you used and I get both the funny
characters and the image without grub in it.

Then I tried the invocation I usually use and it's the same, funny characters
and the image is without grub.

Something is definitely up O_o

$ guix describe
Generation 11   27. August 2019 01:23:33(aktuell)
  guix d8f0834
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: d8f08344a7d6060fca73c12fe27a0d1a3528acda

GUIX_PACKAGE_PATH="/home/dannym/.local/guix"



pgpogb9kvPoFX.pgp
Description: OpenPGP digital signature

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hi,

Mark H Weaver  skribis:

> I pushed the revised commits to 'core-updates', but something seems to
> have gone wrong with the new evaluation on Berlin:
>
>   https://ci.guix.gnu.org/jobset/core-updates-core-updates
>   https://ci.guix.gnu.org/eval/7008
>
> The first URL above shows a big "X" in the "Success" column for
> evaluation 7008, which corresponds to the new commits I just pushed, to
> switch to the new bootstrap tarballs.

We had a Bison build failure:

  https://ci.guix.gnu.org/log/4rvzs59q3smm4kwyfnf7m58a48rql0fs-bison-3.4.1

Excerpt:

--8<---cut here---start->8---
make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
rm -f examples/c/reccalc/scan.stamp examples/c/reccalc/scan.stamp.tmp
/gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p 
examples/c/reccalc
/gnu/store/7fimyv3n4jn7nbyl5f5bzdhnm25qmk3m-bootstrap-binaries-0/bin/mkdir -p 
examples/c/reccalc
touch examples/c/reccalc/scan.stamp.tmp
touch examples/c/reccalc/scan.stamp.tmp
: -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h 
./examples/c/reccalc/scan.l
: -oexamples/c/reccalc/scan.c --header-file=examples/c/reccalc/scan.h 
./examples/c/reccalc/scan.l
mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
mv examples/c/reccalc/scan.stamp.tmp examples/c/reccalc/scan.stamp
make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
mv: cannot stat 'examples/c/reccalc/scan.stamp.tmp': No such file or directory
make[1]: *** [Makefile:6855: examples/c/reccalc/scan.stamp] Error 1
make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
make: *** [Makefile:6847: examples/c/reccalc/scan.h] Error 2
command "make" "-j" "8" "ARFLAGS=crD" "RANLIB=ranlib" "V=1" failed with status 2
builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' 
failed with exit code 1
@ build-failed /gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv - 1 
builder for `/gnu/store/wwysm0mdkbvpyp3n4im5pfwcf2brc23p-bison-3.4.1.drv' 
failed with exit code 1
--8<---cut here---end--->8---

I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957.

> The second URL above returns "500 Internal Server Error".

Bah, that’s another thing in Cuirass that we kind of fixed in Git but we
still need to reconfigure I guess.  Ricardo, is that correct?

> Is there a way to find out what went wrong?

For evaluation failures, I simply browse /var/log/cuirass.log…  Until we
have something better, we should maybe just publish that file.

Thanks,
Ludo’.

bug#36876: guix system delete-generations removes custom boot menu entries

[Ludovic Courtès]

Hello,

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Ludovic Courtès  writes:
>
>> I agree with Danny here that parsing the GRUB config wouldn’t be great.
>>
>> We have information about the user’s extra menu entries.  The issue, as
>> I see it, as that this information is lost once the system is
>> instantiated.
>>
>> But!  We have the  structure, that gets serialized with
>> the system, and which we could extend with those extra menu entries.
>> That way, the info would be preserved, and we can restore them upon
>> ‘delete-generations’.   records are bootloader-independent,
>> which is good.
>>
>> How does that sound?
>
> Would that involve appending an additional field to 
> for storing the previous entries? I think that would have the pleasant
> side-effect of making the code for deployment/reconfiguration simpler :)

Oh that’d be nice.

The attached patches should fix this.  I’ve successfully deleted a
generation on my system. :-)  I don’t have extra menu entries though, so
it’d be great if you could give it a try.

Thanks,
Ludo’.

>From 0735c71707a5ea14e43e9adf6125801afa7db1ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Wed, 28 Aug 2019 23:27:20 +0200
Subject: [PATCH 1/2] system: Add 'bootloader-menu-entries' field to
 .

This allows us to keep track of the extra menu entries specified in the
OS configuration.

* gnu/system.scm ()[bootloader-menu-entries]: New field.
(read-boot-parameters): Initialize it.
(operating-system-boot-parameters): Likewise.
(operating-system-boot-parameters-file): Serialize it.
* gnu/bootloader.scm (menu-entry->sexp, sexp->menu-entry): New
procedures.
---
 gnu/bootloader.scm | 34 ++
 gnu/system.scm | 15 +++
 2 files changed, 49 insertions(+)

diff --git a/gnu/bootloader.scm b/gnu/bootloader.scm
index a381f67145..03616c12ab 100644
--- a/gnu/bootloader.scm
+++ b/gnu/bootloader.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2017 David Craven 
 ;;; Copyright © 2017 Mathieu Othacehe 
 ;;; Copyright © 2017 Leo Famulari 
+;;; Copyright © 2019 Ludovic Courtès 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -23,6 +24,7 @@
   #:use-module (guix records)
   #:use-module (guix ui)
   #:use-module (srfi srfi-1)
+  #:use-module (ice-9 match)
   #:export (menu-entry
 menu-entry?
 menu-entry-label
@@ -32,6 +34,9 @@
 menu-entry-initrd
 menu-entry-device-mount-point
 
+menu-entry->sexp
+sexp->menu-entry
+
 bootloader
 bootloader?
 bootloader-name
@@ -76,6 +81,35 @@
(default '()))  ; list of string-valued gexps
   (initrd  menu-entry-initrd)) ; file name of the initrd as a gexp
 
+(define (menu-entry->sexp entry)
+  "Return ENTRY serialized as an sexp."
+  (match entry
+(($  label device mount-point linux linux-arguments initrd)
+ `(menu-entry (version 0)
+  (label ,label)
+  (device ,device)
+  (device-mount-point ,mount-point)
+  (linux ,linux)
+  (linux-arguments ,linux-arguments)
+  (initrd ,initrd)
+
+(define (sexp->menu-entry sexp)
+  "Turn SEXP, an sexp as returned by 'menu-entry->sexp', into a 
+record."
+  (match sexp
+(('menu-entry ('version 0)
+  ('label label) ('device device)
+  ('device-mount-point mount-point)
+  ('linux linux) ('linux-arguments linux-arguments)
+  ('initrd initrd) _ ...)
+ (menu-entry
+  (label label)
+  (device device)
+  (device-mount-point mount-point)
+  (linux linux)
+  (linux-arguments linux-arguments)
+  (initrd initrd)
+

 ;;;
 ;;; Bootloader record.
diff --git a/gnu/system.scm b/gnu/system.scm
index 01be1243fe..a599ba2750 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -116,6 +116,7 @@
 boot-parameters-label
 boot-parameters-root-device
 boot-parameters-bootloader-name
+boot-parameters-bootloader-menu-entries
 boot-parameters-store-device
 boot-parameters-store-mount-point
 boot-parameters-kernel
@@ -251,6 +252,8 @@ directly by the user."
   ;; OS's root file system, so it might be a device path like "/dev/sda3".
   (root-device  boot-parameters-root-device)
   (bootloader-name  boot-parameters-bootloader-name)
+  (bootloader-menu-entries;list of 
+   boot-parameters-bootloader-menu-entries)
   (store-device boot-parameters-store-device)
   (store-mount-point boot-parameters-store-mount-point)
   (kernel   boot-parameters-kernel)
@@ -297,6 +300,11 @@ file system labels."
  ((_ args) args)
  (#f   'grub))) ; for compatibility reasons.
 
+  (bootloader-menu-entries
+   (match (assq 'bootloader-menu-entries rest)
+ ((_ . entries) (map sexp->menu-entry 

bug#37071: guix import pypi httpie fails

[Ludovic Courtès]

Hi,

Robert Vollmert  skribis:

> $ 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

The key here is the message “Failed to extract […] METADATA from wheel”.

When that happens, I think we miss too much information to do anything
sensible.  Maxim, do you confirm?

If you add ‘unzip’ to $PATH, the problem should vanish.

We should probably process wheels & co. in derivations to avoid relying
on tools that may or may not be in $PATH.

Thoughts?

Ludo’.

bug#37128: guix system reconfigure stops output after "Evaluating user expression..."

[Ludovic Courtès]

Hello,

Pierre Neidhardt  skribis:

> After a guix pull on 0fc235a, guix system reconfigure stop at
>
> shepherd: Evaluating user expression (let* ((services (map primitive-load 
> (?))) # ?) ?).
>
>
> instead of
>
> 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’
>
> The only change I've done to my config.scm is that now I have a btrfs
> filesystem (just for storage, it's not /home).

The “Evaluating user expression” started the ‘file-system’ service for
this btrfs file system, and it got stuck for some reason.  Did
/var/log/messages or the console show anything?

I suppose you’d have to try again the experiment.  Presumably there’s
some fsck-like process or something taking time or waiting for input.

Ludo’.

bug#37047: git needs sed either as propagated input or as input (with some substitute*-work)

[Ludovic Courtès]

Hi Björn,

Björn Höfling  skribis:

> guix environment --container -N --ad-hoc go coreutils binutils less  emacs 
> grep findutils git nss-certs
>
> [env] $ go get github.com/fatih/structs 
> # cd /home/bjoern/go/src/github.com/fatih/structs; git submodule update 
> --init --recursive
> /gnu/store/i89f4rw8a2nzppxf2yixl0hvcw46rsxv-git-2.22.0/libexec/git-core/.git-submodule-real:
>  line 7: sed: command not found
> /gnu/store/kiykcyp4n45c7prba3k3zvfz19vvmymd-profile/libexec/git-core/git-sh-setup:
>  line 86: sed: command not found
> /gnu/store/i89f4rw8a2nzppxf2yixl0hvcw46rsxv-git-2.22.0/libexec/git-core/.git-submodule-real:
>  line 1115: sed: command not found
> /gnu/store/i89f4rw8a2nzppxf2yixl0hvcw46rsxv-git-2.22.0/libexec/git-core/.git-submodule-real:
>  line 1115: cmd_: command not found
> package github.com/fatih/structs: exit status 127

I vote for ‘substitute*’ trickery in libexec/git-core/*.

Ludo’.

bug#37207: guix.gnu.org Last Modified at epoch

[Ludovic Courtès]

Hello,

Gábor Boskovits  skribis:

> we should create a file with the git last modification time of the files,
> updated when there is a new commit in the repo => last-modified
> we should create a file with some hash of the files, updated when there is
> a new commit in the repo => etag
> we could restrict these operations to the files modified since the last
> checkout.
>
> Retrieve these with embededd perl.
> Wdyt?

What would the config look like?  AFAICS our ‘nginx’ package doesn’t
embed Perl, and I think it’s better this way.  :-)  Can we do that with
pure nginx directives?

We create /srv/guix.gnu.org (as a symlink) with the correct mtime¹.  If
we can tell nginx to use it as the ‘Last-Modified’ date, that’s perfect.

Ludo’.

¹ 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n212

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello Tobias,

Tobias Geerinckx-Rice via Bug reports for GNU Guix  ezt
írta (időpont: 2019. aug. 28., Sze, 16:38):

> Gábor, Ludo',
>
> Gábor Boskovits 写道：
> > Supressing the last modified header is just an
> > add_header Last-Modified "";
> > away.
>
> You'll also need:
>
> # Don't honour client If-Modified-Since constraints.
> if_modified_since off;
> # Nginx's etags are hashes of file timestamp & file length.
> etag off;
>
>
You really have a point here.

Based on my reseach, I came up with the following:

we need
etag off;

we should create a file with the git last modification time of the files,
updated when there is a new commit in the repo => last-modified
we should create a file with some hash of the files, updated when there is
a new commit in the repo => etag
we could restrict these operations to the files modified since the last
checkout.

Retrieve these with embededd perl.
Wdyt?


> Turning these off will of course prevent all caching.  I don't
> know if that would add measurable load to guix.gnu.org (it would
> be more problematic if we used a CDN, but it might still make a
> difference).
>
> Nix does something both interesting and icky — as always: patch[0]
> nginx to look up the realpath() instead, so clients can still
> cache using If-None-Match.
>
> Kind regards,
>
> T G-R
>
> [0]: https://github.com/NixOS/nixpkgs/pull/48337
>

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello Danny,

Danny Milosavljevic  ezt írta (időpont: 2019. aug.
28., Sze, 17:05):

> Hi Gabor,
>
> On Wed, 28 Aug 2019 12:40:37 +0200
> Gábor Boskovits  wrote:
>
> > Supressing the last modified header is just an
> > add_header Last-Modified "";
> > away.
> >
> > To get the info from the symlink seems to be much trickier, i would do
> with
> > either embedded perl or embedded lua. I am not sure if we should bother
> > with it, though. Wdyt?
>
> Since we already emit ETag, I don't think we need to bother with
> Last-Modified.
>
> Why is the ETag so short, though?
>
>
The ETag we emit is also bad. Nginx calculates this from mtime and
content-lenght,
so in our case it's just content length.


> >wget --debug -O /dev/null   https://guix.gnu.org/packages.json 2>&1 |
> grep -i etag
> >ETag: "1-2f38b1"
>
>
Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

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

[Mark H Weaver]

Hi Jakob,

zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes:

> Thanks for the input; I wasn't aware that the activation process was
> taking so long for some people. One of Ludovic's suggestions was to
> create a single derivation, rather than three, to speed up system
> activation. I'll look into this further.

To be clear, I don't care how long it takes to build these derivations.
However, I think they should all be built before starting to activate
the system.  Does that make sense?

On a side note, what would happen if one of those builds failed?  Would
the system activation be left half-done?

 Thanks,
   Mark

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

[Jakob L. Kreuze]

Hi Mark,

Mark H Weaver  writes:

> Hello again,
>
> Mark H Weaver  writes:
>
>> As a bonus, this approach might solve another issue I've observed: on my
>> Guix system, where I build everything locally, several derivations are
>> built *during* activation.  Based on the terminal output, I get the
>> impression that the system is compiling things while the system in an
>> intermediate state, when some of the activation steps have been done,
>> but not all of them.
>>
>> As I recall, the derivations built during activation are limited to
>> compiled modules for Guile, but it still sometimes takes on the order of
>> a minute or two on my laptop to complete the "activating system" steps.
>> This seems suboptimal.
>>
>> The next time I update my system, I'll try to remember to keep a
>> transcript of this, so that I can be more specific.
>
> Here's a transcript:
>
> activating system...
> building 
> /gnu/store/fbp6bbxw9cf617fmk57sddrz7zfsfw5p-module-import-compiled.drv...
> building 
> /gnu/store/wfi6hnr9ggal0s1d32xx5wbl5k5wqlvx-switch-to-system.scm.drv...
> making '/gnu/store/mjzk53ia3bajn08lscpyzz5apcw3r70g-system' the current 
> system...
> setting up setuid programs in '/run/setuid-programs'...
> populating /etc from /gnu/store/l7r1has973n26hfqrs6vxbi94xzgh360-etc...
> building 
> /gnu/store/h2fqcxv3xx14lkdhyphm3lawkayw7sdl-module-import-compiled.drv...
> building 
> /gnu/store/dar9smjyxmri6v6cchnmp5mpyiimyx64-install-bootloader.scm.drv...
> guix system: bootloader successfully installed on '/dev/sda'
> building 
> /gnu/store/vkk3h5p799lfpmf6msdhrzlq0wqvk3zq-module-import-compiled.drv...
> building 
> /gnu/store/hn8sr8p13gg2mf379xawscabckp03fkb-upgrade-shepherd-services.scm.drv...
> shepherd: Evaluating user expression (let* ((services (map primitive-load 
> (?))) # ?) ?).
> guix system: warning: only 3.9% of free space available on /gnu/store
> hint: Consider deleting old profile generations and collecting garbage, along 
> these lines:
>
>  guix gc --delete-generations=1m
>
>Mark

Thanks for the input; I wasn't aware that the activation process was
taking so long for some people. One of Ludovic's suggestions was to
create a single derivation, rather than three, to speed up system
activation. I'll look into this further.

Regards,
Jakob


signature.asc
Description: PGP signature

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

[Jakob L. Kreuze]

Hi Ludo,

Ludovic Courtès  writes:

> Jakob, now that we generate scripts for the effectful bits of system
> reconfiguration (one of these bits being service upgrades), couldn’t
> we take it one step further and store those scripts in the “system”
> derivation so we can run them eventually, notably upon
> ‘switch-generation’?

We'd need to find a way of serializing at least the relationships
between services, but I think it's possible (albeit quite involved). I
do really like the idea, though. That way, the system generation would
fully encompass the desired state of the system.

Regards,
Jakob


signature.asc
Description: PGP signature

bug#36876: guix system delete-generations removes custom boot menu entries

[Jakob L. Kreuze]

Hi Ludo,

Ludovic Courtès  writes:

> I agree with Danny here that parsing the GRUB config wouldn’t be great.
>
> We have information about the user’s extra menu entries.  The issue, as
> I see it, as that this information is lost once the system is
> instantiated.
>
> But!  We have the  structure, that gets serialized with
> the system, and which we could extend with those extra menu entries.
> That way, the info would be preserved, and we can restore them upon
> ‘delete-generations’.   records are bootloader-independent,
> which is good.
>
> How does that sound?

Would that involve appending an additional field to 
for storing the previous entries? I think that would have the pleasant
side-effect of making the code for deployment/reconfiguration simpler :)

Regards,
Jakob


signature.asc
Description: PGP signature

bug#37207: guix.gnu.org Last Modified at epoch

[Danny Milosavljevic]

Hi Gabor,

On Wed, 28 Aug 2019 12:40:37 +0200
Gábor Boskovits  wrote:

> Supressing the last modified header is just an
> add_header Last-Modified "";
> away.
> 
> To get the info from the symlink seems to be much trickier, i would do with
> either embedded perl or embedded lua. I am not sure if we should bother
> with it, though. Wdyt?

Since we already emit ETag, I don't think we need to bother with Last-Modified.

Why is the ETag so short, though?

>wget --debug -O /dev/null   https://guix.gnu.org/packages.json 2>&1 | grep -i 
>etag
>ETag: "1-2f38b1"



pgpYU_7jEciPx.pgp
Description: OpenPGP digital signature

bug#37207: guix.gnu.org Last Modified at epoch

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Gábor, Ludo',

Gábor Boskovits 写道：

Supressing the last modified header is just an
add_header Last-Modified "";
away.


You'll also need:

# Don't honour client If-Modified-Since constraints.
if_modified_since off;
# Nginx's etags are hashes of file timestamp & file length.
etag off;

Turning these off will of course prevent all caching.  I don't 
know if that would add measurable load to guix.gnu.org (it would 
be more problematic if we used a CDN, but it might still make a 
difference).


Nix does something both interesting and icky — as always: patch[0] 
nginx to look up the realpath() instead, so clients can still 
cache using If-None-Match.


Kind regards,

T G-R

[0]: https://github.com/NixOS/nixpkgs/pull/48337


signature.asc
Description: PGP signature

bug#37209: [PATCH] gnu: libvirt: Don't wrap with PATH

[宋文武]

Hello, this patch will make libvirt use
  "/run/current-system/profile/bin/qemu-system-x86_64"
in machine's definition, and it can use 'ovs-vsctl' in PATH:

>From e463ef6952009a46c96981df0647cee414fb71a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Wed, 28 Aug 2019 20:49:40 +0800
Subject: [PATCH] gnu: libvirt: Don't wrap with PATH.

This reverts commit 903e051a71467bc96a054c9b4ed89348fdae8977 to fix
.  The full path of the 'ip' command is already
embedded, and we want to search 'qemu' in PATH.

* gnu/packages/virtualization.scm (libvirt): Remove 'wrap-libvirtd phase.  Add
configure flags to run qemu as 'nobody:kvm'.
* gnu/services/virtualization.scm (libvirt-service-type): Add 'qemu' to the
system profile.
---
 gnu/packages/virtualization.scm | 17 +
 gnu/services/virtualization.scm |  6 --
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 26477714e4..f46c31df1f 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -401,7 +401,10 @@ manage system or application containers.")
 (build-system gnu-build-system)
 (arguments
  `(#:configure-flags
-   (list "--with-polkit"
+   (list "--with-qemu"
+ "--with-qemu-user=nobody"
+ "--with-qemu-group=kvm"
+ "--with-polkit"
  (string-append "--docdir=" (assoc-ref %outputs "out") "/share/doc/"
 ,name "-" ,version)
  "--sysconfdir=/etc"
@@ -431,23 +434,13 @@ manage system or application containers.")
  (apply invoke "make" "install"
 "sysconfdir=/tmp/etc"
 "localstatedir=/tmp/var"
-make-flags)))
- (add-after 'install 'wrap-libvirtd
-   (lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
-   (wrap-program (string-append out "/sbin/libvirtd")
- `("PATH" = (,(string-append (assoc-ref inputs "iproute")
- "/sbin")
- ,(string-append (assoc-ref inputs "qemu")
- "/bin"
-   #t))
+make-flags))
 (inputs
  `(("libxml2" ,libxml2)
("eudev" ,eudev)
("libpciaccess" ,libpciaccess)
("gnutls" ,gnutls)
("dbus" ,dbus)
-   ("qemu" ,qemu)
("libpcap" ,libpcap)
("libnl" ,libnl)
("libuuid" ,util-linux)
diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index 705ed84d06..03aedd326c 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -442,8 +442,10 @@ potential infinite waits blocking libvirt."))
   (service-extension polkit-service-type
  (compose list libvirt-configuration-libvirt))
   (service-extension profile-service-type
- (compose list
-  libvirt-configuration-libvirt))
+ (lambda (config)
+   (list
+(libvirt-configuration-libvirt config)
+qemu)))
   (service-extension activation-service-type
  %libvirt-activation)
   (service-extension shepherd-root-service-type
-- 
2.19.2

bug#37207: guix.gnu.org Last Modified at epoch

[Gábor Boskovits]

Hello,

Supressing the last modified header is just an
add_header Last-Modified "";
away.

To get the info from the symlink seems to be much trickier, i would do with
either embedded perl or embedded lua. I am not sure if we should bother
with it, though. Wdyt?

bug#37207: guix.gnu.org returns Last-Modified = Epoch

[Ludovic Courtès]

Hello Guix,

Since the use of the ‘static-web-site’ service, which puts web site
files in the store, nginx returns a ‘Last-Modified’ header that can
trick clients into caching things forever:

--8<---cut here---start->8---
$ wget --debug -O /dev/null   https://guix.gnu.org/packages.json 2>&1 | grep 
Last
Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
--8<---cut here---end--->8---

We should tell nginx to do not emit ‘Last-Modified’, or to take the
state from the /srv/guix.gnu.org symlink, if possible.

Ludo’.

bug#37164: Generated installation image does not include grub.

[Ludovic Courtès]

Hello Jesse,

Jesse Gibbons  skribis:

> 1. generate the install image
>  guix system disk-image --file-system-type=iso9600 --verbosity=3 --
> root=installation-os-x86_64.iso  --system=x86_64-linux -e '(@ (gnu
> system install) installation-os)'
>
> 2. examine the resulting iso
> readlink installation-os-x86_64.iso | xargs file
>
> output: /gnu/store/3xp541s4zrxass6h6rcwfz7bc33wv84p-disk-image: DOS/MBR
> boot sector; partition 1 : ID=0x83, active, start-CHS (0x0,32,33), end-
> CHS (0xe3,198,58), startsector 2048, 3657239 sectors; partition 2 :
> ID=0xef, start-CHS (0xe3,198,59), end-CHS (0xe8,224,16), startsector
> 3659287, 81921 sectors
>
> 3. Compare this output with what file says about the official
> installation iso:
> wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.x86_64-linu
> x.iso.xz
> unxz guix-system-install-1.0.1.x86_64-linux.iso.xz
> readlink guix-system-install-1.0.1.x86_64-linux.iso
>
> output:guix-system-install-1.0.1.x86_64-linux.iso: DOS/MBR boot sector;
> GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2
> address 0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201;
> partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3f6,38,4),
> startsector 1, 2694403 sectors, extended partition table (last)
>
> It appears file discovered the GRand Unified Bootloader in the official
> iso but not in the generated iso.

I can’t seem to reproduce it now:

--8<---cut here---start->8---
$ guix describe 
Generacio 101   Aug 26 2019 09:31:24(nuna)
  guix a707484
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: a707484d64e7e46f8cb8401c660fbb6eb77ab9c6
$ guix system disk-image --file-system-type=iso9660 gnu/system/install.scm 
/gnu/store/cpyyjnwbpm2hrpcjf1j8y4yjis9za33s-image.iso
$ file /gnu/store/cpyyjnwbpm2hrpcjf1j8y4yjis9za33s-image.iso
/gnu/store/cpyyjnwbpm2hrpcjf1j8y4yjis9za33s-image.iso: DOS/MBR boot sector; 
GRand Unified Bootloader, stage1 version 0x79, boot drive 0xbb, stage2 address 
0x8e70, 1st sector stage2 0xb8db31c3, stage2 segment 0x201; partition 2 : 
ID=0xef, start-CHS (0x3ff,63,32), end-CHS (0x3ff,63,32), startsector 2711068, 
5760 sectors
$ guix system disk-image --file-system-type=iso9660 -e '(@ (gnu system install) 
installation-os)'
/gnu/store/cpyyjnwbpm2hrpcjf1j8y4yjis9za33s-image.iso
--8<---cut here---end--->8---

Not sure what’s going on…

Ludo’.

bug#37160: guix lint --checkers=refresh fails

[Jonathan Brielmaier]

On 28.08.19 00:33, Ludovic Courtès wrote:
> Hi,
>
> Jonathan Brielmaier  skribis:
>
>> guix lint --checkers=refresh hello
>> Backtrace:ello@2.10 [refresh]...
>>9 (apply-smob/1 #)
>> In ice-9/boot-9.scm:
>> 705:2  8 (call-with-prompt _ _ #)
>> In ice-9/eval.scm:
>> 619:8  7 (_ #(#(#)))
>> In guix/ui.scm:
>>   1692:12  6 (run-guix-command _ . _)
>> In srfi/srfi-1.scm:
>> 640:9  5 (for-each # …)
>> In guix/scripts/lint.scm:
>>  57:4  4 (run-checkers # …)
>> In srfi/srfi-1.scm:
>> 640:9  3 (for-each # …)
>> In guix/scripts/lint.scm:
>> 64:17  2 (_ _)
>> In guix/lint.scm:
>>1010:2  1 (check-for-updates #)
>> In ice-9/boot-9.scm:
>> 829:9  0 (catch srfi-34 # …)
>>
>> ice-9/boot-9.scm:829:9: In procedure catch:
>> Wrong type to apply: #f
>
> I think commit 58d5f280a36e1cfddfa999d320c285726d8a8bc1 fixes it,
> doesn’t it?  :-)

My package is now on2f57fa10f4, so includes your commit. But the error
still looks very similar:

$ guix lint --checkers=refresh hello
Backtrace:ello@2.10 [refresh]...
   9 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  8 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  7 (_ #(#(#)))
In guix/ui.scm:
  1692:12  6 (run-guix-command _ . _)
In srfi/srfi-1.scm:
640:9  5 (for-each # …)
In guix/scripts/lint.scm:
 57:4  4 (run-checkers # …)
In srfi/srfi-1.scm:
640:9  3 (for-each # …)
In guix/scripts/lint.scm:
64:17  2 (_ _)
In guix/lint.scm:
   1010:2  1 (check-for-updates #)
In ice-9/boot-9.scm:
829:9  0 (catch srfi-34 # …)

ice-9/boot-9.scm:829:9: In procedure catch:
Wrong type to apply: #f

bug#37164: Generated installation image does not include grub.

[Danny Milosavljevic]

Hi,

could you check gnu/bootloader/grub.scm install-grub (and maybe 
install-grub-efi) ?
They are build-side code so you can just use (write "foo\n") to add debugging 
messages.
Interesting would be DEVICE, MOUNT-POINT.

FWIW, I successfully built a new installation iso image from guix master (and 
booted it) a few days ago.

I still have that image and file(1) says:

>guix-master-i686.iso: DOS/MBR boot sector; GRand Unified Bootloader, stage1 
>version 0x79, boot drive 0xbb, stage2 address 0x8e70, 1st sector stage2 
>0xb8db31c3, stage2 segment 0x201; partition 2 : ID=0xef, start-CHS 
>(0x3ff,63,32), end-CHS (0x3ff,63,32), startsector 2483356, 5760 sectors



pgpWw0_DmUq1N.pgp
Description: OpenPGP digital signature