<tune>I can't tell you the specifics, I don't really use it myself, but it allows editing via command instead of an interactive thing, so you should be able to do something like trim a specific pattern from many files with it
<rekado>mbakke: on core-updates e2fsprogs fails one of its tests (d_loaddump).
<rekado>the test failure is due to a difference in reported blocks
<rekado>d_loaddump.failed shows that it expected a message containing “158/512 blocks” but only saw “156/512 blocks”.
<rekado>looks like this very same failure also exists in the freebsd port; they say “This looks like a very unusual failure and careful investigation into lld’s behaviour is warranted, but for now set LLD_UNSAFE to fall back to ld.bfd so the port continues to build for users using the lld as /usr/bin/ld.”
<rekado>I don’t think this applies to us, but maybe there’s something odd going on with our linker.
<rekado>shouldn’t we upgrade to 1.44.3 (July 10)? We are at 1.43.6 (from August 2017).
<ngz>What version of libstdc++ Guix is using with gnu build system? Can I assume it is the same as gcc (5.5.0 at this time), or is it another version?
<ngz>I didn't find how to check libstdc++ version from, e.g., guix environment.
<pkill9>does anyone know what might cause this error?: Failed to contact configuration server; the most common cause is a missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org/gconf/ for information. (Details - 1: GetIOR failed: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.GConf was not provided by any .service files)
<pkill9>from searching around, adding `gconf` as a propagated input is supposed to fix it, but it doesn't
<lfam>mbakke: Epiphany's RUNPATH is incorrect on staging, probably due to that meson-build-system change. The RUNPATH should include '/gnu/store/...-epiphany-184.108.40.206/lib/epiphany' but it's missing the final path component
<lfam>mbakke: I can workaround that issue by passing extra_link_args to the epiphany build