IRC channel logs

<lukas__>nice call bavier` ! I didn't have to rebuild them :)\\

<bavier`>lukas__: \\o/

<lukas__>now all I have to do is push some patches and rebase nala's branch to guile3's branch

<bavier`>lukas__: thanks for working on it!

<jumblemuddle>Is it possible to use guixsd as dom0 xen hypervisor? I don't see xen in the packages.

<lfam>jumblemuddle: I don't know if anyone has tried it yet. We don't have a Xen package

<jumblemuddle>lfam: Ok, thanks. Perhaps a project for the future, but I'm not wanting to blaze any trails at the moment.

<jumblemuddle>Thanks

<zacts>hi #guix

<rekado>Hi Guix!

<cbaines>Morning :)

<efraim>Hello!

<niebie>xb

<civodul>Hello Guix!

<jonsger>hello civodul :)

<fredmanglis>Hi. Quick question, is one supposed to run guix pull` as root?

<civodul>fredmanglis: yes, 'guix pull' is per-user

<civodul>so if you use guix as root, you also need to run 'guix pull' as root

<civodul>if you use guix as "fred", you also need to run it as "fred"

<fredmanglis>Oh, okay.

<fredmanglis>The daemon is run as root though, right? Could the version mismatch between the daemon, and my user's version of guix be causing the failure in 'guix package --install/--update..." and 'guix pull'

<fredmanglis>I've never run `guix pull` as root, since install: `guix --version` as root gives "guix (GNU Guix) 0.11.0" while as frederick I get "guix (GNU Guix) 66660960ba75233ae5b6c539f43d97d06d64e9ad"

<efraim>In that case I would suggest 'sudo -E guix pull' so you can use "Fred's" guix binary for guix pull and not need to upgrade Root's guix version incrementally

<fredmanglis>efraim: Thanks. That did not work though, "Fred's" guix is broken, and will not install/update or pull anything...

<fredmanglis>I'm trying to repair it, but if my run as root fails, I'm nuking the install and starting over.

<civodul>fredmanglis: what failure do you get exactly?

<civodul>i think i missed that part

<elc79>hi guys, i finally upgrade my GuixSD system ^^

<elc79>i have a question, icecat have his binaries in the repos?

<ng0>you can check if something would be build locally with guix package -n -i icecat as an example for --dry-run --install icecat

<elpogo>when i do a "guix pull", i get a "Cannot allocate memory" error. how much memory does guix need? i'm running in a google cloud vm with 512MB of ram

<elpogo>In unknown file:

<elpogo> 0 (open-process "r" "git" "ls-files")

<elpogo>ERROR: In procedure open-process:

<rekado>512MB is not enough

<elpogo>ERROR: In procedure open-process: Cannot allocate memory

<rekado>there’s a bug in Guile 2.2.2 that makes it consume way too much memory

<rekado>in my experience the minimum appears to be 2G

<rekado>we’re working on fixing this bug, but it’s difficult.

<elpogo>ok. i don't really want to pay for more ram right now, so i'll wait for the fix

