<reepca>in nix/libstore/build.cc, it says "only directories can be bind-mounted", but it seems to work fine in my command-line tests, and I can't find any documentation about that limitation. Any ideas?
<reepca>in fact in that same file they bind-mount /etc/resolv.conf, so I guess some documentation must have gotten outdated
<efraim>'guix pack guix' is the new method for making a binary install tarball?
***octe_ is now known as octe
<reepca>"It is this mechanism that is used to create Guix’s own standalone binary tarball" - 3.7 (Invoking 'guix pack'). I don't know if that's the exact command used, but something like that I would guess.
<efraim>i found 'guix-binary.%.tar.xz' in Makefile.am
<jsierles>can the daemon be given a specific path for the work it does while building? looking to move everything to SSD
<civodul>ng0: undoubtedly :-) i was just referring to the idea of a "time machine for science"
<rekado>ng0: sure, but that doesn’t make it a suitable candidate for reproducible science.
<jsierles>civodul: i hope it didn't seem like we're promoting github in that talk
<ng0>if reproducible science can get contributions otherwise and set up selfhosted infrastructure which scales (github occasionaly suffers the size of its own), then no. I really would not promote github for anything, just as a last choice if you considered everything else.
<ng0>and science within proprietary walls should be avoided
<civodul>jsierles: no, not really, the transition from "time machine" to "GitHub" just stroke me as i was watching the intro
<civodul>i haven't watched the talk entirely yet, i'll do that soonish
<jsierles>civodul: 'git' is really the time machine, not github. it's just not great for all types of projects
<ng0>I know people who stuff big videos and pdfs into git oO
<ng0>speaking of github and a little offtopic: some Gentoo people are around, how's that github/gentoo.org dual hosting working out for the project? Is there a reflection post or something which shows if it had a good effect?
<jsierles>our system is also proprietary for now, but we plan to open source it
<jsierles>we just dont believe that you have to run everything yourself. and in fact by doing that, you are severely limiting what's possible
<ng0>I agree. You have to make logical choices and choices which meet your capacities and goals and intentions.
<jsierles>so, our hope is to build an expensive and open system you can adapt to any scale, but has strong foundations for reproducibility
<jsierles>clearly, whatever science is doing, it has mostly failed in this area :) this is why we want to adopt guix, cernfs, etc. but in a way that gives them more exposure, like how github exposed git to a lot of people.
<rekado>I think that science infrastructure should not be in the hands of corporations.
<rekado>we’ve got too much of that already, unfortunately
<ZombieChicken>Okay, weird. Just ran guix pull;guix system reconfigure /etc/sysconfig.scm, then rebooted into the new system, remounted the new USB, then tried "herd start cow-store /mnt", and it's still claiming cow-store doesn't exist.
<ZombieChicken>specificiallly "herd: service "cow-store" could not be found".
<lfam>ZombieChicken: If I understand correctly, the cow-store service is specific to the USB installation image. It's not used in "regular" GuixSD.
<cehteh>i am not familar enouhg with guix yet to contribute
<ng0>that's not really what I meant, but I grew tired of discussing the topic of gnunet distribution.. I just do. My just-doing needs to be documented more, but eventually this will get into guix. if someone else decides to work on some other mechanism, that's fine too, I'll keep working anyway. problem is what I do grew beyond just this topic. but I see it like this, whoever really wants any of these distribution
<ng0>methods and is capable of investing time into it will do it.
<solene>what is the easiest way to run a X session from a xinitrc instead of xfce/gnome etc.. ?
<lfam>I didn't come up with a solution for all the breakage resulting from perl 5.26.0 yet. I think that if we can't find upstream solutions, we should stick to 5.24.* for this cycle, and backport security fixes as necessary.
<lfam>Well, I'd rather keep the upgrade. But if we can't find solutions elsewhere, or write the fixes ourselves, we don't have much choice. I suppose we could keep both versions around as you suggested, but it sounds complicated to me :/
<lfam>I'll try to do "both versions" before I revert, which is the last resort.