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