IRC channel logs

2017-06-29.log

back to list of logs

<rekado>I really wanted to get more server stuff done. Now I need to rush this to be able to finish this week.
<civodul>heh well, we'll understand if you don't get it done by then
<civodul>no worries
<civodul>you also have to prepare your luggage and all that ;-)
<rekado>vacation is good, but this time it feels like having a chance to eat an exquisite cake when you just stuffed yourself with greasy pizza
<rekado>I’m just not ready yet :)
<civodul>greasy pizza :-)
<catonano>rekado: happy vacation !
<rekado>catonano: thanks!
<rekado>I’m trying to make emacs-ess use a texlive-union, but I always get “texi2dvi: TeX neither supports -recorder nor outputs \\openout lines in its log file”. Annoying.
<lfam>The speed of `guix gc` is at least one of magnitude faster on an SSD. Wow
<lfam>One order of magnitude, that is
<civodul>yeah
<cehteh>mhm the xpra package should really be split into client and server, because it lacks a lot dependencies for the server part
<rekado>ESS now uses texlive-union
<janneke>Morning Guix!
<lfam>Good evening janneke :)
<janneke>:)
<nee``````>I've been working on a game in guile for a gamejam and made a very hasty 0.0.0 release through a guix package for the end of the jam. Anyone wanna test if it works on other computers? https://hidamari.blue/yn/
<rekado_>Hi Guix!
<reepca>o/
<janneke>Hi rekado_
<reepca>any idea why nix/libstore/build.cc does a pivot_root before chroot()?
<civodul>Hello Guix!
<efraim1>finally installed weechat on my firefly, I'll have to see if I can get used to this
<civodul>oops the lapack upgrade i made broke numpy
<rekado>R’s “system()” does not like our shell wrappers.
<rekado>running rseqc’s “tin.py” wrapper on the shell is fine
<rekado>but when doing Rscript -e 'system("tin.py")' it fails
<rekado>it execve’s the wrapped Python script, loads the wrong Python and of course does not use the correct PYTHONPATH.
<efraim1>optipng fails on aarch64 like on armhf
<roelj>How should I call the procedure returned by 'profile-derivation'? It expects one parameter, but I don't know what that should be.. the store connection?
<efraim1>same with openh264
<rekado>roelj: have you tried (with-store store the-monadic-procedure)?
<efraim1>orfm on armhf looks like it keeps on timing out during building
<roelj>rekado: Ah, run-with-store seems to work for me.
<efraim> https://hydra.gnu.org/build/2127422/log/raw ovmf on i686 starts by building as i686/IA32 and then it reruns the architecture check and continues building as X64
<efraim>i take it back, I looked at the package definition, its supposed to do that
<efraim>ok, so I'm liking an option to only build the 32 bit firmware on i686 and to build both on x86_64
<catonano_on_mobi> /J guile
<catonano_on_mobi>Oops
<roelj>How would I use run-with-store in a (mlet %store monad ...) expression?
<rekado>roelj: you would not
<rekado>mlet gives you a monadic value
<rekado>but you can join monadic expressions with mbegin
<roelj>Ooh.. I always get confused with monads
<roelj>I've been going about this the wrong way.. Thanks for making me understand. :)
<efraim1>perceptualdiff also fails on aarch64 with some neon error, we have a couple of those
<efraim1>hash mismatch again from libpng-1.6.28-apng.patch.gz
<jsierles2>hey
<rekado>this is so weird and my strace foo is failing me.
<rekado>what does R do with “system”?
<roelj>rekado: Well, I think R relies on "grep" and some stuff from coreutils to be available.
<rekado>that’s fine
<rekado>but it messes with the environment in which processes run
<roelj>How? I never noticed this.
<rekado>I’m currently trying to get a small reproducer for this problem.
<rekado>the gist is: rseqc’s “tin.py” works fine when run on the shell; doing Rscript -e 'system("tin.py")' fails.
<roelj>Ooh
<rekado>and the error is not consistent across different environments
<rekado>in my environment it loads the system python libs
<rekado>in another user’s environment it seems not to do that, but then fails to import numpy
<roelj>I've seen that one when people mixed Guix's R with one installed using the "module system".
<rekado>it’s like it ignores the shell wrapper script that sets PYTHONPATH
<rekado>it does work on GuixSD
<rekado>that’s a relief
<rekado>but the users are on a foreign distro
<roelj>What about setting the "guix package --search-paths" before running Rscript?
<roelj>Does the problem occur then?
<rekado>it also happens in “guix environment”
<roelj>In a --pure environment?
<rekado>trying that now
<rekado>BTW: I’m getting double output on substitutes. One line prefixed with “substitute:”, the other without.
<rekado>I get the same error in a pure environment
<roelj>Completely different topic: It seems that I can get a derivation output path that hasn't been built.. How can I ensure that it gets build before it provides the output path?
<rekado>R is up to no good
<roelj>Can you check the environment with "env"?
<roelj>And then the same thing within R with Sys.getenv?
<rekado>env and getenv seem to return the same things
<rekado>no, wait
<rekado>where does this LD_LIBRARY_PATH thing come from!?
<rekado>wow
<rekado>Rscript -e 'Sys.unsetenv("LD_LIBRARY_PATH"); system("tin.py")'
<rekado>fixed
<rekado>why does Rscript do this?
<rekado>I certainly didn’t set LD_LIBRARY_PATH!
<thomasd>Hi #guix
<civodul>roelj: “you exit a monad like you exit a building on fire: by running” :-)
<civodul> https://www.gnu.org/software/guix/manual/html_node/The-Store-Monad.html
<civodul>heya thomasd
<rekado>so R sets a *default* LD_LIBRARY_PATH that includes /usr/local/lib!
<rekado>what were they thinking?! This is absolutely terrible.
<rekado>seems to be set in config.site: “'-L' options set here will be prepended to LD_LIBRARY_PATH […] at run time. If unset defaults to '-L/usr/local/lib' […]”
<rekado>will prepare a patch today
<thomasd>Something I was wondering about: is there a portable (across GuixSD and non-GuixSD :-) ) way to set a shell script shebang?
<rekado>thomasd: there is not, but GuixSD users can create /bin/sh in their system configuration; it’s just not enabled by default.
<efraim1>I remember when I used to try to get our failed build ratio down to 5%, we're at about 6.4% now
<thomasd>rekado: thanks! I guess will do that
<efraim>you can create a service to have /bin/sh a symlink to /run/...<something>.../sh
<rekado>special-files-service-type
<rekado>its default value is `(("/bin/sh" ,(file-append BASH "/bin/sh")))
<roelj>rekado: Wow.. That is strange..
<roelj>So, how do I ensure that this: http://paste.lisp.org/+7HTJ Would point to a built profile?
<civodul>roelj: what do you want to do with this profile exactly?
<civodul>the idea is that the top-most part of your program calls 'build-derivations' to ensure that things are built
<civodul>but that's the only place where this should be done
<civodul>for for instance (guix scripts package) has one 'build-derivations' call and that's it
<civodul>the rest of the code simply assembles derivations
<jsierles>rekado: do you have any more details on the NFS configuration in your cluster?
<jsierles>trying to figure out the least painful, but practical setup for a global store.
<jsierles>civodul: I looked into CernFS. looks like it would work nicely with guix, except it's transactional, so you have to unlock and lock the filesystem to perform writes. That doesn't sound like it would work well with the daemon which could be writing to the store in parallel from different builds, right?
<civodul>jsierles: does it have a POSIX interface?
<jsierles>civodul: yes, the fs is built upon fuse
<civodul>i guess that would handle locking and all transparently, at the expense of hiding the nice features of CernFS
<civodul>ok
<civodul>jsierles: rekado wrote about their NFS setup at https://elephly.net/posts/2015-04-17-gnu-guix.html
<jsierles>the problem is not knowing when to open and close a transaction, since a built request could come in anytime
<civodul>i think it's still mostly up-to-date
<civodul>yeah, dunno
<jsierles>civodul: yeah i read that. he mentioned that recently, performance was upgraded with some tuning
<civodul>ah right
<jsierles>civodul: let me ask then, are there any hooks for knowing when a build has started or ended?
<jsierles>in the daemon currently
<civodul>jsierles: not really
<jsierles>right now my plan is just to keep a separate store on another disk, and occasionally perform an upgrade of the global store. that means clients won't get immediate access to builds, but that's OK for our setup for now.
<roelj>civodul: Well, I'm trying to build a profile from a list of packages, and then run a G-Expression in the environment of that profile
<civodul>roelj: then you can do something like: (mlet %store-monad ((p (profile-derivation m))) #~(begin (setenv PATH #$(file-append p "/bin")) ...))
<civodul>we could even add a "gexp compiler" for <manifest>, which would hide the profile-derivation call
<roelj>civodul: Yes, that's exactly what I'm doing, but it seems that the profile directory does not exist..!
<roelj>civodul: Oh wait.. I'm not doing #$(file-append profile "/bin")..
<roelj>civodul: But I am doing (derivation-output-path (assoc-ref (derivation-outputs profile) "out")).
<civodul>roelj: right, never ever do that :-)
<civodul>when you do that, what you get is just a string
<roelj>civodul: :) I had noticed..
<civodul>which means that the gexp doesn't know that it actually depends on the derivation that builds the profile
<roelj>Right
<civodul>whereas when you do #$foo, then the gexp "knows" that it depends on "foo"
<roelj>civodul: Can I get a list of dependent packages froma G-Expression?
<roelj>civodul: Woah, it seems to work..
***fps_ is now known as fps
<civodul>roelj: a list of packages the gexp depends on?
<civodul>there's no public API for that, but hopefully you don't really need it ;-)
<roelj>civodul: Yes, so if you do #~(... (string-append #$guile "/bin/guile" ...)), I would like to do (packages-in-gexp ...) => guile.
<roelj>Fortunately, I don't really need it.
<roelj>Now that the profile thingy works
<civodul>good
<civodul>oriansj, janneke: mescc-tools is x86_64 only, right?
<civodul>or i386?
<civodul>i386 it seems
<civodul>README.md is terse :-)
<rekado>massive difference between “guix system disk-image” with redirecting output to a file and with printing to the console.
<jsierles>how does guix know to use the latest guix pulled with `guix pull`?
<rekado>jsierles: it looks for ~/.config/guix/latest
<civodul>rekado: in M-x shell, right?
<rekado>jsierles: see the “guix” script
<rekado>civodul: no, a VT on the server
<jsierles>ok, looks simple
<civodul>rekado: framebuffer maybe?
<civodul>it's slow
<janneke>civodul: it's only been tested on x86_64 afaik (oriansj?) but it could work anywhere, i think
<civodul>anywhere as long as it's x86, right? :-)
<janneke>ACTION is still getting into mescc-tools, which is orianj's work
<janneke>civodul: i don't know; why do you think that?
<civodul>it contains an assembler IIUC, no?
<civodul>also there's this 'x86_defs' file
<janneke>yes, it's complicated -- i now remember that the tests will only run on x86
<civodul>ok
<janneke>and probably only tested on x86_64 -- but i think oriansj will want to support more architectures later
<janneke>currently the tools are written in C, and the tests are tailored to i386
<rekado>hmm, “guix system disk-image’ appears to be stuck after installing the system into a vm(?)
<janneke>and oriansj has hand-coded versions of previous simpler versions of the tools, which are x86 only -- so that will need work
<civodul>rekado: could it be ENOSPC?
<civodul>ENOSPC in the VM i mean
<rekado>I added --image-size=64G
<jsierles>just got a 504 Gateway Timeout from hydra
<jsierles>trying to download: https://mirror.hydra.gnu.org/guix/nar/gzip/r2kjj9xlil1xav4k4psnlabqw1gz64bd-r-curl-2.5
<rekado>ACTION still works on xfce
<civodul>jsierles: it's a sign that our build farm frontend is overloaded again :-/
<jsierles>civodul: ok, looks like using --fallback will build locally in that case
<jsierles>just trying to download/build the whole repo now, so I can publish my own sub server
<boskovits>hello
<boskovits>I am currently packaging thrift.
<boskovits>I have a problem:
<civodul>jsierles: yes, --fallback is the workaround
<boskovits>I need to set environment variable PY_PREFIX to the value of prefix
<boskovits>How can I get what the value of prefix is?
<civodul>boskovits: i would just add a phase (with 'modify-phases') that calls 'setenv'
<civodul>the phase has an 'outputs' keyword argument and it can get the prefix from there
<boskovits>Fine, thanks.
<civodul>so: (lambda* (#:key outputs #:allow-other-keys) (setenv "PY_PREFIX" (assoc-ref outputs "out")) #t)
<boskovits>Ok, thank you
<jsierles>rekado: i've noticed that a lot of CRAN mirrors seem to remove older packages. for example, 'backports@1.0.5' needed to go through 6 servers to find a copy. have you seen a case where one is completely gone?
<rekado>jsierles: not for CRAN, no
<rekado>‘guix system disk-image’ finished.
<rekado>I restarted it with 16G. 64G takes a very long time.
<jsierles>rekado: were you able to successfully build julia 0.6.0?
<rekado>jsierles: yes, of course
<jsierles>hmm. after 'guix pull' i tried installing it but got: https://gist.github.com/jsierles/378ad55f38eacaba2b621e2c8705f10f
<civodul>jsierles: i broke lapack with an upgrade on Tuesday and just fixed it
<jsierles>civodul: ah. just like in the last couple hours?
<jsierles>i see.
<boskovits>civodul: thanks! That worked fine.
<boskovits>Now it builds and installs. It is even reproducible. I still have some problem with the tests.
<civodul>these are the worst ;-)
<civodul>jsierles: yeah: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3ab869b63fc43c8d13864d711c2dc55fb3691456
<boskovits>Also, I would like to know, if it is better to have a minimal package, and have packages like thrift-java, and so on with language support, or just build one with all languages supported?
<davexunit>boskovits: generally we make full-featured packages
<davexunit>and make minimal variants when necessary
<boskovits>davexunit: thanks, I will go that way then.
<jsierles>civodul: thanks. is there a programmatic way now to tell if an upstream build has broken?
<civodul>jsierles: not yet, but it would be nice to have
<civodul>well, actually via Hydra's HTTP API it's more or less possible but tedious
<civodul>what you can do, though, is "guix build foo --log-file --no-grafts"
<civodul>it a built was attempted, you'll get the build log
<jsierles>interesting
<jsierles>what happens now if two people try to build the same package? will the daemon be smart about it?
<jsierles>just tried it and see it's locked
<civodul>yeah it's smart :-)
<rekado>I want to avoid downloading / building the same packages over and over when installing a couple of servers one by one.
<rekado>so I built a disk image after I installed the first server.
<rekado>booting from that image, however, I again have to download a lot of packages.
<rekado>can I easily include the current store in a disk image?
<rekado>or am I doing this wrong and I should be setting up a local mirror?
<efraim>Mirror might be easier
<bavier`>what to do about free software nodejs-based web apps? it'd be nice to be able to install them locally, especially games.
<quiliro>hello again guixsters!
<quiliro>i have finished the emacs manual and i now want to learn to use emacs capabilities for guix
<efraim>i might tag aarch64 as supported by julia even though it doesn't build locally
<quiliro>is there any documentation regarding this?
<bavier`>quiliro: the guix manual has details
<ng0>rain1: after PR #17 for s is merged, should I update the guix package?
<quiliro>found emacs-guix manual
<ng0>efraim: have you figured out what's wrong with Enlightenment locking you out when you lock the screen? That's the current behavior. I have another screenlocker in the works which has similar behavior..
<rekado>civodul: turns out that the USB problems were caused by a defective USB stick. Haven’t had a problem with a different USB disk. Looks like the servers are fine after all.
<jsierles>hmm. julia build failed again after a guix pull
<rekado>jsierles: different error?
<jsierles>looks like because julia's tests crashed
<rekado>:(
<jsierles> https://gist.github.com/jsierles/18e27195ec1aec974be05eb7ea9f0035
<jsierles>also saw: Worker 3 terminated.
<jsierles>ERROR (unhandled task failure): EOFError: read end of file
<rekado>jsierles: you cut the interesting part
<ng0>rekado: thanks for merging the xfce patches.. I think I will get my update patches for xfce a rebased try and see if the gtk issue goes away
<jsierles>updated with the whole thing
<rekado>I built it before I pushed. I don’t know if something else was push afterwards that would break it.
<jsierles>civodul mentioned what broke it, but his fix remove the regression. this looks maybe like the test run just bombed
<jsierles>let me try it again and see.
<rekado>hmm
<rekado>the tests are annoying
<rekado>very slow
<ng0>hrrrmm does someone know where openadventure is released? there is a make dist, but there is no url in the gitlab repo
<jsierles>indeed. not possible to skip tests?
<rekado>and I had to disable some because I couldn’t figure out why they would fail
<rekado>jsierles: you can skip them by doing #:tests? #f in the arguments
<jsierles>rekado: arguments to `guix build`?
<rekado>but then we wouldn’t know if something broke for real
<rekado>no
<rekado>that would have to be a change to the package
<jsierles>lets see if it fails again
<rekado>(or require a variant)
<ng0>found it
<efraim>ng0: I'm not actually running a guixsd machine so I'm not running enlightenment atm
<ng0>ok :)
<ng0>I don#t see a tarball here, even after the last commit which fixed that make dist: http://www.catb.org/esr/open-adventure/
<ng0>We'll just continue with git for now.
<rain1>ng0: if you like but think its a while til a proper "release" happens
<ng0>well it's already in guix as a package
<ng0>occasionally updating it can't be wrong
<jsierles>rekado: maybe a memory issue. julia is using all four CPUs on this box, plus 2GB of RAM
<bavier`>last I checked our julia build did not honor --cores (i.e. parallel-job-count)
<rain1>ng0, is it able to be used for anything yet?
<ng0>scripting
<rain1>btw, i am thinking about possibly doing normal shell style > instead | >
<ng0>cool
<jsierles>rekado: yep it's a memory error indeed
<ng0>rain1: have you dropped linenoise? I don't remember how you used to include it
<rain1>ng0: there was complaint that makefile did networking, so i just made it print the github url
<ng0>ah, ok. that's good
<ng0>Ah, I remember
<rain1>you just need to git clone https://github.com/antirez/linenoise.git inside the repo
<rain1>then it should built everything
<ng0>I do something similar in guix
<ng0>see gnu/packages/shells.scm :)
<rain1>that reminds me! I should fix up the zenity bindings & guix package
<rain1>they are potentially very nice for scheme beginners
<ng0>could someone clone https://github.com/antirez/linenoise and tell me what commit c894b9e59f02203dbe4e2be657572cf88c4230c3 returns as guix hash?
<ng0>I asked linenoise for a new release, but it can take a while
<ng0>I get a hash mismatch here..
<ng0>I have: 1z16qwix8z6a40fskdgxsibkqgdrp4q6ncp4n6hnv4r9iihy2d8r and I get 0wasql7ph5g473zxhc2z47z3pjp42q0dsn4gpijwzbxawid71b4w
<ng0>nvm I used the wrong commit
<efraim1>looks like julia fails on aarch64 due to __fp16 not being defined, or some such
<cehteh>ng0: the xpra package is still work in progress? because i cant start up the server part
<efraim1>any ideas what I need for -larmadillo
<ng0>which package?
<ng0>cehteh: I wasn't involved in that
<cehteh>ah i tought you did that, lemme check only stumbled on a ML entry where you posted that you like to package it
<ng0>I worked on it than I stopped doing that
<ng0>the xpra we have is someone else' achievement
<cehteh>nevermind then
<cehteh>root@guixfarm ~# guix blame xpra
<cehteh>guix: blame: command not found
<cehteh>... got a new command suggestion :D
<civodul>rekado: re USB stick, it's good news that the servers are fine
<civodul>cehteh: :-)
<civodul>jsierles: it could be that Julia really needs lapack 3.5.0 and not 3.7.1, though i would find it surprising
<ng0>what about guix commit, guix push, ... ;P
<cehteh>well seriously, could be a nice idea to have history and blame on packages someday
<civodul>janneke actually wrote a "g" command that automatically dispatches to "guix" or "git" or "guile" :-)
<civodul>but yeah, history and blame would be nice
<ng0>that's useful
<ng0>where can I find it?
<cehteh>for once its nice that packages are not 'tied' to maintainers, but figuring some contacts out could be useful, even more when that tracks whoever contributed to it
<civodul>janneke: where's that one-size-fits-all "g" command that you wrote? :-)
<rain1>hah!
<jsierles>civodul: no, i just ran out of memory really. it was just the tests failing
<janneke>civodul: it's been rotting here: https://gitlab.com/janneke/gee-gee
<ng0>ty!
<cehteh>name it gnu :)
<cehteh>gnu dwim
<janneke>at second thought i wasn't sure it was such a good idea... :-)
<cehteh>what can possibly go wrong :FD
<janneke>what about just one command: /bin/doit
<janneke>`d' for short
<civodul>heheh
<jsierles>ok, now building on an 8 core machine with 32 GB of RAM. should be enough :P
<cehteh>years ago i read some blog article about a fictionous software which was only controlled by 2 buttons punish/reward :D
<cehteh>so implement d with some neural network and these 2 buttons
<cehteh>have fun training it
<ng0>cehteh: Rutger Helling
<jsierles>man, julia is using 5GB ram and all 8 cores to run tests.
<jsierles>rekado: just noticed this in the test run too 'sh: /sbin/ldconfig: No such file or directory"
<jsierles>doesn't seem to affect any test though.
<rekado>yeah, that’s harmless.
<jsierles>phase `check' succeeded after 681.8 seconds
<jsierles>yay. only used 10GB of RAM
<rekado>efraim1: you’d need armadillo from (gnu packages maths)
<bavier`>jsierles: crazy
<jsierles>is there an importer for bringing package definitions from nix?
<bavier`>jsierles: 'guix import nix'
<rekado>my workstation has 32G RAM, so I didn’t notice the crazy mem requirements
<jsierles>ah, didnt see it in the docs. thanks
<rekado>jsierles: the nix importer requires a working nix installation
<rekado>jsierles: I’ve never used it.
<jsierles>ok. i want to bring glusterfs in
<bavier`>jsierles: and the results usually need personal attention
<jsierles>yeah. guess it's OK to start over
<jsierles>ugh, doesn't look like fun. will use a docker container instead
<rekado>would that even work?
<rekado>does it not provide kernel modules?
<jsierles>gluster doesn't, afaik
<jsierles>the native client uses fuse
<jsierles>i'm running on CoreOS, so pretty much have to do everything with docker
<jsierles>would be nice to use guixsd someday. but we've got this crazy setup using cloud-config and systemd. would be quite a lot of work to change that
<jsierles>i see there is no docker package
<rekado>I just finished installing GuixSD on two servers :)
<jsierles>anyone know which package has 'cut'?
<jsierles>busybox's cut is weak
<rekado>/gnu/store/1lvqx35rm9yqgcjjpy1nr337y9j5582g-coreutils-8.27/bin/cut
<rekado>according to readlink -f $(which cut)
<jsierles>huh
<jsierles>there we go
<jsierles>guix build: package 'guile2.2-json' has been superseded by 'guile-json'
<jsierles>this is just after a guix pull. does it mean i should run 'guix package -u'?
<jsierles>starting now to run "guix build --quiet --keep-failed --keep-going `guix package -A | cut -f1,2 --output-delimiter=@` --fallback". let's see what happens :)
<rekado>jsierles: do you want to do this regularly?
<rekado>jsierles: it may make sense to set up cuirass instead
<jsierles>rekado: not yet. kind of just want to see how it goes.
<jsierles>civo suggested cuirass is not really good. i think if we did set something up, we'd roll our own
<jsierles>we are essentially a job scheduling system already, and have our own monitoring and resource management setup
<jsierles>so we could track build resource usage and adjust accordingly for the cluster.
<rekado>it would help us all to improve cuirass
<rekado>it does what it should, but it’s incomplete
<jsierles>i'll take a look at it. but it probably won't fit with our setup
<rekado>it’s certainly better than that command above ;)
<jsierles>of course
<rekado>ACTION goes afk for a while
<jsierles>we're using the hashicorp stack for job scheduling
<jsierles>does cuirass have any support for resource management?
<jsierles>doh, got this again: guix build: error: build failed: while setting up the build environment: getting attributes of path `/etc/nsswitch.conf': No such file or director
<jsierles>i
<jsierles>trying to use the pypi importer. it needs nss-certs, which i installed. but guix/build/download.scm is reporting an error still. anyone know the env var i need to set?
<earthfail22>hello guys, I was installing guixsd and when build I got several errors but the one that stoped the process was "error: in procedure scm-error: no code for module (guix build utils)...."
<jsierles>ah, i see my .guix-profile link was wrong.
<efraim1>libgcrypt 1.7.8 released to fix CVE-2017-7526
<ng0>sneek: later tell mekeor: I think the problem with the wifi is more related to networkmanager. but I need to analyze my logs
<sneek>Okay.
<paroneayea>anyone having trouble starting rhythmbox lately?
<paroneayea>(.rhythmbox-real:5214): Rhythmbox-WARNING **: Unable to grab media player keys: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SettingsDaemon was not provided by any .service files
<paroneayea>searches on the intarwebs suggest I need to run gnome-settings-daemon but that doesn't seem to exist on my system
<boskovits>Hello
<boskovits>I need some help
<boskovits>How can I get where an input is?
<boskovits>I see, that the directory is included in the environment variables, but I need to set one more.
<boskovits>I got help earlier to find the current output directory, so I could set prefix.
<boskovits>Now I need to find the path of an input.
***in0rdr_ is now known as in0rdr
<rekado>boskovits: in the package’s arguments you can use (assoc-ref %build-inputs "the-name") and it will give you the prefix of an input.
<rekado>boskovits: in a build phase you can bind ‘inputs’ and then use that instead of the magical ‘%build-inputs’.
<boskovits>Thanks
<earthfail22>hello guys, I was installing guixsd and got many error but the last one was "In prodecure scm-error: error: no code for module (guix build utils)...."
<civodul>earthfail22: not "guys", really
<civodul>earthfail22: do you have more context above this error message?
<earthfail22>civodul: yes actually many something about Ice 9
<civodul>what was the command that led to this error?
<earthfail22>civodul: "[resolve-Interface (guix build utils) #:select ...]" in the next line it said "[ unknown file: ?: 0 [scm-error misc-error #f ...]"
<civodul>ok
<civodul>and what was the command that led to this error?
<earthfail22>all I did was guix system init /mnt/etc/config.scm /mnt
<buenouan1>I'm having a weird thing with my touchpad. 2008 Macbook running GuixSD. Every other boot, the pointer can't move from a vertical line.
<buenouan1>I can reboot and it works normal.
<civodul>earthfail22: would you be able to copy/paste everything or take a picture of the screen?
<buenouan1>And it's not just vertical, it's tied in to the horizontal direction on the touchpad - So moving a finger left/right moves it up/down the middle of the screen.
<earthfail22>civodul: I actually took one but how Can I send it?
<buenouan1>and up/down on the touchpad does nothing
<civodul>earthfail22: there are web sites where one can upload pictures, but i always forget the name
<civodul>anyone remembers one?
<earthfail22>civodul: is imgur fine?
<civodul>yes
<civodul>that's the one i had in mind
<earthfail22>sorry for the mess I'm really new to all of this
<civodul>sure, np
<earthfail22> https://imgur.com/gallery/xtxaZ here is a link
<efraim> https://www.kickstarter.com/projects/librecomputer/libre-computer-board-next-gen-4k-sbc-dev-board-for similar to odroid-c2
<civodul>oh it's gtk-im-modules.drv failing to build
<earthfail22>should I send a bug note?
<civodul>not yet :-)
<civodul>what's the output of "guix --version"?
<civodul>the is the 0.13.0 installation image?
<earthfail22>I used the lastest version with 32 bit
<civodul>which version exactly?
<earthfail22>guixsd-usb-install-0.13.0.i686-linux.xz
<earthfail22>I made a bootable usb as instructed in the manual
<bavier`>would a 'guix pull' prior to running 'guix system init' fix it?
<civodul>ok
<civodul>bavier`: the profile hook for "gtk-im-modules" looks good to me, and apparently it hasn't changed
<civodul>weird
<bavier`>oh, yeah, that's different then
<earthfail22>I searched the web before asking here and tried guix pull before it and it failed but sadly I don't remember the error
<civodul>earthfail22: could you post your OS config file?
<civodul>was it just a slightly modified desktop.scm?
<earthfail22>yes just removed the encryption part and changed the name and home directory name
<earthfail22> https://paste.gnome.org/pigemzpzp
<earthfail22> https://paste.gnome.org/phf48m1ne
<earthfail22>removed this (dependencies mapped-devices) changed my-root to my label and sdX to sda
<civodul>did you add anything to 'packages' or 'services'?
<earthfail22>no didn't even touch them
<earthfail22>goodbye my dear friend civodul will miss you
<paroneayea>I really gotta get in a better habit of saving profiles for the stuff I'm hacking on
<paroneayea>as in, saving a root somewhere
<paroneayea>that way I don't do an upgrade and then go "oh noes where's my environments at"
<paroneayea>"how does I hacks"
<paroneayea>my own bad probably
<ng0>is there a problem with master or is my upgrade from this 0.12something machine with guile-2.0 "stuck"?
<ng0>--version says 20170322.14
<ng0>I didn't turn it on for a while
<ng0>I can upload a paste of the error
<ng0>paste.lisp.org/+7HUD
<ng0>I have git on there and enough software so I could theoretically use the git guix checkout
<mekeor>ng0: maybe you could first try to pull version 0.13?
<sneek>Welcome back mekeor, you have 1 message.
<sneek>mekeor, ng0 says: I think the problem with the wifi is more related to networkmanager. but I need to analyze my logs
<ng0>that is with a guix pull
<ng0>see paste
<ng0>I'm just trying the git way now