Loïc Minier wrote:
> On Thu, Feb 14, 2008, Frank Lichtenheld wrote:
> > Hmm, I doubt that dpkg-dev should be the place to keep track of that.
> > I mean, that probably depends on the version of gcc/g++/whatever used,
> > so it's quite meaningless to make it dependent on the version of
> > dpkg-dev
On Thu, Feb 14, 2008, Frank Lichtenheld wrote:
> Hmm, I doubt that dpkg-dev should be the place to keep track of that.
> I mean, that probably depends on the version of gcc/g++/whatever used,
> so it's quite meaningless to make it dependent on the version of
> dpkg-dev you use.
Should we have a n
On Wed, Feb 13, 2008 at 10:01:00PM +0100, Moritz Muehlenhoff wrote:
> On Mon, Feb 11, 2008 at 05:44:33PM +0100, Matthias Klose wrote:
> > Moritz Muehlenhoff writes:
> > > [This message has also been posted to gmane.linux.debian.devel.general.]
> > > On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECT
On Mon, Feb 11, 2008 at 05:44:33PM +0100, Matthias Klose wrote:
> Moritz Muehlenhoff writes:
> > [This message has also been posted to gmane.linux.debian.devel.general.]
> > On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> > > Matthias Klose wrote:
> > >> This is a proposal to introdu
Moritz Muehlenhoff writes:
> [This message has also been posted to gmane.linux.debian.devel.general.]
> On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> > Matthias Klose wrote:
> >> This is a proposal to introduce a common set of compiler options which
> >> can be set independently fr
On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> Matthias Klose wrote:
>> This is a proposal to introduce a common set of compiler options which
>> can be set independently from the package, and passed/injected to the
>> package build process. It was first discussed at the last UDS;
Matthias Klose wrote:
> This is a proposal to introduce a common set of compiler options which
> can be set independently from the package, and passed/injected to the
> package build process. It was first discussed at the last UDS; a
> corresponding wiki page can be found at [1].
A change like th
On Fri, Dec 07, 2007 at 08:23:28AM +0100, Loïc Minier wrote:
> With constructs like:
>
> PYVERS := $(shell pyversions -vr debian/control 2>/dev/null)
>
> build-%:
> PYTHON=`which python$*` ./configure
I guess this should have been "`which $*` ./configure", right? If so,
re
On Tue, Dec 04, 2007 at 08:50:15PM +0100, Frank Lichtenheld wrote:
> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
> > === Alternate naming of the macros ===
> >
> > Do omit the '''DEB_HOST_''' prefix and all packages should honour the
> > value of CFLAGS etc. in the environment.
On Thu, Dec 06, 2007, Steve Langasek wrote:
> Then why in the world are you using "build-%" if you don't support
> build-arch? What other values of '%' are you using?
build-python2.4, build-python2.5...
With constructs like:
PYVERS := $(shell pyversions -vr debian/control 2>/d
On Thu, Dec 06, 2007 at 08:54:29PM +0100, Loïc Minier wrote:
> I got the feeling it was flaky from the criticism I read on
> debian-policy@ and that it couldn't work for all Makefiles; for example
> someone proposed to "make -f debian/rules -pn | grep '^build-arch:'"
> but this obviously wont f
On Thu, Dec 06, 2007, Russ Allbery wrote:
>I think we need a clear consensus to change
> it, and I haven't gotten the impression that such a consensus exists.
(Fair enough.)
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubs
On Thu, Dec 06, 2007, Manoj Srivastava wrote:
> *Sigh*.
> __> make -pn build-arch | grep '^build-arch'
> build-arch:
> OK?
Dude, there's no need to sigh out loudly; "make -pn $target" doesn't
change anything, but you didn't even read the rest of my point: that
packages were *alr
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I am convinced that this bug report is of dubious value, and if
> Russ agrees, I am going to just mark this report as closed, or as
> wontfix.
Yup, I tagged this one dubious myself a while back. I agree with closing
it. I know that not ev
On Thu, 6 Dec 2007 20:54:29 +0100, Loïc Minier <[EMAIL PROTECTED]> said:
> I got the feeling it was flaky from the criticism I read on
> debian-policy@ and that it couldn't work for all Makefiles; for example
> someone proposed to "make -f debian/rules -pn | grep '^build-arch:'"
> but this obvious
On Thu, Dec 06, 2007, Manoj Srivastava wrote:
> >> d) stands in the way of technical proposals like passing information
> >> to the build system on the command line
> >> e) prevents people from relying on make semantics for builds.
>
> > The two above points are the same argument. The only prop
On Thu, 6 Dec 2007 18:23:16 +0100, Loïc Minier <[EMAIL PROTECTED]> said:
> On Thu, Dec 06, 2007, Manoj Srivastava wrote:
>> a) Adds no practical value
> It's about rejecting a change to policy; I don't see why it should
> add practical value.
The change was made in 2001. That is nearl
Loïc Minier <[EMAIL PROTECTED]> writes:
> On Thu, Dec 06, 2007, Manoj Srivastava wrote:
>> b) does not represent current practice
>> c) not implementing the proposal is not a technical hindrance to any
>> package
> This is the same point. Just for the record, there's a small set of
>
On Thu, Dec 06, 2007, Manoj Srivastava wrote:
> a) Adds no practical value
It's about rejecting a change to policy; I don't see why it should add
practical value.
> b) does not represent current practice
> c) not implementing the proposal is not a technical hindrance to any
> package
user [EMAIL PROTECTED]
usertag 432564 +dubious
thanks
On Thu, 6 Dec 2007 08:15:08 + (UTC), Frank Küster <[EMAIL PROTECTED]> said:
> Manoj Srivastava debian.org> writes:
>>
>> On Wed, 5 Dec 2007 21:11:53 +0100, Matthias Klose > cs.tu-berlin.de>
> said:
>>
>> > IIRC we cannot assume that d
On Thu, Dec 06, 2007 at 08:15:08AM +, Frank Küster wrote:
> Indeed - but there's a bug, #432564, requesting to change it.
Hmm. Which seems quiet controversal. Maybe the DD should find a decision
on this, before anything else? But this topic is again an example why
changing debian/rules to some
Manoj Srivastava debian.org> writes:
>
> On Wed, 5 Dec 2007 21:11:53 +0100, Matthias Klose cs.tu-berlin.de>
said:
>
> > IIRC we cannot assume that debian/rules is a makefile and pass them as
> > macros directly, so we have to pass them as environment variables.
>
> I think you rememb
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> The two packages in question are leave and webserver-package, and as it
> turns out, the latter is a false positive, since my grepping for
> debian/rules found a file that wasn't a real debian/rules file. So, only
> one package in etch/main uses somethi
On ke, 2007-12-05 at 21:11 +0100, Matthias Klose wrote:
> IIRC we cannot assume that debian/rules is a makefile and pass them as
> macros directly, so we have to pass them as environment variables.
Debian Policy, 4.9, "Main building script: debian/rules":
This file must be an executable m
On Wed, 5 Dec 2007 21:11:53 +0100, Matthias Klose <[EMAIL PROTECTED]> said:
> Frank Lichtenheld writes:
>> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
>> > We define a set of macros which are passed from dpkg-buildpackage
>> > to
>>
>> If you say "macros" you mean the same as
Frank Lichtenheld writes:
> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
> > We define a set of macros which are passed from dpkg-buildpackage to
>
> If you say "macros" you mean the same as environment variables?
IIRC we cannot assume that debian/rules is a makefile and pass t
On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
> We define a set of macros which are passed from dpkg-buildpackage to
If you say "macros" you mean the same as environment variables?
[...]
> === Alternate naming of the macros ===
>
> Do omit the '''DEB_HOST_''' prefix and all pac
This is a proposal to introduce a common set of compiler options which
can be set independently from the package, and passed/injected to the
package build process. It was first discussed at the last UDS; a
corresponding wiki page can be found at [1].
== Rationale ==
The set of compiler/linker fl
28 matches
Mail list logo
