Re: [yocto] [meta-raspberrypi] linux kernel rt

2018-01-26 Thread Martin Hundebøll 



On 2018-01-26 04:51, Khem Raj wrote:


Secondly, I wonder how good is upstream mainline kernel for rpi now a 
days, we could always have a mainline recipe as an option and use it as 
base for things like rt.


Apart from runtime device tree overlay support for RPi hats/extension 
boards, mainline linux fully supports each RPi revision.


I guess linux-yocto-rt would be just fine...

--
MARTIN HUNDEBØLL, Prevas A/S
Software Developer

Hedeager 3, DK-8200 Aarhus N
Phone +45 87438070
Mobile +45 25562438
martin.hundeb...@prevas.dk
www.prevas.com
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] how the linux-raspberry skip the do_kernel_metadata?

2018-01-26 Thread kk 
I see the linux-raspberrypi_4.9.bb recipe didn't use the
yocto-kernel-cache, and add configure in linux-raspberrypi.inc, I am
interested in how the linux-raspberry skip the do_kernel_metadata?

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

[yocto] adding meta-virtualization gives bitbake error

2018-01-26 Thread Jakob Hasse 

Hello,

we're trying to include meta-virtualization in to our project, in 
particular, we want to use docker. However, as soon as I include the 
layer in to our project, bitbake complains:


bitbake -C compile core-image-base
NOTE: Started PRServer with DBfile: 
/home/jakob/workspace/beerstation/cache/prserv.sqlite3, IP: 127.0.0.1, 
PORT: 46136, PID: 5713

ERROR: Execution of event handler 'virt_bbappend_distrocheck' failed
Traceback (most recent call last):
  File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck(e=0x7f945e05d3c8>):

 python virt_bbappend_distrocheck() {
    >    skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
 if 'virtualization' not in 
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:

TypeError: getVar() missing 1 required positional argument: 'expand'

ERROR: Command execution failed: Traceback (most recent call last):
  File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/command.py", 
line 101, in runAsyncCommand

    self.cooker.updateCache()
  File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/cooker.py", line 
1627, in updateCache
    bb.event.fire(bb.event.SanityCheck(False), 
self.databuilder.mcdata[mc])
  File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
201, in fire

    fire_class_handlers(event, d)
  File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
124, in fire_class_handlers

    execute_handler(name, handler, event, d)
  File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
96, in execute_handler

    ret = handler(event)
  File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck

    skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
TypeError: getVar() missing 1 required positional argument: 'expand'


Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


Do we need to checkout a specific branch or so (though I can't find one 
right now)?
Do we need to change some kernel configuration? I added all 
virtualization drivers in the "drivers" section of the kernel config 
already.


We're using DIGI embedded Yocto 2.2 (poky).

Thanks and all the best,
Jakob

--
Jakob Hasse
Software Developement

E: jakob.ha...@smart-home-technology.ch
T: +41 44 552 02 66

Smart Home Technology GmbH
www.smart-home-technology.ch

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

Re: [yocto] adding meta-virtualization gives bitbake error

2018-01-26 Thread Bruce Ashfield 

On 2018-01-26 6:52 AM, Jakob Hasse wrote:

Hello,

we're trying to include meta-virtualization in to our project, in 
particular, we want to use docker. However, as soon as I include the 
layer in to our project, bitbake complains:


bitbake -C compile core-image-base
NOTE: Started PRServer with DBfile: 
/home/jakob/workspace/beerstation/cache/prserv.sqlite3, IP: 127.0.0.1, 
PORT: 46136, PID: 5713

ERROR: Execution of event handler 'virt_bbappend_distrocheck' failed
Traceback (most recent call last):
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck(e=0x7f945e05d3c8>):

  python virt_bbappend_distrocheck() {
     >    skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
  if 'virtualization' not in 
e.data.getVar('DISTRO_FEATURES').split() and not skip_check:

TypeError: getVar() missing 1 required positional argument: 'expand'

ERROR: Command execution failed: Traceback (most recent call last):
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/command.py", 
line 101, in runAsyncCommand

     self.cooker.updateCache()
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/cooker.py", line 
1627, in updateCache
     bb.event.fire(bb.event.SanityCheck(False), 
self.databuilder.mcdata[mc])
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
201, in fire

     fire_class_handlers(event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
124, in fire_class_handlers

     execute_handler(name, handler, event, d)
   File "/usr/local/dey-2.2/sources/poky/bitbake/lib/bb/event.py", line 
96, in execute_handler

     ret = handler(event)
   File 
"/usr/local/dey-2.2/sources/meta-virtualization/classes/sanity-meta-virt.bbclass", 
line 4, in virt_bbappend_distrocheck

     skip_check = e.data.getVar('SKIP_META_VIRT_SANITY_CHECK') == "1"
TypeError: getVar() missing 1 required positional argument: 'expand'


Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


Do we need to checkout a specific branch or so (though I can't find one 
right now)?
Do we need to change some kernel configuration? I added all 
virtualization drivers in the "drivers" section of the kernel config 
already.


We're using DIGI embedded Yocto 2.2 (poky).



You need to check out the matching branch to the release you've
been given as an enablement, since some of the APIs, etc, have
changed and the meta-virt sanity check that was added later than
the 2.2 release isn't working.

2.2 was the 'morty' release, and meta-virt does have a branch for
that:

--
% git whatchanged origin/morty

commit eb6b5129561eda9ea1f47e85ab9ed9e5a6b8f64c
Author: Fabio Berton 
Date:   Tue Nov 28 09:15:59 2017 -0200

python-*: use https for pypi URLs

Several of the recipes here were using http URLs for source hosted on
pypi - pypi apparently no longer supports http so switch to https
instead.

Apply this commit [1] to morty branch.
[1] 
https://www.mail-archive.com/meta-virtualization@yoctoproject.org/msg02821.html


Signed-off-by: Fabio Berton 
Signed-off-by: Bruce Ashfield 
-

So check out the morty branch and you'll have better luck.

Bruce



Thanks and all the best,
Jakob



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

Re: [yocto] [meta-raspberrypi] how the linux-raspberry skip the do_kernel_metadata?

2018-01-26 Thread Bruce Ashfield 
On Fri, Jan 26, 2018 at 4:06 AM, kk  wrote:
> I see the linux-raspberrypi_4.9.bb recipe didn't use the yocto-kernel-cache,
> and add configure in linux-raspberrypi.inc, I am interested in how the
> linux-raspberry skip the do_kernel_metadata?

That task does more than just enable the kernel-cache data, but in theory you
could just delete the task yourself and see what breaks.

(i.e. make a bbappend to the kernel recipe and use something like
"deltask kernel_metadata" to remove the task).

What problem is that step causing in your build ? Maybe there's a better way
to fix things if it's a performance issue or some sort of other bug.

Bruce

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



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

Re: [yocto] [meta-raspberrypi] linux kernel rt

2018-01-26 Thread Trevor Woerner 
On Fri, Jan 26, 2018 at 3:43 AM, Martin Hundebøll <
martin.hundeb...@prevas.dk> wrote:

>
>
> On 2018-01-26 04:51, Khem Raj wrote:
>
>>
>> Secondly, I wonder how good is upstream mainline kernel for rpi now a
>> days, we could always have a mainline recipe as an option and use it as
>> base for things like rt.
>>
>
> Apart from runtime device tree overlay support for RPi hats/extension
> boards, mainline linux fully supports each RPi revision.
>
> I guess linux-yocto-rt would be just fine...
>
>
Does anyone know if the FIQ bug has been fixed upstream? The last time I
looked into PREEMPT_RT on the RPi, the only way to make it work/stable was
to patch the FIQ issue, or disable FIQ altogether (not ideal). This patch
was outside both the kernel and the PREEMPT_RT patch.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] populate_sdk won't work

2018-01-26 Thread John Smith 
Hi list,

 

bitbake my-core-image -c populate_sdk does not work and fails at: x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc

 

Please see the log for further details: https://pastebin.com/w604z66S

 

bitbake myimage works perfect except the sdk.

 

Any suggestions?

 

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

Re: [yocto] populate_sdk won't work

2018-01-26 Thread Khem Raj 
On 1/26/18 9:47 AM, John Smith wrote:
> Hi list,
>  
> bitbake my-core-image -c populate_sdk does not work and fails
> at: x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc
>  
> Please see the log for further details: https://pastebin.com/w604z66S
>  
> bitbake myimage works perfect except the sdk.
>  
> Any suggestions?
>  

what is your build host OS/arch

> Best kkl
> 

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

[yocto] image inheritance problem

2018-01-26 Thread Martin Townsend 
Hi,

I have an image say

my-image-minimal.bb in one layer and and append this
(my-image-minimal.bbappend) in another layer.  In this append I'm adding
IMAGE_INSTALL += "kernel-modules"
for example.

Now if I run
bitbake my-image-minimal -e | grep ^IMAGE_INSTALL
I see kernel-modules

So bbappend is working, now I have another image

my-image which has
requires /core/images/my-image-minimal.bb
...

But kernel-modules is not appearing in this image and
bitbake my-image -e | grep ^IMAGE_INSTALL

confirms this.

Any ideas as to what I'm doing wrong, I assume bitbake supports this.

I'm using the Krogoth release.

Many Thanks in advance,
Martin.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image inheritance problem

2018-01-26 Thread Khem Raj 
On 1/26/18 10:52 AM, Martin Townsend wrote:
> Hi,
> 
> I have an image say
> 
> my-image-minimal.bb in one layer and and append this
> (my-image-minimal.bbappend) in another layer.  In this append I'm adding
> IMAGE_INSTALL += "kernel-modules"
> for example.
> 
> Now if I run
> bitbake my-image-minimal -e | grep ^IMAGE_INSTALL
> I see kernel-modules
> 
> So bbappend is working, now I have another image
> 
> my-image which has
> requires /core/images/my-image-minimal.bb
> ...
> 
> But kernel-modules is not appearing in this image and
> bitbake my-image -e | grep ^IMAGE_INSTALL
> 
> confirms this.
> 
> Any ideas as to what I'm doing wrong, I assume bitbake supports this.
> 

in second case you are including the .bb file so its behaving as an
include file.
bbappend only applies to parsed recipes not include files.

> I'm using the Krogoth release.
> 
> Many Thanks in advance,
> Martin.
> 

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

Re: [yocto] image inheritance problem

2018-01-26 Thread Martin Townsend 
Hi Khem,

On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj  wrote:
> On 1/26/18 10:52 AM, Martin Townsend wrote:
>> Hi,
>>
>> I have an image say
>>
>> my-image-minimal.bb in one layer and and append this
>> (my-image-minimal.bbappend) in another layer.  In this append I'm adding
>> IMAGE_INSTALL += "kernel-modules"
>> for example.
>>
>> Now if I run
>> bitbake my-image-minimal -e | grep ^IMAGE_INSTALL
>> I see kernel-modules
>>
>> So bbappend is working, now I have another image
>>
>> my-image which has
>> requires /core/images/my-image-minimal.bb
>> ...
>>
>> But kernel-modules is not appearing in this image and
>> bitbake my-image -e | grep ^IMAGE_INSTALL
>>
>> confirms this.
>>
>> Any ideas as to what I'm doing wrong, I assume bitbake supports this.
>>
>
> in second case you are including the .bb file so its behaving as an
> include file.
> bbappend only applies to parsed recipes not include files.
>

Thanks for the swift reply and clarifications on how requires/include works.

Don't suppose you know of the best way of handling this situation?

>> I'm using the Krogoth release.
>>
>> Many Thanks in advance,
>> Martin.
>>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image inheritance problem

2018-01-26 Thread Martin Townsend 
On Fri, Jan 26, 2018 at 7:17 PM, Martin Townsend
 wrote:
> Hi Khem,
>
> On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj  wrote:
>> On 1/26/18 10:52 AM, Martin Townsend wrote:
>>> Hi,
>>>
>>> I have an image say
>>>
>>> my-image-minimal.bb in one layer and and append this
>>> (my-image-minimal.bbappend) in another layer.  In this append I'm adding
>>> IMAGE_INSTALL += "kernel-modules"
>>> for example.
>>>
>>> Now if I run
>>> bitbake my-image-minimal -e | grep ^IMAGE_INSTALL
>>> I see kernel-modules
>>>
>>> So bbappend is working, now I have another image
>>>
>>> my-image which has
>>> requires /core/images/my-image-minimal.bb
>>> ...
>>>
>>> But kernel-modules is not appearing in this image and
>>> bitbake my-image -e | grep ^IMAGE_INSTALL
>>>
>>> confirms this.
>>>
>>> Any ideas as to what I'm doing wrong, I assume bitbake supports this.
>>>
>>
>> in second case you are including the .bb file so its behaving as an
>> include file.
>> bbappend only applies to parsed recipes not include files.
>>
>
> Thanks for the swift reply and clarifications on how requires/include works.
>
> Don't suppose you know of the best way of handling this situation?

Not sure if it's the best way but I converted the bbappend to an image
recipe my-minimal-image-xxx.bb
and then include this as well as include will ignore it if the layer
doesn't exist. Seems to work :)

>
>>> I'm using the Krogoth release.
>>>
>>> Many Thanks in advance,
>>> Martin.
>>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Extensible SDK fails to install (build in Ubuntu 16.04 and install in Ubuntu 14.04)

2018-01-26 Thread Bejar-Colonia, Carlos 
Hello,

I am building Yocto using Atmel BSP, Poky and OE version: Morty.
The eSDK installer builds fine (bitbake -c populate_sdk_ext 
core-image-minimal). Build machine x86_64, Ubuntu 16.04 LTS
If I install the eSDK in the same machine where it was build, it works fine.
However, when I try to install the eSDK in a different machine (x86_64, Ubuntu 
14.04) I get these errors:

Proceed[Y/n]?
Extracting SDK...done
Setting it up...
Extracting buildtools...
Preparing build system...
Parsing recipes: 100% 
|| Time: 0:00:51
Initialising tasks: 100% 
|#| Time: 0:00:03
ERROR: Sstate artifact unavailable for 
gettext-minimal-native.do_populate_sysrootETA:  0:00:00
ERROR: Sstate artifact unavailable for quilt-native.do_populate_sysroot
| ETA:  0:00:00
ERROR: Sstate artifact unavailable for 
u-boot-mkimage-native.do_populate_sysroot ETA:  0:00:00
ERROR: Sstate artifact unavailable for 
libxml-parser-perl-native.do_populate_sysroot:  0:00:00
ERROR: Sstate artifact unavailable for file-native.do_populate_sysroot 
| ETA:  0:00:00

I don't see this behavior if I use Poky Morty, commit: 
6da3e0a0abf1251db243548639979f8d74e99766
I see this behavior with Poky Morty commit: 
759a8085afee51abbe36b0bbfe5bf845f41e0971

Is the install suppose to fail due the lower OS version? I searched in the bug 
tracker, but didn't find anything related to this.
NOTE: I tried the other way: build eSDK in Ubuntu 14.04 and install eSDK in 
Ubuntu 16.04. This works fine.

Thanks,
Carlos





The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I generate a dtb for my board support package?

2018-01-26 Thread Peter Spierenburg 
I've discovered the problem. It looks like my SRC_URI entries aren't placing my 
.dts and .dtsi files in the correct locations. If I manually copy those files 
to: 
poky/build/tmp/work-shared/adzs-sc589-ezlite/kernel-source/arch/arm/boot/dts 
then the build will produce a .dtb file as expected.


How do I alter the SRC_URI instruction in my .bbappend file to specify the 
correct destination directory?



From: yocto-boun...@yoctoproject.org  on behalf 
of Peter Spierenburg 
Sent: January 25, 2018 10:46:05 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] How do I generate a dtb for my board support package?


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing
Feedback

Thanks Maciej,


I did add a patch to SRC_URI in my linux-yocto_4.12.bbappend file. Does the 
entry belong somewhere else instead?


Peter.




From: Maciej Pijanowski 
Sent: January 25, 2018 9:37:40 AM
To: Peter Spierenburg; yocto@yoctoproject.org
Subject: Re: [yocto] How do I generate a dtb for my board support package?



On 25.01.2018 14:16, Peter Spierenburg wrote:
| make[2]: *** No rule to make target `sc589-ezkit.dts'.  Stop.
You are building linux-yocto. You need to either add a patch to SRC_URI which 
adds this
dtb target to linux source, or build from a different repository, where this 
support is already
included. I would check from which linux tree they build kernel in buildroot 
BSP.
You will also need proper kernel configuration file for your board.


--
Maciej Pijanowski
Embedded Systems Engineer
http://3mdeb.com | @3mdeb_com

This communication, including any attached documentation, is intended only for 
the person or entity to which it is addressed, and may contain confidential, 
personal, and/or privileged information. Any unauthorized disclosure, copying, 
or taking action on the contents is strictly prohibited. If you have received 
this message in error, please contact us immediately so we may correct our 
records. Please then delete or destroy the original transmission and any 
subsequent reply. Thank you.
This communication, including any attached documentation, is intended only for 
the person or entity to which it is addressed, and may contain confidential, 
personal, and/or privileged information. Any unauthorized disclosure, copying, 
or taking action on the contents is strictly prohibited. If you have received 
this message in error, please contact us immediately so we may correct our 
records. Please then delete or destroy the original transmission and any 
subsequent reply. Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] populate_sdk won't work

2018-01-26 Thread John Smith 
> what is your build host OS/arch

Host:OS debian/x86_64 kernel v4.9
Target:  arm v4.14

A while ago I added the the kernel sources and it has been working (yocto-2.4.0)
Since I ve updated to yocto-2.4.1 it does not anymore. Before build I removed 
build/tmp build/sstate-cache and did a clean.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image inheritance problem

2018-01-26 Thread Khem Raj 
On Fri, Jan 26, 2018 at 11:49 AM, Martin Townsend
 wrote:
> On Fri, Jan 26, 2018 at 7:17 PM, Martin Townsend
>  wrote:
>> Hi Khem,
>>
>> On Fri, Jan 26, 2018 at 6:57 PM, Khem Raj  wrote:
>>> On 1/26/18 10:52 AM, Martin Townsend wrote:
 Hi,

 I have an image say

 my-image-minimal.bb in one layer and and append this
 (my-image-minimal.bbappend) in another layer.  In this append I'm adding
 IMAGE_INSTALL += "kernel-modules"
 for example.

 Now if I run
 bitbake my-image-minimal -e | grep ^IMAGE_INSTALL
 I see kernel-modules

 So bbappend is working, now I have another image

 my-image which has
 requires /core/images/my-image-minimal.bb
 ...

 But kernel-modules is not appearing in this image and
 bitbake my-image -e | grep ^IMAGE_INSTALL

 confirms this.

 Any ideas as to what I'm doing wrong, I assume bitbake supports this.

>>>
>>> in second case you are including the .bb file so its behaving as an
>>> include file.
>>> bbappend only applies to parsed recipes not include files.
>>>
>>
>> Thanks for the swift reply and clarifications on how requires/include works.
>>
>> Don't suppose you know of the best way of handling this situation?
>
> Not sure if it's the best way but I converted the bbappend to an image
> recipe my-minimal-image-xxx.bb
> and then include this as well as include will ignore it if the layer
> doesn't exist. Seems to work :)

thats probably ok. you can call it a .inc file and use include instead
of require to include it
that way you can include it in multiple image recipes or bbappends in
your own layers.


>
>>
 I'm using the Krogoth release.

 Many Thanks in advance,
 Martin.

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

Re: [yocto] [eclipse-poky][oxygen][PATCH v2 2/2] setup.sh: show versions availables and version installed

2018-01-26 Thread Tim Orling 
I am going to go ahead and merge these as other work is depending on these 
changes.

—Tim

> On Jan 25, 2018, at 7:33 PM, Tim Orling  
> wrote:
> 
> From: Chin Huat Ang 
> 
> Signed-off-by: Chin Huat Ang 
> Signed-off-by: Tim Orling 
> ---
> scripts/setup.sh | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/scripts/setup.sh b/scripts/setup.sh
> index 024596bfb1e..e3da101cbe5 100755
> --- a/scripts/setup.sh
> +++ b/scripts/setup.sh
> @@ -219,9 +219,13 @@ update_feature_remote()
>   [ $# -lt 3 ] && err_exit 1 "update_feature_remote: invalid parameters, $*"
>   check_local_version $2 $3 $4 && echo "Feature $2 is already installed" && 
> return 0
>   local installIU=""
> +  local all_versions=$(get_version $1 $2 'all')
> +
> +  echo "Feature $2 versions available: $all_versions"
> +
>   if [ "x$4" != "x" ]; then
>   #has max version requirement
> -  for i in "`get_version $1 $2 'all'`"; do
> +  for i in $all_versions; do
> if [ "$i" \> "$3" ] || [ "$i" = "$3" ] && [ "$i" \< "$4" ]; then
>   [ "$i" \> "$installIU" ] && installIU=$i
> fi
> @@ -264,51 +268,51 @@ fi
> UPDATE_SITE="http://download.eclipse.org/eclipse/updates/4.7";
> 
> #CDT related
> -echo -e "\nPlease wait. Installing CDT.SDK.FEATURE.GROUP"
> CDTFEAT="9.4.0"
> +echo -e "\nPlease wait. Installing CDT.SDK.FEATURE.GROUP ${CDTFEAT}"
> update_feature_remote ${MAIN_SITE} org.eclipse.cdt.sdk.feature.group 
> ${CDTFEAT}
> 
> -echo -e "\nPlease wait. Installing CDT.LAUNCH.REMOTE.FEATURE.GROUP"
> CDTREMOTEVER="9.4.0"
> +echo -e "\nPlease wait. Installing CDT.LAUNCH.REMOTE.FEATURE.GROUP 
> ${CDTREMOTEVER}"
> update_feature_remote ${MAIN_SITE} 
> org.eclipse.cdt.launch.remote.feature.group ${CDTREMOTEVER}
> 
> #AUTOTOOLS
> -echo -e "\nPlease wait. Installing AUTOTOOLS.FEATURE.GROUP"
> ATVER="9.4.0"
> +echo -e "\nPlease wait. Installing AUTOTOOLS.FEATURE.GROUP ${ATVER}"
> update_feature_remote ${MAIN_SITE} org.eclipse.cdt.autotools.feature.group 
> ${ATVER}
> 
> #TM Terminal (was RSE) related
> -echo -e "\nPlease wait. Installing TM.TERMINAL.FEATURE.FEATURE.GROUP"
> TMTERMVER="4.3.0"
> +echo -e "\nPlease wait. Installing TM.TERMINAL.FEATURE.FEATURE.GROUP 
> ${TMTERMVER}"
> update_feature_remote ${MAIN_SITE} 
> org.eclipse.tm.terminal.feature.feature.group ${TMTERMVER}
> 
> -echo -e "\nPlease wait. Installing TM.TERMINAL.VIEW.RSE.FEATURE.GROUP"
> TMTERMVIEWRSEVER="4.3.0"
> +echo -e "\nPlease wait. Installing TM.TERMINAL.VIEW.RSE.FEATURE.GROUP 
> ${TMTERMVIEWRSEVER}"
> update_feature_remote ${MAIN_SITE} 
> org.eclipse.tm.terminal.view.rse.feature.feature.group ${TMTERMVIEWRSEVER}
> 
> -echo -e "\nPlease wait. Installing TM.TERMINAL.CONTROL.FEATURE.GROUP"
> TMCONTROLVER="4.3.0"
> +echo -e "\nPlease wait. Installing TM.TERMINAL.CONTROL.FEATURE.GROUP 
> ${TMCONTROLVER}"
> update_feature_remote ${MAIN_SITE} 
> org.eclipse.tm.terminal.control.feature.feature.group ${TMCONTROLVER}
> 
> #RSE_SDK
> -echo -e "\nPlease wait. Installing RSE.SDK.FEATURE.GROUP"
> RSESDKVER="3.7.0"
> +echo -e "\nPlease wait. Installing RSE.SDK.FEATURE.GROUP ${RSESDKVER}"
> update_feature_remote ${TM_SITE} org.eclipse.rse.sdk.feature.group 
> ${RSESDKVER}
> #echo -e "\nSkipping RSE.SDK.FEATURE.GROUP"
> 
> #RSE_TERMINALS
> -echo -e "\nPlease wait. Installing RSE.TERMINALS.FEATURE.GROUP"
> RSETERMVER="3.8.0"
> +echo -e "\nPlease wait. Installing RSE.TERMINALS.FEATURE.GROUP ${RSETERMVER}"
> update_feature_remote ${TM_SITE} org.eclipse.rse.terminals.feature.group 
> ${RSETERMVER}
> #echo -e "\nSkipping RSE.TERMINALS.FEATURE.GROUP"
> 
> #Lttng2
> TMF_CTF_REL="3.2.0"
> -echo -e "\nPlease wait. Installing TRACECOMPASS.LTTNG2.UST.FEATURE.GROUP"
> +echo -e "\nPlease wait. Installing TRACECOMPASS.LTTNG2.UST.FEATURE.GROUP 
> ${TMF_CTF_REL}"
> update_feature_remote ${MAIN_SITE} 
> org.eclipse.tracecompass.lttng2.ust.feature.group ${TMF_CTF_REL}
> 
> -echo -e "\nPlease wait. Installing 
> OSGI.COMPATIBILITY.PLUGINS.FEATURE.FEATURE.GROUP"
> COMPAT_VER="1.1.1"
> +echo -e "\nPlease wait. Installing 
> OSGI.COMPATIBILITY.PLUGINS.FEATURE.FEATURE.GROUP ${COMPAT_VER}"
> update_feature_remote ${UPDATE_SITE} 
> org.eclipse.osgi.compatibility.plugins.feature.feature.group ${COMPAT_VER}
> 
> echo -e "\nYour build environment is successfully created."
> -- 
> 2.13.6
> 

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

[yocto] [eclipse-poky][PATCH] README.txt: update contributor instructions to use eclipse-poky

2018-01-26 Thread Tim Orling 
Since we have now created an eclipse-poky mailing list, all
patches and discussion should be directed there.

Signed-off-by: Tim Orling 
---
 README.txt | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/README.txt b/README.txt
index cc5b890c5a8..3049c595362 100644
--- a/README.txt
+++ b/README.txt
@@ -188,13 +188,22 @@ Part V. Sharing with the Community
 V.1 Sending Patches to the Mailing List
 
   Any changes to the eclipse-poky plugin should be sent as patches to
-  the Yocto Project mailing list (yocto@yoctoproject.org), with
+  the Eclipse Poky  mailing list (eclipse-p...@yoctoproject.org), with
 
---subject-prefix="eclipse-poky][PATCH"
+--subject-prefix="][PATCH"
+
+  where  might be "neon" or "oxygen". Also if, the bug
+  affects a particular Yocto Project release, include the release name
+  in the subject prefix:
+
+--subject-prefix="][][PATCH"
+
+  where  might be "morty", "pyro" or "rocko" for
+  instance.
 
   This is a subscriber only list, so you will need to sign up for access at:
 
-https://lists.yoctoproject.org/listinfo/yocto
+https://lists.yoctoproject.org/listinfo/eclipse-poky
 
   Patches should follow the same guidelines that are used for other parts of
   the Yocto Project and Open Embedded code-base:
-- 
2.13.6

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

[yocto] [eclipse-poky][neon][PATCH] README.txt: update contributor instructions to use eclipse-poky

2018-01-26 Thread Tim Orling 
Since we have now created an eclipse-poky mailing list, all
patches and discussion should be directed there.

Signed-off-by: Tim Orling 
---
 README.txt | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/README.txt b/README.txt
index cc5b890c5a8..3049c595362 100644
--- a/README.txt
+++ b/README.txt
@@ -188,13 +188,22 @@ Part V. Sharing with the Community
 V.1 Sending Patches to the Mailing List
 
   Any changes to the eclipse-poky plugin should be sent as patches to
-  the Yocto Project mailing list (yocto@yoctoproject.org), with
+  the Eclipse Poky  mailing list (eclipse-p...@yoctoproject.org), with
 
---subject-prefix="eclipse-poky][PATCH"
+--subject-prefix="][PATCH"
+
+  where  might be "neon" or "oxygen". Also if, the bug
+  affects a particular Yocto Project release, include the release name
+  in the subject prefix:
+
+--subject-prefix="][][PATCH"
+
+  where  might be "morty", "pyro" or "rocko" for
+  instance.
 
   This is a subscriber only list, so you will need to sign up for access at:
 
-https://lists.yoctoproject.org/listinfo/yocto
+https://lists.yoctoproject.org/listinfo/eclipse-poky
 
   Patches should follow the same guidelines that are used for other parts of
   the Yocto Project and Open Embedded code-base:
-- 
2.13.6

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