<xavierm02>Any idea on how long installing the full texlive should take?
<xavierm02>mbakke: guix import debian might not be worth it. But it's on the way to "guix install debian-<somepackage>" which installs the package in some kind of chroot. Advantages being that you can get stuff that aren't in Guix, while keeping what I consider to be the main advantage: rollbacks.
<adfeno>Hm… Running Minetest-with-debug-symbols like so gdb -iex "set auto-load safe-path /" "../bin/minetest" "core" to inspect the core dumped, tells me "couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error"
<ryanprior>xavierm02: my understanding is texlive is a big install and should complete in the order of hours.
<nckx>xavierm02 ryanprior: It is also almost entirely I/O bound, which is why it used to(?) be blacklisted on Hydra: downloading and unpacking the substitute took about as long as downloading and unpacking the actual sources.
<ryanprior>fwiw I support any kind of interop with Debian, it's a big accessibility win for GuixSD users since there's so much documentation for installing software on Debian.
<xavierm02>texlive installed! And LyX is working properly with just texlive and freefont added. (I got tired of adding texlive packages one by one and recompiling LyX every time)
<xavierm02>I couldn't find a way to say "If this package is installed, then add it to the run-time dependencies of that other package". Is there a way to do that?
<kori>nckx: everything is a file and every file is a bunch of strings so if you think about it everything is a string!
<nckx>kori: That's as good an argument against your point than for it.
<nckx>Turning a string into a file-type object is trivial: (plain-file "name" "contents"). So is 'interning' a file you already have: (local-file "name"). You lose that flexibility and (loose) 'typing' if you settle for strings.
***amiloradovsky1 is now known as amiloradovsky
<minall>Hello guix!, I'm having some problems with a recent guix installation
<minall>I'm getting these messages: WARNING: loading compiled file /gnu/store/kz34yyckqy714p5hmrrvfj1lfq80qvl9-guix-1.0.1/lib/guile/2.2/site-ccache/gnu/packages/samba.go failed: ---- and ;;; In procedure load-thunk-from-memory: segment beyond end of byte array
<notnotdan>Is there a way in Guix to start a build process of some package, and then drop down to a shell if it goes wrong?
<notnotdan>on a slightly unrelated note, why is cmake always trying to use programs in /usr/bin?
<notnotdan>oh wait, it might be to do with the stupid cmake cache
<quiliro>efraim: was just reading your blog post...
<pkill9>notnotdan: you can run the build with "-K" to keep the build directory if it fails, and then you can go into the build directory and source "environment" from the root of it to get all it's environment variables
<pkill9>it would be great to be able to just drop into a shell though
<notnotdan>I have a .so file in my profile from the `mesa` pacakge. How do I know why is it there, i.e. which package that I've installed depends on it? `guix graph` lists all the dependants
<minall>quiliro: Nothing, as I said before, this is a new guix installation... the only thing I can say I did using guix commands, is installing several packages at the same time. but one can do that on guix, right?
<minall>Nope, the config.scm is the same as the installer build
*nckx .oO Isn't every system .scm 'non-standard'? 🙂
<nckx>minall: If you're installing multiple packages to the same profile at the same time one of them can 'win' (so only one ends up in the profile) but Guix is certainly designed never to crash or fail in such cases.
<nckx>Marlin[m]: fbdev is also an Xorg driver, and the kernel Linux can use VESA modes to drive a TTY (I think…) It's more that fbdev is a more generic framebuffer driver than just VESA. I'm not familiar with the implementations.
<nckx>quiliro: Meh, eble esperantisto amatora. Mi nun koncentriĝas al praktiki mia 中文.
<adfeno>It turns out that debugging Minetest from Guix with GDB from Guix is somewhat also challenging, as a Minetest built using `guix environment minetest' immediatelly segfaults in the begining, and GDB complains that libthread-db used in debugging differs somehow.
<nckx>guix build builds a derivation, so it knows about packages, and package sources are themselves derivations, so you can 'build' them.
<nckx>minall: So you could look a the package expression for xf86-video-openchrome, substitute things like 'version' IN YOUR MIND, and 'guix download $THAT_URL' just fine. But it's a) more work and b) (and most importantly) 'guix build --source' applies any patches and snippets from the package expression.
<roptat>now I actually need to test the plugin I built with that
<roptat>it's building, and the plugin.xml looks quite good, so I have some hope that I won't need too many adjustements
<nixo_>Hi, I'm trying to add support for julia packages. Things are going well and I'm writing an importer (in julia for now) to ease importing packages (since many packages have dozen of dependencies). how do I call guix download on a specific git commit?
<nckx>nixo_: I don't know if guix download can do that (it didn't used to). You can git clone a CLEAN checkout at that commit and run 'guix hash -rx' in it as described in the manual's 'Invoking ‘guix hash’' section, though.
<nckx>roptat: When in doubt, rewrite more of the world in Guile…
<nckx>nixo_: git checkout will work too, just make sure there are no untracked files or changes left over anywhere.
<raghavgururajan>sneek_ later ask mbakke Any improvements regarding core-updates-->master merging? Just following up :)
<nixo_>Yess! I've a working implementation of julia-xyz.scm (installing julia packages). There are many things to fix but I got HTTP.jl working ^^ I'll submit a patch in the following days
<nckx>niten: By which I mean, you're welcome to define & refine it to serve as a concrete proposal that can be considered 🙂 As long as users can easily opt out of any & all system-wide channels it might make some sense.
<sneek_>Welcome back trzcdev, you have 2 messages.
<sneek_>trzcdev, nckx says: 'guix environment hello' makes all inputs (=dependencies) of the hello package available in the environment. It does not make hello itself available: you get an environment for *building* hello.
<sneek_>trzcdev, nckx says: 'guix environment --ad-hoc hello' makes only hello available in the environment, not its inputs. 'guix environment hello --ad-hoc hello' does both.