Date   

Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Robert P. J. Day
 

On Tue, 20 Nov 2012, Gary Thomas wrote:

On 2012-11-20 14:08, Robert P. J. Day wrote:
On Tue, 20 Nov 2012, Tom Zanussi wrote:

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s
i can't explain it -- i've yet to have a successful clone from that
URL. hangs partway through every time.
Maybe it's a routing thing - where are you located?

n.b. it just worked for me - in about the same <10 seconds
left where i was, tried again sitting at the bar with a pint of
dutch pilsner, and it worked fine. i'm sure it's the pilsner.

rday

--

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

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


Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Gary Thomas
 

On 2012-11-20 14:08, Robert P. J. Day wrote:
On Tue, 20 Nov 2012, Tom Zanussi wrote:

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s
i can't explain it -- i've yet to have a successful clone from that
URL. hangs partway through every time.
Maybe it's a routing thing - where are you located?

n.b. it just worked for me - in about the same <10 seconds

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Robert P. J. Day
 

On Tue, 20 Nov 2012, Tom Zanussi wrote:

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s
i can't explain it -- i've yet to have a successful clone from that
URL. hangs partway through every time.

rday

--

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

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


Re: [meta-baryon][PATCH 1/3] packagegroup-core-tools: exclude packages that depend on x11

kevin.strasser@...
 

On 20 November 2012 14:39, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

This would work, but in this instance I think it would be better if we
fixed
the packagegroup-core-tools-* recipes in OE-Core so that the items that
require X11 are only included when x11 is in DISTRO_FEATURES, rather
than
making the change here.
Isn't this what Jack Mitchell's commit (poky
627fd60c8c01bbc14ad375f6aa195469eab73d86) did, which make sysprof
optional on X11?

Ross
Ah, I was building against danny. That patch should fix
packagegroup-core-tools-profile, but packagegroup-core-tools-testapps
looks like it still always includes packages that depend on X11.

-Kevin


Re: is anyone getting pathetic git download from the new kmod SRC_URI?

Tom Zanussi <tom.zanussi@...>
 

On Tue, 2012-11-20 at 15:27 -0500, Robert P. J. Day wrote:
maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?
No problems here:

[trz@empanada tmp]$ time git clone git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Cloning into 'kmod'...
remote: Counting objects: 4003, done.
remote: Compressing objects: 100% (1599/1599), done.
remote: Total 4003 (delta 2811), reused 3196 (delta 2264)
Receiving objects: 100% (4003/4003), 4.59 MiB | 850 KiB/s, done.
Resolving deltas: 100% (2811/2811), done.

real 0m7.183s
user 0m0.361s
sys 0m0.429s

Tom

rday


is anyone getting pathetic git download from the new kmod SRC_URI?

Robert P. J. Day
 

maybe it's something i'm doing, but oe-core just changed the SRC_URI
for kmod to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git,
and the response from the URL couldn't suck any worse than if it
sucked totally. i've yet to get a successful clone.

thoughts? is that working fine for others?

rday

--

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

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


Forcing native binaries to build as 32-bit on a 64-bit host OS?

Jerrod Peach <peachj@...>
 

All,

My company has traditionally built all their code on 32-bit systems for 32-bit target architectures.  We're now trying to move our build hosts to 64-bit OSes, but that's presenting us with a bit of a problem: some non-trivial number of native packages don't want to properly build 64-bit binaries.    Rather than fix all those issues right now, we'd like to build everything as a 32-bit binary on a 64-bit OS.  The problem is, I'm not sure how I'd go about forcing that to happen.  Is there some simple mechanism I can use to force all native packages to build as 32-bit on a 64-bit system?

Kind regards,

Jerrod


Re: updated wiki page for using yocto to build for beagle xM (rev C)

Tim Bird <tim.bird@...>
 

On 11/20/2012 05:13 AM, Robert P. J. Day wrote:

as part of some intro pages i'm going to be using in the future for
teaching yocto, i updated one of my wiki pages this morning for using
yocto to build and boot on a beagle xM. nothing profound, just a
verified recipe that should simply work for anyone:

http://www.crashcourse.ca/wiki/index.php/Yocto_Project_Quick_Start

feedback welcome ... i updated it while not having had enough sleep
so i fully expect it could use some polishing. i just wanted to keep
it simple.
It looks very useful. I put a link to it from my elinux page on Yocto.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Re: Need for offline binary configuration

David Stewart
 

