Re: CVS commit: src/doc

[Steffen Nurpmeso]

Nia Alarie wrote in
 <20230629214647.db217f...@cvs.netbsd.org>:
 |Module Name:  src
 |Committed By: nia
 |Date: Thu Jun 29 21:46:47 UTC 2023
 |
 |Modified Files:
 | src/doc: CHANGES
 |
 |Log Message:
 |ch-ch-changes

station to station

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: CVS commit: src/doc

[Jason Thorpe]

> On Jan 27, 2021, at 3:11 PM, Simon Burge  wrote:
> 
> It can run either big- or little-endian, but has virtually no IO support
> whatsoever - just a UART and an extremely simple eithernet driver.
> 
> I couldn't find any MIPS references to virtio with a quick look through
> the QEMU 5.0 sources.

In theory, you should be able to configure virtio @ pci on the Malta emulation, 
but in practice… *shrug*.

-- thorpej

Re: CVS commit: src/doc

[Simon Burge]

Hi Reinoud,

Reinoud Zandijk wrote:

> Hi Simon,
>
> On Wed, Jan 27, 2021 at 05:27:01AM +, Simon Burge wrote:
> > Module Name:src
> > Committed By:   simonb
> > Date:   Wed Jan 27 05:27:01 UTC 2021
> > 
> > Modified Files:
> > src/doc: CHANGES
> > 
> > Log Message:
> > Note support for QEMU "mipssim" emulator.
>
> Is this machine also *able* to run big endian? Or/and can it also use virtio
> over either FDT/ACPI or PCI?

It can run either big- or little-endian, but has virtually no IO support
whatsoever - just a UART and an extremely simple eithernet driver.

I couldn't find any MIPS references to virtio with a quick look through
the QEMU 5.0 sources.

Cheers,
Simon.

Re: CVS commit: src/doc

[Reinoud Zandijk]

Hi Simon,

On Wed, Jan 27, 2021 at 05:27:01AM +, Simon Burge wrote:
> Module Name:  src
> Committed By: simonb
> Date: Wed Jan 27 05:27:01 UTC 2021
> 
> Modified Files:
>   src/doc: CHANGES
> 
> Log Message:
> Note support for QEMU "mipssim" emulator.

Is this machine also *able* to run big endian? Or/and can it also use virtio
over either FDT/ACPI or PCI?

With regards,
Reinoud

re: CVS commit: src/doc

[matthew green]

> Modified Files:
>   src/doc: HACKS

thank you for keeping this upto date.


.mrg.

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 01.03.2020 22:36, Joerg Sonnenberger wrote:
> On Sun, Mar 01, 2020 at 10:20:44PM +0100, Kamil Rytarowski wrote:
>> If that will nor realize, I will request to enable GNU_HASH for NetBSD-11.
> 
> You have so far demonstrated no justification at all beyond handwaving
> for why it should be included in first place. Seriously, stop rushing
> code without doing your homework to demonstrate that it is (1) correct
> (2) an actual improvement (3) understanding concerns raised in the past.
> I have limited ressources and having to deal with crap like the
> max_align_t commit just costs a lot of time for no good reason.
> 


(1) As it was tested locally and capable to use in the following
benchmark it works. Feel free to double check, catch potential bugs in
the DT_GNU_HASH implementation inside RTLD and correct them.

(2) I linked to benchmarks in my commit message. I have reproduced the
~50% performance boost claim here:

 http://netbsd.org/~kamil/ld/DT_HASH-DT_GNU_HASH-benchmark-2020-03-02.txt

Feel free to tune the benchmark for other scenarios and write your own
tests.

(3) DT_HASH is generally considered as too slow with raised requirements
on dynamically linked libraries over the past 15 years.

>> GNU_HASH is industry standard for all modern Linux and any other
>> mainstream BSD distribution already for around a decade.
> 
> If you want an industry standard, please use the GNU/Linux distribution
> of your choice. Arguing based on industry standards is a non sequitur.
> 

Our current LD and RTLD feature set matrix is at best said..
conservative in the context of all other BSDs and Linux (possibly
Solaris) and undemanding in performance.

If NetBSD wants to be relevant for development of heavy C/C++ code, it
must not be worse compared to alternatives.

I'm working on getting us on  and get NetBSD on par with industry
standard toolchain support (and LLVM lld here).

> Joerg
> 

So. Unless there will be a viable alternative materialized as
DT_NETBSD_HASH, I will flip DT_GNU_HASH on in NetBSD-11. If we cannot
make nice things on our own locally, we shall rely on 3rd party industry
standards.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Joerg Sonnenberger]

On Sun, Mar 01, 2020 at 10:20:44PM +0100, Kamil Rytarowski wrote:
> If that will nor realize, I will request to enable GNU_HASH for NetBSD-11.

You have so far demonstrated no justification at all beyond handwaving
for why it should be included in first place. Seriously, stop rushing
code without doing your homework to demonstrate that it is (1) correct
(2) an actual improvement (3) understanding concerns raised in the past.
I have limited ressources and having to deal with crap like the
max_align_t commit just costs a lot of time for no good reason.

> GNU_HASH is industry standard for all modern Linux and any other
> mainstream BSD distribution already for around a decade.

If you want an industry standard, please use the GNU/Linux distribution
of your choice. Arguing based on industry standards is a non sequitur.

Joerg

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 29.02.2020 23:31, Joerg Sonnenberger wrote:
> On Sat, Feb 29, 2020 at 10:29:02PM +0100, Kamil Rytarowski wrote:
>> On 29.02.2020 21:58, Joerg Sonnenberger wrote:
>>> On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
 On 29.02.2020 19:00, Taylor R Campbell wrote:
>> Module Name:src
>> Committed By:   kamil
>> Date:   Sat Feb 29 04:27:01 UTC 2020
>>
>> Modified Files:
>> src/doc: CHANGES
>>
>> Log Message:
>> ld.elf_so(1): Implement DT_GNU_HASH
>
> Was this discussed anywhere?

 In the toolchain circles, for some time now (2+ years).

 It was one of the pending task to modernize our ELF loader on par with
 at least FreeBSD.
>>>
>>> Can we please stop with this "we must need XXX to be on par with YYY"
>>> nonsense without actually looking at the details first and discuss them?
>>> Practically speaking, there was moderately little discussion about the
>>> actual design choices of DT_GNU_HASH, especially some of its deficits.
>>> Especially because we already have some important improvements in our
>>> tree *without breaking compatibility*. Especially the size claims are
>>> questionable at best as justification are weak at best. It also ignores
>>> that by design DT_GNU_HASH conflicts with at least one platform ABI.
>>>
>>> Joerg
>>>
>>
>> Just keeping DT_GNU_HASH support around does not break compat. Full
>> replacement of HASH algorithm would break compat but nobody wants to do
>> it (at least in NetBSD).
> 
> Can you please stop speaking for the NetBSD community? Seriously, that
> alone makes me want to just /dev/null all messages. "Keeping DT_GNU_HASH
> around" is funny, given that it just got added without any discussion.
> 
> Joerg
> 

If you can design and implement DT_NETBSD_HASH that is at least as good
as DT_GNU_HASH, upstream it to LLVM and GNU toolchains for all ports and
take maintenance, I am fine with never populating .gnu.hash sections in
default installs.

If that will nor realize, I will request to enable GNU_HASH for NetBSD-11.

GNU_HASH is industry standard for all modern Linux and any other
mainstream BSD distribution already for around a decade.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 29.02.2020 22:29, Kamil Rytarowski wrote:
> On 29.02.2020 21:58, Joerg Sonnenberger wrote:
>> On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
>>> On 29.02.2020 19:00, Taylor R Campbell wrote:
> Module Name:src
> Committed By:   kamil
> Date:   Sat Feb 29 04:27:01 UTC 2020
>
> Modified Files:
> src/doc: CHANGES
>
> Log Message:
> ld.elf_so(1): Implement DT_GNU_HASH

 Was this discussed anywhere?
>>>
>>> In the toolchain circles, for some time now (2+ years).
>>>
>>> It was one of the pending task to modernize our ELF loader on par with
>>> at least FreeBSD.
>>
>> Can we please stop with this "we must need XXX to be on par with YYY"

Speaking of what. We are still waiting for over a year now for
multisegment support in the ELF loader. We can barely build a functional
binary with a patched lld.

Can we get at least architectural design what is the proper direction
here (we received no feedback) so we can do it on our own?



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Joerg Sonnenberger]

On Sat, Feb 29, 2020 at 10:29:02PM +0100, Kamil Rytarowski wrote:
> On 29.02.2020 21:58, Joerg Sonnenberger wrote:
> > On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
> >> On 29.02.2020 19:00, Taylor R Campbell wrote:
>  Module Name:src
>  Committed By:   kamil
>  Date:   Sat Feb 29 04:27:01 UTC 2020
> 
>  Modified Files:
>  src/doc: CHANGES
> 
>  Log Message:
>  ld.elf_so(1): Implement DT_GNU_HASH
> >>>
> >>> Was this discussed anywhere?
> >>
> >> In the toolchain circles, for some time now (2+ years).
> >>
> >> It was one of the pending task to modernize our ELF loader on par with
> >> at least FreeBSD.
> > 
> > Can we please stop with this "we must need XXX to be on par with YYY"
> > nonsense without actually looking at the details first and discuss them?
> > Practically speaking, there was moderately little discussion about the
> > actual design choices of DT_GNU_HASH, especially some of its deficits.
> > Especially because we already have some important improvements in our
> > tree *without breaking compatibility*. Especially the size claims are
> > questionable at best as justification are weak at best. It also ignores
> > that by design DT_GNU_HASH conflicts with at least one platform ABI.
> > 
> > Joerg
> > 
> 
> Just keeping DT_GNU_HASH support around does not break compat. Full
> replacement of HASH algorithm would break compat but nobody wants to do
> it (at least in NetBSD).

