Please import kexec-tools 1:2.0.10-2 source package from Debian sid

[Nish Aravamudan]

On 31.05.2016 [17:42:36 -0700], Nish Aravamudan wrote:
> Hello Louis,
> 
> On 30.05.2016 [12:24:21 +0200], Louis Bouchard wrote:
> > Hello,
> > 
> > In order to merge the latest kexec-tools, I would need the latest
> > kexec-tools source package imported into
> > https://code.launchpad.net/~usd-import-team/+git.
> 
> Apologies for the delay on my end in replying!
> 
> After some discussion late last week with Robie, we decided to
> re-formulate the algorithm to make it simpler and more consistent. This
> resulted, though, in throwing out a lot of code (good) but re-testing
> the cases I have already encountered (~bad). I'm nearly done with the
> testing now, and hope to push out a kexec-tools tree you can use by EOD,
> or first thing tomorrow. I will reply here when it's available.
> 
> I would appreciate a review of the tree once it's available, as well,
> for correctness. In particular, the script is importing the full
> publishing history from LP, which is quite a lot of data. I have been
> eyeballing the resulting gitk graphs and finding errors in the
> code/algorithm that way, but that's obviously error-prone.

I have pushed a tree to
https://code.launchpad.net/~usd-import-team/ubuntu/+source/kexec-tools/+git/kexec-tools.

FWIW, the 'new' algorithm attempts to assert:

  a) The parent->child git relationship implies an intention that any
  changes contained in the parent are contained in the child (code isn't
  being lost). This isn't an assertion enforced by the algorithm, but is
  a semantic expectation (my phrasing).

  b) A commit may have up to two parents (and as few as zero). One
  parent may be nearest imported changelog ancestor, by which I mean
  iterating backwards along the changelog versions until an imported
  version is found. The other parent may be the last version published
  in the same series (if it is not the first version in a series/pocket
  pair) or in a parent series if it is. The parent series is the <prior
  series>/release for release pocket versions and the series/release
  pocket for non-release pocket versions. The prior series is as defined
  in the launchpadlib objects for series.
  In cases where these two parents are identical tree-contents, we favor
  the publishing history (that way, for instance, yakkety's first
  version follows xenial's not xenial-proposed where it might have first
  appeared).
  There might be 'pathological' cases where this will not work, but we
  will try to resolve them as we encounter them.

Note that if you're looking for an ubuntu/devel head/tag, you won't find
one (yet). It should be sufficient for now to use ubuntu/yakkety, and I
will work on adding back in ubuntu/devel tagging into the algorithm.

Thanks,
Nish