IRC channel logs

<rekado_>When I share a /gnu/store among many different workstations with different CPUs and the store contains a build of ATLAS which tunes itself to the CPU --- will this lead to problems?

<rekado_>I suppose in this case I should be forcing the lowest common denominator during the ATLAS build.

<rekado_>If I manipulated the atlas package, however, I would have to recompile all packages depending on it.

<rekado_>without having thought much about this it might be nice if local building was not forced at all --- if substitutes are used the package could be substituted with a version built for the lowest common denominator CPU.

<Sleep_Walker>I didn't check the CFLAGS or similar, but I assume that this is already fixed as the project aims to reproducibility

<Sleep_Walker>so you'll have some generic build time configuration options

<Sleep_Walker>but you may have runtime checks with different code paths leading to code optimized for CPUs

<Sleep_Walker>(like mplayer can)

<rekado_>atlas has this argument flag: #:substitutable? #f

<rekado_>this means that substitutes are never used and the package is always built locally.

<rekado_>I might be able to cheat the CPU detection mechanism on the build host (e.g. by building in a virtual machine with a virtual CPU lacking features) to generate an ATLAS package that can be used on any machine sharing the store.

<rekado_>I wonder: does the "substitutable?" flag affect all dependencies? Does it force a local build of any dependent package as well?

<Sleep_Walker>I'm fighting with packaging the_silver_searcher - for some reason PKG_CHECK_MODULE in configure.ac is not expanded and gets to configure

<Sleep_Walker>pkg-config is present as native-input

<Sleep_Walker>hm, `autoconf -I /gnu/store/…-pkg-config-0.28/share/aclocal' works as workaround

<Sleep_Walker>but it is first time I need to do such thing

*davexunit really wants 'guix environment' to be able to spawn VMs

<davexunit>it would make reproducing this SDL OpenGL context issue easier

<Sleep_Walker>oh

<Sleep_Walker>for some reason I miss ACLOCAL_PATH

<civodul>davexunit: in the meantime, to reproduce the issue, maybe you can use 'guix system vm' and then 'guix environment' in there?

<davexunit>civodul: that's what I plan to do

<civodul>not very convenient, i admit, but a good first step

<davexunit>I just haven't had time

<civodul>sure

<davexunit>had to leave the house this morning before the vm built

<civodul>ah :-)

<davexunit>in the meantime, I've been pondering how to make a pleasant interface for system creation in 'guix environment'

<davexunit>haven't come up with anything good thus far.

<civodul>"system creation", as in full VM/container?

<davexunit>yeah

<davexunit>"create an environment in this VM"

<davexunit>and hopefully in the future "create an environment in this container"

<davexunit>my use case is for developing applications that require particular system services to be running like a web server and database.

<davexunit>where simply having all of the dependencies needed to build isn't enough to get the software to run.

<davexunit>that's the dream, anyway. 'guix environment' could then be used as a vagrant replacement, more or less.

<civodul>i wonder how vagrant files specify the requirements in terms of system services etc.

<civodul>would need to look into it

<davexunit>yeah

<davexunit>civodul: it seems that it's left up to the developer to do via a script

<davexunit> http://docs.vagrantup.com/v2/getting-started/provisioning.html

<civodul>oh, not so nice

<davexunit>yeah, we'd have the advantage of using system configuration to specify which services to run and their config files

<davexunit>the basic workflow for vagrant is writing a Vagrantfile, running 'vagrant up' to start the VM, and 'vagrant ssh' to connect to it.

<civodul>ok

<davexunit>maybe this would be a totally separate guix tool, I dunno.

<civodul>yeah, maybe

<davexunit>but to me it feels like a natural extension of 'guix environment'. just build the environment on some other machine instead of the local one.

<civodul>a simple thing we could do in this area is to improve our generated 'run-vm' script

<civodul>yes

<davexunit>civodul: what improvements do you have in mine?

<davexunit>s/mine/mind/

<civodul>davexunit: networking setup for instance

<civodul>i don't know if we can ssh into the VM currently

<civodul>that's a simple thing to do

<civodul>QEMU provides a DHCP server so the VM gets networking if it uses dhcp-client-service

<civodul>but i don't know if there's a route in the host->guest direction

<davexunit>ah okay

*davexunit adds to TODO list

<civodul>the problem with to-do lists is that they often grow too fast :-)

<davexunit>yes they do

<davexunit>who wants to fund me? ;)

<civodul>i have that problem too :-)

<_`_>civodul: did you mean user nat?

