ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Leo,

thanks for helping!

I'm also involving guix-devel since probably this issue must escalate
:-)

I think my specific problem is caused by the "Gateway Timeout" error
from ci.guix.info, see below for details

Leo Famulari <leo@famulari.name> writes:

[...]

> Did you authorize substitutes for ci.guix.info?
>
> https://www.gnu.org/software/guix/manual/en/html_node/Substitutes.html

not explicitly but my (user) guix accepts it by default, I was able to
install other packages with no problem, also tried again some minutes
ago and succeeded installing gnumeric

this also means that my problem installing ungoogled-chromium substitute
does not depend from my X.509 problem shown below (subsitutes are
installed via https://ci.guix.info and I'm able to install them)

still, if I try to install ungoogled-chromium on my machine, it starts
building:

--8<---------------cut here---------------start------------->8---
$ guix package -i ungoogled-chromium
substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
| 'unpack' phase
--8<---------------cut here---------------end--------------->8---

now, guix weather tell me this:

--8<---------------cut here---------------start------------->8---
$ guix weather --manifest=.ungoogled-chromium.manifest
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.info...
https://ci.guix.info
  100.0% substitutes available (1 out of 1)
  99,3 MiB of nars (compressed)
  288,3 MiB on disk (uncompressed)
  0,004 seconds per request (0,0 seconds in total)
  262,4 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

actually all https://ci.guix.info/ returns 504 "Gateway Time-out":
AFAIU this mean I'm not able to install that package (possibly others)
for some problem in the CDN

>> guix/build/download.scm:313:6: In procedure tls-wrap:
>> X.509 certificate of 'ci.guix.info' could not be verified:
>>   signer-not-found
>>   invalid
>> --8<---------------cut here---------------end--------------->8---
>
> Also, did you set up X.509 certificates for use by Guix?
>
> https://www.gnu.org/software/guix/manual/en/html_node/Application-Setup.html

ouch no :-S (I'm on foreign distro)

I've installed nss-certs (and configured my env) and now "guix weather"
does not report the above error

>> and checking the build logs it's clear my problem is lack of space in /tmp
>
> Yes, I don't know off the top of my head how much space it needs but
> since the source alone is several gigabytes I recommend 15 GB.

wow: I don't have so much space in /tmp so I have to find an alternative
:-) (i.e. grow my volume, LVM unfortunately [1])

>> please how can I set a different TMPDIR for the build process?
>
> You need to set this variable in the context of the guix-daemon:
>
> https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix_002ddaemon.html

the builder! guix-daemon is The Builder!

thanks Leo: I read that once in the manual but missed it yesterday when
I needed it :-S

in my case (I'm on Debian with systemd) I have to add an "Environment="
parameter in /etc/systemd/system/guix-daemon.service, reload the systemd
file and restart the service

kudos
Giovanni


[1] because LVM is still not fully supported by Guix

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

Hi Giovanni,

> I think my specific problem is caused by the "Gateway Timeout" error
> from ci.guix.info, see below for details

I cannot reproduce this.

-- 
Ricardo

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Mathieu Lirzin]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Giovanni,
>
>> I think my specific problem is caused by the "Gateway Timeout" error
>> from ci.guix.info, see below for details
>
> I cannot reproduce this.

I can reproduce here (on GuixSD) and like Giovanni I am unable to use
the substitutes for ‘ungoogled-chromium’.

--8<---------------cut here---------------start------------->8---
$ guix weather --manifest=foo.scm 
calcul de 1 dérivations de paquets pour x86_64-linux…
recherche de 1 éléments du dépôt sur https://ci.guix.info...
https://ci.guix.info
  100.0% substituts disponibles (1 sur 1)
  99,3 Mo de fichiers nar (compressés)
  288,3 Mo sur le disque (décompressé)
  0,003 secondes par requête (0,0 secondesen tout)
  358,9 requêtes par seconde
  « https://ci.guix.info/api/queue?nr=1000 » a renvoyé 504 ("Gateway Time-out")
$ guix package -i ungoogled-chromium
construction de /gnu/store/w54r150nj8ksyznj6b8q92fgr1n0l20h-ungoogled-chromium-72.0.3626.109.tar.xz.drv...
\  C-c C-c
--8<---------------cut here---------------end--------------->8---

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Hi Ricardo and Mathieu,

Mathieu Lirzin <mthl@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Giovanni,
>>
>>> I think my specific problem is caused by the "Gateway Timeout" error
>>> from ci.guix.info, see below for details
>>
>> I cannot reproduce this.

do you mean you are able to reach https://ci.guix.info/ without
problems?

> I can reproduce here (on GuixSD) and like Giovanni I am unable to use
> the substitutes for ‘ungoogled-chromium’.

here some detail about the connection from my network (Italy):

--8<---------------cut here---------------start------------->8---
giovanni@anemone: curl -I https://ci.guix.info/
HTTP/2 405 
server: nginx
date: Thu, 21 Feb 2019 16:51:48 GMT
x-cache: Error from cloudfront
via: 1.1 a6fa155499d42d80898e356700528797.cloudfront.net (CloudFront)
x-amz-cf-id: gx4DPKlmNJNqdVcpOWJTXgAXFpPleiZdxBz4HyYRuP-xzkZAKt7j4Q==
--8<---------------cut here---------------end--------------->8---

and from the network of one remote hosts in OVH (France):

--8<---------------cut here---------------start------------->8---
$ curl -I https://ci.guix.info/
HTTP/2 405 
server: nginx
date: Thu, 21 Feb 2019 16:53:33 GMT
x-cache: Error from cloudfront
via: 1.1 6cb5674c966cf185ca044933e4011460.cloudfront.net (CloudFront)
x-amz-cf-id: JXxc1CoqYXERBwRSu-TtvpzdgzbfJ5rBCFcJNrP779n4EG8l33VNFA==
--8<---------------cut here---------------end--------------->8---

and in Hetzner (Germany)

--8<---------------cut here---------------start------------->8---
$  curl -I https://ci.guix.info/
HTTP/2 405 
server: nginx
date: Thu, 21 Feb 2019 16:58:59 GMT
x-cache: Error from cloudfront
via: 1.1 6135f6c459dcfb7b39ddb7d01def7207.cloudfront.net (CloudFront)
x-amz-cf-id: OKRLI-rbcxr59M5HfO6eRiFHkGsFVcV8hbXiMEsmR1qZ70Pc5yrbVg==
--8<---------------cut here---------------end--------------->8---

it seems a problem affecting several geographical regions

if I can do some more testing please tell me!

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

Hi Giovanni,

>>>> I think my specific problem is caused by the "Gateway Timeout" error
>>>> from ci.guix.info, see below for details
>>>
>>> I cannot reproduce this.
>
> do you mean you are able to reach https://ci.guix.info/ without
> problems?

Yes.  I can still access it without problems with a browser.  I can also
access https://berlin.guixsd.org just fine.

Curl gives me the same kind of error, though:

--8<---------------cut here---------------start------------->8---
$ curl -I https://ci.guix.info/
HTTP/2 405 
server: nginx
date: Thu, 21 Feb 2019 18:26:49 GMT
x-cache: Error from cloudfront
via: 1.1 e83e50311ef72f016908ba58ad2e6bd8.cloudfront.net (CloudFront)
x-amz-cf-id: EeV0rybaav9_GfKT4ufwCu5orDNAlV6v11fUV_OEzze_UsjnlP2VvQ==
--8<---------------cut here---------------end--------------->8---

I don’t know what this means.

-- 
Ricardo

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Chris Marusich]

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

