[gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Angelo Arrifano]

Hello ladies and gentlemen,

We at -embedded would like to introduce GPE - The G Palmtop Environment.
<<The GPE Palmtop Environment provides a user interface environment for
palmtop/handheld computers running the GNU/Linux or any other UNIX-like
operating system.>>

GPE is currently under active development, being version 2.8 already
very usable providing a modern mobile desktop environment.

We currently provide an eclass and ebuilds arranged by top level
categories following upstream categorization. Explicitly gpe.eclass and
top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media
gpe-xsession.
We know we have a lot of them but upstream finds useful to classify them
like that and so do we. With the running discussion at -dev about new
top level categorization models and tagging system, maybe a better
solution is found.

The eclass and some ebuilds were based on bugzie #101393. We started
playing with them as big flat gpe-base category which evolved over time
by means of consecutive testing on ARMv5 handheld devices and needs.

Since we are maintaining this over half a year now, we think that its
time to finally starting moving step-by-step the GPE suite into the
portage tree - starting with the eclass and toplevel categories.

Sincerely,
/me in the name of the embedded team.
-- 
Angelo Arrifano <miknix@gentoo.org>
Gentoo Linux ARM/OMAP850 Developer
at Gentoo Embedded

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Richard Freeman]

Angelo Arrifano wrote:
> We at -embedded would like to introduce GPE - The G Palmtop Environment.
> <<The GPE Palmtop Environment provides a user interface environment for
> palmtop/handheld computers running the GNU/Linux or any other UNIX-like
> operating system.>>
> 

Sounds neat?  How long until I'm running gentoo on my android?  :)

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Angelo Arrifano]

On Ter, 2009-02-03 at 11:28 -0500, Richard Freeman wrote:
> Angelo Arrifano wrote:
> > We at -embedded would like to introduce GPE - The G Palmtop Environment.
> > <<The GPE Palmtop Environment provides a user interface environment for
> > palmtop/handheld computers running the GNU/Linux or any other UNIX-like
> > operating system.>>
> > 
> 
> Sounds neat?  How long until I'm running gentoo on my android?  :)
> 

Right away: http://tinderbox.dev.gentoo.org/embedded/linwizard/overlay/
Take the gpe-base/gpe meta ebuild which should pull all the stuff.

Happy xcompiling,
-- 
Angelo Arrifano <miknix@gentoo.org>
Gentoo Linux ARM/OMAP850 Developer

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Ned Ludd]

On Tue, 2009-02-03 at 17:10 +0000, Angelo Arrifano wrote:
> On Ter, 2009-02-03 at 11:28 -0500, Richard Freeman wrote:
> > Angelo Arrifano wrote:
> > > We at -embedded would like to introduce GPE - The G Palmtop Environment.
> > > <<The GPE Palmtop Environment provides a user interface environment for
> > > palmtop/handheld computers running the GNU/Linux or any other UNIX-like
> > > operating system.>>
> > > 
> > 
> > Sounds neat?  How long until I'm running gentoo on my android?  :)
> > 
> 
> Right away: http://tinderbox.dev.gentoo.org/embedded/linwizard/overlay/
> Take the gpe-base/gpe meta ebuild which should pull all the stuff.
> 
> Happy xcompiling,


Assuming you have the G2 you could skip all that and simply merge from
these .tbz2 into a $ROOT

http://tinderbox.dev.gentoo.org/embedded/armv6j-softfloat-linux-gnueabi


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Richard Freeman]

Ned Ludd wrote:
> Assuming you have the G2 you could skip all that and simply merge from
> these .tbz2 into a $ROOT

Uh, is it even possible to get a G2 these days (short of working for 
HTC)?  I thought the only options on the actual market were the G1 and 
the ADP (just a G1 with a fancy battery cover and a different bootloader 
/ std image that otherwise works fine on a rooted G1).

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On 15:34 Tue 03 Feb     , Angelo Arrifano wrote:
> We at -embedded would like to introduce GPE - The G Palmtop Environment.

Hi,

Very cool that you've been working on this!

