Re: [gentoo-dev] mesa r600 gallium news item

[Donnie Berkholz]

On 17:51 Wed 31 Aug , Chí-Thanh Christopher Nguyễn wrote:
> Donnie Berkholz schrieb:
> > On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote:
> >> Existing users will not be switched automatically.
> > 
> > Why not? If it's considered the supported route going forward, we should 
> > just do it automatically.
> 
> Some users might be using UMS instead of KMS still, which would break 3D
> acceleration once they are switched to gallium.

So migrate them. =)

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgpyZdTbs8Ifi.pgp
Description: PGP signature

Re: [gentoo-dev] [WTH] bash-completion useflag

[Mike Frysinger]

On Wednesday, August 31, 2011 18:16:29 Ulrich Mueller wrote:
> > On Wed, 31 Aug 2011, Mike Frysinger wrote:
> > installing the files unconditionally does fall into the
> > logrotate/xinetd category, so it should get punted. but people
> > should not end up with the depends installed all the time.
> 
> And users who want bash completion can just install
> app-shells/bash-completion, so maybe PDEPEND could be removed too?

i think that'd be the equivalent to the current "users add bash-completion to 
their USE in make.conf", so i'd say yes

that'd also solve Michał's logging complaint by putting generic instructions 
into the bash-completion ebuild postinst ?
-mike


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

Re: [gentoo-dev] About upstreams appending additional CFLAGS when building with some configure options

[Aaron W. Swenson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/31/2011 03:24 PM, Pacho Ramos wrote:
> I won't be able to reply to this thread for now, but would like to
> ask about how to handle cases like: 
> https://bugs.gentoo.org/show_bug.cgi?id=381355
> 
> Until now, I usually opted to trust upstreams and don't touch FLAGS
> they set (except cases like Werror and so.), but I am not sure if
> maybe I should drop that CFLAGS :-/
> 
> What do you think? Please also take care I doubt upstream wouldn't
> ever accept that change and, then, we should carry it forever.
> 
> Thanks a lot for your help

If there are C{,XX}FLAGS that are absolutely known to cause the build
to fail, strip them from the C{,XX}FLAGS using the strip-flags.

You shouldn't let upstream jerk you or our users around, though. If I
want to build my packages with -march=native -mtune=native -pipe -O3
- -fzomg -freakin-fast -man -fo-sho, then by golly, let me.

We have a 'custom-cflags' USE flag. The definition of which has been
to allow the CFLAGS the user wants, but if it breaks, that's his or
her problem but not ours -- the Gentoo developers -- nor upstream's.

- - Aaron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk5etc4ACgkQCOhwUhu5AEl3RwD+PJA9RNQGlmMLDvAg2abBflXM
9mks/pxA+bGTkIRZ5iAA/iRTrxTbqGu83LPbCT/QwwMrlecffsE/XdRJ5Y3uhoDR
=R6xV
-END PGP SIGNATURE-

Re: [gentoo-dev] [WTH] bash-completion useflag

[Ulrich Mueller]

> On Wed, 31 Aug 2011, Mike Frysinger wrote:

> installing the files unconditionally does fall into the
> logrotate/xinetd category, so it should get punted. but people
> should not end up with the depends installed all the time.

The eclass currently has RDEPEND=app-admin/eselect and
PDEPEND=app-shells/bash-completion. I believe that the former is
not necessary, because eselect will already be pulled in by the
bash-completion package.

And users who want bash completion can just install
app-shells/bash-completion, so maybe PDEPEND could be removed too? 

Ulrich

Re: [gentoo-dev] About upstreams appending additional CFLAGS when building with some configure options

[Michał Górny]

On Wed, 31 Aug 2011 21:24:25 +0200
Pacho Ramos  wrote:

> I won't be able to reply to this thread for now, but would like to ask
> about how to handle cases like:
> https://bugs.gentoo.org/show_bug.cgi?id=381355

Either you pointed out the wrong bug or have to explain what exactly
you are referring to.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [WTH] bash-completion useflag

[Michał Górny]

On Wed, 31 Aug 2011 22:14:08 +0200
Tomáš Chvátal  wrote:

> Hi,
> what is the purpose of this fancy useflag, it controlls install of at
> best one or more small sh scripts.
> As we do not bother with the logrotate useflag this thing should fall
> into the same category.
> 
> It is mostly added by the eclass for the feature. Which I for example
> didn't notice and forced
> newuse update for all poor souls using libreoffice...

Ok, from a quick tree grep: there are lots of packages which will
probably need to be changed.

Before we will start fixing them, we need to decide how we should
exactly do it. If we're going not to use bash-completion flag by
default, we should probably remove pkg_postinst() from there as well.

Honestly, I don't see a reason for each package to list how to enable
bash-completion. If we do that, we will finally end up outputting
complete instructions on every installed file.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [WTH] bash-completion useflag

[Mike Frysinger]

On Wednesday, August 31, 2011 16:22:28 Michał Górny wrote:
> On Wed, 31 Aug 2011 22:14:08 +0200 Tomáš Chvátal wrote:
> > what is the purpose of this fancy useflag, it controlls install of at
> > best one or more small sh scripts.
> > As we do not bother with the logrotate useflag this thing should fall
> > into the same category.
> > 
> > It is mostly added by the eclass for the feature. Which I for example
> > didn't notice and forced
> > newuse update for all poor souls using libreoffice...
> 
> I already suggested removing it at least twice.
> 
> One issue is that a few packages use it for PDEPs. But I guess making
> the eclass non-conditional by default would be a good start.

installing the files unconditionally does fall into the logrotate/xinetd 
category, so it should get punted.  but people should not end up with the 
depends installed all the time.
-mike


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

Re: [gentoo-dev] glibc-2.14 and changes in rpc support (libtirpc)

[Mike Frysinger]

On Saturday, June 11, 2011 16:11:35 Mike Frysinger wrote:
> historically, glibc provided all the ugly rpc support (while not nearly as
> relevant today, it still is used by way of nfs support).  the glibc
> maintainers have opted to stop supporting this.  at first they declined to
> accept new features, but now they've started removing support for new code
> to build against it.
> 
> libtirpc started off to support the new features (namely ipv6 support), but
> has now taken on a new roll of supporting all the rpc code.
> 
> so if you have a build bug due to glibc-2.14 due to missing rpc/ or rpcsvc/
> header, you're going to have to convert over to libtirpc.
> 
> something like:
>   inherit toolchain-funcs
>   ...
>   append-cppflags $($(tc-getPKG_CONFIG) libtirpc --cflags)
>   export LIBS+=" $($(tc-getPKG_CONFIG) libtirpc --libs)"
> 
> obviously the LIBS part will need tweaking based on your package.

after seeing the feedback of broken packages, and libtirpc itself not being 
ready as a full replacement for the rpc symbols, i plan on implementing the 
same kind of hack that fedora is using atm: re-exporting the symbols and 
headers.  this will give us time to migrate packages over to libtirpc without 
being stuck on glibc-2.13 indefinitely.

the ABI will not be adversely affected long or short or any other term.
-mike


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

Re: [gentoo-dev] [WTH] bash-completion useflag

[Michał Górny]

On Wed, 31 Aug 2011 22:14:08 +0200
Tomáš Chvátal  wrote:

> what is the purpose of this fancy useflag, it controlls install of at
> best one or more small sh scripts.
> As we do not bother with the logrotate useflag this thing should fall
> into the same category.
> 
> It is mostly added by the eclass for the feature. Which I for example
> didn't notice and forced
> newuse update for all poor souls using libreoffice...

I already suggested removing it at least twice.

One issue is that a few packages use it for PDEPs. But I guess making
the eclass non-conditional by default would be a good start.


-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] [WTH] bash-completion useflag

