[odc] Daily src changes for 2010-12-02
ODC
auto at squish.net
Fri Dec 3 07:00:01 GMT 2010
OpenBSD src changes summary for 2010-12-02
==========================================
bin/pax etc/mklogin.conf
share/man sys/arch/alpha/conf
sys/arch/amd64/conf sys/arch/armish/conf
sys/arch/aviion/conf sys/arch/beagle/conf
sys/arch/gumstix/conf sys/arch/hp300/conf
sys/arch/hppa/conf sys/arch/hppa64/conf
sys/arch/i386/conf sys/arch/landisk/conf
sys/arch/loongson/conf sys/arch/luna88k/conf
sys/arch/mac68k/conf sys/arch/macppc/conf
sys/arch/mvme68k/conf sys/arch/mvme88k/conf
sys/arch/mvmeppc/conf sys/arch/octeon/conf
sys/arch/palm/conf sys/arch/sgi/conf
sys/arch/socppc/conf sys/arch/solbourne/conf
sys/arch/sparc/conf sys/arch/sparc64/conf
sys/arch/vax/conf sys/arch/zaurus/conf
sys/dev sys/dev/usb
usr.bin/mandoc
== bin =============================================================== 01/05 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/bin
pax
~ extern.h ~ options.c
~ pax.c ~ tar.1
~ tar.c
> a -N option for tar that uses numeric only IDs, useful for cross system
> tar file manipulation. with advice from guenther and jmc. (tedu@)
== etc =============================================================== 02/05 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/etc
mklogin.conf
~ mklogin.conf
> The awk's split() starts numbering array indices at 1 not 0. (millert@)
== share ============================================================= 03/05 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/share
man
~ man5/port-modules.5
> Bring lang/ruby module documentation up to date.
> OK landry@ (jeremy@)
== sys =============================================================== 04/05 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/sys
arch/alpha/conf
~ Makefile.alpha
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.alpha
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/amd64/conf
~ Makefile.amd64
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.amd64
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/armish/conf
~ Makefile.armish
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.armish
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/aviion/conf
~ Makefile.aviion
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.aviion
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/beagle/conf
~ Makefile.beagle
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.beagle
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/gumstix/conf
~ Makefile.gumstix
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.gumstix
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/hp300/conf
~ Makefile.hp300
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.hp300
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/hppa/conf
~ Makefile.hppa
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.hppa
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/hppa64/conf
~ Makefile.hppa64
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.hppa64
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/i386/conf
~ Makefile.i386
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.i386
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/landisk/conf
~ Makefile.landisk
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.landisk
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/loongson/conf
~ Makefile.loongson
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.loongson
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/luna88k/conf
~ Makefile.luna88k
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.luna88k
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/mac68k/conf
~ Makefile.mac68k
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.mac68k
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/macppc/conf
~ Makefile.macppc
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.macppc
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/mvme68k/conf
~ Makefile.mvme68k
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.mvme68k
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/mvme88k/conf
~ Makefile.mvme88k
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.mvme88k
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/mvmeppc/conf
~ Makefile.mvmeppc
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.mvmeppc
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/octeon/conf
~ Makefile.octeon
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.octeon
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/palm/conf
~ Makefile.palm
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.palm
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/sgi/conf
~ Makefile.sgi
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.sgi
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/socppc/conf
~ Makefile.socppc
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.socppc
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/solbourne/conf
~ Makefile.solbourne
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.solbourne
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/sparc/conf
~ Makefile.sparc
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.sparc
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/sparc64/conf
~ Makefile.sparc64
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.sparc64
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/vax/conf
~ Makefile.vax
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.vax
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
arch/zaurus/conf
~ Makefile.zaurus
> move vers.o to before the other objects, so that it is not linked last.
> having it linked last is bad (on at least i386 and amd64) because the lapic
> is mapped over the start of the data segment -- savecore(8) then reads the
> version string for a fixed buffer space, and reads into the lapic area
> causing unintended side-effects (at least on Intel X5570 and X5680)
> found by pedro, discussed with kettenis and mpf and miod (deraadt@)
~ Makefile.zaurus
> After the most recent change, make it possible to make -j again. The
> early MD and late MI files must be split up so that vers.o can sneak
> between. Issue spotted by bluhm, repair discussed with miod (deraadt@)
dev
~ hotplug.c
> make hotplug queue dynamic, allowing us to increase size without waste.
> ok deraadt kettenis miod (tedu@)
dev/usb
~ umodem.c
> don't match/attach devices without a data endpoint, since this driver
> can't use them anyway.
> tested with working umodem by sthen@
> ok sthen@ (jakemsr@)
~ usb_quirks.c
> don't attach to the hid interface of the ti msp430 (jakemsr@)
== usr.bin =========================================================== 05/05 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin
mandoc
~ mdoc.c
> Properly initialize the manual section to a default when .Dt is missing.
> Without this, we died on an assertion.
> Problem noted and patch provided by kristaps at . (schwarze@)
~ main.c
> Track the parser status both per file (file_status), such that
> we can for example skip rendering on FATAL parsing errors,
> and globally (exit_status), such that we know what to return.
> Without this, following files produced no rendered output
> once a single file suffered from a FATAL error.
> Bug reported by kristaps@, fix by me. (schwarze@)
===============================================================================
More information about the odc
mailing list