Backporting a trivial commit

Help
1

Hi all,

Context: I’ve made a couple minor PRs to nixpkgs, but I haven’t backported anything yet.

When running nixos-rebuild, I noticed a warning:

 /etc/systemd/system/snapper-boot.service:15: Unknown key name 'type' in section 'Service', ignoring.

Digging in a bit, I found that a fix was merged into master a few months ago: snapper: fix "type=oneshot" error in snapper-boot.service · NixOS/nixpkgs@7a6c0bb · GitHub

It looks like this is in master and unstable, but I’m running 22.11:

$ git branch --contains 7a6c0bb4687b5e135e759bd7bc9d15b8f3b97030
* master
  nixpkgs-unstable

This is a pretty trivial change, but it seems like it would be reasonable to backport to 22.11 – I can’t imagine it could break anything (of course now that I’ve said that…).

Reading https://ryantm.github.io/nixpkgs/contributing/submitting-changes/#submitting-changes-stable-release-branches-manual-backports – it looks like the process is just to create a branch, cherry-pick that commit, then create a PR into 22.11.

  • Does my understanding of the process seem right?
  • Is there any immediately obvious reason this wouldn’t seem reasonable to backport?
  • In general, should I try to backport something like this to additional stable branches? If so, would I manually go through the above steps for each branch of interest, or is there a better approach?

TIA for any suggestions!

2

This seems like something which should have been backported to 22.11, correct. I think most package maintainers use unstable as their daily driver, so sometimes these things can get missed, thanks for reporting it.

nixpkgs has some automation on GitHub to automatically create backport PRs (by adding a label on the PR), I triggered it on snapper: fix "type=oneshot" error in snapper-boot.service by luochen1990 · Pull Request #211044 · NixOS/nixpkgs · GitHub (original fix on master) and it created [Backport release-22.11] snapper: fix "type=oneshot" error in snapper-boot.service by github-actions[bot] · Pull Request #225818 · NixOS/nixpkgs · GitHub . If the CI scripts are happy with that change I’ll just merge it, it’s a fairly trivial fix.

1 Like
3

Thanks for creating the label.

AFAIK only people with write access to the repo will be able to create labels, so I don’t think this is something I could have done.

Do you have any input on the approach I outlined above? Would that have been the best way to be helpful on my end?

I imagine starting a thread here is not the most efficient approach :laughing:

4

Making a cherry-pick PR yourself following the instructions you linked would have worked. Commenting on the original PR that fixed the problem in master and asking for a backport would likely also have been a good option, and it’s likely lower effort for everyone involved since automation does most of the work.

1 Like