Nabble - netbsd-tech

re: native xorg fails to build on sgimips latest netbsd-5 co

2009-12-06T12:42:56Z

includes ===> external/mit/xorg/include/xineramaproto
nbmake: don't know how to make Xinerama.h. Stop

nbmake: stopped in /root/netbsd/netbsd-5/src/external/mit/xorg/include/xineramaproto

*** Failed target: includes-xineramaproto
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="external/mit/xorg
/include/"; real="/root/netbsd/netbsd-5/src/external/mit/xorg/include" ;; *) this="external/mit/xorg/include/${dir}/"; real="/root/netbsd/netbsd-5/src/external
/mit/xorg/include/${dir}" ;; esac; show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" && /root/netbsd/netbsd-5/src/../build/tooldi
r.NetBSD-5.99.15-i386/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget xineramaproto includes
*** Error code 2

is your src/external/mit/xorg/include/xineramaproto/Makefile corrupt or
out of date some how? it should not be trying to install Xinerama.h.
that gets installed from src/external/mit/xorg/lib/libXinerama/Makefile.

.mrg.

From forum: tech-x11

Re: Multiseat

2009-12-06T09:58:23Z

On Fri, Dec 04, 2009 at 12:20:07PM +0100, Helge Muehlmeier wrote:

> I put the busid's in my xorg.conf- file and tried to test the configuration. But I get the following error:
>
> X.Org X Server 1.6.3
> Release Date: 2009-7-7
> X Protocol Version 11, Revision 0
> Build Operating System: NetBSD/amd64 -
> Current Operating System: NetBSD beowulf.homenet.home 5.0_STABLE NetBSD 5.0_STABLE (GENERIC) #0: Fri Oct 23 15:25:3
> 2 CEST 2009 root@...:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
> Build Date: 09 July 2009 12:14:03AM
>
> Before reporting problems, check http://wiki.X.Org
> to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 3 13:02:04 2009
> (==) Using config file: "/etc/X11/xorg.conf"
> (++) ServerLayout "Multi0"
> (**) |-->Screen "Screen0" (0)
> (**) | |-->Monitor "Samsung"
> (**) | |-->Device "nvidia"
> (**) |-->Input Device "Mouse0"
> (**) |-->Input Device "Keyboard0"
> ...
> ...
> (II) Primary Device is: PCI 01@01:00:0
> (EE) No devices detected.
>
> Fatal server error:
> no screens found

I installed a new i386 5.0.1 and tried it again... Now it works... I can start both seats...

My problems now are keyboard and mice... If I have started a seat I can turn the mouse and open a xterm. But if I try to insert some code with a keyboard I get waste and it seems, that the input don't stop. I can't exit from X... Only if I remotly login and kill all processes or reboot.

Does somebody knows howto config them to get multiseat working?

Greetings,
Helge

From forum: tech-x11

Re: SSL renegociation vulnerability

2009-12-06T09:39:28Z

On Sun, Dec 06, 2009 at 11:00:55AM -0500, Christos Zoulas wrote:

> On Dec 5, 8:17pm, snj@... (Soren Jacobsen) wrote:
> -- Subject: Re: SSL renegociation vulnerability
>
> | On Dec 5, 2009, at 9:10 AM, Christos Zoulas wrote:
> |
> | > I'll import head then.
> |
> | We still need to figure out what to do for the release branches.
>
> Apply the patch from FreeBSD to disable renegotiation?

What a mess. The problem is that the head of the OpenSSL-0.9.8 branch
in their CVS looks like OpenSSL-current API-wise, while the released
0.9.8l (which wasn't even generated from their CVS -- it has residue
of hand-patching in the release tar file!) is API and ABI incompatible.

I cannot seem to get an answer from them as to whether they intend to
fix the API botch in a later 0.9.8 release. It's exasperating.

What I would actually be inclined to do is:

1) Bring the release branches to 0.9.8-stable from a recent
CVS snapshot.

2) Try to figure out a way to implement the 0.9.8l renegotiation-
control API but adjusted such that it doesn't do anything. This
is dangerous though if they reuse the relevant flag bit in a
later otherwise ABI-compatible release.

I do not understand why they changed the renegotiation control from a
"FLAG" to an "OP" on the SSL * object but they did and that is why we
are in this mess. I wish I could get an explanation of that too other than
"using a flag was a bad idea".

Maybe if someone else asks "on behalf of NetBSD"...

Thor

From forum: tech-security

Re: libgcc

2009-12-06T08:27:42Z

> it is not ever going to be safe to remove these entirely from libc.
> consider the following case:
>
> - build a binary on netbsd-5 that depends upon these symbols
>
> - run this binary on a netbsd-6 system that only has these
> symbols in libgcc, and they won't be resolved.
>
>
> i'd guess that you need to leave them in libc.so as a weak symbol
> for all eternity, or at least until we bump libc.so.

Thanks for clarification. I'll check if __weak_alias() works once things
settle down. (There seem strong oppositions against adding more weak symbols,
though.)

We should consider the static library case too.

Masao

--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

From forum: tech-toolchain

Re: SSL renegociation vulnerability

2009-12-06T08:00:55Z

On Dec 5, 8:17pm, snj@... (Soren Jacobsen) wrote:
-- Subject: Re: SSL renegociation vulnerability

| On Dec 5, 2009, at 9:10 AM, Christos Zoulas wrote:
|
| > I'll import head then.
|
| We still need to figure out what to do for the release branches.

Apply the patch from FreeBSD to disable renegotiation?

christos

From forum: tech-security

Re: WD_QUIRK_FORCE_LBA48

2009-12-06T07:55:50Z

