<rain1>this could be a very helpful talk to watch for guix bootstrapping
<reepca>Wow. I just found out why my system was freezing up during attempts to build gcc-toolchain. It's because I was doing it in an emacs shell buffer... and apparently that build process produces 24GiB of output to stdout, filling up both my memory and my swap partition. The actual build timed out after 1 hour silence, presumably due to so much thrashing. Did not see that coming.
<rekado>reepca I have the same problem, but only since 25.2.
<ecraven>how would I put a few keys into ~/.ssh/authorized_keys with guixsd?
<jsierles>rekado: sorry. what i meant is, if i want to run 'pack' to build a docker image, and builds are all cached in /gnu/store, i shouldn't need to rebuild anything right? so i would need to share that store wherever the packing happens
<jsierles>also, is there an existing remote binary cache or would i need to use my own? i know nix has a remote one
<rekado>jsierles: no, you don’t need GuixSD to create packs.
<rekado>jsierles: we have a build farm and Guix tries to fetch binaries from there (its public key is authorized by default)
<rekado>jsierles: re caching: that’s correct. The only ‘building’ that happens is creating the docker image by copying items from the store.
<jsierles>rekado: ok, thanks for the clarification. once the binaries are fetched from the farm, are they cached then in /gnu/store?
<rekado>jsierles: yes. They stay there until you run ‘guix gc’
<rekado>note that whenever you update Guix it may need to fetch new binaries, even though they hardly differ from previous binaries.
<jsierles>rekado: OK, sounds good. i planned to use a shared filesystem so builds can run on any machine, but share the store. that should be OK?
<rekado>jsierles: note that only the daemon grants write access to the store.
<rekado>jsierles: you cannot have several daemons writing to the same store.
<jsierles>for example, if i wanted to use git HEAD of some python package which isn't in guix yet.
<rekado>you could create a variant by inheriting from the older version in Guix
<jsierles>ok - but i would need to use guix to do that?
<jsierles>i'm referring to a situation where a user would just check out a git repo source and use it, without using guix
<jsierles>i see you can use guix build --with-source. and looks like guix pack too. but i'm curious about a situation where someone might just grab their own copy of a repo and try to use the code directly. in the case of dynamic languages like ruby or python
<rekado>you can mix things from Guix and from elsewhere to some extent.
<rekado>but as soon as linkage with other libraries is needed things become messy
<rekado>if you have pure Python modules that’s fine
<rekado>but when you have a Python module with bindings to a library you have to ensure that this library comes from Guix.
<rekado>or else you will suffer from ABI mismatch.
<jsierles>for some context, we're building a web-based reproducible research platform (nextjournal.com), for reproducing and versioning code and other research elements. this is this missing piece to ensure the base images have this guarantee as well
<jsierles>now just using docker, of course we have no such guarantee
<jsierles>we support R, python and julia, so we're not too far from being able to use guix. only would need to work on a julia importer.
<jsierles>at first we'd just like to replace our base build system with guix, and put a ui around build packs. so for example, if you want a specific combo of software, and we already have an image for it, you'll just use that. otherwise, your image would be built on demand and pushed to a docker registry.
<jsierles>but then others could benefit from having this cached docker image. we need to use docker for other things like CRIU checkpointing.
<jsierles>rekado: we do need to use docker, since we use CRIU checkpointing to save process states beyond the initial base image.
<jsierles>rekado: thats really out of scope of a package manager, but it's nice you can use both here
<rekado>jsierles: I see. I’m not familiar with CRIU checkpointing, but that sounds reasonable.
<jsierles>there's some info here https://criu.org/Main_Page. this way we can store a whole process state, and theoretically rewind and reproduce execution state, not just the underlying software builds.
<Sn0wDay__>Hello everyone. Very strange. I'v tried to install GUIX 0.0.13... But no success. Firs trouble : it don't found some file in a build server as I understand. I suggest me to install from sources. This way was more successfull. But at the end it wrote: grub-install: error: cannot find EFI directory. guix system: error: failed to install GRUB on device /dev/sda1
<Sn0wDay__>But I was mounted /dev/sda1 into newly created /mnt/sda1
<Sn0wDay__>mbakke: but why ? guix system init don'n need BIOS. And it call grub-install or something like that (as I understand). Why I can't install grub manually without BIOS ? In a way guix system init this do.... ?
<civodul>sirgazil: but i think it's not just origins, but anything that can be "lowered"
<civodul>you can always email bug-guix in the meantime!
<brendyn>civodul: `guix package -s emacs' takes 2.1 seconds. `ack 'public emacs\\n' finds the emacs package in 0.5 seconds. On top of that, the guix search shows loads of results which requires honing down tediously. Actually, `guix package --show=emacs' takes 1.2 seconds too.
<mbakke>Sn0wDay__: there is an example in the manual for how to add other operating systems to the grub configuration
<mbakke>but maybe we should mention that guix will assume full control over the boot partition
<Sn0wDay__>This is not problem, because when I press F12, I have an option to boot any stuff that in /dev/sda1/EFI folder (ubuntu, fedora and grub (it name is not Guix but grub)
<jsierles>rekado: is there a way i can help with those packages? i'm needing a handful that aren't there yet.
<mbakke>Sn0wDay__: okay, good. I'm aware of the unfortunate name, will submit a fix for it before the next release.
<rekado>jsierles: in general you can import packages from CRAN or Bioconductor with ‘guix import cran’ (even recursively)
<rekado>jsierles: that should be sufficient for your local needs.
<jsierles>rekado: ah ok. so they don't need to be in upstream. and i can then use with guix pack?
<mbakke>oooh just got an email saying my guix apparel has shipped
<rekado>jsierles: oh, yes. There’s GUIX_PACKAGE_PATH, which can be used for packages that are not part of the upstream distribution.
<rekado>jsierles: I need to leave now, but I hope that in the coming days I can submit my first few patches for the new gnu/packages/cran.scm module, which eventually will contain all of CRAN.
<Sn0wDay__>But ubuntu used another scenario (more advanced IMHO). It detected that Fedora already installed, and also another version of grub already installed. And was installed it grub with option to boot fedora.
<rekado>(once the initial module is in I’ll start a separate branch so that others can collaborate.)
<Sn0wDay__>And when I choose by F12 ubuntu: it grub menu has options to boot ubuntu of fedora
<mbakke>civodul: thanks for covering on guix-patches, I've been busy since starting a new job on Monday
<Sn0wDay__>I am a developer, but new to linux. And it will be interesting to fix something and commit to the community repo. But I need to undersnand how all this stuff is working. Prepare development env, etc. )
<foobar_>I had a stab at the guix enviroment command. I created a file based on my C+Guile project environment. All good.
<foobar_>However -- I cannot run guix enviroment to work when not on the internet/ When it "Creates" this environment, would it not store the result... so when I run it again, it makes use of that rather than fetching stuff off the internet again? Hope that makes sense?
<foobar_>Basically -- can I run guix enviroment without the need of connecting to the internet?
<civodul>foobar_: you could register your environment as a "GC root", such that it is not GC'd
<bavier`>random-nick: should be, ~/.config/guix/latest is just a symlink into the store
<bavier`>random-nick: if you know what the other user's link points to, you can point your own to the same
<efraim_>rekado: apparently tomorrow is the scheduled release for TeX 2017
<jsierles>if I want to use 'guix import' to get a package from CRAN, how can I then use it with 'guix pack'? Above GUIX_PACKAGE_PATH was mentioned. would it be as simple as dumping the module definition output of 'guix import' into a path added to GUIX_PACKAGE_PATH?
<apteryx[m]>jsierles: Yes, it should work that way; although you night want to contribute the package definition to Guix upstream if you are going to maintain it anyway!
<jsierles>apteryx[m]: recardo said he's working on that right now. i just wanted a head start, but also to understand how the alternative path system works
<apteryx[m]>OK! It's explained how to use GUIX_PACKAGE_PATH in the manual, the one biggest catch might be that the file name of your module must match was is declared in the middle source (also briefly covered in the info manual)