On Wed, Apr 24, 2019 at 11:16:18PM +0200, Remi Locherer wrote:
> On Wed, Apr 24, 2019 at 08:54:08AM +0100, Jason McIntyre wrote:
> > On Wed, Apr 24, 2019 at 08:11:42AM +0100, Stuart Henderson wrote:
> > > On 2019/04/23 23:53, Remi Locherer wrote:
> > > > Hi,
> > > >
> > > > with below diff the usb
On Wed, Apr 24, 2019 at 08:54:08AM +0100, Jason McIntyre wrote:
> On Wed, Apr 24, 2019 at 08:11:42AM +0100, Stuart Henderson wrote:
> > On 2019/04/23 23:53, Remi Locherer wrote:
> > > Hi,
> > >
> > > with below diff the usb serial adapter built into the SRX 300 attaches
> > > to uslcom and can be
> Date: Wed, 24 Apr 2019 22:32:29 +0200
> From: Christian Weisgerber
>
> If you boot efiboot via PXE and at the prompt enter a different boot
> device, e.g.
>
> boot> boot sd0a:/bsd
>
> then efiboot will pretend to honor this
>
> booting sd0a:/bsd: ...
>
> but in fact ignore the device an
If you boot efiboot via PXE and at the prompt enter a different boot
device, e.g.
boot> boot sd0a:/bsd
then efiboot will pretend to honor this
booting sd0a:/bsd: ...
but in fact ignore the device and boot from TFTP instead.
In the MI part of the boot loader, open() calls devopen(), which
sven falempin wrote:
> Dear Tech reader,
>
> NTPD -S is useful, when a device is in storage for a while the clock is in
> disarray.
> But this assume the network exists, the fixed 15 seconds timeout makes
> sense,
> nevertheless it could be too long or too short.
>
> https://pastebin.com/gmNGpX
sven falempin [sven.falem...@gmail.com] wrote:
>
> Alast why not just wait for something to respond and then set time ??
> This (bit ugly) diff reveals some dead code in ntpd
>
> https://pastebin.com/9PwqBDHz
>
> Is there another way to bootstrap time correctly ?
>
ntpd will wait under normal
Dear Tech reader,
NTPD -S is useful, when a device is in storage for a while the clock is in
disarray.
But this assume the network exists, the fixed 15 seconds timeout makes
sense,
nevertheless it could be too long or too short.
https://pastebin.com/gmNGpXLq
Also NTPD just log out the failure af
Noticed by visa@
Index: Makefile
===
RCS file: /cvs/src/share/man/man4/man4.armv7/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile1 Feb 2019 01:41:52 - 1.24
+++ Makefile24 Apr 2019 15:53:05
On 4/24/19 4:15 PM, Florian Obser wrote:
> On Wed, Apr 24, 2019 at 09:34:57AM -0400, Bryan Steele wrote:
>> On Wed, Apr 24, 2019 at 03:08:59PM +0200, Fabio Scotoni wrote:
>>> [...]
>>
>> Isn't RF C8555 ACMEv2? acme-client(1) only supports ACMEv1, so I don't
>> think this is correct.
>>
>
> Indeed,
On Wed, Apr 24, 2019 at 09:34:57AM -0400, Bryan Steele wrote:
> On Wed, Apr 24, 2019 at 03:08:59PM +0200, Fabio Scotoni wrote:
> > This diff updates the acme-client(1) STANDARDS section.
> > Currently, it lists an RFC draft for the ACME protocol.
> > Since March of this year, there is a proposed st
Tobias Stoeckmann wrote:
> On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> > ah, good catch. I don't think it's wrong (until it overflows) but needs to
> > be
> > fixed. Needs some more review then. Thanks.
>
> I have added following changes:
>
> - converted 0u to 0 as bluhm poi
On Wed, Apr 24, 2019 at 03:08:59PM +0200, Fabio Scotoni wrote:
> This diff updates the acme-client(1) STANDARDS section.
> Currently, it lists an RFC draft for the ACME protocol.
> Since March of this year, there is a proposed standard with an actual
> RFC number.
>
> While at it, make the format
This diff updates the acme-client(1) STANDARDS section.
Currently, it lists an RFC draft for the ACME protocol.
Since March of this year, there is a proposed standard with an actual
RFC number.
While at it, make the format match ssh(1) STANDARDS by providing .%A and
.%D entries.
Index: usr.sbin/a
OpenBSD 6.5 builds finished a week early, so the May 1 dated code can
go out the door 1 week early.
- OpenBSD 6.5 RELEASED -
May 1, 2019.
We are pleased to announce the offici
On 2019 Apr 24 (Wed) at 22:50:58 +1000 (+1000), Jonathan Matthew wrote:
:On Wed, Apr 24, 2019 at 12:21:47PM +0200, Stefan Sperling wrote:
:> On Sun, Apr 21, 2019 at 09:44:08PM +0800, Kevin Lo wrote:
:> > On Sun, Apr 21, 2019 at 01:02:39PM +1000, Jonathan Matthew wrote:
:> > > Currently we have some
On Wed, Apr 24, 2019 at 12:21:47PM +0200, Stefan Sperling wrote:
> On Sun, Apr 21, 2019 at 09:44:08PM +0800, Kevin Lo wrote:
> > On Sun, Apr 21, 2019 at 01:02:39PM +1000, Jonathan Matthew wrote:
> > > Currently we have some drivers with media_change
> > > functions returning the errno from ieee8021
Hi Fabio,
Fabio Scotoni wrote on Wed, Apr 24, 2019 at 06:14:07AM +0200:
> On 4/23/19 9:30 PM, Ingo Schwarze wrote:
>> Fabio Scotoni wrote:
>>> Ingo Schwarze wrote:
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
>>> Nitpick: The other man pages in the usr.bin/r
On Sun, Apr 21, 2019 at 09:44:08PM +0800, Kevin Lo wrote:
> On Sun, Apr 21, 2019 at 01:02:39PM +1000, Jonathan Matthew wrote:
> > Currently we have some drivers with media_change
> > functions returning the errno from ieee80211_media_change (iwn, iwm) and
> > some
> > just returning 0 at the end (
On Wed, Apr 24, 2019 at 08:11:42AM +0100, Stuart Henderson wrote:
> On 2019/04/23 23:53, Remi Locherer wrote:
> > Hi,
> >
> > with below diff the usb serial adapter built into the SRX 300 attaches
> > to uslcom and can be used.
> >
> > uslcom0 at uhub1 port 1 configuration 1 interface 0 "Silicon
On 2019/04/23 23:53, Remi Locherer wrote:
> Hi,
>
> with below diff the usb serial adapter built into the SRX 300 attaches
> to uslcom and can be used.
>
> uslcom0 at uhub1 port 1 configuration 1 interface 0 "Silicon Labs Juniper
> Networks BX Series System Console" rev 1.10/1.01 addr 10
>
> OK
20 matches
Mail list logo
