Steps to find a commit with cached version of package

Help
1

Hello, can somebody help me with steps to find cached version of a package?

Taking for example the recent onedrive bump to 2.3.13.
This is the pull request- https://github.com/NixOS/nixpkgs/pull/77854

At the end of it there is a statement that says- alyssais merged commit https://github.com/NixOS/nixpkgs/commit/96d2790061f6d34af01b7dde5f17662305d87946.

This happened twelve days ago.

Now I go to channel history here https://channels.nix.gsc.io/nixos-unstable/history and do a log search towards the end and find using date -d @<timestamp> that there are 11 nixos-unstable releases since then. I believe a nixos-unstable release also caches artifacts.

I’m using a pretty recent build 8a9807f1941d046f120552b879cf54a94fca4b38 (the third last line in the history above). Not the last because I don’t understand the caching mechanism. This is 4 days old. However, I’m still having to rebuild onedrive locally.

Could you give me pointers about next step? How do I figure out why I need to build this locally? I want to use a cached version and want to find a commit which would give me one.

1 Like
2

Builds are done by hydra. Hydra periodically builds most easily reachable packages from nixpkgs. When enough packages build correctly, that commit becomes the new xxx channel. Depending on the channel, the subset of required packages is different.

To inspect build state for a given package, you can search it in hydra. Searching for onedrive you get plenty of job and builds corresponding to that.

image
image960×605 52.5 KB

Lets look at the nixos:trunk-combined entry because the only other nixos-related entry is staging, which does not update any channel (it’s kind of an integration branch for large changes).

image
image884×265 21.7 KB

There you see that the package was in pain, and failed for some time before being fixed on the most recent build. An you can also see that 2.3.13 wa only available in the last two builds. Looking at [the oldest one] you see that it failed because the dependencies llvm and dmd failed, and so the build of that package was not attempted.

Back to the most recent build:

image
image890×605 38.8 KB

You see that the changes between this build and the previous build consist in a bump of the nixpkgs revision from e59dcf to 766b78. To expand that 766b78, go to the inputs tab where the revision is spelled out entirely: 766b78841f2342e325e0d801c01ab9d652150a67

Now, on that commit I can guarantee you that you will have a cached version of onedrive, because as you see it has already been built by hydra. You could also find it for other commits, because

  1. there usually is a span of commits that describe the same package (when the changes are irrelevant to that package)
  2. Other projects than nixos:trunk-combined may build that package at different revisions in nixpkgs.

Looking at the trunk-combined jobset, we see that it made its way through nixpkgs commits:

image
image880×514 51.7 KB

The commits listed here match exactly what you have found in the channel history, except for the last one which, as we know now, is the only one that matters to you. 766b78841f2342e325e0d801c01ab9d652150a67 will become the new channel when the evaluation finishes. You can wait a bit, or force your rebuild commands to use that commit. It’s up to you. The good news is that you already know that your package is part of the happy +24 packages that failed before but work now :slight_smile:.

11 Likes
3

Thank you for taking the time to write such a detailed explanation (and thanks to whoever wrote Hydra too!).

I was able to easily follow and reproduce the commit id which gave me a cached version of onedrive!

1 Like