?
Or perhaps:
DEB_CFLAGS_SET ?= $(shell dpkg-buildflags --get CFLAGS)
[...]
./configure CFLAGS=$(DEB_CFLAGS_SET)
I see that's not in the man page, not sure it would make sense in
policy either.
Thanks
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ
as bin NMUs of Debian packages.
PS: 1.2-3.0.1 binNMU gets rejected by DAK now, only 1.2-3+b1 is
accepted.
As I understand it, all problems that appeared in this discussion are
solved with the new scheme.
Bye,
--
Loïc Minier [EMAIL PROTECTED]
What do we want? BRAINS!When do we want
locations. The correct way to disable
services is to configure the service as stopped in all runlevels in
which it is started by default. In the System V init system this means
renaming the service's symbolic links from S to K.
Does that solve your bug?
--
Loïc Minier [EMAIL PROTECTED]
database)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Loïc Minier [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
of having a
configuration to decide to remove user on purge or to keep them.
--
Loïc Minier [EMAIL PROTECTED]
10 SIN
20 GO TO ROBOT HELL -- Temple of Robotology
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
.
--
Loïc Minier [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
Can't we simply allow passing MAKEFLAGS in the env of debian/rules
instead of defining new vars?
Bye,
--
Loïc Minier
/build.log
This is what I used in my packages:
MAKEFLAGS += $(if $(DEB_BUILD_OPTIONS_PARALLEL),-j2
$(DEB_BUILD_OPTIONS_PARALLEL))
(It wont work with packages calling $(MAKE) -f debian/rules which should
protect against adding another -j flag in the submake.)
Bye,
--
Loïc Minier
.
(And there was the same problem with /usr/lib/nautilus/extensions-1.0/
plugins in totem.)
Bye,
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-rc5-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-- no debconf information
--
Loïc Minier
of keywords and parameters with
parameters taking the form name=value. The allowed chars for name
and values would be limited to a-z, A-Z, 1-9, dash, and underscore.
--
Loïc Minier
be mentionned
as a possibility instead of mentionning it in the make snippet.
BTW, MAKEFLAGS also affects the make run for debian/rules, that is if
you extend MAKEFLAGS, debian/rules must be -j-safe too.
--
Loïc Minier
=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
endif
But perhaps the biggest problem is that this would block us from ever
allowing commas as part of the DEB_BUILD_OPTIONS, for example to pass
LDFLAGS=-Wl,something (which would work if only spaces are allowed).
--
Loïc
On Sat, Aug 04, 2007, Matthias Klose wrote:
do it without changing DEB_BUILD_OPTIONS:
What's the gain? I only see the duplication of the $(subst ) foo, and
the risk to forget that DEB_BUILD_OPTIONS might be comma-separated
later in debian/rules.
--
Loïc Minier
such DEB_BUILD_OPTIONS:
LDFLAGS=-Wl,--as-needed,parallel=2,debug
LDFLAGS=-Wl,-T,link,parallel=2,debug
(how would you tell where the LDFLAGS end?)
--
Loïc Minier
+=:
DEB_BUILD_OPTIONS=CFLAGS=-Os parallel=2 debug CFLAGS+=-g
(The += words could be parsed in Make using eval for example.)
--
Loïc Minier
very lax dependencies in the -dbg packages and on the -dbg
packages.
Thanks,
--
Loïc Minier
build in one -dbg per source, there's no
technical issue. On the other hand, renaming the -dbg to carry the
SONAME is gratuitous and doesn't have any additional value.
--
Loïc Minier
or
nautilus-file-management-properties.
--
Loïc Minier
goals or to update the standard requirements in policy.
--
Loïc Minier
, and what I would like is simply to have
this standard way of detecting what a package supports.
--
Loïc Minier
) profit???
Not constraining the interface if we don't need to? There's a huge
difference in possibilities between any script and a Makefile.
Yes, we can do it in other ways, such as defining which flags or env
vars have to be honored, or which files have to be read.
--
Loïc Minier
the list of targets (to check for build-arch for example)
with a make flag wont work either (Policy doesn't require it anyway)
So arguing that you can pretend that your rules are a makefile while
they are actually not is completely destroying the only benefit of the
requirement...
--
Loïc
want it recorded that some people do think it's a bad idea
to require debian/rules to be a Makefile; I hope it will discourages
people to rely on this.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
let us paint him as an irrational bigot. I am going to ignore this as
the logical fallacy that it is.
I didn't say you were irrational; still your response vastly proves my
point: that you're not reading in a mindset where you could reconsider
your position.
--
Loïc Minier
; the new part is to
actually rely on that.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
/null)
build-%:
PYTHON=`which python$*` ./configure
...
build: $(PYVERS:%=build-%)
And it doesn't even conflict with implemeting build-arch; it just makes
the test make moot.
glib2.0 has a very similar example for each of its flavors (deb and
udeb).
--
Loïc
://wiki.debian.org/DebianPython/NewPolicy
(and I didn't touch it! :)
--
Loïc Minier
packages; perhaps slightly harder to read the first time, but
soon becomes a well known line which eats less space.
--
Loïc Minier
are
useful to save space on e.g. live CDs where /usr/share/doc
proliferation has a non-negligible cost (some MBs).
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
.
That's still quite big. :-/
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
system. Of
course these are usually shipped with the upstream tarballs, but are
often missing/incomplete.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
on aclocal).
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
)
- kontact and evolution - fits different to different people
These don't have an OnlyShowIn here and should show up in KDE menus.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
in maintaining a GNOME subpolicy document, I
guess he could try collecting information with us.
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
-dev = 1.14.17 bdep of course.
Please announce it to devel-announce if you end up deciding to revert
these CFLAGS.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
if we could express some inheritance
concept so that you can have conditional behavior in rules based on
either this distribution and its derivatives or only for this exact
distribution and logical combinations such as derivatives of Foo
except derivatives of Bar.
--
Loïc Minier
any
good idea. I think I'd be fine with either an external tool or
environment vars, but in any case the handling of specific vendor and
inherited vendors should be similar IMO.
Thanks!
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject
is not good enough for e.g. derivatives of
Ubuntu as they want to fork the Ubuntu behavior and patches etc.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
think I'd personally
prefer erroring out to raise the issue, but that's only if there's a
sane way to handle that properly, which could be your DEB_VENDORS
proposal. ]
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
and fixes to the debian-policy@ readers.
Bye,
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.9-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
--
Loïc Minier [EMAIL PROTECTED]
Come, your destiny awaits!
Index: policy.sgml
OS
should not be too GCC, i386, or ELF specific.
Hence, I think the developers-reference might be a better place to
document best practices, or expected practices.
Bye,
--
Loïc Minier [EMAIL PROTECTED]
prefer the functionality be described as
such.
I suppose all of this would best be described by examples, and BNF
rules or regular expressions.
2c,
--
Loïc Minier [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
45 matches
Mail list logo
