Re: CTF: compat6x port
On 6/18/07, Marcus Alves Grando [EMAIL PROTECTED] wrote: Abdullah Ibn Hamad Al-Marri wrote: On 6/7/07, Marcus Alves Grando [EMAIL PROTECTED] wrote: Hi lists, I finish compat6x port and i need testers. If you are interested you can download shar file in http://people.freebsd.org/~mnag/compat6x.shar Feedbacks are welcome. I expect commit this until 09 Jun. Regards -- Marcus Alves Grando marcus(at)sbh.eng.br | Personal mnag(at)FreeBSD.org | FreeBSD.org Works with no issues, Thank You! Thanks to test too. When it will be in ports? :D After CURRENT bump all necessary libs. Maybe tomorrow. Regards -- Marcus Alves Grando marcus(at)sbh.eng.br | Personal mnag(at)FreeBSD.org | FreeBSD.org Will we need to rebuild world when the libs version bumped? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
portsdb -uU error
Hi, I'm getting the following on 5.5-STABLE built 18 Oct 2006: box5# portsdb -uU Updating the ports index ... Generating INDEX.tmp - please wait..=== arabic/ae_fonts_mono failed *** Error code 1 === accessibility/at-poke failed *** Error code 1 2 errors box5# more /root/ports-supfile *default host=cvsup4.uk.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress ports-all box5# more /etc/make.conf CPUTYPE?=i686 CFLAGS= -O -pipe COPTFLAGS= -O -pipe NOPROFILE= true NO_BLUETOOTH= true # do not build Bluetooth related stuff NO_PF= true # do not build PF firewall package NO_KERBEROS= true # do not build and install Kerberos 5 (KTH Heimdal) NO_TOOLCHAIN= true # do not build programs for program development # to build gnustep programs without mounting procfs WITH_GNUSTEP_FAKEMAIN=yes # added by use.perl 2006-03-16 18:34:53 PERL_VER=5.8.8 PERL_VERSION=5.8.8 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portsdb -uU error
B Hayward wrote: Hi, I'm getting the following on 5.5-STABLE built 18 Oct 2006: box5# portsdb -uU Updating the ports index ... Generating INDEX.tmp - please wait..=== arabic/ae_fonts_mono failed *** Error code 1 === accessibility/at-poke failed *** Error code 1 2 errors box5# more /root/ports-supfile *default host=cvsup4.uk.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress ports-all box5# more /etc/make.conf CPUTYPE?=i686 CFLAGS= -O -pipe COPTFLAGS= -O -pipe NOPROFILE= true NO_BLUETOOTH= true # do not build Bluetooth related stuff NO_PF= true # do not build PF firewall package NO_KERBEROS= true # do not build and install Kerberos 5 (KTH Heimdal) NO_TOOLCHAIN= true # do not build programs for program development # to build gnustep programs without mounting procfs WITH_GNUSTEP_FAKEMAIN=yes # added by use.perl 2006-03-16 18:34:53 PERL_VER=5.8.8 PERL_VERSION=5.8.8 Try re-syncing and see if stuff works. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clarification on fetch/extract targets
Sam Lawrance wrote: On 17/06/2007, at 7:33 AM, Stephen Hurd wrote: Kris Kennaway wrote: Actually, I found it quite easy to have the port pull the sources from svn. Who are we concerned about making it easier for and why (and how is it any easier?) Everyone behind a firewall that only allows fetching via HTTP/FTP, for one. Also everyone without live network access, and those with pay-per-download who have a free local distfile mirror, etc. Tarballs are overwhelmingly preferred. Kris Ok... I was looking at it from the standpoint of someone who wants the newest version and doesn't care of the pkg-plist is stale. They could just bump PORTREVISION and reinstall. So... how about this: - A distfile target which generates a distfile. The idea being that this would be the one on the local distfile mirror or what have you. - A WITH_SVN option (defaults to off) which allows the end user to specify he/she wants to use the subversion. In this case then, the end user would need to bump PORTREVISION and enable the WITH_SVN option. Rather than suggesting that users change PORTREVISION, just suggest that they set WITH_SVN and force an upgrade (eg. portupgrade -f yourport). You mean have it just grab the current head no matter what when WITH_SVN is enabled? *shudder* All kinds of arguments against that spring to mind... - This is essentially an option to break the pkg-plist - The current trunk may not build/work/etc so the option will only work sometimes - The version number becomes wrong if a later update to the port increases the revision to something less than the current one, the tools will upgrade it to an older version These are just the ones that spring to mind initially... I'm sure there are other wild and crazy things that would/could happen. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keeping track of automatically installed dependency-only ports
[LoN]Kamikaze wrote: When I want to use Software that is not in ports, I get it into the ports tree. I unfortunately don't have the time to maintain ports for every piece of software I use. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keeping track of automatically installed dependency-only ports
Peter Jeremy wrote: On 2007-Jun-16 20:44:53 -0700, Stephen Hurd [EMAIL PROTECTED] wrote: Agreed, but this situation is not easy to detect with the automated ports checks that are in place. Impossible even since we're not using automated tools. I was thinking of pointyhat The scenario is installing something *not* from ports which relies on a port which was installed as a dependency then removing the port that required the dependency. The proposed feature would remove the dependency also. Of course, simply not automatically deinstalling SDL would help out quite a bit. If I decide to remove SDL, all the results of that are my fault. If removing portXXX also removes SDL, I can blame the ports system for removing stuff out from under me. A normal 'pkg_delete' will not remove any ports other than those specified and will only remove the port(s) specified iff those ports have no other ports depending on them. If portXYZ registers a dependency on SDL then it will not be possible to remove SDL without disabling the dependency check (via '-f'). The problematic scenario is where the GNU configure script (or equivalent) for portXYZ senses the presence of SDL and decides to use it even though the port doesn't list SDL as a dependency. Two things 1) The suggestion is that pkg_delete SHOULD remove dependencies with no other dependencies marked. 2) The scenario I used was not a port, but a 3rd party piece of software. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Speedup for make clean-depends (and thus make clean)
Quoting Alexander Leidinger [EMAIL PROTECTED] (from Tue, 22
May 2007 09:26:58 +0200):
Quoting Jeremy Lea [EMAIL PROTECTED] (from Mon, 21 May 2007 15:28:16 -0700):
Hi,
On Mon, May 21, 2007 at 10:20:26AM +0200, Alexander Leidinger wrote:
I tried to do the WRKDIR and _DEPEND_DIRS part in one go myself, but
it was slower than the patch I did post (in the case where all dirs
are already clean). But I did use another implementation, I did a set
-- $$children and used shift instead of state variables. Did you
compare the speed of your patch with the speed of my patch (in a
directory with a lot of dependencies like e.g. gnome2)?
In /usr/ports/x11/gnome2 (on an up to date port's tree):
make clean-depends:
real 1030.98user 916.21 sys 102.80
make all-depends-list:
real 348.25 user 310.27 sys 32.01
make clean-depends-list: (Your patch)
real 685.53 user 611.60 sys 65.93
make clean-depends-full:
real 346.18 user 310.53 sys 31.94
make clean-depends-quick:
real 124.72 user 119.88 sys 3.73
In other words, it takes my poor old machine 17 minutes to do a 'make
clean' of gnome2 with no existing work directories (i.e. to do nothing).
Of that 5.8 minutes is spent building the list of directories to clean.
Your patch increases that to 11.4 minutes (meaning that 'make clean' is
33% faster - which matches the numbers you posted). With my patch it
takes the same time to build the list (meaning 'make clean' is 66%
faster).
The cheating quick version takes one tenth of the time, because gnome2
directly depends on 57 ports, out of 508 total (on my machine).
Yay! Please send-pr and assign to portmgr.
Hi Jeremy, have you send the patch to gnats? If not, could you please
do it (pav@ is interested to run it on the ports build cluster for
testing)? If you don't have time, is it ok if I send your patch?
Bye,
Alexander.
From bsd.port.mk:
# clean - Remove ${WRKDIR} and other temporary files used for building.
# clean-depends - Do a make clean for all dependencies.
This is the only documentation of the targets that I found. Using the
limited-clean target would get users exactly the this behaviour - it
would clean up the port and all of the other ports it depended on that
were built to statisfy the building of this port.
I think this should speed up the ports build on the cluster (if they
don't already cheat and have a dedicated FS which is newfs'ed each
time) a little bit (together with the other patches we have, it is a
very nice improvement overall).
I've added some more to the attched patch, including the idea of a
pre-clean, which would be useful for portupgrade, since it could define
DEPENDS_PRECLEAN and not have to worry about cleaning before building...
Yes, sounds nice.
Bye,
Alexander.
--
Leela: Okay, this has gotta stop. I'm going to remind Fry of his
humanity the way only a woman can.
Professor: You're going to do his laundry?
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
--
The human brain is like an enormous fish -- it is flat and slimy and
has gills through which it can see.
-- Monty Python
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make update broken
Alex Dupre ha scritto: Erwin Lansing wrote: As I described earlier, SUP_UPDATE, CVS_UPDATE and PORTSNAP_UPDATE are mutually exclusive and cannot be used at the same time. From src/Makefile.inc1: # update # # Update the source tree, by running cvsup and/or running cvs to update # to the latest copy. From ports/Makefile rev. 1.61 commit log: Allow both SUP_UPDATE and CVS_UPDATE to be used, similar to src/Makefile The same commit introduced the check .if defined(SUP_UPDATE) !defined(PORTSSUPFILE) with a different meaning from what you say. All the docs I found says explicitly (and does accordingly) that SUP_UPDATE and CVS_UPDATE are *not* mutually exclusive and that SUP_UPDATE can be defined *without* PORTSUPFILE. Please send-pr your patch, but please also add documentation of the new meaning of PORTSNAP_UPDATE. I'll do it. PR 113819 -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Speedup for make clean-depends (and thus make clean)
Alexander Leidinger píše v po 18. 06. 2007 v 12:05 +0200: Quoting Alexander Leidinger [EMAIL PROTECTED] (from Tue, 22 May 2007 09:26:58 +0200): Quoting Jeremy Lea [EMAIL PROTECTED] (from Mon, 21 May 2007 15:28:16 -0700): Hi, On Mon, May 21, 2007 at 10:20:26AM +0200, Alexander Leidinger wrote: I tried to do the WRKDIR and _DEPEND_DIRS part in one go myself, but it was slower than the patch I did post (in the case where all dirs are already clean). But I did use another implementation, I did a set -- $$children and used shift instead of state variables. Did you compare the speed of your patch with the speed of my patch (in a directory with a lot of dependencies like e.g. gnome2)? In /usr/ports/x11/gnome2 (on an up to date port's tree): make clean-depends: real 1030.98 user 916.21 sys 102.80 make all-depends-list: real 348.25user 310.27 sys 32.01 make clean-depends-list: (Your patch) real 685.53user 611.60 sys 65.93 make clean-depends-full: real 346.18user 310.53 sys 31.94 make clean-depends-quick: real 124.72user 119.88 sys 3.73 In other words, it takes my poor old machine 17 minutes to do a 'make clean' of gnome2 with no existing work directories (i.e. to do nothing). Of that 5.8 minutes is spent building the list of directories to clean. Your patch increases that to 11.4 minutes (meaning that 'make clean' is 33% faster - which matches the numbers you posted). With my patch it takes the same time to build the list (meaning 'make clean' is 66% faster). The cheating quick version takes one tenth of the time, because gnome2 directly depends on 57 ports, out of 508 total (on my machine). Yay! Please send-pr and assign to portmgr. Hi Jeremy, have you send the patch to gnats? If not, could you please do it (pav@ is interested to run it on the ports build cluster for testing)? If you don't have time, is it ok if I send your patch? I have this patch locally, it's slated for an exprun next to the upcoming one. Of course, filing it in GNATS does not hurt. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Do not meddle in the fashions of wizards, for they are seasonal and quick to fall out of style! signature.asc Description: Toto je digitálně podepsaná část zprávy
Current unassigned ports problem reports
Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems S Tracker Resp. Description o ports/112754VERY SERIOUS security bug in sysutils/eject 1 problem total. Serious problems S Tracker Resp. Description o ports/105549ports/www/squid_radius_auth doesn't work on sparc64 o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode o ports/107536editors/scite: Can't write on SciTE text editor f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108413net/vnc does not works. f ports/108537print/hplip: Build failure f ports/108606Courier MTA terminates abnormaly after installation o ports/108748mod_fcgid 1.10 does not work inside jail f ports/110035Port fix for sysutils/be_agent o ports/110943start-dccifd chowns /var/run to user dcc o ports/51ports/lang/stklos: l/bin/stklos-install is a buggy she f ports/111338graphics/yafray: doesn't respect CXX, CXXFLAGS and eve o ports/111462syslog-ng2 default configuration file path o ports/111923[PATCH] databases/unixODBC overwrites config file on p o ports/112083mail/qsheff overwrites configuration upon upgrade f ports/112094www/lynx: plist missing configuration file o ports/112097print/ghostscript-gpl-nox11 compile fails due to missi o ports/112277MD5 and SHA256 mismatch for science/hdf5 o ports/112287www/rt36: add missed patches for MULTIPLE_INSTANCES o ports/112385sysutils/lookupd on Kernel 64 f ports/112468sysutils/bacula-server 2.0.3 port build fails for sqli o ports/112545print/ghostscript-gpl 8.54 fail without all driver (or f ports/112698www/opera's spell-check doesn't work o ports/112739audio/midimountain doesn't work as patched o ports/112793editors/e3 problem: one line patch to fix bad syscall f ports/112868[maintainer update] science/afni f ports/112921x11-wm/Beryl not loading focus and keybinding settings f ports/112988print/HPLIP portupgrade failure f ports/113139sysutils/ucspi-tcp runtime crash on amd64 w/ fix o ports/113144print/ghostscript-gnu dumps core with several output d f ports/113212www/jesred: Fix incompatibility with Squid 2.6 f ports/113498www/elinks: lua scripting broken o ports/113818svnserve rc script can't stop svnserve 34 problems total. Non-critical problems S Tracker Resp. Description o ports/94921 isakmpd fails on amd64 o ports/95854 New Port: www/ochusha o ports/100896[new ports] emulators/vmware-server-guestd1 emulators/ o ports/101275bug fixed in sudo that prevented use in LDAP user acco o ports/103395security/gnome-ssh-askpass interferes with gnome-scree o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM f ports/107368audio/normalize: [patch] - normalize-mp3 and normalize f ports/107621net/proxychains doens't compile on 4 and 5 f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut f ports/108104print/hplip: documentation gets installed though NOPOR o ports/108595pstree (sysutils/psmisc) don't work in jail f
ports/x11/nvidia-driver-9xxx: new 9639 version
I successfully used /usr/ports/x11/nvidia-driver-9631/Makefile to install the 9639 version. I just appended a EXTRA_PATCHES= line. Maybe it's time to update to the latest legacy version at ttp://www.nvidia.com/object/unix.html So far, my GeForce2 MX 100/200 is running ok =) Cheers, Igh ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clarification on fetch/extract targets
On 18/06/2007, at 7:28 PM, Stephen Hurd wrote: Sam Lawrance wrote: On 17/06/2007, at 7:33 AM, Stephen Hurd wrote: Kris Kennaway wrote: Actually, I found it quite easy to have the port pull the sources from svn. Who are we concerned about making it easier for and why (and how is it any easier?) Everyone behind a firewall that only allows fetching via HTTP/ FTP, for one. Also everyone without live network access, and those with pay-per-download who have a free local distfile mirror, etc. Tarballs are overwhelmingly preferred. Kris Ok... I was looking at it from the standpoint of someone who wants the newest version and doesn't care of the pkg-plist is stale. They could just bump PORTREVISION and reinstall. So... how about this: - A distfile target which generates a distfile. The idea being that this would be the one on the local distfile mirror or what have you. - A WITH_SVN option (defaults to off) which allows the end user to specify he/she wants to use the subversion. In this case then, the end user would need to bump PORTREVISION and enable the WITH_SVN option. Rather than suggesting that users change PORTREVISION, just suggest that they set WITH_SVN and force an upgrade (eg. portupgrade -f yourport). You mean have it just grab the current head no matter what when WITH_SVN is enabled? *shudder* All kinds of arguments against that spring to mind... - This is essentially an option to break the pkg-plist - The current trunk may not build/work/etc so the option will only work sometimes - The version number becomes wrong if a later update to the port increases the revision to something less than the current one, the tools will upgrade it to an older version These are just the ones that spring to mind initially... I'm sure there are other wild and crazy things that would/could happen. Maybe I don't understand what you're trying to do. What's the point of bumping PORTREVISION? For that matter, what's the point of WITH_SVN given what you've just said? ___ 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 make a make install without questions?
make config-recursive is probably what you want as was said earlier. However, config-recursive only calls the make config for the dependancies, if you for some reason add another dependancy(by selecting some optionas) then the make config isn't called for this port. That's why I recommend you to be sure to run it again till you don't change configurations. This will save you the bleh forgot to config *that* port :D On 6/17/07, Ion-Mihai Tetcu [EMAIL PROTECTED] wrote: On Sun, 17 Jun 2007 12:10:29 +0200 TooMany Secrets [EMAIL PROTECTED] wrote: Hi! Excuse me if this is a estupid question, but in six years with FreeBSD, today I haven't still an answer to this: - If I make a make install clean, in a port like x11/kde3, are there any way to make the lack of questions? Or maybe better, are there any way to make anything like make -y (or -Y for YES options) install clean? The trouble is ports like KDE, with platform independency (more or less cpu power), take more time because you need to stay (more or less) in front of computer to choose and accept the port options. I understand that you don't need this with other ports (like apache, php, etc), for obvious reasons. But I think that with ports like gnome2 or kde3, maybe I believe that it would be a great saving of time. Sorry if the question is understandable for my bad english. `make config-recursive` in the port's directory will help, except for ports that choose not to implement OPTIONS but their own custom script (poking their maintainers might be a .. useful idea). -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect ___ 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 make a make install without questions?
The way I do it is: make BATCH=yes install clean Hope that helps... -Matt On Sun, 17 Jun 2007 12:10:29 +0200, TooMany Secrets [EMAIL PROTECTED] wrote: Hi! Excuse me if this is a estupid question, but in six years with FreeBSD, today I haven't still an answer to this: - If I make a make install clean, in a port like x11/kde3, are there any way to make the lack of questions? Or maybe better, are there any way to make anything like make -y (or -Y for YES options) install clean? The trouble is ports like KDE, with platform independency (more or less cpu power), take more time because you need to stay (more or less) in front of computer to choose and accept the port options. I understand that you don't need this with other ports (like apache, php, etc), for obvious reasons. But I think that with ports like gnome2 or kde3, maybe I believe that it would be a great saving of time. Sorry if the question is understandable for my bad english. -- Have a nice day ;-) TooManySecrets Dijo Confucio: Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: mysql-server-3.23.59.n.20050301_3
Using the apache port as the standard example of how ports should be installed I have noticed 2 things wrong with the mysql-server port. First the port allocates the location for the databases to /var/db/mysql. This location has no space allocated to hold database data. It should be changed to /usr/local/mysql Next the mysql manual should be included in the port just like the apache manual is. These are not technical changes but will make the FBSD port of mysql more easy to use. Looking for feedback from the port team about these suggestions. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Installing Openoffice.org-2-RC and bison conflicts
I'm trying to install openoffice, and some sub-portion of the port is installing bison2, and later it tries to install bison and then it complains about conflicting ports. How is one supposed to deal with sub-port conflicts like these? Why do we /ever/ allow ports to have conflicts with other ports? That seems broken from the start. Thanks, -Clint ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: mysql-server-3.23.59.n.20050301_3
On Mon, Jun 18, 2007 at 06:41:23PM -0400, Bob wrote: First the port allocates the location for the databases to /var/db/mysql. This location has no space allocated to hold database data. It should be changed to /usr/local/mysql You're complaining about the default location of mysql_dbdir, which is somewhat understandable. /var/db/mysql is a good place for it. Ideally, the /var filesystem should be increased when choosing [A]utomatic during filesystem creation (I believe it picks 2GB or something like that), but that's not the responsibility of -ports. The size of each filesystem is up to you to decide; sticking everything blindly into /usr or subtrees of /usr (e.g. /usr/local) simply because FreeBSD defaults to all remaining space -- /usr doesn't justify laziness during initial filesystem creation time. Yes, I realise some other ports do this (Apache for example, although it's quite justified for Apache), and they probably shouldn't. Deciding if ports should install themselves into LOCALBASE/portname or not is quite political, I think... Anyways, what you can do is install MySQL normally, which of course drops the MySQL database structure into /var/db/mysql. Once there, you can move that directory to someplace of your choice (/usr/local/mysql or /home/mysql or whatever you want), then modify rc.conf to say mysql_dbdir=/wherever/mysql. pkg_delete/deinstalling the mysql-server port won't nuke contents of that directory, and future installations (as long as the existing mysql/* tables exist in mysql_dbdir) will skip installing out-of-the-box MySQL databases/tables. Next the mysql manual should be included in the port just like the apache manual is. I second this. I've often the need to review MySQL server configuration changes on a system without (at the time) network access. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: mysql-server-3.23.59.n.20050301_3
On Mon, Jun 18, 2007 at 04:02:41PM -0700, Jeremy Chadwick wrote: On Mon, Jun 18, 2007 at 06:41:23PM -0400, Bob wrote: First the port allocates the location for the databases to /var/db/mysql. This location has no space allocated to hold database data. It should be changed to /usr/local/mysql You're complaining about the default location of mysql_dbdir, which is somewhat understandable. /var/db/mysql is a good place for it. Ideally, the /var filesystem should be increased when choosing [A]utomatic during filesystem creation (I believe it picks 2GB or something like that), but that's not the responsibility of -ports. The size of each filesystem is up to you to decide; sticking everything blindly into /usr or subtrees of /usr (e.g. /usr/local) simply because FreeBSD defaults to all remaining space -- /usr doesn't justify laziness during initial filesystem creation time. Yes, I realise some other ports do this (Apache for example, although it's quite justified for Apache), and they probably shouldn't. Deciding if ports should install themselves into LOCALBASE/portname or not is quite political, I think... Anyways, what you can do is install MySQL normally, which of course drops the MySQL database structure into /var/db/mysql. Once there, you can move that directory to someplace of your choice (/usr/local/mysql or /home/mysql or whatever you want), then modify rc.conf to say mysql_dbdir=/wherever/mysql. pkg_delete/deinstalling the mysql-server port won't nuke contents of that directory, and future installations (as long as the existing mysql/* tables exist in mysql_dbdir) will skip installing out-of-the-box MySQL databases/tables. Or just symlink it. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing Openoffice.org-2-RC and bison conflicts
On Jun 18, 2007, at 3:59 PM, Clint Olsen wrote: I'm trying to install openoffice, and some sub-portion of the port is installing bison2, and later it tries to install bison and then it complains about conflicting ports. How is one supposed to deal with sub-port conflicts like these? Why do we /ever/ allow ports to have conflicts with other ports? Two ports which install files to the same place conflict-- you can't have two different versions of a file at the same path location. With some work, it is possible to install multiple versions of some ports (like Perl, Berkeley DB, GNU autoconf, etc) using a version # suffix, and symlink the version you prefer to the unqualified name: % ls -l /usr/local/bin/perl5 lrwxr-xr-x 1 root wheel 24 Mar 23 2006 /usr/local/bin/perl5@ - / usr/local/bin/perl5.8.8 ...but it doesn't magically happen. -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing Openoffice.org-2-RC and bison conflicts
On Jun 18, Chuck Swiger wrote: Two ports which install files to the same place conflict-- you can't have two different versions of a file at the same path location. With some work, it is possible to install multiple versions of some ports (like Perl, Berkeley DB, GNU autoconf, etc) using a version # suffix, and symlink the version you prefer to the unqualified name: % ls -l /usr/local/bin/perl5 lrwxr-xr-x 1 root wheel 24 Mar 23 2006 /usr/local/bin/perl5@ - / usr/local/bin/perl5.8.8 ...but it doesn't magically happen. Ok, so I'm required to resolve this myself if I want to install this port? -Clint ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing Openoffice.org-2-RC and bison conflicts
On Jun 18, 2007, at 4:33 PM, Clint Olsen wrote: [ ... ] % ls -l /usr/local/bin/perl5 lrwxr-xr-x 1 root wheel 24 Mar 23 2006 /usr/local/bin/perl5@ - / usr/local/bin/perl5.8.8 ...but it doesn't magically happen. Ok, so I'm required to resolve this myself if I want to install this port? It's likely that the maintainer of OpenOffice can provide help/ suggestions. They'll probably want to know the release of FreeBSD you are running and maybe the list of installed ports on your machine... -- -Chuck ___ 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 make a make install without questions?
TooMany Secrets wrote: Hi! Excuse me if this is a estupid question, but in six years with FreeBSD, today I haven't still an answer to this: - If I make a make install clean, in a port like x11/kde3, are there any way to make the lack of questions? Or maybe better, are there any way to make anything like make -y (or -Y for YES options) install clean? The trouble is ports like KDE, with platform independency (more or less cpu power), take more time because you need to stay (more or less) in front of computer to choose and accept the port options. I understand that you don't need this with other ports (like apache, php, etc), for obvious reasons. But I think that with ports like gnome2 or kde3, maybe I believe that it would be a great saving of time. You might want to take a look at ports-mgmt/portmaster for one solution to this problem. It recurses through all the dependencies that need to be updated or installed for a given port, and gives you the OPTIONS dialog for each one before starting to build. This has one significant advantage over 'make config-recursive' because the OPTIONS you choose for one port might affect the dependencies for that port, which portmaster takes into account. hope this helps, Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clarification on fetch/extract targets
On 19/06/2007, at 2:06 PM, Stephen Hurd wrote: Sam Lawrance wrote: Maybe I don't understand what you're trying to do. What's the point of bumping PORTREVISION? For that matter, what's the point of WITH_SVN given what you've just said? PORTREVISION == SVN Revision OK, it makes sense to me now that you explained that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: mysql-server-3.23.59.n.20050301_3
Kris Kennaway wrote:
First the port allocates the location for the databases to /var/db/mysql.
This location has no space allocated to hold database data.
It should be changed to /usr/local/mysql
You can change it as you like with mysql_dbdir=/new/path, so this
isn't an issue.
Or just symlink it.
This may have performance implications. It works, but now is discouraged.
Next the mysql manual should be included in the port just like the apache
manual is.
html, txt and info versions are not enough?
.if !defined(NOPORTDOCS)
DOCS= manual.html manual.txt manual_toc.html
PORTDOCS= ${DOCS} Flags
.endif
INFO= mysql
--
Alex Dupre
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
