On Tue, Oct 17, 2023 at 03:17:19PM +0200, Martijn van Duren wrote:
> According to RFC3416 section 4.2.2 and 4.2.3 case "(2)" when an
> endOfMibView is returned the OID must be identical to originally
> requested OID. Currently this can fail when the original request
> is
On Tue, Oct 17, 2023 at 03:03:16PM +0200, Martijn van Duren wrote:
>
> RFC2741 section 6.2.2 says that reasonByManager can only be used by the
> agentx master. Treat this reason as a parseerror.
ok tb
According to RFC3416 section 4.2.2 and 4.2.3 case "(2)" when an
endOfMibView is returned the OID must be identical to originally
requested OID. Currently this can fail when the original request
is in a !last registered region and all subsequent regions also
return EOMV.
Store the origin
RFC2741 section 6.2.2 says that reasonByManager can only be used by the
agentx master. Treat this reason as a parseerror.
OK?
martijn@
diff --git a/application_agentx.c b/application_agentx.c
index d1efae2..2231d4c 100644
--- a/application_agentx.c
+++ b/application_agentx.c
@@ -576,16
On Thu, Oct 12, 2023 at 03:21:50PM +0200, Claudio Jeker wrote:
> I optimized "announce add-path send all" to not always re-evaluate all
> possible prefixes. While doing that I introduced a small bug. The problem
> is that the new prefix passed to up_generate_addpath_all() coul
I optimized "announce add-path send all" to not always re-evaluate all
possible prefixes. While doing that I introduced a small bug. The problem
is that the new prefix passed to up_generate_addpath_all() could be not
eligible. This causes up_process_prefix() -> up_test_update() to er
On Fri, Sep 22, 2023 at 01:05:17PM -0500, Brian Conway wrote:
> Greetings. I noticed the above behavior with the latest 7.4-beta when
> scripting some fw_update runs. Perhaps a corner case was missed in the
> recent work? Steps below, let me know if more information is required
>
Greetings. I noticed the above behavior with the latest 7.4-beta when scripting
some fw_update runs. Perhaps a corner case was missed in the recent work? Steps
below, let me know if more information is required to reproduce. Thanks in
advance.
root:current-amd64.124:0:~# fw_update -d intel
On Fri, Sep 22, 2023 at 12:21:42PM +0900, YASUOKA Masahiko wrote:
> A leak may happens when wgpeer is deleted.
>
> ok?
OK bluhm@
> The state queue should be freeed when wg_peer is destroyed.
> diff from IIJ.
>
> I
On Fri, Sep 22, 2023 at 12:21:42PM +0900, YASUOKA Masahiko wrote:
> A leak may happens when wgpeer is deleted.
>
> ok?
>
ok mvs@
> The state queue should be freeed when wg_peer is destroyed.
> diff from IIJ.
>
>
A leak may happens when wgpeer is deleted.
ok?
The state queue should be freeed when wg_peer is destroyed.
diff from IIJ.
Index: sys/net/if_wg.c
===
RCS file: /disk/cvs/openbsd/src/sys/net/if_wg.c,v
retrieving revision 1.29
diff -u
On 2023/09/14 11:55, Moritz Fain wrote:
> > My initial reaction is that it's easy to run "rm -f" before starting
> > the agent with the existing "-a" option.
same.
also if there's an existing agent running you probably don't want to
blindly remove t
> My initial reaction is that it's easy to run "rm -f" before starting
> the agent with the existing "-a" option.
>
> The code seems to use a new variable that should be called "A_flag" if
> it's to follow the existing naming scheme.
Of c
Hello,
I've noticed a bug with whitespace indentation in sed.
Summary: For a,i,c `text` the leading whitespace that is intended to
stay in output should be escaped, or else be ignored. The latter is
not the case for sed(1) - it includes leading whitespace of `text`
in the output, even if
Andreas Kähäri wrote in
:
|On Wed, Sep 13, 2023 at 03:08:40PM +0200, Moritz Fain wrote:
|> Most of the code is already there; it's basically just adding a new flag.
|>
|> Happy to hear your feedback!
|
|My initial reaction is that it's easy to run "rm -f" bef
On Wed, Sep 13, 2023 at 03:08:40PM +0200, Moritz Fain wrote:
> Most of the code is already there; it's basically just adding a new flag.
>
> Happy to hear your feedback!
My initial reaction is that it's easy to run "rm -f" before starting
the agent with the existing
On 2023/09/13 15:08:40 +0200, Moritz Fain wrote:
> Most of the code is already there; it's basically just adding a new flag.
>
> Happy to hear your feedback!
can't comment on the diff itself, but the patch was mangled and so it
doesn't apply.
> --- a/usr.bin/ssh/ssh-
Most of the code is already there; it's basically just adding a new flag.
Happy to hear your feedback!
---
diff --git a/usr.bin/ssh/ssh-agent.1 b/usr.bin/ssh/ssh-agent.1
index 6815eb834d3..731a1cf913d 100644
--- a/usr.bin/ssh/ssh-agent.1
+++ b/usr.bin/ssh/ssh-agent.1
@@ -76,6 +
On Fri, 2023-08-25 at 20:40 +1000, David Gwynne wrote:
> umb(4) is a hardware p2p driver, it just has ip coming in, so we can do
> the same thing we do for the address family and input processing as
> other p2p interfaces.
>
> the short packet check that umb_input does is already
umb(4) is a hardware p2p driver, it just has ip coming in, so we can do
the same thing we do for the address family and input processing as
other p2p interfaces.
the short packet check that umb_input does is already done by the ip
stacks, so we're not losing anything.
i havent got a umb(4),
On Tue, Aug 08, 2023 at 01:02:53PM +0200, Marc Espie wrote:
> Actually, as far as bsd.port.mk, it doesn't need to
> move too much stuff around thanks to make's lazyness.
>
> Note that having a list of defined MASTER_SITES variables simplifies
> the check.
>
>
On Tue, Aug 08, 2023 at 12:51:43PM +0200, Marc Espie wrote:
> Here's a revised diff (reordered plus actual use of the boolean)
> plus concrete example use for bsd.port.mk (disregarding the fact
> _ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.
I te
Actually, as far as bsd.port.mk, it doesn't need to
move too much stuff around thanks to make's lazyness.
Note that having a list of defined MASTER_SITES variables simplifies
the check.
I've also added a check for the right MASTER_SITES to be defined,
since currently we do not
Here's a revised diff (reordered plus actual use of the boolean)
plus concrete example use for bsd.port.mk (disregarding the fact
_ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.
Index: var.c
==
On Mon, Aug 07, 2023 at 10:05:37PM -0400, Thomas Frohwein wrote:
> I looked through the file and it seems that varname_list_changed is
> never set to anything but true. Is there a bit missing, like down lower
> in varname_list_retrieve()?
Yep, I removed it at some point because it lo
t;
> I haven't checked whether NetBSD/FreeBSD introduced something similar.
>
> This is a fairly straightforward patch, introduces .VARIABLES corresponding
> to the full list of global variables (from the command line and the Makefile)
> that have been defined.
>
> (^ says t
I think it could be occasionally useful to know which variables have
been defined in make.
Incidentally, this DOES exist in GNU make, so I've reused the same name
for basically the same functionality.
I haven't checked whether NetBSD/FreeBSD introduced something similar.
This i
On Mon, Jul 17, 2023 at 11:05:03AM +0200, Sebastien Marie wrote:
> On Wed, Jul 12, 2023 at 12:26:01PM +0200, thib4711 wrote:
> > make it obvious in the vfsops assignment that an op isnt supported.
>
> I agree that it is more readable.
>
> ok semarie@
OK claudio@ as well. Semarie can you commit t
On Wed, Jul 12, 2023 at 12:26:01PM +0200, thib4711 wrote:
> make it obvious in the vfsops assignment that an op isnt supported.
I agree that it is more readable.
ok semarie@
thanks.
--
Sebastien Marie
> diff --git sys/isofs/cd9660/cd9660_extern.h sys/isofs/cd9660/cd9660_extern.h
> index 2a5348
make it obvious in the vfsops assignment that an op isnt supported.
diff --git sys/isofs/cd9660/cd9660_extern.h sys/isofs/cd9660/cd9660_extern.h
index 2a5348e1768..bd8154a27bd 100644
--- sys/isofs/cd9660/cd9660_extern.h
+++ sys/isofs/cd9660/cd9660_extern.h
@@ -94,10 +94,8 @@ int cd9660_vptofh(stru
nd improving docs later.
>
> Was this an OK for all of the diff?
Yes, sorry if that wasn't clear.
> Btw. I think this is a better version of the bt.5 change. I moved the map
> specific functions into their own section.
That reads
> usage also seems non-intuitive.
> >
> > I find the documentation of bt(5) rather weak. So more is needed for sure.
>
> Agreed, I'm fine with your diff as-is and improving docs later.
Was this an OK for all of the diff?
Btw. I think this is a better version of the bt.
On Mon, Jun 26, 2023 at 10:52:20PM +0200, Claudio Jeker wrote:
> count() is strange since it only works on maps (at least from what I
> figured out). I need to double check how min() and max() work. Since the
> usage also seems non-intuitive.
>
> I find the documentation of bt(5) rather weak. So m
000 1.14
> > +++ bt.526 Jun 2023 15:16:25 -
> > @@ -120,6 +120,11 @@ Functions:
> > .It Fn clear "@map"
> > Delete all (key, value) pairs from
> > .Va @map .
> > +.It "@map[key]" = Fn count
> > +Increment the value of
> &g
ision 1.14
> diff -u -p -r1.14 bt.5
> --- bt.5 31 Mar 2022 17:27:29 - 1.14
> +++ bt.5 26 Jun 2023 15:16:25 -
> @@ -120,6 +120,11 @@ Functions:
> .It Fn clear "@map"
> Delete all (key, value) pairs from
> .Va @map .
> +.It "@map[key]&
SLIST_FOREACH(bp, &r->br_probes, bp_next) {
debug("parsed probe '%s'", debug_probe_name(bp));
@@ -1685,10 +1702,17 @@ ba2dtflags(struct bt_arg *ba)
long
bacmp(struct bt_arg *a, struct bt_arg *b)
{
- assert(a->ba_type == b-&
/etc/acme-client.conf
```
[...]
api url "https://use.some.domain.com:8443/acme/acme/directory
<https://use.some.domain.com:8443/acme/acme/directory>"
[...]
```
But, when I run acme-client to actually get a certificate it terminates with
the following error:
`
Index: main.c
===
RCS file: /cvs/src/usr.bin/rsync/main.c,v
retrieving revision 1.68
diff -u -p -r1.68 main.c
--- main.c 28 Apr 2023 10:24:38 - 1.68
+++ main.c 10 May 2023 17:43:23 -
@@ -602,6 +602,7 @@ basedir:
as per subject, when dobeep_msgs() was introduced some places weren't
converted correctly: it already adds a space between the two
arguments, so no need to duplicate.
Index: extend.c
===
RCS file: /cvs/src/usr.bin/mg/exten
;
>> 1) does anyone know if there is a way to disable MULTICAST on a single
>> interface?
>> I don't see any option in ifconfig to do this.
>>
>
> There is not.
>
>
>> 2) Can outgoing multicast traffic be routed to a specific interface? I
>> don'
On Wed, Mar 1, 2023 at 9:58 AM Luca Di Gregorio wrote:
> 1) does anyone know if there is a way to disable MULTICAST on a single
> interface?
> I don't see any option in ifconfig to do this.
>
There is not.
> 2) Can outgoing multicast traffic be routed to a specific inte
Hi,
1) does anyone know if there is a way to disable MULTICAST on a single
interface?
I don't see any option in ifconfig to do this.
2) Can outgoing multicast traffic be routed to a specific interface? I
don't see any option in route. It seems that the first interface, by id, is
chose
call.2 16 Feb 2023 04:43:54 - 1.1
> +++ pinsyscall.2 18 Feb 2023 13:13:39 -
> @@ -54,7 +54,7 @@ that system call must be entered from, a
> entry instruction to perform the specified
> .Va syscall
> from a different address range will deliver
> -Dv SIGABRT .
&
-
@@ -54,7 +54,7 @@ that system call must be entered from, a
entry instruction to perform the specified
.Va syscall
from a different address range will deliver
-Dv SIGABRT .
+.Dv SIGABRT .
.Sh RETURN VALUES
.Rv -std
.Sh ERRORS
> > are putting data tables into the .text segment
> > >
> > > I am hoping to find someone who can do c++ well enough, and maybe
> > > has some familiarity with the clang code, to add a warning message
> > > for this
> > >
> > > if a .long
ing to find someone who can do c++ well enough, and maybe
> > has some familiarity with the clang code, to add a warning message
> > for this
> >
> > if a .long, .quad, .byte are placed into a .text section, issue
> > a warning, then we'll be able to identify all
the clang code, to add a warning message
> for this
>
> if a .long, .quad, .byte are placed into a .text section, issue
> a warning, then we'll be able to identify all these in a ports build
> and decide which need manual fixing, and move the objects into .rodata
> and apply _
For this xonly work, we are having to one-by-one find .S files that
are putting data tables into the .text segment
I am hoping to find someone who can do c++ well enough, and maybe
has some familiarity with the clang code, to add a warning message
for this
if a .long, .quad, .byte are placed
On Sat, Jan 14, 2023 at 04:29:04PM +1100, Damien Miller wrote:
>
>
> On Fri, 13 Jan 2023, Damien Miller wrote:
>
> > Hi,
> >
> > Forewarning: this is a big, noisy diff. Also on Github at
> > https://github.com/djmdjm/openssh-wip/pull/18
> >
>
> This isn't completely without noise, but it lets you see the substantive
> changes clearly.
This looks good to me and works fine in my environment. Inlining the
weird get_hram() makes things quite a bit clearer. I can't spot anything
wrong in this diff.
ok tb
On Fri, 13 Jan 2023, Damien Miller wrote:
> Hi,
>
> Forewarning: this is a big, noisy diff. Also on Github at
> https://github.com/djmdjm/openssh-wip/pull/18
>
> This updates the ED25519 code to the latest version of SUPERCOP (20221122),
> but the real motivation fo
on't make bold change anything) as the terminal only supports bright and
> > not true bold.
>
> Hummm. That would break existing behaviour in a few cases.
>
> Although most users are not seeing colour at all on the console, anyone who
> has set TERM=pccon currently has w
Ah, here is a trivial program to demo the new 256 color palette on the console:
#include
int main()
{
int i;
printf ("\x1b[m\n");
for (i=0;i<256;i++) {
printf ("\x1b[38;5;%dm#%03d %s",i,i, ((i+1) % 16 ? "" : "\n"));
}
printf ("
parameters.
NEW - Implement SGR 9x and 10x sequences to select 'bright' foreground and
background colours, (I.E. colours 8 - 15), directly.
- All the features of the previous patches.
So this version is mostly to add 256 colour support. This was mainly a
consequence of needi
nothing.
I've seen one program that uses it when colours <= 8, but that seems to have
been an oversight.
> I would be inclined to just ignore bold together with 256 colours (that is,
> don't make bold change anything) as the terminal only supports bright and
> not true bold.
Hum
tuff
> like
> > SGR 38;5;100;1 won't work.
>
> Well I was initially in two minds about that, because I thought there
> might be
> other un-official extensions that used 38 with a varying number of
> parameters.
>
> But I haven't found any apart from 5 followed by one
uments or stuff
> like
> > SGR 38;5;100;1 won't work.
>
> Well I was initially in two minds about that, because I thought there
> might be
> other un-official extensions that used 38 with a varying number of
> parameters.
>
> But I haven't found any apart from
hat used 38 with a varying number of parameters.
But I haven't found any apart from 5 followed by one argument, and 2 followed
by three RGB values, so yes I agree with you on this.
However, since this morning I've been working on actually implementing 256
colour support so the next vers
You should strictly only discard the following two arguments or stuff like
SGR 38;5;100;1 won't work.
This is why some people prefer the : form but the ship has rather sailed on
that.
On Fri, 6 Jan 2023, 11:52 Crystal Kolipe,
wrote:
> This version of the patchset updates a few thin
On Wed, Jan 04, 2023 at 05:42:31PM -0300, Crystal Kolipe wrote:
| Hopefully it'll fix the problem.
Tested with tmux, the spurious ^@'s are now indeed gone. I see
there's a new diff available, so I'll try that
This version of the patchset updates a few things since the one posted early
on Wednesday:
NEW - Fix two off-by-ones that caused spurious trailing null characters when
requesting the terminal IDs. (Noticed by Paul running tmux.)
NEW - Discard any parameters passed to a CSI 38 m or CSI 48
lied, and my TERM set to
> | > 'xterm', I do get colors in mutt and tmux.
> |
> | Great! Thanks for testing :).
> |
> | > The latter, however, shows
> | > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
> | > behavior I
| Great! Thanks for testing :).
|
| > The latter, however, shows
| > '^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
| > behavior I don't see with a 'real' xterm.
|
| This looks like an off-by-one in the wscons code, (not introduced by me!
;^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
> behavior I don't see with a 'real' xterm.
This looks like an off-by-one in the wscons code, (not introduced by me!)
Does the following patch, (on top of the last one), fix it?
--- dev/wscons/wsemul_v
Hi Crystal,
I tried your patch on my laptop. With it applied, and my TERM set to
'xterm', I do get colors in mutt and tmux. The latter, however, shows
'^@^@' before the PS1 prompt upon starting a new session (`tmux new`),
behavior I don't see with a 'real'
different sequences.
* A new keysym has been added - KS_Backtab.
* Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
* Shift-F1 - Shift-F12 now send F13 - F24.
* Five new escape sequences added for cursor movement.
Running with this patch, all of the curses-based programs that I use on
below about F13 - F16.
* With numlock OFF, keypad 5 is now 'begin' rather than unused.
* Home, End, keypad home, and keypad end now send different sequences.
* A new keysym has been added - KS_Backtab.
* Shift-TAB is now defined as KS_Backtab and sends ESC [ Z.
* Shift-F1 - Shift-F12 now send
Hi
It is a good idea to make wscons more like xterm, at least so far as
setting TERM to xterm will not cause major problems for most programs.
Hardly anything uses blinking and the lack of it will bother nobody so TBH
I wouldn't worry too much about it.
Your diff looks good to me, althou
The following patch adds five escape sequences to the wscons vt100 emulation.
It's one part of a larger set of patches I am working on to make the console
more like xterm.
Note: Casual readers of -tech and those not familar with terminfo might
prefer to read my write-up at
]\n", __progname);
> + fprintf(stderr, "usage: %s [file] login\n", __progname);
> + fprintf(stderr, " %s -I [file]\n", __progname);
Sorry, I should have looked close what's going on. I don't think this is
an improvement. Your original diff was bet
On Fri, 2022-12-30 at 14:50 +0100, Florian Obser wrote:
> That seems reasonable. This might be the full list, do you want to do
> all?
>
> usr.bin/htpasswd/htpasswd.c:fprintf(stderr, "usage:\t%s [file]
> login\n", __progname);
> usr.sbin/installboot/installboot.c: fprintf(stderr, "usage:\t
022-12-30 14:45 +01, David Demelier wrote:
> Most utilities seem to use a unique space between the colon and the
> program name, vmctl uses a tab that will expand to two spaces once
> invoked.
>
> e.g.
>
> pfctl: unknown command line argument: tata ...
> usage: pfctl [-d
Most utilities seem to use a unique space between the colon and the
program name, vmctl uses a tab that will expand to two spaces once
invoked.
e.g.
pfctl: unknown command line argument: tata ...
usage: pfctl [-deghNnPqrvz] [-a anchor] [-D macro=value] [-F modifier]
[-f file]
tar foobar
tar: f
On Wed, Dec 28, 2022 at 09:35:52PM +, Jason McIntyre wrote:
> i've finished with this diff. the usr.sbin parts i didn;t take are
> listed below, along with any explanation.
I *think* by my count and by watching the logs this is all of the diffs
on this thread! Kudos for your steadfast review,
ow to provoke integrity check failure */
/*
* fpin = fopen("/tmp/passwd.enc", "a");
-* fprintf(fpin, "borken");
+* fprintf(fpin, "broken");
* fclose(fpin);
*/
bc/include/cancel.h
===
RCS file: /cvs/src/lib/libc/include/cancel.h,v
retrieving revision 1.5
diff -u -p -r1.5 cancel.h
--- lib/libc/include/cancel.h 5 Sep 2017 02:40:54 - 1.5
+++ lib/libc/include/cancel.h 22 Dec 2022 21:14
On Fri, Dec 23, 2022 at 10:33:43AM -0500, Paul Tagliamonte wrote:
> On Fri, Dec 23, 2022 at 03:03:15PM +, Stuart Henderson wrote:
>
> > A bunch of the files in your diff come from external upstream sources
> > which are still synced from upstream (or at least should be); p
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
> Index: include/tib.h
> ===
> RCS file: /cvs/src/include/tib.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 tib.h
> --- include/tib.h 14 Jul 2020 16:48:13 -
/search.c 20 Oct 2022 18:59:24 - 1.48
> +++ usr.bin/mg/search.c 23 Dec 2022 15:20:48 -
> @@ -872,8 +872,8 @@ zapuptochar(int f, int n)
> }
>
> /*
> - * Prompt for a charcter and deletes from the point up to, optionally
> - * including, the firs
the manipulation
> * of archives. The first time an archive is referenced, all of its members'
> * headers are read and hashed and the archive closed again. All hashed
> * archives are kept in a hash (archives) which is searched each time
hi,
i'm not taking this. i can;t convi
itten to
> + * Always true, causes the current pathname to be written to
> * standard output.
> */
> int
> @@ -1576,7 +1576,7 @@ c_user(char *username, char ***ignored,
> /*
> * -xdev functions --
> *
> - * Always true, causes find not to decend past
d_it; /* no type is emitted
> > > for void */
> >
> > style(9) issue, this exceeds 80 columns
>
> I've reflowed the line. I shudder to think that this was done
> intentionally to make it fit
>
doh! so without spotting this note i wondered why
On Mon, Dec 26, 2022 at 12:11:20PM -0500, Josiah Frentsos wrote:
> Index: ksh.1
> ===
fixed, thanks.
jmc
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.217
> diff -u -p -r1.217 ksh.1
> --- ksh.1 13 Sep 2022 20:26:26
Index: ksh.1
===
RCS file: /cvs/src/bin/ksh/ksh.1,v
retrieving revision 1.217
diff -u -p -r1.217 ksh.1
--- ksh.1 13 Sep 2022 20:26:26 - 1.217
+++ ksh.1 26 Dec 2022 17:10:37 -
@@ -2713,9 +2713,7 @@ Exit status i
======
> >
> > This commit contains changes to the code, it is not just a spelling fix:
> >
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1&r2=1.2&f=h
>
> No. This change was already there i
======
> >
> > This commit contains changes to the code, it is not just a spelling fix:
> >
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1&r2=1.2&f=h
>
> No. This ch
elating to libssl.
> > jmc
> >
> > > ===
> > > Index: lib/libssl/test/pkits-test.pl
> > > ===
>
> This commit contains changes to the code, it is
===
> > Index: lib/libssl/test/pkits-test.pl
> > ===
This commit contains changes to the code, it is not just a spelling fix:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1&r2=1.2&f=h
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
>
> Updated patch attached with your feedback, thank you Crystal
>
hi.
i'm rejecting these parts of this diff:
Index: lib/libcurses/term.5
Index: lib/libcurses/tinfo/comp_hash.c
Index: lib/libcurses/tty/hashmap.c
Index: lib/libe
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
hi. i've committed the parts of this diff relating to libssl.
jmc
> Index: lib/libssl/d1_both.c
> ===
> Index: lib/libssl/ssl.h
> =
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
>
> Updated patch attached with your feedback, thank you Crystal
>
hi.
i know by now you have the message that diffs need to be manageable ;)
i'll try and work through your changes as best i can.
so this is a h
On Sat, Dec 24, 2022 at 12:25:15PM -0500, Josiah Frentsos wrote:
> Index: ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.217
> diff -u -p -r1.217 ksh.1
> --- ksh.1 13 Sep 2022 20:26:26 - 1.217
> +
Index: ksh.1
===
RCS file: /cvs/src/bin/ksh/ksh.1,v
retrieving revision 1.217
diff -u -p -r1.217 ksh.1
--- ksh.1 13 Sep 2022 20:26:26 - 1.217
+++ ksh.1 24 Dec 2022 17:22:08 -
@@ -3454,9 +3454,7 @@ option is use
On Fri, Dec 23, 2022 at 03:03:15PM +, Stuart Henderson wrote:
> Overall imho this is too much churn to do in huge swathes across the
> tree.
>
> Fixes for spelling/grammar in comments etc are often more usually
> done by people working on a particular part of the tr
li Offsets tables are not used in the comparison.
probably "Offset tables are..."
A bunch of the files in your diff come from external upstream sources
which are still synced from upstream (or at least should be); patching
in the OpenBSD tree makes it harder to merge in upda
Hi Dave,
* Dave Voutila wrote:
> While working back and forth with dlg@ on his idea of adding in async
> task queues to vmd devices, he started to introduce a cleaner way to
> handle virtqueues. In short, we can just track the host virtual address
> and read/write to that location.
&
36 ],
> @@ -749,7 +749,7 @@ my @testlists = (
> [ "4.14.29", "Valid cRLIssuer Test29", 0 ],
>
> # Although this test is valid it has a circular dependency. As a result
> -# an attempt is made to reursively checks a CRL path and rejected due to
>
Dave Voutila writes:
> While working back and forth with dlg@ on his idea of adding in async
> task queues to vmd devices, he started to introduce a cleaner way to
> handle virtqueues. In short, we can just track the host virtual address
> and read/write to that location.
>
I've only read through 50% of this so far, but there are a few issues:
On Thu, Dec 22, 2022 at 06:31:23PM -0500, Paul Tagliamonte wrote:
> Index: lib/libcurses/base/resizeterm.c
> ===
> RCS file: /cvs/src/lib/
While working back and forth with dlg@ on his idea of adding in async
task queues to vmd devices, he started to introduce a cleaner way to
handle virtqueues. In short, we can just track the host virtual address
and read/write to that location.
This has the benefit of cleaning up a good chunk of
1 - 100 of 1082 matches
Mail list logo
