<civodul>yeah it's fine to revert when there's breakage like this <civodul>Hartmut will reinstate it when they wake up tomorrow ***daviid is now known as Guest89808
***Guest89808 is now known as daviid
<peanutbutterandc>Question: How can I skip tests for perl-build-system; and more importantly, where can I find the (arguments ...) that a (build-system ...) can take? It's not there in the reference manual. <reepca>"They inherit most of GNU-BUILD-SYSTEM, and differ mainly in the set of inputs implicitly added to the build process, and in the list of phases executed." It stands to reason that if perl-build-system has a way to disable tests, it's probably with #:tests? #f, since that's what GNU-BUILD-SYSTEM uses. <reepca>if you want a comprehensive, accurate list, I'd say check out (guix build perl-build-system). <reepca>peanutbutterandc: aye, among any other arguments you want to pass. <reepca>(and I think it's named 'arguments', with an 's' at the end) <peanutbutterandc>reepca, Please forgive my n00b-ness but how would I check out (guix build perl-build-system)? I suppose you are referring to something like >>> import module >>> help(module) in python. I am new to guix and guile. <reepca>"check out" here just means "open up in an editor". For your current version, that'd be '~/.config/guix/current/share/guile/site/2.2/guix/build/perl-build-system.scm'. <peanutbutterandc>reepca Ah I see. I thought I could load it up in guile with first (use modules (guix build perl-build-system) and then (some command) here. <reepca>%standard-phases shows that the 'check phase from the gnu-build-system has been replaced with one tailored to perl, which is bound to the variable check in this module. We see it's defined a few lines above via a macro called define-w/gnu-fallback*, which we can treat like define for most purposes. We see that check takes tests? as a keyword argument, and that it checks the value when deciding whether to run. <peanutbutterandc>Also, I suppose that and the one in the git checkout (source tree) under /guix/build-system/perl.scm are essentially the same (?) <reepca>it'd actually be guix/build/perl-build-system.scm, (the "build-system" subdirectory is for client-side code, the "build" subdirectory is for builder-side code) but yeah I'd expect it to be mostly the same if both are relatively recent <peanutbutterandc>I see. Thank you. That makes sense. I will be trying things out with (arguments ...) now. Your help is much appreciated. :) <peanutbutterandc>`(arguments `(#tests? #f))` didn't quite work. I get the following error: (tail -n 3) <peanutbutterandc>Also, my guix-daemon is running with --cache-failures; is there a way that I can tell guix package to NOT use the cache and start from the beginning? `guix package --help` didn't provide anything helpful. <reepca>peanutbutterandc: 'guix gc --clear-failures <PATH>' should help there <peanutbutterandc>reepca What should the PATH be? The path to the non-existant drv file that it is looking for? <reepca>though if the failure is reproducible it shouldn't matter. Note that changing the package definition in a way that affects the build will cause a different derivation to be produced <peanutbutterandc>guix build: error: opening file `/gnu/store/spn9dn9cqafysd3425m8vz578gm1qqmq-my-chordpro-idk.drv': No such file or directory <reepca>also, I think you've forgotten a colon in #:tests? <reepca>peanutbutterandc: it'll be one of the paths produced by 'guix gc --list-failures' <reepca>I'm actually surprised it didn't give a more descriptive syntax error <reepca>hah, that's actually some pretty interesting behavior: (let ((ests "foo")) (list #tests)) => (#t "foo") <reepca>I don't know if it's technically a bug, but misleading at least. <peanutbutterandc>I see. Not sure if I fully understand but something to do with value-substring-already-defined-as-variable being side by side and expanding, in bash terms, as if it was foo${bar}... I think <reepca>it's actually an issue with the reader, the let-expression there is just to show the behavior it results in when evaluated. To see it in action, fire up a guile repl and run '(begin (write (read)) (newline) (write (read)) (newline))', hit enter, then type '#tests' and hit enter again. <reepca>Unfortunately I'm not familiar with the perl ecosystem, but it looks like it's failing to find one of the inputs you've provided. Perhaps some search path needs to be set or something? <peanutbutterandc>reepca, I checked `guix package --search-paths` and it isn't giving me anything other than PATH. Which is strange because I have been counting on the command to give me the right search paths so far... <reepca>peanutbutterandc: is the output you pasted from 'guix build -f <the-pasted-file>.scm', or from manually running build steps in 'guix environment -f <the-pasted-file>.scm'? <peanutbutterandc>reepca, It is the output of `guix package --install-from-file=chordpro.scm` <reepca>it's strange that it's referencing /root/.guix-profile, that shouldn't be in the build environment anywhere <peanutbutterandc>I wrote guix_sourcerer.sh so as to have it work on any foreign distro so that every new user added to the system will have guix configured without manual intervention. <reepca>peanutbutterandc: so you ran 'guix package --install-from-file=chordpro.scm' and the last line was 'BEGIN failed--compilation aborted at /root/.guix-profile/bin/chordpro line 40.'? <reepca>That it seems to be indicating that chordpro was run from the root profile would suggest that it was built successfully, installed, and then run on something. What does 'guix build --file=chordpro.scm' say? <peanutbutterandc>reepca, I ran `guix package --install-from-file=chordpro.scm`, it executed sucessfully. And then running `$ chordpro` gives me the error <reepca>ah, okay, that makes things clearer <reepca>try installing perl in the same profile. I suspect PERL5LIB needs to be defined. <reepca>The issue is that search path definitions aren't, in general, listed for every single package that *provides* stuff that should be found via that search path, only for the packages that *use* that search path. So for example, the perl package specifies the PERL5LIB environment variable, but if it's not in the profile, then it doesn't get set. <reepca>if it works after that's set, consider adding perl as a propagated-input. I'm not sure if it's good practice (I don't do much public-facing packaging myself), but it should get the environment variable set. <reepca>source /root/.guix-profile/etc/profile <reepca>Hm... maybe this @INC business uses a different environment variable. <peanutbutterandc>It seems to use PERL5LIB. I just found myself wishing Mr. Larry Wall to be a GuixSD user, hanging out here in IRC. lol <reepca>I guess you could try moving all of the inputs to propagated-inputs. Usually we try to avoid this by ensuring that the path to dependencies is burned-in at build-time, but I guess with perl it's not easily-doable. <peanutbutterandc>reepca, Update: I moved just perl-app-packager to propagated-inputs and it didn't work. Trying again. <reepca>peanutbutterandc: did the error message at least change to complain about not finding a different package? <peanutbutterandc>It does seem to be complaining about other packages. So I'll just trying moving all cpan packages to propagated input altogether <reepca>well, basically, runtime linkage is the only linkage perl (and some other languages, like python) seem to have, so everything needs to be accessible through a search path. Profiles only create search path entries for the packages *directly* installed in them, not their dependencies. But if a dependency is in propagated-inputs, it also becomes installed in the profile (and so do its propagated-inputs, recursively), and thus visible via <peanutbutterandc>reepca, So, if I wanted to have it link through just plain old (input) what would I have to do (in theory)? <reepca>A potential alternative would be to create wrapper scripts that set the paths for each executable, but I'm not sure to what extent that's actually done in practice. <reepca>peanutbutterandc: find a way to burn in the paths at build-time. If the build system has a way to provide a "fallback" search path that can be set at compile-time or install-time, you could populate it with all the entries of $PERL5LIB present at build-time. <reepca>For example, in your first attempt to run it, somehow it knew to look in /gnu/store/qjfrp5sffyw9vl4cdb3db581i4q5lp8j-my-chordpro-idk/bin/../lib. If it can be told where its own files are going to be, perhaps it can be told where other files are going to be. <peanutbutterandc>reepca, Whoa. So, for now, is it okay for me to naively think "Interpreted Libraries/modules go to propagated inputs"? <reepca>peanutbutterandc: aye, see the description of propagated-inputs in section 6.2.1 of the manual <reepca>it basically says as much there: "Another example where ‘propagated-inputs’ is useful is for languages that lack a facility to record the run-time search path akin to the ‘RUNPATH’ of ELF files; this includes Guile, Python, Perl, and more. To ensure that libraries written in those languages can find library code they depend on at run time, run-time dependencies must be listed in ‘propagated-inputs’ rather than ‘inputs’." <peanutbutterandc>reepca, I see. I forgot to look at the last paragraph and was only reading about the C/C++ library. Thank you very much for helping me out and being patient with me. You're the coolest! :) <leoprikler>reepca: What about PYTHONPATH, GUILE_LOAD_PATH, et. al.? <reepca>leoprikler: RUNPATH is baked into an executable, letting it always know where to find the libraries it depends on regardless of execution environment. Those are environment variables that depend on having the dependencies in a profile at runtime (usually by means of being propagated inputs). <reepca>peanutbutterandc: no problem, I learn a lot from it too <peanutbutterandc>Now, regarding GUIX channels, are there any tips/warnings? I'm about to create my own soon. What should the git repo NOT have? Anything that I need to be mindful of? <leoprikler>but thats, why e.g. python-build-system uses 'wrap to specify those environment variables, is it not? <reepca>leoprikler: aye, that's one way of getting around the issue <peanutbutterandc>This is strange. I just defined a package and learned that for it to work, I had to install `perl` and export PERL5LIB variable. So, I thought I'd add perl to the (input) in the package definition. But I still have to install perl separately. `guix package --search-paths` does not show PERL5LIB env var. Any ideas please? <peanutbutterandc>I would like for the `guix package --install-from-file=my-package.scm` to install perl itself and for `guix package --search-paths` to report the env vars once the installation is done. <amz3>peanutbutterandc: I use a channel, well, I don't have much recommendation to do outside what is already in the manual <peanutbutterandc>amz3, I would like to put the file up in a channel too, soon. But first I want to get just the .scm part done right... <amz3>peanutbutterandc: did you grep perl in guix packages to see how other package that depend on perl are done? <roptat>peanutbutterandc, there are at least two solutions, either propagate perl, or use a wrapper. A wrapper is preferred, because it doesn't install perl to the user profile (so it reduce the possibility of conflicts) and ensures you can run from the store directly <roptat>now, I don't know what perl packages usually choose <peanutbutterandc>roptat, How would I write a wrapper? And what is a wrapper? And is there any documentation about it? I'd like to do that please. <peanutbutterandc>P.S: 'Propagate perl' means putting it in (propagated-inputs), I presume? <amz3>peanutbutterandc: fwiw grep, 'search' (even in emacs) is a power user pratice. <peanutbutterandc>amz3, Sorry I am still a n00b. A bit n00b-friendlier instruction please! <amz3>peanutbutterandc: I mean to say that searching whether it is via command line, search engine or code editor is a power user pratice. <amz3>peanutbutterandc: if you search for PERL5LIB in ./guix/gnu/packages you will find example code that wraps perl <amz3>fwiw = for what it is worth <amz3>peanutbutterandc: did you read some things about guile programming? <peanutbutterandc>amz3, I am currently going through the manual (and another book on scheme) <peanutbutterandc>If I am explained what the different parts of that code does, where they come from etc, I could probably use it. I find it really strange that these aren't documented. These seem super useful! <amz3>the manual can not deal with every single use case, they are many, users can have. The manual gives guiding principles and detailed explanation about the primitives and how to use them. At the end of the day, the manual will not tell you what to do in every situations. <amz3>peanutbutterandc: if you do not feel confortable, use propagated input. <peanutbutterandc>amz3, Perhaps I should make do with it for now and then, once I'm through with my guile books, will be able to redo it. Thank you for your help. It is much appreciated. <bdju>will the FSF usb membership card ever come with Guix System instead of Trisquel? <bdju>it would be nice if the firefox devs could reduce the compile time <bdju>I started updates before going to get some food, and now I come back to see icecat is building. I may just cancel it because it takes a long time and makes everything slow <bdju>I am thinking back to the guix bootstrap article where compile time of something was reduced from 5 hours to 8 minutes. that is truly magical. it makes me think a lot of software could probably be improved that much <wingo>i work on firefox and my build times are around 13-14 minutes. gotta have a ridiculous machine tho <wingo>reducing build times is always like a 3rd priority tho :P <ng0>wingo: how many cpu cores and ram does it have? <wingo>20 cores (2x10), 2 threads/core, 64g ram <wingo>unfortunately such a machine is table stakes for browser work these days :/ damn things keep getting bigger <ng0>also the build of clang is swapping so much when you have only 8GB Ram <ng0>i've just switched back to gcc in for now base because the increased build time + libcxx is rather annoying, you find bugs you don't want to find all the time, hopefully this is getting better by the time of netbsd 10. <civodul>roptat: i think your overdrive is down <leoprikler>wingo: I'm sure epiphany builds in significantly less time <wingo>leoprikler: not when building webkit also <roptat>civodul, I'll have a look this evening then <bluekeys>Hi guix, can someone tell me how to mount an ntfs disk rw? I've installed ntfs-3g and tried mount -t ntfs /dev/sdc1 /mnt/ntfs <bluekeys>sudo mount ... but I'm told the fs is ro when I try to touch anything <bluekeys>Ooops. sudo ntfs-3g -o rw /dev/sdc1 /mnt/ntfs seems to do just fine. *civodul works on Cuirass to finally have it log evaluation outputs <str1ngs>go 1.13.1 was releases recently as a security update. FYI *janneke works on moving to pointer-based cells for mes <civodul>janneke: "pointer-based cells" like in Guile? <janneke>civodul: oh, i have no idea! *shame*... <janneke>mes 0.2 had pointer-based cells, since mes 0.3 cells were number-based (index) <janneke>i still like number-based better, but pointer-based is much cleaner to do without macros, and m2-planet has no macros :-) <janneke>it could give us an performance boost (or penalty ... :) <janneke>and using number-based, my stop and copy garbage collector could use 90% of the arena, with pointer-based i don't see a nice way to use more than 50% <wingo>see the note about the compacting algorithm there <janneke>wingo: thanks...i should move away from stop-and-copy and go to mark-and-sweep, i guess? <wingo>i think the latter was the thing you could run in guile <roptat>is it possible to get the range of source location for a definition? like, can I find the location of the beginning of a package definition, and of the end of the definition? <wingo>roptat: edit-expression in (guix utils) has some bits <wingo>similarly update-package-source in (guix upstream) <civodul>it'd be great to have support for range locations in 'read' & co. <civodul>but in the meantime, we can always infer it by... calling 'read' again and checking the port position :-) <apteryx>hello Guix! I updated my profile, and suddenly I can't input accentuated characters such as è or à in GTK applications such as Emacs, Icecat, etc. Any ideas? I think I've had this issue before but forgot how to fix it. <apteryx>perhaps it's just a matter of updating my system profile as well; I'm getting locale warnings. <nckx>Disregard that… Might as well ask tho': the above is a pipe-stuff-to-bluetoothctl script I run every time I want to use my Bluetooth mouse. Is there no way to auto-connect BT devices without running a DE/systray/whatever? <dongcarl>I'm guessing that the way we make our gcc target a particular libc needs to be updated... <dongcarl>I'm also seeing this weird "properties" thing on our gcc packages... Is that the new way of parameterizing a package? <nckx>roptat: ¯\_(ツ)_/¯ I was going to say ‘switching on the mouse doesn't generate udev events’ but it actually does… after 20s or so. So just waiting 20s every time I want to get to work is an option, I guess :-/ *nckx will stick with the script that echoes a tab-complete to bluetoothctl oh god <nckx>dongcarl: More a way of tagging metadata (and not new at all, it's how ‘known fixed CVEs’ are tagged for example). Ludo' did suggest overl^Wextending it for parameterizing but I wasn't wild about it. *nckx goes to look at how they're used for GCC though. <nckx>dongcarl: Is this about 'gcc-libc? Because that's a new one to me, too. <bavier>I was also not a fan of the idea <dongcarl>nckx: Nah, I was confused about properties, don't worry about that... <dongcarl>My current struggle is mostly with why MAKE-GCC-LIBC stopped working <nckx>dongcarl: Mh, I saw your bug, but Dropbox boycotts cURL. <nckx>(Don't bother re-uploading though, it's not like I'd be of any help, just curious.) <dongcarl>Why does your tagline say "I do not speak for Google Inc."? <nckx>I was exposed as a paid Google shill trying to bring down ##rms so I decided to put the record straight. <nckx>It should've been long gone, though. <dongcarl>I see... And that accusation was because you work for Google? <lprndn>Does anyone has an idea of what would be needed to use `guix system container` without sudo? (is it expected?) <Laila>Hello Guix! I need help with packaging (I am talking about entry level running packages).Here it goes (this may sound silly and I should know this already) - http://paste.debian.net/1109342 Where do i add export PATH="/root/.guix-profile/bin${PATH:+:}$PATH". etc/profile? <nckx>lprndn: CONFIG_USER_NS_UNPRIVILEGED? Just a guess. I've explicitly disabled it on my system and ‘$ guix system container’ fails as desired. <nckx>Laila: Don't add it anywhere, you will run into trouble :) Either paste it into the current shell if you want to use the new packages right away, or start a new session and the new PATH should be loaded automatically from ~/.guix-profile/etc/profile. <nckx>civodul: Sorry ;-) The Kconofig documentation is IIRC pretty clear (as Kconfigs go) that it's not without risk. <civodul>well, using that whole one-size-fits-all batteries-included kernel is not without risks ;-) <nckx>civodul: So it should work with a Guix System kernel? <gnutec>Why system stop when I try to install big package like Blender or Icecat? <civodul>nckx: what should work? CONFIG_USER_NS_UNPRIVILEGED is set to "y" in our 'linux-libre' packages <nckx>civodul: Unprivileged guix system container. <civodul>that doesn't work but for other reasons <civodul>namely, you need to have more than one UID in the container <civodul>so my understanding is that unprivileged ns isn't enough <gnutec>nckx: Yes! 2 GB memory only. 4 GB of swap. <nckx>civodul: Thanks, makes sense. I was reading up on this but it's all Docker this edit /etc/dockeruid that. <civodul>gnutec: "guix install icecat --dry-run" would tell you whether pre-built binaries are available <nckx>gnutec: I'm afraid there's no way to build Icecat with that amount of physical RAM. You'll have to wait for substitutes, as civodul says, or offload the build to a more powerful machine. <gnutec>civodul: But the system stop when the guix is "build". <nckx>Laila: And the problem is that hello is not in $PATH? I'm not an authority on Guix on other distributions. You need to load $GUIX_PROFILE/etc/profile somehow (like adding ‘. $HOME/.guix-profile/etc/profile’ to ~/.bash_profile). <Laila>nckx - ahh I see. how did i miss that? <nckx>Laila: That's what info (guix)Invoking guix package says anyway. <civodul>gnutec: you can try "guix build icecat --dry-run" too, it's pretty much the same <nckx>Asking questions like that here is fine, we're no elitists 🙂 As long as you don't try to completely outsource your brain you'll be fine. <nckx>Can anyone build gst-plugins-good@1.16.0? <efraim>I have it on my machine but i'll try rebuilding it <nckx>efraim: Thanks! I'm running with -K now… <apteryx>nckx: do you have (bluetooth-service #:auto-enable? #t) in you confdig? <efraim>/gnu/store/yycdxzlp6djw540cl8frqdydr608rkwy-gst-plugins-good-1.16.0 on bayfront <nckx>apteryx: Actually, I have (auto-enable? #t). <efraim>my machine is still chugging along <nckx>(service bluetooth-service-type (bluetooth-configuration …)), but that should be equivalent, right? <apteryx>nckx: it should be. An easy way to check is to cat /etc/bluetooth/main.conf <nckx>[Policy]\nAutoEnable=true 🙂 <efraim>my machine finished building it too <nckx>apteryx: Thanks though. The whole Linux BT stack is something I just don't quite get. <nckx>efraim: OK, then it's just here (watch it succeed this time). Thanks. <nckx>I'll just have to learn to live with the 20-30s connect delay (which really doesn't fit my workflow) or keep typing ‘btc’… there are worse things. <lprndn>civodul: And what is the difference between containers from guix system and guix environment? Would it be possible to start a service in the latter? (as they don't need sudo. I suppose it doesn't create uids?) <efraim>I never implemented a recursive cve checker, right? I know we have the recursive refresher <efraim>guix package -p /run/current-system/profile -I | cut -f1,2 --output-delimiter=@ | sort -u | xargs ./pre-inst-env guix lint -c cve *efraim calls out "come see all the vulnerable packages in your os-config!" <nckx>efraim: guix package -p /run/current-system/profile | wc -l ***jonsger1 is now known as jonsger
<efraim>nckx: guix package -p /run/current-system/profile -I | wc -l <nckx>leoprikler: Not if your Guix is up to date. <efraim>leoprikler: the CVE checking code was just re-enabled about 4 hours ago <bdju>will these get fixed now? <efraim>they get more notice now, hopefully we'll patch them *nckx is ‘fixing’ CVE-2017-6519. <bdju>(mostly similar stuff for me) <efraim>now try 'guix lint -c cve', it'll show all the CVEs that are public that affect packages in guix <bdju>can't figure out how to count them, but there are a lot <bdju>when I pipe to wc it still runs normally and then wc says 0 after it's done <nckx>Warning: Unwind-only `stack-overflow' exception; skipping pre-unwind handler. <bdju>leoprikler: that worked, thanks. I also get 205 <roptat>civodul, the overdrive should be back online <roptat>I think it is, we merged it recently *nckx broke avahi somehow whee. <mbakke>nckx: 'core-updates' is open whenever it's not actively being merged :-) <sneek>Welcome back mbakke, you have 1 message. <leoprikler>nckx: wait, if you broke avahi, why did you push it to master? D: <nckx>leoprikler: Because I have a successfully built avahi graft (that I just spend 10 minutes staring at with objdump) that was dandy. <nckx>I still don't understand how using package/inherit could lead to failed patch hunks. <nckx>It applies the same patch twice, OK, so probably recurses (grafts) infinitely? <nckx>You dare accuse me of logic. <leoprikler>avahi/fixed requires avahi, but avahi becomes grafted to avahi/fixed <leoprikler>so avahi/fixed builds avahi/fixed builds avahi/fixed... <nckx>That's obvious, but I didn't get that from package/inherit. <nckx>So now I've just made a note to never use package/inherit instead of understanding it, which is a shame. <nckx>So package/inherit ‘applies’ the replacement that is merely ‘declared’ when using (package (inherit))? <nckx>I just don't understand my fix 😛 <nckx>It still uses (inherit avahi). That's fine. <leoprikler>Okay, I see it now: package/inherit is "[l]ike (package (inherit P) OVERRIDES ...), except that the same transformation is done to the package replacement, if any." <nckx>Mark's kindly explained it to me via mail. I made a note to add it to the documentation once I'm sure I really understand it. <nckx>I think what went wrong is that I read the word ‘replacement’ either too literally or not literally enough. <leoprikler>Not sure, but imo package/inherit is like asking for bugs. <leoprikler>I'm pretty sure this is not the only case when package/inherit breaks stuff <leoprikler>but admittedly, once you understand it, it is a very simple one <nckx>Yes & no. It's obvious to me now how it broke things. I can't exactly explain what about it confuses me so. <nckx>To me the existence of package/inherit implies that (replacement (package (inherit …))) can somehow, in some situations, be incomplete (and insecure). But that's just a feelin'. <nckx>But there's no need to spam #guix with my Personal Journey. <leoprikler>I don't think package/inherit is meant for replacements, aka grafts. <nckx>So much at least has become quite clear 🙂 <leoprikler>Looking at some of its uses, it's to add optional inputs and stuff, where it is pretty safe. <chrchr>Hi! New to guix and I'm trying to enable X11 forwarding in ssh. I've added (x11-forwarding? #t) to config.scm and did 'sudo guix system reconfigure /etc/config.scm' and still getting 'X11 forwarding request failed' on login. <chrchr>Is there something else I need to do to get changes to take effect? Like doI need to restart the sshd service? <leoprikler>shepherd *should* restart your services, but you could try "sudo herd restart sshd" and see if it works <chrchr>service 'sshd' could not be found <chrchr>Yeah. I just learned how to do 'herd status' and found it there. :) <chrchr>Hm. Well, when I was trying to figure out x forwarding I was trying to see the ssh-daemon log, so let's start with that one. <leoprikler>I'm not sure, what logs sshd produceds, but you should find them in /var/log <leoprikler>try /var/log/auth.log (though it will likely only contain authentication stuff) <chrchr>Ok so it's a fairly standard syslog setup. I thought for a minute that it was something like systemd's logging <chrchr>Ok. I'm not seeing sshd logs anywhere but that's probaby just configuration. Thank you for your help! <leoprikler>again, according to the resources I found it should log to /var/log/auth.log <nckx>Guix System has only /var/log/{messages,debug,secure} system logs. <nckx>I checked: what other distributions log in auth.log, Guix logs to messages. ***ChanServ sets mode: +o nckx
***nckx sets mode: -b Gamayun*!*@*
***nckx sets mode: -b jlouisgnusupport!*@*
***ChanServ sets mode: +b Gamayun*!*@*
***Gamayun_ was kicked by ChanServ (Banned: Fix your bouncer)
***nckx sets mode: -b jmarciano!*@*
***nckx sets mode: -b hio!*@*
***nckx sets mode: -b san4!*@*
***ChanServ sets mode: -o nckx
***ng0_ is now known as ng0
<civodul>nckx: auth.log looks like a good idea... <civodul>we should also add proper bindings for syslog configuration <hugo>Hi! Does guix support Nis and kerberos? I can't find anything about it <civodul>hugo: kerberos no, NIS i don't think so, but i think there have been experimentations <civodul>so we have the pleasure to watch the log <hugo>civodul: That's a shame... That more or less makes guix unusable for me :( <mbakke>hugo: depending on your use case, implementing may not be too difficult <refpga>Hello, I'm trying to set up cgit, and have the form (gnu services version-control) included in the use-modules form. Still I get the error ` cgit-service-type: unbound variable & hint: Did you forget a `use-modules' form?`. Is there any other module I need to load to use that variable? <civodul>refpga: "guix system search cgit" says it's in (gnu services cgit) <hugo>mbakke: I'm taking a look at it! <nckx>Now you're just showing off.