IRC channel logs

<mb[m]1>Ugh, the new elogind worked the first reboot, then failed to start on the second reboot. Fun.

<lfam>mb[m]1: P0 published their full report: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

<lfam>"On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time."

<lfam>Nobody liked keeping secrets anyways ;)

<mb[m]1>lfam: That was fast! And comprehensive.

<lfam>I wonder if KPTI is the reason that GRUB's file_filter_test has been running for over 30 minutes now :(

<mb[m]1>It's apparently been known by the researchers since 2017-06-01, so I guess there's a limit to how long people can remain quiet.

<mb[m]1>It times out after about 30 minutes more.. ;)

<mb[m]1>It works on master though.

<lfam>I think that since Linux started integrating KPTI, it became too obvious to pretend to ignore

<lfam>Bah!

<lfam>Okay, glad I mentioned it :)

<lfam>There was already the KAISER stuff in November

<lfam>I'm sure lots of people started researching it independently then

<mb[m]1>Ah yes.

<mb[m]1>I wonder about the rumors that AMD was not affected, the P0 report suggests otherwise.

<lfam>It's really a shame, out-of-order execution is such a good idea

<lfam>Now we have to go backwards and try to dig ourselves out

<mb[m]1>Heh. That about sums up modern computing.

<lfam>Hah ;)

<lfam>mb[m]1: The file_filter_test timeout, was that with KPTI?

<mb[m]1>lfam: The KPTI patches only landed in 4.14.11 I think, so no.

<lfam>Ah, I updated earlier today :)

<mb[m]1>My "main" build machine is Debian and hasn't been rebooted in 34 days :P

<mb[m]1>Uff, Python 2.7.14 has failed twice in a row on armhf.

<mb[m]1>Same build host, though: https://hydra.gnu.org/build/2422263

<lfam>"test_openpty test_pty"

<lfam>I wonder if it's some aspect of the host environment leaking in

<mb[m]1>librsvg also fails on i686: https://hydra.gnu.org/build/2425708

<mb[m]1>lfam: Yes, I saw a similar issue recently on an armhf host.

<mb[m]1>In fact, the same (hydra-slave3).

<mb[m]1>Trying another restart.

<mb[m]1>Btw, this version of librsvg is the last that does not require Rust. The 2.40 series is now discontinued.

<lfam>mb[m]1: I know :( We really need to get moving with Rust packaging

<lfam>The next Firefox ESR will also require Rust, of course

<mb[m]1>So the new elogind worked exactly once on my test system, on 4-5 subsequent reboots it consistently fails to start. Peculiar.

<mb[m]1>Unfortunately I can't even log in and inspect the system without going back to a previous generation.

<lfam>Can you log in on a console TTY?

<mb[m]1>Nope. Something about login service unavailable. And SSH just hangs.

<mb[m]1>How to reproduce it in the system test :)

<mb[m]1>Back to previous gen now, inspecting logs.

<lfam>I find myself with similar patches for both nfs-utils and libtirpc: including stdint.h

<mb[m]1>lfam: Interesting. Do you find anything of the sort upstream?

<mb[m]1>It's probably related to the glibc 2.26 C++ math kerfuffle.

<lfam>I copied the patch from libtirpc upstream. For nfs-utils I had my own light bulb turn on and found similar patches from other downstream distributors

<lfam>For example: http://lists.busybox.net/pipermail/buildroot/2017-October/203640.html

<lfam> https://github.com/voidlinux/void-packages/commit/cd8af586a8b00a8ba162d070ac1a4e9cb8d28da9

<lfam>And yes, they both seem to be related to changes in glibc 2.26

<lfam>There is also an issue with rpcbind, where the default build glibc 2.26 removed headers for NIS/YP. They were spun off into a standalone library libnsl, or you can build glibc with --enable-obsolete-nsl. It's too late to rebuild glibc IMO

<mb[m]1>lfam: Good to know, there are probably lots of packages with similar issues :)

<mb[m]1>Oh :/

<mb[m]1>Can we package it?

<mb[m]1>(libnsl)

<lfam>It's okay, we can just use the libnsl patch I wrote a few minutes ago ;)