> We currently provide an eclass and ebuilds arranged by top level
> categories following upstream categorization. Explicitly gpe.eclass and
> top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media
> gpe-xsession.
> We know we have a lot of them but upstream finds useful to classify them
> like that and so do we.

Could you expand on how each new category is useful?

> The eclass and some ebuilds were based on bugzie #101393. We started
> playing with them as big flat gpe-base category which evolved over time
> by means of consecutive testing on ARMv5 handheld devices and needs.
> 
> Since we are maintaining this over half a year now, we think that its
> time to finally starting moving step-by-step the GPE suite into the
> portage tree - starting with the eclass and toplevel categories.

What are the stats on package count per category?

-- 
Thanks,
Donnie

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On 11:24 Tue 03 Feb     , Donnie Berkholz wrote:
> > We currently provide an eclass and ebuilds arranged by top level
> > categories following upstream categorization. Explicitly gpe.eclass and
> > top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media
> > gpe-xsession.
> > We know we have a lot of them but upstream finds useful to classify them
> > like that and so do we.
> 
> Could you expand on how each new category is useful?
> 
> > The eclass and some ebuilds were based on bugzie #101393. We started
> > playing with them as big flat gpe-base category which evolved over time
> > by means of consecutive testing on ARMv5 handheld devices and needs.
> > 
> > Since we are maintaining this over half a year now, we think that its
> > time to finally starting moving step-by-step the GPE suite into the
> > portage tree - starting with the eclass and toplevel categories.
> 
> What are the stats on package count per category?

I got this from solar:

     30 gpe-base
      8 gpe-games
      4 gpe-media
      9 gpe-misc
      2 gpe-net
     32 gpe-phone
      6 gpe-pim
     18 gpe-utils
      8 gpe-xsession

Unless those tiny ones are going to be growing a lot, I'm not terribly 
convinced of this many new ones.

-- 
Thanks,
Donnie

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Angelo Arrifano]

On Ter, 2009-02-03 at 11:47 -0800, Donnie Berkholz wrote:
> On 11:24 Tue 03 Feb     , Donnie Berkholz wrote:
> > > We currently provide an eclass and ebuilds arranged by top level
> > > categories following upstream categorization. Explicitly gpe.eclass and
> > > top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media
> > > gpe-xsession.
> > > We know we have a lot of them but upstream finds useful to classify them
> > > like that and so do we.
> > 
> > Could you expand on how each new category is useful?

In my maintainer point of view, it just make sense to follow upstream
categorization of packages.

In the user centric view, it will be a lot more easier to know what
package is for by looking at each category.
gpe-xxxx is intended for embedded devices, one might want to keep it
clean and minimal.

> > 
> > > The eclass and some ebuilds were based on bugzie #101393. We started
> > > playing with them as big flat gpe-base category which evolved over time
> > > by means of consecutive testing on ARMv5 handheld devices and needs.
> > > 
> > > Since we are maintaining this over half a year now, we think that its
> > > time to finally starting moving step-by-step the GPE suite into the
> > > portage tree - starting with the eclass and toplevel categories.
> > 
> > What are the stats on package count per category?
> 
> I got this from solar:
> 
>      30 gpe-base
>       8 gpe-games
>       4 gpe-media
>       9 gpe-misc
>       2 gpe-net
>      32 gpe-phone
>       6 gpe-pim
>      18 gpe-utils
>       8 gpe-xsession
> 
> Unless those tiny ones are going to be growing a lot, I'm not terribly 
> convinced of this many new ones.
> 

They won't grow much over time so I understand your point.
Although, I would like to ask the drawbacks of adding those new
categories to portage.
Adding confusion and mess won't be an issue because these are very
specific categories which won't affect other ebuilds or other
categories.
After all we don't want to introduce something like dev-gpe mail-gpe
x11-gpe net-embedded ... which, IMHO, would be messy.
So, despite "looking" a *lot* of new categories with not so much stuff
inside, will this slow down portage sync/metadata-regen/loopkup in some
way?

