IRC channel logs

<davexunit>woo, tornado warning here in boston. I would laugh at this if one didn't actually touch down in this state 3 years ago.

<civodul>ouch

<civodul>crossing fingers...

<davexunit>funnel cloud seen, but no touch downs.

<bavier>civodul: re i686 glib, the old version couldn't cross-compile either, so I don't have any way to test the i686 build

<civodul>okay

<civodul>bavier: it's native compilation on i686 that fails, not cross-compilation

<civodul>(you can do that with "guix build glib -s i686-linux" from x86_64)

<civodul>it's hard to tell if it's a transient error or not, though

*civodul -> zZz

<civodul>talk to you tomorrow!

<DusXMT>In a multiuser system, how is guix installed? (i.e. is there a system-wide profile to which I can install the dependencies of guix, or should I dedicate a user for it?)

<DusXMT>Okay, I went for the latter

<jmd>W

<jxself>X

<jmd>Debugging an installed program, all the symbol information seems to be missing.

<davexunit>how easy is it to generate an installation image for i686 instead of x86_64?

<civodul>davexunit: trivial! :-)

<civodul>guix system disk-image gnu/system/install.scm -s i686-linux

<civodul>also with --image-size=850MiB or so

<davexunit>cool. the FSF is going to let me borrow a thinkpad x60s, but it's 32 bit only.

<civodul>oh, actually -s is missing

<civodul>woow, cool

<davexunit>since guix is 100% free software :)

<civodul>i was looking at conkeror.scm and just discovered that we can do this:

<civodul>(define-module (gnu packages conkeror)

<civodul> #:use-module ((guix licenses) #:prefix license:)

<civodul>and i thought i new Guile

<civodul>davexunit: yeah, we'll have to restart the FSF procedure to get listed among the free distros

<davexunit>didn't know about #:prefix

<davexunit>civodul: did you already try before?

<civodul>yes

<civodul>they wanted a bootable system

<davexunit>oh okay.

<davexunit>was that from the licensing team?

<civodul> http://lists.nongnu.org/archive/html/gnu-linux-libre/2013-09/msg00001.html

<jmd>I want to debug an installed application. But that is not possible, because the binaries are stripped. Is it possible to build without stripping?

<civodul>jmd: see "Installing Debugging Files" in the manual

<civodul>that may answer your question

<civodul>and "Build Systems"

<jmd>ok. Thanks

<jmd>Actually, I don't quite follow it.

<jmd>It says the strip phase copies the file to the debug output WHEN AVAILABLE.

<jmd>So when and under what circumstances is it available?

<civodul>when the package explicitly has (output '("debug" ...))

<civodul>that's the case for glibc and a few others

<civodul>try "guix package -A|grep debug"

<jmd>I find that odd.

<jmd>It would be better to have that implicit.

<civodul>what?

<davexunit>civodul: thanks for the link. reading it.

<jmd>(output '("out" "debug")) should be the default

<davexunit>civodul: I see that jason self said that patching tarballs programatically after download isn't good enough?

<civodul>jmd: you did read the last paragraph of "Installing Debugging Files", right? :-)

<jmd>Yes. I did.

<civodul>ok

<civodul>davexunit: yes, that's what led to the 'patches' and 'snippets' things

<civodul>so that part is solved, AIUI

<davexunit>oh okay.

<civodul>but in hindsight that was really cosmetic

<davexunit>I guess I misinterpreted.

<civodul>Guix does much better than just "provide the exact source"

<davexunit>I thought we'd have to host our own tarballs

<davexunit>of patched source.

<civodul>we provide the exact build scripts, unlike other distros

<civodul>no, i don't think so

<jmd>civodul: I don't expect hydra to host the debug packages, but I'd like to be able to build them myself without having to hack the package files.

<davexunit>civodul: I'm not very familiar with debian packaging, but they don't provide exact build scripts?

<civodul>they do, but the environment isn't under control

<civodul>so sometimes, they find out that although they distribute binaries, these cannot actually be rebuilt from source

<civodul>Lucas Nussbaum did some experiments years ago on a large cluster we have here

<civodul>in France, i mean

<civodul>and yeah, sometimes they'd distribute foo.deb, but foo would actually fail to build from source

<davexunit>oh I see. because there could be needed libs installed on a machine that aren't in the package recipe

<davexunit>so the build is successful, but it shouldn't be

<civodul>exactly

<civodul>or the package maintainer manually tweaked the build

<davexunit>cool. glad I'm aware of those issues now.

<davexunit>I hear people say "debian did it already" about some guix features

<davexunit>now I can resond better.

<civodul>:-)

<civodul>about which features, actually?

<davexunit>package recipes with the exact steps to build a binary from source.

<davexunit>also, I guess there's an experimental peer-to-peer feature for apt

<davexunit>because it got mentioned when I talked about substitutes from other user's machines

<davexunit>oh, speaking of substitutes: is there any reason that hydra.gnu.org isn't authorized in the disk images that guix system produces?

<civodul>substitutes are just pre-built binaries, only fully automated

<civodul>re authorization, it's just that i wasn't sure about the default

<civodul>some people dislike the idea of getting binaries from somewhere else

<civodul>at any rate, 'guix-service' has an option to authorize hydra.gnu.org automatically

<civodul>it's used in the installation image

<davexunit>awesome. I figured there was a bit I could flip. :)