Hi Giovanni

I responded to your questions here:

https://lists.gnu.org/archive/html/help-guix/2019-02/msg00216.html

I replied there because I didn't see your new email thread here until
just now.  I just wanted to make sure you saw my reply.

-- 
Chris

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Alex Vong]

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

Hello everyone,

Mathieu Lirzin <mthl@gnu.org> writes:

> Hello,
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hi Giovanni,
>>
>>> I think my specific problem is caused by the "Gateway Timeout" error
>>> from ci.guix.info, see below for details
>>
>> I cannot reproduce this.
>
> I can reproduce here (on GuixSD) and like Giovanni I am unable to use
> the substitutes for ‘ungoogled-chromium’.
>
I think the problem is not specific to 'ungoogled-chromium', because I
can reproduce it on the manifest containing all the packages I am using:


scheme@(emacs-guix)> (guix-command "weather" "--manifest=/home/alexvong1995/manifest/manifest")
computing 675 package derivations for x86_64-linux...
looking for 810 store items on https://ci.guix.info...
https://ci.guix.info
  92.5% substitutes available (749 out of 810)
  1,901.5 MiB of nars (compressed)
  7,294.0 MiB on disk (uncompressed)
  0.001 seconds per request (0.7 seconds in total)
  1,118.6 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Chris Marusich]

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

Giovanni Biscuolo <g@xelera.eu> writes:

> $ guix weather --manifest=.ungoogled-chromium.manifest
> computing 1 package derivations for x86_64-linux...
> looking for 1 store items on https://ci.guix.info...
> https://ci.guix.info
>   100.0% substitutes available (1 out of 1)
>   99,3 MiB of nars (compressed)
>   288,3 MiB on disk (uncompressed)
>   0,004 seconds per request (0,0 seconds in total)
>   262,4 requests per second
>   'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
>
> actually all https://ci.guix.info/ returns 504 "Gateway Time-out":
> AFAIU this mean I'm not able to install that package (possibly others)
> for some problem in the CDN

Summary: A Cuirass API is failing, but substitutes are available.  The
CDN is not the problem.  I'll explain more below.

The 504 error comes from berlin, not the CDN.  If you access
berlin.guixsd.org directly when the 504 occurs, I think you'll see a 504
from there, too.  The CDN is merely forwarding you the 504 it got from
berlin.  I've observed this behavior multiple times in the past.  The
next time this happens, try viewing the offending location via berlin
directly in your browser:

https://berlin.guixsd.org/api/queue?nr=1000

I think you'll find that berlin, not the CDN, returns the 504 error.  To
understand why berlin.guixsd.org returns a 504, we would need someone to
investigate more on the server side.  I don't know if anyone understands
why this happens; I don't have access to investigate berlin, myself.

