[gentoo-dev] New eclass proposal: auto-export
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
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)
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)
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
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
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
[gentoo-dev] Last rites: net-im/tapiocad, net-im/tapioca-xmpp, net-im/tapiocaui
# 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
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
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
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
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
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?
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