bug#39575: guix time-machine fails when a tarball was modified in-place

[Jan Nieuwenhuizen]

zimoun writes:

Hi Simon,

> On Fri, 14 Feb 2020 at 14:24, Jan Nieuwenhuizen  wrote:
>
> This command
>
>> >>  $ guix download -o /tmp/harfbuzz-old.tar.bz2 \
>> >>  
>> >> https://ci.guix.gnu.org/file/harfbuzz-2.4.0.tar.bz2/sha256/1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch
>
> now works.
>
>
> However, this command
>
> $ guix time-machine \
>  --commit=56e95d54d209c2428f970d65d9b27ae4168449ad -- help
>
> still fails for me with the message:
>
> [...]
> building /gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv...
> - 'check' phasebuilder for
> `/gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv' failed
> with exit code 1
> build of /gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv failed
> View build log at
> '/var/log/guix/drvs/gg/lbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv.bz2'.
> cannot build derivation
> `/gnu/store/yqpxm07zm0mirrdvl2c4qvf8biyzg468-guix-56e95d54d.drv': 1
> dependencies couldn't be built
> cannot build derivation
> `/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv': 1
> dependencies couldn't be built
> guix time-machine: error: build of
> `/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv' failed
>
> The log 
> /var/log/guix/drvs/gg/lbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv.bz2
> is not meaningful for me... but I can report it here.
>
>
>> that i'm trying now, and for now it looks fine (lots of stuff to build,
>> i'll report success or failure when it's done).
>
> Well, is it a success or a failure for you?

For me, pythohn-minimal fails to build

build-started 
/gnu/store/s0lw23myd3hvpw28sffkhz8b30x1hcz0-python-minimal-3.7.3.drv - 
x86_64-linux 
/var/log/guix/drvs/s0//lw23myd3hvpw28sffkhz8b30x1hcz0-python-minimal-3.7.3.drv.bz2
 20827

==
FAIL: test_register_chain (test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
  File 
"/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_faulthandler.py",
 line 724, in test_register_chain
self.check_register(chain=True)
  File 
"/tmp/guix-build-python-minimal-3.7.3.drv-0/Python-3.7.3/Lib/test/test_faulthandler.py",
 line 702, in check_register
self.assertEqual(exitcode, 0)
AssertionError: -11 != 0

--

Ran 42 tests in 18.782s

FAILED (failures=1, skipped=4)
1 test failed again:
test_faulthandler

== Tests result: FAILURE then FAILURE ==

382 tests OK.

1 test failed:
test_faulthandler

Not sure what to do here.  Could this be a (harmless) coincident?

Greetings
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#39677: Evolution's inbox widget is blank

[raingloom]

I've been haunted by this for months, so it's high time I make a proper 
bug report.


I wiped all Evolution related directories I could find in .cache, 
.config, and .local, and reconfigured it from scratch, but that didn't 
help.


When I open Evolution it prompts me for my password and pulls my emails 
without a problem, even shows a notification for them, but it doesn't 
display anything.


It's not a font issue, because the scroll bar does not appear. There 
are no emails displayed at all. Double clicking on it should open a 
mail in a new window, but no window appears.


I tried it in a VM that's a slight modification of my system, that had 
no problems.

I also tried it in both i3wm and Gnome, but the results are identical.

All I see in the log is this:
```
(evolution:23706): GLib-GIO-WARNING **: 15:17:11.805: Your application 
did not unregister from D-Bus before destruction. Consider using 
g_application_run().

```

I can send an strace log if necessary. The one I took was a bit long 
and didn't reveal much, but someone might have better luck.


Any tips on where I should look?

I suspect that it either doesn't play nice with some other package or 
that there is some state corruption I couldn't track down.


For now I'll just use Geary for this account.

bug#39023: binary installation manual doesn't work on Alpine Linux

[zimoun]

Hi,

I am a bit confused. At the end, what is the fix?

>From my knowledge, 'useradd/groupadd ' are the standard commands. The
other ones, not.

Personally, I am in favour of the option a/ that is described here
[1]: write in the manual in a footnote it should be adapted for the
underlining distro, i.e., mention 'adduser/addgroup'.
Tobias mentioned [2] an option /d: provide in addition of the existing
one a complete example using 'adduser/addgroup'.
But then Tobias sent this message [3] explaining that BusyBox is doing
wrong. ;-) Which IMHO leads to the option a/. :-)

