Closed Bug 609401 Opened 14 years ago Closed 13 years ago

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

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: RyanVM, Assigned: justin.lebar+bug)

References

Details

(Keywords: regression)

Attachments

(2 files)

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.
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
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.
Attached patch Patch v1Splinter Review
This fixes the spam, although I don't know if breaks something else...
Attachment #533303 - Flags: review?(khuey)
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)
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.
Attached patch Patch v2Splinter Review
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+
Ah, thanks for catching that!  I totally glossed over that line.
http://hg.mozilla.org/mozilla-central/rev/99436764a926
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.