IRC channel logs

<civodul>interesting

<mark_weaver>so maybe I'll try to be a little less paranoid about security for the time being, and just load up Parabola for now. Guix is my best hope for better endpoint security, and so the rational action seems to be to move that work forward even if it means less security in the short term.

*civodul nods

<mark_weaver>or perhaps I should just copy over my nix-upstream checkout from my thinkpad backup.

<mark_weaver>yeah, maybe that's worth a try first.

<civodul>mark_weaver: do you do all your hacking on MIPS?

<mark_weaver>well, my thinkpad has a serious problem: some circuit near the lower-left corner of the display, apparently related to the backlight, gets very hot and the backlight soon stops working. so that machine is essentially unusable as a local machine. I could use it for remote login though.

<mark_weaver>so at present, my YeeLoong is the only computer I'm using.

<mark_weaver>(my internet server is a SPARC box)

<civodul>ok

*civodul has a bunch of SPARCs in the basement

<mark_weaver>I also have a Raspberry Pi to play around with ARM (it was a gift, and I accepted it before I knew about its fatal flaw )-:

<civodul>heh

<mark_weaver>anyway, I'd like to focus on porting Guix to MIPS for now, and eventually ARM as well if no one else does so.

<civodul>cool

<mark_weaver>for now, I'll do the MIPS port using the most expedient method possible.

<civodul>apparently Nikita has troubles getting the n64 binaries to run

<civodul>not clear why

<mark_weaver>Note that some of the toolchain will require some patches to work around a bug in the Loongson 2F, which doesn't have flashable microcode (something I'm actually somewhat thankful for)

<civodul>yes, i remember seeing that sort of terrible patch in Nixpkgs ;-)

<civodul>for ARM, the trick will be to choose the ABI du jour

<mark_weaver>also, I wrote a patch long ago for linux-libre to support the Loongson floating-point instructions (MIPS relies on the kernel to handle edge cases like NaNs and denormalized numbers), a patch which I posted to the loongson-dev list but never bothered to submit upstream to Linux-MIPS.

<mark_weaver>I suspect it's still not in the upstream linux-libre.

<mark_weaver>so, lots to do...

<civodul>indeed, not an easy target

<mark_weaver>there was also a bug in binutils, which encoded one of the Loongson-specific instructions according to the english Loongson docs, which turned out to be incorrect. not sure if that was never sent upstream either :-(

<mark_weaver>yeah, the GNU toolchain needs a lot of work for MIPS.

<mark_weaver>I should probably try to get my hands on the newer YeeLoong that's over 3 times as fast as this one. Maybe I can convince djbclark to lend me one.

<civodul>yes, djbclark said during the hackathon that he'd be happy to help people who volunteer for porting with hardware

<civodul>good night/day!

<mark_weaver>hi civodul!

<civodul>hey, mark_weaver!

<youlysses>civodul: o/

<civodul>youlysses: apparently Mailman suspended your subscription to the list because of excessive bounce

<civodul>mark_weaver: i'm struggling with circular module dependencies

<youlysses>Weird, I have a pretty solid network connection. :^P

<civodul>apparently something wrong with the MX of riseup.net

<youlysses>civodul: Might be an excuse for me to finally start hosting my own mail-server at somepoint then.

<civodul>heh

<civodul>did you notice your patch got in?

<mark_weaver>civodul: I'm not sure why circular module dependencies need to be a problem as long as only procedures are involved (not macros). but maybe in practice they are a problem, dunno.

<mark_weaver>s/procedures/variables/

<civodul>me neither

<civodul>it's hard to debug

<youlysses>civodul: Yup, I saw it yesterday when I pulled on my new, build VM. :^)

<civodul>good :-)

<youlysses>civodul: In-terms of the VM, it's powered on NixOS -- but when I grab the guix package via repo,it won't let be do anything but build from source and won't let me pull the latest. Don't know if it's just me, but fyi. :^P

<civodul>youlysses: report a bug with more details, please :-)

<youlysses>civodul: Is there a proper way to do a scan, or just generally go into expansive detail? Too in here guix-bug, or the nix mailing list?

