Re: RFS: flint -- C library for number theory
Hi,
Le 11/08/2014 00:32, Felix Salfelder a écrit :
Hi Julien.
i see your points. let me try to clarify things a bit. sorry if i am
annoying the other receipients.
On Sun, Aug 10, 2014 at 10:53:10PM +0200, Julien Puydt wrote:
(1) the manpage says git-dpm uses a "patched" branch, and I don't see it in
"git branch -a"
the patched branch is accessible with 'git-dpm checkout-patched'.
pushing it to the public repo is unnecessary/redundant (and harmful, as
someone might expect it to retain history). once the package is ready,
you may use "git-dpm tag" to add a shiny immutable tag to it.
(2) git-buildpackage is happy with the current packaging
because it doesn't seem to care about how patches are organized.
(3) pristine-tar has no problem checking out upstream tarballs
dito.
(4) we're discussing for a single patch which is going away in the next
version
it's about whether the patch has been committed to the packaging branch
or to an upstream+patched branch. maybe you know how to rebase a
missorted patch to a new upstream version. i don't. git-dpm doesn't
know, and presumably git-buildpackage is not meant to do such things.
(yes, there is gbp-pq, and i admit that i do not understand how it is
supposed to work. my guess is, it cannot rebase in this situation
either).
the patch in question appears to be a cherry-pick from future upstream,
so it has been a git commit from the beginning. git will know how to
rebase it back to upstream.
It's a patch in a forked tree on github, there has been a pull request,
and upstream answered they will take it. It isn't in upstream yet.
(5) I can't help but notice that git-dpm complains about two files
containing non-debian change... and one of them is fmpz/test/t-invmod.c
which is pristine upstream!
fmpz/test/t-invmod.c has been edited in 90b70c2cce, a commit to the
master (packaging) branch. this is the whole trouble.
Ah, it looks at the whole history, so even if things get back to pure
upstream, it still complains.
I really have the impression that only git-dpm is unhappy with my package,
and that the only reason why it's complaining is that I don't use it. It
would be nice to use it, but (4) says it might be quite overkill, and (5)
says git-dpm is going to make it hard, since it won't even recognize
pristine upstream for what it is.
you do not have to use git-dpm to not commit upstream changes to the
debian branch. i don't see how the total number of patches changes this
or how git-dpm is making it any harder.
A whole thread says it's making it harder... and I committed upstream
changes in there because I found committed changes there: I usually
don't do that.
So, what should I do?
1 revert the commit in question
2 commit the change on top of the upstream branch
3 merge the patched upstream branch into master
4 update debian/patches
1. if I do, I'll still have the old patch applied...
2. which change?
3. see above: it's not upstream yet
4. won't git-dpm get angry if I go my usual cp/rm/vi route?
it doesn't matter much if you use git-dpm or not. doing things manually
is just a bit more involved. for example
Doing things by hand actually works...
>
2 find the current patched branch... (here: just take upstream and
forget about that one patch)
3 what was the right strategy option again? -srecursive -Xtheirs. maybe
4 git show will show your commit, but will the format be ok? don't
forget to update series.
independendly, you may want to plough debian/.git-dpm. expect some
questions from a clueless about how to do stuff without git-dpm...
Ploughing that file doesn't sound like something I would like to do.
Ok, here is what I have done to see if it would work (not pushed):
1. revert my patch
2. try "git-dpm status" -- it complains about not finding the upstream
2.4.4 tarball ;
3. generate said tarball for git-dpm (so much for doing things by hand
being more involved!)
4. try "git-dpm status":
git-dpm: ERROR: 'upstream' does not contain previously recorded revision
'f14355e9070e235a68b933b3da8c238468e9a0e2'!
Indeed, looking at the various branches, I see:
- upstream is still at tag upstream/2.3
- pristine-tar got the 2.4.4 tarball
So even without my culprit commit, I think things were already in a bad
state...
Snark on #debian-science
Reply to: