On Mon, 10 Feb 2014 22:13:45 +0100
Wouter Verhelst 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 get awkwar
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 anoth
> "Bernhard" == Bernhard R Link 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 things involve
* Sam Hartman [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 back to my mast
> "Neil" == Neil Williams 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 builds is a
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 n
On Wed, 5 Feb 2014 12:21:30 +
Sam Hartman wrote:
> > "Andreas" == Andreas Beckmann 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" == Andreas Beckmann 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?
y
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
> requirement
control: subscribe -1
> "Charles" == Charles Plessy 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 which is
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-sour
On 4 February 2014 13:38, Jakub Wilk wrote:
> * Dimitri John Ledkov , 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 auto-rejects to clense the
12 matches
Mail list logo