On Sat, Dec 05, 2009 at 04:27:56PM -0500, der Mouse wrote:
> >> But, really, it's not clear to me that it's worth doing non-LBA48
> >> transfers at all on drives capable of LBA48 [...]
> > the problem is not drives, the problem is controllers. Some IDE
> > controllers don't support LBA48, but I don't have a list of those.
> > The only way to know is to try ...
>
> What behaviour do they produce at present when connected to a drive
> >128G? Wraparound at the 128G point? Errors past there?

probably controller-dependant. But they're useable up to 128G.

>
> I would not suggest doing this unless (a) the drive claims to be
> LBA48-capable and (b) the drive claims to be at least 0x10000000
> sectors long.

Make that 0x10000001. 128Gb drives don't need LBA48 to access the last
sector. But then you'd break actually-working setups.

--
Manuel Bouyer <bouyer@...>
NetBSD: 26 ans d'experience feront toujours la difference
--

From forum: tech-kern

SUBST_SED and newline?

2009-12-06T06:18:16Z

Is it possible to insert a newline into a file using SUBST_SED?

--
Georg Schwarz http://home.pages.de/~schwarz/
georg.schwarz@... +49 151 11559652

From forum: tech-pkg

Re: native xorg fails to build on sgimips latest netbsd-5 co

2009-12-06T06:14:27Z

On 6 Dec 2009, at 02:31, Michael wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> On Dec 5, 2009, at 3:18 PM, Mark Kirby wrote:
>
>> I am building current xsrc against the latest from the netbsd-5 branch for sgimips. Every time i try it is failing with errors regarding xinerama.h
>
> Did you clean up OBJDIR and so on?
> This should Just Work(tm) - the autobuilds on releng.netbsd.org don't show any error.

I have removed my OBJDIR and started again same error.

Just a pointer the build system is 5.99.15 i386 it is cross compiling sgimips from the netbsd-5 branch and trying to build current xsrc against that.

Mark

# install /root/netbsd/netbsd-5/src/../build/destdir.sgimips/usr/X11R7/include/X11/extensions/syncstr.h
/root/netbsd/netbsd-5/src/../build/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/syncstr.h /root/netbsd/netbsd-5/src/../build/destdir.sgimips/usr/X11R7/include/X11/extensions/syncstr.h
# install /root/netbsd/netbsd-5/src/../build/destdir.sgimips/usr/X11R7/include/X11/extensions/xtestext1.h
/root/netbsd/netbsd-5/src/../build/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/xtestext1.h /root/netbsd/netbsd-5/src/../build/destdir.sgimips/usr/X11R7/include/X11/extensions/xtestext1.h
# install /root/netbsd/netbsd-5/src/../build/destdir.sgimips/usr/X11R7/include/X11/extensions/xteststr.h
/root/netbsd/netbsd-5/src/../build/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/xteststr.h /root/netbsd/netbsd-5/src/../build/destdir.sgimips/usr/X11R7/include/X11/extensions/xteststr.h
includes ===> external/mit/xorg/include/evieext
includes ===> external/mit/xorg/include/xineramaproto
nbmake: don't know how to make Xinerama.h. Stop

nbmake: stopped in /root/netbsd/netbsd-5/src/external/mit/xorg/include/xineramaproto

*** Failed target: includes-xineramaproto
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="external/mit/xorg/include/"; real="/root/netbsd/netbsd-5/src/external/mit/xorg/include" ;; *) this="external/mit/xorg/include/${dir}/"; real="/root/netbsd/netbsd-5/src/external/mit/xorg/include/${dir}" ;; esac; show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" && /root/netbsd/netbsd-5/src/../build/tooldir.NetBSD-5.99.15-i386/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget xineramaproto includes
*** Error code 2

From forum: tech-x11

Re: quad funcs in libc on LP64 platforms

2009-12-05T21:46:53Z

> This is surely meant that "don't compile quad funcs on LP64 platforms", right?
> Is it too late to remove quad funcs in x86_64 libc?

Never mind. Now I see that those archs provide optimized functions.

Masao

--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

From forum: tech-userlevel

Re: SSL renegociation vulnerability

2009-12-05T20:17:55Z

On Dec 5, 2009, at 9:10 AM, Christos Zoulas wrote:

> I'll import head then.

We still need to figure out what to do for the release branches.

From forum: tech-security

quad funcs in libc on LP64 platforms

2009-12-05T20:17:11Z

We have this in lib/libc/Makefile:

75 .if (${MACHINE_ARCH} != "alpha") && (${MACHINE_ARCH} != "sparc64")
76 .include "${.CURDIR}/quad/Makefile.inc"
77 .endif

This is surely meant that "don't compile quad funcs on LP64 platforms", right?
Is it too late to remove quad funcs in x86_64 libc?

Masao

--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

From forum: tech-userlevel

Re: native xorg fails to build on sgimips latest netbsd-5 co

2009-12-05T18:31:20Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Dec 5, 2009, at 3:18 PM, Mark Kirby wrote:

> I am building current xsrc against the latest from the netbsd-5
> branch for sgimips. Every time i try it is failing with errors
> regarding xinerama.h

Did you clean up OBJDIR and so on?
This should Just Work(tm) - the autobuilds on releng.netbsd.org don't
show any error.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSxsXeMpnzkX8Yg2nAQL6gwf8DFCkT0JsNSAA3yPwXOVC7hiVE5Xz5DtF
ArefRTVABAFgeeG4+H/99e2IKTDMcdyRJ21T1nKihBnp6XXSBfi7ewId1NqU5wmB
ZHXZB28ue5j1bssMi9stq/EJ4+VXX9qf5r7l3BNIS/5NyQz9nOgKD7vz5Tz/dC6z
0lL2gETzgOiYjewnzOoLbQVjdS6hMUmpRUg8r/0yMCZKJh6b65sxdUw/RymlEBWG
2HuhjjoEXRoK6O5a/VNTRhWKFVmjdBlFBVs+/0u0f3EApgyBfNP5C2g+HcE0bAiZ
n6rV1wmPD4rEClVzON06QSsY73k4W6Y9IdktflBvQKaPEcQ3tnLCiQ==
=oJqi
-----END PGP SIGNATURE-----

