<orivej>
Sonarpulse: sounds ok. In the contexts where stdenv.cc.prefix may clash with a local variable "prefex", it seems better to call the former "targetPrefix" rather then "binPrefix". On the other hand, couldn't you just "inherit cc" to use "cc.prefix" to avoid the clashes?
<Sonarpulse>
orivej: the issue was making prefix a env var
<Sonarpulse>
that hits the prefix bash variable
<Sonarpulse>
in nix there is no conflict, but other packages do use prefix in the normal way
<Sonarpulse>
as to binPrefix vs targetPrefix, I'm fine with either
<Sonarpulse>
I went with "bin" because it could be an arbitrary string
<Sonarpulse>
doesn't matter as long as its used consistently
<Sonarpulse>
also, we don't prefix (yet!) in the native case
<orivej>
Why does the cc.prefix has to be an env var?
<Sonarpulse>
but it isn't like there's *no* target platform in the native case
<Sonarpulse>
orivej: I use it in the setup script for binutils
<Sonarpulse>
and the normal prefix is an env var for `install`
<orivej>
If the use is so limited, why not provide cc.prefix under a different name for binutils? Do you expect this var to be needed in other derivations?
<Sonarpulse>
orivej: this prefix?
<Sonarpulse>
yes
<Sonarpulse>
other compiles (especially GHC in some commits I ahve) will also have a binPrefix
<Sonarpulse>
so I suspect both will be standard across distributions
<Sonarpulse>
orivej: any final thoughts? hoping to go to sleep in a second :)
<Sonarpulse>
I figure this at least makes things unambiguous for a future find+replace
<orivej>
ok then. targetPrefix sounds better as it conveys the idea that it contains the target triplet. spell checking the commit message will do future readers a favor :)
<orivej>
the places where it depends on "hostPlatform != buildPlatform" look suspicious since they do not depend on the target platform, but maybe they are correct; and this does affect your PR
<orivej>
err, does not affect the PR
<Sonarpulse>
orivej: I'll check those
<Sonarpulse>
n.b. targetPrefix would be a mass rebuild, but happy to do
<Sonarpulse>
next one is too, anyways
<Sonarpulse>
so whatever
<Sonarpulse>
orivej: ah, that is because it is from the perspective of the build-time comsumer of the compiler
<orivej>
right
<Sonarpulse>
orivej: ok rebased with targetPlatform and spellcheck
<Sonarpulse>
orivej: thanks!
FRidh has joined joined #nixos-dev
<orivej>
Sonarpulse: oops, pkgs/build-support/cc-wrapper/default.nix actually needs binPrefix in for `substitute`
<Sonarpulse>
orivej: I did a treewide find and replace
<Sonarpulse>
so I think good?
<Sonarpulse>
maybe i forgot
<orivej>
see pkgs/build-support/cc-wrapper/setup-hook.sh
<Sonarpulse>
orivej: oh hmm i guess my find replace wasn't as good I as I thought :(
<orivej>
I can fix this if you want to
<Sonarpulse>
orivej: i got it
<Sonarpulse>
i found old binutils-wrapper file hanging around
<Sonarpulse>
pre revert in august!
<Sonarpulse>
I'll fix both
<orivej>
see also pkgs/build-support/cc-wrapper/macos-sierra-reexport-hack.bash and pkgs/build-support/binutils-wrapper/macos-sierra-reexport-hack.bash
<orivej>
the latter should probably be deleted, but note that they are a little different
<orivej>
(ah, it is the one that from the pre revert)
<Sonarpulse>
orivej: yeah i rewote the whole thing on stable
<Sonarpulse>
(need to forward part, have a PR open fo 17.09)
<Sonarpulse>
so not too worried about little differences between old versions
goibhniu has joined joined #nixos-dev
phreedom has quit [(Ping timeout: 240 seconds)]
phreedom has joined joined #nixos-dev
<domenkozar>
peti: btw, any reason we are using hackage-db instead of hackage-security?
<peti>
domenkozar: We were using hackage-db since long before hackage-security existed and no-one ported the code.
<domenkozar>
peti: ok, I'm going to do some digging
<domenkozar>
cabal2nix takes ~0s on local cabal file
<domenkozar>
but ~2s on cabal file from hackage index
<domenkozar>
since I have a package set of 300, this yields a huge difference
Mic92 has joined joined #nixos-dev
<Profpatsch>
> nix-instantiate -A postgresql.man ~/nixpkgs
<gchristensen>
"error: build of ‘/nix/store/ib44vpxk9fifbb968i4smas4gwsv8srm-powerdns-4.0.5.drv’ failed" weird
<Profpatsch>
adisbladis: ikr
<pstn>
I'm trying to bump linux-testing to 4.15-rc1 in nixos but get the error "/tmp/nix-build-linux-4.15-rc1.drv-0/linux-4.15-rc1/Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel". Stop." What should I do add the dependency or disable the option?
<pstn>
It seems to be a debugging tool but I'm not familiar with it.
<Dezgeg>
add libelf probably
vcunat has joined joined #nixos-dev
<vcunat>
wouldn't it be better to utilize nix-index
<vcunat>
?
<vcunat>
(so you don't have to type the attribute name)
<pstn>
vcunat: Is this comment directed at me?
<vcunat>
no
<vcunat>
that for the "nman" tool
<pstn>
Alright. I was a bit confused what I should do with nix-index anyway :-)
<vcunat>
(I lost an hour or two of history)
ckauhaus has quit [(Quit: Leaving.)]
taktoa has quit [(Remote host closed the connection)]
orivej has joined joined #nixos-dev
<samueldr>
pstn: can you ping me when you have 4.15 building? yes libelf will add the missing elfutils stuff, but the build fails around `AR drivers/built-in.o` for me
<samueldr>
possibly I'm missing an earlier error message in the log, from parallel build, or that there is no error message
<gchristensen>
I think I'd like to rename grahamcofborg now that it is sort of a thing, it feels a bit awkward to talk about it :$
_ris has joined joined #nixos-dev
<gchristensen>
if anyone has recommendations, I'd love to hear them :P
michaelpj has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
michaelpj has joined joined #nixos-dev
<LnL>
why not keep it? :)
<gchristensen>
well I picked grahamcofborg when it wasn't anything but a hack, and now it feels self-centered :P
<vcunat>
I'm not sure if that matters at all
<vcunat>
most of us use Linux anyway
<gchristensen>
LOL
<gchristensen>
it'd be fun to pick a cute name like Bors
<pstn>
samueldr: Do you have your stuff pushed somwhere? I'd like to have a look at how you added it.
<samueldr>
it's not a clean thing, it's in an overlay for a kernel fork, with cherrytrail support, but I did test using an upstream revision, ensuring the issue happened there too
<pstn>
Ah, alright
_ris has quit [(Remote host closed the connection)]
<vcunat>
But probably not large enough to be called moons anymore.
<domenkozar>
should have picked saturn, we'd never run out of projects
<domenkozar>
it has 62 moons
<gchristensen>
a friend suggests something around "leafcutter": "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth."
<vcunat>
(Our Nix started before the moon of the same name was dicovered.)
<vcunat>
pstn: yes, nix will order that even after 4.15
<MichaelRaskin>
domenkozar: as someone who have chosen Saturn for the same reason (for local-scope names), I would advise against Saturn for global names.
<vcunat>
:-)
<domenkozar>
that's why we picked pluto? :D
<MichaelRaskin>
And ran out of names immediately.
<vcunat>
MichaelRaskin: what was wrong with Saturn's moons.
<MichaelRaskin>
vcunat: nothing for local scope.
<vcunat>
and for global one?
<gchristensen>
I assume they're all taken
<MichaelRaskin>
vcunat: doesn't every one has a VM called tethys somewhere?
<vcunat>
I don't.
<vcunat>
So now you use hashes, like for your GitHub username?
<vcunat>
Going (pseudo)random is probably the best way of avoiding collisions on global uncoordinated scope.
<gchristensen>
for people really in to FP, is there some sort of combinator that could describe merging PRs?
<MichaelRaskin>
vcunat: well, when I needed a name, it turned out I can pick two words that make sense in context and are not well-known together.
<MichaelRaskin>
gchristensen: have you read approximately entire design documentation of Darcs?
<MichaelRaskin>
(I guess Pijul is fine, too)
<vcunat>
heh, thought of Darcs as well :-)
<gchristensen>
hahaha no I haven't, but I'm thinking maybe some FP-ey term might be a cute name
<vcunat>
but it doesn't do a real merge
<vcunat>
more like a rebase
<vcunat>
(IIRC)
<MichaelRaskin>
There is no such thing as a real merge.
<vcunat>
I don't expect Pijul changed that, but I don't know.
<vcunat>
I'd hope for non-linear history at least.
<MichaelRaskin>
That exists even in SVN
<vcunat>
(Not sure what "real merge" should mean anyway.)
<gchristensen>
@prcombinator
infinisil has quit [(Quit: ZNC 1.6.5 - http://znc.in)]
<MichaelRaskin>
vcunat: history is one thing; calculating a state combining the changes from some operations is a different thing.