On Thu, Oct 30, 2014 at 12:36:24AM +0900, Osamu Aoki wrote:
> > This would mean a much more expensive build by default, please don't.
>
> git-pbuilder uses cowbulder by default (not bare-bone pbuilder), so it
> is not as slow as pbuilder.
Yes, but it is a lot slower than a plain build on the curr
On Oct 29, 2014, at 01:47 PM, Ian Jackson wrote:
>I got the impression that sbuild is winning over pbuilder BICBW.
Especially now that bug #607228 has been fixed!
Cheers,
-Barry
signature.asc
Description: PGP signature
t; > Standardizing the layout of git packaging repositories)"):
...
> > I do wonder if we should switch to using git-pbuilder by default and
> > rather offer to invoke 'git-pbuilder create' in case we don't find a
> > proper base.cow for it.
Auto-generat
On Wed, Oct 29, 2014 at 02:32:04PM +0100, Guido Günther wrote:
> On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> > Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing
> > the layout of git packaging repositories)"):
> > > dpkg-
Guido Günther writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> I do wonder if we should switch to using git-pbuilder by default and
> rather offer to invoke 'git-pbuilder create' in case we don't find a
>
Simon McVittie writes ("Re: dgit and git-dpm (was Re: Standardizing the layout
of git packaging repositories)"):
> On 29/10/14 12:08, Ian Jackson wrote:
> > The contents of the default ignore
> > list is in dpkg-source, but it is not enabled unless the caller says
> &g
On Wed, Oct 29, 2014 at 12:06:59PM +, Ian Jackson wrote:
> Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing the
> layout of git packaging repositories)"):
> > dpkg-source removes it, by default, for 3.0 based formats as it's part
> > of
On 29/10/14 12:08, Ian Jackson wrote:
> The contents of the default ignore
> list is in dpkg-source, but it is not enabled unless the caller says
> -I. git-buildpackage passes -I.
To be completely clear (because I misread it twice in a row), you mean
that it is not enabled unless the caller uses
[resending because my MUA failed to mangle the headers]
Dimitri John Ledkov writes ("Re: dgit and git-dpm (was Re: Standardizing the
layout of git packaging repositories)"):
> dpkg-source removes it, by default, for 3.0 based formats as it's part
> of the default igno
On 29 October 2014 05:39, Guido Günther wrote:
> On Tue, Oct 28, 2014 at 07:17:49PM +, Ian Jackson wrote:
>> Brian May writes ("Re: Standardizing the layout of git packaging
>> repositories"):
>> > However, with git-dpm, no branch is ever destroyed. Every
On Tue, Oct 28, 2014 at 07:17:49PM +, Ian Jackson wrote:
> Brian May writes ("Re: Standardizing the layout of git packaging
> repositories"):
> > However, with git-dpm, no branch is ever destroyed. Every branch is always
> > merged into the Debian branch. The Debia
Brian May writes ("Re: Standardizing the layout of git packaging repositories"):
> However, with git-dpm, no branch is ever destroyed. Every branch is always
> merged into the Debian branch. The Debian branch itself always heads in a
> single forward direction and this bran
On 08/26/2014 06:37 PM, Mike Gabriel wrote:
> For rebasing debian/patches/*.patch against new upstream releases, I
> simply copy my tarball into the packaging Git, rebase the patches,
> remove upstream sources again and commit the patches.
This is exactly why it's preferable to have upstream sourc
hi,
ill send out a concrete example when I get back home
Manoj
On September 7, 2014 8:41:45 PM PDT, Brian May
wrote:
>On 8 September 2014 04:05, Ben Hutchings wrote:
>
>> How does git-debcherry cope with the overlapping changes when
>generating
>> debian/patches? What can you do if it fa
hi,
no, I get one patch per commit, plus a fixup patch. no squashing.
Manoj
On September 7, 2014 8:53:04 PM PDT, Brian May
wrote:
>On 7 September 2014 13:30, Manoj Srivastava
>wrote:
>
>>
>> | I commit | Ephemeral gbranch contains | Master contains |
>> |--+--
On 7 September 2014 13:30, Manoj Srivastava wrote:
>
> | I commit | Ephemeral gbranch contains | Master contains |
> |--++-|
> | B2 | A11, B12, B21 | D6 |
>
> There are there nodes in the ephemeral branch,
On 8 September 2014 04:05, Ben Hutchings wrote:
> How does git-debcherry cope with the overlapping changes when generating
> debian/patches? What can you do if it fails to linearise the changes
> (as, apparently, it may sometimes do)?
>
Just did some fiddling.
I have no idea if this is the git
Hi,
You need to bag Ron, or pull from the hit repositories directly.
Manoj
On September 7, 2014 5:24:18 PM PDT, Brian May
wrote:
>On 8 September 2014 04:05, Ben Hutchings wrote:
>
>> How does git-debcherry cope with the overlapping changes when
>generating
>> debian/patches? What can
On 8 September 2014 04:05, Ben Hutchings wrote:
> How does git-debcherry cope with the overlapping changes when generating
> debian/patches? What can you do if it fails to linearise the changes
> (as, apparently, it may sometimes do)?
>
I am not sure this needs to be an issue. Or maybe I am jus
Hi,
You have to ask Paul Bremer that. Me, I am merely a happy user. I did
grok it at one point, but I no longer recall that.
Manoj
On September 7, 2014 11:05:50 AM PDT, Ben Hutchings
wrote:
>On Sat, 2014-09-06 at 22:03 -0700, Manoj Srivastava wrote:
>> On Sun, Sep 07 2014, Scott Ki
On Sat, 2014-09-06 at 22:03 -0700, Manoj Srivastava wrote:
> On Sun, Sep 07 2014, Scott Kitterman wrote:
>
> > On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava
> > wrote:
>
> > I'll confess up front that I'm a neophyte when it comes to git. From
> > what I can tell though we've been usin
On Sun, Sep 07 2014, Scott Kitterman wrote:
> On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava
> wrote:
> I'll confess up front that I'm a neophyte when it comes to git. From
> what I can tell though we've been using git-dpm for feature branches
> in pkg-clamav and it seems to me to work
On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava
wrote:
>On Sun, Sep 07 2014, Brian May wrote:
>
>
>> In another email by Manoj Srivastava:
>>
>>> That is really a matter of displaying history. The diagram
>> displays Git history, not the patches; when B21 is committed, > there
>is
On Sun, Sep 07 2014, Brian May wrote:
> In another email by Manoj Srivastava:
>
>> That is really a matter of displaying history. The diagram
> displays Git history, not the patches; when B21 is committed, > there is no
> patch representing B12, however, that commit is still in /.git/obje
On 28 August 2014 00:41, Paulo Tomé wrote:
> rebasing is not an option for any branch that is published, and is very
>> ride to your downstream developers. if git-dpm requires that model of
>> software development, one would have to consider it unsuitable for non
>> trivial package development. I
On 08/26/2014 10:53 PM, Brian May wrote:
On 26 August 2014 16:12, Manoj Srivastava
wrote:
http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a
demonstration of the differences in history given an upstream and two
feature branches with two commits each, using git-dpm and git-de
On Wed, 20 Aug 2014, Jeremy Stanley wrote:
> There still seems to be some legal contention around Apache License
> 2.0 expecting an authors list for a project. And I agree copyright
Not just that one, there are other licences with weird
terms like that.
> significant enough to amend the years/ho
On 27-08-2014 15:24, Manoj Srivastava wrote:
hi,
rebasing is not an option for any branch that is published, and is
very ride to your downstream developers. if git-dpm requires that
model of software development, one would have to consider it
unsuitable for non trivial package development. I
hi,
rebasing is not an option for any branch that is published, and is very ride
to your downstream developers. if git-dpm requires that model of software
development, one would have to consider it unsuitable for non trivial package
development. I certainly hope that is not the case.
Ma
hi,
in my analysis, features a and b are indeed long lived branches with multiple
commits over time, independently evolving, until such time they are folded in
upstream.
I will address the other point when I an motte awake, I recognize that
git-dpm creates ephemeral branches, but the com
Hi,
On Wed, 27 Aug 2014, Matthias Urlichs wrote:
> Brian May:
> > I don't think you should use normally be feature branches with git-dpm.
> > Rather you edit the commit directly (whether by rebase or --amend).
>
> If Upstream uses git and wants you to send a pull request when you add a
> feature
Hi,
Brian May:
> I don't think you should use normally be feature branches with git-dpm.
> Rather you edit the commit directly (whether by rebase or --amend).
>
If Upstream uses git and wants you to send a pull request when you add a
feature (or fix a bug), then using a feature branch is what you
On 26 August 2014 16:12, Manoj Srivastava
wrote:
> http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a
> demonstration of the differences in history given an upstream and two
> feature branches with two commits each, using git-dpm and git-debcherry.
>
Interesting review.
Howev
Hi Guido,
On Di 26 Aug 2014 12:14:58 CEST, Guido Günther wrote:
That said it'd be nice to know why it's more convenient to not have
the upstream sources in git since I think one misses out on many of
the advantages of git based packaging (like rebasing patches to new
upstream versions).
The
On Sun, Aug 24, 2014 at 02:11:16PM +, Mike Gabriel wrote:
[..snip..]
> >- shall we standardize the "pristine-tar" branch?
>
> I'd say "No" here. With packaging of the MATE desktop environment I started
> maintaining only the debian/ folders in the packaging Git repositories (e.g.
> [1]). So, I
On Tue, Aug 26, 2014 at 08:19:48AM +0100, Simon McVittie wrote:
> On 26/08/14 07:01, Brian May wrote:
> > In gbp-pq [...] There is no history kept of
> > the patch-queue branch. Possibly the patch-queue branch shouldn't be
> > pushed to remote repositories, because rebasing is expected.
>
> You ar
On Mon, Aug 25, 2014 at 04:38:05PM +1000, Brian May wrote:
> On 25 August 2014 14:34, Barry Warsaw wrote:
>
> > I'm beginning to think that what we want is for gbp and git-dpm to
> > interoperate, such that any individual maintainer can use whichever tool
> > they
> > choose, but would still allo
On 26/08/14 07:01, Brian May wrote:
> In gbp-pq [...] There is no history kept of
> the patch-queue branch. Possibly the patch-queue branch shouldn't be
> pushed to remote repositories, because rebasing is expected.
You are correct in thinking that it is conventional to avoid pushing the
patch-que
hi.
http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a
demonstration of the differences in history given an upstream and two feature
branches with two commits each, using git-dpm and git-debcherry.
Manoj
On August 25, 2014 11:01:17 PM PDT, Brian May
wrote:
>Ok, so I
Ok, so I have looked at both gbp-pq and git-dpm.
To me, the key difference is different way they store the patches. There
are minor differences in user interfaces, etc, however I don't consider
these to be so important.
(apologies if this has already been said or contradicted, I am finding it
har
hi,
habit looked at both, I think I prefer got-debcherry. since it created a
(IMHO) cleaner history, easier for me to understand and bisect.
Manoj
On August 24, 2014 9:34:29 PM PDT, Barry Warsaw wrote:
>On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote:
>
>>git-buildpackage's gbp pq system
On 25 August 2014 14:34, Barry Warsaw wrote:
> I'm beginning to think that what we want is for gbp and git-dpm to
> interoperate, such that any individual maintainer can use whichever tool
> they
> choose, but would still allow the team to adhere to consensus
> recommendations,
> so there's no gu
On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote:
>git-buildpackage's gbp pq system is what I use. I believe git-dpm is more
>complicated and comprehensive, but gbp pq is simple enough in its
>operations that it doesn't take long to wrap your mind around it.
git-dpm seems pretty easy to use as w
Brian May writes:
> On 24 August 2014 04:24, Russ Allbery wrote:
>> Right, exactly. That's super-annoying to do if you were keeping
>> everything mixed together in the master branch, much easier if you were
>> keeping separate branches for each fix but keeping those separate
>> branches is itse
On 24 August 2014 04:24, Russ Allbery wrote:
> Right, exactly. That's super-annoying to do if you were keeping
> everything mixed together in the master branch, much easier if you were
> keeping separate branches for each fix but keeping those separate branches
> is itself incredibly annoying, a
Le Sun, Aug 24, 2014 at 02:11:16PM +, Mike Gabriel a écrit :
>
> >- shall we standardize the "pristine-tar" branch?
>
> I'd say "No" here. With packaging of the MATE desktop environment I
> started maintaining only the debian/ folders in the packaging Git
> repositories (e.g. [1]). So, I am n
Hi Raphael, hi all,
On Fr 15 Aug 2014 16:16:01 CEST, Raphael Hertzog wrote:
- how do we tag the package releases?
- pkg/
(note: git-buildpackage uses debian/ but I find this confusing
as we then also have the "debian/" prefix for ubuntu or kali uploads, we
don't need the vendor prefix
Matthias Urlichs writes:
> Russ Allbery:
>> It's somewhat harder to maintain, but it's vastly better for
>> communicating to upstream or to other distributions.
> Mmh. Whenever Upstream uses git, my favorite method of sending a patch
> is to put the fix in a separate branch, and then tell ^w ask
Hi,
Russ Allbery:
> It's somewhat harder to maintain, but it's vastly better for
> communicating to upstream or to other distributions.
>
Mmh. Whenever Upstream uses git, my favorite method of sending a patch
is to put the fix in a separate branch, and then tell ^w ask them
to "git pull" it.
--
Matthias Urlichs writes:
> I do wonder, though, how many DDs would rather switch to a preferred
> form of "the debian branch of a git repo, based on the upstream VCS,
> with all changes as git commits". No debian/patches. Source format: a
> tarball with the FOO.git directory (not compressed, as "
Hi,
Scott Kitterman:
> Whatever is "standardized" it really, really ought to produce a useful source
> package as that's the preferred form of modification in the project.
>
I do wonder, though, how many DDs would rather switch to a preferred form
of "the debian branch of a git repo, based on th
Hi,
Ian Jackson:
> In order to generate the correct diff etc. you need the _tree(s)_
> corresponding to the .orig*.tar but in principle those could be
> provided as git tree objects somehow.
>
s/ somehow//: An original-tar branch instead of the current semi-supported
pristine-tar overkill, with t
On 08/20/2014 08:57 AM, Jeremy Stanley wrote:
> also in many
> cases the authors are not the copyright holders, but rather their
> employers are, so the authors list can be essentially irrelevant
> where copyright is concerned
Yeah, this is exactly the problem, as it has been pointed out (rightly)
On Aug 20, 2014, at 02:17 PM, Ian Jackson wrote:
>I am planning to have dgit do some git-dpm'ish things, probably
>actually using git-dpm.
Excellent. I've been playing around with git-dpm (as described over in
debian-python@) and it does a lot of nice things. There are a few glitches
IMHO, but
On August 19, 2014 8:08:14 PM EDT, Jeremy Stanley wrote:
>On 2014-08-20 02:32:10 +0800 (+0800), Thomas Goirand wrote:
>[...]
>> Good! For the moment, it has worked nicely, apart from the fact that
>> *some* upstream, like Jeremy Stanley, don't like it. I honestly feel
>> sorry about that, especial
Thorsten Glaser writes ("Re: Standardizing the layout of git packaging
repositories"):
> On Fri, 15 Aug 2014, Russ Allbery wrote:
> > I want to be able to check out a git repository and do packaging work and
> > an upload, without having to pull any external artifact
Simon McVittie writes ("Re: Standardizing the layout of git packaging
repositories"):
> [stuff]
Thanks for this helpful survey.
> dgit
>
>
> dgit encourages the answer to be "exactly the source that will be built,
> vendor patches *are* applied, if the
On 2014-08-20 02:21:35 +0800 (+0800), Thomas Goirand wrote:
> Well, for the changelog of OpenStack stuff, the FTP masters have
> express their opinion that it's just too big to be in every
> packages, so I have to *not* include them.
Understandable for some of those larger projects with many thous
On 2014-08-20 02:32:10 +0800 (+0800), Thomas Goirand wrote:
[...]
> Good! For the moment, it has worked nicely, apart from the fact that
> *some* upstream, like Jeremy Stanley, don't like it. I honestly feel
> sorry about that, especially with people like Jeremy and other OpenStack
> folks which ar
I would like to point out some considerations.
A winning approach for me is:
* don't assume that if I maintain packages in git, upstream is also
developing using git.
* don't assume that upstream is making releases. Maybe they don't make
tarballs, even tags. Maybe they do, but they are very wrong
On 08/19/2014 07:40 AM, Barry Warsaw wrote:
> As Debian developers, I think we generally shouldn't be dictating best
> practices to upstreams. Let them do whatever is most comfortable to them and
> let them concentrate on making good software!
I agree with that. But the same way, I don't think up
On 08/19/2014 04:40 AM, Jeremy Stanley wrote:
> For a variety of historical and pragmatic reasons, many distribution
> channels expect a release tarball to contain some information which
> is more efficiently stored in VCS metadata (authorship, detailed
> change information, version numbers, et cet
On Sat, 16 Aug 2014, Russ Allbery wrote:
> > And anyway I'd say that downloading the original archive is simpler than
> > having to deal with pristine-tar...
>
> I'm mystified. What is there to deal with? I literally never touch it.
> It just works, completely transparently and silently.
Unfor
On Tue, 19 Aug 2014, Lars Wirzenius wrote:
> On Mon, Aug 18, 2014 at 07:28:51PM -0400, Barry Warsaw wrote:
> > Also, it makes me somewhat uncomfortable to assume that a git tag in the
> > upstream repo will always be equivalent to their released tarball. In fact,
> > it's often not, as is the case
On Mon, Aug 18, 2014 at 07:28:51PM -0400, Barry Warsaw wrote:
> Also, it makes me somewhat uncomfortable to assume that a git tag in the
> upstream repo will always be equivalent to their released tarball. In fact,
> it's often not, as is the case with Python packages containing a MANIFEST.in.
I
Barry Warsaw writes:
> It makes more sense when you're a pure upstream, as master might be
> where you do all your cutting edge development, and there isn't usually
> a clear alternative naming scheme (e.g. code names). 'trunk' might be
> better anyway. But in Debian's case, all packaging work
On Aug 16, 2014, at 04:28 PM, Thomas Goirand wrote:
>Why?!? Is there some sort of religion around tarballs? Shouldn't it be
>the same stuff that "git archive" does? If it isn't, why is this the
>case? Shouldn't one be able to use what's in the Git repository anyway?
>Why can't it be fixed? Aren't
On Aug 17, 2014, at 08:47 PM, Henrique de Moraes Holschuh wrote:
>It is not meaningless in the sense that it is a widely used convention in
>git repositories.
>
>And that's actually quite relevant.
It makes more sense when you're a pure upstream, as master might be where you
do all your cutting e
On Aug 16, 2014, at 01:15 AM, Thomas Goirand wrote:
>As in, always use pristine-tar? No! The point of using git packaging is
>also to be able to use upstream git repo.
What about cases where upstream doesn't use git but you still want to use git
for your packaging branch?
Also, it makes me somew
On Aug 17, 2014, at 11:19 AM, Thomas Goirand wrote:
>By the way, I try to always avoid using "master" as a branch name. This
>doesn't express anything at all.
+1
In the context of Ubuntu (and when it works ) I really like the approach
taken for UDD branches. I can always branch the version of t
Le Mon, Aug 18, 2014 at 02:16:55PM +0200, Jakub Wilk a écrit :
>
> FWIW, "rc-buggy" is not the codename for experimental:
>
> $ wget -q -O- http://http.debian.net/debian/dists/experimental/Release | grep
> -m1 ^Codename:
> Codename: experimental
Excellent news !
So seems that I have been confu
On 2014-08-17 16:20:34 +0800 (+0800), Thomas Goirand wrote:
> But then in which way will you check that the said upstream tarball,
> without any upstream checksum, is valid? At least tags are
> signed...
You keep coming back to the assumption that upstreams don't provide
signed lists of checksums.
On 2014-08-16 16:28:40 +0800 (+0800), Thomas Goirand wrote:
[...]
> If I prefer to use their git repository, and create my
> own orig.tar.xz out of a signed git tag, what is the problem, as
> long as I use the tag they provided by upstream?
[...]
Mainly that the checksums for your orig.tar.{g,x}z
On Sun, 2014-08-17 at 09:00 +0200, Raphael Hertzog wrote:
> On Sun, 17 Aug 2014, Thomas Goirand wrote:
> > Well, I have nothing against derivative/downstream distros, but if
> > you're about to do a new DEP, please consider Debian first. In such
> > case, debian/unstable makes a lot more sense than
Russ Allbery wrote:
> No, I'm pretty sure that currently works. But I don't know how much that
> relies on modifications to Debian's tar package.
It doesn't matter what tar was used to create the original tarball; as
long as we know the files present in it, we can use a (necessarily
stable versio
Hi,
> I do think that this is quite common, and my preferred way of doing
> things. It is easy for newcomers to handle, easy for me to handle, no
> need to learn a lot of git specific tools or helpers, you can mostly
> ignore git if you want to.
>
> I've a couple of times tried to get myself to a
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> > Obviously, when upstream are already doing everything correctly, creating
> > the upstream/ tag should not become some administrative chore but
> > it could be done automatically as part of a some "gbp upstream-merge
> > " command for example.
>
> Ah,
On Mon, 18 Aug 2014, Don Armstrong wrote:
> On Mon, 18 Aug 2014, Thorsten Glaser wrote:
> > This does not work in Debian: you always need the .orig.tar.* file,
> > at least for the upload, for non-native packages.
>
> You need it from somewhere, but the whole point of pristine-tar is that
> you ca
2014-08-18 14:27:15 Thorsten Glaser:
> On Sun, 17 Aug 2014, Jonathan Dowland wrote:
> > On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> > > - encoding (due to git restrictions):
> > > ":" -> "%"
> > > "~" -> "_"
>
> I’d rather have something that sorts like Debian versi
On Mon, Aug 18, 2014 at 02:27:15PM +0200, Thorsten Glaser wrote:
> I’d rather have something that sorts like Debian versions
> in “git tag” output…
If that proves too hard to achieve with a mapping scheme, it would
be trivial to write a filter to implement it. It does sound useful.
> Yikes!
>
>
Thomas Goirand writes:
> On 08/18/2014 01:49 AM, Russ Allbery wrote:
>> Joey took various approaches to work around this, including shipping
>> some of the older versions of the compressors in the package. However,
>> the issue also applies to tar, and so far has been addressed by
>> modifying t
On Mon, 18 Aug 2014, Thorsten Glaser wrote:
> This does not work in Debian: you always need the .orig.tar.* file,
> at least for the upload, for non-native packages.
You need it from somewhere, but the whole point of pristine-tar is that
you can generate the orig.tar.* from information in the git
On Sat, Aug 16, 2014 at 01:59:46PM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 15 Aug 2014, Guido Günther wrote:
> > The gbp manual has a recommended branch layout:
> >
> >
> > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
> >
> > which co
On Sun, 17 Aug 2014, Jonathan Dowland wrote:
> On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
> > - encoding (due to git restrictions):
> > ":" -> "%"
> > "~" -> "_"
I’d rather have something that sorts like Debian versions
in “git tag” output…
> "_" -> "_5f"
>
* Charles Plessy , 2014-08-17, 19:39:
for suites that are never released, I think that it is fine to not use
the codename. Otherwise, people will be confused with debian/rc-buggy.
FWIW, "rc-buggy" is not the codename for experimental:
$ wget -q -O- http://http.debian.net/debian/dists/experime
On Sun, 17 Aug 2014, Neil Williams wrote:
> > The vast majority (all?) of git packaging repositories have the
> > upstream sources.
>
> No. None of mine do, or will.
I’m working with some which also don’t, and find it would be easier
if there were a way to extract a .orig.tar.gz in the same way
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> Like I wrote in another post, "master" doesn't express anything.
ACK.
> All of this is error prone. Using upstream tags and merging them rather
> than branches avoid troubles. I have yet to see a case where using
> upstream tags wasn't practical.
The
On Fri, 15 Aug 2014, Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > The first step is to determine which problem you are trying to solve.
Surprisingly insightful, this one.
> I want to be able to check out a git repository and do packaging work and
> an upload, without having to
On Sat, 16 Aug 2014, Thomas Goirand wrote:
> Why would you tag the upstream release? I mean, it's upstream's job to
Yeah, if upstream uses git at least it should NOT be done by
the packager.
If not, it depends.
> > - shall we standardize the "pristine-tar" branch?
>
> As in, always use pristin
On Sat, Aug 16, 2014 at 09:51:21PM +0200, Bastien ROUCARIES wrote:
> On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog wrote:
> > Hi,
> >
> > On Fri, 15 Aug 2014, Guido Günther wrote:
> >> The gbp manual has a recommended branch layout:
> >>
> >>
> >> http://honk.sigxcpu.org/projects/git-buildpa
On 08/18/2014 03:08 PM, Thomas Goirand wrote:
> On 08/18/2014 01:49 AM, Russ Allbery wrote:
>> Joey took various approaches to work around this, including shipping some
>> of the older versions of the compressors in the package. However, the
>> issue also applies to tar, and so far has been addres
On 08/18/2014 01:49 AM, Russ Allbery wrote:
> Joey took various approaches to work around this, including shipping some
> of the older versions of the compressors in the package. However, the
> issue also applies to tar, and so far has been addressed by modifying tar
> to add a backword-compatibil
On 08/18/2014 07:47 AM, Henrique de Moraes Holschuh wrote:
> On Sun, 17 Aug 2014, Thomas Goirand wrote:
>> On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
>>> On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
> - the above layout is for the traditional case of non-native packages,
>
Hi Russ,
On Sun, Aug 17, 2014 at 10:31:26AM -0700, Russ Allbery wrote:
> Thomas Goirand writes:
>
> > As Charles wrote, pristine-tar works with small tarballs, but when
> > upstream has multi-megabytes tarballs and releases often, the Git
> > repository quickly grows to something not manageable.
On Sat, Aug 16, 2014 at 02:03:18PM +0200, Raphael Hertzog wrote:
> The vast majority (all?) of git packaging repositories have the upstream
> sources.
>
> I think this point is not really contentious.
Others have demonstrated that this is not the case. However, I believe the
majority of git packa
On Sun, Aug 17, 2014 at 04:20:34PM +0800, Thomas Goirand wrote:
> As Charles wrote, pristine-tar works with small tarballs, but when
> upstream has multi-megabytes tarballs and releases often, the Git
> repository quickly grows to something not manageable.
Only if you're lacking a proper branch t
On Sun, Aug 17, 2014 at 07:57:55PM +, Sune Vuorela wrote:
> On 2014-08-16, Raphael Hertzog wrote:
> > I believe that most of the current workflows do respect this rule (except
> > for the case where you only store the debian directory).
> I do think that this is quite common, and my preferred
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
> > On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
> >>> - the above layout is for the traditional case of non-native packages,
> >>> what would be the layout for native packages? how can be diffe
On 2014-08-16, Raphael Hertzog wrote:
> I believe that most of the current workflows do respect this rule (except
> for the case where you only store the debian directory).
I do think that this is quite common, and my preferred way of doing
things. It is easy for newcomers to handle, easy for me
Am 17.08.2014 20:33, schrieb Ansgar Burchardt:
> Michael Biebl writes:
>> It's also very easy to forget this particular caveat when you do
>> stable-security uploads.
>> And as the stable-security archive will *not* reject such a tarball, you
>> can end up with tarballs which have different md5sum
1 - 100 of 162 matches
Mail list logo
