<clever>
it just jams a new attr onto the return value, and when you run that, it has access to the original set, and re-runs itself, but letting f mutate things
<siraben>
ah, right and merge with //
<siraben>
// is right-biased?
<clever>
the right side has higher priority, and can overwrite the left's keys
kalbasit_ has quit [Ping timeout: 260 seconds]
<siraben>
I see. That makes sense
<siraben>
beautifully
<siraben>
beautiful*
<clever>
siraben: related, there is also lib.hydraJob
<clever>
siraben: that function will strip things like overrideAttrs off a package, then nothing depends on the `args` set, and nix can GC it from the heap
<clever>
when your having to eval 20,000 packages at once, that can give a major savings
kalbasit has quit [Quit: WeeChat 2.9]
<siraben>
Oh yeah, definitely.
<siraben>
Is there an updater for aspellDict dictionaries?
<siraben>
there's passthru.updateScript, hm
<siraben>
I ran `nix-shell maintainers/scripts/update.nix --argstr max-workers 2 --argstr commit true --argstr path aspellDicts` but there doesn't seem to be any changes made
kalbasit has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
kalbasit has quit [Ping timeout: 256 seconds]
tilpner has quit [Quit: tilpner]
arcnmx has quit [Quit: Idle for 30+ days]
jonringer has quit [Ping timeout: 264 seconds]
tilpner has joined #nixos-dev
saschagrunert has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
<yorick>
is it not possible to override system.build.installBootloader?
<siraben>
supersandro2000: never mind, only merge when rebuild 0
__monty__ has joined #nixos-dev
<siraben>
Can anyone tell me if `nix-shell maintainers/scripts/update.nix --argstr max-workers 2 --argstr commit true --argstr path aspellDicts` is correct? I ran it and it completed on my device but no commits seem to be made.
<lukegb>
commit true only works if the script supports that
<supersandro2000>
I wouldn't mind if this would be one commit tbh
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<roberth>
I've just merged a PR for a NixOS service that didn't get any response from its 4 (four) package maintainers for 34 days. It wasn't complicated or anything. I wonder what can be done to improve this
<lukegb>
honestly? having an explicit maintainer timeout like freebsd and a pool of people willing and able to review things once they've timed out :p
<lukegb>
but... also, these things happen
<roberth>
yeah that's basically what I did, but without the automation
<roberth>
I know it is to be expected to happen every now and then
<lukegb>
a histogram of PR ages would be interesting, especially if we can classify PRs as "trivial" (e.g. r-ryantm, and most plain version+hash bumps)
<andi->
infinisil: that might get noisy, how about making it opt-in?
<infinisil>
andi-: I'd probably make it only post a single comment, and updating it for multiple mentions
<andi->
ok
<andi->
or create a proxy repo that creats "proper" links to other issues so it doesn't show up as spammy comment
<infinisil>
andi-: Not sure what you mean
<andi->
create the repo infinisil/irc-pings, create one issue there for each GH PR/issue you want to link to and update that issue for every time someone mentions it on IRC
<andi->
Gives the actual PR/Issue proper "pings" in the UI and no spammy comments and you can just post a comment whenever it is mentioned.
<{^_^}>
#101071 (by ju1m, 13 weeks ago, open): apparmor: try again to fix and improve
__monty__ has quit [Quit: leaving]
<cole-h>
infinisil: May be just me, but I link to so many issues in IRC... I'd probably stop doing \###### altogether if it meant an issue would be pinged. Just FWIW.
<infinisil>
Hmm..
<cole-h>
siraben: If you force-push 110655, the eval error should go away.
<infinisil>
It would be very valuable for finding irc conversations, but I can see what you mean
<cole-h>
There's definitely an upside, for sure, but the downside outweighs it for me. I'd go back to full URLs (provided those don't trigger the ping as well)
<infinisil>
Ah yeah that could be an idea
<infinisil>
cole-h: What if it was like andi- suggested?
<samueldr>
well, I would hope full URLs ping too considering the other way pings
<cole-h>
I would much, much, much prefer that
<samueldr>
as it would be inconsistent
<infinisil>
samueldr: Also a good point
<samueldr>
but yeah, comments are noisy, I already quite dislike the discourse pings
<cole-h>
^
<samueldr>
I think the way andi- suggested, if I understand it right, would be fine
<infinisil>
Yeah, I think I'll go for his idea (if/when i implement it)
<samueldr>
also consider non-Nixpkgs projects
<samueldr>
non-NixOS org I should have said
<infinisil>
Yeah
<cole-h>
IMHO, we should only "ping" NixOS-adjacent repos (e.g. nix-community hosted, NixOS hosted, and e.g. naersk / crate2nix / node2nix / vgo2nix / etc.).
<cole-h>
And/or maybe denylist #nixos-chat :-P
<infinisil>
The repos make sense
<infinisil>
Well
<infinisil>
It would be nice if it worked with all repos, I don't think that would be a big problem
<infinisil>
I doubt anybody would get annoyed about relevant discussion for their issue
<cole-h>
Relevant being subjective :P
<infinisil>
If you talk about it it has to be relevant though!
<infinisil>
I guess you have in mind that sometimes people like to sh*ttalk about some issues?
<cole-h>
:)
* infinisil
thinks about how to solve that nicely
<infinisil>
What if we just don't do that in public channels?
<infinisil>
Not a real solution, but I think that would be the ideal way :P
<cole-h>
Just like we also have a guideline to not swear, yet it happens anyways? ;)
<cole-h>
Though somewhat of an apples-to-oranges comparison
kalbasit_ has joined #nixos-dev
<infinisil>
Note that this feature would only work for channels where both {^_^} and {`-`} are in
<samueldr>
cole-h: it's not really not to swear, but "be nice", where swearing mainly is not nice
<cole-h>
Fair
<samueldr>
shittalking about issues would be not nice
<infinisil>
Yeah so I don't think we need to be concerned about that
<infinisil>
One thing that could be implemented is that the bot first checks whether the issue/pr is publicly commentable, and it won't reference it if it isn't
<infinisil>
So that when the admins do "Limit comments to collaborators" or so, it won't backlink to irc
<cole-h>
If this does happen (I'm still lukewarm on it, at best :P), +1 to that.
<infinisil>
I think the potential risk of such a feature is minimal, and any limitation of the feature would reduce it's usefulness way more than the risk it reduces
srk has quit [Ping timeout: 268 seconds]
srk has joined #nixos-dev
<infinisil>
The worst that could happen is that a number of people shittalk about some issue in a public and logged irc channel, at which point it's highly unlikely that the issue members aren't already aware of something icky going on. And even if they aren't, they'd have to click though to the reference, where they are met with nicks that they probably haven't ever seen before, because most people don't
<infinisil>
even use irc
<ekleog>
a number of people's irc nick is close-ish to their github handle, though
<ekleog>
(also, and maybe more importantly, it'd link to discussions happening on #nixos)