Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[David Nyström]

On 08/14/2012 09:26 PM, Khem Raj wrote:

On Tue, Aug 14, 2012 at 12:49 AM, David Nyström  wrote:

Hi, it looks like this was merged to the denzil branch, and
PREFERRED_PROVIDER_linux-libc-headers-nativesdk was moved back to
distro.conf.
Any reason for this ?

why do you want nativesdk headers to come from BSP its a fsl-ppc bsp I
dont expect it to have something special for SDK hosts which are
usually x86 ? afterall these are for
the SDK host and not for target. Moreover it means that this BSP will
not play in the multi BSP environment something you never want.


My main concern is that meta-toolchain uses linux-libc-headers-nativesdk 
for the meta-toolchain
tarball build, i.e. the meta-toolchain API may differ from the on-target 
API in regards to kernel-headers, no ?


This might very well be true if kernel version of 
linux-libc-headers-nativesdk != linux-libc-headers


Br,
David



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

[yocto] Hob and image groups: feedback wanted

[Barros Pena, Belen]

Hi all,

As part of bug 2345 I've come up with an alternative way of selecting base
images in Hob that involves grouping base images. I have given a first go
to the image groups, but it would be good if you looked at them to make
sure they make sense.

The groups are listed in page 2 of this document:

https://bugzilla.yoctoproject.org/attachment.cgi?id=704

There is also a html-based prototype of the image selection process here:

https://github.com/belenbarrospena/2-step-image-selection-2345

You can play with the 'Select a base image' section to see how the image
groups work. 

Let me know if we need to make any changes.

Thanks!

Belen



-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [yocto] [PATCH 1/1] meta-cedartrail: update PVR graphics driver to version 1.0.2

[Darren Hart]

Hi Rahul,

A few questions for you below.

On 08/16/2012 11:36 AM, rahul.sax...@intel.com wrote:
> From: Rahul Saxena 
> 
> This update of the driver enables support for B3 stepping of Cedarview
> processor and also support for DP/eDP ports.
> 
> Signed-off-by: Rahul Saxena 
> ---
>  meta-cedartrail/README |2 +-
>  meta-cedartrail/conf/machine/cedartrail.conf   |2 +-
>  .../xorg-driver/cdv-pvr-driver.inc |   37 -
>  .../xorg-driver/cdv-pvr-driver_1.0.2.bb|  143 
> 
>  .../xorg-driver/cdv-pvr-driver_1.0.bb  |   99 --
>  .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |6 +-
>  6 files changed, 148 insertions(+), 141 deletions(-)
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
>  create mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb
> 
> diff --git a/meta-cedartrail/README b/meta-cedartrail/README
> index 493e831..715cad9 100755
> --- a/meta-cedartrail/README
> +++ b/meta-cedartrail/README
> @@ -61,7 +61,7 @@ Power VR Graphics user-space driver binaries are covered by 
> a
>  "Intel Free Distribution Binary License". The build of this driver
>  can be enabled by adding the following line to the local.conf file:
>  
> -LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0"
> +LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0.2"
>  
>  To enable the layer that does not support Power VR graphics
>  add the following to the local.conf file:
> diff --git a/meta-cedartrail/conf/machine/cedartrail.conf 
> b/meta-cedartrail/conf/machine/cedartrail.conf
> index dbd7d95..f00219e 100644
> --- a/meta-cedartrail/conf/machine/cedartrail.conf
> +++ b/meta-cedartrail/conf/machine/cedartrail.conf
> @@ -19,4 +19,4 @@ PREFERRED_VERSION_xf86-input-evdev ?= "2.6.0"
>  
>  SYSLINUX_OPTS = "serial 0 115200"
>  SERIAL_CONSOLE = "115200 ttyS0"
> -APPEND += "console=ttyS0,115200 console=tty0"
> +APPEND += "console=ttyS0,115200 console=tty0 vmalloc=256MB"

Why is the vmalloc change required? This is a non-obvious change and
should be called out in the commit log.

> diff --git a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc 
> b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
> deleted file mode 100644
> index 787c1fb..000
> --- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -SUMMARY = "Cedartrail PowerVR Graphics Driver version [Gold] 1.0 binaries"
> -DESCRIPTION = "2D, 3D and Media user space driver for Cedartrail platform \
> -The binaries are covered by the Intel Free Distribution Binary License. \ 
> -The user must make himself/herself aware of the Licensing terms \
> -before enabling build of the Cedartrail PowerVR Graphics Driver via \
> -this recipe.  Please see the README in meta-cedartrail for instructions \
> -for enabling the build of the driver "
> - 
> -LICENSE_FLAGS = "license_${PN}_${PV}"
> -LICENSE = "Intel Free Distribution Binary License"
> -
> -LIC_FILES_CHKSUM = " \
> -
> file://${S}/usr/share/doc/psb-video-cdv-0.16/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
>   \
> -
> file://${S}/usr/share/doc/pvr-bin-cdv-1.7.788837_10/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65"
> -
> -INC_PR = "r1"
> -
> -DEPENDS = "rpm-native"
> -
> -FILES_${PN} += "${libdir}/dri ${libdir}/pvr/cdv/dri ${libdir}/pvr/cdv 
> ${libdir}/xorg/modules/drivers"
> -FILES_${PN}-dev += "${libdir}/dri ${libdir}/pvr/cdv/dri 
> ${libdir}/xorg/modules/drivers"
> -FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug 
> ${libdir}/dri/.debug ${libdir}/pvr/cdv/dri/.debug"
> -
> -FILES_${PN} += "${base_libdir}/firmware"
> -FILES_${PN} += "${sysconfdir}/X11/xorg.conf.d"
> -
> -FILES_${PN} += "${libdir}/lib*.so"
> -FILES_${PN}-dev += "${libdir}/lib*.so"
> -FILES_${PN}-dbg += "${libdir}/.debug"
> -
> -FILES_${PN} += "${libdir}/pvr/cdv/xorg/modules/drivers"
> -
> -FILES_${PN} += "${datadir}/doc/psb-video-cdv-0.16/license.txt"
> -FILES_${PN} += "${datadir}/doc/pvr-bin-cdv-1.7.788837_10/license.txt"
> -
> -
> -
> diff --git 
> a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb 
> b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
> new file mode 100644
> index 000..047a7fd
> --- /dev/null
> +++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
> @@ -0,0 +1,143 @@
> +SUMMARY = "Cedartrail PowerVR Graphics Driver version 1.0.2 binaries"
> +DESCRIPTION = "2D, 3D and Media user space driver for Cedartrail platform \
> +The binaries are covered by the Intel Free Distribution Binary License. \ 
> +The user must make himself/herself aware of the Licensing terms \
> +before enabling build of the Cedartrail PowerVR Graphics Driver via \
> +this recipe.  Please see the README in met

Re: [yocto] [PATCH] routerstationpro: move board off 3.0 and onto the 3.4 kernel

[Darren Hart]

On 08/17/2012 06:36 AM, Paul Gortmaker wrote:
> On 12-08-16 06:27 PM, Saul Wold wrote:
>> On 07/27/2012 10:10 AM, Paul Gortmaker wrote:
>>> The updated patch series to support this target is in place
>>> on the BSP specific branch in the 3.4 kernel tree now[1], so
>>> we can move it ahead off of the old 3.0 kernel.
>>>
>>> [1] 
>>> https://lists.yoctoproject.org/pipermail/linux-yocto/2012-July/23.html
>>>
>>> Signed-off-by: Paul Gortmaker 
>>>
>>> diff --git a/meta-yocto/conf/machine/routerstationpro.conf 
>>> b/meta-yocto/conf/machine/routerstationpro.conf
>>> index 3c2f56f..adf36a9 100644
>>> --- a/meta-yocto/conf/machine/routerstationpro.conf
>>> +++ b/meta-yocto/conf/machine/routerstationpro.conf
>>> @@ -10,7 +10,7 @@ KERNEL_IMAGETYPE = "vmlinux"
>>>   KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
>>>
>>>   PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>>> -PREFERRED_VERSION_linux-yocto ?= "3.0%"
>>> +PREFERRED_VERSION_linux-yocto ?= "3.4%"
>>>   PREFERRED_PROVIDER_virtual/xserver = "xserver-kdrive"
>>>   XSERVER = "xserver-kdrive-fbdev"
>>>
>>> diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_3.4.bbappend 
>>> b/meta-yocto/recipes-kernel/linux/linux-yocto_3.4.bbappend
>>> index 2ff467b..1c8d26a 100644
>>> --- a/meta-yocto/recipes-kernel/linux/linux-yocto_3.4.bbappend
>>> +++ b/meta-yocto/recipes-kernel/linux/linux-yocto_3.4.bbappend
>>> @@ -4,11 +4,11 @@ KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
>>>   KBRANCH_beagleboard = "standard/beagleboard"
>>>
>>>   SRCREV_machine_atom-pc ?= "a8291fa6f723b0182d2b7033b5d59f412ba7cf72"
>>> -SRCREV_machine_routerstationpro ?= 
>>> "a8291fa6f723b0182d2b7033b5d59f412ba7cf72"
>>> +SRCREV_machine_routerstationpro ?= 
>>> "27019633ccdaa88dc55101615d936d1d74db9a1e"
>>>   SRCREV_machine_mpc8315e-rdb ?= "47d3076aa7e2a640a1dab8d663529a784709f697"
>>>   SRCREV_machine_beagleboard ?= "a8291fa6f723b0182d2b7033b5d59f412ba7cf72"
>>>
>>>   COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
>>> -# COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
>>> +COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
>>>   # COMPATIBLE_MACHINE_beagleboard = "beagleboard"
>>>   COMPATIBLE_MACHINE_atom-pc = "atom-pc"
>>>
>>
>> Yup, this got lost, sorry about that.  It will need to be rebased 
>> against the patchset that Bruce put up, as I am working with that set also.
> 
> I'll resend with the latest SRCREV.  Too bad SRCREV="latest" isn't
> the default, it would save a lot of churn, at least in dev cycles
> where there is no excuse for not wanting the latest...


