<htgoebel>rekado: Setting the mtime before the .pyc files are generated would be much easier, since python is going to make the job. But if I understand 22533 correctly, this approach was already taken and made tests fail.
<civodul>rekado: now you have a legitimate reason to work on this ;-)
<htgoebel>Thus maybe we could patch the .pyc files.
<htgoebel>But this is more fragile, esp. since Python 3.7 will have a new deterministic file-format.
<civodul>actually strip-nondeterminism probably does that
<wingo>civodul: regarding complexity of guild compile -O0: i am sure we can do better. probably sufficient to write a different slot allocator for use in -O0 compilations
<wingo>i think that would more-or-less solve the problem.
<wingo>civodul: i'm also looking to solve the problem in other ways in master, but that's not really applicable to guix right now
<htgoebel>Perhaps we should change "beta" into "gamma" :-) Or into "rc1"
<htgoebel>How can I create an installation image which includes the guix from my *current* development tree and will install this version of guix into the new system? (I want this system to substitute stuff already build on my development machine.)
<efraim>guix system disk-image gnu/system/install.scm ?
<bms_>I just (finally) got my package to install on GuixSD and I'm very happy with it. It's still a less-than-ideal setup as I'm hosting my tarball distribution on Dropbox (eventually, my plan is to submit to GNU and use their FTP), meaning I have to reupload to that and rehash everytime I make a change, but it works.
<bms_>But for the current stage in the project, it works perfectly. I need to move it farther along before GNU evaluation is viable.
<bms_>I also want to thank you and everyone here for making Guix and GuixSD so good. Once you get past the dirty setup bits, it's near-perfection.
<bms_>And the Grub-EFI support is very helpful for my iMac.
<civodul>bms_: what is the project you're talking about?
<civodul>happy_gnu[m]: normally it's enough to have (1) the GuixSD config file, and (2) the Guix commit id
<bms_>My project is an extensible, encrypted, federated instant messenger, written in Guile. I call it msg. It's designed so that one command can start both a server or a client and with small communities in mind. Don't think of it as a replacement for large IRC servers, more like a modern UNIX talk with groups. It's not exactly that either. I don't know what to compare it to.
<bms_>In theory, everyone can start a server with relative ease for a small group of friends. And the servers stay small and simple enough that you can run one and the client on the same computer, with standard specifications.
<lfam>The newer CMakes seem to build our packages fine, but there are some test failures in CMake that appear spurious. I'm trying to understand them a bit more before sending a patch to disable them
<kmicu>TeMPOraL: did you load Xft module in your StumpWM configuration?
<lfam>I used that system-on-a-chip but in a different board (the Cubieboard 2). For a low power 32-bit ARM CPU, it's pretty nice since it has (slowish) SATA and real Ethernet. The SOC can be used with 100% free software unless you actually need to use the MALI GPU. The thing with ARM is that the GPU does less than on Intel-compatible systems, so you can still use a display with it
<lfam>I generally trust Olimex to make reliable systems, since most of their business is to industrial customers
<efraim>If you're going to compile on it you might want the one with emmc or nand for swap
<efraim>Their A64 with the 2GB of RAM is the board in their laptop I think