<rekado>Helius: if you use “guix publish” on one host that has built binaries you can download its substitutes (binary packages) from any other host, provided that the host has authorized imports from there.
<ng0>rekado: are there notes, logs, or anything from the reproducible builds meeting?
<OriansJ>ng0: the real question is if anyone is going to finally do work to create the dependency path from the C tree to bootstrapping Haskell. I can't, since I am still stuck on the hex monitor to guix bootstrap binaries path. Working assembler, utilities and a forth but the Lisp interpreter and the C compiler still need alot more work.
<OriansJ>rekado: well as long as we catch new languages soon enough, we should be able to sustain a build path [crudely], the problem is that there are a handful of binaries that matter, which we will need to do alot of work to create what we missed.
<ng0>thum: what I hope Vikings will do differently in contrast to others who promise and fail at trustable hosting, is transparency. as transparency (in function, what's used, who's involved, partnering, etc) is essential for trust.
<rekado>OriansJ: ideally we will create awareness of the bootstrapping problem, so *we* don’t have to catch new languages.
<rekado>eventually it would become common knowledge, similar to how reproducibility is moving out of the shadows
<geemili>Is there a way to specify optional dependencies?
<sneek>lfam, Petter says: Sure, I'll see if I can set it to -1.
<ng0>Yes.. so far I see that a redis-service is required for pagure-service (which might just be an wsgi service). I haven't read all of the documentation so far. I'll send the updated patch series tomorrow
<ng0>I can imagine on GuixSD side that the pagure service will be just one service instead of many as in systemd, but I have no idea about non-guixsd systems... should I also install the .service files?
<ng0>I have to do some manual installations because the reference is just the rpm of fedora
<lfam>ng0: I think it's valuable to include the .service files
<roelj>civodul: Do you want to disable UEFI on it?
<ng0>+ ("python2-py-bcrypt" ,python2-py-bcrypt) yep.. I need it
<ng0>eh, i'll just start notmuch a second time and reply
<civodul>roelj: well, i want it to boot and i thought UEFI was the easiest way ;-)
<civodul>roelj: what would you suggest? you seemed to know the topic better than i do :-)
<roelj>civodul: Would you like to boot GuixSD from UEFI, or from BIOS? For UEFI, Marius Bakke has the recipe. For BIOS, just disable it on the system startup thingy (what used to be the BIOS settings).
<roelj>I can also share the snippet needed in the OS declaration when I'm home.
<roelj>(I'd try to go for UEFI, but that's just personal preference I guess)
<civodul>roelj: yeah that sounds like the goot longer-term thing
<civodul>hmm lemme see if i can find Marius' recipe
<roelj>civodul: IIRC you need: (bootloader (grub-configuration (grub grub-efi) (device /dev/sda)))
<roelj>civodul: And a separate /boot formatted as vfat.
<ng0>is there someone who needs redis in their workplace or private? It would help if it wasn't just me working on two more services in addition to the other 3 I'm currently working on. redis is needed for pagure, and for pagure I need to write a service as well if I understand all the individual .service files correctly
<ng0>hm. my spare laptop just got an kernel panic. maybe it needs the older kernel as well
<lfam>Seems funny that we have (gnu packages upnp) and (gnu packages libupnp)
<cbaines>Is there any patterns for working with package managers that use paths (e.g. gem with GEM_PATH) when working in the store? I'm trying to run a ruby program, but its looking like I would have to construct the GEM_PATH to make it work?
<paroneayea>I was like "well I guess I ought to kick out a release of 8sync, then poke at how hard it will be to get suspendable ports working, because I need something like this for the standards stuff I'm doing"