[Pkg-libvirt-discuss] Updating libvirt to 5.2.0

[Andrea Bolognani]

On Mon, Apr 01, 2019 at 10:09:44AM +0200, Guido Günther wrote:
> Hi,
> On Sun, Mar 31, 2019 at 08:42:49PM +0200, Andrea Bolognani wrote:
> [..snip..]
> > I've started looking into the current debian/experimental branch
> > and I have a question already: how do you usually refresh patches?
> 
> The machinery here uses:
> 
> gbp import-orig --uscan
> gbp pq import --time-machine=3
> git rebase debian/experimental
> <manual conflict resolution here if necessary>
> gbp pq export --commit
> 
> Or when importing new patches
> 
> gbp pq import --force
> git cherry-pick <from-libvirt-upstream>
> gbp pq export --commit

Okay, that's very similar to what I eventually came up with. I'll
try some more stuff so that I get comfortable with it.

> > For my other packages I usually have the .pc/ directory committed,
> > which is not the case for libvirt, and I use 'quilt push' + 'quilt
> > refresh' after merging a new upstream version, but doing so in the
> > libvirt repository results in changes like
> 
> This can also be done with plain quilt since pq aims to be compatible
> with that.

Unless I'm missing something, not quite. From a fresh clone:

  libvirt$ quilt next
  No series file found

Compare this with what happens when the same operation is performed
from a fresh clone of spectrwm, one of the packages I maintain:

  spectrwm$ quilt next 
  debian/patches/U01-install-more-files.diff

The difference is that the critical files quilt needs to locate the
patch series are committed along with the rest of the packaging[1]:

  spectrwm$ cat .pc/.quilt_patches
  debian/patches
  spectrwm$ cat .pc/.quilt_series
  series

I remember having a shell snippet in my ~/.quiltrc that allowed it to
automatically locate the patch series by trying a few sensible
places, but that meant anyone who had not configured quilt in advance
could not work with a fresh clone, so I changed approaches.

The 'gbp pq' approach looks cleaner, from what I've seen, but it also
has the disadvantage of requiring a bit of work on the user's side.
Perhaps that could be improved by documenting the expecta---oh, wait,
I've just noticed there's a debian/README.source file in the
repository. And it explicitly mentions 'gbp pq', along with detailed
information on its use. Nevermind :/

> > I tried generating the branch locally with 'gbp pq import' followed
> > by 'gbp pq rebase' and 'gbp pq export', and it seemed to have
> > worked and matched your own patch refreshing commits... Is this the
> > expected workflow?
> 
> That's at least what I'm doing over here but quilt should work as well
> if you prefer that.

Nah, it's better to follow the established workflow. Plus using quilt
directly would mess up all the existing patch headers :)


Thanks for taking the time to answer. I'll play with the whole thing
a bit more over the course of the next few days; in the meantime,
feel free to 'gbp import-orig' libvirt 5.2.0 once it is released
tomorrow or so.


[1] https://salsa.debian.org/debian/spectrwm/tree/master/.pc
-- 
Andrea Bolognani <eof at kiyuko.org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-discuss/attachments/20190401/9a2b054a/attachment.sig>