bug#37226: previously working system config fails to build
I try to run guix system reconfigure and get this error:
guix system: error: #< type: dce bv: #vu8(51 12 55 214 249 221 79
112 186 51 233 64 103 99 34 57)>: invalid G-expression input
Here's the minimum of what I feed it to replicate the error (comments
and non-essentials removed):
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop pm virtualization networking cups sound)
(use-package-modules certs gnome guile-xyz)
(define pureos-root "330c37d6-f9dd-4f70-ba33-e94067632239")
(define swap-uuid "049a0350-bcce-4920-9816-5fd4ee3c0de1")
(define (other-partition entry-label vmlinuz-version root-uuid resume-
uuid)
(menu-entry
(label "pureos")
(linux (string-concatenate `("/boot/vmlinuz-" ,vmlinuz-version)))
(linux-arguments
`(,(string-concatenate `("root=UUID=" ,root-uuid))
"ro" "quiet" "splash"
,(string-concatenate `("resume=UUID=" ,resume-uuid
(initrd (string-concatenate `("/boot/initrd.img-" ,vmlinuz-
version)))
(device (uuid root-uuid
(operating-system
(host-name "piranhaplant")
(timezone "America/Boise")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda") ;include my usual OS
(menu-entries
(list
(other-partition
"pureos"
"4.19.0-2-amd64"
pureos-root
swap-uuid)
(file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
)
Please forgive the ugly formatting and quasiquote/unquote abuse. I was
beginning to understand scheme when I wrote the .
It breaks when I add (file-system ...) which is identical to what's in
the manual. I think it might have something to do with the bootloader,
but I don't know what. Where is a G-expression expected?
bug#36876: guix system delete-generations removes custom boot menu entries
Pushed as c3e59de9b1340f1a0ef7e30dd2e4e7bf7b484ee9. Let me know if anything’s still not quite as expected! Ludo’.
bug#37128: guix system reconfigure stops output after "Evaluating user expression..."
Hi Bengt, Bengt Richter skribis: > On +2019-08-29 14:41:51 +0200, Ludovic Courtès wrote: >> Pierre Neidhardt skribis: [...] >> > Note that everything works alright. But I'm worried that this would >> > fail on a new installation where the bootloader is missing :( >> >> Where the bootloader is missing? The bootloader cannot be missing or >> the thing is not installed. :-) >> >> Ludo’. >> > > Had you considered the case where someone[1] is running a binary install > on a foreign distro booted by refind or a bootloader not in your official > list? I hadn’t! If that’s the case, it’ll be more difficult for us to support that someone. :-) Ludo’.
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi, Mark H Weaver skribis: > Thanks. The next evaluation got further, but eventually failed. Again, > there seems no way to get any details on what went wrong from the web > interface: > > https://ci.guix.gnu.org/jobset/core-updates-core-updates > https://ci.guix.gnu.org/eval/7029 A Guile build of /gnu/store/lbbgpkrs9mpw68k1bz0dwpi8ch6gp557-guile-2.2.6.drv had timed out. I restarted manually earlier today with a larger timeout. It succeeded and a new evaluation is now “in progress”… Ludo’.
bug#37128: guix system reconfigure stops output after "Evaluating user expression..."
On +2019-08-29 14:41:51 +0200, Ludovic Courtès wrote: > Pierre Neidhardt skribis: > > > This is the last message in /var/log/messages: > > > > Aug 29 09:13:40 localhost shepherd[1]: Evaluating user expression (let* > > ((services (map primitive-load (?))) # ?) ?). > > > >> Did > >> /var/log/messages or the console show anything? > > > > What console? > > /dev/console, so tty1, typically. > > >> 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. > > > > Note that everything works alright. But I'm worried that this would > > fail on a new installation where the bootloader is missing :( > > Where the bootloader is missing? The bootloader cannot be missing or > the thing is not installed. :-) > > Ludo’. > Had you considered the case where someone[1] is running a binary install on a foreign distro booted by refind or a bootloader not in your official list? [1] guess who ;-) Regards, Bengt Richter
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
On +2019-08-27 11:38:31 +0200, Ludovic Courtès wrote:
> Hi Mark,
>
> Mark H Weaver skribis:
>
> > Ludovic Courtès writes:
> >
> >> Mark H Weaver skribis:
>
> [...]
>
> >>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
> >>> Author: Mark H Weaver
> >>> Date: Thu Aug 15 16:44:36 2019 -0400
> >>>
> >>> gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
> >>>
> >>> * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
> >>> * gnu/local.mk (dist_patch_DATA): Add it.
> >>> * gnu/packages/bash.scm (bash)[source]: Add the patch.
>
> [...]
>
> >> OK. The Bash change means we’re rebuilding from scratch on
> >> architectures, not just x86. So I’ll probably ungraft my Ghostscript
> >> fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.
> >
> > Hmm, good point. Perhaps we should postpone the Bash fix until the next
> > core-updates cycle. The problem was quite severe in bash-4.4, which
> > builds incorrectly on linux-5.0 or later, but the issue in bash-5.0 is
> > far less likely to cause problems in practice: it will build differently
> > on linux-2.3 or earlier.
> >
> > What do you think?
>
> Your call: if you think this Bash fix can be delayed without causing
> problems, then please revert it and we’ll apply it on the next cycle.
> That would allow us to merge ‘core-updates’ more quickly for sure!
>
> Thanks,
> Ludo’.
>
>
>
Hi,
(Just in case this might be relevant, sorry if not :)
I noticed that the guix-built version of bash is not position-independent,
and also differences in built-for versions, wondered why:
$ type bash which
bash is /home/bokr/.guix-profile/bin/bash
which is /home/bokr/.guix-profile/bin/which
$ which -a bash
/home/bokr/.guix-profile/bin/bash
/usr/bin/bash
$
$ which -a bash|xargs readlink -f
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
/usr/bin/bash
$
$ which -a bash|xargs readlink -f|xargs file
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
^^
interpreter
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.32, not stripped
^^
/usr/bin/bash:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
^^
interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=21a51cb5f7d727370e4d8099d283d7cd20222571,
for GNU/Linux 3.2.0, stripped
^
If you substitute guile for bash in the above, it shows the same differences.
Could something need position-independence only under special circumstances
and silently give up if not repositionable, causing mystery errors?
Also, I am in the foreign (ArchLinux) host environment twilight zone
of mixed /usr vs ~/.guix-profile name searches and wonder if
there are hidden /usr dependencies baked statically into some /gnu/store
executables
that are causing me problems.
exec is a bash built-in, and I suppose that is usually doesn't matter
if a guile script is launched via
#!/usr/bin/bash
exec guile ...
but I have a hunch that sometimes it does matter, because editing scripts
to do hash-bang with
#!/home/bokr/.guix-profile/bin/bash
has made a locale error ("guile: warning: failed to install locale")
go away and the script execute successfully, vs not executing beyond the error.
Also, what about the shell that runs first, when I log in?
Should I set SHELL=/gnu/... ? And/or reconfigure to get login/systemd
to launch /gnu/.../bash ?
I had hoped a binary install could give me clean separation of
guix pull goodies vs pacman -Syu (ArchLinux's package installer/updater)
stuff, but it seems difficult to control the env name environment that
both guix and non-guix use.
My setup, fwiw:
guix describe:
Generation 11 Aug 25 2019 20:58:43(current)
guix a707484
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: a707484d64e7e46f8cb8401c660fbb6eb77ab9c6
uname -a:
Linux PhantoNv4ArchGx 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC
2019 x86_64 GNU/Linux
Well, sorry if these observations are explained in a FAQ.
I note that there is no -pie in the guix version of this:
[15:14 ~/bs]$ which -a gcc|while read line;do { echo -e "$line: ";$line -v
--version|& cat -n|egrep -on -e ' -pie ' ; } ;done
/home/bokr/.guix-profile/bin/gcc:
/usr/bin/gcc:
32: -pie
34: -pie
[15:14 ~/bs]$
HTH in some way, PMJI if not.
Regards,
Bengt Richter
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi Ludovic and Ricardo, 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 [...] > I’ve addressed it by a hack in c55fae452032aa4b1b63406983e9abdf70adc957. Thanks. The next evaluation got further, but eventually failed. Again, there seems no way to get any details on what went wrong from the web interface: https://ci.guix.gnu.org/jobset/core-updates-core-updates https://ci.guix.gnu.org/eval/7029 The second URL works this time, but it shows no results: 0 scheduled builds, 0 succeeded builds, 0 failed builds, and it says "No elements here." Can you see what happened? Thanks, Mark
bug#37128: guix system reconfigure stops output after "Evaluating user expression..."
Ludovic Courtès writes: > Where the bootloader is missing? The bootloader cannot be missing or > the thing is not installed. :-) No it's not missing, but I think the bootloader remained from the previous working configs (before I configured the Btrfs file system). Say I'd wipe the bootloader now and re-run `guix system reconfigure...', I don't think it would get installed then. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#37128: guix system reconfigure stops output after "Evaluating user expression..."
Pierre Neidhardt skribis: > This is the last message in /var/log/messages: > > Aug 29 09:13:40 localhost shepherd[1]: Evaluating user expression (let* > ((services (map primitive-load (?))) # ?) ?). > >> Did >> /var/log/messages or the console show anything? > > What console? /dev/console, so tty1, typically. >> 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. > > Note that everything works alright. But I'm worried that this would > fail on a new installation where the bootloader is missing :( Where the bootloader is missing? The bootloader cannot be missing or the thing is not installed. :-) Ludo’.
bug#36876: guix system delete-generations removes custom boot menu entries
Hi there! Ludovic Courtès skribis: > 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. So I tried it on my laptop: I added a dummy menu entry, reconfigured, rebooted, then ran “guix system delete-generations N”, and I confirm that it preserves the extra menu entry. There was a typo though: > --- 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 entries)) ^ There shouldn’t be a dot here. I’ll go ahead and push these patches (with this correction) if there are no objections. Thanks, Ludo’.
bug#34877: Ghostscript: Missing text when converting PDF to PS
that's a great one to hear, thank you! I'll try it out over the weekend. Dnia 25 sierpnia 2019 22:53:17 CEST, "Ludovic Courtès" napisał(a): >Hello, > >Diego Nicola Barbato skribis: > >> When converting certain PDF files to PostScript pdf2ps (from the >> Ghostscript package) will print the following error messages: >> >> Error reading a content stream. The page may be incomplete. >>Output may be incorrect. >> Error: File did not complete the page properly and may be >damaged. >>Output may be incorrect. > >sirmacik skribis: > >> Unfortunately this is something that affects also printing from >> pdfs. At this point I can see what my printing result will look like >> by opening it in GNU Emacs DocView. > >Good news everyone! Commit 466ff55c72959ba1499ce3ec69f534b3038eb30b >fixes it! The next commit makes a graft so that the working Ghoscript >is readily available to CUPS, etc. > >It turned out that the primary issue was that Freetype was not found at >configure-time, due to the lack of pkg-config… The commit above >improves a couple of other things in passing, but adding Freetype for >good is apparently the decisive change. > >Please let me know if DocView, pdf2ps, and CUPS and all right for you! > >Thanks, >Ludo’.
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Ricardo Wurmus writes: > (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…) It now logs to cuirass-web.log. -- Ricardo
bug#37207: guix.gnu.org Last Modified at epoch
Hello Ludo, Ludovic Courtès ezt írta (időpont: 2019. aug. 28., Sze, 22:32): > 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. > > I was thinking about this. Yes, we can solve that with pure nginx. There is an issue however. It invalidates all cached entries on update, so files not modified will also need to be downloaded again. The easiest way to do that would be to simply generate an nginx config snippet at a configurable location, setting up the mtime and etags variable, and include that from the main config. If this would be ok, then I will have a look at implementing this. Ludo’. > > ¹ > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n212 > Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#37164: Generated installation image does not include grub.
Hello, Danny Milosavljevic ezt írta (időpont: 2019. aug. 29., Cs, 2:36): > > 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 > Wow, nice... Yes, it is quite a hard to spot... -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
