<jmd>I would be grateful if you could post a message to guix-devel about this, including that tune2fs output. Because I think that the default mke2fs options are not suitable for what we put in /gnu/store
<rekado>I’m a little unsure about building the binaries for arm and mips; as I don’t have SSH access to hydra we’d have to coordinate this somehow.
<Apteryx>jmd: OK, I'll make a couple tests (1. simply reboot to see if the inodes issues resolves 2. run fsck from a live usb) and then send a post about it to guix-devel.
<roptat_>I'm trying to use haunt on guisd, but the example here (https://haunt.dthompson.us/) does not build. I get ERROR: no code for module (system reader). Since the news website is run by haunt, I guess some of you may know how to use it properly?
<rekado>you may need to install guile into your profile or set GUILE_LOAD_PATH
<rekado>the haunt package propagates the guile-reader package, so this error tells you that Guile just doesn’t know how to find it.
<lfam>We should identify packages that we know are affected and decide if we can update them to use GCC 5 sooner, on a staging branch
<Apteryx>Yes, this sounds like it would be useful in the meantime.
<lfam>Apteryx: Some of the affected packages will require a huge number of rebuilds themselves. It depends on the capacity of our build infrastructure. I think we can probably do more building. There are times when the farm is underutilized.
<lfam>But, there are other limitations, such as disk space
<Apteryx>By the way, it'll be the first time I attempt to run 'guix gc' after I've started using Guix directly from its git checkout. Do I need to run "guix gc" from a "guix environment guix" to make sure it doesn't garbage collect itself?
<Apteryx>I've got both my root and user guix pointing to the git checkout.
<lfam>If the Guix you want to preserve is in a user profile, then you should be good. You can inspect /var/guix/gcroots to see exactly what is protected from the garbage collector
<Apteryx>lfam: I understand. I'm using lots of space just with my small selection of installed packages, the whole collection must use quite a large amount of storage!
<lfam>The Guix you built from Git is not in /gnu/store, btw. It's wherever you built it
<lfam>So, it shouldn't be affected by the garbage collector at all, IIUC
<Apteryx>OK. This gives me some confidence, thanks.
<Apteryx>The only cryptsetup occurence is in the error thrown, even when looking at the strace.
<Apteryx>I'll paste the strace somewhere for you to see, it's quite cryptic.
<taylan>all of leptonica 1.73's tests fail with tons of errors saying stream couldn't be opened, (later) file not found, etc. it seems the programs in the test suite have difficulty writing to the filesystem. some directories and files do get successfully created by the test suite programs though. what may be causing most of them to fail in creating / writing to files in the build environment?
<taylan>I built leptonica and ran its tests in a guix environment container and they didn't have the problem there
<taylan>(hmm, removing the changes to the "which gnuplot" calls was also wrong I suppose, as 'which' isn't in the build environment? changing them to the literal output of 'which gnuplot' seemed wrong too though; I guess best to change them to "true")
<taylan>civodul: quick Q: is there a way to get a faithful replica of the build environment the daemon would create to build a package, for messing around in it interactively? sometimes I have an issue that happens in that environment but not in e.g. 'guix environment -C --pure foo'
<civodul>roptat_: oh indeed, that's a bug: 'haunt' should close over guile-reader