I recently noticed that the plan9port package is scheduled for removal.
From package.mask:
Diego E. Pettenò flamee...@gentoo.org (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
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
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
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 ;
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:
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:
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
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
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
PGP
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:
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]))
if
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
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 arch,
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 misuse then?
# @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:
...
#
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.
#
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 completely?
punt it
On Mon, 21 Mar 2011 13:07:33 +0100
Paweł Hajdan, Jr. phajdan...@gentoo.org 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
18 matches
Mail list logo