<mb[m]1>Sweet :D

<mb[m]1>Bah, nothing interesting in the logs wrt elogind. It must be some race condition, apparently I only rebooted thrice.

<mb[m]1>Time to spin up a VM so I don't have to run up some stairs and type a long password twice for every reboot :P

<mb[m]1>I have to get some sleep. To be continued.. :)

<lfam>Heh, for me I'd have to go stand and use a computer on top of my fridge :p

<mb[m]1>Haha :P

<lfam>Okay, good night!

<mb[m]1>gn

<soundtoxin>Latest mpv isn't building due to some dependencies related to libdvdcss and dvdread. Adding them both to my system packages and rebuilding doesn't seem to get around the issue either. https://hastebin.com/ekajawixab.sql log here

<dustyweb>yikes https://spectreattack.com/

<clacke[m]>yikes indeed

<clacke[m]>but the URL makes me think of the Chicken Attack yodel

<clacke[m]>I was going to say there's also tge meltdown site, but they're aliases

<amz3>tx

<g_bor>Hello guix!

<g_bor>I've just run into an intermittent test failure in java-commons-lang.

<g_bor>It is a randomized test, test log claims that it fails one times from 1000.

<g_bor>I don't think it is good to have this test enabled, because of reproducibility purposes.

<g_bor>Can I disable it?

<mb[m]1>g_bor: disabling it sounds sensible.

<g_bor>Ok, thanks. I will send a patch soon.

<RockAndSka>Hi there

