<buenouanq>Anyone have any suggestions to getting spell checking working? <buenouanq>I'm worried it's some weird path issue I'm not going to be able to sort out. <jin>hi guix, how i load by default a module with kernel-arguments? <jin>is right?, (kernel-arguments '("modprobe=bcm5974")) <jmd>bavier: I think your email address has been misspelt in gnu/package/jrnl.scm <jmd>This new machine that Guix has acquired - what will it be used for? <jmd>It does mention the build farm. But then it says "this machine will not be used to compile packages" which leaves me to wonder what it will do? <jmd>Just a file server? - then the hardware sounds like a hell of an overkill to me. <rekado>jmd: it runs hydra, so it must prepare evaluations, compute derivations, compress build requisites and transfer them to build machines, fetch the build artifacts from build machines, etc. <waynedpj>ahoy all, musician interested in trying our GuixSD but couple pre-questions: how difficult for non-hacker to use libre kernel with rt patchset? how far is LVM support? thanks <waynedpj>could not find answers in help-guix list archive <rekado>waynedpj: LVM works, but you cannot yet boot from it. <rekado>waynedpj: I don’t use the rt patchset. Do you use the computer for live performances? <waynedpj>rekado: thanks, so that just means /boot cannot be encrypted? <rekado>waynedpj: I’m using GuixSD on a recording machine with Ardour+JACK+Calf <waynedpj>rekado: yes, i use a laptop for effect processing live <rekado>waynedpj: you don’t need LVM for full disk encryption <rekado>alas I’m not the right person to ask about full disk encryption <rekado>for custom kernels it may take a bit of effort <rekado>it’s not very difficult to create a custom kernel package <waynedpj>rekado: i am not even to the disk encryption stage (think my computer would be too slow Core 2 Duo), just use LVM to simplify partition management <rekado>with the rt patch set I’d recommend taking the linux-libre kernel package and inheriting from it. Then override the “patches” field such that it includes the rt patches. <rekado>I don’t know if the rt patches apply cleanly to linux-libre, though. <waynedpj>rekado: ah Libreboot. unfortunately i also doubt that my hardware is on the short list <waynedpj>rekado: that is more/less what i do now with Gentoo and the rt patches apply to libre kernel fine, at least with 4.4.2 <rekado>with libreboot GRUB is on the BIOS chip, so you can decrypt the disk right there. <rekado>if you can make a linux-libre-rt package that would be useful for others too. <rekado>we would welcome a patch adding this <waynedpj>rekado: yes, it seems like Libreboot offers lots of improvements like that, ashame it does not seem to cover much hardware yet <rekado>waynedpj: np! Feel free to ask for help when you get stuck or something’s not clear, before wasting too much of your time :) <waynedpj>rekado: sure, if i could get a kernel-libre-rt package going, definitely would share .. but long way to go yet ;) <waynedpj>rekado: thanks again, good to know GuixSD is already being used for music production .. will see about using LVM but not for /boot before installing <ng0>is marius bakke around? any reason why my milkytracker patch was not applied and instead a new one was created? <waynedpj>kmicu: looks interesting and would be great to have a GuixMD (Music/Media Distribution) .. but i am still trying to figure out how to get it installed ;) <ng0>so someone pushed my patch, but somehow something else ended up in master? <ng0>1b35fea19f4675e9491479c4fb09a626357716db irritates me, that's all <jmd>ng0: What do you mean "something else ended up in master"? <jmd>Are you suspecting a bug in git? <ng0>I've just replied to an email at guix-devel <ng0>this commit has "reported by ng0" in it, but I never reported it. I worked on a patch, tested it, and sent it <ng0>ok.. I'm not actively keeping track of the mailinglist <ng0>I only read the reply I just replied to <kmicu>(Not saying it’s a good thing, personally, I prefer engaging contributors.) <ng0>i personally don't care whose patch ends up in master <ng0>it's fixed either way <ng0>oh, the email ended up in misc, not guix that's why I spotted it just now <ng0>okay, there's the reason in there. <rekado>waynedpj: re "GuixMD": it's very easy to "remix" GuixSD. All you need is to prepare an operating system configuration and maybe a manifest for a user profile. <waynedpj>rekado: very cool, reminds me of something similar possibly in Funtoo/Gentoo. is there documentation on that? i assume that is basically what musNix does <csanchezdll>uh oh, seems debian 9 drops ppc support... I feel like swimming against the flow... <bavier>jmd: indeed, thanks for the pointer <jmd>bavier: You're welcome. ***kelsoo1 is now known as kelsoo
<Apteryx>Do I really have to issue this command before I can use "guix build" with the pre-inst-env script? "sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild" <rekado>Apteryx: guix-daemon must be running. <rekado>it doesn't matter much which version is running <fredmanglis>I'm trying to contribute a new package to guix, but the package in question (ruby-net-http-digest-auth) doesn't have a license <rekado>so you don't necessarily need pre-inst-env with guix-daemon <Apteryx>rekado: OK. Can two versions of the daemon run at the same time? <Apteryx>Because the above command never returns in my case. <rekado>this says that it's the expat (aka MIT) license <rekado>Apteryx: it's a daemon, it doesn't return <rekado>you can append & to the command to make it run in the background <Apteryx>Ah, makes sense now that I realize that ;) <Apteryx>rekado: Maybe there should be the ampersand (&) at the end of the command in 8.2 of the manual, because it does look like we should type sequentially the two commands to achieve a build, and there's no mention that the first one never returns. <Apteryx>Am I supposed to run the "pre-inst-env" prefixed commands inside a guix environment? Or is this taken care of by the script. <bavier>Apteryx: it doesn't need to be inside a guix environment <bavier>Apteryx: did you configure with guile-gnutls? <Apteryx>bavier: Oh, this isn't part of the default build? No, I didn't. Any other flags I should consider enabling to have feature parity with the guix-daemon shipped with GuixSD? <bavier>Apteryx: guile-gnutls is detected by configure, so no flag needed. you can configure and build within a 'guix environment guix' <Apteryx>OK, I will try again, although I followed the manual and built in a guix environment setup like that: guix environment guix --ad-hoc help2man git strace <bavier>Apteryx: and you started guix-daemon and ran 'guix' with ./pre-inst-env? <bavier>(or used an already-running daemon) <Apteryx>After the bootstrap, configure and make check, yes, that's what I was attempting now (start daemon using pre-inst-env, then try building my package using ./pre-inst-env guix build udisks. <Apteryx>I noticed that when I start the daemon it replaces any guix-daemon currently running. <Apteryx>I'll go through these steps again and let you know of the result! Thanks. <bavier>if you have a daemon already running, you don't need to start another <Apteryx>bavier: I wanted to use everything guix related from its git, just for the sake of it. <Apteryx>But yes, if I can't get it working I'll fallback to using my working daemon (default build). <Apteryx>Is this something dangerous to have such a collision when I run "guix environment guix": warning: collision encountered: /gnu/store/5k8z2aj8ca16nmvwvdsl0mdc3slm14k2-ld-wrapper-0/bin/ld /gnu/store/z53lxlrp7061vggbnhpxcsmad6lx96p8-binutils-2.25.1/bin/ld ? <Apteryx>Seems like potentially a normal side-effect of the "environment" command, given the "wrapper" in the path. <bavier>I don't recall hearing of any cases were's there have been problems <Apteryx>bavier: I can confirm that configure says: "checking if (gnutls) is available... yes". I'll rebuild and we'll see :) <Apteryx>Strange thing is that it passed all the tests. <Apteryx>Trying a "make clean" then "make -j3 check". But I have to go. Later! <atheia>Does anyone know where the guix packages page code lives? <atheia>I remember doing some initial work with it, to get the JS to work for it back in the day, but I believe the script for generating the page was part of the main Guix repository back then…