<elpogo>(i'm using the free tier instance to play with guix and get more comfortable with it)

<elpogo>do you have a rough ETA? is it days, weeks or months?

<elpogo>(asking so i can schedule a reminder for when i should try again)

<rekado>hard to say

<rekado>it would require a fix in Guile, not in Guix

<rekado>there isn’t yet a clear way forward

<rekado>guess you’d have to look out for a new Guile release

<elpogo>ok. will do. thanks rekado

<elpogo>ha. guile 2.2.2 isn't even on their news page https://www.gnu.org/software/guile/news/

<roptat>elpogo: in the meantime, you could compile guix locally and send the result to your VM, then modify the ~/.config/guix/latest symlink to point there, it would work as "guix pull"

<roptat>but it's a bit more complicated

<elpogo>my 'local' machine is a 2007 thinkpad. i doubt it will serve a compilation

<roptat>or you could create a 2GB file and use it as ram, but then guix pull will take more than a day to complete

<roptat>swap, not ram

<elpogo>good idea. i will provision a swap partition

<ng0>the last idea depends on your CPU.

<ng0>just try it, you'll either succeed of fail.

<roptat>when I did it on my VM, the IO was constantly at 30MB/s, so I think it's not only a matter of having a good CPU

<rekado>elpogo: I also only have an old Thinkpad (X200s)

<rekado>it’s fine for compiling Guix and more.

<elpogo>ok. i'll consider that if adding a swap partition doesn't work

<efraim>Swapfiles have been a lifesaver for me

<elpogo>is a swap file better than a swap partition?

<cehteh>shoudnt make a difference in performance

<cehteh>but some filesystems dont support swap files

<cehteh>you may use zram/zswap too

<rekado>if you have an encrypted disk your swap file will be encrypted as well

<elpogo>thanks. i'll use a regular swap file for now

<cehteh>that will slow down things massively

<cehteh>you'll see, depending on workload

<cehteh>with 512MB ram only i bet it becomes unbearable slow

<elpogo>i'm not doing anything else on that VM, so should be fine. i'll try zswap if it doesn't work like you say

<cehteh>guix / guile itself is the memory hog, and swapping is few orders if magnitude slower than ram

<cehteh>if memory only leaks and gets swapped out (common problem on bad java programs :D) then its not much a problem, but when it has to swap things in constantly then swap is so slow that it doesnt make any sense

<elpogo>does zswap help because some of the 'swapping' happens via compression to RAM?

<cehteh>yes, can improve the thing massively

<elpogo>ok. it's running with a swap file now. i'll leave it running until i wake up and then decide

<elpogo>thanks cehteh

<cehteh>just enabling zswap already helps, then some tunning improve it further

<cehteh>echo 1 >/sys/module/zswap/parameters/enabled

<cehteh> https://hastebin.com/raw/imeqadibur

<elpogo>ok. ran the command. it's at "lzo,Y,20,zbud" for me

<elpogo>would you recommend changing the other params too to match what you pasted?

<cehteh>just works for me on other computers

<cehteh>compression ration is usually around 50% or better, offering half your ram to zswap means that it wont hit the disk early, z3fold is newer and can stash 3 compressed pages in one for pages which compress really good, lz4 costs more cpu on compressing but compresses better than lzo

<cehteh>decompressing is same or better iirc

<elpogo>cehteh: your expertise boggles my mind. thanks again. will tune the params after i wake up if it's still running

<cehteh>ok

<cehteh>dunno if zswap is enough to improve guix use on 512mb, i am curious too

<cehteh>possibly you need at least 1GB even with zswap

<ng0>elpogo: I am interested in your results, please report back when it's finished :)

<thomasd>Hi #guix

<laertus>is there some way to find out ahead of time what packages "guix package -i glibc-locales" will compile and install?

<laertus>i've been compiling for days now just to get the locales

<laertus>and no end in sight, as far as i can see

<laertus>and i'm just wondering, are all these packages it's installing really necessary just to get the glibc-locales?

<laertus>like libxslt... what does that have to do with locales?

<laertus>in gentoo i can just do an "emerge --ask foo" and it'll show me what it'll install and ask me if i want to proceed

<laertus>anything like that for guix?

<civodul>laertus: "guix package -i glibc-locales -n" should print it

<laertus>thanks

<civodul>that is, it should print what will be downloaded, and what will be built

<civodul>did you enable substitutes?

<laertus>no

<laertus>i don't want substitutes.. i do want to compile everything

<civodul>ah ok, i thought you were complaining about having to compile everything :-)

<laertus>it just seems kind of weird to me that just to get locales it should compile a ton of stuff

<laertus>no, i'm ok with compiling, in principle.. and i know eventually it'll need a ton, especially for packages like firefox or libreoffice

<laertus>but locales?

<civodul>you can look at "guix graph glibc-locales" for an explanation

<laertus>i didn't expect that to require much at all

<laertus>thanks

<civodul>essentially the base system first needs to be compiled

<thomasd>Am I correct that, by default, no shell is available in a build environment?

<thomasd>(And if I need one for the build process, is bash-minimal the preferred one?)

