<paroneayea>that indicates there must be something to be debugged
<piyo>hello I still have a problem with TZDIR inside emacs. this works: env TZDIR=/home/piyo/.guix-profile/share/zoneinfo TZ="America/New_York" date +"%z" --> "-0500" ... inside emacs: (setenv "TZ" "America/New_York") (format-time-string "%z") --> "+0000"
<piyo>is there something special about emacs inside foreign guix?
<efraim>civodul: hi, just got back from vacation with the family. The python-* packages that lead to git-annex-remote-hubic all build nicely, but git-annex-remote-hubic itself fails `git-annex testremote $hubic`, so I need to go through some of them to make sure they all work as intended
<civodul>rekado: --net=host is like "guix environment --network"! :-)
<rekado>I'm now recompiling the cross-compiler using the gcc release tarball (not the embedded branch) and make it fail, so that I can take a look at the configure logs.
<efraim>i have libvdpau&vdpauinfo waiting on someone with a radeon R600 to test it, the git-annex-remote-hubic patch set that needs to actually work, and that large group of python-* patches from last wednesday
<rekado>(once this is all done I promise I go back to catching up on email)
<civodul>rekado: is it with the native cpp that stubs.h ends up being included? or is it with the host (arm) cpp?
<civodul>are the right libc headers being used? (host vs. build)
<efraim>although as far as tracking patches and bugs, redmine (redmine.org) has a bunch of project management stuff that might be nice
<rekado>civodul: it's the arm cpp: "/tmp/nix-build-gcc-cross-sans-libc-arm-none-eabi-4.9.3.drv-0/build/./gcc/xgcc [...] -E"
<civodul>rekado: can you check that it's indeed using headers from the arm libc?
<rekado>civodul: I just elided a whole range of includes such as "-isystem /gnu/store/1j00hiz15z619abp3sx8iw9znvi03nvc-gcc-cross-sans-libc-arm-none-eabi-4.9.3/arm-none-eabi/sys-include".
<rekado>but the error is triggered by glibc sources --- and they should not be used as I'm trying to build a bare-metal compiler.
<rekado>I'm not adding any libc: (cross-gcc triplet (cross-binutils triplet))
<rekado>split the changes of gcc/config/ and gcc/libgcc into two patch sets. With both these patch sets applied the build fails as with the code from the branch. That's nice because the diff isn't very long.
<rekado>trying to figure out what causes the failure.
<rekado>when I changed the source field to download the sources from the branch I forgot to reinstate the patches that are applied to all cross-gcc packages!
<efraim>out of curiosity, how long is the building taking you?
<rekado>efraim: when it fails it fails pretty early, after about 800 seconds. When it goes well (and fails in later dependencies) it takes much longer. I usually just tweak the build, start it, and then turn to do other things...