IRC channel logs


back to list of logs

<davexunit>file name completion is broken with some guix commands
<davexunit>guix environment -l pack<TAB> doesn't do anything
<davexunit>when it should complete to: guix environment -l package.scm
<davexunit>since that is the file I have in my $PWD
<vmlinuz88>davexunit: How do I get guix to be aware of the path of my package definitions?
<davexunit>vmlinuz88: $GUIX_PACKAGE_PATH
<vmlinuz88>I set GUIX_PACKAGE_PATH to the directory containing the pkg defs, but still doesn't work
<davexunit>put the packages in the gnu/packages namespace
<davexunit>and make sure you're using proper modules
<vmlinuz88>I already have (define-module gnu packages obconf on the first line of the pkg def
<vmlinuz88>well (define-module (gnu packages obconf) to be specific
<davexunit>is the corresponding file in gnu/packages/obconf.scm ?
<vmlinuz88>no, I didn't think I have write permission for that directory though
<vmlinuz88>Im on guixSD
<davexunit>relative to the directory you added to GUIX_PACKAGE_PATH
<davexunit>guile looks up a module name like (gnu packages foo) by searching for a file named gnu/packages/foo.scm in each directory on its load path
<vmlinuz88>oh, so the layout of the directory of guix package path has to resemble gnu/packages ?
<vmlinuz88> duhh
<davexunit>if the module name is (gnu packages obconf), yes.
<vmlinuz88>I see what happened now
<davexunit>I think you might not need the same directory structure, but I do it anyhow.
<vmlinuz88>okay, got it to work, now I am running guix lint
<vmlinuz88>thank you
***y is now known as \\e
***\\e is now known as exio4
<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.
<civodul>Hello Guix!
<mthl>hello civodul
<ewemoa>does video.scm seem like an appropriate place for arandr?
<mthl>ewemoa: I think xdisorg.scm is a better choice.
<ewemoa>ueno: thanks!
<ewemoa>mthl: thanks :)
<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/ undefined reference to `__getrlimit@GLIBC_PRIVATE'
<efraim>/gnu/store/hy2hi0zj5hrqkmkhpdxf04c9bcnlnsf9-glibc-2.21/lib/ undefined reference to `__libc_vfork@GLIBC_PRIVATE'
<paroneayea>bavier: mark_weaver: the hydra change is merged!
<efraim>also guix pull failed on me again
<ewemoa>rekado_: finally got java 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
<efraim>yeah it says pulling from ...../guix.git/snapshot/guix-master.tar.gz
<mark_weaver>paroneayea: the hydra change? do you mean the license change to the perl library that hydra needs?
<mark_weaver>ewemoa: ah, thanks!
<efraim>the guix pull fail and the glibc error on running make on the git repo happened about the same time so I assumed they were related
<efraim>guix pull always stops at 40.5%
<civodul>efraim: re the glibc error, is LD_LIBRARY_PATH set, or something like that?
<civodul>and how did you obtain it, like what command did you run?
<efraim>$LD_LIBRARY_PATH doesn't return anything
<efraim>the git repo? git clone
<efraim>find / -name shows I have a couple others in /lib
<civodul>so you run "make" in the Guix repo and you get that undefined reference error, right?
<civodul>could you paste the command that triggers that error?
<efraim>./bootstrap && ./configure && make
<efraim>well, only make after bootstrap and configure worked
<efraim>i assume it would be bad to delete /gnu/store/...glibc and then rerun guix pull
<paroneayea>mark_weaver: yep
<paroneayea>it got merged
<mark_weaver>yes, it would be bad. you must never delete or modify anything in /gnu/store
<mark_weaver>paroneayea: that's great news!!
<efraim>civodul: I got a hit on the character: #\\e string from gnu/packages/enlightenment.scm
<efraim>thats one of the packages I tried to upgrade
<mark_weaver>efraim: it sounds like you used the output of 'sha256sum' instead of 'guix hash'.
<efraim>that I did
<mark_weaver>they are both sha256, but a different encoding is used to convert the 256 bit number to a text string.
<efraim>but the .config/latest/gnu/packages/enlightenment.scm doesn't have that string
<civodul>efraim: sorry i meant: could you paste the command that "make" runs, and which leads to this error?
<civodul>or basically post the last 20 lines of the build log including the error
<mark_weaver>efraim: when you run 'make', the relevant thing is the code in that source tree, not what's in ~/.config
<efraim>right, but the invalid character is giving me the error from guix pull, which would care about .config/guix/latest/ which points at /gnu/store/...latest
<mark_weaver>efraim: the .config/guix/latest symlink is not moved to the new code until after 'guix pull' succeeds.
<mark_weaver>"guix pull" builds the latest code from the master branch in our git repo, unless you override the source URL that it downloads from.
<efraim>i haven't changed the url
<efraim> output from the make command
<mark_weaver>I'm confused, there are apparently two very different problems here. in one of your pastes, there's a problem related to an invalid 'base32' string.
<mark_weaver>in another of your pastes, there is a link problem with guix-daemon.
<mark_weaver>are you saying that you're experiencing both of these problems? sometimes you get one of the errors, and sometimes you get the other error? I don't undrstand.
<efraim>i have two different errors that I assumed were related
<efraim>i get the base32 error with guix pull
<efraim>and the link problem with guix-daemon when I try to build from git clone
<bavier`>paroneayea: thanks for the comment on the set-object pull request
<mark_weaver>efraim: hmm, okay.
<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.
<efraim>so i'll change my PATH and run make again
<mark_weaver>so either build in an environment where nothing is used from the host OS, or nothing is used from Guix.
<mark_weaver>relevant environment variables include PATH, LIBRARY_PATH, CPATH, PKG_CONFIG_PATH, and maybe others/
<mark_weaver>LD_LIBRARY_PATH also, although we don't normally set that.
<mark_weaver>efraim: regarding the 'base32' error: I just searched for that faulty base32 string in and didn't find it. where exactly did you find it?
<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?
<efraim>lrwxrwxrwx 1 efraim efraim 55 Jun 8 23:15 .config/guix/latest -> /gnu/store/cw9m6fw3j1d6l8fxjbvmgs4795rqa3s2-guix-latest
<mark_weaver>when you ran 'guix pull', were you using 'guix' from your git checkout?
<efraim>which guix points to /usr/local/bin/guix and I don't specify guix from checkout, so it shouldn't
<mark_weaver>or did you "make install" that faulty base32 string?
<efraim>i could change my directory to ~/, but it'll take ~25 minutes to get there
<efraim>i never ran make install, just wanted to get through make so I could use /pre_install_env
<mark_weaver>efraim: so where did /usr/local/bin/guix come from?
<efraim>from the binary tarball
<efraim>that points at /root/.guix-profile/bin/guix
<mark_weaver>well, I'm not sure why a faulty base32 string that's in your git checkout directory would affect 'guix pull'
<mark_weaver>one possibility is that some of your environment variables are pointing to your git repo
<efraim>what about a successful guix build enlightenment -L guix-git
<efraim>with the sha256sum instead of guix hash
<mark_weaver>efraim: can you try "env | grep guix-git" from the same shell where 'guix pull' fails?
<efraim>in a second, right now its rerunning make with a system-only PATH
<mark_weaver>okay, I have to go afk for a while. good luck...
<mark_weaver>the other thing to try is running "strace -f -o trace.out guix pull" and see if it loads the faulty file.
<mark_weaver>anyway, gotta run!
<efraim>mark_weaver: here's the log from `strace -f -o log1 guix pull`; i haven't looked through it just yet
<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
<mark_weaver>well, that's a drag
<mark_weaver>so you have a corrupted store item now.
<mark_weaver>if you need to become root to edit something, make sure it's not in /gnu/store, taking into account the existence of symlinks
<davexunit>this is why we bind mount /gnu/store read-only on GuixSD
<mark_weaver>anyway, it's probably not too important in this case, because you're unlikely to ever need to use that store item again.
<mark_weaver>there was another commit to the repo about 2 hours ago, since you had this problem, so now 'guix pull' should work.
<mark_weaver>but in general, editing files in the store could be hard to fix.
<mark_weaver>we don't really have a good way to recover from that.
<efraim>well, guix pull just failed again, is my best case at this point to rm -rf /gnu/store /var/guix ~/.guix-profile and start over?
<efraim>i have guix package -I to know what I have installed
<mark_weaver>efraim: did you editor leave a backup file? maybe you can undo the change.
<mark_weaver>in the worse case, you can start over from scratch, as you outlined.
<efraim>doesn't look like it
<efraim>enlightenment.{scm,go} are the only ones with an edit date not of jan 1 1970
<mark_weaver>you could probably just edit it to have a valid base32 string and then 'guix pull'
<mark_weaver>although if you have the backup file, that would be ideal.
<efraim>the contents of the file look alright
<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
<efraim>could it be the the .go file?
<mark_weaver>yes, it could be. try deleting all of ~/.cache/guile/ccache
<efraim>i don't have a ~/.cache/guile folder atm
<mark_weaver>anyway, I don't have any more time to spare on this. if you can't fix it another way, I guess you should just wipe /gnu/store and /var/guix and start over.
<efraim>fair enough
<efraim>thanks for helping
<alezost>davexunit: hi, "guix environment -l <TAB>" completes the files in the current directory for me. Is that what doesn't work for you?
<davexunit>alezost: I noticed that it works in M-x shell in emacs but not in bash in my xfce term
<mark_weaver>davexunit: that's civodul's implementation of bash completion, which is independent of the emacs one.
<alezost>davexunit: oh, I thought you meant the emacs completions
<davexunit>alezost: no, sorry for the ambiguity.
<davexunit>I had forgotten that you recently added completion.
<alezost>no problems :-)
<mark_weaver>davexunit: it's in etc/completion/bash in the guix source tree
<davexunit>mark_weaver: I'll have to investigate further when I have time.
<alezost>the problem with bash completions is that for "environment" it tries to complete packages, not files
<mark_weaver>or you could just report it to bug-guix and civodul will probably fix it.
<alezost>I think it cannot be easily fixed, because it requires messing with options: "environment" should complete packages, but "-l" option should complete files
<mark_weaver>bash completion can't do custom completion for individual option arguments?
<mark_weaver>(I've never looked into it, partly because I run shells within emacs)
<alezost>I think it's possible but it's a lot of work and shell syntax is not very pleasant for that
<davexunit>yeah, I hate writing bash scripts. I do minimal bash and push everything significant into guile scripts.
<sneek>Welcome back wingo, you have 1 message.
<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>i need to do that
<wingo>i have to Ctrl-R and hope that it shows up when i restart
<wingo>which is not frequently :P
<wingo>good evening mark_weaver :)
<mark_weaver>hi wingo! :)
<wingo>search back in a terminal
<mark_weaver>oh right :)
<wingo>how goes with you, mark_weaver ?
<mark_weaver>yeah, I did that for a long time
<mark_weaver>oh, I'm perpetually low on sleep, and a bit overwhelmed by the kids in the house (a 4 year old and 4 month old)
<mark_weaver>it seems that I have very little energy available to contribute to free software projects at the moment, which is too bad.
<wingo>it's ok :)
<mark_weaver>I expect it will get better at some point
<wingo>you'll find time some time
<wingo>i am being bristly at work trying to carve out more guile time
<wingo>it's going ok
<mark_weaver>it's great that you've been able to do more work on the compiler lately :)
<wingo>it's been a pleasure :)
<wingo>and such a pleasure to be able to think more in terms of sets and maps and what-not
<davexunit>as opposed to what?
<wingo>but, on some files this rewrite uses more time
<wingo>davexunit: as opposed to the mechanics needed to implement the same thing
<wingo>i mean, intmap-fold is really really nice
<davexunit>cps vs cps2?
<wingo>cps2 is slower on e.g. assembler.scm
<wingo>like 10 times slower (!)
<wingo>but i haven't optimized it yet
<wingo>when i was working on the simplifier i was able to get down to the same speed as before
<wingo>so i reckon something similar should happen now
<wingo>but, memory use is down significantly.
<wingo>which was a big issue before.
<wingo>next up is closure conversion, and i think we can do better than before, because we can share closures
<wingo>e.g. f, g, and h are mutually recursive and all of their call sites are well-known -> they share a closure
<wingo>so the transitive set of variables that are free in f, g, and h go into that closure, but only one copy instead of 3
<wingo>simple things like finding strongly-connected components are easier now, i feel. dunno tho
<mark_weaver>if the code is different, how can they share a closure?
<mark_weaver>oh, one closure with multiple code pointers?
<mark_weaver>sorry, kid emergency.. gotta go
<wingo>mark_weaver: so the thing is
<wingo>if a closure is well-known
<wingo>then you call it with call-label
<wingo>which is effectively a jmp or a call with a known label
<wingo>in that case the value you pass as parameter 0
<wingo>which is the closure
<wingo>can be anything.
<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
<wingo>it's a neat trick
<wingo>you end up recovering objects from closures
<wingo>ok, /me -> zzz
<civodul>correct package 'location' for everyone, yay!
*civodul -> zZz
***eru-iluvatar is now known as eru
***eru is now known as eru-iluvatar