> On Thu, Jun 6, 2013 at 11:48 AM, Theo de Raadt
> wrote:
> [...]
> > If anyone thinks using this for the install or boot media is going to
> > help, don't say a word until you can prove it on all platforms.
>
> Has anyone looked at zopfli[1] for the install media? It's a (apache
> 2 licensed)
The following provides address pools for iked. It's nothing fancy, but
it seems to work, at least in the cursory testing done against the
Windows 7 client.
Each policy gets it's own pool, configured by "config address - ".
There is a hard limit of 65536 addresses (8kb) per pool, which should be p
On Thu, Jun 6, 2013 at 11:48 AM, Theo de Raadt wrote:
[...]
> If anyone thinks using this for the install or boot media is going to
> help, don't say a word until you can prove it on all platforms.
Has anyone looked at zopfli[1] for the install media? It's a (apache
2 licensed) slightly better b
On Thu, Jun 06, 2013 at 23:53, Sylvestre Gallon wrote:
> Hi,
>
> Sorry for the last mistakes. Here is a new diff that allow the
> maxtypenum to be reached.
>
> Cheers,
>
> Index: sysctl.c
> ===
> RCS file: /cvs/src/sbin/sysctl/sysct
On Thu, Jun 06, 2013 at 15:39, Sylvestre Gallon wrote:
> If you look at sys/kern/vfs_init.c MOUNT_FUSEFS use the biggest typenum : 18.
> So when the function vfsinit in sbin/sysctl.c gets VFS_MAXTYPENUM it gets
> 18, but this value will never be reached in the for statement...
The diff below does
And here the third one that removes all warns for :
WARNINGS=yes make
Cheers,
Index: sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.189
diff -u -p -u -p -r1.189 sysctl.c
--- sysctl.c16 Apr 2013 22:0
Here is a second one to add fuse sysctls.
Cheers,
Index: sys/miscfs/fuse/fusefs.h
===
RCS file: /cvs/src/sys/miscfs/fuse/fusefs.h,v
retrieving revision 1.1
diff -u -p -r1.1 fusefs.h
--- sys/miscfs/fuse/fusefs.h3 Jun 2013 15:50:56
Hi,
Sorry for the last mistakes. Here is a new diff that allow the
maxtypenum to be reached.
Cheers,
Index: sysctl.c
===
RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.189
diff -u -p -r1.189 sysctl.c
--- sysctl.c
> Date: Thu, 6 Jun 2013 09:48:24 -0600 (MDT)
> From: Theo de Raadt
>
> >On Thu, Jun 06, 2013 at 14:20, Mark Kettenis wrote:
> >> I've ranted before about implementing "standard" tools in Perl. The
> >> user experience just isn't the same as with C code.
> >>
> >> But even more so than with nl(1
On Thu, Jun 06, 2013 at 11:42, patrick keshishian wrote:
> Just curious, how do the variable name changes help any
> warrnings?
>
> nflag -> nf
-Wshadow. nflag is a global, which becomes hidden by giving a local
parameter the same name. The code is kind of silly anyway, since the
only call to th
Theo de Raadt wrote:
> It is primarily used by ports.
Before t2k13, there were 739 .tar.bz2|.tbz2 distfiles--compared to
268 .tar.xz|.txz ones. I don't know how fast that balance is
shifting.
There are some 40 ports that directly depend on libbz2, and some
10 more that pull it in indirectly by
On Thu, Jun 06, 2013 at 03:39:38PM +0200, Sylvestre Gallon wrote:
> Hi tech@
>
> I was currently trying to get the fuse sysctls working when I found a bug
> in sbin/sysctl.c
>
> If you look at sys/kern/vfs_init.c MOUNT_FUSEFS use the biggest typenum : 18.
> So when the function vfsinit in sbin/sy
On Thu, Jun 06, 2013 at 15:39, Sylvestre Gallon wrote:
> Hi tech@
>
> I was currently trying to get the fuse sysctls working when I found a bug
> in sbin/sysctl.c
>
> If you look at sys/kern/vfs_init.c MOUNT_FUSEFS use the biggest typenum : 18.
> So when the function vfsinit in sbin/sysctl.c gets
>On Thu, Jun 06, 2013 at 14:20, Mark Kettenis wrote:
>> I've ranted before about implementing "standard" tools in Perl. The
>> user experience just isn't the same as with C code.
>>
>> But even more so than with nl(1), why would we want to use something
>> that's different from what everybody els
On Thu, Jun 06, 2013 at 14:20, Mark Kettenis wrote:
> I've ranted before about implementing "standard" tools in Perl. The
> user experience just isn't the same as with C code.
>
> But even more so than with nl(1), why would we want to use something
> that's different from what everybody else uses
On Thu, Jun 6, 2013 at 4:39 PM, Alexey E. Suslikov
wrote:
> int emulcmp(const void *, const void *);
using WARNINGS=yes make it remove the following warning :
sysctl.c:2697: warning: no previous prototype for 'emulcmp'
Cheers,
--
Sylvestre Gallon
Sylvestre Gallon gmail.com> writes:
> -2586,6 +2587,7 struct emulname {
> } *emul_names;
> int emul_num, nemuls;
> int emul_init(void);
> +int emulcmp(const void *, const void *);
this seems unrelated to rest of changes you've made. no?
Hi tech@
I was currently trying to get the fuse sysctls working when I found a bug
in sbin/sysctl.c
If you look at sys/kern/vfs_init.c MOUNT_FUSEFS use the biggest typenum : 18.
So when the function vfsinit in sbin/sysctl.c gets VFS_MAXTYPENUM it gets
18, but this value will never be reached in
On Thu, 6 Jun 2013, David Coppa wrote:
> > But even more so than with nl(1), why would we want to use something
> > that's different from what everybody else uses? If we want bzip2 in
> > base (and I think there are good reasons for having it) we should
> > simply use the standard bzip2 code.
>
On Thu, Jun 6, 2013 at 2:20 PM, Mark Kettenis wrote:
>
> I'm a Perl hater
>
>
> I've ranted before about implementing "standard" tools in Perl. The
> user experience just isn't the same as with C code.
>
> But even more so than with nl(1), why would we want to use something
> that's different
> Date: Wed, 05 Jun 2013 20:59:39 -0400
> From: Ted Unangst
>
> Something that comes up from time to time is the question of whether
> to import bzip2 into base or not. Turns out the question is moot
> because already have imported it. There's a copy in perl. (I didn't
> know this until I happene
Hi,
We would like to switch mfii(4) to msi, there is a family of supermicro
X9 motherboards with incorrect ioapic routing, so they only work properly
though msi.
If you have a system with a mfii(4) device, please give this diff a spin
and report back.
So far I was able to test on:
Supermicro X9
On 2013/06/06 08:04, Janne Johansson wrote:
> If it covers that tar needs for "tar xjf bla.tbz2" to work then this would
> be a good addition.
That needs support for -d (and -c but we have that already).
You can use "cvs add" against a mirror to add files. Directories
require write access, so that won't work. Then use "cvs diff -Nup" to
include all of the (N)ew files.
tech@ is the preferred mailing list for diffs.
On 2013 Jun 05 (Wed) at 23:23:53 -0600 (-0600), Ryan Slack wrote:
:I wish to sub
On Wed, Jun 05, 2013 at 02:12:36PM -0400, Ted Unangst wrote:
>
> Conclusion? You'll never notice the difference. Personally I have
> a slight preference for improving worst case behavior.
I've a preference for simpler structures; as long if pid lookup is
not a real problem
-- Alexandre
While the recent work in inteldrm should include
support for haswell we don't currently have the agp
parts or match on the pci devices. This diff updates
things to match on all the devices the linux driver
does with a handful of marketing names found in the
windows driver.
Compile tested only for
26 matches
Mail list logo
