[gentoo-dev] New eclass proposal: auto-export

2009-04-22 Thread Petteri Räty
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
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#
# Original Author: Petteri Räty betelge...@gentoo.org
# Purpose: Automatically export functions.
#

EAPI_FUNCTIONS=(
[0]=
pkg_setup
src_unpack
src_compile
src_install
pkg_prerm
pkg_postrm
pkg_preinst
pkg_postinst

[1]=
[2]=
src_prepare
src_configure

)

#function has() {
#   true
#}

has ${EAPI:-0} ${!eapi_functio...@]} || DEPEND=UNKNOWN_EAPI

func-exists() {
declare -F ${1}  /dev/null
}

auto-export() {
local result=''
for eapi in ${!eapi_functio...@]}; do
for func in ${EAPI_FUNCTIONS[${eapi}]}; do
func-exists ${ECLASS}_${func}  result=${result} 
${func}
done

[[ ${eapi} == ${EAPI:-0} ]]  break
done

echo exporting ${result}
EXPORT_FUNCTIONS ${result}
}

#function EXPORT_FUNCTIONS() {
#   echo $...@}
#}

#ECLASS=foo
#foo_src_unpack() { :; }

#auto-export


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New eclass proposal: auto-export

2009-04-22 Thread Petteri Räty
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 tell me that the list for EAPI 0 is missing some functions. I
fixed that already.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] PKG-INFO (Was: PMS EAPI 3 more or less ready)

2009-04-22 Thread Petteri Räty
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 failed build is submitted,
 there are a load of standard questions (versions of libraries that
 aren't in the usual info_pkgs list, configuration questions, ...) that
 need to be asked. This is a way of automating it.
 

Ok. So people should then be using has_version in pkg_info if they want
to detect if it's installed or not?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] PKG-INFO (Was: PMS EAPI 3 more or less ready)

2009-04-22 Thread Ciaran McCreesh
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 much useful
information as it can, though. In particular, it shouldn't do things
like if we're installed, don't display this information, since people
might be having trouble with a reinstall.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] New eclass proposal: auto-export

2009-04-22 Thread Arun Raghavan
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.

Looks like a nice way to avoid silly errors while writing eclasses.
Would this make sense as a package manager feature?

-- Arun


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] New eclass proposal: auto-export

2009-04-22 Thread Petteri Räty
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 eclass-manpages etc.
 
 Looks like a nice way to avoid silly errors while writing eclasses.
 Would this make sense as a package manager feature?
 
 -- Arun

In general I would like to see more bash code shared between package
managers. For this case you would still have to keep code around for
current EAPIs. I think this feature has been on the table for new EAPI
features at least at some point.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-04-19 23h59 UTC

2009-04-22 Thread James Cloos



[gentoo-dev] Last rites: net-im/tapiocad, net-im/tapioca-xmpp, net-im/tapiocaui

2009-04-22 Thread Mounir Lamouri
# 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




Re: [gentoo-dev] PMS EAPI 3 more or less ready

2009-04-22 Thread Doug Goldstein
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
 * DEFINED-PHASES
critical
 * PROPERTIES
critical
 * SRC-INSTALL
yes
 * CONTROLLABLE-COMPRESS
critical
 * DODOC
yes
 * DOINS
yes
 * ANY-USE
yes
 * BANNED-COMMANDS
yes
 * DOEXAMPLE
yes
 * DOINCLUDE
yes
 * UNPACK-EXTENSIONS
yes
 * ECONF-OPTIONS
yes
 * PKG-INFO
critical
 * PROFILE-IUSE-INJECTION
query
 * AA
yes
 * KV
yes
 * REPLACE-VERSION-VARS
critical
 * S-WORKDIR-FALLBACK
yes
 * UNPACK-IF-COMPRESSED
yes
 * RDEPEND-DEPEND
critical
 * DIE-ON-FAILURE
yes
 * NONFATAL
yes

Sorry all for the extreme delay. I'm keeping up with the development
however I'm in the process of buying a house and have been flying
around for work related items. My original response was lost since I
was writing it on IMAP and took my laptop on a plane without saving
the e-mail as a draft.

-- 
Doug Goldstein



[gentoo-dev] Gentoo cluster liveCD

