bug#36942: Reconfigure broke GRUB

[ison]

On Fri, Aug 16, 2019, Jakob L. Kreuze wrote:
> ison  writes:
> 
> > /boot/efi looks ok as far as I can tell at least. It's tree is:
> > /boot/efi/
> > └── EFI
> > ├── grub
> > │   └── grubx64.efi
> > ├── Guix
> > │   └── grubx64.efi
> > └── GuixSD
> > └── grubx64.efi
> > All 3 grubx64.efi files differ from each other and are around 120kb.
> 
> Interesting... I only have '/boot/efi/EFI/Guix'. Do you have a
> '/boot/grub'?

I do have a /boot/grub actually. Is that strange?
It looks like a normal /boot/grub to me, and contains a grub.cfg

> I think it may be indicative of a more serious problem, since you
> mentioned that this was fine up until the commit refactoring 'guix
> system reconfigure'. If you're willing to reinstall and see if you can
> reproduce it, that maywould be helpful -- you could send me the relevant
> 'install-bootloader.scm' store item if it breaks again.
> 
> Thank you very much, ison. I appreciate your cooperation here greatly.

Sounds good, I'll reinstall it over the weekend

bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

[pelzflorian (Florian Pelz)]

On Fri, Aug 16, 2019 at 12:51:28PM -0700, Bengt Richter wrote:
> For your purposes, it might be worth trying asking for interesting
> specifics (see lsblk -h for more), e.g.
> 
> $ lsblk -o mountpoint,name,size,fstype,label,partlabel,partuuid,uuid
> 
> Maybe that partuuid '31393730-3031-3031-3139-343934363833' might show up?
> 

I just checked for my working USB image and the
boot/grub/grub.cfg contains that line

bzImage --root=31393730-3031-3031-3139-343934363833 
--system=/gnu/store/2j79kbvsxqq7lmzp3isnran1dpcp2z5j-system 
--load=/gnu/store/2j79kbvsxqq7lmzp3isnran1dpcp2z5j-system/boot quiet

but I cannot find that partition either.  It seems to be created by
grub-mkrescue from make-iso9660-image, but I am not sure.

@Calvin: The manual contains this line in section _Building the
Installation Image_ (with Mark’s --system=i686-linux added):

guix system disk-image --file-system-type=iso9660 --system=i686-linux \
   gnu/system/install.scm

If you omit --file-system-type=iso9660, a USB image will still work
and I believe no --root=31393730-3031-3031-3139-343934363833 will be
inserted in GRUB.

Regards,
Florian

bug#36345: Font and other Issues/Bugs in Guix System

[Christian Bertram via Bug reports for GNU Guix]

I have the same issue with numbers in IceCat.

I have tested both inside and outside a VM and with Gnome, XFCE,
Enlightenment and EXWM.  It seems, if I don't have

(service gnome-desktop-service-type)

in my config, numbers in IceCat are shown as long spaces.  I don't have
the problem, even when using XFCE, as long as that line is in my config.

I hope this can help someone find the problem. Thanks.


--
Christian Bertram

bug#34902: guix cannot find a module on boot

[Ludovic Courtès]

Hello!

Danny Milosavljevic  skribis:

> Maybe I'm too paranoid but can we have "guix" in the file name "modules.name"
> somewhere?  Otherwise I see it coming that upstream uses modules.name for an
> incompatible purpose and then we'd be with a guix interface that's broken
> and/or break their interface.
>
> (So much complexity for something so silly.  Honestly, I feel like E-mailing
> the upstream author and telling him what I think.  WTF :P)
>
> Should we warn when we use the fallback?  I like the defensive programming
> but I feel we shouldn't have it *silently* fall back when the database is
> broken/missing.
>
> Otherwise LGTM!

So I went ahead and pushed these patches, derived from our beautiful
patch set at :

  c85ccf60bf linux-modules: Define and use a module name database.
  e1a9a7f275 linux-modules: Add 'load-linux-modules-from-directory'.
  2a693b69ca linux-modules: Add "modules.devname" writer.
  4f8b9d1a6f linux-modules: Add "modules.alias" writer.

