This makes #48008 unnecessary right?

As a nitpick: Please use imperative in your commit messages (e.g. gramps: add support for recommended packages). You can change that with an interactive rebase (git rebase --interactive HEAD~2, then mark the packages you want to edit with r).

This makes #48008 unnecessary right?

It does. Sorry, I wasn't expecting that behaviour from the PR process.

As a nitpick: Please use imperative in your commit messages (e.g. gramps: add support for recommended packages). You can change that with an interactive rebase (git rebase --interactive HEAD~2, then mark the packages you want to edit with r).

Noted, thanks.

Yeah for small changes like these which depend on each other it makes sense to combine them in one PR.

Also please remove the dot at the end of the commit messages.

Understood, I'll make sure I don't submit with those in future. Does the full stop break a process somewhere?

No, its just a matter of standardization.

I'm assuming you don't need me to edit these commit messages?

I did assume you'd do that, which is why I explained how to do it. Any reason not to?

@timokau I've recommitted without the ending full stop. I appreciate the tuition in use of `git1, never done an interactive rebase before.

Only reason I wouldn't have done is because it seems like something I'd let slide once and just let them know. There's nothing in the contributing guide that says to not have a closing period, only for meta.description. I'll propose a clarification in that to help others.

Thanks again for the git tips.

I personally think my job as a reviewer is it to hold the people whose contributions I review to a high standard. I make plenty of mistakes when contributing myself and appreciate when the people reviewing my code do the same. Unfortunately there are no clear review guidelines for nixpkgs, so someone else may review differently. Fixing a commit message should not take very long. Maybe the first time it does, but aferwards you'll know your tooling better. I hope I don't sound antagonistic, I'm grateful for your contribution.

These rules aren't in the contribution guide, but they are general git convention. It couln't hurt to mention that in the contribution guidelines though.

Thanks for fixing the punctuation. The commit messages are still not in imperative ("add" instead of "added") and you added a merge conflict I don't understand though (you can also drop that with an interactive rebase).

Should be imperative now @timokau, I saw you'd renamed the PR so lost track and completely forgot to change the commit message, sorry.

No problem holding me to a high standard, I'd do the same, just with a different approach. I'll read the general git convention link as I'm still very green when it comes to using git.

Everything look OK now? I think I managed to drop the merge conflict. Really like this interactive rebase thing!

@GrahamcOfBorg build gramps

Looks perfect, thank you for the contribution and your patience with the review :) Merge pending on the bots approval.

No attempt on x86_64-darwin (full log)

The following builds were skipped because they don't evaluate on x86_64-darwin: gramps

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)

Attempted: gramps

test_nodeathdate: 0.28

test_peopleprivate: 0.23

test_peoplepublic: 0.23

test_personwithincompleteevent: 0.39

test_relationshipbookmarks: 0.23

Success on x86_64-linux (full log)

Attempted: gramps

test_nodeathdate: 0.53

test_peopleprivate: 0.45

test_peoplepublic: 0.44

test_personwithincompleteevent: 0.75

test_relationshipbookmarks: 0.46