Can you please stop speaking for the NetBSD community? Seriously, that
alone makes me want to just /dev/null all messages. "Keeping DT_GNU_HASH
around" is funny, given that it just got added without any discussion.

Joerg

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 29.02.2020 21:58, Joerg Sonnenberger wrote:
> On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
>> On 29.02.2020 19:00, Taylor R Campbell wrote:
 Module Name:src
 Committed By:   kamil
 Date:   Sat Feb 29 04:27:01 UTC 2020

 Modified Files:
 src/doc: CHANGES

 Log Message:
 ld.elf_so(1): Implement DT_GNU_HASH
>>>
>>> Was this discussed anywhere?
>>
>> In the toolchain circles, for some time now (2+ years).
>>
>> It was one of the pending task to modernize our ELF loader on par with
>> at least FreeBSD.
> 
> Can we please stop with this "we must need XXX to be on par with YYY"
> nonsense without actually looking at the details first and discuss them?
> Practically speaking, there was moderately little discussion about the
> actual design choices of DT_GNU_HASH, especially some of its deficits.
> Especially because we already have some important improvements in our
> tree *without breaking compatibility*. Especially the size claims are
> questionable at best as justification are weak at best. It also ignores
> that by design DT_GNU_HASH conflicts with at least one platform ABI.
> 
> Joerg
> 

Just keeping DT_GNU_HASH support around does not break compat. Full
replacement of HASH algorithm would break compat but nobody wants to do
it (at least in NetBSD).

Improvement. I presume we are talking about enhancements such as
fast_divide32_prepare(3). This is reused also in DT_GNU_HASH.

DT_GNU_HASH is still not fully supported on MIPS ABI with our basesystem
toolchain (as it is not recent enough). Paper work stopped it for some
years and it is now in mainline GNU as DT_MIPS_XHASH.

https://github.com/bminor/binutils-gdb/commit/f16a9783c5f085443d806646074e9c06fdee9a88

So, I presume it is good to ifdef DT_GNU_HASH for __mips__ in the loader.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Joerg Sonnenberger]

On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
> On 29.02.2020 19:00, Taylor R Campbell wrote:
> >> Module Name:src
> >> Committed By:   kamil
> >> Date:   Sat Feb 29 04:27:01 UTC 2020
> >>
> >> Modified Files:
> >> src/doc: CHANGES
> >>
> >> Log Message:
> >> ld.elf_so(1): Implement DT_GNU_HASH
> > 
> > Was this discussed anywhere?
> 
> In the toolchain circles, for some time now (2+ years).
> 
> It was one of the pending task to modernize our ELF loader on par with
> at least FreeBSD.

Can we please stop with this "we must need XXX to be on par with YYY"
nonsense without actually looking at the details first and discuss them?
Practically speaking, there was moderately little discussion about the
actual design choices of DT_GNU_HASH, especially some of its deficits.
Especially because we already have some important improvements in our
tree *without breaking compatibility*. Especially the size claims are
questionable at best as justification are weak at best. It also ignores
that by design DT_GNU_HASH conflicts with at least one platform ABI.

Joerg

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 29.02.2020 19:29, Martin Husemann wrote:
> On Sat, Feb 29, 2020 at 06:00:29PM +, Taylor R Campbell wrote:
>>> Module Name:src
>>> Committed By:   kamil
>>> Date:   Sat Feb 29 04:27:01 UTC 2020
>>>
>>> Modified Files:
>>> src/doc: CHANGES
>>>
>>> Log Message:
>>> ld.elf_so(1): Implement DT_GNU_HASH
>>
>> Was this discussed anywhere?  What are the advantages and drawbacks of
>> this over what we were doing before?  What other toolchain changes are
>> involved in using it?  What maintenance burden does it put on us for
>> compatibility?  What's the impact on systems that prioritize size over
>> speed?
> 
> It also does not compile on most architectures.
> 
> Martin
> 

Looking!



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 29.02.2020 19:00, Taylor R Campbell wrote:
>> Module Name:src
>> Committed By:   kamil
>> Date:   Sat Feb 29 04:27:01 UTC 2020
>>
>> Modified Files:
>> src/doc: CHANGES
>>
>> Log Message:
>> ld.elf_so(1): Implement DT_GNU_HASH
> 
> Was this discussed anywhere?

In the toolchain circles, for some time now (2+ years).

It was one of the pending task to modernize our ELF loader on par with
at least FreeBSD.

>  What are the advantages and drawbacks of
> this over what we were doing before?

Reading:

https://blogs.oracle.com/solaris/gnu-hash-elf-sections-v2

https://flapenguin.me/2017/05/10/elf-lookup-dt-gnu-hash/

1. Advantages.

We support now an alternative hash format that is ~50% faster, de facto
standard in ELF Operating Systems and thinner in size.

2. Disadvantages.

If we switch to GNU Hash only we are no longer producing compliant ELF
binaries.

Once we will deliver GNU Hash binaries, delivering sysv hash for
compatibility and conformance reason, binaries will be fatter for 0.5-5kb.

Some OSs like FreeBSD and most Linux distros decided to build both
hashes concurrently. Upstream LLD developers attempted to switch as many
OSs as possible to GNU Hash only, but it was resisted.

ps(1) sizes
---

54064 sysv hash
54216 both hashes
53520 gnu hash


>  What other toolchain changes are
> involved in using it?

1. On the ld level.

 - dynamically: make LDFLAGS="-Wl,--hash-style=both"
 - statically: possibly flipping

/* Define to 1 if you want to emit gnu hash in the ELF linker by default. */
#define DEFAULT_EMIT_GNU_HASH 0

in config.h

2. gcc/clang

pass - -Wl,--hash-style=both

>  What maintenance burden does it put on us for
> compatibility?

After designing in 10+ years ago, it works as is without changes in
other OSs.

Stable interface and if someone will invent new hash, we will likely get
a new type of: DT_*_HASH.

LLVM and GNU toolchains support it and recommend for ELF targets.

>  What's the impact on systems that prioritize size over
> speed?
> 

We win both size and speed with GNU Hash shipped exclusively.

We pay cost of extra around 1 kbyte per binary if we want both hashes.

If we want minimum size we can generate only one hash type.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Martin Husemann]

On Sat, Feb 29, 2020 at 06:00:29PM +, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By:   kamil
> > Date:   Sat Feb 29 04:27:01 UTC 2020
> > 
> > Modified Files:
> > src/doc: CHANGES
> > 
> > Log Message:
> > ld.elf_so(1): Implement DT_GNU_HASH
> 
> Was this discussed anywhere?  What are the advantages and drawbacks of
> this over what we were doing before?  What other toolchain changes are
> involved in using it?  What maintenance burden does it put on us for
> compatibility?  What's the impact on systems that prioritize size over
> speed?

It also does not compile on most architectures.

Martin

Re: CVS commit: src/doc

[Taylor R Campbell]

> Module Name:src
> Committed By:   kamil
> Date:   Sat Feb 29 04:27:01 UTC 2020
> 
> Modified Files:
> src/doc: CHANGES
> 
> Log Message:
> ld.elf_so(1): Implement DT_GNU_HASH

Was this discussed anywhere?  What are the advantages and drawbacks of
this over what we were doing before?  What other toolchain changes are
involved in using it?  What maintenance burden does it put on us for
compatibility?  What's the impact on systems that prioritize size over
speed?

Re: CVS commit: src/doc

[Christos Zoulas]

Yup, I have those in /etc/mk.conf.

HAVE_LLVM=yes
MKLLVM=yes
MKGCC=no

$ fgrep netbsd-clang /usr/src/make.sparc64-sparc64.release.out | head -4
--- sparc64--netbsd-clang ---
#  link  llvm-clang/sparc64--netbsd-clang
c++ -g -O2 -fno-rtti -fno-exceptions -fno-strict-aliasing 
-I/usr/obj/sparc64-sparc64/tools/include/compat 
-I/p/netbsd/cvsroot/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 
-D_FILE_OFFSET_BITS=64 -I. 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/clang/include
 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/llvm/include
 -I/p/netbsd/cvsroot/src/tools/llvm-include/obj.sparc64-sparc64 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/include 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/tools/clang/include
 -std=c++14 -I. 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/clang/include
 
-I/p/netbsd/cvsroot/src/tools/llvm-clang/../../external/apache2/llvm/bin/clang/../../dist/llvm/include
 -I/p/netbsd/cvsroot/src/tools/llvm-include/obj.sparc64-sparc64 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/include 
-I/p/netbsd/cvsroot/src/tools/llvm/obj.sparc64-sparc64/config/tools/clang/include
   -o sparc64--netbsd-clang driver.lo cc1_main.lo cc1as_main.lo 