There are a ton of interesting interactions here with other efforts -
please review and comment.


On 11/20/12 7:09 AM, "Venkata ramana gollamudi"
<ramana.gollamudi@huawei.com> wrote:

Poky allows to build custom Linux for you, but we have cases where the
post build customization is required, like user-addition, network
configuration, service control. Even selecting the required packages can
be a post build activity.

The current model requires the image to be rebuilt to support these
configuration.
Offline Configuration tool (OCT), which allows a binary image
customization before making a final target image. This case will be more
evident in larger companies, where platform teams, product teams ,
application teams are distributed and Linux build from source will be
owned and lab tested by a single team, like platform team. Other teams
just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252
I can certainly see how something like this would be a valuable addition
to the workflow, particularly at large organizations.

Of course, you could conceive of all of these things being configured in a
layer as well, but would require another bitbake run. I think you are
suggesting something separate from bitbake, and a lot more graphical /
interactive.


OCT should work on the binary pool of compiled packages generated from
poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages into
final target image.
b) Provision to select external binary packages like ADT compiled
applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model,
following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and Hob
can work on this package pool to select packages, configure and generate
image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without build
options but only with binary package selection. Configuration GUI needs
to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and
overall organization as they will be intended for different users.
2) Binary package pool can be a minimal/partial sstate-cache, as complete
sstate-cache is quite big and not required for product teams as they are
not expected to build but just need to select and configure.
I think it is sufficient to keep the minimal binaries from
sstate-cache which are required to execute image.bbclass, do_rootfs task
to generate image.
3) Along with specific configuration UI implementation, a generic
configuration model similar to kernel kconfig and menuconfig can be
considered, in cases where more detailed offline configurations is
required like detailed security configuration.

Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Need for offline binary configuration

Bruce Ashfield <bruce.ashfield@...>
 

On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:
Poky allows to build custom Linux for you, but we have cases where the post build customization is required, like user-addition, network configuration, service control. Even selecting the required packages can be a post build activity.

The current model requires the image to be rebuilt to support these configuration.
Offline Configuration tool (OCT), which allows a binary image customization before making a final target image. This case will be more evident in larger companies, where platform teams, product teams , application teams are distributed and Linux build from source will be owned and lab tested by a single team, like platform team. Other teams just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages into final target image.
b) Provision to select external binary packages like ADT compiled applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model, following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and Hob can work on this package pool to select packages, configure and generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without build options but only with binary package selection. Configuration GUI needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and overall organization as they will be intended for different users.
Is there some overlap between this point and the other ongoing discussions
about image construction, deployment and package management ?

i.e. this thread:

[OE-core] RFC: OE-Core image creation and deployment

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026938.html

These may already be coordinated, but I do see some common threads and
it would be nice to make sure everything will work together and that we
aren't duplicating effort!

Cheers,

Bruce


2) Binary package pool can be a minimal/partial sstate-cache, as complete sstate-cache is quite big and not required for product teams as they are not expected to build but just need to select and configure.
I think it is sufficient to keep the minimal binaries from sstate-cache which are required to execute image.bbclass, do_rootfs task to generate image.
3) Along with specific configuration UI implementation, a generic configuration model similar to kernel kconfig and menuconfig can be considered, in cases where more detailed offline configurations is required like detailed security configuration.

Regards,
Ramana
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Need for offline binary configuration

Venkata ramana gollamudi <ramana.gollamudi@...>
 

Poky allows to build custom Linux for you, but we have cases where the post build customization is required, like user-addition, network configuration, service control. Even selecting the required packages can be a post build activity.

The current model requires the image to be rebuilt to support these configuration.
Offline Configuration tool (OCT), which allows a binary image customization before making a final target image. This case will be more evident in larger companies, where platform teams, product teams , application teams are distributed and Linux build from source will be owned and lab tested by a single team, like platform team. Other teams just configure to use it for product variants from same platform build.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated from poky.

The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages into final target image.
b) Provision to select external binary packages like ADT compiled applications as input and add them to final target image.
c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
Security related configuration
Generate initrd in ramfs/ext3/... format
etc..

