[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