<jgrant>davexunit: I saw Sly 0.1 is fastely approaching, any plans to get it in Guix once it lands? :^) <davexunit>jgrant: yes. once I release it I will package it for guix. <jgrant>paroneayea: Very exciting to check up on it's progress every once in awhile. <davexunit>I need to test on GuixSD, but I'm having some OpenGL issues. <davexunit>I have a few more blocking issues to work out. <paroneayea>I had more convo with the guix people at fosdem :) <jgrant>davexunit: Should porting over to SDL 2.x going to be a big "todo"? <paroneayea>we also talked about how a (gui) layer on top of guix might help with the "deployment challenges" stuff I talked about *jgrant wonders if how the "OpenGL Next" story might play out for Sly. Guess this is starting to border offtopic though... <davexunit>we could continue in #sly, but the tl;dr is: not gonna happen, my laptop only supports up to OpenGL 3.0 <jgrant>So we have xinit now, but to my knowledge no way to manage/start this? Is "xstart" supposed to ship with xinit and work? <jgrant>mark_weaver: We have xinit now, but I thought xstart shipped with xinit? <davexunit>bleh, self-hosted compilers. cool, but a pain to package. <davexunit>mark_weaver: sorry, I haven't tried. no printer at home. <mark_weaver>davexunit: which compiler are you talking about at present? <mark_weaver>I thought civodul said that cups pretty much just worked for him, but I'm not having the same experience :-/ <davexunit>I used to use it when I had just started learning to program. <davexunit>it's nothing anyone needs, but I took a look to see if I could package it easily. *mark_weaver started with basic on the Apple ][ plus :) <mark_weaver>fortunately I discovered pascal not long after, and C not too much longer after that <davexunit>the cool thing about FreeBASIC is that it has a QBASIC compatibility mode and some sort of FFI. <davexunit>QBASIC was my very first language, unfortunately. <davexunit>but there's much nostalgia in revisting that old junk. <davexunit>having a free software, 32-bit replacement is kind of fun. :) <mark_weaver>my first computer came with full schematics and assembly code listings, and then I had to wait another 35 years to get another computer with those things. <davexunit>wow. yeah, computing really took a bad turn. <mark_weaver>here's a nice Edsger Dijkstra quote: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." <mark_weaver>but who knows what we could have been if we'd started with a better language? we'll never know :) <davexunit>yeah, if only I could have been exposed to Lisp early on. <davexunit>but no one was teaching that in my high school or college. <mark_weaver>yeah, I was stuck in imperative C programming for decades. so much wasted time. <davexunit>I remember thinking that I must be dumb because everyone uses C++ to do stuff and here I was banging my head into a wall staring at segfaults all the time. <davexunit>then I tried Python and I started to see what how much better programming could be. <mark_weaver>I don't even have the same excuse. I took a course that used Lisp in university, and I liked it right off the bat, but never really played with it after that. not until I discovered SICP. <davexunit>college was all Java and C. they only taught dynamic languages in courses for non-CS majors. <davexunit>as if dynamic languages aren't real programming. <mark_weaver>when I was at university (and maybe still today), although I had one course with Lisp, it was overwhelmingly in the "object-oriented programming is the wave of the future, and must be used for *everything*" mentality <davexunit>I had courses in "object oriented design" learning about all the desgin patterns. <davexunit>and C is still taught for UNIX systems programming courses. <davexunit>I enjoyed that. I still like C for what it is. <Digit>i'm currently running nixos (as of early jan), and am wondering how smooth a transition to guix (on whatever distro) would be? is it largely like-for-like, or are there a whole load of nuances|quirks|differences|distinctions to learn new? <ewemoa>Digit: not much help for you, but am interested too -- have finally succeeded in installing guix 0.8.1 after several failed attempts for 0.8 :) <Digit>oddly encouraging though. :) <Digit>i've got a few more background tabs opened from various searches to look through, but it all seems a bit stale. <ewemoa>Digit: hmm...i was encouraged by the news that arm support was starting to shape up :) <ewemoa>substituting whatever odd interface name came up for eth0 ofc <Digit>looks like i'll be learning scheme. :) <Digit>i knew scheme/guile was to replace nix's own functional language, hadnt quite realised how involved it is until that link layed it out. :) <ewemoa>was thinking a pl-independent interface to the underlying system might encourage various pl folks to stop trying to reimplement various already nicely provided bits... <Digit>talking purely functional, i'd already got /a little/ practice in with Haskell. i wonder if it ever got mentioned when early notions and plans were starting. <ewemoa>Digit: no idea -- tried learning haskell years ago but am far too lazy to try to learn irregular syntax -- scheme/lisp is much easier on my aging brain :) <Digit>i came to xmonad before i came to emacs (or anything else that would encourage lisp, like clfswm), hence my quirkyness. wanted to have more reasons to learn more lispness for a while. so the extent scheme is involvd is very welcome. :) <ewemoa>Digit: seems like examining guix packages, modifying them, writing them, etc. would be a good opportunity for guile scheme learning :) <civodul>#:configure-flags is incorrect, should be like: <civodul>#:configure-flags (list (string-append "--llvm-root=" (assoc-ref %build-inputs "llvm"))) <civodul>rigelk: the <gnu/stubs-32.h> error suggests they are doing #undef __x86_64__, or somehow forcing a 32-bit build <rigelk>oh. not sure on how to do this but i’ll give it a try <rigelk>i’m changing the #:configure-flags anyway <rigelk>civodul, i have a go from my university to get my servers having a public ip for the Guix project and a ssh access. <civodul>rigelk: cool, let us know how it goes! *civodul thinks it might be wise to have a "hardware donations" section on the web page <rigelk>civodul, i’m wondering how i should setup the distro though. <civodul>rigelk: do you already have the official agreement? <civodul>we should discuss the technical details on guix-sysadmin@gnu.org <rigelk>civodul, if you mean a signed agreement, no. I can’t get it until they exactly know what will be on the network. <rigelk>The network administrator and I talked together though, and he saw no issue as to give our machines ip and ssh access :) <rigelk>I’ll drop a mail on guix-sysadmin@gnu.org then ! <rekado_>one step in offloading a package build is register-gc-root. A script is run on the remote build host to link a derivation in the store to a newly created GC root directory. <rekado_>this fails for me because the derivation does not exist in the store on the remote machine. <rekado_>does the remote build host need to share the store as the offloading machine on which the build is requested? <rekado_>the inline documentation seems to disagree as it says that missing dependencies are transferred over SSH. <civodul>rekado_: yes they are transferred; what may be missing though is the /var/guix/gcroots/tmp directory, no? <civodul>i remember the fine prints, now that you talk about it ;-) <civodul>we need to update the doc/code based on your feedback <rekado_>the directory should be created on the remote: (false-if-exception (mkdir root-directory)) <civodul>anyway the .drv is definitely transferred <civodul>could you paste the errors you're getting? *civodul goes afk for a while <rekado_>well, in transfer-and-offload it first runs register-gc-root (which creates the dir and expects the derivation to exist already), and *after that* runs send-files, which transfers missing dependencies. <rekado_>(ignore the "IN THE LOOP" part; that's just printf debugging ...) <rekado_>I think the mkdir might be failing silently. Trying to confirm.\\ <rekado_>civodul: confirmed that the remote fails to create the directory <rekado_>it attempts to create /usr/var/guix/gcroots/tmp even though I configured it with "--prefix=". <rekado_>anyway: this mkdir is run as the unprivileged user I configured in /etc/guix/machines.scm. <rekado_>this user can't possibly create anything in /usr nor in /var directly. <rekado_>should this script not be run by the remote daemon, rather than by the ssh user? <rekado_>I think the result of (false-if-exception (mkdir root-directory)) needs to be checked and an error reported in case mkdir fails. This should fail early. <Sleep_Walker>I think I should create some table to make it very obvious <rigelk>Sleep_Walker, could you add it to the documentation? <Sleep_Walker>rigelk: 1] when I'll find how 2] when I'll find how it is intended to work <rekado_>civodul: sent a mail to the ML about my experiences with offloading + a couple of recommendations to discuss. <rekado_>BTW: I've got 13 failing tests of 34 when running "make check". <civodul>rekado_: ouch, could you also report them, with test-suite.log and $top_builddir/*.log? <civodul>rekado_: i believe $localstatedir/gcroots/tmp does not exist, hence the symlink error <civodul>and (false-if-exception (mkdir ...)) fails to create it, but the error is swallowed <civodul>someone is asking for a torrent for the image <civodul>anyone would like to help with this? <jgrant>civodul: I could provide a seed for some time, probably. <civodul>i don't know exactly what needs to be done <civodul>we could probably host a seed or something at gnu.org <jgrant>Yeah, we would probably want to set gnu.org as the originator uploader/seeder. <jgrant>If this is done, I'll keep a seed box constantly going on my end for the next few months at least. <jgrant>davexunit: Yeah, evidently someone was asking for it/one. <civodul>i think we just need to host the meta-data at gnu.org, no? *civodul apologies for being a complete noob <jgrant>I think you may have to seed the inital bit, right? <davexunit>yeah, someone's gotta host the thing initially. <davexunit>I think we just need to use our torrent clients <jgrant>I mean, could I seed the initial bit and then just hand it over to gnu.org to host the torrent file? *davexunit is also a n00b when it comes to uploading a new torrent <jgrant>Transmission is capable of creating torrents iirc. <civodul>jgrant: if that's doable this way, that's perfect <civodul>just send us instructions on guix-devel, and we'll copy whatever file needs to be copied to gnu.org :-) <davexunit>yeah, one of us just creates the torrent and has the finished download in our torrents directory. <jgrant>Should I do two different torrents, for x86 and x64? <jgrant>Should I put their signatures in a directory with images/ <civodul>well, maybe people can get the signatures over FTP <civodul>is it possible to have a torrent for two files, or for a directory containing two files? <jgrant>A directory yeah, don't know of outside of a directory. <jgrant>Should we maybe ship a readme, that directs to the install documentation? <jgrant>Okay, x64 downloaded on my always-on server -- now for i686. <davexunit>upload torrent file when done and I'll start seeding. <jgrant>Due to the way my day is shaping up, I wouldn't expect it till evening or sometime tomorrow. <Gabou>davexunit: where should we upload the torrent? I can do it if you want. <jgrant>Gabou: The ML as an attachment, assumingly. <jgrant>If you feel the urge, feel free, today is shaping up to be a busy/tired-filled day for me. :^) <jgrant>I don't know, might get time before I need to head up to class. <davexunit>Gabou: anywhere for now. it would be good to host the final torrent file on gnu.org, but that can wait of course. <jgrant>Okay everything downloaded, going to grab some breakfast and see if I can figure this out before class. <jgrant>So it seems I may have to specify a tracker? <rekado_>could someone please help me with guix configure flags? I want the guile stuff to be installed such that I don't have to set any environment variables. <jgrant>davexunit: If you want to check if it works or not. <jgrant>I'm suspect without a tracker specified. <rekado_>If I just pass "--prefix=" the guile stuff goes to /share/...; do I have to pass all these configure path flags or is there a simpler way? <rekado_>I want the state stuff to go to /var and the rest to system defaults. <davexunit>jgrant: ah yes, I suppose we need to use a tracker. what tracker do other distros use? <civodul>rekado_: check the value of %load-path in your Guile installation <jgrant>davexunit: I think a lot run their own. <civodul>rekado_: however, guilemoduledir is hard-coded in the configure.ac of Guix <civodul>rekado_: we should add a --with-guilemoduledir configure option <civodul>rekado_: but really, just set GUILE_LOAD{,_COMPILED}_PATH in the right shell init file and be done with it ;-) <rekado_>well, I did that and ... now this offloading stuff breaks earlier because guile on the remote doesn't find (guix config) <rekado_>I added this to /etc/profile: export GUILE_LOAD_PATH=/usr/local/share/guile/site/2.0/:$GUILE_LOAD_PATH <civodul>i tend to forget which init files are read when <rekado_>I get this error: ERROR: no code for module (guix config) <rekado_>this means that for some reason the config.scm isn't found in the load path. <rekado_>(feeling really stupid today. Maybe related to recompiling stuff again and again.) <jgrant>Okay, I'm going to leave it going for an hour and see if it makes any Upload progress. <rekado_>apparently, my email to bug-guix went out multiple times, so it created more than one bug report. Sorry for the noise. <davexunit>if anyone already has a phoronix account, there's some misinformation in the 1 comment posted so far. <rekado_>there's misinformation / errors even earlier than the first comment... <davexunit>for instance: we are *not* opting for wicd and not NetworkManager, wicd was just easier to package. <rekado_>second commenter fails to see the relationship between nix and guix. Oh well. <davexunit>and we are not using "uknown replacements" for udev, we are using "eudev" from the Gentoo project. <jgrant>Okay, trying mktorrent instead of transmission. <civodul>rekado_: just make sure your /etc/profile settings for GUILE_LOAD_PATH are honored at all when logging in over ssh <civodul>davexunit: you're too negative, re phoronix ;-) <civodul>maybe not actually, now that i've read the comment <rekado_>civodul: my /etc/profile changes have effect when I log on interactively. I can run guile -c "(use-modules (guix config))" without errors and the load path is ok. <civodul>rekado_: what about: ssh foo guile -c '(use-modules (guix config))' ? <civodul>davexunit: "There's also a web UI coming to Guix in the future." <- now the world knows, you can't escape :-D <civodul>although i wonder why he wrote "in the future" since i actually demoed it <rekado_>ssh build-host "guile -c '(use-modules (guix config))'" --> ERROR: no code for module (guix config) <davexunit>I guess since it isn't in core yet? I dunno. <jgrant>civodul: Probably because it wasn't sold as Stable, I assume. <civodul>rekado_: so you need to carefully read that "Startup Files" section of the Bash manual <civodul>rekado_: alternately, you could copy/paste that export line in all the startup files that you find ;-) <civodul>depends on your level of frustration :-) <rekado_>is everything on phoronix framed in terms of systemd? <jgrant>Yeah, not sure why this won't connect to the tracker. <rekado_>I don't get it. Bash's info page tells me that in non-interactive mode, for non-login sessions, $BASH_ENV is sourced if it exists. But how can I reliably set BASH_ENV to, say, ~/.bash_profile when no other startup file is read? <rekado_>is there another way to tell Guile that /usr/local/share/guile/site/2.0/ is part of the load path? Without having to set environment vars? <rekado_>(e.g. some configuration file or so) <civodul>you could use ~/.bash_login, which is for non-login shells <davexunit>taylanub: thanks for your comment on the phoronix article. <rekado_>civodul: ha, that did it. I'm confused because I feel like I tried this first, but apparently I did not. *rekado_ probably should admit defeat and stop trying to use his brain today. <taylanub>I just noticed there's a Wikipedia page "Gnu Guix" which should be moved to "GNU Guix"; anyone have a Wikipedia account with the rights to move pages? <taylanub>hm, "GNU Guix" exists as a redirect page .. maybe I can do something <taylanub>managed to get it fixed. now there's just a redundant page "Gnu Guix" which is a redirect to "GNU Guix"; someone might want to prune it. <civodul>last time i looked it was a redirect to Nix <taylanub>indeed, it's new. I added a "Main article: GNU Guix" link on the Nix page <rekado_>hmm, after generating keys and authorizing them I now get this error on the remote when offloading: "guix authenticate: error: error: invalid signature: ..." <jgrant>The command I tried to generate a torrent to seed was """mktorrent -l 21 -a udp://open.demonii:1337/announce ~/Seeds/gsd-usb-install-0.8.1.x86_64-linux/ -o "gsd-usb-install-0.8.1.x86_64-linux.torrent" """ <jgrant>Generates without an issue, but I can't seem to seed it. <civodul>rekado_: as a first test, try say "guix archive --export coreutils | ssh build-machine guix archive --import" <rekado_>I just remembered that the guile bindings for gnutls are not included in recent RPMs with the exception of the very latest Fedora 21 RPMs. <rekado_>on the build host I use CentOS 7 and gnutls bindings are not available. <civodul>it depends on libgcrypt, but not on GnuTLS <rekado_>from workstation to remote build host I get the same error. <civodul>so that means that the workstations public key hasn't been authorized on the build host <civodul>from the workstation, you can run something like "ssh build-host guix archive --authorize < /etc/guix/signing-key.pub" <rekado_>I think I found the reason: I've got more than one guix installed, but in different paths ... <rekado_>clear indication that I should not be touching this for the rest of the day :) <rekado_>reconfigured this so many times on so many different machines that I must have lost the overview. <civodul>i did a fresh install of the system on a workstation at work <civodul>that's a good way to find out about glitches and bugs <davexunit>civodul: you have guix on a work machine? :D <bavier`>civodul: I asked earlier about access to unpatched origins, as those derivations need to be built for `guix build --sources=transitive` <jgrant>Yeah, I'll look into this a bit more tomorrow. Gabou if you want to have a go, feel free, one less thing for me to do this weekend. :^) <rekado_>davexunit: so do I. It's running on a server and a workstation at work atm. <davexunit>I'm hoping that one of the x200 laptops we're getting at the FSF can be a guix machine. <Gabou>jgrant: I wish I could help but I don't know where to take the files :P <rekado_>davexunit: erm, correction: I'm not running the system distribution. Just the package manager. (I can't seem to stop...) <civodul>davexunit: yup, i hope it'll work out well :-) <fchmmr>davexunit, then you will have a distribution that is officially part of the GNU project on your X200 <fchmmr>Then all that needs to happen is for me to apply libreboot to be part of the GNU, so that you officially have a GNU laptop. <civodul>bavier`: it would be enough to use package-source-derivation as is <fchmmr>civodul, how usable is guix for the average user? <civodul>bavier`: in practice you would get the patched sources, but that's fine <fchmmr>I'm interested in trying it. I might actually start offering it as a pre-install option for gluglug. <civodul>fchmmr: i think the package manager is just as easy as any other package manager, minus the GUI <fchmmr>Right now I only pre-install Trisquel <civodul>fchmmr: the system itself is probably... ahem... more demanding <fchmmr>I used to offer gnewsense/parabola but now I leave that up to the customer (gnewsense is too old, and a parabola pre-install doesn't make sense due to the nature of the distro) <fchmmr>so right now I just do trisquel. <bavier`>civodul: the only issue with package-source-derivation is if a tarball needs to be repatched <civodul>what about adding a #:patched? parameter to that procedure? <bavier`>civodul: had thought of that option. Default to #t, obviously. <civodul>or simply factor out the raw download derivation <civodul>and have package-source-derivation call it <civodul>anyway, this part can be done in a separate patch, before or after the prefetch thing <fchmmr><fchmmr> davexunit, then you will have a distribution that is officially part of the GNU project on your X200 <fchmmr><fchmmr> Then all that needs to happen is for me to apply libreboot to be part of the GNU, so that you officially have a GNU laptop. <rekado_>I wonder: does $prefix/libexec need to be in the PATH for this to work? The daemon fails with "error: executing `guix-authenticate': No such file or directory" <fchmmr>davexunit, and libreboot's GRUB payload screen which is what you see when you boot up already shows a floating, meditating GNU playing a flute, as a background image. And it says "FREE AS IN FREEDOM" in big letters. <rekado_>I configured guix such: ./configure --prefix= --exec-prefix=/usr --datarootdir=/usr/share --localstatedir=/var <rekado_>(I guess I just missed "make clean"; just trying to confirm for the sake of my sanity) *DusXMT wishes there was a way to make "git" patches with diff... I guess I could write a script to simulate it, as the git way is jut way too clunky for me... I'm most probably doing it wrong. <DusXMT>mark_weaver: sorry, but I have no idea how to do those things you suggested... and even if I did, I don't have write access to the wip-hurd branch (or any remote guix branch, for that matter), I'm just a tourist really <mark_weaver>in a git checkout that's on the wip-hurd branch, type "git rebase master" <mark_weaver>it will apply one patch at a time on the current master. <mark_weaver>when it runs into trouble, it'll tell you which files it had problems with. <mark_weaver>basically, you'll have to edit the files where the merge conflicts occurred. there will be "merge markers" in there. ("<<<<<<" "=======" and ">>>>>>") <mark_weaver>in each place where it couldn't do the merge, it'll show you the relevant bit from master and the relevant bit from wip-hurd. make the edits to incorporate changes in both branches and remove the markers. <mark_weaver>then "git add <files>" for the files you edited, and "git rebase --continue". <DusXMT>Okay, I'll try my best, thanks a lot <mark_weaver>also, if you get into trouble, you can always type "git rebase --abort" <mark_weaver>DusXMT: btw, I really do appreciate your work on this. I very much want to try out the Hurd, but I'd rather try it on Guix than Debian :) <DusXMT>mark_weaver: It's an interesting system indeed <mark_weaver>really, I'd like to completely switch to the Hurd, when it's ready for my needs. <mark_weaver>Sleep_Walker: 'inputs' are run-time only, not build-time. 'native-inputs' are build-time only, not run-time. <mark_weaver>'propagated-inputs' are just like 'inputs' except for the propagation thing. <mark_weaver>Sleep_Walker: so the table you wrote is not quite right. <phant0mas>DusXMT: I have a local branch here that I have merged the two branches <phant0mas>but a problem I had solved in the wip-hurd branch with inheriting from the linux glibc resurfaced <phant0mas>will send a patch with the merge branches so you can have a look <mark_weaver>I would prefer a rebase. it would make reviewing much easier. *DusXMT just finished his attempt at rebasing <DusXMT>No probs if you do it instead, it was a good learning experience :) <mark_weaver>it would be interesting to compare the results of your rebases. <phant0mas>DusXMT: try building it and tell me if you find any problems <espectalll123>Ran dhclient, DHCP works but no packets are sent or received <mark_weaver>I confess I'm mostly ignorant of setting up networked qemu instances, but I guess that you need to do something to connect qemu's network to the host network. <mark_weaver>though hopefully someone else here has more experience with this. <mark_weaver>what said that IPv6 was ready? what was the exact message? <davexunit>I've only used guix on QEMU by running 'guix system vm', which returns a shell script that sets everything up correctly. <mark_weaver>(it might just mean that the network stack has IPv6 support) <mark_weaver>espectalll123: yes, that's the supported way to do it. <DusXMT>Interesting, now there's 2 instances of (cross-gcc-arguments... now I get it why I shouldn't have copy-pasted... What to do with it? <mark_weaver>of course, it should be possible to do it the way you're doing it also. <espectalll123>But then I need to setup something... IPv4 thought, but IPv6 should work with FSF servers, right¿ <espectalll123>The network card gets setup as ens3 instead of eth0 for some reason <mark_weaver>that's because we use eudev, gentoo's fork of udev, and it uses persistent names by default. <mark_weaver>(we can't use upstream udev because it has been merged with systemd, and we don't use systemd) <mark_weaver>the advantage of these names is that they are more stable, but it takes some getting used to. <mark_weaver>it's possible that hydra.gnu.org has no IPv6 address. <DusXMT>okay, my rebase was a failure... Is there a way to be able to inspect the files after each patch before moving to the next, and doing any potential changes? <espectalll123>My network doesn't even have IPv6 support, my ISP (or my router?) only offers IPv4 <davexunit>DusXMT: git rebase stops when there are conflicts. <davexunit>if you need further control, look into interative rebases. <phant0mas>mark_weaver: sent the rebased patches to the list <davexunit>if you use Emacs, magit is a must-have for making rebases a lot easier. <a_e>Hello! Could someone with an x86_64 machine lend me a hand with elfutils? <a_e>It fails a test on hydra, but compiles without problem on my machine. <mark_weaver>phant0mas: did you test the rebased branch to make sure it builds as well as it did before? <a_e>Which makes it difficult to debug. <a_e>Maybe there is someone in this channel where it fails, and who could try to fix it... <mark_weaver>a_e: btw, I went ahead and pushed the gnutls trust store change to master, since there was another gnutls pushed to master a few hours ago anyway. <a_e>mark_weaver: But the one before just moved an input to a propagated input. I think that does not trigger a rebuild, but just a different behaviour when installing into a profile. <mark_weaver>a_e: it doesn't trigger a rebuild of the package itself, but I think it will trigger a rebuild of the packages that use it as inputs. <phant0mas>mark_weaver: that's what I meant with "a problem I had solved resurfaced" and will send the relevant log shortly <mark_weaver>because it will add zlib as another input to those other packages, and I suspect that it ends up reordering things, at least. <mark_weaver>a_e: though I confess I'm not 100% sure, so maybe I erred. <a_e>In any case, what is done, is done! <a_e>The gnutls rebuild was not _that_ bad. <mark_weaver>anyway, since I may have buried his request: a_e is looking for a volunteer with an x86_64 box to try building elfutils locally, and if it fails, to help debug it. any volunteers? <mark_weaver>(it consistently works on his machine, and consistently fails on hydra, apparently) *mark_weaver goes afk for a while. <espectalll123>Is it the best way to create a Guix VM with the package manager, then? <davexunit>I wish I knew more about the networking issue. you could send an email to guix-devel@gnu.org about how to set it up properly. <davexunit>otherwise, if you install guix on your ubuntu machine, you can do something like 'guix system vm-image my-config.scm' <mark_weaver>vm-image will create just the image, and then you still have to figure out how to run qemu properly. <mark_weaver>vm builds vm-image, but then makes a script you can just run. <davexunit>but the issue with 'vm' is that it creates a read-only file system <davexunit>/gnu/store is shared with the host and you can't install new packages from the VM. <davexunit>but 'vm' will at least give you the proper command line to setup qemu correctly <davexunit>espectalll123: I have a feeling that our maintainer who goes by the nick 'civodul' can help you with this, when he's here. <espectalll123>Let's see if I can deal with this meanwhile (and learn how to type less messages on IRC) <jxself>Well sure but you want guix 'cause it's better right? :) <jxself>Nah, guix stays out of the way. The two will happily co-exist. <bavier`>espectalll123: guix on top of another OS it's a pretty well-tested setup <davexunit>all the completed builds live in /gnu/store, so they don't clash with your debian stuff in /usr and such. <espectalll123>Well, now that I have Guix on Ubuntu, maybe I don't need GSD <davexunit>I encourage you to try out the distro some more. we really want to work through the problems people are having. <davexunit>now you should be able to do that from the comfort of your Ubuntu host system, at least for VMs. <espectalll123>Really glad you ask me that, becuase it makes me trust this project more <davexunit>right now the distro is only for the brave, but we want it to be for everyone! <davexunit>another thing we could use help with is packaging. <espectalll123>Because, honestly, it just looks to me right now as weird, unnecesary Lisp thingie <davexunit>yes, it's very essential. Guix wouldn't be what it is without such a great foundation. <DusXMT>espectalll123: You'd be surprised how scheme/guile can make things easier. For example, you can test almost everything out in an interactive shell <DusXMT>Also, it's extensible without having to modify any compiled code <espectalll123>it's like JavaScript or Python, but native and with a better architecture? <davexunit>JavaScript and Python both lack the metaprogramming features (specifically, hygienic macros) that make Scheme a good choice for our project. <davexunit>but yes, like those other languages, Scheme is also dynamic. <Sleep_Walker>mark_weaver: the table - it was question, thanks for clarification <civodul>"propagated" inputs are propagated to users of the package <civodul>so, MPC has MPFR as propagated, and MPFR has GMP as propagated <civodul>when you add MPC as an input to a package, it automatically gets MPFR and GMP as well <civodul>likewise, when you install MPC in a profile, you automatically install the other two <Sleep_Walker>so it affects build of other packages which would like to build against <mark_weaver>civodul: would 122ddc595 have forced a rebuild of packages that use gnutls? (it moved zlib from inputs to propagated-inputs of gnutls) <mark_weaver>(I realize that it wouldn't have forced a rebuild on gnutls, but my guess is that it would affect the other packages, if for no other reason than the order of the inputs being changed) <mark_weaver>civodul: it seems that lots of people are trying to install GuixSD in a VM (e.g. qemu), and having trouble in various ways. maybe worth documenting. ***espectalll123_ is now known as espectalll123
*DusXMT had trouble with the framebuffer, one of the reasons he wanted a custom kernel, to disable it <DusXMT>It was way, _way_ too slow. And it prevented the cirrus xorg driver from working <Sleep_Walker>it does not but you can alter your package definition easily <Sleep_Walker>but you'll get unique hash for all the packages in dependency subtree <mark_weaver>Digit: the most flexible way to make local modifications is by having a private git branch and periodically rebasing your changes onto our upstream (or merging upstream into your branch if you prefer) <yang_>btw. 201408 encoding is plying very slow on my XBMC, while 201402 encoding of the GuiX video plays much better, maybe you'd want to re-encode the stream -0 <yang_>or make a HD and SD version of it... <Digit>that's a little disapointing, but not unexpected. i had high hopes for convenient means. doesnt put me off guix though, and still definately on a path towards using it. <DusXMT>Digit: one of the project's goals is reproducibility, something like Gentoo's USE flags would complely defeat it. <Sleep_Walker>Digit: you can also define your own version of packages by maintaining changes and inheriting the rest <Digit>DusXMT: "completely"? or just over-complexify? might need longer hashes to help cover all possibilities. hehe. ;D <mark_weaver>Digit: the main thing is that USE flags would vastly increase the number of pre-compiled binaries we'd have to produce, or else anyone who played with those would lose pre-compiled binaries. <mark_weaver>also, I should say that 'git pull --rebase && make' is quite easy, and much more flexible that USE flags. <mark_weaver>Guix, as a package manager, is capable of flexibility far more than USE flags. packages are first-class objects in Scheme, and you can make procedures that take packages as arguments, modify them, and return new package objects. <civodul>mark_weaver: i think the GnuTLS/zlib change by iyzsong triggered a rebuild, yes <mark_weaver>it's just that we've not chosen to support USE flags in the package definitions that we're working on. <civodul>re VMs, probably, but i'm not sure what the problems are <mark_weaver>civodul: two people have reported kernel panics while trying to boot the installed system for the first time in the VM (although the installer worked). and another can't get networking to work, although maybe that's because they invoked qemu incorrectly. <mark_weaver>I guess these are probably user error, but it seems that users want to do this and are having trouble. <mark_weaver>and I can understand why they'd want a way to try guix conveniently, without having to build 'guix' from the tarball, and without installing GuixSD on bare metal. *civodul still isn't done going through today's messages <mark_weaver>civodul: I'm frankly amazed how much you manage to work on Guix, with a paid job and family. <civodul>i'm working 4 days a week, so that helps a bit <civodul>mark_weaver: i think nginx should cache .nar as well, up to 1 or 2 GiB <mark_weaver>civodul: okay, I'll try to get to that in the next day or so.