IRC channel logs

<nkar>I'll continue tomorrow

<civodul>nkar: that thing means add (search-path-specification (directories '("lib/coq/${coq-version}/user-contrib")) ...)

<civodul>-add

<civodul>good night/day!

<nkar>mark_weaver: I guess I'll try to package camlp5. not sure which version of camlp I used when I built coq on mips (without guix), but I have both 4 and 5 installed. I also noticed that the nix recipe builds with campl5 and removes a camlp4-related line from configure.

<nkar>build succeeded

<nkar>after installing autoconf on the standalone system, ./bootstrap still cannot find autopoint. ideas?

<Steap_>nkar: at least on Debian, autopoint is in a separate package, maybe it's also the case for Guix ?

<tadni>nkar: I really need to write a guide for this.

<tadni>It's very obnoxious to get Guix to go on a standalone system, because a lot of it is setting paths that should automatically be set and stuff like that.

<Tsutsukakushi>wouldn't it be better to make it automatigically set those up instead of writing a guide?

<nkar>Steap_: it's not

<nkar>tadni: the only envvar I set is ACLOCAL_PATH

<nkar>Steap_: how much time does ocaml's testsuite take?

<Steap_>nkar: cant remember, I packaged OCaML a long time ago :/

<nkar>I'm building 4.02.1 and it's been running the tests from tests/tool-debugger/basic for quite a while

<tadni>Tsutsukakushi: Ideally, I wish we just had a "guix dev-setup" or something, that set an empty user and package profile with all the depends and clones the latest git build.

<tadni>Yeah, maybe we can hack something on top of guix environment -- that makes an empty "guixdev" user or something.

<nkar>sneek: later tell civodul after installing autoconf on the standalone system, guix's ./boostrap fails to find autopoint.

<sneek>Okay.

<nkar>sneek: botsnack

<sneek>:)

<tadni>Tsutsukakushi: But yeah, the developer environment for Guix on GNU Distro could/should be radically improved.

<tadni>I think Guix Environment is probably a good start, that was recently put into place.

<tadni>Not sure if environment or just making a separate, specific guixdev and guixuser profile would be better though.

<tadni>sneek: later tell civodul Hey, I hope the current wiki distro name list is good enough on my end. Feel free to delegate the task to someone else, but I'm going to be gone until like this coming Thr or Fri -- so I have to drop adding any more names until then. See ya in a little under a week!

<sneek>Okay.

<tadni>Okay, I need to get ready for class. Going afk; See y'all in about a week after finals and all that! o/

<mitc0185>can anyone recommend a wifi card (minipci) that has a completely gpl driver and will work on guix?

<gry> https://h-node.org/wifi/catalogue/en/1/1/undef/undef/yes/mini-PCI/undef/undef might be relevant

<mitc0185>no wifi cards found...

<civodul>Hello Guix!

<sneek>Welcome back civodul, you have 2 messages.

<sneek>civodul, nkar says: after installing autoconf on the standalone system, guix's ./boostrap fails to find autopoint.

<sneek>civodul, tadni says: Hey, I hope the current wiki distro name list is good enough on my end. Feel free to delegate the task to someone else, but I'm going to be gone until like this coming Thr or Fri -- so I have to drop adding any more names until then. See ya in a little under a week!

<civodul>nkar: autopoint is part of Gettext, so you need to install that as well

<civodul>ok tadni, thanks!

<nkar>civodul: you're providing first class support

<civodul>that's because everyone deserves first-class support ;-)

<nkar>awww :)

<mitc0185>civodul: sneek is a bot?

<civodul>yes

<civodul>sneek: version

<sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs

<nkar>civodul: after guix package -i gcc, ./configure says that gcc cannot create executables

<civodul>yes, you need to install gcc-toolchain, which also includes Binutils and libc

<civodul>i reckon that it's not obvious

<nkar>would be cool to create a script for installing guix from guix

<davexunit>nkar: building guix from guix? 'guix environment guix' should get you everything you need to build.

<civodul>yes, it really rocks

<davexunit>you still have to do the './configure --with-libgcrypt-prefix=$(guix build libgcrypt)' yourself, but it gets the dependency fetching out of the way

<nkar>davexunit: to clarify: I'm installing a version from git. was the mentioned command written for that?

<nkar>

<davexunit>yes, it will work because the 'guix' package is the guix-devel package.

<davexunit>so it will fetch the autotools and such

<davexunit>for the future, it might be nice to have a file in the root of the source tree that is explicitly for this.

<nkar>cool

<davexunit>then you could just do 'guix environment -l development.scm'

<nkar>so it's a sandbox, right? is there a way to install the same deps systemwide if I want to?

<nkar>something like guix environment --expose guix

<civodul>*note to alezost: M-x guix-environment would be cool, so that one can use M-x compile in a specific environment

