Re: portsnap can't access portsnap[124].freebsd.org
On Sat, May 30, 2009 at 12:48 AM, Scott Bennett benn...@cs.niu.edu wrote: Can you paste the 'ANSWER SECTON' from: 'dig portsnap2.freebsd.org' Sure, but I'm curious to know why. The names all do resolve to A RRs, and pings to each by name did get echos back. Here it is, although I did terminate the domain name by habit. Surely portsnap must not be so silly as to pass unterminated names to the resolver. (Actually, I'm including the whole output, not just the answer section.) To make sure it wasn't a DNS problem (or DNS poisoning / hijacking). ;; ANSWER SECTION: portsnap2.freebsd.org. 3600 IN A 72.21.59.250 Same output for me.. -- Glen Barber ___ 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: portsnap can't access portsnap[124].freebsd.org
On Sat, 30 May 2009 05:32:39 -0400 Glen Barber glen.j.bar...@gmail.com wrote: On Sat, May 30, 2009 at 12:48 AM, Scott Bennett benn...@cs.niu.edu wrote: Can you paste the 'ANSWER SECTON' from: =A0'dig portsnap2.freebsd.org' =A0 =A0 Sure, but I'm curious to know why. =A0The names all do resolve to= A RRs, and pings to each by name did get echos back. =A0Here it is, although I d= id terminate the domain name by habit. =A0Surely portsnap must not be so sil= ly as to pass unterminated names to the resolver. =A0(Actually, I'm includin= g the whole output, not just the answer section.) To make sure it wasn't a DNS problem (or DNS poisoning / hijacking). ;; ANSWER SECTION: portsnap2.freebsd.org. =A03600 =A0 =A0IN =A0 =A0 =A0A =A0 =A0 =A0 72.21.5= 9.250 Same output for me.. Thanks for that much, then, Glen. So we still don't know what is wrong. I did try it again around midnight CDT, and it still failed the same way. In the meantime, my frustration and impatience got the better of me, and I touched up a copy of ports-supfile and csupped it. I also used portinstall, which was there because I had selected it as a package during the 7.2-RELEASE installation, to install portmaster, which is now running the builds. Nevertheless, I'd still rather switch back to portsnap ASAP after this, so I'm still hoping someone has an idea what's wrong with portsnap or the systems at freebsd.org. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: portsnap can't access portsnap[124].freebsd.org
On Sat, 30 May 2009, 05:39 -0500, Scott Bennett wrote: Thanks for that much, then, Glen. So we still don't know what is wrong. I did try it again around midnight CDT, and it still failed the same way. In the meantime, my frustration and impatience got the better of me, and I touched up a copy of ports-supfile and csupped it. I also used portinstall, which was there because I had selected it as a package during the 7.2-RELEASE installation, to install portmaster, which is now running the builds. Nevertheless, I'd still rather switch back to portsnap ASAP after this, so I'm still hoping someone has an idea what's wrong with portsnap or the systems at freebsd.org. Have you excluded local factors (proxy servers, firewalls)? I have not seen any issues at all with portsnap. I have done a few fetches today and haven't seen any problems at all. This one a few minutes ago happened to hit portsnap2. I noticed that one of the earlier ones today was from portsnap1. # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching snapshot tag from portsnap2.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Sat May 30 12:58:09 AEST 2009 to Sat May 30 18:57:34 AEST 2009. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 3 patches.. done. Applying patches... done. Fetching 0 new ports or files... done. -- John Marshall pgpPgvj7gNgjs.pgp Description: PGP signature
Re: portsnap can't access portsnap[124].freebsd.org
On Sat, 30 May 2009 21:05:44 +1000 John Marshall john.marsh...@riverwillow.com.au wrote: Have you excluded local factors (proxy servers, firewalls)? Try fetching the key manually fetch http://portsnap2.FreeBSD.org/pub.ssl ___ 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] Proposal: USE_GNU89 switch
Hi,
I'm proposing the following patch:
--- bsd.port.mk
+++ bsd.port.mk
@@ -2180,6 +2180,10 @@
.endif
.endif
+.if defined(USE_CSTD)
+CFLAGS+= -std=${USE_CSTD}
+.endif
+
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS=#
I thought it would be better to add USE_CSTD, instead of USE_GNU89,
where the port itself can specify which C standard to use. This will
also allow us to force builds with -std=gnu99 when needed, for example.
Any comments? Anyone who wants to integrate this patch into CVS, or
should I do it?
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpKIP1MUNLcg.pgp
Description: PGP signature
Re: [Patch] Proposal: USE_GNU89 switch
* Gabor Kovesdan ga...@freebsd.org wrote: I don't think it's a good idea. This knob is completely superfluous and thus should be avoided. One can just add -std to CFLAGS from a port Makefile. Forced build are also possible without this stuff, you can set this in /etc/make.conf. So how can we be sure all C compilers implement this switch? In bsd.port.mk I see some traces of ICC support. Using this approach it would also be possible to remap certain C standards to different compilers. Really, I really don't care how it's done, whether it's a flag or added to the compiler flags directly. I'm just saying adding it to CFLAGS directly sounds like a very bad idea. Adding it to /etc/make.conf sounds even worse, because it probably only confuses (autoconf) scripts that try to figure out a way to make the compiler speak C99. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp7YgIl9fxzg.pgp Description: PGP signature
Re: portsnap can't access portsnap[124].freebsd.org
On Sat, 30 May 2009 21:05:44 +1000 John Marshall john.marsh...@riverwillow.com.au wrote: On Sat, 30 May 2009, 05:39 -0500, Scott Bennett wrote: Thanks for that much, then, Glen. So we still don't know what is wr= ong. I did try it again around midnight CDT, and it still failed the same way. In the meantime, my frustration and impatience got the better of me,= and I touched up a copy of ports-supfile and csupped it. I also used portins= tall, which was there because I had selected it as a package during the 7.2-REL= EASE installation, to install portmaster, which is now running the builds. Nevertheless, I'd still rather switch back to portsnap ASAP after th= is, so I'm still hoping someone has an idea what's wrong with portsnap or the systems at freebsd.org. Have you excluded local factors (proxy servers, firewalls)? I have not seen any issues at all with portsnap. I have done a few fetches today and haven't seen any problems at all. This one a few minutes ago happened to hit portsnap2. I noticed that one of the earlier ones today was from portsnap1. [portsnap session omitted --SB] There was no proxy. However, I think you may have hit upon the problem. It depends upon what TCP port number portsnap uses. If it connects to the HTTP port, i.e., port 80, then I know what happened. While running portmaster, I soon had to deal with a problem where all of the fetches for a package failed, but immediately, not after lengthy waits for timeouts. It quickly dawned on me that the http_proxy environment variable had been set to connect things like fetch(1) and wget(1) to privoxy, which I haven't reinstalled yet since installing 7.2-RELEASE. This gets set in /root/.cshrc.extensions, a file that I source from /root/.cshrc to keep most of my changes separate from stuff that could get replaced accidentally in a mergemaster run between a buildworld and an installworld or, as in this case, a full new OS installation. I unsetenved that, and various ports' Makefile fetch targets were happy again. I never knew what port portsnap used, but maybe that's it. Once portmaster finishes rebuilding the relatively small set of already installed packages and ports, I'll give portsnap another shot at it to see what happens. Thanks much for the idea that connected the two problems for me! Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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] Proposal: USE_GNU89 switch
Ed Schouten escribió: * Gabor Kovesdan ga...@freebsd.org wrote: I don't think it's a good idea. This knob is completely superfluous and thus should be avoided. One can just add -std to CFLAGS from a port Makefile. Forced build are also possible without this stuff, you can set this in /etc/make.conf. So how can we be sure all C compilers implement this switch? In bsd.port.mk I see some traces of ICC support. Using this approach it would also be possible to remap certain C standards to different compilers. If ICC were supported I would agree with you that a general solution would be the best, but unfortunately ICC isn't actually supported. It's not a trivial task to work on ICC support because you need a license to do so because it is considered a derived work. I wanted to work on ICC support before but this was the barrier that stopped me. Probably netchild@ can tell you more, he has a license and he used to work on ICC support. As for LLVM, probably it won't work out for the whole ports tree. I don't know what's the portmgr opinion on this, if we start to use LLVM in Ports Collection, we should reconsider the knob, though. Really, I really don't care how it's done, whether it's a flag or added to the compiler flags directly. I'm just saying adding it to CFLAGS directly sounds like a very bad idea. Adding it to /etc/make.conf sounds even worse, because it probably only confuses (autoconf) scripts that try to figure out a way to make the compiler speak C99. I didn't say one should add it permanently to make.conf, it was just an example how a forced C99 build can be done without introducing new knobs. Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org ___ 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] Proposal: USE_GNU89 switch
Ed Schouten escribió:
Hi,
I'm proposing the following patch:
--- bsd.port.mk
+++ bsd.port.mk
@@ -2180,6 +2180,10 @@
.endif
.endif
+.if defined(USE_CSTD)
+CFLAGS+= -std=${USE_CSTD}
+.endif
+
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS=#
I thought it would be better to add USE_CSTD, instead of USE_GNU89,
where the port itself can specify which C standard to use. This will
also allow us to force builds with -std=gnu99 when needed, for example.
Any comments? Anyone who wants to integrate this patch into CVS, or
should I do it?
I don't think it's a good idea. This knob is completely superfluous and
thus should be avoided. One can just add -std to CFLAGS from a port
Makefile. Forced build are also possible without this stuff, you can set
this in /etc/make.conf.
Cheers,
--
Gabor Kovesdan
FreeBSD Volunteer
EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org
___
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] Proposal: USE_GNU89 switch
* Gabor Kovesdan ga...@freebsd.org wrote: As for LLVM, probably it won't work out for the whole ports tree. I don't know what's the portmgr opinion on this, if we start to use LLVM in Ports Collection, we should reconsider the knob, though. LLVM/Clang support is trivial. Erwin Lansing fired up an experimental ports build for us and the numbers are *very* promising. There are still some issues with the compiler itself, but so far it seems the only architectural change to the tree that needs to be made, is a hint to fall back to C89. This is not just about LLVM/Clang support. If the GCC folks ever decide to switch to C99 by default, we'll have exactly the same issue. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpD8x3SqNiQm.pgp Description: PGP signature
Re: [Patch] Proposal: USE_GNU89 switch
Hi, On Sat, May 30, 2009 at 04:34:43PM +0200, Ed Schouten wrote: * Gabor Kovesdan ga...@freebsd.org wrote: As for LLVM, probably it won't work out for the whole ports tree. I don't know what's the portmgr opinion on this, if we start to use LLVM in Ports Collection, we should reconsider the knob, though. As the plan is to have both gcc + clang in -9 we are still going to run into this problem. I would expect a lot of users are going to just expect ports to work with clang as well as gcc. LLVM/Clang support is trivial. Erwin Lansing fired up an experimental ports build for us and the numbers are *very* promising. There are still some issues with the compiler itself, but so far it seems the only architectural change to the tree that needs to be made, is a hint to fall back to C89. By the time FreeBSD-9 is released clang support will be solid and all ports will compile with clang as well as gcc. Clang was chosen because of their committment to have full gcc compatibility. This is not just about LLVM/Clang support. If the GCC folks ever decide to switch to C99 by default, we'll have exactly the same issue. Agreed. I don't see the harm in trying Ed_'s diff on a exp. run with both gcc and clang and compare a gcc run with a stock run. Perhaps this is something Itetcu could help with. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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] Proposal: USE_GNU89 switch
On Saturday 30 May 2009 16:21:52 Ed Schouten wrote: Really, I really don't care how it's done, whether it's a flag or added to the compiler flags directly. I'm just saying adding it to CFLAGS directly sounds like a very bad idea. Adding it to /etc/make.conf sounds even worse, because it probably only confuses (autoconf) scripts that try to figure out a way to make the compiler speak C99. Are there any edge cases of (antiquated) ports that (indirectly) use bsd.sys.mk and as such get hit by: 11 # the default is gnu99 for now 12 CSTD?= gnu99 In other words should one clean CFLAGS of -std before applying the forced one, similar as to what WITH_DEBUG in ports does for -O*. -- Mel ___ 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] Proposal: USE_GNU89 switch
* Mel Flynn mel.flynn+fbsd.po...@mailing.thruhere.net wrote:
Are there any edge cases of (antiquated) ports that (indirectly) use
bsd.sys.mk and as such get hit by:
11 # the default is gnu99 for now
12 CSTD?= gnu99
In other words should one clean CFLAGS of -std before applying the
forced one, similar as to what WITH_DEBUG in ports does for -O*.
Yes. This should fix it:
--- bsd.port.mk
+++ bsd.port.mk
@@ -2180,6 +2180,10 @@
.endif
.endif
+.if defined(USE_CSTD)
+CFLAGS:= ${CFLAGS:N-std=*} -std=${USE_CSTD}
+.endif
+
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
_MAKE_JOBS=#
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpgwTc7RwWrQ.pgp
Description: PGP signature
Re: Policy on removed ports
On Sat, May 30, 2009 at 04:48:15PM +0200, Mel Flynn wrote: but what is the general policy on such ports? They can come back if they're not vulnerable and someone volunteers to maintain them. (deleted ports may have had ports@ as the maintainer, but we don't allow that for port (re)additions.) We have ports that get marked vulnerable and then get updated and fixed all the time. It's just when someone doesn't update them that they go away :-) mcl ___ 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] Proposal: USE_GNU89 switch
On Sat, May 30, 2009 at 11:01:38AM -0400, Diane Bruce wrote: By the time FreeBSD-9 is released clang support will be solid and all ports will compile with clang as well as gcc. ooh, can I have unicorns, too? :-) Seriously, I'd like to see the potential to throw the switch, with the caveat that it will probably be a _long_ time before ports will work well with anything other than gcc. (Not that some of them work that well _with_ gcc; many of the port source files are ancient and choke on modern gcc implementations. We keep weeding them out ...) mcl ___ 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
FreeBSD Port: mail/p5-FuzzyOcr-devel
Hi, I sent an update for this port (http://www.freebsd.org/cgi/query-pr.cgi?pr=135065) I also would like to be maintainer of this port. Thanks. -- Ismail YENIGUL Endersys Ltd. Phone :+90 216-4709423 | Mobile:+90 533 747 36 65 Fax :+90 216-4709508 | web: http://www.endersys.com.tr Endersys blog açıldı. http://blog.endersys.com ___ 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: FreeBSD Port: mail/p5-FuzzyOcr-devel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, May 31, 2009 at 12:58:30AM +0300, Ismail YENIGUL wrote: Hi, I sent an update for this port (http://www.freebsd.org/cgi/query-pr.cgi?pr=135065) I also would like to be maintainer of this port. Done Thanks. -- Ismail YENIGUL Endersys Ltd. Phone :+90 216-4709423 | Mobile:+90 533 747 36 65 Fax :+90 216-4709508 | web: http://www.endersys.com.tr Endersys blog aç?ld?. http://blog.endersys.com ___ 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 - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkohtCQACgkQdLJIhLHm/OkrHACeISKlLHSzob2k5E1XDH4FNNJD Ey4AoJUPYrfEN1RnZa/f9gQPjQrov39Z =rKfL -END PGP SIGNATURE- ___ 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: unable to build openoffice.org-3
From: Oliver Lehmann lehm...@ans-netz.de Subject: unable to build openoffice.org-3 Date: Thu, 28 May 2009 18:17:28 +0200 Hi, I'm getting this error when compiling openoffice 3.1.0 on FreeBSD/amd64 7 /mnt/misc/usr/ports/editors/openoffice.org-3/work/OOO310_m11/solenv/bin/checkdll.sh -L../unxfbsdx.pro/lib -L/mnt/misc/usr/ports/editors/openoffice.org-3/work/OOO310_m11/solver/310/unxfbsdx.pro/lib ../unxfbsdx.pro/lib/check_i18npool.uno.so Checking DLL ../unxfbsdx.pro/lib/check_i18npool.uno.so ...-rwxr-xr-x 1 root wheel 2771757 May 28 08:30 ../unxfbsdx.pro/lib/i18npool.uno.so - Running processes: 0 deliver -- version: 266154 Module 'i18npool' delivered successfully. 29 files copied, 5 files unchanged 1 module(s): cppunit need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /mnt/misc/usr/ports/editors/openoffice.org-3/work/OOO310_m11/cppunit Attention: if you build and deliver the above module(s) you may prolongue your the build issuing command build --from cppunit rmdir /tmp/49004 *** Error code 1 Stop in /usr/ports/editors/openoffice.org-3. Exit 1 I've started the build with make -DWITHOUT_CUPS any suggestions? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ 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 Hi Oliver, this can be a build sequesnce problem thanks -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt pgpcQ8pH46AHj.pgp Description: PGP signature
Setiathome
It would be very nice to those of us that install setiathome on remote servers to be able to build it without needing all of X and GL. I'm not the only one since there *is* an option in configure (--disable-graphics) to do this (but when I did the obvious to the makefile to add this option, something else (a SED script late in the build??) broke.) Anyhow, a make option to do this would be very welcome. I guess I can figure out how to do this and submit a send-pr, but someone probably already knows how... -- Pete ___ 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: FreeBSD Port: mail/p5-FuzzyOcr-devel
On Sun, 31 May 2009 00:58:30 +0300 Ismail YENIGUL ismail.yeni...@endersys.com.tr wrote: Hi, I sent an update for this port (http://www.freebsd.org/cgi/query-pr.cgi?pr=135065) I also would like to be maintainer of this port. It doesn't seem sensible that p5-FuzzyOcr contains an obsolete version that's not recommended for use with the current p5-Mail-SpamAssassin port, and the one that is recommended is in p5-FuzzyOcr-devel. The author said that he will develop it, but doesn't have much time to devote to it. I think it might be better if the main port is brought up to 3.6.0 and the -devel port removed. ___ 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
custom PREFIX/LOCALBASE QA run
Hi, In the ongoing QA effort, the second QA Tinderbox - QATty - is currently doing a full run of the Ports Tree with PREFIX, LOCALBASE and X11BASE set to a custom directory. The build is done with PT from 2009-05-28 18:03:14; I'll be probably updating it after each category is built. QATtyMails are sent to the maintainers (and other interested parties) for each failure (but not more often that 2 weeks), with links to the port status on QAT and PortsMon. Often fixing the errors is easy and requires a one-two lines modification of the port Makefile or a little patch. Failed ports can be seen here: http://qatty.tecnik93.com/index.php?action=failed_buildportsbuild=7-STABLE-FPT-CustDirsort=last_built People interested to help can ping me, there are a few more automated resources available. You can send me your patches, I'll test and commit them :-) The stats ATM: Build Name Build Description S U F D L R T 7-STABLE-FPT-CustDir7-STABLE with custom PREFIX 14498 23 122 - 1 1631 S = Number of ports built successfully U = Number of ports with unknown status F = Number of ports that failed to build D = Number of ports that were not built due to a dependency failure L = Number of ports with leftovers R = Number of ports to be remade T = Total -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Amavis::SpamControl-new not found
I had same trouble. And I found a solution/workaround. According to http://marc.info/?l=amavis-userm=124299851715437w=2 o no need to set @bypass_spam_check_maps, just comment out o set @spam_scanners properly, for example @spam_scanners='undef' if you do not want amavisd-new to check spam The RELEASE_NOTES of amavisd-new also mentions about @spam_scanners. Some workaround patches are available like Debian's package, but I think this is better. Thanks. In 20090515125835.gc39...@parmesan.sis.pasteur.fr hum...@pasteur.fr (Thomas Hummel) wrote: Conclusion : it seems to me that : . amavisd miss somewhere the import of the Amavis::SpamControl package (I don't see such import anywhere) . @bypass_spam_checks_maps = (1); doesn't bypass everything since $spamcontrol_obj = Amavis::SpamControl-new if $extra_code_antispam; is still executed. . $sa_mail_body_size_limit = 1; isn't enough to fully bypass spam engine since some messages where marked UBE. Thanks -- NAKAJI Hiroyuki ___ 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: custom PREFIX/LOCALBASE QA run
On Sun, 31 May 2009 05:56:01 +0300
Ion-Mihai Tetcu ite...@freebsd.org wrote:
On Sun, 31 May 2009 05:56:01 +0300
Ion-Mihai Tetcu ite...@freebsd.org wrote:
Hi,
In the ongoing QA effort, the second QA Tinderbox - QATty - is
currently doing a full run of the Ports Tree with PREFIX, LOCALBASE
and X11BASE set to a custom directory.
Why should you care about custom PREFIX and LOCALBASE:
- because we claim we support it and we should put our money where our
mouth is
- because it makes it possible to install eg. in ~/ eg. to test stuff
before replacing the older version in LOCALBSE
- because it makes it easier to create plists
- because PCBSD's port-to-PBI converter needs it
- ...
The build is done with PT from 2009-05-28 18:03:14; I'll be probably
updating it after each category is built.
QATtyMails are sent to the maintainers (and other interested parties)
for each failure (but not more often that 2 weeks), with links to the
port status on QAT and PortsMon.
Often fixing the errors is easy and requires a one-two lines
modification of the port Makefile or a little patch.
A few hints:
- if the port fails with mtree errors then it's almost certain to have
a hard-coded PREFIX=/usr/local in it; grep -R /usr/local WRKDIR should
help. You can test your fix via `make PREFIX=/tmp/PORTNAME install`
- if it fails with configure_, linker_ or missing_header error then
compare the log from QATty with the one from QAT; the differences in
configure or build phase might prompt you in the right way; suspect
either hard-coded /usr/local for -I and -L CFLAGS/CXXFLAGS or
missing -I${LOCALBASE}/include -L${LOCALBASE}/lib and equivalents.
You might also need to hint ./configure where to find libs from
dependencies via some --with... (or patch the brain-dead configure
script).
- make PREFIX=/tmp/PORTNAME LOCALBASE=/tmp/PORTNAME -V CONFIGURE_ENV -V
CONFIGURE_ARGS -V CFLAFS
- look in other BSDs (or Linux) repositories for fixes
- if you get stuck, try again :-) and if you're still stuck ask here
for help
We would appreciate you telling us (eg. by replying to the QATtyMail)
that you work on a fix for a certain port in order to not duplicate the
effort.
Don't forget to push your patches upstream, there are others that will
benefit from them!
I've fixed all unmaintained ports that failed so far and a few
maintainers already submitted fixes for their ports which fixes I
committed.
It took a year+, and in to many cases tens of QATMails, me prodding or
going in and fixing ports to have a somewhat decent obeisance of
NOPORT*.
I'm not willing to wait that much for PREFIX/LOCALBASE problems to be
fixed. Current target is 6 months or 3 QATtyMails (so minimum 6 weeks)
after which we'll either fix it or I'll mark the port in question
BROKEN accordingly.
The only good reason I can see for a port not to obey PREFIX is if it's
a binary port; in this case: please try to get upstream vendor to
support custom PREFIX/LOCALBASE (via eg. env vars or .conf file, ...)
and please submit a PR explaining the problem with corresponding patch
attached.
That's 6 months because we need a few more runs in order to test ports
that depend on the currently broken ones; and because of available
hardware resources.
Speaking of hardware resources, QAT Restless Daemons are aching to
posses a few more machines, for other QA testing. If you or your
employer have a machine that idles and want to put it to good use
please contact me. Thank you!
Happy patching,
--
IOnut - Un^d^dregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