Thank you,
-- 
Angelo Arrifano <miknix@gentoo.org>
Gentoo Linux ARM/OMAP850 Developer

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Tue, 03 Feb 2009 20:13:15 +0000
Angelo Arrifano <miknix@gentoo.org> wrote:
> So, despite "looking" a *lot* of new categories with not so much stuff
> inside, will this slow down portage sync/metadata-regen/loopkup in
> some way?

Performance is best if the number of categories is equal to the number
of packages in each category. Purely from a performance perspective, a
few small categories doesn't hurt much; very large categories are a
much bigger problem.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Announcement of The G Palmtop Environment ebuilds

[Duncan]

Angelo Arrifano <miknix@gentoo.org> posted
1233691996.22368.25.camel@localhost, excerpted below, on  Tue, 03 Feb 2009
20:13:15 +0000:

> On Ter, 2009-02-03 at 11:47 -0800, Donnie Berkholz wrote:
>> On 11:24 Tue 03 Feb     , Donnie Berkholz wrote:
>> > 
>> > Could you expand on how each new category is useful?
> 
> In my maintainer point of view, it just make sense to follow upstream
> categorization of packages.
> 
> In the user centric view, it will be a lot more easier to know what
> package is for by looking at each category. gpe-xxxx is intended for
> embedded devices, one might want to keep it clean and minimal.
> 
>> > What are the stats on package count per category?
>> 
>> I got this from solar:
>> 
>>      30 gpe-base
>>       8 gpe-games
>>       4 gpe-media
>>       9 gpe-misc
>>       2 gpe-net
>>      32 gpe-phone
>>       6 gpe-pim
>>      18 gpe-utils
>>       8 gpe-xsession
>> 
>> Unless those tiny ones are going to be growing a lot, I'm not terribly
>> convinced of this many new ones.
>> 
> They won't grow much over time so I understand your point. {But...]

What about handling it much as split-KDE is handled?  IOW, just one gpe-
base (or if upstream specifically has the dash already, maybe gpalmtop-
environment) category, with gpecat-pkgname or gpe-cat-pkgname packages, 
so you'd have gpe-base/gpebase-pkgfoo, gpe-base/gpegames-pkgbar, etc?

That would closely parallel the kde-base/kdebase-cursors,
kde-base/kdenetwork-kfile-plugins scheme, with options such as
kde-base/konqueror (no upstream category name included) if desired.

-- 
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] Announcement of The G Palmtop Environment ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Angelo Arrifano wrote:
> 
> Since we are maintaining this over half a year now, we think that its
> time to finally starting moving step-by-step the GPE suite into the
> portage tree - starting with the eclass and toplevel categories.
> 

Please start by posting the new eclasses for review then.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Angelo Arrifano]

On Qua, 2009-02-04 at 13:56 +0200, Petteri Räty wrote:
> Angelo Arrifano wrote:
> > 
> > Since we are maintaining this over half a year now, we think that its
> > time to finally starting moving step-by-step the GPE suite into the
> > portage tree - starting with the eclass and toplevel categories.
> > 
> 
> Please start by posting the new eclasses for review then.
> 
> Regards,
> Petteri
> 

# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Authors:
# Rene Wagner <rw@handhelds.org>
# Ned Ludd <solar@gentoo.org>
# Angelo Arrifano <miknix@gentoo.org>

# based on gnome2.eclass and gpe.bbclass (the latter from OpenEmbedded)

inherit libtool toolchain-funcs

# GPE ECLASS
#GPECONF=""             # extra configure opts passed to econf
ELTCONF=""              # extra options passed to elibtoolize
DOCS=""                 # documentation files to be installed with dodoc

[ -z "${GPE_MIRROR}" ] && export GPE_MIRROR="http://gpe.linuxtogo.org/download/source"

[ -z "${GPE_TARBALL_SUFFIX}" ] && export GPE_TARBALL_SUFFIX="gz"

SRC_URI="${GPE_MIRROR}/${PN}-${PV}.tar.${GPE_TARBALL_SUFFIX}"
HOMEPAGE="http://gpe.handhelds.org/"

