83
>
> ok? comments?
>
> Index: sys/dev/acpi/acpiac.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpiac.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 acpiac.c
> --- sys/dev/acpi/acpiac.c 6 Apr 2022 18:59
file: /cvs/src/usr.sbin/relayd/pfe_filter.c,v
retrieving revision 1.63
diff -u -p -r1.63 pfe_filter.c
--- usr.sbin/relayd/pfe_filter.c30 Jun 2023 12:16:00 - 1.63
+++ usr.sbin/relayd/pfe_filter.c13 Sep 2023 04:58:36 -
@@ -486,6 +486,20 @@ sync_ruleset(struct relayd *env, str
On Thu, Sep 07, 2023 at 01:10:17PM BST, Walter Alejandro Iglesias wrote:
>
> I didn't know that, thanks. I'd like to send the patch to the
> maintainer of this version too, but after downloading a snapshot a
> README.1st in the tarball says:
>
> Please do not contact the original authors abo
Hi Raf,
On Thu, Sep 07, 2023 at 12:08:00PM +0100, Raf Czlonka wrote:
> On Thu, Sep 07, 2023 at 08:04:43AM BST, Walter Alejandro Iglesias wrote:
> > Dear OpenBSD developers,
> >
> > On Aug 2 I reported this bug:
> >
> > https://marc.info/?l=openbsd-bugs&m=169100763926909&w=2
> >
> > After fidd
Which, needless to say, also works for both. vi on base and nvi on
> ports. Below I paste a cvs version of Zhihao's patch to use it with vi
> on base.
>
> So it only rests some OpenBSD developer here to take look. It's not
> going to take up much of your time, everything h
On Thu, Sep 07, 2023 at 08:04:43AM BST, Walter Alejandro Iglesias wrote:
> Dear OpenBSD developers,
>
> On Aug 2 I reported this bug:
>
> https://marc.info/?l=openbsd-bugs&m=169100763926909&w=2
>
> After fiddling around I found a solution that works for both vi base and
> nvi from ports:
>
>
developer here to take look. It's not
going to take up much of your time, everything has already been chewed
up :-).
Zhihao's diff translated to cvs:
Index: vi/v_paragraph.c
===
RCS file: /cvs/src/usr.bin/vi/vi/v_parag
prevent unknown
side effects. But it might be unnecessary.
>> Index: sys/dev/acpi/acpiac.c
>> ===
>> RCS file: /cvs/src/sys/dev/acpi/acpiac.c,v
>> retrieving revision 1.36
>> diff -u -p -r1.36 acpiac.c
&g
=
> RCS file: /cvs/src/sys/dev/acpi/acpiac.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 acpiac.c
> --- sys/dev/acpi/acpiac.c 6 Apr 2022 18:59:27 - 1.36
> +++ sys/dev/acpi/acpiac.c 17 Aug 2023 06:57:44 -
> @@ -140,6 +140
otification
always happens. So the diff is to use the battery notification
instead of the AC status notification.
> My vaio actually has this problem.
>
> Also Linux is doing the same thing
>
> https://github.com/torvalds/linux/blob/v6.4/drivers/acpi/ac.c#L165-L183
>
> ok? co
gt;> ok? comments?
>>
>> Index: sys/dev/acpi/acpiac.c
>> ===
>> RCS file: /cvs/src/sys/dev/acpi/acpiac.c,v
>> retrieving revision 1.36
>> diff -u -p -r1.36 acpiac.c
>> --- sys/
=
> RCS file: /cvs/src/sys/dev/acpi/acpiac.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 acpiac.c
> --- sys/dev/acpi/acpiac.c 6 Apr 2022 18:59:27 - 1.36
> +++ sys/dev/acpi/acpiac.c 17 Aug 2023 06:57:44 -
> @@ -140,6 +140,8 @@ acpiac_getpsr(st
ments?
Index: sys/dev/acpi/acpiac.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiac.c,v
retrieving revision 1.36
diff -u -p -r1.36 acpiac.c
--- sys/dev/acpi/acpiac.c 6 Apr 2022 18:59:27 - 1.36
+++ sys/dev/acpi/acpiac.c 1
> >> Hello,
> > >>
> > >> Someone asked about selectable curves in the OpenSMTPD portable tracker,
> > >> and it turns out I had a diff for that among a few others.
> > >
> > > Why do they need this?
> >
> > I suspect for the
able curves in the OpenSMTPD portable tracker,
> >> and it turns out I had a diff for that among a few others.
> >
> > Why do they need this?
>
> I suspect for the same reason people have needed ciphers selection in the
> past,
> being able to comply with th
On Sat, Aug 12, 2023 at 05:22:38PM +0200, Peter J. Philipp wrote:
> On Sat, Aug 12, 2023 at 02:27:13PM +, Miod Vallat wrote:
> > Third time's (hopefully) the charm. How about that diff? Too much things
> > have been removed in uwacom.
>
> partial success! The waco
> On Sat, Aug 12, 2023 at 02:27:13PM +, Miod Vallat wrote:
> > Third time's (hopefully) the charm. How about that diff? Too much things
> > have been removed in uwacom.
>
> partial success! The wacom driver is recognized, no panics this time. But
> the input is
On Sat, Aug 12, 2023 at 02:27:13PM +, Miod Vallat wrote:
> Third time's (hopefully) the charm. How about that diff? Too much things
> have been removed in uwacom.
partial success! The wacom driver is recognized, no panics this time. But
the input is all over the place when I
August 12, 2023 4:34 PM, "Theo Buehler" wrote:
> On Sat, Aug 12, 2023 at 02:29:45PM +, gil...@poolp.org wrote:
>
>> Hello,
>>
>> Someone asked about selectable curves in the OpenSMTPD portable tracker,
>> and it turns out I had a diff for that among
On Sat, Aug 12, 2023 at 02:29:45PM +, gil...@poolp.org wrote:
> Hello,
>
> Someone asked about selectable curves in the OpenSMTPD portable tracker,
> and it turns out I had a diff for that among a few others.
Why do they need this?
Hello,
Someone asked about selectable curves in the OpenSMTPD portable tracker,
and it turns out I had a diff for that among a few others.
The diff below adds support for the curves keyword in listener and relay
directives,
allowing to specify a curve string suitable for
Third time's (hopefully) the charm. How about that diff? Too much things
have been removed in uwacom.
Index: dev/hid/hid.c
===
RCS file: /OpenBSD/src/sys/dev/hid/hid.c,v
retrieving revision 1.5
diff -u -p -r1.5 hid.c
--- de
On Sat, Aug 12, 2023 at 01:12:26PM +, Miod Vallat wrote:
> > On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> > > I have had a look at your diff and I think it's decent enough to go in
> > > after some polishing.
> > >
> > >
> On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> > I have had a look at your diff and I think it's decent enough to go in
> > after some polishing.
> >
> > Can Wacom tablet users try this cleaned up diff?
>
> Hi,
>
> My WACOM table
On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> I have had a look at your diff and I think it's decent enough to go in
> after some polishing.
>
> Can Wacom tablet users try this cleaned up diff?
Hi,
My WACOM tablet stopped working with this, here is a dmesg w
On Sat, Aug 12, 2023 at 08:00:48AM +, Miod Vallat wrote:
> I have had a look at your diff and I think it's decent enough to go in
> after some polishing.
>
> Can Wacom tablet users try this cleaned up diff?
Works on the target tablet here (Wacom Intuos S)
I have had a look at your diff and I think it's decent enough to go in
after some polishing.
Can Wacom tablet users try this cleaned up diff?
Index: dev/hid/hid.c
===
RCS file: /OpenBSD/src/sys/dev/hid/hid.c,v
retrieving rev
On Sun, Jul 23, 2023 at 09:16:40PM +, jon@elytron.openbsd.amsterdam wrote:
> If I'm not mistaken, all wskbd_{get,set}_backlight uses are in the
> following drivers: acpicbkbd, acpithinkpad, asmc, pwmleds, and now
> my implementation in adb. It is my impression that they are roughly
> the same c
If I'm not mistaken, all wskbd_{get,set}_backlight uses are in the
following drivers: acpicbkbd, acpithinkpad, asmc, pwmleds, and now
my implementation in adb. It is my impression that they are roughly
the same code, I have collected them below to ease their inspection.
I would also like to acknow
> Date: Sun, 23 Jul 2023 15:21:38 +0200
> From: Anton Lindqvist
>
> On Sun, Jul 23, 2023 at 11:37:38AM +, jon@elytron.openbsd.amsterdam wrote:
> > Hello all. Thank you very much for your input. I have taken heed of
> > your suggestions in the diff below
> >
&g
On Sun, Jul 23, 2023 at 11:37:38AM +, jon@elytron.openbsd.amsterdam wrote:
> Hello all. Thank you very much for your input. I have taken heed of
> your suggestions in the diff below
>
> On Sat, 22 Jul 2023 20:59:04 -0400 George Koehler
> wrote:
>
> > We should check
Hello all. Thank you very much for your input. I have taken heed of
your suggestions in the diff below
On Sat, 22 Jul 2023 20:59:04 -0400 George Koehler
wrote:
> We should check if (wskbd_get_backlight != NULL), like we do for
> WSKBDIO_GETBACKLIGHT. Same for wskbd_set_backlight.
Fixed
elytron.openbsd.amsterdam wrote:
>
> > Index: arch/macppc/dev/adb.c
> > ===
> > RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
> > retrieving revision 1.50
> > diff -u -p -r1.50 adb.c
> > --- arc
> RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 adb.c
> --- arch/macppc/dev/adb.c 11 Apr 2023 00:45:07 - 1.50
> +++ arch/macppc/dev/adb.c 13 Jul 2023 21:17:17 -
> @@ -102,6 +102,8 @@
> #include
&g
n with him,
> > I am reposting an updated version of my keyboard backlight
> > patch [2], which you can find below:
> >
> > [1] https://marc.info/?l=openbsd-tech&m=168884670208963&w=2
> >
> > [2] https://marc.info/?l=openbsd-tech&m=167755750511636&w=2
Thank you very much for testing.
> the diff looks good to me except for maybe the numlock bit in
> hidkbd
I agree, that was part of my incipient attempt to fix numlock on
these laptops as well, please drop it from this diff, it is unrelated.
> One thing I am never quite sure abo
ch [2], which you can find below:
>
> [1] https://marc.info/?l=openbsd-tech&m=168884670208963&w=2
>
> [2] https://marc.info/?l=openbsd-tech&m=167755750511636&w=2
Hi,
the diff looks good to me except for maybe the numlock bit in hidkbd
which seems unrelated to the res
=2
[2] https://marc.info/?l=openbsd-tech&m=167755750511636&w=2
Index: arch/macppc/dev/adb.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
retrieving revision 1.50
diff -u -p -r1.50 adb.c
--- arch/macppc/dev/adb.c
Please allow me to explain why I have written a custom parser pour the Wacom
devices, instead of just using the already existent one.
The function of interest to us is hidms_setup, it is here that I have a special
condition with as has been mentioned uses a quirk.
We need it because of the follow
On Tue, Jul 04, 2023 at 07:20:51PM -0400, Thomas Frohwein wrote:
> Thanks, I built a kernel with this and no issues observed. I have a
> Wacom Bamboo (CTH-470, product id 0x00de) that doesn't attach yet, but
> this can be left for future work. I don't see anything glaring. hid.c
> could probably us
x
>
> (sorry for the medium, fortunately we have libreoffice)
>
> In the mean time, here is an updated diff.
>
> I removed the Gaomon stuff, which if anything should be a different patch.
>
> And I cleaned up the 20+ minor style violations I could find...
> (tabs instead
On Mon, Jul 03, 2023 at 03:20:33PM +0300, Matthieu Herrb wrote:
> > Index: dev/usb/usbdevs.h
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> > retrieving revision 1.769
> > diff -u -p -r1
x
>
> (sorry for the medium, fortunately we have libreoffice)
>
> In the mean time, here is an updated diff.
>
> I removed the Gaomon stuff, which if anything should be a different patch.
>
> And I cleaned up the 20+ minor style violations I could find...
> (tabs instead
re is an updated diff.
I removed the Gaomon stuff, which if anything should be a different patch.
And I cleaned up the 20+ minor style violations I could find...
(tabs instead of +4 spaces for continued lines, a few non-style compliant
function declarations and/or code blocks, oh well)
plus an
On Sun, Jun 18, 2023 at 09:36:25AM +, Vladimir Meshcheriakov wrote:
> Good day,
>
> I am currently trying to work on an implementation
> of a driver for the WACOM tablet on openBSD
> I am therefore submitting this diff so that it could potentially be evaluated.
> Please if
On Sun, Jun 18, 2023 at 09:36:25AM +, Vladimir Meshcheriakov wrote:
> Good day,
>
> I am currently trying to work on an implementation
> of a driver for the WACOM tablet on openBSD
> I am therefore submitting this diff so that it could potentially be evaluated.
> Please if
Good day,
I am currently trying to work on an implementation
of a driver for the WACOM tablet on openBSD
I am therefore submitting this diff so that it could potentially be evaluated.
Please if you have a moment, could you have a look at this diff?
I have tested it with my Wacom tablet
and it
Hello,
The patch is mangled. It has CRLFs and various 'fancy' unicode spaces
so it doesn't apply. Don't know what mail client you're using, but as
a last-resort you may try to attach the diff instead of inlining, some
MUAs seems to go really out of their way to mangl
Good day,
I am currently trying to work on an implementationion
of a driver for the WACOM tablet on openBSD
I am therefore submiting this diff so that it could potentially be evaluated.
Please if you have a moment, could you have a look at this diff?
I have tested it with my Wacom tablet
and it
/asr/asr_run.3,v
retrieving revision 1.5
diff -u -p -r1.5 asr_run.3
--- lib/libc/asr/asr_run.3 31 Mar 2022 17:27:15 - 1.5
+++ lib/libc/asr/asr_run.3 20 Mar 2023 05:42:02 -
@@ -259,7 +259,7 @@ Upon completion, the return code is foun
.Fa ar_rrset_errno
and the address to the
On 2023/05/15 07:34:03 -0600, "Todd C. Miller" wrote:
> On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote:
>
> > almost always (cast)var. I've adjusted the spacing in the line I was
> > touching, grepping for common types I could only find one instance of
> > a '(long long) src' in envelope.c
May 15, 2023 3:34 PM, "Todd C. Miller" wrote:
> On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote:
>
>> almost always (cast)var. I've adjusted the spacing in the line I was
>> touching, grepping for common types I could only find one instance of
>> a '(long long) src' in envelope.c which I'm n
On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote:
> almost always (cast)var. I've adjusted the spacing in the line I was
> touching, grepping for common types I could only find one instance of
> a '(long long) src' in envelope.c which I'm not addressing here.
OK millert@. It would be nice to
ne instance of
a '(long long) src' in envelope.c which I'm not addressing here.
Index: libexec/mail.local/mail.local.c
===
RCS file: /cvs/src/libexec/mail.local/mail.local.c,v
retrieving revision 1.40
diff -u -p -r1.4
mark as const also the two arrays
> > > > > > day
> > > > > > and month?
> > > > >
> > > > > ok.
> > > > >
> > > > > The previous diff used (long long int) and this one now uses (long
> > > &
> > > > > directory and -even if off topic because it's not in portable- instead
> > > > > of "const"-ify only tz why don't mark as const also the two arrays day
> > > > > and month?
> > > >
> > > > ok.
> &
x27;s not in portable- instead
> > > > of "const"-ify only tz why don't mark as const also the two arrays day
> > > > and month?
> > >
> > > ok.
> > >
> > > The previous diff used (long long int) and this one now uses (long l
y don't mark as const also the two arrays day
> > > and month?
> >
> > ok.
> >
> > The previous diff used (long long int) and this one now uses (long long).
> > Would be nice to be consistent.
>
> Yes, indeed. smtpd uses `long long int', while
> + (long long int)tv.tv_sec, tv.tv_usec,
Please do not use that form. (long long) is enough.
On Wed, 10 May 2023 09:25:43 +0200, Omar Polo wrote:
> I forgot to include one off_t cast since it was in a different
> directory and -even if off topic because it's not in portable- instead
> of "const"-ify only tz why don't mark as const also the two arrays day
> and month?
Sure. OK millert@ f
two arrays day
> > and month?
>
> ok.
>
> The previous diff used (long long int) and this one now uses (long long).
> Would be nice to be consistent.
Yes, indeed. smtpd uses `long long int', while for mail.local doesn't
have any. I'll go with `long long int' for consistency, typed `long
long' out of muscular memory.
thanks!
uding that too.)
> >
> > OK millert@
>
> thanks!
>
> I forgot to include one off_t cast since it was in a different
> directory and -even if off topic because it's not in portable- instead
> of "const"-ify only tz why don't mark as const a
in a different
directory and -even if off topic because it's not in portable- instead
of "const"-ify only tz why don't mark as const also the two arrays day
and month?
sorry for forgetting these in the previous mail,
diff /usr/src
commit - a2d3cb1e480c37eb6fb14cee9f294660
On Wed, 10 May 2023 00:55:54 +0200, Omar Polo wrote:
> As per subject, here's a few misc nits that would reduce the
> difference with -portable. There's some printing of time_t via
> casting to long long, some missing includes (even if in tree it builds
> nevertheless) and a const for a variable
;s not wrong so including that too.)
ok?
diff /usr/src
commit - a2d3cb1e480c37eb6fb14cee9f2946606a0346bc
path + /usr/src
blob - 52924139091915e80409892fbd92dad375ee602c
file + usr.sbin/smtpd/lka_filter.c
--- usr.sbin/smtpd/lka_filter.c
+++ usr.sbin/smtpd/lka_filter.c
@@ -933,13 +933,13 @@ filter
Hello,
On Fri, Apr 28, 2023 at 11:18:18AM +, Klemens Nanni wrote:
> On Fri, Apr 28, 2023 at 12:55:37PM +0200, Alexandr Nedvedicky wrote:
> > Hello,
> > [ sending off-list ]
> >
> > up-to-date complete diff.
>
> Builds, boots and works faster:
>
>
Oops! Thank you for the explanation.
On Thu, Apr 27, 2023 at 3:37 PM Jonathan Gray wrote:
>
> On Thu, Apr 27, 2023 at 03:24:06PM -0900, Andras Farkas wrote:
> > Small diff for 73.html: fixes incorrect link to amdgpu man page.
>
> amdgpu(4) is the xorg driver, it is i
On Thu, Apr 27, 2023 at 03:24:06PM -0900, Andras Farkas wrote:
> Small diff for 73.html: fixes incorrect link to amdgpu man page.
amdgpu(4) is the xorg driver, it is intentionally drm.4
>
> SHA51
Small diff for 73.html: fixes incorrect link to amdgpu man page.
SHA512 (73diff) =
b3a2afb78744cddfaa148d1bfcd825af376dc4e168e12116e49f1f16614cdc108f001b8fd592eb884e7fcf6e342da527fb437dba991fc583fbc85ef9f98b85e3
Index: 73.html
Hello,
below is a complete diff which makes DIOCGETRULE bit more sane.
This is the complete change I'd like to commit. It is also more
convenient for people who want to test the diff.
when running 'pfctl -sr' to show rules pfctl performs several
ioctl(2) calls. The first call is
Hi,
carpdemote is increased/decreased when the link state of the carpdev
is down/up. This behavior is not related to net.inet.carp.preempt since
"carpdemote" is introduced.
But the faq still says the "net.inet.carp.preempt" variable enables it.
I'd like to commit the
Hi Mark,
On Thu, Mar 09, 2023 at 05:23:55PM +0100, Mark Kettenis wrote:
| > Date: Thu, 09 Mar 2023 14:48:25 +0100
| > From: Mark Kettenis
| >
| > The diff below fixes an issue with the way we attach "APCI devices".
| > As with all ACPI diffs, this may potentially
> Date: Thu, 09 Mar 2023 14:48:25 +0100
> From: Mark Kettenis
>
> The diff below fixes an issue with the way we attach "APCI devices".
> As with all ACPI diffs, this may potentially introduce regressions, so
> some wider testing would be welcome.
>
> The fix it
The diff below fixes an issue with the way we attach "APCI devices".
As with all ACPI diffs, this may potentially introduce regressions, so
some wider testing would be welcome.
The fix itself involves resolving a "nameref" in the package that
describes dependencies between
On 3/2/23 10:09, Stefan Sperling wrote:
On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote:
Below is my work-in-progress diff to update iwx(4) to latest firmware.
Every system tracking -current should already have the new -77 firmware images.
The new images contain security fixes
On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote:
> Below is my work-in-progress diff to update iwx(4) to latest firmware.
> Every system tracking -current should already have the new -77 firmware
> images.
>
> The new images contain security fixes of (to me) u
ev/adb.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
retrieving revision 1.49
diff -u -p -r1.49 adb.c
--- arch/macppc/dev/adb.c 26 Dec 2022 19:17:00 - 1.49
+++ arch/macppc/dev/adb.c 28 Feb 2023 03:56:11 -
@@ -102,
Hi Stefan,
thanks for your work.
I also can confirm your patch.
Thanks,
Sven
On 2/24/23 10:36, Mikhail wrote:
On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote:
Below is my work-in-progress diff to update iwx(4) to latest firmware.
Every system tracking -current should already
On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote:
> Below is my work-in-progress diff to update iwx(4) to latest firmware.
> Every system tracking -current should already have the new -77 firmware
> images.
>
> The new images contain security fixes of (to me) u
Below is my work-in-progress diff to update iwx(4) to latest firmware.
Every system tracking -current should already have the new -77 firmware images.
The new images contain security fixes of (to me) unknown severity.
Unfortunately there have been quite a number of firmware API changes since
our
> > > Yes, there are cases where people use .long to inject an instruction
> > > they don't believe the assembler has. We can ignore those by inspect.
> > >
> > > Can anyone help? It doesn't need to be fancy, it just needs to get
> > > us
We can ignore those by inspect.
> >
> > Can anyone help? It doesn't need to be fancy, it just needs to get
> > us moving faster.
> >
> > Thanks
> >
>
> The following diff seems to work. It adds a warning inside assembler parsers.
>
New diff
_PIC__ handling as neccessary
>
> Yes, there are cases where people use .long to inject an instruction
> they don't believe the assembler has. We can ignore those by inspect.
>
> Can anyone help? It doesn't need to be fancy, it just needs to get
> us moving faster.
&
ent.8
===
RCS file: /cvs/src/usr.sbin/rpki-client/rpki-client.8,v
retrieving revision 1.83
diff -u -p -r1.83 rpki-client.8
--- rpki-client.8 13 Jan 2023 08:58:36 - 1.83
+++ rpki-client.8 17 Jan 2023 11:10:01 -
@@ -234,11 +
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 into
On Wed, 04 Jan 2023 13:13:28 -0800, Nathan Houghton wrote:
> This patch removes a few remnants of the unsupported diff -l
> option from diff.c and the diff manual page.
>
> The diff.c usage() print is already correct, so no changes are
> needed there.
Thanks, committed.
- todd
Hi all,
This patch removes a few remnants of the unsupported diff -l
option from diff.c and the diff manual page.
The diff.c usage() print is already correct, so no changes are
needed there.
Thanks,
Nate
diff --git a/usr.bin/diff/diff.1 b/usr.bin/diff/diff.1
index 85a168d7740..e718e37ed61
Hi,
this diff has been sent out earlier, but now that more or the
immutable parts are in, it is time to test it in this new environment.
Thanks,
-Otto
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c
Hi Miod,
Yes, I confirm that your diff fixes the problem.
Thank you!
Leonardo
El mar, 4 oct 2022 a las 13:28, Miod Vallat () escribió:
> > Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
> > being assigned to
> > newly created &
> Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
> being assigned to
> newly created 'sc_fn' inside 'hidkbd'
Argh, sorry about that.
Does the following dif
attach possible one liner fix. This gets the mapping working again.
Thanks!
Leonardo
Index: sys/dev/usb/ukbd.c
===
RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
retrieving revision 1.87
diff -u -p -r1.87 ukbd.c
--- sys/dev/usb/ukbd.c 16 S
On 2022/09/23 21:37:13 +, Klemens Nanni wrote:
> In the few places I run httpd(8) patches usually float around and I do
> look at them with Firefox.
>
> But unless httpd.conf(5) contains `types { text/plain diff patch }' the
> browser will download the file instead of d
In the few places I run httpd(8) patches usually float around and I do
look at them with Firefox.
But unless httpd.conf(5) contains `types { text/plain diff patch }' the
browser will download the file instead of displaying it as text.
Would it be sensible to add them to the default list so
1219sp->key[PF_SK_WIRE].rdomain =
htons(st->key[PF_SK_WIRE]->rdomain);
1220sp->key[PF_SK_WIRE].af = st->key[PF_SK_WIRE]->af;
(gdb)
the uvm_fault happened because st->key[PF_SK_WIRE] is NULL. This is
can happen after pf_state_key_detach() <- pf_st
the
> > length of the main function should increase the readability of the large
> > function.
>
> This patch does not apply cleanly onto current CVS for me.
>
> >
> > Varik Valefor
> > "When lost, just pure :: Monad m => a -> m a."
>
the large
> function.
This patch does not apply cleanly onto current CVS for me.
>
> Varik Valefor
> "When lost, just pure :: Monad m => a -> m a."
>
> diff --git a/sbin/bioctl/bioctl.c b/sbin/bioctl/bioctl.c
> index 58561e5f30f..19963ad762f 100644
> --- a/
On Tue, Aug 30, 2022 at 02:19:29PM +0200, Theo Buehler wrote:
> > Ah, I showed the diff separated from first one.
> > I'm sorry for confusing. The following diff is combined.
>
> Oh, I see.
>
> ok tb (feel free to land the diffs separately if you prefer).
Also OK claudio
--
:wq Claudio
> Ah, I showed the diff separated from first one.
> I'm sorry for confusing. The following diff is combined.
Oh, I see.
ok tb (feel free to land the diffs separately if you prefer).
code using PATH_MAX for a buffer
>> > size that has nothing to do with a file system path?
>>
>> It is a mystery of the history?
>>
>>
>> https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/usr.bin/uudecode/uudecode.c#L92
>>
>
history?
>
>
> https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/usr.bin/uudecode/uudecode.c#L92
>
> MAXPATHLEN was replaced to PATH_MAX in 2015.
>
> ok?
>
> Index: usr.bin/uudecode/uudecode.c
> ==
1 - 100 of 1475 matches
Mail list logo
