<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 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>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>if you installed from the binary tarball, then you have recipes from when that tarball was released. <crocket>What if I just want to update package recipes? <crocket>Does 'guix pull' also update the guix binary? <mark_weaver>guix-daemon is the only non-scheme executable, and that's not updated by guix pull <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. <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. <crocket>How long does it take to build guix? <mark_weaver>as a developer, I always run it out of the git repo. <crocket>guix pull is downloading the entire gcc codebase. <crocket>I don't understand why it is downloading gcc codebase. <crocket>Does it mean ubuntu may not be able to catch up with guix? <mark_weaver>any package from ubuntu would only be used to get started easily. <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>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". <crocket>mark_weaver, I submitted a message in the mailing list. <crocket>I suggested a new guix repository for guile modules only. <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>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. <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. <crocket>ijp stopped maintaining guildhall after guix got attention. <mark_weaver>I'm sorry, I don't have time to continue this discussion right now. maybe later. <crocket>Is it a generic package manager for linux distros? <crocket>sneek, It seems guildhall repositories were abandoned as well. <crocket>Why does every guix command print "warning: failed to install locale: Invalid argument" at the beginning? <crocket>It seems guix pull cannot succeed without substitutes from hydra. <mark_weaver>some of the coreutils tests are sensitive to details of the kernel version and/or configuration, as I recall. <crocket>After enabling hydra, I work around the issue. <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 <crocket>How do I permanently disable hydra on command line? <crocket>I thought guix has a command for that. <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 <mark_weaver>and set the environment variables suggested by guix package --search-paths <crocket>How do I check which package an executable belongs to? <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>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. <mark_weaver>or maybe some environment variable that changes how ls works. <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. <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. <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>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 <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>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 <mark_weaver>the logs are in the filenames ending with "-coreutils-8.23.drv.bz2" <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") <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 <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>unfortunately, some of these test suites are quite sensitive to kernel details. <mark_weaver>crocket: can you send a bug report to bug-guix@gnu.org with just the relevant excerpt from that log? <zacts>crocket: yeah submit a patch to guix upstream <mark_weaver>crocket: it would also be good to include your kernel version and config <crocket>mark_weaver, I already sent an email. Send it again? <mark_weaver>crocket: send the followup comment to 20877@debbugs.gnu.org <mark_weaver>crocket: btw, how much free space is on your /tmp partition? <crocket>105G available in my system partition <zacts>oh cool, does GuixSD allow for btrfs? <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 :) <zacts>wait I thought sneek was a real nick, darn <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. <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? <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 :) <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 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>I think I'm somewhat close to understanding, but something still hasn't clicked. <davexunit>there's a very helpful series of articles on lwn.net that explain in detail about the various namespaces <davexunit>I'm violating one of the rules for writing to the /proc/$PID/uid_map file <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>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>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 <davexunit>anyway, I think the build daemon could benefit from the user namespace anyhow. <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 <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>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. <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 <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 package.name and package.synopsis, not the description. <rekado_>unfortunately "bioinfo" yields 0 matches. <civodul>in 'guix package --search' it yields a bunch of results <civodul>packages.js should be changed as you propose IMO <davexunit>you'd need to serialize the relevant info as json <rekado_>yes, I saw it all goes to a massive (~1MB) packages.json file. <davexunit>yeah, all the packages are serialized to json <rekado_>(I'm all new to writing nice JavaScript. guix-web looks interesting. Must learn.) <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>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 <civodul>mark_weaver: so that leads to a fat binary that doesn't use the ifunc mechanism to choose the implementation, right? *civodul goes afk for a while ***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>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. <Mikko->livestreamer uses vlc so I'm screwed :p <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 <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_>Mikko-, I miss media automounting via udev <Mikko->yeah, it looks like I forgot to set my livestreamer config <amz3>fwiw youtube-dl works fine too <zacts>mark_weaver: would you mind pasting my crocket's systemd init service for guix? <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? <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. <davexunit>I run 'sudo halt' as my regular user and it works <davexunit>'which halt' returns '/home/dave/.guix-profile/sbin/halt' <alezost>davexunit: that's because you installed dmd into your profile; for me "which halt" → /run/current-system/profile/sbin/halt <anthk_>Mikko- the audio under VLC can be solved if you change the output device