Andrew Hewus Fresh wrote:
> I noticed this when testing how signal handling worked in fw_update, it
> turns out that if you `pkill -KILL -f fw_update` it may leave behind a perl
> process that is locking the package database. Instead of just waiting
> to be killed, we can have that process check
On 8/22/23 22:55, Andrew Hewus Fresh wrote:
> I noticed this when testing how signal handling worked in fw_update, it
> turns out that if you `pkill -KILL -f fw_update` it may leave behind a perl
> process that is locking the package database. Instead of just waiting
> to be killed, we can have
I noticed this when testing how signal handling worked in fw_update, it
turns out that if you `pkill -KILL -f fw_update` it may leave behind a perl
process that is locking the package database. Instead of just waiting
to be killed, we can have that process check to see if its parent is
still
We've run into a few errors due to very long variable expansion in bsd.port.mk
that overflows execve(2)
I would consider adding a modifier to give the length of a variable, so
that significant tests can be done, along the lines of
.if ${VARIABLE:len} > 20
ERRORS += "Fatal: variable may
Hello, and sorry for delay.
OpenBSD/luna88k GENERIC.MP kernel with your diff boots up normally on my
real hardware.
I am trying to "make build" on that kernel and it is working now, maybe
it takes more 1~2 days.
-- aoyama
On 2023/08/20 3:44, Scott Cheloha wrote:
On Sun, Aug 13, 2023 at
On Tue, Aug 22, 2023 at 02:33:39PM +0200, Peter J. Philipp wrote:
> Hi,
>
> I have an outstanding bug report that I send to deraadt and claudio, in
> reading the code I came across these macros:
>
> https://github.com/openbsd/src/blame/master/sys/sys/cdefs.h
>
> lines 195 and 196. Now my
On Tue, Aug 22, 2023 at 02:33:39PM +0200, Peter J. Philipp wrote:
> Hi,
>
> I have an outstanding bug report that I send to deraadt and claudio, in
> reading the code I came across these macros:
>
> https://github.com/openbsd/src/blame/master/sys/sys/cdefs.h
>
> lines 195 and 196. Now my
> lines 195 and 196. Now my question, does this not sorta look wrong?
>
> Shouldn't these values be a little more unique? As in not the same?
No, these are correct. These lines are used when the compiler does not
support __predict_false and __predict_true, so __predict_whaterver(x)
has to
Hi,
I have an outstanding bug report that I send to deraadt and claudio, in
reading the code I came across these macros:
https://github.com/openbsd/src/blame/master/sys/sys/cdefs.h
lines 195 and 196. Now my question, does this not sorta look wrong?
Shouldn't these values be a little more
On Tue, 2023-08-22 at 13:27 +0200, Martijn van Duren wrote:
> On Tue, 2023-08-22 at 10:16 +, Gerhard Roth wrote:
> > On Tue, 2023-08-22 at 11:16 +0200, Martijn van Duren wrote:
> > > On Mon, 2023-08-21 at 07:35 +, Gerhard Roth wrote:
> > > > Hi Martijn,
> > > >
> > > > last November you
On Tue, 2023-08-22 at 10:16 +, Gerhard Roth wrote:
> On Tue, 2023-08-22 at 11:16 +0200, Martijn van Duren wrote:
> > On Mon, 2023-08-21 at 07:35 +, Gerhard Roth wrote:
> > > Hi Martijn,
> > >
> > > last November you fixed ber.c so that sequences won't generate
> > > an uninitialized
On Tue, 2023-08-22 at 11:16 +0200, Martijn van Duren wrote:
> On Mon, 2023-08-21 at 07:35 +, Gerhard Roth wrote:
> > Hi Martijn,
> >
> > last November you fixed ber.c so that sequences won't generate
> > an uninitialized subelement.
> >
> > This revealed another bug in ober_scanf_elements():
On Mon, 2023-08-21 at 07:35 +, Gerhard Roth wrote:
> Hi Martijn,
>
> last November you fixed ber.c so that sequences won't generate
> an uninitialized subelement.
>
> This revealed another bug in ober_scanf_elements(): it couldn't
> process sequences with an empty list of subelements. The
13 matches
Mail list logo
