[yocto] bring mipsel support (little endian mode)
HI ALL: Sorry for crossing post, but I'm quite new here, so if I did something wrong, please point me the right direction. thanks I'm using oe-core, and notice that mipsel support(o32, little endian mode) is missing (current available choose is: qemumips, qemumips64, qemumips64el). So, here I'm trying to bring up qemumipsel support . My first attempt would just make qemumipsel work, further would make it running on real board, thus maybe mips4kec, mips24k, mips74k chips. What I achieved here current: 1) toolchain/basic libs, utilities should works ,only one changes, see my patch [a] for mipsel we also have to filter out -march=mips32, previously we only handle mips (the big endian?) don't have the error message now, but if you request, I can provide. 2) attempt to compile kernel to support qemumipsel, unfortunately it fail. The point here is linux-yocto doesn't support qemumipsel, but merely support those other three mips arches, So here is my attempt patch [b], and the fail log [c], complied out binary still big endian. Could my patch [a] be accepted? or should I send with another mail for better review? Is it better to request a ticket in yocto's bugzilla? or just report here, I'm not quite sure. Dennis [a] 0001-eglibc-support-mipsel-little-endian-filter-out-march.patch [b] 0002-qemu-attempt-to-add-mipsel-little-endian-support-but.patch [c] build_log.txt [d] log.do_package Loading cache...done. Loaded 1123 entries from dependency cache. Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = mipsel TARGET_OS = linux MACHINE = qemumipsel DISTRO_VERSION= oe-core.0 TUNE_FEATURES = o32 fpu-hard mips32 TARGET_FPU= meta = master:b7225858d99d9e308aaa700c818d192a0bc831c8 NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Running setscene task 197 of 325 (/home/dennis/oe/oe-core/meta/recipes-kernel/linux/linux-yocto_3.4.bb, do_populate_sysroot_setscene) NOTE: Running setscene task 198 of 325 (/home/dennis/oe/oe-core/meta/recipes-kernel/linux/linux-yocto_3.4.bb, do_deploy_setscene) NOTE: Running setscene task 199 of 325 (/home/dennis/oe/oe-core/meta/recipes-kernel/linux/linux-yocto_3.4.bb, do_populate_lic_setscene) NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_populate_sysroot_setscene: Started NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_deploy_setscene: Started NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_populate_lic_setscene: Started NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_deploy_setscene: Succeeded NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_populate_lic_setscene: Succeeded NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_populate_sysroot_setscene: Succeeded NOTE: Executing RunQueue Tasks NOTE: Running task 294 of 916 (ID: 6, /home/dennis/oe/oe-core/meta/recipes-kernel/linux/linux-yocto_3.4.bb, do_fetch) NOTE: Running task 803 of 916 (ID: 538, /home/dennis/oe/oe-core/meta/recipes-devtools/perl/perl_5.14.2.bb, do_package_write_ipk) NOTE: Running task 820 of 916 (ID: 439, /home/dennis/oe/oe-core/meta/recipes-core/eglibc/eglibc_2.15.bb, do_package_write_ipk) NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_fetch: Started NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_fetch: Succeeded NOTE: Running task 895 of 916 (ID: 2, /home/dennis/oe/oe-core/meta/recipes-kernel/linux/linux-yocto_3.4.bb, do_unpack) NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_unpack: Started NOTE: package perl-5.14.2-r7: task do_package_write_ipk: Started NOTE: package eglibc-2.15-r12+svnr17386: task do_package_write_ipk: Started NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_unpack: Succeeded NOTE: Running task 896 of 916 (ID: 1, /home/dennis/oe/oe-core/meta/recipes-kernel/linux/linux-yocto_3.4.bb, do_kernel_checkout) NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0: task do_kernel_checkout: Started NOTE: package linux-yocto-3.4.1+git1+aa226dcc5a1351fae49da40d77b718c4c3a76e7c_1+c6104a63aae262ff4238b45905ab1c57145334bc-r0:
Re: [yocto] [OE-core] bring mipsel support (little endian mode)
On Tue, Jun 26, 2012 at 11:25 PM, Dennis.Yxun dennis.y...@gmail.com wrote: HI ALL: Sorry for crossing post, but I'm quite new here, so if I did something wrong, please point me the right direction. thanks I'm using oe-core, and notice that mipsel support(o32, little endian mode) is missing (current available choose is: qemumips, qemumips64, qemumips64el). So, here I'm trying to bring up qemumipsel support . My first attempt would just make qemumipsel work, further would make it running on real board, thus maybe mips4kec, mips24k, mips74k chips. What I achieved here current: 1) toolchain/basic libs, utilities should works ,only one changes, see my patch [a] for mipsel we also have to filter out -march=mips32, previously we only handle mips (the big endian?) don't have the error message now, but if you request, I can provide. 2) attempt to compile kernel to support qemumipsel, unfortunately it fail. The point here is linux-yocto doesn't support qemumipsel, but merely support those other three mips arches, So here is my attempt patch [b], and the fail log [c], complied out binary still big endian. Could my patch [a] be accepted? or should I send with another mail for better review? Is it better to request a ticket in yocto's bugzilla? or just report here, I'm not quite sure. Dennis [a] 0001-eglibc-support-mipsel-little-endian-filter-out-march.patch This patch is appropriate for OE-Core, I will add it to my tree. [b] 0002-qemu-attempt-to-add-mipsel-little-endian-support-but.patch This looks good to me but I will leave it to Bruce to decide. [c] build_log.txt [d] log.do_package ___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] bring mipsel support (little endian mode)
hi Raj: On Wed, Jun 27, 2012 at 2:40 PM, Khem Raj raj.k...@gmail.com wrote: On Tue, Jun 26, 2012 at 11:25 PM, Dennis.Yxun dennis.y...@gmail.com wrote: HI ALL: Sorry for crossing post, but I'm quite new here, so if I did something wrong, please point me the right direction. thanks I'm using oe-core, and notice that mipsel support(o32, little endian mode) is missing (current available choose is: qemumips, qemumips64, qemumips64el). So, here I'm trying to bring up qemumipsel support . My first attempt would just make qemumipsel work, further would make it running on real board, thus maybe mips4kec, mips24k, mips74k chips. What I achieved here current: 1) toolchain/basic libs, utilities should works ,only one changes, see my patch [a] for mipsel we also have to filter out -march=mips32, previously we only handle mips (the big endian?) don't have the error message now, but if you request, I can provide. 2) attempt to compile kernel to support qemumipsel, unfortunately it fail. The point here is linux-yocto doesn't support qemumipsel, but merely support those other three mips arches, So here is my attempt patch [b], and the fail log [c], complied out binary still big endian. Could my patch [a] be accepted? or should I send with another mail for better review? Is it better to request a ticket in yocto's bugzilla? or just report here, I'm not quite sure. Dennis [a] 0001-eglibc-support-mipsel-little-endian-filter-out-march.patch This patch is appropriate for OE-Core, I will add it to my tree. [b] 0002-qemu-attempt-to-add-mipsel-little-endian-support-but.patch This looks good to me but I will leave it to Bruce to decide. [c] build_log.txt [d] log.do_package ___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto I'm quite confident with patch [a], but not sure with patch [b], since it should point to a sanity SRCREV which works for qemumipsel - little endian side, but here I'm simply duplicate from qemumips (the big endian port). should confirm?! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Hi Tim, On 26/06/12 19:52, Tim Bird wrote: On 06/26/2012 10:18 AM, Tomas Frydrych wrote: For example, after reading various FAQs I still have no idea what kind of thing Poky is. I know that bitbake is a build tool. I know that OE is a package meta-information project. Yocto Project is an umbrella project for a lot of tools and technologies (Poky among them). But is Poky a distro (sample/reference or otherwise?) or something else? For those of us who have been around Poky well before Yocto came around, we know what Poky used to be, have some inkling what it is, but we are not always entirely clear what Yocto is. :-) When I ran my recently-built image, my target /etc/issue had this content: Yocto (Built by Poky 7.0) 1.2 My understanding (with the above disclaimer!) is that Poky is a build system, Yocto is a distro, so I read the above 'Yocto v1.2 image built by the Poky v7.0 tool'. I think the point of maintaining the distinction is that you can use Poky without the Yocto Distro (/meta-yocto). Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Hi, On 26/06/12 18:59, Brian Duffy wrote: No, an FAQ should not get you the expertise to create a commercial grade product. Reading the documentation should though. You don't want users to have to study source code. If you were paying for the tools, then that would be a reasonable expectation, but you are not. It is entirely fair to point out that the documentation is lacking; it is not at all fair to expect that someone will fix it for you at their own expense. If you are working on a commercial product, you can, of course, pay someone to improve the documentation (and even contribute it back to the project). Also, I think in the Poky context it is better to talk about developers rather than users; to build a commercial product, your team will need to have a pretty solid grasp of every aspect of a Linux system. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Development Manual Appendix B question
On 06/26/2012 04:43 PM, Rifenbark, Scott M wrote: Jim, Did you cleansstate before building and using menuconfig? There is a bug (2256) that prevents configurations made using menuconfig from sticking. As I said from my iPhone last night, yes I did do cleansstate as stated in the manual. I will reset and run a test of Apendix B.2 taking the path of not having done B.1 first. Maybe the stuff related to setting up you local kernel and modifying the source had some impact. More later. JIm A Scott -Original Message- From: jfabernathy [mailto:jfaberna...@gmail.com] Sent: Tuesday, June 26, 2012 1:40 PM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote: Jim, Yes - I am still running the very last part of my test. If that is the change then I will make it to the 1.2 version of the manual and publish it to the website. Scott While I had this working I thought I'd complete the Appendix B example for the CONFIG_SMP change. I'm finding problems with the compile step after menuconfig is run to turn off SMP. I get a mismatch that I don't understand: Value requested for CONFIG_SMP not in final .config Requested value: CONFIG_SMP=y Actual value set: # CONFIG_SMP is not set There must be another setting of CONFIG_SMP that is conflicting with the .config file Jim A -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy Sent: Tuesday, June 26, 2012 12:50 PM To: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote: When I attempted to rebuild minimal I hit the same error you did Jim regarding kern-tools-native. This would be expected as Bruce pointed out that problem is alive in denzil. I am going to set the poky-extras branch to 'denzil' and retry that part of the example. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Rifenbark, Scott M Sent: Tuesday, June 26, 2012 10:44 AM To: Bruce Ashfield Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question I am on task 1507 of 1606 of a minimal build (from the example). No issues so far. So now that Denzil has a branch in poky-extra, the only doc change is to add the checkout -b denzil statement for the poky-extra directory. Everything else is correct. Jim A -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 10:42 AM To: Rifenbark, Scott M Cc: jfabernathy; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:30 PM, Rifenbark, Scott M wrote: I am going to run through the B.1 example verbatim from the current version of the manual and see what happens. Fixing the license check was just a matter of me locking the SRCREV for the tools to a value that works for denzil. I just pushed a denzil branch to poky-extras that built and booted the yocto kernel for me. Cheers, Bruce Scott -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 9:28 AM To: Rifenbark, Scott M Cc: jfabernathy; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:26 PM, Rifenbark, Scott M wrote: This is a good point. In looking at the example it does not say what branch you should be dealing with for poky-extras. And I'm configuring a test right now and will create a denzil branch, once I see it works. Cheers, Bruce -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 9:24 AM To: jfabernathy Cc: Rifenbark, Scott M; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:11 PM, jfabernathy wrote: On 06/26/2012 12:04 PM, Bruce Ashfield wrote: On 12-06-26 12:00 PM, jfabernathy wrote: On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote: Bruce, Should the example note this? Would it be best to specifically say to uncomment that SRC_URI line? Scott I think some text needs to be added. I uncommented the SRC_URI line and I still fail building the image. The failure is related to kernel tools: ERROR: kern-tools-native: md5 data is not matching for file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee ERROR: kern-tools-native: The new md5 checksum is d8d1d729a70cd5f52972f8884b80743d ERROR: kern-tools-native: Check if the license information has changed in ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix ERROR: Function failed: do_qa_configure This one is actually fixed on master, but poky-extras .. is just that 'extra', so this may still be alive in that repo. This wouldn't need to be
Re: [yocto] [OE-core] bring mipsel support (little endian mode)
On Wed, Jun 27, 2012 at 2:40 AM, Khem Raj raj.k...@gmail.com wrote: On Tue, Jun 26, 2012 at 11:25 PM, Dennis.Yxun dennis.y...@gmail.com wrote: HI ALL: Sorry for crossing post, but I'm quite new here, so if I did something wrong, please point me the right direction. thanks I'm using oe-core, and notice that mipsel support(o32, little endian mode) is missing (current available choose is: qemumips, qemumips64, qemumips64el). So, here I'm trying to bring up qemumipsel support . My first attempt would just make qemumipsel work, further would make it running on real board, thus maybe mips4kec, mips24k, mips74k chips. What I achieved here current: 1) toolchain/basic libs, utilities should works ,only one changes, see my patch [a] for mipsel we also have to filter out -march=mips32, previously we only handle mips (the big endian?) don't have the error message now, but if you request, I can provide. 2) attempt to compile kernel to support qemumipsel, unfortunately it fail. The point here is linux-yocto doesn't support qemumipsel, but merely support those other three mips arches, So here is my attempt patch [b], and the fail log [c], complied out binary still big endian. Could my patch [a] be accepted? or should I send with another mail for better review? Is it better to request a ticket in yocto's bugzilla? or just report here, I'm not quite sure. Dennis [a] 0001-eglibc-support-mipsel-little-endian-filter-out-march.patch This patch is appropriate for OE-Core, I will add it to my tree. [b] 0002-qemu-attempt-to-add-mipsel-little-endian-support-but.patch This looks good to me but I will leave it to Bruce to decide. I've always had latent support for mipsel in the kernel tree, since it is just a minor switch to the configs for the mti. We'd also sent the KMACHINE to mti-malta32-le to pickup the le configuration switches from the kernel .. or alternatively, I'll just update the description to match on qemumipsel. I'd want to do some build and boot testing myself first though, Phil seemed to indicate that patch a) wasn't required. I'll start my own build and see if my results match. So if there's a desire to get this into oe-core, I can take care of the kernel tweaks (and then carry it), but I'd expect Richard has an opinion on this, since it really should be something that we then build and minimally test on a regular basis. Cheers, Bruce [c] build_log.txt [d] log.do_package ___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ 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
[yocto] fetch log file errors
here's the log file for one of the tarballs that should have been
fetched from my local mirror:
DEBUG: Executing python function do_fetch
DEBUG: Executing python function base_do_fetch
DEBUG: Trying PREMIRRORS
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['cvs', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['svn', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['git', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['hg', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['bzr', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['svk', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['p4', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['osc', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['https?$', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '',
'', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['ftp', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '', {}]
DEBUG: Trying Upstream
NOTE: fetch
http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz
DEBUG: executing /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
--no-check-certificate -P /home/rpjday/yocto/builds/bbc4/downloads
'http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz'
DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Function failed: Network access disabled through BB_NO_NETWORK but
access requested with command /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
--no-check-certificate -P /home/rpjday/yocto/builds/bbc4/downloads
'http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz'
(for url None)
not sure what i should be seeing here, and i can guarantee that the
tarball gnu-config-yocto-2011.tgz is in my ~/dl directory, as are
numerous others that are now being fetched from the net rather than my
local mirror.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fetch log file errors
On Wed, Jun 27, 2012 at 09:30:59AM -0400, Robert P. J. Day wrote:
here's the log file for one of the tarballs that should have been
fetched from my local mirror:
DEBUG: Executing python function do_fetch
DEBUG: Executing python function base_do_fetch
DEBUG: Trying PREMIRRORS
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['cvs', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['svn', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['git', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['hg', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['bzr', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['svk', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['p4', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['osc', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['https?$', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '',
'', {}]
DEBUG: For url ['http', 'downloads.yoctoproject.org',
'/releases/gnu-config/gnu-config-yocto-2011.tgz', '', '', {}] comparing
['ftp', '.*', '/.*', '', '', {}] to ['file', '', '/home/rpjday/dl/', '', '',
{}]
DEBUG: Trying Upstream
NOTE: fetch
http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz
DEBUG: executing /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
--no-check-certificate -P /home/rpjday/yocto/builds/bbc4/downloads
'http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz'
DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Function failed: Network access disabled through BB_NO_NETWORK but
access requested with command /usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
--no-check-certificate -P /home/rpjday/yocto/builds/bbc4/downloads
'http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-2011.tgz'
(for url None)
not sure what i should be seeing here, and i can guarantee that the
tarball gnu-config-yocto-2011.tgz is in my ~/dl directory, as are
numerous others that are now being fetched from the net rather than my
local mirror.
see
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-June/024465.html
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] LAMP layer
Hi all, In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc. I think we have the L pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either). So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date. Some of the other things I'm looking at adding more immediately: * collectd * mysql-connector-odbc * phpMyAdmin * unixODBC * xdebug The question of how this should all be structured is still not fully determined. I'm thinking this ought to be at least one additional layer (i.e. meta-lamp, or some other name), even in the face of the proposed meta- networking, since the number of recipes in the LAMP layer is likely to grow over time and it's a specific set of functionality that people would explicitly select. I now have updated apache and modphp recipes building and working reasonably well, although further testing will be needed. Initially I'm prepared to maintain these recipes, however if not immediately at some point in the near future it would be good to see a maintainer step forward with more specific knowledge of these particular pieces of software. Thoughts? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Development Manual Appendix B question
I have added a note to the manual explaining this warning. Thanks, Scott -Original Message- From: jfabernathy [mailto:jfaberna...@gmail.com] Sent: Wednesday, June 27, 2012 4:36 AM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/27/2012 06:35 AM, jfabernathy wrote: On 06/26/2012 04:43 PM, Rifenbark, Scott M wrote: Jim, Did you cleansstate before building and using menuconfig? There is a bug (2256) that prevents configurations made using menuconfig from sticking. As I said from my iPhone last night, yes I did do cleansstate as stated in the manual. I will reset and run a test of Apendix B.2 taking the path of not having done B.1 first. Maybe the stuff related to setting up you local kernel and modifying the source had some impact. More later. JIm A Okay I did the example B.2 in the developer manual without having done B.1 first. Summary is it works as documented. However, the WARNING below scared me into thinking I had an issue. If I ignore it, everything works. I was surprised that after recompiling linux-yocto and building it, I didn't have to rebuild the image. I would have thought that a step of bitbake core-image-minimal was needed to add the newly compiled and built kernel to the boot image. Anyway, here's the warning and the contents of the mismatch.cfg file: WARNING: There were 1 hardware options requested that do not have a corresponding value present in the final .config file. This probably means you aren't getting the config you wanted. The full list can be found in your workspace at: /build/qemux86/tmp/work/qemux86-poky-linux/linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+c228cadee60f0ada73d11a36f6932f50a1c52d48-r1/linux/meta/cfg/standard/default/common-pc/mismatch.cfg Waiting a second to make sure you get a chance to see this... - The file mismatch.cfg contains: Value requested for CONFIG_SMP not in final .config Requested value: CONFIG_SMP=y Actual value set: # CONFIG_SMP is not set Jim A Scott -Original Message- From: jfabernathy [mailto:jfaberna...@gmail.com] Sent: Tuesday, June 26, 2012 1:40 PM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote: Jim, Yes - I am still running the very last part of my test. If that is the change then I will make it to the 1.2 version of the manual and publish it to the website. Scott While I had this working I thought I'd complete the Appendix B example for the CONFIG_SMP change. I'm finding problems with the compile step after menuconfig is run to turn off SMP. I get a mismatch that I don't understand: Value requested for CONFIG_SMP not in final .config Requested value: CONFIG_SMP=y Actual value set: # CONFIG_SMP is not set There must be another setting of CONFIG_SMP that is conflicting with the .config file Jim A -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy Sent: Tuesday, June 26, 2012 12:50 PM To: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote: When I attempted to rebuild minimal I hit the same error you did Jim regarding kern-tools-native. This would be expected as Bruce pointed out that problem is alive in denzil. I am going to set the poky-extras branch to 'denzil' and retry that part of the example. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Rifenbark, Scott M Sent: Tuesday, June 26, 2012 10:44 AM To: Bruce Ashfield Cc: yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question I am on task 1507 of 1606 of a minimal build (from the example). No issues so far. So now that Denzil has a branch in poky-extra, the only doc change is to add the checkout -b denzil statement for the poky-extra directory. Everything else is correct. Jim A -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 26, 2012 10:42 AM To: Rifenbark, Scott M Cc: jfabernathy; yocto@yoctoproject.org Subject: Re: [yocto] Yocto Development Manual Appendix B question On 12-06-26 12:30 PM, Rifenbark, Scott M wrote: I am going to run through the B.1 example verbatim from the current version of the manual and see what happens. Fixing the license check was just a matter of me locking the SRCREV for the tools to a value that works for denzil. I just pushed a denzil branch to poky-extras that built and booted the yocto kernel for me. Cheers, Bruce Scott -Original Message- From: Bruce Ashfield
[yocto] Yocto Development Manual Appendix B redux
Just to simplify the previous thread on this subject. To solve the issue I brought up about the Development Manual Appendix B examples, it boils down to this: 1. A denzil branch of poky-extra has now been created to solve the bug I experienced. 2. The only instruction that needs to be added to the appendix is to have the user checkout the denzil branch of poky-extra to match the fact that they are using the denzil branch of poky. 3. The warning about a kernel parameter mismatch should be ignored. A note to this effect would be helpful. With the 3 items taken into account, the examples run as documented either doing B.1, then B.2 or just starting with B.2. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Development Manual Appendix B redux
Awesome! Both documentation points have been dealt with. Thanks for running through this stuff Jim. Scott -Original Message- From: jfabernathy [mailto:jfaberna...@gmail.com] Sent: Wednesday, June 27, 2012 7:54 AM To: Rifenbark, Scott M; yocto@yoctoproject.org Subject: Yocto Development Manual Appendix B redux Just to simplify the previous thread on this subject. To solve the issue I brought up about the Development Manual Appendix B examples, it boils down to this: 1. A denzil branch of poky-extra has now been created to solve the bug I experienced. 2. The only instruction that needs to be added to the appendix is to have the user checkout the denzil branch of poky-extra to match the fact that they are using the denzil branch of poky. 3. The warning about a kernel parameter mismatch should be ignored. A note to this effect would be helpful. With the 3 items taken into account, the examples run as documented either doing B.1, then B.2 or just starting with B.2. Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Op 27 jun. 2012 om 11:09 heeft Tomas Frydrych tf+lists.yo...@r-finger.com het volgende geschreven: Hi Tim, On 26/06/12 19:52, Tim Bird wrote: On 06/26/2012 10:18 AM, Tomas Frydrych wrote: For example, after reading various FAQs I still have no idea what kind of thing Poky is. I know that bitbake is a build tool. I know that OE is a package meta-information project. Yocto Project is an umbrella project for a lot of tools and technologies (Poky among them). But is Poky a distro (sample/reference or otherwise?) or something else? For those of us who have been around Poky well before Yocto came around, we know what Poky used to be, have some inkling what it is, but we are not always entirely clear what Yocto is. :-) When I ran my recently-built image, my target /etc/issue had this content: Yocto (Built by Poky 7.0) 1.2 My understanding (with the above disclaimer!) is that Poky is a build system, Yocto is a distro, so I read the above 'Yocto v1.2 image built by the Poky v7.0 tool'. I think the point of maintaining the distinction is that you can use Poky without the Yocto Distro (/meta-yocto). Yocto is NOT a distro. Poky is both a distro and buildsystem. This thread highlights the reason the oe folks have been pushing to get rid of the 'poky' name completely to avoid needless confusing situations like this. It's sad to see that even the official stuff gets it wrong... Tomas ___ 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] bring mipsel support (little endian mode)
On 12-06-27 02:25 AM, Dennis.Yxun wrote: HI ALL: Sorry for crossing post, but I'm quite new here, so if I did something wrong, please point me the right direction. thanks I'm using oe-core, and notice that mipsel support(o32, little endian mode) is missing (current available choose is: qemumips, qemumips64, qemumips64el). So, here I'm trying to bring up qemumipsel support . My first attempt would just make qemumipsel work, further would make it running on real board, thus maybe mips4kec, mips24k, mips74k chips. What I achieved here current: 1) toolchain/basic libs, utilities should works ,only one changes, see my patch [a] for mipsel we also have to filter out -march=mips32, previously we only handle mips (the big endian?) don't have the error message now, but if you request, I can provide. 2) attempt to compile kernel to support qemumipsel, unfortunately it fail. The point here is linux-yocto doesn't support qemumipsel, but merely support those other three mips arches, So here is my attempt patch [b], and the fail log [c], complied out binary still big endian. Since it was easy enough to do, and doesn't imply any sort of full support (since I can't declare that), I did the tweak to the mips board descriptions and qemumipsel works without any machine mapping in the linux-yocto recipes. I pushed the change to the linux-yocto-3.4 meta branch, and staged a commit for it locally. You can see that commit here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/mipsel .. stacked on top of my other pending 3.4 commits. Note: I didn't update machine compatibility in that commit on purpose, and I wasn't able to complete a full core-image-minimal build due to QA issues. I'm probably just not building with a complete machine.conf .. since I grabbed one quickly this morning to check the kernel parts. Cheers, Bruce Could my patch [a] be accepted? or should I send with another mail for better review? Is it better to request a ticket in yocto's bugzilla? or just report here, I'm not quite sure. Dennis [a] 0001-eglibc-support-mipsel-little-endian-filter-out-march.patch [b] 0002-qemu-attempt-to-add-mipsel-little-endian-support-but.patch [c] build_log.txt [d] log.do_package ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On 27/06/12 15:05, Paul Eggleton wrote: Hi all, In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc. I think we have the L pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either). So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date. Some of the other things I'm looking at adding more immediately: * collectd * mysql-connector-odbc * phpMyAdmin * unixODBC * xdebug The question of how this should all be structured is still not fully determined. I'm thinking this ought to be at least one additional layer (i.e. meta-lamp, or some other name), even in the face of the proposed meta- networking, since the number of recipes in the LAMP layer is likely to grow over time and it's a specific set of functionality that people would explicitly select. I now have updated apache and modphp recipes building and working reasonably well, although further testing will be needed. Initially I'm prepared to maintain these recipes, however if not immediately at some point in the near future it would be good to see a maintainer step forward with more specific knowledge of these particular pieces of software. Thoughts? Cheers, Paul Hi Paul, I think this is a fantastic idea in general and if I remember correctly someone from Linaro was attempting to do something similar to this the other day - so I can't only be me who would appreciate something like this. The one issue I have (initially) is why should it be limited to the Apache web server? There are a couple of good web servers out there which lend themselves much more to an embedded style development than (IMO) the bloat that is Apache. For example: Lighttpd (already in core) nginx Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP) I also remember someone from WindRiver posted recently regarding a meta-networking layer, which I also thought was a great idea if not only for (in my use case) tftp/net-snmp support all rolled up and supported. Maybe this could be a layer with that section? i.e. meta-networking meta-webserver (meta-l*mp?) recipes-* recipes-* meta-* I'm sure you get the idea... Regards, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On Wed, Jun 27, 2012 at 7:05 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Hi all, In conjunction with the folks at Wind River I'm currently in the process of putting together a layer to support the traditional LAMP stack, and wanted to solicit some opinions on how this might be structured/named/etc. I think we have the L pretty much covered ;) and we have MySQL in meta-oe (I'm not convinced that's where it should stay, although perhaps it need not be tied to this layer either). So the layer would at the very least be adding Apache and PHP, with the possibility of web-related python and perl recipes being added at a later date. Some of the other things I'm looking at adding more immediately: * collectd * mysql-connector-odbc * phpMyAdmin * unixODBC * xdebug The question of how this should all be structured is still not fully determined. I'm thinking this ought to be at least one additional layer (i.e. meta-lamp, or some other name), even in the face of the proposed meta- networking, since the number of recipes in the LAMP layer is likely to grow over time and it's a specific set of functionality that people would explicitly select. I now have updated apache and modphp recipes building and working reasonably well, although further testing will be needed. Initially I'm prepared to maintain these recipes, however if not immediately at some point in the near future it would be good to see a maintainer step forward with more specific knowledge of these particular pieces of software. Thoughts? I think PHP probably is common enough to be part of meta-oe or core. instead of lamp call it something else may be meta-webservers or something and more alternatives can also be put in there Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ 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] LAMP layer
On 27/06/12 16:22, Jack Mitchell wrote: Lighttpd (already in core) nginx Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP) I'd add Cherokee to the list; there is a recipe in meta-oe. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On Wednesday 27 June 2012 16:22:09 Jack Mitchell wrote: I think this is a fantastic idea in general and if I remember correctly someone from Linaro was attempting to do something similar to this the other day - so I can't only be me who would appreciate something like this. Indeed, I saw Marcin's earlier thread - at the time I wasn't far enough along to reply unfortunately (was just an item on my todo list), but at least there's interest :) The one issue I have (initially) is why should it be limited to the Apache web server? There are a couple of good web servers out there which lend themselves much more to an embedded style development than (IMO) the bloat that is Apache. For example: Lighttpd (already in core) nginx Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP) I agree Apache is not something you would typically consider to be embedded- friendly, however if you've already got something web-based that is built on top of Apache or relies on functionality that only Apache can provide, and you want to integrate that into an embedded product, then nothing else will really suffice. However I do think there's scope to include these other alternatives particularly if the layer turns into more of a generic web server layer, but I can't commit to maintaining (specifically, updating and testing) the additional recipes on my own. I also remember someone from WindRiver posted recently regarding a meta-networking layer, which I also thought was a great idea if not only for (in my use case) tftp/net-snmp support all rolled up and supported. Maybe this could be a layer with that section? i.e. meta-networking meta-webserver (meta-l*mp?) recipes-* recipes-* meta-* Whenever a new layer is introduced there's always the question of where it should be physically located. I worry more about the confusion that multi- level layers cause - particularly when they're named the same thing - than I do about multiple repositories, but I realise others have different viewpoints. If they are in separate repositories there's still nothing stopping them being used together. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On 27/06/2012 17:27, Paul Eggleton wrote: On Wednesday 27 June 2012 16:22:09 Jack Mitchell wrote: I think this is a fantastic idea in general and if I remember correctly someone from Linaro was attempting to do something similar to this the other day - so I can't only be me who would appreciate something like this. Indeed, I saw Marcin's earlier thread - at the time I wasn't far enough along to reply unfortunately (was just an item on my todo list), but at least there's interest :) The one issue I have (initially) is why should it be limited to the Apache web server? There are a couple of good web servers out there which lend themselves much more to an embedded style development than (IMO) the bloat that is Apache. For example: Lighttpd (already in core) nginx Hiawatha (my personal favourite - I have a recipe I already use in conjunction with PHP) I agree Apache is not something you would typically consider to be embedded- friendly, however if you've already got something web-based that is built on top of Apache or relies on functionality that only Apache can provide, and you want to integrate that into an embedded product, then nothing else will really suffice. However I do think there's scope to include these other alternatives particularly if the layer turns into more of a generic web server layer, but I can't commit to maintaining (specifically, updating and testing) the additional recipes on my own. I would be happy to contribute the hiawatha recipe (it's just simple cmake job), but I understand your earlier comment on standalone PHP as it is indeed a minefield. I tried to update it some weeks ago and failed miserably. Possibly just do your part and let people send in patches against the layer as is done with meta-oe? I also remember someone from WindRiver posted recently regarding a meta-networking layer, which I also thought was a great idea if not only for (in my use case) tftp/net-snmp support all rolled up and supported. Maybe this could be a layer with that section? i.e. meta-networking meta-webserver (meta-l*mp?) recipes-* recipes-* meta-* Whenever a new layer is introduced there's always the question of where it should be physically located. I worry more about the confusion that multi- level layers cause - particularly when they're named the same thing - than I do about multiple repositories, but I realise others have different viewpoints. If they are in separate repositories there's still nothing stopping them being used together. I do agree that layers within layers is a bit confusing, however the earlier proposed meta-networking included having some of the applications in this proposed layer too. If this was instead, then it's fine, but if it's as well then it could get confusing. A possible compromise could be a git sub-module for meta-lamp inside meta-networking, or at least a file containing the meta-lamp location and highlighting its availability? Cheers, Paul ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Hi all - looks like it has been a busy morning while I wasn't looking! I was the last one to touch the FAQ on the wiki, and I can attest that its goal is not to be an end-all be-all technical FAQ, of the how-do-I variety or any other. It should have more correct language in it, to which I will attend directly. We DO have an interactive technical FAQ planned along with a full upgrade on the website sometime in August. Meanwhile, we can certainly use that FAQ for some actual questions that come up frequently, like adding a package. I can add that immediately, and will point toward Robert's FAQ page as well. Koen quoth: 'Do you mean yocto or do you mean poky?'. The reaction to that can go a few ways and the follow up actions I recommend: 1) People don't get the question and/or don't know the difference between 'yocto' and 'poky'. Pretend you have a nosebleed and walk away, fast 2) People say Right, I meant the buildsystem, not the umbrella project or No, I really meant 'yocto' as the umbrella project. Continue the conversation. 3) People say Koen put you up to this, didn't he?. You're most likely talking to Dave or Saul, buy them lunch :) ROFL -- 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] rantthe current yocto FAQ is pretty much valueless/rant
On Wed, Jun 27, 2012 at 10:59 AM, Koen Kooi k...@beagleboard.org wrote: Op 27 jun. 2012 om 11:09 heeft Tomas Frydrych tf+lists.yo...@r-finger.com het volgende geschreven: Hi Tim, On 26/06/12 19:52, Tim Bird wrote: On 06/26/2012 10:18 AM, Tomas Frydrych wrote: For example, after reading various FAQs I still have no idea what kind of thing Poky is. I know that bitbake is a build tool. I know that OE is a package meta-information project. Yocto Project is an umbrella project for a lot of tools and technologies (Poky among them). But is Poky a distro (sample/reference or otherwise?) or something else? For those of us who have been around Poky well before Yocto came around, we know what Poky used to be, have some inkling what it is, but we are not always entirely clear what Yocto is. :-) When I ran my recently-built image, my target /etc/issue had this content: Yocto (Built by Poky 7.0) 1.2 My understanding (with the above disclaimer!) is that Poky is a build system, Yocto is a distro, so I read the above 'Yocto v1.2 image built by the Poky v7.0 tool'. I think the point of maintaining the distinction is that you can use Poky without the Yocto Distro (/meta-yocto). Yocto is NOT a distro. Poky is both a distro and buildsystem. This thread highlights the reason the oe folks have been pushing to get rid of the 'poky' name completely to avoid needless confusing situations like this. It's sad to see that even the official stuff gets it wrong... I took a stab at clarifying the terminology in a blog post back in April. I *think* I got it mostly right ;) http://blogs.mentor.com/chrishallinan/blog/2012/04/13/yocto-versus-poky-versus-angstrom-etc/ Regards, Chris -- Life is like Linux - it never stands still. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On Wednesday 27 June 2012 17:40:44 Jack Mitchell wrote: I do agree that layers within layers is a bit confusing, however the earlier proposed meta-networking included having some of the applications in this proposed layer too. If this was instead, then it's fine, but if it's as well then it could get confusing. It's something I've been discussing with Joe MacDonald already. I think it's an either-or situation - the recipes will not need to be in both layers. People who want recipes from either or both layers should be able to include the layers as needed. A possible compromise could be a git sub-module for meta-lamp inside meta-networking, or at least a file containing the meta-lamp location and highlighting its availability? Given the above I think a pointer in the meta-networking README towards the web server layer would be reasonable. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Op 27 jun. 2012 om 18:43 heeft Chris Hallinan challi...@gmail.com het volgende geschreven: On Wed, Jun 27, 2012 at 10:59 AM, Koen Kooi k...@beagleboard.org wrote: Op 27 jun. 2012 om 11:09 heeft Tomas Frydrych tf+lists.yo...@r-finger.com het volgende geschreven: Hi Tim, On 26/06/12 19:52, Tim Bird wrote: On 06/26/2012 10:18 AM, Tomas Frydrych wrote: For example, after reading various FAQs I still have no idea what kind of thing Poky is. I know that bitbake is a build tool. I know that OE is a package meta-information project. Yocto Project is an umbrella project for a lot of tools and technologies (Poky among them). But is Poky a distro (sample/reference or otherwise?) or something else? For those of us who have been around Poky well before Yocto came around, we know what Poky used to be, have some inkling what it is, but we are not always entirely clear what Yocto is. :-) When I ran my recently-built image, my target /etc/issue had this content: Yocto (Built by Poky 7.0) 1.2 My understanding (with the above disclaimer!) is that Poky is a build system, Yocto is a distro, so I read the above 'Yocto v1.2 image built by the Poky v7.0 tool'. I think the point of maintaining the distinction is that you can use Poky without the Yocto Distro (/meta-yocto). Yocto is NOT a distro. Poky is both a distro and buildsystem. This thread highlights the reason the oe folks have been pushing to get rid of the 'poky' name completely to avoid needless confusing situations like this. It's sad to see that even the official stuff gets it wrong... I took a stab at clarifying the terminology in a blog post back in April. I *think* I got it mostly right ;) http://blogs.mentor.com/chrishallinan/blog/2012/04/13/yocto-versus-poky-versus-angstrom-etc/ That sums it up pretty good! Regards, Chris -- Life is like Linux - it never stands still. ___ 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] Display issue with EFI BOOTING
On 06/27/2012 09:21 AM, Bodke, Kishore K wrote: -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: Friday, June 22, 2012 5:06 PM To: Bodke, Kishore K Cc: yocto@yoctoproject.org; Darren Hart (dvh...@linux.intel.com) Subject: Re: [yocto] Display issue with EFI BOOTING On Fri, Jun 22, 2012 at 3:28 PM, Bodke, Kishore K kishore.k.bo...@intel.com wrote: Hi, Yocto logo displays fines when booted with BIOS. But I see the Logo Display issue when booted with EFI. Attached are the screen shot. Any Idea why? may be screen refresh rate ? just shooting in dark here Hi Darren, Do you also see the Yocto logo distorted while booting with EFI? I don't see this distorted logo with BIOS. No, it works as expected for me on the FRI2 BSP. -- Darren Thanks Kishore. Thanks Kishore. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LAMP layer
On Wed, Jun 27, 2012 at 9:49 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: It's something I've been discussing with Joe MacDonald already. I think it's an either-or situation - the recipes will not need to be in both layers. People who want recipes from either or both layers should be able to include the layers as needed. from my experience of deploying layers for others. Its quite a talk for folks to get it and on top if you have overlapping recipes they are not making life any easier. if we start using this kind of method, it sure will fume into chaos. I think layers should have some wholeness to them but at the same time they should be leveraging other layers to get functionality they need. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Web Hob - two additional design ideas
Gang - there are a couple of ideas for Web Hob that we have talked about. I don't remember seeing them in the various movies and documents. So I'm going to throw them out there to get your feedback and hopefully get them in the design. * Visualizing the image One of the things which frustrates me about GUI tools which build Linux images is that you usually get a long list of packages to choose from, but no real guidance. I think there are a couple of interesting ways to visualize what is in the image. One would be to add more visual information about what makes up the image, maybe like a pie chart or linear chart which shows the breakdown between kernel, libraries, commands; perhaps with some drill down into these categories to show which libraries, for example. This could be extremely useful for tuning a poky-tiny image for its footprint size. I find I'm also struggling with figuring out how to add a whole subsystem, rather than picking out the packages. This goes beyond the scroll list of packages to add higher-level groups of packages. This might be already present in how we present Tasks to select, so it might already be there. * Finalizing your device's source offer One of the things the Project has been praised on is our support for building license compliant embedded distributions. This turns out to be one of the biggest challenges when people use Linux for their embedded devices - often the Linux gets shipped out on the embedded device, but the sources are not made available as specified in the GPL. Through our tracking and validating of source licenses in recipes, the logic in the build system to restrict licenses used, and the source manifests generated in the build, I think we have a world class solution. This really needs to be supported well in Web Hob. So the requirement here is that when a build is completed, you not only get access to the image (and kernel) but maybe also a tar file of the sources and scripts used to build the image, for purposes of GPL license compliance. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bring mipsel support (little endian mode)
hi bruce: i'm cherry-pick your commit, and it seems compile successfully, though will do a run-time check later, thanks at 2012-6-27 pm11:17，Bruce Ashfield bruce.ashfi...@windriver.comwritten： On 12-06-27 02:25 AM, Dennis.Yxun wrote: HI ALL: Sorry for crossing post, but I'm quite new here, so if I did something wrong, please point me the right direction. thanks I'm using oe-core, and notice that mipsel support(o32, little endian mode) is missing (current available choose is: qemumips, qemumips64, qemumips64el). So, here I'm trying to bring up qemumipsel support . My first attempt would just make qemumipsel work, further would make it running on real board, thus maybe mips4kec, mips24k, mips74k chips. What I achieved here current: 1) toolchain/basic libs, utilities should works ,only one changes, see my patch [a] for mipsel we also have to filter out -march=mips32, previously we only handle mips (the big endian?) don't have the error message now, but if you request, I can provide. 2) attempt to compile kernel to support qemumipsel, unfortunately it fail. The point here is linux-yocto doesn't support qemumipsel, but merely support those other three mips arches, So here is my attempt patch [b], and the fail log [c], complied out binary still big endian. Since it was easy enough to do, and doesn't imply any sort of full support (since I can't declare that), I did the tweak to the mips board descriptions and qemumipsel works without any machine mapping in the linux-yocto recipes. I pushed the change to the linux-yocto-3.4 meta branch, and staged a commit for it locally. You can see that commit here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zedd/mipsel .. stacked on top of my other pending 3.4 commits. Note: I didn't update machine compatibility in that commit on purpose, and I wasn't able to complete a full core-image-minimal build due to QA issues. I'm probably just not building with a complete machine.conf .. since I grabbed one quickly this morning to check the kernel parts. Cheers, Bruce Could my patch [a] be accepted? or should I send with another mail for better review? Is it better to request a ticket in yocto's bugzilla? or just report here, I'm not quite sure. Dennis [a] 0001-eglibc-support-mipsel-little-endian-filter-out-march.patch [b] 0002-qemu-attempt-to-add-mipsel-little-endian-support-but.patch [c] build_log.txt [d] log.do_package ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] making PDF docs, error in fop step, Can't load standard profile: sRGB.pf
Robert, So you do think it is a carry-over of that openjdk-6 error? I thought the error output was very similar. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Wednesday, June 27, 2012 12:48 PM To: Yocto discussion list Subject: Re: [yocto] making PDF docs, error in fop step, Can't load standard profile: sRGB.pf On Wed, 27 Jun 2012, Robert P. J. Day wrote: for the first time in a while, i tried to build the PDF docs, and every attempt ends with a java exception on my 64-bit ubuntu system containing the diagnostic: java.lang.IllegalArgumentException: Can't load standard profile: sRGB.pf i've isolated it to the fop invocation in poky-docbook-to-pdf. i'm using openjdk-7, and it appears that i do have that file installed on my system. i have to bolt for the airport to pick someone up so i can't dig any deeper right this minute, but if anyone else has seen this and has an answer, i'd appreciate it. can anyone else at least verify that they get the same error if they try it on a similar system? thanks. it *seems* fairly clear that this is what's happening to me: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641530 when i try to generate yocto docs in PDF format on my ubuntu 12.04 system using openjdk. and on that note, i'm going back to my beer and wings. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] making PDF docs, error in fop step, Can't load standard profile: sRGB.pf
On Wed, 27 Jun 2012, Rifenbark, Scott M wrote: Robert, So you do think it is a carry-over of that openjdk-6 error? I thought the error output was very similar. i'm digging into it now - that bug report implied that it had been addressed back in openjdk-6, so it's clearly returned under some circumstances. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Hi Koen, On 27/06/12 15:59, Koen Kooi wrote: Yocto is NOT a distro. Is that so? :-), meta-yocto distro.conf: DISTRO = poky DISTRO_NAME = Yocto (Built by Poky 7.0) DISTRO_VERSION = 1.2 I am well aware that textual meaning is pretty much constructed by the reader, and that authorial intent is an elusive concept, but I am ready to argue that the conventional understanding of the above is that Poky is a build tool, and Yocto is the public name of the distro that you build if you use meta-yocto. To read that as 'Yocto is NOT a distro' I think requires a definite pre-understanding that Yocto is not a distro, which would need to come from some other source (or perhaps it is an axiom of faith; myself, I tend hold firmly to the authority of the source code alone). I shall not deny you the right to hold to such a reading, but I do reserve the right to deconstruct it. :-) This thread highlights the reason the oe folks have been pushing to get rid of the 'poky' name completely Perhaps one of the reasons; but then the erasure of Poky would mean that you could no longer say 'Yocto is a NOT a distro', which I suspect would achieve the very opposite of what you seek (and, perhaps more importantly, might cost Dave and Saul a lunch or two). Personally, I think much better solution would be if the distro was simply called Poky v7.0, then we could all say 'Yocto is NOT a distro!' with conviction. Plus Poky is such a lovely name, don't you think? ;-) Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Web Hob - two additional design ideas
On 06/27/2012 12:17 PM, Stewart, David C wrote: Gang - there are a couple of ideas for Web Hob that we have talked about. I don't remember seeing them in the various movies and documents. So I'm going to throw them out there to get your feedback and hopefully get them in the design. * Visualizing the image One of the things which frustrates me about GUI tools which build Linux images is that you usually get a long list of packages to choose from, but no real guidance. I think there are a couple of interesting ways to visualize what is in the image. One would be to add more visual information about what makes up the image, maybe like a pie chart or linear chart which shows the breakdown between kernel, libraries, commands; perhaps with some drill down into these categories to show which libraries, for example. This could be extremely useful for tuning a poky-tiny image for its footprint size. This could be interesting for larger images where we could make use the the SECTION metadata, but might be more of a challenge for a meta-tiny where all you really have is libc (of some flavor) and busybox. There may be additional metadata to help with the drill down further than maybe 1 level. I find I'm also struggling with figuring out how to add a whole subsystem, rather than picking out the packages. This goes beyond the scroll list of packages to add higher-level groups of packages. This might be already present in how we present Tasks to select, so it might already be there. We need to work on renaming the existing task-* recipes to make it more understood as package grouping or pick your descriptive name here * Finalizing your device's source offer One of the things the Project has been praised on is our support for building license compliant embedded distributions. This turns out to be one of the biggest challenges when people use Linux for their embedded devices - often the Linux gets shipped out on the embedded device, but the sources are not made available as specified in the GPL. Through our tracking and validating of source licenses in recipes, the logic in the build system to restrict licenses used, and the source manifests generated in the build, I think we have a world class solution. This really needs to be supported well in Web Hob. So the requirement here is that when a build is completed, you not only get access to the image (and kernel) but maybe also a tar file of the sources and scripts used to build the image, for purposes of GPL license compliance. I want to point out to the designers and implementers that there already exists a mechanism to archive various levels of source, source with logs, source with logs and scripts, ... Please review the archiver.bbclass so we do not re-invent the wheels for the underlying implementation of what Dave is asking for. We just need to inherit that class and set the appropriate flags for what level of archiving. This should also include a License Manifest of some sort that could be suitable for posting on a website, I am not sure if this is something Beth already has plans for in her license work. Sau! ___ 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] rantthe current yocto FAQ is pretty much valueless/rant
On 06/26/2012 12:53 PM, Robert P. J. Day wrote: On Tue, 26 Jun 2012, Tomas Frydrych wrote: Kooen's cheeky point is worth keeping in mind though; the Yocto naming semantics is not very helpful ;-) Specifically most of the questions being asked on the Yocto list are about Poky, not Yocto, followed by questions about meta-yocto, not Yocto-project. Many of the questions being asked on the list are readily answered by googling for 'Poky Manual', but clearly very few people understand the Yocto project semantics enough to do this ... and if you want major industry players to take yocto seriously, the last thing you want to do is answer their heartfelt pleas for assistance with, i'm sorry, that's technically not a yocto question, you should try another mailing list. even if you're technically correct, that sort of conversation is not going to end well. The number one question I get asked about the Yocto Project (this is from an audience of people in the software radio area) is how the Yocto project relates to OpenEmbedded (and sometimes Angstrom). Having a realy good answer to this on the FAQ would be awesome. Philip PS: Yes, I know this thread is a few days old. I'm on vacation, sue me :) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rantthe current yocto FAQ is pretty much valueless/rant
Op 27 jun. 2012 om 22:14 heeft Tomas Frydrych tf+lists.yo...@r-finger.com het volgende geschreven: Hi Koen, On 27/06/12 15:59, Koen Kooi wrote: Yocto is NOT a distro. Is that so? :-), meta-yocto distro.conf: DISTRO = poky DISTRO_NAME = Yocto (Built by Poky 7.0) DISTRO_VERSION = 1.2 I am well aware that textual meaning is pretty much constructed by the reader, and that authorial intent is an elusive concept, but I am ready to argue that the conventional understanding of the above is that Poky is a build tool, and Yocto is the public name of the distro that you build if you use meta-yocto. To read that as 'Yocto is NOT a distro' I think requires a definite pre-understanding that Yocto is not a distro, which would need to come from some other source (or perhaps it is an axiom of faith; myself, I tend hold firmly to the authority of the source code alone). I shall not deny you the right to hold to such a reading, but I do reserve the right to deconstruct it. :-) It's actually the catchphrase on the official slides: It's not a distro, it builds you one thread highlights the reason the oe folks have been pushing to get rid of the 'poky' name completely Perhaps one of the reasons; but then the erasure of Poky would mean that you could no longer say 'Yocto is a NOT a distro', which I suspect would achieve the very opposite of what you seek (and, perhaps more importantly, might cost Dave and Saul a lunch or two). Personally, I think much better solution would be if the distro was simply called Poky v7.0, then we could all say 'Yocto is NOT a distro!' with conviction. Plus Poky is such a lovely name, don't you think? ;-) I have no problem with poky-the-distro, I have a problem with poky-the-buildsystem. I warned mallum about this confusion years ago, but you know how stubborn he can be :) Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
