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 :)
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
vcs-pkg-discuss mailing list