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 to do their Debian
>
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
50 matches
Mail list logo