Re: .warning directives in Makefile
Mikhail Teterin wrote: But I'd like remind .warning directive pollutes stderr Warnings are NOT pollution... and discouraged portupgrade which was designed to catch messages from stderr and rises errors. I'd say, the portupgrade needs fixing, if it does, indeed, choke on Well, only imagemagic and ghostscript* use .warning. It is NOT a common way to print warnings. Why do you think portupgrade needs fixing? -- Dixi. Sem. ___ 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: automake-1.9.6_2
Use a ports-supported version of FreeBSD. 6.3 and above. -aDe On Jun 25, 2008, at 20:25 , email wrote: How to fix this? '`; fi; rm -rf $backupdir; exit $rc ./automake-1.9.texi:9821: Unknown command `headitem'. makeinfo: Removing output file `./automake-1.9.info' due to errors; use --force to preserve. *** Error code 1 Stop in /usr/ports/devel/automake19/work/automake-1.9.6/doc. *** Error code 1 Stop in /usr/ports/devel/automake19/work/automake-1.9.6. *** Error code 1 Stop in /usr/ports/devel/automake19. guice# ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: .warning directives in Makefile
On п'ятниця 27 червень 2008, Sergey Matveychuk wrote: = Mikhail Teterin wrote: = = But I'd like remind .warning directive pollutes stderr = Warnings are NOT pollution... = and discouraged portupgrade which was designed to catch messages from = stderr and rises errors. = I'd say, the portupgrade needs fixing, if it does, indeed, choke on = = Well, only imagemagic and ghostscript* use .warning. It is NOT a common = way to print warnings. Some criteria! FreeBSD is not a common way to keep computers running either... = Why do you think portupgrade needs fixing? I already said, why -- there is nothing wrong with using stderr to warn. All compilers do that, for one example -- that's /exactly/ what stderr is for: diagnostic information. Try redirecting cc's stdout to /dev/null -- you'll still see the warnings (unless you also redirect stderr). If foo chokes on that, you should be contacting foo's maintainer, but that's not me (nor do I maintain imagemagic or ghostscript, BTW). In case of portupgrade, the foo is not even part of FreeBSD -- I don't understand, why you think, you can demand patches from me... Yours, -mi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 8-current/kde3 stty defaults incorrect under konsole
On Wed, Jun 25, 2008 at 04:51:02PM +0200, Alexey Shuvaev wrote: Hello! On Wed, Jun 25, 2008 at 07:10:14AM -0700, Mark Atkinson wrote: Hi, Is anyone else running freebsd-current with kde3 (and has rebuilt both recently)? I can only suspect this is related to recent changes in current in prep for mpsafe tty, but in konsole, the defaults turn out to be this (note the missing '^' on intr and quit): cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; eol2 = undef; erase = ^?; erase2 = ^H; intr = C; kill = ^U; lnext = ^V; min = 1; quit = \; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; xterm and the freebsd console are fine. I have noticed that cursor key (right, forward direction) does not work as expected. By pressing it cancels the current command line and prompts with the empty one again. [snip] On Wed, Jun 25, 2008 at 04:34:28PM +0200, Ed Schouten wrote: Blegh. I always hate those applications using non-documented extensions in a non-standard way. ;-) Anyway, could you store this patch in the files/ dir of the kdelibs3 port and see what happens? Thanks! :) %%% --- kdecore/kpty.cpp +++ kdecore/kpty.cpp @@ -128,9 +128,8 @@ #include kstandarddirs.h // locate // not defined on HP-UX for example -#ifndef CTRL -# define CTRL(x) ((x) 037) -#endif +#undef CTRL +#define CTRL(x) ((x) 037) #define TTY_GROUP tty %%% Thanks, I will try this but it takes a while, it is 800MHz Pentium3 :-) Alexey. I have rebuilt kdelibs with this patch and now both wrong stty -a values and issues with cursor keys are gone. Thanks! Any chance to have this patch in the ports tree? Alexey. --- kdecore/kpty.cpp +++ kdecore/kpty.cpp @@ -128,9 +128,8 @@ #include kstandarddirs.h // locate // not defined on HP-UX for example -#ifndef CTRL -# define CTRL(x) ((x) 037) -#endif +#undef CTRL +#define CTRL(x) ((x) 037) #define TTY_GROUP tty ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creating New Port - Question about Installation
On Thu, Jun 26, 2008 at 7:36 PM, Pietro Cerutti [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Schiz0 wrote:
| Hey,
|
| I'm attempting to create a new port for btsh:
| http://btsh.sourceforge.net/
| The website isn't finished yet, but it's a command-line interface for
| torrent websites.
|
| Anyway, the original .tar.bz2 that the author wrote has no configure
| script or makefile. All it has is an INSTALL script. The INSTALL
| script prompts for a directory to install to, then copies the proper
| files over and sets some permissions.
|
| I'm wondering how I can create a port out of this. I read the porters
| handbook and developed a Makefile so far:
|
|
| # Ports Makefile for: btsh
| # Date created:June 26 2008
| # Whom:Schiz0
| #
| # $FreeBSD$
| #
| PORTNAME=btsh
| PORTVERSION=0.1.1
| CATEGORIES=net-p2p shells
| # Eventually the project is moving over to sourceforge
| MASTER_SITES=http://labgecko.com/btsh/
| [EMAIL PROTECTED]
| COMMENT=BitTorrent SHell
| BUILD_DEPENDS=bash:${PORTSDIR}/shells/bash
| BUILD_DEPENDS=wget:${PORTSDIR}/ftp/wget
The second BUILD_DEPENDS definition will overwrite the first one. Use:
BUILD_DEPENDS= bash:${PORTSDIR}/shells/bash \
wget:${PORTSDIR}}/ftp/wget
Moreover, sure they're not RUN_DEPENDS as well?
Ah, thank you. They are RUN_DEPENDS, but I didn't think I needed to
specify bash and wget in both of them. I'll fix that. Thanks.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
CFT: net/freeradius2 upgrade to 2.0.5 (was FreeBSD Port: freeradius-mysql-1.1.7_3)
(please skip down to the line of if you just want the Call for Testers) Hi Scott, Giovanni and all, In message [EMAIL PROTECTED], Scott Lambert [EMAIL PROTECTED] writes On Thu, Jun 26, 2008 at 11:25:48PM +0200, Giovanni Venturi wrote: Hello, what is the difference between freeradius-mysql-1.1.7_3 and freeradius-2.0.3_1 ? In this last one is MySQL support disabled? Has been released Free Radius 2.0.5 on the 7th June. You could update the port :) . Thank you from now for your reply. I started work on 2.0.5 immediately it was released, as did [EMAIL PROTECTED] Do not use the freeradius 1.x stuff, especially if this is a new installation. 2.x is much better. I agree - FreeRADIUS 1.x is deprecated and is already far behind 2.x. All new deployments should be 2.x now. Once I've got 2.0.5 sorted, I intend to ask for a repocopy of net/freeradius to net/freeradius1 as part of my ongoing plan to deprecate the 1.x port. The FreeRADIUS 2.x port has a higher footprint than 1.x because of its current unconditional dependency on python which matters for embedded users. I believe bsd.options.mk is now available for use following the EoL of FreeBSD 5.x, 6.1 and 6.2. That being the case, I can use bsd.options.mk to create a PYTHON option without the ugly hack in the FreeRADIUS 1.x port. The freeradius2 port gives you the option of adding whatever database support you desire. Indeed. The freeradius-mysql port is simply freeradius with the MYSQL option forced on. It exists to ensure that a FreeRADIUS 1.x package with MySQL support is available on the FreeBSD FTP servers. This is required for some work that's being done on the pfSense firewall. Check the mailing list archives from the past week or so for why the freeradius2 port has not yet been updated. As Scott later said, the thread was over at freeradius-users. PR ports/124439 is where we're up to on updating the port to 2.0.5 - that's http://www.freebsd.org/cgi/query-pr.cgi?pr=124439 I believe the port is now correct - though I'm waiting on word from mm@ about testing it (I've copied him into this reply). I want to revisit the new pkg-message, also I need to write an entry for UPDATING - I'm hoping to have this done within the next 48 hours. It will be later today if I can get through some other tasks. I'm very conscious of the need not to trash people's configurations when they upgrade, which is why we're taking our time over this upgrade. I hadn't anticipated the reorganisation of the raddb configuration folder in 2.0.5, though I do support it. Without changing the behaviour of the port, we'd finish up with those upgrading from an older versions having two copies of the configuration for each module, with only one linked in to their live configuration. That's a recipe for disaster. The pre-release 2.0.5 port has some new features that means that it's much easier to get FreeRADIUS going 'out of the box' - you get a pkg-message that walks you through what needs to be done. Please try the pre-release port - I'd be glad to receive your feedback. I open this to all FreeRADIUS users - please try the pre-release 2.0.5 port. Those updating from 1.x should read the UPDATING message of 20080118. I do encourage all FreeRADIUS users to upgrade now - the FreeRADIUS developers have indicated that there will be no further development of 1.x. Amongst many things, 2.x has many bug fixes that are not feasible in the 1.x code base. Everyone who is upgrading should make sure you take a backup of your configuration *before* uninstalling your existing FreeRADIUS port. Reading PR ports/124439 is recommended. My message on freeradius-users http://www.nabble.com/Re%3A-Dependencies-of-Freeradius-2.0.5-p18040698.ht ml will walk you through creating a patched copy of the port and installing FreeRADIUS 2 from it. Those who are upgrading will need to uninstall your existing port before the final 'make install' step - if you want to keep the downtime to a minimum, 'make build', uninstall your existing port, then 'make install'. Don't forget to '/usr/local/etc/rc.d/radiusd start' after the upgrade. I do not anticipate any further changes in the code, though I am going to tidy the pkg-message a little and write an UPDATING entry. I will keep the patch mentioned in the PR updated, so you'll get wherever I'm up to at the time. It would help if any comments gave the 'revision' number in the third line of the patch file; I can relate that back to the Subversion repository in which I develop these ports. The current revision is 202. Comments on the new pkg-message and bootstrap behaviour are especially welcomed. Best wishes, David (maintainer of net/freeradius2) -- David Wood [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list
Re: Portmanager stuck in a loop
On Thu, 2008-06-26 at 15:54 -0400, Josh Hanson wrote: Hi, I'm setting up a fresh installation of freebsd, and portmanager keeps getting stuck in a loop while trying to upgrade ports. I ran portmanager -u -l with several dozen ports to upgrade. It seemed to successfully upgrade quite a few ports; for several ports, it brought up the menu with configuration options, and I always just left the defaults. Eventually, I noticed it brought up some familiar-looking configuration screens. Soon, it was simply cycling through the same 3 ports' configuration screens repeatedly. The log shows messages for each port (repeatedly) saying, options changed so returning [port name] to out of date pool. Some of the port system optimizations caused a situation where a port can be left dependent on multiple versions of the same origin. (Through recursive dependencies) As a result, portmanager will continue to try and update the port. I need to do something of an overhaul of portmanager, but other projects are consuming most of my free time lately. If you use the -p (pristine) flag, portmanager will avoid this issue by ensuring that all ports are updated in order, no matter how deep in the dependency tree. FWIW, my usage of portmanager is portmanager -u -p -l -y. robert. I tried manually installing those 3 ports; each said it was already installed, so I did a make uninstall then make install for each one, and ran portmanager again. It continued to run just fine, upgrading more ports, then hit the same sort of loop with another set of ports. I upgraded those manually and tried again; each time I installed some ports manually, portmanager would get stuck repeating one or more ports. Background: I had just done a full install from the freebsd CDs, including every standard package except the source code. I then ran portsnap, then installed both portupgrade and portmanager, but after a bit of reading decided to use portmanager. Portmanager listed several dozen installed ports with updates available. When I ran it, I encountered the above issues. An excerpt from the most recent (odd-looking) log file is below. Notice that it's repeating the same port over and over. PS: I'm fairly new to FreeBSD, so if I'm missing something obvious or asking this question to the wrong place, please let me know. (Though, even if I'm doing something wrong, there seems to be a bug in portmanager, which is clearly not exhibiting the intended behavior.) -- Josh Log file follows: portmanager 0.4.1_9 FreeBSD noc.caprio.corp 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 autoConflicts 0 autoMoved 0 backUp 0 buildDependsAreLeaves 0 forced 0 interactive0 log1 pmMode 0 pristine 0 resume 0 Thu Jun 26 01:04:38 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:23 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:31 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:36 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:44 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:49 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:57 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:06:01 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] -- Robert Noland [EMAIL PROTECTED] 2Hip Networks ___ freebsd-ports@freebsd.org mailing list
RE: Portmanager stuck in a loop
Ok, so I tried running portmanager -u -p -l -y. It built a lot of ports, then got stuck again on xorg-server over and over. The log file looks the same as my first post. -- Josh -Original Message- From: Robert Noland [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 10:34 AM To: Josh Hanson Cc: freebsd-ports@freebsd.org Subject: Re: Portmanager stuck in a loop On Thu, 2008-06-26 at 15:54 -0400, Josh Hanson wrote: Hi, I'm setting up a fresh installation of freebsd, and portmanager keeps getting stuck in a loop while trying to upgrade ports. I ran portmanager -u -l with several dozen ports to upgrade. It seemed to successfully upgrade quite a few ports; for several ports, it brought up the menu with configuration options, and I always just left the defaults. Eventually, I noticed it brought up some familiar-looking configuration screens. Soon, it was simply cycling through the same 3 ports' configuration screens repeatedly. The log shows messages for each port (repeatedly) saying, options changed so returning [port name] to out of date pool. Some of the port system optimizations caused a situation where a port can be left dependent on multiple versions of the same origin. (Through recursive dependencies) As a result, portmanager will continue to try and update the port. I need to do something of an overhaul of portmanager, but other projects are consuming most of my free time lately. If you use the -p (pristine) flag, portmanager will avoid this issue by ensuring that all ports are updated in order, no matter how deep in the dependency tree. FWIW, my usage of portmanager is portmanager -u -p -l -y. robert. I tried manually installing those 3 ports; each said it was already installed, so I did a make uninstall then make install for each one, and ran portmanager again. It continued to run just fine, upgrading more ports, then hit the same sort of loop with another set of ports. I upgraded those manually and tried again; each time I installed some ports manually, portmanager would get stuck repeating one or more ports. Background: I had just done a full install from the freebsd CDs, including every standard package except the source code. I then ran portsnap, then installed both portupgrade and portmanager, but after a bit of reading decided to use portmanager. Portmanager listed several dozen installed ports with updates available. When I ran it, I encountered the above issues. An excerpt from the most recent (odd-looking) log file is below. Notice that it's repeating the same port over and over. PS: I'm fairly new to FreeBSD, so if I'm missing something obvious or asking this question to the wrong place, please let me know. (Though, even if I'm doing something wrong, there seems to be a bug in portmanager, which is clearly not exhibiting the intended behavior.) -- Josh Log file follows: portmanager 0.4.1_9 FreeBSD noc.caprio.corp 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 autoConflicts 0 autoMoved 0 backUp 0 buildDependsAreLeaves 0 forced 0 interactive0 log1 pmMode 0 pristine 0 resume 0 Thu Jun 26 01:04:38 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:23 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:31 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:36 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:44 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:49 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:57 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:06:01 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of
RE: Portmanager stuck in a loop
On Fri, 2008-06-27 at 10:46 -0400, Josh Hanson wrote: Ok, so I tried running portmanager -u -p -l -y. It built a lot of ports, then got stuck again on xorg-server over and over. The log file looks the same as my first post. Is the options screen being presented repeatedly? If so, the options are corrupt and/or not being stored properly. The dialog box should only be shown once and use the stored options after that. You are running as a user with permission to update /var/db/ports? robert. -- Josh -Original Message- From: Robert Noland [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 10:34 AM To: Josh Hanson Cc: freebsd-ports@freebsd.org Subject: Re: Portmanager stuck in a loop On Thu, 2008-06-26 at 15:54 -0400, Josh Hanson wrote: Hi, I'm setting up a fresh installation of freebsd, and portmanager keeps getting stuck in a loop while trying to upgrade ports. I ran portmanager -u -l with several dozen ports to upgrade. It seemed to successfully upgrade quite a few ports; for several ports, it brought up the menu with configuration options, and I always just left the defaults. Eventually, I noticed it brought up some familiar-looking configuration screens. Soon, it was simply cycling through the same 3 ports' configuration screens repeatedly. The log shows messages for each port (repeatedly) saying, options changed so returning [port name] to out of date pool. Some of the port system optimizations caused a situation where a port can be left dependent on multiple versions of the same origin. (Through recursive dependencies) As a result, portmanager will continue to try and update the port. I need to do something of an overhaul of portmanager, but other projects are consuming most of my free time lately. If you use the -p (pristine) flag, portmanager will avoid this issue by ensuring that all ports are updated in order, no matter how deep in the dependency tree. FWIW, my usage of portmanager is portmanager -u -p -l -y. robert. I tried manually installing those 3 ports; each said it was already installed, so I did a make uninstall then make install for each one, and ran portmanager again. It continued to run just fine, upgrading more ports, then hit the same sort of loop with another set of ports. I upgraded those manually and tried again; each time I installed some ports manually, portmanager would get stuck repeating one or more ports. Background: I had just done a full install from the freebsd CDs, including every standard package except the source code. I then ran portsnap, then installed both portupgrade and portmanager, but after a bit of reading decided to use portmanager. Portmanager listed several dozen installed ports with updates available. When I ran it, I encountered the above issues. An excerpt from the most recent (odd-looking) log file is below. Notice that it's repeating the same port over and over. PS: I'm fairly new to FreeBSD, so if I'm missing something obvious or asking this question to the wrong place, please let me know. (Though, even if I'm doing something wrong, there seems to be a bug in portmanager, which is clearly not exhibiting the intended behavior.) -- Josh Log file follows: portmanager 0.4.1_9 FreeBSD noc.caprio.corp 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 autoConflicts 0 autoMoved 0 backUp 0 buildDependsAreLeaves 0 forced 0 interactive0 log1 pmMode 0 pristine 0 resume 0 Thu Jun 26 01:04:38 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:23 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:31 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:36 2008 options changed so returningxorg-server-1.4_4,1 /x11-servers/xorg-server to out of date pool Thu Jun 26 01:05:44 2008 xorg-server-1.4_4,1 /x11-servers/xorg-server OLD xorg-server-1.4.2,1 /x11-servers/xorg-server Thu Jun 26 01:05:49 2008 options changed so
Re: .warning directives in Makefile
Mikhail Teterin wrote: If foo chokes on that, you should be contacting foo's maintainer, but that's not me (nor do I maintain imagemagic or ghostscript, BTW). In case of I ask you don't commit things that break something. Thank you. -- Dixi. Sem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portmanager stuck in a loop
On Fri, 27 Jun 2008 10:55:57 -0400 Robert Noland [EMAIL PROTECTED] wrote: On Fri, 2008-06-27 at 10:46 -0400, Josh Hanson wrote: Ok, so I tried running portmanager -u -p -l -y. It built a lot of ports, then got stuck again on xorg-server over and over. The log file looks the same as my first post. Is the options screen being presented repeatedly? If so, the options are corrupt and/or not being stored properly. The dialog box should only be shown once and use the stored options after that. You are running as a user with permission to update /var/db/ports? If he wasn't then, presumably portmanager wouldn't detect a modification of options files. It sounds as if portmanager itself might not be at the root of this and it's just reacting to a problem with the ports, whereby one or more of them is spuriously bringing-up the options screen. I'd go to /var/db/ports and remove any directories that match the problem ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portmanager stuck in a loop
On Fri, 2008-06-27 at 17:21 +0100, RW wrote: On Fri, 27 Jun 2008 10:55:57 -0400 Robert Noland [EMAIL PROTECTED] wrote: On Fri, 2008-06-27 at 10:46 -0400, Josh Hanson wrote: Ok, so I tried running portmanager -u -p -l -y. It built a lot of ports, then got stuck again on xorg-server over and over. The log file looks the same as my first post. Is the options screen being presented repeatedly? If so, the options are corrupt and/or not being stored properly. The dialog box should only be shown once and use the stored options after that. You are running as a user with permission to update /var/db/ports? If he wasn't then, presumably portmanager wouldn't detect a modification of options files. It sounds as if portmanager itself might not be at the root of this and it's just reacting to a problem with the ports, whereby one or more of them is spuriously bringing-up the options screen. Yeah, we have eliminated that as an issue. I've suggested a portmanager -u -f -l to get everything in sync. robert. I'd go to /var/db/ports and remove any directories that match the problem ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] -- Robert Noland [EMAIL PROTECTED] 2Hip Networks ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cfengine port update?
So I pulled a fresh copy of the portsnap for cfengine port -- we are *STILL* on 2.2.3? How many years does it take to get a port updated? On May 9, 2008, at 12:19 AM, Boris Samorodov wrote: If there's something wrong with them, someone needs to specify what is wrong. Seems that you shouldn't delete man pages from the Makefile. They were removed from the distribution, therefore they weren't available to install. And I just went through the SVN, and confirmed that the current makefile for the product installs only a single man page. Which is exactly what the port patches I sent you reflect. If you are saying that you'd like me to override the package maintainer and force the installation of man pages which are not installed by default, then you need to state that clearly. (although I disagree in principle with changing the product as delivered by the maintainer without putting those changes into OPTIONS) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: nagios-3.0.2_1
Hello Jarrod, When I read the long description from freebsd.org it said Nagios 3.0.2_1 was here Port description for net-mgmt/nagios-devel but when I went there on my freebsd 7.0 and installed it, I ended up with Nagios 3.0b5 which is not what I really wanted, because things are different. I was hoping you could guide me to the right place to get to 3.0.2_1 or even 3.0.1 would be OK too. Best Regards, Frank ___ 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: nagios-3.0.2_1
On Fri, Jun 27, 2008 at 05:03:38PM -0400, Frank Tavenner wrote: Hello Jarrod, When I read the long description from freebsd.org it said Nagios 3.0.2_1 was here Port description for net-mgmt/nagios-devel but when I went there on my freebsd 7.0 and installed it, I ended up with Nagios 3.0b5 which is not what I really wanted, because things are different. 3.0.2_1 is the version that is currently in the ports tree. 3.0b5 is the version that shipped with FreeBSD 7.0. I was hoping you could guide me to the right place to get to 3.0.2_1 or even 3.0.1 would be OK too. You'll want to update the ports tree using either csup or portsnap, both of which are provided in the base system. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/portsnap.html -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
have: /gettext/ want: /gettext8/ /gettext10/ etc
Just wondering if the change suggested in the Subject line of this message can result in the following scenario of something like it: installed gettext10 installed gettext8 if gettext bumps from so.8 to so.10, both installed and any port which relies upon them uses the lesser until it is bumped non-gettext, upon which time it uses the more recent one. a path? variable? make.conf? Anything to avoid weeks of rebuild. then when nothing depends on gettext8 it can be deinstalled. ... Jeff (not subscribed) .. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
