IRC channel logs


back to list of 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.
<zacts>hi #guix
<rekado>Hi Guix!
<cbaines>Morning :)
<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
<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
<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>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
<civodul>that is, it should print what will be downloaded, and what will be built
<civodul>did you enable substitutes?
<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
<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 ''..."
<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
<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>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
<civodul>laertus: if you never want substitutes, run guix-daemon with --no-substitutes:
<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:
<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
<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
<civodul>also, is it fully deterministic?
<civodul>that is, if you try building several times, does this test always fail?
<civodul>please make sure to include details about your kernel version, Guix version, and guix-daemon settings
<ng0>tcsh itself?
<laertus>apparently, yeah
<laertus>civodul: should i attach the compile log to my email to 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"
<laertus>and that of "guix graph glibc-locales"
<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>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
<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>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)
<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
<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>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>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"
<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>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?
<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:
<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>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>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.
<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>btw, just to clear up any misconceptions.. i'm not a guix developer.. just a regular user
<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
<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? uses a self-signed certificate.
<Apteryx>Looks like I should define a file service with it under "/etc/ssl/certs/".