Subject: Re: bug#32895: file progress reporter crashes on small files

From: [email-masked] (Ludovic Courtès)
Date: Thu, 04 Oct 2018 10:31:07 +0200

Hi,

[email-masked] (Ludovic Courtès) skribis:

> Ricardo Wurmus <[email-masked]> skribis:
>
>> Ludovic Courtès <[email-masked]> writes:
>>
>>> Hello,
>>>
>>> Ricardo Wurmus <[email-masked]> skribis:
>>>
>>>> guix/progress.scm:214:25: In procedure display-download-progress:
>>>> In procedure /: Wrong type argument in position 1: #f
>>>>
>>>> This happens because “transferred” in the “else” branch of (@ (guix
>>>> progress) display-download-progress) is #f instead of a number.  This
>>>> could be the result of running string->number on an invalid string in
>>>> “print-build-event”.
>>>
>>> Indeed, that seems to be the case.  This would mean we’re emitting an
>>> incorrect build trace.
>>>
>>> Do you have the exact command to reproduce it?
>>
>> Unfortunately, I don’t.
>
> Or do you have the log around?  If you run, say:
>
>   grep -r "download-progress .*#f" /var/log/guix/drvs
>
> ?

Turns out I stumbled upon this bug by change.  The traces I was getting
were:

--8<---------------cut here---------------start------------->8---
@ download-progress /gnu/store/2chkmisij4373sb8sf07by0zkcikl4ki-opencv-extra-3.4.3.zip https://codeload.github.com/opencv/opencv_extra/zip/3.4.3 - 472383488
@ download-progress /gnu/store/2chkmisij4373sb8sf07by0zkcikl4ki-opencv-extra-3.4.3.zip https://codeload.github.com/opencv/opencv_extra/zip/3.4.3 - 478478336
@ download-progress /gnu/store/2chkmisij4373sb8sf07by0zkcikl4ki-opencv-extra-3.4.3.zip https://codeload.github.com/opencv/opencv_extra/zip/3.4.3 - 484704256
@ download-progress /gnu/store/2chkmisij4373sb8sf07by0zkcikl4ki-opencv-extra-3.4.3.zip https://codeload.github.com/opencv/opencv_extra/zip/3.4.3 - #f
@ download-succeeded /gnu/store/2chkmisij4373sb8sf07by0zkcikl4ki-opencv-extra-3.4.3.zip https://codeload.github.com/opencv/opencv_extra/zip/3.4.3 487641438
--8<---------------cut here---------------end--------------->8---

The next-to-last one was incorrect.

This is fixed in 1d0be47ab680db938ac8da1ee65e1de91e198f67.  I’ll push an
update of the ‘guix’ package so we get an updated daemon with the fix
(for the “builtin:download” derivations.)

Thanks,
Ludo’.