What is the consensus for the bug?

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023#11
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023#17
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023#26


All the best,
simon

bug#25031: Hunting #25031: Recovery from sleep/hibernate is broken

[Nikolai Merinov]

Hi Zimon,

I have no access to the laptop with this issue anymore. My current
laptop works fine with actual GNU GUIX distribution.

Currently it impossible to extract additional info and bug can be
closed.

Regards,
Nikolai

zimoun  writes:

> Dear,
>
> The bug #25031 is 3 years old [1] with the tag 'moreinfo'.
> What is the status?
> Does it still make sense with a recent Guix version?
>
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25031
>
> All the best,
> simon

bug#25031: Hunting #25031: Recovery from sleep/hibernate is broken

[zimoun]

Dear,

On Wed, 19 Feb 2020 at 19:39, Nikolai Merinov
 wrote:

> I have no access to the laptop with this issue anymore. My current
> laptop works fine with actual GNU GUIX distribution.
>
> Currently it impossible to extract additional info and bug can be
> closed.

Thank you for your reply.
So  I am closing this bug.
Feel free to reopen the bug if you have access to the laptop again.


All the best,
simon

bug#39671: Linux-Libre 5.4.20 breaks Display Sessions

[Raghav Gururajan]

Hello Guix!

After my system reconfigure, GDM didn't start. During boot, I saw "New
gdm session c1" followed by "Session c1 removed".

For me, the last known commit to work properly is "41884bf". Anything
after that breaks my system.

Regards,
RG.


signature.asc
Description: This is a digitally signed message part

bug#39671: Something appears to disable linux kernel modules from loading.

[Ludovic Courtès]

Hi!

Joshua Branson  skribis:

> After I rebooted sway refused to start.  The sway error message said
>
> #+BEGIN_SRC sh
> $ sway
>
> [backend/backend.c:339] Failed to open any DRM device.
> [sway/server.c] Unable to create backend.
> #+END_SRC
>
>
> So sway is not starting.  I believe this is because my i915 intel
> driver is not loaded.  I know this is the case, because the text on my
> virtual console is LARGE.  $ sudo modprobe i915 loads the required
> driver. And I can now log into sway.
>
> However, my ethernet driver is not loaded.

On IRC, tsmish posted this bisect log:

--8<---cut here---start->8---
 1 git bisect start 

 2 # bad: [bfb6c393b91dc4a236678a0682348d5b7bd77193] gnu: gwl: Build with Guile 
3.  
 3 git bisect bad bfb6c393b91dc4a236678a0682348d5b7bd77193  

 4 # good: [d98f7fdabe27f3441f317af3e7f5a979edf5d741] remove sane-backends from 
wine inputs for now 
 5 git bisect good d98f7fdabe27f3441f317af3e7f5a979edf5d741 

 6 # good: [505b2631a9c35bbaa5ba6771ad4f646086f23cad] gnu: le-certs: Update 
input hashes.   
 7 git bisect good 505b2631a9c35bbaa5ba6771ad4f646086f23cad 

 8 # bad: [b4e0166e2d7d9d4b57e1caeb026936f957858ec9] gnu: Add rust-quasi-0.32.  

 9 git bisect bad b4e0166e2d7d9d4b57e1caeb026936f957858ec9  

10 # bad: [d46646d9c772fb699ca24a56f815695eecdcb513] gnu: python-blinker: Use 
HTTPS home page.  
11 git bisect bad d46646d9c772fb699ca24a56f815695eecdcb513  

12 # good: [9469ab532fe561b8bb679ba8bf08f1c1f5f9374a] gnu: ddclient: Update 
home page.  
13 git bisect good 9469ab532fe561b8bb679ba8bf08f1c1f5f9374a 

14 # good: [3603f5536ee0223f2e15ca6c518ab922030646dd] gnu: wabt: Use Texinfo 
mark-up.   
15 git bisect good 3603f5536ee0223f2e15ca6c518ab922030646dd 

16 # bad: [205c1e04e04b9a9338c7219ff82bd13f000fb8c8] gnu: shepherd: Update to 
0.7.0.
17 git bisect bad 205c1e04e04b9a9338c7219ff82bd13f000fb8c8  

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

What does “cat /proc/sys/kernel/modprobe” return on the broken system?

