<apteryx>civodul: Yes! I have to revert back the ordering of phases though, because many packages depend on check happening after install now. I hadn't realized that. <brendyyn>i notice that /run/current-system/profile/share appears in XDG_DATA_DIRS twice when i login in a fresh vm <brendyyn>/etc/profile sets it once, then it is prepended somewhere else somehow ***catonano_ is now known as catonano
<apteryx>sneek: later tell zimoun I can't reproduce your problem with: 'guix build --check --no-grafts -K git'. Perhaps it is triggered only when the --check failed? <apteryx>sneek: later tell tibbe do you have an idea of how --check should be changed to make it more natural to use? One idea: if the package isn't in the store yet, fetch it as a substitutes or build it once, then proceed to build it a second time to validate the result. <apteryx>or perhaps --check should eliminated and implied by --rounds <apteryx>it doesn't really make sense to guix build --rounds multiple time on a built package... <apteryx>you're simply testing the store cache at this point, which is arguably not the intent. <fuedericco>I was wondering if there is anyone among you to help me improve my internet security <fuedericco>Perhaps I should be more spesific. I'm trying to make all my incoming/outgoing connection pass throug a secured bridge. Tor would not suffice since it is for browsing. Currently <fuedericco>I'm looking for vpn services (preferably free) and reading about building on your own vpn server with raspberry pi and such. Any advice will be appreciated. <fuedericco>is my messages even going through? I only see my messages and some logs <fuedericco>Oh okay. I just thought the channel would be more verbose considering 258 people currently listed <brendyyn>i think its the quieter time because a lot of users are in europe <fuedericco>That makes sense. They are sleeping. Alright then, I will continue my search for knowledge. Have a good one <brendyyn>for a vpn i think you want to pay money, because someone has to pay for the servers. <apteryx>fuedericco: it seems we have an openvpn-server service <fuedericco>where? how can i implement it? i want to build a bridge so not only my computer but other people also can have secure internet connection <apteryx>location: gnu/services/vpn.scm:468:2 <apteryx>line 468 of the (gnu services vpn) module <brendyyn>i found a wireguard tutorial in the cookbook <apteryx>yes, I saw that one too! It's for the client part only though. <brendyyn>i think i broke git while rebasing. i now have two commits in succession which somehow add the same lines twice <ryanprior>I've been creating little helpers and snippets in Emacs as I work on Guix packaging <ryanprior>Everything is quite centered around the repetitive go packaging work I've been doing lately. I'd happily consider PRs covering other areas or generalizing what I've got going. <brendyyn>i just had to create a new branch and reapply all my patches manually because i was too bewildered by rebasing behaviour <brendyyn>id squash two commits and then id magically be back where i started <bdju>is gajim-omemo a package that takes a while to build? looks like my machine has been stuck on it a few hours now. but oddly my cores aren't showing maxed in htop <bdju>so maybe it just stopped doing stuff <bdju>not out of disk space either <brendyyn>bdju: sometimes if something fails it might not properly show the command line prompt. you could always try ctrl-c and start again <bdju>alright, thanks for the idea <rekado>bdju: anything could take a long time to build depending on how many of its inputs are not available as substitutes. <brendyyn>guix pull: error: Git error: missing delta bases <bdju>rekado: yeah, but some things like rust stuff, icecat, webkit, etc. are especially bad about build time <rekado>bdju: yes, and about using resources, too *brendyyn accidently runs M-x animate-birthday-present *efraim is building out to python on core-updates on aarch64 since it was updated <brendyyn>module exports seem inconsistent in gnu/services. sometimes the <record-type> is exported, usually it isn't ***hji- is now known as hji
<rekado>brendyyn: often older services didn’t export the record type. <rekado>later it became obvious that you may want to match on the type, so more recent services do export the type <brendyyn>rekado: would you mind explaining what the third argument to guix's define-record-type* is for? the one that is called "make-thing". <brendyyn>we make a record of that type by (thing (a ...) (b ...)), so whats make-thing? <rekado>brendyyn: the “make-*” thing is a constructor procedure <rekado>the other thing is a syntactic constructor, i.e. a macro ***apteryx_ is now known as apteryx
<efraim>what do we need for modprobe tun? ***jonsger1 is now known as jonsger
<dannym>efraim: What do you mean? Which Linux kernel config option needs to be enabled? <efraim>we have /dev/net/tun but I "need" 'lsmod | grep tun' to not return 1 <dannym>efraim: Maybe it's builtin and not a module. Why do you need lsmod to list it? <dannym>efraim: modprobe itself has a feature ("modules.builtin") that ignores modprobe invocations that refer to builtins (without causing a failure) <dannym>efraim: But lsmod probably not... <dannym>If I get a "guix pull: error: Git error: the SSL certificate is invalid" when pulling from a https channel (on github), how can I find the missing certificates, and pass them to guix pull? <dannym>divoplade: But that sounds weird, since guix pull actually updates the (local) guix package repository, it would be weird if it depended on that repository that it is changing. <dannym>divoplade: Might be true anyway--I'll try it <leoprikler>It's a bit hidden, since you bootstrap it using /run/current-system/bin/guix on first pull, but you need Guix to pull Guix ;) <dannym>I got it to work now, without installing stuff from Guix. Turns out guix pull is /etc/ssl/certs/ca-certificates.crt in order to pull channels from git <dannym>I've set up Guix-the-package-manager-only in a docker container, so I know there's nothing else in there <dannym>Adding /etc/ssl/certs/ca-certificates.crt makes it work just fine <civodul>dannym: yeah it needs those X.509 certificates for https <dannym>On guix pull in there, it's downloading a lot of X related stuff and latex and whatever else, though. That's not really a bug I guess--but it was unexpected. (see post on guix-devel about that) <dannym>So now gitlab can build guix derivations ;) <civodul>though i don't understand the .gitlab-ci.yml in there, it doesn't mention "guix" <civodul>FWIW i've been using gitlab-ci (not on gitlab.com) with Guix, but with gitlab-runner running on a Guix System machine i control <civodul>i think divoplade had some success with Guix and gitlab-ci too <dannym>civodul: Sorry, I've not merged heads-on-guix-on-docker feature branch to master yet <dannym>civodul: I see! That would also be a possibility. <civodul>oh i see, so you have a trick to automatically spawn guix-daemon <dannym>I do this entire thing for Heads upstream, and they asked for Guix on Docker... *shrugs* <dannym>civodul: Yes, that guix-daemon autospawn took many tries to get too work btw ;) <civodul>yeah, we should establish a communication channel, because a security conscious project can do better IMO :-) <civodul>re autospawn, that only works if gitlab-runner runs as root or...? <civodul>did you try "guix pack guix --entry-point=bin/guix-daemon" or similar? <dannym>civodul: Probably. It was surprising that this worked as well as it did. But I'm using this on the shared gitlab runners so far, and I think it's using docker <dannym>civodul: So I suspect each job runs a docker container, and in that docker container does the stuff of the script in .gitlab-ci.yml -- so there, I'm *always* root ;) <dannym>civodul: Didn't try pack --entry-point yet. Does that work for guix pack tarballs? Because I don't use guix pack -f docker <dannym>(it's easier not to use guix pack -f docker in that case because of the way gitlab ci works) <sneek>zimoun, apteryx says: I can't reproduce your problem with: 'guix build --check --no-grafts -K git'. Perhaps it is triggered only when the --check failed? *rekado reads “Surviving the TeX font encoding mess” presented at EuroTeX 99 in an attempt to understand what might be wrong with our modular TeX Live packages <dannym>There are already bug reports in Docker about COPY not preserving timestamps--and they don't care <dannym>If timestamps are not preserved, then it copies in a random order, which for me meant guile thought that all guix scm files were newer than the go files and thus didn't use the go files .... veeery slow! <mfg>rekado: thank you for fighting with TeXlive :-) <zimoun>apteryx: yes, it is triggered only when it fails. However, I am not convinced that all the outputs are checked… Not easy to find a package with 2 unreproducible outputs. Maybe ’sbcl’ fits. <dannym>zimoun: Hmm, how does it work? :) <nly>"cannot change nick while quieted on #guix". stupidest thing ever. <civodul>zimoun: your gitlab example is definitely relevant; it doesn't show how you obtained the image, though? <mfg>nly: Why? if you could change the nick it wouldn't make sense to mute anybody :D <civodul>rekado: did the encoding mess get any better in those past 20 years? is it like wine or more like cabbage? <zimoun>civodul, dannym: “guix pack -f docker -m manifest“ on my laptop and push to DockerHub. The DockerHub step could be by-passed with an image containing ‘guix’ and hosted on our own registry. <civodul>ah yes, "skopeo" is the name that was mentioned a few times here <zimoun>I have answered with more details by email. ;-) <zimoun>I do not know what kind of format GitLab accepts. The dannym’s idea to pull from elsewhere than DockerHub is the good one. I have not dove into the details yet. :-) <dannym>zimoun: I pull from gitlab's docker hub. And I also automatically regularily push a current guix (package manager) there using my project guix-on-docker ;) <dannym>That's because I don't want to manually maintain guix on gitlab <dannym>It just pulls guix from git savannah and then does guix pack guix, and then uploads that to gitlab's docker hub <zimoun>yeah, that’s the correct way to do. <civodul>we're using Gitlab-Ci with Guix a lot at work but we're cheating by having a dedicated machine <civodul>it would be nice to have better integration <civodul>so we don't have to suffer like dannym did <dannym>zimoun: That looks very nice! Could have saved me a lot of work :) <dannym>civodul: An easy way to "fix" this is by just also releasing an official Docker image whenever we release guix. The question is whether we want that--people will expect this to work pretty well then *civodul whispers "entry in cookbook" <civodul>dannym: yes, i have to read zimoun's reply on this topic, using skopeo and all <zimoun>I agree with dannym about an ‘official’ Docker image. I had recently a discussion with Nyxt’s guy about that. :-) <dannym>civodul: Hehe, yeah, makes sense to put that into the cookbook eventually <dannym>civodul: Right now I have to still find out which way is best (I've changed the entire approach on gitlab three times by now), and also find out what the test runners expect <zimoun>civodul: my question is more about the path. We have 3 choices, I guess: DockerHub, own registry, skopeo with couple of super powder. <dannym>The default entry point just is guix-daemon <dannym>but gitlab totally doesn't like test runners to do that (I think it hangs, waiting for guix-daemon to finish :P) *zimoun is checking English dictionary ;-) <civodul>zimoun: running our own registry sounds nice, but it's probably quite a bit of work no? <zimoun>yes, it seems work… well setup is one thing but then the burden is maintain since Docker seems a moving target. <dannym>And I don't think we need a general docker registry where all the derivations are available (at least that's not my goal), but just a place to get guix <dannym>That means we can just install static files and no web services <dannym>For example install a static file /v2/_catalog with some fixed JSON content, install static file /v2/<name>/tags/list with one entry and provide /v2/guix/manifests/<reference> as a static file and so on <dannym>And basically give the user a docker registry with one image on there, guix; which updates from time to time <dannym>I mean it would totally be possible to swap out guix-daemon for docker as the backend that is doing our actual derivations--but that should be a non-goal for now ;) <zimoun>dannym: Maybe that’s the road. I do not know. <dannym>That said, there's nothing wrong with gitlab doing the hard work (building Guix from source, publishing it to their registry, hosting the registry for user)--I'm pretty satisfied with how guix-on-docker is now, and it really doesn't have to be part of Guix proper. <dannym>But like it is now, users that pull guix-on-docker from gitlab using docker have to trust gitlab, and also trust savannah. More required trust that would be nice :) <dannym>It would be nice if the user didn't need to trust both <zimoun>What could be nice on this path should be able to generate a Docker image from a manifest; the image only hosted a coupled of hours/days. Not necessary being part of Guix proper. The –save-provenance is a killer feature that many scientists dream (as any dream, they are not really aware yet ;-)) <zimoun>I agree that guix-on-docker looks nice. I will try it soon. <PurpleSym>zimoun: I have a guix integration for GitHub’s CI which works quite well. It’s just slow, because I need to run `guix pull` every time. <zimoun>PurpleSym: Cool! Thank you! You are saving me some time. :-) <PurpleSym>zimoun: :) I’d like to see your use-case, if public. <zimoun>PurpleSym: only the attempt to clean my website :-) Your guix-science looks great! It is one kind of topic that fits Guy Day proposal ;-) <leoprikler>I'm using my own Guix/alpine builds for Gitlab CI <mfg>does anyone use btrfs as the partition where /gnu/store lives? does the compression make a notable difference? <mfg>hm, you are right :D <dannym>PurpleSym: I wonder why the cache doesn't work, though. (I didn't try putting /gnu/store on a shared volume on gitlab yet, so I don't know whether there are the same problems there) <dannym>civodul: As for Heads: I'm talking to the founder of Insurgo regularily. I can suggest other approaches to him. <dannym>civodul: Right now, they are building Heads on two different CIs on github, and also on gitlab <dannym>civodul: In order to find reproducibility problems. Which they did find. <dannym>civodul: That's why they approached me. They had heard about Guix on FOSDEM <dannym>civodul: It's clear to me that first they have to be convinced that Guix is better than what they have now (no containerization of packages, and Makefiles) <dannym>civodul: Basically their previous way of getting reproducibility started not working anymore--because they forgot to refer to some dependencies in their Makefiles that they were using <dannym>civodul: So it picked up the host library :P <dannym>civodul: By now, I've got them ready to try Guix <efraim>I use btrfs for /gnu, I can look up how much it saves when I get back to my computer <dannym>civodul: But in the end getting Heads to work on Guix is a lot of work (I had tried before--it's not easy) because they are targeting flash chips--so they are using musl, sometimes static linking and generally disabling a lot of features <dannym>civodul: Right now, they are using musl-cross-make as toolchain <zimoun>dannym: just to understand the discussion. What is Heads? <dannym>civodul: If they wanted to use Guix, I could package musl-cross-make (I've packaged musl-cross (that's what they had used previously) before, and it worked for a while) <PurpleSym>zimoun: Yeah, I was thinking about presenting our overall Guix setup (not just guix-science) there. <jonsger>zimoun: heads is a distro with a key feature running every application in its own VM, AFAIK <dannym>zimoun: Heads is a firmware (BIOS) that makes sure that your computer has not been tampered with (if it has, it shows up somewhere) <dannym>jonsger: Don't worry. In practice they are often using Qubes OS after Heads, so it's kinda associated. <dannym>jonsger: However, Heads is trying to add support for booting Guix and Nix, too. <janneke>civodul: ah, "guix archive --authorize < key.pub" still exists...i was assuming that would go when i suggested an --authorize-key option <zimoun>PurpleSym: I have just sent an email to guix-science :-) <dannym>cbaines: Huh. Thanks. I had never seen that before... <cbaines>I think I may have come across it before, but I'd forgotten about it *lfam starts making linux-libre 5.9 kernel configs <lfam>It seems that we have to choose between different failure modes <lfam>I wonder if the use of "32-bit applications so ancient that opening a file larger than 2GiB fails with EINVAL" on 64-bit platforms can really be expected on Guix <jackhill>lfam: it sounds like even with the kernel option enabled, narrower inodes could be requested at mount time? <dannym>lfam: ...that's exactly what all of Guix does <lfam>What do you mean dannym? <dannym>lfam: Guix is only providing 32-bit applications so ancient that opening a file larger than 2GiB fails with EINVAL <dannym>I find it absurd to, but that's what Guix does <jonsger>lfam: nice, so I can finally use my onboard ethernet card :) <civodul>janneke: yes, "guix archive --authorize-keys" still exists! <lfam>Thanks for the info dannym, I'm reading the thread now. I'm starting with the x86_64 config, so I'll have to see if this bug is relevant on that platform <lfam>jonsger: Which option is that? :) <janneke>civodul: ah nice, but changes made with archive --authorize-keys will be lost after a reconfigure i guess <civodul>janneke: yes, but actually you'll even get "Permission denied" because /etc/guix/acl will now be a symlink to the store <civodul>and you can still have (authorize? #f) and do things the old way <dannym>lfam: It is relevant, because we are bootstrapping Guix from i686 on x86_64 (and on i686 Guix, we have 32 bit offsets and inodes and directory offsets) <janneke>nice, /me "should" learn to read patches better <civodul>np :-) actually this 'authenticate?' bit was already there <dannym>lfam: So if the kernel used for bootstrapping is x86_64 but the userland is 32 bit guix, that is going to fail very badly randomly <lfam>dannym: Do you recommend disabling this kernel config option then? <dannym>civodul: Thanks. I know that the founder of Insurgo knows the bootstrapping thing--that's why he would prefer guix to alternatives in the first place. <dannym>civodul: He was at FOSDEM hearing the Guix talks :) <jonsger>lfam: it's enabled in the default config of r8169 module. I think it's just some IDs and minor stuff coming in... <dannym>lfam: With an imminent Guix release (if you want this to be in there), I would recommend disabling this kernel config option for the time being (... disabling it will totally come back to haunt us later with something else, though). <lfam>Yes, as a heavy user of tmpfs I would like to enable it eventually, but we can disable it for now. I haven't been paying attention to the release discussion and I don't think it matters much if 5.9 is part of it <dannym>lfam: In an ideal world, I would recommend fixing bug# 43513 and not have any other weird workarounds. But that's gonna take time, rebuild the world, and also right now core-updates has other problems, so I can't even do it. <lfam>We have 5.4 which will be supported for 5 more years, and that is good enough for a release <mfg>is it possible to only show failed builds in the guix data service? <dannym>lfam: Ok, if it doesn't go to master (yet), I would enable it. I'd suggest to enable it on core-updates then (that's where we'll fix bug# 43513, eventually, too). Or where does this go then? <lfam>dannym: Typically kernel updates go to master. Major updates go through a 'kernel-updates' branch but it is supposed to have a short timeline <lfam>Should I make a followup commit on core-updates to enable the option? <cbaines>mfg, in which bit of the Guix Data Service? <mfg>cbaines: i have never used it before, so i went on the most recent commit link and then on view package derivations. <dannym>lfam: 64 bit inodes are probably going to make bug# 43513 much worse if enabled. Which is a good thing when trying to find all the places where the bug is hiding... <lfam>Okay, I've added it to my todo list, dannym. Thanks for the advice <dannym>(But not a good thing if it falls on users heads :) ) <lfam>And to clarify, this is just for tmpfs <lfam>I use tmpfs for building things and processing large files <dannym>Ah, thats right, we don't use tmpfs for /tmp <lfam>Not by default, but it's simple to set up <lfam>And worth the speedup, IMO <lfam>Especially for building kernels... so many small files <dannym>If a user does that and this Linux kernel option is enabled and the bug 43513 not fixed and you are trying to run 32 bit programs built by guix, those will fail in "interesting" random ways <dannym>Or worse, not fail, but be built wrong <lfam>OTOH, files may be lost when inodes are re-used, if I understand correctly <lfam>It's a bug in either case <lfam>I think it's best to stick with the bug we know, rather than change it for another one <mfg>cbaines: many thanls that's what i was searching for :) <mfg>jackhill: thanks for posting those numbers :) what compression level are you using for zstd? <jackhill>this is on my workstation, so has desktop software for what it's worth <mfg>thanks for the info :) <mfg>i would also use it on my desktop, but i don't have that many grpahical applications (emacs, alacritty, icecat) :D <efraim>there's no TTY available in the build environment, right? <Zambonifofex>rekado: I’m sorry to pester you, but I was hoping to be able to wonder whether you have ended up updating the `netdde` package for Hurd. If you’d like, I could try more thoroughly once again by myself, if you think it’d be helpful. <efraim>no, there is. I see it in nix/libstore/build.cc <divoplade>There's something really frustrating while writing guile code: I want to write some data to a file, and it's always the same thing. First, call with-output-to-file. If it fails, parse the file name, remove the base name, and try to make the chain of directories, and then re-try the write (but not recursively, stop if there's an exception this time). <divoplade>I wished there was a with-output-to-file* that did all that. <divoplade>Because to me that's obvious that the behavior "create the file if it does not exist" should extend to "create the chain of directories if there's one missing". <divoplade>leoprikler, wait, where did you find mkdir-p? <leoprikler>I also have my own version for when I can't link against Guix. <leoprikler>It's not too hard to implement, and you can work around it in various ways. <divoplade>There's mkdir -p in coreutils, so it's definitely useful <divoplade>It being not too hard to implement is also a good reason why it would not be too much work to add to guile! <divoplade>These options are orthogonal to the C functions used <divoplade>It's just enhancing the results with a different set of functions <divoplade>But mkdir -p is precisely re-using the mkdir function <sneek>niko, nckx says: Ideally, you *don't* install P's dependencies alongside P. On Guix, ‘installed’ (the package is available in the current profile/environment, its binaries can be invoked from $PATH, &c.) and simply ‘present on the system’ (not in your profile/environment but still in /gnu/store, from where packages that depend on it will load it directly) are different things. <sneek>niko, nckx says: Your package should load its exact build-time dependencies from /gnu/store/<hash>-…, not even noticing whichever random versions the user has installed at any time. Most build systems take care of this for you. <leoprikler>and yet there's no POSIX-mandated mkdir_p function as far as I'm aware. <divoplade>Well, guile has a lot more functions that what posix mandates ^^ <leoprikler>Sure, but mkdir is specifically part of the POSIX stuff ;) <divoplade>I doubt the file tree walk procedure are part of posix <divoplade>I even think readdir is a glibc-specific function <divoplade>So when it comes to directory, it's clear that POSIX is insufficient! <divoplade>I have an implementation of mkdir-p in each of my non-trivial projects, and now guix too, but we can't really use the same version because that would be unreasonable dependencies. Should we go full NPM-style and have mkdir-p as a separate package, or maybe guile could provide it? <civodul>Gash-Utils could become the library of shell-style functions that everyone uses <leoprikler>+ 2 more, because guile-gi and g-golf provide bindings to g_mkdir_with_parents ;) <leoprikler>civodul: only for GPL'd libraries, but yeah, that's probably an option <divoplade>gash-utils is already more reasonable to link against than guix :) That being said, I doubt any of the projects have a use for most of the other functions. Look at that beautiful function "rmdir-p" in gash (shell-utils). The doc string looks very promising! <divoplade>"Remove directory DIR and all its ancestors." <divoplade>(well, in fact it removes all ancestors until ".") <leoprikler>either you're too generic or you're missing stuff <divoplade>The middle ground would be to have a package with exactly mkdir-p <leoprikler>Except being too generic while still missing stuff. <leoprikler>(define-module (i really need mkdir-p like one of those npm folks) #:export (mkdir-p)) <leoprikler>I say "just copy whichever mkdir-p suits your license into (myproject utils)". <divoplade>There's a need for a package, I think. What happens when we'll be all porting our projects to mingw? <leoprikler>As far as I know, there's no mkdir-p out there that has Windows support, so you'll be the first one to write that. <divoplade>I mean, there's not even guile with windows support <divoplade>So I'll try to fix it when we know how dirname and basename work on mingw :) <mfg>does guix support --with-debug-info=all? <mfg>i tried it and i guess i need to update first :D <civodul>mfg: the argument to --with-debug-info is a package name :-) <civodul>which suggests that cbaines did a good job at making it easy to deploy it :-) <lfam>I haven't been paying close attention, but I noticed a lot of recent discussion regarding Cuirass <cbaines>Hmm, that looks like it's just a proxy to data.guix.gnu.org <lfam>I'm wondering if it's expected that Cuirass evaluation take a few hours to complete. Or if they are stuck <mfg>civodul, yes i read that, but i thought it might also understand all because it gets tedious pretty quickly to explicitly list all packages :D <mfg>but that's what i have to do then <cbaines>civodul, how did you stumble upon it? <civodul>searching "guix" on the net (as someone mentioned again the MS "GUIX" thing) <civodul>(to search engines, "guix" is still "GNU Guix" and not "MS GUIX", which is good news) <lfam>Is it new that it's part of MS? <cbaines>also, just realised, it isn't even a proxy, that domain just points at the same IP address as data.guix.gnu.org <cbaines>Maybe data.guix.gnu.org should only respond on that domain... <bluekeys_>Hi guix. I've just run guix edit hello and it opens in nano? What's the idiomatic way to set things like environment variables in config.scm? <lfam>bluekeys_: It should respect the $EDITOR and $VISUAL environment variables <bluekeys_>thanks lfam, is there a way to set environment variables in config.scm? <lfam>I'm not sure... anybody? <cbaines>I've configured nginx on data.guix.gnu.org to now return a 404 if you don't actually ask for data.guix.gnu.org <cbaines>I guess that will help with search engine results in this weird case <rndd>hi everyone! what is purpose of (revision ...) in package? <cbaines>rndd, a revision is explicitly used with some package definitions when the version wouldn't sort normally without it <cbaines>for example, when upgrades to the package just use a different git commit, you put a revision before that which always increases <rndd>cbaines: oh it is needed for guix to not print "package downgrated"? <rndd>cbaines: ok, thank you ^_^ <civodul>cbaines: cool, thanks for the nginx update <rndd>maybe somebody had same problem <rekado>found a problem in the manual: the singularity-service-type is under the section Auditd Service <rekado>I guess it got separated from the docker-service-type with heading Docker Service <rekado>bluekeys_: the undocumented session-environment-service-type allows you to set environment variables globally <rekado>would be good to add its documentation to the manual <bluekeys_>gonna reboot and see if I've managed to use session-environment-service-type properly. <rekado>you could check before reboot if the etc directory in the newly built system contains an “environment” file <rndd>got "guix pull: error: Git error: cannot locate remote-tracking branch 'origin/keyring'" trying to pull from local guix channel directory. could anybody tell what is wrong here? <rekado>rndd: it means that you need to run “git fetch origin” to also get the “keyring” branch <rekado>not sure what you mean by “local guix channel directory”, though <rndd>i alse tried "git checkout origin/keyring" <cbaines>rndd, git checkout keyring might create the branch locally, tracking the remote branch on savannah <cbaines>checking out the remote branch won't be sufficient <rekado>the manual says: git fetch origin keyring:keyring ***niko is now known as nuka
<rndd>rekado: well, thank you, i will reread it <rndd>also, does anybody had problems with sbcl 2.0.9? i had some, and no with 2.0.8