<davexunit>oooh yeah

<davexunit>I *really* wanted that recently

<davexunit>but wasn't sure how to get it.

<davexunit>nkar: I think guix environment would be the wrong tool for that.

<civodul>actually maybe M-x guix-compile could ask for an environment or something, and built it on the fly

<civodul>might be fast enough

<davexunit>it's a bit slow atm

<civodul>the command is slow, but the integration with the Guix REPL would be less slow i think, due to memoization

<nkar>does nix have an emacs mode?

<davexunit>civodul: ah, perhaps.

<civodul>nkar: only for syntax highlighting

<nkar>hah, take that, nix!

<civodul>:-)

<civodul>along with Magit, guix.el is in my top-5 of UIs

<nkar>what are the other 3?

<civodul>good question!

<civodul>Geiser

<civodul>and i'd need to think more for the others ;-)

<nkar>paredit?

<davexunit>not really a UI

<civodul>yes, but it's not a UI

<amirouche>emacs ;)

<davexunit>magit and geiser are my top 2 for sure.

<davexunit>notmuch.

<davexunit>that's on my top-n list

<civodul>davexunit: you use notmuch?

<davexunit>yes

<davexunit>I really like it, but I do have some workflow issues to deal with.

<nkar>mark_weaver wanted to swtich to notmuch from gnus, iirc. what are the benefits compared to gnus?

<davexunit>notmuch is a standalone program that uses xapian to index your mail collection

<davexunit>it allows for really fast and nice tagging and searching of mail

<nkar>cool

<davexunit>and it comes with a CLI and Emacs interface

<davexunit>the emacs interface is very nice.

<kmicu>You can also choose mu/mu4e if you like a notmuch’s design principle, but not much notmuch’s UI/workflow.

<civodul>mu4e looks quite cool as well, indeed

<alezost>civodul: noted; I'll try to do something about it (M-x guix-compile), but not in the nearest future

<civodul>but Gnus has all these bells and whistles

<kmicu>Documentation is much better. The rest is similar.

<civodul>alezost: heh, np, sorry for harassing you once again!

<alezost>no problem :-)

<davexunit>my problem with notmuch is syncing things between many computers.

<davexunit>I need a purely functional mail indexing setup, I guess. :)

<davexunit>so I don't have to clear the same mail out of the inbox on every computer.

<civodul>heh, i see

<davexunit>I need to better learn how to use maildir I guess, so I can move mail out of the inbox to another directory if the inbox tag has been removed.

<nkar>after running 'guix environment guix', I get a syntax error near have_guile_json (on ./configure)

<civodul>nkar: probably because an Autoconf macro was missing last type you run ./bootstrap

<civodul>try re-running autoreconf

<nkar>no difference

<civodul>could you copy/paste the error?

<rekado>Hi guix!

<nkar>rekado: hi

<davexunit>nkar: I feel like I've seen that one before

<davexunit>maybe you're missing an environment variable?

<nkar>who knows

<civodul>ACLOCAL_PATH maybe?

<nkar>already set

<rekado>I had the idea of using Guix at work to allow us to offer to cluster users their preferred versions of their bioinformatics software.

<rekado>Is it possible to use a different directory for the store?

<rekado>i.e. place the store under some prefix?

<nkar>there's a configure flag, iirc

<nkar>--with-store-dir

<rekado>nkar: ah, good.

<rekado>There's one more thing I'm not sure of: when software is built does it really no longer depend on anything in the environment?

<rekado>i.e. will I be able to run the software on a machine with Ubuntu 10 just as well as on CentOS 7?

<Tsutsukakushi>if it's statically compiled