I would expect 8b9cad01e9619f53dc5a65892ca6a09ca5de3447 to be suspect #1
because it potentially leads to ‘LINUX_MODULE_DIRECTORY’ being unset in
places where it used to be set before.

> Man I love guix system.  It really does work smoothly, even when you
> have problems.  So thanks for making a great GNU/Linux distro!

Heh.  :-)

Ludo’.

bug#39671: Something appears to disable linux kernel modules from loading.

[Jack Hill]

On Wed, 19 Feb 2020, Ludovic Courtès wrote:


What does “cat /proc/sys/kernel/modprobe” return on the broken system?


/gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe

The contents of that file are:

"""
#!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile 
--no-auto-compile
!#
(begin (setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules")
   (apply execl "/run/current-system/profile/bin/modprobe"
(cons "/run/current-system/profile/bin/modprobe" (cdr 
(command-line)
"""


I would expect 8b9cad01e9619f53dc5a65892ca6a09ca5de3447 to be suspect #1
because it potentially leads to ‘LINUX_MODULE_DIRECTORY’ being unset in
places where it used to be set before.


Based on the commit message, I would have expected that too, but 
205c1e04e04b9a9338c7219ff82bd13f000fb8c8 is the first bad commit for me as 
well. The above modprobe script is from a system at commit 
8b9cad01e9619f53dc5a65892ca6a09ca5de3447.


Best,
Jack

bug#39671: Something appears to disable linux kernel modules from loading.

[Ludovic Courtès]

Jack Hill  skribis:

> On Wed, 19 Feb 2020, Ludovic Courtès wrote:
>
>> What does “cat /proc/sys/kernel/modprobe” return on the broken system?
>
> /gnu/store/daq5zs7ni529zh3xxgyhidna52wa17js-modprobe
>
> The contents of that file are:
>
> """
> #!/gnu/store/1mkkv2caiqbdbbd256c4dirfi4kwsacv-guile-2.2.6/bin/guile 
> --no-auto-compile
> !#
> (begin (setenv "LINUX_MODULE_DIRECTORY" 
> "/run/booted-system/kernel/lib/modules")
>(apply execl "/run/current-system/profile/bin/modprobe"
> (cons "/run/current-system/profile/bin/modprobe" (cdr 
> (command-line)
> """

The kernel’s lazy module loading mechanism invokes this program, which
should just work.

Does /run/current-system/profile/bin/modprobe exist?

Any hints in “dmesg” or /var/log/messages?

Thanks,
Ludo’.

bug#39681: Manual typo in section "Invoking ‘guix time-machine’"

[Jack Hill]

Tags: easy

Hello Guix,

In the manual section 4.8, "Invoking ‘guix time-machine’", I believe that 
"are passed unmodified to the ‘guix’ command if the specified revision," 
would read better if it said, "to the ‘guix’ command of the specified 
revision."


I've filed this as a bug like #39417 as an easy task for Outreachy 
applicants. Let me know if a patch would be preferred.


Best,
Jack

bug#39671: Something appears to disable linux kernel modules from loading.

[Jack Hill]

On Wed, 19 Feb 2020, Ludovic Courtès wrote:


The kernel’s lazy module loading mechanism invokes this program, which
should just work.

Does /run/current-system/profile/bin/modprobe exist?


Yes, it is a symlink to 
/gnu/store/d064bv2b1hrb07j2zj78i608db7qldx9-kmod-26/bin/modprobe



Any hints in “dmesg” or /var/log/messages?


Not that jump out at me. I do see

udevd[197]: no sender credentials received, message ignored

printed in red, but that message also appears when everything is working 
correctly.


The full dmesg output is attached. The bit at the end about e1000e was 
after I manually ran `modprobe e1000e`.


Best,
Jack[0.00] Linux version 5.4.20-gnu (nixbld@) (gcc version 7.4.0 (GCC)) #1 
SMP 1
[0.00] Command line: 
BOOT_IMAGE=/gnu/store/ac81pphwdj1brvkyrf6vx0mnmcad8qy4-linux-libre-5.4.20/bzImage
 --root=guix-root --system=/var/guix/profiles/system-17-link 
