Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
of functions. This way all eclasses don't have to duplicate the EAPI
detection code. If people find this useful, I will document it properly
with eclass-manpages etc.
Regards,
Petteri
# Copyright 1999-2009 Gentoo Foundation
#
Petteri Räty wrote:
Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
of functions. This way all eclasses don't have to duplicate the EAPI
detection code. If people find this useful, I will document it properly
with eclass-manpages etc.
Regards,
Petteri
No need to
Ciaran McCreesh wrote:
Still trying to stick to one subthread per item here.
On Tue, 21 Apr 2009 04:27:41 +0300
Petteri Räty betelge...@gentoo.org wrote:
* PKG-INFO
query. I have probably missed what's the use case for non installed
packages?
For some packages, when a bug report for a
On Wed, 22 Apr 2009 16:56:08 +0300
Petteri Räty betelge...@gentoo.org wrote:
Ok. So people should then be using has_version in pkg_info if they
want to detect if it's installed or not?
If they absolutely totally need to detect that, then yes.
Generally pkg_info should just try to display as
On Wed, 2009-04-22 at 16:35 +0300, Petteri Räty wrote:
Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
of functions. This way all eclasses don't have to duplicate the EAPI
detection code. If people find this useful, I will document it properly
with eclass-manpages etc.
Arun Raghavan wrote:
On Wed, 2009-04-22 at 16:35 +0300, Petteri Räty wrote:
Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
of functions. This way all eclasses don't have to duplicate the EAPI
detection code. If people find this useful, I will document it properly
with
# Mounir Lamouri volk...@gentoo.org (22 Apr 2009)
# Masked for removal in 60 days. See bug 248008.
# Tapioca is unmaintained and they are officially abandoned subprojects.
# In addition, tapioca-xmpp has been superseeded by telepathy-gabble.
net-im/tapiocad
net-im/tapioca-xmpp
net-im/tapiocaui
On Sun, Apr 12, 2009 at 2:59 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
I've got the EAPI 3 branch for PMS more or less ready:
http://github.com/ciaranm/pms/tree/eapi-3
Here's the list:
* PKG-PRETEND
critical
* SLOT-OPERATOR-DEPS
critical
* USE-DEP-DEFAULTS
critical
*
I am trying to build the Gentoo cluster live CD using the overlay from
here: git://git.overlays.gentoo.org/proj/clustering-livecd.git I have run
into some problems with some of the ebuilds in this overlay. Here is a
patch to fix the beowulf-head ebuild.
-Tom Stellard
diff --git
Here is another patch to fix the livecdtools ebuild from the
clustering-livecd overlay:
git://git.overlays.gentoo.org/proj/clustering-livecd.git
-Tom Stellard
diff --git a/overlay/app-misc/livecd-tools/Manifest
b/overlay/app-misc/livecd-tools/Manifest
index dbbfa1b..5352ce8 100644
---
On 20:59 Sun 12 Apr , Ciaran McCreesh wrote:
Hopefully we can get a final list decided upon and provisionally
approved by the next Council meeting, and then as soon as Portage is
ready to go we can merge everything into PMS proper and get a signed
approval tag as we did for EAPI 2.
On 20:47 Mon 16 Mar , Ryan Hill wrote:
Whether it's enabled for EAPI 3 or not, I'd at least like to see 'test'
added to FEATURES in targets/developer/make.defaults now. That should
(hopefully) raise the visibility somewhat.
I'm all for enabling it in the dev profile by default.
--
Following suggestion, I've written a paragraph about the xpak payload. I
think it helps clear things. I think it can be added to the portage(5)
manpage, but would be happy to hear other suggestions.
BEGIN
Binary packages
A binary package is an image of a pre-built installation. The merging
14 matches
Mail list logo