<RockAndSka>I'm looking to Guix for a while. I want to use it as an unprivileged user, so it comes to 3 options if I'm not wrong : use namespaces if available, use proot ( but require to proot all command i would like to use and didn't find a wrapper who use proot automatically for all commands inside a special directory, does it exist ? ), or compile guix wit

<RockAndSka>h a custom path but require to compile from all the packages from source because I can't use the subtitute

<RockAndSka>So i start to read about the offload system, but require a static config with offload servers already in place. Is there any roadmap to include a system to spawn dynamically some instances from cloud to offload the builds ?

<RockAndSka>something like https://github.com/apeabody/gdistcc would be great

<RockAndSka>or is there already a way to launch some commands before the offload hook to prepare the remote server used for the offload ?

<rekado>RockAndSka: offloading would not help you as you’d still need to store the built packages on your target system under /gnu.

<rekado>rebuilding everything is a big task and I wouldn’t recommend it.

<rekado>due to the nature of functional package management, you’d have to rebuild quite a few packages regularly.

<rekado>if user namespaces are available that’s probably the easiest way.

<g_bor>rekado: The remaining work on switching default jdk to java8 seems more tractable.

<rekado>RockAndSka: you’d run the daemon in a container where it can run as root, and where it has write access to /gnu (which may be bind-mounted from a directory your unprivileged user owns). When you run applications, though, they’d have to be run in that container as well.

<rekado>g_bor: good!

<g_bor>rekado: I would like to know if adding ant-junit to packages is really the best way to solve the junit problem, because a lot of package definitions are affected. Also, if it is, should I squash these as one commit, or send them individually?

<g_bor>rekado: it seems that 39 packages are affected.

<RockAndSka>@rekado: to use a container, i need root access to install docker, so it is not a solution for what i want to achieve

<RockAndSka>@rekado: and why the offloading still need to store packages under /gnu if i reocnfigure guix to use a custom path ?

<RockAndSka>from what i read, the offload respect the custom path inside his builds

<rekado>g_bor: Does this package provide junit target support for ant? If so, should it be a default part of ant?

<rekado>RockAndSka: I misunderstood.

<rekado>RockAndSka: if you build with custom paths it’s going to be all right.

<rekado>RockAndSka: I just think that building everything from source will not be a nice experience.

<rekado>g_bor: what do you think about propagating ant-junit with the junit package? Does this make sense? Actually, I think it’s not so bad to add ant-junit manually to packages that use ant features for junit.

<RockAndSka>rekado: indeed it will be not a nice experience to rebuild all the packages, but without the possibility to use the substitute with custom path ( user namespace, automatic proot for a specific directory ) it is better than nothing and add the possibility to use the same environnement without "proot" trick

<g_bor>rekado: I tend to agree, that we could leave it as is, and add manually. Another thing that could be done would be to add ant-junit if we have junit, and the build system is ant-build-system. It is actually an optional component of ant. I would not propagate ant-junit in the prespective of having more java build systems. I don' think that making de

<g_bor>fault this default part of ant is not needed, we have a lot of packages not using junit.

<RockAndSka>rekado: but rebuild all packages on cloud computer could be a solution to speed up things, it will be great if we could had commands to the offload hook, that way we could use dynamic remote offload server

<buenouanq>where can I find if a particular wifi chip has a free driver?

<buenouanq>one in question is the Qualcomm Atheros AR956x

<g_bor>rekado: However, I dont know if we can make the add ant-juint if junit is added, and ant-build-system is the build system idea without making ant-build-system depend on junit.

<str1ngs>buenouanq: https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers#Status

<str1ngs>buenouanq: I'm not seeing AR956x

<str1ngs>maybe ath9k?

<buenouanq>it looks like maybe, but I can't find it explicitly anywhere either

<buenouanq>would be nice, but I won't get my hopes up

<str1ngs>buenouanq: lspci | grep Atheros

<str1ngs>can you paste the line. assuming I got my grep right

<buenouanq>I don't have access to the machine - Trying to help someone remotely.

<str1ngs>are they running linux?

<buenouanq>not yet (-‿‿ - )

<buenouanq>I don't really want to start and then find the wifi won't work, so I'm trying to figure that out before.

<str1ngs>PCI: 168C:0036 Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter is covered with ath9k

<buenouanq>AR9565 1×1 SB is mentioned under supported devices

<buenouanq>what is the `1x1 SB'?

<str1ngs>nice, that card does not need firmware at all

<str1ngs> https://wiki.debian.org/ath9k#Supported_Devices

<str1ngs>and see ath9k on the wiki page

<str1ngs>also https://wireless.wiki.kernel.org/en/users/Drivers/ath9k

<str1ngs>buenouanq: is this a laptop?

<str1ngs>if so usually, you can get the wifi model from specs

<buenouanq>yeah, laptop

<str1ngs>if you can get the make and model

<buenouanq>asking for more specifics

<buenouanq>thank you very much for the help

<str1ngs>no worries

<ng0>meh. every new exploit gets its own domain. would be cheaper if some org would set up an exploit.org or like an community served this.is/an/exploit

<ng0>nee`: I've read you message, and seen the commits in upstream

<ng0>thanks

<ng0>while I'm procrastinating, I have a question I couldn't answer out of my head at chaos congress: someone I know wants to use GuixSD on an i686 computer. this computer doesn't have enough resources to build software. all the other computers in their house are x86_64. offloading does not support cross-compiling to my best knowledge. what would be an applicable solution here?

<clacke[m]>run guix i686 on one of the x86_64 machines -- it might even be able to coexist with guix x86_64, with the right namespacing tricks around the daemon fifo

<clacke[m]>otherwise, just shove the i686 guix into a container

<ng0>right, I think one solution they thought about was to run a container with Guix i686 on the x86_64

<ng0>forward ssh, done

<ng0>thanks :)

<buenouanq>speaking of other processors, how is ARM support coming along?

<amz3>buenouanq: there is an entry in the guix blog

<buenouanq>oh, awesome

<buenouanq>looks like I'll be breaking out my BBB again :3

<buenouanq>oh good, the EOMA68 seems to be next on the list

<buenouanq>can't wait

<rekado>(EOMA68-A20)

<clacke[m]>EOMA delivery is coming up?

<clacke[m]>I saw that it was nearing production, but it always is :-)

<shiranaihito> https://paste.debian.net/1003550/ - so should i worry about "user-homes" not being started?

<catonano>in learning both magit and git worktrees I messed up so bad, I trashhed the whole folder and I'm starting from scratch :-/

<shiranaihito> https://paste.debian.net/1003551/ - this seems bad, at least :)

<shiranaihito>my VM has 1GB of RAM.. but is that not enough?

