<mordocai>Anyone know what package I should install to get the library complained about in "ld-wrapper: error: attempt to use impure library "/usr/lib/gcc/x86_64-linux-gnu/5/libgcc_s.so" from guix? I already have gcc-toolchain installed.
<jlicht>davexunit: up till now I have only used `guix package -i` stuff. What is the high level overview to end up with an installed 32-bit package? I assume you start with a build command, but after that I'm a bit lost
<davexunit>jlicht: build flags are available in many commands, including 'guix package'
<davexunit>we expose them to anything that could cause things to be built
<davexunit>calher: there is a plethora of terminal-based email clients
<jlicht>just one last thing: is there any specific ordering I have to keep in mind when passing build options to guix package? Seeing as the `s` for the system option is already in use for guix package :/
<calher>davexunit: But I suck at configuring Emacs for email.
<mordocai>calher: Well that's your own limitation you've enforced upon yourself then. Go learn how to configure emacs for your email I guess. I use gnus myself and it took me a couple hours to get the basics setup.
<calher>But it automatically makes a tor user. Why does the tor declaration half-way do it like that?
<mark_weaver>and btw, tor-service *does* "get" tor, but it doesn't add it to the system-wide profile.
<mark_weaver>like other services, it runs tor directly out of its /gnu/store directory
<calher>Agh! I never get to see the messages in the minibuffer because it keeps saying 'Autodoc not available'!
<mordocai>I have found a bunch of packages that need their source url updated (mostly from http to https). Should I make separate commits for each so that they each get a patch file, do one commit/patch, or ?
<mordocai>Well really a few not a bunch, but anyway
<davexunit>mordocai: one patch per change would be nice, because it makes debugging easier if something were to go wrong.
<mordocai>That's what I was thinking. Alright, I'll work on double checking them and generating patches. I noticed people put their copyright at the top of files, is that necessary for a patch to be accepted?
<jlicht>I currently got a 32-bit version of glibc to install properly in a separate profile (yay for rollbacks when I installed it to my 64-bit profile...). Any convenient way to 'switch' profiles? The guix environment command seems like something I could be looking at.
<davexunit>jlicht: it could be better, but you can use the -p flag combined with --search-paths to get the list of environment variables you need to use that other profile.
<davexunit>for on-the-fly environments, 'guix environment' is a good option. this is what I do almost exclusively.
<jlicht>So I could use guix environment to create an environment with a 32bit glibc as well? For context, I'm trying to build libreCMC, which on my 64 bit system complains about the lack of "<gnu/stubs-32.h>". I assumed having a 32-bit toolchain should circumvent this problem
<jlicht>davexunit: thanks, I have to admit that guix is proving to be a bit more complicated than I had hoped. Although each hurdle I overcome seems to (slowly...) increase my understanding of the system ;-).
<davexunit>jlicht: :) we are trying to make things less hard to grok
<calher>Fine, f;jdskfaj I'm jsutlut jdsflksjf Not going to edit the congig.scm; I can't even lkajf;lkds f match the ldjfsa;lkjsf parentheses because they're lksajf interrupted by a program i dont give af;jslkfj;afkjds;fj;dsajf;saf about
<mordocai>Can anyone help me with trying to figure out how to get my common lisp stuff to include a guix version of libgcc_s.so? http://lpaste.net/152162. Anything that requires compiling by my common lisp stuff is currently giving that error. I have gcc-toolchain in the profile and I source .guix-profile/etc/profile so should have all the env variables set too.
<lfam>calher: Sorry, I wish could help but I don't know much about Emacs or Geiser.
<davexunit>mordocai: you won't be able to use your system libraries like that
<mordocai>davexunit: Is there anything semi-automatic to save a list of packages (not the builds/substitutes themselves, just the names and outputs) to a file so I can pass it to another computer and tell it to install all of them? I can make it myself of course if it doesn't exist.
<davexunit>mordocai: you can create a manifest file, and then have guix instantiate that manifest with 'guix package -m profile.scm'
<calher>Transmission's description says it has a GUI but the package transmission is not gui. just cli
<mark_weaver>I'm somewhat reluctant to make llvm an input to our mesa package. I would prefer to wait until you get 3d acceleration working before considering such a patch.
<mark_weaver>most of our graphical programs depend on mesa, which means that almost every guix user would need to pull in llvm
<mordocai>mark_weaver: Yeah, I looked it up and it looks like any card that requires radeonsi requires non-free blobs so that patch would be useless. Llvm is requires for r300 though which I don't think requires non-free blobs.
<mark_weaver>mordocai: I don't understand. the two sentences of your last message seem to contradict each other. If adding llvm as an input would make the r300 work without blobs, then the patch would not be useless.
<mordocai>mark_weaver: Yeah sorry. I meant the patch to add building radeonsi would be.
<Jookia>mark_weaver: do you have a machine that can run KVM?
<mordocai>Hey, I broke substitutes on my laptop somehow. Anyone know how to fix "substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable"? guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub doesn't work
<mark_weaver>or maybe there's an argument to qemu that explicitly disables kvm
<mordocai>mark_weaver: So on my local system I upgraded llvm and mesa to latest stable and added a flag to LLVM(can't get llvm to build with shared libs though), added disabled llvm shared libs flag on mesa. Now r300 and radeonsi both build.