<vmlinuz88>build failed. it says failed to produce output path. is this error familiar to anyone here? if so, is there a general fix for these types of errors?
<mark_weaver>that error indicates that nothing got installed in the output directory where it should have been installed
<iyzsong>Yes, sound like the 'install' phase doesn't install files into the right place. paste the detail log and package recipe should help more.
<mark_weaver>the default 'configure' phase in gnu-build-system passes --prefix=<output-directory> to ./configure, and the default 'install' phase does "make install", so normally things would get installed there.
<vmlinuz88>ah okay, I see what happened. I have --prefix in the configure-flags part, which shouldn't be there.
<ewemoa>mark_weaver: thanks for posting the link to the 'hackers' video -- around 14:03 there's a segment with one of the creators of wizardry, robert woodhead, i think this is the same fellow making the remarks about art and paint
<civodul>anyone knows if Poppler can be made to handle "video" annotations in PDFs?
<efraim>i've been getting some errors in glibc, any suggestions for fixing/overwriting it?
<efraim>/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/libpthread.so.0: undefined reference to `__getrlimit@GLIBC_PRIVATE'
<efraim>/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/libpthread.so.0: undefined reference to `__libc_vfork@GLIBC_PRIVATE'
<paroneayea>bavier: mark_weaver: the hydra change is merged!
<ewemoa>rekado_: finally got java -Djavax.net.ssl.trustStore=cacerts JavaHttpsExample to work -- as a test i obtained an appropriate cacerts file
<ewemoa>i guess /etc/ssl/certs/ca-certificates.crt is in x.509 format, while the trustStore type default for java is jks -- at least one other distribution uses keytool to create an appropriate cacerts file in jks format at the time of building openjdk / icedtea
<civodul>efraim: the relevant part is this: &invalid-base32-character [character: #\\e string: "f40a533956bb9b48374322cdf6b6d51dc97326ea7a087dce852a829d6c6b9be0"]
<civodul>are you pulling from master or using a custom URL?
<efraim>civodul: i just gun `guix pull` so it should be from master
<mark_weaver>well, the link problem is probably because you are trying to build 'guix' in an environment where some of the libraries/headers/compiler of your host OS is getting used.
<mark_weaver>when running Guix on top of another system, you must ensure that whenever you build some software, you are using libraries/headers/compiler from only one of the systems. if you try to mix them, you will get problems like this.
<mark_weaver>specifically, I searched for f40a533956bb9b48374322cdf6b6d51dc97326ea7a087dce852a829d6c6b9be0
<efraim>i found it in my git checkout from my edited gnu/packages/enlightenment.scm
<davexunit>I ran into some issues around this. I was hoping to be able to use ruby's built-in package manager on my guix + host OS system, but things failed hard when I tried installing gems that build native extensions.
<mark_weaver>efraim: does ~/.config/guix/latest point to you git checkout?
<mark_weaver>efraim: thanks. looking at the trace output, I'm reminded that the build is actually happening within an isolated container created by guix-daemon, so the trace is not reaching the relevant processes anyway.
<mark_weaver>efraim: but since the error happens inside the build container, that means that the only available inputs are in /gnu/store
<mark_weaver>so now I'm suspicious that you may have edited a file within /gnu/store
<mark_weaver>so, how about doing this: cd /gnu/store; grep -r f40a533956bb9b48374322cdf6b6d51dc97326ea7a087dce852a829d6c6b9be0
<mark_weaver>efraim: did you ever edit enlightenment.scm within ~/.config/guix/latest ?
<mark_weaver>if so, you would have needed to become root to do so.
<mark_weaver>~/.config/guix/latest is a symlink to a subdirectory of /gnu/store, so if you edited such a file, then you mutated the store. the proper operation of guix depends on the contents of /gnu/store being immutable.
<efraim>mark_weaver: I probably did while I was trying to update the package
<efraim>if I could change the date to jan 1 1970 it might fix it
<mark_weaver>it's easy enough to change the date, but that won't fix it. based on the error, something in the store has an invalid base32 string, and I guess it's in that file. there's an 'e' in the string, right?
<mark_weaver>there's probably also an associated cached .go file (compiled from the .scm) in your ~/.cache/guile/ccache
<sneek>wingo, wleslie says: I remembered why my X1 carbon has a working caps->ctrl mapping, and it's super ugly: (run-shell-command "xmodmap -e 'keycode 66 = Control_L' -e 'clear Lock' -e 'add control = Control_L'")
*mark_weaver put "setxkbmap -layout us -option ctrl:nocaps" in his .xsession
<wingo>you're effectively making your own calling convention, because all call sites are known
<wingo>so for example if there is only one free variable of the closure, you don't need to allocate anything at all -- you just pass that free variable as parameter 0
<wingo>or, if there are two free variables, you don't need to allocate a closure object (which would also include a code pointer); you can just pass those variables in a data structure (a pair is cheapest) and rewrite the body of the closure to read free vars using car and cdr
<wingo>same stuff as in orbit but using the better formulation from the "optimizing closures in o(0) time" paper
<wingo>with a set of well-known mutually recursive procedures the transitive free variable set is the union of all free variables, and since the lifetime of one closure is the lifetime of all you can share a vector of those variables