<civodul>maybe that should be the default, dunno

<civodul>hehe

<davexunit>I'm interested in trying to use Guix to take on Vagrant in some way.

<davexunit>vagrant is used to quickly create VMs for developing a specific piece of software. maintainers dump a Vagrantfile into their project's source tree and contributors simply run `vagrant up` to get a development environment.

<civodul>ok

<civodul>i think i read about it in the past

<civodul>it probably has a better interface than Guix for that

<davexunit>yeah, it's tailored to that

<civodul>since that's not really Guix's "core business" as they say ;-)

<civodul>ok

<davexunit>but, I looked at some project's Vagrantfiles

<davexunit>and to me they looked like Ruby versions of Guix systems.

<civodul>it's declarative?

<davexunit>yeah

<davexunit>it's not *exactly* like guix, of course, but it had similarities.

<davexunit>with vagrant, you usually start from a base VM image like the latest ubuntu LTS or something, whereas in guix you'd build a whole new system.

<davexunit>a simple Vagrantfile: https://raw.githubusercontent.com/inboxapp/inbox/master/Vagrantfile

<davexunit>don't know one off the top of my head that configures more services

<civodul>that's interesting

<davexunit>it seems to me that all that I would need to do is create a VM that shares the needed source directory with the host machine.

<civodul>there's definitely common ideas between this, Chef, Puppet, etc. and NixOS/NixOps

<civodul>yes

<davexunit>yeah, it's sort of confusing

<civodul>VMs created with 'guix system vm' share their store with the host, over an 9p mount

<civodul>one could add another 9p file system declaration to share something else

<davexunit>yeah, that's what I was thinking.

<davexunit>regarding puppet, it seems to rely on a center "puppet master" server that keeps the other machines in sync. that concept doesn't seem to translate to guix.

<davexunit>s/center/central/

<civodul>ah right

<civodul>but it uses a declarative approach as well, no?

<davexunit>yes

<davexunit>but since you can manage configs easily with guix, I can only imagine there's a way to keep a bunch of guix machines in sync with each other.

<civodul>yes, definitely

<civodul>that's how "NixOps" (the puppet-like thing of NixOS) saw the light, actually

<davexunit>I should take a look at that, then.

<davexunit>we have a pretty broken puppet setup here at the FSF

<civodul>heh

<civodul>so what is it like to be at the FSF? :-)

<davexunit>hectic

<civodul>i can imagine :-)

<civodul>you're working with other web/admin people?

<davexunit>a bunch of technical debt to pay back

<davexunit>yeah

<davexunit>primarily with our senior sysadmin, lisa maginnis