In any case, the 504 for the /api/queue path doesn't imply that
substitutes are unavailable.  Indeed, your "guix weather" output states
that the 1 substitute you were looking for was in fact available.  How
can this be?  Well, both Cuirass and "guix publish" are served through a
front-end NGINX web server, which confuses matters a little.  The name
berlin.guixsd.org resolves to that NGINX web server.  That NGINX web
server forwards requests to their appropriate destination ("guix
publish" or Cuirass) depending on the path.  Substitutes are served from
"guix publish" via one set of paths (e.g., /nar/gzip/<store-item>), and
Cuirass resources are served from Cuirass via a different set of paths
(e.g., "/api/queue").  It's possible for a Cuirass path to fail even
though the "guix publish" paths are working just fine.  This is because
"guix publish" and Cuirass are not the same thing, even though they are
served via the same domain name.

What I'm trying to say is that the 504 doesn't mean substitutes are
unavailable.  However, it does suggest a problem with Cuirass or its
dependencies.  When you run commands that fetch substitutes, like "guix
build" and "guix install," you will probably find that the substitution
is not failing.  If that isn't the case, please let us know.

-- 
Chris

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Hi Chris,

thanks for looking into this issue!

Chris Marusich <cmmarusich@gmail.com> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:

[...]

>> actually all https://ci.guix.info/ returns 504 "Gateway Time-out":
>> AFAIU this mean I'm not able to install that package (possibly others)
>> for some problem in the CDN
>
> Summary: A Cuirass API is failing, but substitutes are available.  The
> CDN is not the problem.  I'll explain more below.

OK I got it, actually I didn't check https://berlin.guixsd.org/ whan I
got that error

the "504 Gateway Time-out" is coming from https://berlin.guixsd.org/,
**but** _sometimes_ the error goes away

I mean: if I try to reach https://berlin.guixsd.org/ or
https://ci.guix.info/ and periodically reload the page, sometimes I get
504 error and sometimes not

in particular, it _seems_ to me that the gateway time-out is triggered
by a visit to https://ci.guix.info/api/queue?nr=1000

I mean: if I reach https://berlin.guixsd.org/ or https://ci.guix.info/
and I get a proper response (not 504) I can subsequently reload the page
and clean the cache and always get a proper response; after I try to
visit https://ci.guix.info/api/queue?nr=1000 in my browser and then try
to visit https://ci.guix.info/ or https://berlin.guixsd.org/ I
systematically get a 504

> The 504 error comes from berlin, not the CDN.  If you access
> berlin.guixsd.org directly when the 504 occurs, I think you'll see a 504
> from there, too.

OK, sorry for the confusion I made: it's not CDN related

nevertheless it seems to me we have a problem with our infrastructure

[...]

> What I'm trying to say is that the 504 doesn't mean substitutes are
> unavailable.

OK, so my problem getting ungoogled-chromium installed is not related to
the 504 gateway timeout from the web API

unfortunately I'm still having problems installing it since my client
does not download the substitute but starts building the derivation:

--8<---------------cut here---------------start------------->8---
$ guix package -i ungoogled-chromium
substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
\ 'set-paths' phase^C
--8<---------------cut here---------------end--------------->8---

despite

--8<---------------cut here---------------start------------->8---
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.info...
https://ci.guix.info
  100.0% substitutes available (1 out of 1)
  99,3 MiB of nars (compressed)
  288,3 MiB on disk (uncompressed)
  0,059 seconds per request (0,1 seconds in total)
  16,9 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

...and I still can't understand why

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

Giovanni Biscuolo <g@xelera.eu> writes:

> unfortunately I'm still having problems installing it since my client
> does not download the substitute but starts building the derivation:
>
> --8<---------------cut here---------------start------------->8---
> $ guix package -i ungoogled-chromium
> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
> building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
> \ 'set-paths' phase^C
> --8<---------------cut here---------------end--------------->8---

There is no such derivation on the server at berlin.guixsd.org.

-- 
Ricardo

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> unfortunately I'm still having problems installing it since my client
>> does not download the substitute but starts building the derivation:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ guix package -i ungoogled-chromium
>> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
>> building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
>> \ 'set-paths' phase^C
>> --8<---------------cut here---------------end--------------->8---
>
> There is no such derivation on the server at berlin.guixsd.org.

We do have these though:

/gnu/store/394p90k2kz47pi7nn5cvwzw4hcqrp1xf-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/61kj5jlhq8c1pc32vs2f6ibg45m08y3q-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/7ci5jh1vh9af75xbv330gq647fdpr7pb-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/ayc7plhz9j3y3vxxdss8028h9iw70mza-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/chdj91fkq2yad890zwy9dfd8jc8r30r7-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/gf0bavw8q5mrqh5p87mdf2pdjciq431n-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/gp0s9xi2kijjzfzmy5yqiy9q4pnw285d-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/h67xpfjlw8w9dx880d6b6f79qq9rzd50-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/ipjyrrd3l69bpk3mk6h75gcnm6x87qls-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/j3xvknmcgkmp5m51awi1np4jfqv7148z-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/j7c1apddih4zp8dirf92c362ivixbmc8-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/k3g0nsclzi5l0fil1jvp3i21vz9pirqw-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/l5x9f0rqkbw2agmrkk1lzks0m549hypq-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/m08kbvnclxxgpjkxp2azdgw7cv720fyz-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/nk4jbfd1dd1xbin9jib0yy9nc10am2vz-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/p3wmgfw20npsfcpfjbhaf5nb2x8a27n4-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/qksjfj7s222ybl7gxa6vnhzg2l3d5wiy-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/x2hlczmryal6fd5hbr5n12j4r0xvq6gj-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/yvs8xvhh07q4bgq16zgq16qpxpdzmyfz-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/yw5f9ja6cmfzljwhz0kbk3rq0hs9nbac-ungoogled-chromium-72.0.3626.109.drv
/gnu/store/z0m2mfwsnlc65sbf5pcx04j2mwk4ssb0-ungoogled-chromium-72.0.3626.109.drv

-- 
Ricardo

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Ricardo,

thanks for your patience with users like me still not able to find
substitutes availability info :-S

Ricardo Wurmus <rekado@elephly.net> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Giovanni Biscuolo <g@xelera.eu> writes:
>>
>>> unfortunately I'm still having problems installing it since my client
>>> does not download the substitute but starts building the derivation:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> $ guix package -i ungoogled-chromium
>>> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
>>> building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
>>> \ 'set-paths' phase^C
>>> --8<---------------cut here---------------end--------------->8---
>>
>> There is no such derivation on the server at berlin.guixsd.org.

ouch, sorry! I thought "guix weather" [1] is telling me the contrary
(sorry if I repeat myself):

--8<---------------cut here---------------start------------->8---
$ guix weather --manifest=.ungoogled-chromium.manifest
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.info...
https://ci.guix.info
  100.0% substitutes available (1 out of 1)
  99,3 MiB of nars (compressed)
  288,3 MiB on disk (uncompressed)
  0,004 seconds per request (0,0 seconds in total)
  271,0 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

this is .ungoogled-chromium.manifest:

--8<---------------cut here---------------start------------->8---
(specifications->manifest
 '("ungoogled-chromium"))
--8<---------------cut here---------------end--------------->8---

from the manual I thought this was enough, I mean there is an avaiable
substitute for my current commit of guix

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 3	Feb 19 2019 19:35:54	(current)
  guix a4fc802
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: a4fc80254a53b46b33f138d1009ddd044b8cb6be
--8<---------------cut here---------------end--------------->8---

how can I check if a substitute is available for my specific commit?

> We do have these though:
>
> /gnu/store/394p90k2kz47pi7nn5cvwzw4hcqrp1xf-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/61kj5jlhq8c1pc32vs2f6ibg45m08y3q-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/7ci5jh1vh9af75xbv330gq647fdpr7pb-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/ayc7plhz9j3y3vxxdss8028h9iw70mza-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/chdj91fkq2yad890zwy9dfd8jc8r30r7-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/gf0bavw8q5mrqh5p87mdf2pdjciq431n-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/gp0s9xi2kijjzfzmy5yqiy9q4pnw285d-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/h67xpfjlw8w9dx880d6b6f79qq9rzd50-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/ipjyrrd3l69bpk3mk6h75gcnm6x87qls-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/j3xvknmcgkmp5m51awi1np4jfqv7148z-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/j7c1apddih4zp8dirf92c362ivixbmc8-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/k3g0nsclzi5l0fil1jvp3i21vz9pirqw-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/l5x9f0rqkbw2agmrkk1lzks0m549hypq-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/m08kbvnclxxgpjkxp2azdgw7cv720fyz-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/nk4jbfd1dd1xbin9jib0yy9nc10am2vz-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/p3wmgfw20npsfcpfjbhaf5nb2x8a27n4-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/qksjfj7s222ybl7gxa6vnhzg2l3d5wiy-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/x2hlczmryal6fd5hbr5n12j4r0xvq6gj-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/yvs8xvhh07q4bgq16zgq16qpxpdzmyfz-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/yw5f9ja6cmfzljwhz0kbk3rq0hs9nbac-ungoogled-chromium-72.0.3626.109.drv
> /gnu/store/z0m2mfwsnlc65sbf5pcx04j2mwk4ssb0-ungoogled-chromium-72.0.3626.109.drv

OK there are plenty of it

I still have to learn how to find a guix commit giving me one of those
specific derivations... or just check if one specific commit provides
one of those

Thanks!
Giovanni


[1] https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-weather.html#index-availability-of-substitutes

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

Giovanni Biscuolo <g@xelera.eu> writes:

> Ricardo,
>
> thanks for your patience with users like me still not able to find
> substitutes availability info :-S
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Giovanni Biscuolo <g@xelera.eu> writes:
>>>
>>>> unfortunately I'm still having problems installing it since my client
>>>> does not download the substitute but starts building the derivation:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> $ guix package -i ungoogled-chromium
>>>> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
>>>> building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
>>>> \ 'set-paths' phase^C
>>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> There is no such derivation on the server at berlin.guixsd.org.
>
> ouch, sorry! […]

No need to apologize.  I was curious as to what’s going on here, so I
checked right on berlin.guixsd.org to see if the file exists at all.

I don’t know why the derivation you get isn’t yet available on berlin.
It’s possible that there hasn’t been an evaluation corresponding to your
commit.

> I still have to learn how to find a guix commit giving me one of those
> specific derivations... or just check if one specific commit provides
> one of those

You generally can’t do that.  You can’t compute the commit from only a
derivation file name.

--
Ricardo

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Mathieu Lirzin]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> I still have to learn how to find a guix commit giving me one of those
>> specific derivations... or just check if one specific commit provides
>> one of those
>
> You generally can’t do that.  You can’t compute the commit from only a
> derivation file name.

I guess that ‘guix weather’ checks the presence of substitutes for a
current derivation of a package definition, so if in the same
environment ‘guix weather’ tells that a substitute is available and
‘guix package’ doesn't fetch it, it sounds fishy no?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

Mathieu Lirzin <mthl@gnu.org> writes:

> Hello,
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Giovanni Biscuolo <g@xelera.eu> writes:
>>
>>> I still have to learn how to find a guix commit giving me one of those
>>> specific derivations... or just check if one specific commit provides
>>> one of those
>>
>> You generally can’t do that.  You can’t compute the commit from only a
>> derivation file name.
>
> I guess that ‘guix weather’ checks the presence of substitutes for a
> current derivation of a package definition, so if in the same
> environment ‘guix weather’ tells that a substitute is available and
> ‘guix package’ doesn't fetch it, it sounds fishy no?

Yes.  I cannot see the derivation in question, though, so I don’t
understand why “guix weather” would claim that a substitute exists.

I haven’t begun investigating this yet.  I’m probably overlooking
something obvious.

-- 
Ricardo

guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Mathieu Lirzin <mthl@gnu.org> writes:

[...]

>> I guess that ‘guix weather’ checks the presence of substitutes for a
>> current derivation of a package definition, so if in the same
>> environment ‘guix weather’ tells that a substitute is available and
>> ‘guix package’ doesn't fetch it, it sounds fishy no?
>
> Yes.  I cannot see the derivation in question, though, so I don’t
> understand why “guix weather” would claim that a substitute exists.
>
> I haven’t begun investigating this yet.  I’m probably overlooking
> something obvious.

do you think I should file a bug report or should I wait for more
investigation in this list?

Thanks!
Giovanni

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Chris Marusich]

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