From forum: tech-x11

daily pkgsrc CVS update output

2009-12-05T17:11:01Z

Updating pkgsrc tree:
? pkgsrc/INDEX
? pkgsrc/README-IPv6.html
? pkgsrc/README-all.html
P pkgsrc/cross/mipsEEel-netbsd/Makefile
P pkgsrc/devel/Makefile
U pkgsrc/devel/p5-Devel-Refactor/DESCR
U pkgsrc/devel/p5-Devel-Refactor/Makefile
U pkgsrc/devel/p5-Devel-Refactor/distinfo
U pkgsrc/devel/p5-Format-Human-Bytes/DESCR
U pkgsrc/devel/p5-Format-Human-Bytes/Makefile
U pkgsrc/devel/p5-Format-Human-Bytes/distinfo
U pkgsrc/devel/p5-Locale-Msgfmt/DESCR
U pkgsrc/devel/p5-Locale-Msgfmt/Makefile
U pkgsrc/devel/p5-Locale-Msgfmt/distinfo
P pkgsrc/doc/CHANGES-2009
P pkgsrc/games/cgoban/Makefile
U pkgsrc/games/cgoban/distinfo
P pkgsrc/games/cgoban/patches/patch-aa
P pkgsrc/games/cgoban-java/Makefile
U pkgsrc/games/cgoban-java/distinfo
P pkgsrc/lang/fort77/Makefile
P pkgsrc/lang/fort77/distinfo
cvs update: pkgsrc/lang/fort77/patches/patch-fort77 is no longer in the repository
P pkgsrc/misc/openoffice2-bin/Makefile
U pkgsrc/misc/openoffice2-bin/distinfo
P pkgsrc/net/lftp/distinfo
P pkgsrc/net/lftp/patches/patch-aa
P pkgsrc/shells/mksh/Makefile
U pkgsrc/shells/mksh/distinfo
P pkgsrc/sysutils/checkperms/Makefile
U pkgsrc/sysutils/checkperms/distinfo

Killing core files:

Updating pkgsrc-2009Q3 pkgsrc tree (/ftp/pub/pkgsrc/pkgsrc-2009Q3):
P pkgsrc/databases/phpmyadmin/Makefile
U pkgsrc/databases/phpmyadmin/distinfo
U pkgsrc/doc/CHANGES-pkgsrc-2009Q3

From forum: tech-pkg

Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

2009-12-05T16:30:03Z

At Sat, 5 Dec 2009 13:32:50 +0100, Michael van Elst <mlelstv@...> wrote:
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

>
> On Sat, Dec 05, 2009 at 12:43:54PM +0100, Ingolf Steinbach wrote:
>
> > According to POSIX, getaddrinfo() "shall return a set of socket
> > addresses and associated information to be used in creating a socket
> > with which to address the specified service." What is the use of
> > delivering socket addresses which will certainly fail later when used
> > as intended by this specification?
>
> You don't know how the adresses are used and, at the time of the
> getaddrinfo() call,

The system actually does know how they CANNOT be used though.

> > b) avoid run-time errors by having getaddrinfo() deliver only v4
> > addresses on systems which do not support v6 (unless, of course, the
> > user explicitly requests v6 addresses)
>
> See my answer to kre, that dependency isn't necessarily valid and

I can't find your answer to kre in this thread (though that may be
because this thread is crossing lists without consistently doing so).

I don't agree either -- the dependency _is_ valid. (remember we're
discussing the _default_ behaviour, not an explicit search for an
address related to a given family)

--
Greg A. Woods
Planix, Inc.

<woods@...> +1 416 218 0099 http://www.planix.com/

attachment0 (193 bytes) Download Attachment

From forum: tech-net

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T13:27:56Z

>> But, really, it's not clear to me that it's worth doing non-LBA48
>> transfers at all on drives capable of LBA48 [...]
> the problem is not drives, the problem is controllers. Some IDE
> controllers don't support LBA48, but I don't have a list of those.
> The only way to know is to try ...

What behaviour do they produce at present when connected to a drive
>128G? Wraparound at the 128G point? Errors past there?

I would not suggest doing this unless (a) the drive claims to be
LBA48-capable and (b) the drive claims to be at least 0x10000000
sectors long. If the answer to the above is "errors", then I'd just
retry non-LBA48 if the first LBA48 access errors, and, if that works,
then (a) log it, (b) mark it as no-LBA48, and (c) artificially cap that
drive's capacity at 128G.

Ideally, I'd suggest that controller drivers export some kind of
"LBA48-capable" flag, but getting there from here would be somewhat
nontrivial.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@...
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

From forum: tech-kern

Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

2009-12-05T13:18:31Z

> [B]ut if you say "just give me something I can use" without caring
> what protocol, I don't think it would be unreasonable for
> getaddrinfo() to simply return only addresses that have at least the
> potential to work - and I don't think applications should need to set
> some flag to tell getaddrinfo() not to return useless trash,

The problem is, what constitutes "useless trash"?

