<lfam>ZombieChicken: Ah, then it sounds like you got a cache miss. The mirror is fetching the file from hydra.gnu.org. Once the mirror has the file, it will be fast for every other user. Thanks for your patience :)
<lfam>davexunit: I think we should have substitutes for automake.
<ZombieChicken>guix gc: error: build failed: getting attributes of path '/some/long/path/in/store': No such file or directory
<ZombieChicken>specifically it's refering to an icecat CVE patch that apparently no longer exist
<Apteryx>Would I have more luck at finding substitutes if I stuck to an older linux-libre version? Say, firstname.lastname@example.org instead of latest? My system is slow and rebuilding the kernel regularly is a drag for productivity.
<ZombieChicken>Apteryx: I can't comment on most of that, but I can suggest trying to run everything through nice and ionice, which might help with it bogging down your system. At least, that works on Gentoo...
<Apteryx>rekado: Interesting. I've never really read dig about how apropos works but that would suggest that it needs a database that we aren't generating.
<Apteryx>Could it be that it cannot search through compressed manpages?
<efraim>ryanwatkins: how so can you not install it? guile-ssh is an optional dependancy, but I believe it is like some other packages we have that can fail its tests on slower machines
<efraim>I had to build it 2 or 3 times on my aarch64 board before it passed the tests
<ryanwatkins>efraim: under yaourt and trying to install it from the AUR it is failing on my raspberry pi 3 model b board, should I clone it down and try to install seperately?
<efraim>ryanwatkins: I don't know, I used the binary install method from the manual each time I installed it
<roelj>So, when I run: export R_LIBS_SITE=""; guix environment --pure --ad-hoc r; echo $R_LIBS_SITE; It displays the site-library path of my profile. Does this mean `guix environment' looks for the environment variables, and then uses the values from the user's default profile?
<roelj>When I add --search-paths to the `guix environment' command, it returns different profile directories..
<fps>hmm, i wonder.. i just did a quick experiment: modified the hello packages to be called "helo" and then guix built two variants: the original helo and one where i duplicated the gawk input
<fps>this resulted in two different store items, which is what i kind of expected. inspecting the resulting binaries showed that the only difference is in a reference to the lib/ folder in the output..
<fps>so i wonder: is it generally possible to decouple this? i.e. sure, the package recipe changed, but the resulting store paths aside the resulting binaries are identical
<fps>could another layer of indirection be introduced? such that there's a store item holding the binary is shared between the two but linked to two different store places to reflect the different derivations?
<fps>i suppose it is obvious what i'm thinking about here. let's say package A depends on B. B changes, triggering a rebuild of A. Since the ABI of B didn't change, A is bit identical except for store paths..
<fps>ok, if there are two identical packages with just different names, then they get stored into two locations in the store, while they are really bit identical except for references to (in the case of hello) the lib/ directory in the store
<thomasd>fps: often, absolute references to the package location are also encoded in the files (things like runtime paths)
<fps>thomasd: yeah, that's the part i wonder about if there's a way around it..
<fps>the question if there's a way to canonicalize the part of the build that's different, so that the same build can be used for both packages, even though it's just found out after-the-fact. i.e. build those packages, their common core gets put in a store item who's key is just a result of the binary pattern of the output, then to instantiate the two store items that do depend on the output path, the references of
<thomasd>fps: I don't think I'm following. If you build the package twice anyway, what is the use? :)
<fps>that's just a contrived example, where packages differing on the surface still result in the same binary if canonicalized
<thomasd>You could split out a common “core” into a third package, and then defining a new build for the two packages that takes the common core and grafts it to generate a specialized version.
<fps>now let's take a package depending on another package as the second example.. the dependency changes, but leaving all "cosmetics" aside the binary of the dependee would still be bit identical (as the ABI of the dependency didn't change)
<fps>grafts make use of an invariant in the dependee which i hope to leverage automatically
<Apteryx>I think the man-db index should be located at /run/current-system/profile/share/man/index.db. "man" attempts to read this but falls back to recurse all the manpaths instead.
<fps>thomasd: here's the thing: if the dependency changes, but its output path didn't and the ABI is not changed, then the dependees binary would be bit identical
<fps>[assuming its output path didn't change either]
<fps>i'm arguing that the package inputs' hash and the output store location are useful information, but in a sense orthogonal and too strict thereby ruling out some optimizations like automatic "grafting"
<fps>thomasd: and yes, automatically grafting the two output packages for the first example is along the lines of my thinking..
<thomasd>fps: it would require more complex handling of inputs.
<fps>thomasd: there would be another layer of indirection. i.e. a "concrete" package in the store has links to its binary adressed "core". for the final output hash computation the concrete package's path is used, but for the binary build the resolved links to the core would be used
<adfeno>During my work on packaging Ring, I tried building it, but the "libring" package is failing to build: make enters "src/client", builds things up to configurationmanager.cpp, but when it reaches it, fails saying: src/security/certstore.h:77:73: error: ‘RevocationList’ is not a member of ‘dht::crypto’
<thomasd>fps: you'd need to somehow distinguish ABI-breaking updates from ABI-compatible updates.
<thomasd>fps: I think the issue is that Guix needs to be able to predict the build dependencies in advance. Which is not possible anymore if you need to build a package first to see if it's ABI-compatible with the previous version.... Maybe I misunderstand, maybe I should draw some diagrams :-)
<fps>thomasd: i'm strictly talking about discovering the invariance the dependee after the fact. i.e. if A depends on B, B changes, but leaves A unchanged, then this could be discovered after the build of A after B changes..
<ZombieChicken>Okay, so apparently irssi in abduco in dvtm in abduco does /not/ play nicely. Plus my email is seeming a bit wonky.
<efraim>Looks like I will have to fix mozjs17, its needed by polkit
<thomassgn>I try to setup connman-service in my guixsd config, but keep getting 'Unbound variable: connman-service' though I have already 'use-service-module networking'. The connman service is in defined in /gnu/services/networking.scm...
<slyfox>i'm not vehemently against it. just not used to. in my eves linux kernel has a good culture for commit messages. wondering what value guix gets ChangeLog format
<thomassgn>don't think I'm doing this the right way, '(define tms-desktop-services (remove (lambda (service) (eq? (service-kind service) wicd-service)) %desktop-services))' and then use tms-desktop-services in the modify-services later. Still tells me there's more than one networking service provided. Could I run a REPL on the config somehow?
<lfam>We try to explain things that aren't obvious in code comments, whereas Linux favors putting the explanation in the commit message (or in both places). We could do a better job of commenting
<slyfox>but otherwise commit messages are not processed by any tool afterwards, right? or do they? (to produce a release notes or something like that)
<rekado>thomassgn: don’t use “wicd-service” but use the type
<rekado>thomassgn: you can try this in the REPL, actually
<rekado>and then take a look at the value of tms-desktop-services
<rekado>you are comparing the result of “(service-kind service)” with an actual service object