Re: portsnap and local patches
On 3/14/07, Nate Eldredge [EMAIL PROTECTED] wrote: Hi all, portsnap is a very nice way to keep your ports tree in sync, but it has the disadvantage that it keeps your ports tree in sync :) If you make local changes (e.g. adding a patch) they get clobbered. Does anyone know of a convenient way to keep ports up to date while preserving local patches? One way to keep your local changes is to use cvs to checkout and update the ports tree, you then make your modifications to the port. You will need to fix any conflicts manually between an updated port and your changes. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we are attempting to notify maintainers of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc3.4, which is much stricter about such things as function declarations, literal strings constants that continue over several physical lines, and forcing the deprecation of antique header files such as varargs.h (we should now be using stdargs.h). The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. If you need help in one or more build environments that you do not have access to, please ask for help on the freebsd-ports mailing list. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 4.x/5.x/6.x with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: biology/biojava broken because: Does not build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2007030306/biojava-1.5.b,1.log (Mar 5 03:36:11 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=biojava portname: biology/tinker broken because: Unfetchable build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2007022216/tinker-4.2.20040908_1.log (Feb 26 20:10:06 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=tinker portname: chinese/gbfs broken because: fails to patch - Included patches are broken build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=gbfs portname: chinese/tatter-tools broken because: Incorrect pkg-plist build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2007031101/zh-tatter-tools-1.0.6.1.log (Mar 4 14:41:17 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=tatter-tools portname: chinese/xemacs broken because: Does not build even with fix for -lxpg4 build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.5.2007021416/zh-xemacs-20.4_2.log (Feb 9 16:46:27 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=xemacs portname: databases/postgis-jdbc broken because: Does not build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2007022216/postgis-jdbc-1.1.1.log (Feb 26 17:48:32 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgis-jdbc portname: deskutils/yank broken because: Incomplete pkg-plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=yank portname: devel/php-dbg broken because: Does not compile build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.7.2007022216/php-dbg-2.11.30.log (Mar 2 11:50:04 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=php-dbg portname: games/hlserver-cs broken because: Incomplete fetch instructions build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=hlserver-cs portname: games/hlserver-dod broken because: Incomplete fetch instructions build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=hlserver-dod portname: japanese/gnomelibs broken because: Does not compile on FreeBSD 5.X and above build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2007030306/ja-gnome-libs-1.4.2_6.log (Mar 4 22:20:45 UTC 2007) overview:
FreeBSD ports that you maintain which are currently marked forbidden
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we are attempting to notify maintainers of ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of the port, including errors seen on the build farm, is included below. portname: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=miscportname=compat3x If this problem is one that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openssh-portable upgrade.
Stefan Lambrev wrote: After upgrade from openssh from 4.5 to 4.6 I'm unable to login using password authentication. Neither with RSA keys. After putting PasswordAuthentication yes in sshd_conf I'm able to login using username/password, Idem. but this is built-in password authentication and skips PAM? Yes, it should be so. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Possibly unbuildable ports reminder
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]
Gfortran migration status is now `stablize'
Dear maintainers (who uses/have used FORTRAN in your ports) According to http://people.freebsd.org/~maho/gfortran/gfortran.html , gfortran migration is almost done. Except for ports/science/hdf, and still there are some build issues. I'd like to move the status to stabilize and wait for ~one month. After the stabilization period is over, we are planning to add a knob like USE_FORTRAN=yes [gfortran42(default), gfortran43, ifort, g95, gfortran41, f77, g77-34] and change the Makefile again for simpler Makefile. To do so, I must change some of /usr/port/Mk/*.mk files beforehand, and I'll announce again when we are ready. Discussion for changes are very welcome. BTW: I'll be unavailable until mid of April. I'm too busy in these days. Hope I can answer your e-mails immediately. Greg: your port is broken for FreeBSD 7, so we should add something...but I as wrote, your port doesn't build for me. So I cannot check. Help is really appreciated. Many thanks for your patience, and cooperation. All the best, -- Nakata Maho ([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: Why so many tcl's and tk's
Stephen Montgomery-Smith wrote / napísal(a): Are the different versions of tcl and tk really not backwards compatible with earlier versions? I can guess that there have been heated conversations about this, but a my look at the mailing list archives didn't give me anything. But it sure would be much nicer if there was just a tcl and a tcl-devel port or something like that. Are there really applications that need tcl83 but break on tcl84? Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] The various Tcl and Tk versions do have incompatible changes in the interfaces and in the command syntax. It is very much like Berkeley DB - you have several versions, too. You have to rewrite your program to support more (or newer) Tcl versions. The idea on the current implementation in the FreeBSD ports tree is to stay compatible with older tcl scripts and libraries, too. But the structure of the supporting bsd.tcl.mk is very old and does not suit the needs of current applications anymore. Another recent issue is the handling of threaded and non-threaded versions of Tcl 8.4 and 8.5. The current implementation ist just a workaround, so that applications that explicitly require a threaded Tcl build can use it. A threaded Tcl build is 100% compatible to a non-threaded Tcl. As far as I know, threaded Tcl 8.4 builds and runs on all common FreeBSD architectures. A very clean and good solution would to have a threaded Tcl only. I will test this against all libraries from the FreeBSD ports that extend Tcl to check if they work with the threaded version correctly. I am working with miwi@ on a new implementation of bsd.tcl.mk A first working version can be viewed under: http://www.matuska.org/martin/cgi/viewvc.cgi/ports/Mk/bsd.tcl.mk The final version will probably be different - the threading part might be removed completely in favour of using threaded tcl by default. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Vpopmail + spamassassin doesn't work for aliases?
Hi, I have installed vpopmail port where you are maintainer. I check spamassassin patch, It works well but some e-mails aren't checked. It looks that only physical mailboxess are checked but aliases not. Is it possible? What may I change to test all e-mails? Thank you Radek -- Regards, Bc. Radek Krejca STARNET, s. r. o. [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: portsnap and local patches
On Wednesday 14 March 2007 02:12, Scot Hetzel wrote: On 3/14/07, Nate Eldredge [EMAIL PROTECTED] wrote: Hi all, portsnap is a very nice way to keep your ports tree in sync, but it has the disadvantage that it keeps your ports tree in sync :) If you make local changes (e.g. adding a patch) they get clobbered. Does anyone know of a convenient way to keep ports up to date while preserving local patches? One way to keep your local changes is to use cvs to checkout and update the ports tree, you then make your modifications to the port. You will need to fix any conflicts manually between an updated port and your changes. Scot csup/cvsup has the nice feature of not touching files that shouldn't be there, so my solution to that problem is to create a new directory for my local changes, which csup/cvsup will nicely ignore. -- Thanks, Josh Paetzel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why so many tcl's and tk's
On Mar 13, 2007, at 10:47 PM, Kris Kennaway wrote: On Tue, Mar 13, 2007 at 06:46:48PM -0700, Garrett Cooper wrote: Begin forwarded message: From: Stephen Montgomery-Smith [EMAIL PROTECTED] Date: March 13, 2007 3:48:56 PM PDT To: freebsd-ports@freebsd.org Subject: Re: Why so many tcl's and tk's Kris Kennaway wrote: On Tue, Mar 13, 2007 at 04:09:26PM -0500, Stephen Montgomery-Smith wrote: Are the different versions of tcl and tk really not backwards compatible with earlier versions? No, they are not. What a pity. So how come the various linux distributions seem to get away with only one version of tcl and tk? Better versioning in their package infrastructure? Dunno what you mean by this. Kris Actually after doing a bit of research it appears that what I meant in my reply is incorrect. From what I can see Linux uses a method of branching with its tcl and tk packages similar to what FreeBSD does. I know my sample size is small, but I'm pretty sure it's a defacto standard if these two distros do the branch versioning that I see: Debian (scroll almost all the way to the bottom to find the tk refs): - http://packages.debian.org/stable/libs/ Gentoo: - http://packages.gentoo.org/search/?sstring=tcl -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vpopmail + spamassassin doesn't work for aliases?
Bc. Radek Krejca ha scritto: I have installed vpopmail port where you are maintainer. I check spamassassin patch, It works well but some e-mails aren't checked. It looks that only physical mailboxess are checked but aliases not. Is it possible? Yes and no. Only local Maildirs are checked. Aliases normally point to local Maildirs, so they are checked in any case at a later stage. If you have a forward to a remote address, then no checking is done. What may I change to test all e-mails? Don't use the vpopmail patch, but integrate SpamAssassin at the SMTP layer. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsnap and local patches
--On Tuesday, March 13, 2007 23:26:26 -0700 Nate Eldredge [EMAIL PROTECTED]
wrote:
Hi all,
portsnap is a very nice way to keep your ports tree in sync, but it has
the disadvantage that it keeps your ports tree in sync :) If you make
local changes (e.g. adding a patch) they get clobbered. Does anyone know
of a convenient way to keep ports up to date while preserving local
patches?
That's why God made shell scripting???
if [ -f ${port/path/mypatch} ]; then
cp $mypatch ${port/path/mypatch}
fi
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
Re[2]: Vpopmail + spamassassin doesn't work for aliases?
Hi, AD Yes and no. Only local Maildirs are checked. Aliases normally point to AD local Maildirs, so they are checked in any case at a later stage. If you AD have a forward to a remote address, then no checking is done. I don't think so or I have a problem. I have physical maildir darius created over qmailadmin. Then I have alias radek.krejca pointed to darius. Mail sended to radek.krejca isn't checked. In .qmail-radek:krejca I have this /usr/local/vpopmail/domains/2/starnet.cz/darius/Maildir/ -- Regards, Bc. Radek Krejca [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: Vpopmail + spamassassin doesn't work for aliases?
Bc. Radek Krejca ha scritto: In .qmail-radek:krejca I have this /usr/local/vpopmail/domains/2/starnet.cz/darius/Maildir/ You should modify your aliases to be forwards (as qmailadmin does). So .qmail-radek:krejca should become: [EMAIL PROTECTED] -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
php4 port - undefined ref to getopt_long
First let me say I'm not a programmer, just a humble designer who happens to know enough to make himself dangerous. Anyway, three things started happening with my ports tree that make me unhappy. They may be unrelated, but since I don't know i'll list all three. this is all on freebsd 4.11 1) a while back i stopped being able to make my own ports index because of a bunch of gstreamer-plugins that wouldn't let me make index so i started having to make fetchindex instead. 2) when i look at portversion outputs it seems as though it doesn't really know what versions are in the ports tree -- many ports have been updated and it doesn't seem to think so. When i ran portupgrade on said ports it worked just fine -- just portversion didn't know what was going on. 3) today i stopped being able to build php4 -- i get the following error that stops the upgrade: ext/standard/basic_functions.lo(.text+0x1507): undefined reference to `getopt_long' Anybody have an idea on how i can fix the situation? The only one that really sucks is the last problem -- the other two i can live with although it'd be nice to fix them too. .tim -- View this message in context: http://www.nabble.com/php4-port---undefined-ref-to-getopt_long-tf3404132.html#a9481052 Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php4 port - undefined ref to getopt_long
On Wednesday 14 March 2007 10:56, timmartin said: First let me say I'm not a programmer, just a humble designer who happens to know enough to make himself dangerous. Anyway, three things started happening with my ports tree that make me unhappy. They may be unrelated, but since I don't know i'll list all three. this is all on freebsd 4.11 1) a while back i stopped being able to make my own ports index because of a bunch of gstreamer-plugins that wouldn't let me make index so i started having to make fetchindex instead. 2) when i look at portversion outputs it seems as though it doesn't really know what versions are in the ports tree -- many ports have been updated and it doesn't seem to think so. When i ran portupgrade on said ports it worked just fine -- just portversion didn't know what was going on. 3) today i stopped being able to build php4 -- i get the following error that stops the upgrade: ext/standard/basic_functions.lo(.text+0x1507): undefined reference to `getopt_long' Anybody have an idea on how i can fix the situation? The only one that really sucks is the last problem -- the other two i can live with although it'd be nice to fix them too. .tim On January 31st, FreeBSD 4.11 and earlier releases will have reached its End of Life dates and will no longer be supported by the FreeBSD Ports Team. Users are encouraged to upgrade to FreeBSD 6.2. Compatibility with 4.x has been removed from most of the ports. Beech -- --- Beech Rintoul - Port Maintainer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.freebsd.org/releases/6.2R/announce.html --- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php4 port - undefined ref to getopt_long
On Mar 14, 2007, at 11:56 AM, timmartin wrote: this is all on freebsd 4.11 Please be aware that FreeBSD 4.11 is no longer supported-- the ports framework has been updated in a fashion which is no longer backwards compatible with that version of the OS, so you're going to be rolling your own software from here on out if you want to stay with that version. 1) a while back i stopped being able to make my own ports index because of a bunch of gstreamer-plugins that wouldn't let me make index so i started having to make fetchindex instead. Sometimes this happens when people don't download the entire, complete port tree. Other times, the dependency tree for the Index really is broken...normally, the committers will fix it shortly so re-updating your ports tree a day later will let you rebuild the index locally. It's a moot point now, however. 2) when i look at portversion outputs it seems as though it doesn't really know what versions are in the ports tree -- many ports have been updated and it doesn't seem to think so. When i ran portupgrade on said ports it worked just fine -- just portversion didn't know what was going on. Try running pkgdb -Fu. 3) today i stopped being able to build php4 -- i get the following error that stops the upgrade: ext/standard/basic_functions.lo(.text+0x1507): undefined reference to `getopt_long' Anybody have an idea on how i can fix the situation? The only one that really sucks is the last problem -- the other two i can live with although it'd be nice to fix them too. getopt_long is part of the standard C library under 5.x and later, but is not present in 4.x. If you can't update to a more recent version of FreeBSD, try installing the /usr/ports/devel/libgnugetopt port and convince PHP to build against it. -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why so many tcl's and tk's
On Wed, Mar 14, 2007 at 07:26:25AM -0700, Garrett Cooper wrote: Are the different versions of tcl and tk really not backwards compatible with earlier versions? No, they are not. What a pity. So how come the various linux distributions seem to get away with only one version of tcl and tk? Better versioning in their package infrastructure? Dunno what you mean by this. Kris Actually after doing a bit of research it appears that what I meant in my reply is incorrect. From what I can see Linux uses a method of branching with its tcl and tk packages similar to what FreeBSD does. I know my sample size is small, but I'm pretty sure it's a defacto standard if these two distros do the branch versioning that I see: Debian (scroll almost all the way to the bottom to find the tk refs): - http://packages.debian.org/stable/libs/ Gentoo: - http://packages.gentoo.org/search/?sstring=tcl This makes better sense and is in line with what I would expect. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why so many tcl's and tk's
On Wed 14 Mar 2007 01:03, Kris Kennaway wrote: On Tue, Mar 13, 2007 at 05:48:56PM -0500, Stephen Montgomery-Smith wrote: Kris Kennaway wrote: On Tue, Mar 13, 2007 at 04:09:26PM -0500, Stephen Montgomery-Smith wrote: Are the different versions of tcl and tk really not backwards compatible with earlier versions? No, they are not. What a pity. So how come the various linux distributions seem to get away with only one version of tcl and tk? Probably the various incompatibilities are usually minor, so someone with basic knowledge of tcl/tk can forward-port the legacy code to the latest version. I'd be happy if someone were to do this for FreeBSD, at least for the older tcl/tk versions. Kris It seems most ports work fine with tcl84, and that tcl84 deps are historical rather than technical (no one looked if the ports works with tcl84). Anyway, I started working on this. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