[Tomáš Chvátal]

Hi,
what is the purpose of this fancy useflag, it controlls install of at
best one or more small sh scripts.
As we do not bother with the logrotate useflag this thing should fall
into the same category.

It is mostly added by the eclass for the feature. Which I for example
didn't notice and forced
newuse update for all poor souls using libreoffice...

Cheers

Tom



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] About upstreams appending additional CFLAGS when building with some configure options

[Pacho Ramos]

I won't be able to reply to this thread for now, but would like to ask
about how to handle cases like:
https://bugs.gentoo.org/show_bug.cgi?id=381355

Until now, I usually opted to trust upstreams and don't touch FLAGS they
set (except cases like Werror and so.), but I am not sure if maybe I
should drop that CFLAGS :-/

What do you think? Please also take care I doubt upstream wouldn't ever
accept that change and, then, we should carry it forever.

Thanks a lot for your help


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

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Tomáš Chvátal]

Dne 31.8.2011 21:03, Ulrich Mueller napsal(a):
>> On Wed, 31 Aug 2011, Alec Warner wrote:
>> Also it is my understanding that all tokens in $(()) go through
>> expansion, so for instance:
>> $(( 1024 * 1024 * size ))
>> and
>> $(( 1024 * 1024 * ${size})) are equivalent.
>> Is this only in bash4?
> It's like this since bash 2.05 at least.
>
>> Do we have a style preference?
> Personally, I'd prefer the first variant.
>
> Ulrich
>
I thought it is mandatory to use the second variant, otherwise i preffer
the first myself as it is from bash 2 or so :)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Ulrich Mueller]

> On Wed, 31 Aug 2011, Alec Warner wrote:

> Also it is my understanding that all tokens in $(()) go through
> expansion, so for instance:

> $(( 1024 * 1024 * size ))

> and

> $(( 1024 * 1024 * ${size})) are equivalent.

> Is this only in bash4?

It's like this since bash 2.05 at least.

> Do we have a style preference?

Personally, I'd prefer the first variant.

Ulrich

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Alec Warner]