<mark_weaver>hmm, glib FTBFS for me: "FAIL: network-address". Is this a known problem?

<mark_weaver>I guess that's not important for my task at hand, but I happened to notice when doing "guix package -u"

<mark_weaver>the good news is that I managed to build Guix on my home-grown YeeLoong system, and I'm ready to start trying to build (suitably patched) bootstrap tarballs for MIPS.

<mark_weaver>civodul: is it okay if I push a preliminary branch with my MIPS patches? Maybe something like "wip-loongson"?

<mark_weaver>well, I'm not ready to push anything, so it needn't be decided now.

<civodul>mark_weaver: sure!

<civodul>mark_weaver: glib works for me on x86_64

<civodul>youlysses: if the problem is "does not download binaries from hydra", the relevant info is the system type (i686-linux?), and the exact store names of the packages you think it should be downloading

<civodul>plus anything you think might be useful

<youlysses>civodul: Okay, marked down -- I'll submit a formal post either today or tomorrow (Atm, I'm busy packaging up my stuff; I'm driving to my apartment from my parent's house in another hour or two and that takes like two and a half...)

<civodul>ok :-)

<Steap>civodul: just saw your mail about sbcl, wouldn't it be easier to use the trivial-build-system in this case ? If not, what is the use case for it ?

<civodul>it's only for things that are really trivial

<civodul>because it doesn't even unpack the source etc.

<Steap>oh

<civodul>and usually you want the 'strip' phase and things like that anyway

<Steap>Trivial has no phases at all ?

<civodul>no, nothing

<civodul>hence the name :-)

<Steap>I see.

<mark_weaver>civodul: did you successfully build /nix/store/7fm024bcyw7996jn59pcl7zb6x8vcp4s-glib-2.38.0.drv ?

<mark_weaver>mine consistently fails the make check: "FAIL: network-address"

<mark_weaver>(this on x86_64)

<civodul>mark_weaver: yes, it built here

<civodul>presumably there's an "impurity"

<civodul>like the test relies on IPv6 or some other kernel feature

<mark_weaver>*nod*

<mark_weaver>this is on a debian stock kernel, which certainly has IPv6

<mark_weaver>what's the incantation to leave the build directory intact?

<mark_weaver>ah, --keep-failed..

<mark_weaver>(sorry, I should rtfm first :)

*civodul looks at network-address.c

<civodul>those APIs are a bit crazy

<civodul>i don't see what's problematic here

<mark_weaver>network-address.log contains: GLib-GIO:ERROR:network-address.c:138:find_ifname_and_index: assertion failed (SCOPE_ID_TEST_IFNAME != ""): ("" != "")

<mark_weaver>../../tap-test: line 5: 22684 Aborted $1 -k --tap

<mark_weaver>if I run ./network-address manually, it works, so I guess it's related to the restricted build environment created by guix-daemon.

<civodul>mark_weaver: could you strace it?

<civodul>if_indextoname is implemented using an ioctl

<civodul>so no /proc /sys etc. involved

<mark_weaver>civodul: it accesses /proc/net and /proc/net/unix

<mark_weaver>and then: socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4

<mark_weaver>and on that FD it does: ioctl(4, SIOCGIFNAME, {ifr_index=1, ifr_name="lo"}) = 0

<mark_weaver>and it stats /etc/resolv.conf

<mark_weaver>and then on the same FD it does: ioctl(4, SIOCGIFINDEX, {ifr_name="lo", ifr_index=1}) = 0

<mark_weaver>but this is what it does when I run it outside of guix-daemon, where it succeeds.

<civodul>yes

<civodul>hmm

<civodul> /proc is OK, /etc/resolv.conf is not, but i don't think it actually uses it

<civodul>unix/sysv/linux/opensock.c fiddles with /proc

<civodul>hmm, no idea

<civodul>mark_weaver: perhaps you could try to add a phase that runs the thing through strace

<civodul>for lack of a better idea

<civodul>/proc/net/unix should definitely exist in the chroot

<civodul>anyway good night/day!

IRC channel logs

2013-10-06.log