On Feb 01 17:00:29, dera...@openbsd.org wrote:
> I don't understand your point. We should not require shell-script writers
> to read C manual pages. Imagine the following:
>
> DESCRIPTION
> The cat utility calls open(2) for files sequentially, then read(2)'s the
> contents into a
On Tue, 01 Feb 2022 17:00:29 -0700, "Theo de Raadt" wrote:
> I don't see a problem with explaining what a program does in simple,
> clear english.
Agreed.
- todd
I don't understand your point. We should not require shell-script writers
to read C manual pages. Imagine the following:
DESCRIPTION
The cat utility calls open(2) for files sequentially, then read(2)'s the
contents into a buffer before using write(2) the standard output.
No. I don't
On Tue, Feb 01, 2022 at 01:33:19PM -0700, Todd C. Miller wrote:
> On Tue, 01 Feb 2022 09:59:51 -0600, Scott Cheloha wrote:
>
> > To recap:
> >
> > - Refactor the open/close portions of cook_args() and raw_args() into a
> >single function, cat_file().
> >
> > - Push the flag-check branch in
On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote:
> > Are you running with any malloc flags?
>
> This bug report enabled me to find a bug that would pop up if G mode
> is enabled.
>
> New diff below. New tests appreciated.
It passed a full regress run on amd64 with vm.malloc_conf
Looking at the source, it's simply strcoll().
Jan
Index: bin/expr/expr.1
===
RCS file: /cvs/src/bin/expr/expr.1,v
retrieving revision 1.24
diff -u -p -r1.24 expr.1
--- bin/expr/expr.1 16 Aug 2017 20:10:58 -
Index: yppoll/yppoll.c
===
RCS file: /cvs/src/usr.sbin/yppoll/yppoll.c,v
retrieving revision 1.15
diff -u -p -r1.15 yppoll.c
--- yppoll/yppoll.c 16 Jan 2015 06:40:22 - 1.15
+++ yppoll/yppoll.c 1 Feb 2022 22:35:00
On Tue, 01 Feb 2022 09:59:51 -0600, Scott Cheloha wrote:
> To recap:
>
> - Refactor the open/close portions of cook_args() and raw_args() into a
>single function, cat_file().
>
> - Push the flag-check branch in main() down into cat_file().
>
> - Pull the argv loop in cat_file() up into
Mark Kettenis wrote:
> So yes, it would be good if visa@ could add the startup.sh creation
> code to installboot for arm64, armv7 and riscv64.
That would help.
The non-efi setups will remain pretty stupid, lots of special cases.
The long term idea is to have all that the installboot(8)
> From: "Theo de Raadt"
> Date: Tue, 01 Feb 2022 10:48:39 -0700
>
> Mark Kettenis wrote:
>
> > > From: "Theo de Raadt"
> > > Date: Tue, 01 Feb 2022 09:28:59 -0700
> > >
> > > A few comments.
> > >
> > > I think this approach is increasingly fragile, because a change for one
> > >
Mark Kettenis wrote:
> Maybe we should rename the file to efi_installboot.c and/or rearrange
> the code slightly such that is becomes more obvious that the name of
> the file is indeed the only difference.
And obviously, efi_installboot.c would do this on all efi architectures:
echo
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Tue, 01 Feb 2022 09:28:59 -0700
> >
> > A few comments.
> >
> > I think this approach is increasingly fragile, because a change for one
> > architecture will affect others.
> >
> > > -.elif ${MACHINE} == "armv7" || ${MACHINE} ==
> From: "Theo de Raadt"
> Date: Tue, 01 Feb 2022 09:28:59 -0700
>
> A few comments.
>
> I think this approach is increasingly fragile, because a change for one
> architecture will affect others.
>
> > -.elif ${MACHINE} == "armv7" || ${MACHINE} == "arm64"
> > +.elif ${MACHINE} == "armv7" ||
A few comments.
I think this approach is increasingly fragile, because a change for one
architecture will affect others.
> -.elif ${MACHINE} == "armv7" || ${MACHINE} == "arm64"
> +.elif ${MACHINE} == "armv7" || ${MACHINE} == "arm64" || ${MACHINE} ==
> "riscv64"
> SRCS += armv7_installboot.c
This makes the installer use installboot(8) on riscv64.
OK?
Index: riscv64/ramdisk/install.md
===
RCS file: src/distrib/riscv64/ramdisk/install.md,v
retrieving revision 1.3
diff -u -p -r1.3 install.md
--- riscv64/ramdisk/install.md
On Wed, Dec 15, 2021 at 11:51:48AM +, Ricardo Mestre wrote:
>
> [...]
>
> the filename parameter on cook_buf is just used to show a warning, but it
> should
> be "stdin" instead of "(stdin)" to keep the same old behaviour.
Yep, fixed.
> additionally, please add a blank line after the
Errata patches for kernel Intel GPU driver and expat XML library
have been released for OpenBSD 6.9 and 7.0.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
On Mon, Jan 31, 2022 at 07:40:34PM +, Miod Vallat wrote:
> > The register is set to -1, all bits set, and then its upper half
> > is cleared. Now that the "and" has been removed, the value seems
> > unused. The result of the removed "and" seemed unused too.
>
> Oh, indeed, you're right, that
• Stuart Henderson [2022-02-01 11:28]:
> > Hi, tech
> >
> > I tried misc@ first, but then without a patch. Now diff is at the end of
> > the message.
> >
> > Currently, /etc/examples/httpd.conf uses HTTP 302 to do a redirect, but
> > apparently 307 should give a more predictable behaviour.
> >
On 2022/02/01 11:50, Kirill Miazine wrote:
> Hi, tech
>
> I tried misc@ first, but then without a patch. Now diff is at the end of
> the message.
>
> Currently, /etc/examples/httpd.conf uses HTTP 302 to do a redirect, but
> apparently 307 should give a more predictable behaviour.
>
> According
Hi, tech
I tried misc@ first, but then without a patch. Now diff is at the end of
the message.
Currently, /etc/examples/httpd.conf uses HTTP 302 to do a redirect, but
apparently 307 should give a more predictable behaviour.
According to
21 matches
Mail list logo
