Closed Bug 909147 Opened 8 years ago Closed 8 years ago

Build error during "make check": [] Error 1 ("assert current_type is not None")


(Thunderbird :: Build Config, defect)

Not set


(Not tracked)

Thunderbird 26.0


(Reporter: mcsmurf, Assigned: jcranmer)



(Keywords: intermittent-failure)


(2 files)

Starting with this checkin (certainly not related to the build problem) the Thunderbird build boxen fail while running "make check"/ looks like:
make -C ssltunnel check
make[3]: Nothing to be done for `check'.
make -C testing/xpcshell check
Traceback (most recent call last):
  File "/builds/slave/tb-c-cen-osx64-d-0000000000000/build/mozilla/testing/xpcshell/", line 13, in <module>
    build_obj = MozbuildObject.from_environment()
  File "/builds/slave/tb-c-cen-osx64-d-0000000000000/build/mozilla/python/mozbuild/mozbuild/", line 156, in from_environment
    config = loader.read_mozconfig(mozconfig)
  File "/builds/slave/tb-c-cen-osx64-d-0000000000000/build/mozilla/python/mozbuild/mozbuild/", line 198, in read_mozconfig
    parsed = self._parse_loader_output(output)
  File "/builds/slave/tb-c-cen-osx64-d-0000000000000/build/mozilla/python/mozbuild/mozbuild/", line 306, in _parse_loader_output
    assert current_type is not None
make[2]: *** [] Error 1
make[2]: Target `check' not remade because of errors.
make -C example check
make[3]: Nothing to be done for `check'.
make[1]: *** [check] Error 2
make -C js/src check
make -C config check

Linux and OS X are affected, not sure about Windows (hard-to-find error message, but it's also orange). The affected builds are (free-space) clobber builds according to tbpl.
Ah, the twin-objdir pain of comm-central. This makes the test pass for me locally, and Firefox is still passing, so this should fix the bustage.
Assignee: nobody → Pidgeot18
Attachment #797068 - Flags: review?(gps)
This patch might also fix Bug 907434 then.
Comment on attachment 797068 [details] [diff] [review]
Resolve the objdir properly in comm-central

Review of attachment 797068 [details] [diff] [review]:

Test coverage would be nice. But meh.
Attachment #797068 - Flags: review?(gps) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 26.0
Sigh. Don't you hate it when the error you get locally is not the same error you get on tinderbox?
Resolution: FIXED → ---
Okay, the problem is reproduced if you add this to the mozconfig:
mk_add_options CLIENT_PY_ARGS="$(cat $topsrcdir/build/"

In-depth investigation reveals that $topsrcdir is pointing to mozilla-central where the mozconfig expects comm-central. Ain't our build system fun?
Attached patch A fixSplinter Review
Ugly, but I have no other idea.
Attachment #804162 - Flags: review?(mbanner)
Comment on attachment 804162 [details] [diff] [review]
A fix

Hmm, I'd like Joshua's feedback here as he's been looking at this as well.
Attachment #804162 - Flags: review?(mbanner) → review?(Pidgeot18)
Blocks: 907434
Comment on attachment 804162 [details] [diff] [review]
A fix

This isn't a fix, it's wallpaper. The problem is that I don't know what the proper fix is. mozinfo.json has the wrong topsrcdir for setting $topsrcdir in .mozconfig, but it's probably the right topsrcdir for a lot of things too. Ultimately, the people most affected by topsrcdir issues are SeaMonkey's mochitests, apparently, but I honestly don't know what's up there or what "properly" fixing topsrcdir issues in mozbuild places would cause.

The best fix ultimately is ccrework. I guess the main question is if this wallpaper is sufficient to last us until ccrework makes all these problems go away or if we need to actually fix this for real. Considering that this is basically the patch I was going to write anyways to fix his bug (Plan B being plug my ears and ignoring this altogether), if Standard8 is asking me to review this, and this is passing try, then I guess there's no reason to reject it.
Attachment #804162 - Flags: review?(Pidgeot18) → review+
Just for reference: The first patch (Attachment 797068 [details] [diff]) did not resolve the mochitest problems from Bug 907434 (as noted in Bug 907434 Comment 4). Which is a bit surprising, it looks like msys/mozbuild is not able to properly resolve relative dirs (NTFS symbol links) in the comm-central case. Seems to work fine though with mozilla-central, not really sure what's different there regarding resolving path.
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.