Re: [yocto] What's up with python3

[Burton, Ross]

On 8 June 2017 at 13:10, Gary Thomas  wrote:

> What would I lose by do this, in general, as it's pretty obvious
> that python3 is not needed by any of the recipes I use?
>

It's the scripts in opkg-utils, so if you're not installing that in your
image then you won't notice at all.

(looks like the recipe should respect the python PACKAGECONFIG and delete
the python scripts so they can't get packaged)

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's up with python3

[Gary Thomas]

On 2017-06-08 13:52, Burton, Ross wrote:


On 8 June 2017 at 08:28, Gary Thomas > wrote:

I've listed all the recipes used in my build (from bitbake -g => 
recipe-depends.dot)
and sucked out the ones that claim to depend on python3.  I don't see why, 
for
example, python(2) depends on python3?


I'm 90% sure that this all comes through opkg-utils being the provider for 
update-alternatives.

You could verify this by disabling the python PACKAGECONFIG in opkg-utils.


I'm impressed!  That eliminated all of them :-)

What would I lose by do this, in general, as it's pretty obvious
that python3 is not needed by any of the recipes I use?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's up with python3

[Burton, Ross]

On 8 June 2017 at 08:28, Gary Thomas  wrote:

> I've listed all the recipes used in my build (from bitbake -g =>
> recipe-depends.dot)
> and sucked out the ones that claim to depend on python3.  I don't see why,
> for
> example, python(2) depends on python3?
>

I'm 90% sure that this all comes through opkg-utils being the provider for
update-alternatives.

You could verify this by disabling the python PACKAGECONFIG in opkg-utils.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's up with python3

[Gary Thomas]

On 2017-06-08 13:09, Alexander Kanavin wrote:

On 06/08/2017 10:28 AM, Gary Thomas wrote:

I'm building using Poky/Yocto master
576821ea0a7558b626ccc87e9ae0e9ee40864956
and I've noticed that python3 (target) is being built for my image, but it
doesn't end up in the actual image.  None of my own recipes mention python3
at all, yet virtually every recipe that's used in the build depend on it.

I've listed all the recipes used in my build (from bitbake -g =>
recipe-depends.dot)
and sucked out the ones that claim to depend on python3.  I don't see
why, for
example, python(2) depends on python3?

Can someone explain this?  I've added the appropriate files to this email.

I'm mostly curious, but also a bit concerned that my builds are doing more
than they need (and hence just taking longer than they might need to)


Typically for two reasons:

a) a recipe needs to execute python during build, and host python is not suitable for some reason - so native python is 
built and used;


Not that: I filtered out all uses of python3-native - these are only *target* 
dependencies



b) a supplementary package needs python, while the main package does not - most often this is the -ptest package, which 
will not end up in the image, unless you ask.


None of my recipes build -ptest stuff:
  $ find tmp/deploy/ipk/ -name "*ptest*"

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's up with python3

[Alexander Kanavin]

On 06/08/2017 10:28 AM, Gary Thomas wrote:

I'm building using Poky/Yocto master
576821ea0a7558b626ccc87e9ae0e9ee40864956
and I've noticed that python3 (target) is being built for my image, but it
doesn't end up in the actual image.  None of my own recipes mention python3
at all, yet virtually every recipe that's used in the build depend on it.

I've listed all the recipes used in my build (from bitbake -g =>
recipe-depends.dot)
and sucked out the ones that claim to depend on python3.  I don't see
why, for
example, python(2) depends on python3?

Can someone explain this?  I've added the appropriate files to this email.

I'm mostly curious, but also a bit concerned that my builds are doing more
than they need (and hence just taking longer than they might need to)


Typically for two reasons:

a) a recipe needs to execute python during build, and host python is not 
suitable for some reason - so native python is built and used;


b) a supplementary package needs python, while the main package does not 
- most often this is the -ptest package, which will not end up in the 
image, unless you ask.


Alex

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Mike Looijmans]

On 08-06-16 00:20, Richard Purdie wrote:

On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:

On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:

On 7 June 2016 at 17:02, Burton, Ross 
wrote:

It means the hash calculated my the bitbake master was different
to the
hash calculated when the worker started up.  This usually means
that
you're
using something like ${TIME} in the recipe but not marking it
appropriatly
so the cache ignores it.  Do you have a base-files bbappend that
writes a
timestamp?


The always wise Joshua reminds me that if your DISTRO_VERSION
contains
${DATETIME} then this happens.  If you're doing this then you'll
want to
set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from
getting
into the cache (or not put the current date/time into the distro
version).


I think we need to handle this situation better - if it's really
worth
producing an error about then it's worth producing an error message
that
people can actually understand, particularly as it's recently added
validation.


It was silently running into problems due to this all along but not
reporting it. Its now reporting it which is better than silently things
behaving strangely.

Its very hard for bitbake to know why the hashes differ, it only knows
the values afterwards and hence that they've changed, the information
about how that hash was constructed is not present in any of bitbake's
caches. That implies to have better messages we need to write out more
data.

I did add a patch to make bitbake write out data to allow
reconstruction of basehash (which is part of taskhash). Sadly the
parsing performance was diabolical (10 times slower). I think that
could perhaps be improved if the files don't require an atomic move
during creation but I haven't had time to look further at it.

So whilst I do agree, what is the price people are willing to pay to
have those better messages?


I have a build machine that every so often runs into "basehash mismatch" 
problems (but never when you want it to, such as now), so getting some 
information on what might cause it would be "priceless". I'd happily let the 
machine run for 10 days straight if at the end I get a message that I can work 
with.


Which implies that any performance hit is acceptable, if there's a switch to 
enable and disable that extra diagnostic. Oh dear, just what we need, yet 
another switch...


M.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Gary Thomas]

On 2016-06-08 11:08, Mike Looijmans wrote:

On 08-06-16 00:20, Richard Purdie wrote:

On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:

On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:

On 7 June 2016 at 17:02, Burton, Ross 
wrote:

It means the hash calculated my the bitbake master was different
to the
hash calculated when the worker started up.  This usually means
that
you're
using something like ${TIME} in the recipe but not marking it
appropriatly
so the cache ignores it.  Do you have a base-files bbappend that
writes a
timestamp?


