IRC channel logs
2018-02-14.log
back to list of logs
<OriansJ>Is there a method for masking/blocking the import of specific dependencies that are unwanted? Say perchance Pulseaudio? <Apteryx>Anyone else got that using magit in Emacs: error in process sentinel: Wrong type argument: stringp, nil <Apteryx>It's happenning on most actions such as merge, rebase, pull, etc. Pretty annoying. <Apteryx>But doesn't otherwise impact functionality. <lfam>Oriansj: I'm not sure the best way to achieve that... pulseaudio is basically a per-package choice that we've standardized on. You might look into the package-input-rewriting procedure if you know which package you want to avoid using with pulseaudio <lfam>Oriansj: rekado has experience using with music production and Guix, and that's an area where pulseaudio is not usually unwanted. So he might have more specific advice <lfam>I mean, it's usually not wanted <rekado>I don’t really know much about suppressing pulseaudio, I’m afraid. <rekado>by adding pulseaudio to the inputs we just tell the package that this is something we support. <rekado>most of these packages also take the alsa-libs as an input, so they should also just work with ALSA. <g_bor>I wondered what exactly happens upon guix system reconfigure? <rekado>Happy “I Love Free Software”-Day! <rekado>g_bor: “guix system reconfigure” builds a new system, and then switches the running system over to it. <g_bor>I guess parts of the configuration can be activated only on reboot. Is this correct? <rekado>g_bor: this involves changing a couple of symlinks (including a change in /run/current-system, which now differs from /run/booted-system) <rekado>the guix-daemon service, for example, cannot be stopped before using “guix system reconfigure”, so it keeps running the old service. <g_bor>I was thinking about this in context of the service provisioning setup, so it might be wise to configure the public-facing network interfaces down, so that clients do not see a transient state when reconfiguring. <g_bor>I'm now thinking about extending the concepts of the functional and transactional package management model to services and deploments, but switching services atomically, especially if they are stateful is a pain. <g_bor>It is also a good question, if it is possible at all to get a multi node deployment to change transactionally. I guess we have a good chance to have a machine reboot into a correct state if reconfigure succeed. <rekado>g_bor: is it *necessary* to change a multi node deployment transactionally? <rekado>when services are set up redundantly one could turn some off to update, then turn the others off to update those. <rekado>with a setup like that I wouldn’t want to incur downtimes each time I upgrade. <g_bor>rekado: Yes, I also thought that this should be done this way. Actually I checked some implementations, they all do this. <g_bor>rekado: one more thing I discovered, is that this centralized state database in multi node systems is bascially the manifestation of the CAP theorem, and the willingness to keep the state information available and consistent at the same time. <g_bor>rekado: I wonder if it would worth to check how about to sacrifice consistency instead, and have the deployment state distributed. It would be nice to talk to someone, how is more into these issues... <g_bor>rekado: it would be also nice, to have a policy govern the updates, for example in the redundant service scenario you were describing. <OriansJ>lfam: thanks for the input. rekado: That is interesting, have you ever looked into adding a mask feature to guix to allow a simple way to mask out all dependencies that match. <rekado>OriansJ: the graph rewriting thing would be able to do that. Currently, it can only replace inputs; you could replace pulseaudio with an empty package. <rekado>many packages use the pulseaudio package for the headers, and replacing the pulseaudio package with a dummy would break that. <rekado>I think a better way is to configure the system to not use pulseaudio, i.e. to disable spawning of that dbus user service. <rekado>exactly how that would be achieved: I don’t know yet. <Apteryx>civodul: do you know how we could make our (guix build utils) invoke more verbose when it errors out? Currently it just throws an error saying program X exited with non-zero code Y <Apteryx>I use it emacs to byte compile in a slightly reworked emacs-build-system and it would be much more helpful if it could gather the exact compilation errors instead of just returning an exit code. <civodul>Apteryx: in Unix/GNU all you get is an exit code <Apteryx>emacs by itself prints out nice error details about what went wrong in the compilation (load-file failed: file X not found) for example. <Apteryx>Could it be possible to capture the stderr of Emacs and present it in that error message? <rekado>I noticed that guix-publish and cuirass were both disabled on berlin.guixsd.org. I enabled them a couple of hours ago. <civodul>rekado: oh cuirass was actually running from the build tree in my account, i think <civodul>well maybe it was stopped before, dunno <rekado>berlin was returning 502 on substitutes, so I thought I should do something. <civodul>right, good that you restarted 'guix publish' <civodul>i found it more convenient while testing cuirass master <civodul>though i admit it's not best practice <g_bor>I guess I could use a manifest to create configuration files in my home directory. Is this so? <g_bor>I am looking for ways to move my user configuration between machines, and it would be really nice, if this could be done by only transfering the mainfest. <wigust>g_bor: Hello. Guix doesn't manage user configurations. <g_bor>Yes, I know that. I would like to abuse it to do so... For example transfering settings like default keyboard layout would be nice. <g_bor>I wonder if I can do that... <g_bor>There is a whole bunch of things I do on every system I have a user on, it can be done by a script, but it would be nice if I could somehow integrate this... <g_bor>I guess, as a manifest is a scheme script I can just write there whatever I want, and have it executed, only I have to return a manifest at the end. Is this impression correct? <wigust>g_bor: You could make a package with your configurations and manage it in the manifest. <mbakke>g_bor: I use GNU stow for that, which does all those things. Would be neat with a Guixy version though. <wigust>g_bor: But you will need to reapply manifest after each configuration change. <rekado>mbakke: how do you do that? Are there Guile bindings for GNU stow…? <mbakke>Sorry, all those configuration management things. Not the Schemey stuff. <rekado>right, but you do that manually, not automatically from within Guix, right? <wingo>ffs! 3 hours of chromium build and something fails to link <sneek>wingo, amz3 says: what kind of future is possible for a database system written in guile? <wingo>[21091/23429] LINK ./test_ime_driver.service <wingo>FAILED: test_ime_driver.service <wingo>ld: warning: libvpx.so.5, needed by /gnu/store/akskrn03pvqql6g8ar3d80829gjpp97b-ffmpeg-3.4.2/lib/libavcodec.so, may conflict with libvpx.so.4 <mbakke>rekado: I'm using Stow manually yes. Not through Guix or Guile. <mbakke>wingo: That build output looks familiar. <rekado>mephi42: use “--ad-hoc” before “perl” <rekado>the command as is gives you an environment to build perl, not one that contains perl. <mbakke>That reminds me, I need to fix the Chromium package. The only remaining thing is removing the default thumbnails, but the strings are nowhere to be found... <pkill9>mbakke: where do you have the chromium package? <mbakke>Although it's for 63, haven't gotten around to updating to 64 yet (currently travelling). <efraim>guix build: error: build failed: unexpected EOF reading a line <pkill9>maybe missing a closing bracket efraim <rekado>oh no! A user got this dreaded “ERROR: no code for module (guix build utils)” error. <rekado>the failing derivation is /gnu/store/gpxgqms8frl99jq0n5qnxnpmzc9965cc-gtk-icon-themes.drv <wigust>ACTION killed his X11 session again by hitting Ctrl-Alt-Backspace -_- <wigust>Any usability for this or could we disable it by default? <wigust>It doesn't help when a graphical program hangs a X11 session from my experience. <rekado>wigust: I thought this key combination is disabled by default since a couple of X11 releases. <snape>Is there a way to get a service to spawn a command at reconfigure only, and only if the service configuration changed? <civodul>rekado: i've stopped the 'cuirass' service and am running it in my screen again <snape>(the command being undeterministic) <pkill9>woo i successfully installed GuixSD to a VM <rekado>I think I should move all the bioconductor stuff from the bioinformatics module into a dedicated bioconductor module. <rekado>the bioinformatics module is getting too big. <wigust>rekado: True, seems it should be disabled “/tmp/.local/xorg-server-1.19.6/ChangeLog:29328: DontZap off is the default anyway, don't mention it specifically to avoid” <wigust>ACTION has a “setxkbmap -option terminate:ctrl_alt_bksp” in ~/.xsession <pkill9>if you didn't create a home directory for a user, is it safe to just make one in `/home`? or does it need to be added to the configuration? <wigust>pkill9: Did you create a user manually? <pkill9>no I created it inthe configuration <wigust>pkill9: It should be safe, but I don't understand why you didn't get a directory automatically. <pkill9>it's because i ran `guix system init` without changing the default users, which by default created /home/alice, then i changed it again and ran `guix system init` again but the directory didn't get created <snape>maybe you should have run 'guix system reconfigure'? <wigust>pkill9: I believe you should pull, reconfigure, etc after a reboot <pkill9>well i booted into the installation and now running `guix pull` <wigust>you don't want to pull until a first successful boot into the installed system <pkill9>i have successfully booted into the system <civodul>ACTION watches berlin build ghc-* stuff <civodul>sometimes you do notice things that you wouldn't otherwise notice <efraim>its how i noticed squeak-vm didn't build <efraim>and hadn't updated their cmake build tools in more than 10 years <roptat>hey civodul, I had a simple question about your answer on my patch about cat-avatar-generator: you said there was an indentation error, but I don't really see it... Could you tell me what line should be indented? <jsierles>Hey! I installed guix 0.14.0, then `guix package -i guix` which proceeded to downgrade the guix package. What's the reason for that? <roptat>jsierles: you need to run guix pull <roptat>we you install guix, it doesn't update the list of packages, that's what guix pull does <roptat>and because we can't put a version of guix that doesn't exist yet in the list of packages, you can't have 0.14.0 or later in the list <jsierles>OK. I just figured 0.14 would be able to use itself <jsierles>In this case I do not want to run guix pull because it takes forever. <roptat>because it's the list of packages from 0.14 <roptat>guix is the package manager and the list of packages <roptat>when we update guix (as a package), we cannot use something that doesn't exist. Once it is updated, we call that 0.14 <jsierles>If i'm already using 0.14 from the binary install, it's not intuitive that I cannot use that 0.14 package in a profile. <roptat>I agree, but the best we can do is update to one commit before 0.14 <jsierles>OK, I'm just trying to understand the reason. What you said doesn't make sense to me. <jsierles>0.14 exists in the store that comes with the binary installation. correct? <roptat>yes, but it's outside of the list of packages <jsierles>OK. then is it possible to generate a binary installation for 0.14 that lets you use 0.14 without guix pull? <roptat>jsierles: I would say yes, but you need a clone of the git repo first, then update the definition of the guix package to whatever you want <roptat>but even if you have guix 0.13-something, you sould be able to use package definitions from 0.14 <roptat>civodul: oh, I understand now, thank you :D <jsierles>Another topic - in a cluster environment, a cluster user should only need write access to /var/guix/profiles, correct? <efraim>builder for `/gnu/store/r8vy66bv020jzp3abc3jcc6pbr5fypps-xz-5.2.2.tar.gz.drv' failed due to signal 7 (Bus error) <rekado>my previous three attempts to schedule a new core-updates evaluation have all timed out :( <rekado>how can we start a new evaluation? <jsierles>Ehm, seeing lots of errors like: guix package: error: profile contains conflicting entries for r-digest <jsierles>Could this be related to using a downgraded guix? <rekado>when you are changing the version of Guix and keep installing packages into a profile successively, Guix will refuse to introduce package conflicts. <rekado>R packages like r-digest are usually propagated (i.e. installed into the profile) <rekado>so by installing packages with different versions of Guix into the same profile without upgrading the remaining packages (or without using a manifest) you end up with the superposition of partial instantiations of different variants of the package graph. <rekado>that’s just going to cause pain, so Guix detects that and aborts early. <jsierles>OK. That makes sense, but seems like an easy mistake to make if you just want to try out guix. <roptat>so I was wrong? if you install guix in your profile it will use this version's package definitions? <jsierles>So the fix here would be ensuring I install guix as the first thing in the profile, before trying to use guix again. <rekado>jsierles: this only happens when you install one version of guix, then install a package that propagates other packages, then update guix, then install another package that introduces a conflict. <rekado>why would you install guix into the profile at all? <jsierles>rekado: To be able to use the guix command line. <rekado>but you already *have* guix, no? <jsierles>Sure -but I can only use guix because I sourced the default profile that comes with the binary installation <jsierles>If I then use the newly generated profile, guix is no longer in my path. <rekado>the installation instructions also tell you how to make Guix available for everyone on the system. Did you read these instructions? <rekado>You are not limited to using a single profile <jsierles>This is not a normal unix system, so not applicable to me <jsierles>I'll look at the docs about that, thanks. <jsierles>I see the docs just suggest linking to the guix executable. That's fine, just wondered what the correct way is. I thought it was to install guix into the profile <mbakke>jsierles: The "normal" way is placing root's Guix anywhere on PATH. The Guix profile only prepends to the existing PATH variable. <mbakke>But installing to the profile will work too. <mbakke>To use multiple profiles see the "-p" option of `guix package` et.al. <jsierles>I see. using --search-paths with two profiles seems like it would work there to get what's needed <mbakke>jsierles: You can also access any profile through /var/guix/profiles. <jsierles>Just trying to figure out what's intuitive, or not, to write some articles showing how to use Guix. <mbakke>I'm curious what kind of system you're working on, are you able to share some details? <jsierles>mbakke: Sorry, I will share in a moment via a URL. I'm working at Nextjournal.com, where we've been trying to get guix working within it on-and-off <jsierles>It's a docker-based cloud execution environment, so you can just write code and build software environments in your browser <jsierles>Now I'm trying to get some sample articles that show how you could use Guix to install one of our supported languages and use it directly in the article. <jsierles>It's a bit hacky now, just having to run the daemon long enough to get software installed. But it's mostly working now. <jsierles>The result would be a fully reproducible notebook-style document you can use for playing with guix <davidl>wigust: I got the xmonad working for the root user only. <davidl>wigust: is it possible that the user-homes issue is related? <amz3>jsierles: it look impressive <jsierles>amz3: Thanks! Still working out a lot of issues. But it's coming together. <mbakke>jsierles: sounds very cool indeed, thanks for sharing. Looking forward to the articles :) <jsierles>Everything you see there is actually run in this interface. Each section generates an environment usable by the next section (or downloadable as a Docker image). <jsierles>civodul: Yeah, I'm familiar with the setup and have done it before. But I don't think the client needs full write access to all of /var/guix, does it? <civodul>it does, for GC roots (profiles, etc.) <jsierles>civodul: OK. does the client also do 'guix gc' <civodul>yes, but for that all it needs is access to the daemon socket <jsierles>OK. so it wont delete or move stuff in /var/guix - only create? <civodul>rekado: re core-updates, i can't log in to hydra.gnu.org right now :-/ <jsierles>So maybe sticky bit would work to prevent people from messing with each others profiles. <jsierles>civodul: The end result of the article is that you could inherit that guix environment in another article, or download it, as a self-contained unit (not tied to a global store). Eventually we'd like to support both approaches. <jsierles>Just the global store thing in a cloud environment is tricky <OriansJ>rekado: just a stupid question but is there a mechanism like defadvice in emacs which could be leveraged to provide the work around? <OriansJ>sneek: later tell janneke that path support has been added to kaem and that patches are up <rekado>ACTION is concerned about the ghc-resourcet build failures on other machines :-/