ospfd daemon (quagga-0.99.20_2) not work on freebsd 8.2#0 x64
zebra.log 2011/11/18 09:26:08 OSPF: ospf_recv_packet read length mismatch: ip_len is 64, but recvmsg returned 84 2011/11/18 09:26:15 OSPF: LSA[Refresh]:ospf_lsa_refresh_walker(): start 2011/11/18 09:26:15 OSPF: LSA[Refresh]: ospf_lsa_refresh_walker(): next index 192 2011/11/18 09:26:15 OSPF: LSA[Refresh]: ospf_lsa_refresh_walker(): refresh index 191 2011/11/18 09:26:15 OSPF: LSA[Refresh]: ospf_lsa_refresh_walker(): end 2011/11/18 09:26:15 OSPF: ISM[vlan464:192.168.224.131]: Timer (Hello timer expire) on /usr/ports/net/quagga/files/patch-ospfd__ospf_packet.c --- ospfd/ospf_packet.c.orig2011-09-29 18:59:32.0 +0600 +++ ospfd/ospf_packet.c 2011-11-12 12:02:58.0 +0600 @@ -2116,7 +2116,7 @@ ip_len = iph->ip_len; -#if !defined(GNU_LINUX) && (OpenBSD < 200311) +#if !defined(GNU_LINUX) && (OpenBSD < 200311) && (__FreeBSD_version >= 100) /* * Kernel network code touches incoming IP header parameters, * before protocol specific processing. can change +#if !defined(GNU_LINUX) && (OpenBSD < 200311) && (__FreeBSD_version >= 100) to +#if !defined(GNU_LINUX) && (OpenBSD < 200311) && (__FreeBSD_version < 100) Dmytro Burianov burya...@ukr.net icq: 118639660 skype: buryanov 380-50-343-74-70 ___ 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: Support for running xterm within a jail?
On Thu, Nov 17, 2011 at 11:44:12AM -0800, David Wolfskill wrote: > At $WORK, we have recently been reminded that xterm doesn't cope all > that well with being invoked in an environment that returns ENOENT on > xterm's attempt to open /dev/tty (in main.c). > > (The environment in question is a jailed 32-bit FreeBSD running on a > FreeBSD/amd64 host. Developers need to build in the jail; apparently > they also want to run things like emacs in the jails.) > > In looking at the xterm sources, I found that there's some code (near > main.c:3311 - 3329) to take evasive action if the attempt to open > /dev/tty fails. > > There's even a bit to effectively ignore ENOENT -- if __CYGWIN__ is > defined. > > But that's not our case -- and we don't want to be defining __CYGWIN__ > when we're building xterm for FreeBSD. > > Given that FreeBSD (with devfs) *can* return ENOENT to the attempt to > open /dev/tty, it isn't clear to me why that aprticular "error" > condition isn't ignored unconditionally (in a FreeBSD environment, at > least). > > Accordingly, I cobbled up a patch (attached), and a colleague has > verified that it avoids the issue we were encountering: it allows xterm > to run in the jail. > > Do you think the xterm folks would be receptive to either making the > "ignore ENOENT" unconditional or conditioning it on (say) "__CYGWIN_" > being defined or "__FREEBSD__" being defined? > > Failing that (or in the mean time) would you be receptive to a patch to > the FreeBSD xterm port to patch xterm in a way similar to the attached > patch? > > (I realize we're approaching 9.0-RELEASE; I'm not asking anyone to make > changes before that release date.) I am sure that the issue is a misconfiguration of the jail or attempt to start xterm from the process that has no control terminal. For jail misconfiguration, I mean either failure to properly mount devfs into the jail /dev, or a rule that hides /dev/tty from the jail. I use very similar configuration (32bit stable/8 jail on amd64 stable/9 kernel) and have no issues starting xterm. That said, you should diagnose the issue further, otherwise I think the patch is unneccessary. pgpl06o1Li6O7.pgp Description: PGP signature
ports/textproc/stardict3
Hello, The port (ports tree from CVS) ports/textproc/stardict3 ports/textproc/stardict3 PORTVERSION=3.0.3 MAINTAINER= m...@freebsd.org installs fine on 10-CURRENT, but the application just crahes or runs into a CPU loop; if it runs into CPU loop there is a core file of 'troff', i.e. it seems that it started for some man page reason the troff(1) and after this it loops; I went back for this port only to # cvs update -r RELEASE_8_2_0 which brings> PORTVERSION=3.0.1 PORTREVISION= 5 and this works just fine with all my dictionaries. I could go back to 3.0.3 and provide more details of the crash, but I can't debug or solve this on my own. Or should I file a bug report? HIH matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: "postfix-current" broken on amd64 platform
On Fri, 18 Nov 2011 03:48:49 -0800 per...@pluto.rain.com articulated: > Pav Lucistnik wrote: > > > The build jails are configured to have only IPv4 address on lo0, > > but the host have both IPv4 and IPv6 configured on its lo0. > > Even disregarding RFC3513, is an IPv6-enabled kernel without an IPv6 > address on lo0 a realistic configuration for a "real" FreeBSD system? > If not, I'd think it worthwhile to make pointyhat more realistic. > (Either way, it seems unobjectionable to improve the robustness of > postfix, making it more liberal in what it accepts.) > > > Changing the jail configuration is possible but if a reasonable > > workaround can be made in postfix-current port I'd prefer not to > > touch pointyhat configuration (unexpected consequences and all > > that...) > > It may be a bit late in the 9.0 release cycle to be messing with the > pointyhat configuration, but an adjustment might be considered after > 9.0-RELEASE is done. "postfix-current" -- 2.9.20111012,4 has been unmarked BROKEN on amd64 and builds without incident. I hope the actual current version, ie postfix-2.9-2017.tar.gz will be in the ports system soon. I would like to thank Sahil Tandon for his efforts in getting this valuable port problem corrected. Interestingly enough, and I cannot prove it to anyone's satisfaction, but I did mention to a colleague that if I posted on the ports forum regrading this problem and could get Wietse involved, the problem would be corrected within 24 hours. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ 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: BIND 9 question
On Thu, Nov 17, 2011 at 10:20 PM, Doug Barton wrote: > The ports, 10-current, stable/8 and stable/7 were all updated yesterday > shortly after ISC publicly released the code. But not releng/*? -- chs, ___ 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: BIND 9 question
On 18/11/2011 15:48, Christer Solskogen wrote: > On Thu, Nov 17, 2011 at 10:20 PM, Doug Barton wrote: >> The ports, 10-current, stable/8 and stable/7 were all updated yesterday >> shortly after ISC publicly released the code. > > But not releng/*? http://lists.freebsd.org/pipermail/freebsd-security/2011-November/006081.html HTH, Luchesar ___ 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: Support for running xterm within a jail?
On Fri, Nov 18, 2011 at 11:11:46AM +0200, Kostik Belousov wrote: > ... > I am sure that the issue is a misconfiguration of the jail or attempt to > start xterm from the process that has no control terminal. For jail > misconfiguration, I mean either failure to properly mount devfs into > the jail /dev, or a rule that hides /dev/tty from the jail. > > I use very similar configuration (32bit stable/8 jail on amd64 stable/9 > kernel) and have no issues starting xterm. > > That said, you should diagnose the issue further, otherwise I think the > patch is unneccessary. I appreciate that, but admit that I'm not especially familiar with working with jails. i also admit that the use case is one that strikes me as perverse, in that I would expect someone to run an xterm locally. In the case in question, the folks encountering the problem do not have local X servers; they use MS Windows (with which I am almost completely unfamiliar -- and in which I have no interest) on their desktops. As I type, I am logged in to my desktop machine at work remotely (from home, in another xterm). From that xterm, I can run (e.g.): dwolf-bsd(8.2-S)[10] ssh -Yfn dwolf-bsd xterm -T testing and get a new xterm up, running on my desktop with DISPLAY set to a value that will allow me to run other X clients from it. This is the functionality that is wanted. If, instead, I do something similar to one of our older build machines: dwolf-bsd(8.2-S)[11] ssh -Yfn dwolf.svl-lb xterm -T testing I get a similar result -- an xterm running on the build machine with DISPLAY set so I could run other X clients (e.g., emacs). If I do the same for one of the jails: dwolf-bsd(8.2-S)[12] ssh -Yfn svl-jail xterm -T testing dwolf-bsd(8.2-S)[13] xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty If I use ssh & login to the jail: dwolf-bsd(8.2-S)[13] ssh -Y svl-jail ... svl-jail(7.1-R)[1] I can manually fire off xterm because /dev/tty exists and I am already running an X server locally: svl-jail(7.1-R)[1] ls -lTio /dev/tty 135 crw--w 1 dwolf tty - 0, 135 Nov 18 05:59:58 2011 /dev/tty But if I terminate that connection, then try to perform that "ls" command (as the only thing I want ssh to do for me), that only works if I include the "-t" on the ssh invocation. So if I try adding -t when I try to start the remote xterm, I see: dwolf-bsd(8.2-S)[17] ssh -Ytfn svl-jail xterm -T testing Pseudo-terminal will not be allocated because stdin is not a terminal. dwolf-bsd(8.2-S)[18] xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty So I think it's apparent that we don't have a case where /dev/tty is never available, but I don't know how to make it show up for the intended use case. And there already exists code in xterm to ignore the ENOENT case for CygWin, so it seems that there really isn't much of a reason to treat ENOENT on /dev/tty as a fatal error for xterm invocation. Further, applying the patch in question does provide the desired functionality. If you (or anyone else) could provide some clues as to where to direct my attention, that would be wonderful. (In the mean time, upstream xterm developer has agreed to make the change for xterm-277, and ehaupt@ has updated the x11/xterm port to include the patch, pending xterm-277.) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp3eGqUU8zOB.pgp Description: PGP signature
Re: Support for running xterm within a jail?
On Fri, Nov 18, 2011 at 06:13:20AM -0800, David Wolfskill wrote: > On Fri, Nov 18, 2011 at 11:11:46AM +0200, Kostik Belousov wrote: > > ... > > I am sure that the issue is a misconfiguration of the jail or attempt to > > start xterm from the process that has no control terminal. For jail > > misconfiguration, I mean either failure to properly mount devfs into > > the jail /dev, or a rule that hides /dev/tty from the jail. > > > > I use very similar configuration (32bit stable/8 jail on amd64 stable/9 > > kernel) and have no issues starting xterm. > > > > That said, you should diagnose the issue further, otherwise I think the > > patch is unneccessary. > > I appreciate that, but admit that I'm not especially familiar with > working with jails. i also admit that the use case is one that > strikes me as perverse, in that I would expect someone to run an > xterm locally. > > In the case in question, the folks encountering the problem do not have > local X servers; they use MS Windows (with which I am almost completely > unfamiliar -- and in which I have no interest) on their desktops. > > As I type, I am logged in to my desktop machine at work remotely (from > home, in another xterm). From that xterm, I can run (e.g.): > > dwolf-bsd(8.2-S)[10] ssh -Yfn dwolf-bsd xterm -T testing > > and get a new xterm up, running on my desktop with DISPLAY set to a > value that will allow me to run other X clients from it. This is the > functionality that is wanted. > > > If, instead, I do something similar to one of our older build machines: > > dwolf-bsd(8.2-S)[11] ssh -Yfn dwolf.svl-lb xterm -T testing > > I get a similar result -- an xterm running on the build machine with > DISPLAY set so I could run other X clients (e.g., emacs). > > > If I do the same for one of the jails: > > dwolf-bsd(8.2-S)[12] ssh -Yfn svl-jail xterm -T testing > dwolf-bsd(8.2-S)[13] xterm: Error 14, errno 2: No such file or directory > Reason: spawn: open() failed on /dev/tty > > If I use ssh & login to the jail: > > dwolf-bsd(8.2-S)[13] ssh -Y svl-jail > ... > svl-jail(7.1-R)[1] > > I can manually fire off xterm because /dev/tty exists and I am already > running an X server locally: > > svl-jail(7.1-R)[1] ls -lTio /dev/tty > 135 crw--w 1 dwolf tty - 0, 135 Nov 18 05:59:58 2011 /dev/tty > > > But if I terminate that connection, then try to perform that "ls" > command (as the only thing I want ssh to do for me), that only works if > I include the "-t" on the ssh invocation. > > So if I try adding -t when I try to start the remote xterm, I see: > > dwolf-bsd(8.2-S)[17] ssh -Ytfn svl-jail xterm -T testing > Pseudo-terminal will not be allocated because stdin is not a terminal. > dwolf-bsd(8.2-S)[18] xterm: Error 14, errno 2: No such file or directory > Reason: spawn: open() failed on /dev/tty > > > So I think it's apparent that we don't have a case where /dev/tty is > never available, but I don't know how to make it show up for the > intended use case. The ssh is explicitely saying you what is going on. Did you note the 'Pseudo-terminal will not be allocated because stdin is not a terminal.' line ? It telling that the control terminal will not be allocated. As a consequence, /dev/tty cannot be opened. This has nothing to do with jail. % ssh -Ytfn localhost tty Pseudo-terminal will not be allocated because stdin is not a terminal. not a tty % > > And there already exists code in xterm to ignore the ENOENT case for > CygWin, so it seems that there really isn't much of a reason to treat > ENOENT on /dev/tty as a fatal error for xterm invocation. Further, > applying the patch in question does provide the desired functionality. > > If you (or anyone else) could provide some clues as to where to direct > my attention, that would be wonderful. > > (In the mean time, upstream xterm developer has agreed to make the > change for xterm-277, and ehaupt@ has updated the x11/xterm port to > include the patch, pending xterm-277.) > > Peace, > david > -- > David H. Wolfskillda...@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpSzmiKjyXvV.pgp Description: PGP signature
Makefile Issue
Hi everyone,
Can anyone enlighten me as to why this following make fragment doesn't
work? It falls through to .else.
PKGNAMESUFFIX= -devel
.if defined(PKGNAMESUFFIX) && !empty(PKGNAMESUFFIX)
MASTER_SITES= http://www.fwbuilder.org/nightly_builds/fwbuilder-5.0/build-
${BUILD}/
PORTVERSION=${DISTVERSION}.b${BUILD}
.else
MASTER_SITES= SF/${PORTNAME}/Current_Packages/${PORTVERSION}
DISTVERSIONSUFFIX= .${BUILD}
.endif
If I replace PKGNAMESUFFIX= -devel and the .if defined... with
PKGNAMESUFFIX= "-devel"
.if defined(PKGNAMESUFFIX) && ${PKGNAMESUFFIX} == "-devel"
it works.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
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: "postfix-current" broken on amd64 platform
On 18/11/2011 11:48, per...@pluto.rain.com wrote: Pav Lucistnik wrote: The build jails are configured to have only IPv4 address on lo0, but the host have both IPv4 and IPv6 configured on its lo0. Even disregarding RFC3513, is an IPv6-enabled kernel without an IPv6 address on lo0 a realistic configuration for a "real" FreeBSD system? If not, I'd think it worthwhile to make pointyhat more realistic. (Either way, it seems unobjectionable to improve the robustness of postfix, making it more liberal in what it accepts.) FreeBSD jails only expose the IP addresses they are configured to use. So if you have an IPv6 enabled host (which is the default) with jails that are configured with only IPv4 addresses, then yes, it is very realistic. Furthermore, by default, jails don't have any v4 addresses assigned to the loopback interface - 127.0.0.1 and inaddr_loopback are automagically aliased to the primary v4 IP assigned to the jail. Jase. ___ 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: ports/162665: [patch] [update] graphics/pinpoint to 0.1.4
Synopsis: [patch] [update] graphics/pinpoint to 0.1.4 Responsible-Changed-From-To: glebius->freebsd-ports Responsible-Changed-By: glebius Responsible-Changed-When: Fri Nov 18 19:01:15 UTC 2011 Responsible-Changed-Why: Back to ports. http://www.freebsd.org/cgi/query-pr.cgi?pr=162665 ___ 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: ports/162665: [patch] [update] graphics/pinpoint to 0.1.4
Synopsis: [patch] [update] graphics/pinpoint to 0.1.4 Responsible-Changed-From-To: freebsd-ports->miwi Responsible-Changed-By: miwi Responsible-Changed-When: Fri Nov 18 19:18:19 UTC 2011 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=162665 ___ 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: BIND 9 question
On 11/18/2011 06:05, Luchesar V. ILIEV wrote: > On 18/11/2011 15:48, Christer Solskogen wrote: >> On Thu, Nov 17, 2011 at 10:20 PM, Doug Barton wrote: >>> The ports, 10-current, stable/8 and stable/7 were all updated yesterday >>> shortly after ISC publicly released the code. >> >> But not releng/*? I cannot emphasize this point highly enough: The BIND in the base is intended primarily for use as a local resolver. If you are doing serious, mission-critical work with BIND you should be using a port, preferably dns/bind98. The ability to quickly update in the event of a security issue is one reason, another is the ability to use the same version of BIND across your network regardless of the underlying version of FreeBSD. If you are in any way worried that your flavor of FreeBSD isn't being upgraded soon enough, you are (by definition) in the category that should be using BIND from ports instead. hth, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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"
