From nobody@FreeBSD.org  Sat Mar 26 13:40:53 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 96E061065672
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 26 Mar 2011 13:40:53 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 868738FC1A
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 26 Mar 2011 13:40:53 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QDerDZ036199
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 26 Mar 2011 13:40:53 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p2QDerQO036198;
	Sat, 26 Mar 2011 13:40:53 GMT
	(envelope-from nobody)
Message-Id: <201103261340.p2QDerQO036198@red.freebsd.org>
Date: Sat, 26 Mar 2011 13:40:53 GMT
From: Kalten <kalten@gmx.at>
To: freebsd-gnats-submit@FreeBSD.org
Subject: firefox 4, WITH_PGO, better Text against DISPLAY problem
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         155949
>Category:       ports
>Synopsis:       www/firefox: firefox 4, WITH_PGO, better Text against DISPLAY problem
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    gecko
>State:          feedback
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 26 13:50:05 UTC 2011
>Closed-Date:    
>Last-Modified:  Thu Apr 28 08:40:10 UTC 2011
>Originator:     Kalten
>Release:        8.2-RELEASE
>Organization:
>Environment:
FreeBSD freeKwasir.Walhalla.Leben 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
if WITH_PGO=true but DISPLAY not accessible:
---SCHNIPP---
INFO | automation.py | Application pid: 51999
Error: cannot open display: localhost:1001
TEST-UNEXPECTED-FAIL | automation.py | Exited with code 1 during test run
INFO | automation.py | Application ran for: 0:00:00.514949
INFO | automation.py | Reading PID log: /usr/tmp/tmpQW8cK8pidlog
gmake: *** [profiledbuild] Error 1
*** Error code 1

Stop in /usr/ports/www/firefox.
*** Error code 1
---schnapp---

I know: there is a message; but /many/ people will overlook it.
Better textsee patch: (Maybe other text ;-) ) (longer text line does
not workno possibility to add help text per selectable item?!)
>How-To-Repeat:
cd /usr/ports/www/firefox
option WITH_PGO=true
but DISPLAY not set, or no access. (e.g. ssh to host, then su and portmaster -Da)
make
>Fix:


Patch attached with submission follows:

--- Makefile.orig	2011-03-25 19:34:21.000000000 +0100
+++ Makefile	2011-03-26 13:54:21.000000000 +0100
@@ -51,7 +51,7 @@
 		--disable-ipc
 
 OPTIONS=	DBUS "Enable D-BUS support" on \
-		PGO "Enable Profile-Guided Optimization" off \
+		PGO "Enable ProfileGuidedOptimization (needs X)" off \
 		SMB "Enable smb:// URI support using gnomevfs" off
 
 .include <bsd.port.pre.mk>


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->gecko 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Mar 26 17:14:58 UTC 2011 
Responsible-Changed-Why:  
Fix synopsis and assign. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=155949 
State-Changed-From-To: open->feedback 
State-Changed-By: beat 
State-Changed-When: Tue Mar 29 05:59:17 UTC 2011 
State-Changed-Why:  
I'm not sure how we should handle this problem. Adding (needs X) is 
misleading too as Firefox without PGO also depends on X. Another point 
is that user will see the option only the first time and after that the 
options are saved. So people may forget that they have selected the PGO 
option. I set this PR to the feedback state as I'd like to get feedback 
from the other gecko@ people as I'm tempted to remove PGO from OPTIONS 
as it is too easy to break the build with PGO selected. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=155949 

From: Beat Gaetzi <beat@FreeBSD.org>
To: Bernhard Froehlich <decke@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/155949: www/firefox: firefox 4, WITH_PGO, better Text against
 DISPLAY problem
Date: Tue, 05 Apr 2011 11:01:05 +0200

 On 04.04.2011 13:29, Bernhard Froehlich wrote:
 > I think the cleanest solution would be a check before starting build to
 > detect if X is available or not. (ideally configure or otherwise port
 > Makefile) But if we are talking about PGO removal do we have some
 > numbers how much speed you gain? I don't feel any differences on my
 > machine and JS benchmarks are about the same. Mozilla ships his own
 > Firefox binaries all without PGO so I'm not sure about the support of
 > that optimizations.
 
 I don't know how we should or can test that X is available or not.
 Please note I don't think that we should remove PGO from the port in
 general I propose to remove it only from OPTIONS. Although I do not have
 numbers what we gain with PGO from my subjective experience when using
 Firefox I think it act faster when building with PGO.
 
 Beat

