hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has joined #nix-darwin
erickomoto has joined #nix-darwin
erickomoto has quit [Client Quit]
<pikajude>
oh no
erickomoto has joined #nix-darwin
erickomoto has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hamishmack has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexteves has quit [Remote host closed the connection]
erickomoto has joined #nix-darwin
erickomoto has quit [Client Quit]
thebloggu has joined #nix-darwin
thebloggu has quit [Ping timeout: 252 seconds]
jtojnar has joined #nix-darwin
alexteves has joined #nix-darwin
<LnL>
hmm, this is the second time nix segfaulted on the 10.14 beta
<dhess>
:(
<LnL>
it is the one I built a while back, so it wasn't built with my extra changes
<LnL>
I've also been wondering if we actually need to expose the libraries Libsystem links against
<LnL>
currently we -reexport_library a fixed set of system dylibs that is linked by every os version
<dhess>
I really have no idea how the darwin stdenv works :|
<LnL>
so, libBystem.B.dylib is an umbrella library that exposes a bunch of libraries including unfree stuff we can't package
<dhess>
right
<LnL>
our Libsystem package is a fake library that does something similar but only exposes the set of symbols that are available on all macOS versions we support
<LnL>
that way builds don't detect eg. new features and generate binaries that wouldn't work on older versions
<dhess>
How do other open source projects that release binaries get away with this?
<LnL>
they link against Libsystem directly and get bug reports if apple changes stuff?
<LnL>
:p
<LnL>
there's MMACOSX_DEPLOYMENT_TARGET that works for some probjects if you want to build, eg. a 10.10 compatible binary on 10.13
<LnL>
I don't know how homebrew does this for bottles, but I suspect they just build using hosts that run the oldest supported version
<LnL>
anyway, to finish my story, we do the same for the list of libraries that libSystem links against
<LnL>
but I think we shouldn't care, it shouldn't matter if apple removes or renames system libraries, libSystem knows where to find the symbols
<LnL>
copumpkin: ^
disasm has quit [Quit: WeeChat 2.0]
<dhess>
LnL: Nixpkgs gets bug reports with the current system, too. Maybe I'm missing something, but given that the current system is a lot of work to maintain and has bugs anyway, would it be less work overall just to link against libBsystem.B.dylib (or whatver the appropriate Apple-provided library is)?
<dhess>
or would that break reproducible/cachable builds?
<LnL>
yes, the cache would become useless if you're not using the same os version
<dhess>
yeah ok, that's the best reason not to do it, then.
<dhess>
on the other hand, how often does libBsystem.B.dylib change? Is it with every point release, or just major versions (Sierra, High Sierra, etc.)?
<LnL>
no only major releases, and not necesseraly every major release
<LnL>
and if what I'm thinking of works it's only the list of symbols which might not matter for most packages
<dhess>
well then another alternative is to run builders for the last N major releases (or anyway, each version of libBsystem.B.dylib). It would mean Nx more build products in the cache and 1/N as many builders per release, but maybe that's the right tradeoff vs. developer time.
<LnL>
yeah, we'd have to differentiate packages by os version with eg. platform = "x86_64-darwin1770" which isn't great
<dhess>
I can see the need for that for very specific packages, but why couldn't you use a catch-all "x86_64-darwin" that was a "don't-care" for most packages?
<LnL>
and anything outside of nixpkgs would also require much more infrastructure
<dhess>
oh I see, I guess Hydra would need to know the difference, for one.
<dhess>
ok
<dhess>
or would it? Wouldn't they just evaluate to different hashes?
<dhess>
for the same platform name?
<LnL>
no, the inputs are the same
<LnL>
unless you pass in the os version somehow, but that's essentially what builtins.currentSystem does
alexteves has quit [Ping timeout: 240 seconds]
alexteves has joined #nix-darwin
<dhess>
oh it wouldn't consider libBsystem.B.dylib part of the hash?
<dhess>
if not, shouldn't/couldn't it?
<LnL>
it's impure, we can't build it from source or redistribute it
<LnL>
same with frameworks
<dhess>
ahh ok, I see
<dhess>
re: redistribution, though, other open source projects that distribute binaries get away with this how? I assume because it's not part of the binary blob they distribute and is only linked at runtime?
<LnL>
for example a framework package is just a symlink to the system location
<LnL>
yeah only linked, the fact that stuff changes is less of a problem at runtime
<dhess>
ok so is there no way in Nix to say, "This external package is a dependency, and I want you to calculate its hash and make it part of the output hash, but I don't want you to include it in the output closure" ?
<LnL>
if apple chages something major there then _everything_ will be broken, not just nix stuff
<LnL>
you'd need to do that at evaluation time
<dhess>
so if you could do that, then you could build against different libBsystem dylibs, make sure the different versions are in the output hash, and then the platform name could be the same, no? They'd just have different nix store locations.
<dhess>
without including the libBsystem dylib in the closure and therefore not redistributing it.
<LnL>
yeah, that would work but you still end up having to build caches for each release (and potentially even more)
<dhess>
yes... but at least now we
<dhess>
we're back to just a hardware resources issue
<dhess>
If I were a Nixpkgs darwin maintainer, I'd be giving that a serious think ;)
<dhess>
not up to just the nixpkgs darwin maintainers of course! But I might advocate for it.
<LnL>
well, how do I deal with that for stuff I make outside of nixpkgs?
<dhess>
and you could also of course just be "mean" and say, "Sorry, due to resource limitations, we only provide binary caches for the latest version of macOS. We still support older versions, we just don't give you prebuilt binaries."
<dhess>
like nix-darwin you mean?
<LnL>
either I have to convince everybody at work to run the exact same version or convince my manager buying 5 mac minis is reasonable
<dhess>
oh I see what you mean.
<dhess>
I mean, again, I think this is a tradeoff of "buy 5 mac minis" or "require me to spend N hours a month fixing darwin builds."
<dhess>
If I were your manager, I know which one I'd pick.
<dhess>
but I am not, so... :)
<LnL>
sure, that's true
<dhess>
I understand this is out of your hands though and for whatever reason your manager (and others') might not see it this way.
<dhess>
shit, did nixos-unstable advance without that hpack fix?
<dhess>
ughhhhhhhhhhhhhh
<dhess>
oh my god it missed by 2 commits
<LnL>
anyway, while your idea would probably work I don't think this specifically is a big problem