Re: fresh install of kde4 fails - japanese/kiten
On Wed, Aug 29, 2012 at 5:21 AM, Jim Pazarena fpo...@paz.bz wrote: Alberto Villa wrote, On 2012-08-28 3:31 AM: USE_KDE4= kdehier kdelibs kdeprefix automoc4 KDE4_BUILDENV= yes USE_QT_VER= 4 QT_COMPONENTS= corelib moc_build qmake_build rcc_build uic_build USE_BZIP2= yes MAKE_JOBS_SAFE= yes Your ports tree is out of date, in an inconsistent way (only part of it) I would add. Just update it and it will work. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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
PR 171155 (was: Re: PKG_NG: pkg deinstall fails with argument list too long)
I have created PR ports/171155 to report the issue, that ports with long PLISTs cannot be deinstalled with PKGNG: http://www.freebsd.org/cgi/query-pr.cgi?pr=171155 Regards, STefan ___ 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: PR 171155
On 8/29/2012 9:39 AM, Stefan Esser wrote: I have created PR ports/171155 to report the issue, that ports with long PLISTs cannot be deinstalled with PKGNG: http://www.freebsd.org/cgi/query-pr.cgi?pr=171155 Regards, STefan Already fixed in the git repository (commit 34c1b4f8b21376dfd270779d118cde4a1d0a62e9) :) ___ 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
ports/164072 : [NEW PORT] databases/percona-{server,client} status
Hello. Could someone comment on status of ports/164072? Have been percona ports ever committed to ports tree? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ 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: sysutils/conky Configure Options in Makefile
On 08/28/12 21:41, Jamie Paul Griffin wrote: I have installed conky for use with my wm which is Spectrwm. However, looking in the conky Makefile one of the configure options has been disabled, tcp monitoring (--disable-portmon), which is a feature i'd quite like to have available. Is there a reason the maintainer has disabled this option, perhaps due to security or incompatibility, etc., that anyone knows of? It appears to be disabled in the port Makefile because Conky's configure script says it's not supported on FreeBSD. cd /usr/ports/*/conky make clean patch vi Makefile - remove the --disable-portmon vi work/conky*/configure - change xLinux to xFreeBSD at line 14043 make Dunno if it actually works, but it does build, albeit with a warning for me: cc -DHAVE_CONFIG_H -I. -DSYSTEM_CONFIG_FILE=\/usr/local/etc/conky/conky.conf\ -DPACKAGE_LIBDIR=\/usr/local/lib/conky\ -I/usr/local/include -I/usr/local/include -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/glib-2.0 -D_REENTRANT -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2-I/usr/local/include/lua51 -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include/freetype2 -I/usr/local/include/glib-2.0 -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -Wall -W -O2 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -MT conky-llua.o -MD -MP -MF .deps/conky-llua.Tpo -c -o conky-llua.o `test -f 'llua.c' || echo './'`llua.c llua.c:43:1: warning: MIN redefined In file included from /usr/local/include/glib-2.0/glibconfig.h:9, from /usr/local/include/glib-2.0/glib/gtypes.h:34, from /usr/local/include/glib-2.0/glib/galloca.h:34, from /usr/local/include/glib-2.0/glib.h:32, from libtcp-portmon.h:38, from tcp-portmon.h:25, from conky.h:112, from llua.c:25: /usr/local/include/glib-2.0/glib/gmacros.h:201:1: warning: this is the location of the previous definition The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.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: ports/164072 : [NEW PORT] databases/percona-{server,client} status
Hi! Could someone comment on status of ports/164072? Have been percona ports ever committed to ports tree? Other ones: percona-toolkit I would love to see their database in the ports tree! -- p...@opsec.eu+49 171 3101372 8 years to go ! ___ 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: sysutils/conky Configure Options in Makefile
[ Matt Burke wrote on Wed 29.Aug'12 at 9:01:59 +0100 ] On 08/28/12 21:41, Jamie Paul Griffin wrote: I have installed conky for use with my wm which is Spectrwm. However, looking in the conky Makefile one of the configure options has been disabled, tcp monitoring (--disable-portmon), which is a feature i'd quite like to have available. Is there a reason the maintainer has disabled this option, perhaps due to security or incompatibility, etc., that anyone knows of? It appears to be disabled in the port Makefile because Conky's configure script says it's not supported on FreeBSD. cd /usr/ports/*/conky make clean patch vi Makefile - remove the --disable-portmon vi work/conky*/configure - change xLinux to xFreeBSD at line 14043 make Dunno if it actually works, but it does build, albeit with a warning for me: Cheers Matt, i'll leave it then. It's not worth the hassle by the sounds of it. Thanks for the info though. jamie ___ 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: fresh install of kde4 fails - japanese/kiten
Alberto Villa wrote, On 2012-08-28 11:51 PM: On Wed, Aug 29, 2012 at 5:21 AM, Jim Pazarena fpo...@paz.bz wrote: Alberto Villa wrote, On 2012-08-28 3:31 AM: USE_KDE4= kdehier kdelibs kdeprefix automoc4 KDE4_BUILDENV= yes USE_QT_VER= 4 QT_COMPONENTS= corelib moc_build qmake_build rcc_build uic_build USE_BZIP2= yes MAKE_JOBS_SAFE= yes Your ports tree is out of date, in an inconsistent way (only part of it) I would add. Just update it and it will work. I use: csup -g -L 2 ports-supfile and ports-supfile has all the recommended defaults, including ports-all what am I missing? ___ 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: fresh install of kde4 fails - japanese/kiten
On Wed, Aug 29, 2012 at 5:00 PM, Jim Pazarena fpo...@paz.bz wrote: I use: csup -g -L 2 ports-supfile and ports-supfile has all the recommended defaults, including ports-all what am I missing? I don't know, maybe something went wrong in the past, but for sure that file (at least) is out of date. I suggest checking out a new ports tree with portsnap or Subversion. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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
csup vs portsnap was: fresh install of kde4 fails - japanese/kiten
Alberto Villa wrote, On 2012-08-29 8:17 AM: On Wed, Aug 29, 2012 at 5:00 PM, Jim Pazarena fpo...@paz.bz wrote: I use: csup -g -L 2 ports-supfile and ports-supfile has all the recommended defaults, including ports-all what am I missing? I don't know, maybe something went wrong in the past, but for sure that file (at least) is out of date. I suggest checking out a new ports tree with portsnap or Subversion. A portsnap (which I have NEVER run in my life) fixed this issue. I have always run cvsup and more recently csup. I am concerned, now, because I would have assumed that csup actually DOES update me, where it would seem that it has a failing, at least WRT japanese/kiten Which is the recommended way to stay PORT current? portsnap or csup? I will switch to portsnap, but it is pretty slow compared to csup. Thanks! ___ 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: csup vs portsnap was: fresh install of kde4 fails - japanese/kiten
On Wed, Aug 29, 2012 at 7:27 PM, Jim Pazarena fpo...@paz.bz wrote: Which is the recommended way to stay PORT current? portsnap or csup? I will switch to portsnap, but it is pretty slow compared to csup. csup is just fine, but you probably did something that confused it. If you want your speed back, you can use Subversion: # svn co http://svn.freebsd.org/ports/base $yourportsdir svn:// can be used as well, but http:// is faster for me. Once the checkout is done, you can update with the following command: # make update -C $yourportsdir -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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: upgrading ports with a lot of dependencies
[ Kevin Oberman wrote on Tue 28.Aug'12 at 17:37:17 -0700 ] And, as I mention rather often, pkg-libchk from sysutils/bsdadminscripts can save you from rebuilding a LOT of ports. pkg_libchk -o | grep LIBNAME | cut -d: -f1 | sort | uniq dep-ports (where LIBNAM is the sharable (.so) installed by the port in question) portmaster -D `cat dep-ports` Like the sound of that, will definitely try that out. ___ 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: Regression in PREFIX handling in packages
On Sun, 26 Aug 2012 22:54:35 +0200 Alexander Leidinger alexan...@leidinger.net wrote: Hi, I detected a regression in the handling of the registration of the PREFIX in packages. I'm not sure when it was introduced, surely more than a month ago. The problem: - I have a symlink from /usr/local to another place X. - I share packages between this system A and some jails. - The jails don't have place X and /usr/local is no symlink. - Packages generated on the system A are installed into place X in the jails. So in short: the realpath of PREFIX is recorded in the packages, not the value of PREFIX as before. I had a quick look at bsd.*.mk, but didn't notice something obvious. So in case it is pkg_create which is doing this, I updated from r238438 to r239708. Could it be that my problem comes from r231300 and I was lucky that I didn't create a package on the machine with the symlinked /usr/local and used it on a machine with a normal /usr/local? % ll /usr/local lrwxr-xr-x 1 root wheel25B 2 Mai 2011 /usr/local@ - ../space/system/usr_local http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/create/perform.c?r1=228990r2=231300 What's the problem this patch tries to solve? Shouldn't the plist use the prefix as specified by the env variable instead of the realpath? Bye, Alexander. -- 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 freebsd-ports-unsubscr...@freebsd.org
Re: Regression in PREFIX handling in packages
On 29 August 2012 15:17, Alexander Leidinger alexan...@leidinger.net wrote: Could it be that my problem comes from r231300 and I was lucky that I didn't create a package on the machine with the symlinked /usr/local and used it on a machine with a normal /usr/local? I have not been following this thread, so if you traced the bug to this commit, I'll accept that. http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/create/perform.c?r1=228990r2=231300 What's the problem this patch tries to solve? Shouldn't the plist use the prefix as specified by the env variable instead of the realpath? The specific problem this patch was trying to solve is to allow the use of . or other relative paths in the -p argument to pkg_create. -- Eitan Adler Source Ports committer X11, Bugbusting teams ___ 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: csup vs portsnap was: fresh install of kde4 fails - japanese/kiten
On 29 August 2012 13:27, Jim Pazarena fpo...@paz.bz wrote: I am concerned, now, because I would have assumed that csup actually DOES update me, where it would seem that it has a failing, at least WRT japanese/kiten Which is the recommended way to stay PORT current? portsnap or csup? I will switch to portsnap, but it is pretty slow compared to csup. both usually work. Sometimes some csup mirrors get a bit out of date due to timing or maintenance. -- Eitan Adler ___ 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: portmaster 3.13.13 real endless loop Waiting on fetch checksum..
I think my original reply did not go out on 8/27, so here it is: do...@freebsd.org (Doug Barton) writes: On 08/25/2012 16:58, G. Paul Ziemba wrote: The second scenario exhibits the problem. Here, I delete the distfile and just run portmaster without -F. The fetch completes, but portmaster does not seem to notice. Can you try that second test again, and add -D to the command line? The good news is that I removed the distfile and than ran portmaster -D devel/gsoap, and it worked. The bad news is that I killed it before it installed, went back and deleted the distfile again and deleted devel/gsoap/work and ran just portmaster devel/gsoap, and that also worked. I must have done something in the meantime that caused it to work. I didn't do anything with that specific port, and portmaster lists it as a root port, so I'm not sure what would have made a difference. I was monkeying aroung with libpng and some other ports, but didn't keep an exact record. Argh. One thing I did notice was that in the failed scenario (described in my previous message), the tmp file named /tmp/fooDI-FILESbar was incomplete, but in the run today with -D, the corresponding tmp file was much larger (48851 bytes) and had a lot more ports listed. No idea if that's significant. ~!paul -- G. Paul Ziemba FreeBSD unix: 12:46PM up 2 days, 32 mins, 8 users, load averages: 1.05, 1.26, 1.66 ___ 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: Regression in PREFIX handling in packages
On Wed, 29 Aug 2012 15:28:36 -0400 Eitan Adler ead...@freebsd.org wrote: On 29 August 2012 15:17, Alexander Leidinger alexan...@leidinger.net wrote: Could it be that my problem comes from r231300 and I was lucky that I didn't create a package on the machine with the symlinked /usr/local and used it on a machine with a normal /usr/local? I have not been following this thread, so if you traced the bug to this commit, I'll accept that. It's a guess, I haven't tried to back it out and test again. http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/create/perform.c?r1=228990r2=231300 What's the problem this patch tries to solve? Shouldn't the plist use the prefix as specified by the env variable instead of the realpath? The specific problem this patch was trying to solve is to allow the use of . or other relative paths in the -p argument to pkg_create. Wouldn't it be better to use ---snip--- if (Prefix[0] != '/' realpath(... ---snip--- in this case? Attention: I just guessed what Prefix is and what it should contain by looking at the diff, I didn't had a look at the declaraction and assignments of Prefix. Bye, Alexander. -- 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 freebsd-ports-unsubscr...@freebsd.org
Re: upgrading ports with a lot of dependencies
Am 29.08.2012 02:37, schrieb Kevin Oberman: And, as I mention rather often, pkg-libchk from sysutils/bsdadminscripts can save you from rebuilding a LOT of ports. pkg_libchk -o | grep LIBNAME | cut -d: -f1 | sort | uniq dep-ports (where LIBNAM is the sharable (.so) installed by the port in question) portmaster -D `cat dep-ports` While that will work in the given scenario, I'd personally prefer just pkg_libchk -q -o. There may be a few notorious false positives (mostly packages bypassing the regular ld.so stuff - Mozilla stuff -, or ports dynamically loading facultative UI libraries, such as Opera that can use GTK and Qt, or ports that need compat* stuff for bootstrapping, such as diablo-jdk on newer computers). ___ 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: Regression in PREFIX handling in packages
On Wed, Aug 29, 2012 at 12:48 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Wed, 29 Aug 2012 15:28:36 -0400 Eitan Adler ead...@freebsd.org wrote: On 29 August 2012 15:17, Alexander Leidinger alexan...@leidinger.net wrote: Could it be that my problem comes from r231300 and I was lucky that I didn't create a package on the machine with the symlinked /usr/local and used it on a machine with a normal /usr/local? Symlinking would be a problem if you built it on one machine and installed it on another. ... Wouldn't it be better to use ---snip--- if (Prefix[0] != '/' realpath(... ---snip--- in this case? Attention: I just guessed what Prefix is and what it should contain by looking at the diff, I didn't had a look at the declaraction and assignments of Prefix. That would cause problems in some cases where someone called pkg_create -p /usr/foobar/../local If this commit causes more harm than good, please back it out -- pkg_install is going to die soon anyhow, so I'd rather not fritter away time debating its usefulness if it breaks a valid use case. Thanks, -Garrett ___ 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: Regression in PREFIX handling in packages
On Wed, 29 Aug 2012 21:48:31 +0200 Alexander Leidinger
alexan...@leidinger.net wrote:
On Wed, 29 Aug 2012 15:28:36 -0400 Eitan Adler ead...@freebsd.org
wrote:
On 29 August 2012 15:17, Alexander Leidinger
alexan...@leidinger.net wrote:
Could it be that my problem comes from r231300 and I was lucky
that I didn't create a package on the machine with the
symlinked /usr/local and used it on a machine with a
normal /usr/local?
I have not been following this thread, so if you traced the bug to
this commit, I'll accept that.
It's a guess, I haven't tried to back it out and test again.
http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/create/perform.c?r1=228990r2=231300
What's the problem this patch tries to solve? Shouldn't the plist
use the prefix as specified by the env variable instead of the
realpath?
The specific problem this patch was trying to solve is to allow the
use of . or other relative paths in the -p argument to pkg_create.
Wouldn't it be better to use
---snip---
if (Prefix[0] != '/' realpath(...
---snip---
in this case? Attention: I just guessed what Prefix is and what it
should contain by looking at the diff, I didn't had a look at the
declaraction and assignments of Prefix.
And this one is tested (copypaste, may have lost tabs and add
linebreaks from my mailer):
---snip---
# svn diff
Index: perform.c
===
--- perform.c (revision 239708)
+++ perform.c (working copy)
@@ -215,10 +215,15 @@
/* Prefix should add an @cwd to the packing list */
if (Prefix) {
-char resolved_prefix[PATH_MAX];
-if (realpath(Prefix, resolved_prefix) == NULL)
- err(EXIT_FAILURE, couldn't resolve path for prefix: %s,
Prefix);
- add_plist_top(plist, PLIST_CWD, resolved_prefix);
+ if (Prefix[0] != '/') {
+ char resolved_prefix[PATH_MAX];
+ if (realpath(Prefix, resolved_prefix) == NULL)
+ err(EXIT_FAILURE,
+ couldn't resolve path for prefix: %s,
Prefix);
+ add_plist_top(plist, PLIST_CWD, resolved_prefix);
+ } else {
+ add_plist_top(plist, PLIST_CWD, Prefix);
+ }
}
/* Add the origin if asked, at the top */
---snip---
Bye,
Alexander.
--
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 freebsd-ports-unsubscr...@freebsd.org
Re: Regression in PREFIX handling in packages
On Wed, 29 Aug 2012 12:59:30 -0700 Garrett Cooper yaneg...@gmail.com wrote: On Wed, Aug 29, 2012 at 12:48 PM, Alexander Leidinger alexan...@leidinger.net wrote: On Wed, 29 Aug 2012 15:28:36 -0400 Eitan Adler ead...@freebsd.org wrote: On 29 August 2012 15:17, Alexander Leidinger alexan...@leidinger.net wrote: Could it be that my problem comes from r231300 and I was lucky that I didn't create a package on the machine with the symlinked /usr/local and used it on a machine with a normal /usr/local? Symlinking would be a problem if you built it on one machine and installed it on another. I use this approach since years, and at least with the packages I created on the machine with the symlink I never had problems. This should only cause problems where realpath is used on a dependency during the configuration/build of a port. I don't want to rule out such a case, but I assume it is not a case one can fall into much. Wouldn't it be better to use ---snip--- if (Prefix[0] != '/' realpath(... ---snip--- in this case? Attention: I just guessed what Prefix is and what it should contain by looking at the diff, I didn't had a look at the declaraction and assignments of Prefix. That would cause problems in some cases where someone called pkg_create -p /usr/foobar/../local If this commit causes more harm than good, please back it out -- pkg_install is going to die soon anyhow, so I'd rather not fritter away time debating its usefulness if it breaks a valid use case. See my other mail, the patch there works for me. Only if the Prefix is not an absolute path, the realpath is used. Bye, Alexander. -- 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 freebsd-ports-unsubscr...@freebsd.org
Re: portmaster 3.13.13 real endless loop Waiting on fetch checksum..
On 08/29/2012 09:46 AM, G. Paul Ziemba wrote: I think my original reply did not go out on 8/27, so here it is: I didn't see it, so thanks for the resend. One thing I did notice was that in the failed scenario (described in my previous message), the tmp file named /tmp/fooDI-FILESbar was incomplete, but in the run today with -D, the corresponding tmp file was much larger (48851 bytes) and had a lot more ports listed. No idea if that's significant. Yes, it is, and it confirms what I suspected the problem is. I will need some time to address this, I'll try to get a patch out by the end of this weekend. Doug ___ 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: lang/gcc46 dependency loop on lang/gcc
Me: Life Happened(tm), which means I'll get to this first thing tomorrow, Back on the job. Steps so far: 1) de-installed gcc46 2) removed suspect parts of make.conf 3) installed gcc48 4) de-installed gcc48 5) added back major suspect parts of make.conf, but removed line involving lang/gcc 6) installed gcc46 7) added back line involving lang/gcc 8) built gcc46 9) added back rest of suspect parts 10) built gcc46 11) used portmaster to re-build/re-install gcc46 All steps succeeded. Whatever the breakage is, it has - at least for the moment - gone away. No idea what it was. Thanks for the help. Sorry for the interruption for what appears to be a local error, Robert Huff ___ 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: fresh install of kde4 fails - japanese/kiten
On Wed, Aug 29, 2012 at 8:17 AM, Alberto Villa avi...@freebsd.org wrote: On Wed, Aug 29, 2012 at 5:00 PM, Jim Pazarena fpo...@paz.bz wrote: I use: csup -g -L 2 ports-supfile and ports-supfile has all the recommended defaults, including ports-all what am I missing? I don't know, maybe something went wrong in the past, but for sure that file (at least) is out of date. I suggest checking out a new ports tree with portsnap or Subversion. I strongly recommend using svn so you will have revision numbers. Install devel/subversion rehash rm -rf /usr/ports/* svn co svn://svn0.us-west.freebsd.org/ports/head /usr/ports Once you do this, don't run csup again. If something outside of svn modifies the files, you will need to fix conflicts and that can be a pain. Of course, you can make your own mods, but you will need to resolve conflicts. This is not much of a problem for a small number of files. There are several easy way to maintain you own patched ports and merge them into the main tree. Once you have checked out the ports tree, use 'svn up /usr/ports' to update them to the latest revision or specify a revision to roll back to an older revision. Use the svn web interface to look up revisions at http://svnweb.freebsd.org. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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
Check out my music
http://www.reverbnation.com/hustlemann get a free download for just listening. THANK YOU!!! THANK YOU FOR YOUR TIME... ___ 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: portmaster 3.13.13 real endless loop Waiting on fetch checksum..
do...@freebsd.org (Doug Barton) writes: I will need some time to address this, I'll try to get a patch out by the end of this weekend. Thanks for your efforts Doug. I'm not blocked by this issue but I'll bet your fix will save time for others down the road. ~!paul -- G. Paul Ziemba FreeBSD unix: 10:46PM up 2 days, 10:32, 12 users, load averages: 0.01, 0.02, 0.13 ___ 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
