<piyo>"Early versions of GNU Emacs were numbered as "1.x.x," with the initial digit denoting the version of the C core. The "1" was dropped after version 1.12 as it was thought that the major number would never change, and thus the major version skipped from "1" to "13". A new third version number was added to represent changes made by user sites."
<piyo>i dont know openssl, but it sounds like yet another oddball
<rekado>I wonder if we should provide an internal wrapper around the "jar" tool to make sure that "jar" archives are reproducible (i.e. without timestamps).
<rekado>or we could patch fastjar (already found the lines that need patching) and use that instead of the JDK's jar tool. We'd then have to make sure that when jar archives are built we use the patched fastjar instead of the JDK's jar tool.
<rekado>oh, there is no icedtea9 because there's no jdk9. Oops.
<rgrau>Every 'guix pull' takes forever, no matter how long I did the last 'guix pull' before. Isn't it supposed to just download latest guix (with new recipes) and update what's to update? . It seems it's recompiling everything every time. (bout 500 files every time)
<rgrau>ah, it may be compiling the recipies... still. kinda slow
<rgrau>regarding how fundamentally different it is 'apt-get update' from getting latest versions of gnu/packages/*.scm, is there anywhere where I can find docs on the internals of guix? I'm missing some parts there
<sneek>civodul, lfam says: I remember you sharing a link that describes Nix's analogue of `guix graph`. I seem to remember it involved scraping the recipes. I just can't find the message now. Do you remember the link?
<sneek>civodul, fps says: do you remember the guile but report about too strict parsing of headers (re ETAG)
<mark_weaver>civodul: I fixed the 'fuse' source URI in 826244f01a, which is included in evaluation 108602 on hydra, but that evaluation still uses the old derivation /gnu/store/kvq9rcc4a0dn5bcigyklzzakfmjwyf85-fuse-2.9.4.tar.gz.drv which includes the incorrect source URI, so all the builds that depend on 'fuse' are still failing even when I explicitly restart them. any idea how to fix this?
<mark_weaver>civodul: I try to avoid using "restart dependency-failed builds" when the number of builds to restart is manageable, because it restarts a lot of builds that are almost certain to fail again anyway.
<mark_weaver>civodul: does the filename of a fixed-output derivation depend on the builder, or only the resulting output hash?
<mark_weaver>if the *.drv filename depends only on the output hash, that seems to me to be a design flaw
<mark_weaver>actually, I take that back. I guess that's the way it has to be, so it's not a design flaw.
<civodul>mark_weaver: the .drv file name depends on everything, as with other .drvs