I hear you on this, unfortunately the problem with using anything other
than specific commit ids is that they require a network lookup :-(


>> Also, changes to meta-yocto should go to p...@yoctoproject.org.
> 
> Is there something akin to a maintainers file or similar that
> adds some clarity as to what goes where?  I'm looking at the
> list summaries here:  https://lists.yoctoproject.org/  and it
> isn't helping me understand what bits I should send where.
> 

A continual source of confusion unfortunately. But you're right, I don't
see anything in poky or meta-yocto that state where the patches should
be sent like other layers do with README or MAINTAINERS.

I've sent a patch to that effect.

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

Re: [yocto] [PATCH 1/1] meta-cedartrail: fixed PREFERRED_VERSION_linux-yocto

[Darren Hart]

On 08/17/2012 09:54 AM, Bodke, Kishore K wrote:
> 
> 
>> -Original Message-
>> From: Mihai Lindner [mailto:mihaix.lind...@linux.intel.com]
>> Sent: Friday, August 17, 2012 8:54 AM
>> To: yocto@yoctoproject.org; Bodke, Kishore K
>> Subject: [PATCH 1/1] meta-cedartrail: fixed PREFERRED_VERSION_linux-yocto
>>
>> Missing PREFERRED_VERSION_linux-yocto generated NOTEs when building.
>> """
>> NOTE: preferred version 3.4% of linux-yocto not available (for item
>> virtual/kernel)
>> """
> 
> Acked-by: Kishore Bodke 

Merged to master, thanks.

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

Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[Khem Raj]

On Mon, Aug 20, 2012 at 12:23 AM, David Nyström  wrote:
> On 08/14/2012 09:26 PM, Khem Raj wrote:
>>
>> On Tue, Aug 14, 2012 at 12:49 AM, David Nyström 
>> wrote:
>>>
>>> Hi, it looks like this was merged to the denzil branch, and
>>> PREFERRED_PROVIDER_linux-libc-headers-nativesdk was moved back to
>>> distro.conf.
>>> Any reason for this ?
>>
>> why do you want nativesdk headers to come from BSP its a fsl-ppc bsp I
>> dont expect it to have something special for SDK hosts which are
>> usually x86 ? afterall these are for
>> the SDK host and not for target. Moreover it means that this BSP will
>> not play in the multi BSP environment something you never want.
>
>
> My main concern is that meta-toolchain uses linux-libc-headers-nativesdk for
> the meta-toolchain
> tarball build, i.e. the meta-toolchain API may differ from the on-target API
> in regards to kernel-headers, no ?
>
> This might very well be true if kernel version of
> linux-libc-headers-nativesdk != linux-libc-headers

whats the point of keeping header versions same across two entirely
different systems.
can you point to some instances where this API difference if any is in
conflict ?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Raspberry Pi do_fetch failure

[Andrei Gherzan]

It seems like even if i got no feedback from github, this issue is not
reproducible anymore. Fetch is working as it should now. Could you please
confirm?

Si it could have been a temporary bug or this was solved meanwhile.

ag




On Mon, Aug 13, 2012 at 9:58 PM, Andrei Gherzan  wrote:

>
> On Mon, Aug 13, 2012 at 7:38 PM, Chris Tapp wrote:
>
>> On 13 Aug 2012, at 15:00, Jack Mitchell wrote:
>>
>> > On 13/08/12 14:51, Andrei Gherzan wrote:
>> >>
>> >> On Mon, Aug 13, 2012 at 4:34 PM, Jack Mitchell 
>> >> > m...@communistcode.co.uk>> wrote:
>> >>
>> >>Good afternoon everyone,
>> >>
>> >>I am trying (yet again) to get yocto to build for the Raspberry Pi
>> >>and I am falling at the do_fetch hurdle on the RasPi kernel.
>> >>
>> >>   ERROR: Fetcher failure: Fetch command export HOME="/home/jack";
>> >>   export SSH_AGENT_PID="1350"; export
>> >>   SSH_AUTH_SOCK="/home/jack/.cache/keyring-fjEm9a/ssh"; export
>> >>
>>  
>> GIT_CONFIG="/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/etc/gitconfig";
>> >>   export
>> >>
>>  
>> PATH="/home/jack/Projects/poky-rasp/scripts:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/bin/armv6-vfp-poky-linux-gnueabi:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi/usr/bin/crossscripts:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/sbin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/bin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/sbin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux//bin:/home/jack/Projects/poky-rasp/scripts:/home/jack/Projects/poky-rasp/bitbake/bin/:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl";
>> >>   git clone --bare --mirror
>> >>git://github.com/raspberrypi/linux.git
>> >>
>> >>
>> >>
>> >> Does this work in a shell? Just try to clone it on your computer.
>> >>
>> >> ag
>> >
>> > Yes, cloning it now without issues - it took a while to get going and
>> someone has suggested that it might be timing out within bitbake...
>>
>>
>> I've had similar issues in the past that seemed to be caused by Github.
>> If I ran a manual fetch I could see errors relating to compressed folders
>> (I think - was a while back) that couldn't be found. It sorted itself after
>> a day or so.
>>
>>
> I sent an email to github. Will keep you posted.
>
> ag
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[McClintock Matthew-B29882]

On Mon, Aug 20, 2012 at 11:45 AM, Khem Raj  wrote:
> On Mon, Aug 20, 2012 at 12:23 AM, David Nyström  
> wrote:
>> On 08/14/2012 09:26 PM, Khem Raj wrote:
>>>
>>> On Tue, Aug 14, 2012 at 12:49 AM, David Nyström 
>>> wrote:

 Hi, it looks like this was merged to the denzil branch, and
 PREFERRED_PROVIDER_linux-libc-headers-nativesdk was moved back to
 distro.conf.
 Any reason for this ?
>>>
>>> why do you want nativesdk headers to come from BSP its a fsl-ppc bsp I
>>> dont expect it to have something special for SDK hosts which are
>>> usually x86 ? afterall these are for
>>> the SDK host and not for target. Moreover it means that this BSP will
>>> not play in the multi BSP environment something you never want.
>>
>>
>> My main concern is that meta-toolchain uses linux-libc-headers-nativesdk for
>> the meta-toolchain
>> tarball build, i.e. the meta-toolchain API may differ from the on-target API
>> in regards to kernel-headers, no ?
>>
>> This might very well be true if kernel version of
>> linux-libc-headers-nativesdk != linux-libc-headers
>
> whats the point of keeping header versions same across two entirely
> different systems.
> can you point to some instances where this API difference if any is in
> conflict ?

I just checked and we do have a few obscure bits in our kernel tree's
header files. Nothing that 99.9% would use but it seems reasonable to
include these...

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

[yocto] Documenting the mailing lists.

[Darren Hart]

Scott,

We've come across some more confusion about mailing lists recently. I've
sent a patch against poky to try and clear it up a bit in the source,
but we should also see about cleaning up the web descriptions of the lists.

We have two pages that describe the lists:

http://www.yoctoproject.org/community/mailing-lists
https://lists.yoctoproject.org/

My first recommendation would be to eliminate
http://www.yoctoproject.org/community/mailing-lists and replace links to
it with links to https://lists.yoctoproject.org. This eliminates the
need to keep the CMS version in sync with the mailman page. The mailman
page should be considered the master anyway as the Description field is
taken directly from the list administrative settings.

We should then work to create meaningful Descriptions of all the lists.
These should still fit on a single line, but I think we can improve on
what we have. For example:

meta-ti Mailing list for the meta-ti layer

is not particularly enlightening. Perhaps something like:

meta-ti Usage and development of the meta-ti layer

If we do this all at once, we can also ensure a consistent language,
tone, etc. I'll propose something for each list here and ask that
interested parties comment and correct in reply. Once agreed upon, the
admins of the respective lists can make the changes (all CC'd)

Current:

linux-yocto Development list for the linux-yocto*.git Linux kernel
repositories
meta-ti Mailing list for the meta-ti layer
pokyPoky build system developer discussion & patch
submission for meta-yocto
shoeleather Neutral Board Lab Mailing List
yocto   Discussion of all things Yocto
yocto-abYocto Project Advisory Board
yocto-advocacy  Yocto Project Advocacy & Outreach AB Subgroup
yocto-announce  Announcements from the Yocto Project
yocto-bsp   BSP Interest Group
Yocto-buildsBuild failures and discusion about the build system
yocto-infrastructureInfrastructure


Proposed:
=
linux-yocto Development list for the linux-yocto*.git Linux kernel
repositories
meta-ti Usage and development list for the meta-ti layer
pokyUsage and development list for the Poky build system
(see README for patch submission)
shoeleather Neutral Board Lab Mailing List

I'm not sure what "neutral" is meant to convey. How about:

Discussion list for the Shoeleather embedded board lab

yocto   General discussion list for the Yocto Project and
development for projects without dedicated lists

I think the yocto list is a bit problematic in that it mixes project
conceptual discussion, user help desk, and development all on the same
list. However, I'm trying to clarify what these actually are here - not
change anything.

yocto-abYocto Project Advisory Board ???

This should imply the intended audience. Is it just meant for members?
Is it meant as a way for non-AB members to observe what is going on?

yocto-advocacy  Yocto Project advocacy & outreach AB subgroup

Same as above.

yocto-announce  Announcements from the Yocto Project (low traffic)
yocto-bsp   BSP Interest Group ???

There is no detailed description for this list, so I'm not sure what
this is really about.

Yocto-buildsBuild failures and discussion about the autobuilder

(includes typo fix, "build system" removed to avoid confusion with the
"poky build system")

yocto-infrastructureInfrastructure ???

Jefro or Michael, can you come up with something appropriate here?


For lists where certain guidelines should be used in communications and
patch submission, we should document that in the detailed description of
the list, such as [project] tags for example.

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

Re: [yocto] Documenting the mailing lists.

[Denys Dmytriyenko]

On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
> Scott,
> 
> We've come across some more confusion about mailing lists recently. I've
> sent a patch against poky to try and clear it up a bit in the source,
> but we should also see about cleaning up the web descriptions of the lists.
> 
> We have two pages that describe the lists:
> 
> http://www.yoctoproject.org/community/mailing-lists
> https://lists.yoctoproject.org/
> 
> My first recommendation would be to eliminate
> http://www.yoctoproject.org/community/mailing-lists and replace links to
> it with links to https://lists.yoctoproject.org. This eliminates the
> need to keep the CMS version in sync with the mailman page. The mailman
> page should be considered the master anyway as the Description field is
> taken directly from the list administrative settings.

I completely agree with this proposal to unify and clean up the mailing list 
references and descriptions. I didn't even know there was a separate page at 
http://www.yoctoproject.org/community/mailing-lists - probably because I was 
happy with https://lists.yoctoproject.org/ all the time :)


> We should then work to create meaningful Descriptions of all the lists.
> These should still fit on a single line, but I think we can improve on
> what we have. For example:
> 
> meta-ti   Mailing list for the meta-ti layer
> 
> is not particularly enlightening. Perhaps something like:
> 
> meta-ti   Usage and development of the meta-ti layer

Not sure if this improves much - in either case it's just a generic 
description of the mailing list that is specific to the corresponding layer, 
meta-ti. But I'm fine with the change, as long as we are unifying all the 
other list descriptions.


> If we do this all at once, we can also ensure a consistent language,
> tone, etc.

Exactly! Thanks for initiating this.


> I'll propose something for each list here and ask that
> interested parties comment and correct in reply. Once agreed upon, the
> admins of the respective lists can make the changes (all CC'd)
> 
> Current:
> 
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Mailing list for the meta-ti layer
> poky  Poky build system developer discussion & patch
>   submission for meta-yocto
> shoeleather   Neutral Board Lab Mailing List
> yocto Discussion of all things Yocto
> yocto-ab  Yocto Project Advisory Board
> yocto-advocacyYocto Project Advocacy & Outreach AB Subgroup
> yocto-announceAnnouncements from the Yocto Project
> yocto-bsp BSP Interest Group
> Yocto-builds  Build failures and discusion about the build system
> yocto-infrastructure  Infrastructure
> 
> 
> Proposed:
> =
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Usage and development list for the meta-ti layer
> poky  Usage and development list for the Poky build system
>   (see README for patch submission)
> shoeleather   Neutral Board Lab Mailing List
> 
> I'm not sure what "neutral" is meant to convey. How about:
> 
>   Discussion list for the Shoeleather embedded board lab
> 
> yocto General discussion list for the Yocto Project and
>   development for projects without dedicated lists
> 
> I think the yocto list is a bit problematic in that it mixes project
> conceptual discussion, user help desk, and development all on the same
> list. However, I'm trying to clarify what these actually are here - not
> change anything.
> 
> yocto-ab  Yocto Project Advisory Board ???
> 
> This should imply the intended audience. Is it just meant for members?
> Is it meant as a way for non-AB members to observe what is going on?
> 
> yocto-advocacyYocto Project advocacy & outreach AB subgroup
> 
> Same as above.
> 
> yocto-announceAnnouncements from the Yocto Project (low traffic)
> yocto-bsp BSP Interest Group ???
> 
> There is no detailed description for this list, so I'm not sure what
> this is really about.
> 
> Yocto-builds  Build failures and discussion about the autobuilder
> 
> (includes typo fix, "build system" removed to avoid confusion with the
> "poky build system")
> 
> yocto-infrastructure  Infrastructure ???
> 
> Jefro or Michael, can you come up with something appropriate here?
> 
> 
> For lists where certain guidelines should be used in communications and
> patch submission, we should document that in the detailed description of
> the list, such as [project] tags for example.

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

Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[Khem Raj]

> I just checked and we do have a few obscure bits in our kernel tree's
> header files. Nothing that 99.9% would use but it seems reasonable to
> include these...

Do you want applications for sdk host to be built using these obscure bits ?
if yes I would like to know why?

since then you are creating a scenariou where nativesdk is dependent on target
kernel and we need to fix it so that nativesdk can be common again.

if patches you are carrying are good for nativesdk headers can they be made
available for other kernels like linux-yocto e.g. ?

right now if we do this we are pretty much saying fsl machine layer can really
not mix with other BSPs. Many people use yocto commonly on more than one kind
of CPU and this does not scale.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[McClintock Matthew-B29882]

On Mon, Aug 20, 2012 at 2:27 PM, Khem Raj  wrote:
>> I just checked and we do have a few obscure bits in our kernel tree's
>> header files. Nothing that 99.9% would use but it seems reasonable to
>> include these...
>
> Do you want applications for sdk host to be built using these obscure bits ?
> if yes I would like to know why?
>
> since then you are creating a scenariou where nativesdk is dependent on target
> kernel and we need to fix it so that nativesdk can be common again.
>
> if patches you are carrying are good for nativesdk headers can they be made
> available for other kernels like linux-yocto e.g. ?
>
> right now if we do this we are pretty much saying fsl machine layer can really
> not mix with other BSPs. Many people use yocto commonly on more than one kind
> of CPU and this does not scale.

Hmm I think I was just confused. We don't need any modifications for
the headers for nativesdk foo (that is the x86 tools in
meta-toolchain).

So, I think everything is OK as is.. if you look at meta-toolchain you
will see it includes our kernel's headers for cross compiling.

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

Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[McClintock Matthew-B29882]

Adding David back...

-M

On Mon, Aug 20, 2012 at 2:42 PM, Matthew McClintock  wrote:
> On Mon, Aug 20, 2012 at 2:27 PM, Khem Raj  wrote:
>>> I just checked and we do have a few obscure bits in our kernel tree's
>>> header files. Nothing that 99.9% would use but it seems reasonable to
>>> include these...
>>
>> Do you want applications for sdk host to be built using these obscure bits ?
>> if yes I would like to know why?
>>
>> since then you are creating a scenariou where nativesdk is dependent on 
>> target
>> kernel and we need to fix it so that nativesdk can be common again.
>>
>> if patches you are carrying are good for nativesdk headers can they be made
>> available for other kernels like linux-yocto e.g. ?
>>
>> right now if we do this we are pretty much saying fsl machine layer can 
>> really
>> not mix with other BSPs. Many people use yocto commonly on more than one kind
>> of CPU and this does not scale.
>
> Hmm I think I was just confused. We don't need any modifications for
> the headers for nativesdk foo (that is the x86 tools in
> meta-toolchain).
>
> So, I think everything is OK as is.. if you look at meta-toolchain you
> will see it includes our kernel's headers for cross compiling.
>
> -M
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: OE-Core task rework

[Mark Hatle]

[resend, I had the original mail rejected by the oe list serves as being 
undeliverable.]


On 8/15/12 4:46 AM, Paul Eggleton wrote:

Hi all,

There have been a few requests to review the task recipes (i.e. package
groups) provided by OE-Core, and indeed these have not really been looked at
seriously since OE-Core was created. Ideally I think we want them to be useful
to a wide audience and provide useful units of functionality that can be added
to an image without the person doing the selection having to manually select
too many individual packages. Imagine presenting the list of tasks to someone
in a UI for assembling images (such as Hob or Narcissus) and you can start to
see that we have some work to do in this area.

I know various distros and users of OE-Core have created their own tasks or
resurrected tasks from OE-Classic, and this is an opportunity to perhaps look
at bringing some of these (or at least, parts of them) into the core. It is
true that tasks will often be an expression of distro policy, and we also
can't have any tasks in OE-Core that refer to packages that don't exist in OE-
Core; thus distros will always be extending the base tasks or adding their own
- and that's fine. However, with some thought I believe we can come up with a
set of tasks that are generally useful to most people using OE-Core.

For reference, I've compiled a list on the wiki of the current tasks in OE-
Core with links to the recipes and some notes:

   http://www.openembedded.org/wiki/OE-Core_Task_Rework

Some of the things I think we ought to consider/address as part of this
exercise:

1) Do we rename "task" to something a little more understandable to the
uninitiated, such as "package group"? The word "task" is already used in a
much more natural sense within bitbake as a unit of work. Historically I
believe we picked up this term from Debian but I'm not aware of significant use
by other mainstream distributions.


"group" or "packagegroup" or "package-group" is my suggestion for the existing 
'task' recipes.  From what I've seen, it should be a rename opportunity -- we 
can even provide/rprovide the old names



2) Look at the existing tasks and:
  * evaluate their usefulness
  * remove any that are obsolete
  * adjust existing contents if needed
  * look for useful groups of packages that might be added

  We need to pay particular attention to task-core-boot and task-base as these
are pulled in by default in any image that inherits from core-image.bbclass -
if these are not generally working for people that are creating their own
images, we need to change them such that they are.


During the pre-oe-core Yocto Project development, a design was generated to 
roughly group the packages into functional areas.  For the most part, this 
design (as well as legacy elements) still exist.


I think the boot, base and others need to be evaluated for usefulness... but my 
feeling is most of them are close to being correct.


The original design attempted to group things into functionality, so that OE 
could be an "additive" distribution.  I.e., you don't start with a big blob of 
packages and remove them as necessary, but instead you start with small 
functional blocks and put them together to construct a system.  The tasks seemed 
to be the logical blocks, and the contents of these blocks were based on the 
early design.


Very roughly speaking the early design was:

filesystem
|\
libclibstdcxx
|   \
small cli\
(busybox) \
|  \
basic commands  python -- perl
| | |
initscripts   | |
multiuser | |
system services --+-+
|
LSB functionality

(Lines indicate implicit dependencies)

The goal was that if you include a specific group, such as "multiuser" support, 
you would get all of the recipes necessary to enable multiuser support on the 
system.  I think this is a reasonable theory to consider when evaluating the 
existing groupings.



3) Ensure all task recipes follow reasonable patterns:
  *  Fix recipe DESCRIPTIONs to make sense (and not contain Poky references)
  *  Ensure all individual packages have a decent SUMMARY/DESCRIPTION
  *  Try to make each task have a reasonable name - there are some current uses
