IRC channel logs


back to list of logs

<mark_weaver>hi zacts!
<zacts>I'm @ home now, let me see if I can fetch and build guix now
<zacts>it works!
<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)
<mark_weaver>what are you trying to do?
<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: It creates the phase, but breaks. :^P
<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
<mark_weaver>gzg: oops. remove the quotes from "LC_ALL"
<mark_weaver>gzg: no need to add me to the copyright
<mark_weaver>so it should be (setlocale LC_ALL "en_US.utf8")
<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>yes, I'm sure. thanks for the offer though :)
<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.
<gzg>mark_weaver: Hm...
<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 ?
<gzg>mark_weaver: So something along the lines of the response on ?
<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
<mark_weaver>gzg: yeah, I guess probably so.
<mark_weaver>-K is short for --keep-failed
<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".
<mark_weaver>no noticeable changes compared to what?
<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>if you do
<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.
<mark_weaver>what editor do you use?
<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>hmm. strange
<mark_weaver>anyway: cd /tmp/nix-*; grep -R /bin/sh .
<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.
<mark_weaver>there's also M-x rgrep
<gzg>Okay, went the dired route... let's see here. I'm going to add the /po files into my patch-shebang expression.
<mark_weaver>was it 'update-potfiles' that wasn't patched?
<mark_weaver> I've not seen that before (
<gzg>mark_weaver: I just rechecked actually... the only thing that doesn't seem linked are config and make files, but yeah know. :^I
<gzg>ya know*
<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.
<mark_weaver>I'm glad I've been of some help :)
<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. :^)
<mark_weaver>anyway, time for me to sleep. good luck!
*mark_weaver --> zzz
<gzg>mark_weaver: Peace. I'm probably done working on it tonight anyways. o/
<civodul>Hello Guix!
<gzg>civodul: o/
<civodul>don't miss this Guile news:
<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.
<mark_weaver>(and putting URLs to my server into the git repo)
<civodul>mark_weaver: if it works for you, we can upload them to
<mark_weaver>sounds good to me
<viric>mark_weaver: I used bittorrent DHT for similar things
<civodul>or filegive! ;-)
<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>(I use transmission)
<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>works for me
<civodul>we could also add you to the uploaders but that takes a bit of time
<viric>hm I wonder if this works:
<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.
<viric>what other mips system?
<viric>specifically, mips64.
<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>*nod* seems reasonable.
<civodul>*foreseeable (ouch!)
<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
<viric>same like the Dingoo
<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>ditto for libav/ffmpeg
<mark_weaver>I finished building natively-built MIPS N32 bootstrap tarballs for Guix.
<mark_weaver>hopefully they will soon be on
<mark_weaver>hi civodul1
<mark_weaver>I'm ready to push the loongson branch; just waiting for tarballs on :)
<mark_weaver>I guess the URL should be
<mark_weaver>(sorry to ambush you on entry :)
<civodul>i'm exaclty doing that
<civodul>with that very URL
<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>makes sense.
<mark_weaver>btw, I just renamed the files on fencepost so that they match what they should be on alpha...
<mark_weaver>sorry, I should have done that first..
<civodul>np, i renamed them in Dired
<civodul>works pretty well for that
<mark_weaver>build-aux/download.scm also needed adjustment.
<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
<civodul>so no
<mark_weaver>ah, good!
<mark_weaver>okay, I see the files are all there. thanks! :)
<mark_weaver>I'll push the branch and post in the next few hours.
<civodul>ah good
<civodul>it's arrived
<mark_weaver>what's arrived?
<mark_weaver>the files you mean?