bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Eric Bavier]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

In commit 20927c9331b493eaf94211ad9f8a5055e11b4588
url-fetch/tarbomb and url-fetch/zipbomb in guix/download.scm were
switched to use 'invoke' instead of 'system*'.  On core-updates this
leads for me to an error when attempting to build the source for
packages that use these fetch methods.  For example, font-text-gyre:

$ ./pre-inst-env guix build -S font-tex-gyre
The following derivation will be built:
   /gnu/store/clxzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv
@ build-started /gnu/store/clxzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv - x86_64-linux /var/log/guix/drvs/cl//xzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv.bz2
Backtrace:
           3 (primitive-load "/gnu/store/c1r3fzw5mdh9hqydm2ri2rbdsib?")
In ice-9/eval.scm:
   196:27  2 (_ #f)
   223:20  1 (proc #<directory (guile-user) 7cc140>)
In unknown file:
           0 (%resolve-variable (7 . invoke) #<directory (guile-user?>)

ERROR: In procedure %resolve-variable:
Unbound variable: invoke
note: keeping build directory `/tmp/guix-build-tg-2.005otf.zip.drv-2'
builder for `/gnu/store/clxzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv' failed with exit code 1
@ build-failed /gnu/store/clxzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv - 1 builder for `/gnu/store/clxzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv' failed with exit code 1
guix build: error: build failed: build of `/gnu/store/clxzrqzqbn182nrnkpabd8f4kqfw5bna-tg-2.005otf.zip.drv' failed
$

If I revert that commit it succeeds.  I suppose the (guix build utils)
module needs to be imported into the builder.

`~Eric

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Mark H Weaver]

Hi Eric,

Eric Bavier <ericbavier@centurylink.net> writes:

> In commit 20927c9331b493eaf94211ad9f8a5055e11b4588
> url-fetch/tarbomb and url-fetch/zipbomb in guix/download.scm were
> switched to use 'invoke' instead of 'system*'.  On core-updates this
> leads for me to an error when attempting to build the source for
> packages that use these fetch methods.

[...]

> If I revert that commit it succeeds.  I suppose the (guix build utils)
> module needs to be imported into the builder.

Indeed, you are right.  Commit 6c293a809bba57d4363517fa0bd8ebc34247c577
on core-updates should fix this problem.  Thanks for the report.

However, let's leave this bug report open for now.

The reason is that debbugs.gnu.org mishandled this report in two ways:

(1) This bug is not listed on <https://bugs.gnu.org/guix>, although
    <https://bugs.gnu.org/31187> shows it as an open bug for Guix.

(2) The original bug report was never delivered to me, although I'm
    subscribed to <bug-guix@gnu.org>.  If Eric hadn't CC'd me on his
    original submission, I might not have seen it.  I was unable to find
    out the bug number until I asked Eric directly, so unfortunately the
    commit does not reference the bug number.

I've reported these problems to the FSF sysadmins, and I'd like to give
them an opportunity to diagnose the problem before we change the status
of this bug.

      Thanks,
        Mark

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Glenn Morris]

Mark H Weaver wrote:

> (1) This bug is not listed on <https://bugs.gnu.org/guix>, although
>     <https://bugs.gnu.org/31187> shows it as an open bug for Guix.

There was a problem with the pagination. It's (now) on page 2.

> (2) The original bug report was never delivered to me, although I'm
>     subscribed to <bug-guix@gnu.org>.  If Eric hadn't CC'd me on his
>     original submission, I might not have seen it. 

I would guess that you are subscribed to bug-guix with the "filter out
duplicates" Mailman option, so it is precisely because you were cc'd
that you did not get the mailing list copy (with the bug number).

> I was unable to find out the bug number until I asked Eric directly,
> so unfortunately the commit does not reference the bug number.

(You could have searched for the bug by subject?)

If Eric had used X-Debbugs-CC instead of Cc in the initial report, the
mail you got would have included the bug number in the subject.
I believe this is well documented (eg on the "how to report a bug"
section on https://debbugs.gnu.org/).

> I've reported these problems to the FSF sysadmins, and I'd like to give
> them an opportunity to diagnose the problem before we change the status
> of this bug.

The FSF sysadmins don't maintain debbugs.gnu.org, so the help-debbugs
list would have been better. I (debbugs.gnu.org maintainer) happened to
see your mail although I don't normally read bug-guix.

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Mark H Weaver]

Hi Glenn,

Thanks very much for your informative message.  I feel embarrassed for
not noticing that there were multiple pages.  I rarely use the web
interface, and I guess the projects I've worked tend to have fewer than
400 active bugs.

Glenn Morris <rgm@gnu.org> writes:
> If Eric had used X-Debbugs-CC instead of Cc in the initial report, the
> mail you got would have included the bug number in the subject.
> I believe this is well documented (eg on the "how to report a bug"
> section on https://debbugs.gnu.org/).

Okay, I will try to remind people to use 'X-Debbugs-CC' instead of 'Cc'
in the future.

>> I've reported these problems to the FSF sysadmins, and I'd like to give
>> them an opportunity to diagnose the problem before we change the status
>> of this bug.
>
> The FSF sysadmins don't maintain debbugs.gnu.org, so the help-debbugs
> list would have been better. I (debbugs.gnu.org maintainer) happened to
> see your mail although I don't normally read bug-guix.

That was quite fortuitous.  Thanks again!

I'm closing this bug now.

      Mark

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Glenn Morris]

Mark H Weaver wrote:

> I feel embarrassed for not noticing that there were multiple pages. I
> rarely use the web interface, and I guess the projects I've worked
> tend to have fewer than 400 active bugs.

No need to feel embarrassed. :)
The results pages feature was broken for projects with 400-500 bugs,
such that bugs over 400 weren't being shown, so there was no second guix
page till I fixed it. Thanks for bringing this to light! :)

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Sat, Apr 21, 2018 at 08:29:54PM -0400, Glenn Morris wrote:
> Mark H Weaver wrote:
> 
> > I feel embarrassed for not noticing that there were multiple pages. I
> > rarely use the web interface, and I guess the projects I've worked
> > tend to have fewer than 400 active bugs.
> 
> No need to feel embarrassed. :)
> The results pages feature was broken for projects with 400-500 bugs,
> such that bugs over 400 weren't being shown, so there was no second guix
> page till I fixed it. Thanks for bringing this to light! :)

I think this is a big milestone for Guix ;)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#31187: core-updates: url-fetch/tarbomb, url-fetch/zipbomb fail with "unbound variable: invoke"

[Mark H Weaver]

Glenn Morris <rgm@gnu.org> writes:

> Mark H Weaver wrote:
>
>> I feel embarrassed for not noticing that there were multiple pages. I
>> rarely use the web interface, and I guess the projects I've worked
>> tend to have fewer than 400 active bugs.
>
> No need to feel embarrassed. :)
> The results pages feature was broken for projects with 400-500 bugs,
> such that bugs over 400 weren't being shown, so there was no second guix
> page till I fixed it. Thanks for bringing this to light! :)

Ahh, I had misunderstood.  Now I feel better.
Thanks for fixing the bug so quickly!

     Mark