IRC channel logs


back to list of logs

<tadni>Anyone up?
<phant0mas>good morning guix
<jmd>Hmm. guix build has just told me it intends to build about 28 different versions of bash.
<mark_weaver>jmd: those are the patches
<jmd>Now why has it suddenly decided to download bootstrap-binaries? Have they changed recently?
<mark_weaver>jmd: if you've been using substitutes, you usually don't need them. are you building something now that's used in the early bootstrap?
<jmd>mark_weaver: Well I'm cross-building gcc
<jmd>Right now, its building gcc-cross-boot0-4.8.3 - I cannot imagine why.
<jmd>This is wierd. There is *nothing* in gnu/packages/*.scm which depends on bison-2 yet guix has decided it must be built. What's going on?
<mark_weaver>jmd: our flex package includes an embedded bison 2 package within
<mark_weaver>used for tests
<mark_weaver>(see "bison-for-tests" in flex.scm)
<jmd>Oh. Why does it use that, and not the bison-2.7 from bison.scm ?
<bavier>our doc/guix.texi now depends on texinfo >= 5.0
<bavier>I don't think that was intentional, and our configure should probably check for it
<mark_weaver>jmd: presumably to break the circular dependency. bison-2.7 has flex as an input.
<jmd>Oh right.
<jmd>I'm not sure what cloog is, but from what I infer from the description field, it doesn't really belong in gcc.scm
<bavier>jmd: I think gcc uses is for loop analysis
<jmd>All the same, I think it would more rightly belong in math.scm
<bavier>that would seem to me a valid argument
<jmd>On the other hand, I think there are lots of packages which have definitions in odd files.
<bavier>we've not established a rigorous algorithm for the package/source-file relationship
<jmd>bavier: I noticed.
<civodul>my experience with Nixpkgs is that establishing a categorization algorithm doesn't work well
<civodul>whereas spontaneous mess does work
<bavier>civodul: ;)
<civodul>damn, erc-smiley-mode appears to be broken in 24.4
<civodul>alezost: any idea? :-) ↑
<jmd>civodul: That's a relief. I'm good at creating spontaneous messes.
<jmd>Talking of which, I wish there was a way that guix could infer the dependees of gcc on a per target basis.
<civodul>i'm not sure what you mean
<civodul>it's already possible to walk the package DAG, notably with package-dependents
<jmd>civodul: But if I change gcc-configure-flags-for-triplet then *everything* gets rebuilt, even if the triplet affected is not involved in the build.
<alezost>civodul: I don't use it, but I've just tried and it works for me (I'm on 24.4 currently)
<alezost>civodul: the problem might be that you don't have smiley loaded: check (featurep 'smiley)
<civodul>sneek: later tell jmd unless gcc-configure-flags-for-triplet is changed in a way that doesn't affect the other systems
<sneek>Got it.
<civodul>alezost: t
<alezost>I see that smile :-) Is erc-smiley-mode turned on for you now?
<alezost>civodul: I don't know then. The last thing to try is "M-x erc-smiley-mode" a couple of times
<civodul>yeah, i tried that :-/