<lukas__>Hi can someone clarify guix environment command to me? After creating symlink to the profile of the environment, how do I utilize it afterwards? <cbaines>lukas__, often you either use guix environment as a command, and you don't need to symlink anything <jonsger>civodul: I think it's not the distro. it's the programm <lukas__>hey cbaines. I thought I was supposed to save my development environment in a symlink (to pretect it from gc) <lukas__>so that I can return to same build environment later without building/downloading everything again <cbaines>For the protection from gc, that just requires the symlink to exist, so you could continue using guix environment as you did before <cbaines>however, if you've updated guix, guix environment might generate something different, so you may end up downloading/building packages <lukas__>so like how do I start shell with different environment? <lukas__>you know the shell I get after using environment command. <lukas__>How do I start it again after exiting it? <cbaines>use the guix environment command, or setup the environment variables yourself, e.g. by running source /path-to-profile/etc/profile <cbaines>I'm sortof guessing here, but I think the above will work, I'm guessing the symlink points to some /gnu/store/....-profile directory, and within that there will be etc/profile <lukas__>so I just had to source gnu store's /etc/profile <lukas__>Thought I had to use some specific guix command to get the shell again lol <cbaines>to be honest, it might be good to provide one for usability, so that you can just give it the "name" of an environment you've saved, and it does the rest <lukas__>right that was my mental model while reading guix manual and found nothing. Might be cool if guix starts shell with environment variables inside container <cbaines>You can do guix environment --container ... but I don't know an easy way of combining that with saving profiles <cbaines>making that easy is probably a good reason to make this possible via a command <Apteryx>ahah! I found out why starting geiser with dirty guix checkout is slow. <Apteryx>it has nothing to do with emacs-guix; simply Geiser runs guile without the --no-auto-compile, and compilation takes that much time compared to simply evaluate the modified module (linux.scm -> 2m15s compared to 5.5s) <elc79>Hi guys, i'm writing to you from my new GuixSD system :-) <elc79>where is /usr/bin in GuixSD? <efraim>I believe there is a 'special-file-service' to provide /bin/sh <elc79>efraim, then the personal applications like screenfetch has to be installed in /root/.guix-profile/bin? <efraim>You could put them anywhere and add that path to your PATH or you could create a local package definition for them and then install them <elc79>sorry but i like the logo ^^ <elc79>cehteh, i have to install a web-browser lol <elc79>i'll do it when guix system reconfigure ends, i forgot to include swap-devices and i had to enable swap by hand ***OneBigMes is now known as NullConstant
<efraim>Its enabled in the kernel config IIRC, I'm not sure how to enable it <cehteh>mhm maybe it can be enabled later too dunno, never tried <efraim>Seems like an option that can be added as a kernel parameter in the OS config <cehteh>i have always zswap or zram as swap with great success <cehteh>effectively doubles the available ram <sadiq[m]>Will the staging branch be merged to master soon? <rekado_>in the kernel-arguments field of the operating-system declaration <cehteh>rekado_: is that already in the documentation? i won't ask for making that default but having a note in the doc about zram or zswap and how to set up would be nice <rekado_>any kernel arguments should be added to the kernel-arguments field. <cehteh>and how are things changed in /sys and /proc does guix have a sysfs.conf etc? <cehteh>both come with more parameters and likely when enabled one wants to set /proc/sys/vm/swappiness to 100 since swapping becomes cheap <ng0>we have kdbusaddons .. do we have qtdbus? <ng0>I mean is it in qttools? <ng0>that's an input of kdbus, and kdbus "… builds on top of QtDbus" <cehteh>maybe we shall start a 'guixsd system administrators handbook' where details about system/daemon configuration is explained. the main manual getting alreadly considerably big <Apteryx>tl;dr: If you even see "wrong-type-argument arrayp error" when using emacs-guix and don't want to bother going in your guix checkout to run make, configure the following: (setq guix-guile-program '("guile" "--no-auto-compile")) in your .emacs (https://notabug.org/alezost/emacs-guix/issues/2) <elc79>i don't know why it was recompiling grub <cbaines>elc79, packages will be compiled if there isn't a substitute available <elc79>i forgot to put swap-devices in config.scm and then swap has to be activated by hand, so i include the line in config.scm and then i did guix system reconfigure <elc79>i only want this, swap activated automatically <cbaines>I'm guessing that the version of grub that is available has changed since you reconfigured last <elc79>cbaines, how can i get the swap activated automatically withouth doing guix system reconfigure? <cbaines>elc79, I don't think there is another way of, well, reconfiguring the system <cbaines>how come you'd like to avoid doing guix system reconfigure <elc79>cbaines, i did it to day and failed because of grub after a few hours <elc79>i don't know why it recompiled grub because it's working well, i did guix system reconfigure for swap <rekado_>elc79: you don’t need to run “guix pull” between “guix system reconfigure” <elc79>i know, but anyway guix system reconfigure compiled grub and it failed <rekado_>it won’t do this when you’re using the same version of Guix. <elc79>i changed one line in my config.scm, then i did guix system reconfigure and it compiled many packages like qemu (i didn't installed this package) and after began to compile grub and it failed and guix system reconfigure was stopped <rekado_>how do you run “guix system reconfigure”? <rekado_>this sounds like you’re not using the same version as for your previous install. <elc79>guix system reconfigure, nothing more <rekado_>that determines which guix you will use. <rekado_>every user can have their own version of guix <elc79>i did with my normal user, not as root <cbaines>guix system reconfigure only works on my systems as root, so I normally run with sudo <elc79>cbaines, yes i did it with sudo <ng0>you can run it as sudo -E guix system reconfigure if both your root and normal user guix are on the same commit. <rekado_>I usually do “sudo -E guix system reconfigur” <rekado_>I make root use my main account’s guix (the development checkout) <ng0>how do you feel about gnupg building g13? Werner mentioned this today on the fsfe-rheinland list and I got curious. I could send a patch. <ng0>it adds nothing to gnupg itself, but builds the content in 'g13' directory in source <ng0>'gnupg' itself -> the binary <rekado_>who’s werner, what is “this”, and how does this relate to “g13”? <elc79>rekado_: this order will work for the whole system? <ng0>well. the archive is not public only for list members. damn. <ng0>werner as in werner koch <elc79>sudo -E guix system reconfigure <rekado_>elc79: this will run the current user’s “guix” but as root. <elc79>rekado_: i did sudo without '-E' option, that was the problem? <ng0>basically in WK words g13 replaces LUKS and works directly with dm-crypt. you can encrypt assymetric this way, use multiple keys and use smartcards like GNUk Token. But as I understand it, it is for experimentierfreudige people atm. <elc79>it's compiling grub again... <rekado_>elc79: it will build or download any variant of any package only once. <rekado_>which variant it will build or download depends only on the version of guix. <elc79>rekado_ i dont remember the build of grub in the installation, and it didn't failed... <elc79>but now it's building from source and fails, and you know grub build is not a fast build <elc79>i dont understand why it's build a package that it's installed already <elc79>GuixSD has thing like this, it's not easy for everybody <rekado_>I tried to explain this with my two comments above. <rekado_>I have a feeling that you’re misunderstanding this. <mekeor>does Guix have something like NixOps yet? i.e. a tool for deploying sets of GuixSD machines? <elc79>for sure i have a lot of misunderstandings, but it's a good thing when i scared before any step i do with GuixSD <elc79>this is not easy, i tried to resolve my mistake for not including swap-devices line in config.scm, and now i'm facing a trouble with a package that's installed <elc79>grub it's installed, but the system it's rebuilding it and fails, and i can't complete the operation <cbaines>a version of grub is installed, but not the version of grub you've asked guix to install when you ran guix system reconfigure <elc79>i'm here after two hours, and for sure grub building will fail egain because i saw the same thing right now <elc79>i've not asked to install grub <cbaines>I believe its the only supported bootloader at the moment, so running guix system reconfigure necessitates a version of grub being installed <cbaines>elc79, did you try adding berlin.guixsd.org as a substitutes server? <cbaines>it could have a binary substitute for the grub version you're buiilding <elc79>no, this server has the binaries for all packages?? <mekeor>elc79: if you have specified '(bootloader (grub-configuration …' in your system.scm, guix system reconfigure system.scm' will make sure the latest grub is installed into this new system-generation. <elc79>i installed guix yesterday, i don't think grub made a new version today <rekado_>elc79: you have to be sure about the version of guix you use <rekado_>otherwise you’re just stumbling around in confusion <rekado_>if you installed GuixSD yesterday and now guix tries to build grub from source then the version of Guix obviously differs between these two events. <elc79>the version yesterday was 0.13, how can i check the version today? <elc79>guixi@guixi ~$ guix --version <elc79>Copyright (C) 2017 the Guix authors <elc79>This is free software: you are free to change and redistribute it. <elc79>There is NO WARRANTY, to the extent permitted by law. <mekeor>well. how exactly do you run "guix system reconfigure"? – if you run it with "sudo", i think "guix --version" should give you the version of guix which is used for the reconfiguration. otherwise, if you run "guix system reconfigure" without "sudo", but as root-user, then you should run "guix --version" as root to find out the version of guix used to reconfigure, of course <mekeor>elc79: well, this is strange. there's no version in the output? <elc79>i'm going to this as root in tty2, not in the desktop terminal as sudo <mekeor>elc79: you could also run "su" in the desktop terminal to log-in as root, btw <ng0>have you run guix pull after installing the 0.13 tarball? <ng0>well.. there's your problem :) <ng0>there have been many receipe and otherwise changes and commits since 0.13 <ng0>so the grub you try to build might be from a receipe the build farm no longer uses <ng0>if you update your local content via guix pull, you'll get to the state the build farm (should) have / is building from <elc79>guix pull was a painful operation in my last attempt to install GuixSD, i needed one whole to complete the operation after many failed attempts <ng0>I'm just telling you where the source of your problem might be / probabbly is <ng0>guix pull is being fixed.. in the meantime we have this long time compiling <ng0>it'S a problem which we are facing since 0.13 or one version before it I think. Ludovic and other people made quiet some progress with the problem already. <elc79>it could be very useful if guix checks if a package it's already installed <cbaines>elc79, guix does, just not by name and upstream version <elc79>and why when i did guix system reconfigure the system installed qemu? <ng0>probably bcause you are on an much older guix commit (version) then the qemu definitions in guix master, and therefore no binary substitutes being available, leading to a local build. <elc79>i don't know how the check system works, but i know grub it's installed and working <elc79>ng0, qemu is installed by default? <cbaines>elc79, the grub pacakge depends on qemu-minimal <elc79>cbaines, guix has a lot of dependencies and i don't know why this dependencies are compiled ready to work <elc79>it took some time to compile qemu, grub takes a lot of time <ng0>anyway, between May 22 and today about 3182 commits happened. including a renaming of the qemu module (moving it to virtualization), etc <ng0>may 22 was the 0.13 release, or at least the merge of the branch <elc79>wow, i'm really scared with doing guix pull <ng0>well you need it regulary to update your system. <rekado_>elc79: we *do* compile packages on several build farms, from where they can be downloaded as binaries <elc79>it don't scares with apt, yum, emerge or pacman but... <rekado_>elc79: no offense, but maybe Guix is not for you then. <rekado_>there’s nothing scary about it. Fear and software don’t mix well. <ng0>what scares you is probably the long time compiling.. this is temporary and will be gone once it is fixed. <ng0>also what rekado_ said <rekado_>ng0: there seems to be a deeper misunderstanding <ng0>probably that aswell <rekado_>there’s a *reason* why guix is compiling things <elc79>the thing that scares me is not the time compiling, it's the high possibility of failed operation, and the doing all again <rekado_>*nothing* will ever be done more than once <rekado_>Guix only either builds or downloads a binary *once* per package variant <rekado_>as I wrote repeatedly before: the reason why Guix builds Grub is because you’re using a different version now than when you initially installed Guix. <elc79>rekado_ i know grub 2.02 is installed and the system is trying to recompile it maybe because i didn't guix pull <elc79>i dont see need to rebuild a package that's already installed <rekado_>elc79: I’m trying to tell you that what you think is “grub 2.02” is a particular variant <rekado_>version numbers don’t give you the whole picture <rekado_>Guix won’t *ever* rebuild a package that already exists in the store. <rekado_>a rebuild of grub 2.02 is required when any of its inputs have changed <elc79>with the same hash, i get it, but it's not very practical <rekado_>an input to grub 2.02 will change if any of its inputs gets changed <rekado_>this is nothing to do with practical <elc79>and how many hashes of the same package can be in the same system? <elc79>i think this is the first time i see this <rekado_>FWIW, hydra.gnu.org does have a binary substitute for the latest grub build <rekado_>(hydra.gnu.org isn’t a fast server, so be patient) <elc79>it will be faster that build grub? <rekado_>that depends on your network connection <rekado_>for me it’s certainly faster than building grub locally <elc79>well, i can stop the running guix system reconfigure operation? <rekado_>oops, I may have been wrong about the substitute availability in this case <rekado_>was an *input* to grub, not grub itself <rekado_>you can stop any guix operation at any time <rekado_>what has been downloaded or built ends up in the store anyway and won’t be downloaded or built again. <rekado_>(for the grub build only the check phase is slow) <elc79>after the build before installing <elc79>i have to thank to all of you, you are very good with me <elc79>this is new for me, i never saw a system working like guix <elc79>you are working on an indepent and 100% free distro, this is a great thing <rekado_>yeah, it can be confusing at first. That’s why it’s important to stay calm and try to understand what’s going on. <elc79>what's the command to remove older hashes? <rekado_>“guix gc” removes anything in the store that is not referenced by anything else <rekado_>if you want to keep things you have to hold onto them, e.g. by installing packages into profiles. <rekado_>past generations of profiles are kept until you remove references to them. <rekado_>(on my laptop “grub” just finished building) <elc79>which is the mozilla based browser in guix? <ng0>no idea… I have ignored flash for years. <ng0>the closest would be gnash. <elc79>oh, i'm addicted to facebook games :-( <ng0>flash itself by Adobe is not free <ng0>flash is going away anyway <janneke>we have something for that addiction too: blocking all facebook addresses! ;-) <elc79>haha some level in this games freaks me more than any building operation lol <ng0>I think the one that is waiting for merge doesn't get build with this. Stock chromium has it I think. <elc79>well, grub build failed again, but i have i cool background in my desktop :-) <elc79>tomorrow i will try guix pull, this scares me but i have to do it :-s <elc79>thank you very much and have a very nice week <lfam>I wish we knew how the GRUB build failed. <lfam>There were some flaky tests but we disabled them <Apteryx>eh. I tried restarting udev in a live session. Not a good idea it seems. <Apteryx>Q: How can I extract a string of an <origin> instance? <Apteryx>What string -> I'd like to get some text file from a git repo (udev rules) and pass it to the udev-service-type in my operating-system config. <ng0>couldn't you just write a quick package for it and use that? <Apteryx>ng0: Hmm, it would be misleading to have this packaged, as installing it would serve no purpose. <ng0>but you would have a way to get it into the store <Apteryx>(to hook into udev you need a service -- a package alone won't do that) <Apteryx>origin should already get it to the store, right? <Apteryx>wrong. Some compiler has to lower origin into the store. I'm not sure where it's define. <ng0>search for "add-to-store" <civodul>Apteryx: 'origin' looks like the right thing if you want to add the above file as a udev rule <civodul>the difficulty is that the udev machinery expects the file in a lib/udev subdir, not at the top-level <civodul>so you'd have to write a 'computed-file' that simply copies the file in the right subdir <Apteryx>Hi civodul! My idea was to use the configuration way that we already provides in the dorm of extending the rules field of th eudev-service-type. This field takes a list of udev-rule records. These records are formed by two things: a file name and the file content (as a string). E.g., if I give (udev-rules "51-android.rules" "content...") it will be placed for me under the lib/udev directory. <civodul>oh indeed, i had forgotten about 'udev-rule' <civodul>i guess that should work, doesn't it? <Apteryx>I'm not sure how to do it. IIUC, origin is a dumb record. I cannot input it as a string. <Apteryx>So I probably need the machinery to lower it as an entry to the store (download-to-store/add-to-store?) and then do some basic file reading operating to get it as a string... Or if you know of a simpler way :) <civodul>Apteryx: you need to mimic the 'udev-rules' procedure <civodul>but instead of taking the content as a string, it would take a "file-like" and copy it <Apteryx>Do you suggest extending udev-rule to support both a string or <file-like> object? I could try this, yes. But is an origin record a file-like object to start with? I'm not sure. <Apteryx>How do we define a "file-like" object in Guile? <Apteryx>oh, nicely indexed in our manual. It is defined as an object which when unquoted in a G-expression lead to a file in the store. <civodul>either we extend 'udev-rule' like you say, or we add a separate 'file->udev-rule' procedure <civodul>(i have a slight preference for the latter) <Apteryx>OK. I agree; it's cleaner. Does the origin record already have a gexp compiler? <jcondor>Do you know when LVM will be implemented in GuixSD? <jcondor>If there is any deadline or active development on that <lfam>Basically, somebody needs to do the work to make it happen. Guix is a volunteer project, so we need somebody with the motivation and time to do the work <Apteryx>joke aside, it would be very welcome but I don't know that anyone is working on it ATM. <jcondor>Anyway, thank you very much for answering to that :)