[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
Zac Medico posted on Sun, 09 Sep 2012 18:34:09 -0700 as excerpted: > On 09/09/2012 05:59 PM, Duncan wrote: >> To your knowlege (IOW have you tested) having /etc/make.conf either a >> symlink to /etc/portage/make.conf or a simple one-line "source >> /etc/portage/make.conf"? > > I've tested them both just now, and they work for me. Why wouldn't they? Back then, portage complained. It's been awhile ago and I didn't write it down, but I seem to remember something about double inclusion. However, it's quite possible that was my diagnosis, not portage's complaint. I just returned to /etc/make.conf, because with both that and /etc/portage/make.conf portage had problems, and with /etc/portage/ make.conf only, something else didn't work. But as I said that was way back when I first read about it, probably in the changelog on my first update after it hit a release, so I'd guess it's looonngg fixed by now. Now that you've confirmed it works for you now, I'll play around with things a bit and file bugs if I see 'em. As always, thanks. =:^) (Now back to that kernel 3.6-git bug I just finished bisecting and was about to file upstream... workqueue merge, commit 63d95a91, crashing in schedule/core.c on line 1654, FWIW.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Perl: please don't delete packlists
On 9 September 2012 15:53, Matthias Bethke wrote: > I think Gentoo of all distributions should aim to provide software as > "original" as possible. If there are any reasons that I have ignored so > far why people would want the current behavior, how about I make this > patch conditional on a new use flag? I'd suggest not a USE flag, at least, not at present, it would needlessly require all ebuilds to have that useflag, which would be a significant noise to users. I'd rather a documented( in the eclass ) ENV variable that could toggle this behaviour that was /not/ a use-flag, so only people who cared about that sort of behaviour could adjust it. Then the question is only really as to what a "Sane default" is. Seems the sane default is to install packlists, but have it being disable-able by ENV change for the people who have the tuits to know "I'll never need those, and if I do, I can handle the need to rebuild everything with them". Additionally, it /might/ be nice if we could have a 3rd party ( Gentoo ) tool that reads a dists CONTENTS file and re-creates packlist files when needed, but thats more work than the above at present. =) -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Re: unifying use.mask/package.use.mask, use.force, package.use.force, etc
On Mon, Sep 10, 2012 at 01:28:23AM +, Duncan wrote:
> Brian Harring posted on Sun, 09 Sep 2012 15:10:27 -0700 as excerpted:
>
> > [Current profile config to to mask the USE=introspection
> > globally, but unmask it for app-crypt/gcr]:
> >
> > use.mask:
> > introspection
> >
> > package.use.mask:
> > app-crypt/gcr -introspection
>
> > [Suggest killing package.* content, folding it into use.*]
>
> > use.mask:
> > * introspection
> > app-cryt/gcr -introspection
>
> > Specifically, collapsing:
> > package.use.mask, use.mask -> use.mask
> > package.use.force, use.force -> use.force
> > package.use.stable.mask, use.stable.mask -> use.stable.mask
> > package.use.stable.force, use.stable.force -> use.stable.force
>
> You mention doing this for the profile.
Not 'mention' the proposal *is a profiles modification* in entirety,
nothing else.
Reorganizing the questions into user configuration (aka, the PM
authors choice of what they want to do in /etc/portage/profiles), and
PMS profiles (aka, what can be done in gentoo-x86).
user config first:
> ?? Would user's package.* and general make.conf settings remain the same?
That's the PM's decision. Knowing portage source, I'd expect it'll
wind up enabling that in parallel to the existing for it's user
configuration.
> ?? What about user's existing /etc/portage/profile overrides, if any?
Same response; that's the PMs decision. What Zac does, is what Zac
does.
> ?? And if they change, are you proposing a script that a user can run to
> automate the process, or simply a news item pointing to the appropriate
> gentoo profile upgrade documentation page, or ??
{ cat use.mask | sed -e 's:^:* :'; cat package.use.mask; } > t \
&& mv t use.mask && rm package.use.mask
Actual PMS profiles question:
> ?? Are you proposing the change be only for new profiles, eventually
> deprecating the old ones, thus having the PMs (and devs maintaining
> profiles) support both methods for awhile much as the cascading profiles
> migration was handled?
Profile nodes are EAPI versioned; what I want, is effectively >=EAPI-5
(or 6 if people get cranky about minor mods), is this to be the
default in new EAPI profile nodes.
Meaning if someone uses a EAPI5 profile node in gentoo-x86, they don't
use package.use.mask, they use the syntax I mentioned, and do it
within use.mask.
There will not be maintaining in parallel; there isn't a point.
Basically, this is a ~70 file reduction of profiles; 253 -> 184
roughly. Aside from less general IO (not much, but some), it also
kills of the question for devs as to which comes first; use.mask or
package.use.mask. Ordering of the file would rule in the new scheme.
Frankly if we wanted to, we could push this further; use.force and
use.mask basically operate in a ternary space: -1, 0, +1; meaning
"Forced off", "configurable", and "enforced on"; respecitively such a
syntax would be -use, use, +use.
Thus the following:
use.mask:
blah
-monkeys # Note this is a negation of the parents masking of 'monkeys'
-foon # Negation of the parents masking
package.use.mask:
dev-util/bsdiff foon
use.force:
x
-y # negation of the parents forcing
monkeys # Note we're explicitly forcing monkeys on after reversing
# masking
package.use.force
dev-util/diffball strip
that translates out to basically thus:
use.enforced:
# This globally disables 'blah', globally forces 'monkeys',
# and resets 'foon' back to user controllable.
* -blah +monkeys foon
# Disable blah for dev-util/bsdiff.
dev-util/bsdiff -foon
# Force strip for dev-util/diffball.
dev-util/diffball +strip
The benefit of such an aproach is that
1) I'd argue it's easier on the dev for processing it- just proceed
top down, for the pkg in question considering if each leading
restriction (* or the atom) matches, then applying the resultant
settings.
2) This actually is basically what the PM does now, although it does
so via grabbing the content from multiple files.
In terms of performance gain, couldn't say frankly; pkgcore already
does a variant of this, re-rendering each cat/pkg restriction set so
as to avoid having to do the resolution multiple times (this helps
repoman/pcheck speed for example).
That said I'm not sure if folks would go for the ternary usage there.
Where that scheme to be applied to our profiles, it'd knock the inode
count for these files down to 127. Not the driving reason for it, but
a nice benefit.
~harring
Re: [gentoo-dev] [RFC] new vala.eclass
Revised proposal with suggestions from Nirbheek. VALA_API_VERSION has
been split into max and min to make it easier for packages to depend on
a range of vala slots.
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: vala.eclass
# @MAINTAINER:
# gn...@gentoo.org
# @AUTHOR:
# Alexandre Rostovtsev
# @BLURB: Sets up the environment for using a specific version of vala.
# @DESCRIPTION:
# This eclass sets up commonly used environment variables for using a specific
# version of dev-lang/vala to configure and build a package. It is needed for
# packages whose build systems assume the existence of certain unversioned vala
# executables, pkgconfig files, etc., which Gentoo does not provide.
#
# This eclass provides one phase function: src_prepare.
inherit multilib
case "${EAPI:-0}" in
0) die "EAPI=0 is not supported" ;;
1) ;;
*) EXPORT_FUNCTIONS src_prepare ;;
esac
# @ECLASS-VARIABLE: VALA_MIN_API_VERSION
# @DEFAULT_UNSET
# @DESCRIPTION:
# Minimum vala API version (e.g. 0.16).
VALA_MIN_API_VERSION=${VALA_MIN_API_VERSION:-0.10}
# @ECLASS-VARIABLE: VALA_MAX_API_VERSION
# @DEFAULT_UNSET
# @DESCRIPTION:
# Maximum vala API version (e.g. 0.18).
VALA_MAX_API_VERSION=${VALA_MAX_API_VERSION:-0.18}
# @ECLASS-VARIABLE: VALA_USE_DEPEND
# @DEFAULT_UNSET
# @DESCRIPTION:
# USE dependencies that vala must be built with (e.g. vapigen).
# @FUNCTION: vala_api_versions
# @DESCRIPTION:
# Outputs a list of vala API versions from VALA_MAX_API_VERSION down to
# VALA_MIN_API_VERSION.
vala_api_versions() {
eval "echo
0.{${VALA_MAX_API_VERSION#0.}..${VALA_MIN_API_VERSION#0.}..2}"
}
# @FUNCTION: vala_depend
# @DESCRIPTION:
# Outputs a ||-dependency string on vala from VALA_MAX_API_VERSION down to
# VALA_MIN_API_VERSION
vala_depend() {
local u v versions=$(vala_api_versions)
[[ ${VALA_USE_DEPEND} ]] && u="[${VALA_USE_DEPEND}]"
echo -n "|| ("
for v in ${versions}; do
echo -n " dev-lang/vala:${v}${u}"
done
echo " )"
}
# @FUNCTION: vala_best_api_version
# @DESCRIPTION:
# Returns the highest installed vala API version satisfying
# VALA_MAX_API_VERSION, VALA_MIN_API_VERSION, and VALA_USE_DEPEND.
vala_best_api_version() {
local u v
[[ ${VALA_USE_DEPEND} ]] && u="[${VALA_USE_DEPEND}]"
for v in $(vala_api_versions); do
has_version "dev-lang/vala:${v}${u}" && echo "${v}" && return
done
}
# @FUNCTION: vala_src_prepare
# @USAGE: [--vala-api-version api_version]
# @DESCRIPTION:
# Sets up the environment variables and pkgconfig files for the
# specified API version, or, if no version is specified, for the
# highest installed vala API version satisfying
# VALA_MIN_API_VERSION, VALA_MIN_API_VERSION, and VALA_USE_DEPEND.
vala_src_prepare() {
local p d valafoo version
if [[ $1 = "--vala-api-version" ]]; then
version=$2
[[ ${version} ]] || die "'--vala-api-version' option requires
API version parameter."
else
version=$(vala_best_api_version)
[[ ${version} ]] || die "No installed vala in $(vala_depend)"
fi
export VALAC=$(type -P valac-${version})
valafoo=$(type -P vala-gen-introspect-${VALA_API_VERSION})
[[ ${valafoo} ]] && export VALA_GEN_INTROSPECT=$(type -P
vala-gen-introspect-${version})
valafoo=$(type -P vapigen-${VALA_API_VERSION})
[[ ${valafoo} ]] && export VAPIGEN="${valafoo}"
valafoo="${EPREFIX}/usr/share/vala/Makefile.vapigen"
[[ -e ${valafoo} ]] && export VAPIGEN_MAKEFILE="${valafoo}"
export VAPIGEN_VAPIDIR="${EPREFIX}/usr/share/vala/vapi"
mkdir -p "${T}/pkgconfig" || die "mkdir failed"
for p in libvala vapigen; do
for d in "${EPREFIX}/usr/$(get_libdir)/pkgconfig"
"${EPREFIX}/usr/share/pkgconfig"; do
if [[ -e ${d}/${p}-${VALA_API_VERSION}.pc ]]; then
ln -s "${d}/${p}-${VALA_API_VERSION}.pc"
"${T}/pkgconfig/${p}.pc" || die "ln failed"
break
fi
done
done
:
${PKG_CONFIG_PATH:="${EPREFIX}/usr/$(get_libdir)/pkgconfig:${EPREFIX}/usr/share/pkgconfig"}
export PKG_CONFIG_PATH="${T}/pkgconfig:${PKG_CONFIG_PATH}"
}
[gentoo-dev] app-emulation/qemu & app-emulation/qemu-kvm folding into one package
Hey all, Just an announcement that app-emulation/qemu-kvm will be pkgmove'd to app-emulation/qemu at some point this week. The app-emulation/qemu ebuilds will effectively die and be replaced by the app-emulation/qemu-kvm ebuilds. I've brought this up before and there was a bunch of rabble about "keep our pristine qemu ebuilds!!!". The fact of the matter is that the app-emulation/qemu just isn't getting the same maintenance care that app-emulation/qemu-kvm is. I've really only got the bandwidth to handle one at a time. Additionally this will bring us inline with a few other distros use of qemu as they're really building their binaries from qemu-kvm. For those that want pure qemu builds, I recommend creating an overlay and replacing the URL. The ebuilds will otherwise aim to be 100% compatible. -- Doug Goldstein
[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
Duncan posted on Mon, 10 Sep 2012 00:59:32 + as excerpted: > To your knowlege (IOW have you tested) having /etc/make.conf I apologize for the terrible "sentence" structure (and spelling "knowledge" or rather practice). Hopefully it's obvious what I intended to ask, tho. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
On 09/09/2012 05:59 PM, Duncan wrote: > To your knowlege (IOW have you tested) having /etc/make.conf either a > symlink to /etc/portage/make.conf or a simple one-line > "source /etc/portage/make.conf"? I've tested them both just now, and they work for me. Why wouldn't they? -- Thanks, Zac
[gentoo-dev] Re: unifying use.mask/package.use.mask, use.force, package.use.force, etc
Brian Harring posted on Sun, 09 Sep 2012 15:10:27 -0700 as excerpted: > [Current profile config to to mask the USE=introspection > globally, but unmask it for app-crypt/gcr]: > > use.mask: > introspection > > package.use.mask: > app-crypt/gcr -introspection > [Suggest killing package.* content, folding it into use.*] > use.mask: > * introspection > app-cryt/gcr -introspection > Specifically, collapsing: > package.use.mask, use.mask -> use.mask > package.use.force, use.force -> use.force > package.use.stable.mask, use.stable.mask -> use.stable.mask > package.use.stable.force, use.stable.force -> use.stable.force You mention doing this for the profile. ?? Would user's package.* and general make.conf settings remain the same? ?? What about user's existing /etc/portage/profile overrides, if any? ?? Are you proposing the change be only for new profiles, eventually deprecating the old ones, thus having the PMs (and devs maintaining profiles) support both methods for awhile much as the cascading profiles migration was handled? By definition, at least user's current /etc/ portage/profile/ settings are in the current format, so if you continue to support that, you'll in effect continue to support the old profile format, and (from the PM viewpoint) migration might as well be via new profiles and current profile deprecation, but that will force profile maintainers to maintain both for whatever period. ?? And if they change, are you proposing a script that a user can run to automate the process, or simply a news item pointing to the appropriate gentoo profile upgrade documentation page, or ?? In general, the idea seems like an eventual efficiency gain and I'm not opposed, but I do wonder if the gain is actually going to be worth it in practice, given the above. Still, I'm not opposed, but I tend to be rather more leading edge and less opposed to change than most users in any case, and I'd guess a significant number of both users and devs that will be trying to support them (and both sets of profiles if the profile deprecation and upgrade migration method is chosen), will have rather stronger ideas about the practical cost/benefit ratio of such a change. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
Zac Medico posted on Sun, 09 Sep 2012 14:57:30 -0700 as excerpted: > On 09/09/2012 02:42 PM, Doug Goldstein wrote: >> On Sun, Sep 9, 2012 at 3:13 PM, Jorge Manuel B. S. Vicetto >> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> This news item was committed. >>> >>> >> So the news item was a bit ambiguous on if I wanted to make the change >> myself to the new locations when I could actually make the change. >> Current portage supports it? Or is their a new version coming which I >> would need? > > It's been supported in stable portage since portage-2.1.9.24 stabilized > in November/December 2010: Zac, To your knowlege (IOW have you tested) having /etc/make.conf either a symlink to /etc/portage/make.conf or a simple one-line "source /etc/portage/make.conf"? Back when I first became aware of the movement toward /etc/portage/make.conf, I'd guess in late 2010 or early 2011 given your dates, I tried both setting only /etc/portage/make.conf, which failed due to some third party utility (which I'd hope has been fixed now but I've not tested it), and making /etc/make.conf a simple symlink/source, which caused portage some indigestion. So I'm wondering if the latter problem's now (tested) fixed, and people can use the new location but still put either a compatibility symlink or source at the old location to keep old scripts and the like working, without portage suffering the indigestion at the prospect that it did at least way back then. If you haven't tested it and want me to, then file a bug if necessary, just say so, but it'd be nice to know whether you believe it to be working now, before I go try it again. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-09-09 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-09-09 23h59 UTC. Removals: kde-base/activitymanager2012-09-03 13:42:34 johu app-arch/TheUnarchiver 2012-09-03 16:11:57 hanno app-text/epdfview 2012-09-05 22:41:37 dilfridge xfce-base/xfce-utils2012-09-09 19:24:24 ssuominen Additions: media-gfx/cptutils 2012-09-03 01:02:21 radhermit media-gfx/opencolorio 2012-09-03 08:32:34 pinkbyte app-arch/unar 2012-09-03 16:07:33 hanno net-libs/libtrace 2012-09-03 22:22:03 radhermit sys-cluster/ganglia-web 2012-09-04 03:34:04 jsbronder media-sound/leechcraft-hotstreams 2012-09-04 17:23:27 pinkbyte net-misc/leechcraft-launchy 2012-09-04 17:55:55 pinkbyte net-misc/linux-eoip 2012-09-04 18:48:43 pinkbyte sys-process/glances 2012-09-05 14:36:58 xarthisius dev-php/PEAR-XML_Feed_Parser2012-09-05 18:43:03 lordvan dev-db/libzdb 2012-09-05 19:08:19 lordvan net-misc/ieee-oui 2012-09-05 20:56:58 axs mail-filter/dovecot_deleted_to_trash2012-09-06 17:35:27 maksbotan media-gfx/qiviewer 2012-09-07 07:05:48 pinkbyte app-admin/openrc-settingsd 2012-09-07 16:20:23 tetromino net-wireless/chirp 2012-09-08 17:16:54 zerochaos net-misc/tlsdate2012-09-09 05:53:37 vapier app-admin/ansible 2012-09-09 08:59:42 pinkbyte app-vim/undotree2012-09-09 11:03:15 radhermit app-vim/ctrlp 2012-09-09 11:21:23 radhermit -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: kde-base/activitymanager,removed,johu,2012-09-03 13:42:34 app-arch/TheUnarchiver,removed,hanno,2012-09-03 16:11:57 app-text/epdfview,removed,dilfridge,2012-09-05 22:41:37 xfce-base/xfce-utils,removed,ssuominen,2012-09-09 19:24:24 Added Packages: media-gfx/cptutils,added,radhermit,2012-09-03 01:02:21 media-gfx/opencolorio,added,pinkbyte,2012-09-03 08:32:34 app-arch/unar,added,hanno,2012-09-03 16:07:33 net-libs/libtrace,added,radhermit,2012-09-03 22:22:03 sys-cluster/ganglia-web,added,jsbronder,2012-09-04 03:34:04 media-sound/leechcraft-hotstreams,added,pinkbyte,2012-09-04 17:23:27 net-misc/leechcraft-launchy,added,pinkbyte,2012-09-04 17:55:55 net-misc/linux-eoip,added,pinkbyte,2012-09-04 18:48:43 sys-process/glances,added,xarthisius,2012-09-05 14:36:58 dev-php/PEAR-XML_Feed_Parser,added,lordvan,2012-09-05 18:43:03 dev-db/libzdb,added,lordvan,2012-09-05 19:08:19 net-misc/ieee-oui,added,axs,2012-09-05 20:56:58 mail-filter/dovecot_deleted_to_trash,added,maksbotan,2012-09-06 17:35:27 media-gfx/qiviewer,added,pinkbyte,2012-09-07 07:05:48 app-admin/openrc-settingsd,added,tetromino,2012-09-07 16:20:23 net-wireless/chirp,added,zerochaos,2012-09-08 17:16:54 net-misc/tlsdate,added,vapier,2012-09-09 05:53:37 app-admin/ansible,added,pinkbyte,2012-09-09 08:59:42 app-vim/undotree,added,radhermit,2012-09-09 11:03:15 app-vim/ctrlp,added,radhermit,2012-09-09 11:21:23 Done.
[gentoo-dev] unifying use.mask/package.use.mask, use.force, package.use.force, etc
Hola folks. Currently, our if you needed to mask the use flag introspection globally, but allow it to be used for say app-crypt/gcr, the profile configuration would be the following: use.mask: introspection package.use.mask: app-crypt/gcr -introspection Frankly, this is a bit of a pain in the ass- it creates a shiteton of intermediate files, and it requires the dev to recall "use.mask before package.use.mask" among other things. I'd suggest instead just killing off the package.* content, and folding them into use.*; the proceeding content would thus be: use.mask: * introspection app-cryt/gcr -introspection Mind you, this isn't a new notion; actually pretty damn old (been in user configuration in one form or another for a long time). For whatever reason, it's yet to be proposed/pushed for in PMS, thus bringing it up now. Any major complaints? Specifically, collapsing: package.use.mask, use.mask -> use.mask package.use.force, use.force -> use.force package.use.stable.mask, use.stable.mask -> use.stable.mask package.use.stable.force, use.stable.force -> use.stable.force ~harring
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
On 09/09/2012 02:42 PM, Doug Goldstein wrote: > On Sun, Sep 9, 2012 at 3:13 PM, Jorge Manuel B. S. Vicetto > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> This news item was committed. >> > > So the news item was a bit ambiguous on if I wanted to make the change > myself to the new locations when I could actually make the change. > Current portage supports it? Or is their a new version coming which I > would need? It's been supported in stable portage since portage-2.1.9.24 stabilized in November/December 2010: https://bugs.gentoo.org/show_bug.cgi?id=346819 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d493a029add855e6ade95d60b57ec7b8f5aba067 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f15c724e6ea494c21e57289b0361614b6656ac35 -- Thanks, Zac
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
On Sun, Sep 9, 2012 at 3:13 PM, Jorge Manuel B. S. Vicetto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This news item was committed. > So the news item was a bit ambiguous on if I wanted to make the change myself to the new locations when I could actually make the change. Current portage supports it? Or is their a new version coming which I would need? -- Doug Goldstein
[gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Fixed to support any slot older than specified correctly.
---
gx86/eclass/boost-utils.eclass | 95 ++
1 file changed, 95 insertions(+)
create mode 100644 gx86/eclass/boost-utils.eclass
diff --git a/gx86/eclass/boost-utils.eclass b/gx86/eclass/boost-utils.eclass
new file mode 100644
index 000..0d6eec3
--- /dev/null
+++ b/gx86/eclass/boost-utils.eclass
@@ -0,0 +1,95 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: $
+
+if [[ ! ${_BOOST_ECLASS} ]]; then
+
+# @ECLASS: boost-utils.eclass
+# @MAINTAINER:
+# Michał Górny
+# Tiziano Müller
+# Sebastian Luther
+# Arfrever Frehtes Taifersar Arahesis
+# @BLURB: helper functions for packages using Boost C++ library
+# @DESCRIPTION:
+# Helper functions to be used when building packages using the Boost C++
+# library collection.
+#
+# Please note that this eclass does not set the dependencies for you.
+# You need to do that yourself.
+#
+# For cmake & autotools it is usually necessary to set BOOST_ROOT using
+# boost-utils_export_root. However, other build system may require more
+# hackery or even appending -I$(boost-utils_get_includedir) to CFLAGS
+# and -L$(boost-utils_get_libdir) to LDFLAGS.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4) ;;
+ *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
+esac
+
+inherit multilib versionator
+
+# @ECLASS-VARIABLE: BOOST_MAX_SLOT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The maximal (newest) boost slot supported by the package. If unset,
+# there is no limit (the newest installed version will be used).
+
+# @FUNCTION: boost-utils_get_best_slot
+# @DESCRIPTION:
+# Get newest installed slot of Boost. If BOOST_MAX_SLOT is set, the version
+# returned will be at most in the specified slot.
+boost-utils_get_best_slot() {
+ local pkg=dev-libs/boost
+ [[ ${BOOST_MAX_SLOT} ]] && pkg="<=${pkg}-${BOOST_MAX_SLOT}."
+
+ local cpv=$(best_version ${pkg})
+ get_version_component_range 1-2 ${cpv#${pkg}-}
+}
+
+# @FUNCTION: boost-utils_get_includedir
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Get the includedir for the given Boost slot. If no slot is given,
+# defaults to the newest installed Boost slot (but not newer than
+# BOOST_MAX_SLOT if that variable is set).
+#
+# Outputs the sole path (without -I).
+boost-utils_get_includedir() {
+ local slot=${1:-$(boost-utils_get_best_slot)}
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+
+ echo -n "${EPREFIX}/usr/include/boost-${slot/./_}"
+}
+
+# @FUNCTION: boost-utils_get_libdir
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Get the libdir for the given Boost slot. If no slot is given, defaults
+# to the newest installed Boost slot (but not newer than BOOST_MAX_SLOT
+# if that variable is set).
+#
+# Outputs the sole path (without -L).
+boost-utils_get_libdir() {
+ local slot=${1:-$(boost-utils_get_best_slot)}
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+
+ echo -n "${EPREFIX}/usr/$(get_libdir)/boost-${slot/./_}"
+}
+
+# @FUNCTION: boost-utils_export_root
+# @USAGE: [slot]
+# @DESCRIPTION:
+# Set the BOOST_ROOT variable to includedir for the given Boost slot.
+# If no slot is given, defaults to the newest installed Boost slot(but
+# not newer than BOOST_MAX_SLOT if that variable is set).
+#
+# This variable satisfies both cmake and sys-devel/boost-m4 autoconf
+# macros.
+boost-utils_export_root() {
+ export BOOST_ROOT=$(boost-utils_get_includedir "${@}")
+}
+
+_BOOST_ECLASS=1
+fi # _BOOST_ECLASS
--
1.7.12
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This news item was committed. On 06-09-2012 03:52, Jorge Manuel B. S. Vicetto wrote: > Hi. > > Following the July 24th thread about changing the default location > of make.conf and make.profile in the new stages, I propose to > commit 2 news items in 2 or 3 days. The first one (this one) is > directed to all users and informs about the change and what to do. > The second one (next email) will be directed to catalyst users. > This news item should be presented to as many users as possible. > Following Fabian's request in the previous thread, I'm trying to > restrict it to default/linux profiles only. I don't know if it's > possible to filter with default/linux/*, if there are other > alternatives or if we will have to list *all* relevant profiles > (the latter case is not appealing). > > Does anyone have any comments about this news item? > > > > Title: make.conf and make.profile move to /etc/portage Author: > Jorge Manuel B. S. Vicetto Content-Type: > text/plain Posted: 2012-09-08 Revision: 1 News-Item-Format: 1.0 > Display-If-Installed: sys-apps/portage Display-If-Profile: > default/linux/* > > Starting next week, new stages will have make.conf and > make.profile moved from /etc to /etc/portage. This is a change in > the installation defaults, that will only affect new installs so it > doesn't affect current systems. > > Current users don't need to do anything. But if you want to follow > the gfepreferred location, you may want to take the chance to move > the files in your system(s) to the new location. > > > - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQTPhrAAoJEC8ZTXQF1qEP+0wQAKuVRvE1ZnaDLIKYasxexsGL RI2NhvBayW+N8Al1cwtpKO1sMKu2bbC1mflyB5uTFekExUZ+nQ6+ILywJzyh7VQ4 B+NglgInSkssJ5quEqE8C6sgoMTEw7OhLcTcc2BOP5TOP73PxhtqbeorBSae9gN+ ubsqpRcTpV7EHKJAd1lyEOEHuSYu4gjed1FNTWINPLkvhTSOpgZmRXhtYV0nrSbb reDA0V5FIBG+2Q0LmVGqyHnXLGbM/Eq8ZKrYS+mts/gNOe4tb9VJsx0byRBN4RXS +q3PGvV+liMnw/tlrvAny118zgxluzjsVW5MRVODmmm4DQVR073b2CGUkwSu01Lb G3ImRrjsD0O6nX2/Lzs50VFN5OSh6k2l9yd3UIKmLzDkqclAPvqckafnRlpDgSZV qcZbbvGEFbS3I1wMaBbdcTT8K1S94f+KW+E1d+ROKU/vhUvUJ3ZCY0MypKqtHnrC 5xLszZ6Xwf4t0UmaS4HlDtklhzYQTvPp3k4pKMLjW6Q9wcG4aCSE8/PCrXjPc0oW qsaMS/rIen6GzIy/os2whZwyytpRWPlAbvbPo9mSUeqq9n2JyowQF35fp6Xy5Clp A+9cVxWnDTOjv7BLMGxZx2HX1xdcyFCnfEKYD23XfJG5LhHQ1YaQfRPoL+DdCScO 0ctTiZYTz8pokhoIrBu0 =I8II -END PGP SIGNATURE-
Re: [gentoo-dev] News item 2: updates to catalyst
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This news item was committed. On 06-09-2012 03:55, Jorge Manuel B. S. Vicetto wrote: > Hi. > > Following the July 24th thread about changing the default location > of make.conf and make.profile in the new stages, I propose to > commit 2 news items in 2 or 3 days. The first one (previous email) > was directed to all users and informs about the change and what to > do. The second one (this one) is directed to catalyst users. This > news item should be presented to all users running a version of > catalyst prior to 2.0.11. > > Does anyone have any comments about this news item? > > > > Title: Catalyst updates Author: Jorge Manuel B. S. Vicetto > Content-Type: text/plain Posted: > 2012-09-08 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: > > Starting with catalyst 2.0.10.1, make.conf and make.profile will > be moved from /etc to /etc/portage. This is a change in the > installation defaults and may impact anyone using custom / > automated methods to do Gentoo installations. If you use catalyst, > be sure to check if you need to update your installation > method(s). The 2.0.11 version finally provides support for using xz > snapshots. Catalyst nows prefers xz over bz2 snapshots. > > > - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQTPhUAAoJEC8ZTXQF1qEP21cP/2XO+2p461BwaVMMLmbYez84 KFfUvQqEyvNUy/rc+qjdrZUom8JI32GfDrOr+/AVNEOAa53Xspa8oIDhtfM7hiP1 Z/xX8aS7wnfNjeoS7CjQLvFEUgqF6GfVkDn87JHAiwGHPJ59pyGKnARRxW9p0KYh 8cWP7iZ0HAQYd1MvUzPOVp78Cxk+emVTSW8Wzj1s+MEuYhGK361lC2fkCBj9oMEy C09gp8zgxY236+UBUHo/JgiMFkBenLLM2OAAJgaKzTJjjRLTidDijHnOz4P9Quqv iL0nt6ZobCCTmsErnNEo4xp3s19middh4DsODclXtnAOUJuXv4FlblM8HJkIeEkc ufzSVKNkDHBAoxJi0rM6km2dCxwa0S0a2vb8gwTCmwlx2EZfg1Qmn96leBJ+Zt+V 1QJ5zuW/MxQSZyyOUdNSfN1rpOOhTWntS5qyGGbWkIB6RghtsEPjV673M8Ec6sz+ tLwCmCVoFnoKeF5t/284CFH4LiU9wU8GM/RBlpoko/wkxeYk+qohb9hVtyx/aAgI Q/zcAQQM8fqbKS59hSa0k4qjdcm8RncGFpJaM1GgSw+tNV4wXU7r1JxSMmNipI6i LblSfMjKph0T8VsqQPeNba6gASRy1rjR0ks5tG6puUyxpKANJYjv3/IJkNX07TR4 sh4y8bwjxGY8be22+1eu =EZvU -END PGP SIGNATURE-
Re: [gentoo-dev] News item 1: changes to stages (make.conf and make.profile)
On 9/8/2012 2:05 PM, Jorge Manuel B. S. Vicetto wrote: > Here is the second draft for this news item. > ... > Starting next week, new stages will have make.conf and make.profile > moved from /etc to /etc/portage. This is a change in the installation > defaults, that will only affect new installs so it doesn't affect > current systems. I'd be specific on the date as I could read that news item after this actually happens but be under the impression that it hasn't happened yet. - Aaron
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Sun, 9 Sep 2012 19:47:07 +0200 Arfrever Frehtes Taifersar Arahesis wrote: > 2012-09-09 10:06:43 Michał Górny napisał(a): > > No, we don't support older versions. > > Older versions must be supported to easily handle the situation when Boost > 1.49 is stable and > Boost 1.50 and 1.51 are unstable and not package.masked and package X has > only stable ebuilds > and all of them currently fail to build/work with Boost >=1.51, so > BOOST_MAX_VERSION="1.50" would > have to be used in all ebuilds of package X. > (Boost 1.49 would be used for stable users and Boost 1.50 would be used for > unstable users.) You are probably right. Even though I believe that we should treat 'older slot' support only as an interim solution before people fix their packages... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
2012-09-09 10:06:43 Michał Górny napisał(a): > No, we don't support older versions. Older versions must be supported to easily handle the situation when Boost 1.49 is stable and Boost 1.50 and 1.51 are unstable and not package.masked and package X has only stable ebuilds and all of them currently fail to build/work with Boost >=1.51, so BOOST_MAX_VERSION="1.50" would have to be used in all ebuilds of package X. (Boost 1.49 would be used for stable users and Boost 1.50 would be used for unstable users.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
On Sun, 9 Sep 2012 07:26:23 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> 2012-09-04 22:50:16 Michał Górny napisał(a):
> > + local
> > slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}
>
> When BOOST_MAX_VERSION is non-empty, then it should be used in the
> following way:
>
> [[ "${BOOST_MAX_VERSION}" =~ ^[[:digit:]]+\.[[:digit:]]+$ ]] || die
> "Invalid BOOST_MAX_VERSION" atom="$(best_version
> " slot="$(get_version_component_range 1-2 ${atom#dev-libs/boost-})"
No, we don't support older versions. The eclassdoc says it all.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
