patches-applied historical imports (usd import)

[Guido Günther]

On Mon, Jan 09, 2017 at 02:41:48PM -0800, Nish Aravamudan wrote:
> On 09.01.2017 [15:36:08 -0700], Sean Whitton wrote:
> > Hello Nish,
> > 
> > On Mon, Jan 09, 2017 at 02:15:53PM -0800, Nish Aravamudan wrote:
> > > > Have you considered obtaining the patches-applied tree using
> > > > `dpkg-source -x`?  That applies the patches without using quilt(1), so
> > > > might workaround this sort of bug (if it didn't, the package would
> > > > FTBFS).
> > > 
> > > Well, I would do that, but afaict, there is no way to tell dpkg-source
> > > to only apply one patch at a time? This is to go from a
> > > patches-unapplied state to the fully patches-applied state, commiting
> > > each patch application into the repository. Perhaps I missed a flag in
> > > the manpage, though?
> > 
> > Good point, I don't think it can be done.
> > 
> > It's really quite a serious problem for quilt to be choking on patch
> > queues.  How many packages did you see with this?  It might be that we
> > could get it fixed before you finalise your tool.
> 
> Agreed, it's a bit perplexing when it happens :)
> 
> Honestly, we don't see it with any recent packages, afaict. And I think
> of the packages I've manually been importing lately, we only ran into
> the specified issues with util-linux and samba. I am about to start
> 'automated' test imports based upon the publishing records in Launchpad
> as a test for a subset of packages my team cares about, that will
> probably give us better data :)

Great. I ran a import (gbp import-dsc dscfile && gbp pq import) of
Debian unstable during dc16 with different gbp versions (ignoring
history data for the moment). With the most recent gbp at that time
(0.8.0) it looked like:

all: 24457
errors:
    all: 429
    import-dsc:
      errors:
        all: 219
        fetch_source: 193     (download failures, can be ignored)
        pristinetar_delta: 20   
        permission_denied: 3
        no_tree_found: 1
        others: 2
    pq-import: 
      errors:
        all: 210
        not_apply: 71
        not_in_index: 81
        already_in_index: 13
        corrupt_patch: 29
        others: 16

The not_apply, not_in_index and already_in_index errors stem from git
apply behaving differently than patch (some of the bugs already filed,
some pending). It would be great to see some numbers with your import to
see the differences since I assume that errors from pristine-tar or
git-apply can't happen there.

I also need to file bugs for the failing pristine-tar imports so I
kicked of a new run since bot pristine-tar and gbp have changed quite
a bit since then.

Cheers,
 -- Guido

> 
> And note, it is just when building the 'full' historical repository
> ('full' in quotes only because Launchpad's publishing history data only
> goes back so far), that we see this. So, while it probably (maybe almost
> guaranteed by better tooling and development processes in Debian &
> Ubuntu) won't happen any longer, I would like to agree on what to do
> with those cases where something like this is encountered in the past
> (and honestly, 'skipping' them is the easiest, but then there is the
> question of what to do with the branches as mentioned in my original
> e-mail).
> 
> -Nish
> 
> -- 
> Nishanth Aravamudan
> Ubuntu Server
> Canonical Ltd
> 
> _______________________________________________
> vcs-pkg-discuss mailing list
> vcs-pkg-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
>