Bug 1665

Created attachment 272 [details]
build not proceed with ipk/deb

So is it just deb/ipk and qemux86, how about rpm against qemux86. how about arm for deb/ipk?  WIth the same build tree, not through hob, it build with no problem?

(In reply to comment #2)
> So is it just deb/ipk and qemux86, how about rpm against qemux86. how about arm
> for deb/ipk?  WIth the same build tree, not through hob, it build with no
> problem?

I think it is not related to what MACHINE I set. And rpm build could work well. I could make sure that ipk could work well at least with multilib. I will try normal build case without multilib.

And the same test passed RC3?

(In reply to comment #4)
> And the same test passed RC3?

No, we have another bug reported for ipk/deb build in RC2/RC3, bug 1521, which has been marked as fixed in RC4.

I am unable to reproduce this issue. Can you confirm whether, per Jessica's question in comment 2, you are able to perform deb builds outside of Hob?

I've tested with latest Edison branch today through changing from ipk, deb, rpm, all 3 formats were able to build successfully without issue.  So can you change to a different build area?  Also, I've only changed package format and rebuild core-image-minimal 3 times, if it's different from your test, can you let me know other settings that you've changed?

Today I tried 3 builds on 3 hosts, 2 hosts are Ubuntu 10.04 32b, and another one is Opensuse 11.4 64b. All of them could not pass build by stopping @ some recipes. These recipes status is building but they never go forward.

Following is the steps I test it:
1. source to a new folder against edison branch
2. change BB_NUMBER_THREADS and PARALLEL_MAKE to maximum processor number
3. change DL_DIR to the local source folder
4. run hob and wait for the UI pop up after some pre-packages built out
5. after that, click preference and change package format from rpm to ipk
6. then choose core-image-minimal image and click bake
7. then you will see the issue after a while

I am trying a ipk build with bitbake command line and after it finished, then trigger hob build with ipk in the same build folder. Will give the update tomorrow.

I've noticed that the hob build with issues the following are throw out in the terminal:

*** %n in writable segment detected ***
Traceback (most recent call last):
  File "/home/dongxiao/jxu49/poky/bitbake/lib/bb/ui/crumbs/hobeventhandler.py", line 225, in event_handle_idle_func
    self.handle_event(event, running_build, pbar)
  File "/home/dongxiao/jxu49/poky/bitbake/lib/bb/ui/crumbs/hobeventhandler.py", line 151, in handle_event
    running_build.handle_event(event)
  File "/home/dongxiao/jxu49/poky/bitbake/lib/bb/ui/crumbs/runningbuild.py", line 183, in handle_event
    current = self.tasks_to_iter[(package, task)]
KeyError: (None, None)

(In reply to comment #9)
> I've noticed that the hob build with issues the following are throw out in the
> terminal:
> 
> *** %n in writable segment detected ***

This bit we can ignore, for now at least - it's Ubuntu specific and not related to this issue. I see this when building RPM via hob on Ubuntu 11.10

> Traceback (most recent call last):
>   File "/home/dongxiao/jxu49/poky/bitbake/lib/bb/ui/crumbs/hobeventhandler.py",
> line 225, in event_handle_idle_func
>     self.handle_event(event, running_build, pbar)
>   File "/home/dongxiao/jxu49/poky/bitbake/lib/bb/ui/crumbs/hobeventhandler.py",
> line 151, in handle_event
>     running_build.handle_event(event)
>   File "/home/dongxiao/jxu49/poky/bitbake/lib/bb/ui/crumbs/runningbuild.py",
> line 183, in handle_event
>     current = self.tasks_to_iter[(package, task)]
> KeyError: (None, None)

This is the real issue, I don't see this when building with RPM. Trying to understand why we *do* see it with ipk and deb.

it is confirmed that if we set ipk as default package format in conf/local.conf and through hob, we're able to build all 3 package formats without issue.  It's that if we set rpm as default, it'll cause only rpm is buildable through hob.  We still need to root cause why, but we'll document this bug in release notes and the walk around

I've traced this down to being an InvalidTask event being received by the GUI, which it has no logic to handle (and I've never seen emitted before).

I'm currently trying to narrow down the cause of the InvalidTask, however it seems it would be prudent to handle this in the RunningBuild handler.
I've a WIP patch to do so but am not entirely certain on the *best* way to handle it, currently I'm testing if I can just ignore the InvalidTask event.

Created attachment 274 [details]
Workaround patch

This patch simply ignores TaskInvalid events. This is pretty much what happens in knotty, the default CLI GUI, as knotty will just log the TaskInvalid to the console.

I'd still like to know why this event is suddenly being emitted but I believe this patch would at least allow us to use the GUI without workaround.

I'm going to submit the proposed patch to master for 1.1.1

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=25e449a710d2be741e61af552860d2022528c89a