Re: [yocto] Using stable releases from git
On 01/30/2012 11:38 PM, Joshua Lock wrote: On 30/01/12 15:32, jfabernathy wrote: On 01/30/2012 06:15 PM, Joshua Lock wrote: On 30/01/12 15:05, jfabernathy wrote: On 01/30/2012 05:58 PM, Joshua Lock wrote: It's beginning to sound like we've caught some folks off guard by pushing changes to the edison branch of the poky repository in preparation for an upcoming edison point release. The named branches are development branches for the release, stable release development will be done in the named branch and we can't guarantee they will be issue free (though we intend them to be where possible). If you're looking to use a git checkout which matches the release tarballs you should checkout the tags for the releases. i.e. for Poky Edison-6.0/Yocto 1.1: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?id=edison-6.0 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tag/?id=edison-6.0 So instead of doing: git checkout -b edison origin/edison what should I do if I want to stay in sync with the tarball. This may just be a doc problem. I'd do: git fetch --tags git checkout edison-6.0 Then when a new tarball comes out, you'd repeat with the new tag name. We I just tried that and it crashed a lot quicker. I'll just stick to the tarballs until this is all sorted out. Are you using an appropriate tag (or branch) of meta-intel? The master branch of meta-intel with the bernard tag of poky will fail to parse because some of the recipes being appended to in meta-intel have changed names. Can you explain the branch vs. tag as Yocto uses it? most of the help on git checkout refers to branch, where we are talking using a tag name. In Yocto what is the difference? Cheers, Joshua ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using stable releases from git
On 31/01/12 07:28, jfabernathy wrote: On 01/30/2012 11:38 PM, Joshua Lock wrote: On 30/01/12 15:32, jfabernathy wrote: On 01/30/2012 06:15 PM, Joshua Lock wrote: On 30/01/12 15:05, jfabernathy wrote: On 01/30/2012 05:58 PM, Joshua Lock wrote: It's beginning to sound like we've caught some folks off guard by pushing changes to the edison branch of the poky repository in preparation for an upcoming edison point release. The named branches are development branches for the release, stable release development will be done in the named branch and we can't guarantee they will be issue free (though we intend them to be where possible). If you're looking to use a git checkout which matches the release tarballs you should checkout the tags for the releases. i.e. for Poky Edison-6.0/Yocto 1.1: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?id=edison-6.0 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tag/?id=edison-6.0 So instead of doing: git checkout -b edison origin/edison what should I do if I want to stay in sync with the tarball. This may just be a doc problem. I'd do: git fetch --tags git checkout edison-6.0 Then when a new tarball comes out, you'd repeat with the new tag name. We I just tried that and it crashed a lot quicker. I'll just stick to the tarballs until this is all sorted out. Are you using an appropriate tag (or branch) of meta-intel? The master branch of meta-intel with the bernard tag of poky will fail to parse because some of the recipes being appended to in meta-intel have changed names. Can you explain the branch vs. tag as Yocto uses it? most of the help on git checkout refers to branch, where we are talking using a tag name. In Yocto what is the difference? A tag is a snapshot, a release or milestone usually, and is static. Releases (and their tarballs) are generated from a tag. A branch represents some ongoing development of some sort, we branch master when we're close to release and only put bug fixes in the branch. When it comes to release time we tag the release. We use those same branches for any stable maintenance work, once that's ready for release we'll create another tag. In short: * branches are for development and the contents change * tags are snapshots Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How do I patch the kernel before it is built?
I could not find a way to patch the kernel source before its is built. I promise to update the Yocto wiki's How do I section when I have a working solution for the following :-) Here is what I am trying to do: 1) Patch the kernel (add VID/PID to hid_ignore_list in drivers/hid/hid-core.c and also to add the VID/PID to .h file) 2) Build the kernel - no change here - standard kernel build 3) Build a kernel module I have a meta layer where I am keeping my changes. I am guessing that I need to: a) write a bbappend file to accomplish #1 b) write a recipe to accomplish #3 I have written recipes before, but just for libraries and autotools based applications. Not for a kernel module. If there is a recipe out there for some other module, I would be happy to steal from it. Please advise how I can go about patching the kernel and if there is a recipe for a kernel module - please point me to it. Thank you Autif ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch the kernel before it is built?
On 12-01-31 11:45 AM, autif khan wrote: I could not find a way to patch the kernel source before its is built. I promise to update the Yocto wiki's How do I section when I have a working solution for the following :-) This should be covered in the existing documentation and also the more general bitbake/oe-core docs. Here is what I am trying to do: 1) Patch the kernel (add VID/PID to hid_ignore_list in drivers/hid/hid-core.c and also to add the VID/PID to .h file) 2) Build the kernel - no change here - standard kernel build 3) Build a kernel module I have a meta layer where I am keeping my changes. I am guessing that I need to: a) write a bbappend file to accomplish #1 b) write a recipe to accomplish #3 I have written recipes before, but just for libraries and autotools based applications. Not for a kernel module. If there is a recipe out there for some other module, I would be happy to steal from it. Please advise how I can go about patching the kernel and if there is a It's just like any other package. If your changes are simple, then generating patches and putting them on the SRC_URI via a bbappend in your layer is all you need. If you have complex changes, there are options to manage them via git or via feature descriptions. recipe for a kernel module - please point me to it. Darren validated and updated the kernel module example, so he'd probably got this closer at hand than I do. Cheers, Bruce Thank you Autif ___ 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] How do I patch the kernel before it is built?
On 31/01/12 08:45, autif khan wrote: I could not find a way to patch the kernel source before its is built. I promise to update the Yocto wiki's How do I section when I have a working solution for the following :-) Here is what I am trying to do: 1) Patch the kernel (add VID/PID to hid_ignore_list in drivers/hid/hid-core.c and also to add the VID/PID to .h file) We have some documentation which covers this: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-kernel-appendix I'm not sure if it answers all of your questions, but hopefully it gets you closer. Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I patch the kernel before it is built?
On 01/31/2012 08:51 AM, Bruce Ashfield wrote: > On 12-01-31 11:45 AM, autif khan wrote: >> I could not find a way to patch the kernel source before its is built. >> >> I promise to update the Yocto wiki's How do I section when I have a >> working solution for the following :-) > > This should be covered in the existing documentation and also the > more general bitbake/oe-core docs. > >> >> Here is what I am trying to do: >> >> 1) Patch the kernel (add VID/PID to hid_ignore_list in >> drivers/hid/hid-core.c and also to add the VID/PID to .h file) >> 2) Build the kernel - no change here - standard kernel build >> 3) Build a kernel module >> >> I have a meta layer where I am keeping my changes. I am guessing that I need >> to: >> >> a) write a bbappend file to accomplish #1 >> b) write a recipe to accomplish #3 >> >> I have written recipes before, but just for libraries and autotools >> based applications. Not for a kernel module. If there is a recipe out >> there for some other module, I would be happy to steal from it. >> >> Please advise how I can go about patching the kernel and if there is a > > It's just like any other package. If your changes are simple, then > generating patches and putting them on the SRC_URI via a bbappend in > your layer is all you need. If you have complex changes, there are options > to manage them via git or via feature descriptions. > >> recipe for a kernel module - please point me to it. > > Darren validated and updated the kernel module example, so he'd probably > got this closer at hand than I do. See the hello-mod example under meta/recipes-kernel/hello-mod -- 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] New recipes not installing in core-image-minimal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/27/2012 12:06 AM, Darren Hart wrote:
>
>
> On 01/27/2012 12:02 AM, Martin Jansa wrote:
>> On Thu, Jan 26, 2012 at 05:29:19PM -0800, Darren Hart wrote:
>>> In support of a new BSP I've written two new recipes and
>>> appended to another to depend on them. The new recipes files
>>> are not appearing in the resulting images. I'm sure I'm
>>> overlooking something trivial, but I'm not sure what it would
>>> be. The layer is available here:
>>>
>>> http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=dvhart/sys940x
>>>
>>>
>>>
>
>>>
I've added ranpwd, genmac, and appended to netbase.
>>>
>>> netbase RDEPENDS on genmac and genmac RDEPENDS on ranpwd.
>>> Building core-image-minimal triggers the build of genmac and
>>> ranpwd, and the modified /etc/network/interfaces appears in
>>> the rootfs. genmac and ranpwd place the appropriate files in
>>> their workdir/image directory, but those files don't make it
>>> into the rootfs.
>>>
>>> Can anyone offer an explanation as to why that might be? The
>>> top 4 commits of the repository linked to above will list the
>>> new recipes and the bbappend for reference.
>
>> Have you tried correct version of RDEPENDS? RDEPENDS_${PN} ?
>
> I have, yes, this is what Saul suggested in his response. Same end
> result.
>
Apparently I had failed to cleanall my genmac recipe. So while netbase
depended on genmac, genmac was not depending on ranpwd. I can't explain
why this resulted in neither genmac nor ranpwd appearing in the rootfs
at the time. My current build installed both.
- --
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPKDETAAoJEKbMaAwKp364ca8IAL5eHwcDENdZlknPUVpUIuDj
BVSRbtqKTAzVQgQb8ewWY1Yyt4EEPqlvBl1isKbmNKGz5uyYj+xoHAaQl4Xak2Hp
Q8fkTDuUrpMPlJGJYKt9hV9aXHYf/f2lXU0OXRsq389QVHP9JW/Jvjvs7ynx+KcA
4P6pJav+PXfuKBGAu6by+SFnIZYM3DUyVKZANUcVQChC5siLWHNbwMhfPNurnIbe
3+vrr1acXa9/q4e++apkIENLHY8Omasu/JuKa92aM+7dcUp4gNetj/6oPmkBr1OC
407weio81nC8G5nCSXJcbG58Yf12jXDt6605jjOU9R6fBfFrQMquY3QpeNaeZNk=
=Mlbi
-END PGP SIGNATURE-
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Yocto BSP and kernel usability tools
Hi Tom, This is really late in coming, my apologies. This looks to be the beginnings of a very powerful set of tools, and the detail you started with should help ensure a successful initial version. Nice work. Some general questions that don't belong in any one particular place inline: o You mention the use of json files. Is there a web UI planned for this? Or did you just decide that the requirements for the UI were the same as a web UI so you opted to use an established format rather than create a new one? o As a follow-on to the previous, it is always nice if the input files to tools such as this can be easily human readable (and IMO this excludes things like XML and serialized python objects). A simple INI type config seems like it might be more accessible and python has a module for this. I imagine you've considered this, I'm curious as to your rationale for the method outlined below. o I have some concern about yet another description format of BSPs and essentially kernel configuration. We already ask users to think in terms of SCC and CFG fragments, rather than defconfigs. This effectively asks users to start thinking in terms of json name value pairs to map to bitbake syntax to describe scc and cfg fragments so we can assemble a .config. Having the tools and structure in place eliminates a lot of the guesswork, so in the end I think it is probably worth it ... I just worry about so many levels of abstraction - and I do not have a better alternative in mind. o I see the tools for KMACHINE but nothing for KBRANCH. The distinction here is subtle and not described in any of our documentations (BSP guide, Kernel Arch and Usage, or Yocto Developer guide). Ideally we use standard/default/base for new BSPs and only add the meta-data to the linux-yocto kernel. Is this workflow supported? I ask because I'm failing to accomplish this with the sys940x and seem to have to add the sys940x branch in order for kernel_configme to pick up the sys940x meta data. -- Darren On 12/19/2011 08:55 AM, Tom Zanussi wrote: > Hi, > > This is what I hope to implement in the M2 timeframe. > > Any and all comments welcome... > > Thanks, > > Tom > > --- > > Getting Yocto running on a new board is often a prerequisite task to > the real task of interest for new users, which is creating new > applications designed to run on the board, or creating new > board-specific embedded systems. In other words, most users just want > to get the hardware up and running and not have to think too much > about it before moving on to what they're really interested in, which > is the stuff running on top of it. > > While there really can't be any such thing as a magic-bullet > application that would do that automatically i.e. generate and > maintain a guaranteed-working Yocto BSP for any given piece of > hardware, it should at least be possible to provide a tool that would > generate a base BSP usable as a starting point for that, and which > would additionally allow the user to tweak various BSP settings, > including kernel configuration options and simple kernel patches. > Such a tool should be usable with only a minimal understanding of the > Yocto build system and metadata, and with no knowledge at all of > kernel internals or the Yocto kernel recipe bindings, or of the > details of the internals of yocto kernel repositories, or in fact any > knowledge of git or any other specific build-related tool. > > This document provides the design for such a tool. At a high level, > the goal of the tool is to provide a user the means of creating a new > Yocto BSP from which it should be possible (assuming a perfect > run-time outcome, admittedly unlikely on a first pass) to submit a > 'pull request' for inclusion into any repo(s) that would accept an > 'official' Yocto BSP. For example, the output of the tool should > produce metadata and kernel configuration that would be directly > mergeable into the meta-intel and the linux-yocto kernel repos. The > tool should also allow the BSP maintainer to afterwards at any time > make changes to the kernel configuration and/or submit kernel patches > for the BSP. > > Note that although knowledge of the Yocto kernel or kernel internals > is not expected, the user is expected to know the basics of how to > deal with the linux kernel at the 'user' level, specifically > understanding and determining the specific kernel config options > needed for the user's BSP. > > Specifically, the tool will allow for the following high-level tasks, > which are discussed in more detail below: > > - create a new BSP from scratch from a set of user-settable parameters > - manage individual kernel config settings > - create and use groups of kernel config settings as KERNEL_FEATUREs > - apply patches to a BSP's machine branch > > The following capabilities are specifically not provided by the tool: > > - help in determining a 'correct' set of kernel config options to set. > The tool assumes the user already k
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, January 31, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Attendees: Beth, Saul, Matthew, Tom, Paul, Belen, Sean, Bruce, Richard, Michael, Jessica, Jeff, Scott, Denys, Darren, Josh, Song Agenda: * Opens collection - 5 min (Song) * Yocto 1.1.1 point release update - 10 min (Josh/Beth) - All changes have been pushed. Doc is done. - Richard has merged all changes to Edison. The intension is to have build for QA by the end of this week. * Yocto 1.2 M3 status - 10 min (Song/Team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status - We have more features in progress, features in development are getting more progress also. - Still a lot of features have not been started, lots of features are still in testing. Both of these should get better since the PRC team is back. - Getting a little better on bug fixing, fixed a little more than what we opened last week. 2 high bugs, will see what Mark says about it. - Saul will follow up with Mark on the high bug 1928 - 1898, patch is pending in Bruce kernel update. - Encourage the team to look at your packages, look at warning, specially package warning to reduce the number of warning messages. * SWAT chair person rotation: Paul -> Jessica - MUD testing is going on. Beth is adding trigger for auto BSP build - Saul: There are some real issues, especially in BSP realm. Darren and Saul are looking at it 1940. - RP: has been looking at the issues. 2 predominant one, Bruce's patch, fetcher issue, RP has patches on the mailing list. Package config one, also the BSP one. * Opens - 10 min - Beth: minor release process change, we used to release only tarballs for point releases, changing that to be as same as a major release. We do release tarball and BSP images. Will have the 1.1.1 directory in download area. - Matthew: There is some failure in 1.1.1. Josh is following up these issue, - Michael: Encourage people to help on Bugzilla upgrade. Sent out emails yesterday to the mailing list, we have a new bugzilla up and running now. If people could use it please test it out and report problems. - ScottR - 1.1.1 website status. 1.1.1 release is not ready, will have the related changes on the website when it is ready. - ScottR: would like to encourage people to get back to Scott in 24 hours for his emails clarifying some doc topics. Scott would like to encourage community people to run through the docs and give some feedback. Sean: suggest online review for docs. Scott: we can widen the scope of the review. RP: All docs are in public repos and can be pulled out for review. If people have contribution, please send patches. * Team Sharing - 20 min - Josh: last week finished doing 1.1.1, this week 1.1.1 will continue 1.1.1 - Darren: nothing to sharing this week. - Denys: established a mirror of meta-ti on yoctoproject server, setting a distro to work with OE core and Yocto Project. Beth will talk with Denys about getting meta-ti in autobuilder. The mirror is automated, every time meta-ti is updated, it will be pushed to Yocto server automatically. - Scott: last week wrapped up 1.1.1, moved on to bugs, worked on 4 or so bugs, continue this week on bugs. Creating some new bugs based on some feedback from Jim. - Jeff: working on WRS stuff - Jessica: plan for M3, prepare for ELC developer's day. - Michael: Bugzilla last week. Setting up KVM infrastructure, getting access for SWAT team, helping on meta-ti repos. this week, visiting hosting site to upgrade autobuilder infrastructure. - Richard: last merged some changes, sent out emails about the technical aspects. Working on reducing bug count, dealing with autobuilder. - Bruce : M3 development, development for 3.2 kernel. Need to finish M3. - Sean: nothing this week. - Belen: last week preparing something on HOB2, designing the leftover part for HOB2. As they (PRC team) need things, they can let Belen know. - Paul: last week working on SWAT team duty, not many failures. Preparation for ELC talk. Bitbake layers talk. Found a few areas we can improve and send some patches. This week will be preparation, and some bugs. - Tom: last week working on kernel tools, remaining kernel features, publishing to local repo. Working with Bruce. Internal BSPs, will continue all that and prepare for ELC. - Saul: tracking changes on the list consolidated pull request. Fixed some problems. Working on preps for ELC YDD. This week, package update, getting preps together for ELC. - Beth: did a little of bit licensing, continued on autobuilder layer tooling, build history should be incorporated into autobuilder. Working on ELC presentations. Need autobuilder infrastructure upgrade (Michael will be working on it) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Yocto BSP and kernel usability tools
On Tue, 2012-01-31 at 14:52 -0800, Darren Hart wrote: > Hi Tom, > > This is really late in coming, my apologies. This looks to be the > beginnings of a very powerful set of tools, and the detail you started > with should help ensure a successful initial version. Nice work. > > Some general questions that don't belong in any one particular place inline: > > o You mention the use of json files. Is there a web UI planned for this? > Or did you just decide that the requirements for the UI were the same as > a web UI so you opted to use an established format rather than create a > new one? > > o As a follow-on to the previous, it is always nice if the input files > to tools such as this can be easily human readable (and IMO this > excludes things like XML and serialized python objects). A simple INI > type config seems like it might be more accessible and python has a > module for this. I imagine you've considered this, I'm curious as to > your rationale for the method outlined below. > As a design point, I've tried to completely decouple the user interface from the back-end, so that yes, in the future a web UI could easily replace the current command-line user interface. I decided to use json because it's pretty standard for web applications, and Python also has json parsers available. And it's human-readable, unlike XML or serialized Python. But it really doesn't need to be any of those, if something else makes sense. > o I have some concern about yet another description format of BSPs and > essentially kernel configuration. We already ask users to think in terms > of SCC and CFG fragments, rather than defconfigs. This effectively asks > users to start thinking in terms of json name value pairs to map to > bitbake syntax to describe scc and cfg fragments so we can assemble a > .config. Having the tools and structure in place eliminates a lot of the > guesswork, so in the end I think it is probably worth it ... I just > worry about so many levels of abstraction - and I do not have a better > alternative in mind. > No, users never see json or any description format (UI tool or webapp developers do though). The json format (or whatever it ends up being) is only used as a way of feeding user input values into the back-end in the absence of a user interface (e.g. sent from a browser, or specified as a group on the command-line). Regardless of where the input comes from, in any case it's finally translated it into the .scc and .cfg fragments we all know and love. Actually, the point of all this is that the end user doesn't even need to know about .scc files or .cfg fragments, and deals only at a high-level with 'features' or config items or patches; this whole scheme allows UI developers to creat UIs that do that. > o I see the tools for KMACHINE but nothing for KBRANCH. The distinction > here is subtle and not described in any of our documentations (BSP > guide, Kernel Arch and Usage, or Yocto Developer guide). Ideally we use > standard/default/base for new BSPs and only add the meta-data to the > linux-yocto kernel. Is this workflow supported? I ask because I'm > failing to accomplish this with the sys940x and seem to have to add the > sys940x branch in order for kernel_configme to pick up the sys940x meta > data. > In the current implementation of the cmd-line UI, the user can specify any branch ending with base e.g. standard/base standard/default/base standard/default/common-pc-64/base standard/default/common-pc/base standard/preempt-rt/base 'base' is removed from the branch name and replaced with the machine name e.g. standard/default/foo The 'publish' function will end up creating that branch in the repo and adding the .scc/.cfg files as a bsp/ in the meta branch. Also, new features (.cfg and .scc contained in subdirs in the SRC_URI) will be created under features/ and referenced in the bsp .scc. I've also run into the same thing you describe - the current tools seem to require a 1-1 mapping between KBRANCH/KMACHINE and the machine's metadata, but I don't see a problem with that and it seems more intuitive to the user (and allows a place to commit bsp-specific branches immediately without explicitly having to force a new branch first). Tom > -- > Darren > > On 12/19/2011 08:55 AM, Tom Zanussi wrote: > > Hi, > > > > This is what I hope to implement in the M2 timeframe. > > > > Any and all comments welcome... > > > > Thanks, > > > > Tom > > > > --- > > > > Getting Yocto running on a new board is often a prerequisite task to > > the real task of interest for new users, which is creating new > > applications designed to run on the board, or creating new > > board-specific embedded systems. In other words, most users just want > > to get the hardware up and running and not have to think too much > > about it before moving on to what they're really interested in, which > > is the stuff running on top of it. > > > > While there really can't be any such thing as a magic
[yocto] RFC: Hob 1.2 design
Hi, all, Belen has a new video for Hob2 workflow and design. https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov Please comment. Thanks. -- Shane ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hob 1.2 design
Belen - nice work! This just gets better all the time. I really like the enhancements to the work flow. Quick question - around 6:40 in the video, once you successfully build there is a "Deploy Image" button. Then at 7:44 there is a "Write to Storage" button. Are these both doing the same thing? Thank you for making something so functional and so beautiful. Dave From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Wang, Shane Sent: Wednesday, February 01, 2012 9:39 AM To: yocto@yoctoproject.org Subject: [yocto] RFC: Hob 1.2 design Hi, all, Belen has a new video for Hob2 workflow and design. https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov Please comment. Thanks. -- Shane ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build Error
hi all: i am new comer. i meet a error: NOTE: package pciutils-3.1.9-r0: task do_configure: Started ERROR: Function failed: do_configure (see /home/jwang5/poky-build/tmp/work/i586-poky-linux/pciutils-3.1.9-r0/temp/log.do_configure.9978 for further information) ERROR: Logfile of failure stored in: /home/jwang5/poky-build/tmp/work/i586-poky-linux/pciutils-3.1.9-r0/temp/log.do_configure.9978 Log data follows: | ERROR: Function failed: do_configure (see /home/jwang5/poky-build/tmp/work/i586-poky-linux/pciutils-3.1.9-r0/temp/log.do_configure.9978 for further information) | Configuring libpci for your system/configure: 1: Syntax error: Unterminated quoted string NOTE: package pciutils-3.1.9-r0: task do_configure: Failed ERROR: Task 1041 (/home/jwang5/poky/meta/recipes-bsp/pciutils/ pciutils_3.1.9.bb, do_configure) failed with exit code '1' Waiting for 3 active tasks to finish: 0: linux-yocto-3.0.14+git1+665fea1c249b4f335cb1c9a46a9f2c138d611f1a_1+9e73573b6b227ab2c62e66e63470866d136f8d76-r3 do_compile (pid 7078) 1: openssl-1.0.0f-r15.0 do_compile (pid 3215) 2: db-5.1.19-r4 do_package (pid 7485) Waiting for 2 active tasks to finish: 0: linux-yocto-3.0.14+git1+665fea1c249b4f335cb1c9a46a9f2c138d611f1a_1+9e73573b6b227ab2c62e66e63470866d136f8d76-r3 do_compile (pid 7078) 1: openssl-1.0.0f-r15.0 do_compile (pid 3215) NOTE: package db-5.1.19-r4: task do_package: Succeeded Waiting for 1 active tasks to finish: 0: linux-yocto-3.0.14+git1+665fea1c249b4f335cb1c9a46a9f2c138d611f1a_1+9e73573b6b227ab2c62e66e63470866d136f8d76-r3 do_compile (pid 7078) NOTE: package openssl-1.0.0f-r15.0: task do_compile: Succeeded NOTE: package linux-yocto-3.0.14+git1+665fea1c249b4f335cb1c9a46a9f2c138d611f1a_1+9e73573b6b227ab2c62e66e63470866d136f8d76-r3: task do_compile: Succeeded NOTE: Tasks Summary: Attempted 902 tasks of which 518 didn't need to be rerun and 1 failed. command line: *bitbake core-image-minimal* Who can help me? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build Error
Hi James,
On 31/01/12 22:20, James W. wrote:
hi all:
i am new comer.
i meet a error:
NOTE: package pciutils-3.1.9-r0: task do_configure: Started
ERROR: Function failed: do_configure (see
/home/jwang5/poky-build/tmp/work/i586-poky-linux/pciutils-3.1.9-r0/temp/log.do_configure.9978
for further information)
ERROR: Logfile of failure stored in:
/home/jwang5/poky-build/tmp/work/i586-poky-linux/pciutils-3.1.9-r0/temp/log.do_configure.9978
Log data follows:
| ERROR: Function failed: do_configure (see
/home/jwang5/poky-build/tmp/work/i586-poky-linux/pciutils-3.1.9-r0/temp/log.do_configure.9978
for further information)
| Configuring libpci for your system/configure: 1: Syntax error:
Unterminated quoted string
I cam across this error today also, I'd be willing to bet the OS you're
building on is using the dash shell (Ubuntu)?
I created a patch earlier and submitted it for inclusion. I've attached
it for your convenience, it hopefully it will be merged soon.
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
>From 451986a48fc38f11cca09b7890753c899cfab265 Mon Sep 17 00:00:00 2001
From: Joshua Lock
Date: Tue, 31 Jan 2012 15:21:00 -0800
Subject: [PATCH 1/2] pciutils: fix configure script for dash
configure.patch was missing a closing quote in a sed expression which
causes script execution to error on less forgiving shells such as dash.
Signed-off-by: Joshua Lock
---
.../pciutils/pciutils-3.1.9/configure.patch|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/pciutils/pciutils-3.1.9/configure.patch b/meta/recipes-bsp/pciutils/pciutils-3.1.9/configure.patch
index 658e597..66c9f91 100644
--- a/meta/recipes-bsp/pciutils/pciutils-3.1.9/configure.patch
+++ b/meta/recipes-bsp/pciutils/pciutils-3.1.9/configure.patch
@@ -67,7 +67,7 @@ diff -r af2b10cc3c14 lib/configure
cpu=`/usr/sbin/lsattr -F value -l $proc -a type | sed 's/_.*//'`
else
- cpu=`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/;s/^i86pc$/i386/;s/^BePC$/i386/;s/^BeMac$/powerpc/;s/^BeBox$/powerpc/'`
-+ cpu=${4:-`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/;s/^i86pc$/i386/;s/^BePC$/i386/;s/^BeMac$/powerpc/;s/^BeBox$/powerpc/`}
++ cpu=${4:-`uname -m | sed 's/^i.86$/i386/;s/^sun4u$/sparc64/;s/^i86pc$/i386/;s/^BePC$/i386/;s/^BeMac$/powerpc/;s/^BeBox$/powerpc/'`}
fi
if [ "$sys" = "GNU/kFreeBSD" -o "$sys" = "DragonFly" ]
then
--
1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] forcing a task to run while building an image
Hello,
On Tue, 2012-01-31 at 12:40 +0530, Joshua Immanuel wrote:
> At present in my custom image recipe I've added the following
> lines
>
> SOME_VARIABLE = "Blah"
> do_bootimg[depends] += "base-files:do_install"
>
> But the contents of ${SOME_VARIABLE} is not available in the
> 'base-files' recipe. Even
>
> export SOME_VARIABLE = "Blah"
>
> doesn't solve the problem.
$ bitbake custom-image -c devshell
In the above devshell I can find the contents of ${SOME_VARIABLE}
available but the content of it is empty in 'base-files' recipe. Can
someone guide me?
Regards
Joshua
--
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in
signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