The always wise Joshua reminds me that if your DISTRO_VERSION
contains
${DATETIME} then this happens.  If you're doing this then you'll
want to
set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from
getting
into the cache (or not put the current date/time into the distro
version).


I think we need to handle this situation better - if it's really
worth
producing an error about then it's worth producing an error message
that
people can actually understand, particularly as it's recently added
validation.


It was silently running into problems due to this all along but not
reporting it. Its now reporting it which is better than silently things
behaving strangely.

Its very hard for bitbake to know why the hashes differ, it only knows
the values afterwards and hence that they've changed, the information
about how that hash was constructed is not present in any of bitbake's
caches. That implies to have better messages we need to write out more
data.

I did add a patch to make bitbake write out data to allow
reconstruction of basehash (which is part of taskhash). Sadly the
parsing performance was diabolical (10 times slower). I think that
could perhaps be improved if the files don't require an atomic move
during creation but I haven't had time to look further at it.

So whilst I do agree, what is the price people are willing to pay to
have those better messages?


I have a build machine that every so often runs into "basehash mismatch" 
problems (but never when you want it to, such
as now), so getting some information on what might cause it would be 
"priceless". I'd happily let the machine run for 10
days straight if at the end I get a message that I can work with.

Which implies that any performance hit is acceptable, if there's a switch to 
enable and disable that extra diagnostic.
Oh dear, just what we need, yet another switch...



I wonder if it could be something as simple as an NTP time update
which happens periodically on my build machine?  Since I've only
ever seen this message _once_ after literally thousands of builds,
it is a rare bird indeed!

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Paul Eggleton]

On Tue, 07 Jun 2016 23:20:26 Richard Purdie wrote:
> On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:
> > On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:
> > > On 7 June 2016 at 17:02, Burton, Ross 
> > > wrote:
> > > > It means the hash calculated my the bitbake master was different
> > > > to the hash calculated when the worker started up.  This usually means
> > > > that you're using something like ${TIME} in the recipe but not marking 
> > > > it appropriatly so the cache ignores it.  Do you have a base-files
> > > > bbappend that writes a timestamp?
> > > 
> > > The always wise Joshua reminds me that if your DISTRO_VERSION
> > > contains ${DATETIME} then this happens.  If you're doing this then
> > > you'll want to set [vardepsexclude] on DISTRO_VERSION to stop the
> > > DATETIME from getting into the cache (or not put the current date/time
> > > into the distro version).
> > 
> > I think we need to handle this situation better - if it's really
> > worth producing an error about then it's worth producing an error message
> > that people can actually understand, particularly as it's recently added
> > validation.
> 
> It was silently running into problems due to this all along but not
> reporting it. Its now reporting it which is better than silently things
> behaving strangely.

What are the actual consequences in a situation like this where we have 
something like ${DATETIME} in another variable referenced by the task?

I haven't looked at all of the code involved (and that's probably the root of 
my problem) but I don't quite understand how this is coming about. DATE and 
TIME are supposed to be determined at the start of the build and explicitly 
passed to the worker, so they don't change during the build. What am I 
missing?
 
> Its very hard for bitbake to know why the hashes differ, it only knows
> the values afterwards and hence that they've changed, the information
> about how that hash was constructed is not present in any of bitbake's
> caches. That implies to have better messages we need to write out more
> data.
> 
> I did add a patch to make bitbake write out data to allow
> reconstruction of basehash (which is part of taskhash). Sadly the
> parsing performance was diabolical (10 times slower). I think that
> could perhaps be improved if the files don't require an atomic move
> during creation but I haven't had time to look further at it.
> 
> So whilst I do agree, what is the price people are willing to pay to
> have those better messages?

Clearly a 10x slowdown is unacceptable, hopefully we can find another way of 
dealing with this. I guess if we're able to do nothing else a brief 
explanation of what to look for (i.e. variables that might change with time) 
in the error message would be helpful, but I hope we can do better than that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Richard Purdie]

On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:
> On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:
> > On 7 June 2016 at 17:02, Burton, Ross 
> > wrote:
> > > It means the hash calculated my the bitbake master was different
> > > to the
> > > hash calculated when the worker started up.  This usually means
> > > that
> > > you're
> > > using something like ${TIME} in the recipe but not marking it
> > > appropriatly
> > > so the cache ignores it.  Do you have a base-files bbappend that
> > > writes a
> > > timestamp?
> > 
> > The always wise Joshua reminds me that if your DISTRO_VERSION
> > contains
> > ${DATETIME} then this happens.  If you're doing this then you'll
> > want to
> > set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from
> > getting
> > into the cache (or not put the current date/time into the distro
> > version).
> 
> I think we need to handle this situation better - if it's really
> worth 
> producing an error about then it's worth producing an error message
> that 
> people can actually understand, particularly as it's recently added 
> validation.

It was silently running into problems due to this all along but not
reporting it. Its now reporting it which is better than silently things
behaving strangely.

Its very hard for bitbake to know why the hashes differ, it only knows
the values afterwards and hence that they've changed, the information
about how that hash was constructed is not present in any of bitbake's
caches. That implies to have better messages we need to write out more
data.

I did add a patch to make bitbake write out data to allow
reconstruction of basehash (which is part of taskhash). Sadly the
parsing performance was diabolical (10 times slower). I think that
could perhaps be improved if the files don't require an atomic move
during creation but I haven't had time to look further at it.

So whilst I do agree, what is the price people are willing to pay to
have those better messages?

Cheers,

Richard




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Joshua G Lock]

On Tue, 2016-06-07 at 18:58 +0200, Gary Thomas wrote:
> On 2016-06-07 18:20, Burton, Ross wrote:
> > 
> > On 7 June 2016 at 17:02, Burton, Ross  > > wrote:
> > 
> > It means the hash calculated my the bitbake master was
> > different to the hash calculated when the worker started up.
> > This usually means that you're using something like ${TIME} in
> > the recipe but not marking it appropriatly so the
> > cache ignores it.  Do you have a base-files bbappend that
> > writes a timestamp?
> > 
> > 
> > The always wise Joshua reminds me that if your DISTRO_VERSION
> > contains ${DATETIME} then this happens.  If you're doing
> > this then you'll want to set [vardepsexclude] on DISTRO_VERSION to
> > stop the DATETIME from getting into the cache (or not
> > put the current date/time into the distro version).
> > 
> 
> Ah, that's probably it.  Exactly how do I set that exclusion?