of "core" and "base" that don't actually convey any meaning; LSB specific tasks
should be named as such, etc.


Yup, there is a logical grouping for the lsb specific tasks, as for others.  The 
naming needs to be made clear as to why it's there, and what it represents. Same 
with the summary and descriptions -- they should list the functionality provided 
by this group of components.



  *  Make all tasks inherit task.bbclass so that they get proper dbg/dev
packages and any other common task functionality

4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
converts some IMAGE_FEATURES into the addition of tasks to be installed (see
classes/core-image.bbclass). At the very least we should p

Re: [yocto] Documenting the mailing lists.

[Rifenbark, Scott M]

I can replace the information on 
http://www.yoctoproject.org/community/mailing-lists with a generic bit about 
mailing lists and then provide a link to the https://lists.yoctoproject.org/ 
page.  Regarding the text on the https://lists.yoctoproject.org link.  Who 
maintains that page?

Scott

-Original Message-
From: Denys Dmytriyenko [mailto:de...@ti.com] 
Sent: Monday, August 20, 2012 12:15 PM
To: Darren Hart
Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker; Richard Purdie; Wold, 
Saul; Paul Eggleton; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Koen 
Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
Subject: Re: Documenting the mailing lists.

On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
> Scott,
> 
> We've come across some more confusion about mailing lists recently. I've
> sent a patch against poky to try and clear it up a bit in the source,
> but we should also see about cleaning up the web descriptions of the lists.
> 
> We have two pages that describe the lists:
> 
> http://www.yoctoproject.org/community/mailing-lists
> https://lists.yoctoproject.org/
> 
> My first recommendation would be to eliminate
> http://www.yoctoproject.org/community/mailing-lists and replace links to
> it with links to https://lists.yoctoproject.org. This eliminates the
> need to keep the CMS version in sync with the mailman page. The mailman
> page should be considered the master anyway as the Description field is
> taken directly from the list administrative settings.

I completely agree with this proposal to unify and clean up the mailing list 
references and descriptions. I didn't even know there was a separate page at 
http://www.yoctoproject.org/community/mailing-lists - probably because I was 
happy with https://lists.yoctoproject.org/ all the time :)


> We should then work to create meaningful Descriptions of all the lists.
> These should still fit on a single line, but I think we can improve on
> what we have. For example:
> 
> meta-ti   Mailing list for the meta-ti layer
> 
> is not particularly enlightening. Perhaps something like:
> 
> meta-ti   Usage and development of the meta-ti layer

Not sure if this improves much - in either case it's just a generic 
description of the mailing list that is specific to the corresponding layer, 
meta-ti. But I'm fine with the change, as long as we are unifying all the 
other list descriptions.


> If we do this all at once, we can also ensure a consistent language,
> tone, etc.

Exactly! Thanks for initiating this.


