<mekeor>how can i build guix? there is no INSTALL file in the git repository. (running `./bootstrap` (which i'm guessing i have to do) fails.) <ng0>the documentation is the "INSTALL" :) <ng0>it covers both guix and guixsd <ng0>i'll be offline soo, so i hope someone will be able to answer further questions :) <cehteh>when ./bootstap fails it should give you some hint about why it failed <ng0>there is file:README, and this has a section about installation and how to compile the documentation though <mekeor>yes, the README says suggests either to read the manual with `info -f doc/guix.info "(guix) Installation"` or online. ***alberto is now known as Guest96596
<albertoefg>when i run guix-daemon --build-users-GROUP=guixbild <atw>albertoefg: according to those instructions, should the argument be --build-users-group=guixbuild ? <albertoefg>once it works for the first time for how long is it supossed to build <reepca>Perhaps it's trying to download/install the dependencies (gcc, etc)? I think it doesn't accept substitutes by default, does it? <reepca>(substitutes here meaning "pre-built stuff from the build farm") <albertoefg>is it bad if my cpu works at a 100% for a lot of time? <albertoefg>it felt like a lot of time since the OS took me 15 minutes to install. I was worried and thought. i did something. wrong :/ <albertoefg>its kinda hard to follow everything for a home user like me :) <reepca>yeah, some of the jargon in the manual can be a bit difficult for people unfamiliar with it. But that's okay, because your difficulties will help the others know what they can improve. <reepca>I think a tutorial section to the manual would be helpful, where it can provide information in the order the new user needs to know it <reepca>it'd be easier for you to test it from a flash drive, I think <lfam>I just loaded IRC to see you say "fixed." I bet I know what it's about :) <paroneayea>there was a minor adjustment to the kobodeluxe package (a minor patch removed from the definition), and I didn't test running make (I *did* do a "guix environment --ad-hoc kobodeluxe" which didn't catch it) <paroneayea>so it was still in the automake files and I didn't catch that this needed to be removed. <paroneayea>oh well, it was only broken for... less than an hour ;) <lfam>I'm getting sucked back into the python-updates thing. I'm hoping to update pytest and still build everything that depends on it. The borg test suite depends on a feature introduced in pytest 2.8.0 when built on core-updates. But not on master, for some reason. <lfam>We only just started running that test suite, so it's not a huge problem if we have to disable it again. But there is at least one other package that wants a newer pytest <lfam>Maybe this can be achieve in one night :) <paroneayea>lfam: I know you asked me to look at beautifulsoup4 <paroneayea>I'll try to look soon... I need to remember the context of what I thought it was <lfam>It had to do with python 2to3 <lfam>You don't have to spend too much time on it. I can always ask upstream for help. I'm having a lot of luck with that this core-updates cycle! <lfam>I'm afraid I accidentally volunteered to write the patch ;) <lfam>We'll have to figure something out since ffmpeg depends on that <Apteryx>Is is normal that Guix doesn't ship with a /etc/resolv.conf? <mbuf>Is anyone here using Guix as their primary OS? <Apteryx>mbuf: Starting with it, but I intend to do so (barring any very nasty issue). <mbuf>Apteryx, what is recommended to run VMs on Guix? <Apteryx>Hmm, I'd think qemu/kvm would work well. <janneke>Apteryx: networking services write that file <mbuf>Can we run Docker daemon? <Apteryx>That's one of the reason I switched to Guix; it was to be able to run a VM for getting started with GNU/Hurd. Got tired of heavy distro using half my RAM. <mbuf>I do not see it in the list of packages <Apteryx>My first boot was using a refreshing 83 MB of RAM. <mbuf>Apteryx, wow! I just want to make sure all that I need is available before installing to disk. <mbuf>Apteryx, what do you use to run a VM? <Apteryx>mbuf: I'm not there yet, but I intend to use kvm. <Apteryx>mbuf: I see there is qemu 2.6.0 as an available package. <efraim>Apteryx: only 2.6.0? We should have a later version than that <Apteryx>efraim: That's still a virgin install, maybe I have to do a guix packages pull? <marusich>Apteryx, yeah, try running "guix pull" and see if you find a newer version. I see version 2.7.0, myself. <amz3>I have a question regarding the patch I've sent, which is about scheme-bytestructures <amz3>In that patch/package I use the trivial build system, and then pass in `(arguments (#:builder ... ))` a quoted procedure <amz3>What I find strange, is the appearence of <amz3>What I find strange, is the appearence of some variables that start with %, like %outputs, <amz3>I am wondering why `(arguments (#:builder ...))' is not a lambda which takes those as argument <amz3>this is kind of guile question <rekado>the arguments are passed to the build side where certain variables are bound that start with % <rekado>apteryx: /etc/resolv.conf is checked out anew every time you boot. <rekado>apteryx: in GuixSD the configuration is declarative, so you don’t edit these files directly. <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, davexunit says: I tried to package Ao and failed. <thomasd>I'm trying to find the cause of a non-deterministic build <thomasd>but now the package is built, `guix build' won't build again... what's the easiest way to force a rebuild? <thomasd>I'm following section 6.1.1 of the manual, trying to build the package twice, and compare the outputs to locate the differnce <thomasd>how can I examine the contents of a ".nar" file (result of guix archive --export) <civodul>ACTION pushed Ao, though still with the GL issue <rekado>thomasd: I’m not sure about the nar format. I think it’s just gzipped data. <rekado>but if the package build is non-deterministic you don’t need to compare with the nar. Just build it twice and look at the difference. <thomasd>ok, I'll try that. The manual recommends "stashing one of the build results with ‘guix archive <thomasd> --export’ (*note Invoking guix archive::), then rebuilding, and <thomasd> finally comparing the two results." but I'm not sure how that should work :) <thomasd>hmm the difference seems to be in cached python object files.. <roptat_>hi, I'm writting a service for the openVPN daemon, which can be run as a client or a server <roptat_>server and client have common configuration entries, and some are specific to the role <roptat_>so I could either implement a different service-type for each role, or a single one, that ignores specific configuration from the wrong role <roptat_>so if I go with only one service, the configuration record will have more entries than necessary, but with two service types, it will have to be duplicated in some parts <roptat_>also I think you can run a client and a server simultaneously <mbuf>Guix does not include any binary blobs that are required by BIOS or CPU? <efraim>mbuf: guix uses the Linux libre kernel which is deblobbed <efraim>roptat_: you can run the client as a user though, right? I would go with two services then <roptat_>efraim, ok, that was also what I started doing <jmd>roptat I recommend two services. <jmd>You might want to use a common configuration for both client and server - I don't know. <roptat_>I think I'll use a common configuration record type for both, because most of the configuration is similar in both cases <thomasd>Maybe I'll try to take a look at that one when I'm done packaging my favourite libraries ***contrapumpkin is now known as copumpkin
<rekado>is anyone here working on packaging jupyter? <rekado>I have an old WIP branch and I’d like to avoid having to dust it off <rekado>our ipython package in Guix is *really* old and now I have users asking for jupyter… <efraim>all I know about jupyter is that it came up within the last two weeks and someoone suggested moving some packagess to jupyter.scm <efraim>Also, I've checked and I haven't found .ix or .scm TLDs for sale <rekado>using gui.xxx probably isn’t such a great idea. <civodul>i don't know what to do of that pivot-root test of ours <civodul>it has mkdir(2) fail with EOVERFLOW, which doesn't make much sense <efraim>looking at zile, do I really need bash specified as an input? I thought now it was implied <civodul>efraim: if you cross-compile zile you want it to refer to the target bash, in its 'patch-/bin/sh' phase <efraim>thought I should ask before removing it :) <Apteryx>rekado: OK. I guess I'll have to read the manual more thoroughly :) <Apteryx>Hmm, zile thinks my backspace is C-h ? I've set the dvorak layout using setxkbmap. Any idea? <Apteryx>Petter: Oh. There is an explanation of the EmacsWiki: Traditionally, Unix uses the ^H keystroke to send a backspace from or to a terminal. Emacs, not coming from a Unix background (see CategoryHistory), does not respect this tradition.Traditionally, Unix uses the ^H keystroke to send a backspace from or to a terminal. Emacs, not coming from a Unix background (see CategoryHistory), does not respect this tradi <Apteryx>Yes, in the way of settings binding for C-h, such as: (global-set-key [(control ?h)] 'delete-backward-char) <Petter>Ok, and binding help to something else I assume. <Apteryx>Ah, I hadn't thought about that, but yes, they suggest remaping help to hyper-h. <rekado>just added a d3js graph backend to generate an interactive force-directed graph, but it’s really hard to see anything… <rekado>there are just too many nodes. Need a better visualisation. <amz3>ogma.js is for big graphs <rekado>“Ogma is available in a proprietary license only” <rekado>d3 is nice. I just need to add a few more things to change the opacity of links that are not inspected. <Petter>Apteryx: You triggered me to find an Emacs solution for working with remote files (I'm a pretty new Emacs user). I've now discovered TRAMP and having fun learning new things : ) <rekado>guess I’ll rewrite this to show only n neighbours by default, showing n more on click. <lfam>efraim: Are you using aarch64 hardware? Would you recommend whatever you're using? <efraim>I have the odroid-c2 and pine64 unboxed <efraim>my hikey96 is still boxed since I think I need to flash it specially <efraim>everything has worked easily out of the box with debian <efraim>and I was looking at using it as a cheap, slow desktop replacement (beacuse I can), and so far it seems like it should be okay <efraim>unfortunately I think they all are using kernels with a bunch of custom patches, but a bunch of the people with teh boards are writing patches for the kernel so the odroid looks like it might be mainstreamed eventually <efraim>the price is nice too, ~$40 for the odroid, ~$50 for the pine64, ~$100 for the hikey board <efraim>I limited my search to boards with HDMI support, can boot from SD card, and had 2GB of ram <lfam>The kernel issue is annoying. They all advertise "runs Linux" when they really mean "runs our 5 year old fork of Linux" <lfam>And then they rely on volunteers to get their hardware supported in Linux itself <efraim>or "we got it working with android and I guess you can use the same kernel to run gnu/linux also" <lfam>Have you tried building Linux on any of them? I'm wondering how long that takes <efraim>building the custom kernel on the odroid wasn't too bad, under 20 minutes on an SD card i think <lfam>What about the linux-libre kernel? ;) <davexunit>do any of these machines have 3d accel with libre gpu drivers? <lfam>It seems like low-cost aarch64 is still limited to the Cortex A53 CPUs. I think I'll wait for (or pay more) for a beefier processor <efraim>there's also the $300 board with 2 ddr3 slots <lfam>Wow, there are lot more options on that site than the last time I checked <lfam>The AMD offering have specs I like but it's still in "pre-order", which is such a lame euphemism <lfam>"scheduled to ship in Q2 of 2016." <efraim>huh, I thought there was one already for sale, I'll look a bit more later <lfam>I like Olimex, and they are going to ship an A53 system based on the Allwinner A64 soon. But again, just A53 <lfam>And not really very beefy <lfam>I'd want something that can be used as a builder <Apteryx>Petter: emacs in an adventure full of surprises ;) <efraim>I feel like the main reason we have the novenas for build machines is the 4GB of ram <lfam>Also, that chip (iMX6) has open datasheets, a supportive manufacturer, etc <lfam>Although, the iMX6 is now to acquistions in the past. Freescale -> NXP -> Qualcomm <lfam>So, the party is probably over <lfam>The good thing about Cortex A9 is that it is an out-of-order CPU. I think it's the "lowest" ARM design that is out-of-order <jmd>lfam: What would need to be done to get it working again? <lfam>jmd: Get what working again? :) <lfam>I'm confused. Do you mean the iMX6? <jmd>You said it was out of order. When can it be repaired? <lfam>The good news is that we can do some other tasks while we wait for the repair to complete ;) <efraim>... I replaced the boot0 make with an unpatched make and SUDDENLY it could find the source and unpack it and start building <efraim>I also learned that on a 1440x900 screen I can split vim into 3 windows and still have 80 columns in each <lfam>Heh, I bet you feel pretty good right now :) <efraim>having it cut off at 76 is really distracting <lfam>I'm currently rebuilding everything that depends on pytest to see if we can upgrade it alone. Fingers crossed! <lfam>It will be fun if it works. Otherwise it's pure misery ;) <lfam>I wonder if the suggested solution is a problem for us, however, since our package explicitly sets that option the other way <civodul>lfam: looks like it's just about setting CGO_ENABLED=0 right? <civodul>whatever that means, it seems to work <lfam>Heh, you already tried it?! <civodul>but it seems to make the NixOS folks happy so i guess it's fine <lfam>Well, I have my test case application, Syncthing, so I will know if it totally breaks everything <lfam>Ah yes, I'll test that too. I'm also going to try updating Go to the latest stable versionm 1.7.3 <lfam>mysql 5.7.16 failed on Hydra for armhf due to "No space left on device" <lfam>So, I guess we don't really need that for the bootstrap compiler <davexunit>paroneayea: I need to go afk in a few minutes, unfortunately. sorry! <paroneayea>davexunit: no worries. I just booted up wip-deploy again and was going to see if I could mock up my local network deployment. <paroneayea>I can do that async from you being around, too :) <davexunit>sounds good. would be happy to chat some other time. <paroneayea>doing a tramp connection to a remote guixsd machine, even running openssh <paroneayea>TRAMP is a super wonky system using tons of hacks <paroneayea>maybe I need to switch to sshfs for remote hacking <rekado>I haven’t used TRAMP with GuixSD at all. In fact, I haven’t even SSH’d into my GuixSD machine once. <lfam>I've used Guix's mosh and lsh on both the server and the client. And also OpenSSH on the client. Works great <paroneayea>I'm switching my home server over to guixsd, and want to start playing with remote deployment to it <paroneayea>I need to understand better how you can "copy a derivation" over the network <civodul>paroneayea: re tramp, you should check its debugging buffer <paroneayea>civodul: oh cool. Heh, I just wrote an email to the list about this <paroneayea>but also looking for general guidance on how to move forward <civodul>i confirm that Tramp does work on localhost, which is GuixSD <civodul>maybe there's a .bash_profile or something causing problems? <paroneayea>civodul: there's no .bash_profile or antyhing on the remote machine <paroneayea>civodul: what do you have set for tramp-remote-path? <civodul>because otherwise it does "getconf PATH", which doesn't return anything useful <paroneayea>civodul: hm, using that makes it return my local path stuff on the remote path :) <civodul>ah? maybe that works for me because both the source and destination are on GuixSD <civodul>we should make it work out of the box anyway <civodul>$ git shortlog -s --since=last-month|wc -l <paroneayea>civodul: only 47 commits this month? :) feels like more... <civodul>yeah, the number of commits is higher ;-) <civodul>less than NixOS or Debian, but still something to be happy about :-) <paroneayea>civodul: installing perl on the remote machine seemed to fix it :) <lfam>When 0.11.0 came out, I plotted the number of contributors to each release. The rate of growth seemed to be increasing! <civodul>paroneayea: are you suggesting that Perl is installed on my machine? :-) <civodul>actually it's installed in my user profile <kyamashita>Is anyone here familiar with using "guix system vm" or "guix system vm-image"? <lfam>I quit my IRC client accidentally. Please repeat anything I missed :) <kyamashita>lfam: Yay! OK, first question. Can I use my desktop configuration file as input for either of those commands? <lfam>Yes, it should work. That's how I've tested my configuration before I had a hardware installation <kyamashita>Hm. I've been trying to test the new network-manager packages, but I can't manage to build a vm. <kyamashita>I can use either command and it completes, but neither returns a VM. <lfam>Does it return a store path to a VM? <kyamashita>Are these commands usable when preceded by "./pre-inst-env"? <lfam>I'll try it here to make sure the tools haven't broken <lfam>Yes, they are usable that way <lfam>Many substitutes to update :) <kyamashita>It seems to be working using my current desktop configuration and without "./pre-inst-env". <lfam>Okay, I will stop this build, since we know the tool can work :) <lfam>You might try --dry-run for a report on what *should* happen <lfam>And also try using ./pre-inst-env from our upstream master branch, in case your changes broke something :)