Giovanni Biscuolo <g@xelera.eu> writes:

> do you think I should file a bug report or should I wait for more
> investigation in this list?

Let's confirm the issue by reproducing it, and then open a bug report.
The possible issue here is that berlin reported a substitute was
available, even though the substitute isn't actually available.  Right?

If you could provide the following information, I can try to reproduce
it for you:

- The output of 'guix describe'.
- The manifest file you used in your 'guix weather' command.

Thank you,

-- 
Chris

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

Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> do you think I should file a bug report or should I wait for more
>> investigation in this list?
>
> Let's confirm the issue by reproducing it, and then open a bug report.

OK, thanks!

> The possible issue here is that berlin reported a substitute was
> available, even though the substitute isn't actually available.
> Right?

AFAIU the issue is "guix weather" reporting on the availability related
to current master and not of user commit: am I wrong?

a little (digression

  anyway even if that is not the issue, users should have some way to
  check if a substitute is available for their current commit, so they
  can decide if they are willing to locally build or not.
    
  also, it would be useful if "guix package -i/-u" allowed users to
  choose to fail (via a flag or a CLI prompt) in case a substitute is
  not available; AFAIU "Substitution failure" [1] works when a
  substitute *is available* but download fails (and we have "--fallback"
  just in case), but there is non way to fail in case substitute in not
  available.
    
  in my specific case with ungoogled-chromium, it took about 8 hours on
  a 8 cores + 16GB RAM machine (although heavily used) to reach 75% of
  the build process... and finally I had to cancel the build since the
  machine load reached 40 (since other "heavy" processes started via
  cronjobs).)

