<johnw>
copumpkin: you guys want me to build something against my package set here?
<copumpkin>
the change is in staging if you want to try it out :)
<johnw>
ok, let me give it a shot
<copumpkin>
thanks :)
<johnw>
building now
copumpkin has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sphalerite has quit [Ping timeout: 252 seconds]
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
copumpkin has joined #nix-darwin
copumpkin has quit [Ping timeout: 245 seconds]
hamishmack has joined #nix-darwin
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
<LnL>
hmm, good idea
<LnL>
I'll switch both my machines and use it for a week, if there's any runtime weirdness I'll hopefully notice
copumpkin has joined #nix-darwin
ben has joined #nix-darwin
<copumpkin>
LnL: I'm thinking that LTO thing is fairly low-risk so I'll probably merge it soon
<LnL>
sure
<LnL>
only thing I can think of is builds that start using it automatically but don't work properly with it
<copumpkin>
I'm actually kind of confused about our ld wrapper now :)
<copumpkin>
because it somehow hides the fact that ld supports
<copumpkin>
normally if you just build cctools and ask for ld in it, it tells you LTO support is enabled
<LnL>
I had a quick look yesterday and didn't see that looked off
<copumpkin>
but if you use the ld in the stdenv, with the wrapper, the message about it supporting LTO is gone
<LnL>
oh hmm weird
<copumpkin>
even though with my simple test, LTO still worked
<copumpkin>
so we must do something weird to the `ld -v` output?
<copumpkin>
I couldn't be bothered to look more carefully
<LnL>
you can see what the wrapper does with NIX_DEBUG=1
<LnL>
but my understanding of binutils/ld is pretty fuzzy
<copumpkin>
yup
<copumpkin>
not a big deal
<copumpkin>
I'm just going to try patching qt not to need the missing CF symbol
<copumpkin>
it uses it in stupid places anyway
<copumpkin>
that way we can keep ancient qt4 for another decade :P
<copumpkin>
I want to kill support for it but it seems like everything still depends on it
periklis has joined #nix-darwin
periklis has quit [Remote host closed the connection]
<LnL>
vim did until recently
periklis has joined #nix-darwin
symphorien has joined #nix-darwin
<copumpkin>
fun
<symphorien>
hello. I am developping nix-du on linux, and when travis builds it on darwin (with nix) I get "ld: framework not found Security" for some rust dependency.
<symphorien>
is it caused by nix or something else ?
periklis has quit [Remote host closed the connection]
<LnL>
maybe those should be in a separate constituent job tho
<copumpkin>
so do we just fail the build of a test if it fails?
<copumpkin>
can I just say that a test should be run on all platforms? we seem to be listing out the same stuff on all of them
symphorien has left #nix-darwin ["WeeChat 2.1"]
<LnL>
they don't run on all platforms?
<copumpkin>
maybe they do, I just saw them listed out
<copumpkin>
in the release.nix so assumed they didn't
matthewbauer has joined #nix-darwin
<copumpkin>
hi matthewbauer!
<matthewbauer>
hey! sorry about the patch-shebangs issue
<copumpkin>
no problem
<matthewbauer>
we wanted to do this for some cross stuff but didn't realize it could effect other stuff so much
<copumpkin>
I don't feel too strongly about which solution :) I'm mostly just trying to fix qt4 which I broke but I can't even get there because texlive is out of commission
<copumpkin>
yeah makes sense
<matthewbauer>
yeah. is the parallel thing still an issue? most of the issues should just be moving nativeBuildInputs -> buildInputs
<{^_^}>
#46476 (by dtzWill, 6 days ago, open): parallel: cleanup
<matthewbauer>
this is all still in staging right?
<copumpkin>
yup staging
<copumpkin>
oh parallel hasn't hindered me
<copumpkin>
this is texlive
<copumpkin>
or rather, just build qt4 on staging
<copumpkin>
it'll fail this way
<copumpkin>
on darwin
<copumpkin>
it'll complain that the Makefile has a syntax error in it
<matthewbauer>
ok. since bash is already part of the stdenv, it should be possible to add it as a defaultBuildInput, right? it's already a defaultNativeBuildInput i think
<copumpkin>
the shell?
<copumpkin>
sure, that seems fine to me
<copumpkin>
anyway, anything you can do to unblock me is welcome :)
<LnL>
defaultBuildInput?
<copumpkin>
but also see the latest comment I left on that PR
<copumpkin>
"strictness by not patchShebangs-ing something" doesn't seem desirable
<copumpkin>
anyway, need to go do some stuff, will take a look at the qt4 thing when I get back if someone fixes this in the meantime :)
<copumpkin>
I think I have a sensible patch for it if I can get past texlive
<LnL>
nice
<LnL>
hopefully I have enough cached by tomorrow so I can switch my system to it for a bit
<dhess>
Anyone upgraded to the Mojave GM?
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<copumpkin>
matthewbauer: what confuses me is that bash is in the common-path
<matthewbauer>
yeah it goes in initialPath, which is added to PATH but not HOST_PATH
<copumpkin>
so is that the thing to fix rather than adding [shell]+buildInputs?
<matthewbauer>
The issue is those are all for the builder not the cross system
<matthewbauer>
besides bash is the only thing that should be referenced from there
<matthewbauer>
i guess it's possible someone uses coreutils/gnused/gawk but hopefully we can just have those list that in the derivation. but i don't - it might be easiest to make it backwards compatible?
<copumpkin>
yeah, I don't know enough about all this cross stuff to know which of your commits is a better fix :) will just wait for ericson to weigh in
<copumpkin>
I've worked around it locally by just hacking up the shebang in my mutable store :D
<copumpkin>
so am back to fixing qt4 :D
<copumpkin>
anyone notice that SDL2 somehow builds llvm 3.9, then llvm 6, then actually SDL2 on darwin, despite having llvm 5 in the stdenv 🤔
<johnw>
copumpkin: hi
<johnw>
copumpkin: so, there was a failure building latest staging
<johnw>
gcc-7.3.0 said "unsupported option -static-libgcc'
<johnw>
that is, the gcc-7.3.0 derivation build
<copumpkin>
that seems unlikely to be my fault
<johnw>
it's clang-5.0 reporting the error
<copumpkin>
lots of stuff is broken in staging right now it seems
<johnw>
well, 466 built, which is good
<copumpkin>
cool :)
<copumpkin>
maybe report the issue and see if anyone knows what's up
<johnw>
well, one big question is why anything is building gcc-7.3.0 on darwin
<johnw>
it appears to be a ghc-8.2.1-binary dependency
<copumpkin>
yeah, that seems wrong
<copumpkin>
linux folks love to stuff gcc into their buildInputs when it's not needed
<copumpkin>
not sure if that's the case here
<johnw>
yep, I've noticed that
<copumpkin>
of course qt4 "vendors" all of an ancient version of webkit in its source tree, meaning I have to patch stupid webkit crap that upstream fixed a million years ago
<copumpkin>
johnw: surprised you didn't encounter any qt4 woes :)