<shiranaihito>or was the build eventually successful anyway?

<shiranaihito>running out of memory would usually result in stuff not happening properly

<shiranaihito>when did "postgresql-service" learn to initialize the data directory by itself.. ? or did it? :) (i.e. am i just confused)

<kwerdy>I see many mentions of efforts to get lvm support in guix over the years (even dating back to 2013) but it seems like none of it made it? Does guix support lvm nowadays and if so, how? I can't find any information whatsoever on the topic, and people who ask in mailing lists are told to check the mailing list archive, which only really show unanswered/incomplete threads...

<efraim>I don't believe there is support yet for lvm

<kwerdy>Any idea if someone is working on it or what the status is for lvm support? Or what happened with the 2013 and 2015 efforts?

<shiranaihito>so how would i generally avoid having the postgresql service getting disabled, because it won't start, because the data directory hasn't been initialized yet (after first installing the system)?

<shiranaihito>i thought of initializing the db with something like /gnu/store/0haa85i5rhpxmmninqpkyn3rqax83887-postgresql-10.1/bin/initdb .. but i'm not sure i can specify the postgres user for that command yet

<shiranaihito>(and i started talking before trying :p sorry)

<shiranaihito>but i'm still running the installation image, so .. yeah

<shiranaihito>(because rebooting will get the service disabled, and i'd like to write myself "proper" installation instructions that would take everything into account, and avoid errors etc)

<shiranaihito>postgre's initdb says useable system locales weren't found: https://pastebin.com/1PLXkmvc - i don't know if that's a problem though

<g_bor>kwerdy: I've been thinking about lvm support, and I feel that we miss an abstraction. It seems that we can map devices, we can even map multiple devices to one device, but we don't have partitions, i.e. we can't effectively part of a device to another.

<g_bor>so efraim is right, no lvm support yet

<g_bor>Anyone here familiar with the installer effort?

<shiranaihito>so now that i've used a "local-file" for my postgresql.conf, where do i edit it? am i supposed to edit it somewhere, and then use the new version with a new "guix system reconfigure" command?

<catonano>shiranaihito: what are you trying to achieve ?

<catonano>I have a postgres service running

<shiranaihito>catonano trying to set up GuixSD "properly" for running my SaaS app

<drp>is the way nixos does it wildly different in some way?

<drp>with lvm that is

<catonano>shiranaihito: as for postgres, I can paste my config.scm somewhere, so yo can take the bit forr hhaving a postgres service running

<catonano>shiranaihito: if you want

<shiranaihito>catonano sure, i wouldn't mind seeing a new example

<shiranaihito>thanks

<catonano>ok just a minute

<catonano>shiranaihito: here: https://paste.freshbakedyams.com/paste/H6FZVVLA

<shiranaihito>alrighty, thanks :)

<janneke>$ diff -y guile.log mes.log

<janneke>diff: memory exhausted

<janneke>[2]16:47:06 janneke@dundal:~/src/tinycc

<janneke>ugh ;-)

<kwerdy>g_bor: what are the challenges currently? Is it in terms of abstraction design or is there some difficulty to implement this within the guix system?

<shiranaihito>weird.. i'm running a system reconfigure with basically no other changes than a new postgresql.conf "local-file".. and it's been working for a while now, downloading stuff eagerly :P

<shiranaihito>it looks like it's doing everything again

<shiranaihito>hmm.. it seems guix does try and initialize the psql data directory now

<shiranaihito>i guess that's a new thing

<shiranaihito>more weirdness: now guix is compiling stuff as part of the latest "system reconfigure".. the last time it didn't, and nothing has changed about the installed packages

<shiranaihito>it would be interesting to know what's going on here

<shiranaihito>this would probably take a loong time in a VPS

<rekado>have you updated Guix since the last reconfigure or init?

<shiranaihito>rekado you mean "guix pull"?

<shiranaihito>no

<shiranaihito>when i tried it once at some point, i got an out of memory error, a bit like these: https://pastebin.com/AMYU1yk1

<shiranaihito>but that kind of output looks kind of worrisome

<shiranaihito>and the system reconfigure has been going on "for ages" now, basically

