On Wed, Aug 20, 2014 at 5:23 AM, Visa Hankala wrote:
> On Tue, Aug 19, 2014 at 10:14:59PM -0700, Philip Guenther wrote:
> > Can you describe what you're using that needs it?
>
> Well, I am not using it. The code has not been sent to the Attic yet and
> I happened to take a look at it. That is all
Compared the new mime.types file to the one from nginx and found this.
Index: mime.types
===
RCS file: /cvs/src/share/misc/mime.types,v
retrieving revision 1.1
diff -u -p -r1.1 mime.types
--- mime.types 25 Aug 2014 14:27:54 -
On 08/27/14 16:59, Philip Guenther wrote:
On Wed, Aug 27, 2014 at 11:50 AM, Miod Vallat wrote:
Why not keep the softdep flag when updating rw->ro?
E.g. via mount -ur /usr/obj
fstab(5) already allows ro+softdep.
Because if we were to apply this diff, there would be no way to switch
from rw+sof
On Wed, Aug 27, 2014 at 11:50 AM, Miod Vallat wrote:
> > Why not keep the softdep flag when updating rw->ro?
> > E.g. via mount -ur /usr/obj
> > fstab(5) already allows ro+softdep.
>
> Because if we were to apply this diff, there would be no way to switch
> from rw+softdep to rw.
>
And what exac
> Why not keep the softdep flag when updating rw->ro?
> E.g. via mount -ur /usr/obj
> fstab(5) already allows ro+softdep.
Because if we were to apply this diff, there would be no way to switch
from rw+softdep to rw.
Why not keep the softdep flag when updating rw->ro?
E.g. via mount -ur /usr/obj
fstab(5) already allows ro+softdep.
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig Wed Aug 27 19:00:31 2014
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c Wed Aug 27 19:01:19 2014
@@ -218,10 +218,9 @@
On 27 August 2014 08:25, Brad Smith wrote:
> Looking for some testing of the following diff to add Jumbo support for the
> BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766
> chipsets.
>
>
i have tested this on "Broadcom BCM5719" rev 0x01, unknown BCM5719 (0x5719001),
APE fi
On 27 August 2014 13:23, David Gwynne wrote:
> On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
>> On 20/08/14 8:03 PM, David Gwynne wrote:
>> >sthen@ says this is likely a bit optimistic. while most of our drivers
>> >unconditionally configure their max mru, there's some stupid ones t
Hi Jonathan,
First, thanks for your feedback and for your patch.
On Wed, Aug 27, 2014 at 02:42:43AM +1000, Jonathan Gray wrote:
> Rather than calling acpi_setfan() again would it make
> sense to remove the cached state value and move
> the state reading to just before the method is called?
>
> T
On 27 August 2014 13:17, David Gwynne wrote:
> On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
>> On 20/08/14 8:03 PM, David Gwynne wrote:
>> >sthen@ says this is likely a bit optimistic. while most of our drivers
>> >unconditionally configure their max mru, there's some stupid ones t
On Wed, Aug 27, 2014 at 01:52:19PM +0200, Christian Weisgerber wrote:
> Add httpd default log files to the rotation.
>
> Index: newsyslog.conf
> ===
> RCS file: /cvs/src/etc/newsyslog.conf,v
> retrieving revision 1.32
> diff -u -p -r1
Add httpd default log files to the rotation.
Index: newsyslog.conf
===
RCS file: /cvs/src/etc/newsyslog.conf,v
retrieving revision 1.32
diff -u -p -r1.32 newsyslog.conf
--- newsyslog.conf 26 Aug 2014 19:33:48 - 1.32
+++
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
> On 20/08/14 8:03 PM, David Gwynne wrote:
> >sthen@ says this is likely a bit optimistic. while most of our drivers
> >unconditionally configure their max mru, there's some stupid ones that still
> >interpret the configured mtu as a wha
On Tue, Aug 26, 2014 at 09:11:14PM -0400, Brad Smith wrote:
> On 20/08/14 8:03 PM, David Gwynne wrote:
> >sthen@ says this is likely a bit optimistic. while most of our drivers
> >unconditionally configure their max mru, there's some stupid ones that still
> >interpret the configured mtu as a wha
14 matches
Mail list logo