<laertus>every time i run "guix package -i glibc-locales" guix tells me "substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable" and then proceeds to "updating list of substitutes from 'https://mirror.hydra.gnu.org'..."

<ng0>does someone know how I can find anything that is not plain ascii symbols in a texinfo file (with less or with emacs)? I get @u8 not being a unicode char problem. I tried an with C-M-s and then [ -~] but once I start moving in this very long file I loose the marked content

<thomasd>mew

<laertus>is there any way to make it skip trying to update the list of substitutes? i'm not using substitutes anyway...

<thomasd>does it try to update the list when you pass “--no-substitutes”?

<laertus>no it doesn't

<laertus>thanks :)

<ng0>you can pass default arguments to the daemon.

<laertus>cool

<laertus>also, it tells me "guix package: warning: Consider running 'guix pull' followed by 'guix package -u' to get up-to-date packages and security updates." should i do that before continuing with the "guix package -i glibc-locales" (which still has a boatload of packages to install) ?

<ng0>to reply to myself: grep '[[:cntrl:]]' works

<laertus>nice

<civodul>laertus: if you never want substitutes, run guix-daemon with --no-substitutes: https://www.gnu.org/software/guix/manual/html_node/Invoking-guix_002ddaemon.html

<laertus>thanks

<laertus>i keep getting "[tcsh 6.20.00] testsuite: 68 failed" when i try to "guix package -i glibc-locales"

<laertus>full compile log here: https://paste.pound-python.org/show/Vg0g4kVZEcN2xfYcC07j/

<laertus>should i maybe try that "guix pull" followed by "guix package -u"?

<laertus>also, is there any way to just turn off the tcsh tests?

<laertus>i don't even use tcsh... :P

<ng0>make a custom package.

<civodul>laertus: could you report it to bug-guix@gnu.org?

<civodul>there's only 1 test failure, related to 'nice'

<civodul>we'd need to find out why we haven't seen that test failure before

<laertus>sure

<civodul>also, is it fully deterministic?

<civodul>that is, if you try building several times, does this test always fail?

<laertus>yes

<civodul>ok

<civodul>please make sure to include details about your kernel version, Guix version, and guix-daemon settings

<ng0>tcsh itself?

<laertus>apparently, yeah

<ng0>strange

<laertus>civodul: should i attach the compile log to my email to bug-guix@gnu.org or should i send a link to the pastebin?

<civodul>laertus: attach the relevant part of the build log to the message

<laertus>ok, thanks

<laertus>why does "guix package -i glibc-locales -n" show so many more packages than "guix graph glibc-locales"?

<laertus>here's the output of "guix package -i glibc-locales -n" https://paste.pound-python.org/show/0VkRBrAogoCRdrUAMZCu/

<laertus>and that of "guix graph glibc-locales" https://paste.pound-python.org/show/Ng4SyiUNmMD8XdrJQHdu/

<efraim>The first shows what has to be built to 'get there,' the second is how much stays behind if you run 'guix gc', or if you're downloading from substitutes

<laertus>ah

<laertus>is there a way to see a graph of dependencies showing why guix needs to install all the stuff it does when i do a "guix package -i glibc-locales"?

<laertus>"guix graph glibc-locales" doesn't seem to be it...

<efraim>There's a couple other options for guix graph, I don't have a powerful enough computer to see a full representation of my profile manifest for it to really make much of a difference for me

<laertus>wow... creating a graph is really that computationally expensive?

<efraim>Maybe an option with (implicit?) inputs?

<bavier`>laertus: try '--type=references'

<efraim>The graph is the easy part, passing it through dot to make a PDF takes forever for me

<laertus>ah

<bavier`>which I think roughly corresponds to what would be fetched from substitutes

<laertus>hmm.. when i do "guix graph --type=references glibc-locales" i get: "guix graph: error: references for '/gnu/store/2d97vjjx23w3bhwp4sbylwcx6l5fy8g2-glibc-locales-2.25' are not known"

<bavier`>laertus: that means you don't have glibc-locales in your store and there are no substitutes for it.

<laertus>ah

<laertus>it's true, i don't...

<bavier`>laertus: --type=bag-emerged would be your next best

