IRC channel logs


back to list of logs

<ewemoa>amz3: have installed guixsd on an older machine -- thinking of trying hostapd there :)
<ewemoa>seems like that might work better for testing...not sure how to evaluate whether wireless works well in a vm situation
<crocket>I installed guix on ubuntu 15.04
<crocket>I executed "guix package -i guile-emacs" as a normal user, and guix says package not found.
<crocket>But guix repository has guile-emacs.
<crocket>How do I update local guix repository cache ?
<mark_weaver>crocket: run "guix pull"
<mark_weaver>as your normal user
<crocket>What does guix pull do?
<mark_weaver>it downloads the latest version of guix, compiles it, and arranges for future 'guix' commands to use that version.
<crocket>Why does it pull a new guix binary in addition to the latest cache?
<mark_weaver>I'm not sure what cache you are talking about
<mark_weaver>guix includes a collection of package recipes
<mark_weaver>if you installed from the binary tarball, then you have recipes from when that tarball was released.
<mark_weaver>i.e. 6 weeks ago
<mark_weaver>guile-emacs was added since that release
<crocket>What if I just want to update package recipes?
<crocket>Does 'guix pull' also update the guix binary?
<mark_weaver>what guix binary?
<mark_weaver>guix is a collection of guile scheme code.
<mark_weaver>guix-daemon is the only non-scheme executable, and that's not updated by guix pull
<mark_weaver>but the rest of guix must be updated together
<mark_weaver>it's like asking to update the drivers in linux (the kernel) without updating the rest of the code in linux.
<crocket>Is it ok to add guix as an ubuntu package?
<crocket>When ubuntu updates guix, its package recipes could be wiped out.
<crocket>It takes very long to execute guix pull.
<mark_weaver>yes, that's true.
<crocket>Does 'guix pull' download source code in advance?
<crocket>Does 'guix pull' download source code of every package in advance?
<mark_weaver>the better method is to build guix from the git repository, and then do "git pull && make" and run out of the git checkout
<mark_weaver>that's what I always do, and it is also the setup you need if you want to contribute to guix or to customize it in arbitrary ways.
<mark_weaver>no, but it downloads all of the package recipes.
<mark_weaver>and compiles them.
<crocket>How long does it take to build guix?
<mark_weaver>I don't remember, I *never* use guix pull
<mark_weaver>as a developer, I always run it out of the git repo.
<crocket>guix pull is downloading the entire gcc codebase.
<mark_weaver>git checkout, I mean.
<crocket>I don't understand why it is downloading gcc codebase.
<mark_weaver>we recently did an update of the core toolchain
<mark_weaver>we switched from gcc-4.8 and gcc-4.9
<crocket>It is downloading gcc-4.8.4
<mark_weaver>and it uses our toolchain to compile guix itself
<crocket>Does it mean ubuntu may not be able to catch up with guix?
<mark_weaver>catch up?
<mark_weaver>any package from ubuntu would only be used to get started easily.
<crocket>ubuntu packages ship everything
<mark_weaver>after that users would use 'guix pull' and henceforth use the updated packages from us.
<crocket>That is going to invalidate ubuntu package.
<mark_weaver>no, what happens is the new version of guix goes somewhere in /gnu/store, and the ~/.config/guix/latest is a symlink pointing to the updated guix in the store.
<crocket>When ubuntu updates guix, what happens?
<mark_weaver>and then the 'guix' command that you originally installed (possibly from ubuntu) just uses (almost) all the code pointed to from ~/.config/guix/latest
<mark_weaver>so it doesn't matter.
<crocket>guix ignores ubuntu.
<mark_weaver>guix-daemon doesn't get updated by 'guix pull', but the daemon doesn't change very often and the changes are rarely crucial.
<crocket>Does guix pull install its new toolchains in /gnu/store?
<mark_weaver>actually, I can't think of any changes that are "crucial".
<mark_weaver>*everything* that guix builds goes into /gnu/store
<crocket>What is guix repository for?
<crocket>Is it for GuixSD?
<crocket>mark_weaver, I submitted a message in the mailing list.
<mark_weaver>guix repository?
<crocket>I suggested a new guix repository for guile modules only.
<mark_weaver>I don't know what you're referring to.
<crocket>Guix packages are stored in the main repository.
<crocket>There can be third party repositories.
<crocket>I think guix has a potential for serving as the de facto guile module repository.
<crocket>guile doesn't have an official repository, and that's why guile hasn't accumulated thousands of modules.
<mark_weaver>sneek: guildhall?
<sneek>Last time I checked guildhall is
<mark_weaver>that's the tool for that job ^^
<crocket>guildhall is not being maintained
<mark_weaver>well, it's still the right tool for that job.
<mark_weaver>guix builds everything using its own toolchain, and it's not portable to non-Linux (the kernel)
<mark_weaver>it's not well suited to the purpose you have in mind.
<mark_weaver>we are porting it to Hurd, but probably won't port to anything else.
<crocket>In a guix presentation, language specific repositories were critisized.
<mark_weaver>well, yes. I do think that guix is a better approach. but for those who don't want to switch to guix, there is guildhall.
<crocket>Where does guildhall refer?
<crocket>Too bad
<mark_weaver>if you are looking for a way to distribute guile modules that will work on arbitrary systems, Guix won't do that.
<crocket>If you wanted to install a GTK binding from guildhall on windows, it wouldn't install GTK.
<mark_weaver>that's true
<crocket>ijp stopped maintaining guildhall after guix got attention.
<crocket>What is guix for?
<mark_weaver>I'm sorry, I don't have time to continue this discussion right now. maybe later.
<crocket>Is it a package manager for GuixSD?
<crocket>Is it a generic package manager for linux distros?
<crocket>ok later
<crocket>sneek, It seems guildhall repositories were abandoned as well.
<crocket>'guix pull' failed.
<crocket>Why does every guix command print "warning: failed to install locale: Invalid argument" at the beginning?
<crocket>coreutils build fails.
<crocket>It seems guix pull cannot succeed without substitutes from hydra.
<mark_weaver>crocket: which test failed?
<mark_weaver>some of the coreutils tests are sensitive to details of the kernel version and/or configuration, as I recall.
<crocket>I'm not sure, but I think
<crocket>After enabling hydra, I work around the issue.
<crocket>How do I disable hydra again?
<mark_weaver>anyway, if you don't disable hydra, you'll have a *lot* of stuff to compile.
<mark_weaver>you can temporarily disable it by passing --no-substitutes to either guix-daemon or the guix command itself
<mark_weaver>or you can permanently remove its key from the set of trusted keys by editing /etc/guix/acl
<mark_weaver>(or just remove that file entirely)
<crocket>How do I permanently disable hydra on command line?
<mark_weaver>sudo rm /etc/guix/acl
<crocket>Is that the only way?
<crocket>I thought guix has a command for that.
<crocket>Wuh, guix just installed bash.
<mark_weaver>we have a command to conveniently add a key to the acl, but nothing yet to remove one.
<crocket>Does it mean guix overrode /bin/bash?
<crocket>How do I access guix packages after installation if guix doesn't bother with /bin or /usr/bin?
<crocket>I am installing guile-emacs via guix.
<mark_weaver>the only directories guix writes to are: /gnu/store, $(localstatedir)/guix and $(localstatedir)/log/guix, where $(localstatedir) is normally just /var
<mark_weaver>and it sets the symlink ~/.guix-profile to point to the current profile.
<crocket>Does it mean guix makes a package available to the user who executed guix?
<mark_weaver>so when you "install" software, the only way to can actually use that software is to set environment variables to point to things in ~/.guix-profile or /gnu/store
<mark_weaver>e.g. you need to set PATH to include ~/.guix-profile/bin
<crocket>How convenient.
<mark_weaver>and set the environment variables suggested by guix package --search-paths
<mark_weaver>so it's non-intrusive.
<crocket>How do I check which package an executable belongs to?
<mdln>guix package -l?
<mark_weaver>ls -l $(which <cmd>)
<mark_weaver>assuming it's already installed and in your PATH
<mark_weaver>$(which <cmd>) will be something in ~/.guix-profile if it's in your profile and PATH is set properly. and that will itself be a symlink to something in /gnu/store
<crocket>It is not a symlink in my system.
<crocket>Everything in ~/.guix-profile/bin is not a symlink.
<mark_weaver>well, it may be that you have 'ls' aliased to something that follows symlinks, or something.
<crocket>alias ls='ls --color=auto'
<mark_weaver>or maybe some environment variable that changes how ls works.
<crocket>my ls shows symlinks well...
<crocket>my ls shows symlinks well outside ~/.guix-profile/bin
<crocket>So, I think ~/.guix-profile/bin doesn't contain symlinks.
<mark_weaver>well, I don't know how that could have happened. this is the way guix works.
<mark_weaver>well, actually if you have only one package installed that contains anything in bin/, then bin itself will just be a symlink to that package's bin directory.
<mark_weaver>it's an edge case.
<crocket>Weirdly, after logging out and logging in again, they are all symlinks.
<mark_weaver>basically, the profile generator makes the symlinks at the highest level possible, as an optimization.
<crocket>I'm launching guile-emacs
<mdln>crocket: neat. I haven't check their ToDo in a while
<mark_weaver>apparently you need to pass -q or -Q to guile-emacs, or else it won't work.
<mark_weaver>at least that was the case the last time I tried, and for others here.
<crocket>guile emacs is a lot slower than emacs on my system.
<crocket>I mean it takes a lot more time to load.
<crocket>And, the font size is smaller somehow.
<mark_weaver>yes, it is very much a work in progress. I don't think it uses the guile compiler at all, and there are some important things not yet optimized, such as dynamically scoped variables.
<crocket>Does it support guile scripting in addition to emacs lisp?
<mark_weaver>it can run guile code, but it is not convenient to access emacs data structures and editing commands, etc, from scheme code, at least not yet.
<mark_weaver>anyway, this is a subject for #guile, where bipt hangs out.
<mark_weaver>bipt is the person working on guile-emacs
<mark_weaver>that site blocks tor, so I can't easily access it.
<mark_weaver>so does that one
<crocket>Turn off tor
<mark_weaver>why should I?
<crocket>To see the image
<mark_weaver>what is in the image that I should care to see?
<crocket>guile emacs error
<mark_weaver>how about just pasting the relevant text to ?
<mark_weaver>or if it's just a line or two, right here?
<mark_weaver>anyway, guile-emacs bug reports should go to bipt, not to me.
<mark_weaver>crocket: I would just put that text directly into #guile, directed at bipt, no paste required for something so small.
<lf94>guixsd the next gen linux distro
<iyzsong>lf94: it's GNU/Linux, and hopefully Hurd will come :-)
<lf94>iyzsong: ugh rms is calling it GNU+Linux come on man get with the times
<lf94>And Hurd is already here
<lf94>It's just slow
<crocket>mark_weaver, Somehow, it's hard to know why coreutils build fails on my ubuntu 15.04 system.
<mark_weaver>crocket: well, it would help to look at the build log. see "ls -ltr /var/log/guix/drvs/*/*-coreutils*"
<mark_weaver>anyway, I need to sleep now
<mark_weaver>if it has to do with ttys, it's probably because your kernel lacks the CONFIG_DEVPTS_MULTIPLE_INSTANCES=y config option
<mark_weaver>which might only be needed when running the coreutils test suite within a container
<crocket>no log
<mark_weaver>(which is how guix builds all its software)
<mark_weaver>the logs are in the filenames ending with "-coreutils-8.23.drv.bz2"
<mark_weaver>you want the most recent one presumably
<crocket>mark_weaver, CONFIG_DEVPTS_MULTIPLE_INSTANCES=y in my kernel
<mark_weaver>(I'm not sure why you looked at that and said "no log")
<mark_weaver>look at the log and tell us which test failed.
<crocket>FAIL: tests/dd/sparse
<zacts>I need to add a systemd / sysvinit script for guix so I can have guix-daemon auto-started for debian jessie on each boot
<mark_weaver>okay, that doesn't ring a bell
<zacts>so perhaps I'll look into this, busy busy though
<mark_weaver>to investigate further, the thing to do is "guix build -K coreutils" and when it fails the build directory will be left in /tmp/nix-build-coreutils-*
<mark_weaver>somewhere in there will be a more detailed test log
<crocket> contains the log
<mark_weaver>unfortunately, some of these test suites are quite sensitive to kernel details.
<crocket>Search tests/dd/sparse in the log
<crocket>zacts, ^^
<mark_weaver>crocket: can you send a bug report to with just the relevant excerpt from that log?
<zacts>crocket: what?
<zacts>what is that?
<crocket>mark_weaver, ok
<zacts>oh I see cool
<zacts>crocket: yeah submit a patch to guix upstream
<mark_weaver>crocket: it would also be good to include your kernel version and config
<mark_weaver>oops, too late..
<crocket>mark_weaver, I already sent an email. Send it again?
<mark_weaver>no, hold a sec...
<mark_weaver>crocket: send the followup comment to
<mark_weaver>it will be added to the same ticket
<mark_weaver>(the one at <>)
<mark_weaver>crocket: btw, how much free space is on your /tmp partition?
<mark_weaver>is it a tmpfs?
<crocket>105G available in my system partition
<crocket>It is btrfs
<zacts>oh cool, does GuixSD allow for btrfs?
<mark_weaver>anyway, I need to sleep now.. good night.
<crocket>I sent an email to the address.
<crocket>How long does it take to get there?
<crocket>It arrived there.
<crocket>Sleep tight
<rekado>sneek: later tell civodul I got to a point were guix-web seems to work, but the firewall settings keep me from looking at it with the browser. Was too late yesterday to fiddle with firewall settings :)
<sneek>Will do.
<rekado>sneek: you are the best bot!
<rekado>sneek: botsnack
<zacts>wait I thought sneek was a real nick, darn
<zacts>oh well...
<zacts>can sneek do timed messages?
<rekado>zacts: you can ask sneek with /msg sneek help
<rekado>zacts: seems it doesn't do timed messages.
<rekado>sneek: later tell crocket I very much recommend reading the Guix documentation. It is quite clear on what Guix is used for and how it works.
<sneek>Got it.
<zacts>sneek: tell crocket his/her gist on the systemd service for guix is gone, and zacts forgot to save the config
<sneek>crocket, zacts says: his/her gist on the systemd service for guix is gone, and zacts forgot to save the config
<zacts>sneek: later tell crocket his/her gist on the systemd service for guix is gone, and zacts forgot to save the config
<efraim>can you break the matrix by telling sneek to tell sneek something?
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, rekado says: I got to a point were guix-web seems to work, but the firewall settings keep me from looking at it with the browser. Was too late yesterday to fiddle with firewall settings :)
<civodul>heh, good
<civodul>sneek: seen remi`bd
<sneek>I last saw remi`bd on Jun 20 at 03:44 pm UTC, saying: (sources: & — see the annotations for output).
<rekado_>about bioperl-minimal: the PERL5LIB path with which I have to wrap the executables needs to mention the lib paths of all these inputs:
<rekado_>note that bioperl-minimal only has four direct inputs.
<rekado_>I consider it very ugly to manually find all the indirect inputs and compile a PERL5LIB value from them.
<rekado_>should we have a function to get all inputs except the native-inputs for use with wrap-program?
<rekado_>we need something like that relatively often.
<rekado_>whenever there's a package written in python or perl the executables must be wrapped in PYTHONPATH and PERL5LIB, respectively.
<rekado_>(getenv "PYTHONPATH") or (getenv "PERL5LIB") at build time does not cut it as this contains native inputs (and their inputs).
<amz3>ewemoa: yep, you are right.
<davexunit>good morning geeks.
<iyzsong>welcome back, davexunit!
<civodul>hey, davexunit
*davexunit pokes at user namespaces before he has to start work
<davexunit>grr I just can't quite grok user namespaces.
<davexunit>I do what I think is the right thing and it never works. :(
<civodul>bah, you need to find a working example to start from
<davexunit>civodul: I've been reading a working example
<davexunit>but I'm missing something in the implementation
<davexunit>pflask has simple, easy to read source code and has user namespace support:
<civodul>oh, ok
<davexunit>I think I'm somewhat close to understanding, but something still hasn't clicked.
<davexunit>there's a very helpful series of articles on that explain in detail about the various namespaces
<davexunit>for user namespaces
<davexunit>I'm violating one of the rules for writing to the /proc/$PID/uid_map file
<davexunit>but not sure why
<davexunit>oh I just got it!
<davexunit>probably a whole bunch of problems for booting a guixsd container, but I was able to use 'guix environment' just fine.
<davexunit>need to figure out more about what limitations there are.
<davexunit>but it's really cool to be able to create a container as an unprivileged user.
<mark_weaver>yeah, that's great news!
<mark_weaver>so, does this mean that it would be possible in theory to run guix-daemon as an unprivileged user but still run our builds in a proper build container?
<davexunit>mark_weaver: the question I have there is: what about /gnu/store?
<mark_weaver>well, I suppose we could have a dedicated user that "owns" /gnu/store
<mark_weaver>and run guix-daemon as that user
<davexunit>I think that could work.
<mark_weaver>but we'd want the builds themselves to run as a different user
<davexunit>with the use of user namespaces, the daemon no longer has to be root in order to create build containers.
<davexunit>mark_weaver: yeah we'd still use the user/group pool
<mark_weaver>such that the build process couldn't modify anything in /gnu/store.
<mark_weaver>but could a non-root user create a build container and start a process within running as a different user? (a build user)?
<davexunit>the non-root user would have to have the privilege of switching to that uid/gid
<mark_weaver>yeah. I don't know if there's a way to do that.
<mark_weaver>so this idea may not quite work out.
<davexunit>sudo, but I know you don't like sudo. :)
<davexunit>anyway, I think the build daemon could benefit from the user namespace anyhow.
<davexunit>extra isolation for build processes
<mark_weaver>well, one could perhaps have a minimal setuid helper that's easy to audit.
<davexunit>the daemon can drop privileges *before* creating the container
<davexunit>I'm not sure why Nix doesn't use user namespaces currently
<davexunit>civodul: do you know?
<davexunit>I could be missing some glaring problem.
<civodul>davexunit: the main reason is probably historical
<civodul>i don't know if there are other reasons
<civodul>but as you write you still need to be root to map to another UIDs
<civodul>so it seems we can't avoid the manually created build users and the daemon that runs as root
<civodul>mark_weaver: there used to be a nix-setuid-helper, but that's not very helpful
<civodul>because if you convince the sysadmin to install it, you can just as well get them to install the daemon, in practice
<mark_weaver>it's true that setuid programs are worrisome for different reasons
<mark_weaver>I guess we'll be able to do all this with the Hurd
<mark_weaver>but not with Linux
<mark_weaver>speaking of which, has work begun on modifying guix-daemon to create a build container on the Hurd?
<mark_weaver>since we already have bootstrap binaries for the Hurd, it seems about time to work on that, but I haven't even seen mention of a plan to do it yet.
<mark_weaver>(but I confess I haven't looked very carefully)
<civodul>mark_weaver: the first step in my mind is to use it as-is, which means chroot + separate UIDs, but global file system name space
<mark_weaver>I suspect that many of our build recipes won't work properly when the 'configure' scripts are able to find things in /bin, /usr/bin, etc.
<civodul>the 2nd step would be "bind mounts" and separate file system name space
<civodul>well yeah
<mark_weaver>okay, makes sense
<mark_weaver>zacts: I saved a copy of the systemd service description for guix-daemon that crocket posted.
<rekado_>davexunit: in guix-web I'd like to search packages also by module name. Then typing "bioinformatics" will list all bioinfo packages.
<rekado_>currently, the search is limited to name and synopsis.
<rekado_>davexunit: would you be okay with a patch that addressed this?
<civodul>rekado_: it's name + synopsis + description, no?
<civodul>i'd expect that typing "bioinfo" would effectively give you what happens to be in that module
<rekado_>js/controller/packages.js only applies the regexp to and package.synopsis, not the description.
<rekado_>unfortunately "bioinfo" yields 0 matches.
<civodul>ah ok
<civodul>in 'guix package --search' it yields a bunch of results
<civodul>packages.js should be changed as you propose IMO
<davexunit>rekado_: yeah sure
<davexunit>you'd need to serialize the relevant info as json
<davexunit>to hand to the client
<rekado_>yes, I saw it all goes to a massive (~1MB) packages.json file.
<davexunit>yeah, all the packages are serialized to json
<davexunit>and pagination happens on the client
<rekado_>(I'm all new to writing nice JavaScript. guix-web looks interesting. Must learn.)
<mark_weaver>civodul: any comments on before I start hydra building it?
<mark_weaver>I tried just passing nettle_cv_link_ifunc=no to configure, but that caused interesting problems in the configure script.
<mark_weaver>(the 'ac_fn_c_try_link' shell function ends up being declared in the 'else' of an 'if' statement checking whether 'nettle_cv_link_ifunc' is cached.
<mark_weaver>so if 'nettle_cv_link_ifunc' is cached, ac_fn_c_try_link doesn't get declared at all, even though it is used later.
<mark_weaver>could be an autoconf bug
<mark_weaver>well, I'll start building it and we can fix it later if needed
<anthk_>will guix-web be imported in to the main guix distribution? it would be nice
<rekado_>anthk_: eventually, yes.
<anthk_>rekado_, nice :)
<civodul>mark_weaver: so that leads to a fat binary that doesn't use the ifunc mechanism to choose the implementation, right?
<civodul>if so, that's fine
*civodul goes afk for a while
<mark_weaver>civodul: yes, exactly
***init is now known as exio4
<davexunit>rekado: thanks for the patches. will review when I get a chance.
<davexunit>rekado: heh, I expected larger patches. I'm very happy with how little code needed changing.
***exio4 is now known as hacker
<rekado_>davexunit: my big boss would like to link to search results in our public installation of guix-web.
<rekado_>before I go ahead and implement this here with a route pattern that you might not like, I thought I'd first ask you if (a) this is a stupid idea and (b) if you have any preference for the URL pattern.
<rekado_>e.g. /search/query or /packages?search=query
<davexunit>rekado_: it would be a client-side route
<davexunit>I think...
<davexunit>well, maybe the query string would be best
<davexunit>see "routes with querystrings"
<davexunit>I think that's what you want
<davexunit>oh and btw, I think we'll want to upgrade the copies of mithril, underscore, etc.
<davexunit>I'm very happy to have some help with guix-web :)
<Mikko->I'm not getting any audio on vlc, what am I missing here?
<mark_weaver>Mikko-: I think our vlc package is not currently functional.
<mark_weaver>for now, I've been using mplayer instead
<mark_weaver>we should probably file a bug report on it
*mark_weaver goes afk
<mark_weaver>we'll have totem soon
<Mikko->livestreamer uses vlc so I'm screwed :p
<Mikko->yay audio
<davexunit>Mikko-: sorry about the livestreamer issue (I packaged that :x)
<Mikko->huh, looks like I don't need vlc for livestreamer after all, it has tons of options for different players
<anthk_>livestreamer -p
<davexunit>Mikko-: do any of them work?
<Mikko->can't get the commands to work, but I can download stream just fine
<Mikko->the only thing I'm really missing now is compton to get rid of the screen tearing
<anthk_> livestreamer -p mpv $URL best
<anthk_>Mikko-, I miss media automounting via udev
<davexunit>I miss that, too.
<Mikko->yeah, it looks like I forgot to set my livestreamer config
<amz3>totem works afaik
<amz3>fwiw youtube-dl works fine too
<zacts>mark_weaver: would you mind pasting my crocket's systemd init service for guix?
<zacts>I just woke up
<anthk_>amz3, livestreamer is best suited for some rtmp streams
<rekado>civodul: thanks for reviewing Guitarix. I wonder if maybe it should be in music.scm rather than audio.scm.
<rekado>audio for frameworks, codecs, libraries, etc; music for, erm, music applications?
<Mikko->"shutdown: command not found" wut?
<davexunit>Mikko-: 'halt' is what you're after.
<davexunit>that's the *real* shut down program.
<taylanub>IIRC "shutdown" is part of sys V init, probably found in systemd systems as a compatibility shim as well. maybe we could provide one too.
<Mikko->"halt: command not found"
<davexunit>Mikko-: you must be root
<Mikko->I am root
<davexunit>you're doing something wrong.
<davexunit>I run 'sudo halt' as my regular user and it works
<davexunit>'which halt' returns '/home/dave/.guix-profile/sbin/halt'
<davexunit>perhaps /sbin isn't on $PATH
<alezost>davexunit: that's because you installed dmd into your profile; for me "which halt" → /run/current-system/profile/sbin/halt
<davexunit>either way
<davexunit>halt is there
<davexunit>Mikko- did something wrong
<davexunit>no idea what, though
<anthk_>Mikko- the audio under VLC can be solved if you change the output device