--load=/var/guix/profiles/system-17-link/boot quiet
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Hygon HygonGenuine
[0.00]   Centaur CentaurHauls
[0.00]   zhaoxin   Shanghai  
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e3ff] usable
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcf3ff7ff] usable
[0.00] BIOS-e820: [mem 0xcf3ff800-0xcf453bff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcf453c00-0xcf455bff] ACPI data
[0.00] BIOS-e820: [mem 0xcf455c00-0xcfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed2-0xfed9] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfeef] reserved
[0.00] BIOS-e820: [mem 0xffb0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000127ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: Dell Inc. OptiPlex 755 /0PU052, BIOS A04 
11/05/2007
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2327.633 MHz processor
[0.003825] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.003827] e820: remove [mem 0x000a-0x000f] usable
[0.003834] last_pfn = 0x128000 max_arch_pfn = 0x4
[0.003841] MTRR default type: uncachable
[0.003843] MTRR fixed ranges enabled:
[0.003844]   0-9 write-back
[0.003846]   A-B uncachable
[0.003847]   C-C write-protect
[0.003848]   D-E uncachable
[0.003849]   F-F write-protect
[0.003850] MTRR variable ranges enabled:
[0.003852]   0 base 0 mask 0 write-back
[0.003854]   1 base 0CF60 mask FFFE0 uncachable
[0.003855]   2 base 0CF80 mask FFF80 uncachable
[0.003857]   3 base 0CF50 mask 0 uncachable
[0.003858]   4 base 0D000 mask FF000 uncachable
[0.003860]   5 base 0E000 mask FE000 uncachable
[0.003861]   6 disabled
[0.003862]   7 disabled
[0.005901] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.006047] total RAM covered: 64757M
[0.006291]  gran_size: 64K  chunk_size: 64K num_reg: 8  lose 
cover RAM: 60G
[0.006294]  gran_size: 64K  chunk_size: 128Knum_reg: 8  lose 
cover RAM: 60G
[0.006295]  gran_size: 64K  chunk_size: 256Knum_reg: 8  lose 
cover RAM: 60G
[0.006297]  gran_size: 64K  chunk_size: 512Knum_reg: 8  lose 
cover RAM: 60G
[0.006299]  gran_size: 64K  chunk_size: 1M  num_reg: 8  lose cover RAM: 
60G
[0.006300]  gran_size: 64K  chunk_size: 2M  num_reg: 8  lose cover RAM: 
61439M
[0.006302]  gran_size: 64K  chunk_size: 4M  num_reg: 8  lose cover RAM: 
61438M
[0.006304]  gran_size: 64K  chunk_size: 8M  num_reg: 8  lose cover RAM: 
61438M
[0.006305]  gran_size: 64K  chunk_size: 16M num_reg: 8  lose 
cover RAM: 48G
[0.006307]  gran_size: 64K  chunk_size: 32M num_reg: 8  lose 
cover RAM: 48G
[0.006308]  gran_size: 64K  chunk_size: 64M num_reg: 8  lose 
cover RAM: 48G
[0.006310]  gran_size: 64K  chunk_size: 128Mnum_reg: 8  lose 
cover RAM: 48G
[0.006311]  gran_size: 64K  chunk_size: 256Mnum_reg: 8  lose 
cover RAM: 48G
[0.006313]  gran_size: 64K  chunk_size: 512Mnum_reg: 8  lose 
cover RAM: 56G
[0.006314]  gran_size: 64K  chunk_size: 1G  num_reg: 8  lose cover RAM: 
48G
[0.006316]  gran_size: 64K  chunk_size: 2G  num_reg: 8  lose cover RAM: 
48G
[0.006317]  gran_size: 128K chunk_size: 128Knu

bug#23072: Hunting#23072: GuixSD SSD install hangs at clocksource

[zimoun]

On Tue, 18 Feb 2020 at 17:00, zimoun  wrote:
> On Tue, 18 Feb 2020 at 16:56, my glc2  wrote:

> > I don't know. i haven't changed drive config since 2017, or, for that 
> > matter, upgraded since 2018.
>
> Ok.
> Keep in touch if you change something. :-)
>
> (I am in the process of triaging old bugs ;-))

For the record,  line above why the bug is still open.

bug#39607: GRUB module all_video required to get video on 4K monitor

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Hello,
>
> I installed Guix System on a new machine, which displays on a 4K (3840 x
> 2160 pixels) monitor.
>
> Unless I go to the GRUB command prompt with 'c' at boot and type 'insmod
> all_video', the video cuts early after booting a GRUB entry with 'No
> suitable video mode found', or similar.
>
> I think we should include this GRUB module in our default GRUB
> package/configuration.
>
> Maxim

