<Gxsdnewb>guix edit is broken on both 0.8.6 and 0.9.0pre live usb img due to missing execlp
<Gxsdnewb>Without examining the sourcecode (sorry), i am not certain how exactly the guix-daemon logfile dirs are named. The two characters do not appear to match the hash of the output they contain the logs for.
<Gxsdnewb>It would be nice if they were organised chronologically, so that a large build involving multiple packages could be examined later with full understanding of the order of derivation & therefore the clarifying the build process for packages or enitire systems more intuitively.
<alezost>Gxsdnewb: re "guix edit is broken": I think it happens for you because you didn't set EDITOR environment variable
<Gxsdnewb>sorry, i am still a newbie... what is the absolute pathname of this on the live image civodul?
<civodul>there is no editable copy of this on the installation image
<alezost>Gxsdnewb: I think the best bet for you will be "guix pull". The hard way is to use guix from git directly as described in the manual
<alezost>"the best bet" is probably not a suitable phrase, sorry my English, please :-)
<alezost>Gxsdnewb: an alternative to "guix pull" is to use a local guix repo with "./pre-inst-env guix" commands, see (info "(guix) Running Guix Before It Is Installed")
<Gxsdnewb>when i guix pull, is it going to not change all of the hashes of my outputs?
<fps>also note "guix environment guix" to get an environment to build the local clone of guix
<Gxsdnewb>I am trying to compile as many packages as i can to match what is on hydra...
<fps>which is pretty awesome. so if i want to work on a project before packaging it completely i could just create a package with just the required build inputs and use guix environment my-package to get a shell where i can work on it
<Gxsdnewb>because all of the derivation files have date set to epoch, and the hash is nonintuitive to correlate which .drv and -guile-builder belongs to the more recent package
<toothbrush0>civodul: just installed a VM from the 0.9 image, LGTM :)
<wkarhunguixi>civodul, on one computer i use Libreboot, which includes GRUB, so i didn't install GRUB there. On another computer, with BIOS, i let Guix install GRUB and also set up a unencrypted /boot partition
<wkarhunguixi>for both grub.cfg i add "insmod luks" and "cryptomount <partition>" for the menu entry
<fps>for later: where in guix are the kernel parameters assembled?
<fps>i'd like to set vgamode.. i looked at the grub and linux packages, but i suspect ill have to find the definition of the bootloader procedure instead?
<civodul>wkarhunguixi: so you use a manually-generated grub.cfg, right?
<wingo>civodul: compilation speed is generally slower with guile 2.2 but you could compile packages with -O0 i guess, and who knows if other speedups would make e.g. the expander go faster...
<wingo>so i don't know how an eventual switch to 2.2 would affect things :P
<civodul>wingo: i'm guessing it still wouldn't scale well
<civodul>on one hand, it'll be nicer with 2.2 because more things will be mmapped, startup time will be slower
<civodul>on the other hand, that doesn't solve compilation time
<toothbrush0>civodul: perhaps a stupid idea: split each package into a separate file, and only evaluate on demand? would that be feasible? I'm trying to avoid loading the entire package list on each invokation of `guix package`
<wingo>maybe the macros themselves will be faster tho
<civodul>toothbrush0: when you type 'guix package -i foo', you need to know whether "foo" exist
<civodul>i don't want Nix style where "nix-env -i foo" is basically unusable
<toothbrush0>can't you figure that out by `find gnu/packages | grep foo` or the equivalent, first?
<civodul>so people have to lear "nix-env -Ai bar.foo" etc.
<taylan>from what I understand, while compiling Guix's gnu/packages/*.scm which import each other a lot, you have this situation where many of the files get compiled over and over again from importing them for the compilation of other ones, is that right? if so, getting a single Guile instance to compile as many files as possible would probably be a big improvement?
<civodul>taylan: i've thought about that (that's what 'guix pull' initially did), but it wouldn't scale either
<civodul>currently we keep reloading things, but at least we can compile in parallel
<toothbrush0>doesn't it use .go files when they exist and are up-to-date?
<civodul>and the benefits of parallelism outweigh the slowness of reloading things
<toothbrush0>hm, so it seems hopelessly inconsistent that ratpoison and xfce are in eponymous modules, but xmonad is in the `wm` module
<civodul>toothbrush0: that part is fine; the only thing that's slow currently it 'guix pull'
<taylan>(BTW what time complexity is that, where processing the nth item of a total m involves re-processing items n through m? (that would be if every package module imported every other package module.))
<toothbrush0>(reporting that as a naive user trying to get `guix system reconfigure ..` to work)
<civodul>"time guix package -s . >/dev/null" runs in 4 seconds, which is OK IMO
<civodul>'guix package -i foo' is slower, but it involves mostly things unrelated to package searching
<toothbrush0> time pacman -Qi > /dev/null reports 0.28s user, but i guess that's unrealistically fast?
<taylan>different idea: could we have a way to tell Guile to output a foo.go for every foo.scm it happens to compile due to being imported, just like when auto-compiling into the cache? but maybe that still prevents parallelism.
<taylan>toothbrush0: well, it does that when caching auto-compiled files, but e.g. while compiling Guix, it neither caches them nor writes them to foo.go (the compilatino target), so you get this situation where some foo.scm might get recompiled 10-20 times because it's imported from 10-20 other modules which get compiled-and-written-to-.go first
<Gxsdnewb>civodul: is it too late to make a feature request for guix-daemon logging options? I am doing another bare metal install and the log output is very important for mere mortals who cannot read scrolling gcc output so quickly :P
<Gxsdnewb>It would ideally be a guix-daemon option of where to save logs (very important to save on persistent storage in case something happens) or at least envvar mentioned in manual.
<Gxsdnewb>Also it is a strange dir structure, the logs. It wpould IMO ideally be grouped by date+individual call of the guix command (build, package, system, etc.) in directories, then inside said directories a chronological list of pckages in each file
<Gxsdnewb>that way it would be very transparent what the order of compilation was of which packages based upon every invocation of guix
<Gxsdnewb>right now the organization of the logs is just #confusing#
<Gxsdnewb>also, the example for encrypted / in the manual should instruct users to add unencrypted /boot unless they have something like coreboot or libreboot with grub or linux payload that can handle fully encrypted /
<civodul>davexunit: making progress, i've already tagged and such
<civodul>now building the binary tarballs and all that
<civodul>it wouldn't make sense to put so much sweat in a distro "just" to use it in a VM
<davexunit>civodul: it's fine. releases are tough. there's always "one more patch" that we'd like to get in. :)
<Gxsdnewb>Now that i understand a bit about how Guix works, i am trying to understand why i would install it on top of another distro instead of writing new package definitions in Guile
<davexunit>Gxsdnewb: here's an example: at work, I cannot use GuixSD. I have an Ubuntu workstation. using Guix on top of Ubuntu gives me access to things like the Guix build of Emacs and all the Guix tools that help me do day-to-day development work.
<toothbrush0>Why does a `guix system reconfigure /etc/config.scm` want to re-download so many files, such as cups, dmd, etc.? I guess it is because i did `guix pull` after installation? Should i (not) have done this?
<bavier>toothbrush0: a `guix pull` may have brought updates to some packages, so a system reconfigure will want to bring those up-to-date
<taylan>I just intuitively tried to search for a package by doing 'guix package -A foo' instead of 'guix package -A | grep foo', and it simply gave me no output, making it look like a failed search. I guess we should improve on error checking eventually...
<fps>the same does probably not hold for bootstrapping a particular revision of the guix source..
<fps>since the tools used might differ from user to user..
<Gxsdnewb>if i am in the live env and finished a system init to mounted internal ssd at /mnt
<Gxsdnewb>...but now i want to build more packages to the new installation
<fps>anyways, a binar installer gives you a known hash from which to work on. from then on users can build manually and should get the same hash as binary substitutions that started at the same starting point..
<fps>fuzzy ideas.. would have to study the problem some more
<fps>i have a feeling that a chain of trust might work some way or another. oh well.
<fps>i also have a feeling that it's pizza time, since guix pull takes _ages_ :)