[Pkg-libvirt-discuss] Updating libvirt to 5.2.0

Andrea Bolognani eof at kiyuko.org
Sun Mar 31 19:42:49 BST 2019


On Thu, Mar 28, 2019 at 01:32:12PM +0100, Guido Günther wrote:
> On Wed, Mar 27, 2019 at 11:39:48PM +0100, Andrea Bolognani wrote:
> > I forgot to mention, I'm not a Debian Developer and I don't have (at
> > least I don't think?) push permissions to libvirt-team/libvirt.git,
> > so I would prepare this as a Salsa merge request and then someone
> > else would have to review, merge and upload the result.
> 
> I do have that mostly automated and merging pristine-tar and
> upstream/latest just makes things a tad more complicated so what I just
> did is:
> 
>   - import and upload 5.1.0
>   - then run
> 
>       gbp import-orig --uscan
> 
>      to get 5.2.0~rc1 on the above branches.
> 
> So if you want you can go from there and handle debian/experimental and
> I'm happy to pull that in via a MR.

Right. I clearly failed to consider the complications caused by
having the changes required to import a new upstream version spread
over three separate branches, which is not something that a merge
request-based workflow supports natively...

Still, if you have to import the upstream release in advance, that
requires more coordination and more work on your part (in addition
to reviewing the changes and preparing the upload), which kinda goes
against the whole idea of spreading the load.

Then again, if all goes well I plan to do this more regularly going
forward, so hopefully after a few times not messing it up terribly
I could be granted commit rights to the libvirt repository :) making
all of the above moot.

> We're uploading to experimental to keep unstable free for any pending
> bug fixes to 5.0.0 that should go into buster.

Another thing I forgot to mention in my message but yeah, we're on
the same page here.

> Sounds good?

I've started looking into the current debian/experimental branch
and I have a question already: how do you usually refresh patches?

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

  --- a/debian/patches/Disable-gnulib-s-test-nonplocking-pipe.sh.patch
  +++ b/debian/patches/Disable-gnulib-s-test-nonplocking-pipe.sh.patch
  @@ -9,10 +9,10 @@ Issue reported upstresm.
    gnulib/tests/test-nonblocking-pipe.sh | 4 ++++
    1 file changed, 4 insertions(+)
  
  -diff --git a/gnulib/tests/test-nonblocking-pipe.sh b/gnulib/tests/test-nonblocking-pipe.sh
  -index dd692be..9690791 100755
  ---- a/gnulib/tests/test-nonblocking-pipe.sh
  -+++ b/gnulib/tests/test-nonblocking-pipe.sh
  +Index: libvirt/gnulib/tests/test-nonblocking-pipe.sh
  +===================================================================
  +--- libvirt.orig/gnulib/tests/test-nonblocking-pipe.sh
  ++++ libvirt/gnulib/tests/test-nonblocking-pipe.sh
   @@ -1,5 +1,9 @@
    #!/bin/sh

so I guess you're doing it differently? I see a 'gbp pq' command
exists, and there's some configuration for it in debian/gbp.conf,
but from the man page I seem to understand there should be a git
branch where the patches are stored, and I can't see it on Salsa.

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?

Thanks and sorry for the slight rambling :)

-- 
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/20190331/df6ef581/attachment.sig>


More information about the Pkg-libvirt-discuss mailing list