***ueno_ is now known as ueno
<efraim>10.25 hours to build basically from bootstrap binaries to gettext <efraim>with the extra phase in gnu-build-system, I should `guix challenge` gcc-4.9 and perl before it gets merged into master <efraim>ok, thats a non-event, its a leaf package <efraim>from guix import pypi setuptools, python-setuptools wants python-setuptools as an input <jubalh>is it hard to bring golang to guix? <taylan>jubalh: it uses a self-hosting compiler, right? <rekado>someone was working on packaging Go. There had been a couple of unresolved linker problems. <rekado>not sure what the current status is. <civodul>ACTION fell badly on the ground this morning <civodul>but i'm fine, it's just that i walk slowly <wingo>and go to the doctor or physical therapist as needed :) <efraim>jubalh: I was working on packaging go, the plan was to use gcc5 to build go-1.5, but mulitple 6 hour build failures later i'm using gcc4.9 to build go-1.4 to build go-1.5 as an interm step <jubalh>efraim: do you know what what was the problem with the builds? <efraim>hopefully I can get started on that again next week, first I wanted to finish python for core-updates, and I think I'm nearly done with connman <efraim>/gnu/store/yz1gpp326fwmjgg03ii464k9l94zyc5h-gccgo-5.3.0/bin/go: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib") <efraim>/gnu/store/yz1gpp326fwmjgg03ii464k9l94zyc5h-gccgo-5.3.0/bin/gofmt: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib") <efraim>and this one: /gnu/store/yz1gpp326fwmjgg03ii464k9l94zyc5h-gccgo-5.3.0/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cgo: error: depends on 'libgo.so.7', which cannot be found in RUNPATH ("/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib") <efraim>so it's going to take some more playing, I don't think I've tried making glibc a propagated input yet <efraim>once I get gccgo4.9 to build go-1.4 I'll switch the inputs and use go-1.4 to build go-1.5, and then the great hunt continues for a standalone hello world program written in go <jubalh>why does "guix package -i glibc-locales" need to download linux libre? <jubalh>ACTION is using guix ontop of a foreign distro for now <efraim>hmm, I'm not getting substitutes on core-updates from hydra <efraim>glibc-locales inherits from glibc, and there's a note in glibc's formula: Glibc's <limits.h> refers to <linux/limit.h>, for instance, so glibc users should automatically pull Linux headers as well. <efraim>oooh, guile is a 5 hour build on arm. I might need to find a new package for testing <civodul>efraim: is it just gccgo 5.3 that fails, or also 4.9? <efraim>I belive gccgo4.8 builds fine on all architectures, so 4.9 should also <civodul>another big chunk of GCC under a non-copyleft license, bah... <efraim>that build process was really just s/4.8/4.9/ <efraim>I haven't looked at the makefile yet for go inside gcc <civodul>i suspect "-L $(libgodir)/.libs" might cause libtool to ignore libgo.la, and then to not set -Wl,-rpath ***TML-prv is now known as TML
<jubalh>can somebody tell me whats making problems with having lvm on guixSD? <mark_weaver>there's no problem, it's just that no one has done the necessary work <mark_weaver>so it's waiting for someone who (1) wants to use LVM, and (2) is willing to do the work. <rekado>zacts: do I remember right that you were playing with LVM on GuixSD? <jubalh>zacts is here again? i meet this guy in all the channels i go ;) <efraim>python-sphinx failed to build with just python-setuptools upgraded <efraim>with the freeze coming up I might have to work on python on a separate branch <Steap>efraim: what is the issue with python-sphinx ? <efraim>I just left the build running and went about my day, takes me a long time to build everything from source <Steap>oh yeah, it is a pain indeed <efraim>python2- built fine, I'm rerunning python- <civodul>jubalh: Sleep_Walker did some initial work on LVM support that needs to be polished <koosha>I get this error : " error : failed to download up-to-date source , existing " <rekado>is this the actual message? Is there anything before or after that you could send us, e.g. by posting to paste.lisp.org? <koosha>Ok , let me post the whole message <koosha>Also , I have some problems when I run this command : "guix system init /mnt/etc/config.scm /mnt" <koosha>I write it . But It's a bit hard . Because I should type it <rekado>oh, I thought you can just copy it. <rekado>do you not have network on the machine? <keverets>GNU screen can be useful for copy & paste in text mode <keverets>space to mark the start, cursor to the end, space to mark the end <rekado>"C-a [" means "press 'Ctrl' and 'a', then '['." <koosha>for the last error line of "guix system init /mnt/etc/config.scm /mnt" command : ' guix system : error:build failed: build of '/gnu/store/64gkjcn7k43fn824f8wbzizn1jj1a6pz-system.drv' failed <koosha>Well , I got what you said , but there is still problem to copy that hier . I'm not on irc on that system . <koosha>What do you think about the error ? <keverets>could you paste it into a file, then from there copy it to the machine running IRC? Or alternatively ssh from the machine running IRC to the one with the error <keverets>Is there more information about why the build failed? I'm not sure where logging for that would go <koosha_>sorry there were some problems with irc <efraim>iirc there's a bug with the nameserver configuration or something, thought that might have something to do with the message <efraim>you're using the install image or installing from an existing system? <efraim>normally a "failed to download" error is hydra overloaded or no network access <rekado>or is there always the same error? <koosha_>I have tried it manz times since morning , and yes , It's the same error <efraim>which file was it trying to download? <efraim>which file specifically when it failed <jubalh>i am going for test install of guixsd. created a qemu disk and wanted to boot the usb image but qemu sais "no bootable device" anything i am doing wrong? qemu-system-x86_64 -m 1024 -hda guixsd.img -cdrom guixsd-usb-install-0.9.0.x86_64-linux <efraim>jubalh: hard disk boot is the default for qemu <efraim>so you should pass it -boot once=d <civodul>someone should turn it into a section in the manual <jubalh>argh, right i always forget that <koosha_>'guix substitute: warning: failed to look up host 'hydra.gnu.org ' (Name or service not known) , substituter disabled ' <koosha_>'guix system : error: build failed: unexpected EOF reading a line' <rekado>this might be related to the nscd bug. <rekado>koosha_: try as root: "deco restart nscd" and then retry. <jubalh>maybe a -net nic and -net user is needed to have qemu network adress <jubalh>nope. still. btw this happens with /gnu/store/hash-base-initrd.drv <jubalh>well there just doesnt exist an /etc/resolv.conf file <zacts>rekado: I wanted to test LVM + Luks full disk encryption on GuixSD, but I've been busy lately <koosha>Oh , my god . I got the same reasult when I ran 'guix system init /mnt/etc/config.scm /mnt' but the error of 'guix pull' didn't appear <bavier>koosha: is your config.scm mal-formed? i.e. are you still seeing the "EOF reading a line" error? <koosha>then I changed device '/dev/sdx' , device 'root' to my hard device and to device '/dev/sdax' my partition . also I changed user . <alezost>koosha: could you paste your config? <koosha>I just changed those which I said <efraim>double check all of your parenthesies <koosha>Is it wrong ? (device "/dev/sda2") <bavier>koosha_: if you're speaking of the grub-configuration, you need to specify the unpartitioned device, so "/dev/sda" <alezost>koosha_: then it's ok. what exact error do you get? <bavier>koosha_: ok, did you then also change (title 'label) to (title 'device)? <bavier>koosha_: see the "File Systems" section in the manual <bavier>if you want "/dev/sda2" in the 'device' field, you'll need to use (title 'device), or put the partition label in 'device with (title 'label) <ebisu>Guix looks cool. Is there anything in particular that is does well? Is it intended to be a general use machine, a modular dowhateverthefuckyowant box, a server? Are there any really cool things about it I should know about? (Slackware user here) <df_>ebisu: er, I'm sure there's better propaganda online but: declarative system configuration, transactional system modifications, per-user setup without redundancy, a nice high-level systems language, reproducible builds and (for guixsd at least) an emphasis on software freedom <bavier>the software freedom bit applies equally to Guix and GuixSD <df_>well guix itself is free software but I don't think in itself it particularly does anything to promote or demote free software <ebisu>It looks cool in comparison to a lot of the other completely free distros <ebisu>Trisquel was a huge turd too <ebisu>I dont know what I expected from Ubuntu though <bavier>df_: the Guix project as a whole has made a strong commitment to supporting free software, and only including free software packages. Others are free to write recipes for non-free packages, but they will never be made a part of Guix proper <df_>I'm probably not quite clear where the line is drawn between guix and guixsd ***aeva` is now known as aeva
<efraim>guix can coexist with/exist on a host distro, guixsd is "guix, the distro version" <df_>ok so the available packages are considered "guix"? <efraim>guix and guixsd use the same set of packages <efraim>guix I suppose could be considered like a package repository, with guixsd the distro built around it <user5252>There's a 404 error on the server that provides libev package when installing with --no-substitutes <efraim>it's not the most recent version, so it got moved <user5252>efraim: thanks. Should a guix refresh fix that? <efraim>guix pull will update the package definitions <zacts>user5252: I don't think so yet <efraim>this is at least the 3rd or 4th time I'm compiling perl-5.22 today <efraim>i just updated libffi, which triggered a 3 hour build cycle, and now I'm building xev and it seems to want to rebuild a lot of the things I just built <efraim>I might have to look more at LFS to see how the system is built, that might explain why it seems I'm building and rebuilding the same packages <efraim>I meant to install guixsd today on a pentium4 I have in the corner, might have to do that tomorrow <efraim>oh civodul: during your vacation someone was looking at dmd on arm, and the test that fails is one that you wrote <civodul>efraim: yes, mark_weaver opened a bug for that one <civodul>to understand the rebuilds, you can also look at, say, guix graph -e '(@@ (gnu packages commencement) coreutils-final)' <civodul>with "-t bag" it's a bit more concise <bavier>civodul: I wasn't thinking of directly supporting the "rebuild graph" idea with 'guix graph' <bavier>i.e. producing the graph implicit in `guix refresh -l` <civodul>bavier: ah sure, but efraim was wondering why things get rebuilt; sometimes viewing the graph can help <civodul>sometimes not because it's too big ;-) <jubalh>i wonder if the file is corrupted. now that i created /etc/resolv.conf just by hand i get the next error <rekado>jubalh: you shouldn't need to create resolv.conf manually when you can just start dhclient as suggested in the manual. ***zimmermann_ is now known as zimmermann
<pecg>Hello. Does guix let the user write declarations for building packages from source? <pecg>fps: I almost cry of happiness right now <pecg>These are the best news someone could have ever recieved <pecg>I'm exagerating. But really good news for me <civodul>mark_weaver: Boost has a 140 dependents; should we move to separate branch? <bavier>civodul: also, some are pretty big builds, e.g. libreoffice and dealii <civodul>bavier: yeah; i've emailed mark_weaver & you <civodul>probably best to create a separate branch and have hydra build it <davexunit>civodul: thanks for fixing up that dmd patch. I'm incredibly behind in all things guix right now.