<davexunit>civodul: thanks to you adding support for sharing arbitrary directories on a VM, I can write the the guix equivalent of this vagrant feature http://docs.vagrantup.com/v2/getting-started/synced_folders.html

<civodul>we should create a co-op or something

<civodul>davexunit: it's even better than "synced folders": it's "shared directories"!

<davexunit>hahaha

<davexunit>thanks for using appropriate terminology

<davexunit>a co-op sounds interesting. I've been thinking of what a sales pitch for guix would look like, that could convince a business to fund development.

<davexunit>if I could work part-time on guix somehow, that would be really great.

<Sleep_Walker>yeah, one could sleep more during nights :b

<civodul>yeah i've been wondering too

<civodul>but obviously "sales pitch" is not what i'm best at

<davexunit>same

<davexunit>I'm just unenthused about working with any other "dev ops" (for lack of a better term) style tools now that I know guix.

<davexunit>you've spoiled me, civodul.

<civodul>haha :-)

<davexunit>a lot of web dev places use puppet/chef and vagrant and docker and so on

<davexunit>and I just want *someone* to see the potential for guix to unify all of these tasks

<civodul>yeah it could surely be interesting in that area

<davexunit>where "someone" is "someone with capital" :P

<civodul>we should talk to Gilmore ;-)

<Sleep_Walker>you should value the indepence of the project ;)

<davexunit>well, having someone pay you to work on a project doesn't mean that they direct the project.

<civodul>right

<civodul>although they could pay you to work on specific aspects

<civodul>which could be at the expense of others

<davexunit>sure

<civodul>anyways

<davexunit>heh, back to reality

*davexunit goes back to the PHP salt mines

<civodul>uh

<Sleep_Walker>right, back to bugs

<Sleep_Walker>damn

<Sleep_Walker>I have installed procps, but I want to inspect sources, what should I do?

<Sleep_Walker>It doesn't fail so `-K' won't help

<Sleep_Walker>and `guix build procps' just returns the store already built

<Sleep_Walker>missing `--force-rebuild' ?

<paron_remote>o/

<paron_remote>hello, *

<bavier>Sleep_Walker: use `guix build -S procps`?

<paron_remote>Tsyesika is trying to install guix but I think is hitting an error in guix's autoconf files

<paron_remote>but I'll let her post the error :)

<Sleep_Walker>bavier: it just returns:

<Sleep_Walker>/gnu/store/59c63413dpxkssw15rqa1xl4ci6xbz2h-procps-3.2.8.tar.xz

<Tsyesika>./configure: line 7188: syntax error near unexpected token `have_guile_json,'

<Tsyesika>./configure: line 7188: `GUILE_MODULE_AVAILABLE(have_guile_json, (json))'

<bavier>Tsyesika: Are you bootstrapping from git?

<Tsyesika>yep

<bavier>Sleep_Walker: is that not the source you were looking for?

<Sleep_Walker>bavier: no, not really, I'm looking unpacked sources with applied sources

<Sleep_Walker>I can do it by myself, I know

<bavier>Sleep_Walker: the tarball that `guix build -S` returns has any patches or snippets applied. You'll need to unpack it yourself of course.

<Sleep_Walker>so the tarball is recreated?

<bavier>fetch, patch, repack

<bavier>yes

<Sleep_Walker>and it uses the same compression as original file?

<davexunit>Tsyesika: have you installed the guile-2.0-dev package?

<bavier>no, I believe we always repack to xz

<davexunit>assuming debian

<davexunit>Tsyesika: it sounds like you're missing guile's autoconf macros

<Tsyesika>fedora but yeah i've installed guile-devel

<davexunit>hmm

<davexunit>which version of guile?

