Packaging upstream master

[Colin Watson]

On Mon, Oct 19, 2020 at 12:30:37AM +0200, Petr Vorel wrote:
> I'm familiar with git and (to some extent) with upstream sources, but not that
> much with gbp (which I suppose is used).

No, the grub2 packaging uses git-dpm, not gbp.  Don't attempt to use gbp
for the grub2 packaging: it will make a mess.

> I also have only basic knowledge of Debian packaging structure (rules,
> changelog, etc, but not having real packaging done).

That may mean you'll find this pretty challenging, I'm afraid, as grub2
is not a simple package and there are lots of ways in which a new
upstream release might require corresponding packaging changes.

> What would be the quickest approach to drop most of the patches, but keep some
> (I'd keep bare minimal, e.g. skip-grub_cmd_set_date.patch to avoid rebasing
> patches I does not need - I expect recreating patches from time to time) and
> import upstream tarball grub-2.05.origin.tar.gz (created with make dist,
> renamed).

https://alioth-lists.debian.net/pipermail/pkg-grub-devel/2014-January/013883.html
explains my use of git-dpm in general.  To import a new upstream
repository, you do something like this:

  git-dpm import-new-upstream -p <upstream commit> --pristine-tar-commit --rebase-patched <path to upstream tarball>

Now you are in a normal git rebase of the Debian patch series on top of
your chosen upstream commit (with an extra commit added by git-dpm to
represent the differences between the commit and the tarball you gave
it); resolve or skip patches as you wish.  When you're done, you'll want
to update master with the results of the rebase (git-dpm does this by
constructing a specialised sort of merge commit that also includes
equivalent changes to debian/patches/).  git-dpm will already have made
a commit to master that just adds the new upstream tarball, and I
normally prefer to fold the rebase into that, so:

  git-dpm update-patches --amend

You'll probably also want to make some changes to debian/changelog and
"git commit --amend" those into that commit, or at least that's what I
normally prefer to do when integrating a new upstream release.

If you get it wrong and want to *amend* that merge commit (which should
generally be reserved for things like a broken rebase), then:

  git-dpm checkout-patched
  git rebase -i upstream
  ...
  git-dpm update-patches --amend

Or you can add more commits on top in the more usual way without
amending history:

  git-dpm checkout-patched
  # rebase or commit or whatever
  git-dpm dch 'Description of fix'

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]