IRC channel logs


back to list of logs

<jsgrant>Congrats on 0.8.3! I plan to start making occasional/drive-by contributions again, starting this cycle. :^)
<amz3>jsgrant: me too!
<davexunit>ACTION tries to figure out why 'make' segfaults inside containers
<davexunit>something to do with psuedo-terminals, I suspect, but no idea really.
<mark_weaver>davexunit: could you arrange to have it dump core?
<davexunit>mark_weaver: a bit sad, but I've never actually done that before.
<davexunit>I'll look up how to get that.
<davexunit>mark_weaver: okay, I have a core dump.
<davexunit>here's the strace output, too:
<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
<mark_weaver>gdb <program> <core>
<davexunit>mark_weaver: okay thanks
<davexunit>I'll try that
<davexunit>I'll rebuild my container so that gdb is available
<davexunit>adhoc: they are coming.
<adhoc>davexunit: good
<mark_weaver>you can run gdb on the core file outside of the container
<davexunit>in fact I'm working on it right now.
<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
<adhoc>scp ?
<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
<mark_weaver>sounds good
<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>well, both
<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
<davexunit>adhoc: this would replace docker.
<adhoc>even better =)
<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?
<davexunit>I will do that.
<mark_weaver>I guess the usual guixy way would be to add a "debug" output.
<mark_weaver>or you could remove the strip phase
<mark_weaver>the latter might be a bit easier
<davexunit>I'll try adding the debug output
<davexunit>if that will DTRT
<davexunit>I don't really grok how adding an additional output would magically make the debugging symbols appear
<mark_weaver>see section 6.3 of the guix manual
<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 ?
<davexunit>mark_weaver: cool
<davexunit>thank you
<mark_weaver>adhoc: I don't know what you mean
<adhoc>never mind, you have a debug stream
<mark_weaver>davexunit: in this case, it might be easier to just remove the strip phase
<mark_weaver>then you don't even have to worry about that stuff
<mark_weaver>oh, there's a #:strip-binaries? argument
<mark_weaver>so just pass #:strip-binaries? #f to arguments
<davexunit>mark_weaver: here's how my gdb session turned out:
<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 <
<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?
<davexunit>you need to be root to run that
<davexunit>ACTION is falling asleep
<adhoc>isd: you are about ten minutes ahead of me =)
<isd>adhoc: :P
<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
<civodul>Hello Guix!
<yenda>Hello Guix!
<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>should be fixed
<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: ~/testing should not exist.
<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 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>me too
<yenda>well I still have much to learn with guix so I can wait.
<alezost>yenda: "guix" completions in Emacs are faster. I explained it here: <>
<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>has anyone encountered this before?
<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: I'd probably run it on a Libreboot X200 from Gluglug.
<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)
<davexunit>ACTION uses it
<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>alezost: Nice.
<csed>francis7: Then great, don't need guile-emacs. But was hoping to give it a try.
<civodul>phant0mas: never seen that before
<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?
<davexunit>I ran: 'guix download'
<davexunit>and got the error:
<davexunit>ERROR: Bad media-type header component
<davexunit>guile's http header parser doesn't like it
<yenda>paroneayea: do you know what it takes to make guile-emacs work ?
<davexunit>when I run 'wget --server-reponse --spider' I do not see the media-type header.
<yenda>anyone tried running clojure on guix ?
<iyzsong>someone did, but can't get certs working IIRC.
<davexunit>a-ha, there's a blank Content-Type header
<davexunit>is this Guile's bug, our rubygem's bug?
<yenda>iyzsong: what certs ?
<civodul>iyzsong: this?
<civodul>davexunit: probably a (web client) bug or misplaced strictness
<davexunit>civodul: see #guile
<davexunit>I think we should default to application/octet-stream
<civodul>ah yes
<davexunit>I'll have to see how to patch this for guix.
<davexunit>it's blocking my rubygems adventue
<civodul>monkey-patching to the rescue?
<davexunit>I think it's monkey-patching time
<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>no need to edit the source file from guiile
<davexunit>we'll just load the monkey patch somewhere in guix
<yenda>emacs style
<davexunit>dynamic language environment style. :)
<davexunit>lisp environments are very malleable
<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
<davexunit>Rails ActiveSupport, I'm looking at you.
<davexunit>but it's a useful tool.
<civodul>rekado_: just noticed your reply to Markus; mine is at
<civodul>we stripped the Cc list differently ;-)
<davexunit>civodul: nice response
<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?
<amz3>héllo :)
<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?
<amz3>LGPLv3 or AGPL or GPL?
<amz3>it's nice i think
<davexunit>yes, it is very good.
<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 ?
<davexunit>yeah I think that's right
<davexunit>ACTION hasn't actually used guix edit yet
<yenda>and what do I do once it's done ? make and ?
<davexunit>make && guix build python-yenda
<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 I need the page that's written for a kindergardener...
<yenda>make command not found ? what ?
<davexunit> for the general page
<davexunit>with a FAQ and such
<carif>davexunit, there, ty
<yenda>davexunit: is it possible that gc garbage collected the make command ?
<davexunit>I don't understand.
<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
<mark_weaver>yenda: was that 'make' command in your profile?
<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
<mark_weaver>you were running it directly out of /gnu/store?
<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>there ya go
<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
<mark_weaver>another solution is to register GC roots as needed.
<yenda>I added my package definition in python.scm, make && guix build python-ccm but it doesn't find my package
<yenda>did I miss something ?
<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.
<davexunit>my bad.
<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
<davexunit>makes me a happy camper.
<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.
<yenda>or revert last commit ?
<mark_weaver>yenda: and maybe recompile, yeah.
<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 ?
<mark_weaver>yenda: created what symlink?
<yenda>ln -s ~/.config/guix/latest ~/guix
<mark_weaver>yenda: you got the arguments reversed
<mark_weaver>rm ~/.config/guix/latest && ln -s ~/guix ~/.config/guix/latest
<yenda>oh ty
<yenda>it works
<yenda>now I have to debug though
<mark_weaver>yenda: you probably now have a symlink ~/guix/latest pointing to ~/guix
<mark_weaver>sorry, pointing to ~/.config/guix/latest
<yenda>yes I deleted it
<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
<civodul>instead of the actual 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?
<paron_remote>ACTION packages guile-pg
<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
<paron_remote>since I'm at oscon anyway
<civodul>paron_remote: ooh good, thanks!
<paron_remote>no promises either way! but we'll see.
<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
<civodul>yenda: yes, see
<paron_remote>hm, does libpq come with postgresql?
<paron_remote>maybe I need to package this too
<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.
<civodul>yes, surely
<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.
<paron_remote>not sure how to fix that.
<civodul>mark_weaver: that's less problematic with 'guix environment' IMO
<civodul>mark_weaver: and otherwise 'guix build -r' might do
<civodul>ACTION has to go
<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.
<paron_remote>davexunit: hm I see. In the changelog:
<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: for the patch or guile-pg?
<davexunit>paron_remote: guile-pg
<paron_remote>davexunit: np
<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"
<paron_remote>though I wish it had sample usage docs of qcons
<paron_remote>er, examples
<paron_remote>not just function reference
<davexunit>oh boy it's a ttn project
<davexunit>thien-tyu nguyen's handle
<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>I don't think so.
<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>it's trivial to add it.
<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>there's several issues with that
<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
<yenda>yes yours better
<davexunit>there's potential problems with mine, too.
<davexunit>making good syntax is a craft.
<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, -- ${infodir}. there is no way, until patching his 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
<yenda>s/there/there is
<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 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>it's going to be some work, yeah.
<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
<davexunit>and then release it
<davexunit>and hope others contribute
<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 [guile-gnome]
<daviid>is currently
<davexunit>needs a py -> guile conversion
<daviid>yes i did think to rewrite it in guile, but no time, i mean it's not the most urgent thing to do
<daviid>davexunit: the def file for gtk is 28000 lines, just as an example, here is the link:
<davexunit>daviid: of course, bigger fish to fry.
<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.
<daviid>davexunit: yes, sure
<yenda>davexunit: made me discover propagated inputs
<davexunit>I wish more projects would just publish machine readable files that document the entire API
<davexunit>like xcb and opengl
<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 :)]
<daviid>yep, good idea
<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 ?
<amz3>yenda: he is jocking
<paron_remote>gitorious totally down for now
<paron_remote>guess I'm not porting that to guix quite yet
<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>not strictly guix related, but I recommend that people 'guix package -i youtube-dl' and 'youtube-dl'
<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.'
<rekado->davexunit: nice!
<paron_remote>daviid: yeah :\\
<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.
<davexunit>mark_weaver: wow!
<davexunit>(forgive the title)
<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>yenda-: agreed
<davexunit>our HACKING file should explain this
<davexunit>pretty sure it says the criteria
<davexunit>basically you want to use 'git format-patch'
<davexunit>to create the patch
<davexunit>and make it an inline attachment to an email
<yenda->there is this page of the manual
<davexunit>yeah that's it
<bavier>davexunit: thanks for the links
<davexunit>bavier: yw!
<davexunit>bavier: how about another? :)
<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 ;)
<bavier>davexunit: thanks ;)
<daviid>"This article was first published in the August 2015 issue of WIRED magazine." wow haha
<bavier>great read
<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