Re: PostgreSQL server bus error with uuid-ossp extension
On Mon, 7 Oct 2013 11:20:23 +0800 Christopher Hall christopherhall@gmail.com wrote: Hello Bill, On Fri, 4 Oct 2013 08:34:35 -0400 Bill Moran wmo...@potentialtech.com wrote: On Fri, 4 Oct 2013 15:44:51 +0800 Christopher Hall christopherhall@gmail.com wrote: When running PostgreSQL with the uuid-ossp extension the server fails with signal 10 (bus error). http://pgfoundry.org/projects/uuid-freebsd/ Thanks for the information. I would sooner stay with the existing module so as to be compatible with Linux. Currently I am trying out a patch to misc/uuid-ossp so I can just compile the postgres-contrib unmodified. uuid-freebsd is intended to be compatable. What are you finding incompatable? Although I would be appreciative if you could get that patch working. -- Bill Moran wmo...@potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PostgreSQL server bus error with uuid-ossp extension
On Fri, 4 Oct 2013 15:44:51 +0800 Christopher Hall christopherhall@gmail.com wrote: When running PostgreSQL with the uuid-ossp extension the server fails with signal 10 (bus error). http://pgfoundry.org/projects/uuid-freebsd/ -- Bill Moran wmo...@potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Can I get some love on this PR?
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168583 This bugger is about a month old at this point. Of course, part of that is my fault for being slow to respond, so I'm just putting a heads-up out -- if anyone is able to commit that, it'd be great. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Fw: VirtualBox coredump on FreeBSD 8 during build
I sent the information to the maintainer but haven't heard back yet. Don't know how busy they are, or if they're on holiday or whatever. In any event, I'm reposting this here, in the hopes that someone else has seen this problem and can make a recommendation. Begin forwarded message: Date: Tue, 9 Mar 2010 20:33:48 -0500 From: Bill Moran wmo...@potentialtech.com To: v...@freebsd.org Subject: VirtualBox coredump on FreeBSD 8 during build FreeBSD monster 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #3: Sun Dec 13 14:53:34 EST 2009 r...@monster:/usr/obj/usr/src/sys/GENERIC i386 Ports tree updated as of an hour or so ago. I get the following error doing make install: [r...@monster /usr/ports/emulators/virtualbox-ose]# make install clean === virtualbox-ose-3.1.2_1 depends on executable: yasm - found === virtualbox-ose-3.1.2_1 depends on executable: as86 - found === virtualbox-ose-3.1.2_1 depends on executable: xsltproc - found === virtualbox-ose-3.1.2_1 depends on executable: kmk - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/easy_install-2.5 - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/python2.5 - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/libdata/pkgconfig/xcursor.pc - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/lib/qt4/libQtGui.so - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/linguist-qt4 - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/moc-qt4 - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/lib/qt4/libQtNetwork.so - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/rcc - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/uic-qt4 - found === virtualbox-ose-3.1.2_1 depends on file: /usr/local/bin/sdl-config - found === virtualbox-ose-3.1.2_1 depends on executable: pkg-config - found === virtualbox-ose-3.1.2_1 depends on shared library: png.5 - found === virtualbox-ose-3.1.2_1 depends on shared library: xslt.2 - found === virtualbox-ose-3.1.2_1 depends on shared library: curl.5 - found === virtualbox-ose-3.1.2_1 depends on shared library: dbus-1.3 - found === virtualbox-ose-3.1.2_1 depends on shared library: SDL-1.2.11 - found === virtualbox-ose-3.1.2_1 depends on shared library: glib-2.0.0 - found === virtualbox-ose-3.1.2_1 depends on shared library: IDL-2.0 - found === Configuring for virtualbox-ose-3.1.2_1 Checking for environment: Determined build machine: freebsd.x86, target machine: freebsd.x86, OK. Checking for kBuild: found, OK. Checking for gcc: found version 4.2.1, OK. Checking for as86: found version 0.16.17, OK. Checking for bcc: found version 0.16.17, OK. Checking for iasl: found version 20090521, OK. Checking for xslt: found, OK. Checking for pthread: found, OK. Checking for libxml2: found version 2.7.6, OK. Checking for libxslt: found version 1.1.26, OK. Checking for libIDL: found version 0.8.13, OK. Checking for ssl: found version OpenSSL 0.9.8k 25 Mar 2009, OK. Checking for libcurl: found version 7.19.7, OK. Checking for zlib: found version 1.2.3, OK. Checking for SDL: found version 1.2.14, OK. Checking for X libraries: found, OK. Checking for Xcursor: found, OK. Checking for Xmu: found, OK. Checking for Mesa / GLU: Segmentation fault (core dumped) === Script configure failed unexpectedly. Please report the problem to v...@freebsd.org [maintainer] and attach the /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose. *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose. I'd love to send the file requested, however, there is no such file. If the solution isn't immediately obvious, let me know what debugging steps I can take to help sort this out. Follows the output of pkg_info: [r...@monster /usr/ports/emulators/virtualbox-ose]# pkg_info ORBit2-2.14.17 High-performance CORBA ORB with support for the C language OpenEXR-1.6.1_2 A high dynamic-range (HDR) image file format Terminal-0.4.3_1Terminal emulator for the X windowing system Thunar-1.0.1_3 XFce 4 file manager a2ps-letter-4.13b_4 Formats an ascii file for printing on a postscript printer aalib-1.4.r5_4 An ascii art library amspsfnt-1.0_5 AMSFonts PostScript Fonts (Adobe Type 1 format) appres-1.0.1Program to list application's resources aspell-0.60.6_2 Spelling checker with better suggestion logic than ispell atk-1.28.0 A GNOME accessibility toolkit (ATK) autoconf-2.62 Automatically configure source code on many Un*x platforms autoconf-wrapper-20071109 Wrapper script for GNU autoconf automake-1.9.6_3GNU
Re: [Firefox] Why we can't update..
On 1/23/10 3:02 PM, Doug Barton wrote: On 01/23/10 10:16, Martin Wilke wrote: Before we get more mails with the question why we not update firefox to 3.6, the answer is easy, nox@ found some problems with some plugins, this problem seems to be only FreeBSD releated under Linux or Windows seems to be works all fine. Some plugins crash with some open ASSERTS, we working on this problem but that need a bit time. So please wait a bit. Thanks! No no, thank YOU. :) I was going to report that moving from RC1 to RC2 caused me a lot of problems, but nice to know that y'all are on the case. FWIW I have the following plugins installed, downloaded from addons.mozilla.org: Ditto. Sometimes I forget to thank folks for all the hard work they do. In this case, thank you for: 1) Maintaining this port 2) Making sure things work before you update and 3) Taking the time to give everyone a heads-up about what's going on. -Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need advice from maintainers
In response to Paul Schmehl pschmehl_li...@tx.rr.com: I am the maintainer for security/barnyard2. This is an updated version of security/barnyard, which I also maintain. The version of my port is the current release version, but it has a really irritating problem that is fixed in the current beta version. Barnyard2 is a program that parses snort logs and inserts them into a database (mysql or postgresql). It is supposed to create a placemarker file (called a waldo file) that maintains a record of what logs it has already parsed. (This is only one way of using the program. There are others as well.) The problem in the release version is that it does not read the waldo file when the program is restarted. So every time you restart barnyard2, it reinserts into the database every alert you still have log files for. The beta version fixes this problem. I have created a port for the beta version and am using it myself, but I know that using beta versions of software is frowned upon. Should I go ahead and submit this port because it solves this problem? If I do, my thinking is that I should adjust the pkg-message file in the existing port to warn the user about the problem and note that the beta version solves it so they might want to consider using that instead. An option that you did not mention is to take the patch that fixes that single problem and include as a patch file for barnyard2. That way it's not a true beta, it just has that single patch to fix a known problem. For me, I think that would be the preferred method in this case. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need advice from maintainers
In response to Paul Schmehl pschmehl_li...@tx.rr.com: --On Wednesday, October 21, 2009 10:31:21 -0500 Bill Moran wmo...@potentialtech.com wrote: In response to Paul Schmehl pschmehl_li...@tx.rr.com: I am the maintainer for security/barnyard2. This is an updated version of security/barnyard, which I also maintain. The version of my port is the current release version, but it has a really irritating problem that is fixed in the current beta version. Barnyard2 is a program that parses snort logs and inserts them into a database (mysql or postgresql). It is supposed to create a placemarker file (called a waldo file) that maintains a record of what logs it has already parsed. (This is only one way of using the program. There are others as well.) The problem in the release version is that it does not read the waldo file when the program is restarted. So every time you restart barnyard2, it reinserts into the database every alert you still have log files for. The beta version fixes this problem. I have created a port for the beta version and am using it myself, but I know that using beta versions of software is frowned upon. Should I go ahead and submit this port because it solves this problem? If I do, my thinking is that I should adjust the pkg-message file in the existing port to warn the user about the problem and note that the beta version solves it so they might want to consider using that instead. An option that you did not mention is to take the patch that fixes that single problem and include as a patch file for barnyard2. That way it's not a true beta, it just has that single patch to fix a known problem. For me, I think that would be the preferred method in this case. I *might* be able to do that, if I can figure out where in the code the problem is fixed. I've had two semesters of C++, but I am not a programmer and consider myself the rankest of novices wrt code. In a perfect world. you wouldn't have to be a C++ coder. In theory, you should be able to look at their SVN/CVS/git/whatever repository and find the commit that says it's fixed this problem, then just generate a diff between that version and the release version. Of course, that's in a perfect world. I'm not familiar with that project, so I don't know if they're that organized or not. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Signing Request
In response to J. Hellenthal jhellent...@gmail.com: If you do not need to pgp/gpg sign email message to the lists please don't. What is the purpose of your message? The above statement is self-cancelling. If I go to the trouble to establish a pgp/gpg key, I will sign every single message that I send out. The purpose of this is to differentiate actual messages from me from messages that may impersonate me. I know I probably don't have your pgp public key and a lot more users probably do not either. Please use your best judgment. While you're free to voice your opinion, I don't understand your purpose in spamming three mailing lists with this demand. What problem are you trying to solve? -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Multiple instances of Mailman on FreeBSD
In response to Jeffrey Goldberg jeff...@goldmark.org: I'm posting this to both the mailman-users list and the freebsd-ports list. I realize that not all follow-up will make it to both lists. I would like to set up multiple instances of Mailman on a FreeBSD 7- STABLE system with using Postfix. Looking at the ports Makefile, it appears that if I set MM_DIR=mailman/vhosts/domain-for-this-instance everything should work file (plus add FORCE_PACKAGE_REGISTER allow this second instance to be installed.) Were it me, I'd add jails to the system. Then you can install a separate copy of mailman in each jail. This will keep them happily independent of each other. That's obviously not the only way to get what you want, just my suggestion. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
A plea or sanity in port options menu
I don't believe this is particularly useful: Options for port-fu [ ] BRG Enable BRG support [X] QFZ Enable QFZ support Quite honestly, if you can't figure out that checking the box next to BRG enables BRG support, then don't use a computer. However, if you don't already know what BRG _is_, then those menus are worthless gobbly-gook. So, you've held my hand long enough to teach me that putting an X in a box enables something, but you've given me absolutely NO idea what I've actually done. How about: Options for port-fu [ ] BRG Bernstein Riggs Guillotine parsing [X] QFZ Quantum Freeze Zulu rending At least that one gives me _some_ idea what those TLAs mean. This is so common in the ports infrastructure, that I'm sure a bazillion maintainers are going to scream at me for complaining about it. After all, _everyone_ else does the same thing. But it's completely worthless to have the description simply repeat what the tag is. It's also really bad UI design. Quite honestly, it makes me wonder if the port creator was even awake when they typed up the Makefile. Please, please, please stop this. I'm floored by the pervasiveness of this insanity, and there's absolutely no reason for it to continue. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: A plea or sanity in port options menu
In response to Warren Block wbl...@wonkity.com: On Mon, 2 Feb 2009, Bill Moran wrote: How about: Options for port-fu [ ] BRG Bernstein Riggs Guillotine parsing [X] QFZ Quantum Freeze Zulu rending At least that one gives me _some_ idea what those TLAs mean. There was talk some time ago of having extended descriptions. Several ideas, but the one that made the most sense to me would be a box at the bottom that would display a description as you moved through the options: [.] BRG [X] QFZ Bernstein Riggs Guillotine parsing with the . representing the cursor/highlight position. Move down and the bottom line would change to say Quantum Freeze Zulu rending. The nice thing about the box at the bottom is it would give a full line or possibly several lines for explanations. Seems like it could be added without breaking the existing system with an optional OPTIONS_DESC variable that would correspond with OPTIONS. I don't really know how hard that would be; ideas are cheap, implementation more costly. I don't think there's any need for any new features in the ports infrastructure. I think it's just a matter of Makefile authors taking the time to describe their options. A quick test of some ports turns up this one: [ ] OPENGL OpenGL support True but useless. How about: [ ] OPENGL Use OpenGL graphics library ...which, at least give the user _some_ idea what they're doing. OpenGL probably isn't a good example, however. It's pretty easy to Google OpenGL and figure out what it is. Here's some more bizarre options: [X] EPUB Epub modules [X] EXTENSIONSExtensions [X] TEMPLATE Templates [X] TOOLS Tools I mean, if I enable Extensions, what happens? How do I figure out what happens? I have to read the Makefile, at which point having these options on a menu is pretty pointless. I mean, I can't even come up with a Google search to help me figure out what tools are involved here. There are some ports that do this very well. For example: [ ] NLS Use internationalized messages [ ] PAM Build with PAM support (server only) [ ] LDAP Build with LDAP authentication support [ ] MIT_KRB5 Build with MIT's kerberos support [ ] HEIMDAL_KRB5 Builds with Heimdal kerberos support [ ] OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) [X] XML Build with XML data type (server) [X] TZDATAUse internal timezone database (server) [ ] DEBUG Builds with debugging symbols [ ] ICU Use ICU for unicode collation (server) [ ] INTDATE Builds with 64-bit date/time type (server) I mean, a Google on ICU is liable to bring up all sorts of medical drama websites, but I can do a search for ICU unicode and find my answer on the first result. Not only am I told that optimized compiler flags are an option, but I'm told the exact one that will be used (-O3) The porters handbook doesn't seem to offer any helpful advice on these: http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html In fact, the examples it provides are excellent examples of doing it WRONG. Let me see about making a patch to the porters handbook to provide some advice ... -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: It is illogical layout of ports
Sokolov Alexey [EMAIL PROTECTED] wrote: Hi! The location of some ports contradictory. They need all rank in the categories you want. My goodness, you're right! Quick, stop all other development and have the entire FreeBSD community audit all _18000_ ports to ensure they're all in the appropriate categories! It shouldn't take long. I mean, there's no possibility that there'll be any disagreement among the community as to where each port belongs. There's no possibility that such an audit would be tied up in bikeshed discussions for eons. (Especially since I think most of the ports you complained about are already in the right place.) In all seriousness, what did you expect was going to happen as a result of your email? What did you really hope to accomplish? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
In response to Doug Barton [EMAIL PROTECTED]: Bill Moran wrote: It's a combination of a number of issues: 1) The ports infrastructure shouldn't let you set options that don't make sense. I think that one could argue that it should be _hard_ to set options that don't make sense, but I don't think it should be impossible. you have to keep in mind that we cater to a very diverse user community, from rank beginners to advanced hackers. True. My opinion: A GUI that _prevents_ novice users from selecting incompatible options is a good idea. Expert users can always manually tweak /var/db/ports/ files if they want to override those restrictions. 2) Why is portupgrade dying on a warning message? Why does a poor decision on one port prevent everything on my system from upgrading? For the same reason that portmaster dies on errors, neither program is omniscient. :) If ports tools hit a point where it's not clear how to proceed they _should_ stop and get user input. The next thing the users generally say is that it should somehow proceed with the rest of the upgrade, finish things that don't rely on the broken bits, etc. Unfortunately that is quite a bit harder to do than you might think, although patches are always welcome. Understood. But keep in mind that this was not an error, it was a warning. Perhaps the ports infrastructure doesn't differentiate between those two as much as I think. 3) The error from portupgrade does not immediately point me to the easy solution, it tricks me into thinking I have to hack the Makefile. I don't actually think that the error message you're referring to is from portupgrade, I think it's from the port itself. I can see that. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with portupgrade xscreensaver-gnome
cvsupped my ports tree just this morning. #uname -a FreeBSD vanquish.ws.pitbpa0.priv.collaborativefusion.com 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Wed Jun 25 09:16:13 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VANQUISH i386 # pkg_info | grep portupgrade portupgrade-2.4.6,2 FreeBSD ports/packages administration and management tool s # portupgrade -a [...] ** Makefile possibly broken: x11/xscreensaver-gnome: Makefile, line 106: warning: Option KEYRING needs PAM, but PAM is disabled. xscreensaver-gnome-5.06_1 --- Session ended at: Wed, 30 Jul 2008 08:38:31 -0400 (consumed 00:01:10) /usr/local/sbin/portupgrade:1468:in `get_pkgname': Makefile broken (MakefileBrokenError) from /usr/local/sbin/portupgrade:622:in `main' from /usr/local/sbin/portupgrade:613:in `each' from /usr/local/sbin/portupgrade:613:in `main' from /usr/local/sbin/portupgrade:588:in `catch' from /usr/local/sbin/portupgrade:588:in `main' from /usr/local/lib/ruby/1.8/optparse.rb:1303:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1303:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1299:in `catch' ... 6 levels... from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize' from /usr/local/sbin/portupgrade:229:in `new' from /usr/local/sbin/portupgrade:229:in `main' from /usr/local/sbin/portupgrade:2208 If I comment out line 106 in that Makefile, all is fine. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
In response to Marcin Wisnicki [EMAIL PROTECTED]: On Wed, 30 Jul 2008 08:51:23 -0400, Bill Moran wrote: cvsupped my ports tree just this morning. #uname -a FreeBSD vanquish.ws.pitbpa0.priv.collaborativefusion.com 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Wed Jun 25 09:16:13 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/ sys/VANQUISH i386 # pkg_info | grep portupgrade portupgrade-2.4.6,2 FreeBSD ports/packages administration and management tool s # portupgrade -a [...] ** Makefile possibly broken: x11/xscreensaver-gnome: Makefile, line 106: warning: Option KEYRING needs PAM, but PAM is disabled. xscreensaver-gnome-5.06_1 You need to either enable PAM (recommended) or disable KEYRING by doing: cd /usr/ports/x11/xscreensaver-gnome/; make config Are you saying that I can't portupgrade ANY ports on my system until such time as I make this strange decision? Note that the message is a _WARNING_. So portupgrade is giving up on every port on my system because _one_ port has a warning? No, I tend to thing that something is wrong here. Should portupgrade bail because it sees a warning from a Makefile? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with portupgrade xscreensaver-gnome
In response to Marcin Wisnicki [EMAIL PROTECTED]: On Wed, 30 Jul 2008 17:45:10 -0400, Bill Moran wrote: In response to Marcin Wisnicki [EMAIL PROTECTED]: On Wed, 30 Jul 2008 08:51:23 -0400, Bill Moran wrote: cvsupped my ports tree just this morning. #uname -a FreeBSD vanquish.ws.pitbpa0.priv.collaborativefusion.com 7.0-RELEASE FreeBSD 7.0-RELEASE #4: Wed Jun 25 09:16:13 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/ src/ sys/VANQUISH i386 # pkg_info | grep portupgrade portupgrade-2.4.6,2 FreeBSD ports/packages administration and management tool s # portupgrade -a [...] ** Makefile possibly broken: x11/xscreensaver-gnome: Makefile, line 106: warning: Option KEYRING needs PAM, but PAM is disabled. xscreensaver-gnome-5.06_1 You need to either enable PAM (recommended) or disable KEYRING by doing: cd /usr/ports/x11/xscreensaver-gnome/; make config Are you saying that I can't portupgrade ANY ports on my system until such time as I make this strange decision? Why do you think it is a strange decision? You have set non-default options that don't make sense and the port is warning you about that. Fixing it is quick, easy and painless. It's a combination of a number of issues: 1) The ports infrastructure shouldn't let you set options that don't make sense. If I can't use keyring without PAM, then why am I allowed to set such a thing. I believe such improvements to the ports structure are being worked on by others (based on other conversations I've seen on the list) so I won't belabour the point. 2) Why is portupgrade dying on a warning message? Why does a poor decision on one port prevent everything on my system from upgrading? 3) The error from portupgrade does not immediately point me to the easy solution, it tricks me into thinking I have to hack the Makefile. Anyway, I don't know what the correct solution is. I'm just pointing out the problem so that people smarter than me can work it out. I'm also presenting my viewpoint so those people know how confusing it was to me. Hope the information is helpful. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
databases/evolution-data-server forces requirement on ldap
The port mentioned above has a hardcoded requirement to include openldap-client and does not obey WITHOUT_LDAP in /etc/make.conf (note that the mail/evolution port does obey WITHOUT_LDAP) I hacked the Makefile to remove the dependency and it seems to run fine. Haven't done extensive testing, but it seems as if a tweak to make it respect that setting would be nice. On a (possibly) related note, that port seems to require openldap-2.3 and the build breaks because I have openldap-2.4 installed. Unfortunately, I don't have time to investigate that now. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: www/mediawiki: PostgreSQL non functional - why? + texvc + dependencies
In response to Nikola Lečić [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 No answer after 15 days -- does this mean that the maintainer is not interested in this port? He could be on holiday or otherwise indisposed. Policy dictates that you should open this as a PR. If the PR sits longer than the maintainer timeout without a response from the maintainer, then other committers can make the change. There's documented policy on this: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/maintain-port.html - -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBR8K7SPzDP9K2CKGYAQPGvwP/RzRuWCrnrI9GVPfuY2XMCNDs/aB+G7Oc PXrtce1dgdVwyc1kBbSGR0DHjZ1AaaM1LOYmkbnBa5rTenM4gpKYKrfpl0UIjiM4 /9C+GzeyTmFzUcNA7S/nfnR4PhFxc9lereBSDjgrl02W71G2BWAJdJ8O6+wRXgD9 c6xACTy4fY8= =40Hb -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Not sure why print/lyx15 is marked BROKEN
Erwin Lansing [EMAIL PROTECTED] wrote: On Sat, Feb 02, 2008 at 01:28:14PM -0500, Bill Moran wrote: The above mentioned port is marked BROKEN because it does not build with GCC 4.2 Are you sure you are looking at the right port? Yes. print/lyx15 is marked BROKEN on all platforms and releases, not just for gcc 4.2. My mistake. However, it does not change anything else about my experience. I commented out the BROKEN line, figuring I'd see if I could help fix it, but much to my surprise it built without problems and runs just fine. See one of the error logs: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2008012319/lyx-1.5.3.log Mystery of all mysteries ... $ uname -a FreeBSD monster 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Sun Dec 30 11:59:30 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 $ pkg_info | grep lyx lyx-1.5.3 Document processor interfaced with LaTeX (nearly WYSIWYG) So, what information is useful to solving this? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Not sure why print/lyx15 is marked BROKEN
The above mentioned port is marked BROKEN because it does not build with GCC 4.2 I commented out the BROKEN line, figuring I'd see if I could help fix it, but much to my surprise it built without problems and runs just fine. $ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] $ uname -a FreeBSD monster 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Sun Dec 30 11:59:30 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Perhaps someone else could verify this, and the port could be unBROKENed? -Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.php.mk suggestion
In response to Dominic Fandrey [EMAIL PROTECTED]: Vladimir Zorin wrote: I tried to get in touch with Alex Dupre, the maintainer of the bsd.php.mk, sent him the same text as the above with the patch, but I didn't get any response. As far as I know there are several people who tried to contact him regarding the same issue but, alas, didn't get any response as well. I suppose there might be the possibility of a timeout that allows committing without Maintainer feedback, if you submit it as a PR. This is exactly the way to proceed. If the maintainer is not responding, open the issue as a PR so it's officially tracked. If the maintainer does not respond withing a reasonable length of time, request a maintainer timeout to have another committer check in the patch. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.php.mk suggestion
In response to Vladimir Zorin [EMAIL PROTECTED]: Bill Moran wrote: In response to Dominic Fandrey [EMAIL PROTECTED]: Vladimir Zorin wrote: I tried to get in touch with Alex Dupre, the maintainer of the bsd.php.mk, sent him the same text as the above with the patch, but I didn't get any response. As far as I know there are several people who tried to contact him regarding the same issue but, alas, didn't get any response as well. I suppose there might be the possibility of a timeout that allows committing without Maintainer feedback, if you submit it as a PR. This is exactly the way to proceed. If the maintainer is not responding, open the issue as a PR so it's officially tracked. If the maintainer does not respond withing a reasonable length of time, request a maintainer timeout to have another committer check in the patch. Thank you for the tip, I'll do the way you described. What regards reasonable length of time - a fortnight, for example, is reasonable enough? There is an actual documented policy on this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-maintainer.html -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 removal (Re: Ion3 license violation)
In response to Tuomo Valkonen [EMAIL PROTECTED]: On 2007-12-13, Mark Linimon [EMAIL PROTECTED] wrote: On Thu, Dec 13, 2007 at 08:30:06AM +, Tuomo Valkonen wrote: The copyright holder reserves the right to refine the definition of significant changes on a per-case basis. In other words, a moving target -- which implies, to me, that to be legally in the clear, that we would first have to vet every possible change or modification, including patches. Notice the a priori: it means you're allowed to do that without legal threat until further notice to the contrary. Did you not understand the part where Mark described the requirement to avoid possible legal trouble? Since you felt the need to snip out the part of Mark's post that was truly relevant to your reply, I'll reproduce it here: But in the case of implied threat of legal action, in my opinion, it's not worth anyone's time to try to iterate over every possibility to find out to make sure they -- and others, on their behalf -- aren't somehow liable. The risk is simply too high. Stop abusing this mailing list for your own purposes. Let's state some facts: *) FreeBSD has agreed to remove the offending port in order to comply with your license requirements. However, you continue to complain. *) _Anyone_ could submit a patch to the port to abide by your license requirements and it's likely that it will be committed, yet _nobody_ has. Even you, Tuomo, claim to have bold and revolutionary ideas on package distribution yet would rather argue than WRITE A PATCH AND SUBMIT IT! Beyond that, you've _IGNORED_ posts that I've made in the past suggesting this. *) You blame distro folks as abusing developers and expecting them to just provide free work, then you turn around an complain that the FreeBSD people should bend over backwards to accommodate the software you wrote. You're doing the _exact_ thing you accuse others of doing. *) You continually abuse this mailing list by twisting other persons posts to your agenda by snipping relevant information, replying only to the parts that you want to, and redirecting the meaning of other posts. Please go somewhere that you can find emotional healing Tuomo. I, for one, will be glad to see you return as a sane person but have no desire to watch this thread continue as long as you're sick. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 removal (Re: Ion3 license violation)]
In response to Mikhail Teterin [EMAIL PROTECTED]: On четвер 13 грудень 2007, Peter Jeremy wrote: = So far one person has stated that they tried and gave = up. Maybe the next person will be more successful. Absolutely right. My point, however, was that the rashed removal makes that hypothetical next person's job more difficult. There was nothing rash about it. Any lawyer will tell you that under the threat of legal action, you remove the threat, _then_ look in to creative ways to fix the problem. There was not an immediate answer to hand. As a result, Mark did the right thing and protected the FreeBSD project from any potential legal action until a better solution can be found. Any claims of license violations -- which, according to Mark, lead to the hasty removal -- should've been addressed by using FORBIDDEN/IGNORE instead. Perhaps you're right. However, I'd like to hear the opinion of a lawyer as to whether this is acceptable or not. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 removal (Re: Ion3 license violation)
In response to [EMAIL PROTECTED] (Mark Linimon): On Thu, Dec 13, 2007 at 02:43:07PM +, Tuomo Valkonen wrote: And at least where I come from, contracts are legally enforceable, even if they're only oral ones You clearly don't come from the US, where oral contracts are not germane in business law. What's written down in the license is the only thing that would be germane in court. Again, I'm not a lawyer, but this was my clear understanding from the courses I took. As a side note ... when I owned part of a business we had to got to court with a few clients over gross misunderstandings. As a result, I had a lawyer tell me exactly what you said: That verbal agreements _are_ legally binding, but almost never enforceable. As a result, they're not really germane to business law. At one point, a judge took me aside an told me to start making my clients sign agreements before doing any work, otherwise I was going to end up in serious trouble at some point. It's the reason why, in the US, agreeing to anything over the phone is a bad idea. Ever have a pushy salesman on the phone try to get you to agree to something _right_away_! They reason they do that is it's pretty much impossible to make them liable for misrepresentation or anything like that if you don't have it in writing. They can basically lie through their teeth and promise you the world without delivering, and it's damn near impossible to take legal action against them if it was all verbal. Of course, I am not a lawyer either, so you should consult with one before entering into any important agreement. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 license violation
In response to Tuomo Valkonen [EMAIL PROTECTED]: On 2007-12-12, Mark Linimon [EMAIL PROTECTED] wrote: No, the release packages were already built. You see, part of the problem of software Quality Assurance is that it takes some Distro Quality Assurance... ROTFLMAO. If we're taking a vote, I vote for the following: a) We ban Tuomo from our lists. b) We remove all his software from the ports and refuse to accept any more by him. The guy is obviously just around to start flame wars. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 license violation
In response to Russell Jackson [EMAIL PROTECTED]: Russell Jackson wrote: Damn it. I use this software, and I even feel somewhat responsible for perhaps possibly Tuomo here after I reported a crash under FreeBSD 7 on the ion list that wound up having something to do with the mod_xinerama extension -- something that I haven't had time to further look into. The simple fact is that Tuomo has some strange desire to blame packagers for all his problems with software and users. It's impossible for the FreeBSD ports system to guarantee compliance with his arbitrarily chosen 28 days rule. If he's going to demand that his terms be followed, then it has to come out of the ports. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 license violation
In response to Tuomo Valkonen [EMAIL PROTECTED]: On 2007-12-12, Russell Jackson [EMAIL PROTECTED] wrote: Damn it. I use this software, and I even feel somewhat responsible Don't worry, you're not responsible (much). I'd been monitoring the situation having heard of a ports freeze, and nothing having been done to mark the Ion package as (potentially) obsolete or anything. Not much asked, but it seems distros don't like to admit that they distribute obsolete and buggy software. Translation: Tuomo was just waiting around in the hopes that he could start bitching and cause trouble. He could have pre-emptivly offered his assistance to ensure that the FreeBSD ports tree didn't drift too far out of sync, but instead he just waited around until the opportune moment to start bitching and crying like a baby. If you were watching, why didn't you point this out back at the beginning of the ports freeze? I wasn't running the version in ports CVS. I was running a modified local port that did pull the latest ion sources. I also had to explicitly enable mod_xinerama with a make define; so, it isn't part of the the binary package or a default port install. The option doesn't seem Ion-specific and isn't documented to add unsupported features. A much better place for the module would in any case be, say, x11-wm/ion-3-extras/mod_shit-o-rama. You could also have mod_xrandr, mod_ionflux, and etc. under that kind of setup. There's no reason why the module should deceivingly (and inconveniently) be distributed hidden within the ion-3 package. Either you didn't understand Russell's comment, or you're so bent on blaming folks problems on distro folks that you're redirecting the conversation in an attempt to prove your point, whatever it is. I really don't see why the extreme action of removing it from ports was necessary. :sigh: Distro folks are not reasonable; they think authors should be their undemanding and unquestioning slaves. I think we have learned that already. Who's we? You and all the voices in your head? Remind the voices that FreeBSD isn't a Linux distro, and maybe they'll start feeding you accurate information instead of making you look insane. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 license violation
In response to Tuomo Valkonen [EMAIL PROTECTED]: On 2007-12-12, Bill Moran [EMAIL PROTECTED] wrote: It's impossible for the FreeBSD ports system to guarantee compliance with his arbitrarily chosen 28 days rule. There is no 28 days rule. There is a latest release in 28 days or prominently mark (potentially) obsolete rule. You can make the marking permanent, always requiring users to acknowledge a message. You can make the marking automatic, by checking the website for a new release (as Debian presently does), or by some more sophisticated means or dead man triggers. There you go. I had no idea it would be this easy. Please open a PR and attach a patch. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 removal (Re: Ion3 license violation)
Mikhail Teterin [EMAIL PROTECTED] wrote: The simple fact is that Tuomo has some strange desire to blame packagers for all his problems with software and users. Yes, license-crafting lawyers are usually more polite and don't engage in direct communications with forums such as ours. Their licenses suck much more, however -- think Java, cdrtools, or Skype, and all the other closed-source packages. Put Tuomo's demands in perspective, for crying out loud... What perspective? The port does not meet his license requirements. Nobody has submitted patches to make it meet said requirements. The project has to remove it. What perspective do I have to keep? Oh, you mean the part where he comes onto the FreeBSD lists and insults all the hard-working ports maintainers? Sure, I'll keep that in perspective. It's impossible for the FreeBSD ports system to guarantee compliance with his arbitrarily chosen 28 days rule. If he's going to demand that his terms be followed, then it has to come out of the ports. Actually, it can be done -- when building the port, the date on the distfile (or that on the most recent source-file /extracted/ therefrom) can be checked against the current date and a prominent message can be issued warning of possible obsoleteness (sp?)... Sure. As I already stated: please submit a patch. Without someone who actually cares enough to patch the port, it must be removed do to license problems. This is _no_ different than any other port with similar conflicts between licensing and available manpower to meet those licensing requirements. The _only_ difference is that Tuomo thought it necessary to come onto our lists and make a big stink about it, filling my inbox to overflowing. I just wish we avoided the rash decisions like let's remove everything written by the guy we don't like NOW -- if only in the name of ports slush... In the hurry to spite the admittedly unpleasant-sounding author, the needs and expectations of the users were neglected. Well, I said that because the guy irritates me. Let me be clear on this point. I maintain a few ports. I am _NOT_ in a position to dictate policy, I was only stating my opinion -- which _MUST_ not be construed to be the overall opinion of the FreeBSD community. There are far too many quality hackers out there who _do_ care about the community to tolerate one who seems to be in conflict with his community. I've never used ion, but, judging from some responses here, it is an appreciated piece of software. Fair enough. In that case, those who appreciate it should submit patches that meet Tuomo's requirements. This is how it's done. This is how it's _always_ been done. If the original maintainer is no longer keeping up with the software, then someone else needs to step up. It's his software. If his requirements can't be met, then the port comes out of the tree. What else do you expect to happen? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ion3 removal (Re: Ion3 license violation)
Mikhail Teterin [EMAIL PROTECTED] wrote: середа 12 грудень 2007 06:35 по, Bill Moran Ви написали: It's his software. If his requirements can't be met, then the port comes out of the tree. What else do you expect to happen? I expect the port-removal to be initiated/done in an orderly fashion. This includes marking it FORBIDDEN (or IGNORE, or BROKEN): FORBIDDEN= Violates licensing requirements of the author and: EXPIRATION_DATE=Some date a few months from now This would give those people, whom you expect to submit patches, some time to, actually, create them... Only if nothing materializes by the expiration date, should the port be deleted. It's absolutely a shame that couldn't be done, but he demanded that the port be fixed prior to release. Without a fix to hand, the only way to guarantee that FreeBSD wouldn't be in violation of the license agreement was to pull the port. Generate a patch and submit it. I'm sure the port will be reinstated as soon as somebody does so. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New maintainer forum and wiki
In response to Beech Rintoul [EMAIL PROTECTED]: I am happy to announce the opening of a new forum and wiki aimed primarily at the maintainer community. This site is open to all maintainers and committers. There isn't much there yet, but I'm hoping that you will find this useful and help contribute to the effort. If you want to be part of this, just register at the forum and I'll add you to the wiki. You can find it at: http://freebsd.alaskaparadise.com Feel free to contact me and let me know what you would like to see. At the risk of sounding like a whiner ... First off, what purpose does having yet another forum serve but to fragment discussion? Personally, I don't want to have yet another place to watch for information, and I find the mailing lists quite workable. Secondly, one of the things that I've always enjoyed and bragged about with FreeBSD is the high-quality documentation. I'm really not a big fan of 8-jillion HOWTOs spread all over the internet and all having different levels of quality, reliability, and upkeep. It seems to me that wikis feed this low-quality howto overload. Thirdly, I already have my own site with notes and other stuff about what I do (I maintain a small handful of ports). I'm already forced to maintain two (one for work, and one for personal) and I have absolutely no desire to maintain a third, let alone any time. All that being said, I say go for it. * As long as the forum is searchable without an account, the information there will be generally useful (unlike that obnoxious experts exchange site -- I hate those people!) * As long as _important_ discussions occur on the @freebsd.org lists, it won't cause any (or much) fragmentation * As long as important information on the wiki is cleaned up and committed to the official FreeBSD docs, it won't result in unmaintained garbage. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When PHP5 port will be updated?
In response to Robert Huff [EMAIL PROTECTED]: Ted Nicolson writes: Any idea when the updated php5 port will be released? When the maintainer has time to work on it and decided it's ready. Alternately, you could submit a patch. While you're welcome to post FreeBSD-related email of just about any nature, you're posting is not (generally) conducive to getting things done in the Open Source world. The following improvements will likely lead to better responses in the future. * [EMAIL PROTECTED] is listed as the maintainer for this port. By emailing ports@, you show that you haven't done any real research into the situation. It would be appropriate to email ale@ first to check on the status, and only email ports@ if ale@ doesn't respond. * You email comes across as rather demanding. While that may not have been your intent, that's how it reads. Demanding things of volunteers usually doesn't win you a lot of friends. Consider using phrases like, is there any way I can help speed up the process It's quite possible that ale@ is working on it, and having some testers would be helpful to him. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: for Thomas E. Zander, mplayer maintainer.
In response to Tuc at T-B-O-H.NET [EMAIL PROTECTED]: On Thu, Aug 09, 2007 at 10:58:04AM -0400, Tuc at T-B-O-H.NET wrote: Distributed, worldwide projects like FreeBSD rely on communication between their members. When one project member in a position of responsibility denies the ability for others to contact him -- whether it was his direct choice or just because he chooses to use a mail server with inappropriate filtering -- then it harms the project. Kris, FWIW, I think when someone posts a request for help onto a list, gets back a dozen Did you RTFM either on list or offlist, replies back that they did (And shows they did), and then gets dead air.. THAT harms the project. Uh, you seem to be axe grinding, but I told you to follow up with the maintainer once I evaluated your report and didn't spot any obvious problems. Why wasn't that good enough for you? If you mean axe grinding in the sense that over the years I've posted to freebsd-* for help with things pertaining to either a single piece of software, procedure I read somewhere, problem during an upgrade, etc... and either been blown off, told to re-read the docs that I've missed a crucial step (Which I stated that I did perform in my original email), or told to fix something ELSE that had nothing to do with it first... Then yea, I guess you can call it axe grinding. Perhaps FreeBSD is not the correct community for you? I don't mean that negatively, or that I _want_ you to go away. It's just that open source projects have personalities. The communities that support them (Linux, FreeBSD, etc) have ideals and traditions and so forth. While I don't ever want to chase anyone away from FreeBSD, the point (in my mind) of open source projects is that you can choose what works for you with no strings, and even fork off a project and do it your own way if you so desire. If you're having so much trouble with the FreeBSD community, I would suggest one of two strategies: *) re-evaluate they way you interact with the FreeBSD community *) try to find a community that you can interact with more successfully -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
xorg ports breaks fetch-recursive
Following up on a previous discussion about ports refusing to fetch
because of issues unrelated to the fetch process.
I'm prepping a machine for the xorg 6 - 7 upgrade, and hitting this
in ports/x11/xorg-libraries/Makefile:
.if !defined(XORG_UPGRADE) !defined(PACKAGE_BUILDING) exists(/usr/X11R6)
pre-everything::
@if [ ! -L /usr/X11R6 ]; then \
echo -n /usr/X11R6 exists, but it is not a symlink. ; \
echo Installation cannot proceed.; \
echo -n This looks like an incompletely removed old version ; \
echo -n of X. In the current version, /usr/X11R6 must be ; \
echo -n a symlink if it exists at all.; \
echo -n Please read ${PORTSDIR}/UPDATING (entry of 20070519) ; \
echo -n for the procedure to upgrade X.org related ports.; \
/usr/bin/false; \
fi
.elif !exists(/usr/X11R6) !defined(WITHOUT_X11R6_SYMLINK)
pre-everything::
${LN} -s ${X11BASE} /usr/X11R6 || ${TRUE}
.endif
The problem is that this prevents me from doing make fetch-recursive.
Can't use NO_IGNORE to get around this one. Could that Makefile be patched
to use IGNORE= instead of the current echo? (note, I just hacked my
local version of the Makefile for now, so my immediate problem is
solved -- I'm looking to suggest an improvement)
I was going to throw together a patch, but I realized I'm fuzzy on the
difference between .if and @if -- so if anyone wants to take a few
minutes to clarify those for me, I'd be happy :)
--
Bill Moran
http://www.potentialtech.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to Kris Kennaway [EMAIL PROTECTED]: On Sat, Jul 21, 2007 at 06:20:53AM -0400, Bill Moran wrote: Kent Stewart [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. It's certainly a tradeoff. Either way you do it, there are practical scenarios where a user is inconvenienced. Perhaps an environmental override is the best route. NO_IGNORE=yes or something similar? Yes, use the NO_IGNORE variable (which just passed its tenth birthday) to override IGNORE checks you disagree with. Huh ... here I am bitching and that's been there all along ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
Kent Stewart [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Mark Linimon wrote: On Fri, Jul 20, 2007 at 04:07:49PM -0400, Bill Moran wrote: Even better would be for make to realize that it's only doing the fetching, and do it anyway. That still doesn't help with the problem of a user who starts a 10MB download that won't work on his architecture or OS release. The code is all the same. This is the aggravation we are trying to prevent. That still doesn't address the concern or improve the system downtime that a pkg_delete, make install allows. If you can't run something, you don't have any downtime but to have to pkg_delete before you start the tarball fetch can be really long on some ports. It's certainly a tradeoff. Either way you do it, there are practical scenarios where a user is inconvenienced. Perhaps an environmental override is the best route. NO_IGNORE=yes or something similar? -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What to do when the person who takes responsibility for a PR goes non-responsive?
Zane C.B. [EMAIL PROTECTED] wrote: Summited http://www.freebsd.org/cgi/query-pr.cgi?pr=113611 over a month ago, Araujo took responsibility, and has been no sign from him that this is ever going to get committed. Posting to this list would be a good step. However, the subject title could be better. Something like, Would a committer please look at 113611 then mention in the email what port it relates to and comment that the person responsible seems to be timing out. Have you contacted Araujo directly? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Overly restrictive checks in the make process
[EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make fetch-recursive === Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies === postgresql-server-8.2.4_1 cannot install: the port wants postgresql82-client but you have postgresql81-client installed. *** Error code 1 Why? Is there a legitimate reason why the fetch process refuses to download this? I know I've got an older version installed, but why is it preventing me from downloading a newer one? Seems like the IGNORE= check is either being checked too aggressively or that the logic is less sophisticated than it should be. Does anyone know of a reason why this couldn't be changed to allow fetching of conflicting ports distfiles? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to Garrett Cooper [EMAIL PROTECTED]:
Bill Moran wrote:
[EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make
fetch-recursive
=== Fetching all distfiles for postgresql-server-8.2.4_1 and dependencies
=== postgresql-server-8.2.4_1 cannot install: the port wants
postgresql82-client but you have postgresql81-client installed.
*** Error code 1
Why? Is there a legitimate reason why the fetch process refuses to
download this? I know I've got an older version installed, but why
is it preventing me from downloading a newer one? Seems like the
IGNORE= check is either being checked too aggressively or that the
logic is less sophisticated than it should be.
Does anyone know of a reason why this couldn't be changed to allow
fetching of conflicting ports distfiles?
Sounds like a +CONFLICTS type of issue (the MySQL client and server
files for instance install some libs in the same spot, so they conflict
IIRC).
Actually, it's IGNORE, as I stated earlier:
.if defined(WANT_PGSQL_VER) defined(_PGSQL_VER) ${WANT_PGSQL_VER} !=
${_PGSQL_VER}
IGNORE= cannot install: the port wants
postgresql${WANT_PGSQL_VER}-client but you have postgresql${_PGSQL_VER}-client
installed
.endif
and the same behaviour is used all through the ports collection ...
php4/php5 is another example.
But that's nit-picky details. My question is _why_ is that check run
for fetch? I can see no reason why it's taboo to fetch multiple port
versions, and in the case of an upgrade where time is short, having
the package fetched prior to the outage window can be a huge time-
saver.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
[EMAIL PROTECTED]
Phone: 412-422-3463x4023
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to Jeremy Chadwick [EMAIL PROTECTED]: On Fri, Jul 20, 2007 at 09:14:32AM -0700, Garrett Cooper wrote: Sounds like a +CONFLICTS type of issue (the MySQL client and server files for instance install some libs in the same spot, so they conflict IIRC). Not as far as I know. make install in databases/mysql50-server will cause databases/mysql50-client to get installed. Verification of the results: (09:32:40 [EMAIL PROTECTED]) ~ $ pkg_info | grep ^mysql mysql-client-5.0.41 Multithreaded SQL database (client) mysql-server-5.0.41 Multithreaded SQL database (server) I think what Bill was asking about, though, was why the IGNORE in the port is getting hit for make fetch. For make or make install or other such things, it seems valid, but for fetching distdata it seems erroneous. That is correct. I apologize if I was unclear earlier. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Overly restrictive checks in the make process
In response to [EMAIL PROTECTED] (Mark Linimon): On Fri, Jul 20, 2007 at 08:58:55AM -0400, Bill Moran wrote: Why? Is there a legitimate reason why the fetch process refuses to download this? The intention of the logic is to warn a user, as soon as possible, that they are spending time on something that will wind up being IGNOREd if it is installed. There is no logic there to try to figure out later version of port; it simply looks for is IGNORE set? Since some downloads take a long time, this does not seem too unreasonable to me. If we moved the check later, the process of trying to install a port that would be IGNOREd would be: spend time fetching and checksumming it, and only then tell the user that they had wasted their time. I suspected there was some reasoning along that line. I think the best we could do is add something analagous to how DISABLE_VULNERABILITIES factors into it, and allow foot-shooting only if demanded, but turn it off by default. That would be less annoying than having to constantly hack files in /usr/ports/Mk ... :) Even better would be for make to realize that it's only doing the fetching, and do it anyway. I don't know if this is possible, though. Sooner or later, the person running the system is going to pull out the foot-gun (you can only protect them so much) and waiting for a download that can't install is a comparatively small bullet ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MySQL port checksum problem
In response to Blah Blatz [EMAIL PROTECTED]: Trying to make databases/mysql50-client, I get a checksum error on one of the downloads: = mysql-5.0.41.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.0/. === Vulnerability check disabled, database not found = MD5 Checksum mismatch for mysql-5.0.41.tar.gz. = SHA256 Checksum mismatch for mysql-5.0.41.tar.gz. Try deleting the distfile and allowing the port to re-fetch it. The ports system doesn't seem to have any way to recover from a corrupted download, it just reports it and aborts. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making a local branch of the ports tree
In response to Vivek Khera [EMAIL PROTECTED]: On Apr 25, 2007, at 1:22 PM, Bill Moran wrote: My thought is to make /usr/ports/private (or similar) and teach cvsup not to blow it away. Then I just need to make sure that portupgrade and other tools see it. Does anyone have a HOWTO or list of steps to get this going? I know this has been discussed before but I can't find any reference to it now. I use /usr/port/local and name all the ports kci-XXX for whatever port we have. mostly these are pseudo ports which pull in all the dependencies for our various server needs. (I'll probably post this to my website sometime...) Wow, that's pretty damn detailed. If you have trouble getting it ready for web publication, let me know and I'll maybe jump in and help out. This is great stuff. [snip] -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Making a local branch of the ports tree
I know I've seen this discussed a dozen times, but google is letting me down right now. Basically, I want to create a private branch of the ports tree for scripts and other stuff that isn't suitable to submit back to the main ports tree, and use portupgrade and other ports tools to maintain this across a bunch of systems that mount their ports tree via NFS. My thought is to make /usr/ports/private (or similar) and teach cvsup not to blow it away. Then I just need to make sure that portupgrade and other tools see it. Does anyone have a HOWTO or list of steps to get this going? I know this has been discussed before but I can't find any reference to it now. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Greylisting - recomendation pls using postfix
David Southwell [EMAIL PROTECTED] wrote: Suggestions please for a choice of port for implementing greylisting on a server running a number of mailists and acting as a mailserver for around 10 websites. Ease of configuration and maintenance plus low server load are important considerations. mail/postgrey -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and NetBSD's pkgsrc: A strategic synergy for awesomeness
RW [EMAIL PROTECTED] wrote: On Sun, 01 Apr 2007 13:58:18 -0700 Garrett Cooper [EMAIL PROTECTED] wrote: FreeBSD Ports Tree Management wrote: Dear FreeBSD ports community, ... We are hereby announcing our intentions to switch over to NetBSD's pkgsrc tree and close our own FreeBSD ports tree. ... Wow. I suppose I should try NetBSD now to figure out what it's all about. Can someone either provide a link or a quick synopsis, of what the differences are between the current ports tree and NetBSD's pkgsrc tree? $ date Sun Apr 1 21:09:38 BST 2007 OK. I have to know ... who took all the time to write that all up? -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Openssh
In response to Eric [EMAIL PROTECTED]: Alfredo Perez wrote: Hi I noticed that Openssh port shows in the list of ports that need to be updated to the latest version (4.6), I dont have much experience updating a port but If nobody is working on that, I would really like to give it I try? Thanks Alfredo install portmaster from the ports tree and let it update it for you. its pretty easy I think he's referring to generating a set of diffs and submitting a PR, as the OpenSSH in the ports tree is only 3.6.1 Alfredo: Start by reading The Porter's Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html Different ports require different levels of expertise to create -- I don't know what you're getting yourself in to with OpenSSH -- it could be easy or hard, but the place to start would be that handbook. If you hit specific problems, post the details of where you get stuck to the list and I'm sure others will help out. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: question regarding handling of a port listed with this address as the maintainer (mail/py-spambayes)
In response to Jim Stapleton [EMAIL PROTECTED]: I gather that if I want to make an addition to a port, with this address listed as a maintainer (meaning there is no maintainer, correct?) I should just follow the instructions in the porters handbook of using the same tool that creates bugreports, correct? Additionally, the addition to the port in question, mail/py-spambayes, requires I add a file to the work directory (I made an rc.d script for it), as well as some small changes to the pkg-plist. I don't have a good place to host this file, what do you all recommend I use? These articles have 99% of the information you need: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/index.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ Since there's no maintainer, you may want to consider volunteering to maintain it. Generally, I open a PR. If I don't hear back from someone within a week or so, I'll ping the mailing list asking a committer to look at it, but usually someone jumps in and takes care of it. -- Bill Moran http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: port PostgreSQL
In response to Cristiano Panvel [EMAIL PROTECTED]: Friends help-me, As I make to compile the PostgreSQL in ports with support to the Ldap, he would like to authentication the user in the Ldap. Here, /usr/ports/databases/postgresql82-server effecting one make config does not appear the support. Somebody would know as to solve the problem. The FreeBSD port does not currently have an option to enable LDAP support. You'll need to patch the Makefile. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: postgresql's 502.pgsql periodic script and passwords
In response to George Hartzell [EMAIL PROTECTED]: I'm curious how other freebsd postgresql users handle databases with passwords and running the 502.pgsql periodic script. I've solved the problem by creating a ~pgsql/.pgpass file with the pgsql users password. Is there a better way? Depends. Do you allow untrusted users to log in to that machine? If so, then you've probably got the best approach. Make sure that .pgpass file is chmoded 600 -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System processes monitoring recomendations?
Anton Blajev - Valqk [EMAIL PROTECTED] wrote: Hello Group, I'm wondering what tool to use for system and processes monitoring? For example your disks goes filled and you get a mail, the machine has load over 50 for more than an hour and you get a mail... Some predefined processes MUST be running so there is some kind of a checker and if they stops the util starts them immediately. Please share your experience with me? Have a look at net-snmp. It's in ports. -Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System processes monitoring recomendations?
Anton Blajev - Valqk [EMAIL PROTECTED] wrote: Bill Moran wrote: Anton Blajev - Valqk [EMAIL PROTECTED] wrote: Hello Group, I'm wondering what tool to use for system and processes monitoring? For example your disks goes filled and you get a mail, the machine has load over 50 for more than an hour and you get a mail... Some predefined processes MUST be running so there is some kind of a checker and if they stops the util starts them immediately. Please share your experience with me? Have a look at net-snmp. It's in ports. 10x for the advice, is it possible to use this nice app without installing snmp daemon? I see that the app depends on x11-toolkits/p5Tk which will lead installing a whole bunch from Please don't top-post, and please wrap your lines around 72 characters. The app _is_ the snmp daemon. It's rather difficult to use it without itself. Not sure where you got the idea that it required anything x11 related. I've installed it dozens of places and never come across a dependency on x11. Are you looking at net-mgmnt/net-snmp? -Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to construct this port?
In response to Ion-Mihai \IOnut\ Tetcu [EMAIL PROTECTED]: On Thu, 28 Dec 2006 12:53:34 -0500 Chuck Swiger [EMAIL PROTECTED] wrote: [ ... ] However, sometimes mail systems go down or block traffic for whatever reason: postmaster's job is a thankless task, and this was true even before spam and viral email appeared. Nowadays, it's harder to get things mostly right (nevermind perfect), so postmasters make imperfect decisions because they are faced with undesirable tradeoffs. Indeed :-( However banning a hole country isn't a tradeoff in my book, it's just plain [inset_the_word_here]. And sine it's giving a 5XX code there's really no way to reach the person in question. I disagree. There are certain countries where the people in charge simply don't seem to care whether or not they're spamming or not. It takes a while for me to get ticked off enough to block an entire country, but there are three or four on my list right now. Besides, it's _his_ mailserver. He has the right to accept to deny mail as he sees fit. Trying to tell him otherwise is like trying to tell me that I have to eat a certain type of food. On the flip side, if you're unable to get in contact with him, why not just file a PR? At that rate, the standard timeouts go into effect. It has not been my observation that insisting people not make any mistakes commonly results in fewer mistakes being made, or much less, in zero mistakes being made. :-) Rather than try to insist they are not allowed to do something, I'd prefer to let people make their own decisions and learn which ones are mistakes. YMMV The problem is that, IMHO, this kind of rejecting affects us all as I think that being a port maintainer implies receiving and replying to users' email. No, it doesn't. Port maintainer is a volunteer position. If you start dictating too many things about what they must and must not do, you're going to run short of willing volunteers. I only maintain a few ports, but I'd quit maintaining those if someone were to tell I had to reconfigure my mailserver. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fetch-recursive broken? Is this a ports issue or just a problem with the PostgreSQL port?
In response to Shaun Amott [EMAIL PROTECTED]: On Tue, Dec 26, 2006 at 05:39:50PM -0500, Bill Moran wrote: Why should the fetch-recursive target care what's installed? Hell, I just want the distfile on the server so I can install it on other machines. I agree. Perhaps we should automatically set NO_IGNORE and TRYBROKEN for the fetch-recursive target. I'm getting lost in all the Makefiles trying to cobble together a patch to submit. Anyone familiar enough with the ports tree to do so, or at least point me in the correct direction? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fetch-recursive broken? Is this a ports issue or just a problem with the PostgreSQL port?
In response to Jeremy Chadwick [EMAIL PROTECTED]: On Wed, Dec 27, 2006 at 10:24:19AM -0500, Bill Moran wrote: In response to Shaun Amott [EMAIL PROTECTED]: On Tue, Dec 26, 2006 at 05:39:50PM -0500, Bill Moran wrote: Why should the fetch-recursive target care what's installed? Hell, I just want the distfile on the server so I can install it on other machines. I agree. Perhaps we should automatically set NO_IGNORE and TRYBROKEN for the fetch-recursive target. I'm getting lost in all the Makefiles trying to cobble together a patch to submit. Anyone familiar enough with the ports tree to do so, or at least point me in the correct direction? Bill, This will probably require the expertise of someone who's familiar with the Mk/bsd.port.mk framework. I can confirm what you're reporting, though (and have also wondered about it myself...) Also, does make fetch work (vs. make fetch-recursive) ? make fetch appears to behave identically to make fetch-recursive. It gives the same error, at least. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
fetch-recursive broken? Is this a ports issue or just a problem with the PostgreSQL port?
We have a central system that our other servers NFS mount ports from. [EMAIL PROTECTED] /usr/ports/databases/postgresql82-server]# make fetch-recursive === Fetching all distfiles for postgresql-server-8.2.0 and dependencies === postgresql-server-8.2.0 cannot install: the port wants postgresql82-client but you have postgresql81-client installed. *** Error code 1 Stop in /export/ports/databases/postgresql82-server. *** Error code 1 Stop in /export/ports/databases/postgresql82-server. Why should the fetch-recursive target care what's installed? Hell, I just want the distfile on the server so I can install it on other machines. I've seen this before in other ports, but I'm not sure if this is a problem with the ports structure in general or certain ports specifically. The PHP port, for example, does the same thing under certain conditions. Anyone care to comment? Obviously there are workarounds, but I'd like to get this fixed if possible. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Submitting a new port with dependancies not in the ports tree
Josh Paetzel [EMAIL PROTECTED] wrote: I'm in the process of writing a port and it has a dependancy that's not in the ports tree, so I'm porting that as well. My question is what's the procedure in such a case? Should I submit them both as part of the same pr? Obviously the one can't be committed without the other. I don't know if there's any official procedure on this sort of thing. But I would submit them as two separate PRs, with references from the main to the dependency for tracking purposes. This way, if the dependency goes through easy and the main port raises some discussion, you can track them separately. -Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Config info
Beech Rintoul [EMAIL PROTECTED] wrote: Can someone tell me where the config options for a port are actually stored? /var/db/ports/portname But the canonical way to adjust these is with make config in the port directory. -Bill ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rsync as a daemon doesn't play nice with rcng
In response to Erik Trulsson [EMAIL PROTECTED]: On Thu, Nov 30, 2006 at 05:09:43PM -0500, Bill Moran wrote: Noticed that the rsync port has an rcng compliant script for starting rsync in daemon mode. Nice. Unfortunately, rsync doesn't seem to write its pidfile to /var/run, and doesn't seem to even _support_ doing so. The documentation suggests that it *does* support doing so. The rsyncd.conf(5) manpage (referenced by the rsync(1) manpage) mentions a pid file option that seems to be exactly what you want. (The rsync port also installs an example rsyncd.conf into /usr/local/etc/ that sets that option.) I have never actually tried running rsync in daemon mode so I don't know if the above actually works, but it certainly seems like it should. Ahh ... so that pidfile is dependent on a setting in the config file. Of course, I was looking through the rsync(1) man page, which makes no mention of this. It's odd that there's no command line switch that corresponds. I copied the rsyncd.conf file from an older system, and didn't look at the sample until you pointed it out. It would be nice if this could be specified on the command line, so it could be a default option set in the rc script. Perfect world vs. nearly perfect world ... Thanks for the feedback. As a result, the rc system is unable to determine when it's running, thus stop and restart work poorly. Is there a mechanism within the rc system that can work around this so the rc script can be improved? -- Bill Moran Collaborative Fusion Inc. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade, apache2/apache22, php4/php5
In response to Harlan Stenn [EMAIL PROTECTED]: Will this keep across a make update, or do I need to re-do it every time I update /usr/ports? I'm not familiar with using make update and I don't see any info on it in man ports. I run make update from /usr/src - it updates /usr/src, /usr/ports, etc. portupgrade updates the information in /var/db/pkg. If make update doesn't change /var/db/pkg, then the two will not affect one another, for better or for worse. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Could use some help fixing the pecl-crack port (broken since php 5.2?)
I'm listed as the maintainer for security/pecl-crack
It was recently brought to my attention that make package fails on this
port, apparently since PHP was upgraded to 5.2:
# make package
=== Building package for pecl-crack-0.4.1
Creating package /usr/ports/security/pecl-crack/pecl-crack-0.4.1.tbz
Registering depends: php5-5.2.0 apache-2.2.3 libxml2-2.6.26 libiconv-1.9.2_2
perl-5.8.8 expat-2.0.0_1 pkg-config-0.21.
Creating bzip'd tar ball in
'/usr/ports/security/pecl-crack/pecl-crack-0.4.1.tbz'
tar: lib/php/20050922/crack.so: Cannot stat: No such file or directory
pkg_create: make_dist: tar command failed with code 256
*** Error code 1
Stop in /usr/ports/security/pecl-crack.
Now, crack.so is in /usr/local/lib/php/20060613/crack.so, so it would
appear as if my pkg-plist needs updated. No worries ...
except I'm a little unclear on the build magic behind PHP. I'm guessing
that 20060613 is some sort of API date? If so, is it Ok to be hard-
coding this in to the pkg-plist? It seems as if this is handled by
bsd.php.mk:
.if ${PHP_VER} == 4
PHP_EXT_DIR=20020429
.else
PHP_EXT_DIR=20060613
.endif
Which means hardcoding the path into the pkg-plist will break the port for
PHP 4. Despite the fact that I don't think many folks are using PHP 4,
I'd rather not do this.
Looking through some other pecl ports, none of them seem to have a pkg-plist.
If I remove the pkg-plist from the port, make package works. I guess there's
some sort of magic that allows this to work in the absence of a packing
list ... are packing lists even required any more? Does the porters
handbook need updated? Are eggs good for you or bad for you?
--
Bill Moran
Collaborative Fusion Inc.
IMPORTANT: This message contains confidential information and is intended only
for the individual named. If the reader of this message is not an intended
recipient (or the individual responsible for the delivery of this message to an
intended recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Could use some help fixing the pecl-crack port (broken since php 5.2?)
In response to Jeremy Chadwick [EMAIL PROTECTED]:
On Wed, Nov 08, 2006 at 09:24:46AM -0500, Bill Moran wrote:
Now, crack.so is in /usr/local/lib/php/20060613/crack.so, so it would
appear as if my pkg-plist needs updated. No worries ...
except I'm a little unclear on the build magic behind PHP. I'm guessing
that 20060613 is some sort of API date? If so, is it Ok to be hard-
coding this in to the pkg-plist? It seems as if this is handled by
bsd.php.mk:
.if ${PHP_VER} == 4
PHP_EXT_DIR=20020429
.else
PHP_EXT_DIR=20060613
.endif
Which means hardcoding the path into the pkg-plist will break the port for
PHP 4. Despite the fact that I don't think many folks are using PHP 4,
I'd rather not do this.
Looking at ports/Mk/bsd.php.mk, label `add-plist-phpext`, it appears the
PHP port framework already adds the appropriate .so to the packing list
for you. You can verify this by removing it from your pkg-plist, doing a
make install, then looking at /var/db/pkg/whatever/+CONTENTS
Thanks, Jeremy ... that explains it for me.
--
Bill Moran
Collaborative Fusion Inc.
IMPORTANT: This message contains confidential information and is intended only
for the individual named. If the reader of this message is not an intended
recipient (or the individual responsible for the delivery of this message to an
intended recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: experimental qemu port update, please test
In response to Juergen Lock [EMAIL PROTECTED]: (Btw did 4.x have aio? If not we need to add an IGNORE now I guess...) From the aio man page: HISTORY The aio facility appeared as a kernel option in FreeBSD 3.0. The aio kernel module appeared in FreeBSD 5.0. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems upgrading glib20
Issuing the following command: portupgrade glib Creates the following errors: [snip] ---[OK] ---/tsconv/ncnvtst/TestRegressionUTF8 ---[OK] ---/tsconv/ncnvtst/TestRegressionUTF32 ---[OK] ---/tsconv/ncnvtst/TestTruncated ---[OK] ---/tsconv/ncnvtst/TestUnicodeSet /tsconv/stdnmtst/ ---[OK] ---/tsconv/stdnmtst/TestStandardName ---[OK] ---/tsconv/stdnmtst/TestStandardNames ---[OK] ---/tsconv/stdnmtst/TestCanonicalName /custrtrn/ ---[OK] ---/custrtrn/Test_UChar_UTF32_API ---[OK] ---/custrtrn/Test_UChar_UTF8_API ---[OK] ---/custrtrn/Test_FromUTF8Lenient ---[OK] ---/custrtrn/Test_UChar_WCHART_API ---[OK] ---/custrtrn/Test_widestrs cintltst in free(): error: page is already free Abort trap (core dumped) *** Error code 134 Stop in /usr/ports/devel/icu. *** Error code 1 Stop in /usr/ports/devel/glib20. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.51377.0 env PORT_UPGRADE=yes make ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! devel/glib20 (glib-2.10.3)(coredump) --- Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed FreeBSD 6.1-p10 Ports tree updated earlier today. Any thoughts? -- Bill Moran Potential Technologies http://www.potentialtech.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make fetch refuses because dependencies aren't installed?
In response to Bjorn Nelson [EMAIL PROTECTED]: Bill, On Aug 21, 2006, at 5:07 PM, Bill Moran wrote: [EMAIL PROTECTED] /usr/ports/www/bacula-web]# make fetch This port requires the Apache Module or the CGI version of PHP, but you have already installed a PHP port without them. *** Error code 1 This is on a dedicated fetch/NFS server. It's not supposed to have mod_php installed. It would be pretty roundabout for me to install it just for the purpose of fetching a package. The machines that mount the ports tree via NFS shares off this do not have any access to the Internet for security reasons. Thus we use this machine to fetch packages into /usr/ports/distfiles, then we can build them on the secured systems. It would make life easier if make fetch and make fetch-recursive could ignore these kinds of dependency errors. It seems to me that make fetch* should _never_ fail because of dependencies. I ran into the same problem and ended up making a script to do concurrent make fetches (with a high water mark of 15 concurrent fetches): http://www.onlamp.com/bsd/2006/04/13/examples/fetch_distfiles.sh Shameless plug, but I detail setting this up on page 2 of: http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-system.html Thanks, Bjorn. In my case, I just looked up the site/filename and manually fetched the file into /usr/ports/distfiles. I was more interested in the fact that this seems to be a bug in the ports. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make fetch refuses because dependencies aren't installed?
In response to Brooks Davis [EMAIL PROTECTED]: On Mon, Aug 21, 2006 at 05:07:59PM -0400, Bill Moran wrote: [EMAIL PROTECTED] /usr/ports/www/bacula-web]# make fetch This port requires the Apache Module or the CGI version of PHP, but you have already installed a PHP port without them. *** Error code 1 This is on a dedicated fetch/NFS server. It's not supposed to have mod_php installed. It would be pretty roundabout for me to install it just for the purpose of fetching a package. The machines that mount the ports tree via NFS shares off this do not have any access to the Internet for security reasons. Thus we use this machine to fetch packages into /usr/ports/distfiles, then we can build them on the secured systems. It would make life easier if make fetch and make fetch-recursive could ignore these kinds of dependency errors. It seems to me that make fetch* should _never_ fail because of dependencies. The problem here is that the PHP support code rolls it own IGNORE type command and thus you can't easily skip it. It looks like you might be able to get away with running make fetch with FALSE=true. to get around this. There probably should be a knob to allow fetching in this case. FALSE=true, huh? That's classic. That won't have any side-effects? I'm no ports expert, but shouldn't this check occur _after_ fetching? Then, if the make target was just to fetch, no error. If the make target was a build, then the port gets fetched, _then_ the error occurs. Which is fine since the admin will probably want to fix the problem anyway, and the download won't need repeated. I noticed that the Makefile simply says WANT_PHP_WEB=yes which would seem to indicate that fixing this would fix the same problem for any number of PHP ports. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
make fetch refuses because dependencies aren't installed?
[EMAIL PROTECTED] /usr/ports/www/bacula-web]# make fetch This port requires the Apache Module or the CGI version of PHP, but you have already installed a PHP port without them. *** Error code 1 This is on a dedicated fetch/NFS server. It's not supposed to have mod_php installed. It would be pretty roundabout for me to install it just for the purpose of fetching a package. The machines that mount the ports tree via NFS shares off this do not have any access to the Internet for security reasons. Thus we use this machine to fetch packages into /usr/ports/distfiles, then we can build them on the secured systems. It would make life easier if make fetch and make fetch-recursive could ignore these kinds of dependency errors. It seems to me that make fetch* should _never_ fail because of dependencies. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Netrek port appears broken
It doesn't seem to have a maintainer. [EMAIL PROTECTED] ~]$ netrek bash: /usr/X11R6/bin/netrek: cannot execute binary file [EMAIL PROTECTED] ~]$ file /usr/X11R6/bin/netrek /usr/X11R6/bin/netrek: FreeBSD/i386 compact demand paged executable This happens whether I install BRMH or COWS. [EMAIL PROTECTED] ~]$ uname -a FreeBSD vanquish.pgh.priv.collaborativefusion.com 6.1-RELEASE FreeBSD 6.1-RELEASE #4: Tue May 16 12:43:32 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VANQUISH i386 -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