> I'll propose something for each list here and ask that
> interested parties comment and correct in reply. Once agreed upon, the
> admins of the respective lists can make the changes (all CC'd)
> 
> Current:
> 
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Mailing list for the meta-ti layer
> poky  Poky build system developer discussion & patch
>   submission for meta-yocto
> shoeleather   Neutral Board Lab Mailing List
> yocto Discussion of all things Yocto
> yocto-ab  Yocto Project Advisory Board
> yocto-advocacyYocto Project Advocacy & Outreach AB Subgroup
> yocto-announceAnnouncements from the Yocto Project
> yocto-bsp BSP Interest Group
> Yocto-builds  Build failures and discusion about the build system
> yocto-infrastructure  Infrastructure
> 
> 
> Proposed:
> =
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Usage and development list for the meta-ti layer
> poky  Usage and development list for the Poky build system
>   (see README for patch submission)
> shoeleather   Neutral Board Lab Mailing List
> 
> I'm not sure what "neutral" is meant to convey. How about:
> 
>   Discussion list for the Shoeleather embedded board lab
> 
> yocto General discussion list for the Yocto Project and
>   development for projects without dedicated lists
> 
> I think the yocto list is a bit problematic in that it mixes project
> conceptual discussion, user help desk, and development all on the same
> list. However, I'm trying to clarify what these actually are here - not
> change anything.
> 
> yocto-ab  Yocto Project Advisory Board ???
> 
> This should imply the intended audience. Is it just meant for members?
> Is it meant as a way for non-AB members to observe what is going on?
> 
> yocto-advocacyYocto Project advocacy & outreach AB subgroup
> 
> Same as above.
> 
> yocto-announceAnnouncements from the Yocto Project (low traffic)
> yocto-bsp BSP Interest Group ???
> 
> There is no detailed description for this list, so I'm not sure what
> this is really about.
> 
> Yocto-builds  Build failures and discussion about the autobuilder
> 
> (includes typo fix, "build system" removed to avoid confusion with the
> "pok

Re: [yocto] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

[Darren Hart]

On 08/20/2012 01:35 PM, Bruce Ashfield wrote:
> On 12-08-20 04:31 PM, Liu, Song wrote:
>> Hi Darren/Bruce,
>>
>> Is there anything else that needs to be done for this one? If not, would
>> you please close it?
> 
> It was waiting on a few comments, but it made M3, so I'll take
> care of updating it once more and closing the item later today or
> early tomorrow.

So sorry... too many things cooking...

So a review...

> diff --git a/00-README b/00-README
> index 96a0f7d..ec933cc 100644
> --- a/00-README
> +++ b/00-README
> @@ -1,3 +1,197 @@
> +1.0 Overview
> +
> +
> +The linux-yocto kernel is composed of additions/modifications to the
> +kernel.org source, plus configuration/control data to manage and use those
> +changes.
> +
> +Source code changes are seen as git commits to the kernel source tree, are
> +arranged into features (sometimes) separated by branches and marked by tags.
> +
> +The configuration and control data is contained within a separate branch from
> +source changes called the meta branch. The configuration data is contained
> +within the kernel-cache directory structure, and represents the instructions
> +to modify the source tree and the configuration policies required to 
> configure
> +and build the kernel.
> +
> +While changes to the source code have already been applied to the tree, the
> +control and configuration data is used before and during the kernel build
> +process to generate a valid kernel config.
> +
> +This README explains the configuration data and policies around the
> +organization of this information, it is not a guide to tree construction, scc
> +file syntax or linux-yocto architecture.
> +
> +2.0 Configuration Policy
> +
> +
> +The configuration data contained within the meta branch has the following
> +purposes:
> +
> + - Documents and defines hardware, non-hardware, required and optional
> + configuration data that are used to keep software configuration policy
> + and board support configuration separate. It also tags configuration data
> + in a manner that an audit can be performed to ensure that polices make it
> + t[M#&/o the final .config and that required options are not overridden or

 ^ some junk snuck in here it seems

> + dropped from the final .config.
> +
> + - Creates a baseline configuration that can be inherited/included to result
> + in consistent configuration across all derived kernel builds
> +
> + - Groups patches and their configuration data into documented features. The
> + proper configuration and enablement of a kernel change is coupled with the
> + patches that make the change to the source.
> +
> + - Creates named feature fragments that when included enable the required
> + options to implement a specific behaviour (i.e. USB boot)
> +
> + - Define BSPs (Board Support Packages) (machines) that select a policy

Should be "Defines" to be consistent with previous paragraphs...

> + (features + config) and hardware options to form a buildable, bootable
> + configuration.
> +
> +The policy that is contained within the meta branch can be overridden by

s/policy/policies/ ?

> +external descriptions using the same description format as the meta branch
> +configuration. This allows for flexible modification and extension of the
> +base policy. Also, if a previously defined BSP configuration is modified, it
> +can be audited against the software policy to generate a compliance report.
> +
> +2.1 Kernel types (ktypes)

Types ("Title Caps" should be used in section headings for consistency -
applies throughout)
KTYPE should probably always be capitalized?

> +-
> +
> +Kernel types (ktypes) are the highest level policy containers and represent
> +a significant set of kernel functionality that has been grouped (and named)
> +or partitioned.

What are you trying to convey with "partitioned" vs. "grouped" ? The
"or" indicates a functional difference, but it isn't clear what that is
from this reading.

> +
> +There are often significant differences between kernel types in the following
> +ways:
> +
> + - source code. Large or invasive features that cannot be cleanly disabled,

source code: large ...

> + or that cannot co-exist with other features at a source code level are
> + separated by kernel type. The preempt-rt patches, alternate schedulers,
> + grsecurity, are some examples of patches that are important parts of
> + kernel type definition.
> +
> + - behaviour. A kernel type defines a default behaviour, which is often a

behaviour: a kernel type ...

> + trade off against other options.
> +
> + - performance versus determinism
> + - security vs flexibility

vs.

> + - size vs features

vs.

> + - ..

...

> +
> + are all common parts of behaviour differences between kernel types.

behavioural ?

> +
> + - feature support. Different kernel types support different sets of 
> features;

feature support: different ...

Incorrect semicolon usage. Replace with a comma.

> + such as XIP or dif

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 01:55 PM, Rifenbark, Scott M wrote:
> I can replace the information on
> http://www.yoctoproject.org/community/mailing-lists with a generic
> bit about mailing lists and then provide a link to the
> https://lists.yoctoproject.org/ page.

That would work for me.

>  Regarding the text on the
> https://lists.yoctoproject.org link.  Who maintains that page?

The Description field is pulled from the administrative settings for
each of the lists managed by mailman. So once we agree on the
descriptions, the various list admins will update the descriptions and
the page will reflect that (I believe Jefro and I can cover most.. if
not all of them, but all the admins are CC'd here).

However, please do not make any changes until we come to a consensus on
how to handle this. I believe we have some discussion that needs to
happen first.

To prevent this turning into a multi-week nit-pic-fest, I suggest we set
Friday Augh 24th @ Noon PST as the deadline and the point at which the
agreed on changes can be made and all changes should be made final by
EOD PST on Monday Aug 27th.

--
Darren

> 
> Scott
> 
> -Original Message- From: Denys Dmytriyenko
> [mailto:de...@ti.com] Sent: Monday, August 20, 2012 12:15 PM To:
> Darren Hart Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker;
> Richard Purdie; Wold, Saul; Paul Eggleton; Osier-mixon, Jeffrey;
> Zanussi, Tom; Hudson, Sean; Koen Kooi; Jason Kridner; Flanagan,
> Elizabeth; Michael Halstead Subject: Re: Documenting the mailing
> lists.
> 
> On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
>> Scott,
>> 
>> We've come across some more confusion about mailing lists recently.
>> I've sent a patch against poky to try and clear it up a bit in the
>> source, but we should also see about cleaning up the web
>> descriptions of the lists.
>> 
>> We have two pages that describe the lists:
>> 
>> http://www.yoctoproject.org/community/mailing-lists 
>> https://lists.yoctoproject.org/
>> 
>> My first recommendation would be to eliminate 
>> http://www.yoctoproject.org/community/mailing-lists and replace
>> links to it with links to https://lists.yoctoproject.org. This
>> eliminates the need to keep the CMS version in sync with the
>> mailman page. The mailman page should be considered the master
>> anyway as the Description field is taken directly from the list
>> administrative settings.
> 
> I completely agree with this proposal to unify and clean up the
> mailing list references and descriptions. I didn't even know there
> was a separate page at 
> http://www.yoctoproject.org/community/mailing-lists - probably
> because I was happy with https://lists.yoctoproject.org/ all the time
> :)
> 
> 
>> We should then work to create meaningful Descriptions of all the
>> lists. These should still fit on a single line, but I think we can
>> improve on what we have. For example:
>> 
>> meta-ti  Mailing list for the meta-ti layer
>> 
>> is not particularly enlightening. Perhaps something like:
>> 
>> meta-ti  Usage and development of the meta-ti layer
> 
> Not sure if this improves much - in either case it's just a generic 
> description of the mailing list that is specific to the corresponding
> layer, meta-ti. But I'm fine with the change, as long as we are
> unifying all the other list descriptions.
> 
> 
>> If we do this all at once, we can also ensure a consistent
>> language, tone, etc.
> 
> Exactly! Thanks for initiating this.
> 
> 
>> I'll propose something for each list here and ask that interested
>> parties comment and correct in reply. Once agreed upon, the admins
>> of the respective lists can make the changes (all CC'd)
>> 
>> Current:  linux-yoctoDevelopment list for the
>> linux-yocto*.git Linux kernel repositories meta-ti   Mailing list
>> for the meta-ti layer poky   Poky build system developer discussion
>> & patch submission for meta-yocto shoeleatherNeutral Board Lab
>> Mailing List yocto   Discussion of all things Yocto yocto-ab 
>> Yocto
>> Project Advisory Board yocto-advocacyYocto Project Advocacy &
>> Outreach AB Subgroup yocto-announce  Announcements from the Yocto
>> Project yocto-bspBSP Interest Group Yocto-builds Build failures
>> and discusion about the build system yocto-infrastructure
>> Infrastructure
>> 
>> 
>> Proposed: = linux-yocto  Development list for the
>> linux-yocto*.git Linux kernel repositories meta-ti   Usage and
>> development list for the meta-ti layer poky  Usage and development
>> list for the Poky build system (see README for patch submission) 
>> shoeleather  Neutral Board Lab Mailing List
>> 
>> I'm not sure what "neutral" is meant to convey. How about:
>> 
>> Discussion list for the Shoeleather embedded board lab
>> 
>> yoctoGeneral discussion list for the Yocto Project and 
>> development for projects without dedicated lists
>> 
>> I think the yocto list is a bit problematic in 

Re: [yocto] Documenting the mailing lists.

[Rifenbark, Scott M]

Okay - I will hold off on the 
http://www.yoctoproject.org/community/mailing-lists change until Friday Noon.

Scott

-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com] 
Sent: Monday, August 20, 2012 2:19 PM
To: Rifenbark, Scott M
Cc: Denys Dmytriyenko; Yocto Project; Paul Gortmaker; Richard Purdie; Wold, 
Saul; Paul Eggleton; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Koen 
Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
Subject: Re: Documenting the mailing lists.



On 08/20/2012 01:55 PM, Rifenbark, Scott M wrote:
> I can replace the information on
> http://www.yoctoproject.org/community/mailing-lists with a generic
> bit about mailing lists and then provide a link to the
> https://lists.yoctoproject.org/ page.

That would work for me.

>  Regarding the text on the
> https://lists.yoctoproject.org link.  Who maintains that page?

The Description field is pulled from the administrative settings for
each of the lists managed by mailman. So once we agree on the
descriptions, the various list admins will update the descriptions and
the page will reflect that (I believe Jefro and I can cover most.. if
not all of them, but all the admins are CC'd here).

However, please do not make any changes until we come to a consensus on
how to handle this. I believe we have some discussion that needs to
happen first.

To prevent this turning into a multi-week nit-pic-fest, I suggest we set
Friday Augh 24th @ Noon PST as the deadline and the point at which the
agreed on changes can be made and all changes should be made final by
EOD PST on Monday Aug 27th.

--
Darren

> 
> Scott
> 
> -Original Message- From: Denys Dmytriyenko
> [mailto:de...@ti.com] Sent: Monday, August 20, 2012 12:15 PM To:
> Darren Hart Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker;
> Richard Purdie; Wold, Saul; Paul Eggleton; Osier-mixon, Jeffrey;
> Zanussi, Tom; Hudson, Sean; Koen Kooi; Jason Kridner; Flanagan,
> Elizabeth; Michael Halstead Subject: Re: Documenting the mailing
> lists.
> 
> On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
>> Scott,
>> 
>> We've come across some more confusion about mailing lists recently.
>> I've sent a patch against poky to try and clear it up a bit in the
>> source, but we should also see about cleaning up the web
>> descriptions of the lists.
>> 
>> We have two pages that describe the lists:
>> 
>> http://www.yoctoproject.org/community/mailing-lists 
>> https://lists.yoctoproject.org/
>> 
>> My first recommendation would be to eliminate 
>> http://www.yoctoproject.org/community/mailing-lists and replace
>> links to it with links to https://lists.yoctoproject.org. This
>> eliminates the need to keep the CMS version in sync with the
>> mailman page. The mailman page should be considered the master
>> anyway as the Description field is taken directly from the list
>> administrative settings.
> 
> I completely agree with this proposal to unify and clean up the
> mailing list references and descriptions. I didn't even know there
> was a separate page at 
> http://www.yoctoproject.org/community/mailing-lists - probably
> because I was happy with https://lists.yoctoproject.org/ all the time
> :)
> 
> 
>> We should then work to create meaningful Descriptions of all the
>> lists. These should still fit on a single line, but I think we can
>> improve on what we have. For example:
>> 
>> meta-ti  Mailing list for the meta-ti layer
>> 
>> is not particularly enlightening. Perhaps something like:
>> 
>> meta-ti  Usage and development of the meta-ti layer
> 
> Not sure if this improves much - in either case it's just a generic 
> description of the mailing list that is specific to the corresponding
> layer, meta-ti. But I'm fine with the change, as long as we are
> unifying all the other list descriptions.
> 
> 
>> If we do this all at once, we can also ensure a consistent
>> language, tone, etc.
> 
> Exactly! Thanks for initiating this.
> 
> 
>> I'll propose something for each list here and ask that interested
>> parties comment and correct in reply. Once agreed upon, the admins
>> of the respective lists can make the changes (all CC'd)
>> 
>> Current:  linux-yoctoDevelopment list for the
>> linux-yocto*.git Linux kernel repositories meta-ti   Mailing list
>> for the meta-ti layer poky   Poky build system developer discussion
>> & patch submission for meta-yocto shoeleatherNeutral Board Lab
>> Mailing List yocto   Discussion of all things Yocto yocto-ab 
>> Yocto
>> Project Advisory Board yocto-advocacyYocto Project Advocacy &
>> Outreach AB Subgroup yocto-announce  Announcements from the Yocto
>> Project yocto-bspBSP Interest Group Yocto-builds Build failures
>> and discusion about the build system yocto-infrastructure
>> Infrastructure
>> 
>> 
>> Proposed: = linux-yocto  Development list for the
>> linux-yocto*.git Linux kernel repositories meta-ti   Usa

Re: [yocto] Documenting the mailing lists.

[Paul Eggleton]

On Monday 20 August 2012 11:43:38 Darren Hart wrote:
> Scott,
> 
> We've come across some more confusion about mailing lists recently. I've
> sent a patch against poky to try and clear it up a bit in the source,
> but we should also see about cleaning up the web descriptions of the lists.
> 
> We have two pages that describe the lists:
> 
> http://www.yoctoproject.org/community/mailing-lists
> https://lists.yoctoproject.org/
> 
> My first recommendation would be to eliminate
> http://www.yoctoproject.org/community/mailing-lists and replace links to
> it with links to https://lists.yoctoproject.org. This eliminates the
> need to keep the CMS version in sync with the mailman page. The mailman
> page should be considered the master anyway as the Description field is
> taken directly from the list administrative settings.
> 
> We should then work to create meaningful Descriptions of all the lists.
> These should still fit on a single line, but I think we can improve on
> what we have. For example:
> 
> meta-ti   Mailing list for the meta-ti layer
> 
> is not particularly enlightening. Perhaps something like:
> 
> meta-ti   Usage and development of the meta-ti layer
> 
> If we do this all at once, we can also ensure a consistent language,
> tone, etc. I'll propose something for each list here and ask that
> interested parties comment and correct in reply. Once agreed upon, the
> admins of the respective lists can make the changes (all CC'd)
> 
> Current:
> 
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Mailing list for the meta-ti layer
> poky  Poky build system developer discussion & patch
>   submission for meta-yocto
> shoeleather   Neutral Board Lab Mailing List
> yocto Discussion of all things Yocto
> yocto-ab  Yocto Project Advisory Board
> yocto-advocacyYocto Project Advocacy & Outreach AB Subgroup
> yocto-announceAnnouncements from the Yocto Project
> yocto-bsp BSP Interest Group
> Yocto-builds  Build failures and discusion about the build system
> yocto-infrastructure  Infrastructure
> 
> 
> Proposed:
> =
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Usage and development list for the meta-ti layer
> poky  Usage and development list for the Poky build system
>   (see README for patch submission)
> shoeleather   Neutral Board Lab Mailing List
> 
> I'm not sure what "neutral" is meant to convey. How about:
> 
>   Discussion list for the Shoeleather embedded board lab
> 
> yocto General discussion list for the Yocto Project and
>   development for projects without dedicated lists
> 
> I think the yocto list is a bit problematic in that it mixes project
> conceptual discussion, user help desk, and development all on the same
> list. However, I'm trying to clarify what these actually are here - not
> change anything.
> 
> yocto-ab  Yocto Project Advisory Board ???
> 
> This should imply the intended audience. Is it just meant for members?
> Is it meant as a way for non-AB members to observe what is going on?
> 
> yocto-advocacyYocto Project advocacy & outreach AB subgroup
> 
> Same as above.
> 
> yocto-announceAnnouncements from the Yocto Project (low traffic)
> yocto-bsp BSP Interest Group ???
> 
> There is no detailed description for this list, so I'm not sure what
> this is really about.
> 
> Yocto-builds  Build failures and discussion about the autobuilder
> 
> (includes typo fix, "build system" removed to avoid confusion with the
> "poky build system")
> 
> yocto-infrastructure  Infrastructure ???
> 
> Jefro or Michael, can you come up with something appropriate here?
> 
> 
> For lists where certain guidelines should be used in communications and
> patch submission, we should document that in the detailed description of
> the list, such as [project] tags for example.

This is all good stuff, I'd just like to mention in case it is useful that I 
did update the list in the Reference Manual along with the information on how 
to contribute - which includes some direction on where to send patches. This 
is in the master version of the documentation but not the version currently 
shown on the website - we probably ought to fix that. We really ought to try to 
have all of this information consistent if at all possible.

Cheers,
Paul

-- 

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

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 02:26 PM, Paul Eggleton wrote:
> On Monday 20 August 2012 11:43:38 Darren Hart wrote:
>> Scott,
>>
>> We've come across some more confusion about mailing lists recently. I've
>> sent a patch against poky to try and clear it up a bit in the source,
>> but we should also see about cleaning up the web descriptions of the lists.
>>
>> We have two pages that describe the lists:
>>
>> http://www.yoctoproject.org/community/mailing-lists
>> https://lists.yoctoproject.org/
>>
>> My first recommendation would be to eliminate
>> http://www.yoctoproject.org/community/mailing-lists and replace links to
>> it with links to https://lists.yoctoproject.org. This eliminates the
>> need to keep the CMS version in sync with the mailman page. The mailman
>> page should be considered the master anyway as the Description field is
>> taken directly from the list administrative settings.
>>
>> We should then work to create meaningful Descriptions of all the lists.
>> These should still fit on a single line, but I think we can improve on
>> what we have. For example:
>>
>> meta-ti  Mailing list for the meta-ti layer
>>
>> is not particularly enlightening. Perhaps something like:
>>
>> meta-ti  Usage and development of the meta-ti layer
>>
>> If we do this all at once, we can also ensure a consistent language,
>> tone, etc. I'll propose something for each list here and ask that
>> interested parties comment and correct in reply. Once agreed upon, the
>> admins of the respective lists can make the changes (all CC'd)
>>
>> Current:
>> 
>> linux-yocto  Development list for the linux-yocto*.git Linux kernel
>>  repositories
>> meta-ti  Mailing list for the meta-ti layer
>> poky Poky build system developer discussion & patch
>>  submission for meta-yocto
>> shoeleather  Neutral Board Lab Mailing List
>> yoctoDiscussion of all things Yocto
>> yocto-ab Yocto Project Advisory Board
>> yocto-advocacy   Yocto Project Advocacy & Outreach AB Subgroup
>> yocto-announce   Announcements from the Yocto Project
>> yocto-bspBSP Interest Group
>> Yocto-builds Build failures and discusion about the build system
>> yocto-infrastructure Infrastructure
>>
>>
>> Proposed:
>> =
>> linux-yocto  Development list for the linux-yocto*.git Linux kernel
>>  repositories
>> meta-ti  Usage and development list for the meta-ti layer
>> poky Usage and development list for the Poky build system
>>  (see README for patch submission)
>> shoeleather  Neutral Board Lab Mailing List
>>
>> I'm not sure what "neutral" is meant to convey. How about:
>>
>>  Discussion list for the Shoeleather embedded board lab
>>
>> yoctoGeneral discussion list for the Yocto Project and
>>  development for projects without dedicated lists
>>
>> I think the yocto list is a bit problematic in that it mixes project
>> conceptual discussion, user help desk, and development all on the same
>> list. However, I'm trying to clarify what these actually are here - not
>> change anything.
>>
>> yocto-ab Yocto Project Advisory Board ???
>>
>> This should imply the intended audience. Is it just meant for members?
>> Is it meant as a way for non-AB members to observe what is going on?
>>
>> yocto-advocacy   Yocto Project advocacy & outreach AB subgroup
>>
>> Same as above.
>>
>> yocto-announce   Announcements from the Yocto Project (low traffic)
>> yocto-bspBSP Interest Group ???
>>
>> There is no detailed description for this list, so I'm not sure what
>> this is really about.
>>
>> Yocto-builds Build failures and discussion about the autobuilder
>>
>> (includes typo fix, "build system" removed to avoid confusion with the
>> "poky build system")
>>
>> yocto-infrastructure Infrastructure ???
>>
>> Jefro or Michael, can you come up with something appropriate here?
>>
>>
>> For lists where certain guidelines should be used in communications and
>> patch submission, we should document that in the detailed description of
>> the list, such as [project] tags for example.
> 
> This is all good stuff, I'd just like to mention in case it is useful that I 
> did update the list in the Reference Manual along with the information on how 
> to contribute - which includes some direction on where to send patches. This 
> is in the master version of the documentation but not the version currently 
> shown on the website - we probably ought to fix that. We really ought to try 
> to 
> have all of this information consistent if at all possible.

Does it make sense to have this list in the reference manual? Should we
perhaps just have it reference the README in the source (that way people
can always see the current policy) and the long mailing list
description? That reduces the redundancy to 2 from 4. Should be much
easier to keep in sync.

-- 
Darren Hart
Intel Ope

Re: [yocto] Documenting the mailing lists.

[Denys Dmytriyenko]

On Mon, Aug 20, 2012 at 08:55:34PM +, Rifenbark, Scott M wrote:
> Regarding the text on the https://lists.yoctoproject.org link.  Who 
> maintains that page?

It's generated from each list's configuration data. Corresponding list 
maintainers or mailman admin (Michael?) can change the descriptions, like I 
just did for meta-ti.

-- 
Denys


> -Original Message-
> From: Denys Dmytriyenko [mailto:de...@ti.com] 
> Sent: Monday, August 20, 2012 12:15 PM
> To: Darren Hart
> Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker; Richard Purdie; Wold, 
> Saul; Paul Eggleton; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Koen 
> Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
> Subject: Re: Documenting the mailing lists.
> 
> On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
> > Scott,
> > 
> > We've come across some more confusion about mailing lists recently. I've
> > sent a patch against poky to try and clear it up a bit in the source,
> > but we should also see about cleaning up the web descriptions of the lists.
> > 
> > We have two pages that describe the lists:
> > 
> > http://www.yoctoproject.org/community/mailing-lists
> > https://lists.yoctoproject.org/
> > 
> > My first recommendation would be to eliminate
> > http://www.yoctoproject.org/community/mailing-lists and replace links to
> > it with links to https://lists.yoctoproject.org. This eliminates the
> > need to keep the CMS version in sync with the mailman page. The mailman
> > page should be considered the master anyway as the Description field is
> > taken directly from the list administrative settings.
> 
> I completely agree with this proposal to unify and clean up the mailing list 
> references and descriptions. I didn't even know there was a separate page at 
> http://www.yoctoproject.org/community/mailing-lists - probably because I was 
> happy with https://lists.yoctoproject.org/ all the time :)
> 
> 
> > We should then work to create meaningful Descriptions of all the lists.
> > These should still fit on a single line, but I think we can improve on
> > what we have. For example:
> > 
> > meta-ti Mailing list for the meta-ti layer
> > 
> > is not particularly enlightening. Perhaps something like:
> > 
> > meta-ti Usage and development of the meta-ti layer
> 
> Not sure if this improves much - in either case it's just a generic 
> description of the mailing list that is specific to the corresponding layer, 
> meta-ti. But I'm fine with the change, as long as we are unifying all the 
> other list descriptions.
> 
> 
> > If we do this all at once, we can also ensure a consistent language,
> > tone, etc.
> 
> Exactly! Thanks for initiating this.
> 
> 
> > I'll propose something for each list here and ask that
> > interested parties comment and correct in reply. Once agreed upon, the
> > admins of the respective lists can make the changes (all CC'd)
> > 
> > Current:
> > 
> > linux-yocto Development list for the linux-yocto*.git Linux kernel
> > repositories
> > meta-ti Mailing list for the meta-ti layer
> > pokyPoky build system developer discussion & patch
> > submission for meta-yocto
> > shoeleather Neutral Board Lab Mailing List
> > yocto   Discussion of all things Yocto
> > yocto-abYocto Project Advisory Board
> > yocto-advocacy  Yocto Project Advocacy & Outreach AB Subgroup
> > yocto-announce  Announcements from the Yocto Project
> > yocto-bsp   BSP Interest Group
> > Yocto-buildsBuild failures and discusion about the build system
> > yocto-infrastructureInfrastructure
> > 
> > 
> > Proposed:
> > =
> > linux-yocto Development list for the linux-yocto*.git Linux kernel
> > repositories
> > meta-ti Usage and development list for the meta-ti layer
> > pokyUsage and development list for the Poky build system
> > (see README for patch submission)
> > shoeleather Neutral Board Lab Mailing List
> > 
> > I'm not sure what "neutral" is meant to convey. How about:
> > 
> > Discussion list for the Shoeleather embedded board lab
> > 
> > yocto   General discussion list for the Yocto Project and
> > development for projects without dedicated lists
> > 
> > I think the yocto list is a bit problematic in that it mixes project
> > conceptual discussion, user help desk, and development all on the same
> > list. However, I'm trying to clarify what these actually are here - not
> > change anything.
> > 
> > yocto-abYocto Project Advisory Board ???
> > 
> > This should imply the intended audience. Is it just meant for members?
> > Is it meant as a way for non-AB members to observe what is going on?
> > 
> > yocto-advocacy  Yocto Project advocacy & outreach AB subgroup
> > 
> > Same as above.
> > 
> > yocto-announce  Announcements from the Yocto Project (low traffic)
> > yocto-bs

Re: [yocto] Documenting the mailing lists.

[Paul Eggleton]

On Monday 20 August 2012 14:27:58 Darren Hart wrote:
> On 08/20/2012 02:26 PM, Paul Eggleton wrote:
> > On Monday 20 August 2012 11:43:38 Darren Hart wrote:
> >> Scott,
> >> 
> >> We've come across some more confusion about mailing lists recently. I've
> >> sent a patch against poky to try and clear it up a bit in the source,
> >> but we should also see about cleaning up the web descriptions of the
> >> lists.
> >> 
> >> We have two pages that describe the lists:
> >> 
> >> http://www.yoctoproject.org/community/mailing-lists
> >> https://lists.yoctoproject.org/
> >> 
> >> My first recommendation would be to eliminate
> >> http://www.yoctoproject.org/community/mailing-lists and replace links to
> >> it with links to https://lists.yoctoproject.org. This eliminates the
> >> need to keep the CMS version in sync with the mailman page. The mailman
> >> page should be considered the master anyway as the Description field is
> >> taken directly from the list administrative settings.
> >> 
> >> We should then work to create meaningful Descriptions of all the lists.
> >> These should still fit on a single line, but I think we can improve on
> >> what we have. For example:
> >> 
> >> meta-tiMailing list for the meta-ti layer
> >> 
> >> is not particularly enlightening. Perhaps something like:
> >> 
> >> meta-tiUsage and development of the meta-ti layer
> >> 
> >> If we do this all at once, we can also ensure a consistent language,
> >> tone, etc. I'll propose something for each list here and ask that
> >> interested parties comment and correct in reply. Once agreed upon, the
> >> admins of the respective lists can make the changes (all CC'd)
> >> 
> >> Current:
> >> 
> >> linux-yoctoDevelopment list for the linux-yocto*.git Linux kernel
> >> 
> >>repositories
> >> 
> >> meta-tiMailing list for the meta-ti layer
> >> poky   Poky build system developer discussion & patch
> >> 
> >>submission for meta-yocto
> >> 
> >> shoeleatherNeutral Board Lab Mailing List
> >> yocto  Discussion of all things Yocto
> >> yocto-ab   Yocto Project Advisory Board
> >> yocto-advocacy Yocto Project Advocacy & Outreach AB Subgroup
> >> yocto-announce Announcements from the Yocto Project
> >> yocto-bsp  BSP Interest Group
> >> Yocto-builds   Build failures and discusion about the build system
> >> yocto-infrastructure   Infrastructure
> >> 
> >> 
> >> Proposed:
> >> =
> >> linux-yoctoDevelopment list for the linux-yocto*.git Linux kernel
> >> 
> >>repositories
> >> 
> >> meta-tiUsage and development list for the meta-ti layer
> >> poky   Usage and development list for the Poky build system
> >> 
> >>(see README for patch submission)
> >> 
> >> shoeleatherNeutral Board Lab Mailing List
> >> 
> >> I'm not sure what "neutral" is meant to convey. How about:
> >>Discussion list for the Shoeleather embedded board lab
> >> 
> >> yocto  General discussion list for the Yocto Project and
> >> 
> >>development for projects without dedicated lists
> >> 
> >> I think the yocto list is a bit problematic in that it mixes project
> >> conceptual discussion, user help desk, and development all on the same
> >> list. However, I'm trying to clarify what these actually are here - not
> >> change anything.
> >> 
> >> yocto-ab   Yocto Project Advisory Board ???
> >> 
> >> This should imply the intended audience. Is it just meant for members?
> >> Is it meant as a way for non-AB members to observe what is going on?
> >> 
> >> yocto-advocacy Yocto Project advocacy & outreach AB subgroup
> >> 
> >> Same as above.
> >> 
> >> yocto-announce Announcements from the Yocto Project (low traffic)
> >> yocto-bsp  BSP Interest Group ???
> >> 
> >> There is no detailed description for this list, so I'm not sure what
> >> this is really about.
> >> 
> >> Yocto-builds   Build failures and discussion about the autobuilder
> >> 
> >> (includes typo fix, "build system" removed to avoid confusion with the
> >> "poky build system")
> >> 
> >> yocto-infrastructure   Infrastructure ???
> >> 
> >> Jefro or Michael, can you come up with something appropriate here?
> >> 
> >> 
> >> For lists where certain guidelines should be used in communications and
> >> patch submission, we should document that in the detailed description of
> >> the list, such as [project] tags for example.
> > 
> > This is all good stuff, I'd just like to mention in case it is useful that
> > I did update the list in the Reference Manual along with the information
> > on how to contribute - which includes some direction on where to send
> > patches. This is in the master version of the documentation but not the
> > version currently shown on the website - we probably ought to fix that.
> > We really ought to try to have all of this information consistent if at
> > all possible.
> 
> Does 

Re: [yocto] Documenting the mailing lists.

[Rifenbark, Scott M]

Here is what it says in the Reference Manual:

12.3. Mailing lists
There are a number of mailing lists maintained by the Yocto Project as well as 
related OpenEmbedded mailing lists for discussion, patch submission and 
announcements. To subscribe to one of the following mailing lists, click on the 
appropriate URL in the following list and follow the instructions: 
*   http://lists.yoctoproject.org/listinfo/yocto - General Yocto Project 
discussion mailing list. 
*   http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core - 
Discussion mailing list about OpenEmbedded-Core (the core metadata).
*   http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel 
- Discussion mailing list about OpenEmbedded.
*   http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel - 
Discussion mailing list about the BitBake build tool.
*   http://lists.yoctoproject.org/listinfo/poky - Discussion mailing list 
about Poky.
*   http://lists.yoctoproject.org/listinfo/yocto-announce - Mailing list to 
receive official Yocto Project release and milestone announcements.


This is what Paul is referring to by way of corrections.  I personally think it 
is useful to have something of a list in the Reference manual under this 
heading.  I don't think we need the exact same wordings though in the Reference 
manual as would be found in https://lists.yoctoproject.org/.  The stuff in the 
Reference manual should be general and give the reader an idea of the flavor of 
the lists.  I can update the reference manual to include a link to 
https://lists.yoctoproject.org/ for the final say on each list. 

Scott

-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com] 
Sent: Monday, August 20, 2012 2:28 PM
To: Paul Eggleton
Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker; Richard Purdie; Wold, 
Saul; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Denys Dmytriyenko; Koen 
Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
Subject: Re: Documenting the mailing lists.



On 08/20/2012 02:26 PM, Paul Eggleton wrote:
> On Monday 20 August 2012 11:43:38 Darren Hart wrote:
>> Scott,
>>
>> We've come across some more confusion about mailing lists recently. I've
>> sent a patch against poky to try and clear it up a bit in the source,
>> but we should also see about cleaning up the web descriptions of the lists.
>>
>> We have two pages that describe the lists:
>>
>> http://www.yoctoproject.org/community/mailing-lists
>> https://lists.yoctoproject.org/
>>
>> My first recommendation would be to eliminate
>> http://www.yoctoproject.org/community/mailing-lists and replace links to
>> it with links to https://lists.yoctoproject.org. This eliminates the
>> need to keep the CMS version in sync with the mailman page. The mailman
>> page should be considered the master anyway as the Description field is
>> taken directly from the list administrative settings.
>>
>> We should then work to create meaningful Descriptions of all the lists.
>> These should still fit on a single line, but I think we can improve on
>> what we have. For example:
>>
>> meta-ti  Mailing list for the meta-ti layer
>>
>> is not particularly enlightening. Perhaps something like:
>>
>> meta-ti  Usage and development of the meta-ti layer
>>
>> If we do this all at once, we can also ensure a consistent language,
>> tone, etc. I'll propose something for each list here and ask that
>> interested parties comment and correct in reply. Once agreed upon, the
>> admins of the respective lists can make the changes (all CC'd)
>>
>> Current:
>> 
>> linux-yocto  Development list for the linux-yocto*.git Linux kernel
>>  repositories
>> meta-ti  Mailing list for the meta-ti layer
>> poky Poky build system developer discussion & patch
>>  submission for meta-yocto
>> shoeleather  Neutral Board Lab Mailing List
>> yoctoDiscussion of all things Yocto
>> yocto-ab Yocto Project Advisory Board
>> yocto-advocacy   Yocto Project Advocacy & Outreach AB Subgroup
>> yocto-announce   Announcements from the Yocto Project
>> yocto-bspBSP Interest Group
>> Yocto-builds Build failures and discusion about the build system
>> yocto-infrastructure Infrastructure
>>
>>
>> Proposed:
>> =
>> linux-yocto  Development list for the linux-yocto*.git Linux kernel
>>  repositories
>> meta-ti  Usage and development list for the meta-ti layer
>> poky Usage and development list for the Poky build system
>>  (see README for patch submission)
>> shoeleather  Neutral Board Lab Mailing List
>>
>> I'm not sure what "neutral" is meant to convey. How about:
>>
>>  Discussion list for the Shoeleather embedded board lab
>>
>> yoctoGeneral discussion list for the Yocto Project and
>>  development for projects without dedicated lists
>>
>> I t

Re: [yocto] Documenting the mailing lists.

[Hudson, Sean]

> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Monday, August 20, 2012 1:44 PM
> To: Yocto Project
> Subject: Documenting the mailing lists.

> My first recommendation would be to eliminate
> http://www.yoctoproject.org/community/mailing-lists and replace links to
> it with links to https://lists.yoctoproject.org. This eliminates the
> need to keep the CMS version in sync with the mailman page. The mailman
> page should be considered the master anyway as the Description field is
> taken directly from the list administrative settings.
> 
> We should then work to create meaningful Descriptions of all the lists.
> These should still fit on a single line, but I think we can improve on
> what we have. For example:

> If we do this all at once, we can also ensure a consistent language,
> tone, etc. I'll propose something for each list here and ask that
> interested parties comment and correct in reply. Once agreed upon, the
> admins of the respective lists can make the changes (all CC'd)

[Hudson, Sean] Getting things more organized and topical sounds great to me.  
Thanks for bringing this up.

> Proposed:
> =
> shoeleather   Neutral Board Lab Mailing List
> 
> I'm not sure what "neutral" is meant to convey. How about:
> 
>   Discussion list for the Shoeleather embedded board lab
[Hudson, Sean] Sounds good to me. 

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

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, August 21, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

[Liu, Song]

Agenda:
 
* Opens collection - 5 min (Song)
* 1.3 Beta Program - 5 min (Song)
* Yocto 1.3 status  - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
* 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.
US Toll Free number: 
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.x76994298#
 
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-995 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai): 
>From office dial 8-995 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen): 
>From office dial 8-995 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities): 
>From IP phone dial 8-995
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 8995 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 
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  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



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

Re: [yocto] Documenting the mailing lists.

[Hudson, Sean]

> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Monday, August 20, 2012 2:28 PM

> Does it make sense to have this list in the reference manual? Should we
> perhaps just have it reference the README in the source (that way people
> can always see the current policy) and the long mailing list
> description? That reduces the redundancy to 2 from 4. Should be much
> easier to keep in sync.

[Hudson, Sean]
 Short answer:
   No it doesn't make sense to have the entire set in the reference manual, 
IMHO.
Longer answer:
  IMHO, the description of mailing lists is not useful unless you are connected 
to begin with and merely creates a place for maintenance without much value.   
With that said, I'd personally prefer to see a reference to a canonical 
location for mailing lists that is kept up to date in the reference manual 
and/or the README.

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

Re: [yocto] Documenting the mailing lists.

[Michael Halstead]

On 08/20/2012 02:40 PM, Hudson, Sean wrote:
>> -Original Message-
>> From: Darren Hart [mailto:dvh...@linux.intel.com]
>> Sent: Monday, August 20, 2012 1:44 PM
>> To: Yocto Project
>> Subject: Documenting the mailing lists.
>
> Proposed:
> =
> shoeleather   Neutral Board Lab Mailing List
>
> I'm not sure what "neutral" is meant to convey. How about:
>
>   Discussion list for the Shoeleather embedded board lab
> [Hudson, Sean] Sounds good to me. 
>
>
I've updated the description at https://lists.yoctoproject.org/

Michael Halstead
Yocto Project / Sys Admin




smime.p7s
Description: S/MIME Cryptographic Signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 02:34 PM, Rifenbark, Scott M wrote:
> Here is what it says in the Reference Manual:
> 
> 12.3. Mailing lists There are a number of mailing lists maintained by the
> Yocto Project as well as related OpenEmbedded mailing lists for discussion,
> patch submission and announcements. To subscribe to one of the following
> mailing lists, click on the appropriate URL in the following list and follow
> the instructions: 
> * http://lists.yoctoproject.org/listinfo/yocto - General Yocto Project 
> discussion mailing list. 
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core - 
> Discussion mailing list about OpenEmbedded-Core (the core metadata).
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel 
> - Discussion mailing list about OpenEmbedded.
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel - 
> Discussion mailing list about the BitBake build tool.
> * http://lists.yoctoproject.org/listinfo/poky - Discussion mailing list 
> about Poky.
> * http://lists.yoctoproject.org/listinfo/yocto-announce - Mailing list to 
> receive official Yocto Project release and milestone announcements.
> 
> 
> This is what Paul is referring to by way of corrections.  I personally think
> it is useful to have something of a list in the Reference manual under this
> heading.  I don't think we need the exact same wordings though in the
> Reference manual as would be found in https://lists.yoctoproject.org/.  The
> stuff in the Reference manual should be general and give the reader an idea of
> the flavor of the lists.  I can update the reference manual to include a link
> to https://lists.yoctoproject.org/ for the final say on each list. 

Hrm, a wrench in the works. It is necessary to include non-yoctoproject.org
mailing lists in order to fully document where all patches for "the Yocto
Project" should go. As such, we can't rely on the lists.yoctoproject.org as the
sole point of documentation. As such, as I see it, the sources README or
MAINTAINERS files should be the definitive policy setter regarding where to send
patches. Of course there is more to define than just that.

Perhaps the best we can do is update the descriptions in mailman for the yp
lists and update the mailing lists page with those and the external lists. Many
people will look to the mailing lists page on the yp website before they look in
the reference manual.

Thoughts?

--
Darren


> 
> Scott
> 
> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com] 
> Sent: Monday, August 20, 2012 2:28 PM
> To: Paul Eggleton
> Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker; Richard Purdie; Wold, 
> Saul; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Denys Dmytriyenko; 
> Koen Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
> Subject: Re: Documenting the mailing lists.
> 
> 
> 
> On 08/20/2012 02:26 PM, Paul Eggleton wrote:
>> On Monday 20 August 2012 11:43:38 Darren Hart wrote:
>>> Scott,
>>>
>>> We've come across some more confusion about mailing lists recently. I've
>>> sent a patch against poky to try and clear it up a bit in the source,
>>> but we should also see about cleaning up the web descriptions of the lists.
>>>
>>> We have two pages that describe the lists:
>>>
>>> http://www.yoctoproject.org/community/mailing-lists
>>> https://lists.yoctoproject.org/
>>>
>>> My first recommendation would be to eliminate
>>> http://www.yoctoproject.org/community/mailing-lists and replace links to
>>> it with links to https://lists.yoctoproject.org. This eliminates the
>>> need to keep the CMS version in sync with the mailman page. The mailman
>>> page should be considered the master anyway as the Description field is
>>> taken directly from the list administrative settings.
>>>
>>> We should then work to create meaningful Descriptions of all the lists.
>>> These should still fit on a single line, but I think we can improve on
>>> what we have. For example:
>>>
>>> meta-ti Mailing list for the meta-ti layer
>>>
>>> is not particularly enlightening. Perhaps something like:
>>>
>>> meta-ti Usage and development of the meta-ti layer
>>>
>>> If we do this all at once, we can also ensure a consistent language,
>>> tone, etc. I'll propose something for each list here and ask that
>>> interested parties comment and correct in reply. Once agreed upon, the
>>> admins of the respective lists can make the changes (all CC'd)
>>>
>>> Current:
>>> 
>>> linux-yocto Development list for the linux-yocto*.git Linux kernel
>>> repositories
>>> meta-ti Mailing list for the meta-ti layer
>>> pokyPoky build system developer discussion & patch
>>> submission for meta-yocto
>>> shoeleather Neutral Board Lab Mailing List
>>> yocto   Discussion of all things Yocto
>>> yocto-abYocto Project Advisory Board
>>> yocto-advocacy  Yocto Project Advocacy & Outrea

[yocto] [PATCH 1/3] meta-cedartrail: update SRCREV for Cedartrail machine branch

[rahul . saxena]

From: Rahul Saxena 

update SRCREV_machine_pn-linux-yocto_cedartrail

Signed-off-by: Rahul Saxena 
---
 .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend 
b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 7a0a2a3..48deb45 100644
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -15,9 +15,9 @@ KMACHINE_cedartrail-nopvr  = "cedartrail"
 KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
 KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
 
-SRCREV_machine_pn-linux-yocto_cedartrail ?= 
"81fd8c307997aff37916828dc8b4ef72f5d35a94"
+SRCREV_machine_pn-linux-yocto_cedartrail ?= 
"3b5b629560f2a36426c19f4f18e3633aa93c955e"
 SRCREV_meta_pn-linux-yocto_cedartrail ?= 
"46e8fc2bbbe73514e8d99101adaaa373f760ffa7"
 SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
"997f5644664b31ebefd6e16c451c4a3729eb378a"
 
-SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
"81fd8c307997aff37916828dc8b4ef72f5d35a94"
+SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
"3b5b629560f2a36426c19f4f18e3633aa93c955e"
 SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
"a4ac64fe873f08ef718e2849b88914725dc99c1c"
-- 
1.7.4.1

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

[yocto] [PATCH 3/3] meta-cedartrail: update PVR graphics driver to version 1.0.2

[rahul . saxena]

From: Rahul Saxena 

This update of the driver enables support for B3 stepping of Cedarview
processor and also support for DP/eDP ports.

Signed-off-by: Rahul Saxena 
---
 meta-cedartrail/README |2 +-
 .../xorg-driver/cdv-pvr-driver.inc |   37 -
 .../xorg-driver/cdv-pvr-driver_1.0.2.bb|  139 
 .../xorg-driver/cdv-pvr-driver_1.0.bb  |   99 --
 4 files changed, 140 insertions(+), 137 deletions(-)
 delete mode 100644 
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
 create mode 100644 
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
 delete mode 100644 
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb

diff --git a/meta-cedartrail/README b/meta-cedartrail/README
index 493e831..715cad9 100755
--- a/meta-cedartrail/README
+++ b/meta-cedartrail/README
@@ -61,7 +61,7 @@ Power VR Graphics user-space driver binaries are covered by a
 "Intel Free Distribution Binary License". The build of this driver
 can be enabled by adding the following line to the local.conf file:
 
-LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0"
+LICENSE_FLAGS_WHITELIST += "license_cdv-pvr-driver_1.0.2"
 
 To enable the layer that does not support Power VR graphics
 add the following to the local.conf file:
diff --git a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc 
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
deleted file mode 100644
index 787c1fb..000
--- a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
+++ /dev/null
@@ -1,37 +0,0 @@
-SUMMARY = "Cedartrail PowerVR Graphics Driver version [Gold] 1.0 binaries"
-DESCRIPTION = "2D, 3D and Media user space driver for Cedartrail platform \
-The binaries are covered by the Intel Free Distribution Binary License. \ 
-The user must make himself/herself aware of the Licensing terms \
-before enabling build of the Cedartrail PowerVR Graphics Driver via \
-this recipe.  Please see the README in meta-cedartrail for instructions \
-for enabling the build of the driver "
- 
-LICENSE_FLAGS = "license_${PN}_${PV}"
-LICENSE = "Intel Free Distribution Binary License"
-
-LIC_FILES_CHKSUM = " \
-
file://${S}/usr/share/doc/psb-video-cdv-0.16/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
  \
-
file://${S}/usr/share/doc/pvr-bin-cdv-1.7.788837_10/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65"
-
-INC_PR = "r1"
-
-DEPENDS = "rpm-native"
-
-FILES_${PN} += "${libdir}/dri ${libdir}/pvr/cdv/dri ${libdir}/pvr/cdv 
${libdir}/xorg/modules/drivers"
-FILES_${PN}-dev += "${libdir}/dri ${libdir}/pvr/cdv/dri 
${libdir}/xorg/modules/drivers"
-FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug ${libdir}/dri/.debug 
${libdir}/pvr/cdv/dri/.debug"
-
-FILES_${PN} += "${base_libdir}/firmware"
-FILES_${PN} += "${sysconfdir}/X11/xorg.conf.d"
-
-FILES_${PN} += "${libdir}/lib*.so"
-FILES_${PN}-dev += "${libdir}/lib*.so"
-FILES_${PN}-dbg += "${libdir}/.debug"
-
-FILES_${PN} += "${libdir}/pvr/cdv/xorg/modules/drivers"
-
-FILES_${PN} += "${datadir}/doc/psb-video-cdv-0.16/license.txt"
-FILES_${PN} += "${datadir}/doc/pvr-bin-cdv-1.7.788837_10/license.txt"
-
-
-
diff --git 
a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb 
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
new file mode 100644
index 000..f91b235
--- /dev/null
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
@@ -0,0 +1,139 @@
+SUMMARY = "Cedartrail PowerVR Graphics Driver version 1.0.2 binaries"
+DESCRIPTION = "2D, 3D and Media user space driver for Cedartrail platform \
+The binaries are covered by the Intel Free Distribution Binary License. \ 
+The user must make himself/herself aware of the Licensing terms \
+before enabling build of the Cedartrail PowerVR Graphics Driver via \
+this recipe.  Please see the README in meta-cedartrail for instructions \
+for enabling the build of the driver "
+ 
+LICENSE_FLAGS = "license_${PN}_${PV}"
+LICENSE = "Intel Free Distribution Binary License"
+LIC_FILES_CHKSUM = " \
+
file://${S}/usr/share/doc/psb-video-cdv-${PSB-VIDEO-REV}/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
  \
+
file://${S}/usr/share/doc/pvr-bin-cdv-${PVR-BIN-REV_N}/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65"
+
+DEPENDS = "rpm-native libva"
+
+PR = "r0"
+
+PSB-VIDEO = "psb-video-cdv-0.17-2.1.i586.rpm"
+PSB-VIDEO-REV = "0.17"
+
+PVR-BIN = "pvr-bin-cdv-1.7.862890_05-1.1.i586.rpm"
+PVR-BIN-REV = "1.7.862890"
+PVR-BIN-REV_N = "1.7.862890_05"
+
+LIBWSBM = "libwsbm-cdv-1.1.0-3.1.i586.rpm"
+
+
+NON-OSS-PATH = 
"http://repo.meego.com/MeeGo/builds/1.2.0/1.2.0.10.1.20120723.1/repos/non-oss/ia32/packages/";
+OSS-PATH = 
"http://repo.meego.com/MeeGo/updates/1.2.0/repos/oss/ia32/packages/";
+
+
+SRC_URI = "${NON-OSS-PATH}${PSB-VIDEO};name=psbrpm \
+  ${NON-OSS-PATH}${PVR-BIN};name=pvrrpm \
+  ${OSS-PATH}${LIBW

[yocto] [PATCH 2/3] meta-cedartrail: update SRCREV for yocto kernel pvr branch

[rahul . saxena]

From: Rahul Saxena 

Update SRCREV to point to yocto/pvr kernel branch with v1.0.2  pvr driver 
support

Signed-off-by: Rahul Saxena 
---
 .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend 
b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 48deb45..682aa08 100644
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -17,7 +17,7 @@ KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
 
 SRCREV_machine_pn-linux-yocto_cedartrail ?= 
"3b5b629560f2a36426c19f4f18e3633aa93c955e"
 SRCREV_meta_pn-linux-yocto_cedartrail ?= 
"46e8fc2bbbe73514e8d99101adaaa373f760ffa7"
-SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
"997f5644664b31ebefd6e16c451c4a3729eb378a"
+SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
"7828ab82533828b924dbfad5158e274a8bb04df3"
 
 SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
"3b5b629560f2a36426c19f4f18e3633aa93c955e"
 SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
"a4ac64fe873f08ef718e2849b88914725dc99c1c"
-- 
1.7.4.1

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

[yocto] [PATCH 0/3][meta-intel] Cover letter to update pvr driver to v1.0.2 in meta-cedartrail

[rahul . saxena]

From: Rahul Saxena 

Cover letter to update pvr driver to v1.0.2 in meta-cedartrail

This update of the driver supports B3 stepping of the Cedarview processor and 
also
supports DP/eDP ports.

Signed-off-by: Rahul Saxena  
--
The following changes since commit 2552a046878e4352595f6e081ad371538cceda10:

  meta-n450: explicitly specify KBRANCH we expect to use (2012-07-12 16:32:58 
-0500)

are available in the git repository at:
  git://git.pokylinux.org/meta-intel-contrib rsaxena/denzelv102aug20OK
  
http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena/denzelv102aug20OK

Rahul Saxena (3):
  meta-cedartrail: update SRCREV for Cedartrail machine branch
  meta-cedartrail: update SRCREV for yocto kernel pvr branch
  meta-cedartrail: update PVR graphics driver to version 1.0.2

 meta-cedartrail/README |2 +-
 .../xorg-driver/cdv-pvr-driver.inc |   37 -
 .../xorg-driver/cdv-pvr-driver_1.0.2.bb|  139 
 .../xorg-driver/cdv-pvr-driver_1.0.bb  |   99 --
 .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |6 +-
 5 files changed, 143 insertions(+), 140 deletions(-)
 delete mode 100644 
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
 create mode 100644 
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
 delete mode 100644 
meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb

-- 
1.7.4.1

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

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 02:56 PM, Michael Halstead wrote:
> On 08/20/2012 02:40 PM, Hudson, Sean wrote:
>>> -Original Message-
>>> From: Darren Hart [mailto:dvh...@linux.intel.com]
>>> Sent: Monday, August 20, 2012 1:44 PM
>>> To: Yocto Project
>>> Subject: Documenting the mailing lists.
>>
>> Proposed:
>> =
>> shoeleather  Neutral Board Lab Mailing List
>>
>> I'm not sure what "neutral" is meant to convey. How about:
>>
>>  Discussion list for the Shoeleather embedded board lab
>> [Hudson, Sean] Sounds good to me. 
>>
>>
> I've updated the description at https://lists.yoctoproject.org/
> 

Thanks Michael, let's hold off on any additional changes until we've
been able to agree on the entire set, as we want to keep language,
tense, etc. consistent. No need to change them multiple times.

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

Re: [yocto] [PATCH 1/3] meta-cedartrail: update SRCREV for Cedartrail machine branch

[Darren Hart]

On 08/20/2012 02:52 PM, rahul.sax...@intel.com wrote:
> From: Rahul Saxena 
> 
> update SRCREV_machine_pn-linux-yocto_cedartrail

These typically include a reason for the update. Are you just bringing
it up to the most recent update from Bruce or is this to include some
update that you pushed to the cedartrail branch?

--
Darren

> 
> Signed-off-by: Rahul Saxena 
> ---
>  .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend 
> b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> index 7a0a2a3..48deb45 100644
> --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> @@ -15,9 +15,9 @@ KMACHINE_cedartrail-nopvr  = "cedartrail"
>  KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
>  KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
>  
> -SRCREV_machine_pn-linux-yocto_cedartrail ?= 
> "81fd8c307997aff37916828dc8b4ef72f5d35a94"
> +SRCREV_machine_pn-linux-yocto_cedartrail ?= 
> "3b5b629560f2a36426c19f4f18e3633aa93c955e"
>  SRCREV_meta_pn-linux-yocto_cedartrail ?= 
> "46e8fc2bbbe73514e8d99101adaaa373f760ffa7"
>  SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
> "997f5644664b31ebefd6e16c451c4a3729eb378a"
>  
> -SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
> "81fd8c307997aff37916828dc8b4ef72f5d35a94"
> +SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
> "3b5b629560f2a36426c19f4f18e3633aa93c955e"
>  SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
> "a4ac64fe873f08ef718e2849b88914725dc99c1c"
> 

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

Re: [yocto] [PATCH 1/3] meta-cedartrail: update SRCREV for Cedartrail machine branch

[Saxena, Rahul]

I am just bringing it up to a most recent update from Bruce. Nothing pushed 
from my side to cedartrail branch.

Thanks
Rahul

-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com] 
Sent: Monday, August 20, 2012 3:09 PM
To: Saxena, Rahul
Cc: yocto@yoctoproject.org; Zanussi, Tom
Subject: Re: [PATCH 1/3] meta-cedartrail: update SRCREV for Cedartrail machine 
branch



On 08/20/2012 02:52 PM, rahul.sax...@intel.com wrote:
> From: Rahul Saxena 
> 
> update SRCREV_machine_pn-linux-yocto_cedartrail

These typically include a reason for the update. Are you just bringing it up to 
the most recent update from Bruce or is this to include some update that you 
pushed to the cedartrail branch?

--
Darren

> 
> Signed-off-by: Rahul Saxena 
> ---
>  .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend 
> b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> index 7a0a2a3..48deb45 100644
> --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> @@ -15,9 +15,9 @@ KMACHINE_cedartrail-nopvr  = "cedartrail"
>  KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
>  KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
>  
> -SRCREV_machine_pn-linux-yocto_cedartrail ?= 
> "81fd8c307997aff37916828dc8b4ef72f5d35a94"
> +SRCREV_machine_pn-linux-yocto_cedartrail ?= 
> "3b5b629560f2a36426c19f4f18e3633aa93c955e"
>  SRCREV_meta_pn-linux-yocto_cedartrail ?= 
> "46e8fc2bbbe73514e8d99101adaaa373f760ffa7"
>  SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
> "997f5644664b31ebefd6e16c451c4a3729eb378a"
>  
> -SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
> "81fd8c307997aff37916828dc8b4ef72f5d35a94"
> +SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
> "3b5b629560f2a36426c19f4f18e3633aa93c955e"
>  SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= 
> "a4ac64fe873f08ef718e2849b88914725dc99c1c"
> 

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

Re: [yocto] Documenting the mailing lists.

[Jeff Osier-Mixon]

The mailing lists and website stuff is generally my responsibility,
but please fix anything you like. :)  Be aware that the new website is
under construction, so I am loathe to change much on the old website
at this point.  For the new one, it may be possible to dynamically
grab the description from mailman.

On Mon, Aug 20, 2012 at 3:06 PM, Darren Hart  wrote:
>
>
> On 08/20/2012 02:56 PM, Michael Halstead wrote:
>> On 08/20/2012 02:40 PM, Hudson, Sean wrote:
 -Original Message-
 From: Darren Hart [mailto:dvh...@linux.intel.com]
 Sent: Monday, August 20, 2012 1:44 PM
 To: Yocto Project
 Subject: Documenting the mailing lists.
>>>
>>> Proposed:
>>> =
>>> shoeleather  Neutral Board Lab Mailing List
>>>
>>> I'm not sure what "neutral" is meant to convey. How about:
>>>
>>>  Discussion list for the Shoeleather embedded board lab
>>> [Hudson, Sean] Sounds good to me.
>>>
>>>
>> I've updated the description at https://lists.yoctoproject.org/
>>
>
> Thanks Michael, let's hold off on any additional changes until we've
> been able to agree on the entire set, as we want to keep language,
> tense, etc. consistent. No need to change them multiple times.
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Kernel
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting the mailing lists.

[Rifenbark, Scott M]

Since the YP Reference Manual is the reference manual for YP I think we should 
retain the 12.3 section about mailing lists.  That said, maybe we should only 
list by name the general Yocto project discussion mailing list and then refer 
the reader to https://lists.yoctoproject.org/ for all related lists.  I still 
feel that we should have the general discussion mailing list at least named in 
the YP Reference Manual.

Scott

-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com] 
Sent: Monday, August 20, 2012 3:04 PM
To: Rifenbark, Scott M
Cc: Paul Eggleton; Yocto Project; Paul Gortmaker; Richard Purdie; Wold, Saul; 
Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Denys Dmytriyenko; Koen Kooi; 
Jason Kridner; Flanagan, Elizabeth; Michael Halstead
Subject: Re: Documenting the mailing lists.



On 08/20/2012 02:34 PM, Rifenbark, Scott M wrote:
> Here is what it says in the Reference Manual:
> 
> 12.3. Mailing lists There are a number of mailing lists maintained by the
> Yocto Project as well as related OpenEmbedded mailing lists for discussion,
> patch submission and announcements. To subscribe to one of the following
> mailing lists, click on the appropriate URL in the following list and follow
> the instructions: 
> * http://lists.yoctoproject.org/listinfo/yocto - General Yocto Project 
> discussion mailing list. 
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core - 
> Discussion mailing list about OpenEmbedded-Core (the core metadata).
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel 
> - Discussion mailing list about OpenEmbedded.
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel - 
> Discussion mailing list about the BitBake build tool.
> * http://lists.yoctoproject.org/listinfo/poky - Discussion mailing list 
> about Poky.
> * http://lists.yoctoproject.org/listinfo/yocto-announce - Mailing list to 
> receive official Yocto Project release and milestone announcements.
> 
> 
> This is what Paul is referring to by way of corrections.  I personally think
> it is useful to have something of a list in the Reference manual under this
> heading.  I don't think we need the exact same wordings though in the
> Reference manual as would be found in https://lists.yoctoproject.org/.  The
> stuff in the Reference manual should be general and give the reader an idea of
> the flavor of the lists.  I can update the reference manual to include a link
> to https://lists.yoctoproject.org/ for the final say on each list. 

Hrm, a wrench in the works. It is necessary to include non-yoctoproject.org
mailing lists in order to fully document where all patches for "the Yocto
Project" should go. As such, we can't rely on the lists.yoctoproject.org as the
sole point of documentation. As such, as I see it, the sources README or
MAINTAINERS files should be the definitive policy setter regarding where to send
patches. Of course there is more to define than just that.

Perhaps the best we can do is update the descriptions in mailman for the yp
lists and update the mailing lists page with those and the external lists. Many
people will look to the mailing lists page on the yp website before they look in
the reference manual.

Thoughts?

--
Darren


> 
> Scott
> 
> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com] 
> Sent: Monday, August 20, 2012 2:28 PM
> To: Paul Eggleton
> Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker; Richard Purdie; Wold, 
> Saul; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Denys Dmytriyenko; 
> Koen Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
> Subject: Re: Documenting the mailing lists.
> 
> 
> 
> On 08/20/2012 02:26 PM, Paul Eggleton wrote:
>> On Monday 20 August 2012 11:43:38 Darren Hart wrote:
>>> Scott,
>>>
>>> We've come across some more confusion about mailing lists recently. I've
>>> sent a patch against poky to try and clear it up a bit in the source,
>>> but we should also see about cleaning up the web descriptions of the lists.
>>>
>>> We have two pages that describe the lists:
>>>
>>> http://www.yoctoproject.org/community/mailing-lists
>>> https://lists.yoctoproject.org/
>>>
>>> My first recommendation would be to eliminate
>>> http://www.yoctoproject.org/community/mailing-lists and replace links to
>>> it with links to https://lists.yoctoproject.org. This eliminates the
>>> need to keep the CMS version in sync with the mailman page. The mailman
>>> page should be considered the master anyway as the Description field is
>>> taken directly from the list administrative settings.
>>>
>>> We should then work to create meaningful Descriptions of all the lists.
>>> These should still fit on a single line, but I think we can improve on
>>> what we have. For example:
>>>
>>> meta-ti Mailing list for the meta-ti layer
>>>
>>> is not particularly enlightening. Perhaps something like:
>>>
>>> meta-ti Usage and develop

Re: [yocto] [PATCH 0/3][meta-intel] Cover letter to update pvr driver to v1.0.2 in meta-cedartrail

[Darren Hart]

On 08/20/2012 02:52 PM, rahul.sax...@intel.com wrote:
> From: Rahul Saxena 
> 
> Cover letter to update pvr driver to v1.0.2 in meta-cedartrail
> 
> This update of the driver supports B3 stepping of the Cedarview processor and 
> also
> supports DP/eDP ports.
> 
> Signed-off-by: Rahul Saxena  


Applied to Denzil branch.

Thanks

> --
> The following changes since commit 2552a046878e4352595f6e081ad371538cceda10:
> 
>   meta-n450: explicitly specify KBRANCH we expect to use (2012-07-12 16:32:58 
> -0500)
> 
> are available in the git repository at:
>   git://git.pokylinux.org/meta-intel-contrib rsaxena/denzelv102aug20OK
>   
> http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena/denzelv102aug20OK
> 
> Rahul Saxena (3):
>   meta-cedartrail: update SRCREV for Cedartrail machine branch
>   meta-cedartrail: update SRCREV for yocto kernel pvr branch
>   meta-cedartrail: update PVR graphics driver to version 1.0.2
> 
>  meta-cedartrail/README |2 +-
>  .../xorg-driver/cdv-pvr-driver.inc |   37 -
>  .../xorg-driver/cdv-pvr-driver_1.0.2.bb|  139 
> 
>  .../xorg-driver/cdv-pvr-driver_1.0.bb  |   99 --
>  .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |6 +-
>  5 files changed, 143 insertions(+), 140 deletions(-)
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver.inc
>  create mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.2.bb
>  delete mode 100644 
> meta-cedartrail/recipes-graphics/xorg-driver/cdv-pvr-driver_1.0.bb
> 

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

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
> The mailing lists and website stuff is generally my responsibility,
> but please fix anything you like. :)  Be aware that the new website is

No intent to take over anything, I've just had to answer the "what goes
where" question a few too many times these last couple of weeks and felt
I should do something about it :-)

I made sure you were on CC so you could help guide this.

> under construction, so I am loathe to change much on the old website
> at this point.  For the new one, it may be possible to dynamically
> grab the description from mailman.

We'll still need descriptions of the non-yocto-project lists, so that
may not be particularly helpful.

--
Darren

> 
> On Mon, Aug 20, 2012 at 3:06 PM, Darren Hart  wrote:
>>
>>
>> On 08/20/2012 02:56 PM, Michael Halstead wrote:
>>> On 08/20/2012 02:40 PM, Hudson, Sean wrote:
> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Monday, August 20, 2012 1:44 PM
> To: Yocto Project
> Subject: Documenting the mailing lists.

 Proposed:
 =
 shoeleather  Neutral Board Lab Mailing List

 I'm not sure what "neutral" is meant to convey. How about:

  Discussion list for the Shoeleather embedded board lab
 [Hudson, Sean] Sounds good to me.


>>> I've updated the description at https://lists.yoctoproject.org/
>>>
>>
>> Thanks Michael, let's hold off on any additional changes until we've
>> been able to agree on the entire set, as we want to keep language,
>> tense, etc. consistent. No need to change them multiple times.
>>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>> Yocto Project - Technical Lead - Linux Kernel
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 

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

Re: [yocto] Documenting the mailing lists.

[Jeff Osier-Mixon]

On Mon, Aug 20, 2012 at 3:37 PM, Darren Hart  wrote:
> On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
>> The mailing lists and website stuff is generally my responsibility,
>> but please fix anything you like. :)  Be aware that the new website is
>
> No intent to take over anything, I've just had to answer the "what goes
> where" question a few too many times these last couple of weeks and felt
> I should do something about it :-)

Oh, I'm not joking - please fix anything you want! or Scott or I can
do it. Thanks for getting the ball rolling. I'll catch up on this
thread.

> I made sure you were on CC so you could help guide this.
>
>> under construction, so I am loathe to change much on the old website
>> at this point.  For the new one, it may be possible to dynamically
>> grab the description from mailman.
>
> We'll still need descriptions of the non-yocto-project lists, so that
> may not be particularly helpful.

The only YP-related, non-YP lists I currently track are
openembedded-core and bitbake-devel.  Both are OE lists, and I have
recently volunteered to help admin, so can make sure they have valid
Descriptions. If there are other lists we should track, please let me
know and I'll add them to the pile.

>
> --
> Darren
>
>>
>> On Mon, Aug 20, 2012 at 3:06 PM, Darren Hart  wrote:
>>>
>>>
>>> On 08/20/2012 02:56 PM, Michael Halstead wrote:
 On 08/20/2012 02:40 PM, Hudson, Sean wrote:
>> -Original Message-
>> From: Darren Hart [mailto:dvh...@linux.intel.com]
>> Sent: Monday, August 20, 2012 1:44 PM
>> To: Yocto Project
>> Subject: Documenting the mailing lists.
>
> Proposed:
> =
> shoeleather  Neutral Board Lab Mailing List
>
> I'm not sure what "neutral" is meant to convey. How about:
>
>  Discussion list for the Shoeleather embedded board lab
> [Hudson, Sean] Sounds good to me.
>
>
 I've updated the description at https://lists.yoctoproject.org/

>>>
>>> Thanks Michael, let's hold off on any additional changes until we've
>>> been able to agree on the entire set, as we want to keep language,
>>> tense, etc. consistent. No need to change them multiple times.
>>>
>>> --
>>> Darren Hart
>>> Intel Open Source Technology Center
>>> Yocto Project - Technical Lead - Linux Kernel
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Technical Lead - Linux Kernel



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 03:43 PM, Jeff Osier-Mixon wrote:
> On Mon, Aug 20, 2012 at 3:37 PM, Darren Hart  wrote:
>> On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
>>> The mailing lists and website stuff is generally my responsibility,
>>> but please fix anything you like. :)  Be aware that the new website is
>>
>> No intent to take over anything, I've just had to answer the "what goes
>> where" question a few too many times these last couple of weeks and felt
>> I should do something about it :-)
> 
> Oh, I'm not joking - please fix anything you want! or Scott or I can
> do it. Thanks for getting the ball rolling. I'll catch up on this
> thread.
> 
>> I made sure you were on CC so you could help guide this.
>>
>>> under construction, so I am loathe to change much on the old website
>>> at this point.  For the new one, it may be possible to dynamically
>>> grab the description from mailman.
>>
>> We'll still need descriptions of the non-yocto-project lists, so that
>> may not be particularly helpful.
> 
> The only YP-related, non-YP lists I currently track are
> openembedded-core and bitbake-devel.  Both are OE lists, and I have
> recently volunteered to help admin, so can make sure they have valid
> Descriptions. If there are other lists we should track, please let me
> know and I'll add them to the pile.
> 

The only additional one that we reference in the manual is:

*   http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
- Discussion mailing list about OpenEmbedded.

I'm not sure we need reference it at all though, perhaps oe-core is
sufficient.

--
Darren

>>
>> --
>> Darren
>>
>>>
>>> On Mon, Aug 20, 2012 at 3:06 PM, Darren Hart  wrote:


 On 08/20/2012 02:56 PM, Michael Halstead wrote:
> On 08/20/2012 02:40 PM, Hudson, Sean wrote:
>>> -Original Message-
>>> From: Darren Hart [mailto:dvh...@linux.intel.com]
>>> Sent: Monday, August 20, 2012 1:44 PM
>>> To: Yocto Project
>>> Subject: Documenting the mailing lists.
>>
>> Proposed:
>> =
>> shoeleather  Neutral Board Lab Mailing List
>>
>> I'm not sure what "neutral" is meant to convey. How about:
>>
>>  Discussion list for the Shoeleather embedded board lab
>> [Hudson, Sean] Sounds good to me.
>>
>>
> I've updated the description at https://lists.yoctoproject.org/
>

 Thanks Michael, let's hold off on any additional changes until we've
 been able to agree on the entire set, as we want to keep language,
 tense, etc. consistent. No need to change them multiple times.

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

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

[yocto] [eclipse-poky][PATCH] setup.py: Change main eclipse SDK repo to point to yocto

[Flanagan, Elizabeth]

The main eclipse download site has been hard to connect to
for many users. This sets up the main setup script to use a
mirror of the eclipse tarballs.

One note of importance here, is that we will have to maintain
a mirror of all SDK releases we wish to utilize.

Signed-off-by: Elizabeth Flanagan 
---
 scripts/setup.sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/setup.sh b/scripts/setup.sh
index 5a928f4..b7e2a54 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -66,7 +66,7 @@ if [ ! -f
eclipse/plugins/org.eclipse.swt_3.100.0.v4233d.jar ]; then
   fi
   # Eclipse SDK: Need the SDK so we can link into docs
   echo "Getting Eclipse SDK..."
-  wget "
http://download.eclipse.org/eclipse/downloads/drops4/${ep_rel}${ep_ver}${ep_date}/eclipse-SDK-${ep_ver}-${ep_arch}.tar.gz
"
+  wget "
http://downloads.yoctoproject.org/eclipse/downloads/drops4/${ep_rel}${ep_ver}${ep_date}/eclipse-SDK-${ep_ver}-${ep_arch}.tar.gz
"
   tar xfz eclipse-SDK-${ep_ver}-${ep_arch}.tar.gz || err_exit $?
"extracting Eclipse SDK failed"
   rm eclipse-SDK-${ep_ver}-${ep_arch}.tar.gz
   cd "${curdir2}"
-- 
1.7.5.4

-- 
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting the mailing lists.

[Paul Eggleton]

On Monday 20 August 2012 15:50:37 Darren Hart wrote:
> On 08/20/2012 03:43 PM, Jeff Osier-Mixon wrote:
> > On Mon, Aug 20, 2012 at 3:37 PM, Darren Hart  
wrote:
> >> On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
> >>> The mailing lists and website stuff is generally my responsibility,
> >>> but please fix anything you like. :)  Be aware that the new website is
> >> 
> >> No intent to take over anything, I've just had to answer the "what goes
> >> where" question a few too many times these last couple of weeks and felt
> >> I should do something about it :-)
> > 
> > Oh, I'm not joking - please fix anything you want! or Scott or I can
> > do it. Thanks for getting the ball rolling. I'll catch up on this
> > thread.
> > 
> >> I made sure you were on CC so you could help guide this.
> >> 
> >>> under construction, so I am loathe to change much on the old website
> >>> at this point.  For the new one, it may be possible to dynamically
> >>> grab the description from mailman.
> >> 
> >> We'll still need descriptions of the non-yocto-project lists, so that
> >> may not be particularly helpful.
> > 
> > The only YP-related, non-YP lists I currently track are
> > openembedded-core and bitbake-devel.  Both are OE lists, and I have
> > recently volunteered to help admin, so can make sure they have valid
> > Descriptions. If there are other lists we should track, please let me
> > know and I'll add them to the pile.
> 
> The only additional one that we reference in the manual is:
> 
> * http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> - Discussion mailing list about OpenEmbedded.
> 
> I'm not sure we need reference it at all though, perhaps oe-core is
> sufficient.

FYI, the reason I added oe-devel is because it's the list that is used to 
discuss/submit patches for almost all OE community layers other than OE-Core 
and the ones that are hosted on yoctoproject.org.

Cheers,
Paul

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

[yocto] Classes

[Seth Bollinger]

Hello,

Will anyone recommend some classes regarding yocto and open embedded?  It
would be nice to get up to speed quickly and into the nitty gritty instead
of an overview.

Something covering the following items would be nice:

1.  How should projects be laid out?  Distro, image, task, BSP, what things
should go where?
2.  How should subprojects inherit from superprojects?  If you need to
create many subplatforms from a base platform, what's the best way to go
about this?
3.  How should classes such as distutils be created to be inherited by
other recipes (ruby modules that require a C extension to be compiled would
be one example).
4.  How should hardware specific software be handled?

I fear that (as a newb) I will design a layout that will be sub-optimal,
but we'll discover that after we have 25 platforms that will need major
refactoring.  :)

Thanks,

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

Re: [yocto] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

[Bruce Ashfield]

On 12-08-20 5:06 PM, Darren Hart wrote:

On 08/20/2012 01:35 PM, Bruce Ashfield wrote:

On 12-08-20 04:31 PM, Liu, Song wrote:

Hi Darren/Bruce,

Is there anything else that needs to be done for this one? If not, would
you please close it?


It was waiting on a few comments, but it made M3, so I'll take
care of updating it once more and closing the item later today or
early tomorrow.


So sorry... too many things cooking...


bah, no worries. Reviews aren't exactly fun :)



So a review...


diff --git a/00-README b/00-README
index 96a0f7d..ec933cc 100644
--- a/00-README
+++ b/00-README
@@ -1,3 +1,197 @@
+1.0 Overview
+
+
+The linux-yocto kernel is composed of additions/modifications to the
+kernel.org source, plus configuration/control data to manage and use those
+changes.
+
+Source code changes are seen as git commits to the kernel source tree, are
+arranged into features (sometimes) separated by branches and marked by tags.
+
+The configuration and control data is contained within a separate branch from
+source changes called the meta branch. The configuration data is contained
+within the kernel-cache directory structure, and represents the instructions
+to modify the source tree and the configuration policies required to configure
+and build the kernel.
+
+While changes to the source code have already been applied to the tree, the
+control and configuration data is used before and during the kernel build
+process to generate a valid kernel config.
+
+This README explains the configuration data and policies around the
+organization of this information, it is not a guide to tree construction, scc
+file syntax or linux-yocto architecture.
+
+2.0 Configuration Policy
+
+
+The configuration data contained within the meta branch has the following
+purposes:
+
+ - Documents and defines hardware, non-hardware, required and optional
+ configuration data that are used to keep software configuration policy
+ and board support configuration separate. It also tags configuration data
+ in a manner that an audit can be performed to ensure that polices make it
+ t[M#&/o the final .config and that required options are not overridden or


  ^ some junk snuck in here it seems


indeed. We call that "edited in emacs in screen .. equals some random
control characters with lag and arrow keys!". I'll yank that out.




+ dropped from the final .config.
+
+ - Creates a baseline configuration that can be inherited/included to result
+ in consistent configuration across all derived kernel builds
+
+ - Groups patches and their configuration data into documented features. The
+ proper configuration and enablement of a kernel change is coupled with the
+ patches that make the change to the source.
+
+ - Creates named feature fragments that when included enable the required
+ options to implement a specific behaviour (i.e. USB boot)
+
+ - Define BSPs (Board Support Packages) (machines) that select a policy


Should be "Defines" to be consistent with previous paragraphs...


Agreed.




+ (features + config) and hardware options to form a buildable, bootable
+ configuration.
+
+The policy that is contained within the meta branch can be overridden by


s/policy/policies/ ?


Deer, Deers, Moose, Meese .. but yah, this can be policies. Changed.




+external descriptions using the same description format as the meta branch
+configuration. This allows for flexible modification and extension of the
+base policy. Also, if a previously defined BSP configuration is modified, it
+can be audited against the software policy to generate a compliance report.
+
+2.1 Kernel types (ktypes)


Types ("Title Caps" should be used in section headings for consistency -
applies throughout)


/me hates capital letters, but I agree. Changed.


KTYPE should probably always be capitalized?


Assuming that I want to map it directly to the recipe variable and the
define  in the .scc files, it would be capitalized. But I'm not
sure about this one, I'll add a mention that these are "define KTYPE "
in the .scc files at a minimum.




+-
+
+Kernel types (ktypes) are the highest level policy containers and represent
+a significant set of kernel functionality that has been grouped (and named)
+or partitioned.


What are you trying to convey with "partitioned" vs. "grouped" ? The
"or" indicates a functional difference, but it isn't clear what that is
from this reading.


partitioned means that they are really being kept apart since they won't
work together (think BFS vs CFS, or grsec vs another security patch). 
Grouped

just means that you have 15 or 20 things that you want to collectively
call a "kernel type" and validate that they work together in a particular
configuration. But there's no fundamental incompatibility between these
features and others in the system.

It's a hard vs soft partitioning.

Would the expansion that I have above help ?




+
+There are often significant differences between