2009-04-22 Thread Tom Stellard
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 a/overlay/sys-cluster/beowulf-head/Manifest 
b/overlay/sys-cluster/beowulf-head/Manifest
index c05fb11..b001b5e 100644
--- a/overlay/sys-cluster/beowulf-head/Manifest
+++ b/overlay/sys-cluster/beowulf-head/Manifest
@@ -6,5 +6,5 @@ AUX node-manager 2119 RMD160 
9cb7ffdd91c0bc699abf59b87bf5894157001ad1 SHA1 cd0c6
 AUX setup-pwdless-ssh 819 RMD160 418271742cb1046efebd2ad4ef2d3e99845142ba SHA1 
d06002173fec53bb46f6f5ff6dd30a0ed2e74bfb SHA256 
6a6ac28a8c5c9e32d5544ea0c18afe43fa96456c4a52d5f4849cd5f4527aa766
 AUX torque-add 629 RMD160 79040160b992cfefde964fc6511022e029c1b58a SHA1 
324d4b0cb5071aaf3a6c62d01bb613cdf8ecf901 SHA256 
5d3d4c3ab35923632b81eaf48d64d6cba1060d0a1887fbc85e8adf10b7fc52c9
 AUX torque-del 132 RMD160 bc1e0a9ccc6ce20630003f7372d62bdb705b9187 SHA1 
c735f03fb6715ab601cb84f4fbc92be78ce43575 SHA256 
c455764846f192930625721958532d3cee64aa75d9d83a37b67544e4c7bdee64
-EBUILD beowulf-head-0.1.ebuild 7750 RMD160 
0bdfed136136cf663aa7065b902a1171dfd418f7 SHA1 
f94bc08eb161878809d2b0652cd5fc026106e6e7 SHA256 
bad7a02b99a32d9abe22d6c522739a9e1126187f421f41749538ed4e21942057
+EBUILD beowulf-head-0.1.ebuild 7754 RMD160 
2d9ab8735486a0158d76056fb9543b82bf9df4fa SHA1 
b3b2768f166577ffc741a46bdf4334caa610e2c3 SHA256 
a75c74727964ff2eabfd488025ebb2b68e315e8131d75438870c7c54c1699390
 MISC ChangeLog 101 RMD160 d735719ccc09237e68e4e984eb5451000b06c382 SHA1 
79098d1e8ae451f0430d363da6b717966ade6e78 SHA256 
8dd010e2772026c4a6b86839842931b99c85c44a5e9f380864cc275b55587ac2
diff --git a/overlay/sys-cluster/beowulf-head/beowulf-head-0.1.ebuild 
b/overlay/sys-cluster/beowulf-head/beowulf-head-0.1.ebuild
index fde63dd..9a57f39 100644
--- a/overlay/sys-cluster/beowulf-head/beowulf-head-0.1.ebuild
+++ b/overlay/sys-cluster/beowulf-head/beowulf-head-0.1.ebuild
@@ -19,8 +19,8 @@ RDEPEND=net-nds/ldap-auth
net-fs/nfs-utils
sys-cluster/c3
net-dns/openresolv
-   beep? (app-misc/beep)
-   pbs? (sys-cluster/torque)
+   beep? ( app-misc/beep )
+   pbs? ( sys-cluster/torque )
 
 CONFPATH=/etc/gentoo
 CONFIG_FILE=cluster.conf


[gentoo-dev] Gentoo cluster liveCD

2009-04-22 Thread Tom Stellard
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
--- a/overlay/app-misc/livecd-tools/Manifest
+++ b/overlay/app-misc/livecd-tools/Manifest
@@ -1,3 +1,3 @@
-AUX password_parse.patch 319 RMD160 493e812b53e3b877e76decf5694090384ffb41c4 
SHA1 575ec8735416b03d7f5bf637869f8aecd4fe8d78 SHA256 
220475ddad3486e3802958684d8a634353e17e9e74e08053b506560e529ff0d3
+AUX password_parse.patch 287 RMD160 383efbb8fa443cca37f553d83bd1ab8968163457 
SHA1 2fe7561675008027de8a4d530450e523905bc83a SHA256 
620367aa79906f129e6fb9609bad562dd9b6c2bb6d81fbeb65a2ee2f1fb50a3c
 DIST livecd-tools-1.0.40.tar.bz2 10610 RMD160 