Considering the methods to support these in our current yocto model, following changes can be done.
1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and Hob can work on this package pool to select packages, configure and generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without build options but only with binary package selection. Configuration GUI needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and overall organization as they will be intended for different users.
2) Binary package pool can be a minimal/partial sstate-cache, as complete sstate-cache is quite big and not required for product teams as they are not expected to build but just need to select and configure.
I think it is sufficient to keep the minimal binaries from sstate-cache which are required to execute image.bbclass, do_rootfs task to generate image.
3) Along with specific configuration UI implementation, a generic configuration model similar to kernel kconfig and menuconfig can be considered, in cases where more detailed offline configurations is required like detailed security configuration.

Regards,
Ramana


Re: [meta-baryon][PATCH 1/3] packagegroup-core-tools: exclude packages that depend on x11

Ross Burton
 

On 20 November 2012 14:39, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
On Monday 19 November 2012 12:20:27 Kevin Strasser wrote:
Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
---
.../packagegroup-core-tools-profile.bbappend | 15 +++++++++++++++
.../packagegroup-core-tools-testapps.bbappend | 12 ++++++++++++
2 files changed, 27 insertions(+)
create mode 100644
recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend create
mode 100644
recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend

diff --git
a/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend
b/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend new
file mode 100644
index 0000000..0d13a45
--- /dev/null
+++ b/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend
@@ -0,0 +1,15 @@
+# Only include packages that are useful on a headless device
+
+PROFILETOOLS = " \
+ oprofile \
+ oprofileui-server \
+ powertop \
+ lttng-control \
+ "
+
+RRECOMMENDS_${PN} = " \
+ perf \
+ trace-cmd \
+ kernel-module-oprofile \
+ blktrace \
+ "
diff --git
a/recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend
b/recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend new
file mode 100644
index 0000000..86c7eb5
--- /dev/null
+++ b/recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend
@@ -0,0 +1,12 @@
+# Only include packages that are useful on a headless device
+
+RDEPENDS_${PN} = " \
+ blktool \
+ tslib-calibrate \
+ tslib-tests \
+ lrzsz \
+ ${KEXECTOOLS} \
+ alsa-utils-amixer \
+ alsa-utils-aplay \
+ ltp \
+ "
This would work, but in this instance I think it would be better if we fixed
the packagegroup-core-tools-* recipes in OE-Core so that the items that
require X11 are only included when x11 is in DISTRO_FEATURES, rather than
making the change here.
Isn't this what Jack Mitchell's commit (poky
627fd60c8c01bbc14ad375f6aa195469eab73d86) did, which make sysprof
optional on X11?

Ross


Re: [meta-baryon][PATCH 1/3] packagegroup-core-tools: exclude packages that depend on x11

Paul Eggleton
 

On Monday 19 November 2012 12:20:27 Kevin Strasser wrote:
Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
---
.../packagegroup-core-tools-profile.bbappend | 15 +++++++++++++++
.../packagegroup-core-tools-testapps.bbappend | 12 ++++++++++++
2 files changed, 27 insertions(+)
create mode 100644
recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend create
mode 100644
recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend

diff --git
a/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend
b/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend new
file mode 100644
index 0000000..0d13a45
--- /dev/null
+++ b/recipes-core/packagegroups/packagegroup-core-tools-profile.bbappend
@@ -0,0 +1,15 @@
+# Only include packages that are useful on a headless device
+
+PROFILETOOLS = " \
+ oprofile \
+ oprofileui-server \
+ powertop \
+ lttng-control \
+ "
+
+RRECOMMENDS_${PN} = " \
+ perf \
+ trace-cmd \
+ kernel-module-oprofile \
+ blktrace \
+ "
diff --git
a/recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend
b/recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend new
file mode 100644
index 0000000..86c7eb5
--- /dev/null
+++ b/recipes-core/packagegroups/packagegroup-core-tools-testapps.bbappend
@@ -0,0 +1,12 @@
+# Only include packages that are useful on a headless device
+
+RDEPENDS_${PN} = " \
+ blktool \
+ tslib-calibrate \
+ tslib-tests \
+ lrzsz \
+ ${KEXECTOOLS} \
+ alsa-utils-amixer \
+ alsa-utils-aplay \
+ ltp \
+ "
This would work, but in this instance I think it would be better if we fixed
the packagegroup-core-tools-* recipes in OE-Core so that the items that
require X11 are only included when x11 is in DISTRO_FEATURES, rather than
making the change here.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


updated wiki page for using yocto to build for beagle xM (rev C)

Robert P. J. Day
 

as part of some intro pages i'm going to be using in the future for
teaching yocto, i updated one of my wiki pages this morning for using
yocto to build and boot on a beagle xM. nothing profound, just a
verified recipe that should simply work for anyone:

