IRC channel logs

<vagrantc>so... how much space does /gnu/store "typically" take up over time ? obviously, this varies greatly by user, but what would be a reasonable amount to host a public mirror/proxy? would 450GB be useful? or just a waste of time?

<OriansJ>janneke: well you know I'd change M1 to make it better for you but if life is easier for you to output M2-Planet, that is also an option if you wish to do that

<OriansJ>or if you wanted to be kinda crazy, you could output slow_lisp or M2-Moon (when I am done with it of course)

<bms_>Hi.

<jpt4>Greetings, guixians.

<whereisiso>Hi. Where is the iso located for guixSD?

<jpt4>gnu.org/software/guix/download

<jpt4>GuixSD 0.13.0

<jpt4>The page also links to installation instructions.

<jpt4>If anyone has a moment, I have a question about creating custom initial ram disks.

<brendyn>whereisiso: there doesn't exist an iso atm, just an image

<whereisiso>brendyn: understood. Thank you much. looking forward to this gnu/linux free as in freedom distribution.

<jpt4>My apologies, whereisiso, for confusing the two.

<whereisiso>Not a problem!

<brendyn>whereisiso: People have spoken about creating one, but I think there are complications with it. I don't understand anything about ISO files so I can't commment.

<whereisiso>guix uses the libre kernel right?

<brendyn>yes. There is no nonfree stuff in the official Guix distro, although people have packaged and published nonfree stuff elsewhere like github

<jpt4>GuixSD supports full disk encryption; does it also support FDE with remote LUKS headers?

<jpt4>In Arch Linux, this is done by modifying the "encrypt" module loaded in the initramfs.

<jpt4>The "operating-system" declaration in a GuixSD system configuration has a field for "initrd", but I do not know where to put a modified encrypt module so that it is loaded in the correct order.

<jpt4>Actually, correct that.

<jpt4>"encrypt" is a script, a hook, run by the initramfs.

<civodul>Hello Guix!

***specing_ is now known as specing

<kmicu>( ^_^)／

<efraim>does mcron's vixie syntax accept @restart or @daily or other similar syntax options?

<brendyn>Has anyone got a good rule for figuring out which module to put a program in?

<kernasi>hi

<brendyn>hello

<brendyn>how do i view the logs from when my computer booted up?

<civodul>brendyn: /var/log/messages, or run "dmesg"

<brendyn>thanks

<brendyn>since a created my wifi network config in gnome, now that im in i3 it requires me to run polkit-gnome-authentication-agent-1 to edit that config, but not the one i created before i installed gnome. rather annoying

<brendyn>i swear im never touching gnome ever again

<civodul>oh

<brendyn>i think gnome is the reason my file managers are all borked and wont save their config after i change things too

<pksadiq>brendyn: what would gnome have to do with that?

<brendyn>im not sure i think gnome might have changed some settings somewhere when i had it installed

<brendyn>come to think of it, somehow i was using nautilus and thunar but they weren't even in my profile. that's somehow because of gnome

<brendyn>i think it has to do with dconf

<brendyn>I ran dconf -f /org/gnome/Thunar, and now thunar is not in my path, but also somehow tab completing directories isn't working in bash anymore. nothing makes sense anymore *cries*

<brendyn>ok nevermind the bash thing that was my fault

<pksadiq>brendyn: dconf/gsettings can sometimes be contained. Such that those configurations can only be seen from the corresponding application's running environment

<efraim>civodul: about my gtk error yesterday, it might be related that I didn't have a .config/user-dirs.dirs

<civodul>efraim: oh, is that a new thing?

<civodul>i don't remember seeing that before

<civodul>plop

<civodul>so, release soon!

<civodul>what do people think?

<jonsger>civodul: nice :) next week I could help testing :)

<civodul>cool

<civodul>rekado: still 1.4G resident at the end of the gnu/packages compilation with 4 threads :-/

<civodul>it would be less than that with fewer threads presumably

<mb[m]1>Somehow I can't reproduce the Guile2.0 Guix test hang when run interactively. It only seems to happen in the build container.

<mb[m]1>The problem is somewhere in guix-package.sh. Will try to add some debug statements and use --with-source.

<mb[m]1>Huh, "the transformation --with-source had no effect on guile2.0-guix". Why is that?

<mb[m]1>Tedious to bisect this if I have to update the snapshot guix for each round. Ideas?

<efraim>--with-source doesn't affect packages with patches or snippets

<bavier>mb[m]1: I've hit that hang in a normal environment

<efraim>Guix environment -C ?

<bavier>no no, standard shell, system guile 2.0

<bavier>I think it's hanging in the hints system somewhere

<bavier>tests/guix-package.sh:324, it prints the "unbound variable" message and doesn't proceed any further

<bavier>I could try bisecting, need to go afk for a bit

<mb[m]1>Derp, I ran `guix environment guix`, not guile2.0.

<rekado>civodul: I can test the new installer image on a couple of servers this week.

<clacke[m]>> --with-source doesn't affect packages with patches or snippet

<clacke[m]>ah, oops that was a recent answer, sorry

<clacke[m]>I was digging through the backlig because I know I had the same issue before and discussed it in the channel :-)

<mb[m]1>`make -j40` succeeded though, so I could probably switch back to 2.2 on this machine. But where's the fun in that.

