gs --get CFLAGS)
instead?
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 UNSUBSCRIB
dmins populating their site file with random
> settings (or syntax errors?).
Full ack, thanks for putting it so clearly
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
d but I don't think the choice of Debian's
behavior for unknown vendors is the right one, I 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. ]
--
g at DEB_VENDOR at all).
Applying the Debian logic 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
t mind using;
albeit the name of the field isn't too obvious but I don't have 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 Minie
untu).
Instead, I think it would be nice 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 "deriv
from
dpkg-bp. I added a dpkg-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
ns on [EMAIL PROTECTED]
If anyone is interested 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]
in KDE menus, just like
Banshee and I hope the other players as well (Quodlibet, etc.).
> - gimp is better than the kde equivalent (released versions of krita)
> - 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]
;t have happened with AM_MAINTAINER_MODE in place (or would
upstream have made their build run intloolize on aclocal).
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
automake/autoconf/aclocal might be triggerred while e.g. some m4
macros aren't installed on the buildd or the developer's 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]
nter to whatever directory has the real
> documentation.
That's still quite big. :-/
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ace 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]
UILD_OPTIONS)),0,2)
in my packages; perhaps slightly harder to read the first time, but
soon becomes a well known line which eats less space.
--
Loïc Minier
Most are Python or packages with
multiple builds (like an udeb build with different flags).
This doesn't speak for the archive at large, but still.
Oh and the Wiki page on the new Python Policy also suggets this trick:
<http://wiki.debian.org/DebianPython/NewPolicy>
(and I didn't touch it! :)
--
Loïc Minier
ose anything; I don't think I would gain anything either;
the point was that it isn't a good idea to call make as a method to
check whether I implemented the build-arch concept. In fact, I already
went on and changed my packages to use build-stamp/% or similar instead
(build-%/build-stamp, build-stamp-%, build-%/configure-stamp etc.,
depending on the package.) and hence avoid this bug.
Bye,
--
Loïc Minier
r each of its flavors ("deb" and
"udeb").
--
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
strike "new" in my sentence; 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]
ments, so
> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
e impression that you're still open-minded on the
topic, and since you're one of our beloved policy maintainers, and make
maintainer, I don't think it's worth our time to repeat the arguments
which have already been made.
I simply want it recorded that some people do think it&#
e actually not is completely destroying the only benefit of the
requirement...
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t seems to be
> a) because we can
> b) aesthetics
> c) 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 fl
Why not infer this requirement when
the build and host arches differ?
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
y "build-arch" is a build
option which everybody has, not just buildds, and that you're not
required to use when building packages, even on buildds.
I don't think it makes to have differents fields for buildds and rest
of the world.
There's a pile of build options which could be interesting for us to
list in a Build-Options field, and what I would like is simply to have
this standard way of detecting what a package supports.
--
Loïc Minier
ng some
metrics of "number of packages supporting option foo" to propose
release goals or to update the standard requirements in policy.
--
Loïc Minier
ne functionality and not the others,
or we could aim at having one binary package per utility because one
doesn't need "nautilus-connect-server" or
"nautilus-file-management-properties".
--
Loïc Minier
ONAME change in a source); if you build two
SONAME from two sources, or two SONAME from the same source, you can
still ship the -dbg of each 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
same source are on user systems and we
can have very lax dependencies in the -dbg packages and on the -dbg
packages.
Thanks,
--
Loïc Minier
eter names; I could imagine we could at some
point support "+=":
DEB_BUILD_OPTIONS="CFLAGS=-Os parallel=2 debug CFLAGS+=-g"
(The += words could be parsed in Make using eval for example.)
--
Loïc Minier
AGS from 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
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
$(patsubst parallel=%,%,$(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
27;t.
It's a good point to make, perhaps MAKEFLAGS should only 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
t;, please change
the ifneq to use the same macro as in the jobs computation. As another
minor nitpick, I think ":=" would be nicer for NUMJOBS.
ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS := $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
endif
--
Loïc Minier
eparated DEB_BUILD_OPTIONS.)
My preferred policy change would be to state that DEB_BUILD_OPTIONS
must be a space-separated list 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
T policy: (500, 'unstable'), (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
that you don't need to file a bug about totem shlibs, they are fixed
now.
(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]
I would advise to call make -j explicitely in the parts that
> have been well tested.
(Ack, but it's a general problem not limited to make install: the same
could be said about the main build process which might not be safe for
make -j, or the testsuite, or debian/rules itself.)
--
Loïc Minier
uild.log; exit 1)
cat debian/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.
Hi,
Can't we simply allow passing MAKEFLAGS in the env of debian/rules
instead of defining new vars?
Bye,
--
Loïc Minier
alue on a machine like the one you describe.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rge.
At this point, I found no objection to the proposal 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 PROTE
contact me if you need assistance.
>
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
Loïc Minier <[EM
d this will reinstall
links at their factory default 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
e maintaining packages
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]>
"
so, I don't think security versions can easily be distinguished from
a general "branching", so I'd 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
t's correct style to name them like that.
And again, I think this ought to be in the developers reference, or the
library packaging guide, or what ever best practices and
recommendations guide is fit.
But heh, it's only me.
--
Loïc Minier <[EMAIL PROTECTED]>
icy should prevent. The Universal 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]>
quest review 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 awai
d some light on the origins of this
requirement? If this requirement is only to save memory in most cases,
would it be reasonable to permit building with -fPIC by changing this
"must" in a "should"?
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, e
51 matches
Mail list logo
