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
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
control: subscribe -1
Charles == Charles Plessy ple...@debian.org writes:
Charles The 3.0 (native) format is useful when packaging a work
Charles that is developped and distributed in a Git repository.
Charles Please leave us this possibility.
Let me describe the use case I have
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.
Such a tag corresponds to an upstrema version?
I'm happy to entertain other options rather than 3.0(native) but my
requirements
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
Le Wed, Feb 05, 2014 at 12:46:09PM +0100, Andreas Beckmann a écrit :
All this sounds like it can be done with git-buildpackage
Hello everybody,
I have the impression that we are arguing because of solution in search for a
problem.
Some things worked with the previous version of dpkg, with no
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
On 4 February 2014 13:38, Jakub Wilk jw...@debian.org wrote:
* Dimitri John Ledkov x...@debian.org, 2014-02-04, 13:30:
Enforcing Debian Policy at dpkg-source -b . level, is not a good idea,
especially when it breaks backwards compat for 3rd parties. We have lintian,
and ftp-master lintian
Dimitri John Ledkov writes (Re: dpkg-dev: please reject native/non-native
version when building native/non-native source packages):
Patch is attached to the new bug filed about this issue
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634
Proposed patch adds --force-native dpkg-source
12 matches
Mail list logo
