IRC channel logs


back to list of logs

<nalaginrut>hi folks! where is the 'quick start' about GuixSD for USB?
*davexunit looks at the manual
<nalaginrut>davexunit: nice, I saw "USB Stick Installation" now
<nalaginrut>thanks! ;-)
<grantixx>Oh, did Gabou upload the torrent any where?
<davexunit>nalaginrut: good luck. let us know if you have issues. it's very possible that our setup doesn't "just work" with your hardware.
<nalaginrut>davexunit: fortunately I have a not-so-old physical machine for testing it, it's planed to test Hurd with it, but finally I realized Hurd runs smoothly in VM
<nalaginrut>failed to resolve partition label "gnu-disk-image"
<nalaginrut>/dev/sdg1 not found
<nalaginrut>but I can use (scandir "/") to list files in / yay!
<davexunit>big problem packaging ruby gems: a lot of them assume you are working from a git repo and won't build otherwise.
<davexunit>not sure how to reconcile this with guix's good method of stripping out the .git directory before hashing
<davexunit>bed time for now.
<sir123>Hey guys, does anyone know how you could run the guix package through tor? Is there a way to get it to use SOCKS5?
<sir123>Guix doesn't have a way around proxies, I think, unless you could hack a way in? Any ideas?
<zacts>sir123: hum.. I wonder if you could port forward with nftables / iptables or openssh somehow, as a temporary solution
<sir123>I'm thinking it should be a feature request. Not anything urgent. I used to have success with a program called proxychains that would forward all TCP/IP data through HTTP, SOCKS4 or SOCKS5 proxies, therefore would work with tor. I'm wondering if it would be worth asking for commit?
<sir123>I've got the program here, just looking at the code. GPLv2.
<sir123>Is openssh fully working?
<mark_weaver>the openssh is fully working afaik. I use it all the time.
<mark_weaver>sir123: you want guix to use tor when it downloads source code and binaries from hydra?
<sir123>That would be nice, yes.
<mark_weaver>it can be done with privoxy
<sir123>Just as an option. How hard is it to add SOCKS5 support?
<sir123>ok, i'll look it up.
<mark_weaver>privoxy implements an http proxy, and can be configured to use an upstream SOCKS5 proxy
<mark_weaver>and guix honors the http_proxy environment variable
<mark_weaver>(when used with guile 2.0.11)
<zacts>oh guix needs nftables I think
<mark_weaver>however, it's not perfect.
<sir123>Ok. Nice. I'd better check what I'm doing before posting :)
<mark_weaver>https and ftp requests from guix are not forwarded to a proxy, I think.
<zacts>mark_weaver: once I finish some homework I'm doing, I'll setup my guix server, and then I'll be able to contribute much more
<zacts>nftables is one such feature
<mark_weaver>the tor website has some recipes for configuring iptables to transparently route traffic through tor.
<mark_weaver>(without any explicit proxy configuration in user space)
<sir123>Makes sense.
<mark_weaver>however, I should stress that using tor competently is not trivial
<zacts>mark_weaver: do you know if gnunet will provide any tor-like benefits?
<mark_weaver>for example, if you route *all* traffic through tor, and then some of that traffic involves you logging into a service with your username, you've blown your cover.
<sir123>I read the warnings
<sir123>Uh... Okay. I just installed privoxy and it says command not found. Never had this before.
<mark_weaver>it might be in ~/.guix-profile/sbin
<mark_weaver>which might not be in your PATH
<mark_weaver>although if you're using GuixSD, it should be.
<mark_weaver>we don't yet have an easy to use privoxy-service in guix
<sir123>Still a lot of work to do.
<mark_weaver>zacts: gnunet is much more ambitious than tor, but tor is ready and usable today, whereas gnunet will hopefully be more relevant in the future.
<zacts>ah cool
<zacts>hey has davexunit made any progress with guix deterministic package builds?
<mark_weaver>sir123: for now, this is your best bet:
<zacts>I really like the idea of being able to use binaries built by anyone on the net, and know they match the official guix binaries
<mark_weaver>zacts: why do you single out davexunit in particular?
<zacts>that's a really cool potential idea, and would allow for a much more economic distribution of package builds
<mark_weaver>he has not been working on that, afaik.
<zacts>oh, I didn't mean to per se, I just thought he was the leader of that specific project
<mark_weaver>well, he's been working on "guix publish"
<zacts>oh, perhaps this is just a misunderstanding of mine
<mark_weaver>which will be important for decentralizing hydra, but he's not actually working on making guix builds more deterministic.
<zacts>ah ok, I see
<zacts>mark_weaver: would this deterministic builds idea be a plausable potential in the not so far off future for guix?
<zacts>I mean I would love to learn about this domain for a potential research project if it is approachable, and a realistic goal
<mark_weaver>yes, guix is designed from the ground up to provide deterministic builds.
<zacts>oh sweet!
<mark_weaver>it's just a matter of plugging the remaining leaks
<sir123>how could I download the recipe for installing a package? Privoxy can't find a config file
<sir123>Seems like all the install did was install the package, not set up the files necessary
<mark_weaver>sir123: you need to create a config file and probably pass a command-line argument to privoxy to tell privoxy where the config file is.
<zacts>hey is there a way I can donate specifically to the guix project?
<mark_weaver>sir123: right, that set up that you are looking for is the role of a 'privoxy-service', which has not yet been created.
<zacts>I don't see anything on the homepage
<sir123>Okay. Would it be possible to grab the recipe? See if I can hack in some automation?
<mark_weaver>sir123: the package recipes are in the source code of guix. you can find out the location of the recipe in the source code by typing "guix package -A privoxy"
<mark_weaver>however, the services are distinct from the package recipes.
<mark_weaver>the package recipes only build the read-only build outputs placed in /gnu/store/...
<sir123>I really need to study the source code of Guix. Seems like I'd be much better off knowing the system.
<mark_weaver>the services are what handle creating the configuration files for daemons and setting things up.
<mark_weaver>the packages are in gnu/packages/*.scm
<mark_weaver>the services are in gnu/services/*.scm
<sir123>So we don't have a privoxy-service?
<mark_weaver>not yet
<mark_weaver>for example, our tor package is defined in gnu/packages/tor.scm, and our tor-service is defined in gnu/services/networking.scm
<mark_weaver>we need an analogous privoxy-service
<sir123>Could I try and build one? It might take some time, but I really want to contribute to this project.
<mark_weaver>although most people start by writing packages
<sir123>I don't know what I can do in packages. I don't really use anything not in here yet.
<mark_weaver>anyway, the first step would be to clone our git repo and build guix from the git checkout.
<mark_weaver>which means installing all of the software needed to build guix from the git checkout
<mark_weaver>although actually the better way now is to use 'guix environment'
<mark_weaver>which will automatically create an environment with all the software needed to build guix
<mark_weaver>see section 5.7 of the manual
<sir123>I'm looking at it now.
<mark_weaver>which you can get to by typing C-h i in emacs and then: m guix RET
<mark_weaver>but before you build the code, you need to get it. I would "guix package -i git magit"
<mark_weaver>magit is an emacs package for working with git (optional)
<sir123>Ok, I already have git.
<mark_weaver>and then: git clone git://
<mark_weaver>create your build environment with the necessary software to build guix with "guix environment guix"
<sir123>it's grabbing stuff now
<mark_weaver>that will spawn a shell with the necessary environment variable settings to access all the software needed to build guix.
<mark_weaver>from there, the instructions are in the HACKING file. when viewing that file in emacs, type TAB to toggle expansion of the sections of that file.
<mark_weaver>(type TAB while the cursor is on the section headings)
<mark_weaver>one important note: it's very important to pass --localstatedir=/var to configure
<mark_weaver>do *not* run "make install" after building it.
<sir123>I figured.
<mark_weaver>after it's built, you can run guix directly from that git checkout by prefixing the commands with ./pre-inst-env from that directory.
<mark_weaver>e.g.: ./pre-inst-env guix package -A ...
<mark_weaver>so, you could add a package or service by editing the files in that git checkout, then running "make" to rebuild, and then using that guix to either build your new package or to run "./pre-inst-env guix system build <OS-CONFIG>" to build a new system with your new service included.
<mark_weaver>and if that builds successfully, then, as root, run "./pre-inst-env guix system reconfigure <OS-CONFIG>" to make that new system the "current system".
<mark_weaver>then you can try rebooting into the new system, with that new service.
<mark_weaver>if there's a problem with the new service, the new system might not boot.
<mark_weaver>in which case you can choose an older version of your system from the GRUB menu and try again.
<mark_weaver>anyway, I have to sleep now. happy hacking!
<sir123>Goodnight. I hope to get something to show :)
<zacts>ah, I also need to port znc to guix
<sir123>zacts: happy hacking
<zacts>I think it will be simple to do this
<zacts>znc doesn't have many requirements to build
<mark_weaver>sir123: also, you'll probably need to pass --with-libgcrypt-prefix=<DIR>, where <DIR> is the first line output by the command "guix build libgcrypt"
<sir123>I'm really eager to contribute, personally
<mark_weaver>well, the first line assuming that the package has already been built.
<sir123>mark_weaver: thanks for your help. I really appreciate it.
<zacts>my main practical use case for guix is for my irc ssh server, with znc on it
<mark_weaver>the line you're looking for is something like /gnu/store/xxxxxxxxx-libgcrypt-
<mark_weaver>sorry, let me try again. the line you're looking for is something like /gnu/store/p3cllrw9nhpvyh3qxf84hnr5mgdj0hp3-libgcrypt-1.6.2
<mark_weaver>so ./configure --localstatedir=/var --with-libgcrypt-prefix=/gnu/store/p3cllrw9nhpvyh3qxf84hnr5mgdj0hp3-libgcrypt-1.6.2
<mark_weaver>okay, going to sleep now....
*mark_weaver ---> zzz
<zacts>gn mark_weaver
<zacts>thanks for all of your information
<rekado_>I'm trying to build R right now, but I'm stuck at downloading texlive-2014-data
<rekado_>downloading `/gnu/store/331b3772kzqpgp9mbw73cb9ixfy2fjn7-texlive-2014-data' (3392.6 MiB installed)...
<rekado_>I don't see any progress here. Is hydra asleep?
<rekado_>I use --no-substitutes now to circumvent the problem.
<mark_weaver>rekado_: I've noticed that sometimes the download progress output fails to update for a while, even though it's still going.
<mark_weaver>it's possible that might be a fix for that problem, dunno.
<mark_weaver>however, that's a fix to the guix-daemon, and on GuixSD we usually use the 'guix-daemon' from the 'guix' package within 'guix' itself, which is only updated sporadically.
<paroneayea>now that I have Guix working well enough, maybe I should experiment with writing a package definition for guilemacs
<paroneayea>"how hard could it be", I wonder?
<davexunit>paroneayea: you've built it manually before, right?
<davexunit>how much weird manual intervention did you have to do?
<paroneayea>davexunit: I never got it to build
<davexunit>sounds like it will be a bit tricky, then.
<paroneayea>but I think it's because I refused to make install bt's custom guile
<paroneayea>so, maybe guix will make that esier
<davexunit>if that guile is still needed, you can make a package for that
<paroneayea>yes it needs a special guile
<davexunit>and then use it as an input to the guile-emacs package
<paroneayea>unless that's now been merged into 2.2
<paroneayea>guile 2.2 I mean
<mark_weaver>you need the special guile.
<davexunit>that's what I don't know. you could ask #guile about that.
<mark_weaver>and I wouldn't try to make a guix package for it until you've built it successfully yourself first.
<paroneayea>when I tried compiling guilemacs it got caught in some weird loop
<paroneayea>so I should probably try building it in a VM first :)
<paroneayea>since I still refuse to install on my machine :)
<mark_weaver>no need for a VM
<paroneayea>let's see if I can do that
<paroneayea>mark_weaver: oh?
<mark_weaver>just install with --prefix=<some-dir-in-your-home-directory>
<paroneayea>I think I tried that also
<paroneayea>and didn't get it to work
<mark_weaver>and when building emacs, you'll need to set PKG_CONFIG_PATH to include <prefix>/lib/pkg-config
<mark_weaver>so that it finds the right guile. and probably PATH set as well.
<paroneayea>mark_weaver: yeah I tried doing those things but I think I did them wrong :)
<mark_weaver>well, I dunno, I suppose guix would take care of some of those complications for you, but on the other hand, every iteration of trying would involve a rebuild from scratch, so it's a tradeoff.
<davexunit>and if you write a package for that tweaked guile, it will of course be isolated in /gnu/store.
<mark_weaver>so pick your poison :)
<paroneayea>I think I'm going to just confirm that I can build it from the instructions on in this VM I already have up
<paroneayea>where i don't care about a sudo make install
<paroneayea>and if it works
<paroneayea>then I'll build the guix package.
<mark_weaver>heh, okay
<davexunit>you can also test out the build in a guix environment ;)
<mark_weaver>using a VM seems like using a sledgehammer to put in a nail, but I guess it simplifies things a bit, and I'm just old fashioned :)
<mark_weaver>davexunit makes a good point. you could use guix environment to set up the environment for building guile-emacs
<mark_weaver>after you've used guix to build the guile package for the custom guile.
<mark_weaver>so many choices
<davexunit>'guix environment --pure' would be ideal for the most isolated environment, but you have to be careful of .bashrc type files overriding env vars
<rekado_>I use "guix environment --pure r" to investigate a test failure; apparantly there's an older version of icedtea6 and guix environment starts grafting icedtea6, which takes much longer than I thought it would.
<rekado_>grafting '/gnu/store/d2hakl83ic4d117b3z3d82mr9g3xdrk9-icedtea6-1.13.6' -> '/gnu/store/a8l9a3dmwg03dchb9b7a3rs05crmrscz-icedtea6-1.13.6'...
<rekado_>It's been going for at least an hour.
<rekado_>I thought guix environment would just download the latest stuff if it wasn't yet available.
<rekado_>when exactly are grafts used? Only when the version number is unchanged?
<rekado_>(could it be that the old icedtea6 version is a remnant of previous use of guix environment?)
<davexunit>I haven't grokked when grafts happened
<davexunit>it happened when I built the new version of ruby last night.
*rekado_ leaves now. Will give a short talk about Guix tonight at an FSFE fellowship meeting.
<mark_weaver>the grafts happen when we want to quickly swap in a fixed version of a core package without having to rebuild everything.
<mark_weaver>in this case, it was actually to swap in a fixed version of the 'patch' program, which had a security hole.
<mark_weaver>but the grafting process itself is quite inefficient right now. it needs to be optimized.
<mark_weaver>and grafting is always done in the users machine, not on hydra
<mark_weaver>to prevent having to download everything again
<mark_weaver>the usual anticipated case for grafting is when patching a core library. in such cases, we don't rebuild everything against that new library, but rather rewrite the rpaths in everything to refer to the patched library, which accomplishes something similar to what happens when you simply upgrade a shared library on a traditional distro.
<mark_weaver>but it's still deterministic
<mark_weaver>btw, I have found that on my machine (with a spinning disk), texlive takes longer than an hour to graft, which causes guix-daemon to time out after 1 hour of silence. the workaround for now is to pass --max-silent-time=10000 to any guix command that builds stuff.
<mark_weaver>the better solution will be to (1) optimize grafting to be faster, and maybe (2) show time kind of progress indicator while grafting, so that the 1-hour-of-silence timeout doesn't apply.
<mark_weaver>(IMO, anyway)
<jgay>mark_weaver, or someone else, how does guix manage fonts?
<jgay>in particular I am interested in font aliasing (without renaming the actual filenames of the fonts)
<mark_weaver>jgay: I have to run, but I guess you need a ~/.fonts.conf file. See
<mark_weaver>I don't know much about fontconfig though.
<mark_weaver>one thing: after installing font packages in guix, you need to run "fc-cache -f"
<mark_weaver>the -f is needed because the timestamps in our build outputs (including fonts and user profiles) are all set the epoch.
<mark_weaver>at some point hopefully we can make that nicer
*mark_weaver goes afk
<mark_weaver>back for a bit now...
<mark_weaver>jgay: in brief, we use fontconfig, and we configure it to look for fonts in ~/.guix-profile/share/fonts instead of the default /usr/share/fonts
<mark_weaver>~/.guix-profile points to a user profile, which is itself an immutable tree of symlinks, a merging of all the packages the user has installed.
<mark_weaver>the end result is that the fonts from all the font packages that the user has installed in their personal profile end up into ~/.guix-profile/share/fonts, and fontconfig handles finding them.
<zacts>ah I also want to add terminus fonts
<mark_weaver>zacts: we have them already
<mark_weaver>our fonts are in gnu/packages/fonts.scm
<zacts>oh neato
<mark_weaver>that one is called 'font-terminus'
<mark_weaver>gotta run. happy hacking!
*mark_weaver goes afk
<jgay>mark_weaver, thanks
<paroneayea>well, it didn't get stuck in a loop, but no luck compiling guilemacs agagin
***JamesJRH is now known as JRHaigh
***JRHaigh is now known as JRHaigh_
<rigelk>need a hand paroneayea ?
***JRHaigh_ is now known as JamesJRH
<taylanub>how is 'guix lint' so intelligent? O_o it proposed me a totally different description text.
<sirgazil>rigelk: Sorry for the delay. I just answered your question :)
<civodul>taylanub: it's AI in action!
<zacts>cool I want to port this
<paroneayea>rigelk: yeah, though bipt might help in #guile :)
<ijp>taylanub: becausee guix lint sends an email to civodul, who then emails back
<rekado>sorry about the occasional repeated email from my (most recently to bug-guix). There seems to be a problem at work; msmtp shows me a TLS timeout but the email was actually sent out :-/
<rigelk>sirgazil, no problem, i just saw your IRC message as well ^^'
<civodul>ijp: :-)
<civodul>rigelk: your message was being held for being too big, and i didn't moderate it until this afternoon
<zacts>hum.. can I make an ISO of 0.8.1?
<zacts>or is it best to just use USB?
<zacts>I'm planning to install guix within the hour
<zacts>(on real hw)
<rigelk>civodul, i didn’t realise it, sorry
<rigelk>won’t happen again. what made it so big ?
<civodul>oooh sorry
<civodul>rekado: the reply above to rigelk was meant to you
<civodul>zacts: there's no ISO currently, only USB image
*rigelk was looking for the incriminated mail :p
<zacts>ah ok
<rekado>civodul: I resent it twice or so, but only because msmtp indicated a TLS timeout. I had no idea it actually went out. That it got stuck for being too big made it worse because I was convinced it actually wasn't sent.
<rekado>had this problem only on my workstation in the office, not when going through my personal mail server.
<civodul>ok, no big deal anyway
<grantixx>zacts: I'm not sure how one could make an iso from the usb image?
<grantixx>If you have a spare thumbdrive and your bios support it, I'd go with the usb-install for now.
<grantixx>Eventually we may and hopefully will have *.iso generation. zdavis was working on it briefly, do't know if he hit a deadend or life just got busy for a bit.