AlwaysLivid has quit [Remote host closed the connection]
jonringer has quit [Ping timeout: 260 seconds]
MichaelRaskin has joined #nixos-dev
Jackneilll has joined #nixos-dev
Jackneill has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 264 seconds]
MichaelRaskin has quit [Ping timeout: 256 seconds]
thibm has joined #nixos-dev
__monty__ has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
kalbasit has quit [Ping timeout: 260 seconds]
kalbasit has joined #nixos-dev
orivej has joined #nixos-dev
<kraem>
lovesegfault: i love gource animations!
<andi->
gchristensen: the r13y.com runner seems to be missing / broken
<timokau[m]>
ekleog: (Late reply to your message from Saturday): I already did that a while ago. Its a bit hidden between all the posts. Feel free to plug it again.
pmy has quit [Ping timeout: 256 seconds]
pmy has joined #nixos-dev
ehmry has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 272 seconds]
mkaito has joined #nixos-dev
teto has joined #nixos-dev
ehmry has joined #nixos-dev
mkaito has quit [Client Quit]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
MichaelRaskin has joined #nixos-dev
mkaito has quit [Read error: Connection reset by peer]
thibm has quit [Ping timeout: 246 seconds]
teto has quit [Quit: WeeChat 3.0]
thibm has joined #nixos-dev
thibm has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
thibm has joined #nixos-dev
elvishjerricco has quit [Ping timeout: 260 seconds]
globin_ has quit [Quit: o/]
globin has joined #nixos-dev
ckauhaus has joined #nixos-dev
aranea has quit [Ping timeout: 260 seconds]
globin has joined #nixos-dev
globin has quit [Changing host]
elvishjerricco has joined #nixos-dev
Emantor has quit [Ping timeout: 260 seconds]
aranea has joined #nixos-dev
Emantor_ has joined #nixos-dev
thibm has quit [Ping timeout: 256 seconds]
jonringer has joined #nixos-dev
evanjs has quit [Ping timeout: 256 seconds]
evanjs has joined #nixos-dev
teto has joined #nixos-dev
costrouc has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 265 seconds]
costrouc has joined #nixos-dev
orivej has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<supersandro2000>
Any ideas how to make a setup hook for python which requires maturin but does not pull in the entire rust eco system?
<supersandro2000>
well without the setup more a general hook
orivej has quit [Ping timeout: 260 seconds]
<supersandro2000>
Am I the only that thinks that marvin is kinda pointless?
<gchristensen>
I think marvin could really help with workflow
<supersandro2000>
we could also move PRs in projects with automation which would maybe be even better
<andi->
I lack a CI passed filter on GH
<andi->
that would make reviewing a bit easier as you do not have to figure out that it didn't actually build/eval/…
<ekleog>
I know personally I can't find the motivation to run through the PR list looking for the one PR that's not awaiting changes from the submitter, so getting pinged when (and only when) a PR is ready for review helps me a lot for contributing (the “PRs ready for review” thread has the issue that most of the time when I click things have already been merged, which is equally demotivating)
<ekleog>
(well, either already merged or already r-'d, which is even worse as I then notice only after having read through all the things)
cole-h has joined #nixos-dev
orivej has joined #nixos-dev
<lukegb>
supersandro2000: otoh nixos module changes tend to go ~weeks without anyone doing anything
<lukegb>
The simple package related changes? Trivial. NixOS modules? lol good luck
<lukegb>
That's kind of where I'm hoping Marvin can help out, in flagging changes which don't need author changes but are just stuck on a review (possibly because maintainers are busy with life, or for other reasons)
<infinisil>
lukegb: Packages are easy because the API they expose is very minimal, it's really just a derivation at an attribute path
<infinisil>
NixOS modules are harder (partly) because their API surface is much bigger
<lukegb>
infinisil: right
<lukegb>
And also it requires more thinking about it than just "does this package work"
<infinisil>
But also much more can go wrong
<infinisil>
Yea
<lukegb>
"does this make sense in the NixOS ecosystem" etc
<lukegb>
"will this break existing users"
<infinisil>
We don't really have easy tests for NixOS modules
<infinisil>
(there's NixOS tests, but there are very bloated imo)
<infinisil>
s/there/they
* lukegb
looks at the NixOS chromium test
<lukegb>
Oh yeah, that was something I wanted to look at: can we expose a Prometheus metric of flaky tests
<infinisil>
Hm though I'm not sure actually, maybe NixOS tests are good
<lukegb>
e.g. the chromium one that tends to fail more often than it passes
<lukegb>
My personal stance is NixOS tests are really good at testing the entire system and... well, they're actually relatively quick, if you're only running a few of them
<supersandro2000>
I am not using nixos modules so I have like zero knowledge about them
<lukegb>
right, this isn't a slight against you or anything (sorry if it seemed that way)
<lukegb>
I think the +w people (esp. supersandro2000) are doing a great job at keeping the PR backlog down for the simple things
<lukegb>
but trying to make sure someone knowledgable reviews the more complicated things (like nixos modules, or the generic core packaging stuff) is harder
<lukegb>
I guess it's easy if you're in the "in" crowd and can just poke someone personally for a review :3
<timokau[m]>
Thanks ekleog :) I think it would be better to link the README instead of the USAGE. The readme has a bit more on the "why" and people can click through to the usage if they are interested.
<timokau[m]>
supersandro2000: I'm not very familiar with GH projects and the automation that github offers. I would be surprised if it can replace marvin, but I'd be happy to be proven wrong.
<supersandro2000>
timokau[m]: not going to tackle that right now
<supersandro2000>
working on some buildHook for easier maturin builds
<ekleog>
timokau[m]: makes sense, I'll make sure to link the README next time I advertise marvin! :)
ckauhaus has quit [Quit: WeeChat 2.7.1]
<elvishjerricco>
Whoo, got my initrd working for `nix-build nixpkgs/nixos -A vm`
<elvishjerricco>
So I can probably put it on github today
<cole-h>
:o
<elvishjerricco>
The ability to write `extraUnits."foo.service" = pkgs.writeText "foo.service" "..."` to put a new service into initrd is so very nice. Getting parallelism and actual dependency ordering is quite useful
<elvishjerricco>
Aw, the boot time is actually like 1s slower :(
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
mkaito has joined #nixos-dev
<samueldr>
elvishjerricco: but is it *strictly* equivalent to the script or does it do more?
<elvishjerricco>
samueldr: Actually right now it does substantially less than stage-1.sh
<samueldr>
elvishjerricco: comparing what you're *using*
<elvishjerricco>
It's really just the bare minimum to mount file systems and load modules
<samueldr>
since you were comparing boot speed
<elvishjerricco>
samueldr: Oh, I meant mine is 1s slower than regular nixos stage-1.sh
<samueldr>
yeah, I understood that :)
<elvishjerricco>
Then I do not understand what the question is :P
<samueldr>
but from what you say, it looks like it's not doing anything more *for you* than what the usual .sh script does, right?
<elvishjerricco>
samueldr: Yea, pretty much. I mean in theory I could take advantage of the dependency ordering better this way than with regular stage-1.sh, but I haven't done anything like that yet
<samueldr>
is it really 1000ms or is it hard to measure?
<elvishjerricco>
samueldr: I haven't measured precisely. I just used `time -o mine.txt run-nixos-vm` with autologinUser set to root and entered `poweroff` as quicky as I could :P
<samueldr>
ah
<samueldr>
then your measurements mean nothing :)
<elvishjerricco>
samueldr: systemd-analyze could tell me how much time was spent in initrd, right?
<samueldr>
I don't know, but I'd hope so
<elvishjerricco>
Yea systemd-analyze seems to confirm. Given that systemd can't pass off stage-1 stuff to stage-2 systemd (beacuse init isn't systemd in stage-2), I think it's counting initrd in the kernel time measurement
<elvishjerricco>
And that's about 1.5s slower with mine
<elvishjerricco>
I bet mine would be faster if initrd were doing more things, like opening LUKS volumes and importing ZFS pools
pmy has quit [Ping timeout: 265 seconds]
<elvishjerricco>
Oh, I was only booting with the default cores and memorySize. Bumping those up got me to just 0.7s slower
pmy has joined #nixos-dev
<elvishjerricco>
Huh. I wanted to test out ZFS in this initrd, but I can't get mkForce to override the VM's root device and fsType
<elvishjerricco>
Or rather, mkOverride 0 isn't working
<samueldr>
isn't the VM profile overriding those? though I guess mkOverride 0 might be enough normally&
<elvishjerricco>
samueldr: Yea, the VM uses mkOverride 10, so 0 should beat it
<samueldr>
the whole filesystem attribute, or the leaf nodes? IIRC I had issues by doing it at the wrong place in the hierarchy
<samueldr>
but I don't remember which way around
<elvishjerricco>
samueldr: It does `fileSystems = mkVMOverride { ... }`
<samueldr>
do you do fileSystems = mkOverride 0 ?
<elvishjerricco>
Oh I see. I did `fileSystems."/" = mkOverride 0 { ... }`
<samueldr>
I didn't dig to understand if it should or shouldn't work that way though
<elvishjerricco>
Yea that fixed it
<samueldr>
but I was surprised a bit by putting the override at the "wrong" level