IRC channel logs
2016-01-03.log
back to list of logs
<paroneayea>mark_weaver: francis7: confirmed from aeva that she also gets the "reset to 1969" on Guix + minifree x200 <lfam>They bundle a configuration file that, at least, causes w3m to not accept expired ssl certs as valid <lfam>Maybe it can be configured at build time, I will see <paroneayea>francis7: it works on Debian, then I can reboot back into Debian... I was wrong about the offset I think <paroneayea>some time *during* boot in Guix it seems to reset back to 1969 <francis7>paroneayea, you'd best ask the coreboot mailing list. <paroneayea>mark_weaver is also running Guix and libreboot on an x200 and not hitting this though and I'm not sure why that is <francis7>This issue is most likely not specific to just that one system. <paroneayea>maybe it could also be linux-libre + libreboot? I don't know <lfam>This hwclock is ... internally consistent in a very funny way, if you ask me. Considering that we reset all the timestamps in our packages ;) <lfam>Guix: Eliminating ALL sources of non-determinism from computing. ALL OF THEM <paroneayea>mark_weaver gave me some steps to try but I haven't tried them yet <lfam>I wish you luck. Soon I will have a dedicated GuixSD system so of course I will help however I can <paroneayea>but it was interesting to me that aeva had the same issue on the same hardware with guix <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? <paroneayea>may have narrowed down the x200 date/time issue quite a bit <piyo>paroneayea: hello, I thought you were commenting on my problem. <francis7>paroneayea, ping me if you find the solution. <paroneayea>francis7: so I'll write up an email detailing more but <paroneayea>francis7: I think it's the most recent guix kernel package that's causing it! <paroneayea>"hwclock -r" doesn't even work sometimes, but if I boot the first kernel / system config that guix has, there aren't the same clock problems <paroneayea>it could be another package but I assume the kernel's a likely candidate <francis7>write to libreboot-dev@nongnu.org about it when you think you've cracked it <francis7>I'm currently more or less re-writing about 1/3 of libreboot <francis7>I'll add the appropriate patch or documentation for this issue <francis7>libreboot currently uses 1 revision of coreboot for all boards, with the same patches <francis7>I'm making it use a completely different revision per board <francis7>with patches specific to each revision, per each board <francis7>that'll make libreboot much easier to maintain (especially now that there are more than 1 maintainer for different boards) <francis7>but it requires pretty much re-writing huge chunks of it <francis7>next stable release of libreboot will come with not 1, but about 20 different versions of coreboot <francis7>(small variations, so the src tarball will still be roughly the same size as current stable release, when using tar+xz) <rekado>How do you change the theme of the mouse pointer in GuixSD+Xfce? It's very dark and my Emacs is using a dark theme, so I cannot really see it well-enough the few times I need it. <rekado>so, with the sources from SVN I get this error building libgcc: configure: error: C preprocessor "/lib/cpp" fails sanity check <rekado>this happens when $CPP is undefined <rekado>when I define it as the host compiler's cpp things seem to work but then fail much later when building newlib. <rekado>I wonder why I don't get this error with the 4.9.3 release sources. <rekado>there are few differences, none of which touch CPP. <alezost>rekado: I point "~/.icons/default" to my cursor theme and the mouse pointer is themed for me <wingo>somehow when editing guile files, my emacs is in guix mode <wingo>this leads to incorrect indentation <wingo>does this happen to anyone else? <rekado>sneek: later tell alezost Thanks, I'll try that. <rekado>I'm still having trouble building a working arm-none-eabi cross-compiler from the embedded branch. <rekado>when configuring libgcc the CPP test fails because the test programme cannot be compiled. <rekado>the programme either includes limits.h or assert.h <rekado>when it includes assert.h the error is: "You need a ISO C conforming compiler to use the glibc headers" <rekado>I don't want to use glibc headers. <rekado>this compiler should not use glibc. But the host compiler building the cross compiler certainly is an ISO C conforming compiler. <rekado>if limits.h is loaded then glibc-2.22/include/gnu/stubs.h is loaded, too, which looks for gnu/stubs-32.h --- which doesn't exist as I'm using a 64 bit system. <rekado>because of that "configure" goes on to try a different preprocessor "/lib/cpp", which doesn't exist, of course. <rekado>so, I think I need to get stubs-32.h <rekado>what bothers me is that I see nothing like that when using the sources from the gcc release tarball. <rekado>unfortunately, the cross-compiler built from those sources doesn't seem to produce binaries that can be run by the board. <rekado>I would like to see the config.log in the libgcc directory of the avr-gcc compiler build. <rekado>now building avr-gcc just to see the config.log; hope I can learn something from it. <civodul>rekado: the stubs-32.h thing is used when building with -m32 (or similar) on a 64-bit host <civodul>currently our glibc packages on x86_64 doesn't provide it <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"! :-) <civodul>efraim: i was asking about a bunch of python-* packages you had sent to the mailing list <civodul>and which i left as unread in my inbox, presumably because they were pending review <civodul>ACTION dreams of a better way to track patches... <rekado>avr-gcc doesn't have any problems testing the C preprocessor. It uses a different test programme which does not attempt to include "limits.h" or "assert.h". <civodul>usually this failure is the symptom of a broader problem <civodul>though i realize saying this doesn't help much ;-) <civodul>you should try to see why it ends up loading stubs-32.h <rekado>I've been recompiling compilers for too many days now... <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>where triplet is "arm-none-eabi" <rekado>this does work with the release tarball, but it fails with the sources from the (not so very different) embedded branch. <rekado>it contains a couple of changes for embedded targets. <rekado>crucially, it is supposed to make the binary actually work on the target, whereas the one built from the release tarball simply doesn't <civodul>would it be possible to cherry-pick the relevant patch(es) instead of using the whole branch? <civodul>it could be that the branch lacks some of the fixes from 4.9 <rekado>maybe. Originally, I just wanted to take the same sources everybody else seems to be using, but this took unexpectedly long... <rekado>trying to patch the sources now. <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... <civodul>one of these patches adds CROSS_CPATH, which is kinda useful ;-) <rekado>it's getting a little further now --- sanity restored <efraim>looking at debian-security looks like we've got some cve's against samba and it's dependant ldb <lfam>efraim: `guix lint samba` says: probably vulnerable to CVE-2015-3223, CVE-2015-5252, CVE-2015-5296, CVE-2015-5299, CVE-2015-5330 <lfam>Is anyone working on it? <lfam>Sent to the ML. I need advice on which branch to push to <lfam>Alright, I'll take your advice efraim <civodul>lfam: thanks for looking into the Samba vulns! <lfam>You're welcome. Thanks to Efraim for bringing it up! <civodul>looks like Samba can be modified in master since it has only 4 dependent <lfam>What is the guideline for whether a security fix should go in master vs security-updates? <civodul>it mostly depends on the amount of rebuild <civodul>if there's a lot to rebuild, we'd rather do it in a separate branch <civodul>and so that users don't end up building the world on their machines <lfam>That makes sense. I suppose you'd also want to check for breakage if a lot of packages were to be rebuilt. <civodul>though security updates usually don't change interfaces <taylan>civodul: I think my latest mail in the guix pull thread fell through the cracks... <civodul>taylan: oooh, possibly; i need to look into it <taylan>meanwhile I'll see if it still works with the current master ;) <taylan>works for me. I think if we will keep the invariant that each $guix_source_root/foo/bar.scm file corresponds to a module (foo bar), then this is pretty much the Right Thing <civodul>mark_weaver: i think we (i.e. rekado ;-)) forgot to merge the gtk-path branch, no?