Re: FreeBSD Port: nmap-4.20_1
Pratt, Benjamin E. <[EMAIL PROTECTED]> 2008-01-04: > I was wondering if you had any plans to update the FreeBSD port to > these later versions of Nmap. Of course I have :-) Other priorities got in the way, will update the port this weekend. -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: 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: 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: rrdtool 1.3.3 and dejavu dependency
Guido Falsi 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: rrdtool 1.3.3 and dejavu dependency
Guido Falsi 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 t
Re: DragonFlyBSD mail agent
Michel Talon 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: p5-Crypt-OpenSSL-X509 on FreeBSD 4.9
Brian Woodruff 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: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko 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: firefox[2,3] will not start after recent ports upgrade
Alexander Konovalenko 2009-02-01: > > From: Daniel Roethlisberger > >... > > 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 2009-02-02:
> On Mon, Feb 2, 2009 at 8:38 AM, Daniel Roethlisberger wrote:
> > Alexander Konovalenko 2009-02-01:
> >> > From: Daniel Roethlisberger
> >> >...
> >> > 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 2009-02-03:
> On Tuesday 03 February 2009, Daniel Roethlisberger wrote:
> > Garrett Cooper 2009-02-02:
> > > On Mon, Feb 2, 2009 at 8:38 AM, Daniel Roethlisberger
> wrote:
> > > > Alexander Konovalenko 2009-02-01:
> > > >> > From: Daniel Roethlisberger
> > > >> >...
> > > >> > 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 firefox2&3 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: Call for potential ports maintainers
Thomas Abthorpe 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: nmap broken on current
Peter Pentchev 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 ? :) 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(
Dangling extern "C" in pcap.h (was: Re: nmap broken on current)
Daniel Roethlisberger 2009-03-30: > Peter Pentchev 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 ? :) 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: conflic
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]"
