Re: rar library dependency error
At Wed, 16 Jul 2014 14:46:50 +0200, Carlos Jacobo Puga Medina wrote: /usr/ports/archivers/rar/work/stage//usr/local/lib/default.sfx - shared library libstdc++.so.6 not found Can it be safely ignored? Mostly, yes. As it is a BLOB to create self-extraction rar archives (SFX) which extract themselves on FreeBSD 8.x, you wouldn't need to run this binary when creating ones. On the other hand, you should have compat8x and compat9x installed on FreeBSD = 10, to extract these SFX. Or you can extract SFX without runnnig them - just use rar or unrar. (or 7z.) I think people have nearly zero chance to create SFX archive which runs only on FreeBSD = 8 during their lifetime. -- kuro ___ 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: Why does Samba requires 777 permissions on /tmp
At Sat, 18 May 2013 18:34:47 -0500, sindrome wrote: /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp in PATH, mode 040777 At Sun, 19 May 2013 23:31:21 -0500, sindrome wrote: /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: Insecure world writable dir /tmp/. in PATH, mode 041777 At Sun, 19 May 2013 21:30:03 +0200, Simon Wright wrote: /usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:288: warning: Insecure world writable dir /tmp/ in PATH, mode 041777 /tmp /tmp/. /tmp/ Interesting three different messages. It looks like three different entities adds their own value to your PATH. What you guys should do first is to find who sets stupid PATH for you. I don't suppose portupgrade does. ___ 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: optionsng not saving options on some ports
Hi Kevin, Please refer to this thread: http://docs.FreeBSD.org/cgi/mid.cgi?1505116.DpgL6T9iEl to summarize, - participants: avilla, bapt and others - a problem, persistent for a long time, is confirmed. - resolution looks complicated and need careful inspection and time. - then three weeks passed. I think what it needs is swarm of band-aid, such as adding dedicated OPTIONSFILE to each affected ports. This is really a mess, but it would work as being advertised immediately. I'd prefer working code to yet-to-be-written-proper-fix. Year it's true that this is not an urgent problem at all because we are living with it for a long time. Just we were unaware of it and bapt has visualized this hidden disease for us. pop! -- kuro ___ 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: [RFC] lang/pypy
Hi David, At Sun, 10 Mar 2013 21:18:12 +0300, David Naylor wrote: however my translation processes under -DPYPY_IGNORE_MEMORY take 2GB for normal binary and 2.5GB for sandboxed one so they aggregate 4.5GB to run parallel. This is good news. Could you please detail how you measured peak memory? I might need to retest the port. I heuristically measured them with top(1) RESources, amount of ZFS ARC and swap increased. Oh and free memory after one of translation process finised. I'm afraid I couldn't provide reproducible method for environments for others. I'll disable the test for now and revise my estimation. Thanks for reporting back. I wonder where so much difference of memory usage between yours and mine comes from. 5.5GB vs 2.5GB on the same platform (64bit/pypy) is not so negligible. -- Kuro poyop...@puripuri.plala.or.jp PS. like this, please. thanks for the offer. ___ 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: [RFC] lang/pypy
Hi, good work, David. It compiles, packages and works flawlessly here for replacement of 1.9 so far for a week. On my compile box, amd64/Athlon64 5050e 2.6GHz 2 core/8GB, memory requirement for translation processes is far less than warning shown. It prevents build with | warn: this system has insufficient memory, expected at least 9227MiB RAM however my translation processes under -DPYPY_IGNORE_MEMORY take 2GB for normal binary and 2.5GB for sandboxed one so they aggregate 4.5GB to run parallel. This is far less than expected, no page thrashing, no hang, no stuttering. It does not matter being with pypy1.9 or pypy2.0 (yes, I built twice for 2.0 self hosting. Not tried with cPython.) So I think this warning is a bit excessive that makes everyone just put PYPY_IGNORE_MEMORY=1 in their make.conf. Just in my case. -- kuro ___ 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: portupgrade/portversion and detecting lower versions
portupgrade is working correctly through /usr/ports/MOVED, entries of 2012-12-12 are written to do what you see. Also UPDATING entry is available for this renaming. If you have comments on this movement, Martin matuska m...@freebsd.org is the very person who made this change. ___ 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: mail/mimedefang still using set_rcvar (was: Re: sysutils/smartmontools still using set_rcvar)
Hi Doug, Do you interested in mail/mimedefang? It also has set_rcvar in its rc.d script. -- kuro ___ 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: mail/mimedefang still using set_rcvar
At Tue, 14 Feb 2012 23:09:50 -0800, Doug Barton wrote: On 02/14/2012 22:52, poyop...@puripuri.plala.or.jp wrote: Hi Doug, Do you interested in mail/mimedefang? It also has set_rcvar in its rc.d script. Fixed, thanks. Great, thanks! -- kuro ___ 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: 10-CURRENT ports/devel/gvfs does not compile
At Mon, 14 Nov 2011 14:59:21 +0100, Matthias Apitz wrote: caracas# make ... CC gvfsd_archive-daemon-main.o CC gvfsd_archive-daemon-main-generic.o CCLD gvfsd-archive /usr/bin/ld: warning: libcrypto.so.6, needed by /usr/lib/libarchive.so, may conflict with libcrypto.so.7 /usr/lib/libarchive.so: undefined reference to `lzma_code@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_stream_decoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_lzma_preset@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_alone_encoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_end@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_alone_decoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_memusage@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_stream_encoder@XZ_5.0' gmake[4]: *** [gvfsd-archive] Error 1 gmake[4]: Leaving directory `/usr/ports/devel/gvfs/work/gvfs-1.6.6/daemon' It is likely with you to have xz from ports or something other than base. Remove it and everything should go fine. -- kuro ___ 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
