The "update clang" messages in UPDATING seem to not fix...
...llvm/include/llvm/ADT/StringRef.h: fatal error:
'algorithm' file not found
make stopped in /usr/src/lib/clang/lib/libllvmsupport...
The entire build fails similarly,
also in any subtree I try to start from (clang, lib/clang... etc etc)
On Wed, Jul 08, 2015 at 02:15:38AM +0200, Mateusz Guzik wrote:
> First off note the patch below is a total hack with the easiest solution
> possible so that it can be MFCed for 10.2.
>
> The issue:
>
> Closing the socket involves:
>
> if (pr->pr_flags & PR_RIGHTS && pr->pr_domain->dom_dispose !=
Aleksey Kuleshov wrote:
> The uart_intr will never be called if interrupts are not available.
> Start counter with callout_reset call.
FWIW this fixed an issue we were investgating.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
FreeBSD_HEAD-tests - Build #1170 - Fixed:
Check console output at
https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1170/ to view the results.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To uns
On Thursday, July 9, 2015, Garrett Wollman
wrote:
> In article
> >,
> oliver.pin...@hardenedbsd.org writes:
>
> >Btw, I have found this is atf's documantation:
> >atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the
> >specific test case could "fail" / or expect to coredump.
>
In article
,
oliver.pin...@hardenedbsd.org writes:
>Btw, I have found this is atf's documantation:
>atf_tc_expect_signal(SIGSEGV, "reaseon"), with this, we could mark the
>specific test case could "fail" / or expect to coredump.
No.
I'm not sure why people are having trouble understanding this.
On Wed, Jul 8, 2015 at 5:09 PM, Ermal Luçi wrote:
>
>
> On Tue, Jul 7, 2015 at 6:11 PM, Rink Springer wrote:
>
>> Hi eri@,
>>
>> On Mon, Jul 06, 2015 at 09:21:54AM +0200, Rink Springer wrote:
>> > On Sun, Jul 05, 2015 at 12:45:25PM -0700, Garrett Cooper wrote:
>> > > On Jul 5, 2015, at 8:16, Rin
On 7/9/15, NGie Cooper wrote:
> On Thu, Jul 9, 2015 at 1:41 AM, Konstantin Belousov
> wrote:
>> On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote:
>>> I'm not sure if we want to explicitly document the conditions under
>>> which
>>> gettimeofday() (or clock_gettime()) are implemented i
FreeBSD_HEAD-tests - Build #1169 - Failure:
Check console output at
https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1169/ to view the results.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To u
On 9 Jul 2015, at 10:17, NGie Cooper wrote:
>
> I agree that this is less applicable for FreeBSD than NetBSD. Please
> keep in mind that contrib/netbsd-tests came from NetBSD, not FreeBSD.
> Peter Holm and I tried our best to vet out the issues with the test
> suite before integrating it in, but
On Thu, Jul 9, 2015 at 1:41 AM, Konstantin Belousov wrote:
> On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote:
>> I'm not sure if we want to explicitly document the conditions under which
>> gettimeofday() (or clock_gettime()) are implemented in userland vs syscalls
>> because that is
On Thu, Jul 09, 2015 at 08:27:17AM +1000, Peter Jeremy wrote:
> I'm not sure if we want to explicitly document the conditions under which
> gettimeofday() (or clock_gettime()) are implemented in userland vs syscalls
> because that is guaranteed to get stale over time. How about stating that
Of cou
12 matches
Mail list logo
