Closed Bug 811812 Opened 11 years ago Closed 11 years ago

Fix and/or use the string 'warning' rather than 'fatal error' for: "psutil/_psutil_linux.c:11:20: fatal error: Python.h: No such file or directory"


(Firefox Build System :: General, defect)

Not set


(Not tracked)



(Reporter: bjacob, Assigned: gps)




(1 file)

Red Bg on this try push:

TBPL gives this summary:

psutil/_psutil_linux.c:11:20: fatal error: Python.h: No such file or directory
make[6]: *** [TelephonyCall.o] Error 1
make[6]: *** Waiting for unfinished jobs....
make[6]: *** [CallEvent.o] Error 1
make[5]: *** [telephony_libs] Error 2
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [libs_tier_platform] Error 2
make[3]: *** [tier_platform] Error 2
make[2]: *** [default] Error 2
make[1]: *** [realbuild] Error 2
make: *** [build] Error 2

That suggests that the missing Python.h is the "fatal error" that causes the make errors. Next logical step is to look at the brief log, scroll to the python.h error, but there it's not clear what's happening. It turns out that the make error has nothing to do with it.
Component: Build Config → Tinderboxpushlog
Product: Core → Webtools
Version: unspecified → Trunk
OS: Gonk (Firefox OS) → All
Hardware: ARM → All
We match that line due to:

Whilst we could hardcode that particular line to be ignored, I would much rather that failure be fixed (or at least the string changed to not overlap with normally-relevant failure types).
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Component: Tinderboxpushlog → Build Config
OS: Gonk (Firefox OS) → All
Product: Webtools → Core
Hardware: ARM → All
Summary: TBPL gives confusing summaries about builds → Fix and/or use the string 'warning' rather than 'fatal error' for: "psutil/_psutil_linux.c:11:20: fatal error: Python.h: No such file or directory"
(And thank you for filing this, I've noticed it a few times, but slipped my mind :-))
gps, please may you take a look at this, it's causing confusion with people using Try, eg:

15:00:26 - bz: Should I worry about B2G builds failing on try with a missing Python.h ?
15:02:10 - Ms2ger`: bz, they're not actually failing there
15:03:31 - edmorley: bz, that line is a false positive (bug filed on stopping that error), failure is later
15:04:22 - edmorley: bz, error: no matching function for call to 'mozilla::dom::bluetooth::BluetoothService::GetPairedDevicePropertiesInternal(..
Flags: needinfo?(gps)
The real solution is for the Python development headers to be deployed to the buildbot machines. Bug 788908 is one such request.

That being said, we can probably work around this for the time-being. It would be hacky, but I concede it's probably necessary evil to prevent confusion.
Flags: needinfo?(gps)
Depends on: 788908
I think this should do it.
Assignee: nobody → gps
Attachment #685709 - Flags: review?(ted)
Thank you :-D
Attachment #685709 - Flags: review?(ted) → review+

First Try failed. I suspect things are being written to stderr, not stdout. I added stderr=subprocess.STDOUT to the process invocation. I'll carry r+ forward because change is trivial and I don't think Ted would mind :)
Try looked good.
Target Milestone: --- → mozilla20
Closed: 11 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.