Now it's filtering Error/FetchError/UpgradeNotNeeded errors but you are right that we need to only take into account exceptions inherit Error to avoid send emails with system exceptions like Syntax

Sorry I'm not quite following - you mean you did filter out exceptions that don't inherit from Error or you will change it to do that? Unless I'm missing something, this patch now catches any

Hi Paul, Comments below, Kind regards, alimon Yes i'll change the string testing for isinstance. That's good observation i filter all the errors that don't are in the class of Error, also i

Obviously this is in the existing code, but I'm not hugely keen on checking the error name as a string - I'd much rather we checked it with isinstance here. That might require us to have all errors

Hi, Have a look here [1] 3.2.1.2. Core System Development, and [2] I did have troubles in the past. When I built e.g. for 2 different boards both using the same compiler and the same sstate funny

Not sure it sounds like something might not be accounting for the first 0x8000 for interrupts or something, what error/messages do you see when it fails to boot? or do you see nothing output on the

Hi, I have configured the yocto project and i am getting vmdk.ext3 image I want to configure that iso image should also be generated. I have changed IMAGE_FSTYPE in qemux86.conf to iso. But on

As it's barely functional (no metadata, obviously) it doesn't get used a lot, but it shouldn't be broken... I did wonder if we should remove it some time ago, but the consensus was that it's a nice

i vaguely recall from way back that the tar packaging was not really supported, or was mostly unused, or something to that effect. what's the status on that these days? rday --

Hi All, One more thing the convert task has different flow for both the recipes and the names of the package is different as below is snapshot of the actual code. Also PACKAGE_CLASSES has both

Just add "tar" to PACKAGE_CLASSES and you'll get a tarball of every package alongside the RPM. (note that the tar packages are relatively untested but they're also very simple so should still

Hello all, Why 'yocto-bsp create ... i386' (Yocto dizzy 1.7.2) is defining a kernel config with the MATOM=y even if I select the default kernel with the '586' tune (neither the 'Atom' nor the

Hi, Currently I have two different recipes for similar type of package with a minor differences. Below is the list 1. One being packaged as tar.gz and don’t have pre or post install

Hi Vincent, I’ve switch my build to use 3.19.5-yocto-standard by adding a preferred_version to my local.conf. This has changed the behaviour: 1) At startup XOrg is still using a lot of memory

Hi again, On 06/09/2015 12:21 PM, Peter Bergin wrote: I still have serious with this issue. I think it is not possible to cross-compile python3-ctypes in fido. I filed a

I'm building for two similar targets and sharing sstate between them. Actually, I build for target A and use that sstate cache in my SSTATE_MIRRORS for target B. If I try to build target B from

Hi Luke, Comments below, Best regards, alimon [1] https://autobuilder.yoctoproject.org/ [2] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/

Hi, I’m trying to understand the feasibility of shared-state across multiple users in a development environment. Does anyone have first-hand experience with this? Am I asking for trouble?

Rebased my 1.8 yocto and oe layers. Meta-ti was still master as there was no 1.8 tag when I did my initial checkout. Smoked tmp dir and rebuilt my image and it worked there too now. Don't know

Signed-off-by: Aníbal Limón <anibal.limon@...> --- README | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README b/README index ec3f955..dbcc755 100644 ---