cc1gen_reproducer_main.lo -L/usr/obj/sparc64-sparc64/tools/lib -lnbcompat -lrt 
-lz 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontendTool/obj.sparc64-sparc64 
-lclangFrontendTool 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontend/obj.sparc64-sparc64 
-lclangFrontend 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangARCMigrate/obj.sparc64-sparc64 
-lclangARCMigrate 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangStaticAnalyzerFrontend/obj.sparc64-sparc64
 -lclangStaticAnalyzerFrontend 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangStaticAnalyzerCheckers/obj.sparc64-sparc64
 -lclangStaticAnalyzerCheckers 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangStaticAnalyzerCore/obj.sparc64-sparc64
 -lclangStaticAnalyzerCore 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangCrossTU/obj.sparc64-sparc64 
-lclangCrossTU 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangIndex/obj.sparc64-sparc64 
-lclangIndex 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangASTMatchers/obj.sparc64-sparc64 
-lclangASTMatchers 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangCodeGen/obj.sparc64-sparc64 
-lclangCodeGen 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontendRewrite/obj.sparc64-sparc64
 -lclangFrontendRewrite 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangFrontend/obj.sparc64-sparc64 
-lclangFrontend 
-L/p/netbsd/cvsroot/src/tools/llvm-lib/libclangSerialization/ob...

christos

> On Feb 20, 2020, at 4:10 AM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 20.02.2020 01:42, Christos Zoulas wrote:
>> Not reproducible:
> 
> As reported this needs specified:
> 
> -V MKLLVM=yes -V MKGCC=no -V HAVE_LLVM=yes
> 
>> 
>>  build.sh command:./build.sh -P -U -E -x -m sparc64 -a
>> sparc64 -D /usr/obj/sparc64-sparc64/release -R
>> /usr/obj/sparc64-sparc64/media -j 40 release
>>  build.sh started:Wed Feb 19 15:27:23 EST 2020
>>  NetBSD version:  9.99.47
>>  MACHINE: sparc64
>>  MACHINE_ARCH:sparc64
>>  Build platform:  NetBSD 9.99.18 amd64
>>  HOST_SH: /bin/sh
>>  No $TOOLDIR/bin/nbmake, needs building.
>>  Bootstrapping nbmake
>>  MAKECONF file:   /etc/mk.conf
>>  TOOLDIR path:/usr/obj/sparc64-sparc64/tools
>>  DESTDIR path:/usr/obj/sparc64-sparc64/release
>>  RELEASEDIR path: /usr/obj/sparc64-sparc64/media
>>  Created /usr/obj/sparc64-sparc64/tools/bin/nbmake
>>  Updated makewrapper:
>> /usr/obj/sparc64-sparc64/tools/bin/nbmake-sparc64
>>  Tools built to /usr/obj/sparc64-sparc64/tools
>>  MKREPRO_TIMESTAMPWed Feb 19 19:18:01 UTC 2020
>>  Successful make release
>>  build.sh ended:  Wed Feb 19 17:48:15 EST 2020
>> ===> .
>> 
>> 
>> 
>>> On Feb 19, 2020, at 11:09 AM, Kamil Rytarowski >> 
>>> >> wrote:
>>> 
>>> Signed PGP part
>>> On 19.02.2020 16:32, Kamil Rytarowski wrote:
 On 18.02.2020 22:14, Christos Zoulas wrote:
> Module Name:src
> Committed By:christos
> Date:Tue Feb 18 21:14:16 UTC 2020
> 
> Modified Files:
> src/doc: 3RDPARTY CHANGES
> 
> Log Message:
> new awk
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 
 
 This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
 
>>> 
>>> Log:
>>> 
>>> 

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 20.02.2020 01:42, Christos Zoulas wrote:
> Not reproducible:

As reported this needs specified:

-V MKLLVM=yes -V MKGCC=no -V HAVE_LLVM=yes

> 
>          build.sh command:    ./build.sh -P -U -E -x -m sparc64 -a
> sparc64 -D /usr/obj/sparc64-sparc64/release -R
> /usr/obj/sparc64-sparc64/media -j 40 release
>          build.sh started:    Wed Feb 19 15:27:23 EST 2020
>          NetBSD version:      9.99.47
>          MACHINE:             sparc64
>          MACHINE_ARCH:        sparc64
>          Build platform:      NetBSD 9.99.18 amd64
>          HOST_SH:             /bin/sh
>          No $TOOLDIR/bin/nbmake, needs building.
>          Bootstrapping nbmake
>          MAKECONF file:       /etc/mk.conf
>          TOOLDIR path:        /usr/obj/sparc64-sparc64/tools
>          DESTDIR path:        /usr/obj/sparc64-sparc64/release
>          RELEASEDIR path:     /usr/obj/sparc64-sparc64/media
>          Created /usr/obj/sparc64-sparc64/tools/bin/nbmake
>          Updated makewrapper:
> /usr/obj/sparc64-sparc64/tools/bin/nbmake-sparc64
>          Tools built to /usr/obj/sparc64-sparc64/tools
>          MKREPRO_TIMESTAMP    Wed Feb 19 19:18:01 UTC 2020
>          Successful make release
>          build.sh ended:      Wed Feb 19 17:48:15 EST 2020
> ===> .
> 
> 
> 
>> On Feb 19, 2020, at 11:09 AM, Kamil Rytarowski > > wrote:
>>
>> Signed PGP part
>> On 19.02.2020 16:32, Kamil Rytarowski wrote:
>>> On 18.02.2020 22:14, Christos Zoulas wrote:
 Module Name:src
 Committed By:christos
 Date:Tue Feb 18 21:14:16 UTC 2020

 Modified Files:
 src/doc: 3RDPARTY CHANGES

 Log Message:
 new awk


 To generate a diff of this commit:
 cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
 cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>>>
>>> This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
>>>
>>
>> Log:
>>
>> isters.S |  sed "s;\([^:]*\):\([^(]*\)(\([^, )]*\)\(.*\);\3 \1
>> /^\2(\3\4$/;"  >> tags.tmp
>> In file included from
>> /usr/src/lib/libc/compat/rpc/compat_pmap_rmtcall.c:50:
>> In file included from
>> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpc.h:75:
>> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
>> error: unknown type name 'rpcblist'
>> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>>   ^
>> 1 error generated.
>> --- compat_pmap_rmtcall.o ---
>> *** [compat_pmap_rmtcall.o] Error code 1
>> nbmake[6]: stopped in /usr/src/lib/libc
>> In file included from /usr/src/lib/libc/compat/rpc/compat_rpcb.c:50:
>> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
>> error: unknown type name 'rpcblist'
>> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>>   ^
>> 1 error generated.
>> --- compat_rpcb.o ---
>> *** [compat_rpcb.o] Error code 1
>>
>> nbmake[6]: stopped in /usr/src/lib/libc
>> 2 errors
>>
>> nbmake[6]: stopped in /usr/src/lib/libc
>> --- dependall ---
>> *** [dependall] Error code 2
>> nbmake[5]: stopped in /usr/src/lib/libc
>> 1 error
>> nbmake[5]: stopped in /usr/src/lib/libc
>> *** Failed target:  dependall-libc
>> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
>> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
>> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
>> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
>> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
>> /public/netbsd-sparc64/tooldir.NetBSD-9.99.46-amd64/bin/nbmake
>> _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget libc dependall
>> *** Error code 2
>>
>> Stop.
>> nbmake[4]: stopped in /usr/src/lib
>> --- build_install ---
>> *** [build_install] Error code 1
>>
>> nbmake[3]: stopped in /usr/src/lib
>> 1 error
>>
>> nbmake[3]: stopped in /usr/src/lib
>> --- do-lib ---
>> *** [do-lib] Error code 2
>>
>> nbmake[2]: stopped in /usr/src
>> 1 error
>>
>> nbmake[2]: stopped in /usr/src
>> --- build ---
>> *** [build] Error code 2
>>
>> nbmake[1]: stopped in /usr/src
>> 1 error
>>
>> nbmake[1]: stopped in /usr/src
>> --- distribution ---
>> *** [distribution] Error code 2
>>
>> nbmake: stopped in /usr/src
>> 1 error
>>
>> nbmake: stopped in /usr/src
>>
>> ERROR: Failed to make distribution
>>
>>
>> 
> 




signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Christos Zoulas]

Not reproducible:

 build.sh command:./build.sh -P -U -E -x -m sparc64 -a sparc64 -D 
/usr/obj/sparc64-sparc64/release -R /usr/obj/sparc64-sparc64/media -j 40 release
 build.sh started:Wed Feb 19 15:27:23 EST 2020
 NetBSD version:  9.99.47
 MACHINE: sparc64
 MACHINE_ARCH:sparc64
 Build platform:  NetBSD 9.99.18 amd64
 HOST_SH: /bin/sh
 No $TOOLDIR/bin/nbmake, needs building.
 Bootstrapping nbmake
 MAKECONF file:   /etc/mk.conf
 TOOLDIR path:/usr/obj/sparc64-sparc64/tools
 DESTDIR path:/usr/obj/sparc64-sparc64/release
 RELEASEDIR path: /usr/obj/sparc64-sparc64/media
 Created /usr/obj/sparc64-sparc64/tools/bin/nbmake
 Updated makewrapper: /usr/obj/sparc64-sparc64/tools/bin/nbmake-sparc64
 Tools built to /usr/obj/sparc64-sparc64/tools
 MKREPRO_TIMESTAMPWed Feb 19 19:18:01 UTC 2020
 Successful make release
 build.sh ended:  Wed Feb 19 17:48:15 EST 2020
===> .