On Wed, Aug 31, 2011 at 3:14 AM, Michał Górny  wrote:
> On Wed, 32 Aug 2011 10:57:08 +0200
> Tomáš Chvátal  wrote:
>
>> Good pointer is that we should probably check if the
>> MERGE_TYPE=binary and not check-reqs ram and disk_build in that case.
>> But there is slight problem how to do it in older eapis.
>
> We simply don't. Life is hard :P.
>
>> Also Michal if you want to have that DISK array thingu there could
>> you write a patch?
>
> Well, I don't see really a need for that if we're still keeping old
> vars.
>
> Now about the code:
>
> * I don't see units mentioned nor described in @DESCRIPTION or vars,
>
>> EXPORT_FUNCTIONS pkg_setup
>> case "${EAPI:-0}" in
>>       0|1|2|3) ;;
>>       4) EXPORT_FUNCTIONS pkg_pretend ;;
>>       *) die "EAPI=${EAPI} is not supported" ;;
>> esac
>
> Either you export them (which breaks backwards compat) or require users
> to call them (your @CODE@). Don't do both, it's confusing.
>
>> check-reqs_get_megs() {
>>       debug-print-function ${FUNCNAME} "$@"
>>
>>       [[ -z ${1} ]] && die "Usage: ${FUNCNAME} [size]"
>>
>>       local unit=${1#${1%?}}
>>       local size
>
> local unit=${1:(-1)}
>
>>
>>       # Temporary workaround for unset units.
>>       # Backcompat.
>>       if [[ "${unit//*([[:digit:]])}" ]]; then
>>               # the unit itself was set ; strip it out
>>               size=${1%\%}
>>       else
>>               size=${1}
>>               unit="M"
>>       fi
>
> local size=${1%[GMT]}
>
>>
>>       case ${unit} in
>>               [gG]) echo $((1024 * ${size})) ;;
>>               [mM]) echo ${size} ;;
>>               [tT]) echo $((1024 * 1024 * ${size})) ;;

Also it is my understanding that all tokens in $(()) go through
expansion, so for instance:

$(( 1024 * 1024 * size ))

and

$(( 1024 * 1024 * ${size})) are equivalent.

Is this only in bash4?
Do we have a style preference?

>
> I'd just go with capital letters there.
>
>                [0-9]) echo ${size} ;;
>
> (you can add that to the 'M' cond)
>
>>               *)
>>                       die "${FUNCNAME}: Unknown unit size: ${unit}"
>
> Size unit. Again.
>
>>               ;;
>>       esac
>> }
>
>>               [gG]) echo "Gigabytes" ;;
>>               [mM]) echo "Megabytes" ;;
>>               [tT]) echo "Terabytes" ;;
>
> gibibytes, mebibytes, tebibytes.
>
>> # @FUNCTION: check-reqs_memory
>> # @DESCRIPTION:
>> # Internal function that checks space on the RAM.
>
> 'space on the RAM' sounds bad :P.
>
>>       check-reqs_start_phase \
>>               $(check-reqs_get_number ${size}) \
>>               $(check-reqs_get_unit ${size}) \
>>               "RAM"
>
> Move the number/unit split to _start_phase()?
>
>>               actual_memory=$(sed -n -e '/MemTotal:/s/^[^:]*:
>> *\([0-9]\+\) kB/\1/p' \ /proc/meminfo)
>
> awk '/MemTotal/ { print $2 }' /proc/meminfo
>
>>       space_megs=$(df -Pm ${1} 2>/dev/null | sed -n \
>>               '$s/\(\S\+\s\+\)\{3\}\([0-9]\+\).*/\2/p' 2>/dev/null)
>
> OMFG.
>
> space_megs=$(df -Pm "${1}" 2>/dev/null | awk 'FNR == 2 {print $4}')
>
> I guess.
>
>> # @FUNCTION: check-reqs_unsattisfied
>
> unsatisfied.
>
>>       # @DEAULT_UNSET
>
> @INTERNAL.
>
> --
> Best regards,
> Michał Górny
>

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Ulrich Mueller]

> On Wed, 31 Aug 2011, Tomáš Chvátal wrote:

>> [M0-9]) echo "mebibytes" ;;

> Anyway addressed :)

Please be consistent and change the following occurences too:

> # Internal function that returns number in megabites.

>   ewarn "QA: Assuming Megabytes."

And the name of check-reqs_get_megs() is a misnomer then, maybe it
should be called check_reqs_get_size or check_reqs_get_memory?

Ulrich

Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

[Alec Warner]

On Wed, Aug 31, 2011 at 6:41 AM, Corentin Chary
 wrote:
> Hi,
>
> some news about euscan (still available at http://euscan.iksaif.net)
>
> - New design (yay !)
> - Atom feeds available for each herd/category/maintainer/package
> (http://euscan.iksaif.net/maintainers/59/feed/)
> - Specific handlers for PyPi, RubyGems, pecl and PEAR packages (check
> http://git.iksaif.net/?p=euscan.git;a=tree;f=pym/euscan/handlers;h=9a995dfcebe6beecce71851abb84a875cf6e5979;hb=HEAD
> ).
>
> Now, maybe we should find a way to integrate that with the GSoC
> statistic project and with http://packages.gentoo.org/ (like done at
> http://packages.qa.debian.org/p/php-net-ipv4.html ). A quick way would
> be to host euscan on a gentoo server, and add some webservices to
> publish the data in json or xml, then packages.gentoo.org and others
> could parse that and display it.

The Gentoostats app supports fetching data with json (just put 'json'
in the HTTP_ACCEPT header in your GET.

-A

>
> Thanks,
>
> --
> Corentin Chary
> http://xf.iksaif.net
>
>

Re: [gentoo-dev] mesa r600 gallium news item

[Chí-Thanh Christopher Nguyễn]

Donnie Berkholz schrieb:
> On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote:
>> Existing users will not be switched automatically.
> 
> Why not? If it's considered the supported route going forward, we should 
> just do it automatically.

Some users might be using UMS instead of KMS still, which would break 3D
acceleration once they are switched to gallium.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Tomáš Chvátal]

Dne 31.8.2011 17:30, Michał Górny napsal(a):



DEPEND="sys-apps/gawk"


gawk is in the system set. If you really want to DEP on it explicitly,
maybe we should create a virtual, as any POSIX-compliant awk will
handle this.


# Temporary workaround for unset units.
# Backcompat.
[[ "${unit//*([[:digit:]])}" ]] || unit="M"

case ${unit} in
G) echo "Gibibytes" ;;
M) echo "Mebibytes" ;;
T) echo "Tebibytes" ;;
*)
die "${FUNCNAME}: Unknown unit: ${unit}"
;;
esac
}


case ${unit} in
[M0-9]) echo "mebibytes" ;;
...

And yes, they actually shall be written lowercase [1].

[1]:http://www.bipm.org/en/si/si_brochure/chapter5/5-2.html

Wonder if it would not be easier just to talk on irc so we don't bother 
everyone :P


Anyway addressed :)
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22 
04:46:31 vapier Exp $

# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team 
# @AUTHOR:
# Bo Ørsted Andresen 
# Original Author: Ciaran McCreesh 
# @BLURB: Provides a uniform way of handling ebuild which have very high build 
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY="256M"
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD="2G"
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR="1G"
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR="1024M"
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.

inherit eutils

# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M

# @ECLASS-VARIABLE:  CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? Eg.: 
CHECKREQS_DISK_BUILD=2T

# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? Eg.: 
CHECKREQS_DISK_USR=15G

# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M

EXPORT_FUNCTIONS pkg_setup
case "${EAPI:-0}" in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} "$@"

echo
ewarn "QA: Package calling old ${FUNCNAME} function."
ewarn "QA: Please file a bug against the package."
ewarn "QA: It should call check-reqs_pkg_pretend and 
check-reqs_pkg_setup"
ewarn "QA: and possibly use EAPI=4 or later."
echo

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_prepare
check-reqs_run
check-reqs_output
}

# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} "$@"

if [[ -z ${CHECKREQS_MEMORY} &&
-z ${CHECKREQS_DISK_BUILD} &&
-z ${CHECKREQS_DISK_USR} &&
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror "Set some check-reqs eclass variables if you want to use 
it."
eerror "If you are user and see this message fill a bug against 
the package."
die "${FUNCNAME}: check-reqs eclass called but not actualy 
used!"
fi
}

# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} "$@"

# some p

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Michał Górny]

> DEPEND="sys-apps/gawk"

gawk is in the system set. If you really want to DEP on it explicitly,
maybe we should create a virtual, as any POSIX-compliant awk will
handle this.

>   # Temporary workaround for unset units.
>   # Backcompat.
>   [[ "${unit//*([[:digit:]])}" ]] || unit="M"
> 
>   case ${unit} in
>   G) echo "Gibibytes" ;;
>   M) echo "Mebibytes" ;;
>   T) echo "Tebibytes" ;;
>   *)
>   die "${FUNCNAME}: Unknown unit: ${unit}"
>   ;;
>   esac
> }

case ${unit} in
[M0-9]) echo "mebibytes" ;;
...

And yes, they actually shall be written lowercase [1].

[1]:http://www.bipm.org/en/si/si_brochure/chapter5/5-2.html

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Tomáš Chvátal]

Dne 31.8.2011 14:38, Michał Górny napsal(a):

On Wed, 31 Aug 2011 12:32:03 +0200
Tomáš Chvátal  wrote:


gibibytes, mebibytes, tebibytes.


I preffer binary units over this fancy standard :)
Even our tools return the binary calculated ones not the decadic ones.


These are binary units, rather those fancy misnamed binary units of
yours. It's not fancy standard, it's the ONLY standard :P.


# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? (2T)


Not this looks like a insane default :D.


[G]) echo $((1024 * ${size})) ;;


just 'G)', 'M)', 'T)'.


ebegin "Checking for at least ${sizeunit} ${3}"


What ${3} there? I think you should decide whether to name all vars, or
use numeric ones.


# @FUNCTION: check-reqs_unsattisfied


docstring not updated.


How about now?
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22 
04:46:31 vapier Exp $

# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team 
# @AUTHOR:
# Bo Ørsted Andresen 
# Original Author: Ciaran McCreesh 
# @BLURB: Provides a uniform way of handling ebuild which have very high build 
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY="256M"
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD="2G"
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR="1G"
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR="1024M"
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.

inherit eutils

# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M

# @ECLASS-VARIABLE:  CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? Eg.: 
CHECKREQS_DISK_BUILD=2T

# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? Eg.: 
CHECKREQS_DISK_USR=15G

# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M

DEPEND="sys-apps/gawk"

EXPORT_FUNCTIONS pkg_setup
case "${EAPI:-0}" in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} "$@"

echo
ewarn "QA: Package calling old ${FUNCNAME} function."
ewarn "QA: Please file a bug against the package."
ewarn "QA: It should call check-reqs_pkg_pretend and 
check-reqs_pkg_setup"
ewarn "QA: and possibly use EAPI=4 or later."
echo

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_prepare
check-reqs_run
check-reqs_output
}

# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} "$@"

if [[ -z ${CHECKREQS_MEMORY} &&
-z ${CHECKREQS_DISK_BUILD} &&
-z ${CHECKREQS_DISK_USR} &&
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror "Set some check-reqs eclass variables if you want to use 
it."
eerror "If you are user and see this message fill a bug against 
the package."
die "${FUNCNAME}: check-reqs eclass called but not actualy 
used!"
fi
}

# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} "$@"

# s

Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

[Corentin Chary]

Hi,

some news about euscan (still available at http://euscan.iksaif.net)

- New design (yay !)
- Atom feeds available for each herd/category/maintainer/package
(http://euscan.iksaif.net/maintainers/59/feed/)
- Specific handlers for PyPi, RubyGems, pecl and PEAR packages (check
http://git.iksaif.net/?p=euscan.git;a=tree;f=pym/euscan/handlers;h=9a995dfcebe6beecce71851abb84a875cf6e5979;hb=HEAD
).

Now, maybe we should find a way to integrate that with the GSoC
statistic project and with http://packages.gentoo.org/ (like done at
http://packages.qa.debian.org/p/php-net-ipv4.html ). A quick way would
be to host euscan on a gentoo server, and add some webservices to
publish the data in json or xml, then packages.gentoo.org and others
could parse that and display it.

Thanks,

-- 
Corentin Chary
http://xf.iksaif.net

Re: [gentoo-dev] mesa r600 gallium news item

[Donnie Berkholz]

On 23:12 Thu 25 Aug , Chí-Thanh Christopher Nguyễn wrote:
> Existing users will not be switched automatically.

Why not? If it's considered the supported route going forward, we should 
just do it automatically.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com


pgphL8deYJFG4.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Michael Schreckenbauer]

Hi,

Am Mittwoch, 31. August 2011, 12:32:03 schrieb Tomáš Chvátal:
> Hehe same as above
> Rest I hopefully applied. Lemme know if you find something else.

just a user lurking here, but

# @FUNCTION: check-reqs_unsattisfied
# @DESCRIPTION:
# Internal function that inform about check result.
# It has different output between pretend and setup phase,
# where in pretend phase it is fatal.
check-reqs_unsattisfied() {

is this a typo (unsatisfied) or on purpose?

Regards,
Michael

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Michał Górny]

On Wed, 31 Aug 2011 12:32:03 +0200
Tomáš Chvátal  wrote:

> > gibibytes, mebibytes, tebibytes.
> >
> I preffer binary units over this fancy standard :)
> Even our tools return the binary calculated ones not the decadic ones.

These are binary units, rather those fancy misnamed binary units of
yours. It's not fancy standard, it's the ONLY standard :P.

> # @ECLASS-VARIABLE: CHECKREQS_DISK_USR
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # How much space in /usr is needed to install the package? (2T)

Not this looks like a insane default :D.

>   [G]) echo $((1024 * ${size})) ;;

just 'G)', 'M)', 'T)'.

>   ebegin "Checking for at least ${sizeunit} ${3}"

What ${3} there? I think you should decide whether to name all vars, or
use numeric ones.

> # @FUNCTION: check-reqs_unsattisfied

docstring not updated.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Tomáš Chvátal]

Dne 31.8.2011 12:14, Michał Górny napsal(a):

On Wed, 32 Aug 2011 10:57:08 +0200
Tomáš Chvátal  wrote:


Good pointer is that we should probably check if the
MERGE_TYPE=binary and not check-reqs ram and disk_build in that case.
But there is slight problem how to do it in older eapis.


We simply don't. Life is hard :P.
Meh in that case i will make it same on all eapis and just won't check 
for that :)



gibibytes, mebibytes, tebibytes.


I preffer binary units over this fancy standard :)
Even our tools return the binary calculated ones not the decadic ones.




actual_memory=$(sed -n -e '/MemTotal:/s/^[^:]*:
*\([0-9]\+\) kB/\1/p' \ /proc/meminfo)


awk '/MemTotal/ { print $2 }' /proc/meminfo
Just raw copy from old eclass, didn't feel like updating it, but since 
you did it I incorporated it :)



space_megs=$(df -Pm ${1} 2>/dev/null | sed -n \
'$s/\(\S\+\s\+\)\{3\}\([0-9]\+\).*/\2/p' 2>/dev/null)


OMFG.

space_megs=$(df -Pm "${1}" 2>/dev/null | awk 'FNR == 2 {print $4}')

I guess.

Hehe same as above


Rest I hopefully applied. Lemme know if you find something else.
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22 
04:46:31 vapier Exp $

# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team 
# @AUTHOR:
# Bo Ørsted Andresen 
# Original Author: Ciaran McCreesh 
# @BLURB: Provides a uniform way of handling ebuild which have very high build 
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY="256M"
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD="2G"
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR="1G"
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR="1024M"
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.

inherit eutils

# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? (15M)

# @ECLASS-VARIABLE:  CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? (13G)

# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? (2T)

# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? (3000M)

DEPEND="sys-apps/gawk"

EXPORT_FUNCTIONS pkg_setup
case "${EAPI:-0}" in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} "$@"

echo
ewarn "QA: Package calling old ${FUNCNAME} function."
ewarn "QA: Please file a bug against the package."
ewarn "QA: It should call check-reqs_pkg_pretend and 
check-reqs_pkg_setup"
ewarn "QA: and possibly use EAPI=4 or later."
echo

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_prepare
check-reqs_run
check-reqs_output
}

# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} "$@"

if [[ -z ${CHECKREQS_MEMORY} &&
-z ${CHECKREQS_DISK_BUILD} &&
-z ${CHECKREQS_DISK_USR} &&
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror "Set some check-reqs eclass variables if you want to use 
it."
eerror "If you are user and see this message fill a bug against 
the package."
die "${FUNCNAME}: check-reqs eclass called but not actualy 
used!"
fi
}

# @FUNCTION: check-reqs_run
# @DE

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Michał Górny]

On Wed, 32 Aug 2011 10:57:08 +0200
Tomáš Chvátal  wrote:

> Good pointer is that we should probably check if the
> MERGE_TYPE=binary and not check-reqs ram and disk_build in that case.
> But there is slight problem how to do it in older eapis.

We simply don't. Life is hard :P.

> Also Michal if you want to have that DISK array thingu there could
> you write a patch?

Well, I don't see really a need for that if we're still keeping old
vars.

Now about the code:

* I don't see units mentioned nor described in @DESCRIPTION or vars,

> EXPORT_FUNCTIONS pkg_setup
> case "${EAPI:-0}" in
>   0|1|2|3) ;;
>   4) EXPORT_FUNCTIONS pkg_pretend ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
> esac

Either you export them (which breaks backwards compat) or require users
to call them (your @CODE@). Don't do both, it's confusing.

> check-reqs_get_megs() {
>   debug-print-function ${FUNCNAME} "$@"
> 
>   [[ -z ${1} ]] && die "Usage: ${FUNCNAME} [size]"
> 
>   local unit=${1#${1%?}}
>   local size

local unit=${1:(-1)}

> 
>   # Temporary workaround for unset units.
>   # Backcompat.
>   if [[ "${unit//*([[:digit:]])}" ]]; then
>   # the unit itself was set ; strip it out
>   size=${1%\%}
>   else
>   size=${1}
>   unit="M"
>   fi

local size=${1%[GMT]}

> 
>   case ${unit} in
>   [gG]) echo $((1024 * ${size})) ;;
>   [mM]) echo ${size} ;;
>   [tT]) echo $((1024 * 1024 * ${size})) ;;

I'd just go with capital letters there.

[0-9]) echo ${size} ;;

(you can add that to the 'M' cond)

>   *)
>   die "${FUNCNAME}: Unknown unit size: ${unit}"

Size unit. Again.

>   ;;
>   esac
> }

>   [gG]) echo "Gigabytes" ;;
>   [mM]) echo "Megabytes" ;;
>   [tT]) echo "Terabytes" ;;

gibibytes, mebibytes, tebibytes.

> # @FUNCTION: check-reqs_memory
> # @DESCRIPTION:
> # Internal function that checks space on the RAM.

'space on the RAM' sounds bad :P.

>   check-reqs_start_phase \
>   $(check-reqs_get_number ${size}) \
>   $(check-reqs_get_unit ${size}) \
>   "RAM"

Move the number/unit split to _start_phase()?

>   actual_memory=$(sed -n -e '/MemTotal:/s/^[^:]*:
> *\([0-9]\+\) kB/\1/p' \ /proc/meminfo)

awk '/MemTotal/ { print $2 }' /proc/meminfo

>   space_megs=$(df -Pm ${1} 2>/dev/null | sed -n \
>   '$s/\(\S\+\s\+\)\{3\}\([0-9]\+\).*/\2/p' 2>/dev/null)

OMFG.

space_megs=$(df -Pm "${1}" 2>/dev/null | awk 'FNR == 2 {print $4}')

I guess.

> # @FUNCTION: check-reqs_unsattisfied

unsatisfied.

>   # @DEAULT_UNSET

@INTERNAL.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] category for openoffice/libreoffice extensions

[Kfir Lavi]

2011/8/31 Tomáš Chvátal 

> Hi,
> would it be sane to create new category for the extensions of the
> libreoffice? There will be more than handful of them when we add the
> office-ext eclass and start adding them to the main tree.
>
> I think it could go to office-plugins/ category, any other suggestions?
>
> Cheers
>
> Tom
>
> I think office-plugins can be defined as all plugins that relates to all
offices suits.
So I think office-plugins should be the one.

Regards,
Kfir

[gentoo-dev] [RFC] category for openoffice/libreoffice extensions

