<ngz>I get a lot of warning: collision encountered ... warning: arbitrarily choosing... whenever I try to install a package. I have guix installed as root and as user. My guess is that they are different revisions so packages they use differ by their hash and yet, are located within the store.
<ngz>I assume I should guix pull on both sides and then guix gc.
<ngz>However, it is a bit tedious if I have to keep both guix in sync all the time.
<bavier>ngz: the collision messages only concern profile generation, not store contents
<ngz>bavier: I'm not sure to understand. It is telling me that it found 2 equivalent packages in the store, and that it chose one of them for the current profile.
<mark_weaver>ngz: the collisions happen when creating a profile, which creates a tree of symlinks representing the union of all packages in your profile.
<bavier>ngz: the collisions are at the file level, rather than the package level
<mark_weaver>if you have a collision between two store items from the same package but different versions (or different hashes), that can happen when you update some packages in your profile but not others.
<mark_weaver>that can happen because some packages have "propagated-inputs". If package B is a propagated input for package A, and A is in your profile, then B will also be added to your profile automatically.
<mark_weaver>if you look in .guix-profile/manifest, it includes the list of transitive propagated inputs associated with each package that you explicitly installed.
<mark_weaver>so, let's say that you have package A installed in your profile, which brings in package B as a propagated-input.
<mark_weaver>and that you also have package B installed explicitly.
<mark_weaver>those two package B's might not be the same version.
<mark_weaver>you can usually avoid those problems by running "guix package -u" to upgrade all packages.
<mark_weaver>actually, it occurs to me that the logic in 'guix package -u' might not be upgrading 'guix' reliably, because the version number has a commit hash in it, and that hash doesn't monotonically increase.
<ngz>Ok. Thank you. Apparently collisions left are about icon-theme.cache, provided by various packages (emacs, gtk-icon-theme...). Updated guix fixed other collisions.
<ngz>mark_weaver: Since guix development release's name is arbitrary, wouldn't it make sense to tag it with a time reference instead of a git hash, so as to solve the issue with "guix package -u".
<ngz>For example, number of seconds since Epoch divided by 3600 would be a concise tag, as long as you don't release more than one snapshot per hour.
<ewemoa>i'd like to specify certain linux kernel arguments -- it looks like there's a way to specify menu-entries via (grub-configuration ... (menu-entries ... (menu-entry ... (linux-arguments -- but is there a good way to affect the entries that are already generated for grub?
<mark_weaver>ewemoa: I'm afraid we don't have a nice way to do it right now, but if you run guix out of a git checkout, you could modify the source code where that argument list is created.
<mark_weaver>the relevant code is in 'operating-system-grub.cfg' in gnu/system.scm and 'previous-grub-entries' in guix/scripts/system.scm
<mark_weaver>in both places, look for the 'linux-arguments' field in the 'menu-entry' constructor.
<davexunit>civodul: I wrote 'guix container eval' last night, to do the 'eval-in-container' thing. noticed that accepting a gexp is not sufficient because I need to at least know the modules that should be imported.
<davexunit>so for now I expect a monadic value of the derivation as produced by gexp->script
<davexunit>although with the lack of a daemon, call-with-container is currently synchronous, it waits for the container process to die so it can cleanup properly (remove the temporary directory created for the tmpfs mount point)
<davexunit>it's nice not having to worry about layers of disk images like docker does. ;)
<davexunit>I need to get from there to having a list of store paths to bind-mount.
<rekado_>building texlive-texfm-2014 without substitutes by writing directly to the NFS store takes around 5 hours. It just finished.
<bavier>civodul: I'd like to skip the documentation for slepc for the time being; getting it "right" is looking like a lot of work
<civodul>bavier: i thought it would be a matter of replacing delete-file by (lambda (file) (copy-file ...))
<civodul>but as you prefer, you can leave it as a TODO if you want
<bavier`>civodul: I thought it might be as easy too, but the html has href's to files in the source tree that aren't installed, and the makefiles as far as I can tell give no target to install documentation.
<rekado>oh, eigen fails 3/555 tests on i686. Blocks Guitarix on i686.
<absorto>hello! So I installed again, based my setup on the bare-bones example. It's going fine until I reboot and it goes into a loop that reads "waiting for partition 'root' to appear...', it then lands me into a scheme prompt. Help!
<absorto>I did mkfs.ext4 -L root /dev/sdd1, I checked with e2label, I'm pretty sure 'root' is the label I gave.