> On Feb 19, 2020, at 11:09 AM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 19.02.2020 16:32, Kamil Rytarowski wrote:
>> On 18.02.2020 22:14, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By:   christos
>>> Date:   Tue Feb 18 21:14:16 UTC 2020
>>> 
>>> Modified Files:
>>> src/doc: 3RDPARTY CHANGES
>>> 
>>> Log Message:
>>> new awk
>>> 
>>> 
>>> To generate a diff of this commit:
>>> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
>>> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
>>> 
>>> Please note that diffs are not public domain; they are subject to the
>>> copyright notices on the relevant files.
>>> 
>> 
>> This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
>> 
> 
> Log:
> 
> isters.S |  sed "s;\([^:]*\):\([^(]*\)(\([^, )]*\)\(.*\);\3 \1
> /^\2(\3\4$/;"  >> tags.tmp
> In file included from /usr/src/lib/libc/compat/rpc/compat_pmap_rmtcall.c:50:
> In file included from
> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpc.h:75:
> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
> error: unknown type name 'rpcblist'
> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>   ^
> 1 error generated.
> --- compat_pmap_rmtcall.o ---
> *** [compat_pmap_rmtcall.o] Error code 1
> nbmake[6]: stopped in /usr/src/lib/libc
> In file included from /usr/src/lib/libc/compat/rpc/compat_rpcb.c:50:
> /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
> error: unknown type name 'rpcblist'
> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>   ^
> 1 error generated.
> --- compat_rpcb.o ---
> *** [compat_rpcb.o] Error code 1
> 
> nbmake[6]: stopped in /usr/src/lib/libc
> 2 errors
> 
> nbmake[6]: stopped in /usr/src/lib/libc
> --- dependall ---
> *** [dependall] Error code 2
> nbmake[5]: stopped in /usr/src/lib/libc
> 1 error
> nbmake[5]: stopped in /usr/src/lib/libc
> *** Failed target:  dependall-libc
> *** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
> shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
> this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
> real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
> ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
> /public/netbsd-sparc64/tooldir.NetBSD-9.99.46-amd64/bin/nbmake
> _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget libc dependall
> *** Error code 2
> 
> Stop.
> nbmake[4]: stopped in /usr/src/lib
> --- build_install ---
> *** [build_install] Error code 1
> 
> nbmake[3]: stopped in /usr/src/lib
> 1 error
> 
> nbmake[3]: stopped in /usr/src/lib
> --- do-lib ---
> *** [do-lib] Error code 2
> 
> nbmake[2]: stopped in /usr/src
> 1 error
> 
> nbmake[2]: stopped in /usr/src
> --- build ---
> *** [build] Error code 2
> 
> nbmake[1]: stopped in /usr/src
> 1 error
> 
> nbmake[1]: stopped in /usr/src
> --- distribution ---
> *** [distribution] Error code 2
> 
> nbmake: stopped in /usr/src
> 1 error
> 
> nbmake: stopped in /usr/src
> 
> ERROR: Failed to make distribution
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: CVS commit: src/doc

[Christos Zoulas]

On Feb 19,  5:09pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/doc

| On 19.02.2020 16:32, Kamil Rytarowski wrote:
| > On 18.02.2020 22:14, Christos Zoulas wrote:
| >> Module Name:   src
| >> Committed By:  christos
| >> Date:  Tue Feb 18 21:14:16 UTC 2020
| >>
| >> Modified Files:
| >>src/doc: 3RDPARTY CHANGES
| >>
| >> Log Message:
| >> new awk
| >>
| >>
| >> To generate a diff of this commit:
| >> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
| >> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
| >>
| >> Please note that diffs are not public domain; they are subject to the
| >> copyright notices on the relevant files.
| >>
| >=20
| > This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
| >=20
| 
| Log:
| 
| isters.S |  sed "s;\([^:]*\):\([^(]*\)(\([^, )]*\)\(.*\);\3 \1
| /^\2(\3\4$/;"  >> tags.tmp
| In file included from /usr/src/lib/libc/compat/rpc/compat_pmap_rmtcall.c:50=
| :
| In file included from
| /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpc.h:75:
| /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
| error: unknown type name 'rpcblist'
| extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
|^
| 1 error generated.
| --- compat_pmap_rmtcall.o ---
| *** [compat_pmap_rmtcall.o] Error code 1
| nbmake[6]: stopped in /usr/src/lib/libc
| In file included from /usr/src/lib/libc/compat/rpc/compat_rpcb.c:50:
| /public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
| error: unknown type name 'rpcblist'
| extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);

building.

christos

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 19.02.2020 16:32, Kamil Rytarowski wrote:
> On 18.02.2020 22:14, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Feb 18 21:14:16 UTC 2020
>>
>> Modified Files:
>>  src/doc: 3RDPARTY CHANGES
>>
>> Log Message:
>> new awk
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
>> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>>
> 
> This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).
> 

Log:

isters.S |  sed "s;\([^:]*\):\([^(]*\)(\([^, )]*\)\(.*\);\3 \1
/^\2(\3\4$/;"  >> tags.tmp
In file included from /usr/src/lib/libc/compat/rpc/compat_pmap_rmtcall.c:50:
In file included from
/public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpc.h:75:
/public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
error: unknown type name 'rpcblist'
extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
   ^
1 error generated.
--- compat_pmap_rmtcall.o ---
*** [compat_pmap_rmtcall.o] Error code 1
nbmake[6]: stopped in /usr/src/lib/libc
In file included from /usr/src/lib/libc/compat/rpc/compat_rpcb.c:50:
/public/netbsd-sparc64/destdir.sparc64/usr/include/rpc/rpcb_clnt.h:68:8:
error: unknown type name 'rpcblist'
extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
   ^
1 error generated.
--- compat_rpcb.o ---
*** [compat_rpcb.o] Error code 1

nbmake[6]: stopped in /usr/src/lib/libc
2 errors

nbmake[6]: stopped in /usr/src/lib/libc
--- dependall ---
*** [dependall] Error code 2
nbmake[5]: stopped in /usr/src/lib/libc
1 error
nbmake[5]: stopped in /usr/src/lib/libc
*** Failed target:  dependall-libc
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1";
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .)
this="lib/"; real="/usr/src/lib" ;; *) this="lib/${dir}/";
real="/usr/src/lib/${dir}" ;; esac; show=${this:-.}; echo "${target}
===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/public/netbsd-sparc64/tooldir.NetBSD-9.99.46-amd64/bin/nbmake
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget libc dependall
*** Error code 2

Stop.
nbmake[4]: stopped in /usr/src/lib
--- build_install ---
*** [build_install] Error code 1

nbmake[3]: stopped in /usr/src/lib
1 error

nbmake[3]: stopped in /usr/src/lib
--- do-lib ---
*** [do-lib] Error code 2

nbmake[2]: stopped in /usr/src
1 error

nbmake[2]: stopped in /usr/src
--- build ---
*** [build] Error code 2

nbmake[1]: stopped in /usr/src
1 error

nbmake[1]: stopped in /usr/src
--- distribution ---
*** [distribution] Error code 2

nbmake: stopped in /usr/src
1 error

nbmake: stopped in /usr/src

ERROR: Failed to make distribution



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 18.02.2020 22:14, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Tue Feb 18 21:14:16 UTC 2020
> 
> Modified Files:
>   src/doc: 3RDPARTY CHANGES
> 
> Log Message:
> new awk
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1690 -r1.1691 src/doc/3RDPARTY
> cvs rdiff -u -r1.2649 -r1.2650 src/doc/CHANGES
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

This upgrade broke MKLLVM HAVE_LLVM build (at least for -m sparc64).



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 19.01.2020 07:57, Jason R Thorpe wrote:
> Module Name:  src
> Committed By: thorpej
> Date: Sun Jan 19 06:57:39 UTC 2020
> 
> Modified Files:
>   src/doc: CHANGES
> 
> Log Message:
> Note removal of HIPPI support.

Thanks!

Please keep in sync src/doc/TODO.smpnet.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[Christos Zoulas]

In article <20191114162726.b55f7f...@cvs.netbsd.org>,
Maxime Villard  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  maxv
>Date:  Thu Nov 14 16:27:26 UTC 2019
>
>Modified Files:
>   src/doc: CHANGES
>
>Log Message:
>Note kMSan.
>

Very nice!

christos

Re: CVS commit: src/doc

[Martin Husemann]

On Fri, Oct 18, 2019 at 06:08:55AM +1100, matthew green wrote:
> "Jared D. McNeill" writes:
> > Module Name:src
> > Committed By:   jmcneill
> > Date:   Thu Oct 17 09:38:07 UTC 2019
> > 
> > Modified Files:
> > src/doc: CHANGES
> > 
> > Log Message:
> > Amazon Graviton support is in 9.0, remove the changes entry.
> 
> is it in CHANGES.prev?  entries should move from CHANGES
> to CHANGES.prev when they're going to be part of a first
> release.. otherwise they're lost entirely.

Indeed - my fault, sorry Jared - can you fix it?

Martin

re: CVS commit: src/doc

[matthew green]

"Jared D. McNeill" writes:
> Module Name:  src
> Committed By: jmcneill
> Date: Thu Oct 17 09:38:07 UTC 2019
> 
> Modified Files:
>   src/doc: CHANGES
> 
> Log Message:
> Amazon Graviton support is in 9.0, remove the changes entry.

is it in CHANGES.prev?  entries should move from CHANGES
to CHANGES.prev when they're going to be part of a first
release.. otherwise they're lost entirely.

