IRC channel logs


back to list of logs

<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) Installation"` or online.
<mekeor>and the online manual (at points at the INSTALL file which doesn't exist... :D
<mekeor>mekeor: read this:
<albertoefg>i need help :/
***alberto is now known as Guest96596
<albertoefg>when i run guix-daemon --build-users-GROUP=guixbild
<albertoefg>i get
<albertoefg>bash: guix-daemon: no se encontró la orden...
<albertoefg>no order found...
<albertoefg>what am i missing?
<albertoefg>i did step by step
<atw>albertoefg: according to those instructions, should the argument be --build-users-group=guixbuild ?
<albertoefg>yes atw i did it correctly i wrote it wrong :/
<albertoefg>but i managed it to work
<albertoefg>once it works for the first time for how long is it supossed to build
<albertoefg>when i tried to install hello
<albertoefg># guix package -i hello
<albertoefg>it went to compile and dowload a lot of stuff
<albertoefg>after an hour i thought it was too much
<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 started doin some weird noises
<albertoefg>so i stopped the installation
<albertoefg>it probably was installing all that
<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>because of the noises
<reepca>The smart people are probably sleeping, so let me just point you here
<albertoefg>oh i see
<albertoefg>thanks :)
<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.
<albertoefg>i was thinking about downloading GuixSD
<albertoefg>to test it from a cd
<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
<paroneayea>I broke master very briefly.
<paroneayea>sorry about that.
<lfam>I just loaded IRC to see you say "fixed." I bet I know what it's about :)
<paroneayea>lfam: :)
<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>ACTION nods
<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
<paroneayea>oh right, 2to3
<lfam>It had to do with python 2to3
<paroneayea>yeah anyway, ok
<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!
<paroneayea>lfam: hey athat's great to hear!
<lfam>Although I'm not sure how to interpret this comment:
<lfam>I'm afraid I accidentally volunteered to write the patch ;)
<lfam>Not sure!
<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?
<Apteryx>Is it*
<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.
<Apteryx>Haven't tried yet though!
<mbuf>Apteryx, okay
<janneke>Apteryx: networking services write that file
<mbuf>Can we run Docker daemon?
<janneke>i'm using GuixSD
<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
<janneke>need to run, lat0r!
<mbuf>Apteryx, nice!
<mbuf>janneke, thanks!
<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.
<Apteryx>That's reasonable.
<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.
<mbuf>Apteryx, okay
<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>Héllo :)
<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>and %build-inputs
<amz3>I am wondering why `(arguments (#:builder ...))' is not a lambda which takes those as argument
<amz3>this is kind of guile question
<rekado>amz3 these are special
<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.
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, davexunit says: I tried to package Ao and failed.
<efraim>I thought we had libao
<thomasd>Hi Guix,
<thomasd>I'm trying to find the cause of a non-deterministic build
<rekado>efraim: libao is an audio library. davexunit was talking about this one:
<thomasd>but now the package is built, `guix build' won't build again... what's the easiest way to force a rebuild?
<rekado>thomasd: you can use “--check”
<rekado>guix build --check -K name
<rekado>I think
<thomasd>rekado: thanks
<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
<roptat_>what do you think is best?
<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
<roptat_>the client part is done :)
<jmd>roptat I recommend two services.
<mbuf>efraim, I see
<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
<civodul>thomasd: this may be related to
<thomasd>civodul: yes, though I was using python-3, so it's :)
<civodul>oh ok :-)
<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
<civodul>not me!
<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
<davexunit>gu.ix would be fun :)
<rekado>using 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
<davexunit>is that a test I wrote?
<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
<civodul>that's why it's in 'inputs'
<efraim>ah ok
<civodul>(note: not 'native-inputs')
<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?
<Petter>Hm, here too.
<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>(zile being a clone of emacs, fwiu)
<Petter>Aha, interesting.
<Petter>Does it provide a solution?
<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.
<Apteryx>For the reference, the page is:
<rekado>just added a d3js graph backend to generate an interactive force-directed graph, but it’s really hard to see anything…
<amz3>rekado: do you know about ?
<amz3>maybe it's overkill
<amz3>there is also sigmajs
<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>Yeah :/
<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?
<efraim>I should check
<efraim>the hikey has mali-450
<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>odroid-c2 also mali-450
<efraim>there's also the $300 board with 2 ddr3 slots
<lfam>From odroid?
<efraim>from 96boards
<lfam>Wow, there are lot more options on that site than the last time I checked
<efraim>pine64 has mali-400
<efraim>also A53
<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."
<lfam>I guess I'll wait
<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
<efraim>they're what, A7?
<lfam>Cortex A9, armv7, according to
<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
<lfam>"now two acquisitions"
<jmd>lfam: What would need to be done to get it working again?
<lfam>jmd: Get what working again? :)
<jmd>This Arm CPU?
<lfam>I'm confused. Do you mean the iMX6?
<jmd>You said it was out of order. When can it be repaired?
<lfam>Lol :)
<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>about both actually :)
<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!
<efraim>that sounds like fun
<lfam>It will be fun if it works. Otherwise it's pure misery ;)
<lfam>Our golang issue has already been raised by NixOS:
<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>no i didn't!
<civodul>of course not
<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>Seems unlikely :)
<civodul>we also have "direnv"
<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>"Cgo enables the creation of Go packages that call C code."
<lfam>So, I guess we don't really need that for the bootstrap compiler
<paroneayea>davexunit: around / available to scheme? :)
<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>but... let's talk when you have more time
<paroneayea>I can do that async from you being around, too :)
<davexunit>sounds good. would be happy to chat some other time.
<paroneayea>one thing that doesn't work in guixsd
<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>and hardcoded /usr/bin/ paths iirc
<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
<lfam>Just an anecdote
<paroneayea>I'm switching my home server over to guixsd, and want to start playing with remote deployment to it
<paroneayea>it's already runing it
<paroneayea>but doesn't do much at the moment
<paroneayea>I need to understand better how you can "copy a derivation" over the network
<paroneayea>or a gexp or something
<civodul>paroneayea: re tramp, you should check its debugging buffer
<civodul>i think it works for me
<paroneayea>civodul: oh really? huh
<paroneayea>I wonder what I'm missing
<civodul>to copy a derivation, you can do things like
<civodul>(until we have 'guix copy')
<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>ok :-)
<civodul>i confirm that Tramp does work on localhost, which is GuixSD
<civodul>running lshd
<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>but maybe I am missing some programs it needs?
<paroneayea>civodul: what do you have set for tramp-remote-path?
<civodul>ooh, good point :-)
<civodul>(setq tramp-remote-path
<civodul> (append 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
<paroneayea>civodul: I'll try a few more things.
<paroneayea>I think I might have an idea.
<civodul>in other news:
<civodul>$ git shortlog -s --since=last-month|wc -l
<paroneayea>civodul: only 47 commits this month? :) feels like more...
<paroneayea>wait, it is more right?
<civodul>paroneayea: 47 people
<paroneayea>47 people
<civodul>yeah, the number of commits is higher ;-)
<civodul>pretty cool!
<paroneayea>yeah wow
<paroneayea>47 people in one month, that's a lot
<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>happy dance!
<civodul>paroneayea: are you suggesting that Perl is installed on my machine? :-)
<civodul>it's not! i deny
<civodul>actually it's installed in my user profile
<civodul>how that happened, i'm unsure
<civodul>anyway, good night/day, guix!
<paroneayea>hm, now I am hitting whatever ecraven hit here
<kyamashita>Is anyone here familiar with using "guix system vm" or "guix system vm-image"?
<lfam>kyamashita: Yes, I am
<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.
<lfam>What goes wrong?
<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>No. It just ends cleanly.
<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
<kyamashita>Will do.
<lfam>And also try using ./pre-inst-env from our upstream master branch, in case your changes broke something :)