<laertus>ok, that ran

<bavier`>laertus: anyhow, to answer your question about 'guix graph' vs 'guix package -i .. -n', it's because 'guix graph' has all these different view types :)

<bavier`>depending on what part of the graph you're interested in

<laertus>so what am i looking at here? does stuff like "/gnu/store/rsbi86fbhjf4j6305hj2iy1qkmzh6isf-glibc-locales-2.25.drv" -> "/gnu/store/sx2hjydw6fmc47bns32gj3jd0yvr3zk0-gcc-5.4.0.drv" mean that glibc-locales-2.25 depends on gcc-5.4.0?

<sadiq[m]>it would be nice if /usr/bin/env was provided by guix

<sadiq[m]>at least on guixSD

<bavier`>laertus: yes

<laertus>strange that neither subversion or tcsh are listed in the graph, but they're both in the "guix package -i glibc-locales -n" output, and tcsh is what fails when i try to do "guix package -i glibc-locales"

<laertus>(and it mentions something about subversion failing to build too)

<ng0>sadiq[m]: that's easy to achieve

<sadiq[m]>ng0: I'm trying to package a package. having /usr/bin/env can avoid lots of text replacement.

<ng0>for yourself?

<sadiq[m]>no. to be uploaded to guix git

<bavier`>sadiq[m]: there's a build-system phase that typically handles that

<ng0>there have been some discussions about /usr/bin/env… so far we just replace it where necessary

<sadiq[m]>bavier`: hm.. doing that now, was just thinking of avoiding it.

<ng0>oh that. /me isn't really here

<ng0>that is an automatic phase.

<bavier`>sadiq[m]: I think it wouldn't pay off.

<sadiq[m]>hm.. I understands. guix, when installed with other systems shall have no control over /usr/bin/env

<bavier`>we'd need to write our own /usr/bin/env that know's about profiles and all that. Replacing the interpreter is straightforward and removes uncertainty

<bavier`>sadiq[m]: right

<bavier`>laertus: there are some packages that are required in order to run profile "hooks". I wonder if those packages need to be built in your case

<sadiq[m]>why does installing any package requires 5-10 minutes (I see HDD light constantly lighting)

<bavier`>sadiq[m]: the union-build used for profiles is fairly io-heavy

<sadiq[m]>hm.. the install/uninstall test is too much time consuming :'(

<sadiq[m]>is there any bash variable that defines current environment I'm in?

<bavier`>sadiq[m]: $GUIX_ENVIRONMENT

<sadiq[m]>bavier`: hm.. I just need the name. say if I begin with 'guix environment python', I need some way to get 'python'

<bavier`>sadiq[m]: no

<elpogo>cehteh: ng0: it's still compiling. very low cpu usage. swap is at 533M/2G

<cehteh>yes that means it swaps like hell

<cehteh>run vmstat

<cehteh>vmstat 10

<cehteh>when there is lots si / so then the system is swapping heavily

<cehteh>that will likely not come to an end anytime soon (aka take weeks)

<elpogo>cehteh: https://hastebin.com/yeluticine.sql

<cehteh>see 2nd last line 98% it waits for the cpu

<cehteh>just stop it

<cehteh>kill swap (swapoff) enable zswap as i suggested before, reenable swap

<cehteh>then it may work somewhat better

<cehteh>(i still have doubts thats enough with 512MB ram only)

<cehteh>but worth a try

<elpogo>i did enable zswap before i slept, but i did it after swapon. does it make a difference when zswap is enabled?

<cehteh>since currently it progresses at 2% speed, i dont know how fast your vm there is, but on a netbook i have here with 2GB ram it takes hours already at 100% speed, yours may take waaay too long

<cehteh>the things which are already swapped out will stay in swap i think

<cehteh>over time it should migrate to ram, then .. likely its not enough memory

<cehteh>as expected

<cehteh>you can see the zswap statistics, but google by yourself for it, i am busy

<cehteh>somewhere in /sys or /debugfs

<elpogo> https://hastebin.com/ixekokumeb.lua

<cehteh>just not enough ram

<cehteh>actually swap is nowadays so bad (speed difference between cpu/memory and harddisks) that it makes hardly any sense except for sinking memory leak (which makes no sense in another way)

<cehteh>but as soon a computer starts swapping extensively its as good as standstill

<laertus>bavier`: what packages are needed to run profile hooks? and how would i install them if i don't yet have glibc-locales?