Assuming DISTRO_VERSION includes DATETIME

    DISTRO_VERSION[vardepsexclude] = "DATETIME"

see for example:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/dist
ro/poky.conf#n14

Regards,

Joshua
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Paul Eggleton]

On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:
> On 7 June 2016 at 17:02, Burton, Ross  wrote:
> > It means the hash calculated my the bitbake master was different to the
> > hash calculated when the worker started up.  This usually means that
> > you're
> > using something like ${TIME} in the recipe but not marking it appropriatly
> > so the cache ignores it.  Do you have a base-files bbappend that writes a
> > timestamp?
> 
> The always wise Joshua reminds me that if your DISTRO_VERSION contains
> ${DATETIME} then this happens.  If you're doing this then you'll want to
> set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from getting
> into the cache (or not put the current date/time into the distro version).

I think we need to handle this situation better - if it's really worth 
producing an error about then it's worth producing an error message that 
people can actually understand, particularly as it's recently added 
validation.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Gary Thomas]

On 2016-06-07 18:20, Burton, Ross wrote:


On 7 June 2016 at 17:02, Burton, Ross > wrote:

It means the hash calculated my the bitbake master was different to the 
hash calculated when the worker started up.
This usually means that you're using something like ${TIME} in the recipe 
but not marking it appropriatly so the
cache ignores it.  Do you have a base-files bbappend that writes a 
timestamp?


The always wise Joshua reminds me that if your DISTRO_VERSION contains 
${DATETIME} then this happens.  If you're doing
this then you'll want to set [vardepsexclude] on DISTRO_VERSION to stop the 
DATETIME from getting into the cache (or not
put the current date/time into the distro version).



Ah, that's probably it.  Exactly how do I set that exclusion?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Gary Thomas]

On 2016-06-07 18:02, Burton, Ross wrote:


On 5 June 2016 at 17:44, Gary Thomas > wrote:

I just updated my Poky repo and did a rebuild and saw this "error"
(although it carried on with the build):
ERROR: base-files-3.0.14-r89 do_install: Taskhash mismatch 
ceb25febc6f11a5cc2b3c4a4b0b2c136 verses
44f498452dfce5875451bca66b230e31 for

/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install
ERROR: Taskhash mismatch ceb25febc6f11a5cc2b3c4a4b0b2c136 verses 
44f498452dfce5875451bca66b230e31 for

/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install

What does this mean?  Should I be worried?


It means the hash calculated my the bitbake master was different to the hash 
calculated when the worker started up.
This usually means that you're using something like ${TIME} in the recipe but 
not marking it appropriatly so the cache
ignores it.  Do you have a base-files bbappend that writes a timestamp?


Sorry, nothing like that in my layers.  Note: this only happened once,
immediately after a poky pull and the builds have been happy since.
Whatever it was only happened that one time (not that that should be
any less concerning...)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Burton, Ross]

On 7 June 2016 at 17:02, Burton, Ross  wrote:

> It means the hash calculated my the bitbake master was different to the
> hash calculated when the worker started up.  This usually means that you're
> using something like ${TIME} in the recipe but not marking it appropriatly
> so the cache ignores it.  Do you have a base-files bbappend that writes a
> timestamp?
>

The always wise Joshua reminds me that if your DISTRO_VERSION contains
${DATETIME} then this happens.  If you're doing this then you'll want to
set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from getting
into the cache (or not put the current date/time into the distro version).

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] What's this

[Gary Thomas]

I just updated my Poky repo and did a rebuild and saw this "error"
(although it carried on with the build):
ERROR: base-files-3.0.14-r89 do_install: Taskhash mismatch ceb25febc6f11a5cc2b3c4a4b0b2c136 verses 
44f498452dfce5875451bca66b230e31 for /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install
ERROR: Taskhash mismatch ceb25febc6f11a5cc2b3c4a4b0b2c136 verses 44f498452dfce5875451bca66b230e31 for 
/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install


What does this mean?  Should I be worried?

meta  = "master:04319c0340010c4e0f78cab252cfcb0ebe23ee84"

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the "standard" for adding .dts patches to a BSP layer?

[Robert P. J. Day]

On Thu, 28 Apr 2016, Gary Thomas wrote:

