IRC channel logs
2017-07-25.log
back to list of logs
<magnicida>are there any tips to make "guix environment" faster? <magnicida>i am trying to do "guix environment ... -- make check" as my "compile command" inside emacs but it feels a bit slow sometimes <magnicida>admittedly it is just a few seconds, but enough that it takes longer than the actual tests <lfam>A few seconds is how long it takes for me, too <lfam>It would be awesome to speed it up <magnicida>i guess there are some low hanging fruits somewhere where it just reuses whatever you have already installed if possible <lfam>magnicida: In general, Guix uses what's in the store. The store is basically a cache. But, there are some bugs related to grafting and substitution that can cause spurious requests to be made. <lfam>Unfortunately most, if not all, packages are currently grafted, so those bugs have really gotten annoying. <lfam>Recently we had to graft glibc, so that's why I suspect that every package is grafted now. <lfam>It's imperfect but a good alternative to waiting days or weeks for every package to be rebuilt <magnicida>aha! so passing --no-grafts to guix environment removes the message <lfam>Yes, but beware! The software you run from --no-grafts is vulnerable to a large number of security problems <lfam>It depends on your thread model and risk tolerance. <Apteryx>It's going very well, thanks for asking :). How about youÉ <buenouanq>how do I make herd show more informative error messages when a service fails to start? <brendos>guix system reconfigure is failing because I get 404 trying to download linux-libre-4.11-CVE-2017-1000364.patch <efraim>brendos: I would suggest running guix pull first, 4.12.3 is the current kernel <brendos>Oh. I need to do it as root too don't I <efraim>I've heard 'sudo -E <command>' will also work <brendos>It sucks having to compile 611 scheme files once for each user <ryanwatkins>Hey guys, how might one remove all packages and just do a guix system reconfigure ... to begin from gen 1? :D <buenouanq>$ guix package -r .* for each user, and then $ guix system reconfigure marrow.scm as root <ryanwatkins>buenouanq: seems like it, I am getting this inability to upgrade packages, something must have went wrong, so need to go back to gen 1 :D <buenouanq>but wait, does that account for user packages?... <ryanwatkins>buenouanq: should do yh, I specify the user packages inside my config.scm <buenouanq>$ guix package --roll-back might be more what you're looking for then <ryanwatkins>buenouanq: from (use modules (me guix packages ...)) <buenouanq>I should really make an effort to better understand and try all the features of guix ( ._.) <ryanwatkins>buenouanq: that was brilliant, one guix package --roll-back was enough it seems! <ryanwatkins>buenouanq: likewise, I have the manual up at times, I will read through it all eventually, I promise you based computer science god :D <solene>nckx: I tried your iso on my laptop which doesn't supported 0.13 release, it boots. During the boot process it hangs for 1 or 2 minutes then I get the keyboard, and it screams about some pci device. I didn't tried to install it yet <civodul>reepca: just looked at your message and at the code, it looks great! <civodul>i gave a couple of debugging hints, but we can try to investigate further here <civodul>perl-datetime-format-strptime-1.56 FTBFS on core-updates but if we upgrade it we have to upgrade many things apparently <magnicida>is it possible to use "guix import nix" with a local file? <magnicida>like "guix import nix ./default.nix some_attr" <magnicida>i just tried that but got a cryptic error message, not sure if I am doing something wrong <catonano>sneek later tell rekado_ how iis it going with the new build farm ? <wigust>sneek: later tell magnicida I think local nixpkg checkout is the only way. As (info "(guix) Invoking guix import") says `guix import nix ~/path/to/nixpkgs libreoffice`. You are using ~/path/to/nixpkgs/default.nix as I see. <rekado_>catonano: berlin.guixsd.org seems to do well. <sneek>Welcome back rekado_, you have 1 message. <sneek>rekado_, catonano says: how iis it going with the new build farm ? <rekado_>It only has access to *one* build node, though. <rekado_>before I start setting up more nodes I’d like to figure out how to do a remote deployment. <rekado_>If I can install GuixSD remotely I would just place more servers in the rack and then install them remotely. <wigust>Where can I specify whether patches are upstream patches? Inside themselves? <efraim>I generally leave notes inside the patch itself <Apteryx>Hello Guix! Could someone recommend a GPU which would be good for at least 2 DVI/HDMI output and work with linux-libre (no blob)? <Apteryx>It needs to be a card (can't be integrated intel), as I don't want to change the motherboard/CPU. <civodul>ACTION has integrated Intel & doesn't know what to recommend <solene>apteryx : is it possible to buy 2 cards ? :) <Apteryx>solene: Yes, although that's suboptimal :) <solene>if you don't need a powerful GPU, you can buy a low-end card with 2 outputs. I don't know if nvidia is better supported than amd cards with free drivers. I think that currently they both works correctly. I have been using nvidia cards with nouveau a few times ago and it worked well <nckx>solene: Screaming sounds very promising. <nckx>Sounds like it booted and didn't panic? <nckx>That's better than before. <solene>nckx: yes, on my work laptop I still have the problem with the screen and nothing booting at all, but I tried another linux distro and it does the same thing. I think that last times I installed my laptop, I used a virtual cd emulator in usb (it's an external hard drive case which can emulate an optical drive from ISO on the disk) <Apteryx>solene: I have an nvidia Quadro NVS 295 at work, it's like a 40 USD card. It has two outputs (DisplayPort) and works with Nouveau. The video was very bad (flickering, dropping completely), but that might be due to my requirement to use DisplayPort -> DVI adapters since the panels don't have DisplayPort inputs... <nckx>solene: Interesting. Hm. You didn't mention the other image. Did it not work? <Apteryx>I'll try to find a panel with DisplayPort input so that I can test without the adapters. I hope it would be just the adapters fault! <Apteryx>civodul: Thanks anyway! Sad things is that Intel seems to be going with blobs for their next high gen integrated GPU solutions (I've not researched that carefully but saw this a couple places on the web) <solene>nckx: I'll explain from beginning :) I have 2 laptops. None boot with 0.13. With your latest image from yesterday, one boots. But in fact, the one that never boots (my workstation) seems to not like usb boot <solene>apteryx : I'm not sure your problem is due to the converter <solene>maybe, if you can afford, try a 40$ amd card ? <Apteryx>Right. Will do a couple more experiments today and see. Thanks for the tips! <nckx>solene: So the .iso won't boot and you can't boot the .img from USB. OK. Hm. <atw>I'm also looking for hardware recs in general. Is integrated intel good with free drivers etc? What about wifi chipsets? I'm thinking about getting an xps 13 and replacing its wifi card with one from thinkpenguin. <jonsger>atw: you should have a detailed look on form factor of the wifi-card in the xps13. because there are a lot <ng0>intel gpu support is good <ng0>my personal experience with intel wifi in Lenovo X + T Series (with the non-free linux+firmware) is that (some) Intel Cards as used by Lenovo are uber crap, but that's possibly a Lenovo thing as I've read. <ng0>I have no ideas about XPS. <ng0>well the non-free drivers wouldn't matter anyway, but.. yeah. <Vceqy>hi #guix, I was wondering: is there a way to install GuixSD on a machine that can't boot from USB? <rekado_>Vceqy: since the installation image is just a raw disk image I think it should be possible to write it to a regular disk and boot from there. <nckx>Vceqy: Or you can bravely test the ISO. <Vceqy>I used dd to write the image to the second hard drive and it booted, but I got an error "waiting for partition `gnu-disk-image'" <Vceqy>where can I find the ISO if there already is one? <nckx>It's vanilla, nothing special, but I don't think there's an official ISO yet. <nckx>That error sounds like the kernel can't find your second hard drive, though. Weird. <Vceqy>I'm going to have to go afk in a bit but I'll see if the same thing happens when I boot from the first drive. I'll give the ISO a go if that doesn't work <civodul>rekado_: there's a 'guix offload' process on berlin that's stuck in the slot-allocation loop, which is probably normal, except its heap keeps growing <civodul>which is weird because strace doesn't show any brk(2) or mmap(2) whatever <efraim>I take it back, the .1 seems fairly standard <ng0>test elements/multisocketsink in gst-plugins-base fails <lfam>Can't stop typing 'buigs' while trying to type 'bugs guix' into my browser history <lfam>We've invented a new and better type of bug <lfam>ng0: Do you know since which commit that test fails? <ng0>dunno excatly, at least since bb0f6d7526477c321d025bc8e2dcb019dcc1f415 <ng0>there's b77cc624eccfcffbe9a2ad6e4e4ab2eb4f2a8b74 for "gst" in the log message <ng0>but I've build my system after that <ng0>I think even yesterday <ng0>too tired today, maybe someone else can look into it <ng0>I'll be off, have a nice evening <rekado_>I’m fascinated to see how many people keep spelling “Guix” as “GUIX”, even after correcting them repeatedly. <jonsger>rekado_: did you ever hear people saying "python"? <civodul>rekado_: yeah i wonder how that's possible! <rain1>i can't come up with any backronym for GUIX <civodul>"graphical user interface for X" i guess? <davexunit>since we're venting about that thread... I am in disbelief at how dysfunctional GNU can be, and I already knew that it was dysfunctional! <lfam>I suppose that the best thing to do is make Guix so excellent that it can't be second-guessed ;) <civodul>rain1: there's an old private GNU mailing list that's really terrible <davexunit>the troll in me would love to correct RMS, the ultimate pedant, on using "GUIX" <civodul>ACTION fixed a memory + FD leak in 'guix offload' <rekado_>civodul: oh, the one that caused the hang on berlin? <rekado_>davexunit: oh, that would be delicious! :) <civodul>rekado_: did it hang? but yeah, i noticed it on berlin <civodul>i wonder how that went unnoticed for so long <rekado_>I didn’t actually look at it. “hang” was just my summary of “stuck in the slot-allocation loop […] except its heap keeps growing” ;) <civodul>ah yes that was the problem but it didn't hang i think :-) <cbaines>evening all, I've got an operating-system that I'm trying to use in a VM, but I'm not getting a login prompt, any ideas what I'm missing/have broken? <civodul>do you see shepherd messages about things that get started? <cbaines>I get lots of Service ... has been started, but I've got lots of services, so it's difficult to spot specific ones <rekado_>cbaines: is the VM host using the serial console to connect to it? <rekado_>cbaines: or is this nothing fancy, qemu as usual? <cbaines>I'm using guix system vm with no extra arguments at the moment, just passing -m to the script that it creates <cbaines>and I'm getting a window, in which I can see what I guess is the console <rekado_>and if you hit return repeatedly, does it not show you a prompt? <civodul>maybe check the service dependency graph with "guix system shepherd-graph", to make sure there's not something obvious preventing term-tty* from starting <lfam>cbaines: How did you invoke the VM host? <lfam>Ah, nvm, I see you are using `guix system vm`, which handles the QEMU invocation for you <lfam>I have to go soon and thus can't help debug, but I would inspect the generated QEMU invocation (in run-vm.sh) to see if the virtual console is somehow broken. In that case, the agetty-service could provide a login prompt on the serial console. <lfam>This sort of thing should definitely "just work" though <cbaines>It's possibly just me being impatient, the system is still starting services, just slowly, maybe the login one is near the end of the queue <cbaines>I'll try throwing more cores at it, and, well, being patient <cbaines>While I'm here, is there an easy way of using QEMU in a way that provides access via a shell, but allows scrolling back through the output? <cbaines>say, running it in a terminal with the output there, but still being able to login and poke around <cbaines>I've seen that the system tests that Guix runs output to the terminal, but I'm not sure about the login bit <civodul>you can use "-serial stdio" and append "console=ttyS0" to the kernel command-line <civodul>and you should still get a window with 'login' runnin on each tty <cbaines>for some reason, when I try those options, I end up in the early boot Guile... <cbaines>this may hint at why "no boot file passed via '--load'" <rekado_>In that case you should use the agetty service, though, no? <rekado_>on actual hardware there is no prompt when using mingetty <civodul>cbaines: that's because you must *append* to the kernel command-line, not replace it <rekado_>cbaines: you can take a look at the configuration file for berlin.guixsd.org in the maintenance repository. <rekado_>it is configured with serial console support. <lfam>I'm so happy to see the agetty-service used :) <cbaines>civodul, I'm using -append console=ttyS0 but I guess that is not working <cbaines>the full qemu-system-x86_64 invocation already contains -append <rekado_>cbaines: “console=ttyS0” is to be appended to the kernel args, not to qemu <civodul>cbaines: the second "-append" overrides the first one <cbaines>Ah, yeah, the docs say: -append cmdline <cbaines>is there an easy way to do this with the script that guix system vm produces, or do I need to customise the behaviour earlier <civodul>cbaines: i usually copy/paste run-vm.sh and amend the "-append" argument <civodul>the procedure that generates the script has an option for that though <civodul>maybe we should expose it at the command-line interface? <cbaines>I think that would be great, I was looking to see if guix system vm had options <cbaines>it just took a while for all the other services to try starting <civodul>you must have a lot of services no? :-) <civodul>besides, i think we should use Fibers in the Shepherd and make it non-blocking <civodul>BTW, i've finally incorporated that git-predicate change! \\o/ <cbaines>civodul, quite a few, but actually I think they were starting really slowly, and failing quite a lot, which meant shepherd spent more time retrying <cbaines>civodul, great, thanks for continuing to move that forward :D <cbaines>back in my VM, for some reason QEMU is using 200% of the CPU time on my 4 core system, but htop in the VM shows barely any CPU usage at all <cbaines>I think there is some kind of performance issue, as I didn't think it would be this slow <cbaines>I'm pretty sure, I have /dev/kvm on the host, and Guix put the -enable-kvm flag in to the qemu options <cbaines>I think it might be IO related, strace shows a lot of open and lstat activity for the /gnu/store directory <civodul>normally it uses the "virtio" thingie, which is rather fast <civodul>well /gnu/store is actually a 9p mount <cbaines>yep, I'm reading up on all these things at the moment <cbaines>as a crude benchmark, I've tried running: time find /gnu/store*-guile* -name guile