anyway: back to the issue

> If you could provide the following information, I can try to reproduce
> it for you:
>
> - The output of 'guix describe'.
> - The manifest file you used in your 'guix weather' command.

I posted them yesterday in this thread; they are:

.ungoogled-chromium.manifest:

--8<---------------cut here---------------start------------->8---
(specifications->manifest
 '("ungoogled-chromium"))
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 3	Feb 19 2019 19:35:54	(current)
  guix a4fc802
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: a4fc80254a53b46b33f138d1009ddd044b8cb6be
--8<---------------cut here---------------end--------------->8---


yesterday I upgraded guix (guix pull), now I am on:

--8<---------------cut here---------------start------------->8---
Generation 4	feb 25 2019 16:21:26	(current)
  guix cc842b5
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: cc842b58af0a52dc8a01d4a4a30fa2fa0c599190
--8<---------------cut here---------------end--------------->8---

I was able to install ungoogled-chromium substitute:


today that package weather is the same as two days ago:

--8<---------------cut here---------------start------------->8---
$ guix weather --manifest=.ungoogled-chromium.manifest
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.info...
updating substitutes from 'https://ci.guix.info'... 100.0%
https://ci.guix.info
  100.0% substitutes available (1 out of 1)
  99,3 MiB of nars (compressed)
  288,3 MiB on disk (uncompressed)
  3,952 seconds per request (3,0 seconds in total)
  0,3 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---


Thanks!
Giovanni

[1]
https://www.gnu.org/software/guix/manual/en/html_node/Substitution-Failure.html#Substitution-Failure

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Chris Marusich]

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

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

> AFAIU the issue is "guix weather" reporting on the availability related
> to current master and not of user commit: am I wrong?

I'm not sure.  That would explain the issue you saw.  I haven't checked
the code.  Maybe you could take a peek?  If "guix weather" is using
master branch and ignoring the current channel configuration, it seems
like it might be unintended behavior.

> a little (digression
>
>   anyway even if that is not the issue, users should have some way to
>   check if a substitute is available for their current commit, so they
>   can decide if they are willing to locally build or not.
>     
>   also, it would be useful if "guix package -i/-u" allowed users to
>   choose to fail (via a flag or a CLI prompt) in case a substitute is
>   not available; AFAIU "Substitution failure" [1] works when a
>   substitute *is available* but download fails (and we have "--fallback"
>   just in case), but there is non way to fail in case substitute in not
>   available.
>     
>   in my specific case with ungoogled-chromium, it took about 8 hours on
>   a 8 cores + 16GB RAM machine (although heavily used) to reach 75% of
>   the build process... and finally I had to cancel the build since the
>   machine load reached 40 (since other "heavy" processes started via
>   cronjobs).)

I agree it would be nice if one could control the behavior more easily.
However, someone needs to put in the time to design and implement the
solution.  So far, I think people with time and energy have chosen
instead to focus on improving substitute availability, in the hopes that
it will prove more useful in the long term.

Would you be interesting in working on it?  I have sometimes wanted a
feature like that, but I do believe substitute availability will help
more in the long term.