The actual fix for the hyphen/underscore mismatch that Julien reported
is commit c85ccf60bf.  The “modules.devname” and “modules.alias” are
actually unused so far but (1) it was easier to preserve them, and (2)
that’ll give us an incentive to finish
.  :-)

I added an explicit comment that “modules.name” uses a Guix-specific
format.  We can always rename it if the kernel folks decide to acquire
that file name.

Julien, could you please confirm that your initial issue is fixed?

Thanks,
Ludo’.

bug#36777: Guix Inferiors: Curious incorrect derivation output bug

[Ludovic Courtès]

Hi Carl,

Carl Dong  skribis:

> Yes! The patch actually fixed the problem when applied on top of 
> 5cf4b26d52bcea382d98fb4becce89be9ee37b55!

[...]

> Not sure what the next steps are for this, but I'd very much like to 
> understand where this went wrong. Perhaps we could write tests for this so it 
> doesn't happen in the future for releases.

Yup, I understood when this could happen (if multiple inputs of a
derivation are “fixed-output” derivations leading to the same output),
wrote a test for that, and came up with a simpler fix in commit
268896444bed7b958add74b2e1e86ff802c5f5cb.

Let me know if anything is amiss!

Thanks for testing the patch,
Ludo’.

bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

[Bengt Richter]