> On 2016-04-28 14:14, Robert P. J. Day wrote:
> >
> >looking for common practice here ... what's the canonical way
> > that one should add content to a .dts file for a new board -- all
> > at once, or broken into patches associated with corresponding .scc
> > files that come into play only if one selects that functionality?
> >
> >i ask since i'm a big fan of modularity, but that doesn't seem
> > to work very well here. if i start with a baseline .dts file, and
> > break the rest into optional patches, then based on what a
> > developer selects for his build, some of those patches simply
> > aren't going to apply very cleanly.
> >
> >it would, of course, be easier to just add everything even
> > potentially necessary to the single .dts file, since that's not
> > really adding any actual functionality, just adding more detailed
> > information about the target board (even if it's never used).
> >
> >thoughts? am i overthinking this?
>
> One common way is to have a .dts (or .dtsi) file that includes all
> of the sections you might want, but leave them disabled, hence not
> changing the actual setup.  Then add snippets (via .scc or patch)
> that enable the sections.  This is how the i.MX6 space
> (FreeScale/NXP boards and products) is managed.

  i'm not sure that's a total solution, for the following general
reason, which might be completely idiotic if i'm misunderstanding
something.

  if i have *any* text file for which i can apply some subset of
possible changes, and those changes are geographically close to each
other, it seems possible that i'll have conflicting patches trying to
be applied next to each other, no? i tried something like that a while
back, and that's exactly what happened.

  as a trivial example (and, again, maybe i'm being clueless about
this and missing an easy solution), say i have two possible lines i
can add to the end of a text file via patches -- patch 1 appends the
line:

  #include feature1

while patch 2 appends the line

  #include feature2

won't i run into trouble based on whether i apply one patch, or the
other, or both? certainly, in some circumstances, *some* patch
application is going to fail. this seems like a simple example of the
more general issue -- it's probably a bad idea to allow the
conditional application of a set of patches to the same text file.

  the simplest solution i've come up with to retain some semblance of
modularity is to have a base .dts file, then a number of specific
.dtsi files, and just flat out include those .dtsi files, whether i
need them or not. or am i missing something obvious?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the "standard" for adding .dts patches to a BSP layer?

[Gary Thomas]

On 2016-04-28 14:14, Robert P. J. Day wrote:


   looking for common practice here ... what's the canonical way that
one should add content to a .dts file for a new board -- all at once,
or broken into patches associated with corresponding .scc files that
come into play only if one selects that functionality?

   i ask since i'm a big fan of modularity, but that doesn't seem to
work very well here. if i start with a baseline .dts file, and break
the rest into optional patches, then based on what a developer selects
for his build, some of those patches simply aren't going to apply very
cleanly.

   it would, of course, be easier to just add everything even
potentially necessary to the single .dts file, since that's not really
adding any actual functionality, just adding more detailed information
about the target board (even if it's never used).

   thoughts? am i overthinking this?


One common way is to have a .dts (or .dtsi) file that includes all
of the sections you might want, but leave them disabled, hence not
changing the actual setup.  Then add snippets (via .scc or patch)
that enable the sections.  This is how the i.MX6 space (FreeScale/NXP
boards and products) is managed.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the "standard" for adding .dts patches to a BSP layer?

[Robert P. J. Day]

  looking for common practice here ... what's the canonical way that
one should add content to a .dts file for a new board -- all at once,
or broken into patches associated with corresponding .scc files that
come into play only if one selects that functionality?

  i ask since i'm a big fan of modularity, but that doesn't seem to
work very well here. if i start with a baseline .dts file, and break
the rest into optional patches, then based on what a developer selects
for his build, some of those patches simply aren't going to apply very
cleanly.

  it would, of course, be easier to just add everything even
potentially necessary to the single .dts file, since that's not really
adding any actual functionality, just adding more detailed information
about the target board (even if it's never used).

  thoughts? am i overthinking this?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the recommended way to extend FILESOVERRIDES to add a powerpc CPU?

[Robert P. J. Day]

  currently working on a layer for building for three powerpc-based  
target boards:


  * mach1 (8260-based)
  * mach2, mach3 (8360-based)

i wanted to use FILESOVERRIDES to be able to distinguish between patches
that were:

  * machine-specific
  * CPU-specific (8260 or 8360)
  * common across all powerpc targets

however, a quick check shows me that TRANSLATED_TARGET_ARCH contains
only "powerpc", so that FILESOVERRIDES starts with:

  "powerpc:machine-name:..."

in short, with the *default* powerpc recipes, i can't define patches
that are specific to a processor, only to powerpc (redundant) or to
only a single machine.

  i can, of course, hack either of those two variables and cram an extra
field in there, but is there a *recommended* way to do this so that
i don't feel i have to take a shower afterwards?

rday


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's mounting this partition?

[Fred Ollinger]

If you have a sda1 drive, you can do:

udevadm test /sys/class/block/sda1

to get debug info.

From: yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> on behalf 
of Paul D. DeRocco <pdero...@ix.netcom.com>
Sent: Sunday, September 27, 2015 2:52 AM
To: 'Khem Raj'
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] What's mounting this partition?

> From: Khem Raj [mailto:raj.k...@gmail.com]
>
> are you installing udev-extraconf into image? IIRC that was
> doing it in my cases some time ago.

That adds some rules to /etc/udev/rules.d, including automounting. I had
that in there for a day or so, because I also need to access an external
flash drive sometimes, but it had some insoluble issues, so I took it out
again. So none of those rules are present now, nor is the mount.sh script.
There are a bunch more rules in /lib/udev/rules.d, but none have anything
to do with mounting, as far as I can see.

I wish there was a way I could see this mysterious mounting happen.
Nothing shows up in dmesg or in journalctl.

--

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's mounting this partition?

[Paul D. DeRocco]

> From: Khem Raj [mailto:raj.k...@gmail.com] 
> 
> are you installing udev-extraconf into image? IIRC that was 
> doing it in my cases some time ago.

That adds some rules to /etc/udev/rules.d, including automounting. I had
that in there for a day or so, because I also need to access an external
flash drive sometimes, but it had some insoluble issues, so I took it out
again. So none of those rules are present now, nor is the mount.sh script.
There are a bunch more rules in /lib/udev/rules.d, but none have anything
to do with mounting, as far as I can see.

I wish there was a way I could see this mysterious mounting happen.
Nothing shows up in dmesg or in journalctl.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] What's mounting this partition?

[Paul D. DeRocco]

My x86 system, built with Yocto Fido, boots from /dev/sda2 on a USB flash
drive. There's another partition on /dev/sda1 which I wish to mount with a
systemd mount unit, or with a line in /etc/fstab. But either way is
failing because /dev/sda1 is already mounted on /media/sda1. Lennart over
at the systemd list suggested it might be udisks doing this, but I don't
see any files matching *udisks* anywhere in my file system, or even in my
build tree.

An older version of this system, built two years ago with Dylan, doesn't
have this problem. Nothing relevant changed in my meta-data, so somewhere
else in this gigantic universe something has changed. Does anyone know
what bit of software would be responsible for automounting my /dev/sda1
partition, which is not my root file system, and doing so before fstab or
systemd mounts are processed?

Also, when /dev/sda2 (my root file system) is mounted, it gets certain
default options. Is there a way to modify these options? I'd like to
include noatime, to avoid needless writes to my flash drive.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's mounting this partition?

[Khem Raj]

> On Sep 26, 2015, at 10:39 AM, Paul D. DeRocco  wrote:
> 
> My x86 system, built with Yocto Fido, boots from /dev/sda2 on a USB flash
> drive. There's another partition on /dev/sda1 which I wish to mount with a
> systemd mount unit, or with a line in /etc/fstab. But either way is
> failing because /dev/sda1 is already mounted on /media/sda1. Lennart over
> at the systemd list suggested it might be udisks doing this, but I don't
> see any files matching *udisks* anywhere in my file system, or even in my
> build tree.
> 
> An older version of this system, built two years ago with Dylan, doesn't
> have this problem. Nothing relevant changed in my meta-data, so somewhere
> else in this gigantic universe something has changed. Does anyone know
> what bit of software would be responsible for automounting my /dev/sda1
> partition, which is not my root file system, and doing so before fstab or
> systemd mounts are processed?

are you installing udev-extraconf into image? IIRC that was doing it in my cases
some time ago.

> 
> Also, when /dev/sda2 (my root file system) is mounted, it gets certain
> default options. Is there a way to modify these options? I'd like to
> include noatime, to avoid needless writes to my flash drive.
> 
> --
> 
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the difference between meta-openembedded/meta-oe and meta-oe/meta-oe

[Philip Balister]

On 04/05/2015 06:46 PM, Ken Davis wrote:
 I'm soo confused.
 
 what's the difference between meta-openembedded/meta-oe and
 meta-oe/meta-oe?
 

Nothing. The meta-oe (and oe-core) repos are deprecated and will be
removed soon.

Make sure you use meta-openembedded and openembedded-core checkouts and
refer to them in manifests and scripts.

Philip
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the difference between meta-openembedded/meta-oe and meta-oe/meta-oe

[Ken Davis]

I'm soo confused.

what's the difference between meta-openembedded/meta-oe and meta-oe/meta-oe?

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the rule on specifying layer dependencies?

[Khem Raj]

On Tue, Oct 22, 2013 at 5:17 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:

   long story short, we have this:

 ./meta-openembedded/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
 ./meta-arago/meta-arago-extras/recipes-core/jpeg/libjpeg-turbo_svn.bbappend

 however, the meta-arago-extras layer is not defined to depend on
 meta-openembedded. should it?

Well meta-arago-extras README says

URI: git://git.openembedded.org/meta-openembedded
branch: dylan
revision: HEAD
layers: meta-oe, toolchain-layers, meta-networking



 rday

 --

 
 Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

 Twitter:   http://twitter.com/rpjday
 LinkedIn:   http://ca.linkedin.com/in/rpjday
 
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the rule on specifying layer dependencies?

[Robert P. J. Day]

  long story short, we have this:

./meta-openembedded/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
./meta-arago/meta-arago-extras/recipes-core/jpeg/libjpeg-turbo_svn.bbappend

however, the meta-arago-extras layer is not defined to depend on
meta-openembedded. should it?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the most reliable way to build images for beaglebone black?

[Robert P. J. Day]

  i know there are two layers supporting the BBB -- meta-beagleboard
and meta-ti. for building a simple, bootable system for a BBB for
classroom purposes, can anyone recommend one over the other? i realize
that's kind of an open-ended question, but i'm after simplicity and a
minimum of hacking to get something that just boots to the command
line. thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Robert P. J. Day]

