***Acou_Bass is now known as eddie
***eddie is now known as Acou_Bass
<Apteryx>laertus: when your local guix is done, you can use it to upgrade your user guix, like "./pre-inst-env guix pull". And then, unless you want to work on guix itself, you don't need to use the git checkout anymore. <apteryx[m]>You don't need to run make install or make check. I think some tests are known to fail. <laertus>so does that "./pre-inst-env guix pull" use the old guix-daemon that i have running? <laertus>and that won't mess it up even though it's older than the guix i just built? ***Acou_Bass is now known as eddie
***eddie is now known as Acou_Bass
<clacke[m]>I'm trying to use 'guix import pypi', but I always run into this: <clacke[m]>> guix/build/download.scm:425:6: X.509 certificate of 'pypi.python.org' could not be verified: <clacke[m]>is there some guile-specific environmental variable that should be set for TLS to work? <clacke[m]>It successfully gets other things over https I think, it's just import pypi that makes trouble <clacke[m]>guix on Ubuntu, haven't tried to do this in GuixSD, where it probably Just Works. <IpswichTriptych>I'm trying to configure my system so I can SSH into it, and I'm getting the following after "guix system reconfigure /etc/config.scm" : <IpswichTriptych>My config.scm looks like this: (services (cons* dhcp-client-service) (service openssh-service-type (openssh-configuration (port-number xxxxx))) (xfce-desktop-service) %desktop-services)) <IpswichTriptych>...I guess it is unnecessary because DHCP is handled by xfce-desktop-service? <IpswichTriptych>i removed (dhcp-client-service) and it seems to be working, I'm going to try this and see how it goes! ***Piece_Maker is now known as Acou_Bass
<rekado_>the pandas developers say that we shouldn’t use numpy 1.13. <rekado_>so, I’m going to have to upgrade pandas to latest from git to make it work <nee`>What's the difference between native-search-paths and search-paths? <rekado_>the difference between “native” and non-native is important for cross-compilation <rekado_>“native” means that the search paths apply for executables that run on the host architecture <nee`>So native-search-paths seem to be the default. I only see search-paths used in cross compiler packages like cross-base.scm and mingw.scm. What happens with the non-native search paths? The cross compiling host can't use them, so are they passed to some kind of test vm? <rekado_>pandas from git also fails its tests. 19 failures and 2400+ errors. <rekado_>it simply won’t work with the latest numpy <rekado_>I wonder if I should revert the numpy upgrade and make it available only as numpy-next :-/ <civodul>rekado_: perhaps that's the best way short-term <civodul>that may give an incentive to whoever upgraded numpy, too ;-) <civodul>looks like another variation on the theme, pretty cool <civodul>rekado_: are you going to the R-B summit this year? <rekado_>this year I travelled more than I thought I would, and I think I’ve got to slow down a little :-/ <civodul>but we should find someone to be there, it'd be a shame to miss out on that <civodul>i'll also send a message on the list <rekado_>I feel a bit out of the loop wrt the reproducible builds effort <civodul>well, it's informal and still fairly Debian-centered <civodul>but i found the summits to be fruitful <rekado_>I’m more enthusiastic about the bootstrapping efforts, to be honest <rekado_>I find Linux rather limiting in terms of reproducibility <rekado_>I would love to have more parts of the system be under management of Guix <civodul>and yeah, the bootstrapping efforts are exciting, but we're not done yet with reproducibility IMO <rekado_>I really want to have a Hurd-based system instead of a big Linux blob. <rekado_>especially at work with big shared systems I often dream of using the Hurd instead <rekado_>wrt reproducibility I agree that we are far from being done, but on the other side I see little overlap with other systems <rekado_>the biggest overlap is upstreaming reproducibility fixes <civodul>but then there are the issues of pushing repro to users <civodul>the bits i just wrote to the list actually :-) <civodul>i think that's the most interesting part <civodul>and there are good ideas floating around there <janneke>civodul: nice! i had a pretty negative set of responses to using tcc as a bootstrap compiler <civodul>i can't wait to have gcc@1.27 in Guix :-) <janneke>i have been thinking about redirecting my efforts away from tcc <civodul>maybe MesCC can be made self-sufficient after all? <thomasd>janneke: is this discussion somewhere in public? i'm curious about the reasons <janneke>it's not so bad, i/we could do with thinking things through again <janneke>civodul: yes, maybe we should work to make mescc a(n almost) full C compiler <janneke>civodul, thomasd: had i anticipated this, i would have tried to write more toughtful mail <janneke>and i may still do that when i have made up my mind about things <civodul>janneke: do the examples you gave in that message really simplify compiler implementation? <civodul>my gut reaction is like that of Edmund in that thread <civodul>is someone looking at the 'staging' branch? <bavier>haha, yeah, gcc@1.27 would be fun(ny) <lfam>civodul: I haven't been paying attention to this staging cycle <lfam>I think mbakke was working on it originally <civodul>lfam: yes, mbakke is still taking care of it <lfam>Me too, but I had to take a break <janneke>what i do know is that i could compile mes.c with a next to trivial c compiler last christmas <janneke>i have worked very hard for more than half a year to get tcc compiled, dumbing tcc down and making mescc smarter <janneke>but without applying much compiler-engineering thought <janneke>i can easily imagine a tcc-like compiler implemented in a mes.c like flavour of C <janneke>that would require only a very simple bootstrapping C compiler, much simpler than mescc is now <civodul>well, there's a risk of walking a road very much like tcc's again <civodul>it starts simpler, then gets just as complex <janneke>indeed. i was hoping to embark on a way making tcc written in simpler and simpler C, and removing features from mescc <janneke>and thinking about the end goal: a bootstrapping path that can be reviewed <janneke>i'm not sure if tcc should be a part of that <janneke>civodul: i cannot get nmtui-connect to work with network-manager-openvpn, did you succeed to do that? <janneke>i created a vpn connection with nmtui-edit, but connect says <janneke>Error: Connection activation failed: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed. <civodul>janneke: actually i didn't even find how to choose a VPN in nmtui <civodul>how did you select a VPN connection? <janneke>civodul: i think i'm lying...history shows i probably created it with nm-connection-editor <civodul>i don't even have nm-connection-editor, where is that? <janneke>inside: guix environment --ad-hoc network-manager-applet <janneke>ACTION would really like to get dns working over vpn <efraim>Hmm, gmp failed to build for me on core-updates with GCC6 <laertus>when guix builds gcc i see stuff like "warning: gcc/cc1plus-checksum.o differs" ... is that a benign warning? <efraim>gcc has its own checks, if its actually a problem it'll fail the build itself <janneke>rekado-web: i've been thinking to go to reproducibility summit, sad to hear civodul won't be there, are you coming? <rekado-web>I'll ask my boss; pretty sure this can count as "work" <janneke>i'm kinda stuck with mescc, or i could do with some perspectives on how to move forward <janneke>possibly, i want to explore some possibilities <janneke>take some time and find somem people to think and brainstorm <mb[m]2>efraim: I found the same thing about gmp only yesterday, actually. <mb[m]2>"/gnu/store/58nmwxbiv52m4cgb44jvv3p0rnwkap0q-gcc-6.4.0/include/c++/cstdlib:75:25: fatal error: stdlib.h: No such file or directory" <taylan>happy_gnu[m]: guix uses its own "tree" of dependencies all the way down to the standard C library, so it's normal that it installs a lot of recursive dependencies the first time you start installing packages, even if they're small packages themselves. and it resorts to compilation when the build farm hasn't compiled the exact version of the package you're installing yet. also make sure you even <taylan>authorized the Hydra build farm, otherwise it will compile everything. <taylan>happy_gnu[m]: BTW please don't use the enter key like a comma ;) <Apteryx>Do we have anything else than LibreOffice to read .odt files? <Apteryx>No substitute for LibreOffice and I only need a viewer. <Apteryx>rekado-web: I saw the video of GHM where you were discussing bootstrapping. It was pretty interesting/entertaining, thanks! <taylan>happy_gnu[m]: I mean typing a lot of short lines one after another on IRC. some people consider it rude as it clutters the screen. no offense. :) <happy_gnu[m]>Exactly what you asked, is only a viewer, not editor, to edit I think you can convert them to org mode and then convert them to odt again <bavier>Apteryx: I think abiword can read odt <happy_gnu[m]>Anyway you coul also use pandoc or something to convert from odt to org mode, HTML or whatever, after all you just need to see them <apteryx[m]>happy_gnu: oh, I have to read more about odf-mode; I didn't know about it. It might not require LibreOffice. Thanks for the link. <happy_gnu[m]>Yes I use Emacs to view odt files when I just need a quick look <apteryx[m]>happy_gnu: not Emacs but modes like doc-view-mode allow reading ODT if you have libreoffice available. <happy_gnu[m]>But I have libreoffice installed so I didn't thought about that <happy_gnu[m]>Both options can be good though, using emacs oto view them, or just convert them to something else with pandoc. Also bavier suggested abiword <taylan>that's probably better for people with small screens, yes ^_^ <bavier>all these new guile-package dependencies make installing guix difficult <civodul>bavier: would the binary install be an option for you? <civodul>oh you're talking of guile-json, guile-git, etc., right? <bavier>civodul: I don't think so, I'm trying to install on an aarch64 system <bavier>it doesn't help that bytestructures doesn't even have a makefile <civodul>Guix doesn't depend on bytestructures, does it? <civodul>taylan: ↑ we need ./configure && make :-) <bavier>I've been able to use GSRC in the past for a lot of dependencies, but it doesn't package many of these newer guile packages <bavier>maybe I need to fix that, I guess <laertus>my guix build has been hanging for hours at "BOOTSTRAP GUILEC ice-9/psyntax-pp.go" <civodul>bavier: i think that calls for a way to build Guix gradually: first the core, then the bells & whistles that require guile-* <mb[m]2>Nooo, no FOSDEM room next year :O <bavier>efraim: thanks, I'll keep it in mind <civodul>mb[m]2: BTW, i'm upgrading imagemagick on staging, to fix the Emacs issue <mb[m]2>civodul: wasn't that fixed by 6d89a1ab4e1d886e857e8490091a61f91603f5b9 ? <castilma>I have a problem with the lsh service in default configuration. i need to enter a password even though i have public key authentication enabled. do you experience the same? <castilma>k, resolved it by reading the friendly manual. authorizing keys works different with lsh than with ssh.