The following reply was made to PR kern/165927; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/165927: commit references a PR
Date: Sat, 31 Mar 2012 06:45:20 + (UTC)
Author: kib
Date: Sat Mar 31 06:44:48 2012
New
Synopsis: burncd(8): 9.0 burncd error caused by change to cd0 from acd0
State-Changed-From-To: patched->closed
State-Changed-By: marius
State-Changed-When: Fri Mar 30 23:58:02 UTC 2012
State-Changed-Why:
Close; MFC'ed down to stable/8.
http://www.freebsd.org/cgi/query-pr.cgi?pr=160979
__
The following reply was made to PR bin/160979; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/160979: commit references a PR
Date: Fri, 30 Mar 2012 23:49:02 + (UTC)
Author: marius
Date: Fri Mar 30 23:48:15 2012
Ne
The following reply was made to PR kern/166501; it has been noted by GNATS.
From: Sergey Smitienko
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/166501: FreeBSD 9.0 generates incorrect SEQ/ACK numbers
under load
Date: Sat, 31 Mar 2012 01:07:40 +0300
This is a multi-part message in MIME
The following reply was made to PR kern/75233; it has been noted by GNATS.
From: John Baldwin
To: bug-follo...@freebsd.org, christoph.mal...@gmx.de
Cc:
Subject: Re: kern/75233: [fdc] breaking fdformat /dev/fd0 resets device
permissions
and perhaps causes unkillable process
Date: Fri, 30 Mar 2
The following reply was made to PR misc/166498; it has been noted by GNATS.
From: Sasa Sasa
To: "freebsd-gnats-sub...@freebsd.org" ,
"freebsd-bugs@FreeBSD.org"
Cc:
Subject: Re: misc/166498: libexec
Date: Fri, 30 Mar 2012 11:43:19 +0100 (BST)
--29941074-773298732-1333104199=:90542
Content-
Hello ...
I don`t no were to go ... And ask for help... And o gona ask you if you want to
help me ! i dont no were to find this lib ...
ld-elf.so.d cand you say to me were i can finde it Please ! ...
Thank you very very much !!
From: "freebsd-gnats-su
On Thu, Mar 29, 2012 at 03:52:23PM -0700, Xin Li wrote:
X> I think we would probably want to put the proposed change under #ifdef
X> PURIFY -- the initialization is not necessary since the uninitialized
X> part is never touched for the whole codepath.
The function isn't performance important, so I
