IRC channel logs


back to list of logs

<civodul>Hello Guix!
<civodul>ACTION applies the big ghc-aws patch series
<mb[m]1>Hello civodul! You're up late. :)
<mb[m]1>FYI I gave up on the GCC-6 endeavour after hitting <>.
<mb[m]1>So we're "stuck" on 5.5 for the time being.
<mb[m]1>Hm, not sure how that line break made it in. Here:
<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>and GCC 5 doesn't do that?
<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>It's more than just the `stdlib.h` monkey patching, here is another example:
<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>uh, indeed
<civodul>it could be that #include_next is broken, in that it should honor C_INCLUDE_PATH
<civodul>or maybe not
<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
<civodul>i think that's fine
<civodul>what's the "Python thing"?
<mb[m]1>The shiny new python-updates
<mb[m]1>I think we can merge it with 'core-updates', but I'd hate to regret that :P
<civodul>oh right
<civodul>why regret?
<civodul>ACTION is confused :-)
<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>That's true.
<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!
<civodul>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/ I don't even know where to investigate.
<civodul>Steap: awesome
<civodul>ngz: is it on GuixSD?
<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
<Steap>mb[m]1: oh right
<ngz>civodul: It's from plain Guix
<Steap>mb[m]1: this happened with another package that I updated, and I changed the URI
<Steap>netaddr iirc
<mb[m]1>Goodie :)
<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
<ngz>How so?
<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 ...
<civodul>ngz: try "make clean-go && make"
<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.
<ngz>Good night!
<Apteryx_>is kvm used by default when using the 'qemu-system-x86_64' executable?
<civodul>hey hey!
<rekado>Hi Guix!
<civodul>hey rekado!
<rekado>today will be temporarily unavailable.
<efraim>Oh no!
<efraim>And tomorrow too you said
<rekado>yes, probably
<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>specifically this -
<aravind>when I try a "python 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>this probably isn't something I can remove (test wise)
<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?
<aravind>will try it and report back
<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>Let me check
<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
<aravind>roptat: woot! that worked :)
<aravind>thank you!
<roptat>aravind: you're welcome :)
<roptat>ngz: sorry, I have to go
<roptat>if no one helps you, I'll be back in about an hour
<ngz>OK. Thank you for your help already
<Necrosporus>How to install Battle for Wesnoth 1.13.10 ?
<Necrosporus>1.12.6 is stable version, but it's pretty old
<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
<ngz>roptat: ok
<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 :)
<efraim>Oh :p
<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>I think so
<roptat>ngz: you can also create another environment with "guix environment --ad-hoc scribus", where the scribus binary would be available in the PATH
<roptat>it's cleaner ;)
<ngz>I used guix environment --pure --ad-hoc scribus -- scribus
<roptat>oh, yes then it's fine
<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 :).
<Apteryx_>Here's my current attempt and error:
<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 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
<rama_dan>efraim will that "turn it into GuixSD"?
<rama_dan>ACTION is a noob :p 
<efraim>Yeah, assuming it boots through grub
<rama_dan>well, i have no idea about boot loaders for example
<rama_dan>but i suppose that would be an option
<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>but i can't tell if that's a problem
<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)
<rama_dan>(at least on a larger scale, ofc)
<jonsger[m]>rama_dan: there was a discussion about guix on Mac I think running Guix/GuixSD in a virtualbox or something like that, is far more easy :)
<rekado> 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
<sirgazil>Longer output:
<sirgazil>I don't know what I'm missing :)
***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 <>
<sirgazil>lfam: Ah, ok, thanks.
<aravind>bavier and htgoebel thank you, that worked.
<bavier>aravind: great. :)
<sirgazil>ACTION goes to report bugs
<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 :-(