IRC channel logs


back to list of logs

<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?
<buenouanq>didn't it say a new buildfarm?
<jmd>Yes and no.
<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?
<buenouanq>host them
<buenouanq>it's the new server
<buenouanq>or that's what I understood
<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.
<rekado>it’s not just a file server.
<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
<waynedpj>rekado: wow, good news!
<rekado>(it’s easier with Libreboot)
<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>okay, cool
<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
<rekado>ACTION has to go now
<waynedpj>rekado: yes, it seems like Libreboot offers lots of improvements like that, ashame it does not seem to cover much hardware yet
<waynedpj>rekado: thanks rekado
<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
<kmicu>waynedpj: you could check and port it back to Guix :)
<quigonjinn>rekado: the url of calf that we use has changed
<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
<kmicu> quotes report about changes and Marius pushed different (minimal) fix.
<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
<fredmanglis>Hi people.
<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"
<Apteryx>fredmanglis: Hi
<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 ;)
<fredmanglis>Thanks people.
<cehteh>err fredmanglis
<Apteryx>cehteh: np
<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
<Apteryx>bavier: OK. Thanks.
<Apteryx>I noticed that when I try to use the git-daemon built from Git, I get the following (gnutls related?) errors:
<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>collisions are usually harmless
<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>bavier: Yikes, it didn't get better:
<bavier>Apteryx: doesn't look good
<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…
<atheia>Ah, nm found it.