<emily>
also, tfw you watch ofborg build a kernel in 20 minutes that takes hours on my machine and wish you could grab the resulting binary :'(
<emily>
hm, maybe it's the VM test machinery actually (but I don't recall getting those messages locally)
<cole-h>
emily: I think that's just the test runner?
<cole-h>
Yeah
<cole-h>
I don't see any ofborg errors in any of the logs atm
<emily>
the weird thing is that it got spewed out on one line before I reloaded
<emily>
"(0.10 seconds),12 out of 12 tests succeeded,test script finished in 22.53s,cleaning up,killing machine (pid 6),(0.00 seconds),vde_switch: EOF on stdin, cleaning up and exiting,vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty,/nix/store/ggdv4v9v3m1yyz8y2b89zwbxx09m2drc-vm-test-run-hardened,/nix/store/70gfx57l73sc2b927lmrsp9pz4aj2x4x-vm-test-run-hardened"
<cole-h>
Maybe before the log collector had time to split the elements
<cole-h>
My current position is: "it's innocuous," but I'll keep my eyes and ears peeled.
<emily>
(some update script refactors too but it worked enough to do those ones at least)
<cole-h>
I think Neq beat you to the actual patches (were pushed to master ~30m ago lol), but I like the mypy typing
<emily>
oh whoops :)
<emily>
well, no rush then, I'll rebase it on top of master in a bit and maybe do some more cleanups
<cole-h>
You opened your PR long before that happened, so nothing to "whoops" about
<cole-h>
:P
drakonis has joined #nixos-dev
<DamienCassou>
hi everyone
<etu>
DamienCassou: o/
<DamienCassou>
in the past, I had commit access (see, e.g., https://github.com/NixOS/nixpkgs/pull/18966). I then stopped using NixOS for 2 years and I lost commit access. I'm back now. Would it be possible to get commit access back?
<gchristensen>
interesting, I didn't know we'd revoked commit bit before
<MichaelRaskin>
Maybe 2FA?
<MichaelRaskin>
DamienCassou: do you have 2FA enabled for your account?
<MichaelRaskin>
gchristensen
<MichaelRaskin>
There was definitely de-facto revocation due to checking 2FA-mandatory checkbox
<gchristensen>
https://github.com/NixOS/nixpkgs/issues/42761 indeed DamienCassou's nick is in here :) not sure how I/we decided to remove them. maybe via request? doesn't look like a systemic search was done
<{^_^}>
#42761 (by grahamc, 1 year ago, closed): Require 2FA for all committers
<gchristensen>
DamienCassou: added!
<MichaelRaskin>
I believe there was a full list of the accounts with access, and once the count was low enough, people looked at unticked checkboxes?
<gchristensen>
yeah maybe so
<gchristensen>
DamienCassou: welcome back :)
<DamienCassou>
Thank you very much
<etu>
DamienCassou: we miss you in Stockholm as well at the Emacs meetups ;)
<DamienCassou>
That was indeed a nice experience :-)
<DamienCassou>
It's good to be back. I missed NixOS quite a bit
noonien has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
<DamienCassou>
I have opened a PR to add a package 6 days ago. No one looked at it. All checks pass. Is it ok to merge it myself? Should I instead keep waiting or ping someone? https://github.com/NixOS/nixpkgs/pull/85654
<{^_^}>
#85654 (by DamienCassou, 5 days ago, open): GitAutofixup: init at 0.002007
sogatori has quit [Read error: Connection reset by peer]
<DamienCassou>
there is a PR which contains merge commits. Is it an accepted practice or should I ask the PR author to get rid of them and rebase instead?
<cole-h>
I've seen most other committers ask the author to rebase themselves.
<DamienCassou>
I will do that then. I would prefer not having merge commits in PRs
<worldofpeace>
Damien Cassou: maybe review the nixpkgs contributing guide. It says strictly to rebase
<DamienCassou>
worldofpeace: thanks for the tip. Is it in the nixpkgs manual?
<worldofpeace>
yep
<DamienCassou>
thank you for the release worldofpeace
<DamienCassou>
I remember there were discussions a few years ago about automatically closing PRs and issues after some time. I thought and always think this is a great idea if anyone can reopen them at any point. Were there any decision?
<worldofpeace>
Damien Cassou: you're welcome, my honor ✨
<worldofpeace>
I think we have a stale issue bot
<cole-h>
I think there was talk about that recently. RFC'd maybe?
<{^_^}>
rfcs#51 (by ryantm, 35 weeks ago, merged): [RFC 0051] Mark stale nixpkgs issues
<cole-h>
Yeah, just found it
<worldofpeace>
but closing stale issues was found to be not useful in that RFC
<worldofpeace>
lol
<DamienCassou>
thank you
<cole-h>
worldofpeace: I agree with that finding. Too many times have I searched for something only to find "this issue is stale. closing"
<cole-h>
It feels like a slap in the face -- the fact that I encountered that issue proves it's still problematic...
<worldofpeace>
cole-h: I know one repo that uses the bot and it can be soo annoying, just commenting so the bot can stop being annoying
<cole-h>
Every repo I see that uses the stale issue bot (that autocloses) or that dependency-bump bot gets an automatic stink-eye from me
<DamienCassou>
if an issue is still problematic, I think you should re-open and say that it is. But I guess many issues will be closed and stay closed.
<emily>
cole-h: I especially like the more optimistic version of those, "this hasn't been touched for 3 versions, so we're going to assume it got fixed"
<emily>
awfully bold of you to assume your defect rate is going down over time, imo
<cole-h>
Ugh
<gchristensen>
harsh but fair
<MichaelRaskin>
Well, to be honest, the issues that do get resolved are most often closed a year later when someone decides to triage old and forgotten issues
<emily>
MichaelRaskin: I think that's quite true at the distro level, less so at the level of individual software projects
luc65r has joined #nixos-dev
<emily>
bugs usually don't spontaneously fix themselves, and although big refactors often "accidentally" close a bunch of bugs I reckon they're about as likely to accidentally reopen them
<MichaelRaskin>
emily: I was making a statement of what I see in my GH notification stream
<MichaelRaskin>
Not generally
<MichaelRaskin>
Also, for packaging issues, upstream build system usually evolves in some direction, so new bugs are new, not the reopened old ones
<{^_^}>
#85654 (by DamienCassou, 5 days ago, open): GitAutofixup: init at 0.002007
<cole-h>
👍
<worldofpeace>
Damien Cassou: merged ✨
<DamienCassou>
thank you!
<DamienCassou>
I recently opened an issue about `man` not being able to list man pages. I would like to fix it myself but appreciate some guidance. Do you know anyone who knows a bit how man pages work? https://github.com/NixOS/nixpkgs/issues/86065
<{^_^}>
#86065 (by DamienCassou, 3 hours ago, open): Cannot list man pages with apropos
<DamienCassou>
I already CCed @ryantm @matthewbauer
luc65r has quit [Quit: Quit]
<worldofpeace>
Damien Cassou: I have no idea, but this is what looks interesting to me: documentation.nix man.enable, whatis.c in man-db
<cole-h>
DamienCassou: A quick Google leads me to the manpage for mandb(8). Have you tried `mandb -c`? It "forces mandb to delete previous databases and re-create them from scratch"
<Irenes[m]>
oh hey it would be great to have a solution for that
<Irenes[m]>
thanks for working on it
<cole-h>
Uh, anybody who has ofborg perms to build on Darwin, mind telling borg to build #85930? I forgot I can't do that x)
* cole-h
adds to my borg todo list to investigate if that's possible
<worldofpeace>
cole-h: weird, that has worked for me often
<cole-h>
oh lmao dotnet-sdk is not support on darwin
<cole-h>
worldofpeace: That is weird... regardless, investigating that is now on my growing todolist. We'll see if I get around to it in the next few weeks :P