On Mon, 8 Apr 2013, Bruce Ashfield wrote:

 On 13-04-08 5:59 PM, Robert P. J. Day wrote:
 
 other than the canonical routerstation pro in the meta-yocto-bsp
  layer, is there any serious work being put into MIPS machines?  a
  quick google didn't seem to find anything, and the rs pro itself was
  end-of-lifed a while back (as i recall), so is there something else if
  one wants to use yocto on a MIPS dev kit?

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

 MIPS suggested refresh: http://www.ubnt.com/edgemax

 .. but I've yet to complete the due diligence on seeing if I can
 actually purchase one :) That's going to happen shortly after yocto
 1.4 completes.

  i ordered one last night -- total $159.79 (CAD), including
shipping. it took a couple minutes to understand what i was reading
here:

http://ubnt.ca/en/8-edgemax

  edgemax is simply the generic name for the platform -- the
product itself is the edgerouter lite 3 (or erlite3 as they like to
abbreviate it):

http://ubnt.ca/en/edgemax/61-edgemax.html

so the next shipment comes in on friday to ubnt.ca, at which point
they'll ship one to me.  the admin claims that they're getting in only
a very limited number of them on friday, so you can take that with
whatever grain of salt you feel is appropriate, but i wanted one.

rday

p.s. i was interested in a newer MIPS box as a former student of mine
dropped me a note and told me his corp was planning a new product
based on the MIPS SEAD-3:

http://www.mips.com/products/development-kits/mips-sead-3/

but that thing is crazy expensive ($2K USD).

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Robert P. J. Day]

On Mon, 8 Apr 2013, Bruce Ashfield wrote:

 On 13-04-08 5:59 PM, Robert P. J. Day wrote:
 
 other than the canonical routerstation pro in the meta-yocto-bsp
  layer, is there any serious work being put into MIPS machines?  a
  quick google didn't seem to find anything, and the rs pro itself was
  end-of-lifed a while back (as i recall), so is there something else if
  one wants to use yocto on a MIPS dev kit?

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

 MIPS suggested refresh: http://www.ubnt.com/edgemax

 .. but I've yet to complete the due diligence on seeing if I can
 actually purchase one :) That's going to happen shortly after yocto
 1.4 completes.

  one final addition to the picture, the ERlite 3 seem to have some
real horsepower, according to the specs:

  http://www.ubnt.com/edgemax#EdgeMAXhardware

* (Layer-3 base forwarding) 1,000,000 pps for 64-byte packets. Line
rate (3 Gbps) across all three ports for 512-byte packets and higher

* Dual-core MIPS64 processor with hardware acceleration for packet
processing and encryption/decryption

* 3 RJ-45 Gigabit Ethernet ports

* 512 MB DDR2 RAM

* 2 GB onboard flash storage

* 1 RJ-45 serial console port

  the full datasheet:

http://www.ubnt.com/downloads/datasheets/edgemax/EdgeRouter_Lite_DS.pdf

at $159 (CAD) which includes shipping, that strikes me as eminently
affordable.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Bruce Ashfield]

On 13-04-09 10:15 AM, Robert P. J. Day wrote:

On Mon, 8 Apr 2013, Bruce Ashfield wrote:


On 13-04-08 5:59 PM, Robert P. J. Day wrote:


other than the canonical routerstation pro in the meta-yocto-bsp
layer, is there any serious work being put into MIPS machines?  a
quick google didn't seem to find anything, and the rs pro itself was
end-of-lifed a while back (as i recall), so is there something else if
one wants to use yocto on a MIPS dev kit?


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