I think the attached patches fixes this issue, and makes the
GRUB configuration a bit simpler too!

>From 115cc43361c72b3bae0d89e03f328e4383d9e9be Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Wed, 19 Feb 2020 15:35:46 -0500
Subject: [PATCH 1/2] bootloader: grub: Use the all_video module in graphic
 mode.

Fixes .

* gnu/bootloader/grub.scm (eye-candy): Load the module 'all_video'
which automatically loads all the available and relevant video
modules.
---
 gnu/bootloader/grub.scm | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 3ec960abd8..c1cee78a16 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -163,21 +163,8 @@ system string---e.g., \"x86_64-linux\"."
(string-append "set gfxmode=" (string-join gfxmode ";"))
"# Leave 'gfxmode' to 'auto'."))
  "
-  insmod video_bochs
-  insmod video_cirrus
+  insmod all_video
   insmod gfxterm
-
-  if [ \"${grub_platform}\" == efi ]; then
-# This is for (U)EFI systems (these modules are unavailable in the
-# non-EFI GRUB.)  If we don't load them, GRUB boots in \"blind mode\",
-# which isn't convenient.
-insmod efi_gop
-insmod efi_uga
-  else
-# These are specific to non-EFI Intel machines.
-insmod vbe
-insmod vga
-  fi
 ")
 ""))
 
-- 
2.25.0

>From 5892917e2e56535deba9579a3013b54177fadc57 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Wed, 19 Feb 2020 15:59:06 -0500
Subject: [PATCH 2/2] bootloader: grub: Refactor eye-candy a bit.

* gnu/bootloader/grub.scm (eye-candy)[setup-gfxterm-body]: Define the GFXMODE
binding using AND-LET* instead of chained AND=>.  Add a comment about
supporting graphical mode on other systems than x86. Generate configuration
string using FORMAT rather than STRING-APPEND.
---
 gnu/bootloader/grub.scm | 37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index c1cee78a16..d81e990cea 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -36,6 +36,7 @@
   #:use-module (ice-9 match)
   #:use-module (ice-9 regex)
   #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-2)
   #:export (grub-image
 grub-image?
 grub-image-aspect-ratio
