<Apteryx>Probably my RAM just filled up while building IceCat... With IceCat running too.
<enoeht> hey I was trying to build icecat as well did you run into the issue of the configure script saying gstreamer wasn't installed?
<Apteryx>enoeht: I didn't get far enough it seems!
<Apteryx>Hmm, I ran the gc today, and now when I do "guix environment guix" and try to build the git checkout, it says: "./pre-inst-env: line 71: /gnu/store/77cs63vpqnwmrrrb7i684dym842ijavp-profile/bin/guile: No such file or directory".
<Apteryx>Shouldn't "guix environment guix" take care of pulling guile in the (environment) profile?
<Apteryx>OK I guess I had to re-run ./bootstrap && ./configure --localstatedir=/var
<iyzsong>Yes, the environment command always brings a current guile, and the one you last time used (which configrued into 'scripts/guix') had been collected by gc.
<jmd>The inputs are declared in the package recipie.
<jmd>... and typically the recipe will have a line similar to (python (assoc-ref inputs "python") if it needs to refer to the python directory.
<Apteryx>OK, this I can understand. But supposing the build process runs a Python script which requires a library, this library would need to be made available in the PYTHONPATH. There's no easy way to plug in absolute store locations in source Python scripts as dependencies.
<Apteryx>So the answer must lie in the Python package (native-search-paths).
<jmd>Hey! you're talking about Python. So of course there is no easy way!
<Apteryx>Ha! I think on easy way to make it fit the functional model. Must be a scheme from Guido ;)
<jmd>I think some packages have a --python= option in their configure script.
<Apteryx>The interesting thing about Guix is that the Python libraries are all over the place in /gnu/store and *something* usually takes care of creating links to those under ~/.guix-profile/lib/python2.7/site-packages.
<Apteryx>and add this dir to PYTHONPATH so that the executable (Python) can find those extra libraries.
<jmd>Yes. But the profiles don't exist in the build namespace.
<jmd>You can always do (setenv "PYTHONPATH" "...") if that helps.
<jmd>I'm afraid I'm completely ignorant about python.
<Apteryx>jmd: At least now I have one thing to dig more (how Python libraries are made visible in profile-less build environments)
<thomasd>should I run guix pull before or after this point?
<jmi2k>I'm writing a recipe, and I need to import a package built with Lua 5.2. I use package-input-rewriting, but when I set LUA_CPATH, I have to use /gnu/store/.../lib/lua/5.3 instead of 5.2. How can I deal with that? Using 5.3 doesn't looks right.
<cbaines>I've seen packages pull out the version of an input from the record, and use that to create paths
<cbaines>so, could you use something like (package-version lua), and then use that to create the correct path?
<jmi2k>cbaines: That's what I'm doing now. It works, but I think if I'm using Lua 5.2, the path should be Lua 5.2.
<thomasd>well, lets just proceed with the installation and see if it works :)
<jmi2k>cbaines: can I get package-version from an input, instead of a package? So if I change the input, it changes the path as well.
<cbaines>Although, the call to package-version is unquoted, so rewriting the inputs won't work
<jmi2k>cbaines: yes, I submitted this package :) and that's exactly the problem I have. I'm still getting used to writing Guix recipes...
<cbaines>Looking at other packages as well, this seems to be an awkward issue
<cbaines>If a version is used, the information comes from the module, but the package always comes from the input, so there can be a disparity between the two
<jmi2k>Yes, it's not a big problem, but it's confusing. Well, at least things work!
<thomasd>I'm almost at the end of the installation procedure, but grub is complaining it won't install on /dev/sda ("this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.")