"Section [Build] not found" spammed to the terminal




Build Config
7 years ago
6 years ago


(Reporter: RyanVM, Assigned: Justin Lebar (not reading bugmail))




Firefox Tracking Flags

(Not tracked)



(2 attachments)



7 years ago
Something changed in the last day that's causing this to get spammed a lot when building at least on Windows.
This is really obnoxious.
OS: Windows 7 → All
Hardware: x86 → All
Looks like this gets spammed from printconfigsetting.py.  Not sure how we're firing that off in every directory.
j'accuse http://hg.mozilla.org/mozilla-central/rev/39a979e26931

the export forces BUILDID to be evaluated each pass through which causes this.
Assignee: nobody → ted.mielczarek
Blocks: 607946
Keywords: regression
Summary: Section [Build] not found → "Section [Build] not found" spammed to the terminal
Yeah, lame. I can probably just make that a shell variable setting in the rule command.
Justin, if you wanted an easy-ish build system to work on you could take this one.

Comment 6

7 years ago
This is Windows-only?  If so, I won't be able to hack on it until I get a Windows machine in a few weeks...
(In reply to comment #6)
> This is Windows-only?  If so, I won't be able to hack on it until I get a
> Windows machine in a few weeks...

No -- this happens on Linux & Mac, too.  I see it locally all the time, and it also shows up in build logs on tinderbox. (Just search for "Section [" in any recent TryServer build log, for example.)
It only happens on clobber builds, fwiw

Comment 9

6 years ago
Ah, the reason I didn't see it in comment 6 is that I had my patch for bug 620285 applied, which apparently fixes this problem.  I think I have a fix.

Comment 10

6 years ago
Created attachment 533303 [details] [diff] [review]
Patch v1

This fixes the spam, although I don't know if breaks something else...
Attachment #533303 - Flags: review?(khuey)

Comment 11

6 years ago
Comment on attachment 533303 [details] [diff] [review]
Patch v1

... actually, it only fixes the problem if you don't know how to use grep.

I think it's the right approach, though.
Attachment #533303 - Flags: review?(khuey)

Comment 12

6 years ago
So comments 9 through 11 are wrong. But also, I think, is comment 3 -- if I comment out the SYMBOL_INDEX_NAME definition, I still get the warnings.

Comment 13

6 years ago
Created attachment 533392 [details] [diff] [review]
Patch v2

Okay, this seems to work.  Comment 12 was wrong again -- the problem was what Kyle suggested in comment 3, but my patch queue was messing with things.

How can I test that I didn't mess up upload_symbols.sh?  I guess I could push to try, download the build, and make sure that I'm able to retrieve symbols from the symbol server?
Attachment #533392 - Flags: review?(khuey)
Comment on attachment 533392 [details] [diff] [review]
Patch v2

I'm going to give this one to ted since symbol upload scares me.
Attachment #533392 - Flags: review?(khuey) → review?(ted.mielczarek)
Assignee: ted.mielczarek → justin.lebar+bug
Comment on attachment 533392 [details] [diff] [review]
Patch v2

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

::: toolkit/crashreporter/tools/upload_symbols.sh
@@ +61,1 @@
>  : ${SYMBOL_SERVER_HOST?} ${SYMBOL_SERVER_USER?} ${SYMBOL_SERVER_PATH?} ${1?"You must specify a symbol archive to upload"}

Move your variable assignments below this block (which errors if things are unset), and change the ${1 there to ${2, and add a new ${1 to error if the symbol index name isn't given.
Attachment #533392 - Flags: review?(ted.mielczarek) → review+

Comment 16

6 years ago
Ah, thanks for catching that!  I totally glossed over that line.

Comment 17

6 years ago
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.