> Good catch, thanks.
>
> My eyes glazed over a little while reviewing this, but tentative ok
> mmcc@
>
> Below is what I consider a better refactoring of buf_free(). It makes it
> NULL-safe and has more classic free function logic.
I didn't include buf_free() in my patch but that looks good.
>
Ted Unangst wrote:
> Michael McConville wrote:
> > It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's
> > almost exclusively used for uvm_map()'s flag arg, which has that type.
> > Of course, it's an arithmetic macro, so it doesn't actually have a
> > return type.
>
> I would
Michael McConville wrote:
> It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's
> almost exclusively used for uvm_map()'s flag arg, which has that type.
> Of course, it's an arithmetic macro, so it doesn't actually have a
> return type.
I would argue we should delete some of th
Michael W. Bombardieri wrote:
> Hi tech@,
>
> Function xfree() was previously removed from rcs, so drop it from
> opencvs too...
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/rcs/xmalloc.c?f=h#rev1.9
Good catch, thanks.
My eyes glazed over a little while reviewing this, but tentative
Hi tech@,
Function xfree() was previously removed from rcs, so drop it from
opencvs too...
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/rcs/xmalloc.c?f=h#rev1.9
Footnote:
I noticed that rcsnum_free() is just free() so maybe that could be
removed also (not included in this patch).
- Mich
It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's
almost exclusively used for uvm_map()'s flag arg, which has that type.
Of course, it's an arithmetic macro, so it doesn't actually have a
return type.
ok?
Index: share/man/man9/uvm.9
=
Fixes a segfault (in tcpdump.c:default_print) when a printing a raw
packet of family AF_LINK with an unknown ether_type with
MALLOC_OPTIONS=S. The original version would print 4-bytes of d0 and
occasionally segfault.
With this change, default_print() receives a caplen that is reduced by
NULL_HDRLE
Hello tech@,
I got somewhat annoyed by the fact that OpenBSD's tail can't follow
multiple files and since the last attempt at it was from 2008 I thought
I'd give it a shot. I already sent an earlier version of this diff to
Landry who called it "a welcomed addition", but doesn't have time to
r
When compiling kernel with option DEBUG_INTC, we do not have
AMPINTC_IRQ_TO_REG nor AMPINTC_IRQ_TO_REGi.
In the same file, most uses of Debugger() is protected with either
#ifdef DDB
or with a
#if defined(DEBUG_SOMETHING) && defined(DDB)
as it is with sys/arch/amd64/amd64/cpu.c, sys/arch/arm/a
>From FreeBSD 23397:
Fixed wrong magic numbers in scaling. hypotf() was very broken for large
and small values:
hypotf(2.3819765e+38, 2.0416943e+38) was NaN instead of 3.1372484e+38
hypotf(-3.4028235e+38, 3.3886450e+38) was NaN instead of Inf
hypotf(-2.8025969e-45, -2.8025969e-45) wa
On Wed, Nov 04, 2015 at 01:50:28PM +0500, Alexandr Shadchin wrote:
> Hi,
>
> This diff updates xkeyboard-config to the latest release.
>
> Changes:
> 2.16 10 bugs fixed
> Translations updated
> 2.15 7 bugs fixed
> Translations updated
>
> Test:
> * ftp http://devio.us/~koba/distfil
Frederic Nowak wrote:
> Hi there,
>
> setbuf(3) etc "are obsoleted by setvbuf(3)" and "should be avoided".
thanks!
Hi there,
setbuf(3) etc "are obsoleted by setvbuf(3)" and "should be avoided".
The patch below replaces all occurrences in ping, ping6, lptest & rmt.
Cheers,
Frederic
Index: ping/ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retr
Hi there,
setbuf(3) etc "are obsoleted by setvbuf(3)" and "should be avoided".
The patch below replaces all occurrences in cat, sed & top.
Cheers,
Frederic
Index: cat/cat.1
===
RCS file: /cvs/src/bin/cat/cat.1,v
retrieving revision
Hi there,
setbuf(3) etc "are obsoleted by setvbuf(3)" and "should be avoided".
The patch below replaces all occurrences in libc man pages and
src/regress.
Cheers,
Frederic
Index: libc/stdio/fclose.3
===
RCS file: /cvs/src/lib/libc/s
Hi there,
setbuf(3) etc "are obsoleted by setvbuf(3)" and "should be avoided".
The patch below updates all occurrences in src/games.
Cheers,
Frederic
Index: atc/graphics.c
===
RCS file: /cvs/src/games/atc/graphics.c,v
retrieving re
I think this is correct...
OK?
diff --git ping6.c ping6.c
index 2c786f9..8e42ade 100644
--- ping6.c
+++ ping6.c
@@ -81,35 +81,29 @@
*/
#include
-#include
#include
-
-#include
-#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
On Wed, Nov 4, 2015 at 2:51 PM, Sonic wrote:
> Is there anything else I can provide to assist in finding a cure for this
> issue?
Not sure this helps at all but the specific error I get is "em0:
watchdog timeout -- resetting". In this case em0 is the nic on the
internal network. I do not see the
On Mon, Nov 2, 2015 at 11:19 PM, Sonic wrote:
> Sorry to report that the diff does not solve the timeout problem here.
>
> All was working fine with the if_em* versions from 2015/09/29 (I
> downgraded to this version per Stuarts post on 10-14):
> "try backing out the last commits to
> if_em.c and
Theo de Raadt writes:
> Why?
>
> We don't have decnet code either, yet it is nice to sniff it if you
> see it.
My understanding was that since sl(4) is gone, there's no way to have an
interface configured with SLIP on OpenBSD, thus no way to see that
protocol and no way to reach that code. I'm
On 2015/11/04 19:41, Jérémie Courrèges-Anglas wrote:
>
> Some time ago mpi removed the sl(4) driver, IIUC this makes a bunch of
> code useless in tcpdump.
It still has slight use for pcap files generated on another system..
Why?
We don't have decnet code either, yet it is nice to sniff it if you
see it.
> Some time ago mpi removed the sl(4) driver, IIUC this makes a bunch of
> code useless in tcpdump.
>
> The diff below only removes the define. If people prefer, I could also
> kill some noise by removing the usele
Some time ago mpi removed the sl(4) driver, IIUC this makes a bunch of
code useless in tcpdump.
The diff below only removes the define. If people prefer, I could also
kill some noise by removing the useless code in print-sl.c, leaving only
the stub functions.
Comments / ok?
Index: Makefile
===
Looks great, ok nicm
On Wed, Nov 04, 2015 at 08:50:37AM -0700, Todd C. Miller wrote:
> This changes cron from including all headers in every file to only
> including what each .c file needs. I have not removed cron.h since
> it will be used in a future clean up of the internal .h files.
>
> -
> > Attempted to match printf formating of unsigned 32bits to rest of
> > file.
>
> I don't think this is the good direction. "seq" and "length" are 32bits
> integers. Why cast them to long, and then print them as unsigned long?
> Let's just print them as unsigned int.
That sounds good to me. I
Noth,
I got my APU (first rev) to go from 56-58 temps down to 49-50 by using heatsink
paste instead of the thermal pad...
Noth [nothingn...@citycable.ch] wrote:
> Thanks Stuart, that works for me!
>
> # sysctl hw
> hw.machine=amd64
> hw.model=AMD GX-412TC SOC
> hw.ncpu=4
> hw.byteorder=1234
> hw
Thanks Stuart, that works for me!
# sysctl hw
hw.machine=amd64
hw.model=AMD GX-412TC SOC
hw.ncpu=4
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:47e18331a1a8156e
hw.diskcount=1
hw.sensors.km0.temp0=59.38 degC
hw.cpuspeed=998
hw.setperf=100
hw.vendor=PC Engines
hw.product=apu2
hw.version=1.0
Kevin Reay writes:
> Change printf format to print unsigned values. Minor spacing change of
> casts to match file/style(9).
>
> Attempted to match printf formating of unsigned 32bits to rest of
> file.
I don't think this is the good direction. "seq" and "length" are 32bits
integers. Why cast t
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
> Frederic Nowak writes:
>
>> Hi there,
>
> Hi,
>
>> at the moment ftp pledges "proc exec" in its SMALL version, but not
>> otherwise. This seems wrong, because the SMALL version does not support
>> interactive mode (which needs "proc exec" for e
this will probably get you a cpu temperature sensor.
Index: km.c
===
RCS file: /cvs/src/sys/dev/pci/km.c,v
retrieving revision 1.10
diff -u -p -r1.10 km.c
--- km.c14 Mar 2015 03:38:48 - 1.10
+++ km.c4 Nov 2015
This is with the -CURRENT :
OpenBSD 5.8-current (GENERIC.MP) #0: Wed Nov 4 17:47:40 CET 2015
r...@euryale.nineinchnetworks.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4261081088 (4063MB)
avail mem = 4127813632 (3936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
On Sat, Oct 31, 2015 at 2:29 PM, Theo de Raadt wrote:
>>Whilst browsing their forums I found a link to this:
>> http://pcengines.ch/apu2b4.htm . AMD Jaguar APU, 4 cores, up to 4Gb
>> DDR1333 ram with ECC, and 3 intel i211 or i210 NICs. Hopefully there
>> won't be so many issues with this itera
Got my first beta board today, here's the dmesg:
OpenBSD 5.8 (GENERIC.MP) #1: Mon Oct 19 02:13:53 CEST 2015
r...@openbsd64.nineinchnetworks.ch:/root/binpatchng-2.1.2/work-binpatch58-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4261081088 (4063MB)
avail mem = 4128047104 (3936MB)
mpath0 a
This changes cron from including all headers in every file to only
including what each .c file needs. I have not removed cron.h since
it will be used in a future clean up of the internal .h files.
- todd
Index: usr.sbin/cron/atrun.c
==
On 25/10/15(Sun) 12:10, Ludovic Coues wrote:
> Usbdump is the result of my work during this summer of code.
> It is a tool inspired by pcidump. It reads usb device descriptor and
> print them with a bit of parsing. It aim to be a more friendly
> alternative to lsusb.
I'd like to have an alternativ
gwes [g...@oat.com] wrote:
> Will unbound and nsd be restricted to port 53 only?
>
No
Apologies... I found a set of how-tos on the web.
They suggest the "use a separate address for the
internal nsd". I will change my setup accordingly.
On 11/04/15 09:31, gwes wrote:
Will unbound and nsd be restricted to port 53 only?
Restricting unbound and nsd to port 53 would be
a flag day for
Will unbound and nsd be restricted to port 53 only?
Restricting unbound and nsd to port 53 would be
a flag day for me.
I am simulating bind's views for my split horizon by
using two copies of nsd, one of which serves external
queries and one which unbound queries for internal
zones. They share s
Hi,
Frederic Nowak wrote on Tue, Nov 03, 2015 at 04:59:35PM +0100:
> I think the "dir |more" example in ftp.1 is not working as intended.
True.
> ls (and by extension its synonym dir) expects to be called like this:
>
> ls [remote-directory [local-file]]
>
> Therefore, "dir |more" would print
On Wed, Nov 04, 2015 at 11:57:39AM GMT, Stuart Henderson wrote:
> On 2015/11/04 10:56, Raf Czlonka wrote:
> > @@ -141,7 +145,7 @@ If using a caching name server, add the
> > Relevant
> > .Xr rc.conf 8
> > variables:
> > -.Va named_flags
> > +.Va nsd_flags
> > and
> > .Va unbound_flags .
>
>
On Wed, Nov 04, 2015 at 12:09:45PM +0100, Ingo Schwarze wrote:
> Hi,
>
> Jason McIntyre wrote on Wed, Nov 04, 2015 at 07:51:30AM +:
>
> > the clarity is good, but i worry that you're making a clear sentence
> > harder to grasp. posix spec itself says -l counts "newline characters",
> > which
On Wed, Nov 04, 2015 at 10:56:58AM +, Raf Czlonka wrote:
>
> I've attached an updated patch, with only the "undisputed" parts :^)
>
> Raf
>
committed, slightly tweaked, with one notable change:
> Index: share/man/man8/intro.8
> ==
On 2015/11/04 10:56, Raf Czlonka wrote:
> @@ -141,7 +145,7 @@ If using a caching name server, add the
> Relevant
> .Xr rc.conf 8
> variables:
> -.Va named_flags
> +.Va nsd_flags
> and
> .Va unbound_flags .
Hmm. This section is a bit weird.
If you are using a name server, check the /etc
On 2015/11/03 20:04, Kevin Reay wrote:
> Fix a segfault in the GRE printer when a GRE packet SRE length
> extends past the actual captured length (but not the packet's
> original length).
That's OK with me..
> gre_print() now checks if the length extends past snapend and, if so,
> uses the snapen
On 12/08/15(Wed) 17:03, Martin Pieuchot wrote:
> I'm currently working on the routing table interface to make is safe
> to use by multiple CPUs at the same time. The diff below is a big
> step in this direction and I'd really appreciate if people could test
> it with their usual network setup and
Hi,
Jason McIntyre wrote on Wed, Nov 04, 2015 at 07:51:30AM +:
> the clarity is good, but i worry that you're making a clear sentence
> harder to grasp. posix spec itself says -l counts "newline characters",
> which i find easier to understand in itself, but as flag -l i find it
> much easier
On Wed, Nov 04, 2015 at 07:47:38AM GMT, Jason McIntyre wrote:
> On Wed, Nov 04, 2015 at 03:14:56AM +, Raf Czlonka wrote:
> > Hi all,
> >
> > Some explanation regarding the changes:
> >
> > - might -> "needs to" - it has to be there, no "might" about it :^)
> > - I've added the additional http
On Tue, 03 Nov 2015 10:46:57 +0100,
Philip Guenther wrote:
>
> On Sun, 25 Oct 2015, Peter Hajdu wrote:
> > I try to give it one more attempt with a bit more description about the
> > bug.
> >
> > After calling dlclose in _dl_notify_unload_shlib_ group reference counts
> > are decreased by follo
Mike Burns wrote:
It's not a "source file" unless it ends with a newline. Somewhere along
the way "source file" -> "text file."
"Source file" in 1980's Unix docs in context was understood to mean "the file
which is the source of the
text being counted", not "a file of source code for a compiler
On 2015-11-04 01.05.38 -0500, dan mclaughlin wrote:
> On Tue, 3 Nov 2015 21:01:36 -0800 Philip Guenther wrote:
> > ...but it's not a bug. wc's line count is required by POSIX to be a
> > count of the number of newline characters in the involved input.
>
> out of curiosity, do you know why? some
50 matches
Mail list logo