MIPS suggested refresh: http://www.ubnt.com/edgemax

.. but I've yet to complete the due diligence on seeing if I can
actually purchase one :) That's going to happen shortly after yocto
1.4 completes.


   one final addition to the picture, the ERlite 3 seem to have some
real horsepower, according to the specs:

   http://www.ubnt.com/edgemax#EdgeMAXhardware

* (Layer-3 base forwarding) 1,000,000 pps for 64-byte packets. Line
rate (3 Gbps) across all three ports for 512-byte packets and higher

* Dual-core MIPS64 processor with hardware acceleration for packet
processing and encryption/decryption

* 3 RJ-45 Gigabit Ethernet ports

* 512 MB DDR2 RAM

* 2 GB onboard flash storage

* 1 RJ-45 serial console port

   the full datasheet:

http://www.ubnt.com/downloads/datasheets/edgemax/EdgeRouter_Lite_DS.pdf

at $159 (CAD) which includes shipping, that strikes me as eminently
affordable.


Indeed. And thanks for digging into this more, that's the leg work that
I was starting for 1.5, and now it is largely done. Having a new h/w
reference for MIPS has been near the top of the list for some time.

Bruce



rday



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[William Mills]

On 04/09/2013 07:27 AM, Robert P. J. Day wrote:

On Mon, 8 Apr 2013, Bruce Ashfield wrote:


On 13-04-08 5:59 PM, Robert P. J. Day wrote:


other than the canonical routerstation pro in the meta-yocto-bsp
layer, is there any serious work being put into MIPS machines?  a
quick google didn't seem to find anything, and the rs pro itself was
end-of-lifed a while back (as i recall), so is there something else if
one wants to use yocto on a MIPS dev kit?


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

MIPS suggested refresh: http://www.ubnt.com/edgemax

.. but I've yet to complete the due diligence on seeing if I can
actually purchase one :) That's going to happen shortly after yocto
1.4 completes.


   i ordered one last night -- total $159.79 (CAD), including
shipping. it took a couple minutes to understand what i was reading
here:


I ordered one just now from the N.C. distributor.  They did not say 
anything about back order so I expect it in a couple of days.


(And no this does not mean anything wrt TI.  It is for my own 
intellectual curiosity.)




http://ubnt.ca/en/8-edgemax

   edgemax is simply the generic name for the platform -- the
product itself is the edgerouter lite 3 (or erlite3 as they like to
abbreviate it):

http://ubnt.ca/en/edgemax/61-edgemax.html

so the next shipment comes in on friday to ubnt.ca, at which point
they'll ship one to me.  the admin claims that they're getting in only
a very limited number of them on friday, so you can take that with
whatever grain of salt you feel is appropriate, but i wanted one.

rday

p.s. i was interested in a newer MIPS box as a former student of mine
dropped me a note and told me his corp was planning a new product
based on the MIPS SEAD-3:

http://www.mips.com/products/development-kits/mips-sead-3/

but that thing is crazy expensive ($2K USD).


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Robert P. J. Day]

  other than the canonical routerstation pro in the meta-yocto-bsp
layer, is there any serious work being put into MIPS machines?  a
quick google didn't seem to find anything, and the rs pro itself was
end-of-lifed a while back (as i recall), so is there something else if
one wants to use yocto on a MIPS dev kit?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Bruce Ashfield]

On 13-04-08 5:59 PM, Robert P. J. Day wrote:


   other than the canonical routerstation pro in the meta-yocto-bsp
layer, is there any serious work being put into MIPS machines?  a
quick google didn't seem to find anything, and the rs pro itself was
end-of-lifed a while back (as i recall), so is there something else if
one wants to use yocto on a MIPS dev kit?


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

MIPS suggested refresh: http://www.ubnt.com/edgemax

.. but I've yet to complete the due diligence on seeing if I can
actually purchase one :) That's going to happen shortly after yocto
1.4 completes.

Bruce



rday



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Robert P. J. Day]

On Mon, 8 Apr 2013, Bruce Ashfield wrote:

 On 13-04-08 5:59 PM, Robert P. J. Day wrote:
 
 other than the canonical routerstation pro in the meta-yocto-bsp
  layer, is there any serious work being put into MIPS machines?  a
  quick google didn't seem to find anything, and the rs pro itself was
  end-of-lifed a while back (as i recall), so is there something else if
  one wants to use yocto on a MIPS dev kit?

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

 MIPS suggested refresh: http://www.ubnt.com/edgemax

 .. but I've yet to complete the due diligence on seeing if I can
 actually purchase one :) That's going to happen shortly after yocto
 1.4 completes.

  it would appear there's a canadian branch of ubiquiti:

http://ubnt.ca/en/8-edgemax

but based on what i remember about ubiquiti, it's *excruciating* to
try to figure out how to buy anything from them.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the situation with MIPS support/BSPs/dev kits in yocto?

[Robert P. J. Day]

On Mon, 8 Apr 2013, Bruce Ashfield wrote:

 On 13-04-08 5:59 PM, Robert P. J. Day wrote:
 
 other than the canonical routerstation pro in the meta-yocto-bsp
  layer, is there any serious work being put into MIPS machines?  a
  quick google didn't seem to find anything, and the rs pro itself was
  end-of-lifed a while back (as i recall), so is there something else if
  one wants to use yocto on a MIPS dev kit?

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

 MIPS suggested refresh: http://www.ubnt.com/edgemax

 .. but I've yet to complete the due diligence on seeing if I can
 actually purchase one :) That's going to happen shortly after yocto
 1.4 completes.

  ok, based on a bit more reading, it *seems* that the phrase
edgemax refers to a platform, while an actual router based on that
platform might be the edgerouter lite:

http://ubnt.ca/en/edgemax/61-edgemax.html

  does that make sense? if you look at this page:

http://ubnt.ca/en/8-edgemax

it seems that the edgerouter lite is the single actual product in that
category, and it appears to be buyable online.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the best distro to pick for adding packages to yocto

[Tim Coote]

Hullo
I'm trying to add a package to yocto (an AMQP implementation). There are 
various packaged versions, so I started with the one that I'm most familiar 
(RH). However, it's pretty clear that yocto's not based on that as the 
initscripts are totally different and missing the framework (there isn't even a 
/etc/rc.d/init.d, although it looks like there used to be).

