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
<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
<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