Re: Firefox 21.0 Crash
On 05/21/13 07:02, Cy Schubert wrote: Hi, I'm experiencing firefox crashes since updating to 21.0. Me too. For me, it'll run ok for a while and then when I bring up a new tab or actively do something with the UI it will crash unexpectedly. Happening approximately every few minutes of active use. Leaving it open but not doing anything with it will not trigger a crash. When I ran firefox from the console the only thing printed was: lstewart@lstewart firefox ATTENTION: default value of option force_s3tc_enable overridden by environment. It's unclear if that message is related to the crash or not. Some details about my system: lstewart@lstewart uname -a FreeBSD lstewart 9.1-STABLE FreeBSD 9.1-STABLE #10 r250824M: Mon May 20 22:00:29 EST 2013 root@lstewart:/usr/obj/usr/src/sys/LSTEWART-DESKTOP amd64 lstewart@lstewart pkg info firefox firefox-21.0_1,1 Web browser based on the browser portion of Mozilla Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Firefox 21.0 Crash
On 05/22/13 18:04, Cy Schubert wrote: In message 519c616c.50...@freebsd.org, Lawrence Stewart writes: On 05/21/13 07:02, Cy Schubert wrote: Hi, I'm experiencing firefox crashes since updating to 21.0. Me too. For me, it'll run ok for a while and then when I bring up a new tab or actively do something with the UI it will crash unexpectedly. Happening approximately every few minutes of active use. Leaving it open but not doing anything with it will not trigger a crash. I can leave the computer for five minutes discovering it had crashed when I return. hmm maybe I haven't managed to leave it running long enough without me doing something with it. I'll try overnight. When I ran firefox from the console the only thing printed was: lstewart@lstewart firefox ATTENTION: default value of option force_s3tc_enable overridden by environment. I don't see this. I verified that this is printed well before the crash happens so I'm pretty sure its totally unrelated. It's unclear if that message is related to the crash or not. Some details about my system: lstewart@lstewart uname -a FreeBSD lstewart 9.1-STABLE FreeBSD 9.1-STABLE #10 r250824M: Mon May 20 22:00:29 EST 2013 root@lstewart:/usr/obj/usr/src/sys/LSTEWART-DESKTOP amd64 Similarly my laptop. I've yet to try it on -CURRENT (also on the same laptop) though. What extensions do you have installed? (If you want you can send the list to me privately.) I uninstalled ghostery which made it more stable though when I took the dog for a quick walk I discovered the browser was gone upon my return. For the moment it appears stable (knock on wood). I have Adblock Plus 2.2.4 and Flashblock 1.5.17 as Extensions, and linux-f10-flashplugin-11.2r202.285 via nspluginwrapper 1.4.4 as a plugin. I tried disabling all of them but it still crashes. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 08/21/12 17:04, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 07:05:49AM +0100, Matthew Seaman wrote: On 21/08/2012 00:21, Baptiste Daroussin wrote: On Tue, Aug 21, 2012 at 12:09:46AM +0300, Vitaly Magerya wrote: Baptiste Daroussin b...@freebsd.org wrote: Please [...] ask question about pkgng [...] What would be the best practice of mixing ports with packages? The use case I have in mind is compiling Xorg ports locally WITH_NEW_XORG and WITH_KMS, and using packages from pkgbeta.freebsd.org for everything else. Is there some mixture of pkg and portmaster flags that allows this kind of setup? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org There is no best practice for that unfortunatly, (as actually) the best for you is maybe to build your own pkgng repostories? http://wiki.freebsd.org/PkgPrimer#Using_poudriere for example? We are open to suggestion here :) At the moment, it is about as tricky as mixing locally compiled ports with pkg_tools packages: ie. it might work, or it might leave you a quivering, sobbing mess lost in a pit of dark despair. One thing that should help is a proposal to record metadata like the SVN revision number of the ports tree used to build repository packages into the repository catalogue (repo.sqlite), so users can in principle check out the same revision locally to build their own ports. Unfortunately no one has written that yet, and its probably too late for it to make it into release-1.0. yes but it should definitly find its way to 1.1! Agreed, though ultimately we want to move to making mixing of ports pkgs idiot-proof - something I suspect we're in better shape to do with pkgng. As a recently minted roadtester of pkgng and wanting to do the same as Vitaly without setting up Poudriere, I had to reverse engineer the ports tree svn revision to make sure I could mix and match from pkgbeta and stuff I built locally via ports with WITH_NEW_XORG and WITH_KMS. This becomes more annoying to manage going forward. So far I'm enjoying my pkgng experience for the most part and wish to thank all those involved in getting it to this stage. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OO 3.3.0 fails to build connectivity module on amd64 9-STABLE
On 02/14/12 17:32, Don Lewis wrote: On 10 Feb, Maho NAKATA wrote: Hi I also reproduced, and pointy hat, either. It looks like ooo port is broken again... Thanks Nakata Maho From: Lawrence Stewartlstew...@freebsd.org Subject: OO 3.3.0 fails to build connectivity module on amd64 9-STABLE Date: Thu, 09 Feb 2012 16:42:30 +1100 Hi, The OO 3.3.0 build fails in the connectivity module with the following error: Compiling: connectivity/source/parse/wrap_sqlbison.cxx c++ -fmessage-length=0 -c -O2 -fno-strict-aliasing -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -fvisibility=hidden -I. -I../../unxfbsdx.pro/misc -I../../unxfbsdx.pro/inc/sql -I../inc -I../../inc/pch -I../../inc -I../../unx/inc -I../../unxfbsdx.pro/inc -I. -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/stl -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/external -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solenv/unxfbsdx/inc -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solenv/inc -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/res -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/stl -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solenv/inc/Xp31 -I/usr/local/diablo-jdk1.6.0/include -I/usr/local/diablo-jdk1.6.0/include/freebsd -I/usr/local/diablo-jdk1.6.0/i nclude/bs d -I/usr/local/diablo-jdk1.6.0/include/linux -I/usr/local/diablo-jdk1.6.0/include/native_threads/include -I/usr/local/include -I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/offuh -I. -I../../res -I. -pipe -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fpic -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -DX86_64 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DSUPD=330 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DOOO_DLLIMPLEMENTATION_DBTOOLS -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../unxfbsdx.pro/slo/wrap_sqlbison.o /usr/ports/editors/openoffice.org-3/work/OOO330_m20/connectivity/source/parse/wrap_sqlbison.cxx In file included from /usr/ports/editors/openoffice.org-3/work/OOO330_m20/connectivity/source/parse/wrap_sqlbison.cxx:31: ../../unxfbsdx.pro/misc/sqlbison.cxx: In function 'int SQLyyparse()': ../../unxfbsdx.pro/misc/sqlbison.cxx:7813: error: invalid conversion from 'const char*' to 'sal_Char*' ../../unxfbsdx.pro/misc/sqlbison.cxx:7813: error: initializing argument 1 of 'void connectivity::OSQLParser::error(sal_Char*)' dmake: Error code 1, while making '../../unxfbsdx.pro/slo/wrap_sqlbison.obj' Any thoughts on how to fix? This patch worked for me. Put it under editors/openoffice.org-3/files. Works for me, thanks Don. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
OO 3.3.0 fails to build connectivity module on amd64 9-STABLE
Hi,
The OO 3.3.0 build fails in the connectivity module with the following
error:
Compiling: connectivity/source/parse/wrap_sqlbison.cxx
c++ -fmessage-length=0 -c -O2 -fno-strict-aliasing -DENABLE_LAYOUT=0
-DENABLE_LAYOUT_EXPERIMENTAL=0 -fvisibility=hidden -I.
-I../../unxfbsdx.pro/misc -I../../unxfbsdx.pro/inc/sql -I../inc -I../../inc/pch
-I../../inc -I../../unx/inc -I../../unxfbsdx.pro/inc -I.
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/stl
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/external
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solenv/unxfbsdx/inc
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solenv/inc
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/res
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/stl
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solenv/inc/Xp31
-I/usr/local/diablo-jdk1.6.0/include
-I/usr/local/diablo-jdk1.6.0/include/freebsd -I/usr/local/diablo-jdk1.6.0/i
nclude/bs
d -I/usr/local/diablo-jdk1.6.0/include/linux
-I/usr/local/diablo-jdk1.6.0/include/native_threads/include
-I/usr/local/include
-I/usr/ports/editors/openoffice.org-3/work/OOO330_m20/solver/330/unxfbsdx.pro/inc/offuh
-I. -I../../res -I. -pipe -fvisibility-inlines-hidden -g1 -Wall -Wextra
-Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-fpic -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -D_PTHREADS -D_REENTRANT
-DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400
-DHAVE_GCC_VISIBILITY_FEATURE -DX86_64 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3
-DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DSUPD=330 -DPRODUCT -DNDEBUG
-DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA
-DOOO_DLLIMPLEMENTATION_DBTOOLS -DSHAREDLIB -D_DLL_ -fexceptions
-fno-enforce-eh-specs -DEXCEPTIONS_ON -o
../../unxfbsdx.pro/slo/wrap_sqlbison.o
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/connectivity/source/parse/wrap_sqlbison.cxx
In file included from
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/connectivity/source/parse/wrap_sqlbison.cxx:31:
../../unxfbsdx.pro/misc/sqlbison.cxx: In function 'int SQLyyparse()':
../../unxfbsdx.pro/misc/sqlbison.cxx:7813: error: invalid conversion from
'const char*' to 'sal_Char*'
../../unxfbsdx.pro/misc/sqlbison.cxx:7813: error: initializing argument 1 of
'void connectivity::OSQLParser::error(sal_Char*)'
dmake: Error code 1, while making '../../unxfbsdx.pro/slo/wrap_sqlbison.obj'
Ports tree was csuped yesterday and all installed ports are up to date.
System info that might be useful...
lstewart@lstewart uname -a
FreeBSD lstewart 9.0-STABLE FreeBSD 9.0-STABLE #1 r231173M: Wed Feb 8
16:14:51 EST 2012 lstewart@lstewart:/usr/obj/usr/src/sys/DESKTOP amd64
lstewart@lstewart pkg_info -x bison
Information for bison-2.5,1:
Relevant lines from /etc/make.conf:
.if ${.CURDIR:M*/editors/openoffice.org-3}
WITH_KDE4=1
LOCALIZED_LANG=en-GB
.endif
I'm running KDE 4.7.4.
Any thoughts on how to fix?
Cheers,
Lawrence
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: KWin no longer compositing?
On 10/29/11 19:47, Kostik Belousov wrote: On Sat, Oct 29, 2011 at 07:24:52PM +1100, Lawrence Stewart wrote: On 10/24/11 19:05, Andriy Gapon wrote: on 24/10/2011 07:07 Greg Lewis said the following: So it seems like even the newest version we support in ports is an antique :(. I'm going to guess upgrading it is not going to be easy. Almost trivial in a sense. I've been using xorg-dev for quite a while and it works great (for me). Mesa is at 7.11 in those ports. http://trillian.chruetertee.ch/ports/wiki I too no longer have compositing in KDE 4.7.2 where I used to with 4.6.x. Is there a technical reason the newer MESA hasn't been merged into mainline ports? Or is it purely a manpower thing? There is newer Mesa in xorg-dev. See the instructions at http://miwi.bsdcrew.de/2011/02/cft-xorg-7-5-miwi1-freebsd-edition/ Thanks for the pointer. There is a rat nest of the system dependencies and ddx/xorg server versions that makes the update really tricky. Until GEMified i915.ko is not committed to the src/, the Intel GPUs will not work, I believe. Also, it seems that Mesa 7.11 is the last release that will work for Radeon DRM that lacks TTM and execution support. I use Radeon so I guess it's an interim update which will get things going in the short term followed by hoping someone capable of doing the TTM support for it comes forward. Do you have a feel for just how much time would be involved in doing the required work to get the radeon driver up to scratch? Does your work for the Intel GPUs lay some common groundwork which will reduce the work required to update other drivers like radeon? (It is clear I have no concept about how all the moving parts fit together or what's involved in getting all drivers into shape for the future i.e. KMS). Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Detecting dependencies
On 09/17/11 18:09, b. f. wrote: On 09/15/11 07:06, chukharev at mail.ru wrote: Hi, There have been a discussion about finding interdependencies of ports. I have a relatively simple Python script for that. There is a pr ports/160007 to add its early version. Unfortunately, I missed a reply to it, so there is an issue which I have not yet addressed... Since that time, I added reverse dependencies with full ports tree scanning (1 h on my 2.5GHz notebook) and saving the tree (directed graph, actually) to a file, so that rescanning all ports tree is not needed. See http://code.google.com/p/porttree/ If there will be interest, scanning packages interdependencies could also be added. On a related subtopic, we also need a tool that identifies implicit dependencies not captured in the ports Makefiles. I hacked the following together earlier this year to smooth over the updating process when key libraries get bumped (e.g. the gettext update at the time I wrote the script was a nightmare). There were a tonne of ports which needed to be updated even though they didn't explicitly record a dependency on gettext. https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh It's still quite rough and manually driven and is tied to portmaster at the moment, but I use it routinely after a portmaster -ad to check that no libs are missing dependencies. It works pretty well most of the time, but definitely needs more finessing. I share it mostly to prove the feasibility of the approach and in case anyone is curious. What, no check to see if the libraries listed in the DT_NEEDED tags are actually needed? And no kitchen sink? ;) err... look, over there! A dog with a puffy tail chasing a kitchen sink! *runs* There are scripts in ports/Tools/scripts that were intended to perform similar tasks, although they may be rougher than your script. Yes they provide various bits and pieces of the puzzle. I haven't thought the following ideas through a great deal and welcome feedback, but I think the basic functionality/premise of this script could be integrated into the ports framework so that at package registration time, implicit deps are identified and marked in the package database. A warning could also be generated that the port is using deps not identified in the Makefile, and perhaps trigger a send-pr to the port maintainer to let them know. ... A script like this could also be integrated/called somehow from a tool like portmaster during an update to ensure ports with implicit dependencies on another port which has been updated are identified and recompiled too so that we avoid the nasty problems that crop up with missing library dependencies. Just as in the other *_DEPENDS lists, it was a conscious policy decision, for the sake of brevity and efficiency, that if port B requires port C, and port A requires port B, then libraries from port C will not be listed in the LIB_DEPENDS of port A, even if port A links directly to those libraries. But because Right, which is fine (and more desirable - simpler is better) if we have a way built into the system to actually derive them at upgrade/install time and ensure we don't leave the system broken. Given that the information can be derived, it seems sensible not to have ports' Makefiles define all deps explicitly, and instead use tools at install/upgrade time to do the heavy lifting automatically. Going for brevity without the infrastructure in place to automagically compensate for the information not being explicitly codified in the makefiles means certain brokeness, which is not cool. of recurring problems with partial port updates, this policy has been criticized. I think that the last time the matter was raised, the consensus seemed to lean toward listing all needed libraries, but the amount of work involved in, and the likely disruption arising from, refactoring all LIB_DEPENDS in the tree dissuaded anyone doing so. I can't see a reason why the policy can't stay as it is if the smarts can be added to generate the implicit dependency info when needed, and more importantly use that generated information to avoid leaving the system broken. Whether we argue the smarts belong solely in a tool like portmaster or should be integrated into the ports infrastructure itself is fair game. My gut feeling is that the deps list stored on disk by the ports system at registration time should be complete with explicit and implicit deps, even though the port's Makefile only lists those which are explicit. Tools like portmaster then only need to use the information as is to do their part of the job and the system should be left intact post upgrade cycle, at least from a broken lib deps perspective. If my gut feeling is valid, then that implies the ports infrastructure itself should do a step post install but pre registration where implicit deps are identified and added to the port's +CONTENTS file. I'm very unfamiliar with the
Re: Detecting dependencies
On 09/15/11 07:06, chukha...@mail.ru wrote: Hi, There have been a discussion about finding interdependencies of ports. I have a relatively simple Python script for that. There is a pr ports/160007 to add its early version. Unfortunately, I missed a reply to it, so there is an issue which I have not yet addressed... Since that time, I added reverse dependencies with full ports tree scanning (1 h on my 2.5GHz notebook) and saving the tree (directed graph, actually) to a file, so that rescanning all ports tree is not needed. See http://code.google.com/p/porttree/ If there will be interest, scanning packages interdependencies could also be added. On a related subtopic, we also need a tool that identifies implicit dependencies not captured in the ports Makefiles. I hacked the following together earlier this year to smooth over the updating process when key libraries get bumped (e.g. the gettext update at the time I wrote the script was a nightmare). There were a tonne of ports which needed to be updated even though they didn't explicitly record a dependency on gettext. https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh It's still quite rough and manually driven and is tied to portmaster at the moment, but I use it routinely after a portmaster -ad to check that no libs are missing dependencies. It works pretty well most of the time, but definitely needs more finessing. I share it mostly to prove the feasibility of the approach and in case anyone is curious. I haven't thought the following ideas through a great deal and welcome feedback, but I think the basic functionality/premise of this script could be integrated into the ports framework so that at package registration time, implicit deps are identified and marked in the package database. A warning could also be generated that the port is using deps not identified in the Makefile, and perhaps trigger a send-pr to the port maintainer to let them know. That way when we update ports using a tool like portmaster, it will know to update all the relevant ports and avoid leaving your system broken (yes, I'm aware of the -w switch, but I prefer not to use it as you can get into nasty situations if the compat and non-compat libs get mixed at run-time). A script like this could also be integrated/called somehow from a tool like portmaster during an update to ensure ports with implicit dependencies on another port which has been updated are identified and recompiled too so that we avoid the nasty problems that crop up with missing library dependencies. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Bumping lightning to 1.0b5 so it works with Thunderbird 6.0.1
Hi Florian, On 09/08/11 17:51, Florian Smeets wrote: On 08.09.2011 02:16, Lawrence Stewart wrote: Hi Gecko team, The update from Thunderbird 6.0 to 6.0.1 has stopped the Lightning 1.0b5pre plugin from working - it claims to be incompatible with the new version of Thunderbird and can't be enabled. Lightning 1.0b5 seems to work fine with Thunderbird 6.0.1 on my wife's windows PC, so I'm guessing a very minor bump to the lightning build source is needed to get it working again. If you're aware of this issue then great, but if not, just wanted to bring it to your attention so that it's on your radar. Hi Lawrence, did you reinstall the built xpi? It's usually located here /usr/local/share/lightning/lightning-thunderbird.xpi. That one should be compatible. You are indeed correct, forcibly removing and re-adding the plugin solved it, sorry for the noise. I'm working on making this step automatic, but I'm not there yet, it's on the TODO list ;) Would be cool, but this was most definitely a case of PEBKAC. I've had to do that step in the past. Not sure why I thought I'd done it this time and it didn't work. Move along, nothing to see here... Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Bumping lightning to 1.0b5 so it works with Thunderbird 6.0.1
Hi Gecko team, The update from Thunderbird 6.0 to 6.0.1 has stopped the Lightning 1.0b5pre plugin from working - it claims to be incompatible with the new version of Thunderbird and can't be enabled. Lightning 1.0b5 seems to work fine with Thunderbird 6.0.1 on my wife's windows PC, so I'm guessing a very minor bump to the lightning build source is needed to get it working again. If you're aware of this issue then great, but if not, just wanted to bring it to your attention so that it's on your radar. Your work keeping all this moving parts up to date is really appreciated. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OO 3.3.0 fails to build moz module on amd64 8-STABLE
On 06/07/11 19:05, Maho NAKATA wrote: thanks, committed, Working for me now too. Thanks Don for the pointer and Nakata for committing the fix. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OO 3.3.0 fails to build moz module on amd64 8-STABLE
Hi Nakata, Apologies for the delay in replying. On 05/12/11 11:54, Maho NAKATA wrote: Hi I also reproduced in the tinderbox... Thanks for looking at this. Your analysis that make is being invoked instead of gmake is something I hadn't considered, but sounds plausible. If you have any ideas or patches for me to try, let me know. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
OO 3.3.0 fails to build moz module on amd64 8-STABLE
Hi,
I've attempted to build OO 3.3.0 on two separate machines set up from
scratch recently and both are unable to complete the OO build.
My most recent attempt to build is with a ports tree cvsup'd yesterday
(2011-05-07) and all my installed ports were built from the ports tree
and are up to date. Some details about the system:
lstewart@lstewart-laptop uname -a
FreeBSD lstewart-laptop 8.2-STABLE FreeBSD 8.2-STABLE #0 r221492: Fri
May 6 00:41:20 EST 2011
lstewart@lstewart-laptop:/usr/obj/usr/src/sys/GENERIC amd64
Relevant lines from /etc/make.conf:
.if ${.CURDIR:M*/editors/openoffice.org-3}
WITH_KDE4=1
LOCALIZED_LANG=en-GB
.endif
I'm running KDE 4.6.2.
The problem stems from the moz build module. Here are the last few
lines of console output when the make dies:
##
Entering
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/drawinglayer/util
drawinglayer deliver
Entering /usr/ports/editors/openoffice.org-3/work/OOO330_m20/slideshow/util
slideshow deliver
1 module(s):
moz
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz
Attention: if you fix the errors in above module(s) you may prolongue
your the build issuing command:
build --from moz
*** Error code 1
Stop in /usr/ports/editors/openoffice.org-3.
##
The OO build log for the moz module says this:
##
gmake[5]: Entering directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews/extensions/smime/build'
Makefile:83: *** missing separator. Stop.
gmake[5]: Leaving directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews/extensions/smime/build'
gmake[4]: *** [export] Error 2
gmake[4]: Leaving directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews/extensions/smime'
gmake[3]: *** [export] Error 2
gmake[3]: Leaving directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews/extensions'
gmake[2]: *** [export] Error 2
gmake[2]: Leaving directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews'
gmake[1]: *** [tier_99] Error 2
gmake[1]: Leaving directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir'
gmake: *** [default] Error 2
dmake: Error code 2, while making
'./unxfbsdx.pro/misc/build/so_built_ooo_mozab'
##
Sure enough, line 83 of
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews/extensions/smime/build/Makefile
looks like this:
SHARED_LIBRARY_LIBS + = $(DIST)/lib/$(LIB_PREFIX)msgbsutl_s.$(LIB_SUFFIX)
The space between the + and = looks like the problem to me. Some
sort of Makefile template problem perhaps?
If I delete the space to make += and re-run make from the
editors/openoffice.org-3 port dir, the build dies again in the moz
module. The console output when the make dies this time looks like:
##
Entering
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/drawinglayer/source/animation
slideshow deliver
Entering
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/drawinglayer/util
drawinglayer deliver
1 module(s):
moz
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making
/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz
Attention: if you fix the errors in above module(s) you may prolongue
your the build issuing command:
build --from moz
*** Error code 1
Stop in /usr/ports/editors/openoffice.org-3.
##
and the last few lines of the OO build log output for the moz module
says this:
##
gmake[5]: Entering directory
`/usr/ports/editors/openoffice.org-3/work/OOO330_m20/moz/unxfbsdx.pro/misc/build/mozilla/X_objdir/mailnews/extensions/smime/build'
nsMsgSMIMEFactory.cpp
c++ -o nsMsgSMIMEFactory.o -c -I../../../../dist/include/system_wrappers
-include ../../../../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API
-DOSTYPE=\FreeBSD8\ -DOSARCH=\FreeBSD\ -DBUILD_ID=00
-I../../../../dist/include/xpcom -I../../../../dist/include/string
-I../../../../dist/include/mime -I../../../../dist/include/msgcompose
-I../../../../dist/include/pipnss -I../../../../dist/include/necko
-I../../../../dist/include/intl -I../../../../dist/include/caps
-I../../../../dist/include/msgsmime -I../../../../dist/include
-I../../../../dist/include/nspr-I/usr/local/include -fPIC
-I/usr/local/include -I/usr/local/include -fno-rtti -fno-exceptions
-Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual
-Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long
-pedantic -fshort-wchar -pipe -DNDEBUG -DTRIMMED -O
-I/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT
Re: Adding a PAM config option to net-im/ejabberd
On 01/31/11 13:09, Ashish SHUKLA wrote:
Lawrence Stewart writes:
On 01/31/11 00:45, Ashish SHUKLA wrote:
Hi Lawrence,
Lawrence Stewart writes:
Hi Ashish,
What do you think about applying the attached patch to the ejabberd
port? It installs some parts required to allow ejabberd to auth against
PAM and is working great for me.
Sure, I can apply it, once ports freeze is over. I also need to update
ejabberd. I'll do both together.
Sounds good, thanks. One question: in order to get PAM auth working, you
have to set uid root on the epam bits and chown them appropriately in
order to allow things to work. Should the port installation process do
these steps as well or should we leave them to the user? I would be
inclined to have the port do them so that upgrading the port doesn't
break PAM auth after the upgrade. We would want to print a big warning
at the end of the port install about the set uid security aspects though.
Thanks for the mention, I suggest adding mention of setuid bit in the
description of the OPTION. And ofcourse port is going to set the setuid bit
during installation.
And `security-check' target in bsd.port.mk will catch the setuid bit set on
the installed executable, and will inform the user as well. So, adding a
warning about setuid bit be redundant, IMHO.
Updated patch attached. Feel like committing it for me?
Cheers,
Lawrence
--- Makefile.orig 2010-10-25 08:55:04.0 +1100
+++ Makefile2011-03-06 14:47:27.0 +1100
@@ -23,7 +23,8 @@
USE_RC_SUBR= ${PORTNAME}
NOPRECIOUSMAKEVARS=yes
-OPTIONS= ODBCEnable ODBC support off
+OPTIONS= ODBCEnable ODBC support off \
+ PAM Enable setuid PAM auth supportoff
MAKE_ENV= PORTVERSION=${PORTVERSION}
CONFIGURE_ARGS+=--localstatedir=/var
@@ -55,6 +56,13 @@
PLIST_SUB+=ODBC=@comment
.endif
+.if defined(WITH_PAM)
+CONFIGURE_ARGS+=--enable-pam
+PLIST_SUB+=PAM=
+.else
+PLIST_SUB+=PAM=@comment
+.endif
+
.if defined(NOPORTDOCS)
MAKE_ARGS+=NOPORTDOCS=${NOPORTDOCS}
.endif
@@ -67,6 +75,12 @@
${FIND} ${PREFIX}/lib/erlang/lib/${DISTNAME} -type f -print0 | ${XARGS}
-0 ${CHMOD} ${SHAREMODE}
${FIND} ${PREFIX}/lib/erlang/lib/${DISTNAME} -type f -print0 | ${XARGS}
-0 ${CHOWN} ${SHAREOWN}:${SHAREGRP}
+.if defined(WITH_PAM)
+ ${CHMOD} 4750 ${PREFIX}/lib/erlang/lib/${DISTNAME}/priv/bin/epam
+ ${CHOWN} root:ejabberd
${PREFIX}/lib/erlang/lib/${DISTNAME}/priv/bin/epam
+ ${INSTALL} -m 444 ${FILESDIR}/pam_ejabberd ${PREFIX}/etc/pam.d/ejabberd
+.endif
+
@${CAT} ${PKGMESSAGE}
.include bsd.port.post.mk
--- pkg-plist.orig 2010-10-01 02:22:15.0 +1000
+++ pkg-plist 2011-03-06 14:16:50.0 +1100
@@ -58,6 +58,9 @@
%%ODBC%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/%%PORTNAME%%_odbc.beam
%%ODBC%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/%%PORTNAME%%_odbc_sup.beam
%%ODBC%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/odbc_queries.beam
+%%PAM%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/epam.beam
+%%PAM%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/priv/bin/epam
+%%PAM%%etc/pam.d/ejabberd
lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/dynamic_compile.beam
lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/ejabberd_captcha.beam
lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/ejabberd_commands.beam
--- files/pam_ejabberd.orig 2011-03-06 13:00:15.0 +1100
+++ files/pam_ejabberd 2011-03-06 14:45:11.0 +1100
@@ -0,0 +1,6 @@
+#
+# PAM configuration for the ejabberd service
+#
+
+# auth
+auth requiredpam_unix.so no_warn try_first_pass
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Adding a PAM config option to net-im/ejabberd
Hi Ashish,
What do you think about applying the attached patch to the ejabberd
port? It installs some parts required to allow ejabberd to auth against
PAM and is working great for me.
Cheers,
Lawrence
--- Makefile2010-10-25 08:55:04.0 +1100
+++ Makefile.withpam2011-01-10 01:52:36.0 +1100
@@ -23,7 +23,8 @@
USE_RC_SUBR= ${PORTNAME}
NOPRECIOUSMAKEVARS=yes
-OPTIONS= ODBCEnable ODBC support off
+OPTIONS= ODBCEnable ODBC support off \
+ PAM Enable PAM auth support off
MAKE_ENV= PORTVERSION=${PORTVERSION}
CONFIGURE_ARGS+=--localstatedir=/var
@@ -55,6 +56,13 @@
PLIST_SUB+=ODBC=@comment
.endif
+.if defined(WITH_PAM)
+CONFIGURE_ARGS+=--enable-pam
+PLIST_SUB+=PAM=
+.else
+PLIST_SUB+=PAM=@comment
+.endif
+
.if defined(NOPORTDOCS)
MAKE_ARGS+=NOPORTDOCS=${NOPORTDOCS}
.endif
--- pkg-plist 2010-10-01 02:22:15.0 +1000
+++ pkg-plist.withpam 2011-01-10 01:50:56.0 +1100
@@ -58,6 +58,8 @@
%%ODBC%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/%%PORTNAME%%_odbc.beam
%%ODBC%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/%%PORTNAME%%_odbc_sup.beam
%%ODBC%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/odbc_queries.beam
+%%PAM%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/epam.beam
+%%PAM%%lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/priv/bin/epam
lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/dynamic_compile.beam
lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/ejabberd_captcha.beam
lib/erlang/lib/%%PORTNAME%%-%%PORTVERSION%%/ebin/ejabberd_commands.beam
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net/isc-dhcp41-client, dhclient-script and DHCPv6
On 09/29/10 06:56, Wesley Shields wrote: On Wed, Sep 22, 2010 at 06:20:07PM +1000, Lawrence Stewart wrote: Hi Wesley, I've been playing with DHCPv6 and in doing so, ran into an apparent problem with the net/isc-dhcp41-client port. I've switched to using the script provided by upstream. Thanks for noticing this and sorry for the delay in response. No worries at all and thanks for looking into this. I appreciate it. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
net/isc-dhcp41-client, dhclient-script and DHCPv6
Hi Wesley, I've been playing with DHCPv6 and in doing so, ran into an apparent problem with the net/isc-dhcp41-client port. It currently overwrites the FreeBSD client script distributed by ISC with a custom script client::scripts::freebsd which lives in the net/isc-dhcp41-server port's files directory. I'm not sure what the historical reasoning for this is, but the custom script does not work when the ISC client is used to do DHCPv6 (it barfs with dhclient: dhclient-script called with invalid reason PREINIT6. There is no mention of PREINIT6 in /usr/local/sbin/dhclient-script, but there is in the ISC stock script.). Do you have any thoughts on if there is still the need to replace the ISC script with a custom one? If the answer is no longer necessary, then we can simply remove the post-extract target from the net/isc-dhcp41-server Makefile. If there is a good reason to keep the custom script, then some further hacking will be required. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Whither Thunderbird 3.1(.1)?
On 08/05/10 02:27, jhell wrote: Just for the sheer sake of saying it since its the least I can do for this, I would like to say thanks to the gecko team for all the nice work. Having email with a nice project integrated like lightning means a world of difference for a lot of people if not just me. For the FreeBSD Project to have invaluable tools at-hand like these is priceless and speaks for it self among all the features and tools available. So with a final word, Thanks. +1 to all of the above. I use Thunderbird and Firefox extensively on my 3 FreeBSD desktop machines (home, work and laptop) and have been looking forward to the Lightning port working with Thunderbird 3 for ages. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: problem with pidgin-2.7.0_1 installation
On 05/26/10 07:53, doug wrote: I have pidgin installed on two 8.0 systems: 1) FreeBSD 8.0-STABLE #0: Wed May 5 10:17:16 EDT 2010 - pidgin-2.6.6_1 2) FreeBSD 8.0-STABLE #0: Mon May 17 00:51:56 EDT 2010 - pidgin-2.7.0_1 Both the package and the build of pidgin-2.7.0_1 appear to install without any images. A diff of the package list show about 59 png files are not installed for 2.7. Copying the missing files to their appropriate places (in 2.6) did nothing so I assume the links are built in. I have a minimal installation of kde 3.5.10 staring with kdebase and then installing only what I needed/wanted. I wonder if a dependency not in the pidigin make file could be my problem? Seconded, latest pidgin compiled from ports doesn't seem to install various icon files. Symptom for me is visible in KDE 4.4.3 with the Pidgin system tray icon being shown as a red cross i.e. required icon file is missing and KDE is replacing it with a placeholder. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
virtualbox-ose-3.1.6_2 font issue with X forwarding
Hi all, I installed Virtual Box 3.1.6 from yesterday's ports tree on my amd64 8-STABLE home server. Everything went fine, but when I X forwarded VirtualBox to my desktop PC, the fonts were completely broken, and all the places where characters should have been were small boxes. After installing the same port on my desktop and finding that it worked just fine, I suspected a lack of fonts installed on the server. Sure enough, installing the x11-fonts/xorg-fonts meta package resolved the issue and now it looks great. Might I suggest adding a dependency on x11-fonts/xorg-fonts or one of its appropriate children packages? People that want to X forward from a headless machine that doesn't have a full X.org install would be grateful! My sincere thanks go to those responsible for getting Virtual Box working on FreeBSD - I'm very much looking forward to taking it for a spin in the coming days. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster -x not working?
Lawrence Stewart wrote:
Frederique Rijsdijk wrote:
Lawrence Stewart wrote:
Hijacking the thread slightly, but is there a way to exclude multiple
ports using the -x switch (or multiple -x switches)? Logically, I want
to be able to do something like this:
portmaster -a -x '*foo*' -x '*bar*'
portmaster -x '[.*php5.*|.*apache.*]' -n drupal6-6.12
That seems to work for me..
Nifty, although regex goo is unfriendly even at the best of times.
Thanks for the tip (and sorry for the hijack).
Today, I again had need of the ability to exclude multiple ports from an
update run. It turns out your tip doesn't work with portmaster, though I
suspect it would with portupgrade.
I finally bit the bullet and created a patch that allows a user to
specify -x multiple times, or specify it once with a space-separated
list of port globs.
Example usage with the patch applied:
Update everything, ignoring ports that match *postgres*:
portmaster -adx 'postgres'
Update everything, ignoring ports that match *postgres* or *imap-uw*:
portmaster -adx 'postgres imap-uw'
portmaster -adx 'postgres' -x 'imap-uw'
Doug, what do you think of the attached patch?
Cheers,
Lawrence
--- portmaster.orig 2009-08-08 22:13:01.0 +1000
+++ portmaster 2009-08-09 04:24:34.0 +1000
@@ -618,17 +618,21 @@
}
globstrip () {
+ local glob
+ local globs
local in
- in=$1
+ globs=$1
- case $in in
- *\*) in=`echo $in | sed s/.$//`
- esac
-
- in=${in%\\}
+ for glob in $globs
+ do
+ case $glob in
+ *\*) glob=`echo $glob | sed s/.$//`
+ esac
+ in=${glob%\\} $in
+ done
- echo $in
+ echo ${in%% }
}
#=== End functions relevant to --features and main ===
@@ -801,7 +805,7 @@
u) echo === The -u option has been deprecated ; echo '' ;;
v) PM_VERBOSE=vopt; ARGS=-v $ARGS ;;
w) SAVE_SHARED=wopt; ARGS=-w $ARGS ;;
- x) EXCL=`globstrip $OPTARG` ;;
+ x) EXCL=`globstrip $OPTARG` ${EXCL} ; EXCL=${EXCL%% } ;;
*) echo '' ; echo === Try ${0##*/} --help; exit 1 ;;
esac
done
@@ -818,7 +822,7 @@
if [ -n $EXCL ]; then
case $EXCL in
-*) fail 'The -x option requires an argument' ;;
- *) ARGS=-x $EXCL $ARGS ;;
+ *) ARGS=-x '$EXCL' $ARGS ;;
esac
fi
@@ -1461,16 +1465,21 @@
}
check_exclude () {
+ local glob
+
[ -n $EXCL ] || return 0
- case $1 in
- *${EXCL}*)
- if [ -n $PM_VERBOSE ]; then
- echo === Skipping $1
- echobecause it matches the pattern: *${EXCL}*
- fi
- return 1 ;;
- esac
+ for glob in $EXCL
+ do
+ case $1 in
+ *$glob*)
+ if [ -n $PM_VERBOSE ]; then
+ echo === Skipping $1
+ echobecause it matches the pattern:
*$glob*
+ fi
+ return 1 ;;
+ esac
+ done
return 0
}
@@ -1509,7 +1518,7 @@
[ -n $DEPTH ] echo$DEPTH ${1#$pd/}
if [ -z $NO_ACTION -o -n $CONFIG_ONLY ]; then
- ($0 $ARGS $1) || fail Update for $1 failed
+ (eval $0 $ARGS $1) || fail Update for $1 failed
. $IPC_SAVE
else
[ -n $PM_VERBOSE ]
@@ -1701,7 +1710,7 @@
if [ -n $CONFIG_ONLY ]; then
for port in $worklist; do
check_interactive $port || continue
- ($0 $ARGS $port) || fail Update for $port failed
+ (eval $0 $ARGS $port) || fail Update for $port failed
. $IPC_SAVE
done
check_fetch_only
@@ -1721,7 +1730,7 @@
;;
esac
check_interactive $port || continue
- ($0 $ARGS $port) || fail Update for $port failed
+ (eval $0 $ARGS $port) || fail Update for $port failed
. $IPC_SAVE
done
safe_exit
@@ -1968,7 +1977,7 @@
[ -d $pd/$moved_npd ] || no_valid_port
if [ $$ -eq $PARENT_PID ]; then
- $0 $ARGS -o $moved_npd $upg_port
+ eval $0 $ARGS -o $moved_npd $upg_port
safe_exit
else
exec $0 $ARGS -o $moved_npd $upg_port
--- portmaster.8.orig 2009-08-09 04:28:51.0 +1000
+++ portmaster.82009-08-09 04:36:49.0 +1000
@@ -24,7 +24,7 @@
.\
.\ $FreeBSD: ports/ports-mgmt/portmaster/files/portmaster.8,v 2.8 2009/07/29
23:26:14 dougb Exp $
.\
-.Dd July 29, 2009
+.Dd August 8, 2009
.Dt PORTMASTER 8
.Os
.Sh NAME
@@ -296,7 +296,9 @@
any arguments to supply to
.Xr make 1
.It Fl x
-avoid building or updating ports that match
Re: portmaster -x not working?
Doug Barton wrote: Lawrence Stewart wrote: Today, I again had need of the ability to exclude multiple ports from an update run. It turns out your tip doesn't work with portmaster, though I suspect it would with portupgrade. For now, if you need to exclude more than one port you can check the man page about +IGNOREME files. Ok cool. I would definitely like to be able to specify things dynamically on a per-run basis as well though without adding +IGNOREME files. I often want to special case the exclusion of ports one time only. Doug, what do you think of the attached patch? I think it's interesting, but not quite how I would do it. I have plans to rewrite the command line parser in order to accommodate this, and make things easier to work with generally, so stay tuned. No problemo, will stay tuned. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster -x not working?
Frederique Rijsdijk wrote: Lawrence Stewart wrote: Hijacking the thread slightly, but is there a way to exclude multiple ports using the -x switch (or multiple -x switches)? Logically, I want to be able to do something like this: portmaster -a -x '*foo*' -x '*bar*' portmaster -x '[.*php5.*|.*apache.*]' -n drupal6-6.12 That seems to work for me.. Nifty, although regex goo is unfriendly even at the best of times. Thanks for the tip (and sorry for the hijack). Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster -x not working?
Frederique Rijsdijk wrote: Hi, Miroslav Lachman wrote: Hi, I tried -x to exclude some port from recursive upgrade, but it seems not working. # portmaster -x mysql-client-* phpMyAdmin-3.1.5 Escape the asterix: portmaster -x mysql-client-\* phpMyAdmin-3.1.5 That should work. Hijacking the thread slightly, but is there a way to exclude multiple ports using the -x switch (or multiple -x switches)? Logically, I want to be able to do something like this: portmaster -a -x '*foo*' -x '*bar*' I so far haven't been able to figure out with casual prodding how to achieve the desired behaviour on the command line. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Temporary patch to fix USB in kdebase4
Hans Petter Selasky wrote: On Thursday 02 July 2009 16:52:49 Lawrence Stewart wrote: Hans Petter Selasky wrote: See attachment. --HPS Any chance you (or someone with the right clue) could update this patch to work with more recent 8-CURRENT? I get the following output when trying to compile kdebase4 (which applies your original patch as extra-patch-libusb20) on r195046 world/kernel: Scanning dependencies of target kcm_usb [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o In file included from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevi ces.h:20, Hi, It looks like you have two set of header files. Second, change the USB dev/ header files to: # include dev/usb/usb.h # include dev/usb/usbdi.h Else there are no further changes. ah ha, had forgotten to run make delete-old after last update. Thanks for the hint and thanks for the include fix. Trying it out now. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Temporary patch to fix USB in kdebase4
Hans Petter Selasky wrote: See attachment. --HPS Any chance you (or someone with the right clue) could update this patch to work with more recent 8-CURRENT? I get the following output when trying to compile kdebase4 (which applies your original patch as extra-patch-libusb20) on r195046 world/kernel: Scanning dependencies of target kcm_usb [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o In file included from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevices.h:20, from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/kcmusb.cpp:27: /usr/include/dev/usb/usb_revision.h:33: error: multiple definition of 'enum usb_dev_speed' /usr/include/dev/usb/usb.h:686: error: previous definition here /usr/include/dev/usb/usb_revision.h:34: error: conflicting declaration 'USB_SPEED_VARIABLE' /usr/include/dev/usb/usb.h:687: error: 'USB_SPEED_VARIABLE' has a previous declaration as 'usb_dev_speed USB_SPEED_VARIABLE' /usr/include/dev/usb/usb_revision.h:35: error: conflicting declaration 'USB_SPEED_LOW' /usr/include/dev/usb/usb.h:688: error: 'USB_SPEED_LOW' has a previous declaration as 'usb_dev_speed USB_SPEED_LOW' /usr/include/dev/usb/usb_revision.h:36: error: conflicting declaration 'USB_SPEED_FULL' /usr/include/dev/usb/usb.h:689: error: 'USB_SPEED_FULL' has a previous declaration as 'usb_dev_speed USB_SPEED_FULL' /usr/include/dev/usb/usb_revision.h:37: error: conflicting declaration 'USB_SPEED_HIGH' /usr/include/dev/usb/usb.h:690: error: 'USB_SPEED_HIGH' has a previous declaration as 'usb_dev_speed USB_SPEED_HIGH' /usr/include/dev/usb/usb_revision.h:38: error: conflicting declaration 'USB_SPEED_SUPER' /usr/include/dev/usb/usb.h:691: error: 'USB_SPEED_SUPER' has a previous declaration as 'usb_dev_speed USB_SPEED_SUPER' /usr/include/dev/usb/usb_revision.h:45: error: multiple definition of 'enum usb_revision' /usr/include/dev/usb/usb.h:698: error: previous definition here /usr/include/dev/usb/usb_revision.h:46: error: conflicting declaration 'USB_REV_UNKNOWN' /usr/include/dev/usb/usb.h:699: error: 'USB_REV_UNKNOWN' has a previous declaration as 'usb_revision USB_REV_UNKNOWN' /usr/include/dev/usb/usb_revision.h:47: error: conflicting declaration 'USB_REV_PRE_1_0' /usr/include/dev/usb/usb.h:700: error: 'USB_REV_PRE_1_0' has a previous declaration as 'usb_revision USB_REV_PRE_1_0' /usr/include/dev/usb/usb_revision.h:48: error: conflicting declaration 'USB_REV_1_0' /usr/include/dev/usb/usb.h:701: error: 'USB_REV_1_0' has a previous declaration as 'usb_revision USB_REV_1_0' /usr/include/dev/usb/usb_revision.h:49: error: conflicting declaration 'USB_REV_1_1' /usr/include/dev/usb/usb.h:702: error: 'USB_REV_1_1' has a previous declaration as 'usb_revision USB_REV_1_1' /usr/include/dev/usb/usb_revision.h:50: error: conflicting declaration 'USB_REV_2_0' /usr/include/dev/usb/usb.h:703: error: 'USB_REV_2_0' has a previous declaration as 'usb_revision USB_REV_2_0' /usr/include/dev/usb/usb_revision.h:51: error: conflicting declaration 'USB_REV_2_5' /usr/include/dev/usb/usb.h:704: error: 'USB_REV_2_5' has a previous declaration as 'usb_revision USB_REV_2_5' /usr/include/dev/usb/usb_revision.h:52: error: conflicting declaration 'USB_REV_3_0' /usr/include/dev/usb/usb.h:705: error: 'USB_REV_3_0' has a previous declaration as 'usb_revision USB_REV_3_0' /usr/include/dev/usb/usb_revision.h:59: error: multiple definition of 'enum usb_hc_mode' /usr/include/dev/usb/usb.h:712: error: previous definition here /usr/include/dev/usb/usb_revision.h:60: error: conflicting declaration 'USB_MODE_HOST' /usr/include/dev/usb/usb.h:713: error: 'USB_MODE_HOST' has a previous declaration as 'usb_hc_mode USB_MODE_HOST' /usr/include/dev/usb/usb_revision.h:61: error: conflicting declaration 'USB_MODE_DEVICE' /usr/include/dev/usb/usb.h:714: error: 'USB_MODE_DEVICE' has a previous declaration as 'usb_hc_mode USB_MODE_DEVICE' /usr/include/dev/usb/usb_revision.h:62: error: conflicting declaration 'USB_MODE_DUAL' /usr/include/dev/usb/usb.h:715: error: 'USB_MODE_DUAL' has a previous declaration as 'usb_hc_mode USB_MODE_DUAL' /usr/include/dev/usb/usb_revision.h:69: error: multiple definition of 'enum usb_dev_state' /usr/include/dev/usb/usb.h:722: error: previous definition here /usr/include/dev/usb/usb_revision.h:70: error: conflicting declaration 'USB_STATE_DETACHED' /usr/include/dev/usb/usb.h:723: error: 'USB_STATE_DETACHED' has a previous declaration as 'usb_dev_state USB_STATE_DETACHED' /usr/include/dev/usb/usb_revision.h:71: error: conflicting declaration 'USB_STATE_ATTACHED' /usr/include/dev/usb/usb.h:724: error: 'USB_STATE_ATTACHED' has a previous declaration as 'usb_dev_state USB_STATE_ATTACHED' /usr/include/dev/usb/usb_revision.h:72: error: conflicting declaration
Re: Temporary patch to fix USB in kdebase4
[trimmed CC list] Lawrence Stewart wrote: Hans Petter Selasky wrote: On Thursday 02 July 2009 16:52:49 Lawrence Stewart wrote: Hans Petter Selasky wrote: See attachment. --HPS Any chance you (or someone with the right clue) could update this patch to work with more recent 8-CURRENT? I get the following output when trying to compile kdebase4 (which applies your original patch as extra-patch-libusb20) on r195046 world/kernel: Scanning dependencies of target kcm_usb [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o In file included from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevi ces.h:20, Hi, It looks like you have two set of header files. Second, change the USB dev/ header files to: # include dev/usb/usb.h # include dev/usb/usbdi.h Else there are no further changes. ah ha, had forgotten to run make delete-old after last update. Thanks for the hint and thanks for the include fix. Trying it out now. FYI, Hans your suggestion didn't work. Jeremy's on the other hand did. By only including dev/usb/usb_ioctl.h the compile finishes without issue. I'm in the process of updating to today's current though and a lot of USB related changes were in the changeset so it's entirely possible running new kernel/world will make your comments valid. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Minor fix for KDE 4.2.2 Konsole text selection regression
Hi All,
The upgrade from KDE 4.2.1 to 4.2.2 introduced a small but annoying
regression into the Konsole app. Double click text selection no longer
works correctly.
The bug is documented here:
https://bugs.kde.org/show_bug.cgi?id=189651
The attached patch can be stuck in the files directory of the
x11/kdebase4 port to fix the issue until KDE ships an update.
Cheers,
Lawrence
Index: TerminalDisplay.cpp
===
--- ../apps/konsole/src/TerminalDisplay.cpp
(.../4.2.2/kdebase/apps/konsole/src/TerminalDisplay.cpp)(revision
959808)
+++ ../apps/konsole/src/TerminalDisplay.cpp
(.../4.2.1/kdebase/apps/konsole/src/TerminalDisplay.cpp)(revision
959808)
@@ -2172,12 +2155,11 @@
_wordSelectionMode = true;
// find word boundaries...
- QChar selClass = charClass(_image[i].character);
{
// find the start of the word
int x = bgnSel.x();
while ( ((x0) || (bgnSel.y()0 (_lineProperties[bgnSel.y()-1]
LINE_WRAPPED) ))
- charClass(_image[i-1].character) == selClass )
+ !isCharBoundary(_image[i-1].character) )
{
i--;
if (x0)
@@ -2196,7 +2178,7 @@
i = loc( endSel.x(), endSel.y() );
x = endSel.x();
while( ((x_usedColumns-1) || (endSel.y()_usedLines-1
(_lineProperties[endSel.y()] LINE_WRAPPED) ))
- charClass(_image[i+1].character) == selClass )
+ !isCharBoundary(_image[i+1].character) )
{
i++;
if (x_usedColumns-1)
@@ -2350,7 +2332,16 @@
return QWidget::focusNextPrevChild( next );
}
+// Returns true upon a word boundary
+// TODO determine if the below charClass() is actually required
+bool TerminalDisplay::isCharBoundary(QChar qch) const
+{
+if ( _wordCharacters.contains(qch, Qt::CaseInsensitive) ) return true;
+if ( qch.isSpace() ) return true;
+return false;
+}
+
QChar TerminalDisplay::charClass(QChar qch) const
{
if ( qch.isSpace() ) return ' ';
Index: TerminalDisplay.h
===
--- ../apps/konsole/src/TerminalDisplay.h
(.../4.2.2/kdebase/apps/konsole/src/TerminalDisplay.h) (revision 959808)
+++ ../apps/konsole/src/TerminalDisplay.h
(.../4.2.1/kdebase/apps/konsole/src/TerminalDisplay.h) (revision 959808)
@@ -566,6 +563,9 @@
// - Other characters (returns the input character)
QChar charClass(QChar ch) const;
+// Returns true upon a word boundary
+bool isCharBoundary(QChar ch) const;
+
void clearImage();
void mouseTripleClickEvent(QMouseEvent* ev);
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[PATCH] pilot-link port (as dependency of kdepim-4.2.1) broken by new usb
Hi,
You're listed as the maintainer for the FreeBSD palm/pilot-link port. It
gets pulled in as a dependency of libmal, which in turn is required by
kdepim-4.2.1. On FreeBSD 8-CURRENT, the new USB stack has broken the
build of this port. The attached patch allows the port to compile. The
patch is only required if ${OSVERSION} = 800064.
I tested on 8.0-CURRENT (r190457) amd64.
Cheers,
Lawrence
--- libpisock/freebsdusb.c.orig 2006-10-13 00:21:22.0 +1000
+++ libpisock/freebsdusb.c 2009-03-27 22:37:32.0 +1100
@@ -48,7 +48,7 @@
#if defined(__FreeBSD__)
/* freebsd usb header */
-#include dev/usb/usb.h
+#include dev/usb/usb_ioctl.h
#define MAX_BUF 256
#endif
@@ -98,7 +98,7 @@
i,
endpoint_fd;
- struct usb_device_info udi;
+ struct usb2_device_descriptor udi;
/* struct usb_ctl_request ur; */
/* unsigned char usbresponse[50]; */
@@ -173,18 +173,18 @@
will don't know exactly
what is coming so we can't specify exact byte amounts */
i = 1;
- if (ioctl(endpoint_fd, USB_SET_SHORT_XFER, i) 0) {
+ if (ioctl(endpoint_fd, USB_SET_RX_SHORT_XFER, i) 0) {
LOG((PI_DBG_DEV, PI_DBG_LVL_WARN,
-DEV USB_SET_SHORT_XFER USB FreeBSD fd: %d failed\n,
+DEV USB_SET_RX_SHORT_XFER USB FreeBSD fd: %d failed\n,
endpoint_fd));
}
/* 0 timeout value will cause us the wait until the device has data
available or is disconnected */
i = 0;
- if (ioctl(endpoint_fd, USB_SET_TIMEOUT, i) 0) {
+ if (ioctl(endpoint_fd, USB_SET_RX_TIMEOUT, i) 0) {
LOG((PI_DBG_DEV, PI_DBG_LVL_WARN,
-DEV USB_SET_TIMEOUT USB FreeBSD fd: %d failed\n,
+DEV USB_SET_RX_TIMEOUT USB FreeBSD fd: %d failed\n,
endpoint_fd));
}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[PATCH] trafshow port broken
Hi Alexey,
You're listed as the maintainer for the FreeBSD net/trafshow port. The
port doesn't compile on 8.0-CURRENT (r190457) amd64 at the moment. The
recent import of the new pcap into FreeBSD 8 means pcap.h no longer
includes the system's net/bpf.h, which has a required #define ioctl
(BIOCIMMEDIATE). Placing the attached patch in the port's files
directory fixes the issue for me. The patch should only be required for
${OSVERSION} = 800074.
Rui, is patching the port the correct fix for this issue?
Cheers,
Lawrence
--- show_dump.c.orig2009-03-28 10:33:29.0 +1100
+++ show_dump.c 2009-03-28 10:28:44.0 +1100
@@ -30,6 +30,7 @@
#include string.h
#include unistd.h
#include errno.h
+#include net/bpf.h
#include pcap.h
#include pthread.h
#include time.h
--- trafshow.c.orig 2009-03-28 10:33:50.0 +1100
+++ trafshow.c 2009-03-28 10:27:52.0 +1100
@@ -30,6 +30,7 @@
#include string.h
#include unistd.h
#include time.h
+#include net/bpf.h
#include pcap.h
#include pthread.h
#include errno.h
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [PATCH] trafshow port broken
Rui Paulo wrote:
On 27 Mar 2009, at 23:56, Lawrence Stewart wrote:
Hi Alexey,
You're listed as the maintainer for the FreeBSD net/trafshow port. The
port doesn't compile on 8.0-CURRENT (r190457) amd64 at the moment. The
recent import of the new pcap into FreeBSD 8 means pcap.h no longer
includes the system's net/bpf.h, which has a required #define ioctl
(BIOCIMMEDIATE). Placing the attached patch in the port's files
directory fixes the issue for me. The patch should only be required
for ${OSVERSION} = 800074.
Rui, is patching the port the correct fix for this issue?
I think so. Hard to tell without looking at the program itself.
Ok cool. Just wanted to check that this wasn't *unexpected* fallout from
the recent pcap import and that a conscious decision has been made to
not include the system's bpf.h in pcap.h. Probably worth keeping an eye
out on the ports build cluster for any other ports that look like
they're failing to build because of bpf.h issues.
Cheers,
Lawrence
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Minor fix for KDE 4 monitor screen saver/power save nit
Hi All,
KDE 4.1.4 (and I believe KDE 4.2.0) has an issue with krunner that stops
the monitor from dropping into power save mode if the screen saver kicks
in before the power save timeout. This bugged me sufficiently to find a
fix, so thought I'd share this in case this issue is bugging anyone else.
The relevant KDE bug report is here:
http://bugs.kde.org/show_bug.cgi?id=165265
I've backported the fix from the 4.2 tree for KDE 4.1.4. Stick the
attached patch in /usr/ports/x11/kdebase4-workspace/files and
rebuild/reinstall the port.
For KDE 4.2.0, the patch obtained by running:
svn diff -c916964 svn://anonsvn.kde.org/home/kde/branches/KDE/4.2/kdebase
should work with some minor tweaks to the patch meta data. Same
procedure applies as for 4.1.4.
I've confirmed the attached patch resolves the issue for 4.1.4.
Cheers,
Lawrence
Index: ../krunner/lock/lockprocess.cc
===
--- ../krunner/lock/lockprocess.cc.orig (revision 916963)
+++ ../krunner/lock/lockprocess.cc (revision 916964)
@@ -1104,7 +1104,6 @@
return; // no resuming with dialog visible or when not visible
if( mSuspended mHackProc.state() == QProcess::Running )
{
-XForceScreenSaver(QX11Info::display(), ScreenSaverReset );
QPainter p( this );
p.drawPixmap( 0, 0, mSavedScreen );
p.end();
Index: ../krunner/xautolock.cpp
===
--- ../krunner/xautolock.cpp.orig 2008-08-28 18:07:00.0 +1000
+++ ../krunner/xautolock.cpp2009-02-06 17:05:19.0 +1100
@@ -83,8 +83,10 @@
mActive = false;
mTimerId = startTimer( CHECK_INTERVAL );
+// This is an internal clock timer (in seconds), used instead of querying
system time.
+// It is incremented manually, preventing from problems with clock jumps.
+// In other words, this is the 'now' time and the reference point for
other times here.
mElapsed = 0;
-
}
//---
@@ -126,8 +128,6 @@
{
mActive = true;
resetTrigger();
-XSetScreenSaver(QX11Info::display(), mTimeout + 10, 100, PreferBlanking,
DontAllowExposures); // We'll handle blanking
-kDebug() XSetScreenSaver mTimeout + 10;
}
//---
@@ -138,8 +138,6 @@
{
mActive = false;
resetTrigger();
-XSetScreenSaver(QX11Info::display(), 0, 100, PreferBlanking,
DontAllowExposures); // No blanking at all
-kDebug() XSetScreenSaver 0;
}
//---
@@ -148,12 +146,15 @@
//
void XAutoLock::resetTrigger()
{
+// Time of the last user activity (used only when the internal XScreensaver
+// idle counter is not available).
mLastReset = mElapsed;
+// Time when screensaver should be activated.
mTrigger = mElapsed + mTimeout;
#ifdef HAVE_XSCREENSAVER
xautolock_lastIdleTime = 0;
#endif
-XForceScreenSaver( QX11Info::display(), ScreenSaverReset );
+// Do not reset the internal X screensaver here (no XForceScreenSaver())
}
//---
@@ -205,12 +206,11 @@
bool activate = false;
-// kDebug() now mTrigger;
+// This is the test whether to activate screensaver. If we have reached
the time
+// and for the whole timeout period there was no activity (which would
change mTrigger
+// again), activate.
if (mElapsed = mTrigger)
-{
-resetTrigger();
activate = true;
-}
#ifdef HAVE_DPMS
BOOL on;
@@ -222,6 +222,8 @@
// that is always smaller than DPMS timeout (X bug I guess). So if DPMS
// saving is active, simply always activate our saving too, otherwise
// this could prevent locking from working.
+// X.Org 7.4: With this version activating DPMS resets the screensaver
idle timer,
+// so keep this. It probably makes sense to always do this anyway.
if(state == DPMSModeStandby || state == DPMSModeSuspend || state ==
DPMSModeOff)
activate = true;
if(!on mDPMS) {
Index: ../krunner/saverengine.cpp
===
--- ../krunner/saverengine.cpp.orig (revision 916963)
+++ ../krunner/saverengine.cpp (revision 916964)
@@ -46,7 +46,11 @@
// Save X screensaver parameters
XGetScreenSaver(QX11Info::display(), mXTimeout, mXInterval,
mXBlanking, mXExposures);
-// ... and disable it
+// And disable it. The internal X screensaver is not used at all, but we
use its
+// internal idle timer (and it is also used by DPMS support in X). This
timer must not
+// be altered by this code, since e.g. resetting the counter after
activating our
+// screensaver would prevent DPMS from activating. We use the timer merely
Re: [: -le: argument expected
Hi Chris, Firstly, a disclaimer: I'm not an expert so I might be behind the times on what I'm about to tell you... Chris H. wrote: Hello all, System: FreeBSD 7.0-PRERELEASE i386 Wed Jan 16 18:39:53 PST 2008 Context: After several failed attempts to get a /stable/ installation of Apache13-ssl and friends built and installed from source (see thread: /usr/bin/objformat, for more background). I chose to look at the possibility of using Apache 2.0. I was reluctant, as doing so would require migrating ~50 carefully crafted conf files which have evolved over many yrs. to be now seemingly impervious to abuse, or attack. I hadn't intended this server to become a guinea pig, but my ill fated attempts to install a stable copy of www/apache13-ssl from source necessitated increasing the resources on the other servers. So as to experiment on this one. To the point! Building Apache 2.0 on this box requied cvsupping src/ports (2008-01-30). As the version of Apache 2.0 was 2.0.61 (has 2 security related issues). Current version: 2.0.63. Building/installing this version went w/o trouble. Ran as expected. I only made 1 mod from the default config/build: WITH_MPM?= threadpool. The original was: WITH_MPM?= prefork. My diong so also required: KQUEUE. Other than that, all was as-was. [snip] Regardless of the errors you reported, I believe changing the MPM is a problem. Last time I tried Apache with the threaded worker MPM it worked flawlessly. However PHP has issues because it isn't thread safe. The only safe way to run the 2 together was to set the Apache MPM back to the default (prefork). Taking my disclaimer into account, I possibly just didn't figure out how to make the 2 play nice, so I'd welcome info/pointers from others who have managed to get threaded apache and PHP working together. Assuming no one pipes up and explains how to work around the PHP threading issues, I'd recommend rebuilding apache with the default MPM (shouldn't require any make variables defined). Verify it works ok once installed and then try get PHP working again. I would also echo the recommendation of others to jump straight to Apache 2.2(.8) if you're going to make a disruptive switch now anyways. I have a personal step-by-step build guide for getting Apache 2.2 and PHP5 working together if you're interested. As to your reported errors, I can't really shed any light on them, sorry. Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [: -le: argument expected
Hi Chris, Chris H. wrote: Hello, and thank you for your reply. Quoting Lawrence Stewart [EMAIL PROTECTED]: Hi Chris, Firstly, a disclaimer: I'm not an expert so I might be behind the times on what I'm about to tell you... Note taken. :) Chris H. wrote: Hello all, System: FreeBSD 7.0-PRERELEASE i386 Wed Jan 16 18:39:53 PST 2008 Context: After several failed attempts to get a /stable/ installation of Apache13-ssl and friends built and installed from source (see thread: /usr/bin/objformat, for more background). I chose to look at the possibility of using Apache 2.0. I was reluctant, as doing so would require migrating ~50 carefully crafted conf files which have evolved over many yrs. to be now seemingly impervious to abuse, or attack. I hadn't intended this server to become a guinea pig, but my ill fated attempts to install a stable copy of www/apache13-ssl from source necessitated increasing the resources on the other servers. So as to experiment on this one. To the point! Building Apache 2.0 on this box requied cvsupping src/ports (2008-01-30). As the version of Apache 2.0 was 2.0.61 (has 2 security related issues). Current version: 2.0.63. Building/installing this version went w/o trouble. Ran as expected. I only made 1 mod from the default config/build: WITH_MPM?= threadpool. The original was: WITH_MPM?= prefork. My diong so also required: KQUEUE. Other than that, all was as-was. [snip] Regardless of the errors you reported, I believe changing the MPM is a problem. Last time I tried Apache with the threaded worker MPM it worked flawlessly. However PHP has issues because it isn't thread safe. The only safe way to run the 2 together was to set the Apache MPM back to the default (prefork). While I appreciate your insight regarding php5 not being thread safe. I would argue that I am not seeing php5 using anthing regarding my Apache 2.0 build, except to ask whether it is 1.3 || 2. So, while you may be /absolutely/ correct about php5 not running well/at all with a threaded Apache. I'm still stumped as to why php5 refuses to build, and emits what appears to be errors in the php5 configure/make files. Point being; if I can get php5 to build/install. I might be able to make it play nice with a threaded Apache; and that would make /everyone/ happy. :) It does smell of a problem related with another port... Perhaps you just need to do some portupgrading? That said, with problems like this, I just reckon that it's best to start simple i.e. setup apache in the known good way (prefork mpm) and then get php working. Once you're convinced that all plays nice, then upgrade apache to use worker MPM and see what breaks (if anything). You're more likely to get useful help from people if you only change one variable at a time as it were. Taking my disclaimer into account, I possibly just didn't figure out how to make the 2 play nice, so I'd welcome info/pointers from others who have managed to get threaded apache and PHP working together. Assuming no one pipes up and explains how to work around the PHP threading issues, I'd recommend rebuilding apache with the default MPM (shouldn't require any make variables defined). Verify it works ok once installed and then try get PHP working again. I may try that. But I'm at a loss as to what that has to do with getting php5 to build. As (mentioned earlier) I am unable to find where php5 does anything more that to ask if I'm using Apache 1.3 || 2. As am I. But the cvsup of the ports tree has possibly required php to use a new dependency on a newer version of autoconf or some other pkg. Installing the ports-mgmt/portupgrade port and running portupgrade -Rrf php5 will take all the hard work out of ensuring all your packages required by PHP are up to date. I would also echo the recommendation of others to jump straight to Apache 2.2(.8) if you're going to make a disruptive switch now anyways. I have a personal step-by-step build guide for getting Apache 2.2 and PHP5 working together if you're interested. Not going to happen - in the near future anyway. It's not unlike asking an Athiest to become a Jew. While it may be possible for one to make the change. It's a quantum leap. I've recently elaborated on this already. So I'll not repeat myself here. :) The other messages in the thread hadn't arrived at my mail client before I said this... sorry for flogging the dead horse a little more (but I guess I suspected the effort to go from 1.3-2.0 is effectively identical to 1.3-2.2, but that is a guess). Cheers, Lawrence ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