> I posted them yesterday in this thread; they are:
>
> .ungoogled-chromium.manifest:
>
> (specifications->manifest
>  '("ungoogled-chromium"))
>
> $ guix describe
> Generation 3	Feb 19 2019 19:35:54	(current)
>   guix a4fc802
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: a4fc80254a53b46b33f138d1009ddd044b8cb6be

Excellent - thank you.  I think I missed this in your emails earlier.

I have attempted to reproduce the issue using that information.  When I
ran "guix pull" to use the same version of Guix you were using
(a4fc80254a53b46b33f138d1009ddd044b8cb6be) and then ran "guix weather",
I saw the same output as you (i.e., ci.guix.info reported that the
substitute was available).  However, when I ran...

  guix package \
       --substitute-urls=https://ci.guix.info \
       -p /tmp/test-profile \
       -m /tmp/manifest.scm

...Guix began downloading chromium from ci.guix.info.  The contents of
/tmp/manifest.scm is the same manifest you provided.  So, unfortunately
this means I wasn't able to reproduce the issue you experienced.
Everything seems to be working correctly on my end.

I'm afraid I'm out of time at the moment - I have to go.  But if you
could the check "guix weather" source code to find out if it respects
the current channels, that would be great.  I'll try to get around to it
if you don't beat me to it.

-- 
Chris

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

Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> AFAIU the issue is "guix weather" reporting on the availability related
>> to current master and not of user commit: am I wrong?
>
> I'm not sure.  That would explain the issue you saw.  I haven't checked
> the code.  Maybe you could take a peek?  If "guix weather" is using
> master branch and ignoring the current channel configuration, it seems
> like it might be unintended behavior.

I'll try to understand guix weather code (guix/guix/scripts/weather.scm)
but I'm pretty new to Guile and Guix so it will be a long study for me

...so sorry, but for now do not count on me for a timely report on this
:-)

>> a little (digression
>>
>>   anyway even if that is not the issue, users should have some way to
>>   check if a substitute is available for their current commit, so they
>>   can decide if they are willing to locally build or not.

[...]

> I agree it would be nice if one could control the behavior more easily.
> However, someone needs to put in the time to design and implement the
> solution.  So far, I think people with time and energy have chosen
> instead to focus on improving substitute availability, in the hopes that
> it will prove more useful in the long term.

yes I'm aware of this and I find this is not a priority for Guix,
improving substitutes availability is

> Would you be interesting in working on it?

yes but for me "it's a long way to the top if you (me) wanna
rock'n'roll" :-)

[...]

> I have attempted to reproduce the issue using that information.  When I
> ran "guix pull" to use the same version of Guix you were using
> (a4fc80254a53b46b33f138d1009ddd044b8cb6be) and then ran "guix weather",
> I saw the same output as you (i.e., ci.guix.info reported that the
> substitute was available).  However, when I ran...
>
>   guix package \
>        --substitute-urls=https://ci.guix.info \
>        -p /tmp/test-profile \
>        -m /tmp/manifest.scm
>
> ...Guix began downloading chromium from ci.guix.info.  The contents of
> /tmp/manifest.scm is the same manifest you provided.  So, unfortunately
> this means I wasn't able to reproduce the issue you experienced.
> Everything seems to be working correctly on my end.

could you please report here the exact substitute derivation you got?

on Monday Ricardo told us:

>> --8<---------------cut here---------------start------------->8---
>> $ guix package -i ungoogled-chromium
>> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
>> building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
>> \ 'set-paths' phase^C
>> --8<---------------cut here---------------end--------------->8---
>
>There is no such derivation on the server at berlin.guixsd.org.

It wold be interesting to see what derivation you got this time

Thanks!
Giovanni

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 7715 bytes --]

Hi Giovanni,

I think I may have been confused when I sent my last email.  I saw Guix
downloading the source and mistakenly assumed that it was downloading a
substitute for Chromium.  I looked at the log more closely, and I think
now I was actually able to reproduce your issue.

Using the information you provided, I ran this command:

guix package --substitute-urls=https://ci.guix.info -p /tmp/test-profile -m /tmp/manifest.scm 2>&1 | tee /tmp/package-install.log

I've attached the gzipped log to this email, for your reference.  In it,
you can find messages like the following:

