IRC channel logs


back to list of logs

<civodul>good night/day!
<bavier>and also because scheme ;)
<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>ngz: ^^
<ngz>It doesn't in this case.
<ngz>I haven't anything to upgrade, i.e., "guix package -u" does nothing.
<mark_weaver>ngz: okay, can you tell us which package is colliding with itself?
<ngz>For example libtasn, nettle
<ngz>err libtasn1
<mark_weaver>the two store items
<mark_weaver>so the two absolute pathnames /gnu/store/....
<ngz>Looking at the manifest, I see that libtasn1 is a propagated input for both guix and gnutls, but is listed with two different hashes.
<mark_weaver>I don't see how that could happen after running "guix package -u" as that user.
<ngz>As I said earlier, root also have guix, and perhaps gnutls in one of its profiles. Could it be related?
<mark_weaver>no, each profile is separate.
<mark_weaver>if the collisions are happening when building your normal-user profile, that is only related to what's installed in that profile.
<mark_weaver>it doesn't matter what 'root' has in its profile or what else is in your store.
<ngz>Then I don't know either. "guix package -u" does nothing, so I guess I'm all up-to-date.
<mark_weaver>does "guix package -I | grep '#f'" produce any output?
<ngz>What should have been #f?
<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.
<mark_weaver>maybe try 'guix package -i guix'
<mark_weaver>if you had run "guix package -i /gnu/store/..." at any point, then there would be a raw store item added to your profile, and "upgrading" it wouldn't work.
<ngz>I don't think I did that.
<ngz>I upgraded guix, but I got these warnings again upon completion.
<mark_weaver>if there was no #f in the output of 'guix package -I' then I guess you didn't.
<ngz>This time there is a lot about hicolor-theme-cache
<mark_weaver>well, it would be interesting to see if 'guix package -i gnutls' fixes the libtasn1 collision.
<mark_weaver>anyway, I have to go afk for a while.. ttyl!
<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.
<ewemoa>mark_weaver: thanks for the tips
<ewemoa>mark_weaver: seems to have worked :) thanks! fwiw:
<mark_weaver>ewemoa: FYI, you can disable ipv6 after boot by running "sysctl -w net.ipv6.conf.all.disable_ipv6=1" after boot
<ewemoa>mark_weaver: yes, thanks -- i'm more comfortable with it not getting a chance to work :)
<ewemoa>trying out R in guix sd -- help(read.csv) doesn't appear to do anything, i just see another prompt -- any ideas?
<ewemoa>rekado: if you use R in guix sd, does help(read.csv) show you anything useful? i just see another prompt...
<civodul>Hello Guix!
<ewemoa>civodul: ah, i finally understand your nick :)
<civodul>heheh :-)
<rekado_>ewemoa: I'm still in the process of building inputs for R (texlive), which is very slow because of NFS.
<rekado_>I haven't been able to test help(read.csv) in R.
<civodul>rekado_: i thought you had found a workaround to the NFS slowness?
<rekado_>civodul: I wanted to move /gnu from the NFS share to the local disk and then regularly sync the local thing with what is published via NFS.
<rekado_>the reason: I don't want this virtual machine to publish the NFS share.
<rekado_>that should be done by the file servers directly.
<rekado_>but syncing /gnu from local to NFS takes a long time.
<rekado_>so I'm working on an inotify script that keeps track of changes and syncs only those.
<rekado_>so, until I found a reliable solution it's back to writing to the NFS share.
<ewemoa>rekado_: ah, i see. may be i can do some digging. btw, here is a patch for making and installing the info files for R:
<rekado_>ewemoa: thanks for the patch. Would you be able to send it to the mailing list?
<ewemoa>rekado_: i'll try to find a way
<civodul>rekado_: uh :-/
<civodul>rekado_: and it's not possible to run guix-daemon on the machine that exports the NFS share?
<civodul>ooh, just got the dreaded "bzip2: Compressed file ends unexpectedly;" in 'guix substitute-binary'
<civodul>with the awful backtrace
<zacts>sorry to hear that civodul...
<rekado_>the machine that exports the NFS share is some proprietary, dedicated Oracle ZFS file server running some solaris OS.
<rekado_>I just noticed that a couple of python packages install $out/bin/nosetests
<rekado_>I don't think this is a useful script to install.
<rekado_>also, since in Python we're propagating many inputs we end up with lots of conflicts, so these scripts cannot be used anyway.
<rekado_>another cause for conflicts in python is the useless lib/python$version/site-packages/site.pyc
<rekado_>lots of packages have one and an arbitrary version is picked during profile creation.
<rekado_>In the package I'm working on now I'm removing $out/bin/ (as it only contains nosetests and wrappers around it).
<rekado_>I find it confusing that is *not* installed by the python package, even though "README" in the same directory refers to it.
<rekado_>instead many (or all?) python modules come with a copy of the file (unmodified?).
<civodul>rekado_: we should probably delete those files in python-build-system, as we do for share/info/dir, WDYT?
<rekado_>I'm not sure about what to do with It should be installed by the "python" package, but not by python modules.
<civodul>so let's remove it forcefully in python-build-system, no?
<rekado_>afaics "python" does *not* install
<rekado_>I'm not sure if it's needed at all, but before removing it from all python modules via python-build-system I think we should make sure that its absence doesn't break things.
<rekado_>for "nosetests", removing them through the python-build-system ... I don't know. They are only installed when "python-nose" is among the inputs.
<rekado_>does this justify a change to python-build-system?
<civodul>well, there's also another bug we need to fix
<civodul>so we could do a batch of fixes there :-)
<civodul>namely, which is serious
<Steap>"new" languages are so complex
<Steap>those eggs/wheels/etc. things
<civodul>rekado_: maybe you should ask the list for feedback about these issues?
<rekado_>will do.
<davexunit>morning #guix
<rekado_>davexunit: good morning!
<davexunit>rekado_: sorry that I haven't applied your patch yet. will get to it soon.
<davexunit>I think I want to implement it a bit differently.
<rekado_>davexunit: sorry about not being able to work on ruby over the weekend.
<rekado_>davexunit: no problem. I just care about the feature; doesn't have to be my implementation.
<davexunit>looks like pjotr has made some breakthroughs with a gem that he wants, so that's good.
<civodul>morning, davexunit!
<davexunit>hey civodul
<iyzsong>hi! #guix
<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>does that sound reasonable?
<davexunit>'guix container eval file.scm' where file.scm contains (gexp->script #~(begin ...))
<civodul>davexunit: i didn't think of a command; rather i thought a procedure would be fine
<civodul>so a procedure with the same parameter as gexp->script, except that it would be eval-in-container
<civodul>something like that
<civodul>having a command seems more difficult, indeed
<davexunit>the command was just a frontend for the procedure you talk about
<davexunit>I'll probably remove it now
<davexunit>and change the interface to eval-in-container as you described
<civodul>i'm not sure what the command could look like
<civodul>"guix container run program" would work well, but it's a higher-level beast
<davexunit>it doesn't have to be a command. 'guix environment --container' will suffice.
<davexunit>so right now 'guix container' only has one subcommand: exec.
<civodul>ah right
<civodul>well that's the most important thing
<davexunit>but it will grow as we gain more features
<davexunit>like 'guix container daemon'
<civodul>sounds good
<davexunit>I got the file-system and file-system-mappings types integrated well over the weekend. things are starting to feel pretty nice to use.
<civodul>woohoo :-)
<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. ;)
<civodul>heh :-)
<civodul>you'll have to go to these CoreOS/Docker conferences now
<davexunit>once this is cleaned up and merged I plan to write a blog post this.
<davexunit>and hopefully draw attention to the things that guix makes much simpler.
<davexunit>btw, I was really happy that 'guix system container' got file system mappings for free because they were already used for VMs. :)
<davexunit>civodul: is there a way to get the list of references for a gexp without talking to the store first?
<davexunit>I guess not, but that shouldn't be an issue since I will be returning a monadic value from eval-in-container anyway
<davexunit>my first instinct was to take the input gexp, and splice it into a gexp that uses call-with-container
<davexunit>but if I want to be precise about what gets bind-mounted, I need to know the full list of references.
<civodul>davexunit: there's 'gexp-inputs'
<civodul>but it returns a list of "high-level things", like packages, origins, etc.
<davexunit>ah, okay.
<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.
<civodul>oh, i see
<civodul>well that's fine, then
<bavier`>thanks for the git-send-email review btw
<civodul>yw, i'm glad you added it!
<civodul>i've been wanting it for ages :-)
<civodul>hey, paron_remote
<paron_remote>hi civodul
<civodul>it's mostly about container formats, though
<civodul>not really relevant to Guix
<civodul>paron_remote: :-)
<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.
<alezost>absorto: hi, it may be that you miss a kernel module for you HDD. See the conversation at <> (ask if something is not clear)
<absorto>thanks alezost, might be for it is a scsi drive
<rekado>"g++: internal compiler error: Killed (program cc1plus)"
<rekado>this is not the first time that I see a problem with cc1plus.
<rekado>compiling "powertabeditor" with some changes led to compiler errors as well.
<rekado>such as here:
<absorto>there! I had to add "megaraid_sas" to initrd!
<ijp>is there a systemd service file for guix-daemon?
<rekado>ijp: my colleage wrote one. I don't have it here now, though.
<rekado>ijp: apparently it's just this:
<rekado>in a file /etc/systemd/system/
<rekado>this is for a "make install"ed guix-daemon.
<ijp>right, I didn't expect it to be huge, I just wasn't sure why one isn't included the guix source somewhere
<davexunit>because no one submitted a patch for it
<davexunit>I just use dmd now.