thanks.


.mrg.

Re: CVS commit: src/doc

[Paul Goyette]

I wonder if this would make a good GSOC project?

On Wed, 20 Feb 2019, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Wed Feb 20 04:32:51 UTC 2019

Modified Files:
src/doc: TODO.modules

Log Message:
Add an entry to remind someone(tm) to review the need for WARNS=3 in
more than 100 modules' Makefile.


To generate a diff of this commit:
cvs rdiff -u -r1.18 -r1.19 src/doc/TODO.modules

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


!DSPAM:5c6cd89714072584319933!




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

Re: CVS commit: src/doc

[Steffen Nurpmeso]

Christos Zoulas wrote in <20190108184053.e22c1f...@cvs.netbsd.org>:
 |Module Name:  src
 |Committed By: christos
 |Date: Tue Jan  8 18:40:53 UTC 2019
 |
 |Modified Files:
 | src/doc: 3RDPARTY
 |
 |Log Message:
 |- put all the GPLv3 software together
 |- put all the Last GPLv2 version software at the end.
 |Perhaps it is better to use separate files (per license) at this point?

The current version of groff is 1.22.4.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: CVS commit: src/doc

[Christos Zoulas]

On Sep 30,  1:07am, t...@back-street.net (Takahiro Kambe) wrote:
-- Subject: Re: CVS commit: src/doc

| In message <20180812130741.848c9f...@cvs.netbsd.org>
|   on Sun, 12 Aug 2018 09:07:41 -0400,
|   "Christos Zoulas"  wrote:
| > Module Name:src
| > Committed By:   christos
| > Date:   Sun Aug 12 13:07:41 UTC 2018
| > 
| > Modified Files:
| > src/doc: 3RDPARTY CHANGES
| > 
| > Log Message:
| > mention new bind
| Should "Current Vers" be "9.10.7/BSD" only?

The other way around, let me fix it.

christos

Re: CVS commit: src/doc

[Takahiro Kambe]

In message <20180812130741.848c9f...@cvs.netbsd.org>
on Sun, 12 Aug 2018 09:07:41 -0400,
"Christos Zoulas"  wrote:
> Module Name:  src
> Committed By: christos
> Date: Sun Aug 12 13:07:41 UTC 2018
> 
> Modified Files:
>   src/doc: 3RDPARTY CHANGES
> 
> Log Message:
> mention new bind
Should "Current Vers" be "9.10.7/BSD" only?

Index: doc/3RDPARTY
===
RCS file: /cvsroot/src/doc/3RDPARTY,v
retrieving revision 1.1540
retrieving revision 1.1541
diff -u -r1.1540 -r1.1541
--- doc/3RDPARTY10 Aug 2018 00:19:09 -  1.1540
+++ doc/3RDPARTY12 Aug 2018 13:07:41 -  1.1541
@@ -1,4 +1,4 @@
-#  $NetBSD: 3RDPARTY,v 1.1540 2018/08/10 00:19:09 sevan Exp $
+#  $NetBSD: 3RDPARTY,v 1.1541 2018/08/12 13:07:41 christos Exp $
 #
 # This file contains a list of the software that has been integrated into
 # NetBSD where we are not the primary maintainer.
@@ -114,8 +114,8 @@
 bc includes dc, both of which are in the NetBSD tree.
 
 Package:   bind [named and utils]
-Version:   9.10.7/BSD  9.12.1/MPL
-Current Vers:  9.10.7/BSD
+Version:   9.10.7/BSD  9.12.2-P1/MPL
+Current Vers:  9.10.7/BSD  9.12.2-P1/MPL
 Maintainer:Paul Vixie 
 Archive Site:  ftp://ftp.isc.org/isc/bind9/
 Home Page: http://www.isc.org/software/bind/

-- 
Takahiro Kambe 

Re: CVS commit: src/doc

[Sevan Janiyan]

On 15/08/2018 16:11, Sevan Janiyan wrote:
> Module Name:  src
> Committed By: sevan
> Date: Wed Aug 15 15:11:18 UTC 2018
> 
> Modified Files:
>   src/doc: 3RDPARTY
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1547 -r1.1548 src/doc/3RDPARTY
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

Apologies for the blank commit message, I quit out of the editor and at
the prompt to abort or not I changed my mind and wanted to return to
composing a commit message, so I chose continue.

It was amended with cvs admin within minutes of the change
"Update bc location, still todo: license"


Sevan

Re: CVS commit: src/doc

[Steffen Nurpmeso]

Hello,

Sevan Janiyan wrote in <20180806224530.0eb41f...@cvs.netbsd.org>:
 |Module Name:  src
 |Committed By: sevan
 |Date: Mon Aug  6 22:45:29 UTC 2018
 |
 |Modified Files:
 | src/doc: 3RDPARTY
 |
 |Log Message:
 |Update current version info for IANA services & protocols databases.
 |
 |heads up by 
 |
 |To generate a diff of this commit:
 |cvs rdiff -u -r1.1537 -r1.1538 src/doc/3RDPARTY
 |
 |Please note that diffs are not public domain; they are subject to the
 |copyright notices on the relevant files.
 |
 --End of <20180806224530.0eb41f...@cvs.netbsd.org>

For your possible interest, for CRUX-Linux i have adjusted
a script from Gaetan Bisson of ArchLinux which works with plain
awk and updates protocols and services to the current version.
(Because the full list of especially services is _very_ large,
much larger than what the BSDs have, for example, and also changes
pretty frequently.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


iana-etc-update.sh
Description: Bourne shell script

Re: CVS commit: src/doc

[coypu]

On Sun, Jan 08, 2017 at 04:17:44PM +, Thomas Klausner wrote:
> Module Name:  src
> Committed By: wiz
> Date: Sun Jan  8 16:17:44 UTC 2017
> 
> Modified Files:
>   src/doc: 3RDPARTY
> 
> Log Message:
> zlib-1.2.9 out.
> 

1.2.10 is out

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 02.01.2017 18:54, David Holland wrote:
> On Mon, Jan 02, 2017 at 05:18:49AM +0100, Kamil Rytarowski wrote:
>  > > Historically exect() is used by debuggers to start debuggees. While
>  > > it's equivalent to using PT_TRACE_ME followed by execve(), I think the
>  > > result is that the new process first stops immediately after the exec
>  > > finishes so that the debugger doesn't have to worry about stepping
>  > > through the exec call in its own code.
>  > > 
>  > > This doesn't mean it shouldn't go away (or as much away as it can,
>  > > that is, to COMPAT_70) but I'm not convinced there's no case for it.
>  > > 
>  > 
>  > So, can I change exect(3) to something like:
>  > 
>  > int
>  > exect(const char *path, char *const argv[], char *const envp[])
>  > {
>  > if (ptrace(PT_TRACE_ME, 0, NULL, 0) == -1)
>  > return -1;
>  > return execve(path, argv, envp);
>  > }
>  > 
>  > The current implementation of exect(3) (at least philosophically)
>  > predates SIGTRAP on exec().
> 
> Not really; AFAIK, with that the target will first stop at the return
> from the ptrace call, and also stop at the exec, whereas with
> traditional exect it will first stop after the exec completes, in
> __start or in ld.elf_so.
> 
> An unsophisticated debugger expecting the latter will almost certainly
> be confused by the former.
> 
> Anyway, it needs to be kept in both the kernel and libc for compat so
> there's not much to be gained by mucking with it. :-/
> 

A debugger doesn't catch signal on PT_TRACE_ME. It will stop once on exec().

I don't see any need for compat as I doubt that it was ever functional.
In the past it was trying to singlestep libc call for execve(2), with
the new approach it will not turn on PT_STEP, but emit signal on exec().



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[David Holland]

On Mon, Jan 02, 2017 at 05:18:49AM +0100, Kamil Rytarowski wrote:
 > > Historically exect() is used by debuggers to start debuggees. While
 > > it's equivalent to using PT_TRACE_ME followed by execve(), I think the
 > > result is that the new process first stops immediately after the exec
 > > finishes so that the debugger doesn't have to worry about stepping
 > > through the exec call in its own code.
 > > 
 > > This doesn't mean it shouldn't go away (or as much away as it can,
 > > that is, to COMPAT_70) but I'm not convinced there's no case for it.
 > > 
 > 
 > So, can I change exect(3) to something like:
 > 
 > int
 > exect(const char *path, char *const argv[], char *const envp[])
 > {
 > if (ptrace(PT_TRACE_ME, 0, NULL, 0) == -1)
 > return -1;
 > return execve(path, argv, envp);
 > }
 > 
 > The current implementation of exect(3) (at least philosophically)
 > predates SIGTRAP on exec().

Not really; AFAIK, with that the target will first stop at the return
from the ptrace call, and also stop at the exec, whereas with
traditional exect it will first stop after the exec completes, in
__start or in ld.elf_so.

An unsophisticated debugger expecting the latter will almost certainly
be confused by the former.

Anyway, it needs to be kept in both the kernel and libc for compat so
there's not much to be gained by mucking with it. :-/

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/doc

[Kamil Rytarowski]

On 02.01.2017 04:44, David Holland wrote:
> On Sat, Dec 31, 2016 at 08:57:16PM +, Kamil Rytarowski wrote:
>  > Update TODO.ptrace
>  > 
>  > Mark exect(3) for removal, there is no use-case for it. exec() is already
>  > monitored and emits SIGTRAP when traced.
> 
> Historically exect() is used by debuggers to start debuggees. While
> it's equivalent to using PT_TRACE_ME followed by execve(), I think the
> result is that the new process first stops immediately after the exec
> finishes so that the debugger doesn't have to worry about stepping
> through the exec call in its own code.
> 
> This doesn't mean it shouldn't go away (or as much away as it can,
> that is, to COMPAT_70) but I'm not convinced there's no case for it.
> 

So, can I change exect(3) to something like:

int
exect(const char *path, char *const argv[], char *const envp[])
{
if (ptrace(PT_TRACE_ME, 0, NULL, 0) == -1)
return -1;
return execve(path, argv, envp);
}

The current implementation of exect(3) (at least philosophically)
predates SIGTRAP on exec().

Personally, I have no opinion neither preference on it either way.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/doc

[David Holland]

On Sat, Dec 31, 2016 at 08:57:16PM +, Kamil Rytarowski wrote:
 > Update TODO.ptrace
 > 
 > Mark exect(3) for removal, there is no use-case for it. exec() is already
 > monitored and emits SIGTRAP when traced.

Historically exect() is used by debuggers to start debuggees. While
it's equivalent to using PT_TRACE_ME followed by execve(), I think the
result is that the new process first stops immediately after the exec
finishes so that the debugger doesn't have to worry about stepping
through the exec call in its own code.

This doesn't mean it shouldn't go away (or as much away as it can,
that is, to COMPAT_70) but I'm not convinced there's no case for it.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/doc

[Marc Balmer]

Am 20.05.13 11:31, schrieb Thomas Klausner:
 Module Name:  src
 Committed By: wiz
 Date: Mon May 20 09:31:31 UTC 2013
 
 Modified Files:
   src/doc: 3RDPARTY
 
 Log Message:
 lua-5.2.2 out (mbalmer!!)

Actually I am working on that.  For base and pkgsrc...

So stay tuned ;)

