<civodul>ACTION applies the big ghc-aws patch series <mb[m]1>Hello civodul! You're up late. :) <mb[m]1>So we're "stuck" on 5.5 for the time being. <civodul>of course that café wifi looked stable until i connected to IRC... <mb[m]1>The TL;DR is that GCC 6 and later "monkey patches" `stdlib.h` from glibc and uses an "#include_next" macro to load the real thing, but the search logic fails to locate the "next" stdlib.h if C_INCLUDE_PATH is set. <civodul>so what does it patch in glibc's stdlib.h? <civodul>perhaps we could patch glibc directly, assuming gcc's logic detects that stdlib.h doesn't need patching <mb[m]1>But the stdlib.h problem is the first that occurs when you try to rebuild the world with GCC6 (when building `gmp`) <mb[m]1>I've found many threads about it, and the "fix" is always to drop C[PLUS]_INCLUDE_PATH, which obviously won't work well for us. <civodul>it could be that #include_next is broken, in that it should honor C_INCLUDE_PATH <civodul>but at least, that's something to investigate <mb[m]1>Indeed. I won't have time before the next core-updates though... Should we try to aim for next weekend? Or do the Python thing first. <civodul>mb[m]1: i would leave GCC 6 for the next cycle, then <mb[m]1>I think we can merge it with 'core-updates', but I'd hate to regret that :P <civodul>because you'd prefer it to be merged earlier? <mb[m]1>In case we end up having to update half of the Python packages :) <civodul>Steap was kinda working on updating packages <civodul>Steap: did you stop at packages starting with 'a', or did you have a chance to go further? :-) <civodul>mb[m]1: now, many Python packages can be upgraded without doing a full rebuild <civodul>so we should focus on the ones with a high "rank" <mb[m]1>Anyway I'm off, will check back here tomorrow (this Matrix bridge is pretty sweet, apart from my stupid name). Good night! <Steap>civodul: I puished a few updates last night <ngz>Ah well. scribus > me. I have an almost working update, which builds, but fails miserably when calling the program with "ImportError: No module named _sysconfigdata_nd". Oddly, it complains about /usr/lib/python2.7/site.py. I don't even know where to investigate. <civodul>if not, there might be a hard-coded /usr/lib that needs to be fixed <Steap>ngz: maybe this module is missing from our Python install :/ <mb[m]1>Steap: FYI, watch out for source URI changes when using the Python updater, I had to change chardet to use 'pypi-uri' because the previous URL was 404. You probably didn't notice because the updater had already downloaded the tarball to your store. <Steap>I can "import _sysconfigdata_nd" using Debian's python2, but not Guix's <ngz>civodul: It's from plain Guix <Steap>mb[m]1: this happened with another package that I updated, and I changed the URI <civodul>ngz: so the thing seems to be trying to load stuff from the underlying distro's Python, which is bound to cause problems <ngz>That's also what I think. The problem is to know where the leakage happens. <ngz>There are a couple of /usr/lib in the codebase (in .cmake files), but they look rather harmless. <civodul>i suppose you could check the value of PYTHONPATH <civodul>perhaps test with 'guix environment --pure --ad-hoc scribus -- scribus' <civodul>and then strace the whole thing to see whether it's accessing /usr/lib stuff <ngz>IIUC, the command above is going to call scribus. Where can I sneak in the strace command then? <ngz>Ah well, I cannot pre-inst-env guix environment... gnu/services/shepherd.scm:90:2: In procedure allocate-struct: Wrong type argument in position 2: 5 <ngz>I have the strace output in a regular pre-inst-env build (no guix environment command), if you're interested. I see it tries to open various Python locations, including in .guix-profile/ and /usr/lib ... <ngz>civodul: Makefile:2958 : la recette pour la cible « configure » a échouée <ngz>error: possibly undefined macro: GUILE_MODULE_AVAILABLE <ngz>Well, I give up for today. <Apteryx_>is kvm used by default when using the 'qemu-system-x86_64' executable? <rekado>today berlin.guixsd.org will be temporarily unavailable. <efraim>Apteryx_: qemu uses KVM if its available <rekado>if all goes really well today it will be back by the end of the day. <rekado>ACTION tries to split up the patches from bug#26776 ***fr33domlover1 is now known as fr33domlover
<aravind>hi, I am attempting my first local revision to guix - I need an updated version of python2-websocket-client and the all of my attempts to build it have failed. I did some digging around and it appears that the new requirements in that python module pull some stuff from the network in the test phase of the library. <aravind>more digging around tells me that the guix build process essentially kills all network access during the build/test part - which explains why my attempts to build it are failing. <aravind>when I try a "python setup.py test" manually after sourcing the environment settings for that module - stuff works just fine. <aravind>I'd appreciate any hints/suggesstions on how I could proceed next. <roptat>aravind: I can se two solutions: either remove that test, or create a package for the test resources <aravind>the other thing - creating a package for the test resources, I am not quite sure what that means. <roptat>ok, it's an additional dependency actually, not a resource <aravind>yeah, it attempts to download that during the test phase.. <roptat>sometimes packages fetch test data, and it's easy to fix by fetching that data ourself <roptat>I'm not very good with python, does that mean that it requires 'ssl_match_hostname', specifically compiled with python 2.4, 2.5 or 2.6? <aravind>heh, me neither :-) I just need that damn library to be at 0.44.0! <aravind>I will attempt to understand what it needs and why it downloads it, and if I can fetch it ahead of time.. <roptat>could you try adding "python2-backport-ssl-match-hostname" to the native-inputs? <ngz>Hello. Do you know how I can get a clean Guix repository again? From HEAD, when I run ./boostrap, I get "error: possibly undefined macro: GUILE_MODULE_AVAILABLE" and if I try ./configure, it stops with "line 7052: syntax error near unexpected token `2.2' `GUILE_PKG(2.2 2.0)'". <ngz>Of course, I can delete everything and clone repository again, but I'd rather not lose my local branches. <roptat>guix environment guix doesn't work? <ngz>It does. What I'm supposed to do from here? <roptat>now you can try to ./bootstrap configure ... <ngz>It seems to work. Thank you. How often am I supposed to do that? After each git pull ? <ngz>"make" failed actually: gnu/services/shepherd.scm:90:2: In procedure allocate-struct: Wrong type argument in position 2: 5 <roptat>if no one helps you, I'll be back in about an hour <ngz>OK. Thank you for your help already <ngz>You could try --with-source=/url/to-/1.13.10.tar.gz when installing wesnoth <ngz>Or define a new package that inherits from wesnoth, but set a different source and updates hash. ***pksadiq_ is now known as pksadiq
<roptat>ngz: try make clean-go before make <efraim>ngz: after 'guix package -i $vim-plugin' what do I need to do? 'vim +PluginUpdate'? <ngz>efraim: no idea, I don't use Vim :) <ngz>roptat: It worked. I can run scribus in guix environment now. Funnily, it doesn't work outside that environment. <roptat>can you describe how you installed scribus and how you run it? <ngz>I didn't install it. I built it and called the executable from the store. Granted, this is cheesy. <brendyn>How can I purge my guix binary install except for /gnu/store and reinstall it? <ngz>roptat: If it runs correctly from guix environment, can I assume the package definition is correct? <roptat>ngz: you can also create another environment with "guix environment --ad-hoc scribus", where the scribus binary would be available in the PATH <ngz>I used guix environment --pure --ad-hoc scribus -- scribus <Apteryx_>efraim: OK, the doc suggests it uses tcg as acceleration by default. I pass "-enable-kvm", just to be sure. <Apteryx_>Has anyone successfully bridged a QEMU virtual machine network with its host? I'm trying to do just that, and the options usable through -netdev are a bit overwhelming :). <Guest67041>I just tried on Ubuntu and I get the same error, so apparently this is not GuixSD specific. <nee`>Apteryx_: Guest67041: I don't know anything about qemu, but I have an old hurd.sh file that looks like this: qemu-system-i386 -m 512 -net nic,model=rtl8139 -net user -drive cache=writeback,index=0,media=disk,file="$DISK" <mb[m]1>`guix pull` currently fails with "no code for module (guix build compile)" <efraim>Compile did just move around earlier <rama_dan>i saw a presentation about Guix where someone said there are plans for a "guix deploy" command, that seems like it would be quite delightful :P .. but how would deploying to "bare metal" work, for example? <rama_dan>and does anyone know about a VPS provider that would support GuixSD? or are you all using some kind of custom images to run it? <efraim>Some people take a base install of another distro and run guix system reconfigure on it <efraim>Yeah, assuming it boots through grub <rama_dan>well, i have no idea about boot loaders for example <rama_dan>efraim do you think not having guix available for my (Mac) desktop would be a problem for SaaS app workflow needs? <rama_dan>i mean, on the desktop, i can only use Guix(SD) through virtualization, right? <efraim>I don't really know much about macs <rama_dan>btw, does anyone know if Guix will ever work on a mac? <rama_dan>or if it's already known it won't happen <efraim>I don't believe anyone is working on it <efraim>I don't know of a bootstrap path for Mac though <rama_dan>i think it might actually be necessary for getting businesses to adopt guix(sd) <rekado>berlin.guixsd.org is back in operation <rekado>I might need to power cycle a couple of build nodes tomorrow, but that should not affect availability of substitutes much. <rama_dan>jonsger[m] interesting discussion there :) it seems getting guix to work on macs would be doable <lfam>rama_dan: The VPS hoster Serveraptor offers GuixSD <aravind>hi, I made some local changes to a python package and got it to build. It created a drv.bz2 file, how would I now install this into my guix environment? <aravind>I am guessing this is a derivation file, but not the same as an actual package. I am a bit lost on what I would have to do to make this a package and install it locally. <bavier>aravind: 'guix package -i <the-package>' <htgoebel>aravid: the drv.bz2 is the log-file. The built package is in the store. <sirgazil>Hi, I'm running guix (GNU Guix) 20170802.00 on Debian 9. When I run "guix pull" as a normal user, I get: <sirgazil>guix pull: error: build failed: build of `/gnu/store/z99jmrjnzd30w28px70qp4q0s1pc34g3-guile-git-0.0-3.e156a10.drv' failed ***TaoHansen[m] is now known as taohansen
<sirgazil>I decided to guix pull from root, and guix told me I needed to "guix package -i guile-git" and export some variables. So maybe that was the root of my problem... <lfam>sirgazil: What your log shows is that guile segfaulted during the build of guile-git <lfam>In the penultimate line, it shows the thing that failed: builder for `/gnu/store/z99jmrjnzd30w28px70qp4q0s1pc34g3-guile-git-0.0-3.e156a10.drv' failed with exit code 1 <lfam>That's the derivation that was used to build guile-git <lfam>A few lines up you can see the segmentation fault is reported <lfam>Well, I'm not sure if bash or guile suffered the segmentation fault. I don't know the error reporting convention <sirgazil>lfam: thanks. Do you know what should I do? I don't understand the problem :) <lfam>sirgazil: I'd run the command again and report the failure to <bug-guix@gnu.org> <aravind>bavier and htgoebel thank you, that worked. <sirgazil>ACTION sees lfam already reported the same bug I just sent. <htgoebel>ACTION is a bit frustrated: KDE plasma will be a long way. I stepped over issues caused by out build of Qt :-(