<nkar>civodul: ./configure: line 7116: syntax error near unexpected token `have_guile_json,' [...] GUILE_MODULE_AVAILABLE(have_guile_json, (json))'

<civodul>yes, it really no longer depend on anything in the environment

<civodul>nkar: that's because guile.m4 was not in $ACLOCAL_PATH when you run autoreconf

<rekado>it doesn't need to be statically compiled, because the packages describe their inputs fully, right?

<civodul>exactly

<rekado>awesome

<civodul>shared libraries have a RUNPATH

<civodul>note that if you use a different store directory, you'll be unable to use binaries from hydra.gnu.org

<rekado>that's okay. We have a powerful cluster here which I could use to compile stuff.

<civodul>ok

<rekado>if I can get it set up I might create a lot of bioinformatics packages; would these packages be welcome in the general guix distribution?

<nkar>civodul: there's an m4 file in the store, do I need to copy it by hand?

<civodul>rekado: surely! as long as it's free software

<rekado>great

<civodul>nkar: normally all that's needed is to have /path/to/guile/share/aclocal in $ACLOCAL_PATH

<rekado>right now I'm building RPMs, mostly, and it's getting very difficult to rebuild packages with different prefixes to satisfy different user requirements.

<civodul>i can imagine

<rekado>guix really could solve this problem for us.

<civodul>rekado: i'm interested in your experience report

<rekado>(and I would have a totally legitimate excuse to work on free software at work)

<civodul>heh

<civodul>we have plans to use it on a cluster at work

<civodul>but compute nodes do not have Internet access

<civodul>so that makes things a little bit more difficult

<nkar>civodul: I confirm that it's not in the ACLOCAL_PATH by default

<civodul>weird

<civodul>well, you can add it manually, then

<rekado>civodul: can't the offload facility be used to redirect to a build node with Internet access?

<nkar>just did. and now I finally see the libgcrypt error that davexunit implicitly warned me about

<rekado>most of the nodes here are also without Internet connection, but I suppose I could find a way to offload downloading to a node that does.

<civodul>rekado: yes it can, that's one possibility

<rekado>woo, I'm very excited about this!

<civodul>yeah i think you could configure run the daemon on net-less nodes with --max-jobs=0, and with offloading support

<civodul>meaning that they'll defer everything to the other node

<rekado>I've been following guix since version 0.2 was announced but I never got around to playing with it long enough.

<civodul>maybe now is the right time :-)

<nkar>how can I find out the location of the package in the store?

<civodul>"guix build the-package"

<rekado>civodul: yeah, everything has lined up just perfectly. Thanks for everything!

<nkar>./configure succeeded, finally

<nkar>thanks all

<davexunit>woo!

<nkar>this may be very frustrating for a newcomer, I need to document everything I did

<rekado>I see that the gtk2 package includes a definition for python2-pygtk, but the gtk backend in the python2.7 package definition is commented. Is there anything blocking this?

<civodul>i don't remember

<civodul>this may have been discussed on the list

<civodul>too bad there's no comment explaining that

<nkar>./pre-inst-env guix system reconfigure /etc/config.scm returns "system locale lacks a definition", but there's (locale "en_US.UTF-8") what's wrong?

<alezost>nkar: it should be (locale "en_US.utf8")

<nkar>oh, thanks

<nkar>civodul: does hydra need a replacement?

<nkar>how hard would it be to rewrite?

<taylanub>I wonder why utf8 and not UTF-8, when the latter is the conforming name?

<taylanub>to compensate for broken software?

<civodul>taylanub: actually i think that's the canonical name in libc

<civodul>nkar: it does; but it's quite a bit of work to replace

<nkar>so, not a weekend project, right?

<davexunit>not at all.

<civodul>not really, no :-)

<davexunit>lots of perl and stuff to replace... with guile. :)

<civodul>that said, a week-end project would be "guix publish", which would publish the store in a Hydra-compatible way over HTTP

<taylanub>I guess one should ask them then; the official conforming name is UTF-8, capitalized and with the ASCII minus. :P

<civodul>so you could point 'guix substitute' to that server

<davexunit>civodul: oh that would be cool

*davexunit notes

<civodul>there's already some core in the test suite to generate .narinfo etc.

<civodul>*code

<davexunit>are you aware of the routes that need to be exposed by the http service?

<davexunit>or rather, are they documented by the nix folks?

<civodul>yes, undocumented

<civodul>but 'guix substitute-binary' has code to read those files, and some tests produce them

<civodul>it's not very complicated

<davexunit>but as far the HTTP API, is it just a single route?

<davexunit>I guess I'm curious how many different URIs the server would have to respond to

<nkar>aaand ./pre-inst-env guix system reconfigure fails. okay, I'll put it aside for a while

<Sleep_Walker>when filesystem is btrfs, mkfs.btrfs is missing in initrd

<civodul>Sleep_Walker: right; i sort of decided to start ext4-only

<civodul>but yeah, that needs to be improved

<civodul>davexunit: there 3 URIs: /nix-cache-info (static meta-data), /<hash>.narinfo (per-item meta-data), and /<hash>.nar (archive of a store item, as per 'guix archive --export')

<davexunit>civodul: oh cool, and since the code handle that file format already exists, it should be pretty simple to write a little web server for it.

<davexunit>sounds like a fun, small project. I'll see what I can do. :)

<Sleep_Walker>civodul: and btw. I verified that reverting cc7fa59 fixed by problem

<Sleep_Walker>hm, which version I use? `guix --version' says 0.9, guix package -s guix says 0.8, guix pull said third value...

<davexunit>you are using the pre 0.9 release version, because you used guix pull.

<Sleep_Walker>I called it 0.8+

<Sleep_Walker>davexunit: it would be useful if guix actually could find which version it is :)

<davexunit>guix --version tells you

<davexunit>the guix package recipe points to an older version, so that explains 'guix package -s guix'

