Re: Postfix and SASL compilation problem
Hi
I'll test it probably today / tomorrow, and let you know later.
Regards,
Jan
On Tue, Sep 25, 2012 at 3:57 AM, Sahil Tandon
sahil+freebsd-po...@tandon.net wrote:
On Wed, 2012-09-12 at 12:36:47 +0200, Ján Šebošík wrote:
while I was trying to build ports/mail/postfix, the problem occured
in file ./work/postfix-2.9.4/src/global/dict_ldap.c.
Line 232 in postfix-2.9.4/src/global/dict_ldap.c doesn't contain
proper path to sasl.h header file on FreeBSD.
Fixed line should look like this: #include sasl/sasl.h
Here is the patch:
###
--- dict_ldap.c.old 2012-09-11 00:39:40.0 +0200
+++ dict_ldap.c 2012-09-11 00:22:56.0 +0200
@@ -229,7 +229,7 @@
/*
* SASL headers, for sasl_interact_t. Either SASL v1 or v2 should be fine.
*/
-#include sasl.h
+#include sasl/sasl.h
#endif
Rather, the idiomatic approach is to add ${LOCALBASE}/include/sasl to
the preprocessor's include path. This is done when WITH_SASL2 is
defined. Does that produce undesirable results in your environment?
PS: sorry for the delayed reply; I hope to be quicker in response to
any follow-ups.
--
Sahil Tandon
--
Bc. Ján Šebošík
technické oddelenie
ITM8 - www.itm8.sk
tel: 00421 903 469259
mail: sebo...@itm8.sk
___
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
Apache22 SUEXEC OptionsNG
Hi. I'm trying to update my apache22 installation, but it keeps whinging about having to use OptionsNG instead of the old options, which is fair enough. Unfortunately I can't find how to set the options I need to set for SUEXEC. Previously I had SUEXEC_GIDMIN, SUEXE_UIDMIN and most importantly SUEXEC_DOCROOT set, but from what I can see furtling through the Makefile, all that there seems to be now is MSUEXEC_RSRCLIMIT and MSUEXEC_USERDIR. If anyone can tell me how I can configure SUEXEC using OptionsNG I'd be very grateful. Regards, Neal.___ 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: [BRAINSTORMIG] name of the variable for passing command line options via make
On 2012-Sep-25, 00:15, Baptiste Daroussin wrote: Hi, One of the missing thing since we switch to OptionNG is a reliable ability to pass options via command line that would override make.conf and config file options. Here is an implementation that do work: http://people.freebsd.org/~bapt/OVERRIDE_BLA.diff Now OVERRIDE_SET/UNSET doesn't seems to be the best name :) http://www.freebsd.org/cgi/query-pr.cgi?pr=170180 Here are other proposition from me: LATE_SET/UNSET CMD_SET/UNSET WITH / WITHOUT -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgp324gvT9ZY5.pgp Description: PGP signature
Re: [BRAINSTORMIG] name of the variable for passing command line options via make
[ Pietro Cerutti wrote on Tue 25.Sep'12 at 13:41:41 +0200 ] On 2012-Sep-25, 00:15, Baptiste Daroussin wrote: Hi, One of the missing thing since we switch to OptionNG is a reliable ability to pass options via command line that would override make.conf and config file options. Here is an implementation that do work: http://people.freebsd.org/~bapt/OVERRIDE_BLA.diff Now OVERRIDE_SET/UNSET doesn't seems to be the best name :) http://www.freebsd.org/cgi/query-pr.cgi?pr=170180 Here are other proposition from me: LATE_SET/UNSET CMD_SET/UNSET WITH / WITHOUT SET_OPT / UNSET_OPT ___ 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: [BRAINSTORMIG] name of the variable for passing command line options via make
On 25 Sep 2012 12:42, Pietro Cerutti g...@freebsd.org wrote: On 2012-Sep-25, 00:15, Baptiste Daroussin wrote: Hi, One of the missing thing since we switch to OptionNG is a reliable ability to pass options via command line that would override make.conf and config file options. Here is an implementation that do work: http://people.freebsd.org/~bapt/OVERRIDE_BLA.diff Now OVERRIDE_SET/UNSET doesn't seems to be the best name :) http://www.freebsd.org/cgi/query-pr.cgi?pr=170180 Here are other proposition from me: LATE_SET/UNSET CMD_SET/UNSET WITH / WITHOUT I thought this was a joke, but thinking about it, this is the best idea IMO. Chris ___ 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: [devel/newfile] - Problem with patch.
Hi, 2012/9/25 Rafał Szkodziński u...@atnus.com: Hi. When I upgrade the port devel/newfile, I get the following problem: [cut] === The following actions will be taken if you choose to proceed: Upgrade newfile-1.0.14_2 to newfile-1.0.14_3 === Proceed? y/n [y] === Starting build for ports that need updating === === Launching child to install devel/newfile === All devel/newfile (1/1) === Currently installed version: newfile-1.0.14_2 === Port directory: /usr/ports/devel/newfile === Starting check for build dependencies === Gathering dependency list for devel/newfile from ports === Dependency check complete for devel/newfile === All newfile-1.0.14_2 (1/1) === Cleaning for newfile-1.0.14_3 === Extracting for newfile-1.0.14_3 = SHA256 Checksum OK for newfile-1.0.14.tar.gz. === newfile-1.0.14_3 depends on file: /usr/local/bin/ruby18 - found === Patching for newfile-1.0.14_3 === newfile-1.0.14_3 depends on file: /usr/local/bin/ruby18 - found === Applying FreeBSD patches for newfile-1.0.14_3 1 out of 2 hunks failed--saving rejects to data/projects/p...@makefile.rej = Patch patch-data_projects_port_Makefile failed to apply cleanly. *** [do-patch] Error code 1 Stop in /usr/ports/devel/newfile. === make failed for devel/newfile === Aborting update === Update for devel/newfile failed === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags devel/newfile root@atnus:/root # [/cut] I add a file p...@makefile.rej [cut] uid@atnus:~ uname -a FreeBSD atnus.com 9.1-RC1 FreeBSD 9.1-RC1 #0: Fri Sep 21 16:17:42 CEST 2012 r...@atnus.com:/usr/obj/usr/src/sys/ATNUS i386 [/cut] -- Pozdrowienia, Rafał Szkodziński ___ 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 Did you install and update ports tree via portsnap? This problem is caused by the SVN to CVS exporter. Please consider using svn instead of portsnap to update ports tree. See also http://docs.freebsd.org/cgi/mid.cgi?87zk4fnng6.fsf and http://docs.freebsd.org/cgi/mid.cgi?D7122959-18EF-4BFA-90B2-D40D83287F63 . Thanks, -- TAKATSU Tomonari ___ 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
lang/icon: Port does not respect USE_GCC=4.6+ override and stops building duet to BROKEN flag
If someone overrides the default system compiler which is in my case
CLANG 3.2 (on FreeBSD 10.0-CURRENT #1 r240885M: Mon Sep 24 12:30:44
CEST 2012 amd64), the if-statement does always take place and prevents
lang/icon to be build:
[...]
.if ${CC} == clang || ${CXX} == clang++
BROKEN=does not pass all tests when compiled with clang
.endif
[...]
In /etc/makefile.conf, I include an additional file located in
/usr/local/etc/ports.conf which contains statements like
# lang/icon
.if ${.CURDIR:M*/lang/icon}
USE_GCC=4.6+
#CC=cc
#CXX= c++
#CPP= cpp
.endif
I'd expect the build system system to have already setup CC, CPP and CXX
according to the specifications made in /etc/make.conf and the
overridings in my ports.conf file with USE_GCC=4.6+, but obviously
this doesn't happen.
I expect by setting USE_GCC=4.6 all the nasty stuff like -Wl,rpatch=,
CC,CXX,CPP et cetera is set for me and I do not have to take care of it.
How can this problem be solved?
I think this will become an issue when CLANG will be the default compiler.
oh
___
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
astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
I tried to build astro/xearth on redports using amd64/clang environment. I get several errors like this one: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter The full log: https://redports.org/~mexas/20120925084455-39349-73266/xearth-1.1_2.log It builds fine on amd64/gcc. It seems the problem is not in xearth, but rather in xorg-cf-files. Please advise Thanks Anton ___ 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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
On 2012-09-25 14:47, Anton Shterenlikht wrote: I tried to build astro/xearth on redports using amd64/clang environment. I get several errors like this one: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter The full log: https://redports.org/~mexas/20120925084455-39349-73266/xearth-1.1_2.log It builds fine on amd64/gcc. It seems the problem is not in xearth, but rather in xorg-cf-files. Please advise Thanks Anton The problem is with imake not playing nice with the cpp from clang. The best solution is to not use imake, but that's probably far from trivial to fix. Regards! -- ___ 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: lang/icon: Port does not respect USE_GCC=4.6+ override and stops building duet to BROKEN flag
On Tue, Sep 25, 2012 at 02:42:23PM +0200, O. Hartmann wrote: If someone overrides the default system compiler which is in my case CLANG 3.2 (on FreeBSD 10.0-CURRENT #1 r240885M: Mon Sep 24 12:30:44 CEST 2012 amd64), the if-statement does always take place and prevents lang/icon to be build: Please, do not cross-post freebsd-port issues to freebsd-current. -- Steve ___ 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
Fwd: [Phpmyadmin-users] phpMyAdmin security alert (PMASA-2012-5)
Dear all, If you install phpMyAdmin from ports, you shouldn't be vulnerable to the security problem described in PMASA-2012-5: Firstly, the ports checks the SHA256 checksum of distributed tarballs, which should prevent this sort of tampering. Secondly, the distfile the port uses is phpMyAdmin-3.5.2.2-all-languages.tar.xz not the .zip -- and so far only the .zip is known to have been compromised. However, if you should see distfile checksum warnings when trying to install phpMyAdmin please do let me know about it, if possible including which sourceforge mirror you downloaded from and when. I hope it is needless to say this, but if the SHA256 checksum doesn't match then *don't install*. Cheers, Matthew Original Message Subject: [Phpmyadmin-users] phpMyAdmin security alert (PMASA-2012-5) Date: Tue, 25 Sep 2012 09:44:54 -0400 From: Marc Delisle m...@infomarc.info To: phpmyadmin-n...@lists.sf.net, phpmyadmin-us...@lists.sf.net, phpmyadmin-de...@lists.sf.net Hi, the PMASA-2012-5 security advisory has been published on http://www.phpmyadmin.net/home_page/security/PMASA-2012-5.php. In short, a SourceForge.net mirror server was compromised, leading to the distribution of a doctored phpMyAdmin kit containing a backdoor. phpMyAdmin-3.5.2.2-all-languages.zip fetched from this mirror server is known to be affected. To our knowledge only one mirror is affected, which appears to be taken offline already. All other SourceForge.net mirrors are unaffected. phpMyAdmin security team ___ 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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
From zeis...@daemonic.se Tue Sep 25 14:52:17 2012 On 2012-09-25 14:47, Anton Shterenlikht wrote: I tried to build astro/xearth on redports using amd64/clang environment. I get several errors like this one: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter The full log: https://redports.org/~mexas/20120925084455-39349-73266/xearth-1.1_2.log It builds fine on amd64/gcc. It seems the problem is not in xearth, but rather in xorg-cf-files. Please advise Thanks Anton The problem is with imake not playing nice with the cpp from clang. The best solution is to not use imake, but that's probably far from trivial to fix. $ grep -c imake /usr/ports/INDEX-10 291 This issue must cause problems for quite a few other ports. So is it an agreed policy to migrate away from imake in time for 10-release? This seems an important strategic issue to discuss. My port is relatively small, and I probably can, with time and help, migrate to BSD make, for example. Just don't want to do this, unless this is the majority opinion, and the likely direction for the future. Thanks Anton ___ 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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
On 2012-09-25 16:38, Anton Shterenlikht wrote: ... $ grep -c imake /usr/ports/INDEX-10 291 That's a relatively low number, indeed. :) This issue must cause problems for quite a few other ports. So is it an agreed policy to migrate away from imake in time for 10-release? Imake is obsolete, X.org migrated to autoconf+gmake a long time ago, and new software should avoid it. That said, for old software, you could just add a dependency on one of the gcc ports, or maybe use another C preprocessor that supports -traditional mode. I understood ucpp might be able to do the job. ___ 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: Fwd: [Phpmyadmin-users] phpMyAdmin security alert (PMASA-2012-5)
On 25 Sep 2012 15:37, Matthew Seaman matt...@freebsd.org wrote: Dear all, If you install phpMyAdmin from ports, you shouldn't be vulnerable to the security problem described in PMASA-2012-5: Firstly, the ports checks the SHA256 checksum of distributed tarballs, which should prevent this sort of tampering. Secondly, the distfile the port uses is phpMyAdmin-3.5.2.2-all-languages.tar.xz not the .zip -- and so far only the .zip is known to have been compromised. However, if you should see distfile checksum warnings when trying to install phpMyAdmin please do let me know about it, if possible including which sourceforge mirror you downloaded from and when. I hope it is needless to say this, but if the SHA256 checksum doesn't match then *don't install*. This is exactly the reason distinfo changes should be suspected and be accompanied by an explanation/diff. Thanks for sharing :) Chris ___ 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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
Dimitry Andric wrote at 17:09 +0200 on Sep 25, 2012: On 2012-09-25 16:38, Anton Shterenlikht wrote: ... $ grep -c imake /usr/ports/INDEX-10 291 That's a relatively low number, indeed. :) This issue must cause problems for quite a few other ports. So is it an agreed policy to migrate away from imake in time for 10-release? Imake is obsolete, X.org migrated to autoconf+gmake a long time ago, and new software should avoid it. That said, for old software, you could just add a dependency on one of the gcc ports, or maybe use another C preprocessor that supports -traditional mode. I understood ucpp might be able to do the job. You could also raise a discussion with the clang folks. If it's really legitimate preprocessor syntax, clang/cpp could be fixed perhaps. ___ 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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
On 25 Sep 2012 18:23, John Hein jh...@symmetricom.com wrote: Dimitry Andric wrote at 17:09 +0200 on Sep 25, 2012: On 2012-09-25 16:38, Anton Shterenlikht wrote: ... $ grep -c imake /usr/ports/INDEX-10 291 That's a relatively low number, indeed. :) This issue must cause problems for quite a few other ports. So is it an agreed policy to migrate away from imake in time for 10-release? Imake is obsolete, X.org migrated to autoconf+gmake a long time ago, and new software should avoid it. That said, for old software, you could just add a dependency on one of the gcc ports, or maybe use another C preprocessor that supports -traditional mode. I understood ucpp might be able to do the job. You could also raise a discussion with the clang folks. If it's really legitimate preprocessor syntax, clang/cpp could be fixed perhaps. Imake *really* hates clang. Although it can build with it, the resulting imake is broken. Fixing imake properly is the thing to do here. I'm happy to help anyone mad enough to try. Chris ___ 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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
On 2012-09-25 19:21, John Hein wrote: Dimitry Andric wrote at 17:09 +0200 on Sep 25, 2012: ... Imake is obsolete, X.org migrated to autoconf+gmake a long time ago, and new software should avoid it. That said, for old software, you could just add a dependency on one of the gcc ports, or maybe use another C preprocessor that supports -traditional mode. I understood ucpp might be able to do the job. You could also raise a discussion with the clang folks. If it's really legitimate preprocessor syntax, clang/cpp could be fixed perhaps. The problem is that Imake preprocessing depends on the -traditional option[1], which clang does not support, and it is very unlikely[2] that it will ever support it, unless there is huge demand, and somebody willing to implement and maintain it. -Dimitry [1] http://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html [2] http://llvm.org/bugs/show_bug.cgi?id=4557 ___ 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: Apache22 SUEXEC OptionsNG
On 2012-09-25 11:16, Neal Nelson wrote:
Hi.
I'm trying to update my apache22 installation, but it keeps whinging about
having to use OptionsNG instead of the old options, which is fair enough.
Unfortunately I can't find how to set the options I need to set for SUEXEC.
Previously I had SUEXEC_GIDMIN, SUEXE_UIDMIN and most importantly
SUEXEC_DOCROOT set, but from what I can see furtling through the Makefile,
all that there seems to be now is MSUEXEC_RSRCLIMIT and MSUEXEC_USERDIR.
If anyone can tell me how I can configure SUEXEC using OptionsNG I'd be very
grateful.
Regards,
Hi Nelson,
this should do the trick.
$ cat /etc/make.conf
.if ${.CURDIR:M*/www/apache*}
SUEXE_UIDMIN=$num
SUEXEC_GIDMIN=$num
SUEXEC_DOCROOT=/some/path
.endif
or on the command line
$ make SUEXEC_UIDMIN=$num SUEXEC_GIDMIN=$num SUEXEC_DOCROOT=/some/path
To see your configured values (from make.conf) use the -V parameter
$ make -V SUEXEC_UIDMIN -V SUEXEC_GIDMIN -V SUEXEC_DOCROOT
If you don't see any output run `make config' and make sure SUEXEC is selected.
--
Regards,
olli
___
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: [BRAINSTORMIG] name of the variable for passing command line options via make
On 2012-09-25 13:54, Chris Rees wrote: On 25 Sep 2012 12:42, Pietro Cerutti g...@freebsd.org wrote: On 2012-Sep-25, 00:15, Baptiste Daroussin wrote: Hi, One of the missing thing since we switch to OptionNG is a reliable ability to pass options via command line that would override make.conf and config file options. Here is an implementation that do work: http://people.freebsd.org/~bapt/OVERRIDE_BLA.diff Now OVERRIDE_SET/UNSET doesn't seems to be the best name :) http://www.freebsd.org/cgi/query-pr.cgi?pr=170180 Here are other proposition from me: LATE_SET/UNSET CMD_SET/UNSET WITH / WITHOUT I thought this was a joke, but thinking about it, this is the best idea IMO. I agree, but silently thinking OH NO! this brings us back to the discussions from a view months ago... If I understand correct the LATE_(UN)SET parameter can be used inside the port after including bsd.port.options.mk (where I really miss it) and CMD_(UN)SET from the command line. I'm fine with the naming if we can get them in, and as long we do not force the users to use OVERRIDE_SET/UNSET monsters on the command line. -- Regards, olli ___ 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: [devel/newfile] - Problem with patch.
on 25/09/2012 15:05 TAKATSU Tomonari said the following: Did you install and update ports tree via portsnap? This problem is caused by the SVN to CVS exporter. Please consider using svn instead of portsnap to update ports tree. This is a wrong advice. portsnap MUST be well supported. Whatever feeds should be fixed, probably there is no reason to feed portsnap via svn-cvs exported. See also http://docs.freebsd.org/cgi/mid.cgi?87zk4fnng6.fsf and http://docs.freebsd.org/cgi/mid.cgi?D7122959-18EF-4BFA-90B2-D40D83287F63 . -- Andriy Gapon ___ 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: [BRAINSTORMIG] name of the variable for passing command line options via make
On 25-09-2012 07:56, Matthew Seaman wrote: On 24/09/2012 23:15, Baptiste Daroussin wrote: Here is an implementation that do work: http://people.freebsd.org/~bapt/OVERRIDE_BLA.diff Now OVERRIDE_SET/UNSET doesn't seems to be the best name :) http://www.freebsd.org/cgi/query-pr.cgi?pr=170180 Here are other proposition from me: LATE_SET/UNSET CMD_SET/UNSET SETOPT and UNSETOPT ? As in: # cd /usr/ports/foo/bar # make SETOPT=THIS THAT UNSETOPT=THEOTHER install Since it is setting or unsetting options, and that expresses the user's wishes clearly and succinctly. I vote for this one, with WITH/WITHOUT as a good second one. René -- http://www.rene-ladan.nl:8080/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ 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] unbreak XDM build when clang set as base compiler
Hi all! This patch fixed the problem, when buildig xdm on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). unbreak_xdm_build_when_clang_set_as_CC.diff Description: Binary data ___ 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] unbreak imake build when clang set as base compiler
Hi all! This patch fixed the problem, when buildig imake on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). unbreak_imake_build_when_clang_set_as_CC.diff Description: Binary data ___ 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] unbreak gccmakedep build when clang set as base compiler
Hi all! This patch fixed the problem, when buildig gccmakedep (yeah, gcc...) on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). unbreak_gccmakedep_build_when_clang_set_as_CC.diff Description: Binary data ___ 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] unbreak imake build when clang set as base compiler
On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com wrote: Hi all! This patch fixed the problem, when buildig imake on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). (Picking a random message to reply to) Why not create PRs and CC the relevant parties? ___ 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] unbreak imake build when clang set as base compiler
On 25 September 2012 18:45, Garrett Cooper yaneg...@gmail.com wrote: On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com wrote: Hi all! This patch fixed the problem, when buildig imake on a machine where clang is the base the compiler (WITH_CLANG_IS_CC). (Picking a random message to reply to) Why not create PRs and CC the relevant parties? Yes, please do this. It helps us keep track of what's going on and not lose patches. :) -- Eitan Adler ___ 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] unbreak XDM build when clang set as base compiler
Oliver Pinter oliver.p...@gmail.com writes:
+# XXX unbreak build with clang as CC
+BUILD_DEPENDS+= ucpp:${PORTSDIR}/devel/ucpp
+RUN_DEPENDS+= ucpp:${PORTSDIR}/devel/ucpp
+CONFIGURE_ENV+= ac_cv_path_RAWCPP=ucpp -s
ucpp is even less compatible with GNU cpp:
- escaped newline is not recognized (Xreset, Xstartup)
- extra whitespace around expanded macro (Xresources, Xservers)
- apostrophe is treated differently (Xsession)
Another example is libX11 or ports/166373.
--- config/Xreset cpp47
+++ config/Xreset ucpp
@@ -1,4 +1,6 @@
#!/bin/sh
# Deregister a login. (Derived from TakeConsole as follows:)
#
-/usr/local/bin/sessreg -d -w /var/log/wtmp -u /var/run/utmp-x
/usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h $USER
+ /usr/local/bin /sessreg -d -w /var/log/wtmp -u /var/run/utmp
+-x /usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h $USER
+
--- config/Xresources cpp47
+++ config/Xresources ucpp
@@ -2,17 +2,17 @@ Xcursor.theme: whiteglass
-xlogin*login.translations: #override \
- CtrlKeyR: abort-display()\n\
- KeyF1: set-session-argument(failsafe) finish-field()\n\
- KeyDelete: delete-character()\n\
- KeyLeft: move-backward-character()\n\
- KeyRight: move-forward-character()\n\
- KeyHome: move-to-begining()\n\
- KeyEnd: move-to-end()\n\
- CtrlKeyKP_Enter: set-session-argument(failsafe) finish-field()\n\
- KeyKP_Enter: set-session-argument() finish-field()\n\
- CtrlKeyReturn: set-session-argument(failsafe) finish-field()\n\
+xlogin*login.translations: #override \
+ CtrlKeyR: abort-display() \n\
+ KeyF1: set-session-argument(failsafe) finish-field() \n\
+ KeyDelete: delete-character() \n\
+ KeyLeft: move-backward-character() \n\
+ KeyRight: move-forward-character() \n\
+ KeyHome: move-to-begining() \n\
+ KeyEnd: move-to-end() \n\
+ CtrlKeyKP_Enter: set-session-argument(failsafe) finish-field() \n\
+ KeyKP_Enter: set-session-argument() finish-field() \n\
+ CtrlKeyReturn: set-session-argument(failsafe) finish-field() \n\
KeyReturn: set-session-argument() finish-field()
xlogin*greeting: Welcome to CLIENTHOST
@@ -60,9 +60,9 @@ xlogin*hiColor: black
#endif
#if PLANES = 8
-xlogin*logoFileName: /usr/local/lib/X11/xdm/pixmaps/xorg.xpm
+xlogin*logoFileName: /usr/local/lib/X11/xdm/pixmaps / xorg.xpm
#else
-xlogin*logoFileName: /usr/local/lib/X11/xdm/pixmaps/xorg-bw.xpm
+xlogin*logoFileName: /usr/local/lib/X11/xdm/pixmaps / xorg-bw.xpm
#endif
xlogin*useShape: true
xlogin*logoPadding: 10
@@ -80,3 +80,4 @@ Chooser*label.font: *-new century schoo
Chooser*label.label: XDMCP Host Menu from CLIENTHOST
Chooser*list.font: -*-*-medium-r-normal-*-*-230-*-*-c-*-iso8859-1
Chooser*Command.font: *-new century schoolbook-bold-r-normal-*-180-*
+
--- config/Xservers cpp47
+++ config/Xservers ucpp
@@ -9,4 +9,5 @@
# look like:
# XTerminalName:0 foreign
#
-:0 local /usr/local/bin/X :0
+:0 local /usr/local/bin /X :0
+
--- config/Xsession cpp47
+++ config/Xsession ucpp
@@ -1,49 +0,0 @@
-#!/bin/sh
-#
-
-# redirect errors to a file in user's home directory if we can
-
-errfile=$HOME/.xsession-errors
-if ( umask 077 cp /dev/null $errfile 2 /dev/null )
-then
- exec $errfile 21
-else
-
- mktemp=/usr/bin/mktemp
- for errfile in ${TMPDIR-/tmp}/xses-$USER /tmp/xses-$USER
- do
- if ef=$( umask 077 $mktemp $errfile.XX 2 /dev/null)
- then
- exec $ef 21
- mv $ef $errfile 2 /dev/null
- break
- fi
- done
-fi
-
-case $# in
-1)
- case $1 in
- failsafe)
- exec /usr/local/bin/xterm -geometry 80x24-0-0
- ;;
- esac
-esac
-
-# The startup script is not intended to have arguments.
-
-startup=$HOME/.xsession
-resources=$HOME/.Xresources
-
-if [ -s $startup ]; then
- if [ -x $startup ]; then
- exec $startup
- else
- exec /bin/sh $startup
- fi
-else
- if [ -r $resources ]; then
- /usr/local/bin/xrdb -load $resources
- fi
- exec /usr/local/bin/xsm
-fi
--- config/Xstartup cpp47
+++ config/Xstartup ucpp
@@ -1,4 +1,6 @@
#!/bin/sh
# Register a login (derived from GiveConsole as follows:)
#
-exec /usr/local/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x
/usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h $USER
+exec /usr/local/bin /sessreg -a -w /var/log/wtmp -u /var/run/utmp
+-x /usr/local/lib/X11/xdm/Xservers -l $DISPLAY -h $USER
+
--- config/xdm cpp47
+++ config/xdm ucpp
@@ -9,20 +9,20 @@
-DisplayManager.authDir:/var/lib/xdm
-DisplayManager.errorLogFile: /var/log/xdm.log
-DisplayManager.pidFile:/var/run/xdm.pid
+DisplayManager.authDir: /var/lib/xdm
