sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
<ekleog> matthewbauer: … we don't support canadian cross? I thought we did, with the index-based mechanics described in the nixpkgs docs
<matthewbauer> maybe ericson2314 can explain, but I don't think it will ever do canadian cross
<matthewbauer> instead it would do two cross compilation rounds if you tried to chain pkgsCross for instance
<matthewbauer> @erics
justanotheruser has joined #nixos-dev
<matthewbauer> Ericson2314: ^
<Ericson2314> Eklog you can trick it into trying but it isn't really supported
<Ericson2314> Canadian cross will rarely bootstrap something quicker because there will be native build inputs you cannot build without the slow stage anyways
<ekleog> Ericson2314: FWIW the context was dropping *System and just exposing *Platform at the nixpkgs argument level (with build ? currentSystem, host ? currentSystem, target ? host)
<ekleog> and matthewbauer's question was “what about if one wants a canadian cross package?”
<ekleog> as for native build inputs, if we want to build (a, b, c), can't we build them with (a, c, c)?
<ekleog> (not saying it's implemented right now, just in theory)
<Ericson2314> I'm on my phone let me scroll
<Ericson2314> So if you have compiler (a, b, c) and you want to build something for c on b
<Ericson2314> Who builds the native build input for b?
<Ericson2314> You need an (a, a, b) compiler anyways
justan0theruser has joined #nixos-dev
<Ericson2314> Or (a, b, b)
<ekleog> an (a, a, c) compiler would the (a, c, c) native build input
<ekleog> erm s/c/b/
<Ericson2314> Well dependencies are just specified in terms of the build and host platform
<Ericson2314> It doesn't matter where the dependency is built
<Ericson2314> Oh the s/../
<ekleog> yeah sorry
<Ericson2314> (a, a, b) can build (a, b, b) yeah
drakonis_ has joined #nixos-dev
<ekleog> overall, I'm not saying canadian cross brings anything, I'm just saying it technically works and might be useful to eg. cross-compile from a hydra a GDB for a raspberry pi to use on other embedded systems
<Ericson2314> For (a, b, c) GCC you need to build C libgcc
justanotheruser has quit [Ping timeout: 272 seconds]
<Ericson2314> So need another compiler for C cause cannot run newly built Canadian cross
<Ericson2314> Yeah that's fine. I want to make sure at least we handle it in principle, even if we never use it with real packages, to make sure theory is good
<ekleog> though my use cases would mostly be either cross-compilation or building a gdb for another arch (currently the best solution for another-arch-gdb I have was suggested by matthewbauer, with `(import <nixpkgs> { crossSystem = { system = "riscv32-linux"; }; }).buildPackages.gdb`, whose use of `buildPackages` make me cringe a bit :/)
<ekleog> great :D
<ekleog> also, on the initial question, how would you feel about dropping the *System variables and having *Platform variables be taken as argument to the overall nixpkgs function?
<Ericson2314> The best solution you have so far for gdb is what I'd expect
<Ericson2314> For invoking Nixpkgs there was a thread and I think I was coming around to it?
<ekleog> oh I didn't see that thread, just was talking here on IRC
<ekleog> anyway, time for me to go to sleep, I'll be happy to resume that discussion later with you, and will happily read any ideas you might have on the topic if I see them! :)
<Ericson2314> Yeah I have to go too
<Ericson2314> Good timing!
<ekleog> See you! and thank you :)
orivej has quit [Ping timeout: 248 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
obadz has quit [Ping timeout: 258 seconds]
obadz has joined #nixos-dev
justan0theruser is now known as justanotheruser
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-dev
FRidh has joined #nixos-dev
Jackneilll has joined #nixos-dev
Jackneill has quit [Read error: Connection reset by peer]
Jackneilll has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
Jackneill has joined #nixos-dev
yorick has quit [Quit: nixos-rebuild]
init_6 has joined #nixos-dev
Jackneill has quit [Ping timeout: 245 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
Jackneill has joined #nixos-dev
JosW has joined #nixos-dev
JosW has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
drakonis has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 272 seconds]
init_6 has quit []
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
niksnut has quit [Quit: Lost terminal]
drakonis_ has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis1 has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
niksnut has joined #nixos-dev
scott is now known as riot_scott
riot_scott has quit [Killed (wolfe.freenode.net (Nickname regained by services))]
scott has joined #nixos-dev
scott has quit [Quit: Updating details, brb]
scott has joined #nixos-dev
scott is now known as riot_scott
riot_scott is now known as scott
drakonis has quit [Read error: Connection reset by peer]
<matthewbauer> with lldb at least i think you can just use the one in the binary cache. binutils is a bit uglier in this way
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
<clever> gchristensen: ive been going thru the qemu man page, and it looks like cache=unsafe may improve disk write speeds on the macs
<clever> gchristensen: oh, and youve already set exactly that!
<gchristensen> =)
<clever> id also like to play with discard and detect-zeroes...
<clever> discard=unmap, will allow darwin to perform discard calls to the disk, which will drop the blocks from the zvol, so you can regain space without a shutdown+rollback
<clever> detect-zeroes=unmap would deal with the lack of sparse file support in darwin, and turn them into discards
<gchristensen> hmm interesting
<clever> so they become sparse on the zvol
<clever> but for the main `discard=unmap` to work, you also have to enable discard within darwin
<clever> host/qemu.nix: -drive id=MacHDD,cache=unsafe,if=none,file=${zvolDevice},format=raw \
<clever> i notice there is no driver=
<clever> driver=raw could be used to maybe boost perf a tad
<gchristensen> oh interseting, what does it do otherwise?
<clever> driver=file vs driver=raw, one expects a file on an fs, the other expects a block device
<clever> i suspect block-dev would have faster perf, but need to check the src
<gchristensen> hmm cool
<clever> 542 if (qdict_haskey(bs_opts, "driver")) {
<clever> 543 error_setg(errp, "Cannot specify both 'driver' and 'format'");
<clever> oh, i think format=raw sets driver=raw
<clever> # qemu-system-x86_64 -drive file=nvme://host:bus:slot.func/namespace
<clever> gchristensen: not of much use in out case, but this lets you forward an entire nvme device
<gchristensen> fancy :)