On Thu, 2017-03-09 at 21:13 +1100, Brian May wrote:
> Brian May writes:
>
> > git read-tree --reset -u upstream
> > git reset -- debian
> > git checkout debian
> > git rm debian/.git-dpm
>
> I have tried these steps on python-mkdocs in the debian/experimental
> branch, and then upgraded to the l
❦ 9 mars 2017 21:13 +1100, Brian May :
> The above also assumes that upstream==origin/upstream==latest
> upstream. Which means you need to have done a git pull recently on the
> upstream branch. Depending on the circumstances, using origin/upstream
> might be a better choice rather then upstrea
Brian May writes:
> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
I have tried these steps on python-mkdocs in the debian/experimental
branch, and then upgraded to the latest upstream (using instructions on
wiki). Works perfectly[1].
The
On Feb 14 2017, Scott Kitterman wrote:
> How does dgit avoid maintainer forgot to push problems without being
> limited to the granularity of one commit per upload?
It does not. Until 'dgit push' is called the next time, it will revert
to one commit per upload for the "dark" period.
I am not sur
On Tuesday, February 14, 2017 06:23:43 PM Brian May wrote:
> Scott Kitterman writes:
> > We know in the DPMT context what debcheckout will produce, so for our
> > purposes they don't matter.
> >
> > How does dgit avoid maintainer forgot to push problems without being
> > limited to the granularit
Barry Warsaw writes:
> On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote:
>>The patch-queue branch is based on the Debian branch, not upstream. Try
>>merging the new upstream version to your Debian branch, and then running
>>gbp pq rebase.
>
> This confuses me, or I'm doing something wrong. With
On Tue, 14 Feb 2017 at 11:44:33 -0500, Barry Warsaw wrote:
> So how do I drop a patch with gbp-pq?
rm debian/patches/this-got-fixed-upstream.patch, vi debian/patches/series,
commit? :-)
Or more generally, to do it the git way, if the rest of the patch series
might need non-trivial adjustment:
gi
On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote:
>The patch-queue branch is based on the Debian branch, not upstream. Try
>merging the new upstream version to your Debian branch, and then running
>gbp pq rebase.
This confuses me, or I'm doing something wrong. With git-dpm the way to drop
patch
Barry Warsaw writes:
> On Feb 14, 2017, at 05:54 PM, Brian May wrote:
>>Maybe something like the following?
>>
>>git read-tree --reset -u upstream
>>git reset -- debian
>>git checkout debian
>>git rm debian/.git-dpm
>>git commit
>
> This gets closer, but there still seems to be problems.
>
> gbp p
On Feb 14, 2017, at 05:54 PM, Brian May wrote:
>Not sure how to unapply all patches. "quilt pop -a" won't work, quilt
>doesn't realize the patches are applied.
Yep, that does seem to be the problem.
>Maybe something like the following?
>
>git read-tree --reset -u upstream
>git reset -- debian
>g
Scott Kitterman writes:
> We know in the DPMT context what debcheckout will produce, so for our
> purposes they don't matter.
>
> How does dgit avoid maintainer forgot to push problems without being limited
> to the granularity of one commit per upload?
When you upload a package, you upload th
Brian May writes:
> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
git commit
Of course...
--
Brian May
Barry Warsaw writes:
> One section I think we should add at some point is instructions on how to
> manually convert to gbp-pq, at least until we do a mass conversion.
Yes agreed.
Not sure how to unapply all patches. "quilt pop -a" won't work, quilt
doesn't realize the patches are applied.
"git
On February 11, 2017 4:05:46 PM EST, Nikolaus Rath wrote:
>On Feb 10 2017, Scott Kitterman wrote:
>> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath
>wrote:
>>>On Feb 10 2017, Scott Kitterman wrote:
>No. You are confusing dgit with one particular way to use it. You
>can
>use dgit wi
On Feb 13, 2017, at 04:56 PM, Brian May wrote:
>There might be errors, as I was going from memory for some of this
>stuff.
Thanks Brian. I did a quick review (without testing) and it looks pretty
good.
One section I think we should add at some point is instructions on how to
manually convert to
Brian May writes:
> https://wiki.debian.org/Python/GitPackagingPQ
>
> So far it is just a clone, I haven't tried making any changes.
I have gone through and made numerous updates.
There might be errors, as I was going from memory for some of this
stuff.
I didn't specify anything for dgit. The
On 01/29/2017 08:17 AM, Arto Jantunen wrote:
> Scott Kitterman writes:
>> Does that then result in one big undifferentiated mass of diff in the source
>> package?
>
> No, it results in separate patches with their headers intact in the
> source package. I assume git-dpm (which I've never used) pr
On Feb 10 2017, Scott Kitterman wrote:
> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath wrote:
>>On Feb 10 2017, Scott Kitterman wrote:
No. You are confusing dgit with one particular way to use it. You can
use dgit with the maint-merge workflow mentioned above, you can use
dgit
>>
kuLa writes:
> dgit indeed is using it's own repos:
> https://browse.dgit.debian.org/
> git.dgit.debian.org
The way I understand it is that dgit is simply a replacement for the
upload operation. To implement this with the required checks, it is
recommended (but not required) that you use its bu
Brian May writes:
> [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git
> sbuild --verbose
> Format `3.0 (quilt)', need to check/update patch stack
> examining quilt state (multiple patches, gbp mode)
> dgit: split brain (separate dgit view) may be ne
On 2017-02-10 21:11:42, Brian May wrote:
> Scott Kitterman writes:
>
> > How is that different/better than debcheckout?
>
> I am still learning dgit, however I think that dgit uses its own git
> repositories. dgit-repos. I am not sure where these are located or how
> access is controlled.
dgit
Scott Kitterman writes:
> How is that different/better than debcheckout?
I am still learning dgit, however I think that dgit uses its own git
repositories. dgit-repos. I am not sure where these are located or how
access is controlled.
>From the man page for push "This will push your git history
Nikolaus Rath writes:
> But it seems to me that you are contemplating whether or not the team
> should be using dgit. This is also not a decision that needs to be made
> prior to any switch away from dgit-dpm, you can start using dgit at any
> point.
My vague understanding is that dgit complemen
On February 9, 2017 8:29:32 PM PST, Nikolaus Rath wrote:
>On Feb 10 2017, Scott Kitterman wrote:
>>>No. You are confusing dgit with one particular way to use it. You can
>>>use dgit with the maint-merge workflow mentioned above, you can use
>>>dgit
>>>with git-dpm, and you can use dgit with gbp
On Feb 10 2017, Scott Kitterman wrote:
>>No. You are confusing dgit with one particular way to use it. You can
>>use dgit with the maint-merge workflow mentioned above, you can use
>>dgit
>>with git-dpm, and you can use dgit with gbp.
>
> OK. So then I gather it's effectively a layer on top of 'n
On February 9, 2017 10:52:04 AM PST, Nikolaus Rath wrote:
>On Feb 07 2017, Barry Warsaw wrote:
>> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>>
>>>I know the discussion is leaning towards replacing usage of git-dpm
>>>with gbp-pq. I have nothing against it but, since we are talking
On Feb 07 2017, Barry Warsaw wrote:
> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>
>>I know the discussion is leaning towards replacing usage of git-dpm
>>with gbp-pq. I have nothing against it but, since we are talking about
>>solutions for a git-centric workflow, has anyone considere
Barry Warsaw writes:
> On Feb 05, 2017, at 04:01 PM, Brian May wrote:
>
>>What should we call the clone page?
>>
>>PqGitPackaging???
>
> GitPackagingPq ?
https://wiki.debian.org/Python/GitPackagingPQ
So far it is just a clone, I haven't tried making any changes.
--
Brian May
On Tue, Feb 07, 2017 at 10:47:00AM +, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge wor
On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>I know the discussion is leaning towards replacing usage of git-dpm
>with gbp-pq. I have nothing against it but, since we are talking about
>solutions for a git-centric workflow, has anyone considered the dgit-
>maint-merge workflow [1]?
As
On Tue, 07 Feb 2017 at 10:47:00 +, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workfl
I know the discussion is leaning towards replacing usage of git-dpm
with gbp-pq. I have nothing against it but, since we are talking about
solutions for a git-centric workflow, has anyone considered the dgit-
maint-merge workflow [1]?
It is very well documented and would simplify team-packaging po
On Feb 05, 2017, at 02:07 AM, Scott Kitterman wrote:
>Experimentation with a few packages to prepare for a migration and make sure
>the documentation is good, is fine. We really ought to switch for real all
>at once like we did for svn -> git. It's not much of a team repository
>without a consis
On Feb 05, 2017, at 04:01 PM, Brian May wrote:
>What should we call the clone page?
>
>PqGitPackaging???
GitPackagingPq ?
Cheers,
-Barry
On Sunday, February 05, 2017 03:59:37 PM Brian May wrote:
> Scott Kitterman writes:
> > We should probably be thinking in terms of post-release for this change.
> > During the pre-release freeze, the release team doesn't typically allow
> > changes that extraneous to fixing the specific issue they
Barry Warsaw writes:
> What I'd really like to see is a page like
> https://wiki.debian.org/Python/GitPackaging for a non-git-dpm workflow. (The
> page itself could probably use a bit of gardening anyway.) Specifically, I'd
> like to see guidance on any tasks which are different for git-pq (or
Scott Kitterman writes:
> We should probably be thinking in terms of post-release for this change.
> During the pre-release freeze, the release team doesn't typically allow
> changes that extraneous to fixing the specific issue they are letting a
> package into Testing to fix. The .git-dpm f
On Jan 31, 2017, at 02:51 PM, Scott Kitterman wrote:
>We should probably be thinking in terms of post-release for this change.
Oh, definitely +1
-Barry
On Tuesday, January 31, 2017 02:23:29 PM Barry Warsaw wrote:
> On Jan 29, 2017, at 09:39 AM, Brian May wrote:
> >I would think "gbp pq" is the most popular.
>
> I've used it on some of my non-team packages and while it takes a little
> getting used to for the standard git-dpm workflow, it's been m
On Jan 29, 2017, at 09:39 AM, Brian May wrote:
>I would think "gbp pq" is the most popular.
I've used it on some of my non-team packages and while it takes a little
getting used to for the standard git-dpm workflow, it's been mostly fine.
What I'd really like to see is a page like
https://wiki.d
Scott Kitterman writes:
> OK. Where do I find documentation to give this a try?
I used the following documentation:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html
--
Brian May
Raphael Hertzog writes:
> You don't need that. dpkg-buildpackage unapplies them automatically after
> the build if it has applied them. If they were already applied before the
> build, then it leaves them applied.
Guess it depends how you build the package. I have been using:
gbp buildpackage "
On Sun, 29 Jan 2017 at 20:50:48 +0100, Raphael Hertzog wrote:
> On Sun, 29 Jan 2017, Brian May wrote:
> > 3. Update debian/source/options with "unapply-patches" (anything else?).
>
> You don't need that. dpkg-buildpackage unapplies them automatically after
> the build if it has applied them. If
On January 29, 2017 2:17:16 AM EST, Arto Jantunen wrote:
>Scott Kitterman writes:
>
>> On Sunday, January 29, 2017 09:39:10 AM Brian May wrote:
>>> Scott Kitterman writes:
>>> > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
>>> >> Can we switch away from git-dpm yet? Sure this is mo
On Sun, 29 Jan 2017, Brian May wrote:
> 3. Update debian/source/options with "unapply-patches" (anything else?).
You don't need that. dpkg-buildpackage unapplies them automatically after
the build if it has applied them. If they were already applied before the
build, then it leaves them applied.
Scott Kitterman writes:
> On Sunday, January 29, 2017 09:39:10 AM Brian May wrote:
>> Scott Kitterman writes:
>> > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
>> >> Can we switch away from git-dpm yet? Sure this is most likely user
>> >> error, however I want to try to solve an RC b
On Sunday, January 29, 2017 09:39:10 AM Brian May wrote:
> Scott Kitterman writes:
> > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
> >> Can we switch away from git-dpm yet? Sure this is most likely user
> >> error, however I want to try to solve an RC bug, not fix broken git-dpm
> >>
Scott Kitterman writes:
> On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
>> Can we switch away from git-dpm yet? Sure this is most likely user
>> error, however I want to try to solve an RC bug, not fix broken git-dpm
>> first.
>
> Much like the switch from svn to git, I think we need a
On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
> Can we switch away from git-dpm yet? Sure this is most likely user
> error, however I want to try to solve an RC bug, not fix broken git-dpm
> first.
Much like the switch from svn to git, I think we need an agreed new workflow
and tools a
Brian May writes:
> Hello,
>
> Looks like somebody applied a change to this git-dpm repo that manually
> deleted a patch under debian/patches.
>
> Instead of using "git-dpm checkout-patched" and then updating.
>
> This looks like it has broken git-dpm.
>
> How do I fix?
>
> Guessing I will have t
50 matches
Mail list logo
