Hi,
Christopher Swift christopher.sw...@linux.com:
If possible I'd like to contribute to this herd, I have little ebuild
experience but I am a willing learner with a keen interest in
Mono/dotNET technologies. I am not (yet) a Gentoo developer nor have
I lots of experience with ebuilds
(Sorry that this mail does not contain the proper References:;
I am not a regular reader of this list and therefore cannot reply).
Ryan Hill dirtye...@gentoo.org wrote:
USE flags should not affect CFLAGS unless there is a very good reason
A valid reason should be that upstream would prefer to
On Thursday, July 01, 2010 08:53:19 Vaeth wrote:
The debug USE flag in eix is also about convenience for the user:
If eix segfaults, it prints instructions how to produce a backtrace
in such a way which is most likely useful for upstream to locate
the problem.
Currently, these instructions
On Thu, 1 Jul 2010 14:53:19 +0200 (CEST)
Vaeth va...@mathematik.uni-wuerzburg.de wrote:
(Sorry that this mail does not contain the proper References:;
I am not a regular reader of this list and therefore cannot reply).
Ryan Hill dirtye...@gentoo.org wrote:
USE flags should not affect
On 07/01/2010 11:00 PM, Ryan Hill wrote:
[...]
The way to control compiler flags in Gentoo is CFLAGS.
That is true. However, there's a problem; you can control package
options of individual packages with USE flags, but you can't control
compilation switches of individual packages with
On Thu, Jul 1, 2010 at 1:04 PM, Nikos Chantziaras rea...@arcor.de wrote:
On 07/01/2010 11:00 PM, Ryan Hill wrote:
[...]
The way to control compiler flags in Gentoo is CFLAGS.
That is true. However, there's a problem; you can control package options
of individual packages with USE flags,
Ryan Hill dirtye...@gentoo.org wrote:
Upstream is free to use whatever CFLAGS they see fit, as long as the
user has the option of disabling them. This is simply done by appending
the user's CFLAGS to those of the build system.
Since it is obvious that by _appending_ only the user's CFLAGS to
Nikos Chantziaras rea...@arcor.de wrote:
If you use portage than you can control per-package CFLAGS using
bashrc and /etc/portage/env or similar functionality.
This is correct, but the problem is that an ebuild author or
upstream cannot set a default here: IMHO, it shouldn't be
necessary for
On Thu, Jul 1, 2010 at 3:14 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote:
Nikos Chantziaras rea...@arcor.de wrote:
If you use portage than you can control per-package CFLAGS using
bashrc and /etc/portage/env or similar functionality.
This is correct, but the problem is that an ebuild
On Thu, 1 Jul 2010 23:44:17 +0200 (CEST)
Vaeth va...@mathematik.uni-wuerzburg.de wrote:
Ryan Hill dirtye...@gentoo.org wrote:
Upstream is free to use whatever CFLAGS they see fit, as long as the
user has the option of disabling them. This is simply done by appending
the user's CFLAGS to
On Thu, 01 Jul 2010 23:04:10 +0300
Nikos Chantziaras rea...@arcor.de wrote:
On 07/01/2010 11:00 PM, Ryan Hill wrote:
[...]
The way to control compiler flags in Gentoo is CFLAGS.
That is true. However, there's a problem; you can control package
options of individual packages with USE
Ryan Hill posted on Thu, 01 Jul 2010 19:48:49 -0600 as excerpted:
We've had per-package CFLAGS for quite a long time now. Maybe we need
to advertise this a little more? There would certainly be a market for
some util to manage all the per-package options that we have scattered
around in
On 7/2/10 7:51 AM, Samuli Suominen wrote:
It's a hack, not a solution
Should we make repoman issue a warning about it?
It already warns about using make -j1 as a workaround for upstream
issues. The new warning could be on the same level (yellow, not red).
Paweł
signature.asc
Description:
On 07/02/2010 08:51 AM, Samuli Suominen wrote:
I've recently stumbled upon several packages unnecessarily using old
preserve_old_lib feature from eutils.eclass, namely:
libgnomekbd
libproxy
And then users hit issues like this:
https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
Please
14 matches
Mail list logo