What's the best starting point for picking a prepackaged version for a distro? 
debian? suse?

thanks
Tim
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the best distro to pick for adding packages to yocto

[Burton, Ross]

On 31 January 2013 11:16, Tim Coote tim+yoctoproject@coote.org wrote:
 Hullo
 I'm trying to add a package to yocto (an AMQP implementation). There are 
 various packaged versions, so I started with the one that I'm most familiar 
 (RH). However, it's pretty clear that yocto's not based on that as the 
 initscripts are totally different and missing the framework (there isn't even 
 a /etc/rc.d/init.d, although it looks like there used to be).

 What's the best starting point for picking a prepackaged version for a 
 distro? debian? suse?

Historically Debian is fairly close, but these days that isn't really
true.  It's probably best to look at an existing init script to see
*what* needs to be done, and then copy the style of existing scripts
in Yocto for *how* to do it.

Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the rationale for kern-tools-native bbappend in poky-extras?

[Robert P. J. Day]

 i just noticed, in the poky-extras layer,
kern-tools-native_git.bbappend, which describes itself as for local
kern-tools work.

  is there a use case for this?  oe-core already supplies
kern-tools-native, and that bbappend appears to simply let the
developer work with the head of kern-tools rather than a fixed SRCREV.

  so is it just providing the ability to work with the dev source for
developers who want the bleeding edge?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the rationale for kern-tools-native bbappend in poky-extras?

[Bruce Ashfield]

On Mon, Dec 24, 2012 at 12:28 PM, Robert P. J. Day rpj...@crashcourse.cawrote:


  i just noticed, in the poky-extras layer,
 kern-tools-native_git.bbappend, which describes itself as for local
 kern-tools work.

   is there a use case for this?  oe-core already supplies
 kern-tools-native, and that bbappend appears to simply let the
 developer work with the head of kern-tools rather than a fixed SRCREV.

   so is it just providing the ability to work with the dev source for
 developers who want the bleeding edge?


Pretty much, it provides the ability to point at a local git tree, and
turns on
AUTOREV. Something that I always use, and something that anyone else
doing local work could use as well (not that they can't just create their
own
bbappend to do the same thing, but it doesn't hurt to have it sitting
there).

Cheers,

Bruce



 rday

 --

 
 Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

 Twitter:   http://twitter.com/rpjday
 LinkedIn:   http://ca.linkedin.com/in/rpjday
 
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto




-- 
Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the preferred way of creating images for a classic beagle rev C4?

[Tomas Frydrych]

Hi,

On 08/07/12 19:21, Robert P. J. Day wrote:
   is it adequate to use the canonical beagleboard support in yocto, or
 should i take advantage of the developments in the meta-ti layer?
 this is for a training course so i don't need production-level
 reliability so much as i want access to as many features as i can get
 for educational purposes.  thanks.

Yocto alone should give you working Sato images; I am fairly certain
that works with Denzil.

If you want/need stuff like accelerated graphics, you have to use
meta-ti, but meta-ti does not play very well with Yocto, so expect to
have to do some tweaking to get things to build. Beyond that, my
experience is that actually getting the meta-ti accelerated video work
is a rather time consuming miss and hit exercise without any guaranteed
results at the end -- if you do not need this for your purposes, then
I'd say don't bother.

Tomas
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the preferred way of creating images for a classic beagle rev C4?

[Robert P. J. Day]

  is it adequate to use the canonical beagleboard support in yocto, or
should i take advantage of the developments in the meta-ti layer?
this is for a training course so i don't need production-level
reliability so much as i want access to as many features as i can get
for educational purposes.  thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Darren Hart]

On 10/31/2011 10:39 AM, Gary Thomas wrote:
 On 2011-10-31 11:25, Robert P. J. Day wrote:
 On Mon, 31 Oct 2011, Mark Hatle wrote:

 On 10/30/11 11:15 AM, Robert P. J. Day wrote:
 On Sun, 30 Oct 2011, Christian Gagneraud wrote:

 On 30/10/11 15:32, Robert P. J. Day wrote:

 all the docs recommend twice the number of cores (AFAICT), yet the
 template local.conf file suggests that, for a quad core, the value of
 4 would be appropriate.  shouldn't that say 8?  same with
 PARALLEL_MAKE?

 Hi Robert,

 The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
 and x1.5 for PARALLEL_MAKE.

if that's the case, anyone object to my submitting a patch to
 update local.conf.sample appropriately?

 rday


 I agree the manual and local.conf files should match.  The issue
 seems to be that the perfect values are subjective.  Things like
 memory, disk speed, chipset latency, and of course processor
 speed/cores all affect the optimal setting. But we do need a
 consistent rule of thumb..  I myself usually use x2 for both THREADS
 and MAKE.

that's what i would normally use, assuming that having an overly
 high value for either of those settings can't possibly hurt.  if
 that's the consensus, i can adjust the references to say 2x everywhere
 that i know of.  just let me know.
 
 Look back in the archives - I think it was Richard that did a fairly
 extensive study of this and he (whoever it was) found that there were
 saturation points and trying to get beyond them had a negative impact.

2x on each works well up to about 12 in my experience. Richard has found
benefits using 24 on a similar system with more memory. However, if you
aren't building on a monster machine, then 2x serves as a reasonable
rule of thumb.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Robert P. J. Day]

