[OE-core] Yocto Project booth at ELC - Call for demos

[Barros Pena, Belen]

The Yocto Project will have a booth at the Embedded Linux Conference in
San Diego. If you have something you'd like to demo in the booth, please
reply to me off list providing the following information:

1. Person in charge of the demo (they must be at ELC)
2. Demo description

Thanks!

Belén

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Parsing exception with latest oe-core

[Barros Pena, Belen]

On 12/02/2016 10:52, "openembedded-core-boun...@lists.openembedded.org on
behalf of Martin Jansa"  wrote:

>Hi,
>
>
>is anyone else seeing this unhelpful fatal exception?

FWIW, I am 

http://piratepad.net/2E3lnayxi8

Cheers

Belén

>
>
>ERROR: Failure expanding variable
>__anon_648__home_jenkins_oe_world_shr_core_openembedded_core_meta_classes_
>base_bbclass, expression was def
>__anon_648__home_jenkins_oe_world_shr_core_openembedded_core_meta_classes_
>base_bbclass(d):
>import string, re
>
># Handle PACKAGECONFIG
>#
># These take the form:
>#
># PACKAGECONFIG ??= ""
># PACKAGECONFIG[foo] =
>"--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
>pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
>if pkgconfigflags:
>pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
>pn = d.getVar("PN", True)
>
>mlprefix = d.getVar("MLPREFIX", True)
>
>def expandFilter(appends, extension, prefix):
>appends = bb.utils.explode_deps(d.expand(" ".join(appends)))
>newappends = []
>for a in appends:
>if a.endswith("-native") or ("-cross-" in a):
>newappends.append(a)
>elif a.startswith("virtual/"):
>subs = a.split("/", 1)[1]
>if subs.startswith(prefix):
>newappends.append(a + extension)
>else:
>newappends.append("virtual/" + prefix + subs +
>extension)
>else:
>if a.startswith(prefix):
>newappends.append(a + extension)
>else:
>newappends.append(prefix + a + extension)
>return newappends
>
>def appendVar(varname, appends):
>if not appends:
>return
>if varname.find("DEPENDS") != -1:
>if pn.startswith("nativesdk-"):
>appends = expandFilter(appends, "", "nativesdk-")
>if pn.endswith("-native"):
>appends = expandFilter(appends, "-native", "")
>if mlprefix:
>appends = expandFilter(appends, "", mlprefix)
>varname = d.expand(varname)
>d.appendVar(varname, " " + " ".join(appends))
>
>extradeps = []
>extrardeps = []
>extraconf = []
>for flag, flagval in sorted(pkgconfigflags.items()):
>items = flagval.split(",")
>num = len(items)
>if num > 4:
>bb.error("%s: PACKAGECONFIG[%s] Only
>enable,disable,depend,rdepend can be specified!"
>% (d.getVar('PN', True), flag))
>
>if flag in pkgconfig:
>if num >= 3 and items[2]:
>extradeps.append(items[2])
>if num >= 4 and items[3]:
>extrardeps.append(items[3])
>if num >= 1 and items[0]:
>extraconf.append(items[0])
>elif num >= 2 and items[1]:
>extraconf.append(items[1])
>appendVar('DEPENDS', extradeps)
>appendVar('RDEPENDS_defaultpkgname', extrardeps)
>if bb.data.inherits_class('cmake', d):
>appendVar('EXTRA_OECMAKE', extraconf)
>else:
>appendVar('EXTRA_OECONF', extraconf)
>
>pn = d.getVar('PN', True)
>license = d.getVar('LICENSE', True)
>if license == "INVALID":
>bb.fatal('This recipe does not have the LICENSE field set (%s)' %
>pn)
>
>if bb.data.inherits_class('license', d):
>check_license_format(d)
>unmatched_license_flag = check_license_flags(d)
>if unmatched_license_flag:
>bb.debug(1, "Skipping %s because it has a restricted license
>not"
> " whitelisted in LICENSE_FLAGS_WHITELIST" % pn)
>raise bb.parse.SkipPackage("because it has a restricted
>license not"
> " whitelisted in LICENSE_FLAGS_WHITELIST")
>
># If we're building a target package we need to use fakeroot (pseudo)
># in order to capture permissions, owners, groups and special files
>if not bb.data.inherits_class('native', d) and not
>bb.data.inherits_class('cross', d):
>d.setVarFlag('do_unpack', 'umask', '022')
>d.setVarFlag('do_configure', 'umask', '022')
>d.setVarFlag('do_compile', 'umask', '022')
>d.appendVarFlag('do_install', 'depends', '
>virtual/fakeroot-native:do_populate_sysroot')
>d.setVarFlag('do_install', 'fakeroot', '1')
>d.setVarFlag('do_install', 'umask', '022')
>d.appendVarFlag('do_package', 'depends', '
>virtual/fakeroot-native:do_populate_sysroot')
>d.setVarFlag('do_package', 'fakeroot', '1')
>d.setVarFlag('do_package', 'umask', '022')
>

Re: [OE-core] [PATCH] toaster: update the openembedded-core toaster configuration file

[Barros Pena, Belen]

On 04/02/2016 12:21, "openembedded-core-boun...@lists.openembedded.org on
behalf of Richard Purdie"
 wrote:

>On Thu, 2016-02-04 at 10:47 +, Elliot Smith wrote:
>> From: Belen Barros Pena 
>> 
>> It looks like the master branch will no longer build with the Fido
>> release, so remove all references to fido and make sure that the file
>> sets up local, master and jethro releases.
>
>Did you mean to remove dizzy too? I suspect the answer is yes but the
>commit message doesn't mention that.

I meant to remove Dizzy. I should have been more explicit. Apologies.

Belén

>
>Cheers,
>
>Richard
>
>-- 
>___
>Openembedded-core mailing list
>Openembedded-core@lists.openembedded.org
>http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] OE stand at FOSDEM 2016

[Barros Pena, Belen]

Thanks to all the people who helped with the OE stand at FOSDEM,
particularly Florian for carrying and keeping the suitcase.

Some photographs here

https://www.dropbox.com/sh/2qot9pd1jr32opz/AABfwuET_jetdbMu5bPbjAfwa?dl=0

Cheers

Belén

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Toaster] FW: [PATCH 6/7] toaster: Update for buildstats changes

