[gentoo-dev] Save dev-util/plan9port !
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 problems (bug #224209) as well as missing version
bumps for about two years now (bug #273890).
Removal on 2011-03-26
I would like to see this package remain in portage and would therefore
like to volunteer as the new maintainer. I've updated the existing
ebuild using a 2011-03-20 snapshot and have included quite a few
updates, including those from Bug #273890.
I've attached a copy of the new ebuild, additional files can be found
here: http://andy753421.ath.cx/linked/p9p/
It builds cleanly for me on x86 and amd64 machines. I've included fixes
for Bug #273890, Bug #224209, the W|X section issues, and a variety of
other problems. I wasn't able to immediately reproduce Bug #335471 or
Bug #340671 so they may either have been fixed upstream or I will need
more precise steps to reproduce. Some of these fixes are slightly hacky
patch files, so I'm planning on working with upstream for a proper
solution.
However, I am not an official gentoo developer so it sounds like I'll
need a Proxy Maintainer to review my work and push updates to portage.
Would anyone be willing to do this?
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/dev-util/plan9port/plan9port-20080130.ebuild,v 1.1
2008/03/11 13:03:53 coldwind Exp $
EAPI=4
inherit eutils
# Originally from http://swtch.com/plan9port/${PN}.tgz
# Remove .hg directory before repacking to reduce size
DESCRIPTION=Plan 9 From User Space
HOMEPAGE=http://swtch.com/plan9port/;
SRC_URI=mirror://gentoo/${P}.tar.lzma
LICENSE=Lucent-1.02
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=
DEPEND=x11-apps/xauth
RDEPEND=${DEPEND}
S=${WORKDIR}/plan9
PLAN9=/opt/plan9
# P9P's man does not handle compression
PORTAGE_DOCOMPRESS=()
src_configure()
{
# Fix paths, done in place of ./INSTALL -c
einfo Fixing hard-coded /usr/local/plan9 paths
find -type f -exec sed -i s!/usr/local/plan9!${PLAN9}!g {} ;
}
src_prepare()
{
epatch ${FILESDIR}/${PN}-{9660srv-errno,no-lex,noexecstack}.patch
}
src_compile() {
# Convert -j5 to NPROC=5 for mk
export NPROC=$(echo $MAKEOPTS | sed -r -n 's/.*(^|
)-j([0-9]*).*/\2/p')
# The INSTALL script builds mk then [re]builds everything using that
einfo Compiling Plan 9 from User Space can take a very long time
einfo depending on the speed of your computer. Please be patient!
./INSTALL -b || die Build failed
}
src_install() {
dodir ${PLAN9}
# do* plays with the executable bit, and we should not modify them
cp -a * ${D}/${PLAN9}
# build the environment variables and install them in env.d
cat ${T}/30plan9 -EOF
PLAN9=${PLAN9}
PATH=${PLAN9}/bin
ROOTPATH=${PLAN9}/bin
MANPATH=${PLAN9}/man
EOF
doenvd ${T}/30plan9
}
pkg_postinst() {
elog Plan 9 from User Space has been successfully installed into
elog ${PLAN9}. Your PLAN9 and PATH environment variables have
elog also been appropriately set, please use env-update and
elog source /etc/profile to bring that into immediate effect.
elog
elog Please note that ${PLAN9}/bin has been appended to the
elog *end* or your PATH to prevent conflicts. To use the Plan9
elog versions of common UNIX tools, use the absolute path:
elog ${PLAN9}/bin or the 9 command (eg: 9 troff)
elog
elog If you are migrating from an earlier version of plan9port
elog you may need to update any custom files that they rely on
elog absolute paths to the plan9port utilities.
elog sed -i 's!/usr/lib/plan9/!/opt/plan9/!' FILE ..
elog
elog Please report any bugs to bugs.gentoo.org, NOT Plan9Port.
}
pgpqjFcmUYfzQ.pgp
Description: PGP signature
[gentoo-dev] euscan proof of concept (like debian's uscan)
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 at: http://xf.iksaif.net/bordel/euscan
Currently, it uses two heuristics to find new versions, both based on
SRC_URI and PV:
- Directory scanning: scan directories to find files with newer version
- Brute Force: generate new possible versions, and try to download files
Note that it also works when only a part of the version is available
in the url.
I think that it would be great to have these informations on
http://packages.gentoo.org/ and/or unofficial
http://gentoo-portage.com/ website.
We could also add the ability to browse packages by maintainer to help
them see if they have any outdated package.
I started this mostly to see if it was possible, and I don't know if
i'll have the time to continue to work on that project, but I think
gentoo really needs an automated way to detect outdated packages.
This could also be a 2011 GSOC project (finishing euscan, and adding a
web based interface to browse the results).
Examples:
$ ./euscan PEAR-Validate-0.8.3
Package: dev-php/PEAR-Validate-0.8.3
Herd: php
Maintainer: none
Location: /usr/portage/dev-php/PEAR-Validate
* Scanning: http://pear.php.net/get/Validate-${PV}.tgz
* Scanning: http://pear.php.net/get
* Generating version from 0.8.3
* Brute forcing: http://pear.php.net/get/Validate-${PV}.tgz
* Trying: http://pear.php.net/get/Validate-0.8.4.tgz ... [ ok ]
* Trying: http://pear.php.net/get/Validate-0.8.5.tgz ... [ !! ]
* Trying: http://pear.php.net/get/Validate-0.9.0.tgz ... [ !! ]
* Trying: http://pear.php.net/get/Validate-0.10.0.tgz ... [ !! ]
* Trying: http://pear.php.net/get/Validate-0.8.6.tgz ... [ !! ]
New Upstream Version: 0.8.4 http://pear.php.net/get/Validate-0.8.4.tgz
$ ./euscan icu4j-4.4.2
Package: dev-java/icu4j-4.4.2
Herd: java
Maintainer: none
Location: /usr/portage/dev-java/icu4j
* Scanning:
http://download.icu-project.org/files/icu4j/${PV}/icu4j-4_4_2-src.jar
* Scanning: http://download.icu-project.org/files/icu4j
New Upstream Version: 4.5.1 http://download.icu-project.org/files/icu4j/4.5.1/
New Upstream Version: 4.5.2 http://download.icu-project.org/files/icu4j/4.5.2/
New Upstream Version: 4.6 http://download.icu-project.org/files/icu4j/4.6/
New Upstream Version: 4.6rc2 http://download.icu-project.org/files/icu4j/4.6rc2/
New Upstream Version: 4.7.1 http://download.icu-project.org/files/icu4j/4.7.1/
New Upstream Version: 4.6.1 http://download.icu-project.org/files/icu4j/4.6.1/
$ ./euscan IceE-1.3.0-r1
Package: dev-cpp/IceE-1.3.0-r1
Herd: no-herd
Maintainer: maintainer-nee...@gentoo.org
Description: The Internet Communications Engine (Ice) is a modern
object-oriented middleware with support for C++, .NET, Java, Python,
Ruby, and PHP
Location: /usr/portage/dev-cpp/IceE
* Scanning:
http://www.zeroc.com/download/IceE/${0}.${1}//IceE-${PV}-linux.tar.gz
* Scanning: http://www.zeroc.com/download/IceE
* Generating version from 1.3.0
* Brute forcing:
http://www.zeroc.com/download/IceE/${0}.${1}//IceE-${PV}-linux.tar.gz
* Trying: http://www.zeroc.com/download/IceE/1.3//IceE-1.3.1-linux.tar.gz
... [ !! ]
* Trying: http://www.zeroc.com/download/IceE/1.3//IceE-1.3.2-linux.tar.gz
... [ !! ]
* Trying: http://www.zeroc.com/download/IceE/1.4//IceE-1.4.0-linux.tar.gz
... [ !! ]
* Trying: http://www.zeroc.com/download/IceE/1.5//IceE-1.5.0-linux.tar.gz
... [ !! ]
Thanks,
--
Corentin Chary
http://xf.iksaif.net
[gentoo-dev] masking mailwrapper
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 requests, don't-touch-my-package notices etc regarding net-mail/mailwrapper, please let me know. -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
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 ; then
AC_MSG_CHECKING(for 64bit compilation support)
dnl Test for Linux 64 bit
if test `uname` = Linux; then
CPPFLAGS=-DAJ_Linux64 $CPPFLAGS
fi
exmaple header:
dnl Test for FreeBSD 64 bit
#if !defined(AJ_LinuxLF) !defined(AJ_SolarisLF)
!defined(AJ_IRIXLF) !defined(AJ_AIXLF) !defined(AJ_HPUXLF)
!defined(AJ_MACOSXLF) !defined(AJ_FreeBSDLF) !defined(WIN32)
typedef int ajint;
typedef long ajlong;
typedef unsigned int ajuint;
typedef short ajshort;
typedef unsigned short ajushort;
typedef unsigned long ajulong;
#endif
#ifdef AJ_LinuxLF
#define HAVE64
typedef int ajint;
typedef long long ajlong;
typedef unsigned int ajuint;
typedef short ajshort;
typedef unsigned short ajushort;
typedef unsigned long long ajulong;
#define ftell(a) ftello(a)
#define fseek(a,b,c) fseeko(a,b,c)
#endif
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] RFC: emboss.eclass corrected version for review
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-x86/eclass/embassy.eclass,v 1.17 2008/11/03
22:17:50 ribosome Exp $
# Creator of the original eclass
# Author Olivier Fisette ofise...@gmail.com
#
# Author of the next generation eclass
# Justin Lecher j...@gentoo.org
# @ECLASS: emboss.eclass
# @MAINTAINER:
# sci-biol...@gentoo.org
# j...@gentoo.org
# @BLURB: Use this to easy install EMBOSS and EMBASSY programs (EMBOSS add-ons).
# @DESCRIPTION:
# The inheriting ebuild must set EAPI=4 and provide EBO_DESCRIPTION before the
inherit line.
# KEYWORDS should be set. Additionally (R|P)DEPENDencies and other standard
# ebuild Variables can be extended (FOO+= bar).
# Default installation of following DOCS=AUTHORS ChangeLog NEWS README
#
# Example:
#
# EAPI=4
#
# EBO_DESCRIPTION=applications from the CBS group
#
# inherit emboss
#
# KEYWORDS=~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~ppc-macos
# @ECLASS-VARIABLE: EBO_DESCRIPTION
# @DESCRIPTION:
# Should be set. Completes the generic description of the embassy module as
follows:
#
# EMBOSS integrated version of ${EBO_DESCRIPTION},
# e.g.
# EMBOSS integrated version of applications from the CBS group
#
# Defaults to the upstream name of the module.
# @ECLASS-VARIABLE: EBO_EAUTORECONF
# @DESCRIPTION:
# Set to 'no', if you don't want eautoreconf to be run after patching.
: ${EBO_EAUTORECONF:=yes}
# @ECLASS-VARIABLE: EBO_EXTRA_ECONF
# @DEFAULT_UNSET
# @DESCRIPTION:
# Extra config options passed to econf, similar to EXTRA_ECONF.
case ${EAPI:-0} in
4) ;;
*) die this eclass doesn't support EAPI 4 ;;
esac
inherit autotools eutils multilib
HOMEPAGE=http://emboss.sourceforge.net/;
LICENSE=LGPL-2 GPL-2
SLOT=0
IUSE=mysql pdf png postgres static-libs X
DEPEND=
dev-libs/expat
dev-libs/libpcre:3
sci-libs/plplot
sys-libs/zlib
mysql? ( dev-db/mysql )
pdf? ( media-libs/libharu )
png? ( media-libs/gd[png] )
postgres? ( dev-db/postgresql-base )
X? ( x11-libs/libXt )
RDEPEND=${DEPEND}
if [[ ${PN} == embassy-* ]]; then
# The EMBASSY package name, retrieved from the inheriting ebuild's name
EN=${PN:8}
# The full name and version of the EMBASSY package (excluding the Gentoo
# revision number)
EF=$(echo ${EN} | tr [:lower:] [:upper:])-${PV}
: ${EBO_DESCRIPTION:=${EN}}
DESCRIPTION=EMBOSS integrated version of ${EBO_DESCRIPTION}
SRC_URI=ftp://emboss.open-bio.org/pub/EMBOSS/${EF}.tar.gz -
embassy-${EN}-${PV}.tar.gz
DEPEND+=
=sci-biology/emboss-6.3.1_p4[mysql=,pdf=,png=,postgres=,static-libs=,X=]
S=${WORKDIR}/${EF}
fi
DOCS=AUTHORS ChangeLog NEWS README
# @FUNCTION: emboss_src_prepare
# @DESCRIPTION:
# Does following things
#
# 1. Patches with ${FILESDIR}/${PF}.patch, of present
# 2. Runs eautoreconf, unless EBO_EAUTORECONF is set to no
#
emboss_src_prepare() {
[[ -f ${FILESDIR}/${PF}.patch ]] epatch ${FILESDIR}/${PF}.patch
[[ ${EBO_EAUTORECONF} == yes ]] eautoreconf
}
# @FUNCTION: emboss_src_configure
# @DESCRIPTION:
# runs econf with following options. Extra options can be passed by setting
EBO_EXTRA_ECONF
#
# $(use_with X x)
# $(use_with png pngdriver)
# $(use_with pdf hpdf)
# $(use_with mysql mysql)
# $(use_with postgres postgresql)
# $(use_enable static-libs static)
# --enable-large
# --without-java
# --enable-systemlibs
# --docdir=${EPREFIX}/usr/share/doc/${PF}/
# ${EBO_EXTRA_ECONF}
emboss_src_configure() {
econf \
$(use_with X x) \
$(use_with png pngdriver) \
$(use_with pdf hpdf) \
$(use_with mysql mysql) \
$(use_with postgres postgresql) \
$(use_enable static-libs static) \
--enable-large \
--without-java \
--enable-systemlibs \
--docdir=${EPREFIX}/usr/share/doc/${PF}/ \
${EBO_EXTRA_ECONF}
}
EXPORT_FUNCTIONS src_prepare src_configure
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] FEATURES=test, sys-devel/gcc ignored test failures
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_test() {
cd ${WORKDIR}/build
emake -j1 -k check || ewarn check failed and that sucks :(
}
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?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] pax-utils.eclass: elog - einfo?
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 one case it'd have to be either in src_compile or src_test because the test binary has to be pax-mark-ed). By the way, what do you think about using the hardened USE flag to control the elog behavior, and forcing it on the hardened profile? In my opinion it's a bit hacky. Would it make more sense to scan all installed files in pkg_postinst for pax-mark-ed files, and then elog something? Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] How a new ARCH is added to Gentoo?
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 process, lets say compared to Debian. Regards, Kfir
Re: [gentoo-dev] FEATURES=test, sys-devel/gcc ignored test failures
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 key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
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: AC_CHECK_FUNCS([ftello fseeko]) FYI: There is an AC_FUNC_FSEEKO macro, that is designed to deal with this specifically, in case more is necessary. thanks, i wasnt aware of that. that probably is much better than the AC_CHECK_FUNCS invocation i posted above. -mike
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
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 test ${enable_64} = yes ; then
AC_MSG_CHECKING(for 64bit compilation support)
dnl Test for Linux 64 bit
if test `uname` = Linux; then
CPPFLAGS=-DAJ_Linux64 $CPPFLAGS
fi
this all needs to be punted
exmaple header:
dnl Test for FreeBSD 64 bit
#if !defined(AJ_LinuxLF) !defined(AJ_SolarisLF)
!defined(AJ_IRIXLF) !defined(AJ_AIXLF) !defined(AJ_HPUXLF)
!defined(AJ_MACOSXLF) !defined(AJ_FreeBSDLF) !defined(WIN32)
typedef int ajint;
typedef long ajlong;
typedef unsigned int ajuint;
typedef short ajshort;
typedef unsigned short ajushort;
typedef unsigned long ajulong;
#endif
#ifdef AJ_LinuxLF
#define HAVE64
typedef int ajint;
typedef long long ajlong;
typedef unsigned int ajuint;
typedef short ajshort;
typedef unsigned short ajushort;
typedef unsigned long long ajulong;
#define ftell(a) ftello(a)
#define fseek(a,b,c) fseeko(a,b,c)
#endif
so it wants to normalize aj* types to a specific size. it'd make more
sense to include stdint.h and then do:
typedef int32_t ajint;
typedef int64_t ajlong;
typedef uint32_t ajuint;
typedef int16_t ajshort;
typedef uint16_t ajushort;
typedef uint64_t ajulong;
this should work for *all* targets
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])
then in the header:
#ifdef HAVE_FTELLO
#define ftell(a) ftello(a)
#endif
#ifdef HAVE_FSEEKO
#define fseek(a,b,c) fseeko(a,b,c)
#endif
and again, this should work for all targets, not just linux
-mike
Re: [gentoo-dev] RFC: emboss.eclass as replacement for embassy.eclass
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_FSEEKO macro, that is designed to deal with this specifically, in case more is necessary. then in the header: #ifdef HAVE_FTELLO #define ftell(a) ftello(a) #endif #ifdef HAVE_FSEEKO #define fseek(a,b,c) fseeko(a,b,c) #endif and again, this should work for all targets, not just linux -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] How a new ARCH is added to Gentoo?
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, or a totally new arch. I would like to know the process, lets say compared to Debian. https://bugs.gentoo.org/318251 -mike
Re: [gentoo-dev] pax-utils.eclass: elog - einfo?
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? At least one ebuild I maintain does that (and at least in one case it'd have to be either in src_compile or src_test because the test binary has to be pax-mark-ed). because the PaX markings live in the ELF itself, calling in src_* is valid. i might even propose that this should be done only in src_* steps and not the pkg_* steps. the less crap needed to execute at pkg_* time the better. By the way, what do you think about using the hardened USE flag to control the elog behavior, and forcing it on the hardened profile? In my opinion it's a bit hacky. not worth the time Would it make more sense to scan all installed files in pkg_postinst for pax-mark-ed files, and then elog something? that'd work for me, and would make the output much more concise -mike
Re: [gentoo-dev] RFC: emboss.eclass corrected version for review
# @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:
...
# KEYWORDS=~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~ppc-macos
not sure this makes sense in the example
# @ECLASS-VARIABLE: EBO_EAUTORECONF
# @DESCRIPTION:
# Set to 'no', if you don't want eautoreconf to be run after patching.
isnt the opposite behavior the desired default ? generally running
autotools is undesirable ...
: ${EBO_EAUTORECONF:=yes}
no need for quotes
inherit autotools eutils multilib
i dont see multilib being used anywhere
DEPEND=
dev-libs/expat
RDEPEND=${DEPEND}
usually DEPEND is a superset of RDEPEND, so might make more sense to
reverse these. not that it really matters.
S=${WORKDIR}/${EF}
no need for quotes
[[ -f ${FILESDIR}/${PF}.patch ]] epatch ${FILESDIR}/${PF}.patch
no need for quotes inside of this [[...]]
# runs econf with following options. Extra options can be passed by setting
EBO_EXTRA_ECONF
i'd add a . to the end here, or just drop the 2nd sentence
altogether. you already documented EBO_EXTRA_ECONF above, and the
example shows it being used.
--docdir=${EPREFIX}/usr/share/doc/${PF}/ \
these arent typically specified with a trailing slash
-mike
Re: [gentoo-dev] RFC: emboss.eclass corrected version for review
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. # 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? # @ECLASS-VARIABLE: EBO_EAUTORECONF # @DESCRIPTION: # Set to 'no', if you don't want eautoreconf to be run after patching. isnt the opposite behavior the desired default ? generally running autotools is undesirable ... We need this, because I added many things to fix the buildsystem to get rid of strange options, defaultings etc. The rest is accepted. Thanks Mike. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: emboss.eclass corrected version for review
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 -mike
[gentoo-dev] Re: FEATURES=test, sys-devel/gcc ignored test failures
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 those on Gentoo side), I wonder whether it makes
sense to run them at all:
It does to me, I use them all the time. ;) The important part is that we
install the test results, which can then be used for regression testing when
rolling patchsets.
toolchain.eclass:
gcc_src_test() {
cd ${WORKDIR}/build
emake -j1 -k check || ewarn check failed and that sucks :(
}
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?
I think that glibc and gcc tests and other testsuites that nearly always
fail shouldn't be run for the average user but should still be easily
accessible in a standard way. I think we need a more finely grained test
setup, where we can say tests are expensive or interesting only to
developers or known to fail, and let people opt-in to these on a
per-package basis. Right now you always have to opt-out using
package.use.mask which works but is unintuitive.
--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