Re: CVS commit: src/doc

[Joerg Sonnenberger]

On Sat, Apr 20, 2013 at 05:46:20AM +, Tetsuya Isaki wrote:
 Module Name:  src
 Committed By: isaki
 Date: Sat Apr 20 05:46:20 UTC 2013
 
 Modified Files:
   src/doc: CHANGES
 
 Log Message:
 m68k FPE supports all mathematics functions.

How much chocolate would we need to get you to work on adding long
double support to libm? *g*

Joerg

Re: CVS commit: src/doc

[Tetsuya Isaki]

At Thu, 25 Apr 2013 22:37:08 +0200,
Joerg Sonnenberger wrote:
  Module Name:src
  Committed By:   isaki
  Date:   Sat Apr 20 05:46:20 UTC 2013
  
  Modified Files:
  src/doc: CHANGES
  
  Log Message:
  m68k FPE supports all mathematics functions.
 
 How much chocolate would we need to get you to work on adding long
 double support to libm? *g*

er, I cannot eat anymore :-)
---
Tetsuya Isaki is...@pastel-flower.jp / is...@netbsd.org

Re: CVS commit: src/doc

[Warner Losh]

On Mar 2, 2012, at 12:41 AM, Alan Barrett wrote:

 On Fri, 02 Mar 2012, Jukka Ruohonen wrote:
 tzcode2012b and tzdata2012b ahve been released.
 We have updated to tzdata2012b.
 
 What was the resolution with the patent issues and whatnot?
 
 The lawsuit was withdrawn after it became obvious that the 
 plaintiffs had no valid case.  The EFF got involved with the 
 defence, and here's their collection of links to relevant 
 documents:  https://www.eff.org/cases/astrolabe-v-olson.

And there were never any patent issues.  It was a bad copyright case.

Warner

Re: CVS commit: src/doc

[Jukka Ruohonen]

On Fri, Mar 02, 2012 at 07:06:31AM +, Alan Barrett wrote:
 Module Name:  src
 Committed By: apb
 Date: Fri Mar  2 07:06:31 UTC 2012
 
 Modified Files:
   src/doc: 3RDPARTY
 
 Log Message:
 tzcode2012b and tzdata2012b ahve been released.
 We have updated to tzdata2012b.

What was the resolution with the patent issues and whatnot?

- Jukka.

Re: CVS commit: src/doc

[Christos Zoulas]

In article 20101121200907.ga10...@cs.hut.fi,
Antti Kantee  po...@cs.hut.fi wrote:

  - handle setuid and unsetuid the posix way instead of setresuid()
  - add all missing functions
  - always bump major when importing to avoid api problems.
 +- disabled roaming reconnect

Any reason you bumped only minor?  Please adjust either tree or docs.

I think we should bump major to be safe. Plus what would it take to
enable roaming reconnect?

christos

Re: CVS commit: src/doc

[Izumi Tsutsui]

 Fix last 2 commits.

Ah, sorry bad pasto.

---
Izumi Tsutsui

Re: CVS commit: src/doc

[Nick Hudson]

On Friday 12 November 2010 17:36:57 Izumi Tsutsui wrote:
  Fix last 2 commits.
 
 Ah, sorry bad pasto.

It helped me spot my typo. :)

 
 ---
 Izumi Tsutsui
 

Nick

Re: CVS commit: src/doc

[Izumi Tsutsui]

  Are there any specific problems or (even better) PRs for this
  brokenness?
 
  PR port-hpcmips/43738.
 
  In general, (not specific at all ;p)
  - post-your-fix kernel +  pre-mips64-merge userland work fine
  - post-your-fix kernel + post-mips64-merge userland don't work
  on mips ports I tried.
 
 That's not quite what I see on sgimips.
 With an old userland and a new kernel I still get numerous binaries  
 which dump core on startup, namely all shells except in single user. A  
 kernel prior to Simon's fixes would not run a single userland binary,  
 a fixed kernel seems to run most but not all of them. I didn't try a  
 post merge userland yet.
 So, the machine will get to userland, show a login prompt, let you  
 login but then immediately drop back to the login prompt since the  
 shell died, same effect via ssh.
 
 I see this on both Indy and O2, both have R5k CPUs in case it matters.

Hmm, I tried R5000 180MHz O2, then
 - 5.99.38 kernel + 5.99.15 userland: login works
 - same kernel+ 5.99.38 base.tgz: getty fails
   (note partial mips64 merge happened during 5.99.22)


5.99.38 kernel + 5.99.15 userland:
---
 Starting up the system...

   To perform system maintenance instead, press Esc

NetBSD/sgimips 5.99.10 Bootstrap, Revision 1.5
(tsut...@airtrek, Tue Apr  7 21:29:32 JST 2009)

