ports/141131: www/libxul does not compile any more

[Beat Gaetzi]

Scott Bennett wrote:
>      On Tue, 22 Dec 2009 11:46:06 +0000 Anton Shterenlikht
> <mexas at bristol.ac.uk> wrote:
>> On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote:
>>> On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote:
>>>> On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote:
>>>>> According to PR 141131 I see exactly the same error messages when I try
>>>>> to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16:
>>>>>
>>>>> -----------------------------------
>>>>> [..snip..]
>>>>> cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi
>>>>> -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX
>>>>> -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\"
>>>>> -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG
>>>>> -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC
>>>>> -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include
>>>>> -I/usr/local/include/nspr
>>>>> -I/usr/ports/www/libxul/work/mozilla/dist/include
>>>>> -I../../../../dist/public/nss -I../../../../dist/private/nss
>>>>> -I../../../../dist/include  -Impi -Iecl  dsa.c
>>>>> dsa.c: In function 'FIPS186Change_ReduceModQForDSA':
>>>>> dsa.c:75: error: 'mp_int' undeclared (first use in this function)
>>>>> dsa.c:75: error: (Each undeclared identifier is reported only once
>>>>> dsa.c:75: error: for each function it appears in.)
>>>>> dsa.c:75: error: expected ';' before 'W'
>>>>> dsa.c:76: error: 'mp_err' undeclared (first use in this function)
>>>>> dsa.c:76: error: expected ';' before 'err'
>>>>> [..snip..]
>>>>> gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] Fehler 1
>>>>> gmake[6]: Leaving directory
>>>>> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl'
>>>>> gmake[5]: *** [libs] Fehler 2
>>>>> gmake[5]: Leaving directory
>>>>> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl'
>>>>> gmake[4]: *** [libs] Fehler 2
>>>>> gmake[4]: Leaving directory
>>>>> `/usr/ports/www/libxul/work/mozilla/security/nss/lib'
>>>>> gmake[3]: *** [libs] Fehler 2
>>>>> gmake[3]: Leaving directory
>>>>> `/usr/ports/www/libxul/work/mozilla/security/manager'
>>>>> gmake[2]: *** [libs_tier_toolkit] Fehler 2
>>>>> gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla'
>>>>> gmake[1]: *** [tier_toolkit] Fehler 2
>>>>> gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla'
>>>>> gmake: *** [default] Fehler 2
>>>>> *** Error code 1
>>>>> -----------------------------------
>>>>>
>>>>> This happens on three different machines all running latest 9.0-CURRENT
>>>>> (i386). As far as I can see there are no relevant flags set in
>>>>> etc/make.conf.
>>>>>
>>>>> Any clues what is going wrong? I found no solution to this PR.
>>>>>
>>>>> Please let me know if I can provide more information or test something.
>>>> I've got libxul-1.9.0.16 built fine on ia64 and sparc64.
>>>> No issues, just 'portmaster -force-config -Bd libxul'.
>>>>
>>> Thanks for answering.
>>>
>>> As I wrote before, I have this on different machines, all running newest 
>>> i386-CURRENT. On another machine with amd64-CURRENT I had been able to 
>>> compile libxul-1.9.0.16. Perhaps there is something wrong with my 
>>> configuration? (I copied most from system to system ...)
>> # uname -srm
>> FreeBSD 9.0-CURRENT i386
>> # pkg_info -xo libxul
>> Information for libxul-1.9.0.16:
>>
>> Origin:
>> www/libxul
>>
>> # cd /usr/ports/www/libxul
>> # make showconfig
>> ===> The following configuration options are available for libxul-1.9.0.16:
>>     JAVA=off "Enable JAVA xpcom"
>>     DEBUG=off "Build a debugging image"
>>     LOGGING=off "Enable additional log messages"
>>     OPTIMIZED_CFLAGS=off "Enable some additional optimizations"
>> ===> Use 'make config' to modify these settings
>> # 
>>
>> Have you checked /etc/make.conf, /etc/src.conf?
>>
>      I doubt that either of those has anything to do with the problem.  An
> update for libxul came through in the last two to four days that broke it.
> It halted my "portmaster -a" run, so I've added -x libxul to the command for
> now until another update for it comes through.  For now, though, it's broken
> on 7.2-STABLE as well as on Rainer's system.
>      FWIW, there have been other bad updates recently, too, although many
> have been fixed by subsequent updates within a few days.  A bad pair of
> updates came through a couple of days ago:  print/gutenprint and
> print/gimp-gutenprint.  These have yet to be fixed.
>      multimedia/gstreamer-plugins-dvd was broken by an update a while back,
> three or four months, I think.  It remains unfixed today.
>      Note that these problems are not execution or functional problems in
> the code, but rather problems that prevent the port from completing the
> updating process all the way through installation.  This sort of problem is
> not a daily thing by any means, so it seems like most of the maintainers know
> what they're about, for which we can all be grateful.  But it does seem to
> happen a few times per month, which suggests that at least a few maintainers
> don't or perhaps may lose track of a testing step or two when under pressure.
> (And there certainly is a *lot* of ports to maintain!)
>      
>> Sorry, have no other ideas.
>>
>      Well, an elementary one occurs to me.  If the person committing an
> update or, if applicable, the non-committer maintainer giving the update to
> a committer, were actually to try *configuring, compiling, and installing*
> the port involved before committing the update (or passing it to a committer),
> that person could then see that it didn't actually work and could therefore
> delay any "commit" operation until a version had been tested with one or
> more standard port-maintenance utility (e.g., portmaster, portupgrade,
> portmanager) and found to work properly.  That way no unbuildable or
> uninstallable updates would ever come through on a "portsnap fetch update"
> ...NAAHHHH...that's just ridiculous.
> Silly me.
> :-)

That's not fair. We were working since August on the xulrunner -> libxul
switch. During this time we have done about ten full tinderbox runs and
also a full exp-run on pointyhat. Before I commited this change I have
done runtime testing for most of the applications which were involved in
this change. I've also updated all my systems (even productive ones)
using portmaster before this change hits the tree.

All gecko changes were tested on FreeBSD 6,7,8 and CURRENT on i386,
amd64, sparc64 and powerpc and also runtime tested before we commit
them. Stating that this changes were not testet is definitly not true.

Regarding the libxul update problem we are still not able to reproduce
it. We have done a lot of testing since the pr was opened under several
conditions and work hard to find the problem. If you like to help to
solve this problem please take a look at the pr and check my question
from yesterday which is still unanswered. Also if you like to help with
testing changes before we commit them feel free to join the gecko team.

Beat