@@ -149,24 +150,26 @@ STORE-MOUNT-POINT is its mount point; these are used to determine where the
 background image and fonts must be searched for.  SYSTEM must be the target
 system string---e.g., \"x86_64-linux\"."
   (define setup-gfxterm-body
-;; Intel and EFI systems need to be switched into graphics mode, whereas
-;; most other modern architectures have no other mode and therefore don't
-;; need to be switched.
-(if (string-match "^(x86_64|i[3-6]86)-" system)
-(string-append
- "
-"
- (let ((gfxmode (and=>
- (and=> config bootloader-configuration-theme)
- grub-gfxmode)))
-   (if gfxmode
-   (string-append "set gfxmode=" (string-join gfxmode ";"))
-   "# Leave 'gfxmode' to 'auto'."))
- "
+(let ((gfxmode
+   (or (and-let* ((theme (bootloader-configuration-theme config))
+  (gfxmode (grub-gfxmode theme)))
+ (string-join gfxmode ";"))
+   "auto")))
+
+  ;; Intel and EFI systems need to be switched into graphics mode, whereas
+  ;; most other modern architectures have no other mode and therefore
+  ;; don't need to be switched.
+
+  ;; XXX: Do we really need to restrict to x86 systems?  We could imitate
+  ;; what the GRUB default configuration does and decide based on whether
+  ;; a user provided 'gfxterm' in the terminal-outputs field of their
+  ;; bootloader-configuration record.
+  (if (string-match "^(x86_64|i[3-6]86)-" system)
+  (format #f "
+  set gfxmode=~a
   insmod all_video
-  insmod gfxterm
-")
-""))
+  insmod gfxterm~%" gfxmode)
+  "")))
 
   (define (setup-gfxterm config font-file)
 (if (memq 'gfxterm (bootloader-configuration-terminal-outputs config))
-- 
2.25.0

bug#39505: Adding filesystem utilities based on file-systems

[Maxim Cournoyer]

Hello Leo,

Leo Famulari  writes:

> As discussed in #39332 [0], it would be great if filesystem utility
> packages were added to the system profile if a file-systems entry uses
> that filesystem type.
>
> For example, btrfs-progs could be added if a btrfs filesystem was listed
> in file-systems.
>
> [0]
> https://issues.guix.info/issue/39332#3

What is the use case?  Just having btrfs utilities to manage Btrfs file
systems, or is there some problems to avoid?  I know that for NFS you
must add nfs-utils so that the util-linux provided 'mount' is able to
mount NFS shares.

If the later is the use case, perhaps we could try to hard reference to
each file system utility in util-linux, instead of having it dispatch
some tool supposed to be in the PATH?  I'm not sure how difficult that
would be, and it'd for sure increase the size of util-linux, but perhaps
the pros outweighs the cons.

Maxim

bug#39685: Error on guix-pull using the qemu image

[Eilene Tomkins-Flanagan via Bug reports for GNU Guix]

I downloaded the qemu image from 
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.1.x86_64-linux.xz. It had 
a valid signature.

After booting the machine with qemu 3.1 (I'm on debian-amber):
`qemu-system-x86_64-net user -net nic,model=virtio-enable-kvm -m 512
-device virtio-blk,drive=myhd-drive 
if=none,file=./guix-system-vm-image-1.0.1.x86_64-linux,id=myhd`

I tried installing hello for the guest user. It worked fine.

I then tried running `guix pull && guix package -u`, and received the following 
error:
```
[...]
substitute: updating substitutes from 'https://ci.guix.gnu.org'...100.0%
Backtrace:
  1 (apply-smob/1 #)

ERROR: In procedure apply-smob/1
In procedure fport_write: Broken pipe
```

On the second attempt, it failed immediately with this message:
```
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://guix.savannah.gnu.org/git/guix.git 6dde98c
Computing Guix derivation for 'x86_64-linux'.../guix pull: error: You found a 
bug: the program 
'/gnu/store/mr5q5qcwinaxy7f4cyfm08s05aj9rr6-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"6dde98c3d9e7a0385da57abedd9b41ca733acfc6"; system: "x86_64-linux";
host version: "1.0.1-1.8204295"; pull-version: 1).
Please report it by email to 
```

After asking on the IRC to find out if I'd made a mistake, they directed me to 
send in the error as the message said.

Let me know if other info is necessary for reproduction.

-Eilene

bug#39685: Error on guix-pull using the qemu image

[Gábor Boskovits]

Hello,

Eilene Tomkins-Flanagan via Bug reports for GNU Guix  ezt
írta (időpont: 2020. febr. 20., Csü 5:31):

> I downloaded the qemu image from
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.1.x86_64-linux.xz.
> It had a valid signature.
>
> After booting the machine with qemu 3.1 (I'm on debian-amber):
> `qemu-system-x86_64-net user -net nic,model=virtio-enable-kvm -m
> 512-device virtio-blk,drive=myhd-drive
> if=none,file=./guix-system-vm-image-1.0.1.x86_64-linux,id=myhd`
>

-m 512 looks a bit low.


> I tried installing hello for the guest user. It worked fine.
>
> I then tried running `guix pull && guix package -u`, and received the
> following error:
> ```
> [...]
> substitute: updating substitutes from 'https://ci.guix.gnu.org'...100.0%
> Backtrace:
>   1 (apply-smob/1 #   0 (apply-smob/1 #)
>
> ERROR: In procedure apply-smob/1
> In procedure fport_write: Broken pipe
> ```
>
> On the second attempt, it failed immediately with this message:
> ```
> Updating channel 'guix' from Git repository at '
> https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://guix.savannah.gnu.org/git/guix.git 6dde98c
> Computing Guix derivation for 'x86_64-linux'.../guix pull: error: You
> found a bug: the program
> '/gnu/store/mr5q5qcwinaxy7f4cyfm08s05aj9rr6-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "6dde98c3d9e7a0385da57abedd9b41ca733acfc6"; system: "x86_64-linux";
> host version: "1.0.1-1.8204295"; pull-version: 1).
> Please report it by email to 
> ```
>
> After asking on the IRC to find out if I'd made a mistake, they directed
> me to send in the error as the message said.
>

Could you check if the disk is full? The image is small should be resized
before use.


> Let me know if other info is necessary for reproduction.
>
> -Eilene
>

Best regards,
g_bor

>
>