On Mon, Jul 14, 2014 at 8:44 AM, Jean-Philippe Ouellet <
jean-phili...@ouellet.biz> wrote:
> The C standard mandates that static be first.
>
> From ISO/IEC 9899:1999 and 9899:201x,
> 6.11.5 - Storage-class specifiers:
> The placement of a storage-class specifier other than at the
> beginni
On Sat, Jul 19, 2014 at 06:57:47PM +0200, olli hauer wrote:
> On 2014-07-19 17:51, Jason McIntyre wrote:
> > On Sat, Jul 19, 2014 at 09:00:16AM +, ?? ?? wrote:
> >> On Sat, Jul 19, 2014 at 07:55:12AM +0100, Jason McIntyre wrote:
> >>> On Sat, Jul 19, 2014 at 06:41:35AM +
On Sat, Jul 19, 2014 at 6:57 PM, Doug Hogan wrote:
> On Sat, Jul 19, 2014 at 06:40:54PM -0700, Philip Guenther wrote:
> > Nice job! Committed (except for the microcode/bwi file where your diff
> > revealed another existing bug that we can fix at the same time...)
>
> Thanks! Here's the patch wi
On Thu, Jul 17, 2014 at 7:27 PM, Doug Hogan wrote:
> Ran into this while running the regression suite for another patch.
>
> The regression test for open_memstream causes a SIGBUS because it closes
> the stream too early.
>
> Replaced fclose with fflush since they both update pbuf and psize.
> Ad
On Sat, Jul 19, 2014 at 06:40:54PM -0700, Philip Guenther wrote:
> Nice job! Committed (except for the microcode/bwi file where your diff
> revealed another existing bug that we can fix at the same time...)
Thanks! Here's the patch with the existing bug fixed. I checked other
places for err/war
On Sat, Jul 19, 2014 at 2:36 PM, Doug Hogan wrote:
> Strings changed in the warning message.
>
Committed; thanks!
On Fri, Jul 11, 2014 at 10:44 PM, Doug Hogan wrote:
> This patch is generated by coccinelle, but I reviewed it. I changed the
> lpr patch to use warnc() so it has less code executing inside
> PRIV_START.
>
> I targeted if statements where it modifies errno before warn or err is
> called. It che
regress/sys/kern/extent is failing because of the userland definitions
in sys/kern/subr_extent.c.
Even though subr_extent.c includes sys/pool.h, the struct pool definition
is guarded for _KERNEL and _LIBKVM. I added a simple struct pool
definition that meets the needs of the dummy pool_* function
Strings changed in the warning message.
Index: regress/gnu/egcs/gcc-builtins/stpcpy-1.c.exp
===
RCS file: /cvs/src/regress/gnu/egcs/gcc-builtins/stpcpy-1.c.exp,v
retrieving revision 1.2
diff -u -p -d -r1.2 stpcpy-1.c.exp
--- regress/
On Sat, Jul 19, 2014 at 06:55:02PM +, Miod Vallat wrote:
> What flags were you using? As its name implies, this test causes a lot
> of memory to be allocated, so malloc flags such as F and G will take a
> toll...
I was using G since I had S enabled.
> > I think that was the cause of the kqueu
> > Ah, I see; you're running `make regress' ; simply running `make' should
> > work correctly (it implies building, and the running the regress target,
> > when Makefile includes ).
>
> That would fix it for the local case inside of /usr/src/regress. Wouldn't
> it still be an issue at the top le
On Sat, Jul 19, 2014 at 06:59:14PM +, Miod Vallat wrote:
> Ah, I see; you're running `make regress' ; simply running `make' should
> work correctly (it implies building, and the running the regress target,
> when Makefile includes ).
That would fix it for the local case inside of /usr/src/regr
Ah, I see; you're running `make regress' ; simply running `make' should
work correctly (it implies building, and the running the regress target,
when Makefile includes ).
> > That's odd. This test only takes a few seconds on an amd64 system. Do
> > you have any local changes to libc, or any particular /etc/malloc.conf
> > settings, which could explain the slowdown?
>
> Ahh you caught me. Yes, I had /etc/malloc.conf settings. I'll try it
> again without those sett
> I have a log from a partial run of 'make regression-tests' (I hit a bug
> in kqueue which hangs indefinitely) and it showed up as failing. I went
> into libexec/ld.so/randomdata and ran 'make depend regress' and it doesn't
> work without that patch.
>
> It would get built if something called 'm
> Date: Sat, 19 Jul 2014 18:16:56 +
> From: Miod Vallat
>
> > REGRESS_SKIP_SLOW didn't work as intended. Default is no yet it checks
> > for !empty.
>
> Good catch! Applied, thanks.
>
> > Added t-exhaust as slow because it takes > 90 minutes on my recent CPU.
>
> That's odd. This test onl
On Sat, Jul 19, 2014 at 06:16:56PM +, Miod Vallat wrote:
> > Added t-exhaust as slow because it takes > 90 minutes on my recent CPU.
>
> That's odd. This test only takes a few seconds on an amd64 system. Do
> you have any local changes to libc, or any particular /etc/malloc.conf
> settings, wh
On Sat, Jul 19, 2014 at 06:03:18PM +, Miod Vallat wrote:
> They do; the magic to build libaa comes from
> regress/libexec/ld.so/randomdata/Makefile.inc .
>
> There are no regress tests to run in the libaa directory itself, but it
> needs to be in SUBDIR to get the obj directory and symlink cre
> REGRESS_SKIP_SLOW didn't work as intended. Default is no yet it checks
> for !empty.
Good catch! Applied, thanks.
> Added t-exhaust as slow because it takes > 90 minutes on my recent CPU.
That's odd. This test only takes a few seconds on an amd64 system. Do
you have any local changes to libc,
Applied, thanks!
> Index: regress/sys/kern/rcvtimeo/rcvtimeo.c
> ===
> RCS file: /cvs/src/regress/sys/kern/rcvtimeo/rcvtimeo.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 rcvtimeo.c
> --- regress/sys/kern/rcvtimeo/rcvtimeo.c 2
> The regression tests under randomdata do not work. They must build
> libaa before running. libaa doesn't have a target for regress so
> even though it's a SUBDIR in ../Makefile, it doesn't do anything.
They do; the magic to build libaa comes from
regress/libexec/ld.so/randomdata/Makefile.inc .
REGRESS_SKIP_SLOW didn't work as intended. Default is no yet it checks
for !empty.
Added t-exhaust as slow because it takes > 90 minutes on my recent CPU.
Index: regress/lib/libc/regex/Makefile
===
RCS file: /cvs/src/regress/lib/li
Index: regress/sys/kern/rcvtimeo/rcvtimeo.c
===
RCS file: /cvs/src/regress/sys/kern/rcvtimeo/rcvtimeo.c,v
retrieving revision 1.4
diff -u -p -r1.4 rcvtimeo.c
--- regress/sys/kern/rcvtimeo/rcvtimeo.c2 Sep 2003 23:52:17 -
Initfirst needs the same fix as randomdata.
Index: regress/libexec/ld.so/initfirst/test2/libaa/Makefile
===
RCS file: /cvs/src/regress/libexec/ld.so/initfirst/test2/libaa/Makefile,v
retrieving revision 1.1
diff -u -p -d -r1.1 Makefil
On 2014-07-19 17:51, Jason McIntyre wrote:
> On Sat, Jul 19, 2014 at 09:00:16AM +, ?? ?? wrote:
>> On Sat, Jul 19, 2014 at 07:55:12AM +0100, Jason McIntyre wrote:
>>> On Sat, Jul 19, 2014 at 06:41:35AM +, ?? ?? wrote:
On Sat, Jul 19, 2014 at 07:0
On Sat, Jul 19, 2014 at 09:00:16AM +, ?? ?? wrote:
> On Sat, Jul 19, 2014 at 07:55:12AM +0100, Jason McIntyre wrote:
> > On Sat, Jul 19, 2014 at 06:41:35AM +, ?? ?? wrote:
> > > On Sat, Jul 19, 2014 at 07:01:57AM +0059, Jason McIntyre wrote:
> > > > O
The regression tests under randomdata do not work. They must build
libaa before running. libaa doesn't have a target for regress so
even though it's a SUBDIR in ../Makefile, it doesn't do anything.
Index: regress/libexec/ld.so/randomdata/libaa/Makefile
==
Sync with reality.
Index: arc4random.3
===
RCS file: /cvs/src/lib/libc/crypt/arc4random.3,v
retrieving revision 1.33
diff -u -p -r1.33 arc4random.3
--- arc4random.39 Jul 2014 16:57:49 - 1.33
+++ arc4random.31
On 19 lip 2014, at 15:25, Doug Hogan wrote:
> On Sat, Jul 19, 2014 at 12:28:17PM +0100, Stuart Henderson wrote:
>> Personally I remember a few nearby mirror URLs, but I do think this could
>> be improved - we could add a sample pkg.conf file to /etc/examples with
>> a list of mirrors updated from
On Sat, Jul 19, 2014 at 12:28:17PM +0100, Stuart Henderson wrote:
> Personally I remember a few nearby mirror URLs, but I do think this could
> be improved - we could add a sample pkg.conf file to /etc/examples with
> a list of mirrors updated from mirrors.dat. Unless there are objections to
> that
On 2014/07/19 12:28, Stuart Henderson wrote:
> On 2014/07/19 01:29, Ville Valkonen wrote:
> > what would you suggest for situations where installXX.iso is burned to
> > a CD to avoid downloading sets from the net due a slow Internet
> > connection? When sets are installed from the CD it doesn't set
On Sat, Jul 19, 2014 at 12:28:17PM +0100, Stuart Henderson wrote:
> On 2014/07/19 01:29, Ville Valkonen wrote:
> > what would you suggest for situations where installXX.iso is burned to
> > a CD to avoid downloading sets from the net due a slow Internet
> > connection? When sets are installed from
On 2014/07/19 01:29, Ville Valkonen wrote:
> what would you suggest for situations where installXX.iso is burned to
> a CD to avoid downloading sets from the net due a slow Internet
> connection? When sets are installed from the CD it doesn't set
> PKG_PATH. I couldn't find any mirror list from the
On Sat, Jul 19, 2014 at 07:55:12AM +0100, Jason McIntyre wrote:
> On Sat, Jul 19, 2014 at 06:41:35AM +, ?? ?? wrote:
> > On Sat, Jul 19, 2014 at 07:01:57AM +0059, Jason McIntyre wrote:
> > > On Sat, Jul 19, 2014 at 05:26:41AM +, ?? ?? wrote:
> > > > T
34 matches
Mail list logo
