<xshumeng>Hi, guys. How to use proxy when i run 'guix system init ...'. i tried configure 'http_proxy' and 'https_proxy' environment variable, but i could't captured any package. ***jonsger1 is now known as jonsger
<laertus>after building guix from git source, and trying a "./pre-inst-env guix pull" i'm getting that "output path `/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz' should have sha256 hash `1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa', instead has `1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka'" error again <laertus>i don't understand why i'd be getting that error again even though before i built guix from source, i did a "build --source guile-git --subsitute-urls=https://mirror.hydra.gnu.org" and a "guix build guile-git" <laertus>am i going to have to repeat that process again? <janneke>laertus: wasn't the previous error for version 0.25.1? <ng0>is there a particular reason other than "someone needs to do it" that Guix is using the throw primitive instead of srfi-34 (at least by what I found through grep) for errors? I got curious about Guile and exceptions handling while reading into what needs to be done in gnunet-guile <Sleep_Walker>in my system configuration I need to alter configuration of elogind-service - do I have to remove it from %desktop-services and re-add with configuration again? <efraim>you can also use modify-services <ng0>oh. bad reading of the results from my side then <rekado>Sleep_Walker: that’s what I’m doing to add udev rules <Sleep_Walker>it seems pretty advanced and undocumented for common users I'm afraid nice to kee <rekado>Sleep_Walker: you’re right. There’s very little documentation about udev rules. <laertus>well, i just did another "./pre-inst-env guix build --source guile-git --substitute-urls=https://mirror.hydra.gnu.org" and when i try "./pre-inst-env guix build guile-git" i still get ""output path `/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz' should have sha256 hash `1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa', instead has `1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka'" <laertus>oh, wait, why should i expect "./pre-inst-env guix build --source guile-git --substitute-urls=https://mirror.hydra.gnu.org" to have any bearing on this issue.. that's guile-git, not libgit2 <laertus>nope.. it doesn't like that either.. same error <efraim>It looks like mirror.hydra.gnu.org doesnt have that available <efraim>I'd try hydra.gnu.org to route around the caching server, and then you might have to try a different substitute server <efraim>I don't remember if hydra.gnu.org is http or https <efraim>I would try berlin.guixsd.org next ***pksadiq__ is now known as pksadiq
<efraim>might need to turn off parallel tests on mongodb, 4gb of ram and 7gb of swap and i'm down to the last 500 MB <ng0>also berlin.guixsd.org <efraim>i suggested berlin before i think <ng0>when cURL is build with idn support, why is it still using libidn-1.33 instead of libidn2? My local attempts with it in an environment put out this after configure: IDN support: enabled (libidn2) <ng0>its configure.ac wants -lidn2 <ng0>of course this doesn't fix my own issue… or can one use libidn-1.33 as a -lidn2 ? Because otherwise I'd image curl would've failed to build here. <jherrlin>hey guix! i am trying to get openvpn running with networkmanager-openvpn, as a client. <jherrlin>i think i got my nmcli config correct, but then running =nmcli con up vpn= i get *Connection activation failed: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.* <jherrlin>when looking at =herd status= i dont see openvpn running <warreq>jherrlin: what is the output of =herd start openvpn=? <jherrlin>warreq: *herd: service 'openvpn' could not be found* <jherrlin>i havent added =openvpn-client-service= to my services in my system config. <warreq>I haven't tried running openvpn on guix myself, but I'm pretty sure you'll need that service installed if you want shepherd to manage it. If you don't have a service definition, shepherd doesn't know about the service. <warreq>Alternatively though you could get it running by calling openvpn yourself, with your .ovpn file (assuming that's what you're using). Does that work? <jherrlin>i havent tried doing in manually, will do that! <warreq>How can I avoid needing to =guix pull= and =sudo guix pull=? I basically want root to always be synced with my primary user. Unless there's a good reason to not do that? <cbaines>warreq, change one of the ~/.config/guix/latest symlinks to point to the other one <cbaines>so in this case, change /root/.config/guix/latest to be a symlink to point at /home/warreq/.config/guix/latest <warreq>Oh. Well that's pretty easy then! :) Thank you for the help. Is there any downside to doing this? I can't immediately think of one. <laertus>efraim: i tried bayfront and flashner, and got the same error <laertus>is there any other way to get around a "output path `/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz' should have sha256 hash `1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa', instead has `1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka'" error apart from trying "guix build --source libgit2 --substitute-urls=foo" ? <ng0>create a local variant <ng0>you define a GUIX_PACKAGE_PATH and you create a module which holds a libgit2 with the corrected hash that now takes priority over the guix master one <rekado>ng0: that wouldn’t help with whatever needs libgit2, unless you’d also override libgit2 in the complete graph. <rekado>are you sure that the package in GUIX_PACKAGE_PATH would be preferred? <rekado>in any case, wouldn’t that also cause a rebuild of whatever depends on libgit2? <ng0>as far as I understand GPP it takes priority over the gnu/package definitions <ng0>now if it solves the entire path, I can't say for sure right now <rekado>why do we have a hash mismatch? When did that happen for libgit2 0.26.0? <ng0>*if it applies on the entire path <rekado>if that’s an actual hash mismatch, it still isn’t fixed in master <ng0>I can still build it <laertus>rekado: i'm guessing it's the same issue as what hit 0.25, which is that github tarballs are autogenerated and aren't guaranteed to be the same the next time github generates them <rekado>laertus: I got libgit2-0.26.0.tar.xz from mirror.hydra.gnu.org <ng0>if you do 'guix build --no-grafts --no-substitutes libgit2' on HEAD you get the mismatrch laertus reported <rekado>it is confusing that “guix hash” on that downloaded libgit2 source archive does return the new hash <ng0>new (on github) is 1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka , hydra.gnu.org has 1w1mabk8pzx6xrywcgl37k3akrjbx1x6qkji7gf13dk6fp9rf20d <Apteryx>ng0: we already have a bug about libgit2 hash change <ng0>Apteryx: okay. but my bug is more about dealing with all of github tarballs <Apteryx>right. there's also a list of affected packages that got posted by janneke in the libgit2 thread. <Apteryx>Maybe it should be at least linked in the new bug. <laertus>ng0: you wrote that a way to try to work around this error might be to "define a GUIX_PACKAGE_PATH and you create a module which holds a libgit2 with the corrected hash" <Apteryx>laertus: are you still trying to update your guix without use of substitutes? rekado said he could get a substitute for libgit2 earlier; doesn't this solution work for you? <Apteryx>I have this interesting problem where Geiser/Guile REPL in Emacs become completely unresponsive, and top doesn't show any resources being actively used... Any ideas or bug to follow? <Apteryx>I could reproduce from a stand-alone Guile interpreter... It locked in the same way. When I did C-c to interrupt it printed many lines like: ERROR: In procedure %readline: readline is not reentrant <laertus>you could try in emacs doing a M-x toggle-debug-on-error and seeing where that gets you when you C-c out of it <laertus>it should throw you in to the debugger and at least show you a stacktrace <Apteryx>Seems the process is looping on that %readline error. I'll try commenting activation of readline from my ~/.guile init file. <laertus>Apteryx: i'm trying with substitutes and it's failing: "./pre-inst-env guix build --source libgit2 --substitute-urls=https://hydra.gnu.org" fails with ""output path `/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz' should have sha256 hash `1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa', instead has `1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka'" <Apteryx>laertus: it must be falling back to download from github instead of the cached copy at hydra? You probably can tell this by looking at the output. Make sure substitutes are enabled/substitutes servers authentified. I'm not sure if --substitute-urls would override "--no-substitutes" if you are running your guix daemon with such an option. <laertus>i am running my daemon with --no-subsitutes <Apteryx>I guess it should though. Consider reporting a bug if it doesn't. <laertus>the other day someone told me that --substitute-urls would override it <Apteryx>yes; it would make sense that it does! but since you have problems downloading substitutes, verifying this would give us the confidence it indeed works. <laertus>looks like when i ran my guix-daemon without --no-subsitutes, it worked <laertus>so "guix build ... --subsitute-urls=foo" does not override guix-daemon being run with --no-subsitutes <Apteryx>laertus: please report this as a bug to bug-guix@gnu.org. <ng0>would someone like to review the nototools patch series next week that I've sent a while back? <Sleep_Walker>how can I get rid of system generations which are just not needed anymore? `guix package' allows to delete generations but I see no such option in `guix system' <Sleep_Walker>`guix gc -d' refuse to remove path as it is still active <efraim>you have to manually delete the symlink <warreq>Any of you folks running GuixSD with no login manager, just calling startx directly? If so I'd love to see your system.scm. <warreq>I got a shell script that uses xinit to get X up and running, but I have to run X with setuid and in general the setup seems to go against the point of Guix. <alezost>I also don't use any login manager, but I use shepherd user service to start X server for me <warreq>alezost: Ahh, Kooda is actually who I pillaged most of my setup from. :) I'm interested in your setup, though. It would be preferable to me compared to having Xorg running with setuid. <alezost>it is too specified for my needs, I doubt it will be useful for anyone else though :-) <warreq>alezost: Thanks for the writeup, and thanks for sharing. :) It's good inspiration. <jherrlin>hey, i am still having problem with networkmanager and openvpn <jherrlin>when i use =(openvpn-client-service)= in config i an error when trying to reconfigure <civodul>jherrlin: at first sight it looks like a bug in the openvpn service <jherrlin>when is says: [#:config (openvpn-client-configuration)], the arguments are optional right? <civodul>right, square brackets mean it's optional <civodul>could you report the issue to bug-guix@gnu.org, Cc: Julien Lepiller <julien@lepiller.eu> ? <civodul>jherrlin: well maybe you should still report it to bug-guix so we can better keep track of it <jherrlin>civodul: okey, how should it be formated? and what should it contain? <civodul>jherrlin: send a GuixSD config that reproduces the problem, along with the backtrace that you get <civodul>the config can be the bare-bones.tmpl example, with just (openvpn-client-service) i guess, right? <efraim>wow mongodb requires a lot of memory to compile <efraim>11GB between ram and swap, I'm about to go OOM again <cbaines>efraim, what kind of parallelism is that with? <efraim>scons for building, I already tried with parallel-tests? #f <cbaines>I've build MongoDB successfully on a machine with only 2GB of ram + 2GB of swap <cbaines>maybe it'll use more memory if you compile with more cores <cbaines>efraim, if I remember correctly, I think it respects the parallel job count <thomassgn>how do I deal with an empty drv in store? 'file' returns: "/gnu/store/m1vlmi1b3bcp81j3siksmhvva8fmvcz6-libev-4.24.drv: empty" <ng0>even though that I believe that Nix has weird standard of calling something "complex", todays discussion made me think. On the one hand we follow the guideline to go with what upstream recommends. On the other hand we don't have the restrictions other operating systems and package managers have and could maybe just create a cURL variant package that builds what gnURL intends to solve. But this would probably <ng0>add more lines of code to the repository, as I intend to simplify the build of gnURL a bit and implicitly shorten its guix package. So our (GNUnet) recommendation is to use this *or* a cURL that resembles this. Should we stick with gnURL for GNUnet in Guix or do you think it should be handled like Nix does it? I'm in favor of keeping it, but I'm on the upstream developer side with both. <ng0>on seconds thoughts, nevermind that wall of text. <laertus>while building guile-git-0.0-3.e156a10.drv-0 i'm getting "WARNING: compilation of /gnu/store/yihvhxv3xyyvl1m2cy1lnf1lyi9h76fk-guile-2.2.2/bin/guild failed: ERROR: failed to create path for auto-compiled file "/gnu/store/yihvhxv3xyyvl1m2cy1lnf1lyi9h76fk-guile-2.2.2/bin/guild"" <laertus>i'm not sure if this is the guix way, but on an ordinary *nix system i just edit /etc/shells and add it in <chewzerita>Sleep_Walker: I don't use guixSD, but `chsh -s /bin/zsh` may be what you want <ng0>as the user login shell? <ng0>it's described in the documentation <ng0>replace the tcsh or fish part with zsh <ng0>hua. one of my recent commits in gnurl fixed test1026. I'll send an follow-up patch to the update <thomassgn>derp. so guix build --check libev builds a new derivation and puts it in the store. But running guix system reconfigure still gives me the same error about the old libev derivation being an empty file... Even though there's a new one that possibly works. <thomassgn>ah, so I can 'guix gc -d /gnu/store/...libev...drv' <thomassgn>for some reason I have more than one derivation wich is an empty file... <thomassgn>'guix gc --verify=contents,repair' gives me loads of "error: cannot repair path" ... Seems like it is capable of repairing som things though. <thomassgn>curius, got a live path that is an empty file... Maybe the previous one (libev) was live too...