Re: nmap broken on current
Peter Pentchev r...@ringlet.net 2009-03-30: On Sun, Mar 29, 2009 at 07:23:00PM -0700, Manfred Antar wrote: the nmap port is broken on current: Shouldn't this be reported to the port's maintainer - Daniel Roethlisberger dan...@roe.ch? :) I've CC'd him on this message... Thanks for CC:-ing me, Peter. c++ -c -I/usr/local/include/lua51 -I/usr/local/include -I/usr/local/include -I/usr/include -Inbase -Insock/include -O2 -pipe -fno-strict-aliasing -Wall -fno-strict-aliasing -DHAVE_CONFIG_H -DNMAP_NAME=\Nmap\ -DNMAP_URL=\http://nmap.org\; -DNMAP_PLATFORM=\i386-portbld-freebsd8.0\ -DNMAPDATADIR=\/usr/local/share/nmap\ -DNMAPLIBEXECDIR=\/usr/local/libexec/nmap\ main.cc -o main.o c++ -c -I/usr/local/include/lua51 -I/usr/local/include -I/usr/local/include -I/usr/include -Inbase -Insock/include -O2 -pipe -fno-strict-aliasing -Wall -fno-strict-aliasing -DHAVE_CONFIG_H -DNMAP_NAME=\Nmap\ -DNMAP_URL=\http://nmap.org\; -DNMAP_PLATFORM=\i386-portbld-freebsd8.0\ -DNMAPDATADIR=\/usr/local/share/nmap\ -DNMAPLIBEXECDIR=\/usr/local/libexec/nmap\ nmap.cc -o nmap.o In file included from Target.h:115, from traceroute.h:101, from nmap.cc:111: tcpip.h:458: error: declaration of C function 'int resolve(char*, in_addr*)' conflicts with tcpip.h:453: error: previous declaration 'int resolve(char*, sockaddr_storage*, size_t*, int)' here In file included from nmap.cc:121: utils.h:188: error: template with C linkage nmap.h: In function 'int nmap_main(int, char**)': nmap.h:416: error: previous declaration of 'int nmap_main(int, char**)' with 'C++' linkage nmap.cc:503: error: conflicts with new declaration with 'C' linkage nmap.cc: In function 'int nmap_main(int, char**)': nmap.cc:1167: error: cannot convert 'sockaddr_storage*' to 'in_addr*' for argument '2' to 'int resolve(char*, in_addr*)' nmap.cc:1673: error: cannot convert 'sockaddr_storage*' to 'in_addr*' for argument '2' to 'int resolve(char*, in_addr*)' nmap.h: In function 'void nmap_free_mem()': nmap.h:418: error: previous declaration of 'void nmap_free_mem()' with 'C++' linkage nmap.cc:1907: error: conflicts with new declaration with 'C' linkage nmap.h: In function 'int gather_logfile_resumption_state(char*, int*, char***)': nmap.h:438: error: previous declaration of 'int gather_logfile_resumption_state(char*, int*, char***)' with 'C++' linkage nmap.cc:1932: error: conflicts with new declaration with 'C' linkage nmap.h: In function 'void nmap_free_mem()': nmap.h:413: error: previous declaration of 'void init_socket(int)' with 'C++' linkage nmap.cc:2038: error: conflicts with new declaration with 'C' linkage nmap.h:407: error: previous declaration of 'void getpts(const char*, scan_lists*)' with 'C++' linkage nmap.cc:2128: error: conflicts with new declaration with 'C' linkage nmap.h:409: error: previous declaration of 'void getpts_simple(const char*, int, short unsigned int**, int*)' with 'C++' linkage nmap.cc:2191: error: conflicts with new declaration with 'C' linkage nmap.h:410: error: previous declaration of 'void free_scan_lists(scan_lists*)' with 'C++' linkage nmap.cc:2400: error: conflicts with new declaration with 'C' linkage nmap.h:402: error: previous declaration of 'void printinteractiveusage()' with 'C++' linkage nmap.cc:2410: error: conflicts with new declaration with 'C' linkage nmap.h:426: error: previous declaration of 'char* seqreport(seq_info*)' with 'C++' linkage nmap.cc:2432: error: conflicts with new declaration with 'C' linkage nmap.h:434: error: previous declaration of 'const char* seqidx2difficultystr(long unsigned int)' with 'C++' linkage nmap.cc:2441: error: conflicts with new declaration with 'C' linkage nmap.h:429: error: previous declaration of 'const char* ipidclass2ascii(int)' with 'C++' linkage nmap.cc:2445: error: conflicts with new declaration with 'C' linkage nmap.h:430: error: previous declaration of 'const char* tsseqclass2ascii(int)' with 'C++' linkage nmap.cc:2466: error: conflicts with new declaration with 'C' linkage nmap.h:423: error: previous declaration of 'const char* scantype2str(stype)' with 'C++' linkage nmap.cc:2491: error: conflicts with new declaration with 'C' linkage nmap.h:422: error: previous declaration of 'const char* statenum2str(int)' with 'C++' linkage nmap.cc:2523: error: conflicts with new declaration with 'C' linkage nmap.h:404: error: previous declaration of 'int ftp_anon_connect(ftpinfo*)' with 'C++' linkage nmap.cc:2536: error: conflicts with new declaration with 'C' linkage nmap.h:425: error: previous declaration of 'void reaper(int)' with 'C++' linkage nmap.cc:2614: error: conflicts with new declaration with 'C' linkage nmap.h:424: error: previous declaration of 'void sigdie(int)' with 'C++' linkage nmap.cc:2626: error: conflicts with new declaration with 'C' linkage
Dangling extern C in pcap.h (was: Re: nmap broken on current)
Daniel Roethlisberger dan...@roe.ch 2009-03-30: Peter Pentchev r...@ringlet.net 2009-03-30: On Sun, Mar 29, 2009 at 07:23:00PM -0700, Manfred Antar wrote: the nmap port is broken on current: Shouldn't this be reported to the port's maintainer - Daniel Roethlisberger dan...@roe.ch? :) I've CC'd him on this message... Thanks for CC:-ing me, Peter. c++ -c -I/usr/local/include/lua51 -I/usr/local/include -I/usr/local/include -I/usr/include -Inbase -Insock/include -O2 -pipe -fno-strict-aliasing -Wall -fno-strict-aliasing -DHAVE_CONFIG_H -DNMAP_NAME=\Nmap\ -DNMAP_URL=\http://nmap.org\; -DNMAP_PLATFORM=\i386-portbld-freebsd8.0\ -DNMAPDATADIR=\/usr/local/share/nmap\ -DNMAPLIBEXECDIR=\/usr/local/libexec/nmap\ main.cc -o main.o c++ -c -I/usr/local/include/lua51 -I/usr/local/include -I/usr/local/include -I/usr/include -Inbase -Insock/include -O2 -pipe -fno-strict-aliasing -Wall -fno-strict-aliasing -DHAVE_CONFIG_H -DNMAP_NAME=\Nmap\ -DNMAP_URL=\http://nmap.org\; -DNMAP_PLATFORM=\i386-portbld-freebsd8.0\ -DNMAPDATADIR=\/usr/local/share/nmap\ -DNMAPLIBEXECDIR=\/usr/local/libexec/nmap\ nmap.cc -o nmap.o In file included from Target.h:115, from traceroute.h:101, from nmap.cc:111: tcpip.h:458: error: declaration of C function 'int resolve(char*, in_addr*)' conflicts with tcpip.h:453: error: previous declaration 'int resolve(char*, sockaddr_storage*, size_t*, int)' here In file included from nmap.cc:121: utils.h:188: error: template with C linkage nmap.h: In function 'int nmap_main(int, char**)': nmap.h:416: error: previous declaration of 'int nmap_main(int, char**)' with 'C++' linkage nmap.cc:503: error: conflicts with new declaration with 'C' linkage nmap.cc: In function 'int nmap_main(int, char**)': nmap.cc:1167: error: cannot convert 'sockaddr_storage*' to 'in_addr*' for argument '2' to 'int resolve(char*, in_addr*)' nmap.cc:1673: error: cannot convert 'sockaddr_storage*' to 'in_addr*' for argument '2' to 'int resolve(char*, in_addr*)' nmap.h: In function 'void nmap_free_mem()': nmap.h:418: error: previous declaration of 'void nmap_free_mem()' with 'C++' linkage nmap.cc:1907: error: conflicts with new declaration with 'C' linkage nmap.h: In function 'int gather_logfile_resumption_state(char*, int*, char***)': nmap.h:438: error: previous declaration of 'int gather_logfile_resumption_state(char*, int*, char***)' with 'C++' linkage nmap.cc:1932: error: conflicts with new declaration with 'C' linkage nmap.h: In function 'void nmap_free_mem()': nmap.h:413: error: previous declaration of 'void init_socket(int)' with 'C++' linkage nmap.cc:2038: error: conflicts with new declaration with 'C' linkage nmap.h:407: error: previous declaration of 'void getpts(const char*, scan_lists*)' with 'C++' linkage nmap.cc:2128: error: conflicts with new declaration with 'C' linkage nmap.h:409: error: previous declaration of 'void getpts_simple(const char*, int, short unsigned int**, int*)' with 'C++' linkage nmap.cc:2191: error: conflicts with new declaration with 'C' linkage nmap.h:410: error: previous declaration of 'void free_scan_lists(scan_lists*)' with 'C++' linkage nmap.cc:2400: error: conflicts with new declaration with 'C' linkage nmap.h:402: error: previous declaration of 'void printinteractiveusage()' with 'C++' linkage nmap.cc:2410: error: conflicts with new declaration with 'C' linkage nmap.h:426: error: previous declaration of 'char* seqreport(seq_info*)' with 'C++' linkage nmap.cc:2432: error: conflicts with new declaration with 'C' linkage nmap.h:434: error: previous declaration of 'const char* seqidx2difficultystr(long unsigned int)' with 'C++' linkage nmap.cc:2441: error: conflicts with new declaration with 'C' linkage nmap.h:429: error: previous declaration of 'const char* ipidclass2ascii(int)' with 'C++' linkage nmap.cc:2445: error: conflicts with new declaration with 'C' linkage nmap.h:430: error: previous declaration of 'const char* tsseqclass2ascii(int)' with 'C++' linkage nmap.cc:2466: error: conflicts with new declaration with 'C' linkage nmap.h:423: error: previous declaration of 'const char* scantype2str(stype)' with 'C++' linkage nmap.cc:2491: error: conflicts with new declaration with 'C' linkage nmap.h:422: error: previous declaration of 'const char* statenum2str(int)' with 'C++' linkage nmap.cc:2523: error: conflicts with new declaration with 'C' linkage nmap.h:404: error: previous declaration of 'int ftp_anon_connect(ftpinfo*)' with 'C++' linkage nmap.cc:2536: error: conflicts with new declaration with 'C' linkage nmap.h:425: error: previous declaration of 'void reaper(int)' with 'C++' linkage nmap.cc:2614: error: conflicts with new declaration with 'C' linkage nmap.h:424
Re: Call for potential ports maintainers
Thomas Abthorpe tabtho...@freebsd.org 2009-02-12: This topic came up in IRC, and I was encouraged to go out, and find some new maintainers. At any given time, approximately 20 - 25% of all ports are unmaintained. Not all unmaintained ports need updating, but some do. That is where you folks come in. There are a bunch of you out there who are subscribers to this list (and other FreeBSD related lists too, I am sure), you have FreeBSD installed and likely have quite an array of ports installed on this system of yours. You are subscribed as a means of keeping up with the world of FreeBSD. But you have been holding back, thinking I really would like to do something to contribute to the success of FreeBSD, but I am not sure what. How do I know this? I was one, a silent observer on the mailing lists, and in on IRC. Then one day, I answered a similar plea, http://lists.freebsd.org/pipermail/freebsd-announce/2006-May/001065.html. I have summarised some details on the wiki on Adopting Ports, http://wiki.freebsd.org/PortsTasks#head-f018f566bce2ff96ec13fabd536d7cc6dc6f4275. The gauntlet has been thrown down, who among you is prepared to pick it up? I'll adopt these two additional ports: security/md4coll security/fragrouter Thanks! -- Daniel Roethlisberger http://daniel.roe.ch/ ___ 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: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko k...@kth.se 2009-02-03:
On Tuesday 03 February 2009, Daniel Roethlisberger wrote:
Garrett Cooper yanef...@gmail.com 2009-02-02:
On Mon, Feb 2, 2009 at 8:38 AM, Daniel Roethlisberger dan...@roe.ch
wrote:
Alexander Konovalenko k...@kth.se 2009-02-01:
From: Daniel Roethlisberger dan...@roe.ch
...
Could it be the case that firefox-bin hangs in umtxn state?
you're right!
(Check using ps -laux instead of -aux)
http://daemon.nanophys.kth.se/~kono/ktrace_ff2.txt
http://daemon.nanophys.kth.se/~kono/ktrace_ff3.txt
These trace the wrong process: the wrapper shell script (sh).
The actual hanging process would be firefox-bin, not sh. Try
ktracing with child processes (-i).
ktrace -i showed last line:
firefox-bin CALL _umtx_op(0x65f8e0,0x8,0x1,0x65f8c0,0)
http://daemon.nanophys.kth.se/~kono/ktrace_ff3_ktrace-i.txt
Do you know which port/lib causing this hang on _umtx_op?
Unfortunately, no. I have a box with ports tree from around
mid-January on which I was unable to fix this problem. Native
firefox 2 and 3 hung in umtxn state. So I did pkg_delete -a, rm
-rf /usr/local, rebuilt and installed all ports: now the firefox3
build hangs in umtxn state while running a tool called shlibsign.
No idea how to fix this. I don't want to update the ports tree
to after the unpretty xorg-7.4 changes just yet.
I suspect the problem may be related to upgrading using
freebsd-update from 7.0 to 7.1, but that's just a wild guess
based on the problem appearing after the upgrade; I did make sure
no old leftover libraries or binaries were still lying around.
Have you read UPDATING yet about the libxcb upgrade?
Cheers,
-Garrett
$ fgrep xcb /usr/{ports,src}/UPDATING | wc -l
0
Note that this is a non-current ports tree from before the xorg
7.4 update (mid-January), which used to work fine in the exact
same configuration on RELENG_7_0, but broke on RELENG_7_1. This
is using the version of libxcb committed by miwi in September
2008. The libxcb shlib version bump really cannot be related to
this unless I am very much mistaken.
I upgraded many ports on my office amd64 machine (RELENG_7, 7.1-PRERELEASE
#1: Tue Sep 30 13:26:39 CEST 2008 ) and both firefox23 work now with no
problem. I have libxcb-1.1.93.
Just for the record, I have updated my trouble box
(7.1-RELEASE-p2, i386, GENERIC) to a current ports tree
(2009-02-10) by removing the old ports tree and using portsnap
fetch, extract; force-rebuilt all ports using portupgrade -af
(again!), then after all other ports tried to build firefox3, and
surprise surprise, the build hangs in umtxn state:
cd FreeBSD7.1_OPT.OBJ ; sh
/usr/ports/www/firefox3/work/mozilla/security/nss/cmd/shlibsign/./sign.sh
/usr/ports/www/firefox3/work/mozilla/dist \
/usr/ports/www/firefox3/work/mozilla/security/nss/cmd/shlibsign/FreeBSD7.1_OPT.OBJ
FreeBSD \
/usr/local/lib
/usr/ports/www/firefox3/work/mozilla/dist/lib/libsoftokn3.so
/usr/ports/www/firefox3/work/mozilla/security/nss/cmd/shlibsign/FreeBSD7.1_OPT.OBJ/shlibsign
-v -i /usr/ports/www/firefox3/work/mozilla/dist/lib/libsoftokn3.so
$ top
PID USERNAMETHR PRI NICE SIZERES STATETIME WCPU COMMAND
71155 root 1 960 6116K 2624K umtxn0:00 0.00% shlibsign
$ ps lwww 71155
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
0 71155 71150 0 96 0 6116 2624 umtxn I+p00:00,01
/usr/ports/www/firefox3/work/mozilla/security/nss/cmd/shlibsign/FreeBSD7.1_OPT.OBJ/shlibsign
-v -i /usr/ports/www/firefox3/work/mozilla/dist/lib/libsoftokn3.so
Any ideas how to further debug this? I'm out of ideas.
--
Daniel Roethlisberger
http://daniel.roe.ch/
___
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: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko k...@kth.se 2009-02-01: From: Daniel Roethlisberger dan...@roe.ch ... Could it be the case that firefox-bin hangs in umtxn state? you're right! (Check using ps -laux instead of -aux) http://daemon.nanophys.kth.se/~kono/ktrace_ff2.txt http://daemon.nanophys.kth.se/~kono/ktrace_ff3.txt These trace the wrong process: the wrapper shell script (sh). The actual hanging process would be firefox-bin, not sh. Try ktracing with child processes (-i). ktrace -i showed last line: firefox-bin CALL _umtx_op(0x65f8e0,0x8,0x1,0x65f8c0,0) http://daemon.nanophys.kth.se/~kono/ktrace_ff3_ktrace-i.txt Do you know which port/lib causing this hang on _umtx_op? Unfortunately, no. I have a box with ports tree from around mid-January on which I was unable to fix this problem. Native firefox 2 and 3 hung in umtxn state. So I did pkg_delete -a, rm -rf /usr/local, rebuilt and installed all ports: now the firefox3 build hangs in umtxn state while running a tool called shlibsign. No idea how to fix this. I don't want to update the ports tree to after the unpretty xorg-7.4 changes just yet. I suspect the problem may be related to upgrading using freebsd-update from 7.0 to 7.1, but that's just a wild guess based on the problem appearing after the upgrade; I did make sure no old leftover libraries or binaries were still lying around. -- Daniel Roethlisberger http://daniel.roe.ch/ ___ 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: firefox[2,3] will not start after recent ports upgrade
Garrett Cooper yanef...@gmail.com 2009-02-02:
On Mon, Feb 2, 2009 at 8:38 AM, Daniel Roethlisberger dan...@roe.ch wrote:
Alexander Konovalenko k...@kth.se 2009-02-01:
From: Daniel Roethlisberger dan...@roe.ch
...
Could it be the case that firefox-bin hangs in umtxn state?
you're right!
(Check using ps -laux instead of -aux)
http://daemon.nanophys.kth.se/~kono/ktrace_ff2.txt
http://daemon.nanophys.kth.se/~kono/ktrace_ff3.txt
These trace the wrong process: the wrapper shell script (sh).
The actual hanging process would be firefox-bin, not sh. Try
ktracing with child processes (-i).
ktrace -i showed last line:
firefox-bin CALL _umtx_op(0x65f8e0,0x8,0x1,0x65f8c0,0)
http://daemon.nanophys.kth.se/~kono/ktrace_ff3_ktrace-i.txt
Do you know which port/lib causing this hang on _umtx_op?
Unfortunately, no. I have a box with ports tree from around
mid-January on which I was unable to fix this problem. Native
firefox 2 and 3 hung in umtxn state. So I did pkg_delete -a, rm
-rf /usr/local, rebuilt and installed all ports: now the firefox3
build hangs in umtxn state while running a tool called shlibsign.
No idea how to fix this. I don't want to update the ports tree
to after the unpretty xorg-7.4 changes just yet.
I suspect the problem may be related to upgrading using
freebsd-update from 7.0 to 7.1, but that's just a wild guess
based on the problem appearing after the upgrade; I did make sure
no old leftover libraries or binaries were still lying around.
Have you read UPDATING yet about the libxcb upgrade?
Cheers,
-Garrett
$ fgrep xcb /usr/{ports,src}/UPDATING | wc -l
0
Note that this is a non-current ports tree from before the xorg
7.4 update (mid-January), which used to work fine in the exact
same configuration on RELENG_7_0, but broke on RELENG_7_1. This
is using the version of libxcb committed by miwi in September
2008. The libxcb shlib version bump really cannot be related to
this unless I am very much mistaken.
--
Daniel Roethlisberger
http://daniel.roe.ch/
___
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: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko k...@kth.se 2009-01-31: after recent port upgrade firefox2 and firefox3 do not work anymore. When I start any of them nothing happens, no error message or window appears. # ps -aux|grep firefox USER 36787 0.0 0.1 7060 1388 ?? I12:02PM 0:00.00 /bin/sh -c firefox3 USER 36788 0.0 0.1 7060 1468 ?? I12:02PM 0:00.00 /bin/sh /usr/local/bin/firefox3 USER 36792 0.0 0.1 7060 1508 ?? I12:02PM 0:00.00 /bin/sh /usr/local/lib/firefox3/run-mozilla.sh /usr/local/lib/firefox3/firefox-bin USER 36797 0.0 0.9 120932 17732 ?? I12:02PM 0:00.07 /usr/local/lib/firefox3/firefox-bin Seem something is hanging, so killall firefox-bin will clean memory quietly. Could it be the case that firefox-bin hangs in umtxn state? (Check using ps -laux instead of -aux) I have this effect on two amd64 machines (FreeBSD 7.1-PRERELEAS). One machine has almost all ports up to date, on another just few are updated. At the same time linux-firefox works fine. Recompilation/reinstall of firefox2,3 couple of times did not solved problem. I removed .mozilla/ from home folder hoping that there is a problem with profile, but still no luck. I tried to debug with ktrace but last wait4 (0x,0x7fffe1ac,WUNTRACED,0) call does not say much to me, please see ktraces for both firefox 2 3 respectively: http://daemon.nanophys.kth.se/~kono/ktrace_ff2.txt http://daemon.nanophys.kth.se/~kono/ktrace_ff3.txt These trace the wrong process: the wrapper shell script (sh). The actual hanging process would be firefox-bin, not sh. Try ktracing with child processes (-i). ... and list of installed ports (from machine with almost all ports updated): http://daemon.nanophys.kth.se/~kono/ports.list I wonder if only me got this trouble, any suggestions? -- Daniel Roethlisberger http://daniel.roe.ch/ ___ 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: p5-Crypt-OpenSSL-X509 on FreeBSD 4.9
Brian Woodruff w...@soundconcept.net 2009-01-23: I am trying to install this port on a FreeBSD 4.9-RELEASE machine as a requirement for /usr/ports/mail/sympa5. 4.9 is over half a decade old. Even 4.11 hasn't been supported by the ports tree for quite a while. Consider upgrading to 6.4 or 7.1 if you want to work off an up-to-date ports tree (which you most likely want). -- Daniel Roethlisberger http://daniel.roe.ch/ ___ 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: DragonFlyBSD mail agent
Michel Talon ta...@lpthe.jussieu.fr 2009-01-08: would it not be interesting to have the DragonFlyBSD mail agent in FreeBSD? [...] http://www.freebsd.org/cgi/query-pr.cgi?pr=130658 New port: mail/dma - The DragonFly Mail Agent. Includes an optional quick hack (ruby wrapper) to add -t sendmail option support, needed to make send-pr(1) happy with dma. For simplicity i have a tarball here: http://www.lpthe.jussieu.fr/~talon/dma.tgz Note that this dma.tgz is behind the latest DragonFly sources. -- Daniel Roethlisberger http://daniel.roe.ch/ ___ 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: rrdtool 1.3.3 and dejavu dependency
Guido Falsi m...@madpilot.net 2008-12-16: On Mon, Dec 15, 2008 at 06:38:12PM +0100, Daniel Roethlisberger wrote: Even as the submitter of the PR in question, I fully agree. This is a good starting point :P I read the PR but don't really see such effects.. I'm using mrtg and smokeping, with mrtg.cgi [1] and mailgraph.cgi. They all work fine, mailgraph at least seems to use the functionality described in the PR. Are we sure it isn't something else which is depending on dejavu? Yes, pretty much. Note that rrdtool can fall back to other fonts, such as Bitstream Vera, but if no fonts are found, using `rrdtool graph` or language bindings such as RRDs::graph will fail. I just used Tobi's tutorial [2] to verify this again. Can you try to reproduce this with no fonts installed under /usr/local/lib/X11/fonts and using the tutorial [2] as a test? If it works for you, can you try to find out where it takes the font from? I guess it might be possible to make `rrdtool graph` work without the full install of x11-fonts/dejavu and all it's dependencies by either creating a lightweight dejavu font port without X11, or by adding dejavu to the rrdtool port somehow. I'm all open to better ideas than the current run-time dependency on x11-fonts/dejavu. I kind of hoped that the maintainer would be able to find a better solution, but unfortunately, there was no reaction from the maintainer. I made a few experiments on a spare PC at work(this is an AMD64 8.0 on which I was testing ZFS, grat work to all the developers for that). I reverted your change on the machine, defined WITHOUT_X11 and made sure all rrdtools dependencies where configured to require the least x11 pieces(cairo requires disabling both xcb and glitz support). The machine had no ports installed. I ended up with the following ports installed: bdftopcf-1.0.1 Convert X font from BDF to PCF bitstream-vera-1.10_4 Bitstream Vera TrueType font collection cairo-1.6.4_3,1 Vector graphics library with cross-device output support encodings-1.0.2,1 X.Org Encoding fonts expat-2.0.1 XML 1.0 parser written in C font-bh-ttf-1.0.0 X.Org Bigelow Holmes TTF font font-misc-ethiopic-1.0.0 X.Org miscellaneous Ethiopic font font-misc-meltho-1.0.0_1 X.Org miscellaneous Meltho font font-util-1.0.1 Create an index of X font files in a directory fontcacheproto-0.1.2 Fontcache extension headers fontconfig-2.5.0,1 An XML-based font configuration API for X Windows fontsproto-2.0.2Fonts extension headers freetype2-2.3.7 A free and portable TrueType font rendering engine gamin-0.1.9_2 A file and directory monitoring system gettext-0.17_1 GNU gettext package gio-fam-backend-2.16.5 FAM backend for GLib's GIO library glib-2.16.5_1 Some useful routines of C programming (current stable versi gmake-3.81_3GNU version of 'make' utility icu-3.8.1_1 International Components for Unicode (from IBM) libXfont-1.3.1_3,1 X font libary libfontenc-1.0.4The fontenc Library libiconv-1.11_1 A character set conversion library libtool-1.5.26 Generic shared library support script libxml2-2.6.32_2XML parser library for GNOME mkfontdir-1.0.3_1 Create an index of X font files in a directory mkfontscale-1.0.3 Creates an index of scalable font files for X pango-1.20.5An open-source framework for the layout and rendering of i1 pcre-7.8Perl Compatible Regular Expressions library perl-5.8.8_1Practical Extraction and Report Language pixman-0.10.0_2 Low-level pixel manipulation library pkg-config-0.23_1 A utility to retrieve information about installed libraries png-1.2.33 Library for manipulating PNG images python25-2.5.2_3An interpreted object-oriented programming language rrdtool-1.3.3_2 Round Robin Database Tools xorg-fonts-truetype-7.3 X.Org TrueType fonts xproto-7.0.10_1 X11 protocol headers xtrans-1.0.4Abstract network code for X As you can see it already sucked in various things and some fonts. I tried the tutorial and it works flawlessly in such a setup. I think the trick is this port: bitstream-vera-1.10_4. If there were some way to install dejavu without sucking in all of libX11 it would be good too. could you make your tests without dejavu but with bitstream-vera and see if it works? My tests show that it falls back to bitstream-vera, but I haven't tested it on a clean system. I think what we need is something along the lines of depending on (dejavu OR bitstream-vera). Or even any TTF font. There are other possibilities, like making graphing support optional in rrdtool, or replacing the dependency with a pkg-message, asking the user to install some font if graphing is to be used. I see pango is depending on x11-fonts/xorg-fonts-truetype, which depends on some fonts pacjkages but not on libX11. Hope my feedback
Re: rrdtool 1.3.3 and dejavu dependency
Guido Falsi m...@madpilot.net 2008-12-15: I have noted that the dependency in the subject has been added to the rrdtool port. This has the unfortunate effect of sucking in a libX11 dependency(others too...) which was not before. Maybe I'm an extremist, but I don't like having X11 pieces on headless server machines, I really don't see a reson for that(it also triggers some more ports on depending on them, since the configures find them...This is annoying at least). Even as the submitter of the PR in question, I fully agree. I don't want to look demanding, but I'd like to spell my thought, if anybody cares to listen. What is the reson for this added dependency? rrdtool requires a suitable font for it's graphing features. It used to ship with dejavu, but since the update to 1.3.0 it relies on fonts installed on the system (which the dependency on dejavu is providing). I read the PR but don't really see such effects.. I'm using mrtg and smokeping, with mrtg.cgi [1] and mailgraph.cgi. They all work fine, mailgraph at least seems to use the functionality described in the PR. Are we sure it isn't something else which is depending on dejavu? Yes, pretty much. Note that rrdtool can fall back to other fonts, such as Bitstream Vera, but if no fonts are found, using `rrdtool graph` or language bindings such as RRDs::graph will fail. I just used Tobi's tutorial [2] to verify this again. Can you try to reproduce this with no fonts installed under /usr/local/lib/X11/fonts and using the tutorial [2] as a test? If it works for you, can you try to find out where it takes the font from? I guess it might be possible to make `rrdtool graph` work without the full install of x11-fonts/dejavu and all it's dependencies by either creating a lightweight dejavu font port without X11, or by adding dejavu to the rrdtool port somehow. I'm all open to better ideas than the current run-time dependency on x11-fonts/dejavu. I kind of hoped that the maintainer would be able to find a better solution, but unfortunately, there was no reaction from the maintainer. Thank you for listening. [1] http://www.fi.muni.cz/~kas/mrtg-rrd/ [2] http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html -- Daniel Roethlisberger http://daniel.roe.ch/ ___ 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: bsd-grep-20080725_1 -v flag busted...
Gábor Kövesdán [EMAIL PROTECTED] 2008-08-04: Chuck Swiger escribió: I'd just updated the BSD grep port to bsd-grep-20080725_1, but regrettably have noticed that many things using grep stopped working. For example, running GNU-style ./configure hangs here: configure: creating ./config.status load: 1.15 cmd: sh 72964 [runnable] 7.60u 95.78s 14% 2260k A trivial test case: % echo 'fee\nfi\nfoe\nfum' | ./grep -v fi % echo 'fee\nfi\nfoe\nfum' | /usr/bin/grep -v fi fee foe fum % ./grep --version grep (BSD grep) 2.5.1-FreeBSD Hello Chuck, thanks for your notes. It seems very strange to me, because GNU grep produces the same output for me. Apart from this, the -v flag was really broken, but I applied some fixes before updating the port and in the version, which I committer, I thought that the -v flag was compatible. Here is what I get at the moment: echo 'fee\nfi\nfoe\nfum' | ./grep -v fi echo 'fee\nfi\nfoe\nfum' | /usr/bin/grep -v fi /usr/bin/grep -V grep (GNU grep) 2.5.1-FreeBSD Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It's still the same, thus I don't understand how you could produce that output with GNU grep. I may be stating the obvious, but note that depending on your shell and it's configuration, echo might not translate \n to an actual newline. You might need to use `echo -e' instead of `echo' to get four lines printed instead of one. /bin/sh and bash need it, ksh doesn't, not sure about (t)csh. Also note that our /bin/echo doesn't know about -e and will never translate \n to a newline. The following should be more portable across different shells: printf 'fee\nfi\nfoe\nfum' | ./grep -v fi printf 'fee\nfi\nfoe\nfum' | /usr/bin/grep -v fi -- Daniel Roethlisberger http://daniel.roe.ch/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portmaster and BROKEN ports
Doug Barton [EMAIL PROTECTED] 2008-03-26: Willy Picard wrote: portupgrade simply ignores BROKEN ports during a portupgrade -a. I am not even asking about a similar behaviour for portmaster. I wanted just to ask if an option allows to do the same. If no such an option exists, I think that its addition to the functionality of portmaster may be worth considering. I think it's important for users to know when their ports go into a BROKEN state, so ignoring them is not an option. If a user actually wants to ignore a port that is BROKEN, the +IGNOREME mechanism is available, as you pointed out. Of course the user wants to be notified of all ports which cannot be upgraded for some reason (broken, marked BROKEN, removed/missing origin, etc.), but forcing the upgrade to abort because of a problem with a single port does not make sense. It means that portmaster can only be run successfully if all the installed ports are in a 100% upgradable state, which in my experience is basically almost never, except on production servers with only a few well-maintained ports installed. To keep a box current with portmaster, I have to manually mark each of the non-upgradable ports with +IGNOREME files after portmaster bails out, and restart portmaster. I will then have to periodically check back manually whether the problems went away in the meantime. This is unacceptable for me; too much manual intervention. I would very much prefer to have an option that tells portmaster to skip non-upgradable ports and those that depend on them, and notify me in form of a concise, greppable list after the portmaster run. This is actually the number one reason I switched back to portupgrade. Other than that, portmaster would be the tool of my choice. -Dan -- Daniel Roethlisberger [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: nmap-4.20
Ghirai [EMAIL PROTECTED] 2008-01-07: Just letting you know that nmap 4.52 is out, along with a new frontend. I was wondering when you'll add it to the ports tree. I am working on it. There are a number of big changes (new lua based nmap scripting engine, python based zenmap replacing nmapfe) requiring a lot of work on the nmap ports. -- Daniel Roethlisberger [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NMAP 4.20 Port broken? - PR ports/107478
Daniel Prinz [EMAIL PROTECTED] 2007-01-03: output.cc:746: error: incompatible types in assignment of `__va_list_tag*' to `__va_list_tag[1]' gmake: *** [output.o] Error 1 A previous 4.x fix was broken, enabling the 4.x workaround on all FreeBSD releases. I am correcting this error in PR ports/107478, which should fix build on AMD64. Cheers Dan -- Daniel Roethlisberger [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