On +2019-08-15 15:05:57 -0700, Calvin Heim wrote:
> resubmitted to list
> On Thu, 2019-08-15 at 12:43 +0200, pelzflorian (Florian Pelz) wrote:
> > 
> > Do I understand correctly that this message appears when booting the
> > DVD, not the installed system?
> Yes.
> 
> > 
> > 
> > On Wed, Aug 14, 2019 at 03:32:06PM -0700, Calvin Heim wrote:
> > > 
> > > 
> > >  waiting for partition '31393730-3031-3031-3139-343934363833' to appear...
> > I cannot check right now if that is a legitimate partition id for the
> > i686 installer, but the installer source code in
> > gnu/system/install.scm should mount a partition with
> > (file-system-label "Guix_image").  You could check from another OS if
> > this partition label exists.  
> From Trisquel 8,
> $ ls /dev/disk/by-label
>   GUIX_IMAGE
>  
> $ls /dev/disk/by-uuid
>  1970-01-01-19-49-46-83
>  [other stuff that doesn't change when the DVD ejects]
>
I have found this incantation, and variants, e.g. filtering with grep, useful 
also:

$ stat -c %N /dev/disk/by-*/*

I have also encountered, IIRC, system versions where /disk/dev/by-* could 
present info
from stale cache information, so it might not show what e.g. the following 
might:

$ lsblk
$ lsblk -f

For your purposes, it might be worth trying asking for interesting
specifics (see lsblk -h for more), e.g.

$ lsblk -o mountpoint,name,size,fstype,label,partlabel,partuuid,uuid

Maybe that partuuid '31393730-3031-3031-3139-343934363833' might show up?

BTW, I think some older systems might not know how to look for partuuid,
(especially beyond the intial boot device?) and it could be worth trying
plain uuid instead. I suspected such a stiutation when I got
a not-found in the past, but did not diagnose it unambigously.

--8<--aside
BTW2, I am using refind to multiboot, and consider my shooting myself in the 
foot
(clobbering my efi partition with unintended grub install) as a kind of 
usability-bug,
which I am tempted to use as rationale for posting to this list (but not 
hijacking
this post further ;-) Would that be ok, or should I join guix-help as well? I 
am getting
more email traffic than I am used to :) ... 

(I would like to mount a losetup file partition as a target for grub bootloader 
install,
and thereby capture initrds etc for manual (at first ;-) transfer into my 
refind efi vfat
file tree.)
--8<--aside--

> The contents of by-id and by-partuuid don't change when the install DVD is 
> inserted,
> so I assume that the contents of those directories are not related to the DVD.
> > 
> > You could also type in the recovery
> > Guile repl that opens:
> > 
> > (use-modules (ice-9 ftw))
> > (scandir "/dev/disk/by-id")
> > (scandir "/dev/disk/by-uuid")
> > (scandir "/dev/disk/by-partuuid")
> > 
> > and maybe:
> > 
> > ,L bournish
> > cat /run/booted-system/etc/fstab
> > 
> The keyboard/usb ports do not function at this point in the boot,
> despite working earlier in the boot during EFI and GRUB.  I
> can see but not type in the recovery Guile repl.
> 
> > 
> > Regards,
> > Florian
> 
Regards,
Bengt Richter

bug#36014: [PATCH] Attempt to use console-fonts not provided by kbd if they are installed

[John Soo]

Hi Ludo,

I am not familiar with the info and html documentation build process. Will
this patch suffice?

Thank you,

John
From 681d6e2f81b4cf46501c2312edcef4c98284675b Mon Sep 17 00:00:00 2001
From: John Soo 
Date: Fri, 16 Aug 2019 10:45:43 -0700
Subject: [PATCH] gnu: Update console-font-service docstring.

* gnu/services/base (console-font-service-type):
  Add documentation about valid arguments.
---
 gnu/services/base.scm | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 537d30add5..363cb20c06 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -8,6 +8,7 @@
 ;;; Copyright © 2016 Ricardo Wurmus 
 ;;; Copyright © 2018 Mathieu Othacehe 
 ;;; Copyright © 2019 Efraim Flashner 
+;;; Copyright © 2019 John Soo 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -801,10 +802,14 @@ to add @var{device} to the kernel's entropy pool.  The service will fail if
 (description
  "Install the given fonts on the specified ttys (fonts are per
 virtual console on GNU/Linux).  The value of this service is a list of
-tty/font pairs like:
+tty/font pairs. The font can be the name of a font provided by the kbd package
+or any valid argument to setfont. For example:
 
 @example
-'((\"tty1\" . \"LatGrkCyr-8x16\"))
+'((\"tty1\" . \"LatGrkCyr-8x16\")
+  (\"tty2\" . (file-append
+font-tamzen
+\"/share/kbd/consolefonts/TamzenForPowerline10x20.psf\")))
 @end example\n")))
 
 (define* (console-font-service tty #:optional (font "LatGrkCyr-8x16"))
-- 
2.22.0

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

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Marius Bakke  skribis:
>
>> Mark H Weaver  writes:
>
> [...]
>
>>> I think what needs to be done is the following:
>>>
>>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>>> should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>>
>>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>>> of , along
>>> with digital signatures, of course.  I'm talking about these in
>>> particular:
>>>
>>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  
>>> guile-static-stripped-2.2.4-i686-linux.tar.xz
>>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  
>>> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  
>>> mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  
>>> mes-minimal-stripped-0.19-i686-linux.tar.xz
>>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  
>>> static-binaries-0-i686-linux.tar.xz
>>>
>>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>>> should be updated to use the new binaries above:
>>>
>>>  (a) %bootstrap-linux-libre-headers
>>>  (b) %bootstrap-mescc-tools
>>>  (c) %bootstrap-mes
>>>
>>> (4) Berlin should start rebuilding 'core-updates'.
>>>
>>> If desired, steps (3) and (4) could come before (2) if someone
>>> temporarily uploads the new binaries somewhere else, and adjusts
>>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>>> names to match what we've agreed on here, as I listed in (2) above.
>>>
>>> What do you think?
>>
>> Thank you for the excellent summary.  I can look into adjusting the bash
>> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
>> do this in a 'core-updates-next' branch.  I would also like to merge
>> wip-binaries into it as a final step, unless someone has objections.
>>
>> Ludovic should be back in a couple of days and can hopefully take care
>> of the uploads.
>
> I haven’t quite caught up yet, but I trust you and I can upload the
> files that Mark mentions above to ftp.gnu.org this time (Ricardo should
> also be able to upload them, if needed.)
>
> How can I reproduce them or fetch them?

You can reproduce them with the following command from a git checkout at
commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
'wip-binaries' branch, based on recent 'master':

  ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs

--8<---cut here---start->8---
mhw@jojen ~/guix-wip-binaries$ git describe
v1.0.1-2479-g9e6256ba0f
mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux 
bootstrap-tarballs
/gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
mhw@jojen ~/guix-wip-binaries$ cd 
/gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0
mhw@jojen /gnu/store/rdwyr8mh7dvhfkb5g4cws6q40hp23rbi-bootstrap-tarballs-0$ 
sha256sum *
3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  
guile-static-stripped-2.2.4-i686-linux.tar.xz
1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  
linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  
mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  
mes-minimal-stripped-0.19-i686-linux.tar.xz
c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  
static-binaries-0-i686-linux.tar.xz
--8<---cut here---end--->8---

Do you get the same results?

To match what 'core-updates-next' expects, it would be good to upload
the files above, along with digital signatures, to the following new
directory:

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

>> Ricardo: can you instruct Cuirass to add a reduced jobset for
>> 'core-updates-next', that only builds builds the "core" package subset?
>
> Should be ready now:
>
>   https://ci.guix.gnu.org/jobset/core-updates-next

Thank you.

> However, evaluation fails with:
>
> Backtrace:
> In guix/packages.scm:
>   1188:25 19 (bag->derivation # # ?)
> In srfi/srfi-1.scm:
>592:29 18 (map1 (("source" #http://fossies.org/lin?>) ?))
>592:17 17 (map1 (("bash" #) ?))
> In guix/packages.scm:
>979:16 16 (expand-input # # ?)
>936:16 15 (cache! # # ?)
>   1255:22 14 (thunk)
>   1188:25 13 (bag->derivation # # ?)
> In srfi/srfi-1.scm:
>592:29 12 (map1 (("source" #) ?))
>592:17 11 (map1 (("gcc" #) ?))
> In guix/packages.scm:
>979:16 10 (expand-input # # ?)
>936:16  9 (cache! # # ?)
>   1255:22  8 (thunk)
>   1188:25  7 (bag->derivation # # ?)
> In srfi/srfi-1.scm:
>592:29  6 (map1 (("source" #) ?))
>

bug#34902: Guix cannot find a module on boot

[Julien Lepiller]

Hi Ludo,

Your patch has a LGTM, but I don't see it on master. Would you like to push it, 
or is there a reason why you didn't do it yet?

Thanks!

bug#36781: Website manual generation stopped

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> Le Fri, 26 Jul 2019 00:54:32 +0200,
> Ludovic Courtès  a écrit :

[...]

>> Indeed it fails like this:
>> 
>> --8<---cut here---start->8---
>> ludo@berlin ~$ sudo su - static-web-site
>> -c /gnu/store/9w4bbd6gqya2g9zvwgs6qab6aqgbjbd3-update-guix-manual-devel
>> Backtrace: 7 (primitive-load
>> "/gnu/store/9w4bbd6gqya2g9zvwgs6qab6aqg…") In ice-9/eval.scm:
>> 619:8  6 (_ #f)
>>626:19  5 (_ #)
>> In unknown file:
>>4 (_ # #<…>
>> …) In guix/git.scm:
>>240:29  3 (update-cached-checkout "https://git.sv.gnu.org/git/gu…;
>> …) In ice-9/boot-9.scm:
>> 841:4  2 (with-throw-handler _ _ _)
>> In git/clone.scm:
>>  41:8  1 (_ _ _ _)
>> In ice-9/boot-9.scm:
>>752:25  0 (dispatch-exception _ _ _)
>> 
>> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
>> Git error: cross host redirect not allowed
>> --8<---cut here---end--->8---
>> 
>> So I think we have to change the repo URL in berlin.scm.
>> 
>> Ludo’.
>
> One way I can see to solve that issue is to specify a custome cache
> directory name, instead of the default one, which is a hash of the url.
> The reason why we use git.sv.gnu.org instead of git.savannah.gnu.org
> is that otherwise both repos have the same cache directory, so one wins
> over the other. But that hack doesn't scale if we want to generate more
> than two manual versions.
>
> Attached is a patch that adds a cache-directory field to the
> static-website-configuration record.

OK.

> Another solution is to fix (guix git) to also add the ref as part of
> the hash, so the cache directory is different for two different
> branches of the same repository.

I thought about doing that.  It’d work but it’d also be slightly
wasteful since branches of a repo typically have a lot in common.

Another option would be to compute the cache directory name like you
write, but only in the (sysadmin web) module.

WDYT?

Thanks,
Ludo’.

bug#36942: Reconfigure broke GRUB

[Jakob L. Kreuze]

ison  writes:

> Sorry it took me so long to reply, I didn't have access to the broken
> machine until now.

No worries :)

> As you requested here is the partitions as listed by parted:
>
> Number  Start   End SizeFile system NameFlags
>  1  1049kB  3046kB  2097kB  grubbios_grub
>  2  3146kB  540MB   537MB   fat32   efi boot, esp
>  3  540MB   2588MB  2048MB  linux-swap(v1)  swap
>  4  2588MB  750GB   748GB   ext4guixsd

Hm. Nearly the same as what I had, though my partitions had different
sizes and I didn't have a swap partition. I may try again with this
exact setup when I get back to the United States just to see what
happens.

> /boot/efi looks ok as far as I can tell at least. It's tree is:
> /boot/efi/
> └── EFI
> ├── grub
> │   └── grubx64.efi
> ├── Guix
> │   └── grubx64.efi
> └── GuixSD
> └── grubx64.efi
> All 3 grubx64.efi files differ from each other and are around 120kb.

Interesting... I only have '/boot/efi/EFI/Guix'. Do you have a
'/boot/grub'?

> But considering you can't reproduce the issue would it be a good
> idea for me to reinstall and see if I can even reproduce it?
> Although I think this time I would leave off the bios_grub partition
> I'm willing to keep testing the current bug if it's important or
> indicative of a more serious problem. But please don't feel
> obligated to keep working on this just for me, I'm perfectly fine
> just reinstalling. The issue doesn't seem to affect my desktop
> anyway, I was able to upgrade it smoothly.
>
> It's always possible the issue was caused by some strange
> combination involving the patched bug, from earlier in the
> discussion, and my weird partition layout. Might not even be worth
> investigating unless it happens to someone else
> (or me again after a fresh install).

I think it may be indicative of a more serious problem, since you
mentioned that this was fine up until the commit refactoring 'guix
system reconfigure'. If you're willing to reinstall and see if you can
reproduce it, that maywould be helpful -- you could send me the relevant
'install-bootloader.scm' store item if it breaks again.

Thank you very much, ison. I appreciate your cooperation here greatly.

Regards,
Jakob


signature.asc
Description: PGP signature

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

[Ludovic Courtès]

Hello,

Marius Bakke  skribis:

> Mark H Weaver  writes:

[...]

>> I think what needs to be done is the following:
>>
>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>> should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>
>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>> of , along
>> with digital signatures, of course.  I'm talking about these in
>> particular:
>>
>> 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  
>> guile-static-stripped-2.2.4-i686-linux.tar.xz
>> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  
>> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  
>> mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  
>> mes-minimal-stripped-0.19-i686-linux.tar.xz
>> c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  
>> static-binaries-0-i686-linux.tar.xz
>>
>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>> should be updated to use the new binaries above:
>>
>>  (a) %bootstrap-linux-libre-headers
>>  (b) %bootstrap-mescc-tools
>>  (c) %bootstrap-mes
>>
>> (4) Berlin should start rebuilding 'core-updates'.
>>
>> If desired, steps (3) and (4) could come before (2) if someone
>> temporarily uploads the new binaries somewhere else, and adjusts
>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>> names to match what we've agreed on here, as I listed in (2) above.
>>
>> What do you think?
>
> Thank you for the excellent summary.  I can look into adjusting the bash
> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
> do this in a 'core-updates-next' branch.  I would also like to merge
> wip-binaries into it as a final step, unless someone has objections.
>
> Ludovic should be back in a couple of days and can hopefully take care
> of the uploads.

I haven’t quite caught up yet, but I trust you and I can upload the
files that Mark mentions above to ftp.gnu.org this time (Ricardo should
also be able to upload them, if needed.)

How can I reproduce them or fetch them?

> Ricardo: can you instruct Cuirass to add a reduced jobset for
> 'core-updates-next', that only builds builds the "core" package subset?

Should be ready now:

  https://ci.guix.gnu.org/jobset/core-updates-next

However, evaluation fails with:

--8<---cut here---start->8---
Backtrace:
In guix/packages.scm:
  1188:25 19 (bag->derivation # # ?)
In srfi/srfi-1.scm:
   592:29 18 (map1 (("source" #http://fossies.org/lin?>) ?))
   592:17 17 (map1 (("bash" #) ?))
In guix/packages.scm:
   979:16 16 (expand-input # # ?)
   936:16 15 (cache! # # ?)
  1255:22 14 (thunk)
  1188:25 13 (bag->derivation # # ?)
In srfi/srfi-1.scm:
   592:29 12 (map1 (("source" #) ?))
   592:17 11 (map1 (("gcc" #) ?))
In guix/packages.scm:
   979:16 10 (expand-input # # ?)
   936:16  9 (cache! # # ?)
  1255:22  8 (thunk)
  1188:25  7 (bag->derivation # # ?)
In srfi/srfi-1.scm:
   592:29  6 (map1 (("source" #) ?))
   592:17  5 (map1 (("texinfo" #) ?))
In guix/packages.scm:
   979:16  4 (expand-input # # ?)
   936:16  3 (cache! # # ?)
  1255:22  2 (thunk)
  1188:25  1 Exception thrown while printing backtrace:
Throw to key `srfi-34' with args `(#)'.

srfi/srfi-1.scm:592:17: In procedure map1:
Throw to key `srfi-34' with args `(#)'.
--8<---cut here---end--->8---

Am I missing something?

Ludo’.

bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:
>
>> Mark H Weaver  writes:
>>
 Mark: are the armhf nodes still operational?
>>>
>>> I assume so.  They all respond to pings anyway, and I haven't touched
>>> them since before they were disconnected from Berlin.  (I would need to
>>> boot up my other, more secure computer to try SSHing into them).
>>>
 I would like to re-enable them again, since we desperately need the
 computing power with four huge branches going concurrently at the
 moment.
>>>
>>> I have no objection, but since Ludovic made the decision to disconnect
>>> them, it would be good to hear from him first.
>>
>> Now that we should be able to SSH to them directly from Berlin we can
>> try connecting and perhaps upgrading the guix-daemon on these machines.
>
> I have removed the SSH tunnel configuration from /etc/guix/machines.scm
> and re-enabled the machines.
>
> Let’s see if this makes any difference.

Is it working well now?

> If not we should try to upgrade Guix on these build machines.

I think there’s a misunderstanding: these machines used to run a very
old Guix but I installed 1.0 from scratch before migrating them to
berlin.

Thanks,
Ludo’.

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

[Mark H Weaver]

Hi Marius,

Earlier I wrote:

> Marius Bakke  writes:
>> I can look into adjusting the bash fix for 5.0, and updating the
>> bootstrap binary URLs and hashes.
>
> I've attached preliminary untested patches for these.  I'm testing them
> now.

I pushed those two commits to 'core-updates-next', and am currently
building out that branch on my X200.  So far I've successfully built the
core packages and 'hello', and am now continuing on to build the rest of
my Guix system.

Anyway, I'm long past the point where the slight differences made to the
new bootstrap binaries to make them deterministic should have any
effects, so I think it's fairly safe to predict that these commits will
not introduce new problems.

Marius Bakke  wrote:
> Ricardo: can you instruct Cuirass to add a reduced jobset for
> 'core-updates-next', that only builds builds the "core" package subset?

For now, I did as you suggested and pushed the commits to
'core-updates-next', although personally I'd be inclined to simply push
them to 'core-updates', after the new bootstrap binaries have either
been uploaded or manually added to Berlin's store.

What do you think?

  Mark

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

[Björn Höfling]

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


pgpTeO0dfiXBm.pgp
Description: OpenPGP digital signature