[Barros Pena, Belen]

On 18/12/2015 10:56, "Richard Purdie" <richard.pur...@linuxfoundation.org>
wrote:

>On Fri, 2015-12-18 at 09:21 +, Barros Pena, Belen wrote:
>> I applied the buildstats series on top of toaster-next, ran a build,
>> and
>> checked the build stats info. I can see time per task coming in. I
>> cannot
>> see cpu usage or disk i/o data in the UI because of this
>> 
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8571
>> 
>> But there is data for both in the database, and it looks sane. So I
>> guess,
>> from the UI standpoint, the patches are ok: things were as broken as
>> they
>> were before ;)
>
>Thanks Belén!
>
>I was asked what new data was available from buildstats.

Thanks. I've opened an enhancement for this

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8842

Cheers

Belén

>Right now you
>show in toaster:
>
>Task execution time
>CPU usage
>Some IO usage number
>
>I'd note that CPU usage is no longer logged, the reason being that the
>numbers were basically misleading and inaccurate. The raw data in
>buildstats looks like:
>
>Started: 1450427397.44
>quilt-0.64-r0: do_compile: Elapsed time: 0.37 seconds
>utime: 7
>stime: 2
>cutime: 16
>cstime: 7
>IO write_bytes: 1269760
>IO read_bytes: 0
>IO cancelled_write_bytes: 0
>IO syscr: 6165
>IO wchar: 1205445
>IO rchar: 4465276
>IO syscw: 1508
>rusage ru_utime: 0.076
>rusage ru_stime: 0.02
>rusage ru_maxrss: 39684
>rusage ru_minflt: 4618
>rusage ru_majflt: 0
>rusage ru_inblock: 0
>rusage ru_oublock: 32
>rusage ru_nvcsw: 53
>rusage ru_nivcsw: 0
>Child rusage ru_utime: 0.168
>Child rusage ru_stime: 0.076
>Child rusage ru_maxrss: 41180
>Child rusage ru_minflt: 81640
>Child rusage ru_majflt: 0
>Child rusage ru_inblock: 0
>Child rusage ru_oublock: 2448
>Child rusage ru_nvcsw: 988
>Child rusage ru_nivcsw: 352
>Status: PASSED 
>Ended: 1450427397.81
>
>In particular what you can do now is:
>
>a) breakdown filesystem IO usage to reads and writes (read_bytes and
>write_bytes)
>b) show total IO (wchar and rchar)
>
>[difference between filesystem IO and total IO is that there are caches
>in the middle, filesystem IO goes to the physical disk, total IO can be
>from memory - all the reads above were from cache hence 0 read_bytes
>but a large rchar]
>
>c) break down task execution time into "system" (cstime) and "user"
>(cutime) time. Divide those numbers by 100HZ to get seconds. This tells
>us how much time was in the kernel in syscalls and how much doing
>execution in userspace.
>
>d) break down times into parent and child processes (stime and utime
>verses cstime and ustime). The latter includes all children so is a
>total. This is probably less interesting to most users.
>
>e) show the number of voluntary and involuntary context switches
>(ru_nvcsw and ru_nivcsw). Again, the child numbers are totals, you can
>also just get the parent value.
>
>f) there is other data but the above is the pieces I've personally
>found to be interesting/useful.
>
>Some of the numbers are duplicates, e.g. ru_stime is stime/100 (convert
>to seconds) in the parent and child cases. You could do a better CPU
>usage approximation by something like:
>
>(child(ru_stime + ru_utime) / elapsed time) * 100 = % CPU Usage
>
>Hope that makes some kind of sense and that we could expose a bit more
>of this to the user at some point!
>
>Cheers,
>
>Richard
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Demos for FOSDEM 2016

