| Summary: | error when selecting kernel version 3.4 in yocto bsp tool | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Alexandru Georgescu <alexandru.c.georgescu> | ||||
| Component: | bsps-tools | Assignee: | Tom Zanussi <tom.zanussi> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | dvhart, ioanax.grigoropol, jessica.zhang, tom.zanussi | ||||
| Version: | 1.3 | ||||||
| Target Milestone: | 1.3 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | --- | |||||
| Attachments: |
|
||||||
|
Description
Alexandru Georgescu
2012-10-04 13:54:20 UTC
Looks like it might be a network problem on that end. Creating an i386 BSP using the 3.4-rt kernel works fine here: [trz@empanada build]$ yocto-bsp create myi386 i386 Would you like to use the default (3.4) kernel? (y/n) [default: y] n Please choose the kernel to use in this BSP: [default: linux-yocto_3.4] 1) linux-yocto_3.2 2) linux-yocto-rt_3.4 3) linux-yocto_3.4 4) linux-yocto-rt_3.2 2 Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.4.git... Please choose a machine branch to base this BSP on: [default: standard/preempt-rt/base] 1) standard/preempt-rt/base 2) standard/preempt-rt/fri2 3) standard/preempt-rt/qemuppc 4) standard/preempt-rt/routerstationpro Do you need SMP support? (y/n) [default: y] Which machine tuning would you like to use? [default: tune_core2] 1) i586 tuning optimizations 2) Atom tuning optimizations 3) Core2 tuning optimizations Do you need support for X? (y/n) [default: y] Does your BSP have a touchscreen? (y/n) [default: n] Does your BSP have a keyboard? (y/n) [default: y] New i386 BSP created in meta-myi386 Hi Alex, Is it consistently happening to you or is it just happened once? I tried on my end and seems couldn't reproduce it but I do remember when I showd yocto-bsp when Tom was here, I did run into some traceback with it. What happens if linux-yocto hasn't been fetched prior to running yocto-bsp ? (In reply to comment #3) > What happens if linux-yocto hasn't been fetched prior to running yocto-bsp ? Doh, nevermind, it looks at the SRCURI for those branches and such. Alex, Can you check whether you still can consistently reproduce the failure? (In reply to comment #5) > Alex, > > Can you check whether you still can consistently reproduce the failure? Hi Jessica, I tried with RC4 and couldn't reproduce it anymore. After an online session with AlexG, we were unable to reproduced this on the machine that exhibited the problem. The result was that 'yocto-bsp create myqemux86 qemu' worked fine and was able to fetch the remote branches and display them without error both in the tested version and the current RC. verified. This was seen again on the test system after it was resolved, so reopened. Patch submitted. Hi Tom, Can you provide some detail about the issue, since it's not consistently reproducible on all host distros, probably it shouldn't be a medium+ (In reply to comment #10) > Hi Tom, > > Can you provide some detail about the issue, since it's not consistently > reproducible on all host distros, probably it shouldn't be a medium+ A patch was submitted to fix this bug: https://lists.yoctoproject.org/pipermail/poky/2012-October/008494.html with the following text: yocto_bsp_list_property_values() is missing the context it needs to properly filter choicelists, so add it to the context object. This only affects the users the 'yocto-bsp list property' command, such as ADT who may see cases where the property list filter is incorrect and may return the empty set. The specific details of the system seeing this problem seem to show a filter of 'linux-yocto-rt', but the returned branches did have linux-yocto-rt branches to filter and shouldn't have returned the empty set. The observed behavior that it apparently made a difference which directory the command was invoked from doesn't make sense either, but nonetheless the analysis of the problem area showed there was a problem that could account for the backtrace, and the fix has apparently fixed the problem on the test system, which is the only system the problem was reproducible on. Lowered the priority due to it only shows on one particular machine Fixed by poky/master commit f07be9d2b68ac4e184ce2670bfa65b8d944387aa verified with c3505828f267ca68aaf454355466f54772545a22 in danny. |