IUSE="${IUSE} nls"
GPECONF="${GPECONF} --enable-debug=no --disable-debug"

RDEPEND=""
DEPEND=">=dev-util/intltool-0.29 >=dev-util/pkgconfig-0.12.0"

gpe_src_configure() {
	tc-export CC
	if [ -f configure ]; then
		elibtoolize ${ELTCONF}
		econf "$@" ${GPECONF} || die "./configure failure"
	fi
}

gpe_src_compile() {
	tc-export CC
	has "${EAPI:-0}" 0 1 && gpe_src_configure "$@"
	emake PREFIX=/usr || die "compile failure"
}

gpe_src_install() {
	USE_NLS=yes
	use nls || USE_NLS=no

	if [ -f configure ]; then
		einstall "$@"
	else
		make DESTDIR=${D} PREFIX=/usr \
			STRIP=true ENABLE_NLS=${USE_NLS} \
			"$@" install
	fi

	# manual document installation
	[ -n "${DOCS}" ] && dodoc ${DOCS}

}

gpe_src_unpack() {
	unpack ${A}
	cd "${S}"
	# let portage handle stripping.
	for x in $(find "${S}" -name 'Makefile*') ; do
		sed -i  -e s/'install -s'/'install'/g \
			-e s/'install -Ds'/'install -D'/g \
			-e 's/$(INSTALL) -s/$(INSTALL) /g' $x
	done
}

EXPORT_FUNCTIONS src_compile src_install src_unpack

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

Angelo Arrifano wrote:
> 
> # Copyright 2008 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
> #
> # Authors:
> # Rene Wagner <rw@handhelds.org>
> # Ned Ludd <solar@gentoo.org>
> # Angelo Arrifano <miknix@gentoo.org>
> 

Should use eclass-manpages syntax.

> 
> # GPE ECLASS
> #GPECONF=""             # extra configure opts passed to econf
> ELTCONF=""              # extra options passed to elibtoolize
> DOCS=""                 # documentation files to be installed with dodoc
> 

If other eclass that comes before in the inherit hierarchy and sets
DOCS, do we want to override it?

> [ -z "${GPE_MIRROR}" ] && export GPE_MIRROR="http://gpe.linuxtogo.org/download/source"
> 
> [ -z "${GPE_TARBALL_SUFFIX}" ] && export GPE_TARBALL_SUFFIX="gz"
> 

Is there a binary called that makes use of those two?

> 
> IUSE="${IUSE} nls"
>

This is the first use of IUSE in the eclass so there is nothing to
append to.

> 
> gpe_src_configure() {
> 	tc-export CC
> 	if [ -f configure ]; then
> 		elibtoolize ${ELTCONF}
> 		econf "$@" ${GPECONF} || die "./configure failure"
> 	fi
> }
> 