[Tomáš Chvátal]

Hi,
would it be sane to create new category for the extensions of the 
libreoffice? There will be more than handful of them when we add the 
office-ext eclass and start adding them to the main tree.


I think it could go to office-plugins/ category, any other suggestions?

Cheers

Tom

Re: [gentoo-dev] [RFC] check-reqs.eclass.patch

[Tomáš Chvátal]

Thanks for all the pointers, hopefully I addressed all issues raised by 
both of you :)


Good pointer is that we should probably check if the MERGE_TYPE=binary 
and not check-reqs ram and disk_build in that case.

But there is slight problem how to do it in older eapis.

Also Michal if you want to have that DISK array thingu there could you 
write a patch?


Tom
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22 
04:46:31 vapier Exp $

# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team 
# @AUTHOR:
# Bo Ørsted Andresen 
# Original Author: Ciaran McCreesh 
# @BLURB: Provides a uniform way of handling ebuild which have very high build 
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY="256M"
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD="2G"
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR="1G"
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR="1024M"
#
# # go!
# pkg_pretend() {
#check-reqs_pkg_pretend
# }
# 
# # Run once again to ensure that environment didn't
# # change since the pretend phase.
# pkg_setup() {
#check-reqs_pkg_setup
# }
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.

inherit eutils

# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed?

# @ECLASS-VARIABLE:  CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package?

# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package?

# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var?

EXPORT_FUNCTIONS pkg_setup
case "${EAPI:-0}" in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} "$@"

echo
ewarn "QA: Package calling old ${FUNCNAME} function."
ewarn "QA: Please file a bug against the package."
ewarn "QA: It should call check-reqs_pkg_pretend and 
check-reqs_pkg_setup"
ewarn "QA: and possibly use EAPI=4 or later."
echo

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_prepare
check-reqs_run
check-reqs_output
}

# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} "$@"

check-reqs_pkg_setup "$@"
}

# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} "$@"

if [[ -z ${CHECKREQS_MEMORY} &&
-z ${CHECKREQS_DISK_BUILD} &&
-z ${CHECKREQS_DISK_USR} &&
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror "Set some check-reqs eclass variables if you want to use 
it."
eerror "If you are user and see this message fill a bug against 
the package."
die "${FUNCNAME}: check-reqs eclass called but not actualy 
used!"
fi
}

# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} "$@"

# some people are *censored*
unset CHECKREQS_FAILED

[[ -n ${CHECKREQS_MEMORY} ]] && \
check-reqs_memory \
${CHECKREQS_MEMORY}

[[ -n ${CHECKREQS_DISK_BUILD} ]] && \
check-reqs_disk \
"${T}" \
"${CHECKREQS_DISK_BUILD}"

[[ -n ${CHECKREQS_DISK_USR} ]] && \
check-reqs_disk \
"${EROOT}/

[gentoo-dev] Lastrite: net-irc/conspire

[Pacho Ramos]

# Pacho Ramos  (31 Ago 2011)
# It still needs libsexy and was tagged as dead by upstream, 
# could reappear in the future if a 2.x release is launched   
# some day. bug #381221, removal in 30 days.
net-irc/conspire



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

Re: [gentoo-dev] Stable and keyword requests by users

[Ulrich Mueller]

> On Wed, 31 Aug 2011, Michał Górny wrote:

>> Can users file stable and keyword requests?

> They even should, I'd say. But please only do that for packages
> you're actually using/you actually need. And, as Justin pointed out,
> please don't CC arches yourself; package maintainer has to decide
> first if it can get keyworded/go stable.

That's not completely accurate. While stable requests should indeed be
handled by the package maintainer, keyword requests can be handled by
bug wranglers.

The policy is documented in
:

# * A keyword request should be assigned to the package's maintainer
#   and CC'd to the appropriate arch team(s). The report's Keywords
#   field should contain the KEYWORDREQ keyword.
#
# * A stabilisation request should be handled by the package's
#   maintainer, so you should not CC arch teams in your role as bug
#   wrangler, nor set the STABLEREQ keyword in the Keywords field.
#   Unless the package is maintainer-needed, then you should add
#   arches and set the Keyword field if the bug makes sense.

Ulrich

Re: [gentoo-dev] Re: [RFC] office-ext.eclass

[Tomáš Chvátal]

Dne 31.8.2011 01:09, Jonathan Callen napsal(a):

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Tomáš Chvátal wrote:

die "Unable not determine libreoffice/openoffice implementation!"


"Unable to determine ..."

- --
Jonathan Callen


Thanks, replaced.

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: office-ext.eclass
# @AUTHOR:
# Tomáš Chvátal 
# @MAINTAINER:
# The office team 
# @BLURB: Eclass for installing libreoffice/openoffice extensions
# @DESCRIPTION:
# Eclass for easing maitenance of libreoffice/openoffice extensions.

case "${EAPI:-0}" in
4) OEXT_EXPORTED_FUNCTIONS="src_install pkg_postinst pkg_prerm" ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

EXPORT_FUNCTIONS ${OEXT_EXPORTED_FUNCTIONS}
unset OEXT_EXPORTED_FUNCTIONS