--8<---------------cut here---------------start------------->8---
$ grep ungoogled-chromium /tmp/package-install.log 
downloading from https://ci.guix.info/nar/gzip/g92nls9b9ggnhgmdd9ycmcws38z9aw43-ungoogled-chromium-a58db88-checkout...
 ungoogled-chromium-a58db88-checkout  672KiB 729KiB/s 00:01 [##################] 100.0%
building /gnu/store/w54r150nj8ksyznj6b8q92fgr1n0l20h-ungoogled-chromium-72.0.3626.109.tar.xz.drv...
building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
   /gnu/store/r0jfc6lfakh0mg764kyxzzmlf21b3d7c-ungoogled-chromium-72.0.3626.109.drv
applying 8 grafts for /gnu/store/r0jfc6lfakh0mg764kyxzzmlf21b3d7c-ungoogled-chromium-72.0.3626.109.drv...
--8<---------------cut here---------------end--------------->8---

As you can see, it seems Guix actually did build ungoogled-chromium (the
line "building
/gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv"
is followed by what appears to be many lines of compilation output).

Ultimately, what gets installed into the profile is:

  /gnu/store/za5b7s35jskvvvlv0favqy4as1cfk332-ungoogled-chromium-72.0.3626.109

which is the output of

  /gnu/store/r0jfc6lfakh0mg764kyxzzmlf21b3d7c-ungoogled-chromium-72.0.3626.109.drv

which itself is a graft derivation.  This graft derivation appears to
have the following derivation as an input:

  /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv

which is the derivation that builds the ungrafted ungoogled-chromium.
This makes sense, since the graft derivation needs to modify the
original.

A few minutes ago, I ran "guix weather" again.  It says 1 substitute
(which one, I wonder?) is available:

--8<---------------cut here---------------start------------->8---
$ guix weather -m /tmp/manifest.scm 
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.info...
https://ci.guix.info
  100.0% substitutes available (1 out of 1)
  99.3 MiB of nars (compressed)
  288.3 MiB on disk (uncompressed)
  0.002 seconds per request (0.0 seconds in total)
  612.7 requests per second
  'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

I then tried to download substitutes manually.  However, when I try to
download the grafted and ungrafted versions, I get a 404.  Here's a
summary of these derivations, based on what I observed:

This graft derivation for ungoogled-chromium...

  /gnu/store/r0jfc6lfakh0mg764kyxzzmlf21b3d7c-ungoogled-chromium-72.0.3626.109.drv

...produces...

  /gnu/store/za5b7s35jskvvvlv0favqy4as1cfk332-ungoogled-chromium-72.0.3626.109

When I try to fetch it via...

  curl -v -o /dev/null https://ci.guix.info/nar/gzip/za5b7s35jskvvvlv0favqy4as1cfk332-ungoogled-chromium-72.0.3626.109

...I get a 404 from ci.guix.info.

This non-graft derivation for ungoogled-chromium (which appears to be an
input to the graft derivation above)...

  /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv

...produces...

  /gnu/store/2xnx8nglb8dyjvkq0zra17baxkyic721-ungoogled-chromium-72.0.3626.109

When I try to fetch it via...

  curl -v -o /dev/null https://ci.guix.info/nar/gzip/2xnx8nglb8dyjvkq0zra17baxkyic721-ungoogled-chromium-72.0.3626.109

...I get a 404 from ci.guix.info.

I expected to get a 200 in at least one of those cases, since "guix
weather" said that 1 substitute was available.  I don't really know
what's going on here, but it seems strange.  I guess we need to
investigate more.

It would be interesting to know if "guix weather" honors the current
channel configuration, or if it always checks master.  If it always
checks master, then that could explain what we're seeing.  Anyway, it
seems like it might be time for a bug report.  Could you summarize the
issue and open one?

- 

Giovanni Biscuolo <g@xelera.eu> writes:

> Hi Chris,
>
> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> Giovanni Biscuolo <g@xelera.eu> writes:
>>
>>> AFAIU the issue is "guix weather" reporting on the availability related
>>> to current master and not of user commit: am I wrong?
>>
>> I'm not sure.  That would explain the issue you saw.  I haven't checked
>> the code.  Maybe you could take a peek?  If "guix weather" is using
>> master branch and ignoring the current channel configuration, it seems
>> like it might be unintended behavior.
>
> I'll try to understand guix weather code (guix/guix/scripts/weather.scm)
> but I'm pretty new to Guile and Guix so it will be a long study for me
>
> ...so sorry, but for now do not count on me for a timely report on this
> :-)
>
>>> a little (digression
>>>
>>>   anyway even if that is not the issue, users should have some way to
>>>   check if a substitute is available for their current commit, so they
>>>   can decide if they are willing to locally build or not.
>
> [...]
>
>> I agree it would be nice if one could control the behavior more easily.
>> However, someone needs to put in the time to design and implement the
>> solution.  So far, I think people with time and energy have chosen
>> instead to focus on improving substitute availability, in the hopes that
>> it will prove more useful in the long term.
>
> yes I'm aware of this and I find this is not a priority for Guix,
> improving substitutes availability is
>
>> Would you be interesting in working on it?
>
> yes but for me "it's a long way to the top if you (me) wanna
> rock'n'roll" :-)
>
> [...]
>
>> I have attempted to reproduce the issue using that information.  When I
>> ran "guix pull" to use the same version of Guix you were using
>> (a4fc80254a53b46b33f138d1009ddd044b8cb6be) and then ran "guix weather",
>> I saw the same output as you (i.e., ci.guix.info reported that the
>> substitute was available).  However, when I ran...
>>
>>   guix package \
>>        --substitute-urls=https://ci.guix.info \
>>        -p /tmp/test-profile \
>>        -m /tmp/manifest.scm
>>
>> ...Guix began downloading chromium from ci.guix.info.  The contents of
>> /tmp/manifest.scm is the same manifest you provided.  So, unfortunately
>> this means I wasn't able to reproduce the issue you experienced.
>> Everything seems to be working correctly on my end.
>
> could you please report here the exact substitute derivation you got?
>
> on Monday Ricardo told us:
>
>>> --8<---------------cut here---------------start------------->8---
>>> $ guix package -i ungoogled-chromium
>>> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
>>> building
>>> /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
>>> \ 'set-paths' phase^C
>>> --8<---------------cut here---------------end--------------->8---
>>
>>There is no such derivation on the server at berlin.guixsd.org.
>
> It wold be interesting to see what derivation you got this time
>
> Thanks!
> Giovanni
>
> [...]

-- 
Chris

[-- Attachment #1.2: package-install.log.gz --]
[-- Type: application/octet-stream, Size: 498169 bytes --]

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

Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)

[Björn Höfling]

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

On Tue, 26 Feb 2019 23:29:35 -0800
Chris Marusich <cmmarusich@gmail.com> wrote:

> Hi Giovanni,
> 
> Giovanni Biscuolo <g@xelera.eu> writes:

[...]

> >   anyway even if that is not the issue, users should have some way
> > to check if a substitute is available for their current commit, so
> > they can decide if they are willing to locally build or not.
> >     
> >   also, it would be useful if "guix package -i/-u" allowed users to
> >   choose to fail (via a flag or a CLI prompt) in case a substitute
> > is not available; AFAIU "Substitution failure" [1] works when a
> >   substitute *is available* but download fails (and we have
> > "--fallback" just in case), but there is non way to fail in case
> > substitute in not available.

There is already a bug created about this topic: "do not attempt to
build a package known to be broken":

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33737

It seams like the discussion faded out because the daemon is not yet
ready for this, and there were some discussions about corner cases like
indeterministic build failures.

> >   in my specific case with ungoogled-chromium, it took about 8
> > hours on a 8 cores + 16GB RAM machine (although heavily used) to
> > reach 75% of the build process... and finally I had to cancel the
> > build since the machine load reached 40 (since other "heavy"
> > processes started via cronjobs).)  

