Re: autoconf update
On 17/09/2010 00:35, Anonymous wrote: Dominic Fandrey kamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. Example is the breakage of databases/postgresql84-server + WITH_ICU. I second the question. Revision bump seem absolutely unnecessary. There was the sweeping commit reason in another thread. But I don't really think it would have been a sweeping commit if it weren't for the version bump. Did you forget that autoconf262 was removed? I don't get it. I've been really dumb a couple of times lately. Maybe that's it. So if you have the patience, explain it like you would to a dumb person. Regards -- 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: autoconf update
On 17/09/2010 06:41, Doug Barton wrote: On 9/16/2010 6:15 PM, Doug Barton wrote: On 9/16/2010 3:35 PM, Anonymous wrote: Dominic Fandreykamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. We shouldn't use our users to beta-test infrastructure changes. Sorry, I'm not feeling well atm and realize that I didn't write what I was thinking here. What I intended to say was that we _don't_ intentionally use the ports system to force our users to beta test changes. I think it goes without saying that we _shouldn't_ do this, although I think that changes like this are a platinum-coated example of why we need to have -stable and -dev branches for ports. I used to disagree with this, because I thought it would create additional work load. I have come to think more favourably of the idea, because you can make more daring commits on a -dev branch and don't have to quick-fix everything that goes wrong. Also the time between a MFC does not have to be very long. A week should be more than enough time to uncover and solve all problems. So the delay to get updates and fixes on the -stable branch is not very long. Regards -- 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: net/asterisk16
After yet more inactivity, I am reassigning asterisk16 to f...@kasimir.com with portmgr hat. Thank you both for your patience. mcl ___ 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
Fwd: Tomcat6 port keeps locking up??
This is a snapshot of the 'top' command that shows Java at 100%. Basically it means that the system is more in this state then functional and I can't understand why! Can anyone help me?? Otherwise I will have to start looking at migrating this service away from BSD and much more costlier option of Nexenta based on OpenSolaris, but hogs RAM as uses ZFS natively meaning min 4GB unlike my FreeBSD build with ZFS and UFS2 using 4GB for that many processes and 7 jails! Thansk, Kaya Original Message Subject:Tomcat6 port keeps locking up?? Date: Thu, 16 Sep 2010 21:38:16 +0300 From: Kaya Saman kayasa...@gmail.com To: Mailing List FreeBSD Ports freebsd-ports@FreeBSD.org Hi, I'm running Tomcat6 in a jail which I'm using to host the Xwiki application. This is the version of Tomcat I'm running: tomcat-6.0.29 Open-source Java web server by Apache, 6.x branch Now after a while the wiki will just stop working and the CPU will spin up to 100%?? The system is a Pentium Core 2 Quad Mini-ITX system with 4GB of memory. It runs 7 jails and lots of software both in and out of the jails however swap space never gets colonized meaning that I'm well within the systems limites!! uname -a shows this output: FreeBSD wiki.optiplex-networks.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Checking the memory: wiki# dmesg | grep memory real memory = 4294967296 (4096 MB) avail memory = 3995734016 (3810 MB) agp0: detected 32764k stolen memory real memory = 4294967296 (4096 MB) avail memory = 3993894912 (3808 MB) agp0: detected 32764k stolen memory real memory = 4294967296 (4096 MB) avail memory = 3993894912 (3808 MB) agp0: detected 32764k stolen memory the cpu: kern.ccpu: 0 cpu count=4 mask=0xf0, 1, 2, 3/cpu cpu count=4 mask=0xf0, 1, 2, 3/cpu cpu_reset: Stopping other CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu0:ACPI CPU on acpi0 est0:Enhanced SpeedStep Frequency Control on cpu0 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc0:CPU Frequency Thermal Control on cpu0 cpu1:ACPI CPU on acpi0 est1:Enhanced SpeedStep Frequency Control on cpu1 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc1:CPU Frequency Thermal Control on cpu1 cpu2:ACPI CPU on acpi0 est2:Enhanced SpeedStep Frequency Control on cpu2 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc2:CPU Frequency Thermal Control on cpu2 cpu3:ACPI CPU on acpi0 est3:Enhanced SpeedStep Frequency Control on cpu3 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc3:CPU Frequency Thermal Control on cpu3 cpu_reset: Stopping other CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu0:ACPI CPU on acpi0 est0:Enhanced SpeedStep Frequency Control on cpu0 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc0:CPU Frequency Thermal Control on cpu0 cpu1:ACPI CPU on acpi0 est1:Enhanced SpeedStep Frequency Control on cpu1 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc1:CPU Frequency Thermal Control on cpu1 cpu2:ACPI CPU on acpi0 est2:Enhanced SpeedStep Frequency Control on cpu2 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc2:CPU Frequency Thermal Control on cpu2 cpu3:ACPI CPU on acpi0 est3:Enhanced SpeedStep Frequency Control on cpu3 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc3:CPU Frequency Thermal Control on cpu3 cpu_reset: Stopping other CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu0:ACPI CPU on acpi0 est0:Enhanced SpeedStep Frequency Control on cpu0 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc0:CPU Frequency Thermal Control on cpu0 cpu1:ACPI CPU on acpi0 est1:Enhanced SpeedStep Frequency Control on cpu1 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc1:CPU Frequency Thermal Control on cpu1 cpu2:ACPI CPU on acpi0 est2:Enhanced SpeedStep Frequency Control on cpu2 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc2:CPU Frequency Thermal Control on cpu2 cpu3:ACPI CPU on acpi0 est3:Enhanced SpeedStep Frequency Control on cpu3 est: cpu_vendor GenuineIntel, msr 616081a0600081a p4tcc3:CPU Frequency Thermal Control on cpu3 kern.smp.cpus: 4 kern.smp.maxcpus: 32 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.kdb.stop_cpus: 1 hw.ncpu: 4 hw.acpi.cpu.cx_lowest: C1 machdep.hlt_cpus: 0 security.jail.param.cpuset.id: 0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2666 dev.cpu.0.freq_levels: 2666/-1 2332/-1 1999/-1 1666/-1 1333/-1 999/-1 666/-1 333/-1 dev.cpu.0.cx_supported: C1/20 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU2 dev.cpu.1.%pnpinfo:
Re: Fwd: Tomcat6 port keeps locking up??
On Fri, Sep 17, 2010 at 11:37:13AM +0300, Kaya Saman wrote: This is a snapshot of the 'top' command that shows Java at 100%. Basically it means that the system is more in this state then functional and I can't understand why! Can anyone help me?? You should probably spend a bit of time in a debugger (specifically a Java debugger) figuring out if your code is spinning or not. Debugging anything under Tomcat/Java is a PITA, and I say that from experience. I would advocate you open up a bug/report with the Apache folks and provide them this information, especially if the only thing you're seeing problems with is Tomcat (and not other software). For example -- at my workplace we run Solaris 10, with Tomcat heavily used for different purposes (mainly a translation layer between HTTP and Cisco ICR protocols). For years we saw a problem where a Tomcat thread would take up 100% CPU (ex. on a 4-core machine, 25% CPU) when a Cisco PG would disconnect/reconnect repetitively (common during network problems). The problem turned out to be two fold: a bug in Tomcat, and some improper code on our part, resulted in Tomcat spinning. We did not open up a SunSolve case because there wouldn't have been a point to it. Otherwise I will have to start looking at migrating this service away from BSD and much more costlier option of Nexenta based on OpenSolaris, but hogs RAM as uses ZFS natively meaning min 4GB unlike my FreeBSD build with ZFS and UFS2 using 4GB for that many processes and 7 jails! I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more memory, the Solaris kernel dynamically releases portions of the ARC. We use ZFS on Solaris 10 exclusively at my day job (thousands of x86 servers). When we moved to ZFS, we had to adjust our system memory monitors to take into consideration ARC usage. What I'm trying to say: on Solaris with ZFS, don't let I don't see any free memory in top or prstat equate to there isn't any free memory available for applications. Solaris handles this situation very, *very* well; we have never seen any userland applications get starved for memory as a result of using ZFS on all of our machines. -- | Jeremy Chadwick j...@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 freebsd-ports-unsubscr...@freebsd.org
Re: Fwd: Tomcat6 port keeps locking up??
Thanks a lot Jeremy for the response!! On 17/09/2010 11:56, Jeremy Chadwick wrote: [...] You should probably spend a bit of time in a debugger (specifically a Java debugger) figuring out if your code is spinning or not. Debugging anything under Tomcat/Java is a PITA, and I say that from experience. I would advocate you open up a bug/report with the Apache folks and provide them this information, especially if the only thing you're seeing problems with is Tomcat (and not other software). For example -- at my workplace we run Solaris 10, with Tomcat heavily used for different purposes (mainly a translation layer between HTTP and Cisco ICR protocols). For years we saw a problem where a Tomcat thread would take up 100% CPU (ex. on a 4-core machine, 25% CPU) when a Cisco PG would disconnect/reconnect repetitively (common during network problems). The problem turned out to be two fold: a bug in Tomcat, and some improper code on our part, resulted in Tomcat spinning. We did not open up a SunSolve case because there wouldn't have been a point to it. Hmm... it's the Xwiki application I'm using which works fine on the OpenSolaris homesite although running a different OS and proper programmers there with the experience to deal with such things!! I'll try though and see what happens. Otherwise I will have to start looking at migrating this service away from BSD and much more costlier option of Nexenta based on OpenSolaris, but hogs RAM as uses ZFS natively meaning min 4GB unlike my FreeBSD build with ZFS and UFS2 using 4GB for that many processes and 7 jails! I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more memory, the Solaris kernel dynamically releases portions of the ARC. We use ZFS on Solaris 10 exclusively at my day job (thousands of x86 servers). When we moved to ZFS, we had to adjust our system memory monitors to take into consideration ARC usage. What I'm trying to say: on Solaris with ZFS, don't let I don't see any free memory in top or prstat equate to there isn't any free memory available for applications. Solaris handles this situation very, *very* well; we have never seen any userland applications get starved for memory as a result of using ZFS on all of our machines. Thanks for explaining!! :-) Actually with everyone claiming that OpenSolaris/Solaris needs min. 4GB memory to run a basic system it kinda confuses me a little. Also since I am currently in a job where I can only use MS products there's no one to ask either, even though my personal projects are all UNIX based. It's just hard sometimes to work alone on EVERYTHING which is often how I'm left... anyhow!! I'll look into this situation and see if it is possible to migrate over to Nexenta using Glassfish and MySQL instead of the Postgresql and Tomcat6 setup I have currently. Best regards, Kaya ___ 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: Fwd: Tomcat6 port keeps locking up??
on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? -- Andriy Gapon ___ 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
pwlib build failure
Thanks in advance for any help on this one david gmake[3]: Entering directory `/usr/ports/devel/pwlib/work/ptlib_v1_12_0/src/ptlib/unix' c++ -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -D_REENTRANT -pthread -fno-exceptions -O1 - I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -Wall -g -D_DEBUG -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -O1 -fPIC - DLDAP_DEPRECATED -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -c ../../ptclib/psasl.cxx -o /usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/psasl.o c++ -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -D_REENTRANT -pthread -fno-exceptions -O1 - I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -Wall -g -D_DEBUG -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -O1 -fPIC - DLDAP_DEPRECATED -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -c ../../ptclib/pldap.cxx -o /usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/pldap.o c++ -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -D_REENTRANT -pthread -fno-exceptions -O1 - I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -Wall -g -D_DEBUG -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -O1 -fPIC - DLDAP_DEPRECATED -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -c ../../ptclib/pils.cxx -o /usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/pils.o c++ -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -D_REENTRANT -pthread -fno-exceptions -O1 - I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -Wall -g -D_DEBUG -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -O1 -fPIC - DLDAP_DEPRECATED -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include - I/usr/local/include -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -c ../../ptclib/pssl.cxx -o /usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/pssl.o ../../ptclib/pssl.cxx: In constructor 'PSSLContext::PSSLContext(const void*, PINDEX)': ../../ptclib/pssl.cxx:917: error: invalid conversion from 'const SSL_METHOD*' to 'SSL_METHOD*' gmake[3]: *** [/usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/pssl.o] Error 1 gmake[3]: Leaving directory `/usr/ports/devel/pwlib/work/ptlib_v1_12_0/src/ptlib/unix' gmake[2]: *** [debug] Error 2 gmake[2]: Leaving directory `/usr/ports/devel/pwlib/work/ptlib_v1_12_0' gmake[1]: *** [libs] Error 2 gmake[1]: Leaving directory `/usr/ports/devel/pwlib/work/ptlib_v1_12_0' gmake: *** [debuglibs] Error 2 *** Error code 1 Stop in /usr/ports/devel/pwlib. dns1# Photographic Artist Permanent Installations Design Creative Imagery and Advanced Digital Techniques High Dynamic Range Photography Official Portraiture Combined darkroom digital creations Systems Adminstrator for the vizion2000.net network ___ 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: Fwd: Tomcat6 port keeps locking up??
On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? -- | Jeremy Chadwick j...@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 freebsd-ports-unsubscr...@freebsd.org
Re: Fwd: Tomcat6 port keeps locking up??
on 17/09/2010 12:42 Jeremy Chadwick said the following: On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? I am not sure if this has even been the case :-) It is definitely not the case now. -- Andriy Gapon ___ 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: Fwd: Tomcat6 port keeps locking up??
- Original Message - From: Jeremy Chadwick On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? My experience is no this is no longer the case at least on stable + patches mentioned on thread:- zfs very poor performance compared to ufs due to lack of cache? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Fwd: Tomcat6 port keeps locking up??
on 17/09/2010 12:49 Steven Hartland said the following: My experience is no this is no longer the case at least on stable + patches mentioned on thread:- zfs very poor performance compared to ufs due to lack of cache? And at least one of those is a patch to prevent ZFS from giving memory too eagerly. -- Andriy Gapon ___ 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: Fwd: Tomcat6 port keeps locking up??
On Fri, Sep 17, 2010 at 12:53:09PM +0300, Andriy Gapon wrote: on 17/09/2010 12:42 Jeremy Chadwick said the following: On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? I am not sure if this has even been the case :-) It is definitely not the case now. I trust your experience with it *much* more than mine. :-) It's very likely that I'm basing the ARC remains at 1400MB claim entirely off of what top(1) was showing under either Inact or Wired. The terminology in top(1) for memory on BSD has always confused the hell out of me. That might sound crazy coming from someone that's been using *IX since 1990 and BSD since 1996, but it's true. The man page does go over what's what, but the descriptions are short one-liners (ex. wired down doesn't mean anything to me). This just circles back to my lack of knowledge about the VM. -- | Jeremy Chadwick j...@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 freebsd-ports-unsubscr...@freebsd.org
Re: Fwd: Tomcat6 port keeps locking up??
On 17/09/2010 13:07, Jeremy Chadwick wrote: On Fri, Sep 17, 2010 at 12:53:09PM +0300, Andriy Gapon wrote: on 17/09/2010 12:42 Jeremy Chadwick said the following: On Fri, Sep 17, 2010 at 12:19:00PM +0300, Andriy Gapon wrote: on 17/09/2010 11:56 Jeremy Chadwick said the following: I don't think you understand how Solaris's VM behaves with ZFS. It behaves very differently than FreeBSD. On Solaris/OpenSolaris with ZFS, you'll see the ARC taking up as much memory as possible -- but unlike FreeBSD (AFAIK), when a userland or kernel application requires more ^ memory, the Solaris kernel dynamically releases portions of the ARC. Can you please explain that unlike part? When ZFS was first introduced to FreeBSD, I was given the impression from continual posts on the mailing lists that memory which was allocated to the ARC was never released in the situation that a userland program wanted memory. An example scenario. These numbers are in no way accurate given many other things (network mbufs, UFS and VFS cache, etc.): - amd64 system has 2GB physical RAM (assume ~1920MB usable) - vm.kmem_size=1536M + vfs.zfs.arc_max=1400M - Heavy ZFS I/O results in ARC maxing out at ~1400MB - Userland application runs, requests malloc() of 1024MB - Userland gets 384MB from physical RAM, remaining 640MB from swap - ARC remains at 1400MB Is this no longer the case? I am not sure if this has even been the case :-) It is definitely not the case now. I trust your experience with it *much* more than mine. :-) It's very likely that I'm basing the ARC remains at 1400MB claim entirely off of what top(1) was showing under either Inact or Wired. The terminology in top(1) for memory on BSD has always confused the hell out of me. That might sound crazy coming from someone that's been using *IX since 1990 and BSD since 1996, but it's true. The man page does go over what's what, but the descriptions are short one-liners (ex. wired down doesn't mean anything to me). This just circles back to my lack of knowledge about the VM. Aren't there supposed to be 2 versions of 'top'?? Unix top and Linux top?? Both with slightly different handles on the representation of information? I just recall reading somewhere!! ___ 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
Can't fetch libxml2-2.7.7.tar.gz
When building the meta port xorg I get an error saying libxml2-2.7.7.tar.gz local modification time does not match remote Ports tree is updated with portsnap update. Any advise ? Thanks /Leslie ___ 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: Can't fetch libxml2-2.7.7.tar.gz
On Fri, Sep 17, 2010 at 03:52:01PM +0200, Leslie Jensen wrote: When building the meta port xorg I get an error saying libxml2-2.7.7.tar.gz local modification time does not match remote Ports tree is updated with portsnap update. Any advise ? Can't reproduce... # pkg_info | grep libxml2 libxml2-2.7.7 = up-to-date with port # cd /usr/ports/textproc/libxml2 # ls -l total 10 -rw-r--r-- 1 root wheel 2016 Jun 25 00:23 Makefile -rw-r--r-- 1 root wheel 218 May 11 05:18 distinfo drwxr-xr-x 2 root wheel 512 May 11 05:18 files -rw-r--r-- 1 root wheel 339 Jan 15 2007 pkg-descr -rw-r--r-- 1 root wheel 1822 May 11 2006 pkg-plist # egrep ^PORT Makefile PORTNAME= libxml2 PORTVERSION=2.7.7 PORTREVISION?= 0 # cat distinfo MD5 (gnome2/libxml2-2.7.7.tar.gz) = 9abc9959823ca9ff904f1fbcf21df066 SHA256 (gnome2/libxml2-2.7.7.tar.gz) = af5b781418ba4fff556fa43c50086658ea8a2f31909c2b625c2ce913a1d9eb68 SIZE (gnome2/libxml2-2.7.7.tar.gz) = 4868502 -- | Jeremy Chadwick j...@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 freebsd-ports-unsubscr...@freebsd.org
Re: Can't fetch libxml2-2.7.7.tar.gz
On 2010-09-17 16:25, Jeremy Chadwick wrote: On Fri, Sep 17, 2010 at 03:52:01PM +0200, Leslie Jensen wrote: When building the meta port xorg I get an error saying libxml2-2.7.7.tar.gz local modification time does not match remote Ports tree is updated with portsnap update. Any advise ? Can't reproduce... # pkg_info | grep libxml2 libxml2-2.7.7 = up-to-date with port # cd /usr/ports/textproc/libxml2 # ls -l total 10 -rw-r--r-- 1 root wheel 2016 Jun 25 00:23 Makefile -rw-r--r-- 1 root wheel 218 May 11 05:18 distinfo drwxr-xr-x 2 root wheel 512 May 11 05:18 files -rw-r--r-- 1 root wheel 339 Jan 15 2007 pkg-descr -rw-r--r-- 1 root wheel 1822 May 11 2006 pkg-plist # egrep ^PORT Makefile PORTNAME= libxml2 PORTVERSION=2.7.7 PORTREVISION?= 0 # cat distinfo MD5 (gnome2/libxml2-2.7.7.tar.gz) = 9abc9959823ca9ff904f1fbcf21df066 SHA256 (gnome2/libxml2-2.7.7.tar.gz) = af5b781418ba4fff556fa43c50086658ea8a2f31909c2b625c2ce913a1d9eb68 SIZE (gnome2/libxml2-2.7.7.tar.gz) = 4868502 I get r...@bljbsd01/usr/ports/textproc/libxml2:make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Extracting for libxml2-2.7.7 = MD5 Checksum mismatch for gnome2/libxml2-2.7.7.tar.gz. = SHA256 Checksum mismatch for gnome2/libxml2-2.7.7.tar.gz. === Refetch for 1 more times files: gnome2/libxml2-2.7.7.tar.gz gnome2/libxml2-2.7.7.tar.gz === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = libxml2-2.7.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/gnome2. = Attempting to fetch from ftp://fr.rpmfind.net/pub/libxml/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://gd.tuwien.ac.at/pub/libxml/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://xmlsoft.org/libxml2/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/gnome2/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/gnome2 and try again. *** Error code 1 Stop in /usr/ports/textproc/libxml2. *** Error code 1 Stop in /usr/ports/textproc/libxml2. ___ 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: Can't fetch libxml2-2.7.7.tar.gz
On Fri, Sep 17, 2010 at 04:36:20PM +0200, Leslie Jensen wrote: On 2010-09-17 16:25, Jeremy Chadwick wrote: On Fri, Sep 17, 2010 at 03:52:01PM +0200, Leslie Jensen wrote: When building the meta port xorg I get an error saying libxml2-2.7.7.tar.gz local modification time does not match remote Ports tree is updated with portsnap update. Any advise ? Can't reproduce... # pkg_info | grep libxml2 libxml2-2.7.7 = up-to-date with port # cd /usr/ports/textproc/libxml2 # ls -l total 10 -rw-r--r-- 1 root wheel 2016 Jun 25 00:23 Makefile -rw-r--r-- 1 root wheel 218 May 11 05:18 distinfo drwxr-xr-x 2 root wheel 512 May 11 05:18 files -rw-r--r-- 1 root wheel 339 Jan 15 2007 pkg-descr -rw-r--r-- 1 root wheel 1822 May 11 2006 pkg-plist # egrep ^PORT Makefile PORTNAME= libxml2 PORTVERSION=2.7.7 PORTREVISION?= 0 # cat distinfo MD5 (gnome2/libxml2-2.7.7.tar.gz) = 9abc9959823ca9ff904f1fbcf21df066 SHA256 (gnome2/libxml2-2.7.7.tar.gz) = af5b781418ba4fff556fa43c50086658ea8a2f31909c2b625c2ce913a1d9eb68 SIZE (gnome2/libxml2-2.7.7.tar.gz) = 4868502 I get r...@bljbsd01/usr/ports/textproc/libxml2:make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Extracting for libxml2-2.7.7 = MD5 Checksum mismatch for gnome2/libxml2-2.7.7.tar.gz. = SHA256 Checksum mismatch for gnome2/libxml2-2.7.7.tar.gz. === Refetch for 1 more times files: gnome2/libxml2-2.7.7.tar.gz gnome2/libxml2-2.7.7.tar.gz === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = libxml2-2.7.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/gnome2. = Attempting to fetch from ftp://fr.rpmfind.net/pub/libxml/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://gd.tuwien.ac.at/pub/libxml/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://xmlsoft.org/libxml2/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/gnome2/. fetch: libxml2-2.7.7.tar.gz: local modification time does not match remote = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/gnome2 and try again. *** Error code 1 It looks to me like the tarball you have in /usr/ports/distfiles, probably from a previous build attempt, it incomplete or corrupt. The checksum validation failure is proof of this. I'm betting the file on your system is too small. ls -l /usr/ports/distfiles/gnome2/libxml2-2.7.7.tar.gz should tell you what size the file is. A proper file: -rw-r--r--1 root wheel 4868502 15 Mar 2010 /usr/ports/distfiles/gnome2/libxml2-2.7.7.tar.gz I think the modification time mismatch indicates that fetch is trying to resume the transfer (e.g. pick up where the corrupted file left off), but the resume can't happen for the above reason. If you attempt make distclean, then make install clean, it should re-fetch the entire tarball from scratch. -- | Jeremy Chadwick j...@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 freebsd-ports-unsubscr...@freebsd.org
Re: Can't fetch libxml2-2.7.7.tar.gz
It looks to me like the tarball you have in /usr/ports/distfiles, probably from a previous build attempt, it incomplete or corrupt. The checksum validation failure is proof of this. I'm betting the file on your system is too small. ls -l /usr/ports/distfiles/gnome2/libxml2-2.7.7.tar.gz should tell you what size the file is. A proper file: -rw-r--r--1 root wheel 4868502 15 Mar 2010 /usr/ports/distfiles/gnome2/libxml2-2.7.7.tar.gz I think the modification time mismatch indicates that fetch is trying to resume the transfer (e.g. pick up where the corrupted file left off), but the resume can't happen for the above reason. If you attempt make distclean, then make install clean, it should re-fetch the entire tarball from scratch. You where right! the distclean made it work. Thank you ___ 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
[x11/nvidia-driver] didn't install vdpau header files with NOPORTDOCS
Hi,
I've just meet a problem with x11/nvidia-driver by installing it with:
make install -DNOPORTDOCS
The vdpau include files were not installed (vdpau.h and vdpau_x11.h):
ls /usr/local/include/vdpau/
vdpau*.h
I believe their is a problem in the Makefile on this line:
@${LN} -sf ${DOCSDIR}/vdpau*.h ${PREFIX}/include/vdpau
The vdpau files are links to docs file.
How can I fix it ?
Thanks,
Olivier
___
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: [x11/nvidia-driver] didn't install vdpau header files with NOPORTDOCS
Olivier Cochard-Labbé oliv...@cochard.me writes:
Hi,
I've just meet a problem with x11/nvidia-driver by installing it with:
make install -DNOPORTDOCS
The vdpau include files were not installed (vdpau.h and vdpau_x11.h):
ls /usr/local/include/vdpau/
vdpau*.h
I believe their is a problem in the Makefile on this line:
@${LN} -sf ${DOCSDIR}/vdpau*.h ${PREFIX}/include/vdpau
The vdpau files are links to docs file.
How can I fix it ?
Try to replace the line with
@${INSTALL_DATA} ${WRKSRC}/doc/vdpau*.h ${PREFIX}/include/vdpau
Alternatively you can install libvdpau port.
http://www.freebsd.org/cgi/query-pr-summary.cgi?text=vdpau
___
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: autoconf update
On 09/17/2010 00:41, Doug Barton wrote: On 9/16/2010 6:15 PM, Doug Barton wrote: On 9/16/2010 3:35 PM, Anonymous wrote: Dominic Fandreykamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. We shouldn't use our users to beta-test infrastructure changes. Sorry, I'm not feeling well atm and realize that I didn't write what I was thinking here. What I intended to say was that we _don't_ intentionally use the ports system to force our users to beta test changes. I think it goes without saying that we _shouldn't_ do this, although I think that changes like this are a platinum-coated example of why we need to have -stable and -dev branches for ports. Doug I agree with this to an extent. Having two branches while being a nice idea is not really needed with some of the version control software that is out there. Mercurial being the distributed version control that it is allows you to clone, make the changes you need to the clone test it thoroughly and then either push or pull them to the main tree. This would allow the same work that is being done on ports right now continue to happen with less effort and greater amount of cooperation between users and developers alike. The ports tree is a prime example of why we need a distributed version control. Personally I would love to be able to say HEY! I just made these changes to this port because it was not acting right and you can pull my patch for it here: http://host/repo/. Once tested by whomever Joe Blow Committee they can choose to modify it further test and or push it to the main tree where others can update from. Main Tree Users pull and clone from here | `- Dev CloneDevs pull and clone from here and push to main Ports is a distributed project being used in an old non distributed version control system. If this is going to get anywhere something needs to change and it needs to start from the ground up. Lets do it! no excuses, it does not take very long to convert to mercurial including keeping history intact and there is front-ends for this all over the place. -- jhell,v ___ 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
editors/vim installs to /
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
--
jhell,v
___
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: editors/vim installs to /
2010/9/17 jhell jh...@dataix.net:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
--
jhell,v
___
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
No,
${PREFIX} is the good variable to specify the installation directory,
of course if you set this the port will probably install its files in
the user-defined ${PREFIX}.
I'm writing the rewrite of the port to update vim to 7.3 and with a
real OPTIONS framework and remove the stupid WITH_VIM_OPTIONS KNOB
that doesn't work. The problem is that David doesn't like clean things
and I think he won't commit it because it won't be enough complicated.
With kind regards,
--
Demelier David
___
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
x11/kdelibs4 build fails, can't find docbook
While building kde4-4.5.1, I get this error: # make install clean === kde4-4.5.1 depends on file: /usr/local/kde4/bin/kdebugdialog - not found ===Verifying install for /usr/local/kde4/bin/kdebugdialog in /usr/ports/x11/kdebase4-runtime === kdebase-runtime-4.5.1 depends on file: /usr/local/lib/libssh.so - found === kdebase-runtime-4.5.1 depends on file: /usr/local/share/xml/docbook/4.2/docbookx.dtd - not found === Verifying install for /usr/local/share/xml/docbook/4.2/docbookx.dtd in /usr/ports/textproc/docbook-xml === Returning to build of kdebase-runtime-4.5.1 === kdebase-runtime-4.5.1 depends on executable: gmake - found === kdebase-runtime-4.5.1 depends on file: /usr/local/lib/qt4/libQtCore.so - found === kdebase-runtime-4.5.1 depends on file: /usr/local/lib/qt4/libQtDBus.so - found === kdebase-runtime-4.5.1 depends on file: /usr/local/bin/moc-qt4 - found === kdebase-runtime-4.5.1 depends on file: /usr/local/lib/qt4/libQtOpenGL.so - found === kdebase-runtime-4.5.1 depends on file: /usr/local/lib/qt4/libphonon.so - found === kdebase-runtime-4.5.1 depends on file: /usr/local/bin/qmake-qt4 - found === kdebase-runtime-4.5.1 depends on file: /usr/local/bin/rcc - found === kdebase-runtime-4.5.1 depends on file: /usr/local/bin/uic-qt4 - found === kdebase-runtime-4.5.1 depends on file: /usr/local/bin/automoc4 - found === kdebase-runtime-4.5.1 depends on file: /usr/local/bin/cmake - found === kdebase-runtime-4.5.1 depends on shared library: IlmImf.6 - found === kdebase-runtime-4.5.1 depends on shared library: exiv2.9 - found === kdebase-runtime-4.5.1 depends on shared library: xine.1 - found === kdebase-runtime-4.5.1 depends on shared library: slp.1 - found === kdebase-runtime-4.5.1 depends on shared library: smbclient.0 - found === kdebase-runtime-4.5.1 depends on shared library: ssh.4 - found === kdebase-runtime-4.5.1 depends on shared library: attica.0 - found === kdebase-runtime-4.5.1 depends on shared library: intl - found === kdebase-runtime-4.5.1 depends on shared library: kimproxy.5 - not found ===Verifying install for kimproxy.5 in /usr/ports/x11/kdelibs4 === kdelibs-4.5.1 depends on file: /usr/local/lib/libhspell.a - found === kdelibs-4.5.1 depends on file: /usr/local/share/ontology/core/rdf.ontology - found === kdelibs-4.5.1 depends on file: /usr/local/share/xml/docbook/4.2/docbookx.dtd - not found === Verifying install for /usr/local/share/xml/docbook/4.2/docbookx.dtd in /usr/ports/textproc/docbook-xml === Returning to build of kdelibs-4.5.1 === kdelibs-4.5.1 depends on file: /usr/local/share/xsl/docbook/html/docbook.xsl - found === kdelibs-4.5.1 depends on executable: gmake - found === kdelibs-4.5.1 depends on executable: bison - found === kdelibs-4.5.1 depends on file: /usr/local/bin/assistant-qt4 - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtCore.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtDBus.so - found === kdelibs-4.5.1 depends on file: /usr/local/bin/designer-qt4 - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtGui.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so - found === kdelibs-4.5.1 depends on file: /usr/local/bin/makeqpf-qt4 - found === kdelibs-4.5.1 depends on file: /usr/local/bin/moc-qt4 - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtNetwork.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtOpenGL.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libphonon.so - found === kdelibs-4.5.1 depends on file: /usr/local/bin/qdbusviewer - found === kdelibs-4.5.1 depends on file: /usr/local/bin/qmake-qt4 - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQt3Support.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtTest.so - found === kdelibs-4.5.1 depends on file: /usr/local/bin/rcc - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtScript.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtSql.so - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtSvg.so - found === kdelibs-4.5.1 depends on file: /usr/local/bin/uic-qt4 - found === kdelibs-4.5.1 depends on file: /usr/local/lib/qt4/libQtXml.so - found === kdelibs-4.5.1 depends on executable: pkg-config - found === kdelibs-4.5.1 depends on file: /usr/local/bin/automoc4 - found === kdelibs-4.5.1 depends on package: kde4-shared-mime-info=1 - found === kdelibs-4.5.1 depends on file: /usr/local/bin/cmake - found === kdelibs-4.5.1 depends on shared library: searchclient - found === kdelibs-4.5.1 depends on shared library: soprano.4 - found === kdelibs-4.5.1 depends on shared library: IlmImf - found === kdelibs-4.5.1 depends on shared library: aspell - found === kdelibs-4.5.1 depends on shared library: jasper - found === kdelibs-4.5.1 depends on shared library: pcre - found === kdelibs-4.5.1 depends on shared
Size mismatch in audio/espeak port
There is an apparent size mismatch in the audio/espeak port: /usr/ports/audio/espeak $ sudo make === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = espeak-1.44.05-source.zip doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://heanet.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://heanet.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://sunet.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://sunet.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://iweb.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://iweb.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://switch.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://switch.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://surfnet.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://surfnet.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://kent.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://kent.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://freefr.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://freefr.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://voxel.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://voxel.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://jaist.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://jaist.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://osdn.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://osdn.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://nchc.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://nchc.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://transact.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://transact.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://softlayer.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://softlayer.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://internode.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://internode.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381 = Attempting to fetch from http://biznetnetworks.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/. fetch: http://biznetnetworks.dl.sourceforge.net/project/espeak/espeak/espeak-1.44/espeak-1.44.05-source.zip: size mismatch: expected 2000190, actual 2000381
freeradius2 port with e-dir
Around 3 weeks ago, I had asked on the list about how to compile FreeRADIUS 2 with support for e-directory. I had been hoping to get an answer back by now from someone with a success story of using FreeRADIUS 2 on FreeBSD with Novell E-Directory for a backend. With the (very) old freeradius1 port, there is a toggle in options for e-dir support, but that is missing in the freeradius2 port. It was verified by the FreeRADIUS mailing list that support for E-Directory needs to be compiled in. I've not had a chance to set up the new server yet, but that should be happening in the next week or two. With the imminent release of 2.1.10, I may just set the rest of the server up and wait for that to install FreeRADIUS. I tried looking through the Makefile but I didn't find any reference to edir there. Would it be possible to add the E-Directory option back or at least provide the option within the Makefile even if not available from make config? (Or just tell me I'm an idiot and show me what I missed that gets it to build with e-dir support. ;)) Thanks in advance. -- John McDonnell Penn Cambria School District mcdon...@pcam.org ___ 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: editors/vim installs to /
On 9/17/2010 10:49 AM, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
LOCALBASE is where the ports can find things that have been previously
installed. PREFIX is where a port will install into. Personally I've
never seen a valid argument for having 2 separate definitions, but
that's how it has always been.
hth,
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.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: editors/vim installs to /
On Fri, Sep 17, 2010 at 09:21:46PM +0200, David DEMELIER wrote:
2010/9/17 jhell jh...@dataix.net:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150649
There's that PR which is probably related but it's a bit light on useful
information.
No,
${PREFIX} is the good variable to specify the installation directory,
of course if you set this the port will probably install its files in
the user-defined ${PREFIX}.
I'm writing the rewrite of the port to update vim to 7.3 and with a
real OPTIONS framework and remove the stupid WITH_VIM_OPTIONS KNOB
that doesn't work. The problem is that David doesn't like clean things
and I think he won't commit it because it won't be enough complicated.
While I agree that editors/vim could use the changes you're discussing,
do you really think such a comment is needed? Attacks like that are not
necessary. Let your code speak for itself.
-- 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
Re: editors/vim installs to /
On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
I reverted to the previous Makefile just to get something working before
I leave. I did want to point out that the cleanup (at least for me) was
not that hard. /man and /share were left behind along with a handful of
files in /bin that shouldn't have been there. Once I had reverted and
installed vim I was able to use something like
pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
To find the files which were in /bin that should not have been there.
Not all of them were there in my case but the cleanup was easy. Just
delete /man and /share and the handful of files in /bin.
I still don't know what the real fix for this is but hopefully someone
is working on it. ;)
-- 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
Re: [x11/nvidia-driver] didn't install vdpau header files with NOPORTDOCS
On Fri, Sep 17, 2010 at 5:29 PM, Anonymous swel...@gmail.com wrote:
Try to replace the line with
�...@${install_data} ${WRKSRC}/doc/vdpau*.h ${PREFIX}/include/vdpau
Thanks !
Works great :-)
Regards,
Olivier
___
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: Size mismatch in audio/espeak port
Jerry freebsd-ports.u...@seibercom.net writes: There is an apparent size mismatch in the audio/espeak port: and the date is more recent than the port change, as well. Looks like the release was re-rolled upstream, without changing the version number. You can probably get away with grabbing the new distfile, updating distinfo (there's a makefile target for that), and building it from there. Depends on your comfort level. Or you can wait for nivit@ to go through it and make an official fix. ___ 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: Size mismatch in audio/espeak port
On Fri, 17 Sep 2010 17:04:51 -0400 Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org articulated: Jerry freebsd-ports.u...@seibercom.net writes: There is an apparent size mismatch in the audio/espeak port: and the date is more recent than the port change, as well. Looks like the release was re-rolled upstream, without changing the version number. You can probably get away with grabbing the new distfile, updating distinfo (there's a makefile target for that), and building it from there. Depends on your comfort level. Or you can wait for nivit@ to go through it and make an official fix. I think he just did. http://www.freebsd.org/cgi/query-pr.cgi?pr=150679 -- Jerry ✌ freebsd-ports.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ A general leading the State Department resembles a dragon commanding ducks. New York Times, Jan. 20, 1981 ___ 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: Size mismatch in audio/espeak port
Hi, [2010/9/17 Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org] Jerry freebsd-ports.u...@seibercom.net writes: There is an apparent size mismatch in the audio/espeak port: [...] Or you can wait for nivit@ to go through it and make an official fix. Just fixed. Thank you for the report. -- Nicola Vitale ___ 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: editors/vim installs to /
On Fri, Sep 17, 2010 at 13:54, Wesley Shields w...@freebsd.org wrote: While I agree that editors/vim could use the changes you're discussing, do you really think such a comment is needed? Attacks like that are not necessary. Let your code speak for itself. -- WXS This port has major issues and numerous polite requests (including with patches) to fix them have been summarily ignored or rejected. So don't act surprised when people start to get annoyed by the situation. -- Rob Farmer ___ 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: freeradius2 port with e-dir
On 2010-09-17 22:00, John D McDonnell wrote: Around 3 weeks ago, I had asked on the list about how to compile FreeRADIUS 2 with support for e-directory. I had been hoping to get an answer back by now from someone with a success story of using FreeRADIUS 2 on FreeBSD with Novell E-Directory for a backend. With the (very) old freeradius1 port, there is a toggle in options for e-dir support, but that is missing in the freeradius2 port. It was verified by the FreeRADIUS mailing list that support for E-Directory needs to be compiled in. I've not had a chance to set up the new server yet, but that should be happening in the next week or two. With the imminent release of 2.1.10, I may just set the rest of the server up and wait for that to install FreeRADIUS. I tried looking through the Makefile but I didn't find any reference to edir there. Would it be possible to add the E-Directory option back or at least provide the option within the Makefile even if not available from make config? (Or just tell me I'm an idiot and show me what I missed that gets it to build with e-dir support. ;)) Thanks in advance. Hi John, can you test the attached patch for freeradius2. The --with-edir parameter is only used in the src/modules/rlm_ldap/configure script, I guess it was just overlooked. If the patch is working for you please open a PR. -- olli Index: Makefile === RCS file: /home/pcvs/ports/net/freeradius2/Makefile,v retrieving revision 1.88 diff -u -r1.88 Makefile --- Makefile15 Sep 2010 18:34:58 - 1.88 +++ Makefile17 Sep 2010 22:56:06 - @@ -47,6 +47,7 @@ KERBEROSWith Kerberos support off \ HEIMDAL With Heimdal Kerberos support off \ LDAPWith LDAP database support off \ + EDIRWith Novell eDirectory support off \ MYSQL With MySQL database support off \ PGSQL With PostgreSQL database support off \ UNIXODBCWith unixODBC database support off \ @@ -97,6 +98,10 @@ PLIST_SUB+=KRB5=@comment .endif +.if defined(WITH_EDIR) !defined(WITH_LDAP) +WITH_LDAP= yes +.endif + .ifdef(WITH_LDAP) USE_OPENLDAP= YES CONFIGURE_ARGS+=--with-rlm_ldap @@ -107,6 +112,10 @@ PLIST_SUB+=LDAP=@comment .endif +.ifdef(WITH_EDIR) +CONFIGURE_ARGS+=--with-edir +.endif + .ifdef(WITH_MYSQL) USE_MYSQL= YES CONFIGURE_ARGS+=--with-rlm_sql_mysql ___ 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: autoconf update
jhell jh...@dataix.net wrote: ... Mercurial being the distributed version control that it is allows you to clone, make the changes you need to the clone test it thoroughly and then either push or pull them to the main tree ... At the risk of starting the VCS variant of the vi vs emacs wars :) why Mercurial (rather than, say, GIT or SVK)? And no, I have nothing against Mercurial. I don't know _any_ distributed VCS well enough to have an opinion of which would be best suited. ___ 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: editors/vim installs to /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/2010 17:19, Wesley Shields wrote:
On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
I reverted to the previous Makefile just to get something working before
I leave. I did want to point out that the cleanup (at least for me) was
not that hard. /man and /share were left behind along with a handful of
files in /bin that shouldn't have been there. Once I had reverted and
installed vim I was able to use something like
pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
To find the files which were in /bin that should not have been there.
Not all of them were there in my case but the cleanup was easy. Just
delete /man and /share and the handful of files in /bin.
I still don't know what the real fix for this is but hopefully someone
is working on it. ;)
-- WXS
Attached is the exact patch that fixes this. The two effected areas are
post pre-configure. My best guess on this lays on the REINPLACE_CMD in
pre-configure but I could be wrong.
- --
jhell,v
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJMk/cwAAoJEJBXh4mJ2FR+xukH/2JgWGagRpnvUUjbJfCXetDe
/ahIbbohU+pDmeJ3F6UwcoxPgSd2mW0vRiC+3fFLKi/otAgYqfS+L5X5hMmIoBd1
fgqTeXqy2hF+1IcPdBAIrigxGqv6CA4BmUHYhdMLHV+TVFfboeU70fuBeEYnfsR6
VNYWe8B/0Qb9VNkV+FDFSlvp0Qu4ONkwxPevp/hgTu2914Kd+kmjnLRBTBLekQJ+
KLwXoc1jqoLBwvhT+DRRDFSskNiXjJuAGyt0k10sQpYZCaPwXSXT4mYhjhqDyCnk
uSjxiQe3MK7W1G1QK9RjLOjyMiXbJ8Rv7j6h/pgAoxsegN8xOFryfonRQKp3G44=
=4CXp
-END PGP SIGNATURE-
--- Makefile.1.357 2010-09-17 18:49:24.188934083 -0400
+++ Makefile 2010-09-17 19:13:22.041265307 -0400
@@ -195,9 +195,6 @@
${REINPLACE_CMD} -e 's,ctags -R \.,${CTAGS_CMD},g')
pre-configure:
- # Fix dependency misspelling so that 'make -j#' will work.
- @${REINPLACE_CMD} -e 's|\./auto/osdef\.h|auto/osdef.h|g' \
- ${WRKSRC}/Makefile
@(cd ${WRKSRC} ; ${MAKE} distclean)
@${REINPLACE_CMD} -e ' \
s|\$$gtk_config_prefix/bin/gtk-config|\$${GTK_CONFIG}|g; \
@@ -210,9 +207,6 @@
${WRKSRC}/feature.h
.endif
-post-configure:
- @(cd ${WRKSRC} ; ${MAKE} scratch config)
-
# Clean up junk files to keep them from being installed.
pre-install:
@${FIND} ${WRKSRC:H} -type f -name '*.orig' -delete
Makefile.diff.sig
Description: Binary data
___
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: editors/vim installs to /
On Fri, Sep 17, 2010 at 07:18:09PM -0400, jhell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/2010 17:19, Wesley Shields wrote:
On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
I reverted to the previous Makefile just to get something working before
I leave. I did want to point out that the cleanup (at least for me) was
not that hard. /man and /share were left behind along with a handful of
files in /bin that shouldn't have been there. Once I had reverted and
installed vim I was able to use something like
pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
To find the files which were in /bin that should not have been there.
Not all of them were there in my case but the cleanup was easy. Just
delete /man and /share and the handful of files in /bin.
I still don't know what the real fix for this is but hopefully someone
is working on it. ;)
-- WXS
Attached is the exact patch that fixes this. The two effected areas are
post pre-configure. My best guess on this lays on the REINPLACE_CMD in
pre-configure but I could be wrong.
You may want to also revert the MAKE_JOBS_SAFE too.
-- 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
Re: editors/vim installs to /
On Fri, Sep 17, 2010 at 03:51:42PM -0700, Rob Farmer wrote: On Fri, Sep 17, 2010 at 13:54, Wesley Shields w...@freebsd.org wrote: While I agree that editors/vim could use the changes you're discussing, do you really think such a comment is needed? Attacks like that are not necessary. Let your code speak for itself. -- WXS This port has major issues and numerous polite requests (including with patches) to fix them have been summarily ignored or rejected. So don't act surprised when people start to get annoyed by the situation. I'm not surprised. I'm pointing out that attacks like that are not going to further the cause of getting the port the care you think it deserves. Unfortunately I don't know what the answer is beyond polite requests and patches to fix the problems as you see them. I do know that attacks are not the answer and are in fact harmful to achieving a goal. -- 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
Re: editors/vim installs to /
On 09/17/2010 19:22, Wesley Shields wrote:
On Fri, Sep 17, 2010 at 07:18:09PM -0400, jhell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/2010 17:19, Wesley Shields wrote:
On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
I reverted to the previous Makefile just to get something working before
I leave. I did want to point out that the cleanup (at least for me) was
not that hard. /man and /share were left behind along with a handful of
files in /bin that shouldn't have been there. Once I had reverted and
installed vim I was able to use something like
pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
To find the files which were in /bin that should not have been there.
Not all of them were there in my case but the cleanup was easy. Just
delete /man and /share and the handful of files in /bin.
I still don't know what the real fix for this is but hopefully someone
is working on it. ;)
-- WXS
Attached is the exact patch that fixes this. The two effected areas are
post pre-configure. My best guess on this lays on the REINPLACE_CMD in
pre-configure but I could be wrong.
You may want to also revert the MAKE_JOBS_SAFE too.
-- WXS
Yeah I am leaving that up to the committee to decide. With that setting
here, it builds and installs fine so I am not concerned with it as I
have no control over the end result.
--
jhell,v
___
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: editors/vim installs to /
On 09/17/2010 19:52, Anonymous wrote:
jhell jh...@dataix.net writes:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Does the following diff fixes it?
%%
Index: editors/vim/Makefile
===
RCS file: /a/.cvsup/ports/editors/vim/Makefile,v
retrieving revision 1.357
diff -u -p -r1.357 Makefile
--- editors/vim/Makefile 17 Sep 2010 00:46:45 - 1.357
+++ editors/vim/Makefile 17 Sep 2010 23:47:49 -
@@ -166,7 +166,7 @@ MAKE_ARGS+= CONF_OPT_GUI=--enable-gui=n
MAKE_ARGS+= CONF_OPT_PERL=--disable-perlinterp --disable-pythoninterp
--disable-tclinterp --disable-rubyinterp
.endif # LITE
-.if exists(${PREFIX}/lib/libiconv.so)
+.if exists(${LOCALBASE}/lib/libiconv.so)
USE_ICONV= yes
.endif
@@ -211,7 +211,7 @@ pre-configure:
.endif
post-configure:
- @(cd ${WRKSRC} ; ${MAKE} scratch config)
+ @(cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE} ${MAKE_ARGS} scratch
config)
#Clean up junk files to keep them from being installed.
pre-install:
%%
Since this really is not specific to one installation on a single system
and that I have already compiled and re-installed this port I will not
be testing this patch. Thank you for providing more information to the
maintainer.
Regards,
--
jhell,v
___
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: editors/vim installs to /
jhell jh...@dataix.net writes:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Does the following diff fixes it?
%%
Index: editors/vim/Makefile
===
RCS file: /a/.cvsup/ports/editors/vim/Makefile,v
retrieving revision 1.357
diff -u -p -r1.357 Makefile
--- editors/vim/Makefile17 Sep 2010 00:46:45 - 1.357
+++ editors/vim/Makefile17 Sep 2010 23:47:49 -
@@ -166,7 +166,7 @@ MAKE_ARGS+= CONF_OPT_GUI=--enable-gui=n
MAKE_ARGS+=CONF_OPT_PERL=--disable-perlinterp --disable-pythoninterp
--disable-tclinterp --disable-rubyinterp
.endif # LITE
-.if exists(${PREFIX}/lib/libiconv.so)
+.if exists(${LOCALBASE}/lib/libiconv.so)
USE_ICONV= yes
.endif
@@ -211,7 +211,7 @@ pre-configure:
.endif
post-configure:
- @(cd ${WRKSRC} ; ${MAKE} scratch config)
+ @(cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE} ${MAKE_ARGS} scratch
config)
# Clean up junk files to keep them from being installed.
pre-install:
%%
___
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: editors/vim installs to /
On Fri, Sep 17, 2010 at 16:24, Wesley Shields w...@freebsd.org wrote: On Fri, Sep 17, 2010 at 03:51:42PM -0700, Rob Farmer wrote: On Fri, Sep 17, 2010 at 13:54, Wesley Shields w...@freebsd.org wrote: While I agree that editors/vim could use the changes you're discussing, do you really think such a comment is needed? Attacks like that are not necessary. Let your code speak for itself. -- WXS This port has major issues and numerous polite requests (including with patches) to fix them have been summarily ignored or rejected. So don't act surprised when people start to get annoyed by the situation. I'm not surprised. I'm pointing out that attacks like that are not going to further the cause of getting the port the care you think it deserves. Unfortunately I don't know what the answer is beyond polite requests and patches to fix the problems as you see them. I do know that attacks are not the answer and are in fact harmful to achieving a goal. -- WXS Fair enough. My apologies if my comments on this were too aggressive. However, I still think it would benefit everyone if the maintainer could provide an explanation for some of the current behavior and would at least be open to discussion about changing it. The biggest problem here, IMHO, is not the OPTIONS issue, but rather the use of GTK 1 as the default. Plenty of ports don't support OPTIONS, even though they could, and many users ignore options by setting BATCH, but it isn't a big deal because the defaults are ideal for most situations. I think either defaulting to GTK 2 or just making vim a console application would eliminate most of these complaints. -- Rob Farmer ___ 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: editors/vim installs to /
On Sat, Sep 18, 2010 at 03:52:17AM +0400, Anonymous wrote: jhell jh...@dataix.net writes: After a force upgrade of vim that had failed unfortunately not registering the files it installed already I found out that it is installing to / ~! ugh. Does the following diff fixes it? It does allow the port to pass my tinderbox tests. Hopefully obrien@ will commit it shortly. -- 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
Re: editors/vim installs to /
Anonymous swel...@gmail.com writes:
jhell jh...@dataix.net writes:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Does the following diff fixes it?
%%
Index: editors/vim/Makefile
===
RCS file: /a/.cvsup/ports/editors/vim/Makefile,v
retrieving revision 1.357
diff -u -p -r1.357 Makefile
--- editors/vim/Makefile 17 Sep 2010 00:46:45 - 1.357
+++ editors/vim/Makefile 17 Sep 2010 23:47:49 -
@@ -166,7 +166,7 @@ MAKE_ARGS+= CONF_OPT_GUI=--enable-gui=n
MAKE_ARGS+= CONF_OPT_PERL=--disable-perlinterp --disable-pythoninterp
--disable-tclinterp --disable-rubyinterp
.endif # LITE
-.if exists(${PREFIX}/lib/libiconv.so)
+.if exists(${LOCALBASE}/lib/libiconv.so)
USE_ICONV= yes
.endif
Oops, this hunk with a tiny bit of description is now in ports/150690.
It addresses an unrelated issue.
@@ -211,7 +211,7 @@ pre-configure:
.endif
post-configure:
- @(cd ${WRKSRC} ; ${MAKE} scratch config)
+ @(cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE} ${MAKE_ARGS} scratch
config)
#Clean up junk files to keep them from being installed.
pre-install:
%%
And this hunk is resent as followup to ports/150649.
___
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
