On Mon, 10 Feb 2014 22:13:45 +0100
Wouter Verhelst wou...@debian.org wrote:
Sigh.
On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote:
Using packages to support upstream development is a common problem
/common problem/common source of problems/
and this is exactly where things
Sigh.
On Wed, Feb 05, 2014 at 12:59:23PM +, Neil Williams wrote:
Using packages to support upstream development is a common problem and
this is exactly where things get awkward.
No, it is not a *problem*; it is a *method* of doing things.
It is not your place (nor mine) to question
Andreas == Andreas Beckmann a...@debian.org writes:
Andreas On 2014-02-05 10:57, Sam Hartman wrote:
tarballs useful; anyone who is likely to want to build this from
source probably has a copy of git and can checkout a tag.
Andreas Such a tag corresponds to an upstrema version?
On Wed, 5 Feb 2014 12:21:30 +
Sam Hartman hartm...@debian.org wrote:
Andreas == Andreas Beckmann a...@debian.org writes:
Andreas On 2014-02-05 10:57, Sam Hartman wrote:
tarballs useful; anyone who is likely to want to build this
from source probably has a copy of git and
Neil == Neil Williams codeh...@debian.org writes:
That makes sense and I do something similar as appropriate. Even so, I
do not wish to maintain the upstream tarball as a maintained artifact.
There are cases where packaging release releases are made. Maintaining
pristine-tar commits for daily
* Sam Hartman hartm...@debian.org [140205 13:27]:
no, that means I have to maintain the artifact (namely the
.orig.tar.gz).
The archive software (both reprepro and dak were I to use that) require
that the .orig.tar.gz not change checksums.
I don't want my build machines to be able to push
Bernhard == Bernhard R Link brl...@debian.org writes:
As I mentioned I have a packaging branch and an upstream branch.
I wish to use debian revisions to reflect packaging changes.
It's slightly more complex than changes to debian directory involve a
debian revision change; changes to other
7 matches
Mail list logo