<laertus>is there something i could try?

<bavier`>laertus: just a hunch, could you try 'guix build -K mkfontscale'?

<laertus>ok.. trying...

<nextos>Any notmuch users around, what's your preferred option for syncing local tags with server-side folders?

<nextos>GNU sieve perhaps?

<laertus>nextos: i'm a notmuch user, but i haven't synced local tags with server-side folders.. i'm basically trying to use my webmail interface as little as possible and use notmuch as much as possible, so don't really care if they sync

<laertus>so i can't help... but there is a #notmuch you can ask on

<laertus>bavier`: "guix build -K mkfontscale" completed successfully, but i'm still getting the same tcsh test failure when i try to "guix package -i glibc-locales"

<bavier`>laertus: what does 'guix package --dry-run -i glibc-locales' say?

<laertus>bavier`: https://paste.pound-python.org/show/0H3a2zclNmOPlAwe1Kmq/

<laertus>does anyone know what the "nice" test that tcsh runs actually is?

<laertus>maybe there's a clue in that

<efraim>build-aux/hydra/gnu-system.scm:117, should (%glibc-bootstrap-tarball) be %glibc-bootstrap-tarball?

<efraim>hmm, maybe not

<laertus>that's funny... the comments for tcsh's "nice" test say "# Nothing really tested" and the test itself is "tcsh -f -c 'nice set var=1; echo $?var'"

<laertus>hmm... i wonder if my guix install even has the "nice" command

