On Mon, 21 Mar 2011 13:07:33 +0100
"Paweł Hajdan, Jr." wrote:
> sys-devel/gcc runs tests, but the results are ignored and I remember the
> tests fail most of the time.
s/most/all
> Because the tests take long time to run and fail anyway (I understand
> it's non-trivial to fix those on Gentoo s
On Mon, Mar 21, 2011 at 12:01 PM, justin wrote:
> On 21/03/11 15:34, Mike Frysinger wrote:
>>> # Example:
>>> ...
>>> # KEYWORDS="~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~ppc-macos"
>>
>> not sure this makes sense in the example
>
> Just an example, do you suggest a subset or leave it out complete
On 21/03/11 15:34, Mike Frysinger wrote:
>> # @BLURB: Use this to easy install EMBOSS and EMBASSY programs (EMBOSS
>> add-ons).
>
> do those need to be capitalized ? if upstream refers to them as
> EMBOSS and EMBASSY, then i guess it makes sense ...
>
Yipp, upstream is CAPITAL with everything.
> # @BLURB: Use this to easy install EMBOSS and EMBASSY programs (EMBOSS
> add-ons).
do those need to be capitalized ? if upstream refers to them as
EMBOSS and EMBASSY, then i guess it makes sense ...
> # ebuild Variables can be extended (FOO+=" bar").
variables
> # Example:
> ...
> # KEYWORD
On Mon, Mar 21, 2011 at 8:26 AM, "Paweł Hajdan, Jr." wrote:
> On 3/17/11 11:18 PM, Mike Frysinger wrote:
>> also, this code is run at the pkg_* stage, so it's not the normal src host
>> feature detection. and we're talking about minor output behavior.
>
> Is calling pax-mark in src_compile a misus
On Mon, Mar 21, 2011 at 8:28 AM, Kfir Lavi wrote:
> Is there any article that elaborate my question?
> My aim is to explain, why Gentoo is much more agile then
> any other binary distribution when hopping between arches.
> Lets say we started development on x86, then we want to
> move to another ar
On 21-03-2011 09:04:24 -0400, Mike Frysinger wrote:
> ftell vs ftello is a bit weirder. i'd say always call ftello() all
> the time and let the off_t types worry about 32 bit vs 64 bit. so in
> the configure script. do something like:
> AC_CHECK_FUNCS([ftello fseeko])
FYI:
There is an AC_FUNC_FS
On Mon, Mar 21, 2011 at 6:37 AM, justin wrote:
> During closer investigation I found that it alos changes data width and
> similar. probably something which should be checked during configure.
oh god, this is why it burns
> AC_ARG_ENABLE(64,
> AS_HELP_STRING([--enable-64], [64 bit pointers]))
>
On Mon, Mar 21, 2011 at 9:14 AM, Fabian Groffen wrote:
> On 21-03-2011 09:04:24 -0400, Mike Frysinger wrote:
>> ftell vs ftello is a bit weirder. i'd say always call ftello() all
>> the time and let the off_t types worry about 32 bit vs 64 bit. so in
>> the configure script. do something like:
>>
Excerpts from Paweł Hajdan, Jr.'s message of Mon Mar 21 13:07:33 +0100 2011:
> My suggestion is to make the src_test empty (I think the default one
> still calls make). I can produce a patch if needed.
>
> What do you think?
Maybe restrict? https://bugs.gentoo.org/298014
--
Amadeusz Żołnowski
P
Hi,
Is there any article that elaborate my question?
My aim is to explain, why Gentoo is much more agile then
any other binary distribution when hopping between arches.
Lets say we started development on x86, then we want to
move to another arch, or a totally new arch. I would like
to know the proc
On 3/17/11 11:18 PM, Mike Frysinger wrote:
> also, this code is run at the pkg_* stage, so it's not the normal src host
> feature detection. and we're talking about minor output behavior.
Is calling pax-mark in src_compile a misuse then? At least one ebuild I
maintain does that (and at least in
sys-devel/gcc runs tests, but the results are ignored and I remember the
tests fail most of the time.
Because the tests take long time to run and fail anyway (I understand
it's non-trivial to fix those on Gentoo side), I wonder whether it makes
sense to run them at all:
toolchain.eclass:
gcc_src
Hi,
I corrected and implemented what you suggested. Anything left over to
correct?
Thanks
justin
P.s. the enable-64 thing will be fixed in the emboss ebuild
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo
During closer investigation I found that it alos changes data width and
similar. probably something which should be checked during configure.
I attached some code as example:
from configure:
AC_ARG_ENABLE(64,
AS_HELP_STRING([--enable-64], [64 bit pointers]))
if test "${enable_64}" = "yes" ;
Only virtual/mta remains as an old style virtual in the net-mail herd.
I will be changing it to a new style virtual in a few days.
While at it, I would like to get rid of mailwrapper USE flag and finally
mask net-mail/mailwrapper for removal - bug #158003.
If there are any objections, hold reques
Hi,
I recently started working on a small gentoo utility named "euscan"
(for Ebuild Upstream Scan)
For those who don't know debian's uscan, it allows to scan upstream
for new versions. It's used by packages.qa.debian.org (example:
http://packages.qa.debian.org/p/php-net-ipv4.html ).
It's available
I recently noticed that the plan9port package is scheduled for removal.
From package.mask:
> Diego E. Pettenò (25 Jan 2011)
> on behalf of QA team
>
> Missing a dedicated maintainer; problems regarding LDFLAGS
> (bug #335471), overflows (bug #340671), W|X sections,
> and misc problems (bug #224
18 matches
Mail list logo
