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
Wookey wookey at wookware.org writes:
Do I understand this correctly - that it prevents a package
cross-binutils-0.1 to generate binaries called
binutils-arm-linux-gnueabi-2.24-3
binutils-arm-linux-gnueabihf-2.24-3
Actually, these packages will be buggy usually: debhelper uses
the source
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 Wed, Feb 5, 2014 at 12:08 AM, Charles Plessy ple...@debian.org wrote:
The 3.0 (native) format is useful when packaging a work that is developped and
distributed in a Git repository. Please leave us this possibility.
Can you elaborate a bit? From my understanding of your description I'd
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
* Charles Plessy ple...@debian.org [140205 14:18]:
Who benefited directly from the change of behavior ? Nobody ? Then please
revert it; it was not necessary.
Most import are people starting to create Debian packages.
At least with 3.0 source packages they no longer have to care about the
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
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
How to override this new behaviour that breaks backwards compatibility
of existing packages that (abuse) these bad version numbers?
It appears to be enforcing a Debian Project Policy onto packages
which are not in Debian.
Can this be
* 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 auto-rejects to clense the archive if
so is desired.
Hear,
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
Dimitri John Ledkov writes (RE: dpkg-dev: please reject native/non-native
version when building native/non-native source packages):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
...
Can this be reverted, or dpkg-source option provided to override this
new behaviour that is rejecting
+++ Dimitri John Ledkov [2014-02-04 13:30 +]:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
Do I understand this correctly - that it prevents a package
cross-binutils-0.1 to generate binaries called
binutils-arm-linux-gnueabi-2.24-3
binutils-arm-linux-gnueabihf-2.24-3
unless
On Tue, 4 Feb 2014 16:20:28 +, Wookey woo...@wookware.org wrote:
+++ Dimitri John Ledkov [2014-02-04 13:30 +]:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
Do I understand this correctly - that it prevents a package
cross-binutils-0.1 to generate binaries called
On 4 February 2014 16:20, Wookey woo...@wookware.org wrote:
+++ Dimitri John Ledkov [2014-02-04 13:30 +]:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
Do I understand this correctly - that it prevents a package
cross-binutils-0.1 to generate binaries called
No, you can still
Le Tue, Feb 04, 2014 at 02:05:45PM +, Dimitri John Ledkov a écrit :
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
22 matches
Mail list logo
