IRC channel logs


back to list of logs

<afleck>the manual told me to come here and share my success :)
<afleck>I got GSD up and running
<davexunit>afleck: awesome!
<davexunit>great to hear.
<afleck>davexunit: thanks. should I install all packages as non-root?
<davexunit>yes, in most cases.
<davexunit>only install things as root that you want in root's package profile.
<davexunit>i.e. things that are useful to you when running as root.
<afleck>i see that xfce4 is a package module in guix
<afleck>how do i install all the packages defined in a module?
<afleck>or do i have to do e.g. thunar, xfce-terminal one by one
<davexunit>well, we have an 'xfce4' package that includes everything.
<davexunit>for convenience.
<davexunit>but just so you know, it would be possible to install every package in a guile module with a little of scheme code.
<afleck>guix package -i xfce4 says xfce4 isn't found
<davexunit>guix package -i xfce
<davexunit>to search for everything matching 'xfce', do 'guix package -A xfce'
<afleck>okay. guix pacakge -i xfce is also a not found
<afleck>but i can see all the packages listed
<afleck>with the guix package -A xfce
<davexunit>you should update guix, then.
<davexunit>with 'guix pull'
<afleck>ah, okay.
<afleck>this is so weird
<afleck>there was no /usr directory
<afleck>and i tripped over that
<davexunit>yes, no /usr
<davexunit>that's normal
<afleck>haha i figured. Is there a dmd/deco command to list all available services?
<davexunit>hmmm I can never remember this one
<davexunit>'deco status dmd' maybe?
<davexunit>I'm not on a guixsd system atm
<afleck>can i run dmd as a user? I'm having issues
<afleck>no such file or directory $HOME/.dmd.d/run
<afleck>when i type "dmd"
<davexunit>because dmd is not on your path
<davexunit>you wouldn't typically run dmd, it's already running as PID 1
<davexunit>you use the deco client
<davexunit>note that deco is an admin tool, so you must be root.
<afleck>ah, that explains it
<davexunit>at least for the PID 1 dmd.
<davexunit>I've heard about some people using another dmd process for managing user services.
<davexunit>which sounds cool, but I haven't tried it.
<afleck>hopefully i'll get to that level eventually :-P
<davexunit>I haven't hacked on dmd at all yet.
<davexunit>some day.
<afleck>so is there anything special i have to do to get slim to see xfce4?
<afleck>or should i not bother with slim and just use xinit
<davexunit>oh, I should've mentioned: add xfce as a system package, not a package in your profile.
<davexunit>I think slim will "just work" that way.
<afleck>and system package = installing as root?
<davexunit>add it to your OS config file
<afleck>do i then do guix reconfigure as root or user?
<davexunit>and run 'guix system reconfigure your-os.scm' as root
<davexunit>it alters the root file system, so it's a task for the root user.
<afleck>is the correct place to add xfce in the (use-package-modules ...) line?
<davexunit>that will include the guile module that contains the xfce package recipes
<davexunit>but you also need to add the 'xfce' object to 'packages' in the 'operating-system' declaration
<afleck>i'm getting strange errors
<afleck>(unbound variable #f "Unbound variable: ~S" (use-service-modules) #f)
<davexunit>ah, run 'guix pull' as root ;)
<davexunit>the 'guix pull' you did as your unprivileged user updated guix for yourself only.
<davexunit>each user has the freedom to use their own guix build.
<afleck>it says guix is up to date
<davexunit>'sudo guix --version' ?
<davexunit>and also 'which guix'?
<davexunit>(as root)
<davexunit>an old guix is being used, for sure.
<afleck>guix --version is 0.9
<afleck>which guix is /run/current-system/profile/bin/guix
<davexunit>that's the issue
<davexunit>that's the old guix
<davexunit>which doesn't have the 'use-service-modules' macro
<davexunit>are you using sudo? something isn't right with your $PATH
<afleck>i did su - from a user shell
<davexunit>what is $PATH ?
<davexunit>I haven't used GuixSD long enough to know exactly why this is wrong
<davexunit>try 'guix package -i guix'
<davexunit>and then run the reconfigure again
<afleck>didn't work. my date is wrong, could that be it?
<afleck>ok, guix pull complains about timestamps being in the future
<davexunit>hmmm, I dunno then.
<davexunit>anyway, could you add '(use-modules (gnu))' to the top of your OS config file and try again
<afleck>it's already there
<afleck>this was working a bit ago
<afleck>which was weird
<afleck>i reconfigured a couple times
<afleck>but now it doesn't work
<afleck>well, it's late
<afleck>i'm just going to try to fix it tomorrow
<afleck>thanks for all the help
<davexunit>sorry we couldn't get it working.
<davexunit>it's probably something silly, but I just can't think of it right now.
<rekado>when I want to build, say, lilypond guix freezes after outputing this message: "waiting for locks or build slots..."
<rekado>I get this same message when I do ./pre-inst-env guix build gtkmm-2.24.2
<rekado>never mind. Must have been a stuck CPU. Rebooted. Now it's fine.
<rekado>building solfege (again) I get an encoding error in phase "patch-python-shebangs".
<rekado>the file it complains about is "solfege-3.22.2/solfege/ Python script, ISO-8859 text executable"
<Sleep_Walker>stuck CPU sounds nice :)
<civodul>Hello Guix!
<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 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>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
<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>"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>civodul: it seems that it's left up to the developer to do via a script
<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.
<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
<davexunit>civodul: what improvements do you have in mine?
<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
<civodul>we should create a co-op or something
<civodul>davexunit: it's even better than "synced folders": it's "shared directories"!
<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>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>although they could pay you to work on specific aspects
<civodul>which could be at the expense of others
<davexunit>heh, back to reality
*davexunit goes back to the PHP salt mines
<Sleep_Walker>right, back to bugs
<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>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:
<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?
<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
<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>which version of guile?
<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)
*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
<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>{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.
<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>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)