Wookey 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 version
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
* Charles Plessy [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
different meanings o
* 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
On Wed, Feb 5, 2014 at 12:08 AM, Charles Plessy 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
consider your (git)
Le Tue, Feb 04, 2014 at 02:05:45PM +, Dimitri John Ledkov a écrit :
> 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 3
On 4 February 2014 16:20, Wookey 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 generate any bi
On Tue, 4 Feb 2014 16:20:28 +, Wookey 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
> binutils-arm-linux-g
+++ 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 cros
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 &q
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
> ne
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
* 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 archive if
so is desired.
Hear, hear. And I even dou
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 reve
22 matches
Mail list logo