[Barros Pena, Belen]

On 17/12/2015 20:09, "Philip Balister" <phi...@balister.org> wrote:

>On 12/17/2015 05:43 AM, Barros Pena, Belen wrote:
>> Hi all,
>> 
>> OpenEmbedded will have a huge 2-table stand at FOSDEM'16, which happens
>> January 30th and 31st in Brussels.
>> 
>> We need to fill up those 2 tables with something, so this is a call for
>> demos. If you have something built with OpenEmbedded you'd like to show,
>> let me know. 
>> 
>> Looking forward to your hundreds of demo proposals ;)
>
>Remember we are "selling" the OpenEmbedded build system, not cool
>gadgets. (Yes, we have the same problem every year).
>
>We do want to show that we can build embedded Linux solutions for a
>variety of hardware, both development and production systems.
>
>I'm working toward having two different pieces of hardware, both running
>the same SDR app. 

Sounds good.

>And I want to ahve a copy of toaster running to show
>how the images are built.

If you need any help with the Toaster bit, let us know.

Cheers

Belén

>
>Philip
>
>
>> 
>> Cheers,
>> 
>> Belén
>> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Demos for FOSDEM 2016

[Barros Pena, Belen]

Hi all,

OpenEmbedded will have a huge 2-table stand at FOSDEM'16, which happens
January 30th and 31st in Brussels.

We need to fill up those 2 tables with something, so this is a call for
demos. If you have something built with OpenEmbedded you'd like to show,
let me know. 

Looking forward to your hundreds of demo proposals ;)

Cheers,

Belén

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 02/12/2015 18:43, "Burton, Ross"  wrote:

>
>On 2 December 2015 at 18:04, Martin Jansa
> wrote:
>
>I'm depending on bundles heavily, to "mark" the patches for layers with
>dedicated maintainer and also for extra "status" like merged in
>"master-next" branch for jenkins build, because standard status values
>aren't fine-grained enough.
>
>
>
>
>Sounds like instead of bundles the new patchworks needs the ability for a
>single list to represent multiple projects (so there'd be a meta-oe,
>meta-python, etc),

That's already in place

https://github.com/dlespiau/patchwork/issues/15

>and more status values.

You can add status values (to the db directly or via the Django admin
interface), but they will apply to all projects in the Patchwork instance.
Ideally you should be able to set a list of status values per project I
guess. 

Cheers

Belén

>
>
>Ross
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 02/12/2015 18:04, "Martin Jansa"  wrote:

My only concern is about migrating current database, do you know if the
migration will keep the database
>>I don't know, but I can find out.

I've been told that database migration will work from the version of
Patchwork OE is currently using to the version of Patchwork being used by
FDO. 

including bundles

Yes, including bundles :)

>>If we remove the bundles, then I guess the migration might not keep the
>>bundles. 
>
>OK, then can we please postpone this upgrade (or run both patchworks in
>parallel) until these 2 features are implemented and working?
>
>I'm depending on bundles heavily, to "mark" the patches for layers with
>dedicated maintainer and also for extra "status" like merged in
>"master-next" branch for jenkins build, because standard status values
>aren't fine-grained enough.

Fair enough. Maybe we should consider keeping bundles then.

Cheers

