Bug 1665 - [HOB] deb/ipk build not proceed by showing some packages being built
Summary: [HOB] deb/ipk build not proceed by showing some packages being built
Status: RESOLVED FIXED
Alias: None
Product: Hob
Classification: Build System, Metadata & Runtime
Component: hob (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.1 Point Release
Assignee: Joshua Lock - Disabled
QA Contact:
URL:
Whiteboard: Pending merge upstream and backport t...
Depends on:
Blocks:
 
Reported: 2011-10-09 19:49 UTC by Jiajun Xu
Modified: 2011-12-21 17:30 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments
build not proceed with ipk/deb (76.42 KB, image/jpeg)
2011-10-09 19:50 UTC, Jiajun Xu
no flags Details
Workaround patch (629 bytes, patch)
2011-10-11 17:47 UTC, Joshua Lock - Disabled
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jiajun Xu 2011-10-09 19:49:08 UTC
tree/branch: poky/edison
commit: 5ed59ae0f25bf673d514df2371da7e0415b62bb2

With 1.1 M4 RC4 build, if I choose deb or ipk format in hob and trigger a build, build won't proceed any more by showing some packages being built, like qemu-native, e2fsprogs-native, etc.

You could refer to attached snapshot, it's a build against qemux86 with non-GPLv3 & ipk build. I trigger the build and wait for more than 8 hours but the build could not proceed any more.
Comment 1 Jiajun Xu 2011-10-09 19:50:41 UTC
Created attachment 272 [details]
build not proceed with ipk/deb
Comment 2 Jessica 2011-10-09 20:47:26 UTC
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?
Comment 3 Jiajun Xu 2011-10-09 20:53:33 UTC
(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.
Comment 4 Jessica 2011-10-09 21:00:41 UTC
And the same test passed RC3?
Comment 5 Jiajun Xu 2011-10-09 21:07:54 UTC
(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.
Comment 6 Joshua Lock - Disabled 2011-10-10 16:33:30 UTC
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?
Comment 7 Jessica 2011-10-10 16:40:22 UTC
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?
Comment 8 Jiajun Xu 2011-10-11 08:43:43 UTC
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.
Comment 9 Jessica 2011-10-11 10:24:52 UTC
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)
Comment 10 Joshua Lock - Disabled 2011-10-11 12:01:39 UTC
(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.
Comment 11 Jessica 2011-10-11 16:59:10 UTC
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
Comment 12 Joshua Lock - Disabled 2011-10-11 17:34:00 UTC
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.
Comment 13 Joshua Lock - Disabled 2011-10-11 17:47:33 UTC
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.
Comment 14 Joshua Lock - Disabled 2011-12-13 14:08:53 UTC
I'm going to submit the proposed patch to master for 1.1.1