Re: Making ports from source with weird download restrictions
Brooks Davis wrote: As long as the license allows redistribution, we can host it on FreeBSD infrastructure using MASTER_SITE_LOCAL. 2) openocd - http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD - this is a bit more sensible - there's a stable SVN repository for it, it's just that the only ports I've seen are on sourceforge, and come from release .tgz archives, not a SVN archive (although I've never gotten a broken version from the openocd SVN). If someone pointed me at a port that built from SVN instead of a .tgz, I'm sure I could get the port done. Doing an svn export in the fetch stage is possible, but probably not ideal. In my devel/llvm-devel port I have a do-fetch target that fetches a snapshot and makes a tarball out of it, but I only use that for my own use and host a snapshot on the FreeBSD ftp servers for normal users since a tarball allows users to do a make clean and retry without having to fetch files again. Yes, this is the right way to do it. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: graphics/xmagv - failes: install_error
[EMAIL PROTECTED] wrote: Hi, The build which triggered this email is done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. Excerpt from http://T64.TecNik93.com/logs/7-STABLE-FTP/xmagv-1.11_1.log : building xmagv-1.11_1 in directory /var/tinderbox/7-STABLE-FTP maintained by: [EMAIL PROTECTED] These ports are unmaintained are the mails just spam the list. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: graphics/xmagv - failes: install_error
Kris Kennaway wrote: [EMAIL PROTECTED] wrote: Hi, The build which triggered this email is done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. Excerpt from http://T64.TecNik93.com/logs/7-STABLE-FTP/xmagv-1.11_1.log : building xmagv-1.11_1 in directory /var/tinderbox/7-STABLE-FTP maintained by: [EMAIL PROTECTED] These ports are unmaintained are the mails just spam the list. ^^^ I think this was supposed to be so Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: graphics/xmagv - failes: install_error
Beech Rintoul wrote: On Sunday 24 August 2008, Kris Kennaway said: [EMAIL PROTECTED] wrote: Hi, The build which triggered this email is done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. Excerpt from http://T64.TecNik93.com/logs/7-STABLE-FTP/xmagv-1.11_1.log : building xmagv-1.11_1 in directory /var/tinderbox/7-STABLE-FTP maintained by: [EMAIL PROTECTED] These ports are unmaintained are the mails just spam the list. Kris I think the general idea is that someone will take notice and step up and fix it. Sounds more like a hope to me :) We don't even consistently get people fixing the unmaintained broken ports, let alone edge-polishing. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: best way to work around malloc.h vs stdlib.h ?
Luigi Rizzo wrote: A fair amount of third party software in ports still uses malloc.h which in our system is like this: /* $FreeBSD: src/include/malloc.h,v 1.5 2001/11/07 23:14:31 obrien Exp $ */ #if __STDC__ #error malloc.h has been replaced by stdlib.h #else #include stdlib.h #endif What is the best way to disable the error without an explicit patch (there are over 200 patchfiles in ports just doing that) ? I tried the following + CPPFLAGS += -U__STDC__ seems to work, though it gives some warnings because a built-in define is undefined. Also i am not sure if there are other parts of the system that are affected; + CPPFLAGS += -traditional-cpp is also reported to unset __STDC__, but it generates an independent set of warnings and errors; Any other ideas ? The only reasonable fix is to patch or use sed (e.g. REINPLACE_CMD), then send the fixes upstream. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: best way to work around malloc.h vs stdlib.h ?
Luigi Rizzo wrote: On Tue, Aug 19, 2008 at 01:12:37PM -0500, Jeremy Messenger wrote: On Tue, 19 Aug 2008 12:26:31 -0500, Luigi Rizzo [EMAIL PROTECTED] wrote: A fair amount of third party software in ports still uses malloc.h which in our system is like this: /* $FreeBSD: src/include/malloc.h,v 1.5 2001/11/07 23:14:31 obrien Exp $ */ #if __STDC__ #error malloc.h has been replaced by stdlib.h #else #include stdlib.h #endif What is the best way to disable the error without an explicit patch (there are over 200 patchfiles in ports just doing that) ? I think patch it is best, because if I understand it corrects is that malloc() in stdlib.h is standard of ANSI C. Correct me if I am wrong. However, I don't see anything wrong with patch. You can simple use wildcard (*.c) or use find(1) to find files to replace the malloc.h - stdlib.h by use REINPLACE_CMD without have to create multi-file patch. i am not questioning the correctness of using stdlib.h rather than malloc.h, nor the fact that if the upstream is cooperating, one surely should pass patches upstream. However this malloc.h (and missing sys/types.h -- there's another 200+ patch files doing just that) seem to be very common porting problem and so it would be issues and thought it could be nice to find a fix that addresses those kind of problems. Wonder if a -I/usr/local/questionable-programs/include approach could be used to wrap the handful of system headers that cause problems... It's a trivial fix. Just do it instead of over-engineering a solution :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are there packages available anywhere for kde4 en general and kde4network specifically.
eculp wrote: Quoting Kris Kennaway [EMAIL PROTECTED]: eculp wrote: I have been having issues as I have posted on [EMAIL PROTECTED] compiling kdenetwork4. It always breaks at /usr/ports/net/kdenetwork4/work/kdenetwork-4.1.0/kopete/protocols/jabber/libiris/iris/xmpp-im/xmpp_task.cpp:21:27: error: qplatformdefs.h: No such file or directory *** Error code 1 During the last 24 hora I have forced updates of all my installed ports with portmaster and I keep getting the same error so I give up :( I would like to find a package and later it will probably compile when there are updates, they usually do. I have kde4 working perfectly except for the above. Packages are in the usual place on the FTP site. Kris Thanks Kris. Correct. The problem is tahat pkg_add is lookking for: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/net/kdenetwork4.tbz rather than ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/kdenetwork4.tbz The packages seem to be all together in Latest rather than en Latest/net. Latest/ is the correct location, not Latest/net/. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are there packages available anywhere for kde4 en general and kde4network specifically.
eculp wrote: I have been having issues as I have posted on [EMAIL PROTECTED] compiling kdenetwork4. It always breaks at /usr/ports/net/kdenetwork4/work/kdenetwork-4.1.0/kopete/protocols/jabber/libiris/iris/xmpp-im/xmpp_task.cpp:21:27: error: qplatformdefs.h: No such file or directory *** Error code 1 During the last 24 hora I have forced updates of all my installed ports with portmaster and I keep getting the same error so I give up :( I would like to find a package and later it will probably compile when there are updates, they usually do. I have kde4 working perfectly except for the above. Packages are in the usual place on the FTP site. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build failed for 6.x
Jeremy Messenger wrote: On Wed, 06 Aug 2008 23:08:19 -0500, Erwin Lansing [EMAIL PROTECTED] wrote: INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found pkg_info: not found pkg_info: not found Done. make_index: transmission-gtk2-1.31: no entry for /usr/ports/www/transmission-web Why did your script took hours to find that www/transmission-web? Need to improvement your script? This is not constructively worded. The script currently only runs every 3 hours because the system is overloaded, but you should not be relying upon it to catch the silly mistakes in your commits to begin with ;) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
INDEX warning
Generating INDEX-8 - please wait..gnome-config: not found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing `gstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Can someone please fix? Perhaps someone also needs to take another look at the recent advice I gave about avoiding bare != variable assignments in port makefiles :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
V.Chukharev wrote: On Tue, 29 Jul 2008 18:28:26 +0300, V.Chukharev [EMAIL PROTECTED] wrote: On Fri, 25 Jul 2008 20:19:42 +0300, Kris Kennaway [EMAIL PROTECTED] wrote: You don't want to .include the file, just use the same make -f trick that I used for e.g. the python and java variable caching. Ah, thanks, I think I got it now. Please, review. [patch deleted] I also tried to make only one sweep over /var/db/pkg, but with uncommented 'OPENSSL_INSTALLED+=' line (and corresponding '.if !defined' in bsd.openssl.mk) INDEX-7 was different. I could not trace down the reason. I have found why there is a difference in INDEX-7 generated with and without caching. Without cache security/p5-openxpki* (6 connected ports) are indexed as depending on both openssl-0.9.8h_1 and openssl-beta-0.9.8h_1 (beta is not actually installed), while with cache the second dependence is lost. This is due to WITH_OPENSSL_BETA defined in security/p5-openxpki/Makefile (master for other slave ports). So, Dirk, you are right, cashing breaks current behavior. No, it means that you need to add extra checks to how the cached value is used. Kris But now I wonder if the current behavior is correct and if security/p5-openxpki is correct. IMHO at least one of the two dependences is in err. Best regards, Vladimir Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
Vladimir Chukharev wrote: On Wed, 30 Jul 2008 14:09:16 +0300, Kris Kennaway [EMAIL PROTECTED] wrote: V.Chukharev wrote: I have found why there is a difference in INDEX-7 generated with and without caching. Without cache security/p5-openxpki* (6 connected ports) are indexed as depending on both openssl-0.9.8h_1 and openssl-beta-0.9.8h_1 (beta is not actually installed), while with cache the second dependence is lost. This is due to WITH_OPENSSL_BETA defined in security/p5-openxpki/Makefile (master for other slave ports). So, Dirk, you are right, cashing breaks current behavior. No, it means that you need to add extra checks to how the cached value is used. This is also true, but it might be spreaded over many ports and/or bsd.*.mk files... No, I don't think so. You need to make bsd.openssl.mk not use the cached value if it should not be, e.g. if WITH_OPENSSL_BETA is set. But now I wonder if the current behavior is correct and if security/p5-openxpki is correct. IMHO at least one of the two dependences is in err. Can you comment on this? Seems wrong to me. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
Freddie Cash wrote:
On July 29, 2008 12:52 pm V.Chukharev wrote:
Another patch, just one line. It can be applied independently from the
patch for bsd.port.subdir.mk.
=
--- /usr/ports/Mk/bsd.openssl.mk.orig 2008-07-23 09:14:29.0
+0300 +++ /usr/ports/Mk/bsd.openssl.mk 2008-07-29 20:35:05.0
+0300 @@ -121,7 +121,7 @@
exists(${DESTDIR}/${LOCALBASE}/lib/libcrypto.so)
# find installed port and use it for dependency
PKG_DBDIR?=${DESTDIR}/var/db/pkg
-OPENSSL_INSTALLED!=grep -l -r ^lib/libssl.so. ${PKG_DBDIR} | \
+OPENSSL_INSTALLED!=find ${PKG_DBDIR} -type f -name +CONTENTS
-print0 | xargs -0 grep -l ^lib/libssl.so. | \ while read contents;
Is piping this into xargs faster/better than using -exec option to find?
find ${PKG_DBDIR} -type f -name +CONTENTS -exec \
grep -l ^lib/libssl.so. {} \;
You guys are still just going for the small improvements - there's no
need to compute this 19000 times since it won't change during the course
of an index build or similar global-recursive target.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
Dirk Meyer wrote: Kris Kennaway schrieb:, To repeat, why can't you set the openssl variables in bsd.port.subdir.mk and pass them in to the port-level make process instead of recomputing them with every port? Becuase if someone does make package in ports/security The value must change during the run. That operation does not involve bsd.port.subdir.mk. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
Dirk Meyer wrote: Kris Kennaway schrieb:, The result can be cached only if no other ports or package is installed. So you are right that make index could be otimized, but it will take much more work. Why can't you cache it in bsd.port.subdir.mk as I suggested? openssl does set NOPRECIOUSMAKEVARS=yes, so that part ist skipped in bsd.port.subdir.mk. OK, but why is this necessary? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
Dirk Meyer wrote: Kris Kennaway schrieb:, openssl does set NOPRECIOUSMAKEVARS=yes, so that part ist skipped in bsd.port.subdir.mk. OK, but why is this necessary? otherwise the build breaks, as the length of the commandline reaches a limit. We're not talking about builds, but other processing of the bsd.openssl.mk such as for 'make describe'. I don't see why NOPRECIOUSMAKEVARS should be relevant for that since it's not invoking further child makes. To repeat, why can't you set the openssl variables in bsd.port.subdir.mk and pass them in to the port-level make process instead of recomputing them with every port? Kris P.S. I am not sure that same limit still exists in supported versions anyway ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
Dirk Meyer wrote: V.Chukharev schrieb:, So I looked through some Mk stuff, and tryed to optimize it. Since I do not know any magic of bsd.*.mk, I did just a simple test. And with the below shown patch the time is only 1500 s, while with the original version the time is more than 15000 s. I guess the time depens very much on number of installed ports, I have about 1300. The resulting INDEX* files are identical. I should confess I do not understand how my patch works. I expected to see a file /usr/ports/.openssl_installed or /tmp/index_something/.openssl_installed or similar, but could not see it... But I hope this patch will inspire you to do something really working. This patch breaks the desired funtion. To speedup index build you can add in in your /etc/make.conf WITH_OPENSSL_BASE=yes or WITH_OPENSSL_PORT=yes The linker will pull in the latests version of libssl.so, So this check is necessary to detect an installed port version, and record the correct dependency. The result can be cached only if no other ports or package is installed. So you are right that make index could be otimized, but it will take much more work. Why can't you cache it in bsd.port.subdir.mk as I suggested? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
V.Chukharev wrote: On Fri, 25 Jul 2008 16:09:10 +0300, V.Chukharev [EMAIL PROTECTED] wrote: On Fri, 25 Jul 2008 07:30:18 +0300, Dirk Meyer [EMAIL PROTECTED] wrote: So you are right that make index could be otimized, but it will take much more work. Totally agree on this. I tryed to make caching in bsd.subdir.mk as Kris proposed, and I got also considerable speedup, but not as good as with the first patch. The grep on all packages is done once per port category. I miss how to pass the results to a child make... Anyway, I attach the new (better, but still not fully working) patch JFYI. Well, I've found how to pass params to a child make. So the next version of the patch comes at the end of this post. This patch should work well for index builds, but I have big doubts about all the rest. Please review and test if possible. With the patch Mk/bsd.port.sudir.mk .include's Mk/bsd.openssl.mk, hence everywhere when the former is used the latter is inderectly included. This is because I did not want to split the openssl staff into two parts. I put some protection. You don't want to .include the file, just use the same make -f trick that I used for e.g. the python and java variable caching. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Auto-saving distfiles on freebsd
cpghost wrote: On Tue, Jul 22, 2008 at 11:47:04PM -0700, Ted Mittelstaedt wrote: Another problem with ports is that all of them like pulling the original source from the author's site. I've had a few where the author released the code under GPL then a few years later lost interest, stopped paying whatever ISP he had the main site for the program at, and the porter also lost interest in the project and never bothered obtaining the last available tarfile from the authors site and uploading it to freebsd, then both disappeared. Another one I can recall is the gated code, similar issue. Why not add this to pointyhat scripts? Just upload a copy of every *new* distfile ever encountered from the author's page to freebsd (unless there are legal constraints not to do so, of course)? We've regularly collected and published port distfiles for at least a decade (with increasingly higher frequency as disk space came to permit). It may come as no surprise that Ted is talking out of his ass again :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Auto-saving distfiles on freebsd
Matthew Seaman wrote: cpghost wrote: Why not add this to pointyhat scripts? Just upload a copy of every *new* distfile ever encountered from the author's page to freebsd (unless there are legal constraints not to do so, of course)? Some might say that this already happens. Well, it's on ftp.freebsd.org rather than pointyhat, and it's only for the ports that are built by the package build cluster. Take a look at ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ (Warning: very long listing) I'm not sure what the policy is about getting rid of old distfiles, but there are generally several generations of distfile in there -- about 2 or 3 years worth. Basically we don't delete them any more unless we have to (e.g. porter accidentally allowed redistribution of a distfile for which we don't have permission). In the past we (I) occasionally weeded out everything except for the past couple of release distfile sets (and the current set) because we needed the space, but this is a pain in the ass to do and there hasn't been a need in some years. Thesedays we indeed collect distfiles with every build. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Auto-saving distfiles on freebsd
James Tanis wrote:
cpghost [EMAIL PROTECTED] wrote:
The ports would still go to the primary sites (to conserve bandwidth),
but should the original distfile disappear, it would be still available
on freebsd.
I think his problem comes from the fact that some ports don't do this, not
that it isn't a good idea. The port maintainers just never did it.
No, you're both mistaken:
# MASTER_SITE_BACKUP
# - Backup location(s) for distribution
files and patch
# files if not found locally and
${MASTER_SITES}/${PATCH_SITES}
# Default:
#
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/
All ports fall back to fetching from the master distfile repository if
they can't be found at the upstream sites. This dates back at least to
1996.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Auto-saving distfiles on freebsd
cpghost wrote: On Wed, 23 Jul 2008 16:51:10 +0200 Kris Kennaway [EMAIL PROTECTED] wrote: cpghost wrote: On Tue, Jul 22, 2008 at 11:47:04PM -0700, Ted Mittelstaedt wrote: Another problem with ports is that all of them like pulling the original source from the author's site. I've had a few where the author released the code under GPL then a few years later lost interest, stopped paying whatever ISP he had the main site for the program at, and the porter also lost interest in the project and never bothered obtaining the last available tarfile from the authors site and uploading it to freebsd, then both disappeared. Another one I can recall is the gated code, similar issue. Why not add this to pointyhat scripts? Just upload a copy of every *new* distfile ever encountered from the author's page to freebsd (unless there are legal constraints not to do so, of course)? We've regularly collected and published port distfiles for at least a decade (with increasingly higher frequency as disk space came to permit). It may come as no surprise that Ted is talking out of his ass again :) Kris Ah, thanks! Good to know, and it's good news! :) Will distfiles for ports that are no longer in the tree remain there as well, so that these ports can still be compiled with an older ports tree (yes, I know about the hairy security and dependency issues involved with old unmaintained and even dead ports...)? Yes, as I mentioned in another reply it's been years since I have had to clean out old distfiles for space reasons, and there's no other need to do that so they will remain indefinitely. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mk/bsd.openssl.mk optimization
V.Chukharev wrote:
Dear maintainer,
I have noticed that most time of 'make index' on my system takes a grep for
libssl.
The following is done while 'make index' was running.
$ ps axww | grep libssl
23119 p1 IN+0:00,00 sh -c grep -l -r ^lib/libssl.so. /var/db/pkg | while read contents; do sslprefix=`grep
[EMAIL PROTECTED] ${contents} | /usr/bin/head -n 1`; if test ${sslprefix} = @cwd /usr/local ; then
echo ${contents}; break; fi; done
23124 p1 DN+0:00,84 grep -l -r ^lib/libssl.so. /var/db/pkg
23125 p1 IN+0:00,00 sh -c grep -l -r ^lib/libssl.so. /var/db/pkg | while read contents; do sslprefix=`grep
[EMAIL PROTECTED] ${contents} | /usr/bin/head -n 1`; if test ${sslprefix} = @cwd /usr/local ; then
echo ${contents}; break; fi; done
24555 p1 IN+0:00,00 sh -c grep -l -r ^lib/libssl.so. /var/db/pkg | while read contents; do sslprefix=`grep
[EMAIL PROTECTED] ${contents} | /usr/bin/head -n 1`; if test ${sslprefix} = @cwd /usr/local ; then
echo ${contents}; break; fi; done
24556 p1 DN+0:00,41 grep -l -r ^lib/libssl.so. /var/db/pkg
24557 p1 IN+0:00,00 sh -c grep -l -r ^lib/libssl.so. /var/db/pkg | while read contents; do sslprefix=`grep
[EMAIL PROTECTED] ${contents} | /usr/bin/head -n 1`; if test ${sslprefix} = @cwd /usr/local ; then
echo ${contents}; break; fi; done
So I looked through some Mk stuff, and tryed to optimize it. Since I do not
know any magic of bsd.*.mk, I did just a simple test. And with the below shown
patch the time is only 1500 s, while with the original version the time is more
than 15000 s. I guess the time depens very much on number of installed ports,
I have about 1300.
The right way is either/or:
a) to do the != assignment in bsd.port.subdir.mk and pass it in to the
child make environment. Actually the other != assignments also look
like they should be fixed too, since they'll also be eating up your CPU
time.
b) Try to reduce the number of external commands being invoked by doing
it in shell or make instead (at least partially).
See the recent commits I did to the Mk files for more specifics.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: porter's handbook documentation on avoiding != variable assignments
Matthew Seaman wrote:
Kris Kennaway wrote:
Can someone add to the PH a version of the advice below? It might
need to be fleshed out a bit to provide more context.
Kris
Variable assignments with != are bad! Try as hard as you can to
avoid using them -- especially in Mk/*! Every time something
processes your makefile it will spawn a command, even if it is not
relevant for the operation being performed. If you need to run shell
commands, try to isolate them within a makefile target. You can
avoid code duplication by assigning the *shell commands* (not their
output) to a variable and inserting it into your code block.
e.g. instead of
--
VARIABLE!=do some shell stuff; do some other stuff
target:
echo ${VARIABLE}
--
do this (or similar):
--
VARIABLE_CMDS=do some shell stuff; do some other stuff
target:
echo $$(${VARIABLE_CMDS})
--
This defers the command execution to the point where the target runs,
so in the case when the target is *not* run (e.g. during INDEX builds or
other recursive port traversals), then you avoid wasting one or more
process executions.
Would it be acceptable to use something like:
.if !defined(BUILDING_INDEX)
VARIABLE!= something or other
.endif
or
.if !make(describe)
VARIABLE!= whatever
.endif
No because that only avoids one particular case, not the default case :)
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
porter's handbook documentation on avoiding != variable assignments
Can someone add to the PH a version of the advice below? It might need
to be fleshed out a bit to provide more context.
Kris
Variable assignments with != are bad! Try as hard as you can to avoid
using them -- especially in Mk/*! Every time something processes your
makefile it will spawn a command, even if it is not relevant for the
operation being performed. If you need to run shell commands, try to
isolate them within a makefile target. You can avoid code duplication
by assigning the *shell commands* (not their output) to a variable and
inserting it into your code block.
e.g. instead of
--
VARIABLE!=do some shell stuff; do some other stuff
target:
echo ${VARIABLE}
--
do this (or similar):
--
VARIABLE_CMDS=do some shell stuff; do some other stuff
target:
echo $$(${VARIABLE_CMDS})
--
This defers the command execution to the point where the target runs, so
in the case when the target is *not* run (e.g. during INDEX builds or
other recursive port traversals), then you avoid wasting one or
more process executions.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build failed for 6.x
Erwin Lansing wrote: INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found pkg_info: not found === sysutils/burn failed Hangup Hangup Looks like this lost out to a server reboot Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading through packages: an experience.
Michel Talon wrote: Hello, Since KDE recently appeared in the Latest prebuilt packages Well, it's always been there, except when it could not be built. Now the problems. They come from the fact that the Latest packages are not always coherent between themselves or with the libraries in FreeBSD-7.0. No, they are. In fact this is a key design feature, and the same reason why sometimes certain packages do not appear on the FTP site (if they did appear they would be necessarily *out* of sync). Similarly they are always built against recent versions of -STABLE, by design. Glad to hear your experience was generally positive though. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NOT SOLVED --cvsup after upgrade to 6.3 coredump
David Southwell wrote: But this may be a clue Here is what happened.. in the past it seemed to core dump immediately - but now it transpires the dumping takes place only once the connection is made. I incorrectly assumed all was OK when I got the Rejected by Server message but jumped too quickly. So problem is still with us!! Connected to cvsup10.FreeBSD.org Rejected by server: Access limit exceeded; try again later Will retry at 10:05:05 Retrying Connected to cvsup10.FreeBSD.org Bus error: 10 (core dumped) [EMAIL PROTECTED] /usr/ports/net/cvsup-without-gui] Any ideas?? Can you either get a backtrace or do a binary search on the kernel sources to work out which commit caused it? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/124944: [PATCH] audio/arts: Remove 5.x support
Philip M. Gollucci wrote: o Remove 5.x support Port maintainer ([EMAIL PROTECTED]) is cc'd. FYI, we stated in the EOL announcement that we are not doing sweeping 5.x removals right away. Please give it more time. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/124944: [PATCH] audio/arts: Remove 5.x support
Brandon S. Allbery KF8NH wrote: On 2008 Jun 24, at 19:03, Philip M. Gollucci wrote: Kris Kennaway wrote: Philip M. Gollucci wrote: o Remove 5.x support Port maintainer ([EMAIL PROTECTED]) is cc'd. FYI, we stated in the EOL announcement that we are not doing sweeping 5.x removals right away. Please give it more time. I thought I waited 2 weeks, anyway, ACK. I rather think not right away means at least for one point release, and possibly to the next major release. Nah, 5.x is dead and has begun to decompose, but there was a bit of a mix-up in getting the pre-announcements widely publicized so we decided to hold off on the burial process in case some people only saw the final termination notice and not the pre-announcements. Let's give it a month and then we can begin to actively remove 5.x support. Waiting shouldn't cause major difficulties. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build optimizations - please review
Doug Barton wrote: Kris Kennaway wrote: The new 'make describe' target runs entirely using shell builtins apart from the need to sed pkg-descr to extract the WWW [2] [2] Actually I am not happy with this but couldn't think of a way to do it better. Having to fork the subshell costs about 60 seconds of system time and 10 of wall time. Here's one way to do it. This is quick and dirty and I haven't benchmarked it, but I imagine it would be faster. while read one two discard; do case $one in WWW:)echo one: $one two: $two case $two in http://*) echo WWW= $two ;; *) echo WWW= http://$two ;; esac break ;; esac done pkg-descr I did test this briefly and it pulls out the right values for variables with and without http://. hth, Doug Unfortunately it doesn't DTRT with files terminated with DOS-style CRLF (e.g. devel/p5-Tie-Restore, others). Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: regression-test
Thierry Thomas wrote: Le Ven 20 jui 08 à 3:54:04 +0200, Garrett Cooper [EMAIL PROTECTED] écrivait : I try to enable regression-test when possible, but the current implementation is a post-build target, and some ports' testings need a post-install target. In these cases, I enclose the regression-test target between .ifdef MAINTAINER_MODE. I'd say those ports are broken; conceptually, you should be testing whether or not your port works *before* you install it, not after. Kris Agreed. Functionality verification is a requirement for acceptance in any release structure, not the other way around. That's not always so simple: - when you run the configure script, it may define some paths (e.g. DATADIR), and some files under this directory may be required for the program to be run; - some runtime dependencies may be required; - the program may be unusable without some additional steps taken into account by a pkg-install script; Apart from #2 (which I addressed previously), that just means that your regression-test target and/or port patches need to be more complicated to prepare the tests. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysutils/screen package
Philip M. Gollucci wrote: itche wrote: Chess Griffin wrote: Boris Kochergin wrote: Hi, List. I noticed that there isn't a package for sysutils/screen for 7.0. Compiling it from ports works fine, and I looked around and wasn't able to find logs relevant to it on http://pointyhat.freebsd.org/errorlogs/, so I was wondering if anyone could shed some light on why it's not available. Thanks. Despite, cy@ disagreeing with me, I *believe* this problem is local to the pointyhat build cluster. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/122545 That's fine and all, but it doesn't solve the problem. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build optimizations - please review
Pietro Cerutti wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Kris Kennaway wrote:
| **
| * NOTE TO PORT DEVELOPERS
| **
|
| Variable assignments with != are bad! Try as hard as you can to avoid
| using them -- especially in Mk/*! Every time something processes your
| makefile it will spawn a command, even if it is not relevant for the
| operation being performed. If you need to run shell commands, try to
| isolate them within a makefile target. You can avoid code duplication
| by assigning the *shell commands* (not their output) to a variable and
| inserting it into your code block.
|
| e.g. instead of
|
| --
| VARIABLE!=do some shell stuff; do some other stuff
|
| target:
| echo ${VARIABLE}
| --
|
| do this (or similar):
|
| --
| VARIABLE_CMDS=do some shell stuff; do some other stuff
|
| target:
| echo $(${VARIABLE_CMDS})
| --
|
| This defers the command execution to the point where the target runs, so
| in the case when the target is *not* run, then you avoid wasting one or
| more process executions.
Yes, in theory.
Any clue why this doesn't work?
SCHED_NAME= sysctl -n kern.sched.name
all:
~echo $(${SCHED_NAME})
Try $$(${SCHED_NAME}) (escape the $ you don't want make to process)
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: regression-test
Wesley Shields wrote: On Thu, Jun 19, 2008 at 08:54:17AM -0700, [EMAIL PROTECTED] wrote: Christian Weisgerber wrote: ... In particular, running tests of what duration would be considered appropriate? E.g., building audio/flac takes a minute here, running the tests sixteen, which I suspect would be excessive. FWIW, I started adding those regression-test targets to many ports because they are extremely useful: while trying to update to the latest coreutils I found everything apparently built but everything was actually broken. Now I am finding bugs in some ports that I thought were fine. Which is why I would recommend wrapping them in checks for MAINTAINER_MODE or something similar. This way you, as the maintainer, can turn them on when you want but they don't affect anything else. Our experience has shown that it is very common for tests to succeed when run by the maintainer, but to fail in the package cluster environment because of differences in the environment, configuration, default assumptions, etc. i.e. the regression tests found bugs, which is the entire point. We *want* regression tests to be available unconditionally -- that is why I added the hook to the package build process to run them if present. Please don't hack around this because you think you're doing us a favour :-) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kdebase3 package is missing in 7-stable
Patrick Lamaizière wrote: Hi, kdebase3 package for 7-stable/i386 is missing on the FTP. Yes. This happens from time to time when the ports or their dependencies are broken. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kdebase3 package is missing in 7-stable
Patrick Lamaizière wrote: Le Thu, 19 Jun 2008 19:08:43 +0200, Kris Kennaway [EMAIL PROTECTED] a écrit : kdebase3 package for 7-stable/i386 is missing on the FTP. Yes. This happens from time to time when the ports or their dependencies are broken. Thank you Kris. I think something is wrong because It was never uploaded since FreeBSD 7 and i don't find any error log on pointyhat. Package for amd64 seems ok. The OpenEXR port is broken, it hangs forever during the build. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: regression-test
Tom Hukins wrote: On Thu, Jun 19, 2008 at 12:35:01PM -0400, Wesley Shields wrote: Which is why I would recommend wrapping them in checks for MAINTAINER_MODE or something similar. This way you, as the maintainer, can turn them on when you want but they don't affect anything else. That's true for the OS versions and architectures that a maintainer builds on. I'm very fond of CPAN's culture of build, test then install for all modules. Sure, it takes time, but it's helped me find problems on machines I use that others, including the author, haven't encountered. I didn't know Ports had such options until this thread: I'm tempted to enable regression tests whenever I build ports to benefit from the extra sanity checking that tests provide. Please do. The only difficult situation becomes when ports require extra dependencies to run the self-tests. You can either add them unconditionally as a BUILD_DEPENDS (but this is more compilation for users who don't run the tests), or make it conditional on PACKAGE_BUILDING. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: regression-test
Thierry Thomas wrote: Le Jeu 19 jui 08 à 19:06:36 +0200, Kris Kennaway [EMAIL PROTECTED] écrivait : We *want* regression tests to be available unconditionally -- that is why I added the hook to the package build process to run them if present. Please don't hack around this because you think you're doing us a favour :-) I try to enable regression-test when possible, but the current implementation is a post-build target, and some ports' testings need a post-install target. In these cases, I enclose the regression-test target between .ifdef MAINTAINER_MODE. I'd say those ports are broken; conceptually, you should be testing whether or not your port works *before* you install it, not after. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about ports adding cronjobs
David Hawthorne wrote: I have a piece of software I've been working on that gathers stats about the local host and shoves them into rrd files, with an accompanying web front-end page that generates pretty graphs from the RRDs on demand. I have a package done up for it, and I'd like to add it to the ports tree eventually, but I'm stuck on how to get it to automagically add the cronjob to have the stats gathering script run every five minutes, and I don't know of any ports that add cronjobs off the top of my head to go look at. Is there an approved standard for doing this? It doesn't have to be as root, either, it can run under a different user. Any advice on how to get the port to add the user (and remove it properly when the port is deinstalled) properly and securely would be appreciated as well. Don't do it automatically. Provide a script that allows users to do it if they want. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: regression-test
Christian Weisgerber wrote: So I just learned that pointyhat tries to run a target regression-test as part of the build. (Somebody asked me to use that target in a port.) Is this documented somewhere? I don't know off-hand. I assume you searched the handbook? In particular, running tests of what duration would be considered appropriate? E.g., building audio/flac takes a minute here, running the tests sixteen, which I suspect would be excessive. 16 minutes is fine, the only ports that cause trouble are those that take many hours/days to build. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
INDEX build optimizations - please review
Please review and test the following patches that optimize port INDEX
builds (and as a side-effect, other recursive tree traversals). I am
particularly interested in a comparison between old and new indexes
built locally: the only diff should be in audio/festvox-hvs [1].
The patches remove most of the extraneous command executions required
for each invocation of bsd.port.mk (e.g. via 'make describe' in a port),
by replacing external command invocations with shell or make builtins,
as well as caching of constants.
Another important optimization is to use /rescue/sh instead of /bin/sh
for index builds. The former is statically linked and this is much
faster to execute.
One further change I didn't do would be to move the WWW specification
from pkg-descr into a Makefile variable (this could be done
mechanically). The new 'make describe' target runs entirely using shell
builtins apart from the need to sed pkg-descr to extract the WWW [2]
(previously 'describe' was a combination of several shell executions and
a perl script, invoked for every port).
With these patches an index build on an 8 core system drops from
796.486u 974.564s 5:25.14 544.7%28+193k 37252+719io 27pf+0w
to
642.846u 164.520s 2:31.29 533.6%67+297k 0+721io 0pf+0w
(or with statically linked sed:
637.805u 142.335s 2:27.32 529.5%71+304k 0+720io 0pf+0w
)
The new version requires 69301 forks and 68614 execs (would be ~19000
fewer of each without WWW in pkg-descr), compared to 252383 forks and
226875 execs with the current version.
The resulting index is identical except for one port [1] but generating
it is more than twice as fast (and uses 6 times less system CPU).
I am only getting ~530% CPU utilization because of contention in the
scheduler, so there is scope for going as low as 100 seconds if this
went away. Further improvements are no doubt possible but would require
profiling the work done within make(1) to see where it is spending its
time (variable setting, conditional evaluation, loop invocation, regexp
processing, etc).
**
* NOTE TO PORT DEVELOPERS
**
Variable assignments with != are bad! Try as hard as you can to avoid
using them -- especially in Mk/*! Every time something processes your
makefile it will spawn a command, even if it is not relevant for the
operation being performed. If you need to run shell commands, try to
isolate them within a makefile target. You can avoid code duplication
by assigning the *shell commands* (not their output) to a variable and
inserting it into your code block.
e.g. instead of
--
VARIABLE!= do some shell stuff; do some other stuff
target:
echo ${VARIABLE}
--
do this (or similar):
--
VARIABLE_CMDS= do some shell stuff; do some other stuff
target:
echo $(${VARIABLE_CMDS})
--
This defers the command execution to the point where the target runs, so
in the case when the target is *not* run, then you avoid wasting one or
more process executions.
Kris
[1] This patch exposed a bug: for some reason no dependencies were
previously recorded for audio/festvox-hvs! Probably because it only has
RUN_DEPENDS and the 'make describe' perl script was broken.
[2] Actually I am not happy with this but couldn't think of a way to do
it better. Having to fork the subshell costs about 60 seconds of system
time and 10 of wall time.
Index: Makefile
===
RCS file: /zoo/cvsup/FreeBSD-CVS/ports/Makefile,v
retrieving revision 1.103
diff -u -r1.103 Makefile
--- Makefile27 Sep 2007 05:36:26 - 1.103
+++ Makefile10 Jun 2008 09:56:17 -
@@ -103,6 +103,7 @@
tmpdir=`/usr/bin/mktemp -d -t index` || exit 1; \
trap rm -rf $${tmpdir}; exit 1 1 2 3 5 10 13 15; \
( cd ${.CURDIR} make -j${INDEX_JOBS} INDEX_TMPDIR=$${tmpdir}
BUILDING_INDEX=1 \
+ __MAKE_SHELL=/rescue/sh \
ECHO_MSG=${INDEX_ECHO_MSG} describe ) || \
(rm -rf $${tmpdir} ; \
if [ ${INDEX_QUIET} = ]; then \
Index: Mk/bsd.java.mk
===
RCS file: /zoo/cvsup/FreeBSD-CVS/ports/Mk/bsd.java.mk,v
retrieving revision 1.82
diff -u -r1.82 bsd.java.mk
--- Mk/bsd.java.mk 28 Oct 2007 15:09:43 - 1.82
+++ Mk/bsd.java.mk 10 Jun 2008 09:56:17 -
@@ -249,34 +249,30 @@
. endfor
# Error checking: JAVA_VERSION
+.if !defined(_JAVA_VERSION_LIST_REGEXP)
_JAVA_VERSION_LIST_REGEXP!=${ECHO_CMD} ${_JAVA_VERSION_LIST} |
${SED} s/ /\\\|/g
-_ERROR_CHECKING_JAVA_VERSION!= ${ECHO_CMD} ${JAVA_VERSION} | ${TR} \n \
- | ${GREP} -v
${_JAVA_VERSION_LIST_REGEXP} || true
-.
Re: INDEX build optimizations - please review
Pietro Cerutti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Pietro Cerutti wrote: | Kris Kennaway wrote: | | | Another important optimization is to use /rescue/sh instead of /bin/sh | | for index builds. The former is statically linked and this is much | | faster to execute. | | True, but the for is not even guaranteed to exist (WITHOUT_RESCUE in | src.conf or similar). the for??? err... the file I meant.. Yeah, I forgot to add a check for that. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build optimizations - please review
Jeremy Messenger wrote:
On Tue, 10 Jun 2008 11:45:32 -0500, Kris Kennaway [EMAIL PROTECTED] wrote:
Another important optimization is to use /rescue/sh instead of /bin/sh
for index builds. The former is statically linked and this is much
faster to execute.
I don't have INDEX in all of my systems, so I am only take a peek. What
about users that have WITHOUT_RESCUE defined or/and something different?
IMO, I think your patch should have a check on if /rescue/sh exists when
our src provides optional of WITHOUT_RESCUE and is harmless to kill the
/rescue.
--
.if exists(/rescue/sh)
__MAKE_SHELL=/rescue/sh
.else
__MAKE_SHELL=/bin/sh
.endif
--
Yeah, I will add this in the next version.
Thanks for hint on 'NOTE TO PORT DEVELOPERS' part as I didn't know about
VARIABLE!= vs $(${VARIABLE_CMDS}). /me copies it in my note.
What would be good is if someone can add it to the porter's handbook.
As for the audio/festvox-hvs issue, probably because of no executables
or files in RUN_DEPENDS:
--
RUN_DEPENDS=${PORTSDIR}/audio/festival+OGI \
${PORTSDIR}/audio/festlex-poslex \
${PORTSDIR}/audio/festlex-ogi \
${PORTSDIR}/audio/festogi-spanish
--
Ah yes, good catch. This looks like a port bug, so I don't think I need
to modify my patches.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build optimizations - please review
Alex Kozlov wrote: On Tue, Jun 10, 2008 at 06:45:32PM +0200, Kris Kennaway wrote: Please review and test the following patches that optimize port INDEX builds (and as a side-effect, other recursive tree traversals). I am particularly interested in a comparison between old and new indexes built locally: the only diff should be in audio/festvox-hvs [1]. Work on RELENG_6 only after this patch (maybe good candidate for MFC): Crap! I need :u! Without it the duplicate removal will have to be pushed into the perl script that collates the output, which means that Colin's portsnap script may be affected. The patch definitely should be MFCed though. Who committed it originally to HEAD? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build optimizations - please review
Alex Kozlov wrote:
On Tue, Jun 10, 2008 at 11:52:01PM +0200, Kris Kennaway wrote:
Alex Kozlov wrote:
On Tue, Jun 10, 2008 at 06:45:32PM +0200, Kris Kennaway wrote:
Please review and test the following patches that optimize port INDEX
builds (and as a side-effect, other recursive tree traversals). I am
particularly interested in a comparison between old and new indexes
built locally: the only diff should be in audio/festvox-hvs [1].
Work on RELENG_6 only after this patch (maybe good candidate for MFC):
Crap! I need :u! Without it the duplicate removal will have to be
pushed into the perl script that collates the output, which means that
Colin's portsnap script may be affected.
The patch definitely should be MFCed though. Who committed it
originally to HEAD?
var.c Revision 1.161 Sat Apr 8 06:59:54 2006 UTC (2 years, 2 months ago) by fjoe
Thanks, I have emailed Max. What I think I will do is add an .if
${OSVERSION} 6xx check around it, and keep the old perl script as
a fallback. In a couple of years when 6.3 is no longer supported we can
GC the old code.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: Port versions going backwards
Dear maintainers, For some time now the script that is supposed to monitor for port version strings decreasing has not been functioning (it runs but produces no output for some reason). Unfortunately this has allowed quite a few regressions to creep in. These are the ones I detected; the time interval listed is the narrowest date window found, during which the version decrease occurred (as measured by pkg_version -t). In most cases it should be clear why the version decreased by looking at commits to the port within this time window, but sometimes it may be necessary to look at other included files. If you can't work out how the decrease occurred, please let me know. Many of these can be repaired by increasing PORTREVISION, but others will require PORTEPOCH bumps. Thanks, Kris P.S. I will be rerunning this script regularly, so your expedient response to this issue is appreciated :) audio/xmms-bonk [EMAIL PROTECTED] (2008/03/23 11:56 -- 2008/03/24 19:41): 0.12_3 -- 0.12_1 chinese/bitchx [EMAIL PROTECTED] (2008/01/26 17:30 -- 2008/01/30 08:42): 1.1.0.1_5 -- 1.1.0.1_1 databases/libgda2 [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 1.2.4_4,1 -- 1.2.4_1,1 databases/libgnomedb[EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 3.0.0_2 -- 3.0.0_1 devel/automake17[EMAIL PROTECTED] (2004/06/10 01:54 -- 2007/07/28 17:54): 1.7.9_1 -- 1.7.9 devel/automake18[EMAIL PROTECTED] (2004/10/02 05:28 -- 2007/07/28 17:54): 1.8.5_2 -- 1.8.5 ftp/urlgfe [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 0.7.1_7 -- 0.7.1_1 misc/amanda-server [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 2.5.1p3_3,1 -- 2.5.1p3_1,1 misc/bidwatcher [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 1.3.17_6 -- 1.3.17_1 multimedia/xmms-status-plugin [EMAIL PROTECTED] (2008/03/25 17:39 -- 2008/03/26 08:24): 1.0_3 -- 1.0_1 security/samba-vscan[EMAIL PROTECTED] (2007/12/21 23:35 -- 2007/12/29 13:09): 0.3.6c_1 -- 0.3.6c textproc/p5-Spreadsheet-WriteExcel-FromXML [EMAIL PROTECTED] (2006/04/20 03:08 -- 2006/09/12 21:42): 1.02 -- 1.1 www/mozilla [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 1.7.13_6,2 -- 1.7.13_1,2 x11/xscreensaver-gnome [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 4.24_7 -- 4.24_1 x11-toolkits/gal2 [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 2.5.3_5 -- 2.5.3_1 x11-toolkits/gtksourceview [EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 1.8.5_3 -- 1.8.5_1 databases/py-qt4-sql[EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 devel/etoile-unitkit[EMAIL PROTECTED] (2008/05/06 13:53 -- 2008/05/12 15:53): 1.1_1 -- 0.2_1 devel/py-qt4-assistant [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 devel/py-qt4-core [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 devel/py-qt4-dbus [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_3 devel/py-qt4-designer [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 devel/py-qt4-designerplugin [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 devel/py-qt4-test [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 editors/vim6[EMAIL PROTECTED] (2008/05/30 08:14 -- 2008/06/07 08:00): 6.4.9_2 -- 6.4.9_1 games/linux-alienarena [EMAIL PROTECTED] (2007/09/07 21:31 -- 2007/09/13 17:47): 2007.604,1 -- 2007.610 graphics/py-qt4-svg [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 math/miracl [EMAIL PROTECTED] (2007/04/28 05:10 -- 2007/05/24 07:35): 5.23_3 -- 5.3.2_1 misc/py-qt4-demo[EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 -- 4.3.3_2 misc/py-qt4-doc [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070225 -- 4.3.3_1 net/mpich2 [EMAIL PROTECTED](2008/03/22 20:19 -- 2008/03/23 11:56): 1.0.6.p1,3 -- 1.0.7_1,2 net/py-qt4-network [EMAIL PROTECTED] (2007/04/13 23:41 -- 2007/04/17 23:19): 20070318 --
Re: INDEX build failed for 6.x
Pav Lucistnik wrote: Kris Kennaway píše v pá 06. 06. 2008 v 13:39 +0200: Yasuhiro KIMURA wrote: From: Erwin Lansing [EMAIL PROTECTED] Subject: INDEX build failed for 6.x Date: Fri, 6 Jun 2008 04:03:22 GMT INDEX build failed with errors: Generating INDEX-6 - please wait../a/erwin/tindex/ports/chinese/links/../../www/links/Makefile, line 75: warning: duplicate script for target pre-configure ignored pkg_info: not found pkg_info: not found pkg_info: not found pkg_info: not found Done. make_index: synce-kde-0.9.1_2: no entry for /usr/ports/archivers/libdynamite make_index: synce-kde-0.9.1_2: no entry for /usr/ports/archivers/libdynamite make_index: orange-0.3_2: no entry for /usr/ports/archivers/libdynamite make_index: orange-0.3_2: no entry for /usr/ports/archivers/libdynamite Revision 1.197 of archivers/Makefile should be reverted. Commit message says it removed archivers/dynamite, but what is really removed is the entry of archivers/libdynamite that is already connected in 1.196. Archivers/dynamite is also been removed in that revision. Can someone also fix the warnings please? The duplicate target warning will go away in few weeks when chinese/links expire. ;) I suppose that's good enough :) How about the bare pkg_info references? It seems suspicious that a port is doing that anyway. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build failed for 8.x
Erwin Lansing wrote: INDEX build failed with errors: Generating INDEX-8 - please wait../a/erwin/tindex/ports/chinese/links/../../www/links/Makefile, line 75: warning: duplicate script for target pre-configure ignored pkg_info: not found pkg_info: not found pkg_info: not found /libexec/ld-elf.so.1: Cannot open /lib/libutil.so.7 === shells/44bsd-csh failed *** Error code 1 /libexec/ld-elf.so.1: Cannot open /lib/libutil.so.7 === net/p5-Net-FTP-File failed *** Error code 1 /libexec/ld-elf.so.1: Cannot open /lib/libedit.so.6 === security/hostsentry failed *** Error code 1 *** Error code 1 Stop in /a/erwin/tindex/ports. *** Error code 1 Stop in /a/erwin/tindex/ports. 3 errors Committers on the hook: anders araujo dinoex fjoe green hq hrs mm mnag obrien olgeni pav rafan shaun sumikawa vanilla Most recent CVS update was: U comms/obexapp/files/patch-Makefile U devel/cvs+ipv6/files/patch-freebsdlocal U devel/linuxthreads/files/getlogin.c U devel/linuxthreads/files/telldir.c U devel/linuxthreads/files/ttyname.c U devel/ncurses-devel/Makefile U devel/ncurses-devel/distinfo U devel/p5-BS-Event/Makefile U devel/p5-BS-Event/distinfo U devel/p5-BS-Event/pkg-descr U devel/p5-BS-Event/pkg-plist U devel/p5-TheSchwartz/Makefile U devel/p5-TheSchwartz/distinfo U devel/p5-TheSchwartz/pkg-descr U devel/p5-TheSchwartz/pkg-plist U graphics/libqrencode/Makefile U graphics/libqrencode/distinfo U mail/libspf/files/patch-respect_cflags_and_dont_create_spfmilter_Makefile U misc/cdcollect/Makefile U misc/cdcollect/distinfo U misc/cdcollect/pkg-descr U misc/cdcollect/pkg-plist U misc/qbrew/Makefile U misc/qbrew/distinfo U misc/qbrew/files/patch-qbrew.pro U net-mgmt/netdisco/files/patch-netdisco U net-mgmt/netdisco/files/patch-netdisco.conf U net-mgmt/netdisco/files/patch-netdisco.crontab U net-mgmt/netdisco/files/patch-netdisco_apache.conf U net-mgmt/netdisco/files/patch-netdisco_apache_dir.conf U net-mgmt/netdisco/files/pkg-install.in U net-mgmt/netdisco/files/pkg-message.in U net-mgmt/p5-Nagios-Plugins-Memcached/Makefile U net-mgmt/p5-Nagios-Plugins-Memcached/distinfo U net-mgmt/p5-Nagios-Plugins-Memcached/pkg-descr U net-mgmt/p5-Nagios-Plugins-Memcached/pkg-plist U net-mgmt/p5-Nagios-Plugins-Memcached/files/patch-Makefile.PL U palm/synce-rra/files/patch-src-rra-timezone.c U print/ghostscript7/Makefile U print/ghostscript7/pkg-descr U print/ghostscript7-commfont/Makefile U print/ghostscript7-commfont/pkg-descr U print/ghostscript7-jpnfont/Makefile U print/ghostscript7-jpnfont/pkg-descr U print/ghostscript7-korfont/Makefile U print/ghostscript7-korfont/pkg-descr U print/ghostscript7-nox11/Makefile U print/ghostscript8/Makefile U print/ghostscript8/pkg-descr U print/ghostscript8-nox11/Makefile U sysutils/lookupd/files/patch-modules-dns-resolv-getaddrinfo.c U sysutils/mybashburn/Makefile U sysutils/mybashburn/distinfo U sysutils/mybashburn/pkg-descr U sysutils/mybashburn/pkg-plist U www/apache13-modssl/files/patch-apachectl U www/cocoon/files/patch-src-blocks-ajax-samples U www/cocoon/files/patch-src-blocks-forms-samples U www/py-forgethtml/files/patch-lib-forgetHTML.py Two things are going on here: 1) This raced with an installworld which is why the library went missing. 2) cvs is broken and updates the same files with each update, which is why ancient changes are showing up here. Hopefully David will fix this soon. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: adding configuration file support to pkg_install
Philip M. Gollucci wrote: Florent Thoumie wrote: This adds support for /etc/pkg.conf configuration file. Also, this adds support for naive multi-site package fetching. Any comment welcome (and appreciated). Patch is here: http://people.freebsd.org/~flz/local/ports/pkg-install-config.diff Tarball is here: http://people.freebsd.org/~flz/local/ports/pkg-install-0a553aac.tar.bz2 Hi flz, I don't quite get what the end goal is. It looks like /etc/pkg.conf is duplicating a lot of things already in /usr/ports/Mk/bsd.port.mk. Would not it be better to just have the pkg_install tools read that file instead ? packages are usually built from the ports tree, but not always, and users may use packages without a ports tree present on the local system. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compiler segfault under fbsd7?
Matthew Seaman wrote: Jeremy Chadwick wrote: On Tue, May 27, 2008 at 12:38:05PM +0200, [EMAIL PROTECTED] wrote: You are right: make buildworld exits with /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattrtab.c: In function 'make_internal_attr': /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattrtab.c:4240: internal compiler error: Segmentation fault: 11 You have CPU, motherboard, or memory problems. My vote is on memory. I've seen this on a system without *enough* memory -- when trying to do a 6.x to 7.0 upgrade compilation died in that exact place. Turned out that server hadn't been configured with a swap partition when it was originally built, and adding swap cured the problem. It's not quite the same error. The out of memory killer will kill the cc process, which displays Killed on the terminal and logs it on the console, and then it may segfault or otherwise crash, as a secondary effect. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Handling user input and package building
Paul Schmehl wrote:
I'm trying to figure out how to handle user input in package building mode.
I've got statements like this in my Makefile, and they work fine to
suppress user input from the pkg-install script:
pre-install:
.if !defined(PACKAGE_BUILDING)
@${SETENV} ${SCRIPTS_ENV} PKG_PREFIX=${PREFIX} \
${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL
.endif
However, the same syntax doesn't seem to work for the pkg-deinstall
script, which also requires user input.
.if defined(PACKAGE_BUILDING)
deinstall:
@${SETENV} ${SCRIPTS_ENV} PKG_PREFIX=${PREFIX} \
${SH} ${PKGDEINSTALL} ${PORTNAME} DEINSTALL
post-deinstall:
@${SETENV} ${SCRIPTS_ENV} PKG_PREFIX=${PREFIX} \
${SH} ${PKGDEINSTALL} ${PORTNAME} POST-DEINSTALL
.endif
One other question. The Porters Handbook says:
If your port requires user input to build, configure, or install, you
must set IS_INTERACTIVE in your Makefile.
Yet portlint says:
WARN: Makefile: [25]: use of IS_INTERACTIVE discouraged. provide batch
mode by using BATCH and/or FOR_CDROM.
What's the correct way to do this?
Avoid the requirement of interactive input at all costs.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: perl5.8 - perlio.c:2919: error: dereferencing pointer to incomplete type
Randy Bush wrote: `sh cflags optimize='-O2 -pipe -march=pentiumpro -fno-strict-aliasing' globals.o` -DPIC -fPIC globals.c CCCMD = cc -DPERL_CORE -c -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -O2 -pipe -march=pentiumpro -fno-strict-aliasing -Wall `sh cflags optimize='-O2 -pipe -march=pentiumpro -fno-strict-aliasing' perlio.o` -DPIC -fPIC perlio.c CCCMD = cc -DPERL_CORE -c -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -O2 -pipe -march=pentiumpro -fno-strict-aliasing -Wall perlio.c: In function 'PerlIOStdio_invalidate_fileno': perlio.c:2919: error: dereferencing pointer to incomplete type *** Error code 1 am i doing something wrong? cvsup, make world ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How often do pointyhat do a build?
Mark Linimon wrote: On Mon, Apr 28, 2008 at 06:41:30PM -0700, Xin LI wrote: So does it imply that pointyhat's -CURRENT would (slightly) behind the current development? Yes, it takes some amount of time to upgrade everything. Is there any way to know which __FreeBSDversion the current build is running against? Not without logging onto pointyhat and the nodes. (We do update all the nodes for a given architecture at the same time.) Here's the snapshot right now: pointyhat itself (amd64): FreeBSD 8.0-CURRENT #23: Mon Feb 11 21:22:10 UTC 2008 node gohan40 (i386):FreeBSD 8.0-CURRENT #21: Sun Feb 17 11:22:36 UTC 2008 node hammer1 (amd64): FreeBSD 8.0-CURRENT #0: Thu Apr 24 07:03:35 UTC 2008 node netra1 (sparc64): FreeBSD 7.0-CURRENT #2: Wed Aug 8 19:34:13 PDT 2007 kernel version usually isn't relevant unless you're looking at a change that broke the kernel/userland ABI. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How often do pointyhat do a build?
Kris Kennaway wrote: Mark Linimon wrote: On Mon, Apr 28, 2008 at 06:41:30PM -0700, Xin LI wrote: So does it imply that pointyhat's -CURRENT would (slightly) behind the current development? Yes, it takes some amount of time to upgrade everything. Is there any way to know which __FreeBSDversion the current build is running against? Not without logging onto pointyhat and the nodes. (We do update all the nodes for a given architecture at the same time.) Here's the snapshot right now: pointyhat itself (amd64):FreeBSD 8.0-CURRENT #23: Mon Feb 11 21:22:10 UTC 2008 node gohan40 (i386):FreeBSD 8.0-CURRENT #21: Sun Feb 17 11:22:36 UTC 2008 node hammer1 (amd64):FreeBSD 8.0-CURRENT #0: Thu Apr 24 07:03:35 UTC 2008 node netra1 (sparc64):FreeBSD 7.0-CURRENT #2: Wed Aug 8 19:34:13 PDT 2007 kernel version usually isn't relevant unless you're looking at a change that broke the kernel/userland ABI. Also the nodes are not always updated simultaneously for each architecture, it usually falls more along administrative groupings like which ones are colocated and sharing the same NFS root. The bottom line is that if you want to evaluate the impact on the ports tree of a certain change to src, contact portmgr to schedule a full build. We're happy to work with src developers to do this (ideally before the change is committed, if there is a belief that it might have a large disruptive impact). Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hang making bash in current
On Sun, Apr 27, 2008 at 04:43:58PM +0900, Randy Bush wrote: i386 extremely current. making bash checking for ranlib... ranlib checking for bison... yacc checking whether make sets $(MAKE)... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking whether byte ordering is bigendian... no checking for preprocessor stringizing operator... yes checking for working long double with more range or precision than double... yes checking for function prototypes... yes checking whether char is unsigned... no checking whether NLS is requested... yes checking for msgfmt... /usr/X11R6/bin/msgfmt checking for gmsgfmt... /usr/X11R6/bin/msgfmt checking for xgettext... /usr/X11R6/bin/xgettext checking for msgmerge... and it hangs right there Doing what? Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New portmgr member: Florent Thoumie
Soeren Straarup wrote: Hi flz and ret, On Wed, 26 Mar 2008 15:19:20 +0100 Erwin Lansing [EMAIL PROTECTED] wrote: Portmgr is pleased to announce that Florent Thoumie has accepted the challenge of being a portmgr member. Florent has been with the project for a long time and is one of our most active committers. Amongst other things, he was one of the people that worked on the complete overhaul of the X11 infrastructure with the Xorg 7.2 upgrade. He will join the other portmgr members on integrating infrastructure patches and quality assurance in addition to other portmgr tasks. Wish him luck! -erwin portmgr secretary After all that work he has done .. and then all he gets is a hat (; Congrats with yet another punishment. No truth to the rumour that the portmgr hat is conical. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel Compile Options: _KPOSIX_PRIORITY_SCHEDULING, SMP
Jim Stapleton wrote: Supposedly SMP is available by default in 7.0, but I didn't see the 'options SMP' entry in the generic config. I take it that is unnecessary for SMP support now? No, I think you are referring to the fact that sysinstall will install a kernel compiled with options SMP if run on an SMP-capable system. _KPOSIX_PRIORITY_SCHEDULING: This says it's for real time in the config. Chances are, i don't need it, but I'd like to verify. Mostly I do standard desktop stuff: KDE/gnome/xfce/ion depending on who's logged in, FireFox, kmail, OpenOffice, WINE, and probably a VM once I get one working. I do some coding (C/C++/Python, maybe some D soon), but nothing that would need real time to my knowledge. A future rebuild of this machine will act as a PVR as well. It's a standard API that some applications may need to use. There is no good reason not to include it. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 release ports packages gone missing?
Sean Bruno wrote: I guess due to the 6.3 release all the 6.2 release packages got deleted? Why delete them? Are they placed somewhere else? $ pkg_add -nr net-snmp Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/net-snmp.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/net-snmp.tbz' by URL Sean ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] They had to be removed because the master FTP site was out of space. They were moved to ftp-archive.freebsd.org. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clint port broken on 7-STABLE amd64
Steve Franks wrote: Just built /devel/clint on my vanilla 7.0 system. Appears to build and install fine, but #clint or #clint --help freezes the console, and ctrl-C initiates a core-dump. Python appears to run just fine. Talk to the clint developers and/or the maintainer. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade, recommended by 7 release notes, breaks perl
Steven Hartland wrote: Would fix this particular package but again: how many others do this? Maybe this is something that BSDPAN could / should override? It might be possible, you should talk to the BSDPAN maintainer. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc/compat6x
Sergey Matveychuk wrote: Hi. I tried to start an application on 7.0 that requires libpthread.so.2. I've installed misc/compat6x, but have a problem: /usr/local/lib/compat/libpthread.so.2: Undefined symbol __malloc_lockCould not load addin module /usr/local/lib/libtfmessbsp.so! As I can see __malloc_lock symbol is in libc.so.6 from compat6x port but does not load. Why? Any ideas how to fix it? How is libc.so.6 being loaded by the application? Is it linked explicitly or is it (incorrectly) trying to dlopen(libc.so) or similar? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc/compat6x
Sergey Matveychuk wrote: The library is not linked with libc. But dynamic loader loads libc.so.7 for libthr.so.3. kib@ has told me it's impossible to fix (we can't mix libc.so.6 and libc.so.7 in one namespace). So we should ask vendor to recompile it for 7.0 (it's security/bsp_upektfmess). Yeah, it should be marked BROKEN except on 6.x. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: timeseal-1.0 - Bad system call
peter bird wrote: Please can you help with this? pulsarity# uname -a FreeBSD pulsarity.demax.sk 7.0-RC1 FreeBSD 7.0-RC1 #1: Wed Feb 6 11:45:51 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PULS i386 pulsarity# timeseal Bad system call Use ktrace to determine what the syscall is. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make index on FBSD 5
Patrik Forsberg wrote: Hi, Trying to do a make index of the ports tree on a FBSD 5.4-RELEASE-p4 but get the following error Generating INDEX-5 - please wait..=== arabic/ae_fonts_mono failed *** Error code 1 === accessibility/accerciser failed *** Error code 1 2 errors cut text *** Error code 1 Stop in /usr/ports. *** Error code 1 Stop in /usr/ports. I have no refuse file or WITH/WITHOUT statements in make.conf. The ports tree is updated with cvsup from cvsup2.se.freebsd.org today - but been the same the past week or two. I tried erasing the two offending directories from the ports tree and did a new cvsup sync with the same result. What happens when you 'make describe' in those directories? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Different variants of the same package on ftp.FreeBSD.org
[EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 10:37:38AM +0100, Pav Lucistnik wrote: ~ $ host ftp.freebsd.org ftp.freebsd.org has address 204.152.184.73 ftp.freebsd.org has address 62.243.72.50 ftp.freebsd.org has IPv6 address 2001:6c8:6:4::7 ftp.freebsd.org has IPv6 address 2001:4f8:0:2::e ~ $ echo -e dir mathopd*\nquit | ftp ftp://204.152.184.73/pub/FreeBSD/ports/i386/packages-6-stable/All/ Connected to 204.152.184.73. 220 Welcome to freebsd.isc.org. ... -rw-r--r--1 110 100256584 Jan 24 06:20 mathopd-1.5p6.tbz ~ $ echo -e dir mathopd*\nquit | ftp ftp://62.243.72.50/pub/FreeBSD/ports/i386/packages-6-stable/All/ Connected to 62.243.72.50. 220 ftp.FreeBSD.org NcFTPd Server (licensed copy) ready. ... -rw-r--r-- 1 ftpuser ftpusers 56520 Nov 4 14:48 mathopd-1.5p6.tbz Different sizes, different dates. The November variant is broken (installed package crashes at first connection), the January variant works. I.e. half of users get the broken variant from ftp.FreeBSD.org. Local mirrors contain the broken variant. http://www.freshports.org/www/mathopd lists last commit on August 13, 2007. How, why different variants? I'm not able to find out why the files are there on the 62.243 one, but they are from 6.2 while the one from January 24 is the FreeBSD 6.3 one. The November variant crashes under 6.2-RELEASE-p1. If I build mathopd from ports under the same 6.2-RELEASE-p1 then it works. ftp-master have the January 24. Guess the mirrors are behind in mirroring the stuff. :) I already found out how to get working variant. I want to attract attention to the fact that for several months ftp.freebsd.org had the broken variant which crashes under 6.2 though building from port under my 6.2 gives working package. The mathopd port hasn't depencencies at all, one binary. How the broken variant was compiled? From the ports tree as it was around November 4 2007. Presumably the port was broken back then, and then it was fixed. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possibly unbuildable ports reminder
Stephen Montgomery-Smith wrote:
Wesley Shields wrote:
On Mon, Jan 28, 2008 at 07:45:09AM -0600, Stephen Montgomery-Smith wrote:
Bill Fenner wrote:
Dear porters,
This is just a reminder to please periodically check the list of
unbuildable ports at http://pointyhat.freebsd.org/errorlogs/ .
A list by MAINTAINER is
http://people.freebsd.org/~fenner/errorlogs/
so you can easily check the status of ports that you maintain. In
addition, the list of ports with no MAINTAINER with build problems is
http://people.freebsd.org/~fenner/errorlogs/[EMAIL PROTECTED]
Since no one is responsible for these ports, the problem won't get
fixed unless someone on this list takes the initiative.
Thanks for your help!
Bill annoying port email Fenner
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
[EMAIL PROTECTED]
What does it mean if the port's error is called mtree?
http://people.freebsd.org/~fenner/errorlogs/[EMAIL PROTECTED]
See: http://pointyhat.freebsd.org/errorlogs/ - the section entitled
Types of errors detected.
The port leaves ${PREFIX} in a state that is not consistent with the
mtree definition after pkg_delete. This usually means some files are
missing from PLIST. It could also mean that your installation scripts
create files or directories not properly deleted by the deinstallation
scripts. Another possibility is that your port is deleting some
directories it is not supposed to, or incorrectly modifying some
directory's permission.
Thank you. I believe that in this case the error lies with pointyhat.
According to the build logs of accessx, the extra files that are not
deleted are actually files installed by tk82.
accessx is extremely catholic in its requirements for which version of
tk it needs. This might be confusing pointyhat.
Sort of. In this case it is a secondary error because your port has a
broken dependency:
pkg_add tcl-8.4.16,1.tbz
skipping tcl-8.4.16,1, already added
pkg_add tk-8.4.16,2.tbz
skipping tk-8.4.16,2, already added
...
=== Installing for accessx-0.951_2
=== accessx-0.951_2 depends on executable: wish8.2 - not found
===Verifying install for wish8.2 in /usr/ports/x11-toolkits/tk82
i.e. it is depending on the 8.2 version of wish when the port is
installed, but when the index was built it requested 8.4. Something is
going wrong.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports setting UIDs/GIDs broadscape: chmod -R likely breaks things!
Peter Much wrote:
Dear all,
a couple of Ports have in the install part of their Makefiles
constructs like this:
@ ${CHOWN} -R pgsql:pgsql ~pgsql/. ;\
I perceive this as very problematic. For instance: Below ~pgsql
there at least two mounted filesystems, both with a .snap directory,
which must be GID-operator.
Furthermore, ~pgsql is a fine place fore lots of data-import- and
-export-directories, each belonging to user or group of the corresponding
foreign subsystem.
Now any time I reinstall or upgrade the port, all of this gets
destroyed, and has to be manually recreated.
Is there any way to configure such unwanted modifications to not
happen? Maybe some central switch or Makefile.local or anything
I might have overlooked, which can be added and will persist the
updating of the ports tree (simply editing these Makefiles is not
feasible as they will be updated from CVS).
If not, then I would strongly suggest that Ports maintainers
modify only and maximally those files+directories which get removed
and recreated during port upgrades.
Yes, that seems overly broad. Please bring it up with the respective
maintainers.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: packages with security vulnerabilities
P Bielecki wrote: On Jan 22, 2008 12:23 AM, P Bielecki [EMAIL PROTECTED] wrote: On Jan 21, 2008 11:57 PM, Doug Barton [EMAIL PROTECTED] wrote: Kris Kennaway wrote: I still don't understand what you claim is the problem :) We do not specially update packages like perl; rather, *every* package is frequently rebuilt and updated. If I understood the question correctly, I think the OP is asking about the frequency of rebuilding packages with security updates. In which case your answer is still correct, but leads to a new question, which is would it be possible to trigger an update for a port that has a security update sooner? Doug Kris, That's exactly what I wanted to ask. Thanks Doug. Unfortunately it's not really feasible. They will usually be updated within days anyway, on the normal schedule. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: packages with security vulnerabilities
P Bielecki wrote: Hi, freebsd-update helps me update base system, portaudit(1) reminds me everyday about security vulnerabilities in ports/packages and thanks to portupgrade(1), I keep them up to date. Quite often I build packages or use packages whenever available and share (NFS) them with my other boxes. Although building and deploying packages can be fairly simple, due to dependencies, slow network connections, hw problems or just slow machine it takes a while. What would really help me is if latest - updated packages could be available more often. How porters decide which package should be updated and available as package? Is there anything what can I do to help updating latest packages? Packages are built continuously and as fast as possible. Which package sets do you feel are being updated too slowly? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-games: hack needs -fwritable-strings
Robert Huff wrote: James Cook writes: This seems to be caused by line 170 of hack.u_init.c, which attempts to modify a string constant. SOLUTION: Add -fwritable-strings to CFLAGS in hack's Makefile. (There's already a patch that changes that line of the Makefile, so this is easy to change.) Has something changed in the definition of correctly written code while I was away at the funny farm? Why is the solution not Don't modify a costant.? This code has been largely untouched since the 1980s :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pointyhat is building for 5.5 but claiming 8.0
Boris Samorodov wrote: On Wed, 09 Jan 2008 00:28:45 +0100 Kris Kennaway wrote: Pav Lucistnik wrote: Boris Samorodov píše v st 09. 01. 2008 v 02:16 +0300: On Tue, 08 Jan 2008 23:10:45 +0100 Pav Lucistnik wrote: No, the port is using sysctl(2) to query the OS version which cannot be wrapped. Hm, ports-mgmt/tinderbox masks it somehow... And doesn't get an error for this port. The FreeBSD version inside the tinderbox is same as the host? OK, I found the difference. The port builds for all FreeBSD version except 5.x. The same is for ports-mgmt/tinderbox. Thus I think that there is something that was not MFS'd to 5-STABLE that causes the difference. For now I'm going to mark the port as IGNORE for OSVERSION 60. A question to portmgr@: Do you have any objections? It would be nice to know what exactly is going on in there. Yeah, I can't imagine what it would be, unless it is using uname(1) or (3) and 5.x doesn't have the environment variable overrides...but in that case hundreds of other things would break. I stepped a little bit further. Seems that the port (?) does not respect UNAME_r at 5.x (I have only 5.4-STABLE to test at): - # echo $UNAME_r UNAME_r: Undefined variable. # uname -srm FreeBSD 5.4-STABLE i386 # pwd /usr/ports/devel/py-lxml # make UNAME_r=9.0-FUTURE | grep freebsd creating build/lib.freebsd-5.4-STABLE-i386-2.4 creating build/lib.freebsd-5.4-STABLE-i386-2.4/lxml copying src/lxml/_elementpath.py - build/lib.freebsd-5.4-STABLE-i386-2.4/lxml copying src/lxml/ElementInclude.py - build/lib.freebsd-5.4-STABLE-i386-2.4/lxml copying src/lxml/sax.py - build/lib.freebsd-5.4-STABLE-i386-2.4/lxml copying src/lxml/__init__.py - build/lib.freebsd-5.4-STABLE-i386-2.4/lxml creating build/temp.freebsd-5.4-STABLE-i386-2.4 creating build/temp.freebsd-5.4-STABLE-i386-2.4/src creating build/temp.freebsd-5.4-STABLE-i386-2.4/src/lxml cc -fno-strict-aliasing -DNDEBUG -O -pipe -march=pentiumpro -DTHREAD_STACK_SIZE=0x2 -O -pipe -march=pentiumpro -fPIC -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include/python2.4 -c src/lxml/etree.c -o build/temp.freebsd-5.4-STABLE-i386-2.4/src/lxml/etree.o -w ^C interrupted # - Other FreeBSD versions (didn't check 6.x but assume the same): - # echo $UNAME_r UNAME_r: Undefined variable. # uname -srm FreeBSD 8.0-CURRENT i386 # pwd /usr/ports/devel/py-lxml # make UNAME_r=9.0-FUTURE | grep freebsd creating build/lib.freebsd-9.0-FUTURE-i386-2.5 creating build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml copying src/lxml/sax.py - build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml copying src/lxml/builder.py - build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml copying src/lxml/htmlbuilder.py - build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml copying src/lxml/_elementpath.py - build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml copying src/lxml/__init__.py - build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml copying src/lxml/ElementInclude.py - build/lib.freebsd-9.0-FUTURE-i386-2.5/lxml creating build/temp.freebsd-9.0-FUTURE-i386-2.5 creating build/temp.freebsd-9.0-FUTURE-i386-2.5/src creating build/temp.freebsd-9.0-FUTURE-i386-2.5/src/lxml cc -DNDEBUG -O2 -fno-strict-aliasing -pipe -D__wchar_t=wchar_t -DTHREAD_STACK_SIZE=0x2 -O2 -fno-strict-aliasing -pipe -fPIC -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include/python2.5 -c src/lxml/etree.c -o build/temp.freebsd-9.0-FUTURE-i386-2.5/src/lxml/etree.o -w ^Cinterrupted # - The same results are for adding MAKE_ENV+= UNAME_r=9.0-FUTURE to the port's Makefile. Yes, 5.4 is likely too old. How about 5.5? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pointyhat is building for 5.5 but claiming 8.0
Boris Samorodov wrote: On Tue, 08 Jan 2008 23:10:45 +0100 Pav Lucistnik wrote: Boris Samorodov píše v st 09. 01. 2008 v 00:45 +0300: No, the port is using sysctl(2) to query the OS version which cannot be wrapped. Hm, ports-mgmt/tinderbox masks it somehow... And doesn't get an error for this port. The FreeBSD version inside the tinderbox is same as the host? No, the versions are different. This is common in the python world. It needs to use uname(1) or uname(3) or OSVERSION. The port itself (at the Makefile) uses uname -r. There is something weird though. Not specific to this port - this is an issue with easydistutils or whatsthename of that thing that does eggs. But not all of python ports with eggs does not build at pointyhat. Err, I mean very few python ports with eggs get errors... They have often been the cause of failure but someone apparently knows how to fix them :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pointyhat is building for 5.5 but claiming 8.0
Boris Samorodov wrote: On Wed, 09 Jan 2008 00:28:45 +0100 Kris Kennaway wrote: Pav Lucistnik wrote: Boris Samorodov píše v st 09. 01. 2008 v 02:16 +0300: On Tue, 08 Jan 2008 23:10:45 +0100 Pav Lucistnik wrote: No, the port is using sysctl(2) to query the OS version which cannot be wrapped. Hm, ports-mgmt/tinderbox masks it somehow... And doesn't get an error for this port. The FreeBSD version inside the tinderbox is same as the host? OK, I found the difference. The port builds for all FreeBSD version except 5.x. The same is for ports-mgmt/tinderbox. Thus I think that there is something that was not MFS'd to 5-STABLE that causes the difference. For now I'm going to mark the port as IGNORE for OSVERSION 60. A question to portmgr@: Do you have any objections? It would be nice to know what exactly is going on in there. Yeah, I can't imagine what it would be, unless it is using uname(1) or (3) and 5.x doesn't have the environment variable overrides...but in that case hundreds of other things would break. The port is using uname -r at the Makefile: - OSRELEASE!=/usr/bin/uname -r - WBR Yes, but that alone should be fine unless the above. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port Version via pkg_add
Jeremy Chadwick wrote: On Tue, Jan 01, 2008 at 08:10:12PM -0800, Jason C. Wells wrote: How does pkg_add determine what version of a port to add when 'pkg_add -Kr' is used? pkg_add calls getosreldate(3) to obtain the integer value of the release of FreeBSD running on the machine. The list of paths to fetch from are hard-coded based on range comparisons for the above reldate value. See src/usr.sbin/pkg_install/add/main.c for a list. How can I make pkg_add use 6.3 packages instead of 6.2? You run pkg_add with a URL that contains packages-6.3-release instead of packages-6.2-release, e.g.: pkg_add -r ftp://ftp4.freebsd.org/pub/FreeBSD/ports/i386/packages-6.3-release/Latest/whatever.tbz Or just set one of the various env variables that controls fetch location, see the manpage. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unknown build error
Piotr wrote: hi I try to install a packet from ports using portinstall: # portinstall -f net/p5-Net-Pcap but get the following error: [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 651 packages found (-0 +1) . done] ** Listing the failed packages (*:skipped / !:failed) ! net/p5-Net-Pcap (unknown build error) --- Packages processed: 2 done, 0 ignored, 0 skipped and 1 failed howto solve this problem ? First show us the actual error :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unknown build error
Piotr wrote: # cd /usr/ports/net/p5-Net-Pcap # make install clean === Building for p5-Net-Pcap-0.15_1 Makefile out-of-date with respect to /usr/local/lib/perl5/5.8.8/mach/Config.pm /usr/local/lib/perl5/5.8.8/mach/CORE/config.h Cleaning current config before rebuilding Makefile... make -f Makefile.old clean /dev/null 21 /usr/local/bin/perl5.8.8 Makefile.PL INSTALLDIRS=site CC=cc CCFLAGS=-O2 -fno-strict-aliasing -pipe PREFIX=/usr/local INSTALLPRIVLIB=/usr/local/lib INSTALLARCHLIB=/usr/local/lib looking for -lpcap... yes checking for pcap_lib_version() in -lpcap... yes detecting available functions... ok WARNING: LICENSE is not a known parameter. Checking if your kit is complete... Looks good 'LICENSE' is not a known MakeMaker parameter name. Writing Makefile for Net::Pcap == Your Makefile has been rebuilt. == == Please rerun the make command. == false *** Error code 1 Stop in /usr/ports/net/p5-Net-Pcap/work/Net-Pcap-0.15. *** Error code 1 Stop in /usr/ports/net/p5-Net-Pcap. This often means your clock is wrong. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unknown build error
Piotr wrote: which clock you mean ? # date Thu Jan 3 02:41:21 CET 2008 --- On Wed 01/02, Kris Kennaway [EMAIL PROTECTED] wrote: From: Kris Kennaway [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-ports@freebsd.org Date: Thu, 03 Jan 2008 02:31:25 +0100 Subject: Re: unknown build error Piotr wrote: # cd /usr/ports/net/p5-Net-Pcap # make install clean === Building for p5-Net-Pcap-0.15_1 Makefile out-of-date with respect to /usr/local/lib/perl5/5.8.8/mach/Config.pm /usr/local/lib/perl5/5.8.8/mach/CORE/config.h Cleaning current config before rebuilding Makefile... make -f Makefile.old clean /dev/null 21 /usr/local/bin/perl5.8.8 Makefile.PL INSTALLDIRS=site CC=cc CCFLAGS=-O2 -fno-strict-aliasing -pipe PREFIX=/usr/local INSTALLPRIVLIB=/usr/local/lib INSTALLARCHLIB=/usr/local/lib looking for -lpcap... yes checking for pcap_lib_version() in -lpcap... yes detecting available functions... ok WARNING: LICENSE is not a known parameter. Checking if your kit is complete... Looks good 'LICENSE' is not a known MakeMaker parameter name. Writing Makefile for Net::Pcap == Your Makefile has been rebuilt. == == Please rerun the make command. == false *** Error code 1 Stop in /usr/ports/net/p5-Net-Pcap/work/Net-Pcap-0.15. *** Error code 1 Stop in /usr/ports/net/p5-Net-Pcap.This often means your clock is [EMAIL PROTECTED] mailing listhttp://lists.freebsd.org/mailman/listinfo/freebsd-portsTo unsubscribe, send any mail to [EMAIL PROTECTED] ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! Makefile out-of-date with respect to /usr/local/lib/perl5/5.8.8/mach/Config.pm What is the timestamp on that file? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unknown build error
Piotr wrote: and how is the command to find out the timestamp of this file ? --- On Wed 01/02, Kris Kennaway [EMAIL PROTECTED] wrote: From: Kris Kennaway [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-ports@freebsd.org Date: Thu, 03 Jan 2008 02:52:48 +0100 Subject: Re: unknown build error Piotr wrote: which clock you mean ? # date Thu Jan 3 02:41:21 CET 2008--- On Wed 01/02, Kris Kennaway [EMAIL PROTECTED] wrote: From: Kris Kennaway [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: freebsd-ports@freebsd.org Date: Thu, 03 Jan 2008 02:31:25 +0100 Subject: Re: unknown build error Piotr wrote: # cd /usr/ports/net/p5-Net-Pcap # make install clean === Building for p5-Net-Pcap-0.15_1 Makefile out-of-date with respect to /usr/local/lib/perl5/5.8.8/mach/Config.pm /usr/local/lib/perl5/5.8.8/mach/CORE/config.h Cleaning current config before rebuilding Makefile... make -f Makefile.old clean /dev/null 21 /usr/local/bin/perl5.8.8 Makefile.PL INSTALLDIRS=site CC=cc CCFLAGS=-O2 -fno-strict-aliasing -pipe PREFIX=/usr/local INSTALLPRIVLIB=/usr/local/lib INSTALLARCHLIB=/usr/local/lib looking for -lpcap... yes checking for pcap_lib_version() in -lpcap... yes detecting available functions... ok WARNING: LICENSE is not a known parameter. Checking if your kit is complete... Looks good 'LICENSE' is not a known MakeMaker parameter name. Writing Makefile for Net::Pcap == Your Makefile has been rebuilt. == == Please rerun the make command. == false *** Error code 1 Stop in /usr/ports/net/p5-Net-Pcap/work/Net-Pcap-0.15. *** Error code 1 Stop in /usr/ports/net/p5-Net-Pcap.This often means your clock is [EMAIL PROTECTED] mailing listhttp://lists.freebsd.org/mailman/listinfo/freebsd-portsTo unsubscribe, send any mail to [EMAIL PROTECTED] ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! Makefile out-of-date with respect to /usr/local/lib/perl5/5.8.8/mach/Config.pmWhat is the timestamp on that file?Kris ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ls -l ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: php5-bz2-5.2.5
Darrell Betts wrote:
I am receiving this error when trying to compile php5
Makefile, line 588: warning: duplicate script for target
main/internal_functions.lo ignored
/bin/sh /usr/ports/lang/php5/work/php-5.2.5/libtool --silent
--preserve-dup-deps --mode=compile cc -Iext/date/lib -Iext/date/
-I/usr/ports/lang/php5/work/php-5.2.5/ext/date/ -DPHP_ATOM_INC
-I/usr/ports/lang/php5/work/php-5.2.5/include
-I/usr/ports/lang/php5/work/php-5.2.5/main
-I/usr/ports/lang/php5/work/php-5.2.5 -I/usr/local/include/libxml2
-I/usr/local/include -I/usr/ports/lang/php5/work/php-5.2.5/ext/date/lib
-I/usr/ports/lang/php5/work/php-5.2.5/TSRM
-I/usr/ports/lang/php5/work/php-5.2.5/Zend-O2 -fno-strict-aliasing
-pipe -prefer-non-pic -c
/usr/ports/lang/php5/work/php-5.2.5/ext/date/lib/parse_date.c -o
ext/date/lib/parse_date.lo
cc: Internal error: Killed: 9 (program cc1)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
{standard input}: Assembler messages:
{standard input}:10028: Warning: end of file not at end of a line;
newline inserted
*** Error code 1
Stop in /usr/ports/lang/php5/work/php-5.2.5.
*** Error code 1
Stop in /usr/ports/lang/php5.
*** Error code 1
Stop in /usr/ports/lang/php5.
Running freebsd 6.2
Thanks for looking into this.
This usually means your machine ran out of swap during the compile. Add
more RAM, more swap, try reducing the optimization level, or just use
the precompiled package.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Package Building in the Large
Jason C. Wells wrote: I have been toying with a variety of package building methods lately. My latest effort involves looking into the Third Party Release Engineering documented here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng-packages/index.html. Where do I start if I am looking for package building tools that the FreeBSD project uses for burning onto ROMs? Is ports/Tools/scripts/release the right place? The dates on the files there seem stale. ports/Tools/portbuild/scripts/ What I am trying to do is to build 30 or so packages including the big ones like X, kde, gnome, plus all of their dependencies on a build host and then use pkg_add on various machines. I have had a variety of difficulties with all of the methods I have used thus far (portmaster, portupgrade, homegrown). Probably you want the tinderbox port though, unless you need to distribute across many build hosts. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4203:31337 (possible exploit?)
Jeremy Chadwick wrote: On Sat, Nov 10, 2007 at 03:25:57PM +0100, Mike -freebsd wrote: Guys, is anyone else seeing this? drwxr-xr-x 69 4203 31337 1536 Nov 9 13:59 ports I see this on three of four FreeBSD 7 boxes and only on /usr/ports/ (why...?). Anyone else? Four different boxes of ours: $ uname -r ls -ld /usr/ports 6.2-STABLE drwxr-xr-x 69 root wheel 2048 10 Nov 02:14 /usr/ports/ $ uname -r ls -ld /usr/ports 6.3-PRERELEASE drwxr-xr-x 69 root wheel 1536 10 Nov 02:12 /usr/ports/ $ uname -r ls -ld /usr/ports 7.0-PRERELEASE drwxr-xr-x 69 root wheel 1536 7 Nov 02:24 /usr/ports/ $ uname -r ls -ld /usr/ports 7.0-BETA2 drwxr-xr-x 69 root wheel 1536 10 Nov 02:19 /usr/ports/ Sounds like you may have a security problem (re: 31337 GID). If that's the case, I would strongly advocate formatting + reinstalling those machines. I asked because that is the uid/gid used on pointyhat ;) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4203:31337 (possible exploit?)
Mike -freebsd wrote: On Nov 10, 2007 5:28 PM, Kris Kennaway [EMAIL PROTECTED] wrote: Sounds like you may have a security problem (re: 31337 GID). If that's the case, I would strongly advocate formatting + reinstalling those machines. I asked because that is the uid/gid used on pointyhat ;) Kris Well, I've dug up all available backups and what I can tell is that those uid/gid propagated with the rest of the ports tree from a main box used here for builds, installations and updates to the whole network. Stupid me had weekly noid reports disabled on all of them, except the last one added recently that finally caught it. The problem was there present for at least three, possibly four months... BUT I'm 95% sure that the main ports three was never downloaded via anything else than c[v]sup + supfile with default host set to eiter ftp.freebsd.org, or one of the official mirrors, for a past few years. I wish I could tell you more, but I see nothing even remotely connected to pointyhat, as there is no point of using any other than official ports repo for productional machines. OTOH, you wont believe how glad I was to hear that those are pointyhat IDs.. The 31337 scared the shit ot of me :( Well the only possibility I can think of is if you installed from a ports.tar.gz downloaded from the FTP site, and extracted with the tar -p option that preserves ownership. Actually that doesn't make sense either because that tarball isn't sourced from pointyhat anyway. In case it jogs any memories, 4203 is the uid used for managing the sparc64 package builds (and gid 31337 is for portmgr ;-). Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Major changes since 6.2?
What are some of the major changes to ports/ported applications since 6.2-RELEASE (01/2007)? I am in the process of putting together a talk and would like to mention some of the highlights. The main ones are xorg 7.3, KDE 3.5.7 and GNOME 2.18.3. Have there been any other major changes of interest to end users over the past year? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Smarteiffel is marked broken but is not
Patrick Lamaiziere wrote: Le Mon, 15 Oct 2007 02:18:28 +0200, Kris Kennaway [EMAIL PROTECTED] : Hi, lang/smarteiffel is marked BROKEN= does not install on FreeBSD = 7 but it builds and installs fine, and runs fine too on 7.0-PRERELEASE/i386 Check the error log on http://pointyhat.freebsd.org then try to determine why you are not seeing that error on your system. In the pointyhat report (I found it this morming, but can't find it now), the SmartEiffel's installation program crashs with Eiffel program crashs at runtime. That's all, it can be a compiler problem or a bug into the installation program. So I don't know. Just to test, I've setup a tinderbox on my PC (7.0/i386) and SmartEiffel builds fine. OK, someone will have to dig deeper then to understand the cause. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Smarteiffel is marked broken but is not (maybe!)
Patrick Lamaiziere wrote: Le Tue, 16 Oct 2007 22:27:16 +0200, Kris Kennaway [EMAIL PROTECTED] : lang/smarteiffel is marked BROKEN= does not install on FreeBSD = 7 but it builds and installs fine, and runs fine too on 7.0-PRERELEASE/i386 Check the error log on http://pointyhat.freebsd.org then try to determine why you are not seeing that error on your system. In the pointyhat report (I found it this morming, but can't find it now), the SmartEiffel's installation program crashs with Eiffel program crashs at runtime. That's all, it can be a compiler problem or a bug into the installation program. So I don't know. Just to test, I've setup a tinderbox on my PC (7.0/i386) and SmartEiffel builds fine. OK, someone will have to dig deeper then to understand the cause. I compiled the install program with full assertions and it crashs with a run-time stack dump. Looking the code it seems related to the memory management by SmartEiffel (it is not good because there is a garbage collector). So may be it is broken. I will check it with FreeBSD 6.2 and another C compiler and try to get more informations. Try building it normally but with MALLOC_OPTIONS=AJ. This is enabled for port builds (and by default in CURRENT) and sometimes catches application bugs. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports using gcc 4.2 under FreeBSD 6.2-RELEASE
Naram Qashat wrote: I was wondering if it would be possible to test if a port would work properly with GCC 4.2 would help test for FreeBSD 7-CURRENT if I use the lang/gcc42 port while under 6.2-RELEASE. I want to test and see what does and doesn't compile, maybe to see if I could help the ports tree for 7-CURRENT before I try to move to 7-CURRENT myself. You don't need to test to see whether or not they compile, hundreds of them that do not compile are already marked BROKEN. What is needed is someone to fix them, and that you can help with using the gcc42 port. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Smarteiffel is marked broken but is not
Patrick Lamaiziere wrote: Hi, lang/smarteiffel is marked BROKEN= does not install on FreeBSD = 7 but it builds and installs fine, and runs fine too on 7.0-PRERELEASE/i386 Check the error log on http://pointyhat.freebsd.org then try to determine why you are not seeing that error on your system. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compat-6x does not work when kernel has NO_KSE
Jiawei Ye wrote: On 9/11/07, LI Xin [EMAIL PROTECTED] wrote: Jiawei Ye wrote: Hi, This hit me when I tried bootstrapping JDK builds on a -current with Diablo JDK1.5. Running java -version returns Fatal error 'kse_create() failed ' at line 444 in file /usr/src/lib/libpthread/thread/thr_kern.c (errno = 2) Any workarounds for this? Will mapping libpthread.so.2 to libthr.so.2 work? Cheers, -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - The Power to Serve! Unfortunately no, because symbol versioning is already in the system. I guess this situation is quite stuck unless NO_KSE is removed. Jiawei How does symbol versioning affect this? Are you saying that libmap no longer works with pre-7 libraries? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build failed for 5.x
Sergey Matveychuk wrote: Erwin Lansing wrote: INDEX build failed with errors: Generating INDEX-5 - please wait..pkg_info: not found pkg_info: not found pkg_info: not found Makefile, line 60: warning: /usr/sbin/pkg_info -O x11-servers/XFree86-4-Server 2/dev/null | /usr/bin/grep Server- || /usr/sbin/pkg_info -O x11-servers/xorg-server 2/dev/null | /usr/bin/grep server- || /usr/sbin/pkg_info -qO x11-servers/xorg-server-snap 2/dev/null returned non-zero status /a/erwin/tindex/ports/x11/nvidia-driver-71xx/../nvidia-driver/Makefile, line 60: warning: /usr/sbin/pkg_info -O x11-servers/XFree86-4-Server 2/dev/null | /usr/bin/grep Server- || /usr/sbin/pkg_info -O x11-servers/xorg-server 2/dev/null | /usr/bin/grep server- || /usr/sbin/pkg_info -qO x11-servers/xorg-server-snap 2/dev/null returned non-zero status /a/erwin/tindex/ports/x11/nvidia-driver-96xx/../nvidia-driver/Makefile, line 60: warning: /usr/sbin/pkg_info -O x11-servers/XFree86-4-Server 2/dev/null | /usr/bin/grep Server- || /usr/sbin/pkg_info -O x11-servers/xorg-server 2/dev/null | /usr/bin/grep server- || /usr/sbin/pkg_info -qO x11-servers/xorg-server-snap 2/dev/null returned non-zero status Done. Please add /usr/sbin/pkg_info to index-5 build server :) It is there, of course. Some of the errors appear to be because it's called without the full path, and the rest are pkg_info itself returning failure because of some bogus calls. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openoffice crashes the whole system
h wrote: I've had this bug twice already ... When pasting from a selection made on a website (typically, a confirmation page after ordering something online, because I have no printer, and I'm too lazy to try to print from popups), openoffice first hangs, then eventually X goes black and the whole system reboots and gets in to a background filesystem check after the boot ... Here's my config: - FreeBSD 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Aug 22 00:24:58 CEST 2007 i386 openoffice.org-2.3.20070822 kde-3.5.7 768mb ram 1.5G swap is this error known? No. It could have various causes including a bug in your X driver, bad hardware on your system, or a bug in FreeBSD. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compat-6x does not work when kernel has NO_KSE
Jiawei Ye wrote: On 9/12/07, Jiawei Ye [EMAIL PROTECTED] wrote: [/usr/local/diablo-jdk1.5.0/jre/bin/java] libpthread.so.2 libthr.so Changing this to libthr.so.2 fixes the problem. Sorry about the noise. Regards, Jiawei Thanks, that's very useful to know. In the future we will be removing KSE support, so it is good to know that libthr is a suitable replacement. Well, I guess only for shared binaries :( Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: compat-6x does not work when kernel has NO_KSE
Timur I. Bakeyev wrote: On Wed, Sep 12, 2007 at 10:21:59AM -0400, Vivek Khera wrote: On Sep 12, 2007, at 5:37 AM, Jiawei Ye wrote: On 9/12/07, Jiawei Ye [EMAIL PROTECTED] wrote: [/usr/local/diablo-jdk1.5.0/jre/bin/java] libpthread.so.2 libthr.so Changing this to libthr.so.2 fixes the problem. Sorry about the noise. curious... on 6.1/6.2 I *must* use libpthread as the threading library for diablo jdk. it throws hotspot compiler errors at random if I map it to libthr. I second Vivek here - there are some weird problems with compiler on FreeBSD 6.x amd64 if you use libthr as a threading library. It's difficult to say - why, but the effect was noted both by me and Vivek. So, beware, there are dragons there. But do they apply to a 6.x binary running on 7.0? i.e. are you describing a 6.x kernel bug or a 6.x libthr bug? Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.port.options.mk status
Dmitry Marakasov wrote: * Pav Lucistnik ([EMAIL PROTECTED]) wrote: It's possible to use this feature, but only on -CURRENT and -STABLE FreeBSD systems newer than certain date. No existing release supports it - it will be supported in upcoming 6.3 and 7.0. Erm, isn't ports code (more or less) release-independent? What's missing in existing FreeBSD versions that's needed to support options.mk? The make only looks into /usr/share/mk for includes, until told otherwise. bsd.port.options.mk is included before bsd.port.pre.mk, so it can't be found. Base system was modified to install stub of the same name into /usr/share/mk to workaround this problem. Understood. Then we really have to wait till 5.5 and 6.2 EOL to use options.mk... That's a bit strange to wait multiple years for an useful feature, aren't there any workaround planned? I have some ideas on how to construct a working time machine, but I just need some seed capital :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bad line in Makefile for /usr/ports/audio/mbrolavox
[EMAIL PROTECTED] wrote:
Dear [EMAIL PROTECTED]
I am using the PORTS supplied with PCBSD 1.4RC on CD2 . I have
updated my PORTS recently.
I do not know where this sytem gets the PORTS from but anyway
..
There is a bug in this Makefile (
/usr/ports/audio/mbrolavox/Makefile ) which will show up if you do
#cd /usr/ports
#make index
or
#cd /usr/ports/audio/mbrolavox
#make maintainer
The output shows
madrid# make index
Generating INDEX-6 - please wait..cut: stdin: Illegal byte sequence
Makefile, line 32: warning: /usr/bin/cut -f 1 -d '|'
/usr/ports/audio/mbrolavox/voices
.conf returned non-zero status
This arises because of a strange character in the name of an Icelandic
person in file voices.conf
Suggest you change the cut line to say instead -
awk -F'|' '{print $1}' voices.conf
( Incidently I wonder if this is actually a bug incut . I would
think it should concern itself only with the
divider character )
Do you have a non-default locale set?
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any standard method to fetch a port's sources from svn (or cvs, etc) ?
Luigi Rizzo wrote:
as the subject says, i was wondering if there is any standard method
to fetch the sources for a port from a Subversion (or CVS or other
scm) repository.
Right now i am doing it with the following sequence
(the use of update vs checkout is because originally i
fetched into distfiles, not ${WRKSRC}, and later copied
the source to WRKSRC)
REMOTE_REPO= http://svn.foo.bar/svn/xyz
REPO_CMD= \
if [ -f xyz ] ; then \
svn update ${REMOTE_REPO} . ; else \
svn checkout ${REMOTE_REPO} . ; fi
do-fetch:
${MKDIR} -p ${WRKSRC}
(cd ${WRKSRC}; ${REPO_CMD} )
but there might be better ways, and perhaps if this is a common
pattern it may be worth having generic support for it ?
It is recommended not to do this. Some of our users are behind
firewalls and cannot fetch except via HTTP and FTP. Instead, you need
to create your own tarball of the sources checked out from the VCS,
possibly using a helper makefile target that fetches from VCS and
creates the tarball for republication by you on MASTER_SITE_LOCAL.
Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/116078: bsd.port.mk - Handling of PREFIX doesn't work as documented
Markus Hitter wrote: Am 04.09.2007 um 17:08 schrieb Kris Kennaway: To reiterate: in most but not all configurations, users who set PREFIX to a nonstandard location should also set LOCALBASE to the same location. If any documentation needs to be corrected to clarify this, please redirect your PR as a documentation request. Already done: http://www.freebsd.org/cgi/query-pr.cgi?pr=116080 I'll commit the results of the recent discussion soon. Markus Thanks, Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system and umask
martinko wrote: Marcus Reid wrote: Hi, I had my umask set to 007 and installed some ports, and it broke a lot of things. Some ports seem to install files with correct permissions, while others install files with the default umask. Worse, one port even changed the perms on /usr/local/lib to 770, which made my system unusable until I booted into single and fixed it. Should the ports system check for this and correct the umask before installing files with bad permissions? Thanks, Marcus Hallo, We have similar problems here -- default umask is set to 027 and therefore one needs to always remember changing it to 022 prior installing any ports or packages. Been bitten many times because of this. :-\ Martin There is an argument that if you set the umask then you are getting exactly what you ask for :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has it ever been possible to build all of gnome or gnome2 at once?
Lars Eighner wrote: Today it muine that won't build, but it always something. And make readmes are still broken. Yes, of course. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INDEX build failed for 5.x
On Wed, Aug 15, 2007 at 11:52:39AM +, Erwin Lansing wrote: INDEX build failed with errors: Generating INDEX-5 - please wait.. Done. make_index: tme-0.4_3: no entry for /usr/ports/devel/pkg-config I think this is because pointyhat's / filled up, sorry. Kris pgpLfYZNfjAcS.pgp Description: PGP signature
