<shanemikel_>I just converted the raw image to vdi, because I was having a little trouble building a live iso <lfam>shanemike1_: Guix has tooling for building QEMU images built in <lfam>We actually use some of those tools to build the GuixSD installer image <paroneayea>I am giving a talk about how the retreat went for me <lfam>Steap: Do you think it will be accepted upstream? <lfam>And, how does it not work in Guix? Simply no effect? <paroneayea>shanemikel_: be sure you also introduce yourself to me before/after I speak! :) <Steap>lfam: well, I talked to a CPython dev I know at work, and he seems ok with such a patch <Steap>lfam: yeah, it does not change anything when appliedin our Guix recipe <Steap>but the Python package has become quite weird, so I might be missing something <lfam>Steap: Care to share the patch? I'm interested to see how you did it. And maybe I can try debugging it in Guix :) <lfam>Yes, the python packages are very complex. <lfam>I don't really understand them fully. Or at least, the understanding I gained a month ago has been washed away <davexunit>paroneayea: good luck with your talk tonight :) <str1ngs>Are the docs for guix master/tip served anywhere? <lfam>str1ngs: Not AFAIK :( You can build HTML with `make doc/guix.html` <str1ngs>that will work thanks. actually I should just diff the node <Steap>lfam: we bootstrap them from a minimal python, which makes things hard :D <str1ngs>hmm make html depends on gif generation but I dont know the make rule :( <lfam>str1ngs: It should "just work" if you are in a guix build environment. That is, in `guix environment guix` <lfam>Is it not working in that environment? <str1ngs>no I'm working on a s390x . I can build the docs locally though <str1ngs>I just want to make sure the porting pages has not changed <lfam>str1ngs: The online manual is only a few commits behind master right now. It should be relevant <str1ngs>I'm going to port guix first. then port the boot strap <str1ngs>I also have a power8 server I can work on aswell <lfam>shanemike1_: Yes, please <ziz15>guys about how long does it take for guix to finish install? <lfam>ziz15: It depends on your hardware, network speed, and how much you need to build from source. <str1ngs>cause if you dont it will take much longer :P <lfam>What installer are you using, ziz15? <lfam>Then, it depends on those ofter factors I mentioned a minute ago <ziz15>i install it inside a vm i gave it 4 cores and it has download packges now i see it compiles them <shanemikel_>oh, I don't know if it's relevant.. the failure mentions gnutls, but I skipped the optional guiletls requirement in the manual <lfam>shanemike1_: I would send the report anyways. It helps us find bugs. <lfam>If it's not relevant, we'll just say so and close the bug :) <lfam>I'm curious, what method are you using? Binary installation or from source? <lfam>Okay, I wasn't sure because it's also possible to do the binary installation and use that to bootstrap a source based installation. Just curious :) <lfam>The advantage is that you don't have to round up all the dependencies yourself. You install Guix from the binary and then use `guix environment guix` to provide the dependencies to build from source <bavier>shanemikel_: yes, send a bug, because the test should be guarded/skipped probably <lfam>shanemike1_: Are you referring to use of something like `apt-get`? You could provide the dependencies by building them from source as an un-privileged user. <lfam>For Guix, you still need root to start the daemon ***Basstard1 is now known as Basstard`
<lfam>Steap: Thanks, I'll try it out <ziz15>guys,for real...how much time does it takes about to install ?? i mean i have almost 3 hours already i keep it running..what does it do?? <ziz15>i mean eg when you install parabola it shows 200 mb to download and about a 40 min the install is finish and youre ready to configure the os <Jookia>ziz15: what's it doing right now? <jmarciano>well, it maybe builds packages from source.... <ziz15>Jookia: it compiles some packages from tcl 8.6.4 <ziz15>i have install so many distros over the years..this thing for me is... <jmarciano>I think that GuixSD is future of Internet, just like Debian back in time, when they made some good decisions. <ziz15>jmarciano: i also believe it have things to give thats why i want to try the os <jmarciano>Well, I did not always get binaries, so sometimes system started to build, compile the programs, unlike some popular distributions. <ziz15>it shows thread.test time.test etc <jmarciano>I understand that later I can pull packages from not-centralized place unlike with other distributions. <jmarciano>You could even have your own distribution and your own binaries done on VPS or maybe local server. <ziz15>str1ngs: you mean from 9 go to 10? <ziz15>str1ngs: or before install current image? <str1ngs>what stage of the install are you at? <str1ngs>if you do guild pull. it only builds guix and it generally will never have to build packages <str1ngs>it only builds packages for substitutions it cant find <str1ngs>IMO they should add that step to the install manual <ziz15>str1ngs: so now it even builds binaries? <ziz15>str1ngs: you kidding me right???please tell me so!!!!!!!!!!!!!!!!!!! <str1ngs>guix pull keeps things in sync and generally the substitution will exist on the mirror <ziz15>str1ngs: in my occasion what should i do let it be or stop?? i mean here is 3 am i need to sleep!! <Jookia>cancel it, run guix pull, try reinit <str1ngs>what command is it running? that is building alot. system init? <Jookia>fwiw it's not worth losing sleep over computers <str1ngs>guix pull should be added to the install manual IMO <str1ngs>if a package gets GC'd on the mirror you are using. it will build it. <str1ngs>better to build just guix then the world <ziz15>guys thank you all for your help..but i believe that with the things how are now im not gonna try another time to install that os <ziz15>i ll keep an eye on project and if i can help ill help but for now... <str1ngs>you can run guix inside your current distro <jmarciano>yes you can run guix totally independent of the existing system <ziz15>str1ngs: i ll think of it ;) <jmarciano>later, you can imagine... you define your own distribution in simple script, and it is always the same. <lfam>str1ngs: The MOTD of the installer recommends the user run `guix pull` <ziz15>jmarciano: i believe it ll take a while .. <lfam>Just saying, the reminder is printed directly in front of the eyes of the user as they start the installation. <lfam>But, it shouldn't be necessary yet since 0.10.0 just came out <str1ngs>fair enough, but if your like me you have the manual open as you are installing :) <lfam>I don't think it would make a big difference for the 0.10.0 installer <ziz15>i believe thats the price to try beta or things like that <ziz15>but we learn from our mistakes <lfam>jmarciano: It's actually a live operating system system <str1ngs>guix can install form existing distro :) <str1ngs>guix's making guix's its kinda perverted :( <jmarciano>I have run last version, came to console mode from USB stick. <lfam>You boot it from a USB flash drive (typically), mount your target storage device, and then it installs to the target. <lfam>Sometimes it takes a while to build some of the components from source. There's not much we can do about except try harder to make sure the binaries are available from the substitutes server <lfam>Right now we are having an issue where a small number of binary archives are corrupted. Users must use --fallback to get around that, and hopefully they will tell us about it so we can remove the corrupted archives. <str1ngs>is there a flag to not fallback ever? <lfam>To never build from source? <ziz15>str1ngs: you 're my hero!!!! <lfam>`guix build -h` doesn't mention one. I don't know why you would want that, however. If the substitutes aren't available, and you don't want to build, then you won't get anywhere. <lfam>I mean, by default, you don't fallback if the substituter errors out. But if the substituter says "not available", then you will build. <lfam>So, there is a difference between "no substitute available" and a <lfam>and "substitution failed" <ziz15>lfam: so the first things after start config.scm is guix pull and then guix system --fallback init /mnt/etc/config.scm /mnt <str1ngs>it might be better in some cases to not assume you want to build packages <lfam>str1ngs: If you did that, you just won't get the software in question. <str1ngs>it would be a way to blacklist builds. <lfam>ziz15: Yes, just wait for it to finish. <str1ngs>or alternative is a summary prompt flag? <str1ngs>downloading such and such, buidling such and such ... continue y/n ? <lfam>str1ngs: You could suggest it on guix-devel. I see your point although it goes against the spirit of the system, in my opinion. <ziz15>man i cant believe that for a command i wait 3 hours... <lfam>I wouldn't be the person who decides or implements it, so that's why I suggest mailing guix-devel. <lfam>ziz15: Some programs take a really long time to build. For example, libreoffice takes ~8 hours to build on my fastest machine. <str1ngs>me personally I would like to know if I'm going to be building a kernel or gcc <lfam>str1ngs: It prints out what it's going to do at the beginning <lfam>You can CTRL+C and read the list, and then decide if you want to continue. I do that often <ziz15>lfam: by default if i choose desktop.scm and configure it as i like eg remove gnome-desktop and keep only xfce how long you estimate it will last to complete the install?? <lfam>ziz15: What kind of CPU do you have? <str1ngs>I have to check the output of -n though <lfam>str1ngs: I just tried --dry-run (-n). It prints the summary and exits <lfam>Are you sure? It should print everything it's going to do <ziz15>lfam: i mean it only install xorg xfce slim and their deps right no icecat libreoffice etc.right?? <lfam>I don't know how long it will take. It really depends on whether the packages you need to build the system are already built and available, or if you have to build from source. <str1ngs>I could be wrong. I need to follow up on it. was just something I noted. <lfam>str1ngs: That doesn't seem right <lfam>That feature broke for a while when we had to use grafts. I wonder if it didn't come back fully after we removed the grafts <lfam>str1ngs: Can you give a reproducer? <lfam>Like, a git commit and a package to build from that commit? <str1ngs>let me see if I can produce it locally <str1ngs>sudo rm -rf /gnu/ /usr/local/var/guix/ dont run that at home haha <lfam>If you can reproduce it, you should send a report to bug-guix <str1ngs>I'll see what I can do. but its not easier to produce since its dependant on state <str1ngs>but I think with a fresh guix install I can produce it with the git package <lfam>The "easiest" way I can think of to debug things like this is to create a bare-bones vm-image, and do it in there. Keep a pristine copy of the vm-image around for when you need to start over <lfam>There's probably a better way but I don't know it <str1ngs>then all I have to do is stop the daemon <lfam>Oh, you have a separate store? <lfam>See, I would never purge /gnu <str1ngs>its intentional on my part. not advised for normal users <lfam>At least set up a caching mirror on your local network... <str1ngs>you can move the store but thats not advised either <str1ngs>I'm really only using it while I do some work on guix <lfam>But, I rely on my store, so deleting it would mean I would have to wait a long time to do anything while it is rebuilt. If I didn't rely on it, it would be less expensive to do your method <str1ngs>there is a guix docker image but... probably dated <lfam>That's good! Please report it if you see it again <str1ngs>actually if anything.. it installing alot. <lfam>You are starting from an empty store? <str1ngs>there is no way, bash need coretutils <str1ngs>glibc, ncurses, readline, libgcc atmost <lfam>Those packages are the base of the system. I think they are required before you can do anything. Hopefully somebody with more knowledge can chime in <str1ngs>but there not really required by bash. unless they are used by guix <lfam>You should explore the `guix gc --r*` commands. --references, --requisites, and --referrers <lfam>You can inspect the web of relationships of a given store item with those tools <lfam>I wonder if gzip is required to decompress substitutes. <Digit>fresh guixsd on aspireone 32bit, followed instructions from altf2, no wired connection success (and no wireless here). may try install from the already installed slack-based connochaetos or even from the fsf trisquel card. tmro tho. zzz now. :) ***Basstard1 is now known as Basstard`
<jololo>Hey! I'm having a problem installing 0.10. when downloading python it says the compressed file ends unexpectedly. What should I do? <shanemikel_>ok, what kind of config should I use with the `guix system vm-image` command? certainly the disks config isn't gonna work the same as templates/desktop.scm, is it? is there an example config for this? <jololo>shanemikel_, did you resolve it? <str1ngs>shanemikel_: use whatever config you would like <str1ngs>jololo: sounds like there is an issue with the mirror <str1ngs>hopefully that only builds the python package <str1ngs>shanemikel_: for qemu I might use base-system as a starting point though <rekado>when you add "--fallback" it will try to build the package locally on failures to download the binary substitute. <marusich>So, I've noticed that if you're running tor-service in GuixSD, IceCat can still browse to a .onion address (e.g., http://duskgytldkxiuqc6.onion/) when SOCKS5 proxy is enabled BUT remote DNS resolution is disabled. <marusich>Does anyone know why that works? I thought that remote DNS resolution, through the TOR network via the SOCKS5 proxy, would have been necessary for .onion addresses. <efraim>it's not necessary, but it's good practice to enable it <marusich>What I don't understand is how Icecat is resolving the .onion name <efraim>I don't remember exactly how it works, but IIRC remote dns is to prevent leaking information about you and your system <marusich>I'm familiar with that aspect of TOR; what I'm trying to figure out is why IceCat is able to resolve the .onion address even though remote DNS resolution is *DISABLED* <marusich>Not sure how to figure that out... It's just curiosity. I'd like to know where request are going. <marusich>efraim, turns out that icecat is caching results while it's active <marusich>I don't know why, but it seems that there's some kind of strange caching going on. Restarting it makes it detect the new settings and behave as expected. <rekado>marusich: I also found that icecat caches stuff (for a little too long), which (temporarily) made the development of a web server application in Guile really frustrating. <rekado>for development I switched to epiphany. <marusich>Interesting! I've seen similar problems with other software. <efraim>on my debian system there's no libpaper, but there is a libpaper1 <efraim>still looking for a copy on debian <ozzloy>(equal? (lambda (x) (1+ x)) (lambda (x) (1+ x))) ; => #f <shanemikel_>so guix downlaod does a hashcheck of the file, and compares it to some cache of everything? or did it associate the name of the file downloaded with the name of the package, and do a hash verification afterwards? <efraim>it has the hash of the file, and it compares that to the hash of the file you downloaded <shanemikel_>that's pretty amazing.. distro responsible for packaging/installation, all we need is the src package <efraim>they moved it to the archive section <efraim>uh oh, got a different hash from the debian archive <efraim>yes, but the debian one shouldn't have changed <shanemikel_>while guix is in this early stage, not hosting it's own source packages, it'd be nice if there was a really simple way for users/early adopters to post alternative package urls to an automated service <efraim>does changing the source url cause the package to be rebuilt? <civodul>if the 'file-name' field remains unchanged, nothing needs to be rebuilt <efraim>ok, so I'll update libpaper's uri and see if it wants to rebuild my system <efraim>also, we were getting it from debian, but they moved it to their archive and the hash changed somehow <shanemikel_>where should I read about the hashing mechanism? is it the same as nix? <str1ngs>it probably uses public keys for GNU stuff aswell <marusich>If you routinely want a different source for a package, or you need other customizations, you can create your own packages by copying the package definition from the guix repo and changing the appropriate lines. Just put your package definition in a guile module on the GUIX_PACKAGE_PATH, and it will be used. See Info node "(guix) Package Modules" for details. <marusich>Once you know how to do it, it's really quite pleasant and easy! <Jookia>civodul: qemu derivation stuff is to make the caller unaware of bootloader <Jookia>civodul: at lesat as a beginning <civodul>Jookia: could you reply in the email thread, because i'm afraid of getting lost otherwise :-) <civodul>ACTION starts going through his backlog <marusich>I need to log off - thank you for the very nice v0.10.0 release! It's awesome :) <civodul>thank you for your feedback marusich! ***Basstard1 is now known as Basstard`
<rekado>does this mean I can create a service "pam-limits-service" that extends the "pam-root-service-type" with a procedure adding "pam_limits.so"? <rekado>will this apply to *all* pam entries? <rekado>we have the "unix-pam-service" procedure which takes a name and then produces a pam entry. <civodul>just throw a pk in your procedure if in doub <civodul>or "guix system build" the thing and check its etc/pam.d <rekado>I find it a bit hard to wrap my head around the service stuff. And I seem to have to wrap my head around it repeatedly, because my head is so unflexible... :) <civodul>maybe it's a sign that things are unclear or complex (bah!) <rekado>nah, I think it's just unfamiliarity on my side. <rekado>ah, I think I understand better now: services are not "registered" anywhere, but they point to one another, all the way down to system-service-type. <rekado>it seemed like magic to me that the extension mechanism would work without some sort of register of services. <rekado>but it's right there in the "extend" field. <shanemikel_>I just tried to build vm-image .. built a lot of things, and I failed some tests after about an hour of compilation.. it's saying to grab tests/testsuite.log, but I don't know where to find it <rekado>I have a couple of R packages here that really only provide very large data files (the latest genomes for human, mouse, worm, and fly). Should I just keep them local or does it make sense to add them to Guix? <rekado>the mouse genome tarball is 593 MB. <rekado>or would it be okay to add them if we also mark them as not substitutable? <rekado>to spare hydra from building them <rekado>shanemikel_: are you running GuixSD already? Or is this using Guix on another distribution? <civodul>rekado: re services, you can check "guix system extension-graph", it might help figure out what's going on <civodul>rekado: we could add those packages are mark them as unsubstitutable, indeed <civodul>i would argue that genome data is not copyrightable, but you know... <shanemikel_>according to us gov, the dna itself isn't, but the mrna transcripts of it are <shanemikel_>that's like saying the data in your raid is free, but the parity blocks aren't <shanemikel_>or the java of your body is yours, but the jvm of your body is property of sun <shanemikel_>damn.. this guixsd installation sure takes a bit of time.. it really is the emacs of distros :) <rekado>civodul: the packages are under artistic 2.0 <rekado>I don't know about whether the actual genome codons are copyrighted :) <rekado>shanemikel_: what about it takes time? <rekado>shanemikel_: compilation takes time, but if you use substitutes compilation is not necessary. <rekado>we don't have substitutes for everything, and sometimes substitutes are unavailable because hydra is overloaded. <rekado>in that case I'd just try again. <rekado>it is okay to abort guix and retry. It's safe to do this. (Do not kill the daemon, though, as that's not safe.) <nckx>rekado: what's the Right Way to terminate the daemon then? <nckx>ACTION killalls guix-daemon all the time, but not when it's ‘working’. <ng0>ACTION packages guix on gentoo today just for fun <ng0>my #FIXME notes in it read like i won't be done with it afterwards.. FIXME: package shepperd for gentoo or get an shepperd-to-openrc import thing. FIXME: write openrc related files to be included in addition to systemd file in guix master . etc <ng0>not that there is any point in shpperd-to-openrc.. but maybe someone does it as a proof that it works. <ng0>doing guix on gentoo is funny. the default just stuffs guix into the guile/site/ locations <Jookia>GNU on windows 10 is going to be very interesting <ziz15>when install bare-bone config how many packages does it downloads ? <rekado>ziz15: which bare-bone config do you refer to? The one from the manual? <ziz15>rekado: i mean as a template <rekado>nckx: you may of course kill it when it's not doing anything. I just meant that to abort a guix build process one should not kill the daemon. <Jookia>To speculate it looks like Windows has implemented the Linux ABI on top of the NT kernel, meaning we could add Guix as a 'native' environment devel environment <rekado>nckx: instead of using killall you could use the systemd service unit file (if you are on a system using systemd). <rekado>nckx: or wrap it up in a non-systemd service. <rekado>nckx: but ultimately it's the same as sending SIGTERM to the daemon. <rekado>ziz15: I don't know how many packages it will download. <rekado>ziz15: do you think it downloads too many? <nckx>rekado: nope, just manually launched ./pre-inst-env from the git repo. But as long as there's no hidden danger in killing an idle daemon I'm reassured. <ziz15>rekado: i will soon figure it out i just try to install guixsd with bare-bone.config :) <ziz15>rekado: yesterday i try the desktop but after 4 hours i gave up <rekado>ziz15: back when I installed a bigger GuixSD system for the first time it took a long time to download substitutes from hydra. <rekado>as long as it's just downloading stuff it's all fine. <rekado>when it starts building something from source it's very likely going to take a lot longer. <nckx>ziz15: downloading alone took me 14 hours once. Those were the days. <rekado>hydra is, unfortunately, very very slow. <ziz15>rekado: i know it starts give me chills when i see it compiles :))) <rain1>it shouldn't take that long! <nckx>Now it's 1 hour of building packages truncated by the mirror... <rain1>you could give one of the mirrors a go, that might help a bit <rekado>we have the funds for a replacement, but there have been problems on the vendor's side to get the hardware set up. <rekado>once we have the new hardware in place things are going to get better. <ziz15>i believe at least for the basic setup of the os the packages needed should be all precompile so when someone who wants to try the os want have to wait for so long.. <Jookia>i feel like i've missed out on all the substitute drama but just compiling everything from source <efraim>rekado: edirect fails to build because the source changed, it also seems like there have been a few new releases <efraim>I was thinking of tossing the download on archive.org for the backup <rekado>efraim: I was thinking about dropping edirect completely. I don't like to play catch with the developers. <rekado>ziz15: they are precompiled. They are available as binary substitutes on hydra. <rekado>it's just that hydra is slow and busy. <ziz15>for me at least every time a try to install guixsd it compiles something <ziz15>now i waiting for the results <ziz15>man im about to cry !!! it just finish saying Installation finished. No error reported. <ziz15>thank you all for you pacience toward me 2 days now.really appreciate <civodul>rekado: Guix 0.10 uses mirror.hydra.gnu.org aka. mirror.guixsd.org by default <ziz15>rain1: thanks my friend !! :P <ziz15>now at last i ll see what this os is all about... <ziz15>one comment i believe what rain1 was said was right someone should put on the manual this two commands before begin installation guix pull and guix system --fallback init /mnt/etc/config.scm /mnt and the just wait to finish <Jookia>--fallback will compile things tho <ziz15>now that i do the above steps and install bare-bone config it only took about 30-40 min to finish the install <ziz15>Jookia: yes it will compile only if not find a precompile package to install or im wrong?? <ng0>regarding guix building from source: /var/empty should be equal for homedir as /dev/null , right? <rekado>ziz15: each time you ran "guix system init" it downloads a little bit more. Already downloaded packages are cached in /gnu/store. <rekado>ng0: I don't understand the question. Could you rephrase? <ng0>compiling guix from source. <ng0>the point where I create users for guix <ng0>I have to add parameters like homedir, does /var/empty (like recommended on the guix site) has an equal effect as /dev/null (gentoo default) ? <ziz15>now that i login when i want to uprade the installed packages (guix package -u) should i run guix pull before or no? <ng0>I ask about the difference between the null device and /var/empty because searching for the difference is not really productive <ziz15>rain1: now i m in cli mode id like to install eg. xfce if i give guix package -i xfce do i have then to modify anything inside /etc/config.scm or it will be modified automatically(desktop-services etc) <rain1>ziz15, xfce is a special case you gotta do this differently <rain1>you need to copy the stuff from /etc/configuration/desktop.scm into yoru config <rain1>so that it is able to start x and stuff like that <rain1>then as root guix system reconfigure <your-config.scm> <rain1>which will install XFCE and other things, then you can reboot <rain1>for anything else you can just guix package -i though <ng0>i'll just see if guix works with the gentoo default. <ng0>so bug #355355 is still not relevant for gentoo.. or too little people working on it.. which is almost equal. (version bump to guile-2 , guile-2 already being in the tree but their guile-2 (can) break your entire system (happened to me)) <ng0>the bug was opened in 2011 <ng0>meanwhile the overlay I am contributing to ocassionally has a perfectly working guile 2 <ziz15>i want to install iptables after i create the rules is there a specific service i need to enable with herd? <ng0>not sure if my answer applies <ng0>I was thinking of configuring iptables through the system file <ng0>at the moment you can't <ng0>there are system services which can be configured through your system.scm , like tor-service <ziz15>so i just create my rules save them into a file and make it an autostart script? <davexunit>yeah the service layer is the right place for this. <rain1>you might have to write a new service <ziz15>so how to setup a basic firewall? <davexunit>ziz15: no one has written a service for doing that yet <davexunit>but it can't be part of your declarative system config until there is a service for it <ziz15>davexunit: thats what i think so..right now im reading the manual about network services and so and i think that i should make it as an autostart script <davexunit>ziz15: what do you mean by "autostart script"? <ziz15>davexunit: i write my rules into a sh scipt and put it in /etc/rc.local <ziz15>davexunit: or something like that <davexunit>well, it may work, I don't know much about it, but it's very much not the way to do things in GuixSD <ziz15>davexunit: ?? man that os is die-hard !!! <davexunit>I imagine rc.local is an init system specific thing <iyzsong>yep, we can add a shepherd service to run '/etc/rc.local'. <ziz15>davexunit: then why not? i ll try to create a service <davexunit>that way it will compose with the rest of the services <davexunit>a good firewall service would allow for other services to extend it <davexunit>for example, a web server could extend the firewall service to open up port 80 or 443 <ng0>a very good firewall service could allow the tor service to redirect tor traffic <ziz15>davexunit: i know...back to 'school' back to reading :P <davexunit>for getting something done quickly, sure go ahead and hack as needed, but I just want to make it clear what the "right way" is to do things in GuixSD. <ng0>ACTION gets extra bonus points for adding 19 guixbuilder users >.< <davexunit>consider this an invitation for someone to create an extensible firewall service to guix. <ziz15>davexunit: Guixsd quote: "the right way is the hard way" :P <rain1>Anyone want to compile the linux kernel to help the test reproducible build patch? <davexunit>ng0: can that tor thing be achieved with an iptables rule? <ng0>let me come up with the link for that <ng0>depends on how you want to run tor. tor-dns is one method. <rain1>" An Isolating Proxy requires at least two machines. Those machines can be either virtual machines or two physically isolated machines. Both machines are connected through an isolated LAN. One machine is called Gateway. The other one is called Workstation." <rain1>could do that with guix environments? <ng0>in the current state it is unlikely <ng0>if you can fix that, it's one more step towards Guix'ish Tails <TMA-1>Hi all, just about to try installing guix on a spare x200s I have :-) <Jookia>rain1: i think using nftables/iptables to isolate connections is good enough <efraim>gst-plugins-base on arm failed the orc related tests, on mips orc failed to build <efraim>time to see about removing orc as an input on those two arches <ng0>so i wonder if my problem is that files sit in their default gentoo location, but I have a /gnu/store/ dir. the guix command is available to all system users (personal, root) ,all buildusers are in the group guixbuild, i have not copied the /per-user/root/guix-profile to ~root/.guix-profile and I get a message about no users being in buixbuild group. <ng0>could be an error of no .guix-profile in root? <ng0>sure this is inofficial and not supported, but i am currious if someone might know the solution. otherwise I deal with this over a period of time :) ***tschwing_ is now known as tschwinge
<ng0>sidequestion: openrc init files of gentoo are gpl2 (at least the vim template files and the ones included by default in packages shipped with portage), can this be included in master of guix? ***nckx is now known as nckx|offline
<bavier>I just read a very poorly researched and misleading "viewpoint" article in the Communications of the ACM about GNU/Linux history <chewieQC>Do I have to reinstall guix to upgrade on a foreign distro? <chewieQC>davexunit: I tried guix package -u guix and guix pull <davexunit>chewieQC: 'guix pull' is correct, it will pull the latest version from master <rain1>chewieQC, I think there's a bug that menas 0.10 doesn't show up in --version <ng0>guix (GNU Guix) 0.10.0 <chewieQC>Still at 0.9.0, but if I do guix edit guix I can see in the editor that the version should be 0.10.0-0. <ziz15>why the os have so many users??(guixbuilder1,2,..) <rain1>chewieQC, yeah it's the bug mentioned yesterday <davexunit>chewieQC: 'guix edit guix' has nothing to do with this <rain1>it just isn't displaying the new version <rain1>but I think we really are on .10 <chewieQC>Does it mean the deamon only is stuck on an older version? <rain1>~/.config/guix/latest/guix/config.scm doesn't exist <rain1>~/.config/guix/latest/guix/config.scm.in does <rain1>maybe this is related to why it's still displaying 0.10? <davexunit>I symlink .config/guix/latest to my git checkout of guix <chewieQC>Also I can search for packages added in 0.10 now (ex: blender) <ng0>well.. almost. :/ at least i managed to get some downloads <ng0>maybe "error: build failed: the build users group `guixbuild' has no members" is its way to say connection interrupted. I can't guix pull as normal user either. might be a problem with where gentoo stuffs guix files <rain1>is there something like add- <rain1>I don't want to go all the way pure, just remove one thing <davexunit>if you need custom package transformations, you should write Scheme to create them. <rain1>oh actually pure doesn't even help <rain1>I have a custom qemu package that I made <ng0>can i build guix to be more verbose? <kas2207>Out of curiosity, is the current guix package management and guixSD able to be version controlled? Just thinking it would be cool to take a snapshot of my current configuration and load it onto another computer. <davexunit>kas2207: this is why we describe system configurations in text files. <kas2207>davexunit: that is awesome!! Do you mind sharing your repo? <ng0>ohh. guix-daemon must run as root:root , right? <ng0>is this assumed as default by systemd? <rain1>the c library installed ok but there's also python bindings, not sure how to do that <rain1>I don't know how python works <anthk_>an "extensible" firewall for Guix... so a layer written in Scheme as an interface for iptables, kinda like ufw? <davexunit>anthk_: yeah, pretty much. we already have a number of services like this. <davexunit>services that extend other services, that is. <anthk_>davexunit: nice. I guess Scheme is really suited to create a dynamic firewall <davexunit>I'm talking about using the service API to generate a configuration file for iptables <optikalmouse>scheme as configuration tool, an alternative to ansible/chef/puppet <chewieQC>Do you know which package have a translated description? I'd like to study how it is done <ng0>gentoo: /usr/bin/guix-daemon --build-users-group=guixbuild guixsd: /storepath/bin/guix-daemon --build-users-group guixbuild <ng0>notice the difference? <davexunit>optikalmouse: the system configuration interface replaces those imperative tools <davexunit>and I am (very slowly) working on a tool to use that interface to manage clusters of remote machines <davexunit>NixOps has some problems that I hope to avoid with 'guix deploy' <davexunit>the most important of which being the state file that NixOps requires. <lfam>rain1: Deterministic kernel builds :) <lfam>rain1: Have you played with 'diffoscope' yet? It's a very nice tool for exploring these issues <rain1>lfam, I tried to install it but no guix package :) <rain1>it slooks cool I might install debian to try it out <lfam>rain1: There is a Guix package! <lfam>I sent some preliminary feedback on your patch while I build the kernel over and over again <civodul>lfam: ooh, you're working on deterministic kernel builds? <lfam>civodul: rain1 is working on it, and I'm testing and giving a bit of advice <ng0>does the format the error message outputs matter? why does it say `guixbuild' and not 'guixbuild' in the error message? <jmd>How is the "container" feature going? <ng0>i think gentoo broke guix. it does work, but essential features do not, which is why i need to rewrite the package to get installed in the guix standard way (binary) / layout. <rain1>guix/build/gnu-build-system.scm: (setenv "SOURCE_DATE_EPOCH" "1") <bavier>I was just going to paste that link <rain1>grep -r SOURCE_DATE_EPOCH --include='*scm' <rain1>i searched for it inside guix but I can't see any uses of it <rain1>I don't really understand what it's about or what to do <rain1>we use gnu build system, and it sets this var - so maybe it's not needed? <bavier>rain1: it's for any packages that support the use of SOURCE_DATE_EPOCH <rain1>Should I write (setenv "KBUILD_BUILD_TIMESTAMP" (getenv "SOURCE_DATE_EPOCH")) <bavier>that should work, the source-date-epoch phase is run early <bavier>rain1: I think there are other packages that explicitly use the timestamp of the release tarball <bavier>makes upgrades a bit more involved though, so I don't know if that's the best solution. <bandrami>Installing Guix SD 0.10.0 now. I’m noticing I have to regularly restart the ‘guix system init $CONFFILE $MOUNTPATH” command a lot, every time there’s a network timeout or sig mismatch or something. If nobody’s working on that I’ll see what I can do. <jmd>I wonder if the guix project could maintain and publish a list of which packages appear to be reproducible and which do not. <handsome_pirate>So, now that I have guix building under Fedora, I'll be submitting a review request shortly <davexunit>handsome_pirate: that's really great to hear! I'm sorry that we didn't get a chance to catch up before the end of LibrePlanet. <davexunit>having a Fedora package for Guix is really exciting. <handsome_pirate>davexunit: So, before I submit an actual review request, what all should I be setting up beyond just building? <davexunit>handsome_pirate: I guess it depends on how far Fedora packages go in setting up state with post-install hooks and things. <davexunit>but for guix to be usable, the daemon needs to be running, which requires some users and a group to be created <davexunit>future steps could include packaging optional dependencies for Guix, like guile-json and guile-charting, that enable non-essential features. <davexunit>I think the only other one that will work is MIPS <davexunit>we don't have ports to powerpc or other architectures <davexunit>handsome_pirate: are you using the 0.10.0 release tarball? was released yesterday. ***Basstard1 is now known as Basstard`
<ng0>on failing guix: i think after 8 hours I made progress but I refuse to follow building from source on gentoo today any longer. I'll just try and package the binary version first <handsome_pirate>davexunit: As a note, network access is not allowed from within the Fedora build environment <davexunit>but guix wants to download the bootstrap tarballs <bavier>could those tarballs be made into their own fedora packages? <ng0>gentoo without any specific instructions for econf and emake throws guix (from source) all over the place, it works, but the builder users never get recognized. <davexunit>this would be a great question for guix-devel <handsome_pirate>bavier: Well, bootstrap binaries are sort of allowed to do an initial build of a package <davexunit>bavier: our own guix package doesn't need network access <bavier>davexunit: I think we intern the bootstrap binaries into the store <davexunit>ah, we have separate packages for the bootstrap Guile for each platform <bavier>so that the guix package build has access to them <davexunit>bavier: but those aren't inputs to the 'guix' package <davexunit>I believe it's the bootstrap guile that is problematic <davexunit>the copy-bootstrap-guile phase copies the bootstrap guile binaries (which are separate packages here) into the correct places <davexunit>gnu/packages/bootstrap/$ARCH-linux/guile-$BOOT-GUILE_VERSION.tar.xz <davexunit>these are the binaries that are taken for granted so the rest of the system may be reproducible. <bavier>they *can* be built without guix, via guix's makefiles, but I don <bavier>'t think their reproducibility is guaranteed <ng0>if i get this done for gentoo, I wonder if I try to shake up the portage project about guile-2, or if I just am done with contribution it to the overlay. <davexunit>so if the bootstrap binaries vary by any number of bits, *every package build* in guix will have a different hash than what all other guix users will have. <davexunit>thus, Fedora users will build everything from source all the time, since we won't have substitutes for them. <davexunit>this has grown into a bigger discussion into reproducible builds than I had hoped. <davexunit>Fedora surely has bootstrap tools, too. all distros do. <handsome_pirate>Packaging guidelines aren't going to allow me to grab someone's binaries for every build <davexunit>so the question is: can Fedora accept that Guix bootstraps with a fixed set of tools? <davexunit>right, so it appears that Guix and Fedora are incompatible. <davexunit>the issue here is that Guix is a distro, that does its own bootstrapping process. <davexunit>this discussion has come up before about getting Guix into Debian, and the conclusion I have come to but can't yet convince everyone of is that we can *never* hope to have a Guix package in Debian proper. <davexunit>we should distribute unofficial packages ourselves <davexunit>that use our bootstrap binaries, because they are essential and must not be even a single bit different from what other Guix users use without suffering severe practical consequences. <handsome_pirate>So, that would get you an official unofficial build with part of Fedora's build system. <davexunit>the issue is less about the network and more about binaries taken for granted, though, right? if we just shoved those binaries in the Guix repo, the same issue would be present. <davexunit>handsome_pirate: okay, maybe that's the best thing. <davexunit>a discussion should probably happen on guix-devel about this. I'd be happy to have *anything* that Fedora users could install. <davexunit>the problem with Fedora accepting a Guix package is the same problem that we have accepting self-hosting compilers. <davexunit>bootstrapping requires taking binaries for granted that aren't in your blessed set of bootstrap binaries. <davexunit>the conflict occurs because Guix has its own "initial build and initial build only" binaries <davexunit>and they *cannot* be changed without affecting the rest of the system. <handsome_pirate>See, if I can build those inital build binaries in Fedora and then subsequently use them, then we're good <davexunit>in that every Guix build will have a different identity because of such a change <davexunit>handsome_pirate: you can build them, but you'd have to *ensure* somehow that they are bit-identical to the ones we provide. <davexunit>but bit-reproducible builds are, as you know, an unsolved problem currently. <handsome_pirate>davexunit: The issue I could see is linking against, say, different glibc <str1ngs>also no distro is going to take kindly to linking against a third party glibc <str1ngs>sorry redundant missed the last message :( <handsome_pirate>davexunit: do you happen to know if there's a way to tell it to not install the upstart config? <paroneayea>handsome_pirate: chris webber here. Welcome to #mediagoblin! <paroneayea>(I'm used to inviting people to a different channel oops) <rain1>If anyone wants to test for the reproducible kernel - 5407vh3mpb69lnkd0ajx0xly6gd77gs1 is the hash I'm getting <rain1>mark_weaver, btw I tried using a different email program - would be curious to know if this fixes that UTF-8 thing <rain1>if not I should learn to use mutt <mark_weaver>rain1: it didn't help. the relevant header is Content-Type. It should include something like 'charset=utf-8' <mark_weaver>I guess it would be fine to use a different charset also, as long as the copyright symbol exists in that charset and is properly encoded for it. <rain1>I specially set transfer encoding to UTF-8, I'll learn to use mutt <rain1>(that was with claws from guix packages) <mark_weaver>rain1: in your second email, the Content-Type of the attachment is application/octet-stream, which might be part of the problem. <mark_weaver>I guess that means "binary", hence no encoding at all <mark_weaver>in your first email, the Content-Type was text/x-diff, which was better, but it just lacked the 'charset' field. <rain1>oh no.. my build --check just finished with /gnu/store/n20i0s96p29vkl07vlvxli5xql3m3hgi-linux-libre-4.5 <rain1>that's a different hash, but it didn't complain? <mark_weaver>rain1: removing the user and hostname environment variables would change the output compared with your original patch, but it's still deterministic. <rain1>alright, hopefully we can confirm it across computers <mark_weaver>the user, as set by the build daemon, is nixbld, and the hostname is the empty string <mark_weaver>also, the timestamp will be different with the new patch version <mark_weaver>I don't know off-hand what we set SOURCE_DATE_EPOCH to <rain1>but I did that since it was suggested <civodul>all build systems set SOURCE_DATE_EPOCH now AFAIK <civodul>so you shouldn't have to set it explicitly for one package <suitsmeveryfine>Hi! I'd like to try to get the Macbook2,1 touchpad working again but could need a little bit of help. <suitsmeveryfine>I experienced the same problem in Parabola and found a way to fix it there (permanently), but GuixSD is very different. <mark_weaver>civodul: the linux-libre build system doesn't seem to honor SOURCE_DATE_EPOCH, but honors KBUILD_BUILD_TIMESTAMP instead <mark_weaver>so we now copy SOURCE_DATE_EPOCH into KBUILD_BUILD_TIMESTAMP <suitsmeveryfine>The Parabola solution was to simply copy "/usr/share/X11/xorg.conf.d/50-synaptics.conf" to "/etc/X11/xorg.conf.d/". How could that be achieved in GuixSD? <rain1>suitsmeveryfine, I think one way might be to copy the /etc/hosts shepherd service <rain1>I haven't done this myself so there might be challenges doing that i'm not aware of <rain1>I mean make a copy of it and repurpose it to do the xorg config file setup, instead of a /etc/hosts file setup <rain1>it's just an idea that I wanted to suggest <suitsmeveryfine>I can't see why etc/hosts has anything to do with the init system though. Did you really mean the hosts file= <mark_weaver>suitsmeveryfine: if you're running 'guix' from a git checkout, then the easy way is to add the relevant bits into the strings in 'xorg-configuration-file' in gnu/services/xorg.scm <mark_weaver>and maybe that's how we'll want to fix it anyway, if we can find something that would work for you without breaking anyone else <mark_weaver>there's another way to do it, but it's kind of a pain <mark_weaver>of course, really the xorg-server should be fixed to handle this automatically. <suitsmeveryfine>mark_weaver: cool! I'll try that. I'm mainly doing this for the project because the computer runs very fine on Parabola currently. <mark_weaver>the goal nowadays is to not need to play with Xorg configuration files to have things "just work" <suitsmeveryfine>yes, but I'd like to make a contribution so that the MacBook2,1 machine "just works". <mark_weaver>especially given that you are not even using GuixSD, it's great that you are still trying to help us :) <suitsmeveryfine>It was a good experience to install Parabola, because I experienced basically the same issues as with GuixSD, except it was easy to find solutions on the arch wiki. <suitsmeveryfine>mark_weaver: I'm sitting with GuixSD right now on my desktop computer :) <suitsmeveryfine>I really like GuixSD, but I must say that systemd is very convenient. <mark_weaver>and anyway, we want to support GNU Hurd, whereas the systemd developers are unabashedly uninterested in support any kernel other than Linux. <mark_weaver>much of the benefit of Guix, we think, comes from using a general purpose language (Scheme) in many different areas, where other projects (e.g. Nix) tend to use multiple special-purpose, inflexible, languages for different things. <suitsmeveryfine>I'm takling about the chromebook computer that's supported by libreboot <mark_weaver>there are just two complications with GuixSD on the C201. One is that at present, we assume GRUB, and GRUB-on-arm seems to only work on u-boot systems, and the C201 doesn't use u-boot. <mark_weaver>and the other thing is that maybe the limited storage on the C201 would make it a bit tight to run GuixSD on. <mark_weaver>yeah, I don't know how much of a problem it would be in practice. <suitsmeveryfine>Regarding u-boot: the depthcharge payload can be modified to chainload u-boot <str1ngs>rain1: is there a doc for kernel building? <mark_weaver>anyway, at this time I don't feel I can make a commitment to port GuixSD to it in the short term. <suitsmeveryfine>mark_weaver: there are instructions for how this can be done on older chromebooks, but not on the c201. I'm not skilled enough to do it myself. <mark_weaver>I guess if someone from Parabola is ready to jump on this, maybe it should go to them. <str1ngs>If I had chromebook I would look at it :) <str1ngs>I think guix is good candidate for chrome books. does HOME allow for exec :) <mark_weaver>the other thing is that the wifi needs a nonfree blob, and the GPU needs a nonfree driver, which makes the machine less interesting to me. <mark_weaver>I was close to jumping on that bandwagon, but then had second thoughts. <suitsmeveryfine>mark_weaver: that's true. It does work well with a USB dongle though <optikalmouse>same, that's why I'm looking at the thinkpads the older ones, X200? T-something or other, I think they're all free now? <mark_weaver>suitsmeveryfine: well, we could add a custom kernel with additional patches on top of linux-libre, like I did for the Lemote Yeeloong 8101B <str1ngs>optikalmouse: I have a x220 its awesome <davexunit>str1ngs: I use an x220 with a freedom friendly wifi chip <str1ngs>how are are those to get and installl? <davexunit>at the time, it required flashing a hacked proprietary BIOS <petter>wifi affects our bodies in bad ways though, use wired network <str1ngs>optikalmouse: yes, but dongles are a pain <davexunit>but now I hear that you can use coreboot instead <mark_weaver>str1ngs: and it has a processor embedded in the chipset that's running a complete proprietary operating system with independent network access, direct access to all your RAM, and designed for remote supervisor access. <str1ngs>but the notebook is greal linux machine for the price <davexunit>not libreboot, unfortunately, because of what mark_weaver notes. <mark_weaver>if that doesn't send a chill up your spine, you haven't learned enough about it yet :) <davexunit>I'm hesistant to buy anything from allwinner <mark_weaver>str1ngs: it's not paranoid, this is undisputed fact. it's a documented "feature" <optikalmouse>what's the min. memory I can get away with for running guixsd? is a 10gb hard drive big enough or? <str1ngs>what are the specs on the allwinner A20? <fhmgufs>The development of the Raspberry Pi is great - they even have contracts with Broadcom for special chips. I don't understand why they don't use their power to enforce Broadcom to free these old firmware files. <fhmgufs>If that would be possible this Board would be so good :( <str1ngs>so who was giving away a chrome book?? :P <mark_weaver>rain1: you might want to run: guix config user.name "YOUR REAL NAME" <mark_weaver>str1ngs: have you made any contributions to Guix yet? <rain1>mark_weaver, is it ok to stick with how I have it? That's my default set up <mark_weaver>str1ngs: or demonstrated an ability to do the necessary tasks here? <rain1>Well I should set it different for guix <mark_weaver>normally I wouldn't ask such questions, but if you're trying to get a free computer to do a job, and deprive Parabola of one, it might be good to know whether there's reason to have confidence that you can and will do that job. <str1ngs>I've only been using guix less then a week. I'm not setup to contribute code yet. But I have stuff on my TODO <str1ngs>right now my giving back is purely IRC support :) <mark_weaver>str1ngs: okay, I don't think you're yet in the position to promise to port GuixSD to a new architecture and machine, then. <str1ngs>I'm talking notes for the LD_PRELOAD idea <suitsmeveryfine>Actually, I'd be happy to work on the machine myself, but the trouble is that so few people have one so it's hard to get help. <str1ngs>I'm in the middle of porting it to s390x and powerpc64le <petter>fhmgufs: that wireless radiation (wifi etc.) has bad effects on our bodies. <fhmgufs>petter: Yes, I know, but are there some new studies or sth like that? <fhmgufs>I'm currently not able to see videos (compiling) <suitsmeveryfine>mark_weaver: I rebooted and lost what you said above above what file to edit for xorg. Do you mind repeating? <fhmgufs>petter: But I think that there's so much radiation already that (if you aren't using mobile phones constantly) it can't be worse by your fault. <petter>fhmgufs: exactly how this affects our bodies is pretty new to us civilians, the military has studied it for 30-40 years <mark_weaver>suitsmeveryfine: if you're running 'guix' from a git checkout, then the easy way is to add the relevant bits into the strings in 'xorg-configuration-file' in gnu/services/xorg.scm <petter>fhmgufs: distance is very important when it comes to sources of radiation. <mark_weaver>it's terrible that we're forced to use microwaves for this stuff. we only use it because the rest of the useful spectrum has been allocated for other things, and microwaves were not of much interest because they're absorbed by water <mark_weaver>suitsmeveryfine: the contents of that 50-synaptics.conf file <fhmgufs>petter: Interesting, because I have seen a study on plants that happen to grow in a extrem way near wifi senders because of the higher temperature. And I already thought that this is bad for humans, too. (danger of cancer etc.). <fhmgufs>But didn't see a study on it. I'll look the video later. <mark_weaver>basically, we had to use whatever dregs of the spectrum were left over after the commercial interests locked up all the best areas of the spectrum <fhmgufs>But there are a lot of things the industry is doing to us for profit. <petter>fhmgufs: yes, i've seen studies with plants as well. It's very obvious that radiation has an important effect on them. <mark_weaver>and those dregs happen to be in a range that is efficiently absorbed by water, e.g. by *us*, and thus quite possibly dangerous to us <petter>mark_weaver: it's known to affect us in bad ways, and it's pretty well understood as well now <davexunit>handsome_pirate: I guess all we need to do is probe them to update to 0.10.0 <davexunit>handsome_pirate: sorry if you feel like your work has been wasted effort. I didn't know that this even existed. <petter>there's no doubt that we're not hearing the full story from politicians and media <handsome_pirate>davexunit: Fedora's builds are, theoretically, reproducable. I just do not believe that there are currently tests in place to check that, though that is one of my current projects. <davexunit>handsome_pirate: all distros that I know of use chroots, so I didn't mean to suggest that Fedora doesn't do this. <davexunit>but a chroot alone isn't enough. I don't know what else Fedora does, but Guix uses Linux namespaces to isolate further, and *only* allows access to explicitly defined input dependencies. <davexunit>so it goes further than I've seen any other distro go. <davexunit>(besides Nix, though Guix is even a bit more rigorous) <davexunit>but both Debian and Fedora are working on reproducible builds, too. <davexunit>so I also don't want to suggest that they won't achieve reproducibility. <rekado>hmm, writing services is still difficult to me :( I get the general idea but the services we have are all so very different that it's hard for me to see how this all works together. <rekado>(I don't mean shepherd services) <ng0>heh. might be that getting the binary version into gentoo is more pain than to build from source. gentoo runs tons of QA correction scripts on binaries. <civodul>rekado: what service are you working on? <rekado>civodul: just a simple service to add pam_limits.so <rekado>I'm now writing a service to create and populate /etc/security <rekado>because limits.conf sits in /etc/security <rekado>but there might be other files in that directory, so I need a service for that dir. <rekado>I also have "pam-limits-service-type" which extends "pam-root-service-type" (that part is easy) <rekado>it will also have to extend the new etc-security-service-type, I guess <davexunit>handsome_pirate: you can 'guix pull' to compile a new guix for your user <rekado>civodul: I also have "pam-limits-service", which is just "(service pam-limits-service-type config-file)" <davexunit>handsome_pirate: yeah, I hear ya. just 'guix pull' so that you can actually install stuff without having to build it all from source. <davexunit>handsome_pirate: no, just for the root user. <davexunit>each user may use a different version of the guix client <rekado>and I suppose that config-file would be passed to the extension of "etc-security-service-type"; but I'm not sure about this. <davexunit>on my systems, I have the system-wide Guix, and then my bleeding edge development version that I use pretty much exclusively. <rekado>civodul: I have a feeling that I'm doing too much; that this can probably be achieved with less effort. <rekado>took me a while to get to this point as I'm searching through the existing services for guidance. <handsome_pirate>davexunit: might not be a bad idea to do guix pull as root updates system-wide ... <civodul>rekado: i think this should be a single service that (1) extends pam-root-service-type with a procedure that adds pam_limits.so where appropriate, (2) extends etc-service-type with a "security" entry for /etc <civodul>when you're done, we'll have to work on this API based on your feedback <rekado>not sure about 2: not only do I need the "/etc/security" directory but also at least an empty "/etc/security/limits.conf" by default. <rekado>I'm looking at "file-union" right now, which contains a gexp to create a directory and symlink files <rekado>I suppose I could have a computed-file expression for "limits.conf" nested inside of a computed-file expression for "/etc/security" <civodul>i suggest doing only (1), and when that works starting with (2) ;-) <civodul>but yeah, you need a 'computed-file' that creates 'security' with an limits.conf inside <rekado>I think I'm done with (1) already, but this would crash PAM as the config file must exist (even if it is empty) <civodul>like (computed-file "security" #~(begin (mkdir #$output) (call-with-output-file (string-append #$output "/limits.conf") ...))) <rekado>I guess I'm primarily confused about argument passing. <rekado>by the time I have found the code that illuminates how the plumbing works I forgot what I wanted to do... <rekado>it's just a tad too dense for my tired brain :) <rekado>civodul: thanks for confirming my approach <davexunit>seems to be just one big bash script right now <davexunit>I could use a bug tracker for my personal projects <rekado>davexunit: bugs are stored along with the git repository. <davexunit>rekado: that's nice and simple, I could dig that. <rekado>it creates a separate directory for its state, so you could break that out into a subtree. <civodul>yeah at one point distributed bug databases became the "hot" thing and there were several such projects