> if anything, for the one in a hundred application that isn't a
> diagnostic tool (which wouldn't be using getaddrinfo()),

Where do you get this idea that diagnostic tools don't use
getaddrinfo()? Especially when trying to diagnose name resolution
issues, one of the things to do is to try the usual interface.

> doesn't care what address type, but wants everything available, even
> if it cannot possibly work,

"Cannot possibly work" is impossible for software to tell.

> a flag to indicate that would make more sense (you'd really have to
> hunt to find an application that you'd need to modify to set it).

I wouldn't have to hunt at all; I have an example at ready hand.

One of my programs (I call it addr) simply prints out the list of
addresses a name resolves to. There is no implication that any of
those addresses are going to be used to aim network traffic; they
might, for example, be going into a router blocking list. And there
most certainly is no implication that whatever use is to be made of the
addresses will be done on the machine where addr is running. As such,
software - addr, getaddrinfo(), whatever - is not in a position to tell
what might or might not be useful to return.

I use addr regularly. I wrote it because I couldn't find any other
application that could turn a name into a list of addresses without a
lot of extracting addresses from undocumented (and usually non-frozen
and thus liable to breakage upon upgrade) output formats. I initially
meant it for use in shell scripts, but most of the times I run it turn
out to be command-line queries.

>> getaddrinfo() is only used by programs that can handle IPv6
> Typically yes, but not necessarily, [...], getaddrinfo() is a much
> nicer interface than gethostbyname().

In many respects. It certainly has its problems, perhaps most notably
the inconvenience of initializing hints structures (I can't see any
reason for demanding that the unused fields be set to fixed values,
and, since some of them are pointers, a wholesale bzero() is not
suitable). But most of the problems I run into when using it are not
ones that it is in a position to solve.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@...
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

From forum: tech-net

native xorg fails to build on sgimips latest netbsd-5 co

2009-12-05T12:18:03Z

Hi,

I am building current xsrc against the latest from the netbsd-5 branch for sgimips. Every time i try it is failing with errors regarding xinerama.h

--- includes-xextproto ---
# install /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XEVI.h
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/XEVI.h /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XEVI.h
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XLbx.h ---
--- includes-resourceproto ---
--- includes-xproto ---
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/nbsed 's/@USE_FDS_BITS@/fds_bits/' < /root/netbsd/netbsd-5/src/../xsrc/external/mit/xproto/dist/Xpoll.h.in > Xpoll.h
--- includes-recordproto ---
--- includes-xextproto ---
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XShm.h ---
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XTest.h ---
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XLbx.h ---
# install /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XLbx.h
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/XLbx.h /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XLbx.h
--- includes-resourceproto ---
includes ===> external/mit/xorg/include/resourceproto
--- includes-xextproto ---
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XShm.h ---
# install /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XShm.h
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/XShm.h /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XShm.h
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XTest.h ---
# install /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XTest.h
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/XTest.h /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/XTest.h
--- includes-recordproto ---
includes ===> external/mit/xorg/include/recordproto
--- includes-xextproto ---
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/Xag.h ---
--- includes-videoproto ---
--- includes-xproto ---
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/Xfuncproto.h ---
# install /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/Xfuncproto.h
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 Xfuncproto.h /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/Xfuncproto.h
--- /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/Xpoll.h ---
--- includes-xextproto ---
# install /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/Xag.h
/root/netbsd/netbsd-5/src/tooldir.NetBSD-5.99.15-i386/bin/mipseb--netbsd-install -N /root/netbsd/netbsd-5/src/etc -c -p -r -c -o root -g wheel -m 444 /root/netbsd/netbsd-5/src/../xsrc/external/mit/xextproto/dist/Xag.h /root/netbsd/netbsd-5/src/destdir.sgimips/usr/X11R7/include/X11/extensions/Xag.h
--- includes-videoproto ---
includes ===> external/mit/xorg/include/videoproto
--- includes-xineramaproto ---
nbmake: nbmake: don't know how to make Xinerama.h. Stop
*** [includes-xineramaproto] Error code 2

Thanks

Mark

From forum: tech-x11

re: libgcc

2009-12-05T12:07:48Z

I've converted all archs' reach-overs & successfully built them. Next I need
to resolv the conflicts between libc's functions and libgcc's ones. In the
long run, it'd be better to remove libc's functions, but I'll exclude the
conflicting functions from libgcc. This is less intrusive. I'll consider
how to migrate later.

it is not ever going to be safe to remove these entirely from libc.
consider the following case:

- build a binary on netbsd-5 that depends upon these symbols

- run this binary on a netbsd-6 system that only has these
symbols in libgcc, and they won't be resolved.

i'd guess that you need to leave them in libc.so as a weak symbol
for all eternity, or at least until we bump libc.so.

.mrg.

From forum: tech-toolchain

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T09:50:05Z

On Sat, Dec 05, 2009 at 05:17:29PM +0000, David Laight wrote:

> On Sat, Dec 05, 2009 at 05:30:39PM +0100, Manuel Bouyer wrote:
> > On Sat, Dec 05, 2009 at 03:06:50PM +0000, David Laight wrote:
> > > The 'wd' (aka ATA disk) driver has a load of code for the
> > > WD_QUIRK_FORCE_LBA48 quirk.
> > >
> > > This forces LBA48 transfers for an ever increasing number of disks.
> > >
> > > My suspicion is that the problems only relate to transfers that
> > > actually cross the LBA48 boundary.
> > >
> > > So quite possibly checking:
> > > wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
> > > would remove the need for the quirk.
> >
> > This would need to be tested more carefully, but actually this problem is
> > detected automatically and the quirk table for these drives should not be
> > needed any more (I didn't remove this table just to be conservative).
>
> What about PR/36896 where sector 0 got overwritten.

This kernel doesn't have the autodetect code, obviously.
With the autodetect code the error message would have something like
Aug 31 11:59:50 30_DEMO_697 /netbsd: wd1g: LBA48 bug writing fsbn 216369024 of 216369024-216369151 (wd1 bn 268435391; cn 266304 tn 15 sn 14), retrying

Aug 31 11:59:51 30_DEMO_697 /netbsd: wd1: soft error (corrected)

The autodetect code has been commited to HEAD on 2007/09/16,
and pulled up to various branches one month later.

--
Manuel Bouyer <bouyer@...>
NetBSD: 26 ans d'experience feront toujours la difference
--

From forum: tech-kern

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T09:17:07Z

On Sat, Dec 05, 2009 at 05:30:39PM +0100, Manuel Bouyer wrote:

> On Sat, Dec 05, 2009 at 03:06:50PM +0000, David Laight wrote:
> > The 'wd' (aka ATA disk) driver has a load of code for the
> > WD_QUIRK_FORCE_LBA48 quirk.
> >
> > This forces LBA48 transfers for an ever increasing number of disks.
> >
> > My suspicion is that the problems only relate to transfers that
> > actually cross the LBA48 boundary.
> >
> > So quite possibly checking:
> > wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
> > would remove the need for the quirk.
>
> This would need to be tested more carefully, but actually this problem is
> detected automatically and the quirk table for these drives should not be
> needed any more (I didn't remove this table just to be conservative).

What about PR/36896 where sector 0 got overwritten.

David

--
David Laight: david@...

From forum: tech-kern

Re: SSL renegociation vulnerability

2009-12-05T09:10:58Z

On Dec 4, 10:52pm, tls@... (Thor Lancelot Simon) wrote:
-- Subject: Re: SSL renegociation vulnerability

| On Sat, Dec 05, 2009 at 03:30:57AM +0000, Christos Zoulas wrote:
| > In article <20091204162709.GA11270@...>,
| > Thor Lancelot Simon <tls@...> wrote:
| > >On Fri, Dec 04, 2009 at 01:13:52AM -0500, Brian Seklecki wrote:
| > >>
| > >> However, I can confirm that:
| > >>
| > >> http://security.FreeBSD.org/patches/SA-09:15/ssl.patch
| > >
| > >If this is the patch from OpenSSL 0.9.8l it should not be applied to
| > >NetBSD; it is broken and introduces both forward *and* backwards API
| > >and ABI incompatibility.
| >
| > Unfortunately I have not seen anything in the head of the OpenSSL tree
| > that addresses this issue so I have applied a similar patch to FreeBSD
| > that disables renegotiation completely for now. I would like to have
| > a better solution, but I don't see one.
|
| Actually, OpenSSL HEAD gets it pretty much right.
|
| The problem with what OpenSSL 0.9.8l did is that it:
|
| 1) Leaves the connection hung rather than closing it after the
| renegotiation attempt.
|
| 2) Uses a different API/ABI for renegotiation control than what
| they did two days later in OpenSSL HEAD, without any backwards
| compatibility!

I'll import head then.

christos

From forum: tech-security

Re: libgcc

2009-12-05T08:48:43Z

From forum: tech-toolchain

Re: Quirk WD_QUIRK_SPLIT_MOD15_WRITE

2009-12-05T08:37:42Z

On Sat, Dec 05, 2009 at 01:53:21PM +0000, David Laight wrote:
> sys/dev/ata/wd.c has some very strange code for the
> WD_QUIRK_SPLIT_MOD15_WRITE quirk.
>
> The code splits in two any transfers where the 'sector_count % 15 == 1'.
> It appears to do this by dividing the byte transfer size in two.
> This is fine for 16 sector transfers (converts one 16k byte transfer
> into two 8k transfers), but it next applies to 31 sector transfers and
> I can't help thinking that the requests for 15.5 sectors aren't going
> to be processed correctly!

Actually it will: the first request will be 15 sectors, the
second one 15 and the last one 1.

--
Manuel Bouyer <bouyer@...>
NetBSD: 26 ans d'experience feront toujours la difference
--

From forum: tech-kern

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T08:35:40Z

On Sat, Dec 05, 2009 at 05:30:39PM +0100, Manuel Bouyer wrote:
> This would need to be tested more carefully, but actually this problem is
> detected automatically and the quirk table for these drives should not be
> needed any more (I didn't remove this table just to be conservative).

e.g. I had a drive listed in the table, and after Manuel added the
automatic check, I removed the table, the automatic check fired on the
first access and all was well without the table...

Cheers,

Patrick

From forum: tech-kern

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T08:31:45Z

On Sat, Dec 05, 2009 at 10:59:19AM -0500, der Mouse wrote:
> [..]
> But, really, it's not clear to me that it's worth doing non-LBA48
> transfers at all on drives capable of LBA48 - what's the cost, two more
> command bytes per transfer? Four? And that, only for accesses below
> the 128G point.
>
> We might need quirks for drives that claim LBA48 but which do not
> actually work with LBA48, but I suspect there would be very few of
> them, way fewer than the current (and growing) list.

the problem is not drives, the problem is controllers.
Some IDE controllers don't support LBA48, but I don't have a list of
those. The only way to know is to try ...

--
Manuel Bouyer <bouyer@...>
NetBSD: 26 ans d'experience feront toujours la difference
--

From forum: tech-kern

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T08:30:39Z

On Sat, Dec 05, 2009 at 03:06:50PM +0000, David Laight wrote:

> The 'wd' (aka ATA disk) driver has a load of code for the
> WD_QUIRK_FORCE_LBA48 quirk.
>
> This forces LBA48 transfers for an ever increasing number of disks.
>
> My suspicion is that the problems only relate to transfers that
> actually cross the LBA48 boundary.
>
> So quite possibly checking:
> wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
> would remove the need for the quirk.

This would need to be tested more carefully, but actually this problem is
detected automatically and the quirk table for these drives should not be
needed any more (I didn't remove this table just to be conservative).

--
Manuel Bouyer <bouyer@...>
NetBSD: 26 ans d'experience feront toujours la difference
--

From forum: tech-kern

Re: WD_QUIRK_FORCE_LBA48

2009-12-05T07:59:19Z

> The 'wd' (aka ATA disk) driver has a load of code for the
> WD_QUIRK_FORCE_LBA48 quirk.

> This forces LBA48 transfers for an ever increasing number of disks.

> My suspicion is that the problems only relate to transfers that
> actually cross the LBA48 boundary.

> So quite possibly checking:
> wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
> would remove the need for the quirk.

In my wd.c, I actually added another quirk, one which effectively
lowers LBA48_THRESHOLD by one sector, upon finding that my "Hitachi
HDT721010SLA360" was returning errors for sector 0xfffffff:

if ( (wd->sc_quirks & WD_QUIRK_FORCE_LBA48) ||
( (wd->sc_flags & WDF_LBA48) &&
( (wd->sc_quirks & WD_QUIRK_LOW_LBA48_THRESH) ?
(wd->sc_wdc_bio.blkno >= LBA48_THRESHOLD) :
(wd->sc_wdc_bio.blkno > LBA48_THRESHOLD) ) ) )

Looking at the comments, I suspect at least a few of the
QUIRK_FORCE_LBA48 drives could use this instead, but since I don't have
them to test, I don't know.

But, really, it's not clear to me that it's worth doing non-LBA48
transfers at all on drives capable of LBA48 - what's the cost, two more
command bytes per transfer? Four? And that, only for accesses below
the 128G point.

We might need quirks for drives that claim LBA48 but which do not
actually work with LBA48, but I suspect there would be very few of
them, way fewer than the current (and growing) list.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@...
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

From forum: tech-kern

WD_QUIRK_FORCE_LBA48

2009-12-05T07:06:34Z

The 'wd' (aka ATA disk) driver has a load of code for the
WD_QUIRK_FORCE_LBA48 quirk.

This forces LBA48 transfers for an ever increasing number of disks.

My suspicion is that the problems only relate to transfers that
actually cross the LBA48 boundary.

So quite possibly checking:
wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
would remove the need for the quirk.

David

--
David Laight: david@...

From forum: tech-kern

Re: Quirk WD_QUIRK_SPLIT_MOD15_WRITE

2009-12-05T06:17:13Z

On Sat, Dec 05, 2009 at 01:53:21PM +0000, David Laight wrote:

> sys/dev/ata/wd.c has some very strange code for the
> WD_QUIRK_SPLIT_MOD15_WRITE quirk.
>
> The code splits in two any transfers where the 'sector_count % 15 == 1'.
> It appears to do this by dividing the byte transfer size in two.
> This is fine for 16 sector transfers (converts one 16k byte transfer
> into two 8k transfers), but it next applies to 31 sector transfers and
> I can't help thinking that the requests for 15.5 sectors aren't going
> to be processed correctly!
>
> Have I missed something?

Apart for the fact that it converts an 8k transfer into two 4k ones ;-)

Perhaps it should just do the first 4k separately.

David

--
David Laight: david@...

From forum: tech-kern

Quirk WD_QUIRK_SPLIT_MOD15_WRITE

2009-12-05T05:52:56Z

sys/dev/ata/wd.c has some very strange code for the
WD_QUIRK_SPLIT_MOD15_WRITE quirk.

The code splits in two any transfers where the 'sector_count % 15 == 1'.
It appears to do this by dividing the byte transfer size in two.
This is fine for 16 sector transfers (converts one 16k byte transfer
into two 8k transfers), but it next applies to 31 sector transfers and
I can't help thinking that the requests for 15.5 sectors aren't going
to be processed correctly!

Have I missed something?

David

--
David Laight: david@...

From forum: tech-kern

Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

2009-12-05T04:32:50Z

On Sat, Dec 05, 2009 at 12:43:54PM +0100, Ingolf Steinbach wrote:

> According to POSIX, getaddrinfo() "shall return a set of socket
> addresses and associated information to be used in creating a socket
> with which to address the specified service." What is the use of
> delivering socket addresses which will certainly fail later when used
> as intended by this specification?

You don't know how the adresses are used and, at the time of the
getaddrinfo() call, you don't know wether you can use these addresses
for a connection. Even more, socket(), bind() and connect() will happily
tell you when they do not support the requested family or when
they cannot connect to the requested address and you can and
should continue by trying the next address. This is how
you should handle the answer from getaddrinfo(), independent
of IPv4 or IPv6.

> b) avoid run-time errors by having getaddrinfo() deliver only v4
> addresses on systems which do not support v6 (unless, of course, the
> user explicitly requests v6 addresses)

See my answer to kre, that dependency isn't necessarily valid and

> c) if both v4 and v6 are supported, make the decision on selection /
> ordering configurable.

if you already want a separate configuration as a workaround (like I
suggested) then this will allow you to do the same.

Greetings,
--
Michael van Elst
Internet: mlelstv@...
"A potential Snark may lurk in every tree."

From forum: tech-net

Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

2009-12-05T04:20:59Z

On Sat, Dec 05, 2009 at 05:44:43PM +0700, Robert Elz wrote:

> | getaddrinfo() is only used by programs that can handle IPv6
>
> Typically yes, but not necessarily

To clarify this, a program that uses getaddrinfo() has to know
that not everything is IPv4 (and thus 'handle it') wether it
wants to use IPv6 connections or not. It either has to tell
getaddrinfo() to restrict itself to some answers or it has to
check the result for answers that it does understand.

> Yes, it is (or should be) a real problem only in those cases, but it is
> a waste of network resources in others - just asking for a v6 address
> you're never going to use is a packet out, a packet back, and the back
> end resolver being made to do (and then cache) data that's useless.
> It shouldn't be a problem, but it is pretty stupid and unnecessary.

It is how the coexistence of IPv4 and IPv6 has been designed. The
alternative is to use a T_ANY query and filter the results.

> | So please, add a knob to control libc behaviour.
>
> For this, I'd do that, but I'd also not query for addresses that we
> can tell cannot possibly be useful

How would you know? I can easily imagine a program analyzing
logfiles, resolving host names or addresses without using
these to create a network connection. The program would behave
differently wether you give the machine IPv6 connectivity or not.

As I said in my previous mail. This is about a workaround that
should be enabled by a decision. Magically deriving this from
something else is going to fail.

> | - resolv.conf is not my first choice, because this is used by
> | the resolver code, not the high level functions like getaddrinfo().
>
> Here I disagree (mildly at least) - I consider getaddrinfo() (and
> gethostbyname()) to just be the programmer friendly interfaces to the
> resolver - they're part of it.

Neither regarding history of development nor the actual code.

resolver is about DNS queries, it doesn't deal with files, nis,
ldap or anything else and it uses resolv.conf as its configuration
file.

getaddrinfo() is about name and address translations, it may use
the resolver subsystem as one of its data sources and it uses
nsswitch.conf as its configuration file.

> That's not the right bit to use (even though I couldn't find any place
> NetBSD's code actually uses it - in libc anyway) but the analogy is a
> reasonable one. And we have practice of other systems.

Do we?

> | - nsswitch.conf would be a natural choice if it allowed to pass
> | options to the backends (e.g. hosts: files dns[v4only]). But
> | who dares to touch nsswitch code? :)
>
> Well, maybe, I guess we could allow dns4only and dns6only as alternatives
> to dns in there, but that looks to be a bit of a stretch.

