***Acou_Bas- is now known as Acou_Bass
<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. <rekado>reepca I now do my builds in urxvt :-/ <jsierles>hey! is there an API or something for listing guix packages? <rekado>jsierles: you can use fold-packages to iterate over all packages <rekado>what other kind of API are you looking for? <jsierles>my goal really is to build a UI around package installation <jsierles>so whatever I could use to simplify that, the better. mainly need to filter by language, package name and versions <jsierles>and pass this information on to our package installer UI as json <rekado>jsierles: a lot of that seems to have been implemented in guix web <eiro>would you use guix as a package manager for guile (as cpanm for perl or npm for js) <jsierles>rekado: for performing builds, do i need a dedicated host for things like caching? or could I run builds on a cluster, for example inside a docker container. ***Piece_Maker is now known as Acou_Bass
<slyfox>i guess it's one of diffoscope's hexadecimal comparators (xxd) <civodul>would be nice if there was a standalone version of that <slyfox>looking at the diffoscope source xxd can be traded for python library if xxd is not found <civodul>and the Python lib is as capable as xxd? <jsierles>is anyone using guix to export docker images? ***luto__ is now known as luto
<rekado>jsierles: all builds end up in the store at /gnu/store <rekado>jsierles: you do not need a dedicated host, but it can make sense to share a single store <rekado>jsierles: I don’t know what you mean about running builds on a cluster in a docker container. <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>so for using guix pack - how can i specify specific versions of software? <rekado>the same way as specifying any version in guix <jsierles>great! lastly, are there any guidelines for using git repository sources for packages alongside guix versions? <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>great, thats what i thought. good enough for us <jsierles>the profile thing was what I was hoping existed <jsierles>that should also work inside a guix pack? <rekado>‘guix pack’ can also take a profile path, I think. <rekado>so you can export the profile as a Docker image. <jsierles>the profile would be inside the image along with the software, right? <rekado>a profile is a union of several Guix packages + the results of evaluating profile hooks. <rekado>the contents of the image would be the profile. <jsierles>ah ok. i thought you meant the bash profile <jsierles>so we would just have to ensure the profile is sourced when booting the container. <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. <rekado>brendyn: How can an openssh server [be configured on GuixSD]? <rekado>jsierles: if you use Guix underneath you may not even need to use Docker at all. <rekado>jsierles: for sharing profile bundles, however, it makes sense to offer the bundle as a Docker image. <rekado>jsierles: that’s a very nice project, BTW! Feel free to ask here or on help-guix@gnu.org if you run into problems making Guix work for you. <rekado>brendyn: have you checked the manual? You just need to create an instance of the openssh-service-type. <rekado>brendyn: if you hit ‘i’ in the Info manual and type ‘openssh’ you should get a match for ‘openssh-service-type’, which leads you to an example. <brendyn>So I have to reconfigure my whole system to enable it? <rekado>brendyn: yes, any change to the system configuration requires you to run ‘guix system reconfigure’ <rekado>this creates a new system and registers it. <rekado>so you can easily switch between different generations of your system <brendyn>then I can use herd to turn oppenssh on and off? <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. <rekado>but it really doesn’t import from CTAN <rekado>because CTAN doesn’t provide versioned access to packages at all. <rekado>so although the importer fetches package information from CTAN it downloads the sources via SVN from the Texlive repo. <rekado>this means that it can only import packages that are part of Texlive. <rekado>I suppose I could make it optionally download from CTAN (and switch via the ‘-a’ option), but I don’t really see the point. <rekado>so: is this a CTAN importer or a Texlive importer? <jlicht>rekado: So it does get package metadata from CTAN? <civodul>rekado: you could call it "texlive" i guess? <civodul>damn it, when we get a modular texlive, i'll be dancing all night long :-) <jlicht>How big is a more bare-bones version of texlive? <rekado>jlicht: I don’t know if that’s defined. Texlive is a distribution containing lots of things. <rekado>but not every package it provides is actually needed by every package using Texlive. <jlicht>heh, so we´ll see what happens as it happens <rekado>I tried tracking down a couple of reproducibility failures but when I built the software twice on my machine it resulted in the same binaries. <rekado>I remember they were need to be unpacked in somewhat non-obvious ways. <civodul>you do that for both and run "diff -ru" or diffoscope on that <civodul>the "Invoking guix challenge" mentions it i think <jsierles>i'm getting "guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory" <rekado>jsierles: is the daemon running? <jsierles>ah, it was, but then i killed it by accident. now it's running and pulling. <rekado>Is anyone planning to go to the Scheme and Functional Programming Workshop in September? <jsierles>this pull should just get metadata, right? <jsierles>that workshop looks good, and nearby. but my son is scheduled to be born Sept 3 :P <rekado>jsierles: you can think of Guix as a library that describes a very large lazy graph. <civodul>rekado: it's kinda costly so i'd have to get work pay for it <rekado>civodul: I don’t think I can get my institute to pay for me. There’s no ‘bio’ or ‘HPC’ in the name… <rekado>jsierles: when you update Guix (e.g. via ‘guix pull’) you are getting a new description of that graph. <jsierles>yeah, that's what i meant :) i see it needs some base packages first though <rekado>jsierles: any Guix command operates on that graph; ‘guix build’ for example takes a package name, and instantiates the subset of the graph that leads to that package. <civodul>rekado: you could submit a paper, like "Scheme in bioinfo & HPC"? :-) <rekado>so it’s not just metadata. It’s all of Guix, both package expressions that together form a lazy graph and all of the tooling that is needed to describe and instantiate them. <jsierles>rekado: right. but not the binary builds. those are downloaded as needed at build time? <jsierles>if i want to shut and reuse my container, i only need to mount /gnu/store into it, correct? <jsierles>meaning thats the only place data is stored that the daemon would need to access next time it runs. <rekado>civodul: is this not the zlib license? <rekado>jsierles: you may also need /etc/guix and /var/guix when building stuff. <rekado>jsierles: /var/guix contains profile links and /etc/guix contains the acl (needed for public keys from substitute servers) <jsierles>rekado: ok. when are profile links generated? do you also share those on your NFS mount? <rekado>jsierles: I have two NFS shares. One user-writeable for profiles, the other read-only for /gnu/store. <rekado>jsierles: users write to /var/guix/profiles when doing things like ‘guix package -i hello’ <jsierles>rekado: i see. i won't have actual users writing anything here. just my docker container <jsierles>in other words, i'll only be using the guix command line for 'guix pack'. <rekado>heh, our texlive-texmf-2016 package probably doesn’t need to install share/texmf-dist/source at all. <rekado>jsierles: in that case you might not need /var/guix/profiles to be available, but you still need other things from /var/guix, such as the database. <jsierles>does the database update with guix pull? <brendyn>Has anyone here tried packaging Ack? (grep alternative)? <jsierles>to be clear, /var/guix gets setup once at build time. i guess i'll just try and see how it goes <rekado>jsierles: the database is an optimisation; it keeps some info on the contents of the /gnu/store <rekado>jsierles: ‘guix pull’ causes a new directory to be added to the store, so it will also affect the database. <rekado>brendyn: there is ‘the-silver-searcher’; its description says ‘it’s an order of magnitude faster than ack’ <rekado>ACTION just uses grep with M-x rgrep <brendyn>;( Well Ack is need packaging anyway. I've never packaged anything perl before and it was failing with the default perl-build-system <rekado>ACTION tries to work on a texlive-build-system now <rekado>ACTION has no idea how this works <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 <rekado>Sn0wDay__: shouldn’t it be /dev/sda, not /dev/sda1? <brendyn>I'm actually amazed how fast helm-files-smart-do-search is <rekado>grub is always installed to a device, not a partition. <rekado>brendyn: I really should give helm another try. <brendyn>Actually it's sad that I can use that to find packages faster by searching the git repo than guix it's self can. <rekado>Sn0wDay__: I’m not so familiar with this. Maybe mbakke can help here. <brendyn>I wonder what it is that makes guix package -s so slow <brendyn>Sn0wDay__: I think rekado is right. I made that same mistake. you need /dev/sda instead of /dev/sda1 <mbakke>Sn0wDay__: Did you format the drive? Those folders look like MacOS or something. <rekado>hmm, for me ‘guix package -A hello’ takes 5 seconds. <rekado>hmm, for me ‘guix package -s hello’ takes 2 seconds. <Sn0wDay__>@mbakke: no they are. /dev/sda1 is a separate EFI partition I made before <Sn0wDay__>And it contains bootloaders for different OSes <mbakke>Sn0wDay__: you'll need to mount that drive under <guixroot>/boot/efi <mbakke>for grub-install to detect it during "guix system init" <Sn0wDay__>sure, I made this through mount /dev/sda1 /boot/efi <mbakke>so, if you have the guix root partition at /mnt/guix, /dev/sda1 must be mounted at /mnt/guix/boot/efi <Sn0wDay__>Is is possilbe to install simply GRUB for Guix <mbakke>Sn0wDay__: yes, but then you need legacy boot enabled in your firmware <sirgazil>Hi! Is the value of origin-patches supposed to be just a list of file name strings or the list may contain other <origin> objects? Because I'm getting the latter as well... <civodul>sirgazil: it can contain origins as well, indeed <sirgazil>Oh, then I don't know how to handle that yet :P <sirgazil>civodul: Do you think the documentation of origin should mention that, or is it obvious? <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__: you can run grub-install manually <rekado>brendyn: ‘-s’ searches through descriptions as well. If you just want package names use ‘-A’. <rekado>brendyn: also, the results are in recutils format. You can use recutils to filter. <mbakke>on a related note, I struggled for hours to install GuixSD with EFI at a new $dayjob today <brendyn>rekado: yes but ack is a perl script that literally scans the entire source code and other files too <mbakke>the solution was upgrading the UEFI firmware <civodul>brendyn: yeah like rekado suggests, you're comparing apples and oranges :-) <rekado>brendyn: I’m not talking about speed. I was addressing ‘guix search shows loads of results which requires honing down tediously’. <rekado>jsierles: as often as you want to be able to get new packages or package updates. <rekado>jsierles: if you don’t run ‘guix pull’ you won’t get updates. <brendyn>Fine, pacman takes 0.2 seconds. That's apples and apples right? <rekado>‘guix pull’ is currently pretty slow, especially since the switch to Guile 2.2. <jsierles>i see. what does the 'compiling' step actually do? <jsierles>ok . so nothing idempotent about that operation? <rekado>Guix is written in Guile and the sources are compiled to object code for the Guile VM. <rekado>jsierles: we are working on improving ‘guix pull’. Hopefully in the near future it won’t require compiling too much locally. <jsierles>so if i need an update just for one package, i'll have to wait right? <jsierles>maybe not a problem if i can build while that's happening <rekado>jsierles: ‘guix pull’ currently is not smart at all. It will build everything from scratch. <rekado>jsierles: because of that (and because we’re working on Guix) many of us use Guix from git. Changes there don’t require recompiling everything. <rekado>but that’s something we want to fix in ‘guix pull’ <jsierles>is there a place to see which packages are being worked on for import? i'd like to try adding R's lubridate package. <Sn0wDay__>Yeah !) monut /dev/sda /mnt/boot/efi was a right way <Sn0wDay__>Now it already installed and I was booted from this driver. But... It don't updated existing grub it simply overwrite it <rekado>jsierles: I’m currently working on lubridate <rekado>jsierles: actually, it’s already donee <rekado>jsierles: I also have packages for all of CRAN <rekado>jsierles: I’ll submit lubridate to guix-patches in a moment. <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 <mbakke>should have more time from tomorrow! <mbakke>rekado: we need more reviewers :/ <rekado>it would be nice to be able to only show patches that haven’t gotten a response yet <rekado>I took some time yesterday to clean up a little <civodul>i hope it's gonna be cool and maybe feature Guix and Guile and all that :-) <Sn0wDay__>For my opiniont best way to detect what systems already insalled and make try to simply add lines to existing grub config isntead to owerwrite existing <rekado>Sn0wDay__: that sounds like a good idea. Would you like to give a try to modify the code that handles Grub installation? <rekado>ACTION goes to repair a broken water pipe <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. ) <Sn0wDay>ACTION installed ircii @ guix system <foobar_>New user of GNU Guix -- loving it so far. I have a query (and apologies if the answer is in the docs) <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 <civodul>with "guix environment -r my-env ..." <civodul>normally, if you do that, your environment sticks around and doesn't need to be rebuilt <foobar_>Reading the docs now -- regarding parameter -r <foobar_>Yep looks like it will solve my problem. Thank you -- I will have a go with this approach and see if I can continue my dev work in the cafe (no internet) lol -- thanks <foobar_>Will have a play when I get home. Thank you for the quick reply, Sn0wDay! Take care <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) <civodul>mbakke: BTW, did you have a chance to merge version-0.13.0 in master? <jsierles>apteryx[m]: right. but what if i want to change it from, say packageName to r-packageName <apteryx[m]>jsierles: it should work as long as your `define-module' line matches the file name. <apteryx[m]>Oh, sorry I misread, I thought you meant renaming the module. Renaming the package will work fine. Otherwise it will shadow the original definition. <rekado>does ‘trace bitmap’ in Inkscape work for you? <rekado>used to work in previous versions ***andreh1 is now known as andreh