Cool!

Can I suggest that you

1. Add yourself to lib/maintainers.nix in a separate commit (just force push the rebased branch)
2. git tag / release your projects and update the Nix files to refer to the tag/version instead of an (arbitrary) commit.

Alright, will do. How should I format the commit message of the commit that only adds me to maintainers.nix? (Amusingly, I had three commits at first, but then rebased after reading the contributions guidelines, and their notes about commit message formats)

Hehe, yes, I guess there is no standard for the lib/maintainers.nix file. (Looking at "git log -- lib/maintainers.nix" shows all kinds of formats.) I guess I'd use "maintainers: add X" or "Add X as maintainer". Your choice :-)

Hmm, I made some changes to use the (newly released 😄) 1.0.0 releases of the two tools, but kind-of expected I might have to change the hashes too... however, when I try to build the derivations after making changes to them, I simply get nix-build printing the path to the old derivation's output... even though the version changed, and the path has the old version in it!

I'm not entirely sure how to properly rebuild the derivations, what am I missing here? (For future reference/my own learning, if nothing else!)

% nix-build -A hexd
/nix/store/2q8wasr5zxn1cfp9jpgrfy3nd8clrcvq-hexd-2017-11-12
% grep 'version =' pkgs/tools/misc/hexd/default.nix 
  version = "1.0.0";

Did you remember to update the derivation name/version, which in turn makes a change in the url passed to fetchurl?

If you did, then it's a bug. If you didn't, it's a feature. (Oh, wait. You're using fetchFromGitHub... Well, it's just a wrapper around fetchurl.)

fetchurl re-downloads if the name or sha256 changes. Most often "name" is not passed directly to fetchurl, instead it takes "name" from the basename of the URL.

If there is no change in inputs for fetchurl, it returns the cached artifact (which is uniquely identified by its hash).

I mostly change the first few chars of the hash to "00000...." and rebuild the package. Then update the hash according to the error message. There is also a tool called nix-prefetch-url which can be used.

I did update the version in the derivation (that's why I put the grep line there in the shell excerpt, showing it's different from the one in the path, which is a date). Actually... okay, I'm really confused now. Changing the hash to an obviously incorrect one:

firefly@as ~/local/repos/nixpkgs
% vim pkgs/tools/misc/hexd/default.nix  # updating the hash to a dummy one
firefly@as ~/local/repos/nixpkgs
% nix-build -A hexd  # still prints the path to an old, cached build in the store!
/nix/store/2q8wasr5zxn1cfp9jpgrfy3nd8clrcvq-hexd-2017-11-12
firefly@as ~/local/repos/nixpkgs
% git diff
diff --git a/pkgs/tools/misc/hexd/default.nix b/pkgs/tools/misc/hexd/default.nix
index b080e23b..a3de5f62 100644
--- a/pkgs/tools/misc/hexd/default.nix
+++ b/pkgs/tools/misc/hexd/default.nix
@@ -10,7 +10,7 @@ stdenv.mkDerivation rec {
     owner = "FireyFly";
     repo = "hexd";
     rev = "v${version}";
-    sha256 = "1lm0mj5c71id5kpqar8n44023s1kymb3q45nsz0hjh9v7p8libp0";
+    sha256 = "zzzzzzzzzzzzzzzzzzzzz4023s1kymb3q45nsz0hjh9v7p8libp0";
   };
 
   makeFlags = [ "PREFIX=$(out)" ];

I have no clue why the old, cached build is used here, now...

I tried building with nix-build -v -A hexd, and don't even see my derivation being evaluated, somehow... I redirected stderr of the above and the same for xxd, and this is how they differ:

% diff /tmp/xxd.build.err /tmp/hexd.build.err 
34,36d33
< evaluating file ‘/home/firefly/local/repos/nixpkgs/pkgs/tools/misc/xxd/default.nix’
< evaluating file ‘/home/firefly/local/repos/nixpkgs/pkgs/applications/editors/vim/default.nix’
< evaluating file ‘/home/firefly/local/repos/nixpkgs/pkgs/applications/editors/vim/common.nix’
95,96c92
< evaluating file ‘/home/firefly/local/repos/nixpkgs/pkgs/development/libraries/ncurses/default.nix’
< derivation is /nix/store/za3d6w6fi4w4pnkfl29mpbg8kvwzyicf-xxd-8.0.1257.drv
---
> derivation is /nix/store/qjwb50la23smwvmdb681yk90pk85586p-hexd-2017-11-12.drv

I'm expecting my nixpkgs/pkgs/tools/misc/hexd/default.nix to be evaluated here, surely? Or am I missing something silly here?

There is one odd thing here. Your derivation still outputs "/nix/store/...-hexd-2017-11-12". I think that should have been "...hexc-1.0.0", if you updated the version attribute.

The only reason I can think of causing fetchurl to return the old source package is if the basename of the url did not change.

This is a bit confusing, but it is intentional. c3255fe was made with the purpose to make all sources with the same content to be considered the same — in the case of fetchFromGitHub regardless of the owner, repo, and rev. Nix will not redownload your source and will not rebuild your derivation unless you change the hash. (Or it will rebuild your derivation from the old source if you change the derivation without changing source hash.) You may use nix-prefetch-url '<nixpkgs>' -A hexd.src to redownload and recompute it.

@orivej: Thanks!

@orivej Hmm, nix-prefetch-url does appear to download and print the hash.. however, changing the hash to a dummy value (all 'z', i.e. sha256 = "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz") seems to still just print the cached build's store path. I'm expecting a hash mismatch error in that case, surely?

Could you attach the full /tmp/hexd.build.err?

hexd.build.err.log

This is stderr of nix-build -v -A hexd, issued after changing the hash in the derivation to all z's.

Edit: oh, with -vv I see this at the end:

...
instantiated ‘unzip-6.0’ -> ‘/nix/store/fs0pqs584ka5hj2bfb915zy2bdmd4nxl-unzip-6.0.drv’
instantiated ‘source’ -> ‘/nix/store/hkyfbnzd2kjalq2bdqj81pvazpx1vg0j-source.drv’
instantiated ‘hexd-2017-11-12’ -> ‘/nix/store/qjwb50la23smwvmdb681yk90pk85586p-hexd-2017-11-12.drv’
derivation is /nix/store/qjwb50la23smwvmdb681yk90pk85586p-hexd-2017-11-12.drv
/nix/store/2q8wasr5zxn1cfp9jpgrfy3nd8clrcvq-hexd-2017-11-12

Here's the full log with -vv, for good mesaure: hexd.build-vv.err.log

And what is the output of nix-instantiate --eval -A hexd.meta.position?

... oh. Oh dear, that was silly of me. Before deciding to put these packages in nixpkgs I was experimenting with declarative management of user packages, and had put my hexd and pixd packages inline in my ~/.config/nixpkgs/config.nix in packageOverrides--and apparently promptly forgot about that when I started moving them out to nixpkgs.

Sorry about that. I'm getting the expected hash conflict now with the all-z hash, and getting the expected output after changing to the correct hash. Thanks for helping me debug this :)

Also, I've now built the most recent versions (after switching to using the version tags) and they do build and work properly with the most recent force-pushed rebase.

Applied to master (bdce932 and 2 parents). Thanks!