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
ryantm has quit [Quit: Lost terminal]
orivej has joined #nixos-dev
boredom101 has joined #nixos-dev
boredom101 has quit [Quit: Page closed]
orivej has quit [Ping timeout: 258 seconds]
Irenes has quit [Ping timeout: 276 seconds]
Irenes has joined #nixos-dev
justanotheruser has quit [Ping timeout: 248 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 250 seconds]
aminechikhaoui has quit [Quit: Ping timeout (120 seconds)]
aminechikhaoui has joined #nixos-dev
orivej has joined #nixos-dev
psyanticy has joined #nixos-dev
arianvp has quit [Quit: WeeChat 2.4]
Jackneill has quit [Ping timeout: 246 seconds]
arianvp has joined #nixos-dev
Jackneill has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 245 seconds]
<gchristensen> I know of a handful of companies in need of good Nix people. Please PM me if you're interested.
<Taneb> Alas I am already a company's good nix person
orivej has joined #nixos-dev
chaker has joined #nixos-dev
globin has quit [Remote host closed the connection]
globin has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 245 seconds]
drakonis has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 245 seconds]
disasm_ has joined #nixos-dev
disasm has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
sir_guy_carleton has quit [Quit: WeeChat 2.4]
<thoughtpolice> Does anyone know if we have a strict policy on putting things under linuxPackages? Here's the deal: there's a tool called 'bpftool' that lets you do some analysis of the running BPF programs loaded into the kernel or network subsystem. It is always packaged with Linux. So normally we'd put it under linuxPackages and there'd be a "family" of tools for each kernel.
<thoughtpolice> But, AFAICS, bpftool isn't really strictly tied to the kernel version as much as, say, perf is. In fact it should be fine to use bpftool from e.g. newer kernels on older ones, so you can see what features are enabled, or because bpftool might be built with newer features like disassembler improvements (this is one of its intended uses, to test/diagnose what things are available regardless of the underlying kernel version).
<thoughtpolice> Of course on the other hand I suppose it's possible that won't always be true! It's not a strict guarantee in any place.
<thoughtpolice> So I'm wondering if maybe we should 1) only have 'one' bpftool, built from linuxPackages_latest automatically, or 2) just keep it in linuxPackages like everything else and let people get the appropriate version, shipped with their kernel.
<thoughtpolice> Thoughts?
<gchristensen> seems safest to keep them per-kernel
psyanticy has quit [Quit: Connection closed for inactivity]
<samueldr> linuxPackages is mainly for things that are affected by which kernel version you pass them, e.g. kernel modules; though looks like your case is a bit on the edge
<samueldr> like, does it receive a `kernel` parameter to its derivation?
<thoughtpolice> Yeah, and to be fair I'm a bit loathe to put things in kernelPackages like that because often minor things need to be fixed between versions (so you end up with a lot of edge cases in the expression). Plus it just bloats the cache.
<thoughtpolice> And so many characters to type!
<thoughtpolice> nix run linuxPackages_latest.bpftool, etc
<thoughtpolice> samueldr: It *does* need linuxPackages.kernel, yes. But only so I can reuse the .src attribute
<thoughtpolice> So I don't take 'kernel' but linuxPackages instead, right now
<samueldr> right, so it's affected by using the kernel given
<thoughtpolice> In theory I suppose it's possible it could also be affected by patches you apply thru an override.
<thoughtpolice> Which means it probably even needs to be inside the kernel/ dir itself.
<thoughtpolice> (On that note, I wonder if 'perf' handles that case too...)
<samueldr> oh, I meant to say "not affected by the kernel given"
<thoughtpolice> To be fair I have another tool like this called 'lockdep' which is in the same category but it doesn't use the src attribute
<samueldr> or uh
<thoughtpolice> So it isn't updated when linuxPackages_latest is touched, etc. (I need to fix some things in it...)
<globin> Ericson2314, Mic92, matthewbauer: are you aware of llvmPackages not evaluating for cross or have a fix?
<globin> nix-build -A pkgsCross.aarch64-multiplatform.clang
MichaelRaskin has joined #nixos-dev
<globin> error: attribute 'llvmPackages_5' missing, at /home/robin/dev/nixpkgs-upstream/pkgs/top-level/all-packages.nix:7673:27
Profpatsch has quit [Ping timeout: 252 seconds]
<globin> for some reason llvmPackages doesn't exist in buildPackages at that point, but I cannot figure out why
<matthewbauer> globin: yeah that looks like the targetPackages is being used
<Ericson2314> a new use?
<matthewbauer> we probably need to condition all of the targetLlvmLibraries usage on `stdenv.hostPlatform != stdenv.targetPlatform`
<matthewbauer> usually we don't compile clang for the cross target so i think it just happens now
<matthewbauer> i remember running into it before as well
<gchristensen> matthewbauer: btw can you relicense your contributions? https://github.com/NixOS/nixos-homepage/pull/260
<{^_^}> nixos-homepage#260 (by davidak, 13 weeks ago, open): [WIP] Add licenses
<gchristensen> thanks!
<matthewbauer> globin: if you want a clang that /builds/ for aarch64, you should be able to use `pkgsCross.aarch64-multiplatform.buildPackages.llvmPackages_8.lldClang`
<Ericson2314> matthewbauer: errrr `targetLlvmLibraries` should be safe to use unnconditonally
<Ericson2314> if anything *safer* in the native case
<matthewbauer> Ericson2314: but it's missing llvmPackages_*!
<Ericson2314> I should see the error
<matthewbauer> it's when you are building llvm /for/ a certain target, that targetPackages is empty
<Ericson2314> ohh
<Ericson2314> yeah that needs a general solution
<Ericson2314> we should make a final stage after cross's targetPackages whiich is basically targetPackages // fake stdenv
<Ericson2314> whereas today it is just fake stdenv
janneke_ has joined #nixos-dev
<Ericson2314> that stuff needs to be `postStage = buildPackages: buildPackages // { .. }` or something like that
janneke_ is now known as janneke`
<Ericson2314> and that stage should be "fixed" to itself with `targetPackages = self`.
<Ericson2314> (well maybe exposing that is not needed as nobody should be doing targetPackages.targetPackages.targetPackages.... into the abyss)
delroth1 has joined #nixos-dev
disasm| has joined #nixos-dev
disasm_ has quit [Ping timeout: 248 seconds]
chaker has quit [Ping timeout: 248 seconds]
delroth has quit [Ping timeout: 248 seconds]
janneke has quit [Ping timeout: 248 seconds]
<globin> thanks, from all this I noticed that I was looking for a package which was using llvm in the buildInputs
Profpatsch has joined #nixos-dev
delroth1 is now known as delroth
<Ericson2314> ahh
<Ericson2314> I mean, cross compiling llvm *should* work too, but yeah that's more likely
<globin> generally, yes! but in this case I was running blindly in the wrong direction :)
<matthewbauer> yeah laziness saves us there. only clang should care about targetLlvmLibraries
<clever> llvm = llvm.overrideAttrs (old: {
<clever> cmakeFlags = old.cmakeFlags ++ [ "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR" ];
<clever> of note, i would be interested in a clang that can use this
<clever> out of the box, clang doesnt beleive avr is a valid target, so i have to generate llvm IR from clang, and then run llvm over that
<clever> (and llvm segfaults)
<globin> matthewbauer, Ericson2314: also do you have a solution for newScope not splicing?
<Ericson2314> globin: x11 does that manually right?
<Ericson2314> so the problem is that it's hard to pass in the things to splice
<globin> Ericson2314: it does for some things but all e.g. xorg.font* is broken
<Ericson2314> without the newscope "knowing its own name"
<Ericson2314> globin: https://github.com/NixOS/nixpkgs/pull/51213 was my attempt at trying to make a common ideom for nested package sets
<{^_^}> #51213 (by Ericson2314, 22 weeks ago, open): WIP lib: Better extensible attrsets
<Ericson2314> after which is it would be at least 1 yak shave not many to get them all automatically splicing
<Ericson2314> "knowing your own name" is endless problems (imaging "copying" a package set (binging under a different attribute) and now picking up wrong splices / overrides / etc)
<globin> Ericson2314: I just found the same issue with gst_all_1 :(
<Ericson2314> but one could use a smilar trick I used in that PR to automatically merged nested attrsets properlly in overlays to pass in the other ones at the last moment
<Ericson2314> so nothing knows it's own name but some "late binding" track
aszlig has quit [Quit: Kerneling down for reboot NOW.]
<Ericson2314> gst_all_1 ?
<globin> Ericson2314: another use of mkScope breaking cross -> meson not fetched from buildPackages
<Ericson2314> gotcha
<Ericson2314> well there's more problems with meson things usually
<Ericson2314> trying to fix that upstream
<Ericson2314> but it's been on odyseey
<globin> well, it breaks before we get there since it's trying to use the host meson
aszlig has joined #nixos-dev
<matthewbauer> globin: could you make a ticket for this? i think there is something specifically broken in meson here... it binds stuff in the cross file that can make this more confusing
<Ericson2314> pkgs.newScope -> __splicedPackages.newSpace
<Ericson2314> as long as the new scope stuff is only runtime packages should work fine
<Ericson2314> which should be the common case
<globin> Ericson2314: that works, but would be ugly to replace all of the newScopes with that, is there a way we can make that "default"?
<Ericson2314> not a bad idea!
<globin> Ericson2314: I'll try that
<Ericson2314> sweet let me know how it works!
<globin> sure
<Ericson2314> (If only everyone used matrix, then we could get to a word were "IRC" pastes were no longer bad etiquette)
<Ericson2314> *world
<globin> just for me to use matrix in weechat again :>
<Ericson2314> hmm?
<globin> I'm using a plugin in my IRC client to connect to matrix :)
<gchristensen> joepie91 reports that Matrix's protocol specification and implementations don't match up, either
<Ericson2314> oh nice nice
<Ericson2314> gchristensen: I hope to finish my competing implementation
<Ericson2314> which will have all the types
<gchristensen> :)
<Ericson2314> so at least these things can be caught
<gchristensen> how about ircv3 is that ever going to be a thing
<samueldr> it already is
<tilpner> "Full support for all currently ratified IRCv3 extensions."
<samueldr> and just like the previous RFCs, will be followed in parts or completely both by clients and servers
<globin> gchristensen: how are you creating your performance report>
<gchristensen> NIX_SHOW_STATS=1
<globin> gchristensen: ty
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 248 seconds]
ryantm has joined #nixos-dev
boredom101 has joined #nixos-dev
drakonis has joined #nixos-dev
boredom101 has quit [Quit: Page closed]
drakonis_ has joined #nixos-dev
drakonis_ has quit [Remote host closed the connection]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 258 seconds]