Re: [oe] [meta-oe][PATCH 4/4] qt4: remove bbappends
On Sat, Apr 6, 2013 at 4:28 PM, Paul Eggleton wrote: > On Saturday 06 April 2013 10:36:41 Otavio Salvador wrote: >> On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton >> wrote: >> > These changes to Qt's configuration need to be applied in distro layers, >> > not in meta-oe. >> > >> > Signed-off-by: Paul Eggleton >> >> NACK! >> >> Keep PRINC as otherwise revision will go backwards. > > Sigh... Oh well I guess Qt 4.8.5 is just around the corner and then we can > drop this bbappend. When can we drop the packagegroup one though? We can't; but it does not hurt as I think it won't be removed from oe-core any time soon ;-) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 4/4] qt4: remove bbappends
On Saturday 06 April 2013 10:36:41 Otavio Salvador wrote: > On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton > wrote: > > These changes to Qt's configuration need to be applied in distro layers, > > not in meta-oe. > > > > Signed-off-by: Paul Eggleton > > NACK! > > Keep PRINC as otherwise revision will go backwards. Sigh... Oh well I guess Qt 4.8.5 is just around the corner and then we can drop this bbappend. When can we drop the packagegroup one though? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] List of distro policies?
Hello, is there a list of settings, values, policies that are distro specific? I haven't found anything like that so far, and the only source of information about what is allowed and what isn't has been this mailing list and the IRC channel. For example, I am suspecting that MULTI_PROVIDER_WHITELIST is a distro policy, but I cannot find that documented anywhere. thanks, Carlos ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 0/4] Clean up recipes
On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton wrote: > Drop some items that should no longer be in meta-oe. The Qt ones need to be reworked to keep the upgrade path. I replied accordingly. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 2/4] icon-naming-utils: remove
On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton wrote: > This version is now in OE-Core. > > Signed-off-by: Paul Eggleton Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 1/4] libmad: remove
On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton wrote: > This is largely equivalent to the recipe in OE-Core apart from > LICENSE_FLAGS, insignificant patch differences, and an additional patch > for avr32 optimisation (and since there appears to be no public layer > for an avr32 machine, there's not a great deal of point in preserving > the latter). > > Signed-off-by: Paul Eggleton Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 3/4] packagegroup-qte-toolchain-target: remove bbappend
On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton wrote: > This added Qwt to the Qt Embedded toolchain. This is a distro policy > decision, and in any case Qwt is a third-party library which is not part > of Qt. Distros that wish to do this should add this bbappend to their > own layers. > > Signed-off-by: Paul Eggleton NACK Keep PRINC please. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][PATCH 4/4] qt4: remove bbappends
On Fri, Apr 5, 2013 at 8:35 PM, Paul Eggleton wrote: > These changes to Qt's configuration need to be applied in distro layers, > not in meta-oe. > > Signed-off-by: Paul Eggleton NACK! Keep PRINC as otherwise revision will go backwards. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Can a .bbappend introduce a different PACKAGE_ARCH ?
On 2013-04-06 04:50, Carlos Rafael Giani wrote:
Hello,
assume there is package foo, which is normally not dependent on a specific
machine. It is built with default, machine independent configuration options.
But then I want to add a .bbappend to it, which add some configuration options
that make it machine dependent (imagine something like --device=beagleboard).
I then add PACKAGE_ARCH=${MACHINE_ARCH} to the .bbappend file. Is this actually
okay to do? Or does it break something?
You can do this and it will work fine.
However, if your .bbappend file forces the use of any override
directories/files, I believe it will happen automatically. For
example, my BSP layers have their own network configuration files
which I do like this:
gthomas@zeus:/local/poky-multi$ tree -S meta-cobra4430p82/recipes-core/netbase/
meta-cobra4430p82/recipes-core/netbase/
netbase-5.0
cobra4430p82
interfaces
modem.py
netbase_5.0.bbappend
2 directories, 4 files
gthomas@zeus:/local/poky-multi$ cat
meta-cobra4430p82/packages/netbase/netbase_5.0.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:${THISDIR}/${PN}:"
SRC_URI_append = " file://modem.py"
do_install_append() {
install -m 0755 ${WORKDIR}/modem.py ${D}/etc
}
This setup generates a machine dependent package.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Can a .bbappend introduce a different PACKAGE_ARCH ?
Hello,
assume there is package foo, which is normally not dependent on a
specific machine. It is built with default, machine independent
configuration options.
But then I want to add a .bbappend to it, which add some configuration
options that make it machine dependent (imagine something like
--device=beagleboard).
I then add PACKAGE_ARCH=${MACHINE_ARCH} to the .bbappend file. Is this
actually okay to do? Or does it break something?
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
