Re: build failed: substituter `substitute' died unexpectedly
Ludovic Courtès writes:
> Leo Famulari <l...@famulari.name> skribis:
>
>> On Fri, Apr 28, 2017 at 11:29:50AM -0500, Christopher Allan Webber wrote:
>>> I am getting this error right now on multiple machines:
>>>
>>> substitute: updating list of substitutes from
>>> 'http://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'http://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'http://mirror.hydra.gnu.org'... 66.7%Backtrace:
>>> substitute: In ice-9/boot-9.scm:
>>> substitute: 160: 9 [catch #t # ...]
>>> substitute: In unknown file:
>>> substitute:?: 8 [apply-smob/1 #]
>>> substitute: In ice-9/boot-9.scm:
>>> substitute: 66: 7 [call-with-prompt prompt0 ...]
>>> substitute: In ice-9/eval.scm:
>>> substitute: 432: 6 [eval # #]
>>> substitute: In ice-9/boot-9.scm:
>>> substitute: 2412: 5 [save-module-excursion #>> ice-9/boot-9.scm:4084:3 ()>]
>>> substitute: 4089: 4 [#]
>>> substitute: 1734: 3 [%start-stack load-stack ...]
>>> substitute: 1739: 2 [#]
>>> substitute: In unknown file:
>>> substitute:?: 1 [primitive-load
>>> "/gnu/store/nqy9m6hhnkkfwr5wyq5bac96v9s9hc9i-guix-0.12.0-9.25a4/bin/.guix-real"]
>>> substitute: In guix/ui.scm:
>>> substitute: 1255: 0 [run-guix-command substitute "--query"]
>>> substitute:
>>> substitute: guix/ui.scm:1255:8: In procedure run-guix-command:
>>> substitute: guix/ui.scm:1255:8: Throw to key `bad-response' with args
>>> `("Bad Response-Line: ~s" (""))'.
>>> guix environment: error: build failed: substituter `substitute' died
>>> unexpectedly
>>
>> Same here. It kills the Guix process even if --fallback is used.
>
> I don’t seem to have this problem today (I’m using https instead of
> http, but --substitute-urls=http://… seems to work too). Does it still
> show up for you?
>
> It could have to do with a difference in how the newer nginx version
> deals with pipelined HTTP requests.
>
> Ludo’.
Mark fixed it. See bug#26705 for that and tracking "what happened?"
Re: build failed: substituter `substitute' died unexpectedly
Tobias Geerinckx-Rice writes:
> On 28/04/17 23:21, Tobias Geerinckx-Rice wrote:
>> On 28/04/17 23:16, Christopher Allan Webber wrote:
>>> Gave it a shot... still seems to be breaking here.
>>
>> Oh :-(
>>
>> Did you re-launch guix-daemon after re-building it?
Oh, I didn't!
> I forgot to mention: adding
>
> --substitute-urls="http://bad.http.response.tobias.gr;
>
> should serve as a simple test. It always triggers the the patch for me.
>
> Kind regards,
>
> T G-R
I think I tried it right...
cwebber@oolong:~$ guix environment --ad-hoc julia
--substitute-urls="http://bad.http.response.tobias.gr;
substitute: Backtrace:
substitute: In ice-9/boot-9.scm:
substitute: 160: 9 [catch #t # ...]
substitute: In unknown file:
substitute:?: 8 [apply-smob/1 #]
substitute: In ice-9/boot-9.scm:
substitute: 66: 7 [call-with-prompt prompt0 ...]
substitute: In ice-9/eval.scm:
substitute: 432: 6 [eval # #]
substitute: In ice-9/boot-9.scm:
substitute: 2412: 5 [save-module-excursion #]
substitute: 4089: 4 [#]
substitute: 1734: 3 [%start-stack load-stack ...]
substitute: 1739: 2 [#]
substitute: In unknown file:
substitute:?: 1 [primitive-load "/home/cwebber/devel/guix/scripts/guix"]
substitute: In guix/ui.scm:
substitute: 1255: 0 [run-guix-command substitute "--query"]
substitute:
substitute: guix/ui.scm:1255:8: In procedure run-guix-command:
substitute: guix/ui.scm:1255:8: Throw to key `bad-response' with args `("Bad
Response-Line: ~s" (""))'.
guix environment: error: corrupt input while restoring archive from #
I'm not really sure if this triggered the patch or not? It does look
like a different error message, so I'm guessing it did?
Re: build failed: substituter `substitute' died unexpectedly
Tobias Geerinckx-Rice writes:
> Chris, Leo,
>
> On 28/04/17 22:32, Leo Famulari wrote:
>> On Fri, Apr 28, 2017 at 11:29:50AM -0500, Christopher Allan Webber wrote:
>>> I am getting this error right now on multiple machines:
>>> substitute: guix/ui.scm:1255:8: Throw to key `bad-response' with args
>>> `("Bad Response-Line: ~s" (""))'.
>>
>> Same here. It kills the Guix process even if --fallback is used.
>
> Does the patch at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26489 help?
>
> Kind regards,
>
> T G-R
Gave it a shot... still seems to be breaking here.
build failed: substituter `substitute' died unexpectedly
I am getting this error right now on multiple machines:
substitute: updating list of substitutes from
'http://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'http://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'http://mirror.hydra.gnu.org'... 66.7%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute: 160: 9 [catch #t # ...]
substitute: In unknown file:
substitute:?: 8 [apply-smob/1 #]
substitute: In ice-9/boot-9.scm:
substitute: 66: 7 [call-with-prompt prompt0 ...]
substitute: In ice-9/eval.scm:
substitute: 432: 6 [eval # #]
substitute: In ice-9/boot-9.scm:
substitute: 2412: 5 [save-module-excursion #]
substitute: 4089: 4 [#]
substitute: 1734: 3 [%start-stack load-stack ...]
substitute: 1739: 2 [#]
substitute: In unknown file:
substitute:?: 1 [primitive-load
"/gnu/store/nqy9m6hhnkkfwr5wyq5bac96v9s9hc9i-guix-0.12.0-9.25a4/bin/.guix-real"]
substitute: In guix/ui.scm:
substitute: 1255: 0 [run-guix-command substitute "--query"]
substitute:
substitute: guix/ui.scm:1255:8: In procedure run-guix-command:
substitute: guix/ui.scm:1255:8: Throw to key `bad-response' with args `("Bad
Response-Line: ~s" (""))'.
guix environment: error: build failed: substituter `substitute' died
unexpectedly
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
It doesn't seem to be caused by either the guix system revision or the
userspace guix version I'm running. This happens with any operations
that use substitutes right now.
Are other people experiencing this? What happened, and what's causing
it... do we know?
Re: squee
Catonano writes: > Ok, I was just confused, it works like a charm > > Sorry for the noise Ah! No worries about the noise. I'm happy to see someone using squee. It hasn't gotten much love in the last couple of years. I intend to return to using it in the not too distant future. If you're interested in working on improvements to it we should talk. In particular we need help on code that converts between postgres types and guile native types more, I think. David Pirotte also has commit access and can help make decisions on the project.
Re: Hosting a GuixSD server on commodity hosting platforms, a journey
Christopher Baines writes: > On 02/12/16 04:06, Christopher Allan Webber wrote: >> Except, oops! This won't boot. We need to put GRUB on it. >> >> Well here's where I'm stuck for tonight. I don't know exactly what's >> needed; maybe either the -b flag, or --grub2-mbr, or some combination. >> The man page is a little bit overwhelming (I mean, xorrisofs is clearly >> featureful, credit there): >> >> https://www.gnu.org/software/xorriso/man_1_xorrisofs.html >> >> But how do I generate the right GRUB stuff to put there? Can I pull it >> off the USB image? Generate it separately? >> >> This web page is very long but appears to have the appropriate info (and >> unfortunately requires running arbitrary javascript to even render): >> >> >> http://lukeluo.blogspot.com/2013/06/grub-how-to-2-make-boot-able-iso-with.html >> >> ... so I guess the next steps are following roughly what's described at >> the bottom of the page? >> >> I wonder how other distros do this step. > > Thanks for looking in to this Chris! I'm using Bytemark for personal > servers, and have tried and failed to install Guix from a Debian live > cd. But, they do support installing from arbitrary ISO images, this > would be great to get working. > > The bash script which I guess Nix uses looks quite short [1], you might > find some useful inspiration there. > > 1: > https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-iso9660-image.sh That looks VERY helpful, thank you!
Re: Hosting a GuixSD server on commodity hosting platforms, a journey
Chris Marusich writes: > Hi, > > Reading Chris' report, I was inspired to try the same thing on EC2. I > don't know much about Linode or Rackspace, but I do know EC2. I'm happy > to report that I was successfully in creating a GuixSD EC2 instance. > > Here's what I did. Essentially, all I wanted to do was run "guix system > init" on the root device of an EC2 instance. I accomplished that by > running "guix system init" on a loopback device (on my laptop), copying > the file which backed the loopback device onto an EC2 instance, writing > the file to an EBS volume attached to the instance, and then replacing > the EC2 instance's root EBS volume with the newly written EBS volume. Wow, great! Thank you for trying it, and documenting it :)
Re: Hosting a GuixSD server on commodity hosting platforms, a journey
Marius Bakke writes: > I've had the questionable privilege of working on Openstack for some > time, and indeed have a GuixSD system running on it. I can tell you that > any errors you see are not necessarily representative of what's > happening in the back-end, although it does sound like the Rackspace GUI > just spits out a generic message, instead of a flat-out lie.. Yeah it was pretty generic, so I have no idea what happened. :) > The image I used was created by installing a bare-bones GuixSD to an LVM > device (e.g. with Qemu), then dumping this with `dd` before first boot > to create a "RAW" image. RAW is supported (required, actually) by Glance > if Ceph is used as the backing storage, but Rackspace only supports VHD. Interesting! > I haven't looked into the fstab of the generated VM image, but it may be > hard-coded to '/dev/vda' whereas Xen creates '/dev/xvda' (IIRC). Though > it should at least try to boot if that was the case. Yeah, my configuration was set up for /dev/sda I think. I guess I could do a system reconfigure switching it out to /dev/vda or whatever at least minute... I dunno. > My best advice is to try doing a normal install in a VM from the USB > image (qcow2 probably works) and then convert it to the format your > cloud platform expects, instead of booting the VM image directly. I used > GPT with a "bios_grub" partition FWIW. Out of curiosity, why do you think this would be an improvement? > Make sure to use (title 'label) and appropriate FS labels, since the > root device path may vary between cloud platforms. Right, though labels might vary between platforms too, correct? > On a vaguely related note, I'm slowly working on a "native" GuixSD > hosting platform, where you will be able to submit (and share!) > configuration files and get a VM and/or disk image back. It's still a > long way off, but I could use some help building the web front-end once > the back-end is ready. Feel free to contact me for more details :) Now this I'm really interested in! I'll ping you off-list to discuss this more. :)
Re: Hosting a GuixSD server on commodity hosting platforms, a journey
Christopher Allan Webber writes: > What am I doing wrong? I'm not totally sure... I feel like I'm > navigating a jungle out here in the OpenStack / Rackspace docs. Here's > one thing I found: > > https://community.rackspace.com/products/f/25/t/7186 > > So I probably need to execute this "import" command. I guess that's > what's next... Well, I did a bit more exploration tonight with *some* progress, but still not success. I followed the above link and got a task to generate an image based off my file. Looks like the task took! And it showed up in "image-list" with the glance command line client. Sounds like progress! And hey, if I try to create the server now via the web UI... if I look to create an image based off the images list from "Saved -> Deleted Servers (!!!)" menu, I indeed see my image listed. Cool! So I select that and click "create server". Ok... I wait a bit. It says it's initializing it! Uhoh, suddenly the status turns to ERROR. What's ERROR? I don't know. It says ERROR, and it's red. Hovering over it suggests I ask support. Hm. I wonder if I used the Nova command line client if I'd get more information, or if there's a way to query the API to get more info. Still, that's *some* progress... I kicked off generating an image generated via GuixSD, even if it didn't work at all... :) Relatedly! User dvc in #guix on freenode suggests looking at https://www.vultr.com/ which looks quite affordable and hey! It has a "custom ISO" option. If we can convert our USB boot stick thingy (presumably via xorriso) we could try generating a base server image from there. I'd prefer to have a workflow where I go from handing off something made with "guix system vm-image" to some API, but maybe in the meanwhile Vultr would be a lower barrier to entry. In the meanwhile, anyone familiar enough with Nova or Rackspace want to give me hints on how to find out more about what ERROR means, more specifically? ;) Onwards and upwards! - Chris
How to make current icecat less crashy
Seems a lot of us have been experiencing crashes in the current Icecat. in Guix master. Ricardo Wurmus gave me a nice tip that seems to have fixed the problem here: go to about:config find the keys gfx.canvas.azure.backends and gfx.content.azure.backends for both change “cairo” to “skia” note that for me this results in less readable fonts Seems to work here! (I haven't noticed the font issue but I could just be missing it.)
Re: GuixSD and TRAMP
Christopher Allan Webber writes: > Hello! > > I've been trying to access a remote GuixSD server I have running using > TRAMP in emacs. I figured out that in order for path resolution to > work I had to install perl in my remote user's path somehow. So, that's > done. > > I can open up directories in dired, but when I try to open an individual > file, I get: > > Tramp: Inserting ‘/ssh:kari:/home/cwebber/.emacs’...failed > Wrong method specification for ‘ssh’ > > I see I'm not the only one! ecraven reports the same here: > https://gnunet.org/bot/log/guix/2016-06-10#T1053360 > > Does anyone know how to resolve this? > Thanks! > - Chris Ho-ho, it turns out the snippet Ludo pasted me on IRC was the answer after all: ;; Make sure we work on remote guixsd machines :) ;; probably only helps if you start on a guixsd machine..! (setq tramp-remote-path (append tramp-remote-path '(tramp-own-remote-path))) There ya go!
What prevents "guix package --profile" profiles from being gc'ed?
Heya all, I'm a bit confused about profile management for profiles that *aren't* your system or default user profile. guix package --profile=/home/cwebber/guix-profiles/test -i hello then I run "guix gc", it seems like that profile is still kept around. David seemed to think that maybe the profile link would be under /var/guix/profiles/ cwebber@oolong:~$ find /var/guix/profiles/ /var/guix/profiles/ /var/guix/profiles/system-20-link /var/guix/profiles/system-21-link /var/guix/profiles/system-7-link /var/guix/profiles/system-6-link /var/guix/profiles/system-10-link /var/guix/profiles/system-22-link /var/guix/profiles/per-user /var/guix/profiles/per-user/cwebber /var/guix/profiles/per-user/cwebber/guix-profile-188-link /var/guix/profiles/per-user/cwebber/guix-profile-187-link /var/guix/profiles/per-user/cwebber/guix-profile-189-link /var/guix/profiles/per-user/cwebber/guix-profile-186-link /var/guix/profiles/per-user/cwebber/guix-profile-191-link /var/guix/profiles/per-user/cwebber/guix-profile /var/guix/profiles/per-user/cwebber/guix-profile-192-link /var/guix/profiles/per-user/cwebber/guix-profile-193-link /var/guix/profiles/per-user/cwebber/guix-profile-194-link /var/guix/profiles/per-user/cwebber/guix-profile-185-link /var/guix/profiles/per-user/cwebber/guix-profile-190-link /var/guix/profiles/per-user/root /var/guix/profiles/system-12-link /var/guix/profiles/system-11-link /var/guix/profiles/system-1-link /var/guix/profiles/system-14-link /var/guix/profiles/system-19-link /var/guix/profiles/system-18-link /var/guix/profiles/system-15-link /var/guix/profiles/system-13-link /var/guix/profiles/system-17-link /var/guix/profiles/system /var/guix/profiles/system-5-link /var/guix/profiles/system-8-link /var/guix/profiles/system-4-link /var/guix/profiles/system-9-link /var/guix/profiles/system-3-link /var/guix/profiles/system-16-link /var/guix/profiles/system-2-link It doesn't look like it. What's keeping that profile around? Will it ever get gc'ed? Is it somehow recorded in Guix's state files? Just curious, - Chris
Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?
Thompson, David writes: > On Thu, Feb 11, 2016 at 5:40 PM, Ludovic Courtès <l...@gnu.org> wrote: >> "Thompson, David" <dthomps...@worcester.edu> skribis: >> >>> On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès <l...@gnu.org> wrote: >>>> Christopher Allan Webber <cweb...@dustycloud.org> skribis: >>>> >>>>> Just for posterity, Dave helped me figure out what was wrong. I missed >>>>> putting guile-2.0 in my inputs. Critical! Well, once I did that, >>>>> things were fine! >>>> >>>> Indeed. However, since Haunt ships a command-line tool, we should fix >>>> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has >>>> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set. >>>> >>>> Done in 4ecbf6d. I think it should be fixed upstream though. :-) >>> >>> I don't understand why this would require an upstream fix for what >>> seems to be a Guix-specific quirk. Could you elaborate? >> >> I think stand-alone commands like ‘haunt’ should ensure that they’ll >> find their modules rather than assume that the user defined >> ‘GUILE_LOAD_PATH’ & co. appropriately. >> >> This is particularly important when users are likely to use exclusively >> the CLI (the same is also true of ‘skribilo’, ‘guix’, ‘herd’, etc.) > > Thanks for the explanation, I am convinced and will (eventually) fix > in Haunt and my other Guile applications. Does this also apply to the > applications dependencies, or just the modules for itself? If the > former, I'm actually not sure how to do the relevant autotools magic > to make it work. > > - Dave Okay, so I'm less convinced! I was thinking about this on my walk. Maybe I have something wrong though... would this also prevent loading other Guile modules when running "haunt build" that weren't inputs, or would it just guarantee that inputs are preferred? If the former, a-ok. If the latter, I am worried: this seems like it could block important late-binding use cases. Eg, if I build a library of Haunt utilities I use across all my Haunt sites and call it haunted-house, will I be able to (use-modules (haunted-house)) still? (Or maybe I'd want to import a new external reader, etc.) If so, then no worries. If not, that's a worry. It'd also be a worry in a project like MediaGoblin, where a user might install a plugin for a new media type outside of MediaGoblin. If they "launch" mediagoblin through some gmg executable, and I took the method above, could they still find a plugin which wasn't an input on the path? (If the above worries are unfounded, then great!)
