IRC channel logs
2013-10-17.log
back to list of logs
<zacts>I'm @ home now, let me see if I can fetch and build guix now <gzg>How do you set a argument for a certain phase? <mark_weaver>phases don't have arguments. can you be more specific? <mark_weaver>(though I'm a relative newbie at guix packaging, so maybe I'm wrong) <gzg>mark_weaver: After the unset phase, I'm supposed to add a phase that just does (setlocale "LC_ALL" "en_US.utf8") -- Thinking about it, yeah, argument probably wouldn't be the way to do this... I'm just not sure how though. :^P <mark_weaver>gzg: I think you need something like (arguments '(#:phases (alist-cons-after 'unpack 'set-locale-utf8 (lambda _ (setlocale "LC_ALL" "en_US.utf8"))))) <mark_weaver>sorry, I meant: (arguments '(#:phases (alist-cons-after 'unpack 'set-locale-utf8 (lambda _ (setlocale "LC_ALL" "en_US.utf8")) %standard-phases))) <mark_weaver>so that adds a new phase called 'set-locale-utf8' after the 'unpack' phase. this new phase just does the setlocale. <gzg>mark_weaver: Also what's your email, I'm adding you to the copyright notice. *gzg still needs to figure why it's going awry though. :^P <gzg>Oh, beautiful; Thanks! :^) Now I just need to figure out why /bin/sh isn't found. <gzg>mark_weaver: Also, you sure -- that was a tremendous help? <mark_weaver>gzg: /bin/sh is not available in the chroot that does the build. <mark_weaver>gzg: all references to /bin/sh need to be converted to /nix/store/*/bin/sh <mark_weaver>that should have been taken care of automatically in one of the default phases. <mark_weaver>but maybe it's in a place where it doesn't get found automatically. <mark_weaver>I think the automatic scan might only search at the top of scripts, e.g. #!/bin/sh <gzg>mark_weaver: It's looking in /timp/nux-build.../kbd-1.25.3/po <gzg>Other directories in kbd-1.25.3/s seems to have worked just fine? :^P <mark_weaver>yeah, the automatic patching is only done for shebangs at the top of scripts. <mark_weaver>you might need to do your own manual substitutions, pass some arguments to make or configure, or perhaps set some environment variables or something. <mark_weaver>packages that use the gnu build system allow you to set the shell with variables like SHELL and CONFIG_SHELL, etc. and that's probably being done automatically here, but this package probably doesn't support the standard ways of overriding the desired shell. <mark_weaver>gzg: do you know about the -K option to guix build ? <mark_weaver>that causes it to leave the build directory around after a failed build. <mark_weaver>I'd do guix build -K <package>, and then look in the build directory for occurrences of /bin/sh <gzg>mark_weaver: It's weird, it's saying it patched /bin/sh though... <mark_weaver>it might not have found all the places that needed to be changed. that's why I suggest searching for occurrences of bare /bin/sh in the failed build directory. <gzg>I did' but there's no noticeable changes? <mark_weaver>you did what? and I don't know what you mean by "no noticeable changes". <gzg>mark_weaver: Sorry, I'm not being very clear. I'm not sure what that did over normal build, since my build failed isn't it there anyways? At least the directory was there before added the -K flag... *gzg really needs to learn grep. <mark_weaver>unless you pass -K, it will delete the build directory from /tmp/nix-* <mark_weaver>if you pass -K, then you can look around in /tmp/nix-* after it fails. <gzg>mark_weaver: Emacs. And I swear, it was there prior to the -K flag, unless there's some weird waiting mechanism... but it might just be a bug? <mark_weaver>or in emacs, open the directory in dired, and then do M-x grep-find <mark_weaver>the emacs way is nicer because you can just hit RET on any of the lines, and it will automatically open the file at that line. <gzg>Okay, went the dired route... let's see here. I'm going to add the /po files into my patch-shebang expression. <gzg>mark_weaver: I just rechecked actually... the only thing that doesn't seem linked are config and make files, but yeah know. :^I <mark_weaver>anyway, hopefully civodul, a_e, or Steap will be online in a couple of hours, and they are all more knowledgeable about guix packaging than I am. <gzg>mark_weaver: No worries, you've already been a tremendous help. :^) <mark_weaver>I'm a core dev for Guile, but am still relatively new at Guix. <gzg>mark_weaver: Believe me, you were -- you've forced me into looking into arguments more seriously, which I'm sure will serve me well in the long run. :^) <gzg>mark_weaver: Peace. I'm probably done working on it tonight anyways. o/ <mark_weaver>civodul: I'm very close to having natively-built bootstrap tarballs for MIPS N32. I'm wondering if they should be put online somewhere, such that MIPS users could simply check out a git branch of guix and have it work properly without fiddling. What do you think? <mark_weaver>my own server has limited bandwidth, such that I'm not entirely comfortable hosting them there. <civodul>mark_weaver: if it works for you, we can upload them to alpha.gnu.org <viric>mark_weaver: I used bittorrent DHT for similar things <mark_weaver>viric: bittorrent sounds good, now we just need to add BT support to guix :) <civodul>mark_weaver: anyway, i can do the upload myself if you can put them somewhere in the meantime <viric>I'm not sure how well the bittorrent DHT works. some people have troubles downloading the files, despite my client being always connected. <viric>Next time I'll use that simple tracker... how is it called... <mark_weaver>civodul: sounds good. I could put them in my home directory on fencepost. I could also sign them with a GPG key that I recently got signed by RMS. <civodul>we could also add you to the uploaders but that takes a bit of time <mark_weaver>my next question is: should I make my new loongson branch off of master or core-updates? <mark_weaver>I guess core-updates makes more sense, because that's where it might actually be merged. <mark_weaver>though it seems likely that loongson will always be a branch, with some patches that aren't yet ready for upstream. <civodul>well, it upstream is unusable by patches, then the patches are better than nothing <civodul>in addition, i guess they don't hurt the other arches <mark_weaver>That's true; the most important patches would only hurt other MIPS systems. For example, 'pixman' checks for a Loongson 2F processor at 'configure' time, and if present, uses a bunch of Loongson 2F specific SIMD instructions. Our current guix package for pixman does not prevent this impurity. <mark_weaver>but if we fix that by disabling the loongson support in generic MIPS N32, then we'll have to make a separate branch for Loongson 2F, because those optimizations are very important for graphics performance in X and cairo (and thus Gtk) <mark_weaver>of course, the best solution would be to make pixman detect the processor at runtime and dynamically use the right code, but that's a bigger fix. <civodul>yeah i guess in practice it'll be just Loongson for the forthseeable future <civodul>when someone comes up with another MIPS system, we can still adjust <mark_weaver>viric: to be honest, I'm not very familiar with MIPS outside of Loongson 2F, but I know that the 2F has non-standard SIMD instructions. <viric>I've a nanonote, but it's mips32 <mark_weaver>so I'm fairly sure that e.g. the pixman code won't work on a standard mips64 system. <mark_weaver>in the kernel, there are a bunch of patches that were never upstreamed. <mark_weaver>I finished building natively-built MIPS N32 bootstrap tarballs for Guix. <mark_weaver>I'm ready to push the loongson branch; just waiting for tarballs on alpha.gnu.org :) <civodul>mark_weaver: you'll have to fiddle with bootstrap.scm so it uses the right dir and file names on mips64el-linux <civodul>i think this should be abstracted a little <civodul>for instance, we could have an alist that maps arch -> package -> url <mark_weaver>btw, I just renamed the files on fencepost so that they match what they should be on alpha... <mark_weaver>ideally, we could generate new bootstrap tarballs for all the arches the next time you merge core-updates.. and then we wouldn't need the abstraction. <civodul>though it would still be good if all the URLs and hashes were in one place <civodul>the manual could say "update this variable" instead of "go do the right thing in bootstrap.scm" ;-) <mark_weaver>if I started bootstrapping now, and then added the abstraction later, would that force me to rebuild everything? <civodul>the abstraction is just "host-side" code, so it doesn't change the bits of the inputs <mark_weaver>I'll push the branch and post in the next few hours.