<davexunit>and I don't remember the output of guix pull, but might it include the git SHA?

<Sleep_Walker>yes, it uses part of hash

<Sleep_Walker>but I couldn't find it

<Sleep_Walker>first attempt for bug report sent :b

<Sleep_Walker>mail interface looks interesting in comparison to bugzilla or trac

<davexunit>'git show <that-hash>' in the guix repo doesn't show anything?

<Sleep_Walker>davexunit: sorry, you misunderstood me, besides `guix pull' where the hash is visible I couldn't find it anywhere later

<davexunit>ah I see.

<davexunit>yeah, it wouldn't be.

<davexunit>guix pull is just telling who which commit it's using

<davexunit>it's not really part of the version number

<Sleep_Walker>and another thing, to use `guix pull' it seems I need to have installed guix (guix package -i guix), but it is not obvious neither from documentation, neither from --help message... should I file report as well?

<Sleep_Walker>(in this context I'm talking about guix package manager running on top of another distribution)

<civodul>davexunit: cool!

<civodul>Sleep_Walker: could you report one bug for each remaining problem?

<civodul>like the reversal of the commit you mentioned

<civodul>i'm afraid of forgetting everything otherwise :-)

<civodul>oh i see you already reported bugs actually

<civodul>ok, nevermind

<Sleep_Walker>civodul: sure, I'm about to start with that...

<Sleep_Walker>not to lost track of that

<civodul>thanks

*civodul has to go

<th3kent>hello guix!

<Tsutsukakushi>hai

<davexunit>hey there!

<th3kent>anyone running the guix distro on a laptop, bare metal?

<davexunit>I ran it on a borrowed x60 for a bit, but not anymore.

<th3kent>i assume it ran without a hitch on the x60?

<Sleep_Walker>I'm about to do so X230

<nkar>sneek: later tell civodul ./pre-inst-env guix system reconfigure /etc/config.scm failed with "unexpected EOF reading a line". when I tried to run it again, I got "/bin/sh: bad interpreter". and 'ls', for instance, returns "/gnu/store/.../bin/ls: No such file or directory". what should I do?

<sneek>Got it.

<davexunit>nkar: the first part sounds like your config has a syntax problem

<Sleep_Walker>nkar: and does your ls and sh really exist?

<nkar>probably not

<Sleep_Walker>it did before, but after `guix system reconfigure /etc/config.scm' it stopped?

<nkar>davexunit: unfortunately, I can't verify since every command fails, and I don't want to reboot until I hear from ludo

<nkar>Sleep_Walker: yes

<nkar>sneek: later tell civodul: I found a single warning in the build log: setlocale: LC_ALL: cannot change locale (en_US.UTF-8). that's the old (and incorrect) value I used.

<sneek>Got it.

<nkar>davexunit: that's inside the evironment, so maybe it's not that bad

<nkar>n*

<davexunit>hmmm

<davexunit>things should work in the env...

<nkar>if I exit the env, will I go back to the working state?

<davexunit>yeah, the env just sets up some environment variables for you.

<davexunit>it's possible that your shell unset them upon launch

<davexunit>depending upon your configs

<th3kent>now that i know about the gluglug x60, it's time to invest in hardware that respects my freedom 8-)

<Sleep_Walker>isn't it better invest to some x230?

<Sleep_Walker>hmm, it is not offered

<davexunit>I think the x200 is going to be next

<th3kent>xan you get the x230 with libreboot???

<th3kent>s/xan/can/

<davexunit>the libreboot people seem to have an experimental working version for the x200

<davexunit>I want libreboot for my x220

<davexunit>th3kent: I don't think so.

<Tsutsukakushi>getting wholly free pc would be so nice

<davexunit>but I don't know that

<Sleep_Walker> http://www.coreboot.org/Board:lenovo/x230

<Sleep_Walker>support looks good

<Sleep_Walker>but last time I asked on FOSDEM it needed to be opened and flashed from outside

<Sleep_Walker>otherwise I'd use it already :)

<Sleep_Walker>and I don't think there will be any better model

<Sleep_Walker>x240 is just awful

*Sleep_Walker sees slim login screen in Guix distribution for the first time :')

<davexunit>:)

<davexunit>joeyh, former debian guy, writing system configs and deployment system in haskell http://joeyh.name/blog/entry/clean_OS_reinstalls_with_propellor/

<paroneayea>davexunit: I was just about to link you that

<paroneayea>there's a lot of overlap with things happening here and htere

<nkar>davexunit: former?

<paroneayea>nkar: yeah, he's been disappointed with the governance of the project (esp the way general resolution was used against systemd and etc)

<nkar>ah, i though it's because of debian's doubletalk

<nkar>t*

IRC channel logs

2014-12-05.log