<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
<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.
<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
<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'?
<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?
<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.
<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