Re: [gentoo-dev] emerge feature suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2007-08-11 18:25:32 Rumi Szabolcs napisał(a): > 1.) I apparently cannot exclude one or two packages from a large > emerge action. For example if I say 'emerge -upv world' or > 'emerge -Dupv xorg-x11' it may pull in some large updates I do > not want to do, like gcc or glibc but there is no such thing as > an exclusion list like 'emerge -Dupv xorg-x11 --except gcc glibc' > to stop it from emerging these but let it do everything else. Temporary package.provided. > 3.) There is no way to print a bare list of package atoms > without colors emerge -pv --color=n > newlines and anything about what an 'emerge -upv' > action would be merging which could then be cut&pasted, edited, > or whatever. I mean a list like what revdep-rebuild is printing > out before actually emerging packages. You can get output without versions with: emerge -pv | eix -"|" --only-names You need app-portage/eix. > What do you think? Maybe file enhancement bug report in Bugzilla for your third suggestion. - -- Arfrever Frehtes Taifersar Arahesis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGvekF/axNJ4Xo/ZERAuarAJ4uNZxE1+xd19umYJ2oyEr1HUvyMQCgllb4 P80tsRzukwoE8sduEZkmC+s= =rJsL -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] emerge feature suggestions
Hello! I've got a couple of suggestions for emerge: 1.) I apparently cannot exclude one or two packages from a large emerge action. For example if I say 'emerge -upv world' or 'emerge -Dupv xorg-x11' it may pull in some large updates I do not want to do, like gcc or glibc but there is no such thing as an exclusion list like 'emerge -Dupv xorg-x11 --except gcc glibc' to stop it from emerging these but let it do everything else. 2.) If I use the --ask option it also only asks for the whole large action once but I cannot make it ask about every single package in a large update action. Even handier could be an edit list in the style of etc-update, like one could select some packages from a list by their number, say yes or no for them, and then say '-3' for the rest and go get a coffee until it finishes. 3.) There is no way to print a bare list of package atoms without colors, newlines and anything about what an 'emerge -upv' action would be merging which could then be cut&pasted, edited, or whatever. I mean a list like what revdep-rebuild is printing out before actually emerging packages. I suggest a new --listonly flag or maybe reusing the '-q' flag for that which currently does not seem to do anything. What do you think? Thanks, Sab -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: new gnustep eclasses
On 07-08-2007 00:04:13 +0200, Bernard Cafarelli wrote:
...
> some love to GNUstep support in Gentoo, which you can track progress
> from the gnustep overlay:
> http://overlays.gentoo.org/proj/gnustep
...
> Latest version of the base eclass (sent with this mail) can be found at:
> http://overlays.gentoo.org/proj/gnustep/browser/overlay/eclass/gnustep-base.eclass
We have incorporated all suggested changes more or less in our eclasses
now. We plan to inject the eclasses in a week from now if no major
issues are pointed out. So please give the eclass a quick scan if you
can and report any feedback to us. For convenience I also attached the
diffs made between the first post and this post.
Thanks for all remarks made sofar.
--
Fabian Groffen
Gentoo on a different level
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit eutils flag-o-matic
# Inner gnustep eclass, should only be inherited directly by gnustep-base
# packages
#
# maintainer: GNUstep Herd <[EMAIL PROTECTED]>
# IUSE variables across all GNUstep packages
# "debug": enable code for debugging
# "doc": build and install documentation, if available
IUSE="debug doc"
# packages needed to build any base gnustep package
GNUSTEP_CORE_DEPEND="virtual/libc
doc? ( virtual/tetex =dev-tex/latex2html-2002*
>=app-text/texi2html-1.64 )"
# Where to install GNUstep
GNUSTEP_PREFIX="/usr/GNUstep"
# GNUstep environment array
typeset -a GS_ENV
# Ebuild function overrides
gnustep-base_pkg_setup() {
if test_version_info 3.3 ; then
strip-unsupported-flags
elif test_version_info 3.4 ; then
# strict-aliasing is known to break obj-c stuff in gcc-3.4*
filter-flags -fstrict-aliasing
fi
# known to break ObjC (bug 86089)
filter-flags -fomit-frame-pointer
}
gnustep-base_src_compile() {
egnustep_env
if [[ -x ./configure ]] ; then
econf || die "configure failed"
fi
egnustep_make
}
gnustep-base_src_install() {
egnustep_env
egnustep_install
if use doc ; then
egnustep_env
egnustep_doc
fi
# Copies "convenience scripts"
if [[ -f ${FILESDIR}/config-${PN}.sh ]] ; then
dodir ${GNUSTEP_SYSTEM_TOOLS}/Gentoo
exeinto ${GNUSTEP_SYSTEM_TOOLS}/Gentoo
doexe "${FILESDIR}"/config-${PN}.sh
fi
}
gnustep-base_pkg_postinst() {
# Informs user about existence of "convenience script"
if [[ -f ${FILESDIR}/config-${PN}.sh ]] ; then
elog "Make sure to set happy defaults for this package by
executing:"
elog " ${GNUSTEP_SYSTEM_TOOLS}/Gentoo/config-${PN}.sh"
elog "as the user you will run the package as."
fi
}
# Clean/reset an ebuild to the installed GNUstep environment
egnustep_env() {
# Get additional variables
GNUSTEP_SH_EXPORT_ALL_VARIABLES="true"
if [[ -f ${GNUSTEP_PREFIX}/System/Library/Makefiles/GNUstep.sh ]] ; then
# Reset GNUstep variables
source
"${GNUSTEP_PREFIX}"/System/Library/Makefiles/GNUstep-reset.sh
source "${GNUSTEP_PREFIX}"/System/Library/Makefiles/GNUstep.sh
# Needed to run installed GNUstep apps in sandbox
addpredict "/root/GNUstep"
# Set rpath in ldflags when available
case ${CHOST} in
*-linux-gnu|*-solaris*)
append-ldflags \
-Wl,-rpath="${GNUSTEP_SYSTEM_LIBRARIES}" \
-L"${GNUSTEP_SYSTEM_LIBRARIES}"
;;
*)
append-ldflags \
-L"${GNUSTEP_SYSTEM_LIBRARIES}"
;;
esac
# Set up env vars for make operations
GS_ENV=( AUXILIARY_LDFLAGS="${LDFLAGS}" \
DESTDIR="${D}" \
HOME="${T}" \
GNUSTEP_USER_DIR="${T}" \
GNUSTEP_USER_DEFAULTS_DIR="${T}"/Defaults \
GNUSTEP_INSTALLATION_DOMAIN=SYSTEM \
TAR_OPTIONS="${TAR_OPTIONS} --no-same-owner" \
messages=yes \
-j1 )
# -j1 is needed as gnustep-make is not parallel-safe
if ! use debug ; then
GS_ENV=( "[EMAIL PROTECTED]" "debug=no" )
fi
return 0
fi
die "gnustep-make not installed!"
}
# Make utilizing GNUstep Makefiles
egnustep_make() {
if [[ -f ./[mM]akefile || -f ./GNUmakefile ]] ; then
emake ${*} "[EMAIL PROTECTED]" all || die "package make f
Re: [gentoo-dev] Ruby ebuild "howto" question
Richard Brown wrote the following on 10.08.2007 21:44 : > Yes, see: > > http://devmanual.gentoo.org/eclass-writing/index.html#export-functions > Hits the very spot I was aiming for, many thanks. Lionel -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: > > Yes, you have a good point, as it applies to ebuilds. But there are still > potential incompatibilities in the source itself that this cannot solve. > At least for the ebuild side, perhaps we should get some sort of automated > tool that can analyze all possible code paths and spit out a list. > Does anybody outside of aerospace contractors do this? For even a fairly rudimentary piece of software the number of paths to test would be insane. There is a reason that even modern spacecraft have UIs that consist of operators typing obscure codes into keypads which operate single-threaded control systems. It is about the only way to make it possible to test the software thoroughly. Toss in multitasking and and good luck with code-path analysis... Sure, automated test suites are great, but even packages with tons of automated tests still have bugs. At some point you hit the point of diminishing returns and you have to ask yourself just how perfect the software really needs to be... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGvbXNG4/rWKZmVWkRAn77AJwL76AsBqO1ZZDlyKrZMvczPqTbQwCgm7Cs hOEAs4cI4H9Y1abgtuIe4lE= =l/5D -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] LinuxWorld pictures and Dev House
070810 Mike Lundy wrote: > Quite the crew: http://www.flickr.com/photos/novas0x2a/1079324702/. > Also, http://www.flickr.com/photos/novas0x2a/1079315370/ Why are they all so fat ? (Retreats north of the frontier ... ) -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT`-O--O---' University of Toronto -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] LinuxWorld pictures and Dev House
Mike Lundy wrote: > Quite the crew: http://www.flickr.com/photos/novas0x2a/1079324702/. > Also, http://www.flickr.com/photos/novas0x2a/1079315370/ > > (If anyone in the pictures wants to be tagged, let me know, or just > send me a friend request and then do it yourself) > > Solar must be a vampire- he didn't end up in any of my pictures. > > Also, I'd like to extend an invitation to anyone who lives in the > northern california (USA) area. We do this geek party called Super > Happy Dev House every few weeks, and the next one is tomorrow, > Saturday, August 11th. It's free, and there will be food and geeks. If > you want more information, check out [1]. I know it's sort of last > minute, but we're going from 2pm until 1am, and you can show up or > leave at any time. Come by if you get a chance :) > > 1) http://www.superhappydevhouse.org/letter19 Nice pictures, Mike! Much thanks. hey dostrow, man your hair's grown out since SCALE. Who's that you're molesting? and i think this one's vapier (http://www.flickr.com/photos/novas0x2a/1079315370/) -- that how you always look? ;) RUNS AWAY. signature.asc Description: OpenPGP digital signature