Ebuilds/Eclasses should use [[ instead of [ and econf dies on it's own
any way.


> gpe_src_install() {
> 	USE_NLS=yes
> 	use nls || USE_NLS=no
> 

I don't see USE_NLS used outside install so it should be local and
written in lower case.

> 	if [ -f configure ]; then
> 		einstall "$@"
> 	else

If you really need to use einstall, it would be best to add a comment
about why it's needed.

> 		make DESTDIR=${D} PREFIX=/usr \
> 			STRIP=true ENABLE_NLS=${USE_NLS} \
> 			"$@" install
> 	fi
> 

Should use emake. Stripping should be left to the package manager.

> 	# manual document installation
> 	[ -n "${DOCS}" ] && dodoc ${DOCS}
> 
> }
> 

dodoc should have || die with it

>
> EXPORT_FUNCTIONS src_compile src_install src_unpack
> 

Never exports configure for EAPI 2.

Regards,
Petteri




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Angelo Arrifano]

On Qua, 2009-02-04 at 18:36 +0200, Petteri Räty wrote:
> Angelo Arrifano wrote:
> > 
> > # Copyright 2008 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header: $
> > #
> > # Authors:
> > # Rene Wagner <rw@handhelds.org>
> > # Ned Ludd <solar@gentoo.org>
> > # Angelo Arrifano <miknix@gentoo.org>
> > 
> 
> Should use eclass-manpages syntax.

Thanks, fixed on next revision
> 
> > 
> > # GPE ECLASS
> > #GPECONF=""             # extra configure opts passed to econf
> > ELTCONF=""              # extra options passed to elibtoolize
> > DOCS=""                 # documentation files to be installed with dodoc
> > 
> 
> If other eclass that comes before in the inherit hierarchy and sets
> DOCS, do we want to override it?

Yes, we want. If we will make dodoc die by default like you proposed
below, DOCS must be explicitly set by each ebuild sourcing any common
DOC provided by the eclass.
> 
> > [ -z "${GPE_MIRROR}" ] && export GPE_MIRROR="http://gpe.linuxtogo.org/download/source"
> > 
> > [ -z "${GPE_TARBALL_SUFFIX}" ] && export GPE_TARBALL_SUFFIX="gz"
> > 
> 
> Is there a binary called that makes use of those two?
Yes, some packages uses bz2 but most of them gz. Ebuilds fetching bz2
from the default URI will use both.

> 
> > 
> > IUSE="${IUSE} nls"
> >
> 
> This is the first use of IUSE in the eclass so there is nothing to
> append to.

True, fixed on next revision.
> 
> > 
> > gpe_src_configure() {
> > 	tc-export CC
> > 	if [ -f configure ]; then
> > 		elibtoolize ${ELTCONF}
> > 		econf "$@" ${GPECONF} || die "./configure failure"
> > 	fi
> > }
> > 
> 
> Ebuilds/Eclasses should use [[ instead of [ and econf dies on it's own
> any way.

Fixed on next revision.
> 
> 
> > gpe_src_install() {
> > 	USE_NLS=yes
> > 	use nls || USE_NLS=no
> > 
> 
> I don't see USE_NLS used outside install so it should be local and
> written in lower case.

This is an ancient issue where almost (but not all) packages provides an
--enable-nls flag. I'll discuss with solar about the usefulness of this
code. Thanks.

> 
> > 	if [ -f configure ]; then
> > 		einstall "$@"
> > 	else
> 
> If you really need to use einstall, it would be best to add a comment
> about why it's needed.

Some packages are not automake driven. We have to detect those.
> 
> > 		make DESTDIR=${D} PREFIX=/usr \
> > 			STRIP=true ENABLE_NLS=${USE_NLS} \
> > 			"$@" install
> > 	fi
> > 
> 
> Should use emake. Stripping should be left to the package manager.

Stripping is problematic when cross-compiling. I'll do some more tests
to figure out the best way. Although, we are doing this for a long time
now and it works. IMHO, changing things in the last "hour" usually leads
to breakage.
> 
> > 	# manual document installation
> > 	[ -n "${DOCS}" ] && dodoc ${DOCS}
> > 
> > }
> > 
> 
> dodoc should have || die with it
There are some ebuilds that don't provide all the DOCS, I'll try to fix
the ebuilds first and then we'll see..
> 
> >
> > EXPORT_FUNCTIONS src_compile src_install src_unpack
> > 
> 
> Never exports configure for EAPI 2.

Already fixed, thanks to loki_val for his patch.
> 
> Regards,
> Petteri
> 
> 
> 

Thank you,
-- 
Angelo Arrifano <miknix@gentoo.org>
Gentoo Linux ARM/OMAP850 Developer

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Ned Ludd]

On Thu, 2009-02-05 at 00:37 +0000, Angelo Arrifano wrote:
> On Qua, 2009-02-04 at 18:36 +0200, Petteri Räty wrote:

> Some packages are not automake driven. We have to detect those.
> > 
> > > 		make DESTDIR=${D} PREFIX=/usr \
> > > 			STRIP=true ENABLE_NLS=${USE_NLS} \
> > > 			"$@" install
> > > 	fi
> > > 
> > 
> > Should use emake. Stripping should be left to the package manager.


STRIP=true replaces STRIP=strip while also returning a non error status.
This is done in order to ensure that portage handles the stripping using
the correct cross-strip. We also have to sed a bunch of templates out
that use install -s etc which always calls the wrong strip.

But STRIP=true is proper as in /bin/true without the path.

Side note I've already talked with upstream and future versions will
probably drop any default stripping or move towards better unification.

Thanks.

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

Angelo Arrifano wrote:
> On Qua, 2009-02-04 at 18:36 +0200, Petteri Räty wrote:
>> Angelo Arrifano wrote:
>>> # Copyright 2008 Gentoo Foundation
>>> # Distributed under the terms of the GNU General Public License v2
>>> # $Header: $
>>> #
>>> # Authors:
>>> # Rene Wagner <rw@handhelds.org>
>>> # Ned Ludd <solar@gentoo.org>
>>> # Angelo Arrifano <miknix@gentoo.org>
>>>
>> Should use eclass-manpages syntax.
> 
> Thanks, fixed on next revision
>>> # GPE ECLASS
>>> #GPECONF=""             # extra configure opts passed to econf
>>> ELTCONF=""              # extra options passed to elibtoolize
>>> DOCS=""                 # documentation files to be installed with dodoc
>>>
>> If other eclass that comes before in the inherit hierarchy and sets
>> DOCS, do we want to override it?
> 
> Yes, we want. If we will make dodoc die by default like you proposed
> below, DOCS must be explicitly set by each ebuild sourcing any common
> DOC provided by the eclass.

This makes little sense to me. The checks there makes sure that DOCS is
non empty.

>>> [ -z "${GPE_MIRROR}" ] && export GPE_MIRROR="http://gpe.linuxtogo.org/download/source"
>>>
>>> [ -z "${GPE_TARBALL_SUFFIX}" ] && export GPE_TARBALL_SUFFIX="gz"
>>>
>> Is there a binary called that makes use of those two?
> Yes, some packages uses bz2 but most of them gz. Ebuilds fetching bz2
> from the default URI will use both.
> 

If only the eclass/ebuilds use these variables, then there should not be
an export statement here.

> 
> Stripping is problematic when cross-compiling. I'll do some more tests
> to figure out the best way. Although, we are doing this for a long time
> now and it works. IMHO, changing things in the last "hour" usually leads
> to breakage.

Stripping is removed in your src_unpack so that variable probably does
nothing.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-dev] Re: Announcement of The G Palmtop Environment ebuilds

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Wed, 04 Feb 2009 18:36:15 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> Angelo Arrifano wrote:
> > 	# manual document installation
> > 	[ -n "${DOCS}" ] && dodoc ${DOCS}
> > 
> > }
> > 
> 
> dodoc should have || die with it

Dieing on dodoc is a complete waste of time and effort.  No one wants
the ebuild to fail if ChangeLog.2006 doesn't exist.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Announcement of The G Palmtop Environment ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Ryan Hill wrote:
> On Wed, 04 Feb 2009 18:36:15 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> 
>> Angelo Arrifano wrote:
>>> 	# manual document installation
>>> 	[ -n "${DOCS}" ] && dodoc ${DOCS}
>>>
>>> }
>>>
>> dodoc should have || die with it
> 
> Dieing on dodoc is a complete waste of time and effort.  No one wants
> the ebuild to fail if ChangeLog.2006 doesn't exist.
> 
> 

If ebuild devs test their stuff before committing, it will never hit users.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Angelo Arrifano]

# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: gpe.eclass
# @MAINTAINER: <gpe@gentoo.org>
#
# Original Authors:
# Rene Wagner <rw@handhelds.org>
# Ned Ludd <solar@gentoo.org>
# Angelo Arrifano <miknix@gentoo.org>
#
# @BLURB: Provides common functionality for the G Palmtop Environment.
# @DESCRIPTION: Provides common functionality for the G Palmtop Environment.
#
# Thanks to:
# loki_val for EAPI->EAPI2 patch
# 
# Based on:
# gnome2.eclass and gpe.bbclass (the latter from OpenEmbedded)

inherit libtool toolchain-funcs

case "${EAPI:-0}" in
	0|1)
		EXPORT_FUNCTIONS src_unpack src_compile src_install
		;;
	*)
		EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
		;;
esac

ELTCONF=""              # extra options passed to elibtoolize
GPE_DOCS=""             # documentation files to be installed with dodoc

[ -z "${GPE_MIRROR}" ] && GPE_MIRROR="http://gpe.linuxtogo.org/download/source"
[ -z "${GPE_TARBALL_SUFFIX}" ] && GPE_TARBALL_SUFFIX="gz"
SRC_URI="${GPE_MIRROR}/${P}.tar.${GPE_TARBALL_SUFFIX}"

