Sam Hartman writes:
> * One is that you're not using upstream tarballs. If upstream has
> tarballs they produce, we're not using them. I guess we may end up
> having that part of the conversation now rather than later.
>
> It's clear that we value integrity of upstream source. That is we
>
On Aug 30, Scott Kitterman wrote:
> It's not particularly rare for me to poke through other distros package
> patches when I'm trying to figure out how to solve a problem. I suspect I'm
I would even say that maintainers who do not periodically review what
other distributions do with their own
Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> [context: git-debrebase, git-dpm]
>
> However, while analyzing a rebased branch isn't as hard for other
> people as a branch with a complex merge history, it does mean that
> upstream has to
gregor herrmann writes ("Re: Git Packaging: Native source formats"):
> On Thu, 29 Aug 2019 22:03:18 -0400, Theodore Y. Ts'o wrote:
> > The problem I have is that "dgit gbp" doesn't extract the upstream
> > .asc.
>
> This sounds like #872864 i
On Fri, Aug 30, 2019 at 09:05:45AM -0700, Russ Allbery wrote:
> Ian Jackson writes:
> > This is also not that hard, in simple cases. There is a tool
> > git-debcherry which can do it automatically. I haven't used it but AIUI
> > if your Debian delta queue has few commits, and doesn't have commit
On Thu, 29 Aug 2019 22:03:18 -0400, Theodore Y. Ts'o wrote:
> The problem I have is that "dgit gbp" doesn't extract the upstream
> .asc.
This sounds like #872864 in git-buildpackage.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : Ope
On Fri, 2019-08-30 at 12:20 -0400, Scott Kitterman wrote:
> On Friday, August 30, 2019 12:05:45 PM EDT Russ Allbery wrote:
> > This lets you generate the patches for people on demand, but they aren't
> > just sitting out there for anyone to look at whenever they want.
> >
> > I suppose it could b
On Fri, 30 Aug 2019 at 09:05:45 -0700, Russ Allbery wrote:
> [git-debcherry] lets you generate the patches for people on demand, but
> they aren't just sitting out there for anyone to look at whenever they want.
I think that's really important from the transparency point of view that
you touched o
On Friday, August 30, 2019 12:05:45 PM EDT Russ Allbery wrote:
> Ian Jackson writes:
> > Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> >> [ discussion of benefits of maintaining the Debian delta as
> >>
> >> a linear series
Ian Jackson writes:
> Russ Allbery writes ("Re: Git Packaging: Native source formats"):
>> [ discussion of benefits of maintaining the Debian delta as
>> a linear series of broken-down changes ]
>>
>> There are obviously ways to represent this with a p
Russ Allbery writes ("Re: Git Packaging: Native source formats"):
> [ discussion of benefits of maintaining the Debian delta as
> a linear series of broken-down changes ]
>
> There are obviously ways to represent this with a pure Git repository, but
> apart from using
Philipp Kern writes ("Re: Git Packaging: Native source formats"):
> While this may be true on some level, it is also important to be able to
> build packages from checked-out source trees (say, git repositories)
> without an original source present.
Quite.
For example, if
Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote:
> > I think dgit ought to be compatible with the idea of shipping
> > upstream's .asc's about, but maybe there are bugs. I d
On Fri, Aug 30, 2019 at 12:29:45AM +0200, Thomas Goirand wrote:
> Now, you're talking about upstream using bzr or hg. These are the very
> few minority (and counting...). We may as well get rid of hg and bzr in
> Debian if it doesn't get fixed so it uses Python 3 only... (well, I
> guess someone wi
On Thu, Aug 29, 2019 at 01:26:08PM -0700, Russ Allbery wrote:
> While this is not an argument against *ever* using 3.0 (native) or some
> equivalent when packaging upstream software, I have found it to help
> relationships with upstream considerably in the past to represent the
> package as their s
Hi,
On Thu, Aug 29, 2019 at 09:42:50PM +0200, Philipp Kern wrote:
> Obviously I'm not bound to that format being "3.0 (native)" but some
> "3.0 (dumb)" that just tars up the whole tree without caring about the
> version scheme would then be nice to have as a replacement. ;-)
Are you planning to
On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote:
> Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> > Or if we end up moving to dgit for everything, and we don't want to
> > use pristine-tar (which I like, but I realize
On Fri, Aug 30, 2019 at 12:29:45AM +0200, Thomas Goirand wrote:
>
> Pristine-tar forces you to have multiple branches when you may only need
> a single one. It's also not reliable and may easily generate different
> tarballs for the same tag, which defeats its purpose (and no, the
> workaround to
On 8/29/19 1:49 AM, Theodore Y. Ts'o wrote:
> Or if we end up moving to dgit for everything, and we don't want to
> use pristine-tar (which I like, but I realize that's not an opinion
> shared by everyone; some people seem to hate it
/me raises hand. I hate it.
Pristine-tar forces you to have mul
Sam Hartman writes:
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the same. You don't need to synthesi
On 2019-08-28, Sam Hartman wrote:
> * I've heard at least one person claim that native format packages are
> problematic for downstreams.
> I'd like to better understand both the theoretical argument here and
> to understand from downstreams whether it is an issue in practice.
>
> For down
On 8/29/2019 8:32 PM, Andrej Shadura wrote:
>> So `3.0 (native)' is not strictly better than 1.0. dpkg-source
>> refuses to work in the situation where I am saying (and you seem to be
>> agreeing) that it shouldn't even print a warning ...
>
> I have to disagree with you but I consider this stric
On Thu, 29 Aug 2019 at 16:25:35 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > for
> > version 1.0 source packages, detecting a non-native version with a native
> > source format is the only way to generate
Ian Jackson writes ("Re: Git Packaging: Native source formats"):
> Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> > Unlike 1.0 (non-native) vs. 3.0 (quilt), where some people prefer one and
> > some people prefer the other, I am not aware o
Milan Kupcevic writes ("Re: Git Packaging: Native source formats"):
> I've also seen developers deleting a git tag and then creating a new
> git tag using exactly the same name/release number pointing to
> different commit.
It is possible to avoid some of these proble
Simon McVittie writes ("Re: Git Packaging: Native source formats"):
> On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> > If you already don't care about bit-identical upstream tarballs, then
> > dealing with these tarballs is a reasonably well-solved pro
On 8/28/19 4:00 PM, Sam Hartman wrote:
>
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
> upstream, as well as to reduce
On Thu, 29 Aug 2019 at 11:56:55 +0100, Ian Jackson wrote:
> If you already don't care about bit-identical upstream tarballs, then
> dealing with these tarballs is a reasonably well-solved problem.
> git-deborig etc. FTW.
I think it's important to distinguish between the two things that you
might m
Hi,
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote:
> Back in the day, one of the big reasons for separating .orig.tar.gz from
> .diff.gz was to reuse upstream tarballs for space reasons, both in terms
> of space on mirrors when the pool had two Debian revisions with the same
> upstr
Sam Hartman writes ("Git Packaging: Native source formats"):
> Internet is faster and disks are cheaper.
> I assert this is much less of a concern than it used to be.
We have some extremely large packages. Also we have users in places
where internet is slow and/or expensive.
Even for medium-size
Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"):
> Or if we end up moving to dgit for everything, and we don't want to
> use pristine-tar (which I like, but I realize that's not an opinion
> shared by everyone; some people seem to hate it),
Hi,
On Wed, 28 Aug 2019, Sam Hartman wrote:
> Internet is faster and disks are cheaper.
I'm not sure that DSA (which is maintaining snapshot.debian.org) will
be happy with this assertion.
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you c
> "Paul" == Paul Wise writes:
Paul> On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote:
>> Using native source formats (1.0 and 3.0 (native)) is attractive
>> for some git workflows. It means you can just export the git
>> repository and don't need to make sure that you use th
On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote:
> Using native source formats (1.0 and 3.0 (native)) is attractive for
> some git workflows. It means you can just export the git repository and
> don't need to make sure that you use the same upstream tarball when
> upstream versions are the s
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote:
>
> But if we're thinking that people will be working in Git, another way
> to do this is to merge in a signed upstream git tag. Then you can
> perform a diff against that git tag.
One of the things to consider is how we should h
On 2019-08-28 16:00:10 -0400 (-0400), Sam Hartman wrote:
[...]
> It seems particularly attractive when upstream doesn't produce
> tarballs and instead does their development in git.
[...]
Not to be a pedant, and it probably wasn't what you meant to imply
either, but I want to be clear that upstrea
36 matches
Mail list logo
