IRC channel logs


back to list of logs

<paroneayea>mark_weaver: francis7: confirmed from aeva that she also gets the "reset to 1969" on Guix + minifree x200
<francis7>does that hwclock command work?
<lfam>Any examples of bundling configuration files with Guix packages? Perhaps it's not a road we want to go down but it seems to be how Debian solves our nasty w3m bug:
<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
<lfam>^ mark_weaver
<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 ;)
<paroneayea>debian isn't running linux-libre
<lfam>This hwclock bug*
<paroneayea>lfam: I have thought about that :)
<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>ho ho
<paroneayea>ha ha
<paroneayea>may have narrowed down the x200 date/time issue quite a bit
<piyo>Its you!
<paroneayea>piyo: it's me! (??)
<paroneayea>piyo: hello
<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>confirmed on aeva's machine
<paroneayea>it could be another package but I assume the kernel's a likely candidate
<francis7>write to 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
<paroneayea>francis7: cool
<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
<alezost>(I don't use xfce or any other DE)
<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?
<civodul>Hello Guix!
<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>my glibc only hase stubs-64.h.
<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>this drives me crazy
<rekado>now building avr-gcc just to see the config.log; hope I can learn something from it.
<rekado>using Docker's "--net=host" to access restricted files:
<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
<civodul>we should fix it someday
<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>howdy, efraim
<civodul>welcome back :-)
<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
<civodul>that shouldn't happen
<rekado>I've been recompiling compilers for too many days now...
<civodul>heh, i know that feeling...
<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 ( 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.
<civodul>what's the "embedded" branch?
<civodul>ACTION is confused
<civodul>a glibc branch?
<rekado>it's this one:
<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
<rekado>this branch is the basis of the widely used binary release on launchpad:
<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>I think I know what's going on.
<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>rekado: oooh!
<civodul>one of these patches adds CROSS_CPATH, which is kinda useful ;-)
<rekado>yeah, I noticed that :)
<rekado>it's getting a little further now --- sanity restored
<wingo>meep meep
<civodul>hey, wingo!
<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
<efraim>yeah I saw that
<lfam>Is anyone working on it?
<lfam>I'm 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>so that Hydra has time to build it
<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>thanks :)
<taylan>meanwhile I'll see if it still works with the current master ;)
<civodul>sorry for being sloppy!
<taylan>nah, you do so much... :)
<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?
<civodul>or did i misunderstand?