<lfam>The person that wrote the package definition searched online and found the source code of hello on the GNU servers. They use a GNU mirror to download the source code. That is in the (source (origin ...))
<quiliro>please show me where specifically so i can read it
<lfam>That locales bug didn't stop anything from building or booting. You had to actually try using some applications to discover it
<lfam>Although, VMs might not catch issues with system initialization on real hardware
<lfam>Anyways, I understand that everyone has their own tolerance for risk. I would really like it if a handful of us tried using core-updates "for real" before we merge it to master
<lfam>My x86_64 headless GuixSD system is working fine for ~1 week on core-updates :)
<jmd>ohhh. What does this mean: +/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/src/ui/terminal/.libs/pspp: Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp' ?
<lfam>I think it's a bit of risky maneuver. You *could* do the build on a "throwaway" system, for example another machine or a VM. Then, use `guix archive` to make the built binary substitute available on your primary machine.
<quiliro>rekado: lfam: i guess you are right... i am sorry fps...please disregard those comments i made
<lfam>fps: If you did that, you'd also need to authorize the signing key of 2nd machine before you decommission it for good
<fps>lfam: yeah, sounds like a hassle. i'll see if i can find info on updating my guix install with a newer binary release..
<lfam>Overall, that gnutls bug is a real pain in the context of functional package management. I'd hoped that nobody would be experiencing it at this point
<fps>i might just try to copy the contents of the tarball over the old ones ;)
<quiliro>fps: please feel welcome with guix in ubuntu