<Tsyesika>2.0.11

<bavier>Tsyesika: check that you've appropriately set and exported ACLOCAL_PATH

<davexunit>okay, that's great, at least.

<davexunit>I haven't used guix on fedora, so I don't know what could be going wrong with these load paths

<rekado_>I'm using guix on Fedora and CentOS7. I didn't have to set ACLOCAL_PATH

<Tsyesika>i've installed everything with yum so i don't know why there would be path issues

<davexunit>me either

<davexunit>but the problem seems to be 100% that the guile autoconf macros aren't found.

*Sleep_Walker had ACLOCAL_PATH not exported as well today

<rekado_>I needed to install autoconf, automake, git, gettext-devel, guile, guile-devel, libgcrypt-devel, graphviz and a couple more (according to my puppet manifest for the CentOS machine)

<Tsyesika>hm

*civodul adds an m4_pattern_forbid for guile.m4

<civodul>Tsyesika: as davexunit writes, you need to install guile-devel or whatever package provides guile.m4

<davexunit>guile-devel is installed, apparently, which leaves me with no additional recommendations

<Tsyesika>davexunit: i can confirm /usr/share/aclocal/guile.m4 exists and is brought in by guile-devel

<civodul>Tsyesika: could you try "autoreconf -fi && grep GUILE_MODULE_AVAILABLE configure"?

<civodul>so i guess we have to update OpenSSL again

<civodul>mark_weaver: are you looking at it?

<mark_weaver>civodul: I'm on it.

<mark_weaver>civodul: apply to master directly, or have hydra build it on another branch first, wdyt?

<civodul>mark_weaver: i have a slight preference for separate branch

<civodul>+a

<mark_weaver>okay

<mark_weaver>sounds good

<{0}grant>I'm trying to build Guix on Fedora Rawhide at it's spewing a "syntax error near unexpected token `have_guile_json,'. Then `Guile_MODULE_AVAILABLE(have_guile_json, (json))'. Any ideas?

<{0}grant>Am I just missing a depend, that has this unexpected effect?

<taylanub>{0}grant: wild guess: you don't have pkg-config

<taylanub>{0}grant: where is it spewing that though? during ./configure?

<{0}grant>Yeah, and just checked. I have pkgconfig.

<taylanub>using a release or checkout? (did you run autogen/autoreconf yourself, or was the ./configure there already?)

<{0}grant>The latter.

<mark_weaver>{0}grant: you need guile.m4 installed at the time that you run autogen

<mark_weaver>guile.m4 is where GUILE_MODULE_AVAILABLE is defined.

<{0}grant>Wait, so does that ship with Guile or M4 via autotools?

<mark_weaver>guile.m4 would typically be in the development package for guile. on debian it would be guile-2.0-dev. not sure on fedora

<{0}grant>I have 'guile-devel' installed, though yeah, not sure of the specifics.

<taylanub>it seems we have samba 3.6. given 4.0 is from 2012 December, I'm guessing this was a conscious decision. if I package samba 4, should I name the variable samba-4 and inherit from samba, or the other way around?

<mark_weaver>guile.m4 should be in PREFIX/share/aclocal/guile.m4

<mark_weaver>where PREFIX is probably /usr or maybe /

<{0}grant>Yup, it is.

<mark_weaver>was it there when you ran autogen?

<{0}grant>Uh, I believe so. I can try again, sec.

<mark_weaver>you might need to set ACLOCAL_PATH to include PREFIX/share/aclocal

<mark_weaver>that would be interesting of the default ACLOCAL_PATH on Fedora is unable to find the guile.m4 installed by Fedora

<mark_weaver>s/of/if/

<mark_weaver>{0}grant: where exactly is the guile.m4 file?

<{0}grant>mark_weaver: /usr/share/aclocal/guile.m4

<mark_weaver>does /share/aclocal also exist? are there many files there?

<{0}grant>mark_weaver: Set the path, and it now works; Weird. I suspect it must have something to do with the way I upgraded Fedora mabye, to Rawhide. Stable worked just fine.

<{0}grant>mark_weaver: Yeah, there's a dozen or so.

