<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. <mordocai>If you already are setup to use the git repo as your config anyway <mordocai>For one thing it'd be the name of your package so guix build mcwm not guix build mcwm.scm <davexunit>for one-offs, you can can use 'guix build -f file.scm' <davexunit>where file-scm contains an expression that evaluates to a package object <davexunit>as in, it can't be a guile module that defines some variables <davexunit>so I have a package expression to use as the basis of development environments <mordocai>My first thought was to skip the file one way or another, but I don't really want to do it by modifying the regex like ricardo suggests there. <davexunit>mordocai: you don't need to modify that regexp <davexunit>you can simply filter the resulting list and skip the file that is problematic <mordocai>calher: not a fan of that transfer.sh btw <mordocai>Annoying to have to download the file to see anything, at least for me <mordocai>davexunit: Yeah, that's what I was thinking. I'll have to learn a bit of guile then! <calher>mordocai: i can just click it and see it wtf <calher>dsjflksjflkjfkdsfjlksjflksjfslkfj <mordocai>calher: It makes me click download and download it. Idk why the behavior is different on your machine. <davexunit>mordocai: you can simply using "delete" to remove an item from a list <davexunit>(delete "foo/bar/problem.lisp" (find-files "." "\\\\.(lisp|sh)$")) <calher>mordocai: No it doesn't! It has a DL button and then below it has the file embedded in the page! <paroneayea>do I have to make a postgres user first before I install the postgres-service? <mordocai>davexunit: Cool, do you know where find-files is defined? Wanted to try this at the repl first. <davexunit>mordocai: grep the source, but I think it's in (guix build utils) <mordocai>Ah okay, wasn't sure if it was a guile thing or a guix thing <davexunit>paroneayea: the user/group is automatically created, or should be. this is probably fallout from the recent changes to start services immediately after reconfigure <jlicht>Is it possible to install a 32-bits version of a guix package on a 64-bits installation? <davexunit>jlicht: 'guix build' has a flag to set the target platform and architecture <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>davexunit: Indeed, I missed that line at the bottom of the guix package docs. thanks a bunch <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. <calher>If I declare a tor service, does Guix automatically add tor and torsocks packages globally? <calher>mordocai: But I want my email in emacs if it's going into the terminal. <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? <calher>It declares a tor user but it doesn't get tor. <davexunit>services don't pollute the global package profile. <calher>Might as well just declare a tor user manually and not have the tor service declaration do it. <jlicht>calher: Chen's blog has an amazing guide for setting up Gnus <davexunit>calher: the tor service starts a daemon, no? <calher>But what if I want to host a hidden service? <davexunit>calher: you could have a service that does that. <calher>tor, torsocks didn't work last time i had them in my profile, was it because of not having SSL stuff? <davexunit>if you want to do it without using the GuixSD interface, you can just install tor to the system profile or your user profile <calher>oh, ok. i declared two things and hoped they would work together if i put it in the torrc <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? <mordocai>These are definitely trivial IMO so i'll vote not necessary until told otherwise <calher>Can I run a tor proxy without root? <calher>I don't want to reboot just to get a tor proxy up <calher>:( i have to rebuild the system and reboot just to get a tor proxy :( <davexunit>I think with our current limitations, you can stop the service before reconfiguring and the new service will be started <davexunit>we can't currently automatically restart running services, because that is a much trickier sort of thing. <davexunit>calher: well, I see a syntax error in the lsh-service form <mordocai>Lol was all ready to submit a patch to update to "latest" sbcl and figured out they've released since I started looking at it. <calher>I can't use torify for ANYTHING anymore. JLKDSJFKDSJF <calher>Gotta use admin privs to run a stupid proxy <calher>Can't even launch the stupid Tor Browser Bundle. <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 <davexunit>as far as actually building librecmc, that will be an exercise left to you :) <calher>'Autodoc not available' 'Autodoc not available' STOP HOGGING THE MINIBUFFER SO I CAN READ IT <lfam>It looks an error message from geiser <jlicht>calher: perhaps you can check the *messages* buffer (control-x, control-b, *messages*) for the messages you missed <calher>And when I start geiser, it hogs half my pane with a stupid guile shell. i thought guile was supposed to be invisible and you do C-x C-e to eval it in guile <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>and now the cat is nagging me to open the door... <calher>I can't match parens because of Autodoc! <calher>I'm not going to check the messages just to see if I matched a paren. <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: Well, to be fair, I am not trying to use any system libraries at all. This is stuff I don't directly control. <lfam>mordocai: Maybe the path is hard-coded somewhere? <davexunit>mordocai: sometimes, when using guix on a foreign distro, impurities can leak in. <davexunit>if your system supports the necessary features, 'guix environment --container' may be useful. <lfam>I remember there being a similar issue with the WIP Golang build system. I think there are some messages about it on guix-devel <davexunit>or yeah, perhaps there is a hard-code file name as lfam says <davexunit>mordocai: it's pretty common to encounter software that assumes its being built on a distro that uses the FHS <davexunit>such software must be patched in order to build with guix <calher>wait, geiser isn't in elpa. is it installed into guix emacs by default? !!!!!!!!!!!!!!!!!!!! <mordocai>davexunit: lfam: So the path definitely isn't hardcoded. Not sure how to tell if it has the second problem <davexunit>mordocai: I'm not familiar with the common lisp build system, so I don't really know how it finds the compiler and all that <mordocai>Well as the paste shows it is literally just using cc -m64 -I<a directory> -o <a directory> file.c <mordocai>Ooooh, i see maybe. If I do which cc on my shell it says /usr/bin/cc <davexunit>mordocai: 'guix environment --pure' can help with this <lfam>But would the environment in the shell affect the environment in the build chroot? <mordocai>I'm not using a build chroot, this is stuff that isn't in guix yet <davexunit>yeah, making an attempt to purify env vars is a good first step to mitigating this sort of stuff <mordocai>davexunit: Well if I make a symlink ~/bin/cc to ~/.guix-profile/bin/gcc it works. (my ~/bin is in my path at a high precedence) <davexunit>mordocai: it would really be best if you remove anything that refers to /usr from your env vars <davexunit>you *cannot* mix things from your host distro and guix and expect things to work. <davexunit>things *will* break in subtle, or not-so-subtle, ways. <lfam>They will break when the host distro gets updated <mordocai>davexunit: What's the best way to do that? Currently I source .guix-profile/etc/profile but that keeps path intact <davexunit>mordocai: 'guix environment --pure' is one way <davexunit>you could also manually remove the stuff that keeps paths in-tact <iyzsong>mordocai: you may want to set 'GUIX_LD_WRAPPER_ALLOW_IMPURITIES' <mordocai>iyzsong: I'd prefer not to, but good to know it exists <mordocai>Almost to where I can run common lisp games with guix locally. <mordocai>So far i'm having to manually tell lisp to include .guix-profile/lib in my library path though for some reason, probably have to talk to #sbcl about that <davexunit>mordocai: is there a search path you need to set? <mordocai>davexunit: That's what I'm asking them, not sure. It seems to ignore LIBRARY_PATH <mordocai>Like loading libsdl or libGL or what have you <mordocai>Based on docs it may be looking for LD_LIBARY_PATH not LIBRARY_PATH <mordocai>Just learned about guix outputs, cool stuff. <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 <mordocai>calher: without looking probably guix package -i transmission:gui <lfam>It provides transmission-gtk. That's the GUI <calher>mordocai: it's not listed when i do -s <mordocai>davexunit: Both transmission and git have a gui output <mordocai>At least if I'm reading the package files correctly <lfam>It's there, I have it installed. <calher>It's there, but I obv. couldn't find :gui because :things are not listed. <mordocai>calher: Yeah, :<output> is what you are doing there. You can see the outputs udner outputs: <mordocai>In a manifest, how do you do outputs? Like I want git:send-email in my manifest. <davexunit>mordocai: you use a tuple, like (list git "send-email") <mordocai>Yeah, cool. I should read more carefully before asking :P <lfam>I'm watching / shrink as I install texlive-texmf. Will I have enough space?! ;) <mordocai>I had to upgrade my / for that on my laptop <calher>I can't do `guix pull' as root, can I? I did the `update from git' thing. <mordocai>calher: If you are updating from git you probably don't want to do guix pull. <mordocai>So i'm getting 14 out of 35 tests failed on gnupg(which causes a failure to install). Anyone know off the top of their head how to easily see what these failures are? <mordocai>I mean it tells me the name but i'd like to see why they failed <mordocai>mark_weaver: Nice, though I'm not seeing a solution in there. <mordocai>Anyone happen to know what will end up providing radeonsi_dri.so? <mordocai>My 3d stuff is trying to load it but i haven't managed to find what to install to get it <Jookia>mordocai: I think radeonsi_dri.so should come from mesa <mordocai>Jookia: Yeah, i've got both of those installed and no luck so far. <Jookia>Does Guix build with radeon support? <mordocai>Looks like it based on the the package files but there's logic around which drivers to use and I may be falling afoul of those <Jookia>mordocai: It looks like it's diabled: "--with-gallium-drivers=r600,svga,swrast,nouveau" <Jookia>Or rather, " '("--with-dri-drivers=nouveau,r200,radeon,swrast"))))" is only applicable to non-x86 <mark_weaver>mordocai: it might be that your gpu needs a non-free blob, and we don't provide those. <mordocai>mark_weaver: AFAIK it doesn't but I can't tell for sure yet <Jookia>mark_weaver: I think what's happened is that the radeon driver has been disabled as it was only recently added back to Linux-libre <mordocai>It definitely works without debian non-free if I remember correctly <mark_weaver>mordocai: did you get acceleration working on any other distro in FSF's free distro list? <Jookia>You won't get acceleration without firmware, but you will get basic things like KMS (I think) <mordocai>Looks like radeonsi is one of those that requires llvm <mordocai>Added it to that gallium-drivers list and that's the message I get <Jookia>I wonder if you could pull in LLVM? <Jookia>";; drop r300 from default gallium drivers, as it requires llvm" :\\ <yvm>On 79.4% of installation process I got "host name lookup error", domain names resolving becomes broken, though /etc/resolv.conf still has it's "nameserver" parameters. <yvm>How do I inspect what happened? <mark_weaver>yvm: I don't have an easy answer for how to debug it, but you might try "deco restart nscd" <yvm>Yep, this workaround works, thanks. <mordocai>Jookia: Well it found llvm at least... "radeonsi requires libelf when using llvm" <mordocai>Hmm... now it is complaining that it can't find llvm shared libraries <mark_weaver>mordocai: you might also need clang-runtime and maybe also clang <mordocai>mark_weaver: Yeah, I was wondering if it was that or that we need to build llvm with --enable-shared <mordocai>Trying to add clang is much faster than recompiling llvm so i'll try that first <mordocai>mark_weaver: I went the other direction and added "--disable-llvm-shared-libs" to the mesa configure flags. I imagine that is not a proper solution for guix though right? <mordocai>I guess. Basically makes it not need the shared libs <mark_weaver>have you checked that --enable-shared is not the default? <mordocai>I haven't downloaded it and checked yet though <mark_weaver>mordocai: --disable-llvm-shared-libs might be fine, and is probably the most expedient option for you. <mordocai>mark_weaver: Definitely most expedient. Running it that way for now. Should we try to go the other direction before I submit a patch though? <mordocai>Ah, it actually fails do to apparently (according to google) bad llvm flags. So i'll be having to rebuild llvm anyway <mordocai>Rebuilding llvm and mesa. If this ends up being the fix the patch is going to be much more significant. <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. <mordocai>mark_weaver: Nah, desktop. Card is "Radeon R7 370 / R9 270x/370" per lspci (I don't remember exactly since it has been awhile) <mark_weaver>mordocai: maybe replace it with a card that's well-supported by Nouveau <mordocai>mark_weaver: Yeah, it'll be a little bit before I replace any hardware but this time i'll pay more attention and try to get something more freedom respecting <mordocai>For now i'm actually running on top of debian testing so I should be able to get rendering with guix working if I can locally build the radeonsi driver. I think. <mark_weaver>note that modifying mesa forces rebuilds of most of the graphics stack <mordocai>Does guix detect that or will I have to cause that to happen in some way? <mark_weaver>so with a modified mesa you won't be able to use substitutes those things <mordocai>That part is fine with me, i'm using substitutes a little as possible anyway since I have a beefy desktop <yvm>Is it possible to install GRUB to MBR, not to partition? <mark_weaver>yvm: that's normally what we do: install GRUB to MBR <Jookia>yvm: What's the problem you're trying to solve? <Jookia>mark_weaver: Are you sure they don't mean not having a /boot partition <mordocai>Loving guix so far btw, gives me all the control of gentoo but a plethora of other advantages and so much easier to modify. <mordocai>Though since i've started using it i've spent all my programming time playing with it instead of writing my game :) <yvm>The problem is that on "populating '/mnt'' stage I got a message saying that ext2 doesn't support embedding and blocklists are UNRELIABLE, so installation of GRUB is failed. <mark_weaver>mordocai: yeah, if you're willing to do without binary substitutes, it gives you ultimate flexibility. <mark_weaver>mordocai: I always run guix from a git checkout of my local git branch, which includes my patches that are not ready to upstream yet. <mordocai>mark_weaver: Yeah, that's what I plan on setting up if I get my radeonsi stuff working. Though i'll upstream the LLVM stuff. <mordocai>and r300 if we decide it is worth llvm being required for mesa <mordocai>I think the llvm version might be too old for our mesa version. At least one of the mesa tests is failing. <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 <rekado>mordocai: do you have /etc/guix/acl? <mark_weaver>Jookia: my i686-based Libreboot X60 supports KVM afaik <mordocai>rekado: Yeah, and it has at least a public key in it <mordocai>Looks identical to the one on my desktop that works in fact <Jookia>mark_weaver: Something something microcode on T400 has broken KVM, so I can't test a change I'm making <Jookia>Changing the args of grub-install to take grub-configuration rather than a device arg <mordocai>Meh, I probably messed something up when I was doing stuff with it last week. I'll just reinstall guix <mark_weaver>Jookia: you could just remove --enable-kvm in the invocations of qemu in gnu/system/vm.scm and gnu/build/vm.scm <Jookia>I tried that but still got KVM errors <mark_weaver>I'm not sure what's needed, but it would be good to remove the requirement on kvm <marusich>Jookia, the libreboot documentation there says, "Working around this in QEMU might be possible; if not, software virtualization should work fine (it's just slower)." <Jookia>Let's see how long 'slower' is then ;) <marusich>Is it actually possible to work around? I'm not familiar with QEMU <marusich>But I'm very interested because I just ordered an X200 from MiniFree, myself <mark_weaver>Jookia: the additional complication is that auto-detection of KVM on T400 (and X200) will seem to indicate that it's available. e.g. it's listed in /proc/cpuinfo iirc. <Jookia>mark_weaver: Yeah, it's not good <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. <mordocai>Any changes there that upstream would be interested in i'm happy to prepare patches for. Bed for now though. <lfam>How does one remove old GuixSD generations? <rekado>lfam: AFAIK that's not exposed via the user interface, so it has to be done manually. <lfam>rekado: Can you point me in the right direction? <rekado>lfam: sorry, I don't know. Never done this. <lfam>I think this little QEMU VM has outlived its usefulness :) <Jookia>mark_weaver: qemu vm-image fails <lfam>It ran out of space in the image. <Jookia>But it panicked without ability to backtrace <lfam>You have to give it more space on the command line <lfam>It didn't even download enough software to give you a backtrace <lfam>`guix system vm-image --image-size=SIZE` <Jookia>I removed all -enable-kvm from the source code <marusich>Can you enter the BIOS and disable vt-x there, to make sure qemu isn't somehow trying to use it and triggering the problem mentioned in the libreboot docs? <Jookia>Because qemu's running the VM fine <marusich>Jookia, the libreboot doc says there is a failure mode where the guest panics but the host is fine. Isn't that what you're seeing? <lfam>I just pushed the new version of htop. It has a nice feature where you can press 'e' to view the environment of the selected process. <Jookia>marusich: No, Guix fails like this <Jookia>marusich: I've seen it happen on real hardware <marusich>Hm, I see. So you don't think the kernel panic in your paste is related to the problem mentioned in the libreboot docs. <lfam>The kernel panic in your paste is caused by not having enough disk space to assemble a working operating system <marusich>lfam, beyond the fact that the panic occurs right after the error about no space left on device, is there something that tells you that's why it happens? <lfam>Well, I can't ever be 100% sure. But I think it's a good guess since it happened while Jookia was downloading the initial components to install the operating system, and then ran out of space. <lfam>What can the kernel do but panic if the REPL software hasn't been downloaded yet? <Jookia>Doesn't Guix include its own REPL? <lfam>It wasn't downloaded yet <mark_weaver>and then the next time you run 'guix system reconfigure' it will generate a new GRUB menu without linking to the older profiles, and then you can GC them. <lfam>marusich: I also have no problems with KVM, and I get that same kernel panic when I run out of space while initializing a new system in QEMU <Jookia>"./gnu/build/install.scm:40:0: Wrong number of arguments to #<procedure install-grub (grub.cfg device mount-point libreboot?)>" bingo! time to be able to refactor and test things :) <Jookia>civodul: I'm trying to get grub-configuration passed in to qemu-image, but it only takes an os-derivation and a grub.cfg. Would it be worthwhile changing it to take just an os-configuration? <civodul>Jookia: maybe, but the difficulty is that we don't want it to recompute (operating-system-derivation os) several times <civodul>although eventually that should be memoized <efraim>so... libreoffice hit 5.1, but it took hydra 12.5 hours to build it on x86_64 <efraim>I'd be looking on the order of days on my laptop <Jookia>civodul: why not just compute it in the qemu-image functioni <civodul>dunno, it'd be more convenient for me to discuss by email :-) <Jookia>I'll write a patch and post it I guess <civodul>maybe you could send a message explaining what you think would be best? <civodul>and from there we can see if there are any blockers etc. <Jookia>civodul: I'll do what I think is kinda okay then post the WIP patch since it affects multiple parts of the system <yvm>I tried guix package -i iproute2, it starts ok, but then failed and told me that make-session variable is unbound. How do I remove all dependencies the command fetched? <alezost>yvm: could you provide a full output? <yvm>It's in Qemu and VT, so I can not copy-paste text. <Jookia>yvm: Change the pkg-config mirror to be non-HTTPS <alezost>yvm: But did you want to build everything from source? <alezost>oh, is it ok for you to download the built packages from hydra? <yvm>It's ok, but first I want to remove all the garbage that command just fetched. <alezost>all the garbage? you mean you want to remove it from store right now? <alezost>for downloading from hydra (I assume that substitutes are enabled), did you do "guix pull" recently? <yvm>Yes, the packages that guix package -i iproute2 downloaded. Since I don't need them. <yvm>I can find -mtime -exec rm "{}" etc, but maybe there is more convenient way? <civodul>oh, rather the substitute disappeared, i guess <alezost>yvm: you must never try to modify the store by hand!! there is "guix gc" command <alezost>yvm: actually there is no need to run "guix gc" every time you think the store has been polluted by some garbage. I clean my store rather rarely <yvm>I did not enabled substitutes manually (did not run guix archive). iproute2 is the first package I tried to install on this system. <yvm>guix gc works, thanks. <alezost>I thought substitutes are enabled by default in the latest release <alezost>civodul: I think iproute2 should be in %base-packages. We have both "iw" and "wireless-tools" but only a deprecated "net-tools" and not "iproute2" <alezost>yvm: same for me: iproute2 was the first and only package I have installed globally <alezost>cough, also our iproute is horribly outdated (it is probably a guilt of the person who noticed this fact) <efraim>I have iproute2 updated locally, I'll push it in a bit <alezost>efraim: oops, I've just sent the patches for updating iproute and adding it to %base-packages :-) <efraim>that's fine, we'll use your patch :) <alezost>efraim: no, I just noticed that iproute is outdated, so I updated only this package. Anyway you are the master of updates, so do whatever seems best for you! ***raulet_ is now known as raulet
<rekado>I'd like to update numpy to 1.9.3. <rekado>not sure if "guix refresh -l" is accurate; rebuilding both versions would directly affect 10+20 packages, that would again affect 14+32 packages. <rekado>should I wait with this until security-updates is ready? Or do you think it wouldn't hurt much if I did this now on master? <rekado>our version is already pretty old (end 2014) <efraim>I don't remember if python-ipython takes a long time, but it's not that many packages <efraim>guix refresh -t pypi says macs can also be upgraded <rekado>I think I did upgrade macs some days ago <phant0mas>civodul: I will rebase wip-hurd on master and push the new wip-hurd <phant0mas>civodul: I will spend some time this week to work on merging the two branches <phant0mas>I will not push anything before you give me the okay <civodul>i think one of the "psychological barriers" for me was the increased complexity of the GCC package <civodul>we should think about how to hide that complexity <civodul>for instance by moving some of the special phases to a separate file, say (guix build gcc) <pecg>Hello. Where can I find precise documentation about keyword/value pair symbols in scheme? such as #:use-module <rekado>pecg: the Guile manual documents this <rekado>trying to install a guix wrapper for the cluster <rekado>it should just be the latest guix but since it must run across all systems it has to sit on NFS and must only use inputs that are in the store <rekado>is there an easy way to pin the store items that are needed for guix environment guix? <rekado>right now I'm installing all dependencies for guix in a separate profile, "enter" this, configure there, then exit <rekado>"entering" a profile on a foreign distro is mildly "dangerous" when you just do eval $(guix package -p /path/to/profile --search-paths) <rekado>now with --search-paths=prefix, hoping that the profile is still close enough to being "pure" <fps>gravitational waves detection confirmed <civodul>rekado: what you're doing with a separate profile is the best we can do at the moment; 'guix environment' cannot save its profile yet <efraim>everytime I hear dentist I think about little shop of horrors <paroneayea>I guess I"ll find out in a minute if my system crashes :D <paroneayea>(the libreboot install I have doesn't support hardware acceleration and will crash in such a case......) <mark_weaver>paroneayea: yeah, we should definitely have a way to disable KVM on Libreboot machines with buggy CPU microcode <mark_weaver>there are two places where --enable-kvm is passed to qemu: gnu/system/vm.scm and gnu/build/vm.scm <mark_weaver>unfortunately, the kernel detects that KVM is supported. it is supported on the machine but buggy without a CPU microcode update <francis7>There might be a way to disable it from libreboot <df__>proprietary bioses tend to come with an option to disable vt-x... not sure how it works <paroneayea>I submitted a bug to bug-guix to come up with an option <mark_weaver>paroneayea: first, we should find a way to run qemu that works on a Libreboot X200 <mark_weaver>just yesterday I suggested that someone remove the --enable-kvm switches from the qemu command lines, and they said that it still didn't work. <francis7>can probably get same info using other utils <mark_weaver>this is something that can only be determined by someone with such a machine. and at the moment my X200 is kaput <francis7>that's not reliable for detecting X200 though <francis7>btw, I have an X200 that I can abuse for you <mark_weaver>francis7: are there any X200 machines without buggy microcode, where vt-x works? <mordocai>QT takes so long to download the substitute from hydra and, as I learned when I gave up, even longer to build... sigh <fhmgufs>mordocai: Long? Today hydra is really fast (for me). <mordocai>fhmgufs: Wasn't for me as of two hours ago. <fhmgufs>About ten minutes ago I downloaded around 1 GB texlive in less then 10 minutes. <mordocai>fhmgufs: Yeah, it probably just depends on when you hit it and how many other people are also hitting it at the time. <mark_weaver>mordocai, fhmgufs: and crucially, it depends on whether the substitute you're requesting is in the nginx cache <mordocai>Not sure if I have something setup wrong or what but the qt build appears to only be using a single core. That explains why it is taking so long. <mordocai>other builds seemed to use all cores if I remember correctly <mordocai>Haven't used this machine for a couple days though <mark_weaver>mordocai: our qt package has #:parallel-build? #f in its arguments, presumably because the makefile is racy <efraim>i checked my dmidecode, is it normal that I have 2xLAN ports? one labeled external and one internal? <efraim>later it says I have a broadcom ethernet nic and an atheros ethernet nic <efraim>perhaps that's how the hacked bios on my machine works, to defeat the lenovo wifi whitelist <fhmgufs>Could sb take please take a look at the 5 patches I've sent a few days ago? I would like to have some feedback. <dannym>efraim: (for comparison, on the X200 with libreboot, dmidecode doesn't mention the words "LAN", "Atheros", "Broadcom" or "NIC". That machine has one LAN port) <efraim>thanks. my machine also only has 1 LAN port ***keverets_ is now known as keverets
<paroneayea>ACTION sends / receives all mail through a tunnel <fhmgufs>Is gtk-doc really needing the full texlive distribution? <bavier>paroneayea: did adjusting SSH_PATH help at all? <paroneayea>I wrote up a new package and also tried adjusting the environment variable <paroneayea>I don't know what I'm doing when it comes to make flags :) <bavier>SSH_PATH would be a compiler macro definition, so you could add "CPPFLAGS=-DSSH_PATH=$openssh/bin/ssh" to #:make-flags <mark_weaver>mordocai: section 8.5 (Submitting Patches) has a few words about it <mark_weaver>the basic concepts are taken from the GNU coding standards for Change Logs, but with some minor formatting differences <mordocai>mark_weaver: Ah okay, I see it now. I was focusing more on the numbered steps than the preamble. <mark_weaver>for most patches, it's easiest to just look in our existing logs for examples <fhmgufs>How are the compiled gsettings schemas handled in Guix? I can't find anything in the sources. <fhmgufs>But if there are multiple ones they end up in the same profile directory. <fhmgufs>And only the last one gets installed. <mark_weaver>efraim: the CVEs you referenced in the update were already fixed in 1.8.1, which was the version we had before your update. <mark_weaver>and 1.9.x is the unstable development branch, whereas 1.8.x is the stable branch <efraim>no I didn't put it up for review first <efraim>I relied a bit too heavily on debian it seems, they've updated to 1.9.10 <mordocai>efraim: mark_weaver: Regarding your review of my patches, it looks like our line length limit is set to 90 not 80 per lint. <mordocai>Sorry, didn't need mark_weaver on that really :P <mark_weaver>mordocai: what do you mean by "our line length limit" ? <efraim>line 655 of guix/scripts/lint.scm <mordocai>efraim: same line i'm looking at, where it says 90 <cbaines>Trying to follow the Packaging Guidelines, do I need to use ./pre-inst-env if I am trying to build a package on GuixSD? <mark_weaver>mordocai: I guess we made lint a bit more permissive, but generally we try to keep lines to 80 columns. <mark_weaver>it's just that in some isolated cases it's hard to keep lines containing long hashes to 80 columns. <mark_weaver>so, we are willing to stretch the rules a bit in those cases, and want to keep the noise from lint manageable. <mark_weaver>but if your patch includes lines longer than 80 that are easily avoidable, then reviewers should push back on it. <mordocai>mark_weaver: Yeah, that's two standards from where I sit. Doesn't matter much in any case. Maybe guix lint needs pragmas <fhmgufs>Is there nobody having the same problem? The gschemas.compiled file is always the one of the most recently installed package. <mark_weaver>fhmgufs: looks like we have no code to merge gschemas.compiled files from different packages. maybe something should be added to %default-profile-hooks in guix/profiles.scm <mark_weaver>in the absense of anything like that, the most recently installed package with that file will take precedence. <mark_weaver>you might want to post to guix-devel with your proposal for how to handle it before working on it, though. <calher>Can I do guix pull if I updated root's guix stuff with git <mark_weaver>calher: if you run "guix pull" then it will overwrite the $HOME/.config/guix/latest symlink that you set manually <mark_weaver>but if you're running out of git, I'm not sure why you'd want to run "guix pull" <calher>goodammmit the git thing really ruins the beauty of the system <calher>mark_weaver: well i need to make sure everything's ok before i test a config <fhmgufs>mark_weaver: Shouldn't we just call 'glib-compile-schemas /path/to/profile/share/glib-2.0/schemas/' at the end of the profile build? <mark_weaver>fhmgufs: possibly, I don't know. can you email guix-devel about it? <rgrau>latest guile available is guile-next, right? <fhmgufs>ACTION has to sleep now, maybe he sends a patch tomorrow. 