IRC channel logs


back to list of logs

<davexunit>ACTION realizes 'guix environment' with no args actually works
<castilma>davexunit: and what does it?
<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 :)
<civodul>interesting :-)
<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
<davexunit>lots to clean up but so far so good.
<wingo>moin all
<rekado_>hello guix!
<wingo>heya rekado_ :)
<civodul>Hello Guix!
<rekado_>hi civodul!
<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
<pmikkelsen>hello gui
<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?
<mekeor[m]>hello mekeor
<mekeor>hello mekeor[m]
<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.
<jonsger_>how can I get the xorg-configuration work in my-services? the slim part works.
<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_: i can only show you my config:
<mekeor>jonsger_: does that help?
<jonsger_>I'll try
<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 :-)
<civodul>2 years old already, time flies!
<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>currently, yes.
<davexunit>this was a proof of concept.
<davexunit>so for example, in the guix git repo I can do this:
<civodul>something like --save + --load sounds good
<davexunit>'guix environment --cache guix'
<civodul>the difficulty if this were implicit is garbage collection
<civodul>maybe not
<civodul>well, food for thought
<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 wonder how Gentoo resolved the nmake usage in at&t ksh. Bug reports are not clear on this. I think I really have to read this incredible chaotic, overcommented file
<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
<ng0>it's just a shell!
<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>the name isn't important to me
<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>right, that makes sense to me
<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
<civodul>that'd be great
<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
<civodul>and have it too ;-)
<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>davexunit: re environment, i've been using this hack to switch emacs to different profiles (or environments)
<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 quite possibly, that's why I'm asking
<davexunit>I need to do more research there myself
<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. :)
<janneke>davexunit: doh' yeah!
<zacts>hi #guix
<zacts>I should try out guix again
<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>oh cool
<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>i'm not
<janneke>iwbn if emacs would parse `#f'
<janneke>then we could just read manifest
<civodul>rekado_: what happened to the CTAN importer?
<rekado_>civodul: it turned into the texlive importer
<civodul>oooh, ok
<civodul>silly me
<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>RTFM, civodul!
<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
<davexunit>need to be*
<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>davexunit: ah, that could be nice
<janneke>although i often experience `no prompt!' when trying guix-edit 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
<janneke>ok, right
<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
<davexunit>I wish it was elisp only
<civodul>rekado_: ok
<janneke>davexunit: shouldn't direnv be a propagated input then?
<davexunit>janneke: I guess?
<davexunit>we have a guix package for it?
<davexunit>I was reading the source code on github
<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>pasting is hard ;D
<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>starting from this line it looks Nix sets MOZ_PLUGIN_PATH to a list of directories found in the profile separated by ":"? (I'm not very familar with Nix packaging, I assume this much
<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>last commit touching this line was 9 years ago:
<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
<guix_noob>That worked. Thank you!!
<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
<davexunit>good luck!
<garlox[m]>guix_noob: I can confirm that this one works perfectly well with GuixSD:
<garlox[m]>(a bit pricey though)
<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 ''... 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>'killing process 17678'
<guix_noob>'guix system: error: build failed: substituter `substitute' died unexpectedly
<buenouanq>yay network errors~
<buenouanq>run it again
<buenouanq>the substitutes thing is normal
<guix_noob>okay, I'm running it again.
<buenouanq>15 minutes seems long, maybe the handshake timeout could be shortened
<guix_noob>it worked this time. Thank you!