tox has a new upstream so I decided to take the opportunity to A/B git-dpm and
gbp-pq on a more complicated, but probably common task, simply stated::
upgrade to the new upstream, refresh the patches, handling any conflicts, and
regenerate a source package for testing.
TL;DR: You can make things w
On Thursday, September 04, 2014 15:40:42 Barry Warsaw wrote:
> That gets you a source package, but the binary package FTBFS because one
> additional test cannot be run during the build process (there's a DEP-8 test
> for full coverage). Now though, you *must* commit or stash the d/changelog
> chan
On Thursday, September 04, 2014 16:05:53 Scott Kitterman wrote:
> On Thursday, September 04, 2014 15:40:42 Barry Warsaw wrote:
> > That gets you a source package, but the binary package FTBFS because one
> > additional test cannot be run during the build process (there's a DEP-8
> > test for full c
On Sep 04, 2014, at 04:36 PM, Scott Kitterman wrote:
>Actually, nevermind. That's not the problem you were trying to solve,
>although you could remove the patch as described and then apply the updated
>patch at the end of the series.
Yeah, though sometimes for legitimate reasons you can't reorde
I've done enough experimentation to feel confident in my opinion that the team
should adopt git-dpm as its git packaging regime.
Note that this is just my personal opinion. I look forward to feedback from
other team members and interested parties, either for or against my
recommendation. I've on
> > The file is patched, but now I have an d/p/0005- file instead of a
> > modified
> > 0003- patch file. Sigh.
In this case you can use
git rebase -i master
edit the commit to merge 0003- and 0005-
Cheers
Frederic
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a s
On Thu, 04 Sep 2014, Barry Warsaw wrote:
> On Sep 04, 2014, at 04:36 PM, Scott Kitterman wrote:
>
> >Actually, nevermind. That's not the problem you were trying to solve,
> >although you could remove the patch as described and then apply the updated
> >patch at the end of the series.
>
> Yeah, t
On Thu, 04 Sep 2014, Barry Warsaw wrote:
> Even with those complaints, git-dpm feels like the better tool for team
> package management in git. The problems are minor and probably easily
> fixable.
>From my point of view, since you're anyway using features of
git-buildpackage, it would be better
On Sep 05, 2014, at 12:25 AM, Raphael Hertzog wrote:
>As others have mentionned, you should use "git rebase -i ". This is
>what you want to use on your patch-queue branch to modifiy individual
>commits, reorder them, or drop them.
Brilliant. For git-dpm then this would be:
$ git-dpm checkout-pa
On Sep 05, 2014, at 12:32 AM, Raphael Hertzog wrote:
>From my point of view, since you're anyway using features of
>git-buildpackage, it would be better to improve git-buildpackage...
>I like how git-dpm can keep patches applied on the packaging
>branch and porting the required shell to "gbp pq" s
10 matches
Mail list logo