From: Kalten <kalten@gmx.at>
To: bug-followup@FreeBSD.org, kalten@gmx.at
Cc:  
Subject: Re: ports/155949: www/firefox: firefox 4, WITH_PGO, better Text against DISPLAY problem
Date: Fri, 22 Apr 2011 01:00:39 +0200

 I have found an interesting entry in the /FreeBSD Porter's Handbook/ in
 section =E2=80=9C6.7.4 Getting fake DISPLAY using Xvfb=E2=80=9D[1].
 The option =C2=BBUSE_DISPLAY=3D  yes=C2=AB in the Makefile seems to do the =
 trick.
 
 If I am right, you could try this instead of removing PGO?  I am not
 sure.=20
 
  Greetings, Kalten
 
 [1] http://www.freebsd.org/doc/en/books/porters-handbook/using-x11.html#AEN=
 3577

From: Bernhard Froehlich <decke@FreeBSD.org>
To: Kalten <kalten@gmx.at>
Cc: <gecko@FreeBSD.org>, <bug-followup@FreeBSD.org>
Subject: Re: ports/155949: www/firefox: firefox 4, =?UTF-8?Q?WITH=5FPGO=2C?=
 =?UTF-8?Q?=20better=20Text=20against=20DISPLAY=20problem?=
Date: Fri, 22 Apr 2011 08:38:43 +0200

 On Thu, 21 Apr 2011 23:10:12 GMT, Kalten wrote:
 >  I have found an interesting entry in the /FreeBSD Porter's Handbook/ in
 >  section =E2=80=9C6.7.4 Getting fake DISPLAY using Xvfb=E2=80=9D[1].
 >  The option =C2=BBUSE_DISPLAY=3D  yes=C2=AB in the Makefile seems to do the =
 >  trick.
 >  
 >  If I am right, you could try this instead of removing PGO?  I am not
 >  sure.=20
 
 That is already there but obviously does not work or isn't enough.
 
 -- 
 Bernhard Froehlich
 http://www.bluelife.at/

