Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)
Hi Giovanni,
Giovanni Biscuolo 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
signature.asc
Description: PGP signature
Re: Guix video repository: First video script commited
Hello Björn, Björn Höfling ezt írta (időpont: 2019. febr. 27., Sze, 0:10): > > Hi Laura, Hi Guix, > > the repository is now filled with the scripts for the first video: > > git clone https://git.savannah.gnu.org/git/guix/videos.git > Thanks for looking into this. I will have a look tomorrow. > To try it out, there is a script to enter a Guix container containing > all packages you need. After that, you can enter the video's directory > and call "./buildall.sh" to go through all build steps and get the > final video out: > > > $ ./environment.sh > Entering a Guix container to work with the videos. > Available packages in the container: paps make imagemagick guile ffmpeg > inkscape coreutils which less grep findutils git emacs vim > [env]# cd 01-installation-from-script/ > 01-installation-from-script [env]# ./buildall.sh > [... building video ... ] > > > The video currently contains only the sounds to the slides, not to the > CLI sessions. All parts will be spoken again by a native speaker. > > Unfortunately, the slides part does not fit on the screen, I couldn't > figure out why. Laura, your example videos looked normal, right? > > For reference, I uploaded my final .webm output to IPFS: > > QmdGJ1vs9QefS22WjjnSRJNjjEkL4ePfgYa3dHi8p7LshN > > Laura, do you like that directory layout, the way of creating the full > final video? Do you have any clue why my slides don't fit the screen? > Would you like to go on with the rest of the videos in that way? > > Don't be afraid of mistakes concerning the repository: Before pushing, > double-check that everything looks right, try to create the videos > locally, then push. If anything was wrong or not 100% perfect, that's > fine and can be corrected with a new commit. If you look closely into > the main Guix repository, you will also see mistakes. It is more a > matter of communications and get them corrected in time. > I agree. Mistakes are in all repos where real work gets done :) And they can be easily corrected. > Thank you for all the work you have done so far. > Yes, thank you very much. > Björn
Guix video repository: First video script commited
Hi Laura, Hi Guix, the repository is now filled with the scripts for the first video: git clone https://git.savannah.gnu.org/git/guix/videos.git To try it out, there is a script to enter a Guix container containing all packages you need. After that, you can enter the video's directory and call "./buildall.sh" to go through all build steps and get the final video out: $ ./environment.sh Entering a Guix container to work with the videos. Available packages in the container: paps make imagemagick guile ffmpeg inkscape coreutils which less grep findutils git emacs vim [env]# cd 01-installation-from-script/ 01-installation-from-script [env]# ./buildall.sh [... building video ... ] The video currently contains only the sounds to the slides, not to the CLI sessions. All parts will be spoken again by a native speaker. Unfortunately, the slides part does not fit on the screen, I couldn't figure out why. Laura, your example videos looked normal, right? For reference, I uploaded my final .webm output to IPFS: QmdGJ1vs9QefS22WjjnSRJNjjEkL4ePfgYa3dHi8p7LshN Laura, do you like that directory layout, the way of creating the full final video? Do you have any clue why my slides don't fit the screen? Would you like to go on with the rest of the videos in that way? Don't be afraid of mistakes concerning the repository: Before pushing, double-check that everything looks right, try to create the videos locally, then push. If anything was wrong or not 100% perfect, that's fine and can be corrected with a new commit. If you look closely into the main Guix repository, you will also see mistakes. It is more a matter of communications and get them corrected in time. Thank you for all the work you have done so far. Björn pgprI8mU2ne3D.pgp Description: OpenPGP digital signature
Re: bug#25970: mozjs build failure
On Wed, Feb 27, 2019 at 02:18:57AM +0800, Alex Vong wrote: > Leo Famulari writes: > > > On Tue, Feb 19, 2019 at 10:31:03PM +0100, Andreas Enge wrote: > >> the package builds, but I see no need to keep it. Do you agree to remove > >> it together with mozjs@17? The latter would require a little work, since > >> all other mozjs packages inherit from it. If there is consensus, I can > >> look into it. > > > > I agree, we don't need to keep any unused mozjs packages. > > Are we keeping the latest version of mozjs? It can be useful for running > javascript (like node and gjs). Yes, I think we should keep the latest version. signature.asc Description: PGP signature
Re: bug#25970: mozjs build failure
Leo Famulari writes: > On Tue, Feb 19, 2019 at 10:31:03PM +0100, Andreas Enge wrote: >> the package builds, but I see no need to keep it. Do you agree to remove >> it together with mozjs@17? The latter would require a little work, since >> all other mozjs packages inherit from it. If there is consensus, I can >> look into it. > > I agree, we don't need to keep any unused mozjs packages. Are we keeping the latest version of mozjs? It can be useful for running javascript (like node and gjs). signature.asc Description: PGP signature
Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
Hello, Leo Famulari writes: > On Mon, Feb 25, 2019 at 09:31:48PM +0100, Ricardo Wurmus wrote: >> swedebugia 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 signature.asc Description: PGP signature
Re: guix weather issue? (was Re: guix package builds, subsitutes and --no-build)
Hi Chris,
Chris Marusich writes:
> Giovanni Biscuolo 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 3Feb 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 4feb 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
signature.asc
Description: PGP signature
Re: To prevent guix gc from removing *grub.cfg file under /gnu/store/
Great :-) Raghav Gururajan writes: > Hi Clement! > > I wanted to contact you but I lost your email ID. Yes, the code snippet you > gave me did work perfectly. I just tested it today. Thanks a lot. > > Regards, > RG. > > > February 25, 2019 2:47 PM, "Clément Lassieur" wrote: > >> Hi Raghav, >> >> You can prevent this behaviour if you don't pass "--no-bootloader", and >> use in your config.scm the code snippet I showed you in a previous >> email, so that GRUB isn't installed. >> >> Clément