http://www.crashcourse.ca/wiki/index.php/Yocto_Project_Quick_Start

feedback welcome ... i updated it while not having had enough sleep
so i fully expect it could use some polishing. i just wanted to keep
it simple.

rday

--

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

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


possible update to yocto QS guide, "own-mirrors"

Robert P. J. Day
 

i recall that the QS guide scarfed some of my wiki QS page (which is
fine, given that i was credited for it, :-). if someone (scott?)
wants to tweak, the whole current section showing how to set up a
local mirror of tarballs using:

PREMIRRORS_prepend = "\
git://.*/.* file:///home/you/dl/ \n \
svn://.*/.* file:///home/you/dl/ \n \
cvs://.*/.* file:///home/you/dl/ \n \
ftp://.*/.* file:///home/you/dl/ \n \
http://.*/.* file:///home/you/dl/ \n \
https://.*/.* file:///home/you/dl/ \n"

can be tossed and replaced by what's now at my wiki page,
http://www.crashcourse.ca/wiki/index.php/Yocto_Project_Quick_Start,
which is a much tidier solution:

SOURCE_MIRROR_URL ?= "file:///home/rpjday/y/src/dl/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
# BB_NO_NETWORK = "1"

so help yourself.

rday

--

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

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


Agenda: Yocto Project Technical Team Meeting - Tuesday, November 20, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song <song.liu@...>
 

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.4 status - 20 min (Song/team)
* SWAT team rotation: Jessica -> Ross
* Opens - 10 min
* Team Sharing - 20 min


-----Original Appointment-----


We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
76994298
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x76994298#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
From TI Campus use 89957777
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 26, 2012
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 21, 2013, 10:40 AM CDT


Re: some yocto QS guide links could be tweaked

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Robert,

Good catch. I have fixed these links, pushed to yocto-docs/master and republished to "latest".

Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Robert P. J. Day
Sent: Monday, November 19, 2012 1:24 PM
To: Yocto discussion list
Subject: [yocto] some yocto QS guide links could be tweaked


reading the current version of the QS guide here (this is the
current version, yes?):

http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html

in the Note in the section "The Linux Distribution", there are two
links, "OE and your distro" and "Required Software" that take one to
wiki *diff* pages, rather than the page itself.

scott?

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


some yocto QS guide links could be tweaked

Robert P. J. Day
 

reading the current version of the QS guide here (this is the
current version, yes?):

http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html

in the Note in the section "The Linux Distribution", there are two
links, "OE and your distro" and "Required Software" that take one to
wiki *diff* pages, rather than the page itself.

scott?

rday

--

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

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


[meta-baryon][PATCH 3/3] baryon-image: change IMAGE_FEATURES assignment to "+="

Kevin Strasser <kevin.strasser@...>
 

this will allow EXTRA_IMAGE_FEATURES to have an affect on the image.

Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
---
recipes-extended/images/baryon-image.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/images/baryon-image.bb b/recipes-extended/images/baryon-image.bb
index 656fdba..d5fd8a5 100644
--- a/recipes-extended/images/baryon-image.bb
+++ b/recipes-extended/images/baryon-image.bb
@@ -1,4 +1,4 @@
-IMAGE_FEATURES = "nfs-server package-management ssh-server-dropbear debug-tweaks"
+IMAGE_FEATURES += "nfs-server package-management ssh-server-dropbear"

inherit core-image

--
1.7.9.5


[meta-baryon][PATCH 2/3] baryon-image: use parted instead of util-linux

Kevin Strasser <kevin.strasser@...>
 

util-linux replaces the 'reset' command provided by busybox with
a script that uses 'tset', which fails because it isn't installed.

Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
---
recipes-extended/images/baryon-image.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/images/baryon-image.bb b/recipes-extended/images/baryon-image.bb
index 56b160c..656fdba 100644
--- a/recipes-extended/images/baryon-image.bb
+++ b/recipes-extended/images/baryon-image.bb
@@ -2,7 +2,7 @@ IMAGE_FEATURES = "nfs-server package-management ssh-server-dropbear debug-tweaks

inherit core-image

-IMAGE_INSTALL += "samba procps mdadm e2fsprogs-mke2fs util-linux \
+IMAGE_INSTALL += "samba procps mdadm e2fsprogs-mke2fs parted \
webmin \
webmin-module-status \
webmin-module-proc \
--
1.7.9.5