From: Kalten <kalten@gmx.at>
To: bug-followup@FreeBSD.org, kalten@gmx.at
Cc:  
Subject: Re: ports/155949: www/firefox: firefox 4, WITH_PGO, better Text against DISPLAY problem
Date: Fri, 22 Apr 2011 20:57:22 +0200

 --=-=-=
 Content-Type: text/plain
 
 > That [USE_DISPLAY=yes] is already there but obviously does not work or
 > isn't enough.
 I see--sorry for not having had a look into the Makfile prior to writing
 full of joy and hope--I had a look into ports/Mk/bsd.port.mk now: Let's
 have a deeper look into the matter: (I think, I have solved it) :-)
 
 bsd.port.mk adds the Xvfb (alongside a couple of other ports) to the
 build dependencies and if not building a package (our case) sets the
 DISPLAY variable in the configure- as well as in the make-environment.
 
 The error `cannot open display: localhost:1001' tells us, that the
 python script realiced that fact, but did try to really connect to the X
 server--that is not running (as I assume).  Better saied: the Xvfb(1)
 is not started at display localhost:1001.
 
 The Xvfb realy is being installed (x11-servers/xorg-vfbserver) prior to
 the error, but am I right, that noone did start it?  `Xvfb :1001 &' and
 be aware that you must not use `Xvfb $DISPLAY' as it does not understand
 `localhost:1001' but solely `:1001', and besides: USE_DISPLAY=yes does
 only set DISPLAY in the make- and the configure-environment, not in the
 environment of the Makefile in www/firefox/!
 
 (BTW: courageous; profileserver.py uses a line `PORT=8888' and if
 something else was running there?)
 
 Some not very nice adjustment of www/firefox/Makefile (see attachment).
 It is just meant as an idea of how to do it! (Even too many ${ECHO}s for
 debuging purpose).
 
 I adopted the version of the same problem I happened to find in
 accessibility/accercise/Makefile.  One shoule, at least, write some
 example like this in ports/Mk/bsd.port.mk at USE_DISPLAY: better:
 introduce two functions: one for starting, one for terminating the Xvfb.
 
 One could try to read DISPLAY out of MAKE_ENV or CONFIGURE_ENV, but I
 lost my patience trying; so I set it in the lines below USE_DISPLAY=yes.
 
 Some questions remain open:
 *) What to do, if the build has an error and terminates? post-build will
    not be called and the server will continue to run.  If one calls
    `make clean', the pid-file is gone and noone can terminate the Xvfb
    server.  Restarting one at the same DISPLAY just terminates the new
    one, all will compile.  We could place the pid file elsewhere--still
    no good solution (leads back to some functions mentioned earlier).
    Is there a target being called regardless of failiour in the Makfile
    in <portname>/work/*?
 *) What if some other port is being built paralelly and uses the same
    mechanism: should there be some kind of `smart pointer' to terminate
    the Xvfb, when all currently running port-builds do not need it any
    more?  All will use `:1001' as it es written down in
    ports/Mk/bsd.port.mk at USE_DISPLAY.  Remember: Only the last one
    hast to terminate Xvfb but the others must not do so (at least, I
    think so).
 
 I hope, that `solved' the problem!
 Greetings,
    Kalten
 
 --=-=-=
 Content-Type: text/plain
 Content-Disposition: attachment; filename=patch.txt
 Content-Description: patch-Makefile-PGO
 
 --- Makefile.orig	2011-04-09 01:31:32.000000000 +0200
 +++ Makefile	2011-04-22 20:53:39.000000000 +0200
 @@ -78,6 +78,8 @@
  BUILD_DEPENDS+=	${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3
  USE_PYTHON_BUILD=	yes
  USE_DISPLAY=		yes
 +# in make and config environment, but not accessable here:
 +DISPLAYat=		"localhost:1001"
  .include "${PORTSDIR}/Mk/bsd.python.mk"
  
  MAKEFILE=	client.mk
 @@ -134,6 +136,30 @@
  	(cd ${WRKSRC} && ${GMAKE} distclean)
  .endif
  
 +pre-build:
 +.if defined(WITH_PGO)
 +	@if [ -f ${WRKDIR}/.Xvfb.pid ]; then \
 +	@${ECHO} "Killing ${LOCALBASE}/bin/Xvfb  at PID `${CAT} ${WRKDIR}/.Xvfb.pid`" \
 +	@sleep 5 \
 +	    ${CAT} ${WRKDIR}/.Xvfb.pid | ${XARGS} kill || ${TRUE} ; \
 +	    ${RM} -f ${WRKDIR}/.Xvfb.pid ; \
 +	fi
 +	@${LOCALBASE}/bin/Xvfb `${ECHO_CMD} ${DISPLAYat} | ${SED} -e 's|localhost\(:.*\)|\1|'` \
 +	    -screen 0 800x600x24 > /dev/null 2>&1 & ${ECHO_CMD} $$! > ${WRKDIR}/.Xvfb.pid
 +	@${ECHO} "Started ${LOCALBASE}/bin/Xvfb `${ECHO_CMD} ${DISPLAYat} | ${SED} -e 's|localhost\(:.*\)|\1|'` at PID `${CAT} ${WRKDIR}/.Xvfb.pid` on ${DISPLAYat}"
 +	@sleep 10
 +.endif
 +
 +post-build:
 +.if defined(WITH_PGO)
 +	@if [ -f ${WRKDIR}/.Xvfb.pid ]; then \
 +	@${ECHO} "Killing ${LOCALBASE}/bin/Xvfb  at PID `${CAT} ${WRKDIR}/.Xvfb.pid`" \
 +	@sleep 5 \
 +	    ${CAT} ${WRKDIR}/.Xvfb.pid | ${XARGS} kill || ${TRUE} ; \
 +	    ${RM} -f ${WRKDIR}/.Xvfb.pid ; \
 +	fi
 +.endif
 +
  port-pre-install:
  	${ECHO_CMD} 'share/applications/${MOZILLA}.desktop' >> ${PLISTF}
  	${ECHO_CMD} "@dirrmtry share/applications" >> ${PLISTD}
 
 --=-=-=--

From: Kalten <kalten@gmx.at>
To: bug-followup@FreeBSD.org, kalten@gmx.at
Cc:  
Subject: Re: ports/155949: www/firefox: firefox 4, WITH_PGO, better Text against DISPLAY problem
Date: Fri, 22 Apr 2011 21:19:43 +0200

 --=-=-=
 Content-Type: text/plain
 
 I am terribly sorry! The patch was not good (allthough compiling
 worked)--I made it buggy when I added the ${ECHO}s.
 
 Better version here. Sorry once again! :-(
 (you might delete the old one? Don't know)
 
 ru,
  Kalten
 
 --=-=-=
 Content-Type: text/plain
 Content-Disposition: attachment; filename=patch2.txt
 Content-Description: patch-Makefile2
 
 --- Makefile.orig	2011-04-09 01:31:32.000000000 +0200
 +++ Makefile	2011-04-22 21:12:46.000000000 +0200
 @@ -78,6 +78,8 @@
  BUILD_DEPENDS+=	${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3
  USE_PYTHON_BUILD=	yes
  USE_DISPLAY=		yes
 +# in make and config environment, but not accessable here:
 +DISPLAYat=		"localhost:1001"
  .include "${PORTSDIR}/Mk/bsd.python.mk"
  
  MAKEFILE=	client.mk
 @@ -134,6 +136,30 @@
  	(cd ${WRKSRC} && ${GMAKE} distclean)
  .endif
  
 +pre-build:
 +.if defined(WITH_PGO)
 +	@if [ -f ${WRKDIR}/.Xvfb.pid ]; then \
 +	${ECHO} "Killing ${LOCALBASE}/bin/Xvfb  at PID `${CAT} ${WRKDIR}/.Xvfb.pid`"; \
 +	sleep 5; \
 +	    kill `${CAT} ${WRKDIR}/.Xvfb.pid` || ${TRUE} ; \
 +	    ${RM} -f ${WRKDIR}/.Xvfb.pid ; \
 +	fi
 +	@${LOCALBASE}/bin/Xvfb `${ECHO_CMD} ${DISPLAYat} | ${SED} -e 's|localhost\(:.*\)|\1|'` \
 +	    -screen 0 800x600x24 > /dev/null 2>&1 & ${ECHO_CMD} $$! > ${WRKDIR}/.Xvfb.pid
 +	@${ECHO} "Started ${LOCALBASE}/bin/Xvfb `${ECHO_CMD} ${DISPLAYat} | ${SED} -e 's|localhost\(:.*\)|\1|'` at PID `${CAT} ${WRKDIR}/.Xvfb.pid` on ${DISPLAYat}"
 +	@sleep 10
 +.endif
 +
 +post-build:
 +.if defined(WITH_PGO)
 +	@if [ -f ${WRKDIR}/.Xvfb.pid ]; then \
 +	${ECHO} "Killing ${LOCALBASE}/bin/Xvfb  at PID `${CAT} ${WRKDIR}/.Xvfb.pid`"; \
 +	sleep 5; \
 +	    kill `${CAT} ${WRKDIR}/.Xvfb.pid` || ${TRUE} ; \
 +	    ${RM} -f ${WRKDIR}/.Xvfb.pid ; \
 +	fi
 +.endif
 +
  port-pre-install:
  	${ECHO_CMD} 'share/applications/${MOZILLA}.desktop' >> ${PLISTF}
  	${ECHO_CMD} "@dirrmtry share/applications" >> ${PLISTD}
 
 --=-=-=--

From: Bernhard Froehlich <decke@FreeBSD.org>
To: Kalten <kalten@gmx.at>
Cc: <bug-followup@FreeBSD.org>
Subject: Re: ports/155949: www/firefox: firefox 4, =?UTF-8?Q?WITH=5FPGO=2C?=
 =?UTF-8?Q?=20better=20Text=20against=20DISPLAY=20problem?=
Date: Thu, 28 Apr 2011 10:30:15 +0200

 On Fri, 22 Apr 2011 19:00:24 GMT, Kalten wrote:
 >  I adopted the version of the same problem I happened to find in
 >  accessibility/accercise/Makefile.  One shoule, at least, write some
 >  example like this in ports/Mk/bsd.port.mk at USE_DISPLAY: better:
 >  introduce two functions: one for starting, one for terminating the Xvfb.
 
 That fix should be done in bsd.port.mk and all ports that have
 USE_DISPLAY and their own workarounds for that need to be cleaned up as
 well.
 
 >  One could try to read DISPLAY out of MAKE_ENV or CONFIGURE_ENV, but I
 >  lost my patience trying; so I set it in the lines below USE_DISPLAY=yes.
 >  
 >  Some questions remain open:
 >  *) What to do, if the build has an error and terminates? post-build will
 >     not be called and the server will continue to run.  If one calls
 >     `make clean', the pid-file is gone and noone can terminate the Xvfb
 >     server.  Restarting one at the same DISPLAY just terminates the new
 >     one, all will compile.  We could place the pid file elsewhere--still
 >     no good solution (leads back to some functions mentioned earlier).
 >     Is there a target being called regardless of failiour in the Makfile
 >     in <portname>/work/*?
 
 Yes it could happen that Xvfb keeps running. Probably there is a better
 solution for that.
 
 >  *) What if some other port is being built paralelly and uses the same
 >     mechanism: should there be some kind of `smart pointer' to terminate
 >     the Xvfb, when all currently running port-builds do not need it any
 >     more?  All will use `:1001' as it es written down in
 >     ports/Mk/bsd.port.mk at USE_DISPLAY.  Remember: Only the last one
 >     hast to terminate Xvfb but the others must not do so (at least, I
 >     think so).
 
 Just start Xvfb with a port and if it fails start it again with a
 different port number?
 
 >  I hope, that `solved' the problem!
 
 Thanks, that's good work! I do not have time to work on that so if
 someone wants to finish this up please feel free to do this. This PR is
 not even gecko related anymore.
 
 -- 
 Bernhard Froehlich
 http://www.bluelife.at/
>Unformatted:
