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

[Chris Marusich <cmmarusich@gmail.com>]

[-- 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 --]