IRC channel logs
2017-08-30.log
back to list of logs
<davexunit>ACTION realizes 'guix environment' with no args actually works <davexunit>castilma: it's sort of a no-op... it spawns a new shell where nothing is different. <davexunit>and if you use --container you get a shell that can absolutely nothing :) <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, ng0 says: I'll work on the 3 patches for [bug#27790] text-editor: mg and afterwards we can close it. <davexunit>ACTION changed 'guix environment' so it caches the profile for later use <efraim>i'm turning an idea around in my head about making a 'dont break bootstrap' test, where it would build the bootstrap binaries and then use them to build to hello <efraim>not to run as a regular test, but as an occasional test to check <civodul>efraim: something like that could be useful, indeed <civodul>currently we just make sure we can build "bootstrap-binaries", but we don't go further than this <civodul>cbaines: how far did you go with that ISO9660 bug-fix we looked at at the GHM? :-) <efraim>what do we have for translating .po files? just emacs/vim? <ng0>When I need to do something like (setenv "CCFLAGS" CFLAGS) where do I get the CFLAGS from, what is the correct way? I have to use CCFLAGS. <ng0>Or: I want to use it. Checking out some possible solutions to the ksh build <ng0>(getenv "CFLAGS") ,right? <ng0>civodul: I have seen your email wrt to my group inclusion email/question, I just have a very long time to respond to messages sometimes.. sometimes months. I'll get to it eventually :) <ng0>was there something bad about the way github generates the tar.gz of commits, or can I just take them that way? <mekeor>jonsger_: so which part doesn't work? <jonsger_>mekeor, after xorg-start-commnd. I don't know how pass the xorg configuration there :( <mekeor>ACTION likes to refer to his system config <Apteryx>are we low on fresh substitutes? My machine's been building all night long. <mekeor>jonsger_: have you been looking for #:extra-config? i mean, is that what you want? specifying extra xorg-configuration as string in the xorg-config-syntax?... <davexunit>civodul: quick temperature check: how would you feel about some breaking changes to 'guix environment' before 1.0 drops? 'guix environment' is almost 2 years old and I've got some ideas. ;) <civodul>davexunit: i'm not opposed, we can negotiate :-) <davexunit>my motivation is wanting to improve usability and streamline reproducible dev environment creation <civodul>hey ng0, no problem with the delay, the same happens to me :-) <civodul>davexunit: yup, i'm definitely on the same line of thought <davexunit>last night I made a smallish hack that enables you to cache an environment profile <civodul>is it an implicit cache, or explicit? <civodul>like do you have to pass an extra flag? <davexunit>so for example, in the guix git repo I can do this: <civodul>something like --save + --load sounds good <civodul>the difficulty if this were implicit is garbage collection <davexunit>as a first stab at this, my hack writes a .guix-environment symlink in the current directory <davexunit>running 'guix environment --cache' will just use that profile and skip building anything <davexunit>so coming back to a project takes about 1.5 seconds to re-use the cached profile. <davexunit>I found an archived bug where someone wanted to integrate emacs-direnv with 'guix environment' but was put off by how slow it was. using a cache would fix this. <davexunit>this is the workflow I'm used to in other programming languages. Ruby's Bundler, for example. <davexunit>it will just re-use the stuff it has already built for you unless you run 'bundle update' <davexunit>skipping right to the end goal: I want the user to be able to enter a project repo that has a guix.scm file in it and run 'guix environment' with *no other arguments* and have it produce a fully functional development environment. <davexunit>sane defaults: read from guix.scm, cache the profile, etc. <ng0>I could use the debian source, but I prefer to try building from the original source for now, as it moved to github <ng0>ACTION throws hands dramatic in the air <civodul>davexunit: yes i replied to this archived bug earlier today, saying that --root gets us halfway, i think <civodul>1.5 seconds is still more than i expected <civodul>davexunit: re guix.scm, that sounds good <davexunit>civodul: I think we can optimize there, but I wasn't able to quickly fix it. <civodul>i think it might be wise to call it ".guix.scm" though (similar to .travis-ci.yml and all that0 <civodul>part of the reason is that this would allow conflicts with the (guix) module <davexunit>maybe a different file name is in order entirely <davexunit>whatever we deem to be an appropriate, canonical name <davexunit>I'm writing up a bigger proposal for guix-devel <ng0>that reads really nice <davexunit>because I think another problem is that guix.scm should not evaluate to a package, but rather a <guix-environment> record that fully specifies the environment <davexunit>so not only the packages, but whether to run in a container, etc. <civodul>and also, following discussions at the GHM (hi rekado_! :-)), it may be a good idea to support .guix.json as well <davexunit>and there's one big missing feature that I think will put us over the top: shepherd services <davexunit>running 'guix environment' in a web app project should start nginx, mysql, redis, etc. <civodul>that one requires more work, but i agree it'd be awesome <ng0>that's what I jus twanted to ask :) <davexunit>it can be added later, if we agree on having a <guix-environment> record <civodul>i'm already happy to see you back on board davexunit :-) <davexunit>if we got services working, we would be eating docker-compose's lunch <davexunit>okay, mail sent with my thoughts explained as best as I can. <davexunit>I sent it *before* I noticed all the additional replies to that closed bug <davexunit>but I don't think I would change anything having read them <davexunit>all of those options approximate what I want, but it would be best if 'guix environment' just did that automatically. <janneke>i would like to have a nicer solution for that <davexunit>janneke: neat. I think integrating with emacs-direnv may be the answer? <janneke>davexunit: i haven't looked at emacs-direnv..so quite possibly, that's why I'm asking <janneke>i can imaging wanting to have the profile/environment settings as s-exps <janneke>instead of snarfing bash syntax/output <davexunit>janneke: yeah, we can parse the manifest file for the profile and get the search path strings. :) <zacts>how is the install these days? <zacts>is there yet an installer (even if text based)? <zacts>I like OpenBSD-style installs or Debian style installs too <zacts>I don't mind if there isn't one, but I was just curious <rekado_>zacts: there’s a branch for an installer, but it hasn’t been merged yet <zacts>that's progress at least (for an installer) <civodul>janneke: looks like a useful hack! it would be good to have something like this in emacs-guix <janneke>civodul: are you using emacs-direnv? i should prolly look at that <civodul>rekado_: what happened to the CTAN importer? <rekado_>civodul: it turned into the texlive importer <rekado_>a CTAN importer turned out to be of limited use <civodul>i was pretty sure we had something like that, but "guix import ctan" didn't work <civodul>does the importer provide a valid 'license' field? <rekado_>the license file is mostly correct, but the CTAN XML doesn’t specify keys for “or later” variants. <rekado_>so I recommend checking the license it reports <davexunit>janneke: it would need an emacs-guix feature, which can use the guile repl to read that <rekado_>civodul: we had “guix import ctan” only in an early patch, but I rewrote it when I started to actually package the modular TeXlive. <janneke>although i often experience `no prompt!' when trying guix-edit ...it mustn't be as fragile as that <janneke>or guix edit should be fixed, or i should be more enlightened <davexunit>either that or emacs-direnv can handle the etc/profile <davexunit>direnv sounds a lot like dotenv, a ruby library I use for a similar purpose <davexunit>the annoying thing about emacs-direnv is that it requires having a program called direnv installed <janneke>davexunit: shouldn't direnv be a propagated input then? <janneke>davexunit: yes, we have emacs-direnv <ng0>Is the PLUGINS_DIR_NAME in source of icecat xpcom/io/nsAppFileLocationProvider.cpp (and xpcom/io/nsAppFileLocationProvider.cpp) defined in such a way that we could make use of it for the search-path thing we can add to aqpplications? I mean in general, would it work (even with modifications) or am I wrong? <ng0>it doesn't read an environment variable, but does it read an env variable the way we can make use for the search-path? <ng0>the second file name was supposed to be another one <ng0>actually it's just this one file. <rekado_>I don’t understand the question. “it doesn’t read an env var, but does it read an env var?” <efraim>since I set up a git-worktree for core-updates I keep on forgetting to change the directory when I open a file in vim <ng0>in other words: I haven't read too much into search-path and I don't always know at the moment when it would work <rekado_>efraim: I’ve got the same problem with worktrees and a long-living Emacs session. <ng0>I could look at pidgin and read the pidgin source to learn how it works <efraim>I tried to have just one vim tab in screen, I should go back to a guix-vim and a guix-cu-vim tab <rekado_>ng0: what do you think search-paths do? <ng0>hm.. I assumed something more than just using environment variables <ng0>but the pidgin patch looks like it's just env vars <ng0>I should re-read the guix source parts for that <ng0>#define NS_ENV_PLUGINS_DIR "EnvPlugins" // env var MOZ_PLUGIN_PATH <ng0>but maybe this PLUGIN is something else, still reading <davexunit>wow, lots of replies to my thread. I will try to formulate a response later to address all the feedback. <ng0>later on you find this: <ng0> # Let each plugin tell us (through its `mozillaPlugin') attribute <ng0> # where to find the plugin in its tree. <ng0>plugins = map (x: x + x.mozillaPlugin) plugins; <ng0>yeah.. it could be that easy <efraim>qemu-2.10.0 tagged 60 minutes ago <guix_noob>Hi all, I am attempting to install GuixSD and I cannot get my networking running. When I execute 'ifconfig -a' my wireless card doesn't show up, so I plugged in an ethernet cable and used 'ifconfig enp3s0 up' to turn on that connection. However I cannot ping any websites <davexunit>guix_noob: you need to run 'dhclient enp3s0' after <davexunit>your wireless card is probably not showing up because it requires proprietary firmware <guix_noob>I assumed that was the case. It seems that there are some decent USB wifi dongles that are compatible with the linux-libre kernel. I will look into those options <efraim>it looks like file from %content-addressed-mirrors is the file-name from package-source <guix_noob>So I'm at what I believe to be the last step of the installation process. After running 'guix system init . . .' It downloads a bunch of stuff and seems to compile a bunch of stuff. Then it prints "substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%" a lot of times and now it hasn't done anything for a while. <guix_noob>I might just be impatient, but it hasn't moved for about 15 minutes. Is this expected behavior? <guix_noob>It just ended with 'substitute: guix substitute: error: TLS error in the procedure 'handshake;: Error in the pull function. <guix_noob>'guix system: error: build failed: substituter `substitute' died unexpectedly <buenouanq>15 minutes seems long, maybe the handshake timeout could be shortened