Belén

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [Openembedded-architecture] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 03/12/2015 12:51, "Burton, Ross" <ross.bur...@intel.com> wrote:

>On 3 December 2015 at 11:43, Barros Pena, Belen
><belen.barros.p...@intel.com> wrote:
>
>>and more status values.
>
>You can add status values (to the db directly or via the Django admin
>interface), but they will apply to all projects in the Patchwork instance.
>Ideally you should be able to set a list of status values per project I
>guess.
>
>
>
>
>Well it depends on what the extra values are.

Heh, I meant that's how Patchwork works at the moment, independently of
what we do for OE


> Martin, what values do you use?  A "merged in staging" value would be
>useful for everyone.
>
>
>Ross
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 02/12/2015 08:17, "openembedded-core-boun...@lists.openembedded.org on
behalf of Martin Jansa"  wrote:

>On Wed, Dec 02, 2015 at 04:01:40PM +1300, Paul Eggleton wrote:
>> On Tue, 01 Dec 2015 11:47:20 Martin Jansa wrote:
>> > On Tue, Dec 01, 2015 at 07:49:50AM +1300, Paul Eggleton wrote:
>> > > Hi Trevor,
>> > > 
>> > > On Mon, 30 Nov 2015 10:19:35 Trevor Woerner wrote:
>> > > > On 11/26/15 16:00, Paul Eggleton wrote:
>> > > > > I'm also
>> > > > > trying to ensure that the patch validation is generic enough so
>>it can
>> > > > > live in OE-Core, and thus we can easily update and refine it
>>over time
>> > > > > in
>> > > > > line with the code itself as well as encourage submitters to
>>use the
>> > > > > script on their own changes before sending.
>> > > > 
>> > > > This all sounds like an improvement and is therefore a step in
>>the right
>> > > > direction :-)
>> > > > 
>> > > > A while back I had the idea of "porting" the kernel's
>>"checkpatch.pl" to
>> > > > The Yocto Project (it was around the same time that I was trying
>>to
>> > > > float the whole "Maintainers File" idea too, since I was also
>>trying to
>> > > > re-purpose "get-maintainer.pl" as well). About one minute into
>>that
>> > > > effort I realized the existing *.bb files were all over the place
>>in
>> > > > terms of the order of statements and the order of the blocks of
>> > > > statements. At that time I found one recipe style guide from OE,
>>and
>> > > > another one from The Yocto Project, each of which described a
>>slightly
>> > > > different preference. So I asked on the mailing list and quickly
>> > > > discovered that both groups prefer a different style.
>> > > > 
>> > > > I'm not saying this job isn't worth doing, but I am pointing out
>>there's
>> > > > the potential for feathers to be ruffled on both sides if someone
>>tries
>> > > > to produce a definitive style guide for recipe files and then
>>enforces
>> > > > it in an automated way. Since it is the OpenEmbedded Project's
>>job to
>> > > > provide the recipes for The Yocto Project, I'm guessing this
>>question
>> > > > needs to be decided by them? If that sounds reasonable, then
>>maybe The
>> > > > Yocto Project needs to acquiesce to OE's decision?
>> > > 
>> > > I don't think there's that much of a division. I don't recall if it
>>was
>> > > you
>> > > that raised it at the time but the issue of having two style guides
>>did
>> > > get
>> > > rectified - I changed the one on the Yocto Project wiki to simply
>>be a
>> > > link to the OE style guide in June last year. It certainly didn't
>>come
>> > > about through a conscious decision to have a different style.
>> > > 
>> > > However there is a minor disagreement over indentation for shell
>>functions
>> > > between OE-Core and other layers - this persists because of the
>> > > backporting
>> > > pain a blanket replacement would potentially lead to. As I recall
>>this did
>> > > get discussed at the OE TSC level. I think that's one thing we
>>could just
>> > > not evaluate (or make an option) until such time as we resolve the
>> > > difference - and I do mean to see it resolved at some point in the
>> > > future.
>> > 
>> > Using consistent indentation (4 spaces) at least for new metadata
>>would
>> > be step in right direction.
>> > 
>> > With the amount of changes which are backported to older releases I
>> > still don't see this "backporting pain" argument. Doing it just before
>> > the release is of course useful, because e.g. now more changes will be
>> > backported to Jethro than to Fido or Dizzy. So having consistent
>> > indentation in Jethro and master would prevent 95% of "backporting
>> > pain". Maybe some Yocto 10.0 will finally get the meaning of
>> > "consistent" indentation.
>> 
>> I agree it's not ideal. I said above, I do want to see it resolved.
>> 
>> Leaving indentation aside for a moment do you have any comments on my
>> proposal?
>
>I'm not familiar with FDO fork, so I don't know how it looks and
>behaves,

