Hi @tech,
I just got through building a new desktop machine and thought I'd
install OpenBSD -current on it. The install kernel booted quite fast,
but now that I have the real kernel there, it takes approximately 5
minutes to boot. The vast majority of the time is spent at the very
beginning
Hi,
Now that I'm finally on my new home and tree is opened again...
hotplugd(8) needs to open(2) `device' with read permissions, /dev/hotplug by
default but can be changed via arguments. Then it needs read/execute on both
_PATH_ETC_HOTPLUG_{ATTACH,DETACH} to access(2) and execl(3) them.
Tested
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file:
Remi Locherer(remi.loche...@relo.ch) on 2019.04.22 11:07:18 +0200:
> Hi,
>
> when ospfd originates LSAs for p2p interfaces it puts the interface
> address into the link id field where it should use the network address.
>
> The issue was reported by Mitchell Krome on tech@ and one part of the
>
On Mon, Apr 22, 2019 at 10:06:44PM +, Bryan Everly wrote:
> Hi @tech,
>
> I just got through building a new desktop machine and thought I'd
> install OpenBSD -current on it. The install kernel booted quite fast,
> but now that I have the real kernel there, it takes approximately 5
> minutes
Hi,
I had a patch with pledge(2) for quite a while ago, but my setup is too simple
and cannot test it enough so at least we can have restricted read access to the
fs in relayd(8)'s main process through unveil(2).
Comments? OK?
Index: relayd.c
On Thu, Apr 11, 2019 at 04:32:28PM +0200, Tobias Heider wrote:
> Hi,
>
> this patch fixes a bug that appears after simultaneous
> rekeying of the ikesa. Currently the initiator does not set it's
> IKED_REQ_INFORMATIONAL flag when sending the delete request and thus rejects
> the response to the
Hi,
when ospfd originates LSAs for p2p interfaces it puts the interface
address into the link id field where it should use the network address.
The issue was reported by Mitchell Krome on tech@ and one part of the
problem was fixed in rde_spf.c revision 1.77.
-->
> Date: Mon, 22 Apr 2019 12:12:18 +0200
> From: Stefan Sperling
>
> This should make scans on iwn(4) more reliable.
>
> At present the calculation of 'passive' in iwn_get_passive_dwell_time()
> serves no purpose because iwn_limit_dwell() ignores its second parameter.
> This looks like an
This should make scans on iwn(4) more reliable.
At present the calculation of 'passive' in iwn_get_passive_dwell_time()
serves no purpose because iwn_limit_dwell() ignores its second parameter.
This looks like an accident.
Effectively, this diff extends channel dwell time during passive scans
by
Here is the lost manpage.
Index: Makefile
===
RCS file: /cvs/src/share/man/man4/man4.octeon/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile12 Jan 2019 17:07:16 - 1.13
+++ Makefile22 Apr
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 pointed out
- converted -1 to SIZE_MAX whereever
Tobias Stoeckmann wrote:
> Changing n means that at least timeout_correct in event.c must be
> adjusted as well, because it is used as an unsigned:
ah, good catch. I don't think it's wrong (until it overflows) but needs to be
fixed. Needs some more review then. Thanks.
Hi,
In xenocara, we still build a number of video drivers for very old
hardware, that is mostly useless. For AGP, I don't have a working
motherboard to test the cards I still have.
I also still have a few PCI cards for some of them, but most of them
are dead, or don't work as primary display with
On Sun, Apr 21, 2019 at 08:53:11PM +0200, Alexander Bluhm wrote:
> I wonder whether SIZE_T_MAX would be better than -1. But they seem
> to be equivalent.
I prefer SIZE_T_MAX as well.
> > Index: min_heap.h
> > ===
> > RCS file:
On Thu, Mar 14, 2019 at 09:31:59PM +0100, Matthieu Herrb wrote:
> Hi,
>
> all tools dealing with X font server have been already removed, and
> don't seem to be missed since no one asked to re-add them in ports.
>
> Now, libFS, the font server client library can be removed.
> I've checked in
(sorry this isn't coming with In-Reply-To/References headers as I
read Matthieu's post on marc.info via Mastodon)
> So rather that try to blindly fix the issues with these drivers I'd
> rather remove them. This is the list of candidates for removing.
>
> If you're still using a machine with a
17 matches
Mail list logo