devopen: pci(0)scsi(0)disk(1)rdisk(0)partition(0) type scsi file /netbsd
5337856+260680 [298144+285217]=0x5e5940
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 5.99.38 (GENERIC32_IP3x) #216: Fri Aug 27 20:05:41 JST 2010
tsut...@mirage:/usr/src/sys/arch/sgimips/compile/GENERIC32_IP3x
total memory = 256 MB
(6848 KB reserved for ARCS)
avail memory = 237 MB
mainbus0 (root): SGI-IP32 [SGI, 9], 1 processor
cpu0 at mainbus0: MIPS R5000 CPU (0x2321) Rev. 2.1 with built-in FPU Rev. 1.0
cpu0: 48 TLB entries, 16MB max page size
cpu0: 32KB/32B 2-way set-associative L1 Instruction cache
cpu0: 32KB/32B 2-way set-associative write-back L1 Data cache
cpu0: 512KB/32B direct-mapped write-through L2 Unified cache
crime0 at mainbus0 addr 0x1400: rev 1.1 (CRIME_ID: 161)
crmfb0 at mainbus0 addr 0x1600: SGI CRIME Graphics Display Engine
crmfb0: device unusable if not setup by firmware
mace0 at mainbus0 addr 0x1f00
lpt0 at mace0 offset 0x38 intr 4 intrmask 0xf
com0 at mace0 offset 0x39 intr 4 intrmask 0x3f0: ns16550a, working fifo
com0: console
com1 at mace0 offset 0x398000 intr 4 intrmask 0xfc00: ns16550a, working fifo
macekbc0 at mace0 offset 0x32 intr 5 intrmask 0x0: PS2 controller
mcclock0 at mace0 offset 0x3a intrmask 0x0
mec0 at mace0 offset 0x28 intr 3 intrmask 0x0: MAC-110 Ethernet, rev 1
mec0: Ethernet address 08:00:69:0c:95:79
nsphy0 at mec0 phy 8: DP83840 10/100 media interface, rev. 0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
mavb0 at mace0 offset 0x30 intr 6 intrmask 0x0: AD1843 rev 1
audio0 at mavb0: full duplex, playback, capture, independent
macepci0 at mace0 offset 0x8 intr 7 intrmask 0x0: rev 1
pci0 at macepci0 bus 0
ahc0 at pci0 dev 1 function 0: Adaptec aic7880 Ultra SCSI adapter
ahc0: interrupting at crime interrupt 8
ahc0: Using left over BIOS settings
ahc0: Host Adapter has no SEEPROM. Using default SCSI target parameters
ahc0: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
scsibus0 at ahc0: 16 targets, 8 luns per target
ahc1 at pci0 dev 2 function 0: Adaptec aic7880 Ultra SCSI adapter
ahc1: interrupting at crime interrupt 9
ahc1: Using left over BIOS settings
ahc1: Host Adapter has no SEEPROM. Using default SCSI target parameters
ahc1: aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
scsibus1 at ahc1: 16 targets, 8 luns per target
tl0 at pci0 dev 3 function 0
tl0: Compaq Netelligent 10/100 TX
tl0: Ethernet address 00:80:5f:8b:55:cc
tl0: interrupting at crime interrupt 10
nsphy1 at tl0 phy 1: DP83840 10/100 media interface, rev. 1
nsphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
tlphy0 at tl0 phy 31: ThunderLAN 10BASE-T media interface, rev. 5
tlphy0: no media present
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
WARNING: module error: can't find builtin dependency `compat_svr4'
sd0 at scsibus0 target 1 lun 0: SGI, IBM DCAS-32160W, S62A disk fixed
sd0: 2049 MB, 8188 cyl, 3 head, 170 sec, 512 bytes/sect x 4197405 sectors
sd0: sync (50.00ns offset 8), 16-bit (40.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 4 lun 0: TOSHIBA, CD-ROM XM-5701TA, 0167 cdrom 
removable
cd0: sync (100.00ns offset 8), 8-bit (10.000MB/s) transfers
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs
pid 1(init): ABI set to O32 (e_flags=0x1007)
Fri Aug 27 20:08:01 JST 2010
swapctl: 

Re: CVS commit: src/doc

[Izumi Tsutsui]

   Mention mips64 support (from the first branch merge) by matt@,
   so details wont be forgotten in the release notes.
  
  IMO, no one will forget it because all mips ports have been broken
  since the merge and we won't get the next release unless it's fixed.
  
  Anyway, if you would like to mention it, we should also mention
  it's broken in the HEAD.
 
 Are there any specific problems or (even better) PRs for this
 brokenness?

PR port-hpcmips/43738.

In general, (not specific at all ;p)
 - post-your-fix kernel +  pre-mips64-merge userland work fine
 - post-your-fix kernel + post-mips64-merge userland don't work
on mips ports I tried.

 I've fixed all the lossage the mips64 merge has caused
 that I'm aware of, but admit that I haven't had time to track all
 the issues.

I also see:

 - sshd causes a kernel panic on ews4800mips
 - getty quits quickly on arc (as PR 43738 and martin said)
 - pmax bootloader doesn't load a kernel properly on gxemul
 - pmax binaries dump core and kernel gets panic: utlbmod: invalid pte

I've put pmax disk images that can be used for test on gxemul:
ftp://ftp.NetBSD.org/pub/NetBSD/misc/tsutsui/pmax/


% gxemul -e 3max -X -d NetBSD-pmax-20100810.img
 - loaded kernel doesn't start properly:

---
NetBSD/pmax 5.99.38 FFSv1 Primary Bootstrap

NetBSD/pmax 5.99.38 Secondary Bootstrap, Revision 1.5
(bui...@b8.netbsd.org, Tue Aug 10 11:10:30 UTC 2010)

Boot: 5/rz0/
Loading: 5/rz0/netbsd.pmax
open 5/rz0/netbsd.pmax: No such file or directory
Loading: 5/rz0/netbsd
3536400+251696 [217728+206897]=0x404e84
Starting at 0x8003


NetBSD does not yet support system type 0 (???).

panic: platform not supported
cpu0: Begin traceback...
pid -2147287208 

---


% gxemul -e 3max -X -d NetBSD-pmax-20100810-binaries-5.1_RC3-boot.img
 - kernel seems loaded properly, but binaries dump core:

---
 :
root file system type: ffs
pid 1(init): ABI set to O32 (e_flags=0x1007)
[1]   Segmentation fault  /sbin/sysctl -n ...
Fri Aug 27 13;21:41 UTC 2010
[1]   Segmentation fault  rcorder -s nosta...
rcorder terminated with signal 11
[1]   Doneecho  ${rc_f... |
  Segmentation fault  fmt
The following compnents reported failures:

See /var/run/rc.log for more information.
Fri Aug 27 13:21:42 UTC 2010
panic: utlbmod: invalid pte
cpu0: Begin traceback...
pid -977305960 not found
cpu0: End traceback...

dump to dev 19,1 not possible
rebooting...
---


% gxemul -e 3max -X -d NetBSD-pmax-5.1_RC3.img
 - works fine.

% gxemul -e 3max -X -d NetBSD-pmax-20100810-kernel-5.1_RC3-userland.img
 - also seems working.


It smells -current toolchain has some issue.
(around default target settings?)

---
Izumi Tsutsui

Re: CVS commit: src/doc

[Simon Burge]

Izumi Tsutsui wrote:

  Mention mips64 support (from the first branch merge) by matt@,
  so details wont be forgotten in the release notes.
 
 IMO, no one will forget it because all mips ports have been broken
 since the merge and we won't get the next release unless it's fixed.
 
 Anyway, if you would like to mention it, we should also mention
 it's broken in the HEAD.

Are there any specific problems or (even better) PRs for this
brokenness?  I've fixed all the lossage the mips64 merge has caused
that I'm aware of, but admit that I haven't had time to track all
the issues.

Cheers,
Simon.

Re: CVS commit: src/doc

[Joerg Sonnenberger]

On Wed, Oct 21, 2009 at 10:32:12PM +, Thomas Klausner wrote:
 Module Name:  src
 Committed By: wiz
 Date: Wed Oct 21 22:32:11 UTC 2009
 
 Modified Files:
   src/doc: 3RDPARTY
 
 Log Message:
 Add entry for mdocml with joerg as responsible person.

Nu mach mal keinen Stress :)

Joerg

Re: CVS commit: src/doc

[Marc Balmer]

Am 02.10.2009 um 09:43 schrieb Christoph Egger:


Module Name:src
Committed By:   cegger
Date:   Fri Oct  2 07:43:01 UTC 2009

Modified Files:
src/doc: BUILDING.mdoc CHANGES.prev
src/doc/roadmaps: storage

Log Message:
backout wrong changes after I got teached that the vowel *sound*  
matters

and not the spelling letter (which is what I learned at school).


are you sure they teached you english at that school and not some  
bavarian variant of it?


;) - Marc




To generate a diff of this commit:
cvs rdiff -u -r1.78 -r1.79 src/doc/BUILDING.mdoc
cvs rdiff -u -r1.96 -r1.97 src/doc/CHANGES.prev
cvs rdiff -u -r1.6 -r1.7 src/doc/roadmaps/storage

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/doc/BUILDING.mdoc
diff -u src/doc/BUILDING.mdoc:1.78 src/doc/BUILDING.mdoc:1.79
--- src/doc/BUILDING.mdoc:1.78  Fri Oct  2 07:17:16 2009
+++ src/doc/BUILDING.mdoc   Fri Oct  2 07:43:01 2009
@@ -1,4 +1,4 @@
-.\   $NetBSD: BUILDING.mdoc,v 1.78 2009/10/02 07:17:16 cegger Exp $
+.\   $NetBSD: BUILDING.mdoc,v 1.79 2009/10/02 07:43:01 cegger Exp $
.\
.\ Copyright (c) 2001-2008 The NetBSD Foundation, Inc.
.\ All rights reserved.
@@ -1165,7 +1165,7 @@
.Sy /bin/sh
is unusually old and broken, the Korn Shell
.Sy ( /bin/ksh ) ,
-if available, may be an usable alternative.
+if available, may be a usable alternative.
.Pp
All cross-compile builds, and most native builds, of the entire system
should make use of

Index: src/doc/CHANGES.prev
diff -u src/doc/CHANGES.prev:1.96 src/doc/CHANGES.prev:1.97
--- src/doc/CHANGES.prev:1.96   Fri Oct  2 07:17:16 2009
+++ src/doc/CHANGES.prevFri Oct  2 07:43:01 2009
@@ -1,4 +1,4 @@
-LIST OF CHANGES FROM PREVIOUS RELEASES:$Revision: 1.96 
$
+LIST OF CHANGES FROM PREVIOUS RELEASES:$Revision: 1.97 
$