HOMEPAGE="http://gpe.linuxtogo.org"

IUSE="nls"
GPECONF="${GPECONF} --enable-debug=no --disable-debug"

RDEPEND=""
DEPEND="
	>=dev-util/intltool-0.29
	>=dev-util/pkgconfig-0.12.0"

# @FUNCTION: gpe_src_unpack
# @DESCRIPTION: Unpacks and applies some required patches for GPE.
gpe_src_unpack() {
	unpack ${A}
	cd "${S}"
	has "${EAPI:-0}" 0 1 && gpe_src_prepare "$@"
}

# Do not call, use gpe_src_unpack() instead.
gpe_src_prepare() {
	# let portage handle stripping.
	for file in $(find . -name 'Makefile*') ; do
		sed -i  -e s/'install -s'/'install'/g \
			-e s/'install -Ds'/'install -D'/g \
			-e 's/$(INSTALL) -s/$(INSTALL) /g' \
			-e 's;strip ;#strip ;g' \
			${file} \
			||die "Sedding ${file} failed."
	done
	[[ -f configure ]] && elibtoolize
}

# @FUNCTION: gpe_src_configure
# @DESCRIPTION: Configures a GPE package in a cross-compile aware environment.
gpe_src_configure() {
	tc-export CC
	[[ -f configure ]] && econf "$@" ${GPECONF}
}

# @FUNCTION: gpe_src_compile
# @DESCRIPTION: (Cross-)Compiles a GPE package.
gpe_src_compile() {
	tc-export CC
	has "${EAPI:-0}" 0 1 && gpe_src_configure "$@"
	# miknix: Code belo must NOT die, some packages dont really build anything,
	# just install.
	emake PREFIX=/usr
}

# @FUNCTION: gpe_src_install
# @DESCRIPTION: Installs a GPE package in the correct way.
gpe_src_install() {
	local use_nls

	use_nls=yes
	use nls || use_nls=no

	if [ -f configure ]; then
		einstall "$@" || die "einstall failed"
	else
		emake DESTDIR=${D} ENABLE_NLS=${use_nls} \
			"$@" install || die "emake install failed"
	fi
	if [[ "${GPE_DOCS}" ]]; then
		dodoc ${GPE_DOCS} || die "dodoc failed"
	fi
}


Thanks all for the suggestions/patches
-- 
Angelo Arrifano <miknix@gentoo.org>
Gentoo Linux ARM/OMAP850 Developer

Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

Angelo Arrifano wrote:
> 
> [ -z "${GPE_MIRROR}" ] && GPE_MIRROR="http://gpe.linuxtogo.org/download/source"
> [ -z "${GPE_TARBALL_SUFFIX}" ] && GPE_TARBALL_SUFFIX="gz"
> SRC_URI="${GPE_MIRROR}/${P}.tar.${GPE_TARBALL_SUFFIX}"
> 

Use [[ here.

> 
> # @FUNCTION: gpe_src_compile
> # @DESCRIPTION: (Cross-)Compiles a GPE package.
> gpe_src_compile() {
> 	tc-export CC
> 	has "${EAPI:-0}" 0 1 && gpe_src_configure "$@"
> 	# miknix: Code belo must NOT die, some packages dont really build anything,
> 	# just install.
> 	emake PREFIX=/usr
> }
> 

The packages that don't build anything can do:
src_compile() { :; } or you can have a variable for skipping the build
step.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]