nsswitch.conf determines who provides the name translations. Using
it to provide options on how the names are translated seems to be
logical. An argument against this is the fact that this would be
the first and so far only option.

> | This would help with the broken DNS server only when you also
> | create a kernel without IPv6 (so far we cannot disable IPv6
> | link local addresses).
>
> Ingolf already did the former, and it didn't help

The reasoning was: a special flag to getaddrinfo() would deduce
how names are translated from the network configuration, but
we need to rebuild the system for this. Rebuilding the kernel
alone obviously doesn't help, but it shouldn't be necessary
to control some other aspect of the system.

If you can make this a boot option instead this might be
useful to some, but see above that creating an automatic
dependency between getaddrinfo() behaviour and kernel
configuration is still questionable at least.

Following that logic the next might be to filter out
DNS answers that point to addresses that have no routing
table entry.

> | So I propose /etc/addrinfo.conf with an associated environment
> | variable ADDRINFO_CONF. And please paint it in pink.
>
> I think resolv.conf is better, it is where resolver config goes, it
> already has the ability to specify options, and is a reasonable home
> for this kind of config.

Tell that the person who has to augment the parser and data structures
of the DNS resolver library for things controlling getaddrinfo().

> I also don't think we need an env var at all,

Very few people will consider it, it's more a debug help (like
MALLOC_OPTIONS) that can be used to override libc behaviour per
process.