<shiranaihito>i wonder how the decision to skip some tests is made: "SKIP: tests/builders.scm" but "PASS: tests/modules.scm", for example

<shiranaihito>all in all, i have no clue what "guix system reconfigure" has been doing for a long time now, downloading stuff, compiling stuff, running out of memory, skipping tests (that supposedly matter when doing whatever it's doing).. and the only change (compared to the config applied before) was new content in a postgresql config defined as a "local-file"

<shiranaihito>(it's running under VMWare, in a VM with 1GB of RAM)

<lfam>Things like test suite PASS and SKIP are decided automatically by the package's build scripts.

<lfam>If we (Guix) choose to disable tests we typically do it in a different way

<shiranaihito>lfam ok

<lfam>For Guix's own tests, again, it's handled automatically by the test suite. Generally, a test suite will check the environment for various features, tools, and other conditions, and decide which tests to run based on that

<shiranaihito>the worrying part here is all this work happening for no apparent reason though

<lfam>It sounds like your system is building the latest version of Guix

<shiranaihito>lfam ok, but why? :) all i did was run system reconfigure on a config that hadn't changed (itself), but referenced a "local-file" whose contents had

<lfam>Did you run `guix pull` ever since the latest `reconfigure`? Or did you never run it since initializing the system?

<shiranaihito>and now the build seems stuck on something

<shiranaihito>i don't think i ran pull after reinstalling the whole thing

<shiranaihito>the whole guixsd installation, that is :)

<shiranaihito>and why would anything run out of memory with 1GB available?

<lfam>Presumably because it needs more than 1GB ;)

<shiranaihito>:P

<shiranaihito>yes, but why would anything need more?

<lfam>Is it a rhetorical question?

<shiranaihito>it's building low level stuff, right?

<shiranaihito>in C and Guile etc?

<shiranaihito>well, can GuixSD be used on a VPS server (with less than.. X GB of RAM)? :P

<shiranaihito>a VPS typically doesn't have much RAM, right?

<shiranaihito>even this 1GB is more than the default would usually be

<lfam>Recently Guile 2.2 was released, superseding Guile 2.0. This brought some big changes to the Guile compiler, which allowed for faster run-time execution of Guile programs at the cost of slower and more memory-intensive compilation.

<lfam>I _think_ this is the main entry point to the upstream Guile discussion: https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html

<lfam>The point is that 1 GB memory is not enough to build Guix anymore. That is, `guix pull` needs more than 1 GB

<shiranaihito>"time(1) reports a maximum resident set size of 3.8G (though I see

<shiranaihito>something around 900MiB in ‘top’.)" .. omg :D

<lfam>And also building the Guix package which could be required by reconfiguring or upgrading an installed guix package

<lfam>So... it's a problem

<shiranaihito>hhm.. why does the build continue even after something runs out of ram though btw? :)

<shiranaihito>so does that mean anyone who wants to use GuixSD on a VPS server needs to pay for at least 4GB of RAM for it? :)

<lfam>That's a good question. I agree it should totally stop after that

<shiranaihito>maybe more!

<lfam>Swap works but is very slow

<shiranaihito>it seems quite excessive for a linux distro :)

<shiranaihito>oh, right

<shiranaihito>well, i've configured 2GB of swap for the VM

<shiranaihito>i guess that was used up too, before officially running out of memory

<lfam>Upstream, the Guile team is trying to reduce the resource consumption, but it's a slow and iterative process. In Guix, we are working on changes to `guix pull` that could improve the situation too

<shiranaihito>but if GuixSD basically requires more than 4GB of RAM for anything it's run on, that might be a problem too

<rekado>shiranaihito: we agree that it’s undesirable to require more than 1GB of RAM.

<rekado>that’s work in progress.

<shiranaihito>cool :)

<lfam>I have a 1 GB system, with 1.46 GB swap, and that seems to be enough

<rekado>FWIW: I use GuixSD on a machine with less than 1GB RAM.

<lfam>Err, I mean 1.64 GB swap

<shiranaihito>lfam well, my VM has 1GB RAM and 2GB of swap, and bad stuff is happening :)

<shiranaihito>actually, the first "guix system init" goes through fine