<laertus>is there some way to test that? (sorry i'm new to guix)

<janneke>laertus: nice is in coreutils, part of %base-packages

<laertus>i presume i already have %base-packages installed

<laertus>but, just for reference, how can i test both that i have %base-packages, coreutils, and nice installed?

<janneke>laertus: yes, it will be in: /run/current-system/profile/bin/nice

<janneke>laertus: if your config.scm packages section includes with %base-packages...

<laertus>where is /run/current-system?

<laertus>in /run is just my OS's regular /run directory, nothing to do with guix

<janneke>ah, you're not on GuixSD?

<laertus>i'm not

<laertus>i'm on gentoo

<janneke>right, sorry

<janneke>then you can say: `guix package -I' and look if it has coreutils

<laertus>"guix package -I" returns nothing

<laertus>well, actually it says "guile: warning: failed to install locale" and "warning: failed to install locale: Invalid argument" but nothing apart from that

<janneke>okay, then you haven't installed any packages in your current user's profile

<laertus>i have run "guix package -i glibc-locales" about a dozen times, though.. and i know it compiled tons of packages

<laertus>where did they go?

<bavier`>laertus: into /gnu/store

<laertus>so even though they're in /gnu/store they're not availabe in my user's profile?

<janneke>if the exit status of one of those commands was zero, the package is installed in the user profile of the user that executed that command

<laertus>no, all my "guix package -i glibc-locales" have failed so far

<bavier`>laertus: right, you've asked to install glibc-locales, not the other packages, though they need to be in the store to build glibc-locales

<laertus>i see

<laertus>so then how would i check to see if i have the nice command (which should be part of coreutils) available to guix when it tries to run tcsh's nice test?

<janneke>guix works transactionally: if an operation fails, nothing has changed (execpt maybe there are additionaly cached store items)

<janneke>are you building the guix tcsh package, or are you building tcsh as a user, from source?

<efraim>what filesystem is your build directory on?

<laertus>janneke: all i'm doing is "guix package -i glibc-locales" and that itself tries to build tcsh.. and i have guix-daemon running with --no-substitutes

<laertus>efraim: it's a zramfs mount: /dev/zram0 on /var/tmp/guix type ext4 (rw,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl)

<laertus>i could try without it...

<efraim>we've seen build errors on btrfs vs ext4, its possible

<laertus>ok

<laertus>my usual filesystem is xfs

<laertus>so if i unmount /var/tmp/guix guix will build on xfs

<laertus>it'd be wierd for just that one "nice" test to fail on zramfs/ext4, though

<laertus>but i'm giving xfs a go...

<laertus>failed again

<janneke>ah, okay and building tcsh fails? tcsh uses `gnu-build-system' and that includes %final-inputs (from gnu/packages/comencement.scm) as build dependencies, which includes coreutils

<laertus>i see

<laertus>so it should have "nice"

<janneke>yes

<efraim>`guix build tcsh --no-grafts --check' worked on aarch64 on ext4

<janneke>you can do: guix build tcsh --keep-failed and investigate /tmp/guix-build*tcsh*, you'll see coreutils be included there

<laertus>cool

<laertus>so the difference between "guix build" and "guix package -i" is that the former just builds but doesn't install, while the latter also installs?

<efraim>yeah

<laertus>well, after doing a "guix build tcsh --keep-failed" i do see a /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0 but there's no coreutils or nice in there

<laertus>"print -l /var/tmp/guix/**/nice" fails to find anything

<laertus>"print -l /var/tmp/guix/**/core*" also fails

<efraim>is there a test*log in there?

<laertus>i did manage to run the "nice" test like so, though: /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0/tcsh-6.20.00/tcsh -f -c 'nice set var=1; echo $?var'

<laertus>and tht succeeded

<laertus>but i think it's using my system's nice

<laertus>efraim: i found a /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0/tcsh-6.20.00/testsuite.dir/068/testsuite.log (68 was the number of the test that failed)

<laertus>efraim: and its contents are: https://paste.pound-python.org/show/KQd6PIOkJJbebKb17vlg/

<janneke>laertus: do someting like:

<janneke>cd /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0/; bash; . environment-variables; type -p nice

<janneke>look at the `environment-variables' script to see which build inputs are used

<nextos>laertus: Thanks. I've discussed this over at #notmuch too. Perhaps using Sieve from GNU mailutils

<nextos>is a good idea

<laertus>janneke: ok, that returns: /gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/nice

<janneke>great, so you know this command is available in and in PATh in the container when tcsh is built

<laertus>janneke: interestingly, when i then "cd tcsh-6.20.00/" and proceed to run the "nice" test from the tcsh testsuite as: ./tcsh -f -c '/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/nice set var=1; echo $?var'

<laertus>it tells me: /gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/nice: ‘set’: No such file or directory

<laertus>set is a builtin tcsh command, though

<laertus>but apparently not a builtin bash command

<dustyweb>anyone playing with a package definition for latest firefox anywhere, maybe based on the icecat definition?

<bavier`>laertus: should it not be executing just 'nice' rather than the full path, so that tcsh uses its builtin?

<laertus>actually, it looks like "nice" is a builtin tcsh command

<laertus>yeah

<laertus>using the builtin tcsh nice command succeeds

<bavier`>laertus: I can recreate the failure you describe with a full path, and it succeeds with plain 'nice'

<laertus>me too

<laertus>so why is it failing during the built but succeding when i try it manually?

<laertus>heisenbug

<laertus>oh, maybe because of the chroot that guix does?

<laertus>is there a way i can chroot as guix-daemon does, and try this same test from within the chroot?

<bavier`>laertus: 'guix environment --container tcsh' would be close

<laertus>that automatically tries to build tcsh, fails again for the same reason, and boots me out of the container...

<laertus>is there some way i can get into the container but have guix refrain from trying to build tcsh, and just let me poke around inside with a shell?

<laertus>"guix environment --container bash" maybe?

<laertus>or i guess that would just try to build bash... hmm..

<laertus>here's something else weird...

<laertus>when i "cd /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0/; bash" and in bash: ". environment-variables ; cd tcsh-6.20.00 ; /gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/sh ./tests/testsuite"

<laertus>then test 68 (the "nice") test passes, but these tests fail: 35 40 134 154

<laertus>so there does seem to be some critical differences between my setup outside the build and inside the build

<laertus>well, if there's no solution to this tcsh issue at the moment, is there some way i can force guix to just keep building other packages that it needs to install glibc-locales?

<laertus>i'd like to use this time productively...

<ng0>laertus: do you consider working on xfs for guix, or did I understand the message wrong? If you want to, I can give you a head start with what I have, because I won't be finishing or working on it anytime soon

<laertus>ng0: i'd love to, but i'm afraid i don't have time to do any development work.. i barely have time to just install and start using guix

<laertus>hopefully i can make some time to learn how to create new packages and maybe contribute something to that

<laertus>what i wrote about xfs above was just that i used it as my root filesystem under Gentoo

<ng0>imo, I've used Gentoo for some time too, there is no real gain for building only fronm source.

<laertus>and over that i'd mounted zramfs just for the guix build directory, but that i could test removing that zramfs mount to see if it would make a difference with building tcsh (it didn't)

<ng0>I just rebased. https://gitweb.krosos.org/ng0_guix/guix/commit/?h=package/fs/xfs&id=57a828913fc7d47dafbee721c60626845d60c735

<laertus>well, one gain with building from source is you can customize features per package, and also you can optimize for your machine

<ng0>good luck with all the work for guix...

<ng0>I had the idea to write a short post / article about Gentoo / Guix comparison. Maybe I should do it within the next 12 months.

<laertus>cool

<laertus>btw, just to clear up any misconceptions.. i'm not a guix developer.. just a regular user

<ng0>sure.

<ng0>you don't have to explain to me the views from inside Gentoo, when I said "some time" I meant "long enough"

<ng0>the only thing that you will like is easy customization via GUIX_PACKAGE_PATH and (inherit) and some more techniques.

<laertus>i'm looking forward to not having to constantly compile packages

<laertus>in gentoo i have to constantly keep up, or when i finally decide to upgrade my packages then more than likely lots of things will break

<laertus>i hope that's not the case with guix, and i can just compile once and leave most stuff alone for a while, then compile again when i finally need to upgrade

<ng0>you need to guix pull though..

<laertus>guix pull doesn't compile anything, though, right?

<efraim>anyone have a paste site for ~25MB text file?

<efraim>bpaste took it

<bavier`>laertus: 'guix pull' upgrades package definitions

<bavier`>laertus: most often this is desired for security updates

<laertus>ok, in that case i can just create a cron job to pull every day

<laertus>i just want to avoid having to constantly keep compiling to keep up with the distro, as i do with gentoo

<bavier`>laertus: following 'guix pull' a 'guix package -u' will update packages in your profile

<laertus>i don't want to update the packages all the time, though.. quite the opposite.. i want to update rarely

<laertus>only when i really need to, ideally

<laertus>or when i need some feature that's lacking in the currently installed version

<bavier`>laertus: you can decide what works for you

<laertus>cool

<bavier`>laertus: but if you're not going to update, then 'guix pull' is not useful to you

<laertus>and it doesn't hurt if i delay "guix pull" until i am ready to update?

<bavier`>laertus: no (except for security patches)

<laertus>is there a way to see which packages i'd need to update to get just the security patches?

<bavier`>laertus: not easily

<bavier`>laertus: we don't currently maintain anything like a "stable branch"

<laertus>that's ok, as long as i can delay upgrading my packages indefinitely and not have everything break when i finally decide to upgrade

<efraim>Upgrades are atomic, python-pyxdg failed to compile so nothing updated, then I updated everything except for Borg, which was left linked to an older version of python-pyxdg

<efraim>Then later when it got fixed I upgraded that too

<jonsger>elc79: :)

<elpogo>compiling... 54.3% of 633 filesbuilding of `/gnu/store/ccvkg3720g3gpk0i9mn57y6a9gjga5i9-guix-latest.drv' timed out after 3600 seconds of silence

<Apteryx>Hello Guix! How can I add a custom X.509 certificate? news.gmane.org uses a self-signed certificate.

<Apteryx>Looks like I should define a file service with it under "/etc/ssl/certs/".

IRC channel logs

2017-09-26.log