IRC channel logs
2015-07-23.log
back to list of logs
<jsgrant>Congrats on 0.8.3! I plan to start making occasional/drive-by contributions again, starting this cycle. :^) <davexunit>ACTION tries to figure out why 'make' segfaults inside containers <davexunit>something to do with psuedo-terminals, I suspect, but no idea really. <davexunit>mark_weaver: a bit sad, but I've never actually done that before. <davexunit>the core dump is large and I don't know what to make of it <adhoc>is there any tools for working with containers in guix ? <mark_weaver>davexunit: use gdb to load the program and core file and it should be able to show you a backtrace <davexunit>I'll rebuild my container so that gdb is available <mark_weaver>you can run gdb on the core file outside of the container <davexunit>mark_weaver: I currently don't have a way to access the file outside :) <adhoc>i need to figure out how to deploy containers across various machines <mark_weaver>davexunit: if 'make' core dumps inside the container, I don't know that 'gdb' will work properly either. <mark_weaver>can't you somehow get the core file out of the container? <mark_weaver>there are ways of configuring where the core dumps go <davexunit>mark_weaver: I need to make a new container that bind-mounts a writable directory from the host <davexunit>so I'll do this one more time and get the core dump to analyze with gdb on the host <davexunit>adhoc: deployment automation is an orthogonal issue, and we're also slowly working on that. <adhoc>davexunit: ok, where do i look to start work on that ? <davexunit>but basically, when my work is done, you'll be able to take a GuixSD configuration file and instantiate it as a container <davexunit>adhoc: which part? containers or deployment? <davexunit>there's wip-container and wip-deploy branches <adhoc>but building a container, something i can run on docker <mark_weaver>davexunit: it might also be helpful to build a version of make with debugging symbols, and getting that to dump core inside the container, for more useful debugging. <adhoc>and then deploying it on a remote machine <mark_weaver>but don't change the package bound to 'make' or else you'll rebuild the world. <davexunit>mark_weaver: hmmm okay. is there an easy build system switch to turn that on? <mark_weaver>I guess the usual guixy way would be to add a "debug" output. <davexunit>I don't really grok how adding an additional output would magically make the debugging symbols appear <mark_weaver>what happens is that the debugging information is installed in the debug output, and then you tell gdb where to find those files. <adhoc>can you throw debugging to stderr ? <adhoc>never mind, you have a debug stream <mark_weaver>davexunit: in this case, it might be easier to just remove the strip phase <isd>Okay, I'm *certain* I've done this before and had no trouble --- I've got a git checkout of the source tree, built it, would like to run things from the directory, keeping the source tree where it is, but still have it do stuff to ~/.guix-profile. I am just not finding something in the manual about what to do next...? <davexunit>isd: to use the guix built within the repo, use the ./pre-inst-env script <isd>davexunit: I get a permission denied error when running guix archive --authorize < hydra.gnu.org.pub <isd>mkdir is the command throwing the error <isd>there's no /gnu, ~/.guix-profile doesn't exist... <isd>where is the store supposed to go in this case? <adhoc>isd: you are about ten minutes ahead of me =) <isd>that seems to have done the trick. <adhoc>i'm just installing on a new machine <isd>I feel like incremental builds may be taking *longer* than clean ones... <isd>I did a git pull and then a `make', and it's spitting out a lot of "note: source file foo.scm is newer than compiled foo.go", and occasionally actually compiling something <isd>like every 10-20 lines I see an invocation of GUILEC <isd>am I missing something? <isd>desktop just *shut off* in the middle of a compile. It might be a bit warm in my apartment <yenda>if I have emacs installed and I install guile-emacs how do I start guile-emacs ? <rekado_>yenda: they should be installed into separate profiles. <rekado_>guix package -p /path/to/guile-emacs-profile -i guile-emacs <rekado_>the executables are both called "emacs" <rekado_>after installing into a separate profile you can just do /path/to/guile-emacs-profile/bin/emacs <yenda>yeah that's what I thought reading the package definition :( <yenda>a profile is just a directory ? <rekado_>that's the same as with some other packages. Most cannot be installed into the same profile because the files are indistinguishable at profile build time. <rekado_>a profile is a directory containing links. <rekado_>actually the profile path is a link as well. <rekado_>a link to the latest version of the profile. <rekado_>which also is a link to the actual profile directory in the store. <rekado_>which contains links to the package outputs in the store. <yenda>have you ever noticed that autocompletion is really slow with guix ? <yenda>rekado_: if I want to test guile-emacs my best option is to install it in a testing profile then ? <civodul>yenda: i have, that's because i implemented it very naively :-) <civodul>yenda: for a quick test, you could run: $(guix build guile-emacs)/bin/emacs <yenda>I tried guix package -p ~/testing -i guile-emacs and I got guix package error: rename-file: Is a directory <yenda>civodul: what is suppose to happen with this command ? <rekado_>yenda: guix creates the links on its own. <rekado_>yenda: $(guix build guile-emacs)/bin/emacs runs "guix build guile-emacs" first, which (upon success) prints the location in /gnu/store. <yenda>rekado_: it created a dir testing.new can I "rm -r" it or is it a cleaner way ? <rekado_>so you end up with a command "/gnu/store/abclong-hash123-guile-emacs-version/bin/emacs <yenda>rekado_: ok I thought there was a space that's why I didn't understand the command <rekado_>you can remove profile links without problems. (But never ever manually delete stuff from /gnu/store) <rekado_>I would just use "rm" on it, it's just a link. <yenda>"$(guix build..." returns Cannot open load file: No such file or directory, emacs-lisp/byte-run <yenda>which I got too after installing it in a testing profile and trying to run emacs from this profile <civodul>yenda: i actually have the same error <yenda>rekado_: that should ring a bell you had the same error in may <yenda>apparently emacs -Q should works <rekado_>I did? I don't remember. I just remember guile-emacs was *really* slow to start. <yenda>rekado_: yes it is. seems quite unsuable yet <rekado_>I wish I could help, but I don't know how. I'd really like to have a Guile-powered Emacs. <yenda>well I still have much to learn with guix so I can wait. <yenda>alezost: ok, I have yet to add guix in my emacs <alezost>yenda: if you are on GuixSD, then it's already added <csed>Anyone here use Guix as their main distro? I've been thinking about what I need for work, and it's basically Emacs and SSH. I'm guessing both work fine on Guix. <csed>I saw that there's even a guile-emacs package. Which is pretty great. <ph4n70m4s>perl fails to build on hurd with "miniperl: memmove.c:72: memmove: Assertion `len == 0' failed." <svetlana>does guix have gnustep in it? is it packaged with clang or gcc? <svetlana>and on a related note: how should I normally go about finding it out, other than by installing the distro somewhere? is such information available on the web? <yenda>csed: guile-emacs doesn't work <yenda>only with -Q param and it loads slowwwwwly <yenda>also the kernel is linux-libre so if your hardware runs on proprietary firmware you can say it goodbye <yenda>that's the only quirks I've encountered so far <csed>yenda: Too bad about guile-emacs, though. <alezost>csed: several people here use GuixSD as their main distro (I'm on it right now) <francis7>csed, gluglug laptops are good. mark_weaver also has one (not gluglug, but it's the same one, and has libreboot), and he develops guix on it. <davexunit>rekado_: what's up with that person that you replied to from the release thread? I don't have that reply in my inbox. <csed>francis7: Then great, don't need guile-emacs. But was hoping to give it a try. <civodul>yenda: re guile-emacs, paroneayea may know what it takes to "make it work" <davexunit>we've sure made it easier to try out guile-emacs, at least. <davexunit>ACTION works on a revised ruby-build-system that uses .gem archives <davexunit>hmm, anyone know what the following error is about? <yenda>paroneayea: do you know what it takes to make guile-emacs work ? <yenda>anyone tried running clojure on guix ? <iyzsong>someone did, but can't get certs working IIRC. <civodul>davexunit: probably a (web client) bug or misplaced strictness <davexunit>I think we should default to application/octet-stream <davexunit>I'll have to see how to patch this for guix. <davexunit>and my hack time has run out for today. I'll do that tomorrow I guess. <yenda>how will you do it ? I'm curious <davexunit>yenda: there's a procedure in guile's (web http) module called 'parse-media-type'. I will 'set!' that variable to refer to a new procedure does the right thing. <yenda>you will have to change the guile.scm file to point to your own version of it once patched ? <davexunit>we'll just load the monkey patch somewhere in guix <civodul>yenda: (guix http-client) is full of monkey-patching, if you want to see what it's like ;-) <civodul>that's actually one reason i would not propose immutable top-level bindings or getting rid of 'set!' <civodul>(things i would have been in favor of until i started practicing monkey-patching) <davexunit>immutability is great... except at the top-level :) <davexunit>being able to evolve a program at the REPL needs such mutability <civodul>yes right, live programming is obviously another good reason :-) <yenda>the risk though is to have tons of monkey patching that should actually be done upstream <davexunit>I'm sure many of us are familiar with the horrors of too much monkey patching <civodul>we stripped the Cc list differently ;-) <rekado_>davexunit: there was a reply to all lists sent by Markus. I stripped the Cc list to only contain guix-devel. Not sure why you didn't get the original message. <davexunit>rekado_: thanks, I saw it now via the link above <carif>what are the restrictions, if any, for guix commercial use? <davexunit>carif: none. guix wouldn't be free software if it didn't allow for commercial usage. <davexunit>the requirements of the license are the same whether or not money changes hands. <amz3>what is the license of guix? <yenda>if I want to add a package from pypi and I have pulled guix source code I have to manually edit python.scm and add the definition I get with guix import right ? <yenda>because guix edit will point my system's python.scm ? <yenda>and what do I do once it's done ? make and ? <davexunit>replace 'python-yenda' with the appropriate name of course <carif>davexunit, my googlefu is weak, is there a url that describes GPL3+? I find references to it and find http://gplv3.fsf.org/. I need the page that's written for a kindergardener... <yenda>make command not found ? what ? <yenda>davexunit: is it possible that gc garbage collected the make command ? <yenda>davexunit: earlier today I tried guix gc <yenda>and now the make command is not found <yenda>I did guix -i make and now it's there again <yenda>so I assume gc got rid of it somehow ? <yenda>no but I could use it befire <yenda>I build guix yesterday with it <davexunit>yenda: if a package isn't in a profile (or another "gc root"), then 'guix gc' will reclaim it. <mark_weaver>you can register GC roots, and that automatically includes things in your profile (including earlier generations of your profile) and the system profiles. <mark_weaver>and every reachable store item is scanned for references to other store items. <mark_weaver>but if there's no GC root to something, and it's not reachable from a GC root, then yes, it can be reclaimed by GC. <mark_weaver>so, for example, if you refer to /gnu/store/... directly from some program or script you write, or you set your environment variables to point to things in /gnu/store (e.g. by running 'guix environment'), then they are not protected automatically. <yenda>oh i got it, the difference was that I ran make in the guix environment <davexunit>IIRC, 'guix environment' will protect those store items for the duration of its execution <davexunit>but afterwards, 'guix gc' is free to reclaim it. <mark_weaver>yenda: btw, one other case where this can happen is when you compile something manually using Guix toolchain+libraries. <mark_weaver>the thing you compile will contain references to items in /gnu/store, e.g. references to shared libraries there, but those things will not be protected by default. <mark_weaver>the best solution is to always make a Guix package for such things <yenda>I added my package definition in python.scm, make && guix build python-ccm but it doesn't find my package <mark_weaver>yenda: to run guix out of the git checkout, prefix your commands with ./pre-inst-env, e.g. ./pre-inst-env guix build -K python-ccm <mark_weaver>(and when debugging a package, -K is a good idea, because it leave the failed build directory in /tmp if the build fails) <davexunit>oh yes, sorry I forgot to include the './pre-inst-env' part. <mark_weaver>one trick: if you want 'guix' to always use the packages from your git repo, you can make ~/.config/guix/latest a symlink to your git checkout directory <mark_weaver>~/.config/guix/latest normally holds a symlink to a copy of guix in /gnu/store that was produced by "guix pull" <davexunit>do we document that trick anywhere? it's a good one <mark_weaver>yeah, I think maybe we should document the "git approach" along with that trick. <yenda>I'm taking notes :) at the end of my journey I'll put in in form <yenda>s/put it in form/format it properly <mark_weaver>the only caveat to be aware of, with that trick, is that if your git checkout is in a bad state, then 'guix' will effectively be broken with that symlink in place. if that happens, just remember you can always remove that symlink temporarily. <mark_weaver>like other things that are compiled manually, the things that 'guix' from the git repo refer to in the store are not protected from GC by default. <mark_weaver>I guess I should protect that entire directory from GC. I confess I've never learned the details of what I can protect from GC, and have been too lazy to look into it yet. <mark_weaver>but my guess is that any file or directory can be protected, and it will be scanned for references <mark_weaver>but since I haven't done that, every once in a while after a 'guix gc' I find that my guix built from git is broken because something it depends on was GC'd, and I just recompile it. <mark_weaver>civodul: what's the best way to protect software built in a git checkout (e.g. guix itself) but not installed, from having its dependencies in /gnu/store GC'd? <mark_weaver>(preferably a way that doesn't require having root access) <mark_weaver>it would be good to improve the documentation on this. <mark_weaver>can I make a symlink to an arbitrary file or directory, and that file or directory will be scanned for references during each GC ? <mark_weaver>if so, where do I put that symlink, as a normal unprivileged user? <yenda>I created the symlink it doesn't work <yenda>I suppose it's because I built in a guix environment ? <yenda>ln -s ~/.config/guix/latest ~/guix <mark_weaver>rm ~/.config/guix/latest && ln -s ~/guix ~/.config/guix/latest <mark_weaver>yenda: you probably now have a symlink ~/guix/latest pointing to ~/guix <yenda>basically the only thing to do when adding a pypi package is to find out the missing libraries ? <yenda>couldn't it be automated based on the requirements.txt file ? <yenda>also considering the number of pypi packages at some point the python.scm package will be enormous ? <paron_remote>it may make sense to put some python things not in python.scm, but maybe that can wait till it's a big problem :) <civodul>mark_weaver: if it runs, its dependencies won't be GC'd <civodul>for instance i run a hand-built Guile, and that is fine <civodul>because the 'list-runtime-roots' script looks for /gnu/store references in lsof, in env vars, etc. <mark_weaver>civodul: the git checkout is not necessarily to be found in lsof or env vars. <mark_weaver>I have definitely had several occurrences of, e.g. the guix in my git checkout not being able to find its libgcrypt after a GC. <mark_weaver>and I'd like to know how to register a GC root for hand-built software like that, in general. <civodul>you could manually add symlinks in /var/guix/gcroots or something like that <civodul>but the best is to configure guix to refer to $HOME/.guix-profile/lib/libgcrypt <mark_weaver>civodul: okay, but what about C compiled software, where ld-wrapper will insert rpaths? <civodul>and yeah, you could use "guix build -r something libgcrypt" to register a GC root <civodul>mark_weaver: this could be a problem, indeed <civodul>except if they're actually running at the time of GC <civodul>but yeah, you can't always guarantee that <mark_weaver>'guix build -r' is not adequately documented. I'm not sure exactly what it does. <civodul>then again, if it's software that you use (as opposed to merely developing it ;-)), it probably makes sense to install it with guix rather than by hand <mark_weaver>I haven't been able to see from the docs how to register an arbitrary GC root, and what kinds of things I can register, e.g. can I register an arbitrary file/directory and how will it be scanned? <yenda>in package definitions (inputs ...) are the dependencies ? <mark_weaver>civodul: right, but as a developer, I have several git checkouts built <paron_remote>civodul: btw in response to your email, I think Deb might have a good sense of whether the people we know might actually be able to get us machines and if so who to ask, I'll talk to her about it today <civodul>mark_weaver: yeah me too, but that's usually Not a Problemâ„¢ <civodul>nowadays i use 'guix environment' with my developer hat, and that's fine <civodul>because by definition it makes sure that everything is there <yenda>civodul: adding erquirements for a pypi package was trivial but using the requirements.txt file it could be possible to import the vast majority of pypi packages all at once wouldn't it ? <paron_remote>guess I'll try installing the package without anything extra and see if it works :) <civodul>yenda: yes, but most of the time manual tweaks may be needed <civodul>'guix import pypi' honors requirements.txt now <yenda>ok maybe the package itself wasn't because I created a definition for ccm and pyyaml and six were missing <yenda>I would like to see the nomenclature for the different licences, manual says to check (guix licenses) but where do I excecute that ? <civodul>you can open guix/licenses.scm in your editor <yenda>ok I was wondering if there was a repl somewhere <civodul>if you use Emacs + Geiser, you can also browse the module this way <mark_weaver>civodul: well, what happens is that sometimes after "guix gc" the binaries in my git checkouts no longer work, and I need to "make clean" and maybe also reconfigure. <mark_weaver>it's tolerable, but there's room for improvement, I think. <paron_remote>guile-postgres installs to share/guile/site/ rather than share/guile/site/2.0 <mark_weaver>if there was a way to register that entire directory as a GC root, it would be helpful. <civodul>mark_weaver: that's less problematic with 'guix environment' IMO <civodul>mark_weaver: and otherwise 'guix build -r' might do <paron_remote>well, I submitted a guile-pg patch to the list, but with a list of things it needs help with <paron_remote>I just don't know enough about autotools to get any further than I did. <davexunit>paron_remote: usually there's guilesitedir var or something <remo3>Hello. Yesterday, when I said it took 6 hours to build GuixSD on my laptop, somebody suggested doing "guix pull" and "guix archive --authorize < $hydra_key" to ensure I avoid building from source. <remo3>I just wanted to let you know that when I experimented with those two suggestions, only "guix pull" solved the problem. After doing that (which took about 20 minutes), the build completed in about 50 minuttes instead of 6 hours. <davexunit>that's alarming. are we missing substitutes for packages at the 0.8.3 tag? <remo3>I don't really understand why that is the case, though. Do you know why this might be? <davexunit>paron_remote: is there a git repo I can browse for this? <davexunit>remo3: I'm not sure. someone that administers the build farm will have more insight. mark_weaver ? <remo3>ACTION needs to go afk for a feew hours, but will resppond upon returning. <paron_remote>davexunit: I figure it'll also be worth exploring since we're both interested in sexp reresentation of queries, and it does have "qcons" <davexunit>paron_remote: anyway, what is the output of './configure --help'? there's probably <davexunit>there's probably a flag to configure those two site dir variables <yenda>should't we have a python2 macro for python packages ? <davexunit>yenda: we have a 'package-with-python2' procedure <yenda>davexunit: feels like it's already too much repetition <davexunit>not every package can reasonably work on python2 <yenda>yes but you could have a list of the ones that do and get defined automatically <davexunit>you have to weigh the cognitive overhead of introducing a macro with the real benefit it will have. I don't think the ratio is right here. <yenda>I would even just have a list of excluded packages <yenda>because for instance I need python2-pycrypto to build ansible <yenda>and there is no reason it wasn't there since pycrypto is there <davexunit>but one still has to test that it works and all that <davexunit>perhaps there could be a macro, but I'd need to see some example syntax. <davexunit>for fun, here's a stab at it: (define-python-package python-pycrypto python2-pycrypto (package (name "python-pycrypto") ...)) <davexunit>but I'm sure someone could find flaws with it. <yenda>(define-python setuptools (2 3) (package (name "setuptools"...) <yenda>expands to 2 define-public : python2-setuptools and python3-setuptools... <davexunit>the most important of which is that the variable names are not included <davexunit>such that a grep for the variable python2-setuptools would return nothing <davexunit>it's hard for me to think that it would be beneficial right now when the boilerplate level is already so low. <yenda>it's low because the number of people using it is still low <yenda>but wait till people start using guix instead of pypi <daviid>paron_remote: davexunit, the installation path for guile-pg are determined at configure time, using his SNUGLE_* m4 macros, and it will be in: modules -- ${GUILE_LIBSITE}/database, guile-pg.info -- ${infodir}. there is no way, until patching his configure.ac file, to pass another module location as a arameter <sneek>Welcome back daviid, you have 1 message. <sneek>daviid, civodul says: news entries are moderated by each project's admins <yenda>there at least hundreds of usefull packages <davexunit>daviid: and that's why I cower in fear every time I discover that ttn is the author of a guile lib I want to use. <daviid>i abandonned the use of guile-pg a while ago for [very] bad support, imo of course <davexunit>yenda: yes, but it's 1 extra line of code for each package that should have a python2 version. I'm not very concerned about it. <daviid>ian grant was the original author <davexunit>if it does become a problem, I think we can deal with it then. <daviid>sure: rewrite the configure.ac but it also depends, iirc, on ttn's other lib/tools, which is a pain <daviid>i'd rather use guile-dbi at this point, but currently happy with guile-sqlite [which i wonder if wingo has a copy somehwre, it was on gitorious.... <davexunit>I don't want to sound ungrateful to ttn, I've used his guile-sdl library for years in Sly, but his projects are hard for people that aren't him to hack on. <davexunit>one of these days I'll get around to writing guile-sdl2 as a pure guile module with the FFI <daviid>that's going to be a lot of work no? i was wondering if we should not consider ewriting g-wrap [in the spirit of I mean], so that it does what it does :) but using the FFI <davexunit>but if other folks that want to use sdl with guile pitch in... <davexunit>I plan to wrap enough functions to port Sly to it <daviid>we need a way to bind auto, or at least semi auto, which is what g-wrap does today [it needs quite a lot of tweaking], we should rewrite that using the ffi <yenda>#:tests? #f means the package doesn't run tests ? <davexunit>yenda: yes, it means the build process will skip the 'check' phase <daviid>too bad i'm not a good C programmer, because I'd like to write that: read the .h and auto write the ffi <davexunit>daviid: we need a C parser written in Scheme that can take header files and produce Scheme wrappers <daviid>davexunit: yes, that C prser is h2defs.py [guile-gnome] <daviid>yes i did think to rewrite it in guile, but no time, i mean it's not the most urgent thing to do <yenda>davexunit: do you have an exemple of tests requiring packages not required by the package itself ? <daviid>davexunit: would that info, the content of defs files I mean, be sufficient to then write something that then use the ffi? <davexunit>yenda: you would add such packages in the 'native-inputs' field of the package <davexunit>search for 'native-inputs' and you'll see many examples <davexunit>daviid: well, ideally we want something that can be done completely within Guile <davexunit>without having to write out intermediate files to disk <yenda>davexunit: made me discover propagated inputs <davexunit>propagated inputs are for packages that get installed along with the package. <davexunit>you want to avoid them as much as possible, but there are certain situations where there's no other way. <yenda>davexunit: made me discover propagated inputs <davexunit>I wish more projects would just publish machine readable files that document the entire API <davexunit>we have good bindings for those in guile because of that <yenda>I'm adding an ansible package and a lot of packages come with it. For instance it needs paramiko and pycrypto. Paramiko needs pycrypto too so do I put pycrypto as a propagated package ? <daviid>davexunit: yes, of course this would be ideal. in the case of gnome, there is gir of course <daviid>davexunit: do you hve an xcb link [the API as you said]? <daviid>sneek: later tell civodul thanks, din't get that, there was a pending for approval in my own savannah account, my bad. tx <yenda>I just wanted to add ansible, I end up having to declare pypi <amz3>daviid: I think guile-log from stis has a c parser (and python). There are problem with packaging. <yenda>I have a test failing because "Perhaps your account does not have write access to this directory? You can <yenda>change the cache directory by setting the PYTHON_EGG_CACHE environment <yenda>variable to point to an accessible directory." <daviid>amz3: tx. my prolog knowledge is about zero though <amz3>daviid: prolog is a computation paradigme or computer language with original unary operators, it ain't alien ;) <daviid>oh, amz3 i know of course, very well the paradigm, even had exams, haha, like another century :), but knowing means, afaic, 100.000 lines of code, not less ... <daviid>so i don't know C, but i can write and read C ... <amz3>I 'll add that to the rule table <daviid>100000 [the dot is umbigious in an english channel :)] <amz3>still I'll think tha the correct code correct code doesn't take much lines ;) <amz3>shameless plug from Miles Davids <yenda>daviid: your 100000 is for C only or every language ? <yenda>ok I have to go thanks for the help guys. I'll have a look at how to contribute and I'll submit my package definitions tomorrow <rekado->yenda: sometimes python2-package and python-package have slightly different requirements / inputs. <rekado->so it still makes sense to keep them separate, in my opinion. <davexunit>it's a video feature bunnie, maker of the Novena, describing what phones could be like if users had more freedom. <daviid>paron_remote: it's been ages they claim 'The repositories will soon be available for read-only access, with original clone URLs preserved.' <paron_remote>daviid: I imagine it's no simple task to migrate all those. <daviid>sure, but why did they have to migrate anything anyway... <davexunit>daviid: they're going to put up a full read-only mirror of the site, which isn't trivial. <yenda->when you click on contribute->send a new package on the website it redirects you directly to a page to register to and browse the mailing list. It would be nice to had a short description of the process to send a new package <davexunit>basically you want to use 'git format-patch' <davexunit>and make it an inline attachment to an email <paron_remote>davexunit: thanks for the link. The photo quote is hilarious <paron_remote>"Richard Stallman (rms) wants you to buy your warez from Crowd Suppy." <paron_remote>makes me think 1990 warez sites, probably not the most rms-endorsed direction ;) <daviid>"This article was first published in the August 2015 issue of WIRED magazine." wow haha <sprang>what's the recommended method for going from guix 0.8.2 to 0.8.3 on a non-GuixSD installation? the user guide warns not to overwrite a working installation <ngz>guix pull & guix package -u <ngz>(& not in the bash sense) <sprang>ah, I tried the guix package -u, but didn't pull