inherit eutils multilib

UNOPKG_BINARY="${EPREFIX}/usr/bin/unopkg"

# @ECLASS-VARIABLE: OO_EXTENSIONS
# @REQUIRED
# @DESCRIPTION:
# Array containing list of extensions to install.
[[ -z ${OO_EXTENSIONS} ]] && die "OO_EXTENSIONS variable is unset."
if [[ "$(declare -p OO_EXTENSIONS 2>/dev/null 2>&1)" != "declare -a"* ]]; then
die "OO_EXTENSIONS variable is not an array."
fi

DEPEND="virtual/ooo"
RDEPEND="virtual/ooo"

# @FUNCTION: office-ext_flush_unopkg_cache
# @DESCRIPTION:
# Flush the cache after removal of an extension.
office-ext_flush_unopkg_cache() {
debug-print-function ${FUNCNAME} "$@"

debug-print "${FUNCNAME}: ${UNOPKG_BINARY} list --shared > /dev/null"
${UNOPKG_BINARY} list --shared > /dev/null
}

# @FUNCTION: office-ext_get_implementation
# @DESCRIPTION:
# Determine the implementation we are building against.
office-ext_get_implementation() {
debug-print-function ${FUNCNAME} "$@"
local implementations=(
"libreoffice"
"openoffice"
)
local i

for i in "${implementations[@]}"; do
if [[ -d "${EPREFIX}/usr/$(get_libdir)/${i}" ]]; then
debug-print "${FUNCNAME}: Determined implementation is: 
\"${EPREFIX}/usr/$(get_libdir)/${i}\""
echo "${EPREFIX}/usr/$(get_libdir)/${i}"
return
fi
done

die "Unable to determine libreoffice/openoffice implementation!"
}

# @FUNCTION: office-ext_add_extension
# @DESCRIPTION:
# Install the extension into the libreoffice/openoffice.
office-ext_add_extension() {
debug-print-function ${FUNCNAME} "$@"
local ext=$1
local tmpdir=$(mktemp -d --tmpdir="${T}")

debug-print "${FUNCNAME}: ${UNOPKG_BINARY} add --shared \"${ext}\""
ebegin "Adding extension: \"${ext}\""
${UNOPKG_BINARY} add --shared "${ext}" \
"-env:UserInstallation=file:///${tmpdir}" \
"-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1"
eend $?
rm -rf "${tmpdir}"
}

# @FUNCTION: office-ext_remove_extension
# @DESCRIPTION:
# Remove the extension from the libreoffice/openoffice.
office-ext_remove_extension() {
debug-print-function ${FUNCNAME} "$@"
local ext=$1
local tmpdir=$(mktemp -d --tmpdir="${T}")

debug-print "${FUNCNAME}: ${UNOPKG_BINARY} remove --shared \"${ext}\""
ebegin "Removing extension: \"${ext}\""
${UNOPKG_BINARY} remove --shared "${ext}" \
"-env:UserInstallation=file:///${tmpdir}" \
"-env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1"
eend $?
flush_unopkg_cache
rm -rf "${tmpdir}"
}

# @FUNCTION: office-ext_src_install
# @DESCRIPTION:
# Install the extension source to the proper location.
office-ext_src_install() {
debug-print-function ${FUNCNAME} "$@"
local i

# subshell to not pollute rest of the env with the insinto redefinition
(
insinto 
$(openoffice-ext_get_implementation)/share/extension/install/
for i in "${OO_EXTENSIONS[@]}"; do
doins "${i}"
done
)

einfo "Remember that if you replace your office implementation,"
einfo "you need to recompile all the extensions."
einfo "Your current implementation location is: "
einfo "$(openoffice-ext_get_implementation)"
}

# @FUNCTION: office-ext_pkg_postinst
# @DESCRIPTION:
# Add the extensions to the libreoffice/openoffice.
office-ext_pkg_postinst() {
debug-print-function ${FUNCNAME} "$@"
local i

for i in "${OO_EXTENSIONS[$@]}"; do
openoffice-ext_add_extension "${i}"
done

}

# @FUNCTION: office-ext_pkg_prerm
# @DESCRIPTION:
# Remove the extensions from the libreoffice/openoffice.
office-ext_pkg_prerm() {
debug-print-function ${FUNCNAME} "$@"
local i

for i in "${OO_EXTENSIONS[@]}"; do
openoffice-ext_remove_extension "${i}"
done
}

Re: [gentoo-dev] Stable and keyword requests by users

[Michał Górny]

On Wed, 31 Aug 2011 10:45:29 +0300
Nikos Chantziaras  wrote:

> Can users file stable and keyword requests?

They even should, I'd say. But please only do that for packages you're
actually using/you actually need. And, as Justin pointed out, please
don't CC arches yourself; package maintainer has to decide first if it
can get keyworded/go stable.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Stable and keyword requests by users

[justin]

On 31/08/11 09:45, Nikos Chantziaras wrote:
> Can users file stable and keyword requests?
> 
> 

Yes, but please do not CC any arches.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Stable and keyword requests by users

[Nikos Chantziaras]

Can users file stable and keyword requests?