8db6b15d5df1dba92b4fad70b2b6bcc3a6153287 SHA1 
d9bb532ec8cd092288489949252e1310118a4b6e SHA256 
03f0a6d943f6dbaade14ce16c325777498ce9ca9c8b9480147117816a9857541
 EBUILD livecd-tools-1.0.40-r1.ebuild 1453 RMD160 
776a761dd094a155b09c357662beda27edb283ed SHA1 
7719565da2b1fee9ccc2580caa0be2243d22132e SHA256 
150fef5587816fa0e78b511d92147b3d5da64c36d911863341f0579177fd5bbf
diff --git a/overlay/app-misc/livecd-tools/files/password_parse.patch 
b/overlay/app-misc/livecd-tools/files/password_parse.patch
index 116a181..79e12ea 100644
--- a/overlay/app-misc/livecd-tools/files/password_parse.patch
+++ b/overlay/app-misc/livecd-tools/files/password_parse.patch
@@ -1,5 +1,5 @@
 --- autoconfig 2008-05-29 00:17:17.0 -0400
-+++ /var/svnroot/livecd-tools/trunk/autoconfig 2008-07-07 14:41:00.0 
-0400
 autoconfig 2008-07-07 14:41:00.0 -0400
 @@ -182,9 +182,9 @@
dox)
X11=yes


Re: [gentoo-dev] PMS EAPI 3 more or less ready

2009-04-22 Thread Donnie Berkholz
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.
 
 Here's the list:

 * PKG-PRETEND
 * SRC-INSTALL
 * PKG-INFO
 * DIE-ON-FAILURE
 * NONFATAL
 * USE-DEP-DEFAULTS
 * CONTROLLABLE-COMPRESS

critical

 * SLOT-OPERATOR-DEPS
 * DEFINED-PHASES
 * PROPERTIES
 * UNPACK-EXTENSIONS
 * RDEPEND-DEPEND
 * DODOC
 * PROFILE-IUSE-INJECTION

yes

 * ANY-USE
 * BANNED-COMMANDS
 * ECONF-OPTIONS
 * AA
 * KV
 * REPLACE-VERSION-VARS
 * S-WORKDIR-FALLBACK
 * DOINS

whatever

 * DOEXAMPLE
 * DOINCLUDE
 * UNPACK-IF-COMPRESSED

no

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgp1uTqIXd3Wy.pgp
Description: PGP signature


Re: [gentoo-dev] Re: EAPI 3 PMS Draft

2009-04-22 Thread Donnie Berkholz
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.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpr4gIKb3PR3.pgp
Description: PGP signature


Re: [gentoo-portage-dev] Re: does emerge verify arch compatibility when merging a binary package?

2009-04-22 Thread Amit Dor-Shifer
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 
process of such a package skipps building from source on the target 
host. Portage supports the creation and installation of binary packages. 
See emerge(1) for more information.


A binary package is stored as a .tbz file. Format consists of a bzip2 
archive of the installation, with an extra chunk of data appended at the 
end. This extra binary data is called the 'xpak' archive (add: origin of 
name). It is a binary dump of the package's database entry (under 
/var/db/pkg). When a binary package is installed, the xpak payload is 
used to generate the entry in the package database. It is also used by 
emerge in the installation process (e.g. verifying arch compatibility). 
For more information about the  format of the xpak archive, see xpak(5).


Extracting the xpak archive from the .tbz file can be achieved with 
qtbz2. Reading the xpak archive can be done using qxpak. See qtbz2(1) 
and qxpak(1) for more info.

END
Comments, please.
Amit

Zac Medico wrote:

Amit Dor-Shifer wrote:
 I don't think I would have realized this implementation myself. Is this
 xpak piggybacking documented somewhere?Can you refer me?
 BTW:
 amit0 Installation # man xpak
 No manual entry for xpak
 amit0 Installation # man 5 xpak
 No entry for xpak in section 5 of the manual
 amit0 Installation # eix -S xpak
 No matches found.

The xpak.5 man page is included with =portage-2.1.6.11. Here's a copy:

 http://dev.gentoo.org/~zmedico/portage/doc/man/xpak.5.html

Zac