<civodul>rekado: excellent

<civodul>mb[m]1: note that yesterday i committed something to max at 8 compilation threads

<civodul>otherwise heap usage could go crazy

<civodul>and you end up with something potentially slower

<mb[m]1>The hanging command is "guix package --bootstrap -n -m t-guix-package-.../manifest.scm". Last test in the file.

<mb[m]1>stderr seems to contain the expected output though.

<mb[m]1>So why does it not return.

<mb[m]1>Running the same command through strace reveals a loop, and SIGINT is ignored.

<mb[m]1>Bisect ahoy.

<civodul>a loop doing what?

<mb[m]1>I just saw a bunch of PIDs with FUTEX_WAIT_PRIVATE and FUTEX_WAKE_PRIVATE. Maybe I killed it too early, though. Bisecting now, roughly 7 steps to go.

<civodul>ok

<mb[m]1>Attached to a hanging test now and got the same result. The only other thing in the log is 'open("/proc/self/statm")' occasionally.

<civodul>yeah that's from libgc

<mb[m]1>Curiously strace prints "Process PID=123 runs in x32 mode" and a new line with "Process PID=123 runs in 64-bit mode" when attaching. Same PID.

<mb[m]1>5 steps to go.

<cehteh>btw: https://blog.fefe.de/?ts=a4ea83b6

<cehteh>anyone tried to reproduce that on guix? :)

<cehteh>ct@guixfarm ~$ strings $(which man) | grep gimme

<cehteh>gimme gimme gimme

<mb[m]1>And the winner is....drumroll.... a2985bb101 "ui: provide hints for unbound-variable errors".

<civodul>ooh :-)

<civodul>now you need to find out why :-)

<mb[m]1>D'oh.

<civodul>ACTION fiddles with multiple-derivation guix pull

<janneke>o/

<mfzap>hi all... having trouble on aws ec2 nano and micro instances - guix pull seems to lack the memory to complete, I get out of memory errors... they are 0.5GB and 1GB respectively. Adding a GB of swap didn't help (cancels for extended silence). How much RAM does guix pull need? Can I reduce the requirement to make it work on these usefully small instances? thanks!

<lfam>mfzap: It should work with 1 GB RAM and 1 GB swap but, as you noticed, using swap will take a very long time.

<lfam>You can set the options --timeout and --max-silent-time to a high number to avoid timeout cancellations

<mfzap>lfam - thanks

<lfam>I recommend setting it to something like 12 hours. It shouldn't take that long but since you are sharing the underlying disk while using EC2 micro instances, it could potentially take forever if EC2s I/O sharing mechanism penalizes you for some reason

<lfam>I use Guix on a micro EC2 and that's what I do

<lfam>We know that these memory requirements are really too high, but it's taking a while to find and fix or workaround the bugs that cause such high memory consumption

<mfzap>ya that's an wise observation, eventually engineering it to run under 1GB would be a nice goal

<lfam>It's probably worth using an SSD for this use case (I'm still using spinning disks on EC2)

<lfam>It used to require much less memory with the previous version of the Guile compiler, but some optimizations in the new version ended up being more RAM-expensive than expected

<mfzap>oh, those opts can't be turned off? maybe that's a trade-off that some people would choose

<lfam>There is a package 'guile2.0-guix'. I haven't tried using it but it sounds like a version of Guix that uses the previous version of Guile

<lfam>(We should clarify what it is in the package description!)

<mfzap>if I get through the initial guix pull, are subsequent pulls "easier" or they all run the same way? sometimes the initial update of a system is heavier

<lfam>Currently each pull recompiles all of Guix (Guix itself, not all the packages), if I understand correctly

<lfam>People are working to fix the issues in Guile, and we are also doing some workarounds in Guix in the meantime. But still we need >1 GB RAM to do `guix pull`

<lfam>It's unfortunate considering that there is lots of interesting hardware with only 1 GB RAM

<vagrantc>ouch

<lfam>I mean, swap works, it's just super slow for spinning disks (and slow for other storage devices)

<lfam>Too slow, really

<mfzap>thanks for the advice

<mb[m]1>It's a bit ironic that Guile 2.2 has problems on both low and high end hardware.

<buenouanq>the workingman"s guile

<bavier>out of curiosity, created a guile 2.0.9 package, but it fails a test: https://paste.debian.net/996932

<mfzap>just tried an aws ec2 small, and it does a guix pull very well. ec2 micro and nano are the ones that struggle. would be nice to get micro to work over time. nano would be awesome but that's 0.5GB ram.

<civodul>ACTION pushed multiple-derivation "guix pull" \\o/

<civodul>not perfect, but hopefully an improvement

<bavier>woo!

<mb[m]1>Yay! :)

<kmicu>ヽ(*＾▽＾)／

<civodul>longer-term it'd be interesting to see if we can get rid of the redundancy between makefiles and (guix self)

<bavier>have (guix self) parse the makefiles? :P

<civodul>bavier: not sure that's the right approach :-)

<bavier>civodul: just joking. what redundancy specifically?

<mb[m]1>I'm getting: "ERROR: Unbound variable: scheme-files" when trying to pull now (from an earlier Guix).

<civodul>conceptually, both (guix self) and the makefiles are build systems for GUix

<civodul>mb[m]1: uh