Nixpkgs-update/r-ryantm logs

I manually run it every couple weeks or so. I’d like to automate it but I’m a little scared to spam everyone with low quality PRs.

I expect this to work because it uses the name of the package from the nixpkgs JSON dump returned by the repology API.

I think it would be great if it could be run daily or even hourly - there’s no reason why humans should do the trivial work :).

Have you seen many low-quality PRs produced by it? And what consitutes a low-quality PR in this case?

It takes it 2 to 3 days to get through all the packages as is. This could be sped up drastically by maintaining a database of failed outPaths.

I’m just worried that the bot might not have enough checks in place that it submits some nonsense PRs. I think there is some aspect that nixpkgs-update is introducing extra work for maintainers, because it is catching all the updates from hyper-actively updated packages, and I want to keep the overall quality of nixpkgs-update PRs very high so they are easy to merge and to trust that they will be good.

Another reason I like to manually monitor it is that I am usually developing nixpkgs-update and I don’t have much of a test-suite, so if something goes wrong, I like to catch it through manual monitoring. If I work on improving the test suite, I think I’ll feel much more comfortable making it automatically run continuously.

1 Like

Thanks, all of that sounds very reasonable.

I wonder if it could automatically close (or if not privileged enough, label as stale somehow) PRs that are superseded by a newer one. I understand that this would be adding a lot of responsibility and logic into it though.

But I think that this 's an extremely valuable tool that is showing the way we need to go to make nixpkgs scale better.

2 Likes

2019-05-11 log

2019-06-16 log

Thanks! Apparently Dafny is out of date. Update is here: dafny: 2.1.0 -> 2.3.0 by layus · Pull Request #63575 · NixOS/nixpkgs · GitHub.

Another one fixed: xtrace @ xtrace: 1.3.1 -> 1.4.0 by layus · Pull Request #63592 · NixOS/nixpkgs · GitHub

Could we consider setting up a tag in nixpkgs for PR related to this ? Or maybe we could agree on mentioning @r-ryantm ?

@layus I’m not sure I understand what the tag or mention is about. Can you explain it more?

Well I think it is nice to see what PRs are related to your log of failed updates, and I do not want to spam the mailing list with all my PRs (just like the two above).

Ah, okay. Well @ing r-ryantm is fine with me. I monitor the bot’s notifications.

2019-07-01 log

2019-07-15 log

@ryantm got any more of those logs?
scratches neck

@jonringer Ask and yee shall receive:

20190803 log

1 Like

Noticing:

2019-08-06T10:39:57 vim 8.1.1432 -> 8.1.1794
2019-08-06T10:40:02 FAIL nix-env -q failed to find package name with old version

Vim version in nixpkgs is 8.1.1547 currently so I guess that’s there might be some internal state that’s out of sync. That version also has a bug with the quickfix window, which I’ve hit a few times in the last while. So I’m motivated to help fix the issue.

Does it disrupt this automatic process if I were to submit a vim update PR? Similar to how the version is currently out of sync? If so I can wait for a fix here as I’ve got the latest release running locally for myself, but I imagine others might like the fix too.

@wkral

Right now, the bot will only update a package if the version in nixpkgs master exactly matches the “old” version. It gets the “old” version from the current nixpkgs unstable channel. I’d like to relax this constraint in the future.

If a manual PR disrupts the automatic process, that’s a bug with the automatic process. Please make your PR!

20190817 log

1 Like

Thanks for working on this. Looking forward to a resolution on this

@ryantm it’s the time again, feed me some logs :slight_smile:

2 Likes