I don't say we need it, but just took malloc as a model for how
to control a libc function. If we use this model then we might
want all of it for consistency.

> most applications already
> have options that say whether they should use v4 or v6 (defaulting to whatever
> works usually) and complicating that by adding yet another way wouldn't
> help, just make everything messier, after all, what is telnet (or anything)
> to do if you say "telnet -4 ..." when your ADDRINFO_CONF says "v6 only"
> (or vice versa).

It will behave correctly. Just like telnet -4 to a v6 only host:

henery% telnet -4 pussyfoot.ipv6.local
pussyfoot.ipv6.local: No address associated with hostname

Greetings,
--
Michael van Elst
Internet: mlelstv@...
"A potential Snark may lurk in every tree."

From forum: tech-net

Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

2009-12-05T03:43:54Z

2009/12/5 Michael van Elst <mlelstv@...>:
> With the same argument you could say that a 'nslookup' or 'dig'
> should fail to query AAAA records when your kernel cannot handle
> IPv6.

I don't think that the argument is equivalent: nslookup and friends
are tools to explicitly look up various types of information offered
by DNS servers -- not just addresses. You (typically) explicitly tell
the tool to lookup A, NS, TXT, whatever and possibly also AAAA
records.

> getaddrinfo() is pretty agnostic. You tell it you want IPv4, you get
> IPv4. You tell it you want IPv6, you get IPv6. You don't tell it anything,
> you will get either.

