On 01.07.19 15:09, Andrey Rahmatullin wrote:
> On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
> wrote:
>> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>>
Perhaps we should update policy to say that the .orig tarball may (or
even "should") be generated from an
Picking just two examples:
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> I think for each supported upstream version there should be ...
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
On 29.05.19 23:39, David Bremner wrote:
>> Also, how do you move to a new upstream version ?
>
> use git merge, typically from an upstream tag, or from a debian specific
> upstream branch with tarballs imported on top of upstream history.
Uh, that creates an pretty ugly, unreadable git repo and
On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>
> >> Perhaps we should update policy to say that the .orig tarball may (or
> >> even "should") be generated from an upstream release tag where
> >> applicable.
> >
On 29.05.19 17:41, Andrey Rahmatullin wrote:
>> Perhaps we should update policy to say that the .orig tarball may (or
>> even "should") be generated from an upstream release tag where
>> applicable.
> This conflicts with shipping tarball signatures.
Does that really need to be the upstream's
On 29.05.19 15:14, Ben Hutchings wrote:
> Perhaps we should update policy to say that the .orig tarball may (or
> even "should") be generated from an upstream release tag where
> applicable.
ACK. But there should also be some definition or at least guideline on
what is considiered "applicable"
On 02.06.19 16:22, Sam Hartman wrote:
>> "Nikolaus" == Nikolaus Rath writes:
>
>
> Yes, but the lack of similarity is the thing I find interesting.
> In git-pdm (and git-debrebase), you retain all the rebases and stitch
> them together with various pseudo-merges into a combined history.
>
On 02.06.19 00:57, Ian Jackson wrote:
Hi,
> The difficulty with this as a collaboration approach is that you can't
> tell whether a rebase is "the newest", at least without a lot of
> additional information. That additional information is the "clutter"
> if you like which the "cleaner" history
On 29.05.19 14:47, Sam Hartman wrote:
Hi,
> I'm certainly going to look at dck-buildpackage now, because what he
> describes is a workflow I'd like to be using within Debian.
:)
Maybe you'd also find that useful: https://github.com/metux/deb-pkg
It's a little tool for automatically creating
On 29.05.19 13:50, Ian Jackson wrote:
Hi,
> Oh. I think I have misunderstood. I think you are describing a git
> workflow you use as a *downstream* of Debian, not as a maintainer
> *within* Debian.
Yes, something like that. I'm maintaining additional repos for certain
projects, usually
Theodore Ts'o writes ("Re: Survey: git packaging practices / repository
format"):
> On Fri, Jun 21, 2019 at 05:59:52PM +0100, Ian Jackson wrote:
> > How do you update to a new upstream version while preserving your
> > delta queue ? Just git merge with an upstream see
On Fri, Jun 21, 2019 at 05:59:52PM +0100, Ian Jackson wrote:
> > There's a variant of this which is to grab updates from upstream using
> > "git cherry-pick -x COMMIT_ID ; git format-patch -o debian/patches -1
> > COMMIT_ID".
> >
> > At the moment I'm updating debian/patches/series by hand, but
Theodore Ts'o writes ("Re: Survey: git packaging practices / repository
format"):
> On Tue, May 28, 2019 at 04:51:10PM +0100, Ian Jackson wrote:
> >
> > Modified Direct changes git merge
> > upstream files,to upstream files (.
Gunnar Wolf writes ("Re: Survey: git packaging practices / repository format"):
> I don't know whether this is relevant to what you are asking, but:
> > Main packaging Delta from upstream Tools for manipulating
> > git branch represented as
> "Nikolaus" == Nikolaus Rath writes:
Yes, but the lack of similarity is the thing I find interesting.
In git-pdm (and git-debrebase), you retain all the rebases and stitch
them together with various pseudo-merges into a combined history.
If you could avoid that and have a more pure rebase
On Tue, May 28, 2019 at 04:51:10PM +0100, Ian Jackson wrote:
>
> Modified Direct changes git merge
> upstream files,to upstream files (.dsc: 1.0-with-diff or
> plus debian/*. single-debian-patch)
> Maybe d/patches, depending.
Nikolaus Rath writes ("Re: Survey: git packaging practices / repository
format"):
> On May 29 2019, Sam Hartman wrote:
> > The thing his approach really seems to have going for it is that he
> > gives up on the debian history fast forwarding and instead rebases a lot
On May 29 2019, Sam Hartman wrote:
> I'm certainly going to look at dck-buildpackage now, because what he
> describes is a workflow I'd like to be using within Debian.
>
> For some projects I want to ignore orig tarballs as much as I can. I'm
> happy with native packages, or 3.0 quilt with
Ian Jackson dijo [Tue, May 28, 2019 at 04:51:10PM +0100]:
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git to do their Debian
> packaging, and what
Ian Jackson writes:
> Can you please look through the table below and see if I have covered
> everything you do ?
You have covered the workflows I set up where I have the choice. Thanks.
--
\ “I am amazed, O Wall, that you have not collapsed and fallen, |
`\since you must
Ian Jackson writes:
> Ian Jackson writes ("Re: Survey: git packaging practices / repository
> format"):
>> David Bremner writes ("Re: Survey: git packaging practices / repository
>> format"):
> ...
>> > With unmodified upstream files in the
Ian Jackson writes:
> Hi. Thanks for your contributions which I am trying to capture, but I
> don't think I fully understand them.
>
> David Bremner writes ("Re: Survey: git packaging practices / repository
> format"):
>> With modified upstream files
Ian Jackson writes ("Re: Survey: git packaging practices / repository format"):
> David Bremner writes ("Re: Survey: git packaging practices / repository
> format"):
...
> > With unmodified upstream files in the main branch, plus debian/*, but
> > usu
Hi. Thanks for your contributions which I am trying to capture, but I
don't think I fully understand them.
David Bremner writes ("Re: Survey: git packaging practices / repository
format"):
> With modified upstream files in the main branch, plus debian/*, but
> usually no
On Wed, May 29, 2019 at 12:20:23PM -0400, Sam Hartman wrote:
> >> Perhaps we should update policy to say that the .orig tarball may
> >> (or even "should") be generated from an upstream release tag
> >> where applicable.
> Andrey> This conflicts with shipping tarball signatures.
>
> "Andrey" == Andrey Rahmatullin writes:
Andrey> On Wed, May 29, 2019 at 02:14:09PM +0100, Ben Hutchings wrote:
>> [...] > My understanding is that this unusual difference between
>> the .orig > tarball and what's in git is an attempt to "square
>> the circle" between > two
On Wed, May 29, 2019 at 02:14:09PM +0100, Ben Hutchings wrote:
> [...]
> > My understanding is that this unusual difference between the .orig
> > tarball and what's in git is an attempt to "square the circle" between
> > two colliding design principles: "the .orig tarball should be upstream's
> >
On Wed, 29 May 2019 at 14:14:09 +0100, Ben Hutchings wrote:
> On Wed, 2019-05-29 at 00:39 +0100, Simon McVittie wrote:
> [...]
> > My understanding is that this unusual difference between the .orig
> > tarball and what's in git is an attempt to "square the circle" between
> > two colliding design
On Wed, 2019-05-29 at 00:39 +0100, Simon McVittie wrote:
[...]
> My understanding is that this unusual difference between the .orig
> tarball and what's in git is an attempt to "square the circle" between
> two colliding design principles: "the .orig tarball should be upstream's
> official binary
On Tue, 2019-05-28 at 21:14 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Survey: git packaging practices / repository
> format"):
[...]
> > Debian Linux kernel
> > ===
> >
> > Tree contains: an incomplete debi
> "Ian" == Ian Jackson writes:
Ian> Enrico Weigelt, metux IT consult writes ("Re: Survey: git
Ian> packaging practices / repository format"):
>> I'd call it the 'git-only-workflow' ;-)
Ian> ...
>> It's not in official Debian. I've announced it long go, but
>> nobody
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> On 28.05.19 22:08, Ian Jackson wrote:
> > Please can we leave aside discussion of the merits or otherwise of
> > each of these formats/workflows.
> >
> >
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> I'd call it the 'git-only-workflow' ;-)
...
> It's not in official Debian. I've announced it long go, but nobody
> here really cared. I couldn't even convice debian maintainer
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> hmm, sounds quite complicated ... anyone here who could explain why
> exactly they're doing it that way ?
>
> by the way: that's IMHO an important information we shou
Ian Jackson writes:
>
> Main packaging Delta from upstream Tools for manipulating
> git branch represented as delta from upstream,
> contains building .dsc, etc.
>
> Unmodified debian/patches gbp, gbp pq
>
On 28.05.19 19:31, Simon McVittie wrote:
Hi,
> Debian Linux kernel
> ===
>
> Tree contains: an incomplete debian/ directory, notably without d/control,
> and no upstream source
> Changes to upstream source are: d/patches only
> Baseline upstream: changelog version => .orig
On 29.05.19 01:39, Simon McVittie wrote:
Hi,
> You might reasonably assume that, but no, they are not. mesa (and probably
> other xorg-team packages) uses v1.0 dpkg-source format combined with
> dh --with quilt, so deliberate Debian changes can be either direct
> changes to the upstream source
On 28.05.19 22:08, Ian Jackson wrote:
Hi,
> Please can we leave aside discussion of the merits or otherwise of
> each of these formats/workflows.
>
> Perhaps we can talk about that (again!) at some point, but it tends to
> derail any conversation about git packaging stuff and I don't want
>
intainers was asymptotically
approaching zero, from below.
> Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices
> / repository format"):
>> I'm always cloning the upstream repo, branch off at their release tag
>> and add all necessary chanages a
On Tue, 28 May 2019 at 21:20:50 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Survey: git packaging practices / repository
> format"):
> > xorg-team (e.g. mesa)
> > =
> >
> > Tree contains: upstream files from a git tag (not
> "Ian" == Ian Jackson writes:
Ian> If folks think it worthwhile I guess I could post to d-d-a, but
Ian> let's let it run here for a bit first.
I don't have an opinion on whether you should post to d-d-a.
I know I'll reference this in my upcoming bits from the DPL because
discussion
Hi, thanks for replying. You have an interesting workflow which I
think I need to ask some questions about before I can document it
fully.
Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices /
repository format"):
> I'm always cloning the upstream rep
Simon McVittie writes ("Re: Survey: git packaging practices / repository
format"):
> xorg-team (e.g. mesa)
> =
>
> Tree contains: upstream files from a git tag (not identical to the
> upstream `make dist` tarball), sometimes with extra commit
Simon McVittie writes ("Re: Survey: git packaging practices / repository
format"):
> On Tue, 28 May 2019 at 16:51:10 +0100, Ian Jackson wrote:
> > Unmodified debian/patches gbp, gbp pq
> > upstream files,(only)quilt
On 28.05.19 17:51, Ian Jackson wrote:> While trying to write the dgit
FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git to do their Debian
> packaging, and what people call these
Ian Jackson writes ("Survey: git packaging practices / repository format"):
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git
Chris Lamb writes ("Re: Survey: git packaging practices / repository format"):
> Dear Ian,
> > Can you please look through the table below and see if I have covered
> > everything you do ?
> >
> > In particular:
> > - have I missed a git reposit
Thanks for this work.
I've reviewed your table and believe everything I've used is there.
I think this survey is really important.
On Tue, 28 May 2019 at 16:51:10 +0100, Ian Jackson wrote:
> Unmodified debian/patches gbp, gbp pq
> upstream files,(only)quilt / dquilt
> plus debian/* Manual patch editing
> incl. d/patches
Do you intend "manual
Dear Ian,
> Can you please look through the table below and see if I have covered
> everything you do ?
>
> In particular:
> - have I missed a git repository and history layout
> - have I missed a primary tool that should be mentioned
> - are any of the details wrong for workflows that you
While trying to write the dgit FAQ, and some of the relevant docs, it
has become even more painfully obvious that we lack a good handle on
what all the different ways are that people use git to do their Debian
packaging, and what people call these formats/workflows, and what
tools they use.
Can
51 matches
Mail list logo
