IRC channel logs


back to list of logs

<Petter>sneek: later tell lfam Sure, I'll see if I can set it to -1.
<geemili>I got rust built!
<geemili>But cargo is erroring out.
<geemili>Phase `patch-source-shebangs' sees rust code attributes (`#![Foo]`) and spews out some warnings
<geemili>But it errors out on the build phase because of an unknown error. :/
<bavier1>has anyone tried running the Android SDK on GuixSD?
***bavier1 is now known as bavier
<bavier>hmm... I totally meant *Arduino* SDK
<marusich>Hello guix!
<roelj>Is anyone experiencing compilation issues with the latest Guix?: "?: 0 [scm-error misc-error #f "~A ~S" ("no code for module" (json)) #f]"
<marusich>I have not seen that, but it brings a certain bug report to mind.
<marusich>bug 25192
<roelj>Thanks, going to look
<roelj>Interesting. I'm now compiling with "make -j1".
<roelj>I think I'm missing guile-json because it fails to import the module "json".
<roelj>But I cannot install that without having a working Guix!
<roelj>Building without parallelity fails as well
<marusich>Hmmm, maybe it's something else, then.
<roelj>Thanks though :)
<roelj>Does anyone have the source tarball for linux-libre-4.4.18-gnu.tar.xz? I can only find a patch..
<roelj>I cannot seem to install anything without building this package first.
<marusich>I have a couple of derivations for that in my store...
<roelj>Great! Is the source tarball there too?
<marusich>I didn't see a file with that exact name
<marusich>do you happen to know what the hash (guix hash) of the file you want is?
<roelj>I think it is 0k8k17in7dkjd9d8zg3i8l1ax466dba6bxw28flxizzyq8znljps
<marusich>I don't have an item with that exact hash in my store
<marusich>judging by the source for the linux-libre package, you ought to be able to download it from...
<marusich>but that url does not work for me :(
<roelj>Indeed. All mirrors tried by Guix seem to have removed this tarball.
<marusich>Looks like they don't have it at
<marusich>I was able to get one: /gnu/store/51f2f2ck80migsfr2hwy4ds30966lifi-linux-libre-4.4.18-gnu.tar.xz
<roelj>Could you upload it somewhere? I could try whether it's the same.
<marusich>yea, one sec...
<marusich>It's available as a nar but i'm not sure how to convert that
<marusich>(that's not the xz file, just the nar)
<taylan>updated leptonica to 1.73 and all tests fail, WTF :\\
<taylan>the test suite log is full of "steram not opened", "file not found" and "data not returned" errors. something about the guix build environment must be upsetting it...
<quigonjinn`>i'm trying to do a 'guix pull' from live USB, and i get the message to try "--fallback", but it's an unrecognised option for guix pull. any ideas?
<taylan>quigonjinn`: guix --fallback pull should work I think, instead of guix pull --fallback
<quigonjinn`>taylan: unrecognised option again
<taylan>quigonjinn`: you're right :\\ I think --fallback is recognized only by 'guix package ...' commands. hmm.
<taylan>I don't have a solution, if 'guix pull' requires --fallback further down the line but there's no way to pass it on
<quigonjinn`>and module-import-compiled(the package in question) cannot be found by "guix build --fallback", to build it explicitely. I guess it's not defined as public
<roelj>There's an R package that relies upon tools in coreutils and on grep. Should I add these as propagated-inputs to that R package?
<taylan>roelj: the Right Way(TM) would be to patch it so that it uses absolute paths (/gnu/store/.../bin/foo) for said tools
<roelj>taylan: Right. I'll try to find the relevant source code then :)
<thum>hello there, is there a chance that GNU Guix would consider endorsing our project: Vikings, world's first libre-friendly data-center/hosting provider? (
<Petter>Wow, very exciting to read about the Vikings data-center!
<thum>Petter: thanks!
<Petter>Which country will you build this center in?
<nliadm>are there any docs/posts on how to set up a hyrda builder?
<davexunit>has anyone else had the issue where programs that use OpenGL don't work on non-GuixSD systems
<davexunit>I'm having this issue on ubuntu 14.04
<davexunit>ah, I think I know the cause.
<rekado>Hi Guix!
<Petter>Hello Guik!
<jmd>rekado: You in the c-base?
<rekado>oh, jmd left
<rekado>hey Guix, did you know that you can now do this: “guix graph --backend=d3js r > super-cool.html” ?
<rekado>it’s new!
<davexunit>did you just push that?
<rekado>I think
<rekado>it’s all a blur
<davexunit>well I know what I'm going to check out right now
<davexunit>I think my coworkers will like this a lot when I show an interactive graph of one of our custom packages
<rekado>we should add one of these graphs to the HTML version of the hosted manual (said ludo and I agree)
<davexunit>you could use a standalone page and embed it into a manual page with an iframe
<davexunit>'guix graph' doesn't support the --load-path option
<davexunit>rekado: can you do anything more than highlight certain nodes?
<rekado>davexunit: in principle: yes. That would require changing graph.js.
<rekado>davexunit: what do you have in mind?
<davexunit>rekado: I don't have anything in mind, but I was curious if there were goodies that I didn't know about. :)
<davexunit>I'm currently messing with the various graph types to find the best graph to show people
<davexunit>sometimes the text for nodes overlap and makes the graph hard to read
<davexunit>but I imagine it's unavoidable in some cases
<davexunit>rekado: this graph helped reveal some unoptimal things about a package of mine. so, thanks!
<davexunit>in particular that if I used python-minimal instead of python, I would shave off a bunch of extraneous dependencies.
<davexunit>ah, it's an upstream thing. the lapack package should depend on python2-minimal
<davexunit>wow does that reduce the dep graph size
<davexunit>though the d3 graph becomes harder to read because the radius of the circle has been reduced a lot
<ng0>"it's only an update" oh, you changed the build system and also forked the main library you depended on? argh. and I thought updating utox is a 5 minute task
<davexunit>ng0: that's about what I expect from a community that doesn't even believe in release tarballs
<ng0>I am doiung this with their tarballs though ;)
<davexunit>for the short while I was interested in tox, the toxcore project *refused* to make proper releases
<davexunit>ng0: I guess utox has grown up a bit :)
<ng0>yeah, most of them still don't, but these two subprojects do
<davexunit>they wrongly think that tagging a release means "this is stable software that we will support forever"
<ng0>i only wanted to update.. :/ not package 1.5 new packages. well, almost done
<OrangeShark>wait, what did uTox do?
<ng0>change to c-toxcore, move build system to cmake
<ng0>no 5 minute update
<ng0>I'm halfway there
<OrangeShark>ah, so now there is two toxcores?
<ng0>:me shrugs
<ng0>no idea
<ng0>it's labeled as official fork
<geemili>How does tox compare to matrix?
<ng0>so maybe.. but i don't really care about news or what happens in there
<OrangeShark>hmm, qTox still uses the original toxcore
<OrangeShark>qTox seems to be moving to cmake as well, there is a pull request for it
<OrangeShark>pull request for the c-toxcore as well
<OrangeShark> found more about it
<nalin>hello guys
<nalin>I want some guidance
<nalin>regarding guixsd installation
<nalin>i tried installing GuixSD for the first time today..
<dvc>nckx: hey
<dvc>does the problem persist?
<nckx>Hiya :)
<dvc>it works for me... :)
<dvc>can you try autoreconf -vfi?
<dvc>since I modified the
<nckx>It's reproducible here, but that could just be the fault of my environment. Sure!
<Petter>nalin: And how did it go?
<nalin>Thanks Petter :)
<nalin>Everything was fine untill I hit a blockage
<nalin>Suddenly the installation said something related to substitute install error
<nalin>TLS handshake error..
<nalin>And then it all stopped
<Petter>Hm, did you try rerunning the command?
<nalin>And I was back to my root prompt..
<nckx>dvc: Hm, it seems I was already running that through ./bootstrap already.
<nalin>Nope, honestly
<nckx>dvc: ~/guix/pre-inst-env guix environment --keep-going --fallback --pure guix -- sh -c 'make -j clean; ./bootstrap && ./configure --localstatedir=/var && make -j1'
<buenouanq>nalin: did you run guix pull first?
<nckx>dvc: But knowing it's likely a problem on my side helps a lot already. Thanks.
<nalin>buenouanq: Not really..
<nalin>I started out here
<nalin>And I think no where I saw any mention of doing a pull
<dvc>ah nckx: What guix-daemon version are you running?
<dvc>I think I had a similar issue, maybe it's too old
<nalin>So I kind of prepared the USB, somehow as the laptop had a windows on it..
<nalin>But somehow I managed.. :-)
<nalin>But anyways I was well able to do network configuration
<dvc>ah no I think it was guix offload wasn't found - I was missing guile-ssh now I remember
<buenouanq>wow, what sort of crazy install is that?... I've always just run guix system init .../config.scm as per
<nalin>buenouanq: unfortunately the laptop is not personal, I cannot wipe Windows out of it.. :-)
<nalin>So I kind of took some space out on the disk, and thought to install GuixSD
<nalin>buenouanq: But you haven't faced any challenge with guix install the way you said
<nalin>And I hit upon this TLS handshake error :(
<buenouanq>nalin: nope - Everything just works. You should run guix pull prior though. And of course you have to have to do the whole network thing first.
<nalin>buenouanq: sounds interesting.. and when exactly am I suppoed to do that?
<nalin>Before running init?
<ng0>when in a cmake based setup the files all are in /tmp/$out/build and the setup chdir's to /tmp/$out/name-version before copying the files and fails because the files are not in "." but in "../build", can this be fixed in advance? in CMakeLists.txt?
<buenouanq>$ guix pull
<buenouanq>$ guix system init .../config.scm /mnt
<buenouanq>assuming you've followed all the other steps in that guide
<nalin>buenouanq: ok.. I will for sure try this, but only tomorrow..
<nalin>buenouanq: Just one more thing, do I need to wipe my partition clean, and then start over..Or I can resume where I was stuck?
<nalin>buenouanq: obviously, with a pull first, as you said..
<buenouanq>I'm not competent enough yet to do anything than follow the guide directly - But it has worked for me no problem.
<buenouanq>you shouldn't have to start over
<nalin>buenouanq: never mind, I will try both of them for the case.. And thank you so much for helping me here.. :-)
<nalin>buenouanq: but I think the guide should mention this pull thing..
<nalin>buenouanq: it looks to be a thing for the case of rescue..
<buenouanq>you have to get the network up, then make and mount the partitions, then start the cow-store, then make up your config, then guix pull, then tell guix to build it
<nckx>dvc: guix-daemon 0.11.0-8.8d12, the latest. (I updated and restarted the daemon just in case. I had the issue of which you speak as well.)
<nalin>buenouanq: :-) That sound as good as starting over..Except for I don't have to prepare the USB.. :-)
<buenouanq>note to devs, the guix pull step should be added to the install guide
<buenouanq>nalin: yeah, but it goes quick, and you don't have to repartition if you've already done that, just mount them
<nckx>ACTION clones a clean repo out of desparation.
<nalin>buenouanq: Sure I agree to that.. :D
<buenouanq>the guixsd install is the coolest and slickest of any distro I've ever tried
<nalin>buenouanq: And thanks again.. I will try the suggestions tomorrow, and get back if stuck again.. And may be even after that..:D
<buenouanq>and just wait until you start playing with and understand guix system reconfigure and rollbacks nalin
<buenouanq>this is unquestionably the bright beautiful future of all *nixes
<nalin>buenouanq: for sure.. I am trying, and may hold on with it, the one GNU/Linux free distro that I want to cling onto
<quigonjinn>buenouanq: by the way, guix pull wouldn't work for me today with the 0.11 release live usb image
<ng0>i'm stuck with cmake build.. anyone around who knows more about cmake?
<nalin>quigonjinn: what's the erro that you are getting?
<quigonjinn>it needs --fallback to build from source, and it's not an accepted flag of "guix pull"
<nalin>quigonjinn: *error, my bad
<nalin>quigonjinn: does that init command needs this --fallback flag?
<ng0>too much noise. I'll ask later again
<quigonjinn>nalin: it doesn't, but if "guix pull" is not done, there are no substitutes at hydra of the packages in that image
<quigonjinn>nalin: so almost everything needs to build from source, or that's what happened to me today
<quigonjinn>s/build/be built/
<dvc>nckx: do you have guix-json installed?
<nalin>quigonjinn: does it mean i will have to build from source?
<nalin>quigonjinn: Is there something that you are following to get this done?
<dvc>nckx: I cloned a fresh repo too, just incase I have stale files
<quigonjinn>nalin: if "guix pull" succeeds, there likely won't be a need to build from source
<dvc>sry guile-json
<quigonjinn>nalin: i'm trying to figure that out, or i will try to create a more up-to-date disk-image
<roptat>hi, I have an issue with gcc (ld): ld: cannot find crti.o: No such file or directory while trying to build a new package
<nalin>quigonjinn: Hmmm... I will have to try it first, and that can happen only I think I should do this pull thing first, and then get back in case I'm still stuck.. :-(
<roptat>gcc is called by ocamlmklib, and it should create a shared library
<roptat>I modified the makefile to run gcc -v, so I know what's happening
<nalin>quigonjinn: buenouanq Petter Thanks guys.. I shall catch up later
<roptat>I get COLLECT_GCC_OPTIONS=... lib/gcc/x86_64-unknown-linux-gnu/4.9.4/crtendS.o crtn.o
<quigonjinn>roptat: install gcc-toolchain, to get glibc etc, and see that guix package's reported environment variables are set
<Petter>nalin: Good luck! :)
<roptat>(and crti.o is also alone)
<roptat>when I run this from my environment, it comes from glibc (with full path to the store)
<roptat>and LIBRARY_PATH does include glibc in the build environment
<roptat>actually building with -K, sourcing environment-variables and changing permission to the directory lets me build the library without any problem
<dvc>Can someone please try ./pre-inst-env guix refresh --help from master? just in case I'm sending Tobias on a wild goose chase :)
<quigonjinn>roptat: what environment variables are you sourcing for it to work?
<nckx>ACTION is still running make. That's how long it takes on this machine.
<roptat>dvc: no issue on current master (plus a wip in ocaml packages)
<nckx>roptat: thanks. I guess it's me sending David to the geese.
<nckx>It's so weird. Only ‘guix refresh’ refuses to be found at all. All others work.
<ng0>fixed. I'll send the update patch for utox in the next minutes
<OrangeShark>ng0: qTox seems it will go the same direction with using cmake and the new toxcore
<OrangeShark>but they haven't finished the transition yet
<dvc>nckx: I could reproduce the issue
<dvc>with env -i ./pre-inst-env guix refresh --help
<roptat>oh, yes I can reproduce that with "env -i"
<roptat>quigonjinn: any idea for my issue?
<quigonjinn>roptat: seems i have missed something. are you trying to build a package?
<roptat>yes I am
<dvc>nckx: this works: env -i GUILE_LOAD_COMPILED_PATH=/gnu/store/0fl8rpirg13jj4x5kfscjrb9smlhbvxi-profile/share/guile/site/2.0 ./pre-inst-env guix refresh --help
<nckx>Aha! Wonderful. So I'm lacking some environment goodies. That's at least a lead. Let's see if re-sourcing my profile... [nope]. Opening a new shell... [nope]. Re-installing the guix package which I never use... [laptop from hell].
<dvc>ls /gnu/store/0fl8rpirg13jj4x5kfscjrb9smlhbvxi-profile/share/guile/site/2.0
<dvc>gnutls gnutls.scm json json.go json.scm ssh
<nckx>ACTION rattle rattle *fan noise*
<quigonjinn>roptat: well, there *should* be some difference in the environment variables, between the successful and failed tries. I would check the output of 'env' in a "--pure" environment with coreutils and go on by elimination
<nckx>dvc: I don't have anything GUILE_ set in my environment. That explains the symptoms. Now to find the cause. :-)
<nckx>(The cause is that I set up this environment on day 0 of my glorious Guix future and never looked back to re-do it properly, but whatever.)
<dvc>nckx: awesome! :)
<dvc>so thats me finished for today then...
<roptat>quigonjinn: the difference between my package and coreutils is only the profile, and a new variable I need (OCAMLPATH) in my package
<roptat>and both profiles have crti.o
<nckx>sneek: later tell dvc Bye, and thanks for all the help!
<sneek>Will do.
<ng0>done for today
<ng0>bye o/
<geemili>How do I get applications to run as background processes on startup?
<quigonjinn>roptat: you should look into the profile, what what paths that translates to, i think
<cbaines>geemili, do you mean as a system service, or for your user?
<Helius>I did the binary installation, and I am tring to build guix from git. I created the guix environment adding ad hoc packages and help2man is there. make tells me that WARNING: 'help2man' is missing on your system. but which help2man is /gnu/store/hs83kw23b37w57mdnjzsc9r5lifp3dsr-profile/bin/help2man and help2man —version is GNU help2man 1.47.4
<cbaines>Helius, maybe you need to ./configure again?
<Helius>cbaines: I did ./configure --localstatedir=/var
<cbaines>also, I think the main thing that using the git repository involves is building the guile object files, you might have the man pages anyway?
<cbaines>I have guix installed from guix (as in guix package -i guix), and ~/.config/guix/latest symlinked to a checkout of the guix repository
<Helius>cbaines: rekado helped me in setting up my guix but maybe I missed the same thing you are saying now about “~/.config/guix/latest symlinked to a checkout of the guix repository”
<Helius>what does it mean ?
<Helius>I see that my user is missing the ~/.config/guix/latest
<thum>Petter: Germany!
<roptat>quigonjinn: I think I got it... the makefile thinks it's a good idea to redefine LIBRARY_PATH...
<roptat>thank you for your help :)
<quigonjinn>roptat: cool :) no problem
<cbaines>Helius, it would help to understand why you are building Guix from git?
<nckx>rekado: Thanks for the early Christmas present. Those graphs are awesome.
<alezost>Helius: ~/.config/guix/latest is the symlink to a guix source code created by "guix pull"; many developers don't use "guix pull" at all, and instead they make ~/.config/guix/latest a symlink to their guix git checkout, so they always use the latest code
<Helius>cbaines: to use the latest guix, thanks alezost
<Helius>i guess to use the latest guix I need to build it. running guix pull I had some trouble.
<cbaines>cool, so you are heading in the right direction
<cbaines>I normally run the following to build guix in the repository: guix environment --fallback --pure --container -N guix -- sh -c "make clean; ./bootstrap && ./configure --prefix=/ && make -j4"
<cbaines>sometimes, the following also works, if nothing has changed to much: guix environment --fallback --pure --container -N guix -- sh -c "make -j4"
<cbaines>I have aliases, so I don't type it out all the time!
<Helius>cbaines: thanks I will try it. in case it will compile do I need to shutdown the current guix-daemon and then run the new one ?
<Helius>How? Do I need to type also make install as root ?
<Helius>and the run the guix-daemon ?
<cbaines>are you on GuixSD
<Helius>No Ubuntu
<cbaines>You probably don't need to update the daemon
<cbaines>That is a big advantage of using Guix
<cbaines>The daemon doesn't change often
<Helius>ah ok , that is the reason
<cbaines>Once you have setup the symlink, guix should be using the package definitions in the repository
<cbaines>If you run guix commands (e.g. guix package --show=guix), you might notice guile starts saying things, I forget exactly what
<cbaines>It will still work, but you can speed everything up by running make in the repository to build the files once
<cbaines>e.g. I've just done a git pull in the guix repository I have, and now when I run guix, I get ;;; note: source file /home/gds/.config/guix/latest/gnu/packages/python.scm ...
<cbaines>then I run the 2nd command I pasted, which runs make in a guix environment, in the guix repository
<cbaines>It does some GUILEC and some other things
<cbaines>then when I run guix again, I don't get any output from guile
<cbaines>that is as far as I am aware what using the latest guix looks like
<Helius>ok, maybe I am slowling getting the point
<cbaines>don't worry, it took me a while
<Helius>I nee to practice a bit more, but this chat was very useful
<cbaines>note that updating guix does not update the packages in your profile
<cbaines>so if you want to make sure they are up to date, after you have updated guix (by running git pull in the repo), you should run guix package -u
<Helius>cbaines: ok
<Helius>cbaines: in you command line guix environment --fallback --pure --container -N guix -- sh -c "make clean; ./bootstrap && ./configure --prefix=/ && make -j4”, why did you set the configure prefix and not the --localstatedir=/var ?
<cbaines>I forget
<cbaines>I think it may have been when I was trying to install the guix daemon from the repository, I think that might be the setting that gives the same behaviour as the binary installation, otherwise things end up in different places
<cbaines>Regardless, on foreign systems (e.g. I have a few Debian systems which I use Guix on) I would now just use the binary installation method
<rekado>davexunit: glad to hear that the new visualisation revealed a problem!
<rekado>davexunit: the radius size and the labels aren’t always optimal.
<rekado>actually, I’d be surprised if they were because I tested it with package graphs the size of R.
<rekado>I really wanted to make this a little smarter but … yeah. So instead of having it rot away in a local branch waiting for me to get around to improving it I thought I’d rather push it now.
<rekado>patches are very welcome in that area.
<davexunit>I think that was the right call
<davexunit>"release early, release often" and all that
<rekado>d3 makes a lot of nice visualisations possible, so having one example in the source tree should serve as inspiration.
<rekado>if anyone is tired of hacking Guile: here’s your chance to do some JavaScript for a change ;)
<baconicsynergy>im just starting to use these guix extensions for emacs
<baconicsynergy>its so cool
<Helius>so I had to add some —ad-hoc the the basic guix environment posted by cbaines $ guix environment --fallback --pure --container -N guix --ad-hoc guile-cairo guile-charting guile-rsvg -- sh -c "make clean; ./bootstrap && ./configure --localstatedir=/var && make -j4”
<Helius>guile-cairo guile-charting guile-rsvg
<Helius>I created the link $ ln -s ~/guix ~/.config/guix/latest
<Helius>do I have to upgrade packages with $ guix package -u ?
<cbaines>you need to run guix package -u if you want to use the new package definitions to update your profile
<geemili>Is it possible to install a system wide font?
<geemili>I keep getting little boxes from missing glyphs
<SovereignBleak>I was just about to pull the trigger on testing a Ruby development environment with nginx and postgres with NixOS but then remembered that GuixSD was a thing and that it much of it was written in a language similar to the language used to make my beloved Emacs. Is GuixSD ready for that kind of task?
<SovereignBleak>Or should I just stick with making him an environment built on NixOS?
<rekado>I’m running a simple webserver with nginx on GuixSD.
<rekado>I’m not using postgres and I don’t know off-hand if we have a convenient abstraction for configuring and starting postgres.
<rekado>geemili: make sure you install a font that contains the missing glyphs, install it into your profile, and run fc-cache to update the font cache.
<rekado>geemili: usually you don’t need to install packages into the global system profile
<rekado>(you can do that if you’re using GuixSD by adding packages to the “packages” field of your /etc/config.scm)
<cbaines>SovereignBleak, I've been doing pretty well with doing Ruby development with Guix
<SovereignBleak>cbaines: Oh this is good news. Do you have whatever passes for a GuixSD configuration.nix on github somewhere?
<cbaines>For what I have been doing recently at work, there is some stuff up here
<cbaines>Its not particularly pretty, but it works more or less
<cbaines>I really need to update it, as I've been making quite a few improvements since I did the original implementation
<SovereignBleak>Anything is better than the fog of nothing I'm dealing with right now. :-)
<cbaines>I was going for a particular set of possibly unusual requirements, e.g. using environment variables to affect package sources, so the gds/systems/end-to-end-test.scm file ended up being a real mess
<cbaines>I've been working on building system containers, but that might not be what you want for development
<cbaines>Easy development is something that I'm yet to really get a handle on, some of the conventions in rails (where it expects the rails root to be mutable) and trying to fight with bundler don't really go well with Nix and Guix
<SovereignBleak>He'll also be doing website hosting for clients (potentially). This is all just testing other methods of hosting and deployment since he's been using Ubuntu and it's been dependency Hell for him.
<SovereignBleak>rekado: I'd also be interested in seeing your Guix configurations for my own education, if those are around.
<rekado>SovereignBleak: my nginx config is messy :-/
<rekado>SovereignBleak: our config abstractions need to get an “escape hatch” to allow us to add config snippets for things that our config language doesn’t cover.
<rekado>SovereignBleak: at the moment that’s not the case, so I’m just using an ugly external configuration file and tell the nginx service to use that.
<SovereignBleak>Aha so GuixSD is still pretty rough?
<rekado>no, I wouldn’t say so
<rekado>but some service and configuration abstractions aren’t as battle-hardened as others
<rekado>the nginx config language is a fairly recent addition
<rekado>you can totally express *everything* by just using a plain text config file
<rekado>using the super pretty way of writing server blocks in Scheme is currently a little too limited
<rekado>maybe around gravmass I’ll see if I can submit some patches to make it a little more flexible
<cbaines>I've got a branch that I use that adds records for upstream and location blocks, which I use to run NGinx in front of rails and other apps
<rekado>cbaines: wonderful!
<rekado>cbaines: pretty patch please?
<cbaines>I'm hoping to prepare some patches from it at some point
<Helius>Just send my first patch to the ml thanks cbaines and rekado
<rekado>Helius: yay!
<Helius>does it take a bit to be distributed?
<Helius>btw, rekado to deploy a package as described here do I need to have fully working guix system on the remote host or may I just unpack the archive ?
<rekado>Helius: the easiest way is to have a guix system on the remote
<rekado>Helius: I’ve never tried to do without, but the archives are really just gzipped binaries, so it might work without.
<Helius>ok , that is easy. How do I import it ?
<rekado>hey Guix, here’s a sneek peak at a new project that was born at the reproducible builds summit: (will later be available at
<rekado>Helius: erm… dunno. It should be explained in the official manual (I should add this bit to the documentation on
<rekado>there’s a “guix archive --import” command, I think
<Helius>rekado: but if I publish my building store then I can directly import packages from there, is that right ?