Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> By definition, there shouldn't be any packages in the archive with this,
> because dpkg does not include the local-options when it builds a .dsc:
> that's why it's called
On 12/08/15 15:43, Ian Jackson wrote:
> Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration
> tools"):
>> tglase@tglase-nb:~/Misc/Vendor/xrdp $ cat debian/source/local-options
>> unapply-patches
>
> I want to test whether a package
Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> tglase@tglase-nb:~/Misc/Vendor/xrdp $ cat debian/source/local-options
> unapply-patches
I want to test whether a package with this in its source tree works
properly with dgit. Do you know
Colin Watson writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Tue, Aug 04, 2015 at 07:47:23AM +0100, Ian Campbell wrote:
> > AIUI this is compatible with dgit, although I've not tried it.
>
> Based on my discussions with Ian J, the only
Ian Campbell writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> But git log shows that they are, it's just that Quilt is unaware of
> this (no .pc directory in git). Perhaps grub and python-pip differ here
> but I don't think so.
Right.
> A
❦ 5 août 2015 18:56 GMT, Thorsten Glaser :
>> There are two variants. One does have the patches under debian/patches/
>> (although this does not mix well with VCS IMO, so I don’t usually use
>> it), in which case either the applied or unapplied source tree may be
>> in the VCS. Both are troubli
Thorsten Glaser tarent.de> writes:
> There are two variants. One does have the patches under debian/patches/
> (although this does not mix well with VCS IMO, so I don’t usually use
> it), in which case either the applied or unapplied source tree may be
> in the VCS. Both are troubling. Not sure w
On Tue, Aug 04, 2015 at 07:47:23AM +0100, Ian Campbell wrote:
> On Mon, 2015-08-03 at 14:37 -0400, Barry Warsaw wrote:
> > You'll be in the master branch which is the packaging branch, but `quilt
> > applied` returns nothing, and `quilt unapplied` shows you that the patches
> > are
> > not yet app
On Aug 04, 2015, at 07:47 AM, Ian Campbell wrote:
>But git log shows that they are, it's just that Quilt is unaware of
>this (no .pc directory in git). Perhaps grub and python-pip differ here
>but I don't think so.
I think you're right. I took a look at a different package (pip *is* a little
wei
On Mon, 2015-08-03 at 14:37 -0400, Barry Warsaw wrote:
> On Jul 21, 2015, at 06:46 PM, Ian Jackson wrote:
>
> >That is, the dgit git tree contains the patches in debian/patches/
> but
> >also contains the implied changes in the main source code. If you
> add
> >commits yourself to the dgit git
On Jul 21, 2015, at 06:46 PM, Ian Jackson wrote:
>That is, the dgit git tree contains the patches in debian/patches/ but
>also contains the implied changes in the main source code. If you add
>commits yourself to the dgit git tip, new patches will generated from
>your commits.
I think then that
On Sat, Aug 01, 2015 at 05:07:38PM +0100, Ian Jackson wrote:
> Guido Günther writes ("Re: Ad-hoc survey of existing Debian git integration
> tools"):
> > On Fri, Jul 31, 2015 at 03:21:59PM +0100, Ian Jackson wrote:
> > > I think the problems you are describing
Guido Günther writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Fri, Jul 31, 2015 at 03:21:59PM +0100, Ian Jackson wrote:
> > I think the problems you are describing arise when the user does _both_
> > (a) manipulate the patches in debina/p
On Fri, Jul 31, 2015 at 03:21:59PM +0100, Ian Jackson wrote:
> Guido Günther writes:
> > Having patches applied with 3.0(quilt) calls out for sync problems
> > between your git tree and debian/patches/. This can be mitigated with
> > --single-debian-patch --auto-commit but that's not what most peop
Ian Jackson writes ("Ad-hoc survey of existing Debian git integration tools"):
> I would like to think some more about the workflows of the existing
> tools people are using to work with Debian and git, so that I can
> provide good guidance for how these tools work with dgit (and perhaps
> send fea
Guido Günther writes:
> Having patches applied with 3.0(quilt) calls out for sync problems
> between your git tree and debian/patches/. This can be mitigated with
> --single-debian-patch --auto-commit but that's not what most people mean
> when talking about 3.0(quilt) - and it kind of defeats it's
Hi Ian,
On Thu, Jul 30, 2015 at 03:51:59PM +0100, Ian Jackson wrote:
[..snip..]
> I don't think the number of git-based workflows is going to decrease.
> I'm hoping (betting!) that the proportion of packages whose git
> maintainers' git workflows involve strange[1] git trees will go down.
>
> [1]
On Thu, 30 Jul 2015 14:56:33 +0200, Vincent Bernat
wrote:
> ? 30 juillet 2015 11:54 +0100, Ian Jackson :
>
>>> > Do your published git branches contain the patches-applied or
>>> > patches-unapplied tree ?
>>>
>>> Without using "gbp pq", the published git branches are patches-unapplied
>>> trees
❦ 30 juillet 2015 11:54 +0100, Ian Jackson :
>> > Do your published git branches contain the patches-applied or
>> > patches-unapplied tree ?
>>
>> Without using "gbp pq", the published git branches are patches-unapplied
>> trees.
>
> Then to use dgit push, you must use gbp pq.
>
> Do you see w
Vincent Bernat writes ("Re: Ad-hoc survey of existing Debian git
integration tools"):
> [Ian Jackson:]
> > Do your published git branches contain the patches-applied or
> > patches-unapplied tree ?
>
> Without using "gbp pq", the published git branches ar
❦ 30 juillet 2015 01:09 +0100, Ian Jackson :
>> There is a patch management system but I think that most people (at
>> least me) are just using gbp with plain/normal quilt.
>
> Do your published git branches contain the patches-applied or
> patches-unapplied tree ?
Without using "gbp pq", the p
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> Yes ish, but with the orig/diff structure the way it is, the preferred
> form for modifying a non-native Debian package seems to be the tree
> representing the unpacked package, plus t
Vincent Bernat writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> There is a patch management system but I think that most people (at
> least me) are just using gbp with plain/normal quilt.
Do your published git branches contain the patches-applied or
patche
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> "gbp buildpackage" can work either way, but I think most gbp users
> consider a patches-unapplied tree to be what they normally work with
> (for instance that's what the p
On 29/07/15 13:48, Ian Jackson wrote:
> I got the impression that gbp normally works with a patches-unapplied
> tree. Is that correct ? If so then an additional gbp step may be
> needed, to convert the tree to patches-applied.
"gbp buildpackage" can work either way, but I think most gbp users
co
On 29/07/15 15:00, Ian Jackson wrote:
> Are you saying that your source packages contain things that your git
> repositories don't ? This comes up occasionally, and I will say again
> what I have said before: I think this is wrong.
Perhaps it is; but if so, then any conventional Autotools project
❦ 29 juillet 2015 13:48 +0100, Ian Jackson :
>> > If you are an NMUer or a downstream using dgit, you should usually
>> > make plain git commits (with no changes to the patch stack). dgit
>> > will generate a separate patch for each of your commits. You should
>> > leave rebasing/squashing/ref
Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On 29 July 2015 at 07:34, Ian Jackson wrote:
> > If you are an NMUer or a downstream using dgit, you should usually
> > make plain git commits (with no changes to the patch stack).
On 29 July 2015 at 07:34, Ian Jackson wrote:
>
> Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
> tools"):
> > On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> > > That is, the dgit git tree contains the patches in debian/pa
Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> > That is, the dgit git tree contains the patches in debian/patches/ but
> > also contains the implied changes in the main
On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git
> integration tools"):
>> [workflow description]
>
> Thanks. FYI, dgit trees are (for `3.0 (quilt)' format source packages)
> what i
On Mon, Jul 20, 2015 at 05:46:15PM +0100, Ian Jackson wrote:
> I would like to think some more about the workflows of the existing
> tools people are using to work with Debian and git, so that I can
> provide good guidance for how these tools work with dgit (and perhaps
> send feature requests for
Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> [workflow description]
Thanks. FYI, dgit trees are (for `3.0 (quilt)' format source
packages) what is nowadays called a `patches-applied packaging
branch'.
That is, the dgit git tr
Ian Jackson chiark.greenend.org.uk> writes:
> I would like to think some more about the workflows of the existing
> tools people are using to work with Debian and git, so that I can
I tend to have the entire tree “as seen from Debian” in version control,
so I can just throw the .orig.tar.* to ..
Le 20/07/2015 18:46, Ian Jackson a écrit :
> AFAICT the only tools which attempt to convert between a `3.0 (quilt)'
> and a series of git commits are git-dpm and gbp-pq. Am I wrong about
> that ?
There are also dom-{apply,save}-patches in dh-ocaml. They are basically
wrappers around git-am and gi
On Mon, 20 Jul 2015 17:46:15 +0100, Ian Jackson wrote:
> AFAICT the only tools which attempt to convert between a `3.0 (quilt)'
> and a series of git commits are git-dpm and gbp-pq. Am I wrong about
> that ?
There's also git-debcherry (by David Bremner, shipped in the gitpkg
package).
Cheers,
Ian Jackson wrote:
> I would like to think some more about the workflows of the existing
> tools people are using to work with Debian and git, so that I can
> provide good guidance for how these tools work with dgit (and perhaps
> send feature requests for those tools, or know what extra features a
37 matches
Mail list logo