Another related topic discussed before (I'm not sure if there is a
ticket for this) is to collect build resource consumption (wall-time,
cpu-time, memory-usage, ...) and store it in a local or even
global database. With that data available you could at least roughly
calculate the cost of compilation and if you want to put that effort in
(or to plan your heavy compilation say overnight).

> I agree it would be nice if one could control the behavior more
> easily. However, someone needs to put in the time to design and
> implement the solution.  So far, I think people with time and energy
> have chosen instead to focus on improving substitute availability, in
> the hopes that it will prove more useful in the long term.
> 
> Would you be interesting in working on it?  I have sometimes wanted a
> feature like that, but I do believe substitute availability will help
> more in the long term.

I found with a huge profile there is always some dependency failing.
And it is not clear which leaf packages to exclude to "just" update the
rest of your profile. This could be automated. I would like to see that
feature.

Though on the other hand as you said, everyone's resources are limited
and we tend to look at the packages and getting them fixed.

Björn

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Mark H Weaver]

Giovanni Biscuolo <g@xelera.eu> writes:

> OK, so my problem getting ungoogled-chromium installed is not related to
> the 504 gateway timeout from the web API
>
> unfortunately I'm still having problems installing it since my client
> does not download the substitute but starts building the derivation:
>
> $ guix package -i ungoogled-chromium
> substitute: updating substitutes from 'https://ci.guix.info'... 100.0%
> building /gnu/store/4mvzzx2jmr4r4p2kx0hcvwr9s9lvx0gd-ungoogled-chromium-72.0.3626.109.drv...
> \ 'set-paths' phase^C

I don't know about berlin, but hydra.gnu.org has *never* successfully
built ungoogled-chromium.  So far, it has made 3 attempts on
x86_64-linux and 5 attempts on i686-linux:

  https://hydra.gnu.org/build/3387889 (x86_64-linux)
  https://hydra.gnu.org/build/3381436 (x86_64-linux)
  https://hydra.gnu.org/build/3380876 (x86_64-linux)
  https://hydra.gnu.org/build/3386821 (i686-linux)
  https://hydra.gnu.org/build/3385227 (i686-linux)
  https://hydra.gnu.org/build/3381453 (i686-linux)
  https://hydra.gnu.org/build/3380895 (i686-linux)
  https://hydra.gnu.org/build/3379818 (i686-linux)

If the same is true on berlin.guixsd.org, that would explain the lack of
binary substitutes.

        Mark

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Leo Famulari]

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

On Sun, Mar 03, 2019 at 11:06:32AM -0500, Mark H Weaver wrote:
> I don't know about berlin, but hydra.gnu.org has *never* successfully
> built ungoogled-chromium.  So far, it has made 3 attempts on
> x86_64-linux and 5 attempts on i686-linux:

[...]

> If the same is true on berlin.guixsd.org, that would explain the lack of
> binary substitutes.

Berlin did build it, soon after the package was first added. I used the
substitute on my machine which lacks the capacity build the package.

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[swedebugia]

[-- Attachment #1.1: Type: text/plain, Size: 353 bytes --]

On 2019-02-21 16:14, Giovanni Biscuolo wrote:
snip

> 
> in my case (I'm on Debian with systemd) I have to add an "Environment="
> parameter in /etc/systemd/system/guix-daemon.service, reload the systemd
> file and restart the service

If this is not explained in the manual could you send a patch to include
this?

-- 
Cheers Swedebugia


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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

swedebugia <swedebugia@riseup.net> writes:

> On 2019-02-21 16:14, Giovanni Biscuolo wrote:
> snip
>
>> 
>> in my case (I'm on Debian with systemd) I have to add an "Environment="
>> parameter in /etc/systemd/system/guix-daemon.service, reload the systemd
>> file and restart the service
>
> If this is not explained in the manual could you send a patch to include
> this?

yes! not tomorrow, on Wednesday I should be able to send it...

stay tuned :-D
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Ricardo Wurmus]

swedebugia <swedebugia@riseup.net> writes:

> On 2019-02-21 16:14, Giovanni Biscuolo wrote:
> snip
>
>> 
>> in my case (I'm on Debian with systemd) I have to add an "Environment="
>> parameter in /etc/systemd/system/guix-daemon.service, reload the systemd
>> file and restart the service
>
> If this is not explained in the manual could you send a patch to include
> this?

The service file already includes an “Environment” line.

-- 
Ricardo

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Leo Famulari]

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

On Mon, Feb 25, 2019 at 09:31:48PM +0100, Ricardo Wurmus wrote:
> swedebugia <swedebugia@riseup.net> writes:
> > If this is not explained in the manual could you send a patch to include
> > this?
> 
> The service file already includes an “Environment” line.

Also, this 'Environment=' parameter is a feature of systemd services [0]
and applicable to any use of systemd. I don't think the Guix manual
needs to include specific examples of how to set environment variables
in third-party service managers.

[0] See the manual page systemd.service(5) or view it online:
https://www.freedesktop.org/software/systemd/man/systemd.service.html

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

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)

[Giovanni Biscuolo]

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

Hello,

Leo Famulari <leo@famulari.name> writes:

> On Mon, Feb 25, 2019 at 09:31:48PM +0100, Ricardo Wurmus wrote:
>> swedebugia <swedebugia@riseup.net> writes:
>> > If this is not explained in the manual could you send a patch to include
>> > this?
>> 
>> The service file already includes an “Environment” line.
>
> Also, this 'Environment=' parameter is a feature of systemd services [0]
> and applicable to any use of systemd. I don't think the Guix manual
> needs to include specific examples of how to set environment variables
> in third-party service managers.

I agree, non need to patch Guix manual in this case

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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