IRC channel logs


back to list of logs

<crocket>Does guile emacs install packages from guix?
<crocket>Or elpa?
<zacts>crocket: I'm assuming that guix doesn't provide emacs M-x package-install packages
<zacts>also, I'm assuming that if any ELPA or MELPA packages work in guilemacs
<zacts>you would probably want to use M-x package-install or something from within guilemacs to install them, and not guix
<zacts>(although, I can't remember if guilemacs was forked from emacs 23.* or 24.*)
<crocket>zacts, 24.5
<crocket>Very recent
<zacts>oh cool
<zacts>I would try M-x package-list
<zacts>or something
<zacts>and then you could try adding MELPA, and see how far you can get with it
<crocket>guile emacs mostly works.
<civodul>Hello Guix!
<ewemoa>mark_weaver: got a message from stgit ml software saying that my message regarding the inclusion of t/ is awaiting moderation
<efraim>ewemoa: was the email message with attachment(s) too big?
<ewemoa>efraim: there was no attachment, this was just to let the stgit folks know that t/ isn't included in their recent tarballs
<_amz3_>there is a higher version of bdb available 6.1.*, should we bump it? there is also a license change to AGPLv3
*_amz3_ salute everybody
<_amz3_> is an interesting read, I recommend it :)
<rekado_>I don't understand how to run guix-web.
<rekado_>It provides guix/scripts/web.scm but I don't know how to convince my local guix command to find this file.
<rekado_>Tried fiddling with GUILE_LOAD_PATH but to no avail.
<civodul>rekado_: where's the current guix-web repo?
<civodul>the module must be name (guix scripts web), and it must export a procedure calls 'guix-web'
<iyzsong>it's at dave's home >>
<rekado_>guix/scripts/web.scm does this.
<rekado_>I have a script in /usr/local/bin named "guix" that starts my development version of guix in my home directory using ./pre-inst-env.
<rekado_>I suppose I have to set some environment variables to make it work.
<_amz3_>rekado_: ./pre-inst-env guix web in guix-web repo
<rekado_>hmm, strace says "web.scm" is read.
<_amz3_>then browse http://localhost:8080
<rekado_>_amz3_: same result: [rwurmus@guix-builder:/srv/guix-web] (616) $ ./pre-inst-env guix web guix: web: command not found
<rekado_>(I did read the file)
<_amz3_>~/src/guile/guix-web () $ ./pre-inst-env guix web
<rekado_>do you use a "make install"ed guix?
<rekado_>or is this on GuixSD?
<_amz3_>euh yes
<rekado_>I'm not on GuixSD here. (Not my private machine but a CentOS server.)
<_amz3_>maybe you can chain ./pre-init-env scripts
<rekado_>_amz3_: that's what I'm doing. Indirectly.
<_amz3_>sorry I can't help
<rekado_>I'll play with this some more.
<rekado_>guix --help only lists the included commands, not "web", even if guix-web is part of the GUILE_LOAD_PATH.
<davexunit>rekado_: that's expected behavior.
<davexunit>there's no magic. the help text is just a string literal.
<rekado_>davexunit: I'm trying to use guix web with my development version of guix on CentOS, but I cannot seem to get it to work.
<rekado_>guix always aborts telling me "guix: web: command not found".
<rekado_>I'm chaining ./pre-inst-env for guix and for guix-web.
<rekado_>I have a script at /usr/local/bin/guix that sets GUIX_PACKAGE_PATH and then runs ./pre-inst-env for guix-web followed by ./pre-inst-env for guix.
<rekado_>is this something that should obviously NOT work?
<davexunit>rekado_: the guix pre-inst-env script probably clobbers the environment built by guix web's
<rekado_>well, it doesn't matter in which order I do this.
<rekado_>and the scripts explicitly include the existing values of GUILE_LOAD_PATH, PATH, and so on.
<rekado_>"env" running inside this pre-inst-env cascade tells me that both paths are included.
<davexunit>not sure what's up then.
<rekado_>I'll investigate.
<davexunit>it obviously cannot load the proper module.
<davexunit>but I'm not sure why if the load paths are correct.
<rekado_>strace also shows me that web.scm is read (and it triggers a couple of additional imports), so I'm not sure if the error message is to be trusted.
<rekado_>maybe it points to a failure later on.
<davexunit>perhaps another exception is being eaten and you're just getting that inaccurate message
<rekado_>yeah, that's what I suspect.
<rekado_>I'll try running this in the REPL.
<_amz3_>did you try to inverse the order of pre-inst-env ?
<rekado_>_amz3_: [14:46] <rekado_> well, it doesn't matter in which order I do this.
<rekado_>I'm probably doing something weird again.
<rekado_>have to clean up this whole environment first.
<rekado_>apparently guix-web fails because it doesn't find (ice-9 hash-table)
<rekado_>I'm using guile 2.0.9 on CentOS.
<rekado_>in fact, there is no hash-table.* file on my system.
<rekado_>is this a more recent addition to Guile?
<davexunit>rekado_: yes
<davexunit>I added it ;)
<davexunit>new in 2.0.11
<davexunit>we can remove the use of that, or rather snarf the implementation and put it into the guix-web repo
<davexunit>it's not much code
<rekado_>I guess it would be good if the configure script checked for the existence of (ice-9 hash-table)
<civodul>davexunit: yeah maybe it'd be easier to copy that code into guix-web proper for now
<rekado_>with the hash-table.scm file from latest guile it seems to work.
<rekado_>I'm running it inside a "guix environment -l env.scm" session, though, because of guile-json and other dependencies I might be missing.
<crocket>I realize that guix could be used for third party repositories such as a guile module repository.
<crocket>The needs of other distros could break GuixSD potentially.
<_amz3_>crocket: I don't know guix good enough, but my understanding is guix will always work on top of other distros
<_amz3_>I don't think so.
<crocket>The main repository will be intertwined with the needs of GuixSD and various factions.
<crocket>Guix may be able to handle this with functional package management, but I'm not sure.
<_amz3_>crocket: sorry corcket, but I can argue with you since I don't understand your argument. Sincerly I think it's something "that can't happen"
<_amz3_>you argue that something *might* happen, that will make guix not useable on other distributions?
<crocket>If the official ubuntu repository had to cater to pip modules and cabal modules, then what would happen?
<crocket>I'd expect big collisions
<crocket>Some pip modules would break ubuntu...
<crocket>like pyzmq
<_amz3_>guix software are installed in parallel in a completly separate repository. It doesn't live in the same "world" as ubuntu and other distros directories, they can never collied
<_amz3_>*except* because of environment variables / PATH / PYTHONPATH and things like that
<_amz3_>but it won't break your system
<crocket>I still don't understand how guix works.
<_amz3_>every software in guix is installed in /gnu/store/...-name-of-software
<crocket>Does it host multiple versions of the same package?
<_amz3_>let me try to explain
<_amz3_>the directory "...-name-of-software" has every files of the build software man pages, libs, headers and stuff
<_amz3_>this can't collide with say ubuntu
<_amz3_>in another directory, your guix profile, they are symbolic links to the files of the softwares you installed.
<_amz3_>then, you have to tweak your environment so that those softwares are accessible by updating $PATH, $PYTHONPATH and other env variables
<_amz3_>that's where things can collide
<_amz3_>but it's harmless
<crocket>_amz3_, By the way, I was arguing that if the official ubuntu repository hosted language specific modules, too, there would be big problems.
<_amz3_>no, because guix install language specific modules in /gnu/store too
<crocket>_amz3_, I wasn't talking about guix.
<_amz3_>yes I understand, they won't overwrite ubuntu files
<_amz3_>guix won't overwrite ubuntu, and ubuntu won't overwrite guix files. never.
<crocket>If all python modules were installed by apt-get, I'd expect a big disaster, so I expected a similar result from guix before.
<_amz3_>do think about venv?
<_amz3_>and multiple version of the same package?
<crocket>I haven't tried that part.
<_amz3_>venv works in guix I use them daily, it's the same as ubuntu
<crocket>apt-get doesn't have venv.
<_amz3_>"multiple version of the same package" is one of the useful feature of venv
<_amz3_>(guix has equivalent thing to venv)
<_amz3_>(but this can be misleanding)
<crocket>Your english is ambiguous from time to time.
<_amz3_>here is my $PYTHONPATH
<_amz3_>$ echo $PYTHONPATH
<_amz3_>if you install guix over ubuntu, you can choose to have the regular ubuntu $PYTHONPATH + the above paths or only guix's $PYTHONPATH
<crocket>In any case, it's hard to make guile people use guix as official guile module repository.
<_amz3_>I don't understand why
<crocket>guix is not advertised as such
<_amz3_>maybe not
<_amz3_>but it's clear that being written in Guile, it has good guile support
<crocket>Is guix aware of PYTHONPATH?
<_amz3_>I don't know the details, I just know that when I install Oracle Berkeley DB with guix, and python-bsddb3 with in a venv everything works as expected
<_amz3_>this is the most complex I know of and it works
<_amz3_>I mean there is also kivy which is more complex (cython dependency)
<_amz3_>guix has cython
<crocket>Does guile have any other centralized module repository other than guix?
<_amz3_>(kivy builds c with and without cython)
<crocket>By piggybacking on distribution repositories, guile couldn't build up momentum.
<_amz3_>private ones
<_amz3_>I think
<crocket>Do you mean unpopular private repositories that almost no one knows?
<_amz3_>ah sorry you talk about guile
<_amz3_>there is guildhall
<crocket>guildhall doesn't even have search.
<_amz3_>crocket: write it :)
<crocket>I'm one of late adopters.
<crocket>I don't think it's worth my time to push it forward.
<crocket>Where does guildhall fetch modules?
<crocket>only from github?
<crocket>Since there is no documentation, it's hard to know.
<crocket>_amz3_, How have guile users fetched third party modules?
<_amz3_>crocket: I don't know I use guix :)
<crocket>I think guix has a potential as a guile repository.
<crocket>Other languages wouldn't adopt guix, though.
<ijp>good thing you know what you are talking about
<ijp>oh wait
<davexunit>oh boy
<davexunit>"open container project"
<davexunit>the container standard developed will surely be incompatible with guixsd.
<davexunit>given that we will be able to deduplicate files for all containers on a single host with a bind-mounted /gnu/store
<davexunit>and containers as popularized by Docker are just disk images.
<davexunit>lol and of course the example systemd file for 'runc' is for a proprietary server program.
<Sleep_Walker>davexunit: it is still step forward
<Sleep_Walker>it's amazing that they put all the big players together
<Sleep_Walker>and having some standard followed by all is generally beneficial
<Sleep_Walker>how I miss something like that in mobile sector :(
<davexunit>I'm not sure how good it is.
<davexunit>I think the agreed upon format will neglect our (and Nix's) use-case.
<davexunit>in our case the important files are all outside of the container, in /gnu/store
<davexunit>we don't need no disk image.
<_amz3_>If i'm not mistaken it's, because nix and guix have reproducible builds, which is not the case of all other distros. this is wrong imho but they want ot fix that too with docker and the like
<davexunit>solving the problem at the wrong layer
<davexunit>our builds aren't really reproducible, so let's just build a disk image and ship it everywhere.
<_amz3_>is it correct that with guix container, I ship a recipe.scm file and I can run my application in a container?
<_amz3_>there is an advantage to image, they save disk space because they share some things
<davexunit>_amz3_: there's going to be an 'eval-in-container' procedure that creates a guile script that creates a container and evaluates the desired code
<davexunit>will be pretty cool
<_amz3_>runc can run with directory only
<davexunit>yeah, you specify a directory for the chroot
<davexunit>'guix container' will probably have something similar for daemon-less operation
<_amz3_>it looks nicer than docker
<davexunit>right now all my container stuff is hard coded to use /tmp/container ;)
<zacts>wait, can guix boot HURD yet?
<zacts>or does Guix even run as a package manager on-top of HURD yet?
<zacts>(just curious) :-)
<ph4nt0mas>zacts: we are close to have Guix running on top of Hurd :-)
<zacts>oh nice!
<zacts>I can't wait
<civodul>rekado: so how far did you go with guix-web?
<zacts>ph4nt0mas: so just to be clear, you mean Guix on top of Debian HURD as a package manager?
<ph4nt0mas>zacts: yes
<davexunit>paron_remote: hehe
<civodul>iyzsong: mysql has 140 MiB in bin/, should we split it out?
<davexunit>140? how...
<davexunit>what's taking up all that space
<civodul>there's 45 binaries in there, dunno what they're about :-)
<civodul>hmm mplayer2 segfaults after core-updates merge
*paron_remote thinking of doing a short HPR episode on Guix
<paron_remote>I ought to start contributing
<paron_remote>hpr being
<ijp>I didn't realise that was still going
<paron_remote>still going, still some good stuff coming out now and then
<paron_remote>it's better than many of the other tech podcasts out there ;p
<zacts>which podcast is this
<zacts>of HPR
<zacts>I also like gnu world order
<zacts>and I think klattu from GWO also sometimes guest hosts HPR
<zacts>he is a heavy slackware user though
<zacts>he uses emacs a ton
<nully>davexunit: i stole your mark_weaver
<nully>MH is an expert letter folder
<nully>i think i found his lost calling
<davexunit>nully: hehe
<davexunit>nully: will you still be stuffing on wednesday?
<davexunit>I want to come on down after work and help out