This is how it looks like currently

http://patchwork.freedesktop.org/project/intel-gfx/patches/

> but any improvement on patchwork side is definitely welcome and
>I appreciate it.
>
>Does it support e.g. moving the patches to given bundle based on some
>substring in subject? To sort e.g. meta-networking, meta-java,
>meta-browser, .. patches automatically?

Mmm, you might not like this, but we are thinking of getting rid of
bundles. Basically, we assumed bundles were a manual way of creating patch
series. The new Patchwork can identify series, so we thought: great!
Bundles no longer needed.

There are other features been considered that might be an alternative to
bundles, like tagging


>
>I don't expect FDO fork to provide other features I'm used to from
>gerrit like cherry-picking to selected branch from the UI or doing the
>review there. But still if we're stuck with patchwork forever (because

Re: [OE-core] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 02/12/2015 10:54, "openembedded-core-boun...@lists.openembedded.org on
behalf of Barros Pena, Belen"
<openembedded-core-boun...@lists.openembedded.org on behalf of
belen.barros.p...@intel.com> wrote:

>
>
>On 02/12/2015 08:17, "openembedded-core-boun...@lists.openembedded.org on
>behalf of Martin Jansa" <openembedded-core-boun...@lists.openembedded.org
>on behalf of martin.ja...@gmail.com> wrote:
>
>>On Wed, Dec 02, 2015 at 04:01:40PM +1300, Paul Eggleton wrote:
>>> On Tue, 01 Dec 2015 11:47:20 Martin Jansa wrote:
>>> > On Tue, Dec 01, 2015 at 07:49:50AM +1300, Paul Eggleton wrote:
>>> > > Hi Trevor,
>>> > > 
>>> > > On Mon, 30 Nov 2015 10:19:35 Trevor Woerner wrote:
>>> > > > On 11/26/15 16:00, Paul Eggleton wrote:
>>> > > > > I'm also
>>> > > > > trying to ensure that the patch validation is generic enough so
>>>it can
>>> > > > > live in OE-Core, and thus we can easily update and refine it
>>>over time
>>> > > > > in
>>> > > > > line with the code itself as well as encourage submitters to
>>>use the
>>> > > > > script on their own changes before sending.
>>> > > > 
>>> > > > This all sounds like an improvement and is therefore a step in
>>>the right
>>> > > > direction :-)
>>> > > > 
>>> > > > A while back I had the idea of "porting" the kernel's
>>>"checkpatch.pl" to
>>> > > > The Yocto Project (it was around the same time that I was trying
>>>to
>>> > > > float the whole "Maintainers File" idea too, since I was also
>>>trying to
>>> > > > re-purpose "get-maintainer.pl" as well). About one minute into
>>>that
>>> > > > effort I realized the existing *.bb files were all over the place
>>>in
>>> > > > terms of the order of statements and the order of the blocks of
>>> > > > statements. At that time I found one recipe style guide from OE,
>>>and
>>> > > > another one from The Yocto Project, each of which described a
>>>slightly
>>> > > > different preference. So I asked on the mailing list and quickly
>>> > > > discovered that both groups prefer a different style.
>>> > > > 
>>> > > > I'm not saying this job isn't worth doing, but I am pointing out
>>>there's
>>> > > > the potential for feathers to be ruffled on both sides if someone
>>>tries
>>> > > > to produce a definitive style guide for recipe files and then
>>>enforces
>>> > > > it in an automated way. Since it is the OpenEmbedded Project's
>>>job to
>>> > > > provide the recipes for The Yocto Project, I'm guessing this
>>>question
>>> > > > needs to be decided by them? If that sounds reasonable, then
>>>maybe The
>>> > > > Yocto Project needs to acquiesce to OE's decision?
>>> > > 
>>> > > I don't think there's that much of a division. I don't recall if it
>>>was
>>> > > you
>>> > > that raised it at the time but the issue of having two style guides
>>>did
>>> > > get
>>> > > rectified - I changed the one on the Yocto Project wiki to simply
>>>be a
>>> > > link to the OE style guide in June last year. It certainly didn't
>>>come
>>> > > about through a conscious decision to have a different style.
>>> > > 
>>> > > However there is a minor disagreement over indentation for shell
>>>functions
>>> > > between OE-Core and other layers - this persists because of the
>>> > > backporting
>>> > > pain a blanket replacement would potentially lead to. As I recall
>>>this did
>>> > > get discussed at the OE TSC level. I think that's one thing we
>>>could just
>>> > > not evaluate (or make an option) until such time as we resolve the
>>> > > difference - and I do mean to see it resolved at some point in the
>>> > > future.
>>> > 
>>> > Using consistent indentation (4 spaces) at least for new metadata
>>>would
>>> > be step in right direction.
>>> > 
>>> > With the amount of changes which are backported to older releases I
>>&

