Re: i keep *trying* to move from portupgrade to portmaster
Am 13.08.2010, 17:47 Uhr, schrieb Mike Jakubik: On 8/12/2010 5:32 PM, Doug Barton wrote: On Thu, 12 Aug 2010, Mike Jakubik wrote: I tried portmaster for myself and im wondering how to get the functionality of "portupgrade lib\*", meaning update all libraries that need updating. With "portmaster lib\*" it tries to update and rebuild all libraries, how can i tell portmaster to only update what needs updating? I can't find such an option in the man page, there is an option to always rebuild but no option to never rebuild. There is also -i, but it's a pain in the ass to manually select y/n for all libraries. Am i not seeing something in the man page? No, you're not missing anything. The default behavior for portmaster is to upgrade everything you specify on the command line. Something like this would probably work: portmaster `pkg_version -Ivl\< | grep ^lib | cut -f1 -d\<` hth, Doug Thanks for the info. Do you think this may be a usefull feature for other users coming from portupgrade though? If there is an option to always rebuild, one would think there would be an opposite option too. To be a bit impolite and blunt, if people acted a bit less helplessly -- meaning that the solution is so relatively simple as a one-liner in a reasonable shell -- there probably isn't a need to change portmaster code. This can instead go into the portmaster manual as a usage example. And telling what this is up to doing without committing to it is as simple as prefixing "echo" to the whole line. -- Matthias Andree ___ 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: textproc/soprano linking problem
On 16/08/2010 11:49, Dominic Fandrey wrote: > I wanted to switch to the new k3b-kde4. I ran through a couple > of problems, most of them ports not accepting spaces in CC, but > there's a soprano issue I don't get through to: > > Linking CXX executable sopranod > cd > /usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/server > && /usr/local/bin/cmake -E cmake_link_script > CMakeFiles/sopranod.dir/link.txt --verbose=1 > /usr/bin/c++ -O2 -pipe -march=nocona -fno-strict-aliasing > -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align > -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-check-new > -fno-common -fvisibility=hidden -fvisibility-inlines-hidden > CMakeFiles/sopranod.dir/sopranod.cpp.o > CMakeFiles/sopranod.dir/sopranodcore.cpp.o > CMakeFiles/sopranod.dir/lockfile.cpp.o -o sopranod > ../soprano/libsoprano.so.4.3.0 libsopranoserver.so.1.2.0 > ../index/libsopranoindex.so.1.1.0 /usr/local/lib/qt4/libQtNetwork.so > /usr/local/lib/qt4/libQtDBus.so ../soprano/libsoprano.so.4.3.0 > /usr/local/lib/qt4/libQtCore.so -pthread /usr/local/lib/libclucene.so > -Wl,-rpath,/usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/soprano:/usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/server:/usr/obj/mobileKamikaze.norad/amd64/usr/ports/textproc/soprano/work/soprano-2.4.4/index:/usr/local/lib/qt4:/usr/local/lib: > > CMakeFiles/sopranod.dir/sopranod.cpp.o(.text+0x33): In function `usage()': > : undefined reference to `Soprano::versionString()' > CMakeFiles/sopranod.dir/sopranodcore.cpp.o(.gnu.linkonce.r._ZTV12SopranodCore+0xb0): > undefined reference to `Soprano::Error::ErrorCache::lastError() const' > libsopranoserver.so.1.2.0: undefined reference to > `Soprano::Error::ErrorCache::ErrorCache()' > ... By removing the dependency in kdelibs4 I got a slightly more useful error message from x11/kdelibs4 that sheds some light: -- Performing Test _OFFT_IS_64BIT -- Performing Test _OFFT_IS_64BIT - Success -- Performing Test HAVE_FPIE_SUPPORT -- Performing Test HAVE_FPIE_SUPPORT - Success -- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL -- Performing Test __KDE_HAVE_W_OVERLOADED_VIRTUAL - Success -- Performing Test __KDE_HAVE_GCC_VISIBILITY -- Performing Test __KDE_HAVE_GCC_VISIBILITY - Success CMake Error at cmake/modules/FindKDE4Internal.cmake:1170 (message): Qt compiled without support for -fvisibility=hidden. This will break plugins and linking of some applications. Please fix your Qt installation. Call Stack (most recent call first): CMakeLists.txt:36 (find_package) -- Configuring incomplete, errors occurred! *** Error code 1 Stop in /usr/ports/x11/kdelibs4. shell returned 1 After some searching I found that I am not the first person to have this problem and the solution was to rebuild qt and everything related without using ccache. Unfortunately this solution did not work for me. It might be that it's a build dependency and I missed it. Unfortunately the error message holds no information whatsoever about which component is affected. I'm at a dead end and need some hints where to go next. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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's annoying when something other than rsyncd listens on tco/873
--On Monday, August 16, 2010 20:20:31 -0400 jhell wrote: On 08/16/2010 01:49, David Wolfskill wrote: My build machine is noisy & generates heat, so I leave it powered off when it's not actively in use. As a consequence, it gets rebooted rather often. It is configured to run rsyncd(8) so I can update my laptop's local mirror of the FreeBSD SVN repository. A couple of mornings ago, I woke up, ready to start my daily builds (on the laptop & build machine), but noticed that the SVN mirror on the laptop hadn't been updated. Eventually, I discovered that the reason was that amd(8) [on the build machine] was listening on 873/tcp, which is the port for rsync. I restarted amd(8); it happened to get other ports, so I restarted rsyncd(8), and was able to perfomr the mirroring. Mind, that was the first time since around February that I've had a problem with using rsyncd(8) in this fashion. Since then, I've become a bit ... sensitized to the issue, so a quick "sockstat -4l" immediately after powering it on helps avoid ths sort of thing. So this evening, such a check showed that ypbind(8) was listening on 873/tcp. The most straightforward way to make this a non-issue (it seems to me) would be to start rsyncd(8) before other services that grab arbitrary ports; however, the start-up script for rsyncd s[ecifies: # PROVIDE: rsyncd # REQUIRE: LOGIN # BEFORE: securelevel # KEYWORD: shutdown and both amd & ypbind specify # BEFORE: DAEMON so that approach doesn't seem to quite work out. (I note that I recently stopped tracking stable/7 on the build machine, so I now boot into stable/8; perhaps something changed between stable/7 and stable/8 that inicreases the probability of such an unfortunate collsion.) Also, rsyncd(8) doesn't appear to consider this a condition worthy of note -- at least, I wasn't able to find any whines, and the daemon was still running. Anyone have suggestions for avoiding a recurrence (vs. working around the coiindition should one occur)? I have been at this point once or twice and it always boiled down to rpcbind in my situation on a few NIS+ boxen. The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents so adding the BEFORE to the rsync start script would not help or didn't at that time. One thing that comes to mind is that script that Jeremy? posted for waiting for the network a certain period of time before initializing services. Maybe this could also play a role in a situation to have a services script that could be controlled by rc.conf(5) to wait for a service to come up before continuing its own operation. And of course it should continue no matter what in either case but would allow you to introduce possibly needed delays in the rc. Here is a slightly modified version of Jeremy's script that I use. http://bit.ly/cpbrlm The IP_PORTRANGE value, which is used by ypbind and amd to select a port, is adjustable according to your needs. man (4) ip "IP_PORTRANGE_DEFAULT use the default range of values, normally IPPORT_HIFIRSTAUTO through IPPORT_HILASTAUTO. This is adjustable through the sysctl setting: net.inet.ip.portrange.first and net.inet.ip.portrange.last." Note that the man page is incorrect for FreeBSD 8. # uname -r 8.1-PRERELEASE # sysctl net | grep portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 1 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 So set net.inet.ip.portrange.lowlast to 874. That should keep rsyncd's port from being grabbed, unless I'm misunderstanding this, in which case Matthew or someone else will correct me. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: shells/bash and the libiconv dependency mess
,--- You/Jeremy (Mon, 16 Aug 2010 23:01:14 -0700) * | On 2010/05/11, ehaupt committed the following patch: | | http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/files/patch-Makefile.in | | And bumped PORTREVISION (from 0 to 1) in the Makefile. This | unconditionally made bash require libiconv, and the only justification | is "fix statically linked version". | | Those of us who use WITHOUT_NLS or who do not have libiconv already on | their systems (from another port) immediately notice the problem (bash | will no longer build): | | http://www.freebsd.org/cgi/query-pr.cgi?pr=147747 | http://www.freebsd.org/cgi/query-pr.cgi?pr=148329 | http://www.freebsd.org/cgi/query-pr.cgi?pr=149218 | | Three months goes by and finally something is committed to fix the | problem on 2010/08/06. Except the fix doesn't make any sense; all it | does is make libiconv a mandatory dependency (USE_ICONV): | | http://www.freebsd.org/cgi/cvsweb.cgi/ports/shells/bash/Makefile#rev1.123 | | This, of course, means that WITHOUT_NLS is broken and doesn't work as | it's supposed to, since libiconv is now a mandatory requirement (it | doesn't need to be): Mine is 147747, and I say (in http://www.freebsd.org/cgi/query-pr.cgi?pr=147747): >>> It would be ideal to be able to exclude libiconv from the build and >>> dependency, subject to a certain make variable setting, but this seems >>> to be difficult to do without the port surgery available only to the >>> port maintainer, so at least let's register the libiconv dependency >>> correctly, so that the installation from a package results in a >>> workable `bash'. So, I agree with you. What was suggested in my PR was the minimum to make the dependency list honest -- not to depend on libiconv would be much better. | # make WITHOUT_NLS=true all-depends-list | /usr/ports/devel/bison | /usr/ports/converters/libiconv | /usr/ports/devel/m4 | /usr/ports/devel/libtool22 | | Why was this done the way it was? patch-Makefile.in should be removed | and instead replaced with a REINPLACE_CMD that handles the conditionals | (WITH_STATIC_BASIC, WITHOUT_NLS, etc.) in a more clean manner. | | And where are the details of the supposed "statically linked version" | problem? | | Sorry if I sound angry, but this whole situation is a mess, and | shells/bash is a very important port. Agree here, too -- can't live without it. | If someone wants me to put my money where my mouth is and go + clean | it up I'll be happy to. Testing all the different quirk | combinations really isn't that complex. I *definitely* want it -- your anger is justified. Bash is an essential component of FreeBSD and should be given all the care and attention possible. I could help with testing/maintaining the bash port, too (not until the end of August, though). But I am of the opinion, OTOH, that's it's a port maintainer responsibility to drive the effort. Plainly put: if the current maintainer doesn't have time or desire to maintain this critical port properly, will you (the maintainer) kindly release your maintainership to be passed over to somebody who will? Making mistakes is completely OK, in my mind; letting the simple-to-fix issue to be marinated for two months, since the first report: -- 147747: Open: Wed, 09 Jun 2010 23:34:12 -0400 Closed: Fri Aug 06 10:49:57 CEST 2010 -- is not OK (IMHO). Thank you, Jeremy! -- Alex -- alex-goncha...@comcast.net -- ___ 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: i keep *trying* to move from portupgrade to portmaster
On 8/16/2010 4:29 PM, Doug Barton wrote: On 8/16/2010 6:49 AM, Mike Jakubik wrote: Im not saying because its in portupgrade it needs to be in portmaster. I'm simply saying that it's a useful feature for me, and possibly others. I guess my question is what is the use case that portmaster doesn't already cover? You can specify a list of ports on the command line, or you can use the -i option with a wider glob, or even -a. There is also the +IGNOREME file option; all of these are described in the man page. I guess my approach to updates with portupgrade does not apply well to portmaster since portupgrade does not update dependencies by default. On a sliglty out of date box i would start updating dependencies such as libraries (portupgrade lib\*) before i would do the actual programs, and this would only update what needed an update instead of rebuilding everything. I just never felt comfortable for some reason using the -R option in portupgrade. You are probably right that this is not needed, i'll just have to change my habbits. Sorry for the noise, and thanks for the work on this port. I think it's pretty obvious what my preference is, but if you can demonstrate the need I'm willing to consider it. 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: i keep *trying* to move from portupgrade to portmaster
On 8/17/2010 4:07 AM, Matthias Andree wrote: To be a bit impolite and blunt, if people acted a bit less helplessly -- meaning that the solution is so relatively simple as a one-liner in a reasonable shell -- there probably isn't a need to change portmaster code. This can instead go into the portmaster manual as a usage example. If no one asked or complained there would be no progress. I think you misnterperted my intentions, which were to make the tool easier and more functional for everyone. A lot of complex tasks can be accomplished with a 1 line amalgamation of grep, awk, perl, etc. This doesn't mean we shouldn't build tools that simplify those tasks, hence the portmaster tool itself. And telling what this is up to doing without committing to it is as simple as prefixing "echo" to the whole line. You assume my level of commitment because i didn't produce code before asking the author for his opinion? Ok.. ___ 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 always re-installs some ports
On Mon 16 Aug 2010 at 20:40:44 PDT b. f. wrote: A while back I aborted a recursive update (bad idea, I know now) and must have messed up something in whatever info portmaster uses to decide whether to re-install a port. Now, whenever I use portmaster -a, it re-installs py26-imaging, py26-reportlab and py26-xml. From portmaster(8): "/var/db/pkg/*/PM_UPGRADE_DONE_FLAG Indicates to a subsequent -a, -f, or -r run which includes the -R option that a port has already been rebuilt, so it can be safely ignored if it is up to date." Are there any of the above files left in your PKG_DBDIR (/var/db/pkg, by default)? If so, delete them, and try again. There were many of these, but not in the directories corresponding to the three python ports. (But perhaps in one or more of the ports that depend on them?) Anyway, I deleted all of them. It didn't fix the problem. py-reportlab and py-xml are still unnecessarily reinstalled. py-imaging was recently updated, but when I ran portmaster yesterday it complained that a previous version was still installed. Hmm, portmaster usually uninstalls the old version automatically. So I tried deinstalling it manually and got an error message about not being able to completely remove the PIL directory from Python's site-packages. Found a .so file in there and deleted it and the directory. Then installed the new version of py-imaging from the ports tree. Today midori needed an update, so portmaster -a found some work to do. py-imaging is no longer re-installed! Tried manually de-installing py-reportlab and got a similar error message from pkg_delete about not being able to delete site-packages/reportlab. This looks promising. I'll clean this stuff out manually and then reinstall, as I did with py-imaging, and check py-xml to see if it has a similar problem. ___ 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 always re-installs some ports
On Tue 17 Aug 2010 at 14:22:21 PDT Charlie Kester wrote: Tried manually de-installing py-reportlab and got a similar error message from pkg_delete about not being able to delete site-packages/reportlab. This looks promising. I'll clean this stuff out manually and then reinstall, as I did with py-imaging, and check py-xml to see if it has a similar problem. Sorry to reply to my own post, but I want to be sure to document as much as I can in this thread, in case someone else ever encounters a similar problem. py-xml also failed to deinstall cleanly. So there's the common factor. After cleaning up and reinstalling py-reportlab and py-xml, I ran portmaster --check-depends and noticed that it updated the REQUIRED_BY for each of them. (I'd noticed the same thing yesterday for py-imaging after I had updated to the new version.) ___ 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"
google-earth
I installed Google-Earth 5.1.3535.3218 (the newer one crashed before start). I had problem with the old one too on FreeBSD 8.0, KDE 4.4.5: If I try to closed a picture or just click somewhere when is a picture opened the program crashed::: /usr/local/bin/googleearth %f undefined:4: ReferenceError: Can't find variable: ge_bridge undefined:4: ReferenceError: Can't find variable: ge_bridge Google Earth has caught signal 11. We apologize for the inconvenience, but Google Earth has crashed. This is a bug in the program, and should never happen under normal circumstances. A bug report and debugging data have been written to this text file: Mitja http://starikarp.redbubble.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"
databases/postgresql-odbc: MAINTAINER no more
$ < /usr/ports/databases/postgresql-odbc/Makefile grep MAINTAIN => MAINTAINER=alex-goncha...@comcast.net Please remove -- I am releasing my maintainership. -- Alex -- alex-goncha...@comcast.net -- ___ 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: databases/postgresql-odbc: MAINTAINER no more
On Tue, Aug 17, 2010 at 07:04:13PM -0400, Alex Goncharov wrote: > Please remove -- I am releasing my maintainership. done ___ 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: Bacula 5.0.3
On Sat, Aug 14, 2010 at 02:47:59PM -0400, Dan Langille wrote: > On 8/8/2010 10:59 PM, Dan Langille wrote: > > Allan: > > > > For Bacula 5.0.2 you submitted patches which included: > > > > patch-src-cats-Makefile.in > > patch-src-findlib-Makefile.in > > patch-src-lib-Makefile.in > > > > In particular, I'm interested in things like this (hugely condensed for > > clarity): > > > > - -release $(LIBBAC_LT_CURRENT).$(LIBBAC_LT_REVISION).$(LIBBAC_LT_AGE) > > + -version-info $(LIBBAC_LT_CURRENT):$(LIBBAC_LT_REVISION):$(LIBBAC_LT_A > > > > Of note, 5.0.3 uses this: > > > > -release $(LIBBAC_LT_RELEASE) > > > > I am not sure how best to patch for 5.0.3. > > > > I first tried: version-info $(LIBBAC_LT_RELEASE) > > > > But encountered this error: > > > > Making libbac.la ... > > /var/ports/usr/home/dan/src/sysutils/bacula-server/work/bacula-5.0.3/libtool > > --silent --tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -o > > libbac.la attr.lo base64.lo berrno.lo bsys.lo bget_msg.lo bnet.lo > > bnet_server.lo runscript.lo bsock.lo bpipe.lo bsnprintf.lo btime.lo > > cram-md5.lo crc32.lo crypto.lo daemon.lo edit.lo fnmatch.lo > > guid_to_name.lo hmac.lo jcr.lo lex.lo alist.lo dlist.lo md5.lo > > message.lo mem_pool.lo openssl.lo plugins.lo priv.lo queue.lo bregex.lo > > rwlock.lo scan.lo serial.lo sha1.lo signal.lo smartall.lo rblist.lo > > tls.lo tree.lo util.lo var.lo watchdog.lo workq.lo btimers.lo > > address_conf.lo breg.lo htable.lo lockmgr.lo -export-dynamic -rpath > > /usr/local/lib -version-info 5.0.3 -lwrap -lz > > libtool: link: CURRENT `5.0.3' must be a nonnegative integer > > libtool: link: `5.0.3' is not valid version information > > *** Error code 1 > > > > > > I don't know enough about your patch to proceed with confidence. > > I tried this solution: > > cd files > rm patch-src-lib-Makefile.in patch-src-findlib-Makefile.in > patch-src-cats-Makefile.in > > Then I removed all lib/* entries from pkg-plist and pkg-plist.client > > A sample test job ran just fine. > > However, this seems to undo the advances made in 5.0.2 regarding > libaries. In 5.0.3 the libraries are named: > > libbac-5.0.3.so > libbacpy-5.0.3.so > > etc. > > Whereas, the 5.0.2 port assumes they are named like libbacpy-5.so > > So far, I see no reason not to proceed with my attached diff. But I > welcome different opinions, if they have suggestions for patches. Unfortunately I don't have the time right now to handle this, but I have forwarded this mail to Olli Hauer (ohauer@) who will hopefully have the time to take care of it. He has graciously stepped in to pick up the Bacula related PRs on my plate. -- WXS ___ 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"
google-earth
ajtiM writes: > I installed Google-Earth 5.1.3535.3218 (the newer one crashed > before start). I had problem with the old one too on FreeBSD > 8.0, KDE 4.4.5: While I haven't exercised it extensicely, this version works for me under: FreeBSD 9.0-CURRENT #0: Fri Apr 23 11:34:17 EDT 2010 amd64 and: linux_base-f10-10_2 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: google-earth
On Tuesday 17 August 2010 18:27:58 Robert Huff wrote: > ajtiM writes: > > I installed Google-Earth 5.1.3535.3218 (the newer one crashed > > before start). I had problem with the old one too on FreeBSD > > > 8.0, KDE 4.4.5: > While I haven't exercised it extensicely, this version works > for me under: > > FreeBSD 9.0-CURRENT #0: Fri Apr 23 11:34:17 EDT 2010 amd64 > > and: > > linux_base-f10-10_2 > > > Robert Huff and what is unusual for me: I deinstall GE 5.2xxx, make clean, clean distfiles...and installed 5.1 but if I run locace google-earth I got also: /var/db/pkg/google-earth-5.2.1.1329 /var/db/pkg/google-earth-5.2.1.1329/+COMMENT /var/db/pkg/google-earth-5.2.1.1329/+CONTENTS /var/db/pkg/google-earth-5.2.1.1329/+DESC /var/db/pkg/google-earth-5.2.1.1329/+MTREE_DIRS but version 5.2.xxx in not in the directory.. At this momemnt I did: cd /usr/ports/astro/google-earth make deinstall ===> Deinstalling for astro/google-earth ===> Deinstalling google-earth-5.1.3535.3218,1 make clean===> Cleaning for google-earth-5.1.3535.3218,1 and: portmaster --clean-distfiles ===>>> Gathering distinfo list for installed ports ===>>> Checking for stale distfiles ===>>> Delete stale file: google-earth/5.1.3535.3218/GoogleEarthLinux.bin? y/n [y] y ...and now I try again locate google-earth and I got: /usr/ports/distfiles/google-earth /usr/ports/distfiles/google-earth/5.2.1.1329 /usr/ports/distfiles/google-earth/5.2.1.1329/GoogleEarthLinux.bin /var/db/pkg/google-earth-5.2.1.1329 /var/db/pkg/google-earth-5.2.1.1329/+COMMENT /var/db/pkg/google-earth-5.2.1.1329/+CONTENTS /var/db/pkg/google-earth-5.2.1.1329/+DESC /var/db/pkg/google-earth-5.2.1.1329/+MTREE_DIRS /var/db/ports/google-earth /var/db/ports/google-earth/distfiles and also that is in /usr/local/share/google-earth/shaders/ (many files...but there are nothing in distfiles, no in /var/db/pkg, no in /usr/local/share/google-earth (directory doesn't exist). Thanks. Mitja http://starikarp.redbubble.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"