<shiranaihito>or at least i haven't noticed problems there

<shiranaihito>but reconfigures go wild

<shiranaihito>and why is it building stuff anyway when the only change is in the contents of a "local-file"?

<lfam>shiranaihito: The thing is, it looks like you are building the Guix package itself, which we generally offer substitutes for. However, you are building a really older version, so we might not have substitutes cached for that.

<lfam>Hm, maybe not "really" older, but not so current :)

<lfam>It may simply be a matter of waiting a few minutes for the mirror to be populated

<shiranaihito>lfam well, all i did was run "guix system reconfigure" with the same system config i used for "guix system init", but again, with new contents for a "local-file" referenced in the system config

<lfam>Hmm...

<shiranaihito>so i don't *mean* to build guix or anything else :)

<lfam>rekado: I guess shiranaihito is experiencing that surprising behaviour where a new system without `guix pull` will actually downgrade the guix package?

<shiranaihito>i just uploaded the refreshed set of files to my VM and re-ran the reconfigure

<shiranaihito>oh? :D

<shiranaihito>sounds wacky :p

<lfam>It's a bit counterintuitive but there's a reason the system installation recommends `guix pull` at the end :)

<shiranaihito>and btw, this was the second reconfigure i ran (after the system init) - the first reconfigure didn't do nearly as much as this one! :)

<shiranaihito>so the correct time to run "guix pull" is.. right after rebooting into your freshly installed GuixSD? :)

<shiranaihito>or.. something else?

<lfam>Unless I missed some sort of workaround for this in recent months, there's a counterintuitive result to reconfiguring or `guix package --upgrade` before the first `guix pull`.

<shiranaihito>maybe add a warning: "if you don't guix pull right away, GuixSD will go all Arch Linux on you!" :P

<lfam>Some people can explain it better than me but I'll try

<shiranaihito>i haven't done "guix package --upgrade" either yet

<lfam>Basically, the guix package ((gnu packages package-management) guix) is based on a Git snapshot of our Git repo

<lfam>Currently it's based on commit f76ff984ebdbed18fce4fe2a62cee73d0ccd8140

<shiranaihito>oh, it seems the build finally stopped.. but i didn't see new output since a long time ago

<shiranaihito>(but nevermind that now, please continue :))

<lfam>So, this version of the Guix tree contains the package recipes the new system will use

<lfam>However, it's impossible for commit f76ff984ebdbed18fce4fe2a62cee73d0ccd8140 to include a Guix package based on that same commit

<lfam>So, the available guix package is a bit older

<lfam>When you run `guix pull`, the most recent version of the Git repo is built and made available at ~/.config/guix/latest

<lfam>This is how package recipes can be different per-user, and it also makes it possible to get a new copy of the package definitions

<shiranaihito>hm

<lfam>So, if you install a new system and never `guix pull`, the set of available packages is actually older than the set of packages that were built and being used to run the new system

<lfam>That is why you must run `guix pull`

<lfam>Hopefully that makes some sense

<shiranaihito>"the set of available packages is actually older than the set of packages that were built" <-- that sounds confusing

<lfam>Right

<shiranaihito>the "packages built" by my "guix system init" invocation?

<lfam>Yes

<lfam>Try `guix --version`

<shiranaihito>and "guix system reconfigure" is trying to use "available packages" that are older than .. what i have?

<lfam>Yes

<shiranaihito>guix (GNU Guix) 0.13.0-14.91c9b5d

<lfam>And your earlier paste showed it was building guix-0.13.0-13.3fb6464

<lfam>Note the '-13.'

<shiranaihito>but again, am i supposed to do "guix pull" right after rebooting into a fresh install?

<shiranaihito>yep! :) it's different

<lfam>And earlier :)

<shiranaihito>earlier? :P

<lfam>I recommend doing `guix pull` on a new system before doing any package installation, upgrading, or system building or reconfiguration

<shiranaihito>before running "system init" from having booted the installation image?

<lfam>No, I recommend doing it after the system is installed

<shiranaihito>ok

<shiranaihito>so after the initial "system init"?

<shiranaihito>.. but before rebooting into the installed system?