On Thu, 3 Nov 2011, Darren Hart wrote:



 On 10/31/2011 10:39 AM, Gary Thomas wrote:
  On 2011-10-31 11:25, Robert P. J. Day wrote:
  On Mon, 31 Oct 2011, Mark Hatle wrote:
 
  On 10/30/11 11:15 AM, Robert P. J. Day wrote:
  On Sun, 30 Oct 2011, Christian Gagneraud wrote:
 
  On 30/10/11 15:32, Robert P. J. Day wrote:
 
  all the docs recommend twice the number of cores (AFAICT), yet the
  template local.conf file suggests that, for a quad core, the value of
  4 would be appropriate.  shouldn't that say 8?  same with
  PARALLEL_MAKE?
 
  Hi Robert,
 
  The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
  and x1.5 for PARALLEL_MAKE.
 
 if that's the case, anyone object to my submitting a patch to
  update local.conf.sample appropriately?
 
  rday
 
 
  I agree the manual and local.conf files should match.  The issue
  seems to be that the perfect values are subjective.  Things like
  memory, disk speed, chipset latency, and of course processor
  speed/cores all affect the optimal setting. But we do need a
  consistent rule of thumb..  I myself usually use x2 for both THREADS
  and MAKE.
 
 that's what i would normally use, assuming that having an overly
  high value for either of those settings can't possibly hurt.  if
  that's the consensus, i can adjust the references to say 2x everywhere
  that i know of.  just let me know.
 
  Look back in the archives - I think it was Richard that did a fairly
  extensive study of this and he (whoever it was) found that there were
  saturation points and trying to get beyond them had a negative impact.

 2x on each works well up to about 12 in my experience. Richard has found
 benefits using 24 on a similar system with more memory. However, if you
 aren't building on a monster machine, then 2x serves as a reasonable
 rule of thumb.

  since i vaguely recall that i was the one who asked about this, i
can submit a patch for this unless someone else already wants to.  i
can see that the places to change would be in some of the docs, as
well as the comment in local.conf.sample.

  anyone else want to take care of that?  anyone?  bueller?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Mark Hatle]

On 10/30/11 11:15 AM, Robert P. J. Day wrote:
 On Sun, 30 Oct 2011, Christian Gagneraud wrote:
 
 On 30/10/11 15:32, Robert P. J. Day wrote:

all the docs recommend twice the number of cores (AFAICT), yet the
 template local.conf file suggests that, for a quad core, the value of
 4 would be appropriate.  shouldn't that say 8?  same with
 PARALLEL_MAKE?

 Hi Robert,

 The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
 and x1.5 for PARALLEL_MAKE.
 
   if that's the case, anyone object to my submitting a patch to
 update local.conf.sample appropriately?
 
 rday
 

I agree the manual and local.conf files should match.  The issue seems to be
that the perfect values are subjective.  Things like memory, disk speed, chipset
latency, and of course processor speed/cores all affect the optimal setting.
But we do need a consistent rule of thumb..  I myself usually use x2 for both
THREADS and MAKE.

--Mark
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] what's the proper value for BB_NUMBER_THREADS?

[Robert P. J. Day]

  all the docs recommend twice the number of cores (AFAICT), yet the
template local.conf file suggests that, for a quad core, the value of
4 would be appropriate.  shouldn't that say 8?  same with
PARALLEL_MAKE?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Christian Gagneraud]

On 30/10/11 15:32, Robert P. J. Day wrote:


   all the docs recommend twice the number of cores (AFAICT), yet the
template local.conf file suggests that, for a quad core, the value of
4 would be appropriate.  shouldn't that say 8?  same with
PARALLEL_MAKE?


Hi Robert,

The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS, and 
x1.5 for PARALLEL_MAKE.


Chris




rday




--
Chris
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Robert P. J. Day]

On Sun, 30 Oct 2011, Christian Gagneraud wrote:

 On 30/10/11 15:32, Robert P. J. Day wrote:
 
 all the docs recommend twice the number of cores (AFAICT), yet the
  template local.conf file suggests that, for a quad core, the value of
  4 would be appropriate.  shouldn't that say 8?  same with
  PARALLEL_MAKE?

 Hi Robert,

 The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
 and x1.5 for PARALLEL_MAKE.

  if that's the case, anyone object to my submitting a patch to
update local.conf.sample appropriately?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] What's the purpose of BDIR in oe-buildenv-internal?

[Robert P. J. Day]

  prepping to give a yocto talk to my local (ottawa) LUG next week, and
was reviewing the logic of the setup starting with oe-init-build-env,
and noticed in scripts/oe-buildenv-internal a test of the variable
BDIR for the name of the build directory.  but there's no mention of
that variable in the calling oe-init-build-env, and i see no mention
of it in the intro-level docs.

  clearly, one could use that shell env variable if one wanted to name
the build directory to be used, but given that there's absolutely no
explanation of it anywhere for a new user, what exactly is its purpose?

rday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's the purpose of BDIR in oe-buildenv-internal?

[Scott Garman]

On 10/27/2011 01:27 PM, Robert P. J. Day wrote:

prepping to give a yocto talk to my local (ottawa) LUG next week, and
was reviewing the logic of the setup starting with oe-init-build-env,
and noticed in scripts/oe-buildenv-internal a test of the variable
BDIR for the name of the build directory. but there's no mention of
that variable in the calling oe-init-build-env, and i see no mention
of it in the intro-level docs.

clearly, one could use that shell env variable if one wanted to name
the build directory to be used, but given that there's absolutely no
explanation of it anywhere for a new user, what exactly is its purpose?

rday


This allows you to specify a build directory that lives elsewhere on 
your filesystem, rather than in poky/build. This is handy in case you 
want to keep the build system source tree pristine.


Simply source the build init script with the desired build directory as 
an argument. I'm quite sure we have this documented, although BDIR isn't 
explicitly mentioned.


Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's the purpose of BDIR in oe-buildenv-internal?

[Robert P. J. Day]

On Thu, 27 Oct 2011, Scott Garman wrote:

 On 10/27/2011 01:27 PM, Robert P. J. Day wrote:
  prepping to give a yocto talk to my local (ottawa) LUG next week,
  and was reviewing the logic of the setup starting with
  oe-init-build-env, and noticed in scripts/oe-buildenv-internal a
  test of the variable BDIR for the name of the build directory. but
  there's no mention of that variable in the calling
  oe-init-build-env, and i see no mention of it in the intro-level
  docs.
 
  clearly, one could use that shell env variable if one wanted to
  name the build directory to be used, but given that there's
  absolutely no explanation of it anywhere for a new user, what
  exactly is its purpose?

 This allows you to specify a build directory that lives elsewhere on
 your filesystem, rather than in poky/build. This is handy in case
 you want to keep the build system source tree pristine.

 Simply source the build init script with the desired build directory
 as an argument. I'm quite sure we have this documented, although
 BDIR isn't explicitly mentioned.

  that's the point i was raising -- that variable's value is obvious,
it's just not described anywhere i noticed.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto