Re: [yocto] [PATCH 1/1] emgd-driver-bin: Fix package naming issue
On 6 September 2012 01:59, nitin.a.kam...@intel.com wrote: emgd-driver-bin is generating rpm package with name libegl1. This name clashes with a package of mesa-dri recipe. This name clash blocks installation of emgd user land binaries in the image. And due to missing emgd user land components X fails start on BSPs like crownbay. Fix this problem by specifying package names in the recipe with the PKG_ vars. Could we name the packages with a -emgd suffix, such as libegl-emgd? I'm going to fix mesa to name it's packages libegl-mesa and so on, so consistency would make everything a lot easier (see my mail to oe-core yesterday about GL). Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
On 09/06/2012 06:19 PM, Bruce Ashfield wrote: On 12-09-06 5:06 PM, Philip Balister wrote: On 09/06/2012 04:11 PM, Trevor Woerner wrote: Hi Elvis, Thanks so much for taking a look at my email! I've read through lots of this mailing list's history and noticed all your meta-xilinx work in the past and was hoping I could pique your interest :-) On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson elvis.dow...@gmail.com wrote: Can you please list which version of the Xilinx ISE tools you are using? e.g. 12.4, 14.1, 14.2 ? I have 14.2 installed on my Linux machine at home. Could you also please list the Xilinx development board that you are using? e.g. SP601 (Spartan6) ? I have been (slowly) teaching myself VHDL and working with a Papilio board from Gadget Factory. Are you familiar with them? They have a Spartan 3E on them. http://papilio.cc/ Let me know what you ISE development tool configuration and development board is, and I'll see if I can divert a bit from target platform, and try to explore getting the toolchain to build for the Microblaze processor. It is my understanding that Microblaze won't fit or work with the Spartan 3E (?). However, the guy who makes the Papilio board, Jack Gassett, is currently working on his latest board called the Papilio Plus. The Plus is not yet out, although prototypes are available: http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/ The Plus will feature a Spartan 6 LX9, which, I believe, can support the Microblaze. In a comment on the All Programmable Planet blog about a month ago, Jack bemoans how easy it used to be to get Linux up and running on a Spartan 3E devel board using what has now become PetaLinux. The problem is that PetaLinux is now a commercial product and not readily available to the DIY market: http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509piddl_msgid=717514#msg_717514 When I noticed the meta-xilinx layer had support for the Spartan 6 LX9 I was really hoping to surprise Jack by testing it out and providing instructions for creating a filesystem he could use as part of his work on the Plus. Unfortunately my attempts fell flat. I even tried using denzil-7.0.1 but encountered the same problems. Seeing how soft processors within programmable logic seems to be gaining in popularity, I thought it would be a great niche to get into. If the Yocto Project could be used to create images for the Microblaze or even the Picoblaze processors I think it would help fill a void which is quickly expanding. Also, if support could be added to meta-xilinx to support Jack's Papilio boards it would help introduce the DIY community to the Yocto Project. I've got the following boards with me: - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440) - Xilinx SP601 (Spartan 6) - Xilinx Zynq (ARM Cortex A-9) Once I get more into the VHDL I'll probably end up getting a Zynq myself too; talk about combining the best of both worlds :-) Speaking of zynq, I have a simple BSP here for the zc702 board: https://github.com/balister/meta-zynq We have a namespace collision, there is also: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ Before creating the layer I checked: http://www.openembedded.org/wiki/LayerIndex This is where layer information is collected. If a layer is not listed here, yo can expect namespace collisions. Philip Cheers, Bruce Philip ___ 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] beagleboard: change to xserver-xorg, not -lite
hello, I did a new build of poky git clone git://git.yoctoproject.org/poky.git With gitk I see that the patch has been applied to meta-yocto-bsp/conf/machine/beagleboard.conf When I execute MACHINE=beagleboard bitbake -v core-image-sato I get the following Summary: 4 tasks failed: /home/vidal/poky/meta/recipes-graphics/xorg-proto/glproto_1.4.16.bb, do_compile /home/vidal/poky/meta/recipes-graphics/xorg-proto/dri2proto_2.8.bb, do_compile /home/vidal/poky/meta/recipes-graphics/xorg-proto/xf86driproto_2.1.1.bb, do_configure /home/vidal/poky/meta/recipes-graphics/xorg-proto/fontsproto_2.1.2.bb, do_configure Summary: There were 4 ERROR messages shown, returning a non-zero exit code. Is this error related to change from xorg-xserver instead of xorg-xserver-lite Any help will be appreciated. Thanks ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister phi...@balister.org wrote: On 09/06/2012 06:19 PM, Bruce Ashfield wrote: On 12-09-06 5:06 PM, Philip Balister wrote: On 09/06/2012 04:11 PM, Trevor Woerner wrote: Hi Elvis, Thanks so much for taking a look at my email! I've read through lots of this mailing list's history and noticed all your meta-xilinx work in the past and was hoping I could pique your interest :-) On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson elvis.dow...@gmail.com wrote: Can you please list which version of the Xilinx ISE tools you are using? e.g. 12.4, 14.1, 14.2 ? I have 14.2 installed on my Linux machine at home. Could you also please list the Xilinx development board that you are using? e.g. SP601 (Spartan6) ? I have been (slowly) teaching myself VHDL and working with a Papilio board from Gadget Factory. Are you familiar with them? They have a Spartan 3E on them. http://papilio.cc/ Let me know what you ISE development tool configuration and development board is, and I'll see if I can divert a bit from target platform, and try to explore getting the toolchain to build for the Microblaze processor. It is my understanding that Microblaze won't fit or work with the Spartan 3E (?). However, the guy who makes the Papilio board, Jack Gassett, is currently working on his latest board called the Papilio Plus. The Plus is not yet out, although prototypes are available: http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/ The Plus will feature a Spartan 6 LX9, which, I believe, can support the Microblaze. In a comment on the All Programmable Planet blog about a month ago, Jack bemoans how easy it used to be to get Linux up and running on a Spartan 3E devel board using what has now become PetaLinux. The problem is that PetaLinux is now a commercial product and not readily available to the DIY market: http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509piddl_msgid=717514#msg_717514 When I noticed the meta-xilinx layer had support for the Spartan 6 LX9 I was really hoping to surprise Jack by testing it out and providing instructions for creating a filesystem he could use as part of his work on the Plus. Unfortunately my attempts fell flat. I even tried using denzil-7.0.1 but encountered the same problems. Seeing how soft processors within programmable logic seems to be gaining in popularity, I thought it would be a great niche to get into. If the Yocto Project could be used to create images for the Microblaze or even the Picoblaze processors I think it would help fill a void which is quickly expanding. Also, if support could be added to meta-xilinx to support Jack's Papilio boards it would help introduce the DIY community to the Yocto Project. I've got the following boards with me: - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440) - Xilinx SP601 (Spartan 6) - Xilinx Zynq (ARM Cortex A-9) Once I get more into the VHDL I'll probably end up getting a Zynq myself too; talk about combining the best of both worlds :-) Speaking of zynq, I have a simple BSP here for the zc702 board: https://github.com/balister/meta-zynq We have a namespace collision, there is also: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ Before creating the layer I checked: http://www.openembedded.org/wiki/LayerIndex This is where layer information is collected. If a layer is not listed here, yo can expect namespace collisions. Sure, I don't argue with that, but I wasn't the original owner of the layer so I can't say why it was or wasn't put into the wiki .. I'm not really concerned about the minor oversight. They layer I pointed to was done under contract by xilinx themselves, and contributed to be maintained as a yocto BSP, so the layers name is not something that I control or can change. Other similar layers can use the same name if they want, I was pointing it out for reference, since I've had the same thing pointed out to me in the past ;) Cheers, Bruce Philip Cheers, Bruce Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ 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] ERROR: Nothing RPROVIDES 'libsegfault'
Ah, right--sorry, you did say the denzil *branch*. It seems to be building fine now, thanks. So far, it's gotten through the first 150 tasks, which is a lot further than before. I'll follow up if I encounter any other problems... On Fri, Sep 7, 2012 at 1:08 AM, Florin Sarbu florin.sa...@windriver.com wrote: Please use the denzil branch for poky, not a denzil tag. Thanks, Florin On 09/06/2012 11:02 PM, Evade Flow wrote: Thanks for confirming that the target for meta-ivi is denzil. After re-targetting to branch denzil-7.0.1, I got the following error: -- Pseudo is not present but is required, building this first before the main build Parsing recipes...NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb ERROR: Unable to parse /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/pango/pango_1.28.4.bb ERROR: Command execution failed: Traceback (most recent call last): File /media/acme/remus/poky-git/bitbake/lib/bb/command.py, line 84, in runAsyncCommand self.cooker.updateCache() File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1202, in updateCache if not self.parser.parse_next(): File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1669, in parse_next self.virtuals += len(result) UnboundLocalError: local variable 'result' referenced before assignment Summary: There were 2 ERROR messages shown, returning a non-zero exit code. -- I attempted a trivial fix for this (see below), and then got: -- Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 3 entries from dependency cache. Parsing recipes...NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb ERROR: Unable to parse /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/pango/pango_1.28.4.bb ERROR: Command execution failed: Traceback (most recent call last): File /media/acme/remus/poky-git/bitbake/lib/bb/command.py, line 84, in runAsyncCommand self.cooker.updateCache() File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1202, in updateCache if not self.parser.parse_next(): File /media/acme/remus/poky-git/bitbake/lib/bb/cooker.py, line 1671, in parse_next if parsed: UnboundLocalError: local variable 'parsed' referenced before assignment Summary: There were 2 ERROR messages shown, returning a non-zero exit code. -- The patch I tried was: diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py index 4a4dc38..a2cac9a 100644 --- a/bitbake/lib/bb/cooker.py +++ b/bitbake/lib/bb/cooker.py @@ -1644,6 +1644,8 @@ class CookerParser(object): yield result def parse_next(self): +result = [] +parsed = 0 try: parsed, result = self.results.next() except StopIteration: After this attempted fix, I got the following errors: -- Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 3 entries from dependency cache. Parsing recipes...NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb ERROR: Unable to parse /media/acme/remus/poky-git/meta-ivi/recipes-graphics/mesa/mesa-dri_8.0.1.bb NOTE: Error expanding variable populate_packages NOTE: Error during finalise of /media/acme/remus/poky-git/meta-ivi/recipes-graphics/pango/pango_1.28.4.bb ERROR: No recipes available for: /media/acme/remus/poky-git/meta-yocto/recipes-core/uclibc/uclibc_git.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-bsp/formfactor/formfactor_0.0.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-connectivity/openssl/openssl_1.0.0j.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-kernel/kmod/kmod_git.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/eglibc/eglibc-locale_2.16.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/tinylogin/tinylogin_1.4.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-graphics/mesa/mesa-dri_7.11.bbappend /media/acme/remus/poky-git/meta-ivi/recipes-core-ivi/eglibc/eglibc_2.16.bbappend /media/acme/remus/poky-git/meta-yocto/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
Re: [yocto] Procedure to setup icecc for performing a distributed build
On Thu, Sep 6, 2012 at 2:17 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 16 August 2012 00:30:15 Elvis Dowson wrote: Otherwise, Dmitry, any suggestions? I'm assuming you made use of icecc.bbclass since you made some changes to it a while ago... I'm sorry, I had not tried icecc.bbclass lately. I should give it a try. Probably either on Weekend, or next week. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- With best wishes Dmitry ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote: On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister phi...@balister.org wrote: On 09/06/2012 06:19 PM, Bruce Ashfield wrote: Speaking of zynq, I have a simple BSP here for the zc702 board: https://github.com/balister/meta-zynq We have a namespace collision, there is also: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ Before creating the layer I checked: http://www.openembedded.org/wiki/LayerIndex This is where layer information is collected. If a layer is not listed here, yo can expect namespace collisions. Sure, I don't argue with that, but I wasn't the original owner of the layer so I can't say why it was or wasn't put into the wiki .. I'm not really concerned about the minor oversight. They layer I pointed to was done under contract by xilinx themselves, and contributed to be maintained as a yocto BSP, so the layers name is not something that I control or can change. Other similar layers can use the same name if they want, I was pointing it out for reference, since I've had the same thing pointed out to me in the past ;) The bigger question is whether that layer is getting maintained. If it isn't, it will likely get removed. I'd prefer it to get added to the layer index and the namespace collision getting fixed. I was going to cc the maintainer but there isn't one listed in the README which is a really bad start. The feedback I gave when this was added has not all been acted upon either (multi-dtb.inc, layencytop/sysprof nastiness). This puts it right at the top of my likely to get removed soon list. Bruce: Since you have an idea who wrote it, could you find out whether its going to get fixed (at the very least fix the README, add to the index and resolve the namespace) or whether I should be deleting it. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any success with spartan6-lx9mb?
On 12-09-07 12:19 PM, Richard Purdie wrote: On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote: On Fri, Sep 7, 2012 at 7:22 AM, Philip Balisterphi...@balister.org wrote: On 09/06/2012 06:19 PM, Bruce Ashfield wrote: Speaking of zynq, I have a simple BSP here for the zc702 board: https://github.com/balister/meta-zynq We have a namespace collision, there is also: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ Before creating the layer I checked: http://www.openembedded.org/wiki/LayerIndex This is where layer information is collected. If a layer is not listed here, yo can expect namespace collisions. Sure, I don't argue with that, but I wasn't the original owner of the layer so I can't say why it was or wasn't put into the wiki .. I'm not really concerned about the minor oversight. They layer I pointed to was done under contract by xilinx themselves, and contributed to be maintained as a yocto BSP, so the layers name is not something that I control or can change. Other similar layers can use the same name if they want, I was pointing it out for reference, since I've had the same thing pointed out to me in the past ;) The bigger question is whether that layer is getting maintained. If it isn't, it will likely get removed. I'd prefer it to get added to the layer index and the namespace collision getting fixed. I was going to cc the maintainer but there isn't one listed in the README which is a really bad start. The feedback I gave when this was added has not all been acted upon either (multi-dtb.inc, layencytop/sysprof nastiness). This puts it right at the top of my likely to get removed soon list. It is being maintained, updates are pending. Bruce: Since you have an idea who wrote it, could you find out whether its going to get fixed (at the very least fix the README, add to the index and resolve the namespace) or whether I should be deleting it. Don't delete it. Work is being done. This was supposed to be a primary repository for work, and it is the basis for spin off BSPs. There was a handoff issue between Wind River and Xylinx .. but I don't have all the details. And it's something that I'll be carrying forward and pulling kernel patches into linux-yocto on the next kernel bump. I'll do the simple updates to the README and put it in the layer index. Cheers, Bruce Cheers, Richard ___ 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] meta-zynq, was Re: any success with spartan6-lx9mb?
On 09/07/2012 12:30 PM, Bruce Ashfield wrote: On 12-09-07 12:19 PM, Richard Purdie wrote: On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote: On Fri, Sep 7, 2012 at 7:22 AM, Philip Balisterphi...@balister.org wrote: On 09/06/2012 06:19 PM, Bruce Ashfield wrote: Speaking of zynq, I have a simple BSP here for the zc702 board: https://github.com/balister/meta-zynq We have a namespace collision, there is also: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ Before creating the layer I checked: http://www.openembedded.org/wiki/LayerIndex This is where layer information is collected. If a layer is not listed here, yo can expect namespace collisions. Sure, I don't argue with that, but I wasn't the original owner of the layer so I can't say why it was or wasn't put into the wiki .. I'm not really concerned about the minor oversight. They layer I pointed to was done under contract by xilinx themselves, and contributed to be maintained as a yocto BSP, so the layers name is not something that I control or can change. Other similar layers can use the same name if they want, I was pointing it out for reference, since I've had the same thing pointed out to me in the past ;) The bigger question is whether that layer is getting maintained. If it isn't, it will likely get removed. I'd prefer it to get added to the layer index and the namespace collision getting fixed. I was going to cc the maintainer but there isn't one listed in the README which is a really bad start. The feedback I gave when this was added has not all been acted upon either (multi-dtb.inc, layencytop/sysprof nastiness). This puts it right at the top of my likely to get removed soon list. It is being maintained, updates are pending. Bruce: Since you have an idea who wrote it, could you find out whether its going to get fixed (at the very least fix the README, add to the index and resolve the namespace) or whether I should be deleting it. Don't delete it. Work is being done. This was supposed to be a primary repository for work, and it is the basis for spin off BSPs. There was a handoff issue between Wind River and Xylinx .. but I don't have all the details. And it's something that I'll be carrying forward and pulling kernel patches into linux-yocto on the next kernel bump. I'll do the simple updates to the README and put it in the layer index. I'm concerned the kernel version is the yocto project version is based off 3.2 and the code in git.xilinx.com is based of 3.3 now. I do not like either situation :) But, working with vendors who provide git repos of their work, it is easier for people using the boards to track the vendor tree, and not spend time figuring out how to get from linux releases to the vendor tree. I'd like to see the layers unifed, since we need to reduce confusion, but have some reservations about the layer on the Yocto Project server. Philip Cheers, Bruce Cheers, Richard ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] emgd-driver-bin: Fix package naming issue
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Friday, September 07, 2012 2:29 AM To: Kamble, Nitin A Cc: Zanussi, Tom; Hart, Darren; yocto@yoctoproject.org Subject: Re: [yocto] [PATCH 1/1] emgd-driver-bin: Fix package naming issue On 6 September 2012 01:59, nitin.a.kam...@intel.com wrote: emgd-driver-bin is generating rpm package with name libegl1. This name clashes with a package of mesa-dri recipe. This name clash blocks installation of emgd user land binaries in the image. And due to missing emgd user land components X fails start on BSPs like crownbay. Fix this problem by specifying package names in the recipe with the PKG_ vars. Could we name the packages with a -emgd suffix, such as libegl-emgd? I'm going to fix mesa to name it's packages libegl-mesa and so on, so consistency would make everything a lot easier (see my mail to oe-core yesterday about GL). Ross The package generated has lot of other libraries. And IMO the most important in that is emgd-drv. Libegl is one of the many supporting libraries in the package. So to me renaming package to emgd-drv makes more sense than extending the name to libegl-emgd. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zynq, was Re: any success with spartan6-lx9mb?
On 12-09-07 01:29 PM, Philip Balister wrote: On 09/07/2012 12:30 PM, Bruce Ashfield wrote: On 12-09-07 12:19 PM, Richard Purdie wrote: On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote: On Fri, Sep 7, 2012 at 7:22 AM, Philip Balisterphi...@balister.org wrote: On 09/06/2012 06:19 PM, Bruce Ashfield wrote: Speaking of zynq, I have a simple BSP here for the zc702 board: https://github.com/balister/meta-zynq We have a namespace collision, there is also: http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/ Before creating the layer I checked: http://www.openembedded.org/wiki/LayerIndex This is where layer information is collected. If a layer is not listed here, yo can expect namespace collisions. Sure, I don't argue with that, but I wasn't the original owner of the layer so I can't say why it was or wasn't put into the wiki .. I'm not really concerned about the minor oversight. They layer I pointed to was done under contract by xilinx themselves, and contributed to be maintained as a yocto BSP, so the layers name is not something that I control or can change. Other similar layers can use the same name if they want, I was pointing it out for reference, since I've had the same thing pointed out to me in the past ;) The bigger question is whether that layer is getting maintained. If it isn't, it will likely get removed. I'd prefer it to get added to the layer index and the namespace collision getting fixed. I was going to cc the maintainer but there isn't one listed in the README which is a really bad start. The feedback I gave when this was added has not all been acted upon either (multi-dtb.inc, layencytop/sysprof nastiness). This puts it right at the top of my likely to get removed soon list. It is being maintained, updates are pending. Bruce: Since you have an idea who wrote it, could you find out whether its going to get fixed (at the very least fix the README, add to the index and resolve the namespace) or whether I should be deleting it. Don't delete it. Work is being done. This was supposed to be a primary repository for work, and it is the basis for spin off BSPs. There was a handoff issue between Wind River and Xylinx .. but I don't have all the details. And it's something that I'll be carrying forward and pulling kernel patches into linux-yocto on the next kernel bump. I'll do the simple updates to the README and put it in the layer index. I'm concerned the kernel version is the yocto project version is based off 3.2 and the code in git.xilinx.com is based of 3.3 now. True. But the work I mentioned is happening is to move this to 3.4. 3.2 is the version that Xilinx requested for initial integration as a yocto BSP, so that's where it sits for now. I do not like either situation :) Niether do I. But, working with vendors who provide git repos of their work, it is easier for people using the boards to track the vendor tree, and not spend time figuring out how to get from linux releases to the vendor tree. In this case, they were hoping to track the yocto kernel versions to not make version skew or spread the version landscape anymore. As far as I know, this is still the case, since it makes the route to commercial support simpler in some cases. I'd like to see the layers unifed, since we need to reduce confusion, but have some reservations about the layer on the Yocto Project server. I'm sure we can work through them, I'm raising the right people at Xilinx to discuss as well, since in the end, their voice carries the most weight. Cheers, Bruce Philip Cheers, Bruce Cheers, Richard ___ 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CyaSSL Yocto Recipe
Hi Richard, On Sep 6, 2012, at 4:53 PM, Richard Purdie wrote: This looks like an interesting piece of software and a quick read through your webpages suggests there may be some interesting applications of this within OE which I'd love to explore. We are however quite careful about what goes into OE-Core and you've picked about the worst possible point of the cycle to have this discussion (just after feature freeze which was six days ago). So I certainly think this could make OE-Core but probably not in the 1.3 release timeframe. I would also want to see some kind of demo that we could replace some of our openssl/gnutls usage with this too which so far I've not seen. There is discussion in the OE-Core archives about making the SSL/TLS provider selectable though so there is certainly interest. So I think this is a good idea, a layer is a great place to start experimenting and if its shown to be successful it would make the core. We've got to be realistic about the development process and this isn't going to happen overnight though (a layer is much easier/faster to start with). Thanks for the notification about your feature freeze. I do understand that it may take some time to get CyaSSL rolled into OE-Core, and I think you and Saul's suggestion of starting with a layer on GitHub is a good first step. From there, maybe we can explore some of the interesting applications you have in mind. Best Regards, Chris ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Denzil / Cedartrail on DN2800MT
Has anyone used the Cedartrail BSP under Denzil 7.0.1 on a DN2800MT motherboard? I've just built core-image-sato and used the hddimg to boot from a USB drive, but 'X' won't start and reports that it can't find a screen. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Denzil / Cedartrail on DN2800MT
I used Denzil branch to pick up the latest GFX drivers changed added recently. Jim A Sent from my iPhone On Sep 7, 2012, at 3:58 PM, Chris Tapp opensou...@keylevel.com wrote: Has anyone used the Cedartrail BSP under Denzil 7.0.1 on a DN2800MT motherboard? I've just built core-image-sato and used the hddimg to boot from a USB drive, but 'X' won't start and reports that it can't find a screen. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][eclipse-poky] setup.py: Change main eclipse SDK repo to point to yocto
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 elizabeth.flana...@intel.com
---
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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][eclipse-poky][Rev1] setup.py: Use Yocto mirror of eclipse juno repo
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 sdk tarballs and a mirror of the update
site.
Signed-off-by: Elizabeth Flanagan elizabeth.flana...@intel.com
---
scripts/setup.sh |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/setup.sh b/scripts/setup.sh
index 5a928f4..9c57e50 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}
@@ -178,7 +178,11 @@ update_feature_remote()
}
#Eclipse Update Site
-MAIN_UPDATE_SITE=http://download.eclipse.org/releases/juno;
+#MAIN_UPDATE_SITE=http://download.eclipse.org/releases/juno;
+# The main eclipse download site is unreliable at times. For now,
we're going to
+# maintain a mirror of just what we need.
+MAIN_UPDATE_SITE=http://downloads.yoctoproject.org/eclipse/juno/ftp.osuosl.org/pub/eclipse/releases/juno;
+
UPDATE_SITE=${MAIN_UPDATE_SITE}
#CDT related
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH][eclipse-poky][Rev1] setup.py: Use Yocto mirror of eclipse juno repo
Beth,
Can u change the old wget line to a comment instead of replacement so we can
have a record?
Thanks,
Jessica
-Original Message-
From: Flanagan, Elizabeth [mailto:elizabeth.flana...@intel.com]
Sent: Friday, September 07, 2012 4:28 PM
To: yocto@yoctoproject.org; Zhang, Jessica
Subject: [PATCH][eclipse-poky][Rev1] setup.py: Use Yocto mirror of eclipse juno
repo
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 sdk tarballs and a
mirror of the update site.
Signed-off-by: Elizabeth Flanagan elizabeth.flana...@intel.com
---
scripts/setup.sh |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/setup.sh b/scripts/setup.sh index 5a928f4..9c57e50 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}
@@ -178,7 +178,11 @@ update_feature_remote() }
#Eclipse Update Site
-MAIN_UPDATE_SITE=http://download.eclipse.org/releases/juno;
+#MAIN_UPDATE_SITE=http://download.eclipse.org/releases/juno;
+# The main eclipse download site is unreliable at times. For now,
we're going to
+# maintain a mirror of just what we need.
+MAIN_UPDATE_SITE=http://downloads.yoctoproject.org/eclipse/juno/ftp.osuosl.org/pub/eclipse/releases/juno;
+
UPDATE_SITE=${MAIN_UPDATE_SITE}
#CDT related
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH][eclipse-poky][Rev1] setup.py: Use Yocto mirror of eclipse juno repo
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 sdk tarballs and a mirror of the update
site.
Signed-off-by: Elizabeth Flanagan elizabeth.flana...@intel.com
---
scripts/setup.sh | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/scripts/setup.sh b/scripts/setup.sh
index 5a928f4..17b1af4 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -66,7 +66,9 @@ 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://download.eclipse.org/eclipse/downloads/drops4/${ep_rel}${ep_ver}${ep_date}/eclipse-SDK-${ep_ver}-${ep_arch}.tar.gz;
+ # The eclipse site has moments where it is overloaded. Maintaining
our own mirror solves this.
+ 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}
@@ -178,7 +180,11 @@ update_feature_remote()
}
#Eclipse Update Site
-MAIN_UPDATE_SITE=http://download.eclipse.org/releases/juno;
+#MAIN_UPDATE_SITE=http://download.eclipse.org/releases/juno;
+# The main eclipse download site is unreliable at times. For now,
we're going to
+# maintain a mirror of just what we need.
+MAIN_UPDATE_SITE=http://downloads.yoctoproject.org/eclipse/juno/ftp.osuosl.org/pub/eclipse/releases/juno;
+
UPDATE_SITE=${MAIN_UPDATE_SITE}
#CDT related
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
