IRC channel logs


back to list of logs

<jxself>Welcome back Mr. Unit.
<davexunit>hey jxself
<jgrant>davexunit: I saw Sly 0.1 is fastely approaching, any plans to get it in Guix once it lands? :^)
<paroneayea>hi davexunit !
<davexunit>jgrant: yes. once I release it I will package it for guix.
<paroneayea>woo sly in guix! :)
<davexunit>all the dependencies are there.
<davexunit>and working via guix environment.
<jgrant>paroneayea: Very exciting to check up on it's progress every once in awhile.
<jgrant>davexunit: *
<davexunit>I need to test on GuixSD, but I'm having some OpenGL issues.
<davexunit>hey paroneayea
<paroneayea>hey davexunit
<davexunit>I have a few more blocking issues to work out.
<paroneayea>I had more convo with the guix people at fosdem :)
<davexunit>cool :)
<jgrant>davexunit: Should porting over to SDL 2.x going to be a big "todo"?
<davexunit>jgrant: yes, for another time.
<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?
<mark_weaver>iirc, we don't have startx.
<mark_weaver>normally we use slim
<mark_weaver>or you can just use xinit directly
<jgrant>mark_weaver: We have xinit now, but I thought xstart shipped with xinit?
<mark_weaver>hmm, I don't remember clearly
<mark_weaver>anyone here using cups successfully on guixsd?
<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 :-/
<mark_weaver>well, I'll ask him when he's back here and awake
<davexunit>mark_weaver: an interesting compiler called FreeBASIC
<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.
<mark_weaver>heh, yeah :)
<mark_weaver>I can sympathize
<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>the novena?
<davexunit>wow. yeah, computing really took a bad turn.
<davexunit>and the first computer was an apple ][?
<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."
<davexunit>we turned out alright ;)
<mark_weaver>I like to think so :)
<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 went to C++ after BASIC. oops!
<mark_weaver>and some time with C++ as well (shudders)
<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>that's still the case.
<mark_weaver>it's probably mostly Java and C++ today, I'd guess.
<davexunit>I had courses in "object oriented design" learning about all the desgin patterns.
<davexunit>Java seems to be the popular one.
<davexunit>and C is still taught for UNIX systems programming courses.
<davexunit>I enjoyed that. I still like C for what it is.
<mark_weaver>yes, me too
<mark_weaver>as a low-level portable assembly language :)
<davexunit>yes, exactly.
<mark_weaver>well, I have to afk for a while...
<davexunit>see ya mark_weaver
<davexunit>hope you figure out CUPS
<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>may be you've seen this already, but i found the following to be helpful:
<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>Hello Guix!
<rigelk>hello #guix ; i’m still having trouble with the --llvm-root=... option bavier suggested for the rust package : (output:) (source:)
<civodul>rigelk: is it on i686?
<rigelk>x86_64 here
<civodul>#:configure-flags is incorrect, should be like:
<civodul>#:configure-flags (list (string-append "--llvm-root=" (assoc-ref %build-inputs "llvm")))
<civodul>something along these lines
<civodul>rigelk: the <gnu/stubs-32.h> error suggests they are doing #undef __x86_64__, or somehow forcing a 32-bit build
<civodul>perhaps using -march in CFLAGS
<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
<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 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>hmm really?
<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_>civodul: here's the error output:
<rekado_>(ignore the "IN THE LOOP" part; that's just printf debugging ...)
<rekado_>I think the mkdir might be failing silently. Trying to confirm.\\
<Sleep_Walker>iyzsong: thanks for confirmation
<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>is propagated-input also used for build?
<Sleep_Walker>I think I should create some table to make it very obvious
<Sleep_Walker>differences between the input types
<Sleep_Walker>build time, install time
<Sleep_Walker>✓, ✓ - input
<Sleep_Walker>✓, × - native-input
<Sleep_Walker>?, ✓ - propagated-input
<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>it would be nice
<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
<jgrant>Yeah, we would probably want to set 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.
<davexunit>guixsd torrent?
<davexunit>also, good morning.
<civodul>hey, davexunit!
<jgrant>davexunit: Yeah, evidently someone was asking for it/one.
<davexunit>I will seed.
<civodul>i think we just need to host the meta-data at, no?
<civodul>or do we need to run something?
*civodul apologies for being a complete noob
<davexunit>just the torrent file, I believe.
<jgrant>I think you may have to seed the inital bit, right?
<davexunit>yeah, someone's gotta host the thing initially.
<civodul>i'm not sure where we could do that
<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 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
<jgrant>Yeah, transmission-create.
<civodul>just send us instructions on guix-devel, and we'll copy whatever file needs to be copied to :-)
<davexunit>yeah, one of us just creates the torrent and has the finished download in our torrents directory.
<davexunit>then we upload the .torrent file to
<jgrant>Should I do two different torrents, for x86 and x64?
<civodul>i686 and x86_64, yes
<civodul>with the signatures as well
<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.
<davexunit>it would be contained in 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, 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
<davexunit>fedora, ubuntu, etc.?
<jgrant>davexunit: I think a lot run their own.
<rekado_>I use Fedora/CentOS 7
<jgrant>I found not sure how reliable that would be.
<civodul>rekado_: however, guilemoduledir is hard-coded in the 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
<rekado_>this should be okay, no?
<civodul>i think so
<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.
<jgrant>Trying for
<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>guix is on phoronix
<davexunit>let the inevitable flamewar commence.
<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
<davexunit>the article itself is OK
<davexunit>it's just that 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.
<rekado_>but when I use offloading it fails.
<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
<davexunit>civodul: hahaha that's true
<davexunit>gotta get crackin'!
<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
<rekado_>will do.
<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 :-)
<civodul>related news:
<rekado_>is everything on phoronix framed in terms of systemd?
<civodul>no, sometimes it's in terms of LLVM
<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
<civodul>err, ~/.bashrc
<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.
<civodul>thanks taylanub
<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>oh, it must be a new page i guess
<civodul>last time i looked it was a redirect to Nix
<jgrant>Yeah, I'm lost.
<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: ..."
<taylanub>(it has a section about Guix)
<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"
<civodul>then try in the opposite direction
<rekado_>this does depend on gnutls, right?
<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.
<rekado_>I'll copy the files from Fedora.
<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/"
<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 :)
<civodul>uh :-)
<rekado_>reconfigured this so many times on so many different machines that I must have lost the overview.
<rekado_>sorry for the confusion.
<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. :^)
<jgrant>bbl. o/
<rekado_>davexunit: so do I. It's running on a server and a workstation at work atm.
<davexunit>that is amazing.
<davexunit>I'm hoping that one of the x200 laptops we're getting at the FSF can be a guix machine.
<davexunit>we run Trisquel on everything typically.
<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?
<davexunit>fchmmr: :D
<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>that's right
<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
<bavier`>sure, ok
<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.
<fchmmr><davexunit> fchmmr: :D
<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>DusXMT: no need to apologize!
<mark_weaver>I very much appreciate this work.
<DusXMT>thanks :)
<mark_weaver>here's how to do it:
<mark_weaver>in a git checkout that's on the wip-hurd branch, type "git rebase master"
<mark_weaver>there will surely be merge conflicts along the way.
<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>just follow the instructions it gives
<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".
<mark_weaver>repeat until it's done :)
<DusXMT>Okay, I'll try my best, thanks a lot
<mark_weaver>thank you! :)
<mark_weaver>also, if you get into trouble, you can always type "git rebase --abort"
<mark_weaver>(a nice security blanket :)
<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>(propagated-native-inputs makes no sense)
<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.
<phant0mas>sorry I meant rebased
<phant0mas>sending the rebased patches in a sec
<mark_weaver>ah, good, thanks!
*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.
<espectalll123>Hi! :3
<phant0mas>DusXMT: try building it and tell me if you find any problems
<phant0mas>mark_weaver: yes :P
<espectalll123>Okay, so I don't know if anybody could help me
<espectalll123>I don't want to mix conversations
<davexunit>just ask :)
<mark_weaver>espectalll123: no worries, please ask!
<espectalll123>Oh, thx
<espectalll123>Well, trying to install GSD on QEMU
<espectalll123>Ran dhclient, DHCP works but no packets are sent or received
<espectalll123>I do ping, it gets the IP but does nothing
<espectalll123>Reloading Guix does nothing
<mark_weaver>is this a wired or wireless interface?
<espectalll123>Nope, it's QEMU
<mark_weaver>oh, right :)
<espectalll123>Emulating an Intel network card
<espectalll123>Also happens with AMD
<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.
<espectalll123>It said that IPv6 was ready
<mark_weaver>though hopefully someone else here has more experience with this.
<espectalll123>Hoping right now - otherwise no GNU goodness
<mark_weaver>what said that IPv6 was ready? what was the exact message?
<espectalll123>Lemme copy
<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)
<espectalll123>Oh wait - Guix can generate VM scripts?
<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?
<espectalll123>I was trying to install native-like
<mark_weaver>of course, it should be possible to do it the way you're doing it also.
*DusXMT did it like that
<espectalll123>But then I need to setup something... IPv4 thought, but IPv6 should work with FSF servers, right¿
<espectalll123>Because I PINGed to and
<espectalll123>Obviously Guix's packages are also there.
<espectalll123>Rebooting the system
<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)
<espectalll123>Oh of course
<mark_weaver>the advantage of these names is that they are more stable, but it takes some getting used to.
<espectalll123>No systemd
<mark_weaver>it's possible that has no IPv6 address.
<espectalll123>Could be?
<mark_weaver>well, can you reach anything?
<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>(hydra.) has no IPv6
<espectalll123>And also...
<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!
<mark_weaver>DusXMT: "git rebase -i" is the tool for that job.
<a_e>The gnutls rebuild was not _that_ bad.
<DusXMT>mark_weaver: thanks again
<mark_weaver>DusXMT: do a web search on "git interactive rebase"
<mark_weaver>DusXMT: np, thank you!
<mark_weaver>a_e: yeah, it's not that bad, I agree.
<espectalll123>It seems that there's an option -4 to set DHCPv4
<espectalll123>Oh well
<espectalll123>I mean, on dhclient
<espectalll123>It does nothing
<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?
<espectalll123>Should I install it on my Ubuntu?
<davexunit>I wish I knew more about the networking issue. you could send an email to 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.
<davexunit>oh, sorry.
<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.
<mark_weaver>ah, right.
<mark_weaver>well, nevermind me :)
<davexunit>but 'vm' will at least give you the proper command line to setup qemu correctly
<mark_weaver>I've only run guix on bare metal.
*mark_weaver goes afk
<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>Thank you anyway
<espectalll123>Let's see if I can deal with this meanwhile (and learn how to type less messages on IRC)
<espectalll123>For some reason, I've just installed Guix on Ubuntu
<jxself>"For some reason"?
<espectalll123>Checking if creating the VM from there makes any difference
<jxself>You don't know why? :)
<espectalll123>I've got apt-get
<espectalll123>Debian packaging
<jxself>Well sure but you want guix 'cause it's better right? :)
<espectalll123>Mixed with Guix
<espectalll123>Explosions and deaths could happen, 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
<espectalll123>Seems nice then
<jxself>Double really :)
<davexunit>I use it on top of Debian
<davexunit>all the completed builds live in /gnu/store, so they don't clash with your debian stuff in /usr and such.
<espectalll123>Also - packages are managed with per-user profiles, right?
<espectalll123>Well, now that I have Guix on Ubuntu, maybe I don't need GSD
<davexunit>yes, per-user profiles.
<davexunit>I encourage you to try out the distro some more. we really want to work through the problems people are having.
<espectalll123>Oh, alright, beta testing and such before the 1.0
<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!
<espectalll123>I'm kinda brave. Used Plan 9 and a bit of HURD
<espectalll123>So is this the perfect OS for me?
<espectalll123>I guess I'll have to better understand Guile too
<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
<espectalll123>But it seems to be an essential piece of both Guix and GSD
<davexunit>Guile is our not-so-secret sauce ;)
<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.
<espectalll123>Seems cool, them! I'll take a look at it later
<espectalll123>But first - gotta install packages :3
<davexunit>espectalll123: happy hacking!
<espectalll123>Thank you! ^_^
<Sleep_Walker>mark_weaver: the table - it was question, thanks for clarification
<Sleep_Walker>but please, explain me the last bit
<Sleep_Walker>difference between input and propagated-input
<Sleep_Walker>civodul: hi
<Sleep_Walker>quick question
<Sleep_Walker>what is difference between input and propagated-input?
<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
<Gabou> :/
*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
<Digit>:) loving what i'm seeing here ( ) so far, 11 minutes in, told can build everything locally... where my next thought is... "does it have useflags/options like portage/paludis?"
<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
<Sleep_Walker>that could be bearable :)
<Digit>DusXMT: "completely"? or just over-complexify? might need longer hashes to help cover all possibilities. hehe. ;D
<paroneayea>oh hey, congrats on the fsf endorsement
<paroneayea>that's great to see
<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.
<mark_weaver>and we do this in some places.
<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.
<mark_weaver>civodul: thanks
<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>yes, definitely
<civodul>we need to investigate that
*civodul still isn't done going through today's messages
<mark_weaver>heh :)
<mark_weaver>civodul: I'm frankly amazed how much you manage to work on Guix, with a paid job and family.
<civodul>i'm sometimes amazed as well ;-)
<civodul>i'm working 4 days a week, so that helps a bit
<davexunit>civodul is a bit of a superhero.
<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.
<civodul>great, thanks