According to POSIX, getaddrinfo() "shall return a set of socket
addresses and associated information to be used in creating a socket
with which to address the specified service." What is the use of
delivering socket addresses which will certainly fail later when used
as intended by this specification?

My suggestion would be:
a) keep the application protocol agnostic
b) avoid run-time errors by having getaddrinfo() deliver only v4
addresses on systems which do not support v6 (unless, of course, the
user explicitly requests v6 addresses)
c) if both v4 and v6 are supported, make the decision on selection /
ordering configurable.

Ingolf

From forum: tech-net

Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

2009-12-05T02:44:43Z

Date: Sat, 5 Dec 2009 09:10:07 +0000 (UTC)
From: mlelstv@... (Michael van Elst)
Message-ID: <hfd813$7m4$1@...>

| With the same argument you could say that a 'nslookup' or 'dig'
| should fail to query AAAA records when your kernel cannot handle
| IPv6.

Not quite - no-one would argue that if you asked for a particular addr type
that getaddrinfo() should do anything different than what it was asked (not
that dig (etc) use getaddrinfo() anyway), but if you say "just give me
something I can use" without caring what protocol, I don't think it would
be unreasonable for getaddrinfo() to simply return only addresses that
have at least the potential to work - and I don't think applications should
need to set some flag to tell getaddrinfo() not to return useless trash,
if anything, for the one in a hundred application that isn't a diagnostic
tool (which wouldn't be using getaddrinfo()), doesn't care what address type,
but wants everything available, even if it cannot possibly work, a flag to
indicate that would make more sense (you'd really have to hunt to find an
application that you'd need to modify to set it).

| getaddrinfo() is only used by programs that can handle IPv6

Typically yes, but not necessarily, it is really just a newer, cleaner,
interface to the resolver low level routines, and ought to be used by
anything new (or just being overhauled) these days, of course, such things
should be able to handle IPv6. but even if they can't, getaddrinfo() is a
much nicer interface than gethostbyname().

| It is a problem for people with a broken IPv6 setup. I.e. the machine
| is configured for an IPv6 network but the network doesn't function
| because of things like unstable tunnels or unreliable ipv6 providers.

Yes, it is (or should be) a real problem only in those cases, but it is
a waste of network resources in others - just asking for a v6 address
you're never going to use is a packet out, a packet back, and the back
end resolver being made to do (and then cache) data that's useless.
It shouldn't be a problem, but it is pretty stupid and unnecessary.

And of course the same is true for v4 for (future) systems where v4
doesn't work.

| I don't think that such a workaround should depend on the kernel
| because the need for the workaround has little to do with the kernel
| and the functionality that needs to be adjusted is embedded in
| libc.

Yes, it is libc that should act differently here.

| So please, add a knob to control libc behaviour.

For this, I'd do that, but I'd also not query for addresses that we
can tell cannot possibly be useful, if the application hasn't expressly
asked for that address type (either by name, which is an interface that
already exists, or by explicitly asking for useless answers, using some
new interface, if one gets invented).

| - sysctl is out of the question. It controls kernel behaviour and
| the kernel shouldn't be a storage for configuration data.

If you mean a sysctl whose purpose was to config libc, then certainly
that would be absurd. But that doesn't mean that libc cannot look at
a sysctl that has some other purpose, to determine whether a protocol is
supported or not (or something.) Not that I'd do that that way either,
it's cheaper and easier just to (try to) create a socket of the
appropriate type, if that succeeds, then return addresses of that type,
if it fails, don't (by default). That also works on any kernel.

| - an environment variable would be sufficient for me but there
| are issues to make this a system wide setting. There are always
| other parties that tweak the environment and break such a setup.

Agreed, env vars should be reserved for users to start personal
preferences, not for system settings.

| - resolv.conf is not my first choice, because this is used by
| the resolver code, not the high level functions like getaddrinfo().

Here I disagree (mildly at least) - I consider getaddrinfo() (and
gethostbyname()) to just be the programmer friendly interfaces to the
resolver - they're part of it. So, config in resolv.conf is not
at all unreasonable (and the relevant function already accesses the
resolver state, so using that just means moving a function call a
little earlier).

| But since there already is a bit that controls the resolver library
| in a similar way, this might be an option. The particular bit
| (RES_USE_INET6) however, has a completely different meaning
| because it is supposed to return IPv4 adresses as IPv6 adresses
| to simplify application code.

That's not the right bit to use (even though I couldn't find any place
NetBSD's code actually uses it - in libc anyway) but the analogy is a
reasonable one. And we have practice of other systems.

| - nsswitch.conf would be a natural choice if it allowed to pass
| options to the backends (e.g. hosts: files dns[v4only]). But
| who dares to touch nsswitch code? :)

Well, maybe, I guess we could allow dns4only and dns6only as alternatives
to dns in there, but that looks to be a bit of a stretch.

| - a new file/symlink like /etc/malloc.conf (which BTW is the system
| wide configuration for something controlled by an environment
| variable).

If we didn't already have resolv.conf, that would be my choice.

| This would help with the broken DNS server only when you also
| create a kernel without IPv6 (so far we cannot disable IPv6
| link local addresses).

Ingolf already did the former, and it didn't help - but not sending
a query for v6 addresses would have helped, regardless of whether his
kernel had v6 support in it or not. And since there seemed to be at
least some support, and no opposition, I'll dig out the CD I have somewhere
with the "disable protocol" code on it, and make it fit current as it
is now, and send in a change request PR (probably for the simple version
that just makes the selected protocol vanish to new users of it, rather
than all the extra that allows existing connections to be affected as well).

For most expected requirements, it does what is desired, you set the
sysctl in /etc/sysctl.conf and from the next boot, there is almost no
difference visible between running a system with the disabled protocol,
and running a kernel with the protocol compiled out (except that you
can "undisable" (yes, I know correct English is "enable" but that
doesn't quite give the same impression) the protocol any time.)

| So I propose /etc/addrinfo.conf with an associated environment
| variable ADDRINFO_CONF. And please paint it in pink.

I think resolv.conf is better, it is where resolver config goes, it
already has the ability to specify options, and is a reasonable home
for this kind of config.

I also don't think we need an env var at all, most applications already
have options that say whether they should use v4 or v6 (defaulting to whatever
works usually) and complicating that by adding yet another way wouldn't
help, just make everything messier, after all, what is telnet (or anything)
to do if you say "telnet -4 ..." when your ADDRINFO_CONF says "v6 only"
(or vice versa). Just leave that config to command line options - if an
application doesn't provide a way, then its author didn't intend his users
to be able to control this behaviour.

kre

From forum: tech-net

Re: CVS commit: pkgsrc/mbone/common-mml

2009-12-04T22:27:46Z

Date: Fri, 4 Dec 2009 12:33:11 -0800
From: Soren Jacobsen <snj@...>
Message-ID: <00C3FA51-6FE2-4C3D-8FA6-085975F140F4@...>

| I am quite sure that those files are supposed to be included in the package,

OK, in that case when I get time (perhaps not before Wednesday) I'll also
take a look and see if I can tell what might be happening (unless you, or
someone, find a solution first).

| but there must be a missing build dependency somewhere that
| causes bulk builds (and your pkg_comp setup) to not generate
| those two files.

My setup certainly builds packages in (almost) as sparse an environment
as they allow themselves to be built in, and I believe the pbulk setup
does the same (though I haven't ever looked at it), so that is certainly
possible.

| I admit I have no idea how gtk-doc works,

I have no idea how gtk-anything works, ...

kre

From forum: tech-pkg