sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ | 20.09 ZHF: https://discourse.nixos.org/t/nixos-20-09-zero-hydra-failures/8928 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 20.03 RMs: worldofpeace, disasm; 20.09: worldofpeace, jonringer | https://logs.nix.samueldr.com/nixos-dev
<sphalerite> infinisil++ I might have done this already but I need to express appreciation for your work on RFC42 again, it looks like an uphill battle to me but I really appreciate your sustained effort on it and think it's shaped into a really well thought-out and helpful design by now.
<{^_^}> infinisil's karma got increased to 360
<sphalerite> I'd love to see it go through, and am considering working on some of the remaining TODOs if you'd like
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #nixos-dev
spacekookie has quit [Quit: **aggressive swooshing**]
spacekookie has joined #nixos-dev
rajivr has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 240 seconds]
AlwaysLivid has quit [Ping timeout: 244 seconds]
justanotheruser has joined #nixos-dev
<Ericson2314> gchristensen: :) fixed
AlwaysLivid has joined #nixos-dev
<infinisil> sphalerite: <3
<infinisil> I think it's just really about stripping it down to a "Don't extraConfig, do settings with freeformType and pkgs.formats" now
cole-h has joined #nixos-dev
alp has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<sphalerite> infinisil: there are a couple of TODOs left in the text too though
bk16031 has joined #nixos-dev
disasm has quit [Ping timeout: 240 seconds]
disasm has joined #nixos-dev
emilazy has quit [Ping timeout: 240 seconds]
emilazy has joined #nixos-dev
orivej has joined #nixos-dev
cole-h has quit [Ping timeout: 260 seconds]
bk16031 has quit [Ping timeout: 240 seconds]
emilazy has quit [Ping timeout: 240 seconds]
emilazy has joined #nixos-dev
alp has joined #nixos-dev
sdier has quit [Ping timeout: 240 seconds]
sdier has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
alp has quit [Ping timeout: 244 seconds]
elvishjerricco has quit [Ping timeout: 272 seconds]
elvishjerricco has joined #nixos-dev
carter has quit [Ping timeout: 272 seconds]
chrisaw has quit [Ping timeout: 272 seconds]
dmj` has quit [Ping timeout: 272 seconds]
carter has joined #nixos-dev
chrisaw has joined #nixos-dev
dmj` has joined #nixos-dev
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
bk16031 has joined #nixos-dev
alp has joined #nixos-dev
bk16031 has quit [Ping timeout: 244 seconds]
alp has quit [Ping timeout: 272 seconds]
bk16031 has joined #nixos-dev
orivej has joined #nixos-dev
nschoe has joined #nixos-dev
bk16031 has quit [Remote host closed the connection]
bk16031 has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
teto has joined #nixos-dev
teto has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 265 seconds]
bk16031 has quit [Ping timeout: 244 seconds]
bk16031 has joined #nixos-dev
nschoe has quit [Remote host closed the connection]
nschoe has joined #nixos-dev
abbe has quit [Quit: “Everytime that we are together, it's always estatically palpitating!”]
bk16031 has quit [Ping timeout: 244 seconds]
bk16031 has joined #nixos-dev
NinjaTrappeur has quit [Quit: WeeChat 2.9]
NinjaTrappeur has joined #nixos-dev
AtnNn has joined #nixos-dev
orivej has joined #nixos-dev
AtnNn has quit [Ping timeout: 245 seconds]
bk16031 has quit [Ping timeout: 240 seconds]
bk16031 has joined #nixos-dev
bk16031 has quit [Ping timeout: 240 seconds]
alp has joined #nixos-dev
bk16031 has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
init_6_ has joined #nixos-dev
<yorick> gchristensen: can we add a hacktoberfest tag?
<puck> since https://github.com/digitalocean/hacktoberfest/pull/596 they changed hacktoberfest to be opt-in
<{^_^}> digitalocean/hacktoberfest#596 (by MattIPv4, 22 hours ago, merged): Require PRs be in a repo with hacktoberfest topic and be accepted
bk16031 has quit [Ping timeout: 258 seconds]
<V> -- on this, it'll just attract the low quality contribs
init_6_ has quit []
<MichaelRaskin> I think there are already some hacktoberpest marked-invalid PRs in Nixpkgs even
<MichaelRaskin> And… it doesn't seem like the current most pressing issue of Nixpkgs development is insufficient number of minor-improvement PRs
init_6_ has joined #nixos-dev
<yorick> MichaelRaskin: we need more reviewers?
<MichaelRaskin> That, and maybe people with deep understanding of some area and Nix to develop the domain-specific workarounds wisely
<MichaelRaskin> And maybe people good at guiding search of consensus in situations with many trade-offs
init_6_ is now known as init_6
<ajs124> what's nixpkgs definition of a mass rebuild? as in, should something like #98091 go to staging or directly to master?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/98091 (by titouanco, 2 weeks ago, open): x265: 3.2 -> 3.4
<qyliss> IME the threshold is between 1000 and 5000 depending on what types of packages are likely to need rebuilding.
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
betawaffle has quit [Ping timeout: 272 seconds]
sorear has quit [Ping timeout: 272 seconds]
manveru has quit [Ping timeout: 260 seconds]
ghuntley has quit [Ping timeout: 260 seconds]
kalbasit has quit [Ping timeout: 272 seconds]
vdemeester has quit [Ping timeout: 272 seconds]
claudiii has quit [Ping timeout: 272 seconds]
manveru has joined #nixos-dev
vdemeester has joined #nixos-dev
claudiii has joined #nixos-dev
kalbasit has joined #nixos-dev
ghuntley has joined #nixos-dev
betawaffle has joined #nixos-dev
sorear has joined #nixos-dev
m1cr0man has quit [Ping timeout: 272 seconds]
m1cr0man has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<hexa-> we had 3 low effort prs in 2y, so I think we could manage :D
<hexa-> but besides planting a tree hacktoberfest probably isn't worth it
<MichaelRaskin> We got two of them this year, though, it might be riskier now
<MichaelRaskin> I can imagine projects where upside from opting in is likely, for Nixpkgs I am sceptical
<V> nixpkgs requires actual experience
<hexa-> which is why low-effort prs easily stand out
init_6 has quit [Ping timeout: 265 seconds]
<kloenk> .
<MichaelRaskin> Frankly, a good programmer on a dare could land an update without understanding much
<hexa-> sure, because most updates are actually low-effort, no harm there
<MichaelRaskin> Like, hmm, let's bump this version, hmm, let's try to do that thing from homepage, hmmm, it complains about hash, hmmm, replacing helps, whatever
<hexa-> you could (cd pkgs/server/home-assistant && ./update.sh) && git push
<MichaelRaskin> It's just that Ryan has wrote a bot that makes sure such PRs are useful but their lack will not credibly becomes a relevant problem anytime soon
<MichaelRaskin> hexa-: now finding _that_ requires more understanding
<MichaelRaskin> Not just basic vague awareness of packaging existing, reading the homepage, and five years of grepping experience
<hexa-> hehe
<hexa-> so a good programmer then
<hexa-> either way, hacktoberfest is on a hill I want to die on
<hexa-> s/on/not/
<MichaelRaskin> Hmmm
<MichaelRaskin> That mental image
<MichaelRaskin> Hacktoberfest is on a hill I want to die on, and it makes it less comfortable to live and less convenient to defend. So, demolish it.
<hexa-> it has become opt-in, so I think we're good
<hexa-> projects that have had a good experience will continue supporting it, others won't.
<MichaelRaskin> Yeah, hopefully the worst-case scenario (which is kind of unlikely) won't materialise
<MichaelRaskin> I do not understand why this person did not just set up a few repos and sent people there. Could get a few high-starred repos to later primote whatever project!
cole-h has joined #nixos-dev
bk16031 has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
<Mic92> Are our experiences really that bad?
<Mic92> I did not had a chance to look at it this year. Last year there maybe a handfull bullshit prs
__monty__ has joined #nixos-dev
<hexa-> the outrage far outweights the bad experiences :)
bk16031 is now known as bk1603
<MichaelRaskin> We do manage to look gatekeeping enough
JJJollyjim has joined #nixos-dev
<JJJollyjim> how much CI needs to run on a pull request before it outweighs the benefit of the tree they plant
<Mic92> JJJollyjim: data centers usually are not that bad at wasting energy compared to your local computers, so I guess quite a bit.
<hexa-> tl;dr: datacenters in FRA are consuming one fifth of the citys total power consumption
<hexa-> biggest industry
<Mic92> hexa-: but is not more ecological to have all data centers in one place rather spread over the country?
<hexa-> probably
r-burns has joined #nixos-dev
<JJJollyjim> sadly those places don't often seem to be dictated by access to clean energy
<JJJollyjim> all the datacenters in new zealand are in the north island even though the south has >99% renewable energy
<JJJollyjim> (north is like 80% so it's not that bad)
<gchristensen> let's put all the datacenters in iceland
<andi-> Just less datacenters but people seem to enjoy building overhead these days..
<gchristensen> my todo app needs 11 9's of availability andi-
<andi-> gchristensen: my piece of paper has 100%
<r-burns> quick question, any idea why a nix-build would error with "No such file or directory" for a store path even thought the path exists and is in the buildinputs?
<andi-> also: client side caching if it has to be online. I'd argue anything beyond 4 9's is not important to most
<infinisil> r-burns: That's too little info to help
<gchristensen> andi-: not enough kubernetes :(
<infinisil> r-burns: Also #nixos seems like a better place
bk1603 has quit [Ping timeout: 272 seconds]
<r-burns> ah k, thanks
<andi-> gchristensen: wasn't that the thing that has like 20% overhead for keeping itself busy? ;)
bk1603 has joined #nixos-dev
<ryantm> I just ran a script that labeled all (I think) of the merge-conflicted PRs.
<andi-> why do we even need that? GH clearly knows which ones are conflicts, no?
<hexa-> you can now see it before diving into the pr
<ryantm> @andi- GH doesn't expose this information in the PR search interface
<andi-> Can we file a PR to add that feature yet?
<ryantm> andi-: No, GitHub is not open source :)
<hexa-> haha
<andi-> Why are we using it then? ;)
<andi-> Are we the product?
<ryantm> I think we are their marketing materials for proving they can handle ridiculous repos.
<JJJollyjim> "Look, nixpkgs is big! github.com/ice/deportees-list will work just fine!"
<hexa-> :<
<JJJollyjim> :(
<samueldr> ryantm: with the proper automation to remove the labels once the conflict resolved?
<ryantm> samueldr: ofborg already removes the conflict if they push to the branch.
<ryantm> samueldr: but, if I make my script run regularly, it claims to remove conflicts too.
<samueldr> good
<ryantm> The problem with ofborg's merge conflict labeling is it doesn't handle the case where master advancing introduces the conflict.
<samueldr> yeah
<JJJollyjim> what other type of conflict is there?
<JJJollyjim> i guess if the pr is based on an old master at the time it's posted?
<samueldr> old is relative, change can happen quickly :)
<samueldr> top-level/all-packages.nix changed in master, you then open your PR, oops
<infinisil> Actually github can't reasonably compute whether PRs conflict ahead-of-time
<infinisil> Because every time a new commit is pushed to master, they'd have to compute the mergability of every PR again
<infinisil> Although, they could detect which files were changed, and do something smarter then
<infinisil> But still, possibly very wasteful and slow
<samueldr> wasteful? not sure
<samueldr> it'd be quite useful
<samueldr> with some smarts added it hopefully would have been made quick enough
<infinisil> I guess they could sacrifice correctness by reasonably assuming that once PR's are conflicting, they stay that way until the PR is updated
<MichaelRaskin> Being useful is apparently not mutually exclusive with being wasteful in GitHub's view
<MichaelRaskin> File disjointness could be a reasonable heuristic, although all package additions intersect on all-packages.nix in our case
<samueldr> I don't know if a first pass listing files being changed between versions is a good "first pass" filter that filters out conflicts well or not
<MichaelRaskin> I guess for repositories other than Nixpkgs it could be pretty OK
<samueldr> I guess, MichaelRaskin, file disjointness is if base...master has changes to b/b.nix and your PR has changes to a/a.nix you know it can't be a conflict?
<samueldr> even Nixpkgs, what's the percentage of changes that touch all-packages.nix?
* samueldr should break out the big database of diffs
<samueldr> but uh, it's indisposed getting an SSD swap
<MichaelRaskin> Well, it's also nice if neither master nor any of the two PRs rename a/a.nix to b/b.nix
<samueldr> I have a way-out-of-date dump of all PRs including the diffs :)
<samueldr> git show base...master ; git show base...PR # I assumed would be used to do the intersection
<MichaelRaskin> I think at some point I fetched all PR heads from upstream remote… I gave up, though
<samueldr> my methodology was much thriftier: use the API to get the diffs, save them to postgreSQL
<samueldr> (or is it sqlite still?)
<samueldr> the goal was to then search for `--- /path/to/file` in the text index to find a PR that touched a particular file
<samueldr> as an experiment to something I wanted to write but never had the time to
bk1603 has quit [Ping timeout: 240 seconds]
<infinisil> Makes me think, probably pijul's model could compute conflicting PRs faster than git's
<MichaelRaskin> I assume that GitHub stores precomputed diffs anyway
<hexa-> if pijul ever gets ouf of its rewrite I really plan to take a look
<infinisil> hexa-: Same
<hexa-> and nest not being open source is kinda meh
<MichaelRaskin> Assuming general success of the rewrite, reasonable network sync solution like SSH being used to tunnel sync protocol, and lack of deliberate sabotage of third party efforts, I would assume that something open for small-scale hosting will appear
teto has joined #nixos-dev
r-burns has quit [Remote host closed the connection]
r-burns has joined #nixos-dev
<ryantm> Correction, I did not actually label all of the merge-conflicts yet.
cole-h has quit [Ping timeout: 240 seconds]
teto has quit [Quit: WeeChat 2.9]
<ryantm> Okay, now it is done. We have 750 merge conflict PRs, or 1/3 of all open PRs are in conflict
<samueldr> thanks for doing it
<samueldr> earlier this year I went through all the PRs with "WIP" in the title, tagged those WIP, and conversely, looked at PRs with the WIP tag, without the title containing WIP
<samueldr> (or was it last year?)
<samueldr> by these criterias we have only 1524 open PRs
<samueldr> hm... "changes requested" is something that might be helpful to filter against
<samueldr> and obviously the github search can't do that
<samueldr> only filtering for
<infinisil> Doesn't a - before the thing negate it?
<samueldr> depends on the criteria
<samueldr> it is quite inconsistent
<samueldr> some requires using NOT
<infinisil> Oh you have that in above link
<samueldr> the `NOT ... in:title` is how you negate in a textual search
<infinisil> Huh interesting
<samueldr> I made this a while back
<samueldr> hm... someone added a link in there that wasn't really relevant
* samueldr moves it
<infinisil> I should integrate such criteria into ,random-pr
<ryantm> Stale PRs search can be updated to use the stale tag.
* ryantm should make a wiki account.
<samueldr> ryantm: yeah
<samueldr> would be nice to tag `has: package (update)` on updates
<ryantm> You mean on the r-ryantm updates?
<ryantm> r-ryantm doesn't have permission to label things
<samueldr> on any with package upgrades
<ryantm> I thought OfBorg already did that.
<samueldr> I don't see them being applied to recent PRs for package updates
__monty__ has quit [Quit: leaving]
alp has joined #nixos-dev
drakonis has quit [Quit: ZNC 1.8.1 - https://znc.in]
codyopel has joined #nixos-dev
abathur has quit [Quit: abathur]
abathur has joined #nixos-dev