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 current
On 29 October 2014 05:39, Guido Günther a...@sigxcpu.org 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 branch is always
merged
[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 ignore list.
(or rather ignores
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
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 the default ignore list.
(or rather
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
-I. git-buildpackage passes -I
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
proper base.cow for it.
I got the impression
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-source removes it, by default, for 3.0 based
Hi,
On Wed, Oct 29, 2014 at 11:54:41AM -0200, Antonio Terceiro wrote:
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
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
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 branch is never rebased
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 Debian branch itself always heads
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
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
sriva...@debian.org wrote:
I'll confess up front that I'm a neophyte when it comes to git. From
what I can tell though we've
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 b...@decadent.org.uk
wrote:
On Sat, 2014-09-06 at 22:03 -0700, Manoj Srivastava wrote:
On Sun, Sep
On 8 September 2014 04:05, Ben Hutchings b...@decadent.org.uk 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.
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 br...@microcomaustralia.com.au
wrote:
On 8 September 2014 04:05, Ben Hutchings b...@decadent.org.uk wrote:
How does git-debcherry cope with the overlapping
On 8 September 2014 04:05, Ben Hutchings b...@decadent.org.uk 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
On 7 September 2014 13:30, Manoj Srivastava sriva...@debian.org wrote:
| I commit | Ephemeral gbranch contains | Master contains |
|--++-|
| B2 | A11, B12, B21 | D6 |
There are there nodes in the
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 br...@microcomaustralia.com.au
wrote:
On 7 September 2014 13:30, Manoj Srivastava sriva...@debian.org
wrote:
| I commit | Ephemeral gbranch contains | Master
hi,
ill send out a concrete example when I get back home
Manoj
On September 7, 2014 8:41:45 PM PDT, Brian May br...@microcomaustralia.com.au
wrote:
On 8 September 2014 04:05, Ben Hutchings b...@decadent.org.uk wrote:
How does git-debcherry cope with the overlapping changes when
On 28 August 2014 00:41, Paulo Tomé paulo.jorge.t...@gmail.com 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
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 top/.git/objects
On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava sriva...@debian.org
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,
On Sun, Sep 07 2014, Scott Kitterman wrote:
On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava sriva...@debian.org
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
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
On 08/26/2014 10:53 PM, Brian May wrote:
On 26 August 2014 16:12, Manoj Srivastava sriva...@golden-gryphon.com
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
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
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 (or fix
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
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.
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.
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
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
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-queue
On Mon, Aug 25, 2014 at 04:38:05PM +1000, Brian May wrote:
On 25 August 2014 14:34, Barry Warsaw ba...@python.org 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
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 are
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 am not
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 26 August 2014 16:12, Manoj Srivastava sriva...@golden-gryphon.com
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.
On 25 August 2014 14:34, Barry Warsaw ba...@python.org 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
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 ba...@python.org wrote:
On Aug 24, 2014, at 08:33 PM, Russ Allbery wrote:
git-buildpackage's
Hi Raphael, hi all,
On Fr 15 Aug 2014 16:16:01 CEST, Raphael Hertzog wrote:
- how do we tag the package releases?
- pkg/version
(note: git-buildpackage uses debian/version but I find this confusing
as we then also have the debian/ prefix for ubuntu or kali uploads, we
don't need the
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 not
On 24 August 2014 04:24, Russ Allbery r...@debian.org 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
Brian May br...@microcomaustralia.com.au writes:
On 24 August 2014 04:24, Russ Allbery r...@debian.org 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
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
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 matth...@urlichs.de 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
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 the
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 the
Matthias Urlichs matth...@urlichs.de 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
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 package uses 3.0 (quilt) then .pc
also
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 artifacts from somewhere
else.
Yes. dgit
On August 19, 2014 8:08:14 PM EDT, Jeremy Stanley fu...@yuggoth.org 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
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 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)
to
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 with
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.
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
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
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
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 are
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
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
Hi Russ,
On Sun, Aug 17, 2014 at 10:31:26AM -0700, Russ Allbery wrote:
Thomas Goirand z...@debian.org 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
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,
what would be
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-compatibility
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 addressed by
On Sat, Aug 16, 2014 at 09:51:21PM +0200, Bastien ROUCARIES wrote:
On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog hert...@debian.org wrote:
Hi,
On Fri, 15 Aug 2014, Guido Günther wrote:
The gbp manual has a recommended branch layout:
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 pristine-tar?
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 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.
There
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 that
* Charles Plessy ple...@debian.org, 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-
On Sun, 17 Aug 2014, Jonathan Dowland wrote:
On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
- version encoding (due to git restrictions):
: - %
~ - _
I’d rather have something that sorts like Debian versions
in “git tag” output…
_ - _5f
: - _3a
~
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 could serve as a
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
Thomas Goirand z...@debian.org 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
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!
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:
- version encoding (due to git restrictions):
: - %
~ - _
I’d rather have something that sorts like Debian versions
in “git
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 can
On Sun, 17 Aug 2014, Thomas Goirand wrote:
Obviously, when upstream are already doing everything correctly, creating
the upstream/version tag should not become some administrative chore but
it could be done automatically as part of a some gbp upstream-merge
upstream-tag command for
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
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 version
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 just
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 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. I
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 confused by
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 wink) I really like the approach
taken for UDD branches. I can always branch the version of
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
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 edge
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 we
Barry Warsaw ba...@python.org 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
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
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 just debian/master.
Like I wrote in another post, master doesn't
On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
Hi,
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 differentiate
between native/non-native layout?
On 08/17/2014 12:20 AM, Russ Allbery wrote:
Thomas Goirand z...@debian.org writes:
On 08/16/2014 07:05 AM, Jeremy Stanley wrote:
However upstream may build tarballs through a (hopefully
repeatable/automated) process at release time, publish checksums and
signatures for them, et cetera and
On 08/17/2014 03:13 AM, Raphael Hertzog wrote:
Hi Thomas,
On Sat, 16 Aug 2014, Thomas Goirand wrote:
The goal here is to be able to host in the same repository the branches
for
multiple cooperating distributions (at least so that downstream can
clone the debian respository and
Am 17.08.2014 10:20, schrieb Thomas Goirand:
On 08/17/2014 01:08 AM, Michael Biebl wrote:
More importantly (at least in my experience): If you are working in a
team and you regenerate the tarball from git, it's very likely that
the md5sum of the generated tarball differs from what has been
1 - 100 of 162 matches
Mail list logo
