<davexunit>you can gc them manually if needed and nothing else refers to them
<rain1>they're troubling me a bit since I'm struggling to make my package work and I don't want anything interfering
<lfam>If the installation is returning instantly, then the package definition you are building with is generating one of those 8 versions
<lfam>rain1: I'll try your package definition after my current compile.
<davexunit>rain1: it's almost certainly not interfering
<rain1>i suppose adding the / helped but wasn't enough then?
<rain1>ill look into the gnu packages more to try to understand better
<lfam>rain1: Can I suggest a change to your workflow? I think it will make things a little easier to test. Rather than using `guix package -i foo` and `guix package -r foo` to test your changes, use `guix environment --ad-hoc foo`. That will build foo and put it on your PATH, but it won't register foo against garbage collection.
<rain1>oh yeah I definitely should be doing that, i'll try it now
<lfam>You just need to ctrl-d out of the environment shell to get back to normal
<lfam>I will say I think their configure script is broken. Setting the prefix as instructed (with --prefix) has a bizarre result: CMake Error: The source directory "/tmp/guix-build-midori-0.5.11.drv-0/build/--prefix=/gnu/store/3g4n0n5d1vf2bkkc0sz5n2gm4vdw60d0-midori-0.5.11" does not exist.
<amz3>I think IPFS.io does a good job at buzz word bingo, but doesn't describe yet what it provides. AFAIK it's possible to have a client library push data in the IPFS an retrieve it
<NiAsterisk>okay, I never used privoxy.. maybe I should use that. but I am used to just using torrc
<amz3>they take a great time dealing with the underlying infrastructure/code to explain that it's a really versatile platform. A problem remains is that it linked to some bitcoin-based tech which might be a problem
<NiAsterisk>does it use the blockchain? because blockchain ages and scales terribly
<NiAsterisk>ipfs is on the list of things I need to read into
<efraim>that was a 6 hour build process, but downloading ~20GiB over git was also hours
<NiAsterisk>i had gentoo running on an 10 years old netbook with incredible small amount of ram. I was used to compiling, even with archlinux on that thing, I knew slow speeds from back when I started with ZenWalk and slackware, but this netbook... nope.
<xd1le>ugh try --depth 1 if you don't need all of it
<NiAsterisk>it was interesting to learn the difference i5 cpu and 16 gb ram vs centrino2 vs arm.. 45 min to 2 hours vs 16 hours..
<xd1le>although i have no idea how git handles binary files
<efraim>from watching some of joeyh's early git-annex videos, each blob is basically unique, and you can't really generate a diff
<xd1le>ah well there you go, i was speaking of optimization/compression or whatever to save disk space
<NiAsterisk>I will look more closely at torbrowser,firefox,iceweasel buildsets and sources in the next time to see if the non-free parts can be dealt with easy or can be patched and (best case scenario) be send to torproject, so that at build time there could be the option to remove those parts.
<NiAsterisk>What's more likely: outdated website or outdated github readme? I don't get an answer from the developing team at the moment, but it's a difference between CMake and Cargo/Rust for building.
<wingo>mark_weaver: so are you handling the merge of wip-xorg-server-1.18 ?
<wingo>ACTION wants to get it on a train headed towards master
<mark_weaver>wingo: yes, I'll combine it with some other updates (pulseaudio, gstreamer, libvpx) on a branch and ask hydra to build it out.
<mark_weaver>wingo: btw, as a general rule, autoconf/autogen/autoreconf phases should go after unpack instead of before configure. the reason is that some of the phases before configure are needed especially on non-intel platforms.
<mark_weaver>some of those phases need to fix up the generated scripts, e.g. configure
<mark_weaver>wingo: also, sometimes you removed patches but forgot to remove them from dist_patch_DATA in gnu-system.am
<mark_weaver>civodul: the package list doesn't seem to be updating correctly
<mark_weaver>the updater script ran last night, but the list on the website still says "Updated February 18, 2016"
<a_e>Nice! I am a bit worried by the hundreds of not building packages. It is difficult to compare. Well, we have to make do! Hopefully this will go through well.
<roelj>Oh, I found something. the variable CC is not defined, but used in one of the Makefiles.
<a_e>calher: I just moved to GuixSD on my work machine over the weekend. I am rather thrilled by how well it is working. (Except that all change takes time, I am used to KDE but now need to learn Xfce). The up- and downgrade facilities are really pleasant. Also the on-the-fly tests of the configuration when doing a "guix system reconfigure", before a reboot would break everything.
<davexunit>a 2.23 update should go to core-updates, if it hasn't already
<a_e>There is already a core-updates branch that is being filled with patches, so we could build all this at the same time.
<davexunit>we are already rebuilding glibc there for at least one reason
<paroneayea>well at least one of them listed here is the one we arleady have patched
<paroneayea>* An integer overflow in hcreate and hcreate_r could lead to an
<paroneayea> out-of-bounds memory access. Reported by Szabolcs Nagy. (CVE-2015-8778)
<paroneayea>that's the only one that looks maybe worrying to me, but I haven't looked at how hard it is to trigger.
<mark_weaver>davexunit: yeah, glibc should definitely be updated in core-updates
<lfam>I don't want to try to cherry-pick upstream security updates of core components
<mark_weaver>civodul: btw, in case you don't know: we need to update our 'pkg-config' source URL to use https, because upstream now redirects to https. however, gnutls depends on pkg-config, so it's not clear how to fix this.
<mark_weaver>and more generally, there seems to be a widespread movement to deprecate http, so we'll probably need another plan for how use https sources for all packages, even those that gnutls depends on.
<paroneayea>this must be closer to coreutils as a requirement?
<davexunit>the answer may indeed be that gnutls is a bootstrap binary
<Jookia>maybe you might have to put gnutls in the bootstrap-
<davexunit>but I'd like to evaluate all other possibilities first
<mark_weaver>another option is to handle downloads differently, so that they can make use of resources outside of the build environment. since they are fixed-output derivations, the loss of purity here shouldn't matter, as long as we end up with the file we intended to download.
<calher>a_e: The upgrade facilities are *not* pleasant. I had to do stuff from a git repo.
<mark_weaver>https is not the only issue. a few months ago I wanted to use 'git-fetch' to download something that was needed for 'git'.
<a_e>calher: Yes, there are some rough edges there. I also switched to the git versions as soon as I could.
<civodul>wingo: glad you're looking into it, BTW :-)
<wingo>i don't know if i'll find the thing, but we'll see :)
<paroneayea>calher: anyway, yes it's a requirement. If you aren't willing to abide by treating people nicely in this space, then as goes the phrasing, "you don't have to go home, but you can't stay here".
<Jookia>calher: Speaking as a human being, I know you're upset because Guix isn't going that way and I assume you have some form of depression, but being angry and seeing everyone as an enemy or hurting you isn't going to make things better. It might make you feel justified or let you vent, but you need to find a better place than #guix for that.
<lfam>I'm interested in trying GNOME on GuixSD. Do I just need to add gnome to global packages and enable the desktop-services?
<mark_weaver>I'm not sure it's quite reached the point of deserving a ban, but if he gives up on Guix and uses something more finished and polished, that's fine with me, and I *do* think a polished system is a better fit for him.
<NiAsterisk>treating people nice, and therefore no freespeech (which includes hatespeech) is totaly okay. every discussion on "why" is wasted time for pleasant teamwork
<civodul>switch-symlinks is really when you need atomicity guarantees
<Jookia>Yes and no- in my patchset I've moved the generation of the GC root of grub.cfg to install-grub. It will error when there's already a symlink, and I also need it for more GRUB stuff in the patch after that one (yet to post yet)
<lfam>Hm, somethin has changed between Guix and QEMU. I'm having all sorts of trouble
<_hubertus_>thanks for info and tips. See you to the next time
<lfam>When I try to reconfigure, I get an error from guix/scripts/system.scm, when doing [string-append "--root=" ...]. The error is something like "string-append: Wrong type (expecting string): #vu8(6 145 236 74 2 206 [...]". There are some more numbers
<lfam>This error repeats itself even when I try to reconfigure using the same configuration I initialized the system with. This is in QEMU
<lfam>Does anyone have any idea what could be wrong?