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
orivej has quit [Ping timeout: 248 seconds]
dhess has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
layus has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.4]
pie__ has quit [Quit: Leaving]
sir_guy_carleton has joined #nixos-dev
drakonis has joined #nixos-dev
aminechikhaoui has joined #nixos-dev
drakonis2 has quit [Ping timeout: 248 seconds]
pie__ has joined #nixos-dev
drakonis1 has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.4]
init_6 has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Client Quit]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
init_6 has quit []
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
<emily> ah, thanks, I didn't know that existed
<dhess> me neither, until a few days ago :)
<dhess> I haven't actually tried it yet but it looks like a more automated process for generating kexec bundles, in any case.
<clever> dhess: ive been planning on adding nix-bundle to my kexec stuff
<dhess> Cool. I always reach for kexec first when I need to install NixOS on a remote machine that doesn't boot to the installer natively.
<dhess> I'm not sure it has ever failed to work.
<dhess> Maybe with one of those providers that boots their physical hardware from network-attached storage. Scaleway I think
<clever> something weird i discovered recently, is that the higher end aws machines, boot legacy, from nvme
<clever> normal bios cant do that!
<dhess> yeah we were talking about that a few weeks ago when I couldn't figure out why grub was failing to install on a running machine
<clever> ah
<dhess> except this is just a t3, not even high-end.
<clever> and thanks to the prep you gave me, i was prepared to deal with that when running into it at work, lol
<dhess> oh nice to finally return the favor for once :)
<dhess> it was a real bummer. Had to rescue to an EC2 instance for the first time ever.
<clever> half the problems i'm solving are "oh, i helped with that 2 days ago" lol
<dhess> clever: nice :)
<clever> most of the time, its people in #nixos running into the same stuff i fixed at work
<clever> latest was somebody wanting to clone private github repos, with submodules, on hydra
<dhess> I'm about to install on an R5a.large later today. First thing I'm going to do is look at /proc/partitions to see if I need to fix grub on that one as well.
<dhess> clever: well now that you mention it...
<dhess> I have exactly that same issue right now. My Hydra builds are failing because it's trying to check out a Keybase git submodule
<dhess> I was looking into this. The submodule isn't actually needed to complete any of the builds; it's just used to store the NixOps database. Is there a way to tell git or Hydra not to check out submodules?
<clever> this user was having issues with builtins.fetchGit not supporting submodules
<dhess> Only thing I could come up with offhand was to create a branch that doesn't use the submodule, but that will be a PITA to maintain.
<clever> depends on if its hydra itself doing the fetch (via build inputs) or at the nix level
<dhess> I looked around in the Hydra repo for a way to say, "Don't check out submodules," but I didn't see it.
<dhess> clever: it's at the nix level in my case.
<clever> dhess: what nix function are you using to clone it?
<dhess> mkFetchGithub, and it's a private repo.
<clever> mkFetchGithub in a declarative jobset?
<dhess> exactly
<clever> thats still at the hydra level, with build inputs
<dhess> oh ok
<dhess> I don't specify the submodule as a build input, though
<clever> but nix is generating that hydra config
<clever> dhess: are you fetching it with git@github.com or https://github.com ?
<dhess> sorry hold on, mkFetchGithub is my own function
<dhess> but it's based on iohk's default.nix for Hydra declarative jobs so you probably have the same function.
<clever> which was based on this
<dhess> yeah that's it
<dhess> clever: in this case it's with git@github.com because it's private.
<dhess> and I'm using an SSH key
<clever> this is the perl code responsible for fetching that url every time hydra is doing a check
<dhess> so deepClone?
<clever> thats for deep vs shallow, not recursive-ness
<dhess> ahh
<dhess> quick glance at that doesn't show me anything about submodules or recursive
<clever> it will then run this copy of nix-prefetch-git
<dhess> ok init_submodules
<dhess> looks like no way to bypass that
<dhess> oh that's right I think I saw an issue about this very same issue on the Hydra issues
<dhess> no that was just a fix for submodule fetches. Previous commit to that file, in fact.
<dhess> OK I guess I'll have to patch Hydra
<clever> one min
<clever> dhess: this will parse the "value" you gave to mkFetchGithub, and generate some config from it
<clever> including options, which appears to be an attrset
<dhess> right so maybe add a new option to that, "recursive" or something like that
<clever> yep
<dhess> you could really go crazy and write a filter or something. I can see wanting to clone some submodules and not others.
<clever> i once discovered that one of the submodules in cardano-sl, had a complete copy of the blockchain
<dhess> yikes
<clever> and for EVERY EVAL hydra did, it made another copy, of the whole blockchain
<dhess> oh my god
<clever> yes
<dhess> hahahaha
<clever> luckily, auto-gc took care of things, and nobody noticed, until i got bored and ran ncdu :P
<dhess> yeah but the eval time!
<dhess> bad enough as it is. If there's one thing I could change about Nix it's be to speed up evals. OK, maybe incremental builds, but evals next.
<clever> ,profiling dhess
<{^_^}> dhess: Use NIX_COUNT_CALLS=1 and/or NIX_SHOW_STATS=1 to profile Nix evaluation
<clever> in nix master, it has a 3rd variable, that will make it output the stats as json to a file
<dhess> ok good to know
MichaelRaskin has joined #nixos-dev
<clever> hydra-eval-jobs though, when it auto-restarts, will overwrite that stats, since it doesnt open in append mode
init_6 has joined #nixos-dev
init_6 has quit []
v0|d has joined #nixos-dev
sir_guy_carleton has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
v0|d has quit [Ping timeout: 272 seconds]
aszlig has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis has quit [Client Quit]
drakonis has joined #nixos-dev
v0|d has joined #nixos-dev
ekleog_ is now known as ekleog
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-dev
lopsided98 has quit [Ping timeout: 248 seconds]
lopsided98 has joined #nixos-dev
<ivan> fun fact: bcc execsnoop as root causes panic and instant reboot on 4.19.48-hardened, confirmed on 3 machines
<ekleog> ryantm_: Hey! I was wondering, do you think it'd make sense to have r-ryantm build `passthru.tests` when it exists? something like building `<derivation>.tests or {}` in addition to what's already done should be enough :) (saying that because I've just been pointed to a PR of someone adding a nixos tests and a link with passthru.tests following an update from r-ryantm that got merged but broke the package
<ekleog> -- there's no certainty the test would have detected it, but it'd still have been better than nothing)
<lopsided98> How do we deal with packages that contain references to other derivations within compressed files?
<lopsided98> In particular, the zfs kernel module currently finds mount and umount using /usr/bin/env. I fixed it so it points directly at the binary, but the dependency is not picked up because the kernel module is compressed
<Profpatsch> ekleog: Yes please
<Profpatsch> I use passthru.tests in my packages
<lopsided98> In practice, this is probably not a problem, because zfs will almost always be pulled in by a NixOS system configuration which has other references to utillinux, but I was wondering if there was a better solution.
<ekleog> Profpatsch: <3 you, the more people use passthru.tests the better I feel :D
<ivan> lopsided98: I think you can just write some /nix/store paths to a file
<ivan> I forgot which attribute does that for you
<lopsided98> ivan: thanks. I can't find an attribute to do it automatically, so I'll just do it manually for now and ask when I submit the PR
<ivan> propagatedBuildInputs?
<ivan> that writes to nix-support/propagated-build-inputs
<ivan> I see a lot of packages write to nix-support
<lopsided98> That would work, but its not really right because there is no reason for the dependency to be propagated. I'm just going to use a different file that doesn't have any semantics associated with it
Cale has quit [Ping timeout: 248 seconds]