Re: Fwd: building java/eclipse in HEAD w/ poudriere ...
El día Friday, October 24, 2014 a las 08:04:11PM +0200, Matthias Apitz escribió: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193479 ... Re/ RAM and SWAP, I watched the server in the moment when it fails: there is plenty much RAM and SWAP unused (many GBytes). So I don't agree that the server limits the build, it must be something in the jail constructed by poudriere. This is was a cyclcic top shows in the moment when the JVM crashes; the java proc has a SIZE of 465M; is there somehow a jail limit for memeory of 512M? last pid: 92498; load averages: 2.52, 2.38, 2.21 up 0+01:38:05 08:11:58 94 processes: 3 running, 91 sleeping CPU: 91.7% user, 0.0% nice, 8.3% system, 0.0% interrupt, 0.0% idle Mem: 886M Active, 2254M Inact, 266M Wired, 49M Cache, 90M Buf, 47M Free Swap: 4096M Total, 1431M Used, 2664M Free, 34% Inuse, 28K In PID USERNAMETHR PRI NICE SIZERES STATETIMEWCPU COMMAND 46713 root 26 520 465M 395M uwait 34:41 94.67% java 803 guru 1 200 95640K 66984K select 2:18 2.49% Xorg 868 guru 4 200 255M 54632K select 0:17 1.19% kwin -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ chinese/scim-tables | 0.5.10 | 0.5.14.1 +-+ devel/projectcenter | 0.6.1 | 0.6.2 +-+ science/gramps | 3.4.8 | 4.1.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: audio/openal-soft fails to install on FreeBSD 8.4-stable
On Fri, Oct 24, 2014 at 10:32 PM, Henry Hu henry.hu...@gmail.com wrote: I just tried it on 8.4-RELEASE/amd64 and it failed with the same error. It seems like that the gcc on 8.4 is too old. One way to fix it is adding USE_GCC=yes to makefile. This will use gcc 4.8 by default and it builds successfully. But on later freebsd versions we can just use clang. Maintainer cc'ed. Interesting. I tried this: root@kg-core1# grep USES Makefile USES= tar:bzip2 cmake compiler:c11 and now it compiles happily: root@kg-core1# make === License LGPL20 accepted by the user === Found saved configuration for openal-soft-1.16.0 === openal-soft-1.16.0 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by openal-soft-1.16.0 for building === Extracting for openal-soft-1.16.0 = SHA256 Checksum OK for openal-soft-1.16.0.tar.bz2. === Patching for openal-soft-1.16.0 === Applying FreeBSD patches for openal-soft-1.16.0 === openal-soft-1.16.0 depends on file: /usr/local/bin/cmake - found === openal-soft-1.16.0 depends on file: /usr/local/bin/clang34 - found === openal-soft-1.16.0 depends on file: /usr/local/bin/as - found === Configuring for openal-soft-1.16.0 === Performing in-source build /bin/mkdir -p /usr/ports/audio/openal-soft/work/openal-soft-1.16.0 -- The C compiler identification is Clang 3.4.2 -- The CXX compiler identification is Clang 3.4.2 -- Check for working C compiler: /usr/local/bin/clang34 -- Check for working C compiler: /usr/local/bin/clang34 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/local/bin/clang++34 -- Check for working CXX compiler: /usr/local/bin/clang++34 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Checking _FILE_OFFSET_BITS for large files -- Checking _FILE_OFFSET_BITS for large files - not needed -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of long -- Check size of long - done -- Check size of long long -- Check size of long long - done -- Performing Test HAVE_STD_C99 -- Performing Test HAVE_STD_C99 - Success -- Performing Test HAVE_C99_VLA -- Performing Test HAVE_C99_VLA - Success -- Performing Test HAVE_C99_BOOL -- Performing Test HAVE_C99_BOOL - Success -- Performing Test HAVE_C11_STATIC_ASSERT -- Performing Test HAVE_C11_STATIC_ASSERT - Success -- Performing Test HAVE_C11_ALIGNAS -- Performing Test HAVE_C11_ALIGNAS - Success -- Performing Test HAVE_C11_ATOMIC -- Performing Test HAVE_C11_ATOMIC - Failed -- Performing Test HAVE_W_EXTRA -- Performing Test HAVE_W_EXTRA - Success -- Performing Test HAVE_FPIC_SWITCH -- Performing Test HAVE_FPIC_SWITCH - Success -- Performing Test HAVE_GCC_DESTRUCTOR -- Performing Test HAVE_GCC_DESTRUCTOR - Success -- Performing Test HAVE_GCC_PROTECTED_VISIBILITY -- Performing Test HAVE_GCC_PROTECTED_VISIBILITY - Success -- Performing Test HAVE_VISIBILITY_HIDDEN_SWITCH -- Performing Test HAVE_VISIBILITY_HIDDEN_SWITCH - Success -- Performing Test HAVE_ATTRIBUTE_ALIGNED -- Performing Test HAVE_ATTRIBUTE_ALIGNED - Success -- Performing Test HAVE_MSSE_SWITCH -- Performing Test HAVE_MSSE_SWITCH - Success -- Performing Test HAVE_MSSE2_SWITCH -- Performing Test HAVE_MSSE2_SWITCH - Success -- Performing Test HAVE_MSSE4_1_SWITCH -- Performing Test HAVE_MSSE4_1_SWITCH - Success -- Performing Test HAVE_GCC_FORMAT -- Performing Test HAVE_GCC_FORMAT - Success -- Looking for stdbool.h -- Looking for stdbool.h - found -- Looking for stdalign.h -- Looking for stdalign.h - not found -- Looking for malloc.h -- Looking for malloc.h - not found -- Looking for ftw.h -- Looking for ftw.h - found -- Looking for io.h -- Looking for io.h - not found -- Looking for strings.h -- Looking for strings.h - found -- Looking for cpuid.h -- Looking for cpuid.h - found -- Looking for intrin.h -- Looking for intrin.h - not found -- Looking for sys/sysconf.h -- Looking for sys/sysconf.h - not found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for float.h -- Looking for float.h - found -- Looking for ieeefp.h -- Looking for ieeefp.h - found -- Looking for guiddef.h -- Looking for guiddef.h - not found -- Looking for initguid.h -- Looking for initguid.h - not found -- Performing Test HAVE_GCC_GET_CPUID -- Performing Test HAVE_GCC_GET_CPUID - Success -- Looking for pow in m -- Looking for pow in m - found -- Looking for aligned_alloc -- Looking for aligned_alloc - not found -- Looking for posix_memalign -- Looking for posix_memalign - found -- Looking for _aligned_malloc -- Looking for _aligned_malloc - not found -- Looking for lrintf -- Looking for lrintf - found -- Looking for _controlfp -- Looking for _controlfp - not found -- Looking for __control87_2 -- Looking for __control87_2 - not found -- Looking for ftw -- Looking for ftw - found -- Looking for strtof -- Looking for strtof - found --
Re: Status of ntopng
On 10/25/14 04:28, Muhammad Moinur Rahman wrote: Hi, Hello. First off, thanks for your attention. 1. I am not aware about if it's not working in 8.4. It will be helpful if you can provide me any logs. # uname -r 8.4-RELEASE-p16 # cd /usr/ports/net/ntopng/ # make === ntopng-1.2.1 is marked as broken: Does not build on 8.X due to *ENDIAN implementations. *** Error code 1 Stop in /usr/ports/net/ntopng. In fact on the contrary I think it's time for you to at least upgrade to 9.3 as 8.4 will be EOL soon. There's more than half a year of support ahead; I already moved several system to 9.3, but I still cannot move others. This is out of the scope, anyway. If ntopng does not work on this systems, I'll live with that (in fact, as I said, I installed it on another box). 2. Not aware of that either. Last time I checked it was working well. # portupgrade -RNv ntopng # service ntopng onestart #/usr/local/etc/rc.d/ntopng: 33: Syntax error: Unterminated quoted string It's trivial to add the missing quote. Besides, I discovered redis is required; maybe it should be a dependency? Finally, running redis, I got ERROR: Startup error: missing super-user privileges ? in /var/tmp/ntopng/ntopng.log, until I fiddled with ntopng_flags. This might be normal, though; I don't know ntopng enough yet to tell. 3. nProbe is a commercial supported GPL product where the source code is available for the customer. However I will talk with Luca if he provides me the code so that I can work on it and make some patches to work on. Thanks, it would be great. You are looking on the wrong direction I believe. I am not aware about your traffic capacity but what you are looking for is possible without nProbe too. Consult ntopng user guide. I believe -i and -I will clarify your requirements. Since I cannot run ntopng on the two 8.4 routers, I cannot right now achieve this setup (if I get what you are suggesting right). That's why I thought about nProbe. bye Thanks av. ___ 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: Status of ntopng
Hi, On Sat, Oct 25, 2014 at 6:37 PM, Andrea Venturoli m...@netfence.it wrote: On 10/25/14 04:28, Muhammad Moinur Rahman wrote: Hi, Hello. First off, thanks for your attention. 1. I am not aware about if it's not working in 8.4. It will be helpful if you can provide me any logs. # uname -r 8.4-RELEASE-p16 # cd /usr/ports/net/ntopng/ # make === ntopng-1.2.1 is marked as broken: Does not build on 8.X due to *ENDIAN implementations. *** Error code 1 Stop in /usr/ports/net/ntopng. Sorry, my mistake. Yes it is broken for 8.4. Tried a lot but I need to patch so many files that I left it like that. In fact on the contrary I think it's time for you to at least upgrade to 9.3 as 8.4 will be EOL soon. There's more than half a year of support ahead; I already moved several system to 9.3, but I still cannot move others. This is out of the scope, anyway. If ntopng does not work on this systems, I'll live with that (in fact, as I said, I installed it on another box). 2. Not aware of that either. Last time I checked it was working well. # portupgrade -RNv ntopng # service ntopng onestart #/usr/local/etc/rc.d/ntopng: 33: Syntax error: Unterminated quoted string It's trivial to add the missing quote. Besides, I discovered redis is required; maybe it should be a dependency? Finally, running redis, I got ERROR: Startup error: missing super-user privileges ? in /var/tmp/ntopng/ntopng.log, until I fiddled with ntopng_flags. This might be normal, though; I don't know ntopng enough yet to tell. Will look forward to it. Yes. You will require a redis server. It's built with redis client. But in most of the cases we don't add server as a dependency as the user might use a different database server host. 3. nProbe is a commercial supported GPL product where the source code is available for the customer. However I will talk with Luca if he provides me the code so that I can work on it and make some patches to work on. Thanks, it would be great. You are looking on the wrong direction I believe. I am not aware about your traffic capacity but what you are looking for is possible without nProbe too. Consult ntopng user guide. I believe -i and -I will clarify your requirements. Since I cannot run ntopng on the two 8.4 routers, I cannot right now achieve this setup (if I get what you are suggesting right). That's why I thought about nProbe. bye Thanks av. You can try ntop itself. Not the ntopng. If you are looking forward something explicit to flow based sampling try the following URL to look for more alternatives. http://www.freshports.org/search.php?stype=shortdescriptionmethod=matchquery=netflownum=100orderby=categoryorderbyupdown=ascsearch=Search However I am not aware about any tools which can generate netflow/sflow alike traffic from FreeBSD host itself except bpft. But you can give a shot at the following to investigate your options: http://www.switch.ch/network/projects/completed/TF-NGN/floma/software.html BR, Muhammad ___ 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
Python 2.7 and semaphores
In the process of building and trying textproc/meld, I discovered that
the lang/python27 configure process concludes, erroneously, that FreeBSD
does not support working Posix semaphores. In particular, this program
from the configure script was alleged to fail, according to config.log:
#include unistd.h
#include fcntl.h
#include stdio.h
#include semaphore.h
#include sys/stat.h
int main(void) {
sem_t *a = sem_open(/autoconf, O_CREAT, S_IRUSR|S_IWUSR, 0);
if (a == SEM_FAILED) {
perror(sem_open);
return 1;
}
sem_close(a);
sem_unlink(/autoconf);
return 0;
}
But when I compiled and ran the program by hand, it worked perfectly.
Then, poking around in lang/python27/Makefile, I found these two lines:
SEM_CONFIGURE_ENV= ac_cv_posix_semaphores_enabled=yes
SEM_CONFIGURE_ENV_OFF= ac_cv_posix_semaphores_enabled=no
I could not explain why these settings should have any effect on the
configure and build process, but muttering my most superstitious
imprecations under my breath I changed ...=no to ...=yes in the
second line and re-installed Python. Lo and behold, configure now
admitted that Posix semaphores worked, and I could run meld. (Why
meld needs working semaphores is beyond me, but I'll worry about that
another day.)
Can anyone explain to me how those lines affect the configure process?
And does either line belong in the Makefile at this point?-- George
___
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: building java/eclipse in HEAD w/ poudriere ...
El día Friday, October 24, 2014 a las 12:38:45PM -0500, Jimmy Kelley escribió: Matthias, I finally had the time to set up an environment to do the build in a -CURRENT i386 poudriere environment. It built with no errors; see the bug you filed for details: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193479 Regards, Jimmy I was able today to build java/eclipse with poudriere in an i386 VM with: 4 GByte RAM 6 GByte SWAP files and the following parameters. /boot/loader.conf: kern.maxdsiz=1073741824 # in bytes 1024*1024*1024 kern.maxssiz=671088640 # in bytes 65536*1024*10 kern.maxswzone=72351744 # double of default 36.175.872 /usr/local/etc/poudriere.conf: export MAVEN_OPTS='-Xmx1024m -XX:MaxPermSize=256m' export JAVA_OPTS='-Xms512m -Xmx1024m' It took around ~52 minutes to build and I think the essential is the memory/swap in the last phase of the building, and esp. to unlimit the JVM (per default it seems to be limited to 512 MByte). Maybe we should adjust the above *_OPTS value in the ports Makefile. I have closed the issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193479 matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ___ 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: Python 2.7 and semaphores
On Sat, Oct 25, 2014 at 2:38 PM, George Mitchell george+free...@m5p.com
wrote:
In the process of building and trying textproc/meld, I discovered that
the lang/python27 configure process concludes, erroneously, that FreeBSD
does not support working Posix semaphores. In particular, this program
from the configure script was alleged to fail, according to config.log:
#include unistd.h
#include fcntl.h
#include stdio.h
#include semaphore.h
#include sys/stat.h
int main(void) {
sem_t *a = sem_open(/autoconf, O_CREAT, S_IRUSR|S_IWUSR, 0);
if (a == SEM_FAILED) {
perror(sem_open);
return 1;
}
sem_close(a);
sem_unlink(/autoconf);
return 0;
}
But when I compiled and ran the program by hand, it worked perfectly.
Then, poking around in lang/python27/Makefile, I found these two lines:
SEM_CONFIGURE_ENV= ac_cv_posix_semaphores_enabled=yes
SEM_CONFIGURE_ENV_OFF= ac_cv_posix_semaphores_enabled=no
I could not explain why these settings should have any effect on the
configure and build process, but muttering my most superstitious
imprecations under my breath I changed ...=no to ...=yes in the
second line and re-installed Python. Lo and behold, configure now
admitted that Posix semaphores worked, and I could run meld. (Why
meld needs working semaphores is beyond me, but I'll worry about that
another day.)
Can anyone explain to me how those lines affect the configure process?
And does either line belong in the Makefile at this point?-- George
There is a config option called SEM which enables Posix sem support.
By default it is enabled.
___
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
--
Cheers,
Henry
___
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: Python 2.7 and semaphores
On 10/25/14 18:16, Henry Hu wrote: On Sat, Oct 25, 2014 at 2:38 PM, George Mitchell george+free...@m5p.com wrote: In the process of building and trying textproc/meld, I discovered that the lang/python27 configure process concludes, erroneously, that FreeBSD does not support working Posix semaphores. [...] Can anyone explain to me how those lines affect the configure process? And does either line belong in the Makefile at this point?-- George There is a config option called SEM which enables Posix sem support. By default it is enabled. Thanks for the explanation. I must have turned the option off at some point in the past, but I don't remember doing it.-- George ___ 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: Python 2.7 and semaphores
On Sat, Oct 25, 2014 at 7:26 PM, George Mitchell george+free...@m5p.com wrote: On 10/25/14 18:16, Henry Hu wrote: On Sat, Oct 25, 2014 at 2:38 PM, George Mitchell george+free...@m5p.com wrote: In the process of building and trying textproc/meld, I discovered that the lang/python27 configure process concludes, erroneously, that FreeBSD does not support working Posix semaphores. [...] Can anyone explain to me how those lines affect the configure process? And does either line belong in the Makefile at this point?-- George There is a config option called SEM which enables Posix sem support. By default it is enabled. Thanks for the explanation. I must have turned the option off at some point in the past, but I don't remember doing it.-- George I guess that it's a new option, and it seems like that because the old selected options are remembered, the new option is considered as not selected. I think that I've hit this problem before. ___ 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 -- Cheers, Henry ___ 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