[OE-core] [RFC] Development workflow

[Barros Pena, Belen]

One of the things that came out of the discussion Why is embedded still
hard at the OEDAM was the need to document development workflow best
practices, particularly when it comes to application development.

It was agreed that the first step should be collecting existing practices
to understand what people are currently doing and what works well in which
circumstances. If you are working (or have worked) with embedded
application developers, you can help with this. You have a couple of
sharing options:

1) You can talk to me (a 45-minute conversation should do). I can then
document our conversation, and once you are happy with the outcome, I can
share it with the list. If you prefer this way, send me an email off list
or ping me in IRC (belen)

2) You can write it down in an email to the mailing list. You can use the
examples Richard Purdie shared as a starting point

http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092079.h
tml

Or you can answer some / all of the following questions:

* Can you tell me a little bit about the context in which you are using
the Yocto Project? Is it for specific products? Is it across the whole
company?

* How many people are using Yocto Project? How are they organised? How are
they split in terms of their skill set? What are their responsibilities?

* How do the different skill sets interact? Are there specific
deliverables they must hand over to each other, things like development
images, or application recipes?

* Can you describe the development process for custom applications? What
are they main steps in the process?

* Do you use the Yocto Project for the full development process, or only
for certain steps in it?

* Are there any steps in the process that are particularly problematic?
Can you describe why?

* What do you miss to assist you in those steps? Tools? Documentation?
Best practices? Something else?

* Have you looked at the Yocto Project ADT/SDK? Do you find it useful and
if not, what would you consider its limitations?

* Have you looked at the Yocto Project Eclipse plugin? Do you find it
useful and if not, what would you consider its limitations?

* If you could ask 3 wishes from the Yocto Project, what would they be?

The document attached to this Bugzilla feature


https://bugzilla.yoctoproject.org/show_bug.cgi?id=6225

might also help somehow.

Looking forward to all the answers.

Cheers,

Belén


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] My thoughts on the future of OE?

[Barros Pena, Belen]

On 05/05/2014 04:39, David Nyström david.nyst...@enea.com wrote:

How do I trace a buggy package
installed on my target rootfs, back to an item in the locked sstate?

FWIW, you should be able to do that with Toaster, as long as you know
which one is the buggy package :) With Toaster you can navigate the build
process, from the package, to the recipe, to the tasks executed by the
build system for that recipe. As part of the tasks information, Toaster
will show you which tasks reused which sstate objects. So effectively you
can trace any package to the corresponding sstate object(s).

Cheers

Belén

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Dogfooding and usability testing Toaster

[Barros Pena, Belen]

Hi all, 

I am looking into collecting feedback on the first version of Toaster

https://www.yoctoproject.org/blogs/belenbarrospena/2014/eye-candy

which will be out with Yocto Project 1.6. There are 2 things I'd like to
do:

1) Dogfooding

Once the release is out, it would be great to have people trying Toaster
for real work stuff, and telling us how it went. I am of course
particularly keen on hearing about what's wrong, so feel free to vent your
frustrations with the thing.

2) (More formal) usability testing

I am also looking into validating the Toaster interface in more
conventional ways, which means usability testing. This is done in
30-minute sessions run remotely using screen sharing software, although we
can also do it in person if you are going to ELC or the OEDAM. During
those 30 minutes you will be asked to do some stuff with Toaster and to
speak your mind a lot. I will also ask for your permission to record the
session, which you can of course refuse.

If you would like to volunteer for this (which is useful and important
stuff), get in touch with me (I am belen in IRC, or email me). I would
normally give out something in return for your time, but things are tight
right now, so I'm afraid all you'll get on this occasion is a heartwarming
thank you.

Cheers

Belén


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core