Changes from 386bsd 0.1 + patchkit 0.2.2 to NetBSD 0.8:
@@ -1608,7 +1608,7 @@
counts (e.g. isofs). [mycroft 19941026]
Reworked part of the `mcd' driver to make it more reliable. [mycroft
19941026]
-	Made fork(2)ing with an user-defined LDT work (and not panic).  
[mycroft
+	Made fork(2)ing with a user-defined LDT work (and not panic).  
[mycroft

19941031]
upgraded diff, diff3, and sdiff to version 2.7. (jtc)
lorder(1): Fixed lorder manpage. From Brad Parker. (jtc)
@@ -2644,7 +2644,7 @@
underlying device and a printable external name
(name + unit number), thus eliminating if_name and if_unit.
Updated interface to (*if_watchdog)() and (*if_reset)()
-   to take a struct ifnet *, rather than an unit number.
+   to take a struct ifnet *, rather than a unit number.
[thorpej 19960506]
ethernet: made the MI LANCE driver standalone, using cfattach to
resolve naming conflicts on ports which can have more
@@ -3512,7 +3512,7 @@
new bus dma framework.  [thorpej 19970606]
alpha: Add support for SGMAP-mapped DMA, using new bus dma
framework, allowing ISA DMA to function.  [thorpej 19970606]
-   isa: convert isadma.c to be an user of new bus dma framework,
+   isa: convert isadma.c to be a user of new bus dma framework,
and convert all drivers that use it to the new API.
[thorpej 19970606]
New sysctl hw.machine_arch which returns the CPU class of a machine.
@@ -4307,7 +4307,7 @@
Sweep inspired by a discussion of a bug introduced in
OpenBSD on Bugtraq.  [thorpej 19980728]
libedit: add 'edit on|off' editrc command, which is used to advise
-   invoking programs if an user's does or doesn't want editline
+   invoking programs if a user's does or doesn't want editline
support. Modify ftp(1) to honour this.  [lukem 19980729]
	tftpd(8): add support for -u user and -g group, which specify the  
user

and group to run as. Fixes PR #4218.  [lukem 19980729]
@@ -4498,7 +4498,7 @@
newsmips: Switch to UVM by default on newsmips. [tsubai 19981116]
i386: Switch to gas.new on i386. [kristerw 19981116]
sparc: Switch to gas.new on sparc. [kristerw 19981116]
-   mbrlabel(8): Add an utility to access partitions on MBR labeled
+   mbrlabel(8): Add a utility to access partitions on MBR labeled
disks like those transferred from a DOS machine [ws 19981116]
pmax:  Add crunched miniroot distribution media [jonathan 19981116]
	kernel: Add support for detaching and activating/deactivating  
devices.

@@ -4749,7 +4749,7 @@
[bad 19990323]
dump(8): Add read cache. Speeds up dump operations in most cases
[bouyer,mjl 19990323]
-	net: prevent bind(2)ing to an unicast address/port if the uids of  
the

+   

Re: CVS commit: src/doc (fix grammar: a - an)

[Geoff Wing]

On Friday 2009-10-02 07:17 +, Christoph Egger output:
:Module Name:   src
:Committed By:  cegger
:Date:  Fri Oct  2 07:17:16 UTC 2009
:
:Modified Files:
:   src/doc: BUILDING.mdoc CHANGES CHANGES.prev
:   src/doc/roadmaps: storage
:
:Log Message:
:fix grammar: a - an
:
:To generate a diff of this commit:
:cvs rdiff -u -r1.77 -r1.78 src/doc/BUILDING.mdoc
:cvs rdiff -u -r1.1297 -r1.1298 src/doc/CHANGES
:cvs rdiff -u -r1.95 -r1.96 src/doc/CHANGES.prev
:cvs rdiff -u -r1.5 -r1.6 src/doc/roadmaps/storage

You're kidding, right?  The only correct change is in doc/CHANGES.

Regards,
Geoff

Re: CVS commit: src/doc (fix grammar: a - an)

[Christoph Egger]

Geoff Wing wrote:
 On Friday 2009-10-02 07:17 +, Christoph Egger output:
 :Module Name: src
 :Committed By:cegger
 :Date:Fri Oct  2 07:17:16 UTC 2009
 :
 :Modified Files:
 : src/doc: BUILDING.mdoc CHANGES CHANGES.prev
 : src/doc/roadmaps: storage
 :
 :Log Message:
 :fix grammar: a - an
 :
 :To generate a diff of this commit:
 :cvs rdiff -u -r1.77 -r1.78 src/doc/BUILDING.mdoc
 :cvs rdiff -u -r1.1297 -r1.1298 src/doc/CHANGES
 :cvs rdiff -u -r1.95 -r1.96 src/doc/CHANGES.prev
 :cvs rdiff -u -r1.5 -r1.6 src/doc/roadmaps/storage
 
 You're kidding, right?  The only correct change is in doc/CHANGES.

I reverted the wrong ones.

Christoph

Re: CVS commit: src/doc

[Soren Jacobsen]

On Oct 2, 2009, at 12:17 AM, Christoph Egger wrote:


Index: src/doc/BUILDING.mdoc
diff -u src/doc/BUILDING.mdoc:1.77 src/doc/BUILDING.mdoc:1.78
--- src/doc/BUILDING.mdoc:1.77  Sun Sep 27 18:08:24 2009
+++ src/doc/BUILDING.mdoc   Fri Oct  2 07:17:16 2009
@@ -1165,7 +1165,7 @@
.Sy /bin/sh
is unusually old and broken, the Korn Shell
.Sy ( /bin/ksh ) ,
-if available, may be a usable alternative.
+if available, may be an usable alternative.


This is wrong.


Index: src/doc/CHANGES.prev
diff -u src/doc/CHANGES.prev:1.95 src/doc/CHANGES.prev:1.96
--- src/doc/CHANGES.prev:1.95   Sat May  2 06:21:16 2009
+++ src/doc/CHANGES.prevFri Oct  2 07:17:16 2009
@@ -1608,7 +1608,7 @@
counts (e.g. isofs). [mycroft 19941026]
Reworked part of the `mcd' driver to make it more reliable. [mycroft
19941026]
-	Made fork(2)ing with a user-defined LDT work (and not panic).  
[mycroft
+	Made fork(2)ing with an user-defined LDT work (and not panic).  
[mycroft


This is wrong.


@@ -2644,7 +2644,7 @@
underlying device and a printable external name
(name + unit number), thus eliminating if_name and if_unit.
Updated interface to (*if_watchdog)() and (*if_reset)()
-   to take a struct ifnet *, rather than a unit number.
+   to take a struct ifnet *, rather than an unit number.


This is wrong.


@@ -3512,7 +3512,7 @@
new bus dma framework.  [thorpej 19970606]
alpha: Add support for SGMAP-mapped DMA, using new bus dma
framework, allowing ISA DMA to function.  [thorpej 19970606]
-   isa: convert isadma.c to be a user of new bus dma framework,
+   isa: convert isadma.c to be an user of new bus dma framework,


This is wrong.


@@ -4307,7 +4307,7 @@
Sweep inspired by a discussion of a bug introduced in
OpenBSD on Bugtraq.  [thorpej 19980728]
libedit: add 'edit on|off' editrc command, which is used to advise
-   invoking programs if a user's does or doesn't want editline
+   invoking programs if an user's does or doesn't want editline


This is wrong.


@@ -4498,7 +4498,7 @@
newsmips: Switch to UVM by default on newsmips. [tsubai 19981116]
i386: Switch to gas.new on i386. [kristerw 19981116]
sparc: Switch to gas.new on sparc. [kristerw 19981116]
-   mbrlabel(8): Add a utility to access partitions on MBR labeled
+   mbrlabel(8): Add an utility to access partitions on MBR labeled


This is wrong.


@@ -4749,7 +4749,7 @@
[bad 19990323]
dump(8): Add read cache. Speeds up dump operations in most cases
[bouyer,mjl 19990323]
-   net: prevent bind(2)ing to a unicast address/port if the uids of the
+	net: prevent bind(2)ing to an unicast address/port if the uids of  
the


This is wrong.


@@ -4821,7 +4821,7 @@
[augustss 19990512]
ftp(1): support `[user[:passwo...@]' in http URLs and $http_proxy.
[lukem 19990513]
-   kernel: Allow a user-specified stack to be used in the child after a
+	kernel: Allow an user-specified stack to be used in the child  
after a


This is wrong.


@@ -4835,7 +4835,7 @@
sessions eventually close down). add transfer time to
syslog messages for get/put. other cleanups.  [lukem 19990518]
whois(1): imported client from RIPE WHOIS Tools 2.4. [tron 19990518]
-	net: Make layer 2 protocol input routines private, and with a  
uniform
+	net: Make layer 2 protocol input routines private, and with an  
uniform


This is wrong.


@@ -5632,7 +5632,7 @@
i386: utilize uvm_pagezeroidle.  [thorpej 2424]
poweroff: Powers down the system equivalent to halt -p, but
allows powering down the system from an exec(2) call, e.g.
-   via a user which has poweroff as login shell. The command
+   via an user which has poweroff as login shell. The command


This is wrong.


@@ -8704,7 +8704,7 @@
[msaitoh 20070130]
uplcom(4): Add support for Willcom WS002IN PHS device
(Prolific Technology PL2303X). [msaitoh 20070131]
-	zaurus: Updates to allow Zaurus screen to rotate 90 degrees to a  
usable
+	zaurus: Updates to allow Zaurus screen to rotate 90 degrees to an  
usable


This is wrong.


@@ -9725,7 +9725,7 @@
wm(4): Add support for more Ethernet ICH9 devices. [bouyer 20081015]
rump: Add networking support to rump.  Support is available in
libraries prefixed with librumpnet.  [pooka 20081016]
-	rump_nfs(8): Add support for a userspace NFS client.  [pooka  
20081016]
+	rump_nfs(8): Add support for an userspace NFS client.  [pooka  
20081016]


This is wrong.


Index: src/doc/roadmaps/storage
diff -u src/doc/roadmaps/storage:1.5 src/doc/roadmaps/storage:1.6
--- src/doc/roadmaps/storage:1.5Tue Sep 15 21:07:58 2009
+++ 

Re: CVS commit: src/doc

[Frank Kardel]

Hi !
I tried a kernel from today (20090530).

Strangely cups/foomatic fails with EBADF when attempting to read
from STDIN in the foomatic perl script. A kernel from 20090516 works.

Userland is from 20090516. Have there been library changes or is a bug
hiding the in descriptor changes ? The system is a Q9450 MP system.

Frank

Andrew Doran wrote:

Module Name:src
Committed By:   ad
Date:   Sun May 24 21:42:39 UTC 2009

Modified Files:
src/doc: CHANGES

Log Message:
Note fd changes.


To generate a diff of this commit:
cvs rdiff -u -r1.1234 -r1.1235 src/doc/CHANGES

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.