Re: [OE-core] [PATCH 1/2] gstreamer1.0: convert GSTREAMER_1_DEBUG to PACKAGECONFIG
On Fri, 2015-05-08 at 13:35 -0700, Andre McCurdy wrote:
On Fri, May 8, 2015 at 12:12 PM, Otavio Salvador
ota...@ossystems.com.br wrote:
On Fri, May 8, 2015 at 4:07 PM, Andre McCurdy armccu...@gmail.com wrote:
...
Or perhaps even use the GSTREAMER_DEBUG variable in gstreamer 1.x
recipes?
I think the PACKAGECONFIG is a nice compromise as it allows for
granular control over what to enable or not. It is easy to enable it
for recipes in a local.conf using pn-package_append or similar.
Over-riding GSTREAMER_DEBUG could be done on a per-package basis too,
if there's really a need to enable debugging selectively.
However, I guess when you want to enable gstreamer debugging, you
typically want to do so through-out gstreamer and all plug-ins... and
needing to control PACKAGECONFIG for each recipe makes it harder to do
that.
Whatever happens, the GSTREAMER_DEBUG, GSTREAMER_1_DEBUG and
GSTREAMER_1_0_DEBUG duplication should probably be fixed.
I don't have a strong preference though and I'm stuck partnered with
an SoC vendor who only supports Gtreamer 0.10, so I'll be watching
from the sidelines as everyone else debugs GStreamer 1.x in oe-core
:-(
I took the patch since I do think PACKAGECONFIG is an improvement for
this. We could build upon it with something like:
GSTREAMER_CONFIG =
PACKAGECONFIG ??= ${GSTREAMER_CONFIG}
then setting GSTREAMER_CONFIG = debug could do what you describe if
there really is the demand for it.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] opkg_install_pkg: Package name md5sum mismatch. Either the opkg or the package index are corrupt.
On Fri, 2015-05-08 at 17:09 -0400, Denys Dmytriyenko wrote: weston-init RDEPENDS on weston and kbd. $ bitbake-diffsigs 1.0-r0.do_package_write_ipk.sigdata.eb3921bfc9623056f7ffaef4be8549ab 1.0-r0.do_package_write_ipk.sigdata.90c2978497847912cd64f66039927f7d Hash for dependent task waylandweston_1.6.0.bb.do_packagedata changed from 551b3b5ac7b3c41bfced58b88db2d824 to f3eb9cd1861c186382e47f90e82e3295 Hash for dependent task kbdkbd_2.0.1.bb.do_packagedata changed from 53a5dc88b80dc5ab559fbecd14277650 to 950fbc7fe3c33564e781743f2c260670 Then, comparing signatures for weston, for exaple, gives all the changes caused by different DEFAULTTUNEs, TUNE_FEATURES and ARMPKGARCH - obviously, since one machine is cortexa8, while another is cortexa9. But why would an allarch package even care about machine tunes in dependant packages, when it only RDEPENDS on them? If A DEPENDS on B and B changes, the package name may change (thanks to debian.bbclass) so A has to repackage. Very very annoying but technically correct :/. And how should I fix this? Thanks. See SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf of OE-Core. You probably need to add weston-init to the list. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] [0/2] Yocto Bug #6149, #5044
On Thu, 2015-05-07 at 19:50 -0400, Jate Sujjavanich wrote: I came across these bugs in poky 1.6.3 (daisy) with multiple package providers. I fixed bug 6149 with just bitbake patch. I came across another bug with this when I tried the bitbake fix on master. With the test case IMAGE_INSTALL_append = sshd PREFERRED_PROVIDER_sshd=dropbear meta/lib/oe/package_manager.py reported a package not found in the base feeds. The file image.bbclass starts copies IMAGE_INSTALL to PACKAGE_INSTALL and performs fix ups for multilib, etc. I added another function (rootfs_process_preferred_providers) to replace sshd in PACKAGE_INSTALL with dropbear. This eliminated the error. The mega-manual is vague when it describes what can be specified in PREFERRED_PROVIDER: an item. And the code partially supports run-time packages as a valid item on the left. My implementation assumes a package name on the right. I'm afraid this assumption is not correct. There are two distinct namespaces we have, the buildtime recipe names (PN) and the runtime package names. PREFERRED_PROVIDER takes recipe names (PN), not runtime ones. Mixing the two up is going to cause confusion and problems so the patch as it stands cannot be merged for this reason. Yocto bug 5044 suggests traversing from the package name to the virtual/* provider, but I have not thought through how this might work. IMAGE_INSTALL_append = libasound-module-bluez PREFERRED_PROVIDER_libasound-module-bluez=bluez4 I got this working on poky 1.6.3, but some changes to the bluez recipes on master seemed to mitigate the original problem. We have several issues with the way PREFERRED_PROVIDER works today and the translations between build time and runtime. I suspect that code needs rethinking to some extent. I know 5044 is assined to me, as yet I've not been able to find the time it needs to properly think through the different issues and fix it :( Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [fido] orphaned bbappend in meta-angstrom
Op 4 mei 2015, om 07:46 heeft Steffen Sledz sl...@dresearch-fe.de het volgende geschreven: On 30.04.2015 08:07, Steffen Sledz wrote: The angstrom-v2015.06-yocto1.8 branch of meta-angstrom contains recipes-tweaks/linux/linux-yocto_3.10.bbappend. But the fido branch of openembedded-core does not have a recipe for linux-yocto_3.10 (just 3.14 and 3.19). So the bbappend should be removed or updated. Ping! https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2350b1fdcffd31717c4ce256403fe2b391bb8d -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
