428683 - "WINNT 5.1 tpol Dep suiterunner" is red: issue with Parental Control

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P5)

Description

[Serge Gautherie (:sgautherie)]

"WINNT 5.1 tpol Dep suiterunner %"
(disappeared after "2008/04/01 21:27:04")
reappeared on "2008/04/04 03:59:00"
and has been red since then.

{{
Build Error Summary

c:\tinderbox\seamonkey-exp\winnt_5.1_depend\mozilla\toolkit\components\parentalcontrols\src\nsParentalControlsServiceWin.h(53) : fatal error C1083: Cannot open include file: 'wpcapi.h': No such file or directory
}}

Seems related to bug 425979.

Comment 1

[Benjamin Smedberg]

You either need the Vista SDK or --disable-parentalcontrols, see bug 426065 for a better configure check and early-bail.

Comment 2

[Mark Banner (:standard8)]

This isn't a 2.0a1 blocker. Robert is currently in America and I doubt that he can fix it for a while. The SeaMonkey trunk tinderboxes are working fine.

Comment 3

[Mark Banner (:standard8)]

Also not a blocking level bug because we still have SeaMonkey tinderbox trunk "WINNT 5.2 sea-win32-tbox Dep Nightly" that provides nightlies.

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #1)
> You either need the Vista SDK or --disable-parentalcontrols, see bug 426065 for
> a better configure check and early-bail.

New (much clearer) error after that bug checkin:
<http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1208360580.1208361829.14119.gz>
{{
WINNT 5.1 tpol Depend suiterunner on 2008/04/16 08:43:00

Build Error Summary

configure: error: System header atlbase.h is not available. See http://developer.mozilla.org/en/docs/atlbase.h for details on fixing this problem.

Build Error Log

checking for mmintrin.h... (cached) no
checking for oleacc.idl... (cached) no
checking for atlbase.h... (cached) no
checking for wpcapi.h... (cached) no
}}

Comment 5

[Benjamin Smedberg]

Which SDK is that machine running? If the Windows 2003 R2 SDK or the one that comes with VC8 pro, I'm a little surprised at the output: it should be

oleacc.idl: yes
atlbase.h: yes
wpcapi.h: no

Comment 6

[Serge Gautherie (:sgautherie)]

Can you find the/enough answer in the full log ?
<http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1208360580.1208361829.14119.gz&fulltext=1>

Could wrong values be cached ? (and need to be reset somehow)

Anyway, at this point, it seems we can only wait for Robert to come back and have a look at his tinderbox :-|

Comment 7

[ause]

still a cygwin based buildsystem? see Bug 425974

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #7)
> still a cygwin based buildsystem? see Bug 425974

Yes, it looks very much like so:
<http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/1208360580.1208361829.14119.gz&fulltext=1>
{{
HOME=/cygdrive/c/moz
PWD=/cygdrive/c/tinderbox
TERM=cygwin

/cygdrive/c/tinderbox/SeaMonkey-exp/mozconfig: line 3: $'\r': command not found
/cygdrive/c/tinderbox/SeaMonkey-exp/mozconfig: line 7: $'\r': command not found
/cygdrive/c/tinderbox/SeaMonkey-exp/mozconfig: line 10: $'\r': command not found
/cygdrive/c/tinderbox/SeaMonkey-exp/mozconfig: line 22: $'\r': command not found
/cygdrive/c/tinderbox/SeaMonkey-exp/mozconfig: line 26: $'\r': command not found

checking for ml... (cached) /cygdrive/c/Programme/Microsoft Visual Studio 8/VC/bin/ml
}}

Thanks for your bug 425974 comment 14 !
I had noticed this, but as it seemed to be working as is previously...

Comment 9

[Serge Gautherie (:sgautherie)]

For now, tpol has gone away after:
<http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports&maxdate=1208496481&hours=24&legend=0&norules=1>
{{
WINNT 5.1 tpol Depend suiterunner on 2008/04/17 12:01:00

Build Comments

[[e-mail] - 2008/04/17 15:34:34]
On top of already reported red,
this build has
"cvs [checkout aborted]:
reading from server: Software
caused connection abort"

Build Error Summary

cvs [checkout aborted]: reading from server: Software caused connection abort
configure: error: System header atlbase.h is not available. See http://developer.mozilla.org/en/docs/atlbase.h for details on fixing this problem.
}}

Comment 10

[Serge Gautherie (:sgautherie)]

(In reply to comment #9)
> For now, tpol has gone away after:

The box seems to be stuck in the following build:
<http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-SeaMonkey&maxdate=1208497039&hours=24&legend=0&norules=1>
{{
WINNT 5.1 tpol Depend (1.1)
Started 2008/04/17 12:14, still building..
22 hours, 39 minutes elapsed
}}

Comment 11

[Robert Kaiser]

(In reply to comment #9)
> For now, tpol has gone away

Sometimes, cygwin or blat seems to refuse to talk to the outside world and then tpol disappears from tinderbox. I just restarted it, it should come online again.
There was a checkin to configure that might have fixed the problem we were seeing here, let's see if the fixes to bug 426065 and bug 425974 make us actually go green again.

Comment 12

[Serge Gautherie (:sgautherie)]

Welcome back, Robert.
The box is back online.

***

"WINNT 5.1 tpol Depend suiterunner on 2008/04/21 08:20:00":
Trunk build ended up red, as in comment 4.
Does it need a "clobber/reset" to take the fixes ?

***

"WINNT 5.1 tpol Dep (1.1)"
is currently building.

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)
> Does it need a "clobber/reset" to take the fixes ?

See bug 425974 comment 16.

Comment 14

[Robert Kaiser]

Sure, I need it remove the .cache so that configure is re-run (it has been regenerated by the checkin already)

Comment 15

[Serge Gautherie (:sgautherie)]

"WINNT 5.1 tpol Depend suiterunner on 2008/04/21 15:44:00"
is still red :-/

(The 1.1 branch is green ;-))

Comment 16

[Robert Kaiser]

I added --disable-parental-controls, it probably doesn't work without that option (at least that's what bug 425974 makes me believe).

Comment 17

[Serge Gautherie (:sgautherie)]

(In reply to comment #16)

As I understood the 3 patches,

> I added --disable-parental-controls, it probably doesn't work without that

We (will) need this in order not to get comment 0 behavior again.

"WINNT 5.1 tpol Depend suiterunner on 2008/04/21 16:51:00"
This made no difference (for now).

> option (at least that's what bug 425974 makes me believe).

But the current behavior is unexpected:
we should be getting bug 425974 comment 20 behavior,
whereas we still get comment 4 behavior.

As a guess, I looks as if the cygwin environment is not identified as such ?

Comment 18

[Serge Gautherie (:sgautherie)]

Robert,
any more hint ?
Either at finding what is going on, or upgrading to new environment (msys, sdk).

Comment 19

[Robert Kaiser]

I'll look into this deeper next week, but upgrading the machine to throw away cygwin would probably stop us from having 1.1.x nightlies and releases on Windows, which is not the option I have in mind, and I'm not sure if one single tinderbox process can build 1.1.x on cygwin and trunk on MSYS (the current hack I use for doing one with VC6 and the other with VC8 is already fragile enough).
I'm also not sure how the SDK plays into this box being essential for 1.1.x - if I can't fix the trunk cycle on this box, I'll turn it off, make this a WONTFIX and leave the box completely to the branch. The trunk cycle here nowadays is just fun and nothing depends on it, while the branch cycles are what we do current releases with.
That said, this bug is very low priority for me. I have it on my list, but please don't nag me about it any more. Nothing depends on it, as I already stated.

Comment 20

[Serge Gautherie (:sgautherie)]

(In reply to comment #19)
> I'll look into this deeper next week, but upgrading the machine to throw away
> cygwin would probably stop us from having 1.1.x nightlies and releases on
> Windows, which is not the option I have in mind, and I'm not sure if one single

Oh ! Sure, I wouldn't want that.

> tinderbox process can build 1.1.x on cygwin and trunk on MSYS (the current hack
> I use for doing one with VC6 and the other with VC8 is already fragile enough).

(I would think it could, but I don't know.)

> I'm also not sure how the SDK plays into this box being essential for 1.1.x -

FWIW, see bug 428970 new(er) flag:
I'm not sure that it will make any actual difference,
but it shouldn't hurt to use it.

> if I can't fix the trunk cycle on this box, I'll turn it off, make this a

Agreed.

Comment 21

[Robert Kaiser]

Attachment: patch: make the definition for cygwin match others in configure.in

This fix makes my cygwin box go green as well. If we have that case in configure that was added in bug 425974, we should match cygwin host descriptions the same way as in other places in this file.

Comment 22

[(not currently active) Ted Mielczarek]

Comment on attachment 318702 [details] [diff] [review]
patch: make the definition for cygwin match others in configure.in

Seems reasonable to me.

Comment 23

[Robert Kaiser]

Comment on attachment 318702 [details] [diff] [review]
patch: make the definition for cygwin match others in configure.in

Requesting a1.9? - this does only affect cygwin builds, which aren't officially supported for 1.9 any more. Official builds aren't affected at all, as they are MozillaBuild now, but we're able to build in a few more unofficial cygwin configurations.

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 318702 [details] [diff] [review]
patch: make the definition for cygwin match others in configure.in

a=beltzner, assuming "doesn't affect official builds" also means "doesn't affect nightly builds"

Comment 25

[Robert Kaiser]

Nightly builds are all MSYS/MozillaBuild now and are not affected by this.
Checked in.