<mark_weaver>It might be that Fedora autoconf now only looks in /share/aclocal by default, and that the Fedora Guile package should be changed to install guile.m4 there.

<mark_weaver>just a guess...

<{0}grant>I'll look into it a bit more over the weekend likely, but yeah, mark_weaver thanks for the help. Going to leave it run via make while I go afk, and head to class. o/

<rekado_>I basically have a functional package for Julia, but it annoys me that there are two bundled libraries that I haven't been able to replace with system packages.

<rekado_>one of them is suitesparse for which I already submitted a patch.

<rekado_>the other is dsfmt.

<rekado_>the build system for suitesparse only builds static libraries, but Julia wants shared libs.

<rekado_>dsfmt has no build system at all. It's just a C file and a header file.

<rekado_>I don't know how to proceed.

<rekado_>change suitesparse's Makefile to also build shared libs?

<rekado_>write a Makefile for dsfmt?

<mark_weaver>I think it would be fine to use those two bundled libraries for now.

<rekado_>okay.

<mark_weaver>maybe with a TODO comment

<rekado_>yes, I've added a comment.

<rekado_>Julia itself is released under expat license, but it links to GPL code. Is the package license expat, then, or GPL?

<mark_weaver>expat

<rekado_>okay

<rekado_>thanks.

<mark_weaver>thanks for working on it!

<taylanub>does anyone know waf's analogue of passing foo_CFLAGS/foo_LIBS to ./configure to bypass pkg-config detection of foo?

<taylanub>#waf told me there isn't; I'll probably be patching the wscript file.

<taylanub>so Requires.private packages in .pc files should be propagated inputs. does the same go for the Requires field of the .pc file?

<taylanub>hm, not from what I can tell from pkg-config documentation. I guess libxrandr propagates randrproto for some other reason then (it being in the Requires field but not Requires.private)

<taylanub>and maybe I should write a script that runs through .pc files in a package and checks if Requires.private libraries are all propagated

<taylanub>no wait, if private requires need to be propagated, then non-private ones should definitely be propagated too. in fact I would have thought that private ones needn't be propagated, if I'm reading pkg-config documentation right. well that's confusing.

<Sleep_Walker>it seems that IceCat doesn't support H.264 - is that intentional?

<davexunit>could be, but not sure.

<civodul>taylanub: isn't Require.private for static links?

<civodul>well Libs.private is for static linking

<taylanub>civodul: apparently, if libbar is under Requires of libfoo, 'pkg-config --libs foo' will emit -lfoo -lbar, if .private it will only emit -lfoo. I posted on the ML about this by the way.

<civodul>taylanub: but --libs --static will also emit -lbar, i suppose

<civodul>i'll check the ml

<taylanub>indeed. (actually not sure about '-lfoo -lbar' for the Requires, trying to figure out)

<taylanub>(well yeah, can't find an explicit example but everything I'm reading seems to imply it)

<Sleep_Walker>civodul: my estimation is that I should backport ~20 patches to make gnash release working with gstreamer-0.10

<Sleep_Walker>and ~30 patches to make it working with ffmpeg

<Sleep_Walker>yes, it is still fraction of all ~760 patches between 0.8.10 and HEAD

<civodul>Sleep_Walker: ouch, then that's a good reason to stick with the git thing

<civodul>well sure, but that's still a lot

<Sleep_Walker>yeah, that was the reason I went the git snapshot way

<Sleep_Walker>this way it works and all the required fixes for guix are already pushed :b

<afleck>I'm getting the following error with guix package -i:

<afleck>substitute-binary: guix/scripts/substitute-binary.scm:634:2: Throw to key `match-error' with args `("match" "no matching pattern" ())'.

<afleck>guix package: error: build failed: substituter `substitute-binary' died unexpectedly

<afleck>any tips?

<afleck>guix version 0.8.1

<afleck>I can't update it to .9 with guix package -i guix

<afleck>due to that error

<afleck>oh, and this only happens on root account

<afleck>works fine as user, using same guix (/run/current-system/profile/bin/guix)

IRC channel logs

2015-03-19.log