<lfam>Anytime after you boot the installed system, but before doing anything that builds or installs packages, like the operations I mentioned a minute ago

<shiranaihito>and if i "guix pull" appropriately soon, then no bad stuff will be happening anymore? :P

<lfam>That is my sincere hope :)

<shiranaihito>:P

<shiranaihito>why after every boot specifically?

<lfam>No, not after every boot. Just at least before the first time you build or install packages

<shiranaihito>ok

<lfam>I'm sorry, my use of "Anytime" was ambiguous. My intention was to communicate that you don't have to it immediately after booting the new system for the first time, but simply at some point before you start reconfiguring the system, or building or installing packages

<shiranaihito>so just to be clear: run "guix pull" after "system init" and before any other "system" or "package" operation until the end of time? :P

<shiranaihito>i mean, any time i'm about to do a "system <something>" or some "package" operation, i should run guix pull first?

<lfam>Run `guix pull` after booting a newly initialized system and before doing anything that builds or installs packages

<lfam>No!

<lfam>Just do it at least once

<shiranaihito>just once when setting things up?

<shiranaihito>ok

<lfam>And then do it whenever you want to update the set of available packages for the user who are you are doing it as

<shiranaihito>i think you said i should run it before rebooting into a fresh install.. ?

<shiranaihito>or is it enough to run it after rebooting for the first time, for example

<shiranaihito>(ok)

<lfam>If I said to run `guix pull` before rebooting, I was wrong. Do it after booting the new system.

<shiranaihito>ok, cool

<lfam>Having been using Guix for a while, it's hard for me to see the weak points in our documentation. I already know how to do this stuff and how to avoid the potential pitfalls. So I'm curious, did you follow the system installation guide?

<shiranaihito>lfam yeah, i did, and i remember it mentioning i should run "guix pull", but apparently it didn't make it clear enough that it NEEEEEDS TO BE DONE, and what the correct time to do it is :P

<lfam>Okay, I'll see what we can do to clarify that

<shiranaihito>thanks :)

<lfam>The results of not doing it are really counterintuitive

<shiranaihito>also, it would be nice to know if "postgresql-service" is supposed to now correctly set up the psql data directory, or not

<shiranaihito>afaict, it didn't, like.. a week ago or something

<shiranaihito>lfam indeed they are! :)

<shiranaihito>maybe use Comic Sans and the <blink> tag :P

<lfam>Heh, if only

<shiranaihito>well, you should make the warning stand out somehow.. :p

<lfam>In a past life I was a graphic designer. The truth is that warnings and signs don't really work

<lfam>The designers have to make the obvious choice the correct one

<lfam>And that is, of course, the hard part :)

<shiranaihito>:)

<lfam>ACTION works on numpy for core-updates

<efraim>I have gcc6 built on core-updates, I just want to check if I can strip out one of my patches

<jackhill>Hi, I'm running Guix on a forign disto and using systemd to run guix-daemon. Is there a recommended way for configure the .service file (e.g. to add additional --substitute-urls ?

<jackhill>I currently have guix-daemon linked to the guix installed in root's profile

<lfam>jackhill: You can just list them in the guix-daemon invocation in ExecStart

<jackhill>lfam: I have that linked to /root/.guix-profile/lib/systemd/system/guix-daemon.service , so I assume that it will get re-written when guix gets upgraded in root's profile.

<jackhill>was symlinking it a bad idea?

<lfam>Well, as you pointed out, it won't work if you want to modify it

<jackhill>okay. I just hadn't thought that far ahead until it happened ☺

<jackhill>I guess the downside to not doing it is that I'll miss a needed/recommended change if I don't pay enough attention. I guess that should be rare enough.

<jackhill>With GuixSD, I assume that overrides like that are handled as part of the system-configuration?

<lfam>Right, on GuixSD you'd use a modified guix-service-type

<lfam>For example: https://dpaste.de/duac

<jackhill>ACTION nods

<jackhill>thanks

<lfam>I use a modified guix-daemon.service, and I've never needed to change it based on a change in Guix. So it's not too much of a burden

IRC channel logs

2018-01-04.log