Re: ports and printf("%n") (was: Re: CVS: cvs.openbsd.org: src)

[Theo de Raadt]

Jeremie Courreges-Anglas  wrote:

> (cc'ing ports bulk builds herders)
> 
> Hi folks,
> 
> On Mon, Aug 30 2021, Theo de Raadt  wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: dera...@cvs.openbsd.org 2021/08/30 05:16:49
> >
> > Modified files:
> > lib/libc/stdio : vfprintf.c vfwprintf.c 
> >
> > Log message:
> > jca and I converted %n to a syslog warning about a year ago, and the ports
> > ecosystem experienced a very good cleanup.  Time has arrived to switch (as
> > planned) to syslog + abort, which will result in a coredump thus identifying
> > the remaining culprits in a more visible fashion.
> > vfprintf(3) and vfwprintf(3) man pages still require documentation changes.
> > with jca
> 
> Ports may suffer from this at build time *and* runtime.  Regarding
> issues at build time we can ease the debugging with the diff below.
> This is not intended for commit, also I intend to drop the _THIS_PORT
> getenv from libc before next release.

I've been arguing that corefiles will be produced, and the directory the
corefile lands in is a pretty strong hint.

But .. not my decision.

ports and printf("%n") (was: Re: CVS: cvs.openbsd.org: src)

[Jeremie Courreges-Anglas]

(cc'ing ports bulk builds herders)

Hi folks,

On Mon, Aug 30 2021, Theo de Raadt  wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   dera...@cvs.openbsd.org 2021/08/30 05:16:49
>
> Modified files:
>   lib/libc/stdio : vfprintf.c vfwprintf.c 
>
> Log message:
> jca and I converted %n to a syslog warning about a year ago, and the ports
> ecosystem experienced a very good cleanup.  Time has arrived to switch (as
> planned) to syslog + abort, which will result in a coredump thus identifying
> the remaining culprits in a more visible fashion.
> vfprintf(3) and vfwprintf(3) man pages still require documentation changes.
> with jca

Ports may suffer from this at build time *and* runtime.  Regarding
issues at build time we can ease the debugging with the diff below.
This is not intended for commit, also I intend to drop the _THIS_PORT
getenv from libc before next release.


Index: bsd.port.mk
===
RCS file: /d/cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1555
diff -u -p -p -u -r1.1555 bsd.port.mk
--- bsd.port.mk 3 May 2021 17:53:15 -   1.1555
+++ bsd.port.mk 9 May 2021 18:50:35 -
@@ -793,6 +793,9 @@ CONFIGURE_ENV += ${_EXTRA_ENV}
 MAKE_ENV += ${_EXTRA_ENV}
 .endif
 
+CONFIGURE_ENV += _THIS_PORT=${WRKSRC}
+MAKE_ENV += _THIS_PORT=${WRKSRC}
+
 .if ${PROPERTIES:Mlld}
 USE_LLD ?= Yes
 .else

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Theo de Raadt]

I hope fixing these ports is easy and fast.

LOOK, let me be clear.

At the very last minute, the sysctl can be changed to return success

But if you guys aren't even going to try to cope with change, that's
coming off a little lame.

There are bad side effects from the past behaviour as well.


Jeremie Courreges-Anglas  wrote:

> On Thu, Sep 27 2018, Stuart Henderson  wrote:
> > On 2018/09/26 20:15, Stuart Henderson wrote:
> >> On 2018/09/26 19:16, Stuart Henderson wrote:
> >> > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> >> > 
> >> > This is likely to cause a bunch of breakage in things reporting CPU stats
> >> > and time is very short to fix them before release.
> >> > 
> >> > If you look after ports that do this, get onto a kernel with this change
> >> > (very new commit so it probably won't be in snaps quite just yet) and
> >> > test ASAP.
> >> 
> >> Some starting points for investigation,
> >> 
> >> assorted mozillas
> >> collectd
> >> conky
> >> go
> >> htop
> >> libgtop2
> >> net-snmp
> >> node
> >> pgtop
> >> py-psutil
> >> libuv (+ embedded copies, at least in cmake, maybe more)
> >> zabbix
> >
> > From a search over extracted ports source and cleaned up (ignoring ifdefs 
> > etc):
> 
> The tests I did so far, thinkpad x230 with HT enabled and hw.smt=0:
> 
> > libgtop2-2.38.0 sysdeps/openbsd/cpu.c:static int mib_cptime_s 
> > [] = { CTL_KERN, KERN_CPTIME2, 0 };
> 
> glibtop_get_cpu() from libgtop2 is broken, I get an abort due to
> a double-free error when using the short program below.
> 
> --8<--
> // cc -g  $(pkg-config --cflags libgtop-2.0) gtop2.c $(pkg-config --libs 
> libgtop-2.0) -L/usr/X11R6/lib
> 
> #include 
> 
> int
> main(void)
> {
>   glibtop_cpu gcpu;
> 
>   glibtop_get_cpu();
>   return 0;
> }
> -->8--
> 
> 100% failures with malloc.conf -> S, 5% without malloc.conf.
> 
> > libuv & vendored copies
> >
> > libuv-1.19.1src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> > cmake-3.10.2Utilities/cmlibuv/src/unix/openbsd.c:  which[1] 
> > = KERN_CPTIME2;
> > moarvm-2017.10  3rdparty/libuv/src/unix/openbsd.c:  which[1] = 
> > KERN_CPTIME2;
> > node-8.12.0 deps/uv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> > passenger-5.1.11
> > src/cxx_supportlib/vendor-copy/libuv/src/unix/openbsd.c:  which[1] = 
> > KERN_CPTIME2;
> > py-uv-1.3.0 deps/libuv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> 
> Looking at the code, uv_cpu_info() will now fail (but at least it
> shouldn't crash).  dunno how many ports actually use it.
> 
> > psutil & vendored copies
> >
> > py-psutil-5.4.3 psutil/arch/openbsd/specific.c:mib[1] = 
> > KERN_CPTIME2;
> > firefox-esr-60.2.1  
> > third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> > KERN_CPTIME2;
> > firefox-62.0.2  
> > third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> > KERN_CPTIME2;
> 
> py-psutil is completely broken, ''import psutil'' fails:
> 
> --8<--
> >>> import psutil
> python2: failed to get kern.cptime2: Operation not supported by device
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/site-packages/psutil/__init__.py", line 
> 1617, in 
> _last_per_cpu_times = cpu_times(percpu=True)
>   File "/usr/local/lib/python2.7/site-packages/psutil/__init__.py", line 
> 1606, in cpu_times
> return _psplatform.per_cpu_times()
>   File "/usr/local/lib/python2.7/site-packages/psutil/_psbsd.py", line 218, 
> in per_cpu_times
> for cpu_t in cext.per_cpu_times():
> -->8--
> 
> Both the libgtop2 and the py-psutil problems are fixed with hw.smt=1.
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

Not ports related, but seeing these failures, it would also be worth
testing snmpd from base with hw.smt=0 on an HT machine.

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Jeremie Courreges-Anglas]

On Thu, Sep 27 2018, Stuart Henderson  wrote:
> On 2018/09/26 20:15, Stuart Henderson wrote:
>> On 2018/09/26 19:16, Stuart Henderson wrote:
>> > N.B. "Ports using KERN_CPTIME2 will need to be updated."
>> > 
>> > This is likely to cause a bunch of breakage in things reporting CPU stats
>> > and time is very short to fix them before release.
>> > 
>> > If you look after ports that do this, get onto a kernel with this change
>> > (very new commit so it probably won't be in snaps quite just yet) and
>> > test ASAP.
>> 
>> Some starting points for investigation,
>> 
>> assorted mozillas
>> collectd
>> conky
>> go
>> htop
>> libgtop2
>> net-snmp
>> node
>> pgtop
>> py-psutil
>> libuv (+ embedded copies, at least in cmake, maybe more)
>> zabbix
>
> From a search over extracted ports source and cleaned up (ignoring ifdefs 
> etc):

The tests I did so far, thinkpad x230 with HT enabled and hw.smt=0:

> libgtop2-2.38.0   sysdeps/openbsd/cpu.c:static int mib_cptime_s 
> [] = { CTL_KERN, KERN_CPTIME2, 0 };

glibtop_get_cpu() from libgtop2 is broken, I get an abort due to
a double-free error when using the short program below.

--8<--
// cc -g  $(pkg-config --cflags libgtop-2.0) gtop2.c $(pkg-config --libs 
libgtop-2.0) -L/usr/X11R6/lib

#include 

int
main(void)
{
glibtop_cpu gcpu;

glibtop_get_cpu();
return 0;
}
-->8--

100% failures with malloc.conf -> S, 5% without malloc.conf.

> libuv & vendored copies
>
> libuv-1.19.1  src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> cmake-3.10.2  Utilities/cmlibuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> moarvm-2017.103rdparty/libuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> node-8.12.0   deps/uv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> passenger-5.1.11  
> src/cxx_supportlib/vendor-copy/libuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> py-uv-1.3.0   deps/libuv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;

Looking at the code, uv_cpu_info() will now fail (but at least it
shouldn't crash).  dunno how many ports actually use it.

> psutil & vendored copies
>
> py-psutil-5.4.3   psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> firefox-esr-60.2.1
> third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> firefox-62.0.2
> third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;

py-psutil is completely broken, ''import psutil'' fails:

--8<--
>>> import psutil
python2: failed to get kern.cptime2: Operation not supported by device
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/psutil/__init__.py", line 1617, 
in 
_last_per_cpu_times = cpu_times(percpu=True)
  File "/usr/local/lib/python2.7/site-packages/psutil/__init__.py", line 1606, 
in cpu_times
return _psplatform.per_cpu_times()
  File "/usr/local/lib/python2.7/site-packages/psutil/_psbsd.py", line 218, in 
per_cpu_times
for cpu_t in cext.per_cpu_times():
-->8--

Both the libgtop2 and the py-psutil problems are fixed with hw.smt=1.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Solene Rapenne]

Stuart Henderson  wrote:
> On 2018/09/26 20:15, Stuart Henderson wrote:
> > On 2018/09/26 19:16, Stuart Henderson wrote:
> > > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> > > 
> > > This is likely to cause a bunch of breakage in things reporting CPU stats
> > > and time is very short to fix them before release.
> > > 
> > > If you look after ports that do this, get onto a kernel with this change
> > > (very new commit so it probably won't be in snaps quite just yet) and
> > > test ASAP.
> > 
> > Some starting points for investigation,
> > 
> > assorted mozillas
> > collectd
> > conky
> > go
> > htop
> > libgtop2
> > net-snmp
> > node
> > pgtop
> > py-psutil
> > libuv (+ embedded copies, at least in cmake, maybe more)
> > zabbix
> 
> From a search over extracted ports source and cleaned up (ignoring ifdefs 
> etc):
> 
> libgtop2-2.38.0   sysdeps/openbsd/cpu.c:static int mib_cptime_s 
> [] = { CTL_KERN, KERN_CPTIME2, 0 };
> conky-1.9.0   src/openbsd.c:int cp_time_mib[] 
> = { CTL_KERN, KERN_CPTIME2, i };
> symon-2.88platform/OpenBSD/sm_cpu.c:st->parg.cp.mib[1] = 
> KERN_CPTIME2;
> xstatbar-0.5  stats.c:  mib_cpus[1] = KERN_CPTIME2;
> xfce4-cpugraph-1.0.5  panel-plugin/os.c:   gint mib[] = {CTL_KERN, 
> KERN_CPTIME2, i - 1};
> net-snmp-5.8  agent/mibgroup/hardware/cpu/cpu_sysctl.c:int
> mcpu_mib[] = { CTL_KERN, KERN_CPTIME2, 0 };
> zabbix-3.4.11 src/zabbix_agent/cpustat.c: mib[1] 
> = KERN_CPTIME2;
> filebeat-6.2.4
> vendor/github.com/elastic/gosigar/sigar_openbsd.go:mib = 
> []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> heartbeat-6.2.4   
> vendor/github.com/elastic/gosigar/sigar_openbsd.go:   mib = 
> []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> metricbeat-6.2.4  vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
>  mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> packetbeat-6.2.4  vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
>  mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> collectd-5.8.0src/cpu.c:  int mib[] = {CTL_KERN, 
> KERN_CPTIME2, i};
> consul-1.2.3  vendor/github.com/shirou/gopsutil/cpu/cpu_openbsd.go:   
> KernCptime2 = 71 // KERN_CPTIME2
> htop-2.2.0openbsd/Platform.c:   int mib[] = { CTL_KERN, 
> KERN_CPTIME2, cpu-1 };
> 
> libuv & vendored copies
> 
> libuv-1.19.1  src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> cmake-3.10.2  Utilities/cmlibuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> moarvm-2017.103rdparty/libuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> node-8.12.0   deps/uv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> passenger-5.1.11  
> src/cxx_supportlib/vendor-copy/libuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> py-uv-1.3.0   deps/libuv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> 
> psutil & vendored copies
> 
> py-psutil-5.4.3   psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> firefox-esr-60.2.1
> third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> firefox-62.0.2
> third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> 
> rust & vendored copies, consts only I believe:
> 
> cbindgen-0.6.3
> modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> const KERN_CPTIME2: ::c_int = 71;
> exa-0.8.0 
> modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> const KERN_CPTIME2: ::c_int = 71;
> firefox-62.0.2
> third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> firefox-esr-60.2.1
> third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> librsvg-2.44.4
> vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> ripgrep-0.8.1 
> modcargo-crates/libc-0.2.36/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> const KERN_CPTIME2: ::c_int = 71;
> rust-1.29.1   
> src/liblibc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> rust-1.29.1   
> src/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> seamonkey-2.49.4  
> mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> seamonkey-2.49.4  
> mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> spidermonkey-52.8.1   
> third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> spidermonkey-52.8.1   
> 

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Solene Rapenne]

Stuart Henderson  wrote:
> On 2018/09/26 19:16, Stuart Henderson wrote:
> > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> > 
> > This is likely to cause a bunch of breakage in things reporting CPU stats
> > and time is very short to fix them before release.
> > 
> > If you look after ports that do this, get onto a kernel with this change
> > (very new commit so it probably won't be in snaps quite just yet) and
> > test ASAP.
> 
> Some starting points for investigation,
> 
> assorted mozillas
> collectd
> conky
> go
> htop
> libgtop2
> net-snmp
> node
> pgtop
> py-psutil
> libuv (+ embedded copies, at least in cmake, maybe more)
> zabbix
> 
> > 
> > 
> > 
> > - Forwarded message from Scott Soule Cheloha  -
> > 
> > From: Scott Soule Cheloha 
> > Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT)
> > To: source-chan...@openbsd.org
> > Subject: CVS: cvs.openbsd.org: src
> > 
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13
> > 
> > Modified files:
> > sys/kern   : kern_sched.c kern_sysctl.c 
> > sys/sys: sched.h 
> > usr.bin/systat : cpu.c vmstat.c 
> > usr.bin/top: display.c display.h machine.c machine.h top.c 
> > 
> > Log message:
> > KERN_CPTIME2: set ENODEV if the CPU is offline.
> > 
> > This lets userspace distinguish between idle CPUs and those that are
> > not schedulable because hw.smt=0.
> > 
> > A subsequent commit probably needs to add documentation for this
> > to sysctl.2 (and perhaps elsewhere) after the dust settles.
> > 
> > Also included here are changes to systat(1) and top(1) that account
> > for the ENODEV case and adjust behavior accordingly:
> > 
> > - systat(1)'s cpu view prints placeholder marks ('-') instead of
> > percentages for each state if the given CPU is offline.
> > 
> > - systat(1)'s vmstat view checks for offline CPUs when computing the
> > machine state total and excludes them, so the CPU usage graph
> > only represents the states for online CPUs.
> > 
> > - top(1) does not draw CPU rows for offline CPUs when the view is
> > redrawn.  If CPUs "go offline", percentages for each state are
> > replaced by placeholder marks ('-'); the view will need to be
> > redrawn to remove these rows.  If CPUs "go online" the view will
> > need to be redrawn to show these new CPUs.  In "combined CPU" mode,
> > the count and the state totals only represent online CPUs.
> > 
> > Ports using KERN_CPTIME2 will need to be updated.  The changes
> > described above to make systat(1) and top(1) aware of the ENODEV
> > case *and* gracefully handle a changing HW_NCPUONLINE while the
> > application is running are not necessarily appropriate for each
> > and every port.
> > 
> > The changes described above are so extensive in part to demonstrate
> > one way a program *might* be made robust to changing CPU availability.
> > In particular, changing hw.smt after boot is an extremely rare event,
> > and this needs to be weighed when updating ports.
> > 
> > The logic needed to account for the KERN_CPTIME2 ENODEV case is
> > very roughly:
> > 
> > if (sysctl(...) == -1) {
> > if (errno != ENODEV) {
> > /* Actual error occurred. */
> > } else {
> > /* CPU is offline. */
> > }
> > } else {
> > /* CPU is online and CPU states were set by sysctl(2). */
> > }
> > 
> > Prompted by deraadt@.  Basic idea for ENODEV from kettenis@.  Discussed at
> > length with kettenis@.  Additional testing by tb@.
> > 
> > No complaints from hackers@ after a week.
> > 
> > ok kettenis@, "I think you should commit [now]" deraadt@
> > 
> > 
> > - End forwarded message -
> > 

conky hw.smt=0 ERROR :

 conky  


 Conky: desktop window (1c00010) is subwindow of root window (e1)
 Conky: window type - desktop
 Conky: drawing to created window (0x1e1)
 Conky: drawing to single buffer
 Conky: sysctl kern.cp_time2 failed
 Conky: sysctl kern.cp_time2 failed
 Conky: sysctl kern.cp_time2 failed
 Conky: sysctl kern.cp_time2 failed

conky hw.smt=1 OK

htop hw.smt=0 OK
htop hw.smt=1 OK

top hw.smt=0 OK
top hw.smt=1 OK


zabbix: hw.smt=0 OK
zabbix: hw.smt=1 OK

tested with zabbix_get -s localhost -k system.cpu.util


xstatba

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Sebastien Marie]

On Thu, Sep 27, 2018 at 09:25:51PM +0100, Stuart Henderson wrote:
> > 
> > From a search over extracted ports source and cleaned up (ignoring ifdefs 
> > etc):
> 
> The rust-related things are not going to be actually using it so you
> can ignore those.

yes. it is the Rust libc (re)definition. so just the constant for
program that would use it. but nothing use it currently.

> > rust & vendored copies, consts only I believe:
> > 
> > cbindgen-0.6.3  
> > modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> > const KERN_CPTIME2: ::c_int = 71;
> > exa-0.8.0   
> > modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> > const KERN_CPTIME2: ::c_int = 71;
> > firefox-62.0.2  
> > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > firefox-esr-60.2.1  
> > third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > librsvg-2.44.4  
> > vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > ripgrep-0.8.1   
> > modcargo-crates/libc-0.2.36/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> > const KERN_CPTIME2: ::c_int = 71;
> > rust-1.29.1 
> > src/liblibc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > rust-1.29.1 
> > src/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > seamonkey-2.49.4
> > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > seamonkey-2.49.4
> > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > spidermonkey-52.8.1 
> > third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > spidermonkey-52.8.1 
> > third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > suricata-4.0.5  
> > rust/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > tb-browser-7.5.3
> > third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > tb-browser-7.5.3
> > third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > thunderbird-52.9.1  
> > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > thunderbird-52.9.1  
> > mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
> > KERN_CPTIME2: ::c_int = 71;
> > 
> 

Thanks for the investigation time sthen@.
-- 
Sebastien Marie

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2018/09/27 20:06, Stuart Henderson wrote:
> On 2018/09/26 20:15, Stuart Henderson wrote:
> > On 2018/09/26 19:16, Stuart Henderson wrote:
> > > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> > > 
> > > This is likely to cause a bunch of breakage in things reporting CPU stats
> > > and time is very short to fix them before release.
> > > 
> > > If you look after ports that do this, get onto a kernel with this change
> > > (very new commit so it probably won't be in snaps quite just yet) and
> > > test ASAP.
> > 
> > Some starting points for investigation,
> > 
> > assorted mozillas
> > collectd
> > conky
> > go
> > htop
> > libgtop2
> > net-snmp
> > node
> > pgtop
> > py-psutil
> > libuv (+ embedded copies, at least in cmake, maybe more)
> > zabbix
> 
> From a search over extracted ports source and cleaned up (ignoring ifdefs 
> etc):

Before we can figure out how to fix things we need to know what's
actually broken by this change. If you have a CPU with hyperthreading
available and enabled in BIOS it would be helpful to make sure you
have a new enough system (if it's new enough, you willl see output
from "strings /usr/bin/top | grep '%s%5s %s'") and try some of the
programs from the list below (with the default sysctl hw.smt=0 setting)
and exercise any cpu-time related functionality.

Ports in the first group below are likely easy enough to figure out how
to test (for things like htop and xstatbar just running them should be
enough, some others will need config).

Second and third groups might be a bit trickier as I don't know what if
anything would trigger actually using that.

The rust-related things are not going to be actually using it so you
can ignore those.


> libgtop2-2.38.0   sysdeps/openbsd/cpu.c:static int mib_cptime_s 
> [] = { CTL_KERN, KERN_CPTIME2, 0 };
> conky-1.9.0   src/openbsd.c:int cp_time_mib[] 
> = { CTL_KERN, KERN_CPTIME2, i };
> symon-2.88platform/OpenBSD/sm_cpu.c:st->parg.cp.mib[1] = 
> KERN_CPTIME2;
> xstatbar-0.5  stats.c:  mib_cpus[1] = KERN_CPTIME2;
> xfce4-cpugraph-1.0.5  panel-plugin/os.c:   gint mib[] = {CTL_KERN, 
> KERN_CPTIME2, i - 1};
> net-snmp-5.8  agent/mibgroup/hardware/cpu/cpu_sysctl.c:int
> mcpu_mib[] = { CTL_KERN, KERN_CPTIME2, 0 };
> zabbix-3.4.11 src/zabbix_agent/cpustat.c: mib[1] 
> = KERN_CPTIME2;
> filebeat-6.2.4
> vendor/github.com/elastic/gosigar/sigar_openbsd.go:mib = 
> []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> heartbeat-6.2.4   
> vendor/github.com/elastic/gosigar/sigar_openbsd.go:   mib = 
> []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> metricbeat-6.2.4  vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
>  mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> packetbeat-6.2.4  vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
>  mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
> collectd-5.8.0src/cpu.c:  int mib[] = {CTL_KERN, 
> KERN_CPTIME2, i};
> consul-1.2.3  vendor/github.com/shirou/gopsutil/cpu/cpu_openbsd.go:   
> KernCptime2 = 71 // KERN_CPTIME2
> htop-2.2.0openbsd/Platform.c:   int mib[] = { CTL_KERN, 
> KERN_CPTIME2, cpu-1 };
> 
> libuv & vendored copies
> 
> libuv-1.19.1  src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> cmake-3.10.2  Utilities/cmlibuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> moarvm-2017.103rdparty/libuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> node-8.12.0   deps/uv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> passenger-5.1.11  
> src/cxx_supportlib/vendor-copy/libuv/src/unix/openbsd.c:  which[1] = 
> KERN_CPTIME2;
> py-uv-1.3.0   deps/libuv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
> 
> psutil & vendored copies
> 
> py-psutil-5.4.3   psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> firefox-esr-60.2.1
> third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> firefox-62.0.2
> third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;
> 
> rust & vendored copies, consts only I believe:
> 
> cbindgen-0.6.3
> modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> const KERN_CPTIME2: ::c_int = 71;
> exa-0.8.0 
> modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
> const KERN_CPTIME2: ::c_int = 71;
> firefox-62.0.2
> third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> firefox-esr-60.2.1
> third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
> KERN_CPTIME2: ::c_int = 71;
> librsvg-2.44.4
> 

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Landry Breuil]

On Thu, Sep 27, 2018 at 08:06:39PM +0100, Stuart Henderson wrote:
> On 2018/09/26 20:15, Stuart Henderson wrote:
> > On 2018/09/26 19:16, Stuart Henderson wrote:
> > > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> > > 
> > > This is likely to cause a bunch of breakage in things reporting CPU stats
> > > and time is very short to fix them before release.
> > > 
> > > If you look after ports that do this, get onto a kernel with this change
> > > (very new commit so it probably won't be in snaps quite just yet) and
> > > test ASAP.
> > 
> > Some starting points for investigation,
> > 
> > assorted mozillas
> > collectd
> > conky
> > go
> > htop
> > libgtop2
> > net-snmp
> > node
> > pgtop
> > py-psutil
> > libuv (+ embedded copies, at least in cmake, maybe more)
> > zabbix
> 
> From a search over extracted ports source and cleaned up (ignoring ifdefs 
> etc):
> 
> 
> py-psutil-5.4.3   psutil/arch/openbsd/specific.c:mib[1] = 
> KERN_CPTIME2;

For the surrounding code:
https://github.com/giampaolo/psutil/blob/master/psutil/arch/openbsd/specific.c#L651

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2018/09/26 20:15, Stuart Henderson wrote:
> On 2018/09/26 19:16, Stuart Henderson wrote:
> > N.B. "Ports using KERN_CPTIME2 will need to be updated."
> > 
> > This is likely to cause a bunch of breakage in things reporting CPU stats
> > and time is very short to fix them before release.
> > 
> > If you look after ports that do this, get onto a kernel with this change
> > (very new commit so it probably won't be in snaps quite just yet) and
> > test ASAP.
> 
> Some starting points for investigation,
> 
> assorted mozillas
> collectd
> conky
> go
> htop
> libgtop2
> net-snmp
> node
> pgtop
> py-psutil
> libuv (+ embedded copies, at least in cmake, maybe more)
> zabbix

>From a search over extracted ports source and cleaned up (ignoring ifdefs etc):

libgtop2-2.38.0 sysdeps/openbsd/cpu.c:static int mib_cptime_s [] = { 
CTL_KERN, KERN_CPTIME2, 0 };
conky-1.9.0 src/openbsd.c:int cp_time_mib[] 
= { CTL_KERN, KERN_CPTIME2, i };
symon-2.88  platform/OpenBSD/sm_cpu.c:st->parg.cp.mib[1] = 
KERN_CPTIME2;
xstatbar-0.5stats.c:  mib_cpus[1] = KERN_CPTIME2;
xfce4-cpugraph-1.0.5panel-plugin/os.c:   gint mib[] = {CTL_KERN, 
KERN_CPTIME2, i - 1};
net-snmp-5.8agent/mibgroup/hardware/cpu/cpu_sysctl.c:int
mcpu_mib[] = { CTL_KERN, KERN_CPTIME2, 0 };
zabbix-3.4.11   src/zabbix_agent/cpustat.c: mib[1] 
= KERN_CPTIME2;
filebeat-6.2.4  vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
   mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
heartbeat-6.2.4 vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
  mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
metricbeat-6.2.4vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
 mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
packetbeat-6.2.4vendor/github.com/elastic/gosigar/sigar_openbsd.go: 
 mib = []int32{C.CTL_KERN, C.KERN_CPTIME2, int32(curcpu)}
collectd-5.8.0  src/cpu.c:  int mib[] = {CTL_KERN, KERN_CPTIME2, i};
consul-1.2.3vendor/github.com/shirou/gopsutil/cpu/cpu_openbsd.go:   
KernCptime2 = 71 // KERN_CPTIME2
htop-2.2.0  openbsd/Platform.c:   int mib[] = { CTL_KERN, 
KERN_CPTIME2, cpu-1 };

libuv & vendored copies

libuv-1.19.1src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
cmake-3.10.2Utilities/cmlibuv/src/unix/openbsd.c:  which[1] = 
KERN_CPTIME2;
moarvm-2017.10  3rdparty/libuv/src/unix/openbsd.c:  which[1] = 
KERN_CPTIME2;
node-8.12.0 deps/uv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;
passenger-5.1.11
src/cxx_supportlib/vendor-copy/libuv/src/unix/openbsd.c:  which[1] = 
KERN_CPTIME2;
py-uv-1.3.0 deps/libuv/src/unix/openbsd.c:  which[1] = KERN_CPTIME2;

psutil & vendored copies

py-psutil-5.4.3 psutil/arch/openbsd/specific.c:mib[1] = 
KERN_CPTIME2;
firefox-esr-60.2.1  
third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
KERN_CPTIME2;
firefox-62.0.2  
third_party/python/psutil/psutil/arch/openbsd/specific.c:mib[1] = 
KERN_CPTIME2;

rust & vendored copies, consts only I believe:

cbindgen-0.6.3  
modcargo-crates/libc-0.2.41/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
const KERN_CPTIME2: ::c_int = 71;
exa-0.8.0   
modcargo-crates/libc-0.2.30/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
const KERN_CPTIME2: ::c_int = 71;
firefox-62.0.2  
third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
firefox-esr-60.2.1  
third_party/rust/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
librsvg-2.44.4  
vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: 
::c_int = 71;
ripgrep-0.8.1   
modcargo-crates/libc-0.2.36/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub 
const KERN_CPTIME2: ::c_int = 71;
rust-1.29.1 
src/liblibc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const KERN_CPTIME2: 
::c_int = 71;
rust-1.29.1 
src/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
seamonkey-2.49.4
mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
seamonkey-2.49.4
mozilla/third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
spidermonkey-52.8.1 
third_party/rust/libc/src/unix/bsd/openbsdlike/bitrig.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
spidermonkey-52.8.1 
third_party/rust/libc/src/unix/bsd/openbsdlike/openbsd.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
suricata-4.0.5  
rust/vendor/libc/src/unix/bsd/netbsdlike/openbsdlike/mod.rs:pub const 
KERN_CPTIME2: ::c_int = 71;
tb-browser-7.5.3

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2018/09/26 12:28, Chris Bennett wrote:
> I was about to file a bug report, perhaps this is relevant here?
> 
> This was happening also on a recent snap before this one.
> 
> Using spectrwm, my windows freeze up until I go yo another screen and
> back. For example, cat file or ls -la show screen output, but no
> scrolling with mouse until I switch screens back and forth.
> Same for firefox, etc.

It's not going to be related to the current topic of today's commit to
KERN_CPTIME2.

The spectrwm port was updated recently (9 September) so I'd expect it's
probably related to that.


> 
> OpenBSD 6.4-beta (GENERIC.MP) #325: Tue Sep 25 22:24:42 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4077236224 (3888MB)
> avail mem = 3944398848 (3761MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdbb33000 (45 entries)
> bios0: vendor LENOVO version "5PCN20WW" date 01/15/2018
> bios0: LENOVO 80XV
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST SSDT MSDM BATB SSDT SSDT 
> IVRS CRAT VFCT SSDT FPDT SSDT BGRT UEFI
> acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) 
> GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 16 (boot processor)
> cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.81 MHz, 15-70-00
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT
> cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 
> 16-way L2 cache
> cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
> cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 17 (application processor)
> cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.39 MHz, 15-70-00
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT
> cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 
> 16-way L2 cache
> cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
> cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
> cpu1: smt 1, core 0, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped
> ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (GPP0)
> acpiprt2 at acpi0: bus -1 (GPP1)
> acpiprt3 at acpi0: bus 1 (GPP2)
> acpiprt4 at acpi0: bus 2 (GPP3)
> acpiprt5 at acpi0: bus -1 (GPP4)
> acpiprt6 at acpi0: bus -1 (GFX0)
> acpiprt7 at acpi0: bus -1 (GFX1)
> acpiprt8 at acpi0: bus -1 (GFX2)
> acpiprt9 at acpi0: bus -1 (GFX3)
> acpiprt10 at acpi0: bus -1 (GFX4)
> acpiec0 at acpi0
> acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS
> acpipwrres0 at acpi0: P0U3, resource for XHC0
> acpipwrres1 at acpi0: P3U3, resource for XHC0
> acpipwrres2 at acpi0: P0U2, resource for EHC1
> acpipwrres3 at acpi0: P3U2, resource for EHC1
> acpipwrres4 at acpi0: P0SD
> acpipwrres5 at acpi0: P3SD
> acpipwrres6 at acpi0: P0ST, resource for SATA
> acpipwrres7 at acpi0: P3ST, resource for SATA
> acpibtn0 at acpi0: PWRB
> acpicmos0 at acpi0
> acpibat0 at acpi0: BAT0 model "L16L2PB2" serial  3458 type LiP oem "LGC"
> "VPC2004" at acpi0 not configured
> acpiac0 at acpi0: AC unit online
> acpibtn1 at acpi0: LID_
> "PNP0C14" at acpi0 not configured
> "AMD0030" at acpi0 not configured
> "AMD0010" at acpi0 not configured
> "ELAN060C" at acpi0 not configured
> acpivideo0 at acpi0: VGA_
> acpivideo1 at acpi0: VGA_
> acpivideo2 at acpi0: VGA_
> cpu0: 2994 MHz: speeds: 3000 2700 2400 2100 1800 1400 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD AMD64 15h Root Complex" rev 0x00
> "AMD AMD64 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured
> vendor "ATI", 

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Chris Bennett]

I was about to file a bug report, perhaps this is relevant here?
This was happening also on a recent snap before this one.

Using spectrwm, my windows freeze up until I go yo another screen and
back. For example, cat file or ls -la show screen output, but no
scrolling with mouse until I switch screens back and forth.
Same for firefox, etc.


OpenBSD 6.4-beta (GENERIC.MP) #325: Tue Sep 25 22:24:42 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4077236224 (3888MB)
avail mem = 3944398848 (3761MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdbb33000 (45 entries)
bios0: vendor LENOVO version "5PCN20WW" date 01/15/2018
bios0: LENOVO 80XV
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST SSDT MSDM BATB SSDT SSDT IVRS 
CRAT VFCT SSDT FPDT SSDT BGRT UEFI
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) 
GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.81 MHz, 15-70-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT
cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.39 MHz, 15-70-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT
cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 1, core 0, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped
ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (GPP0)
acpiprt2 at acpi0: bus -1 (GPP1)
acpiprt3 at acpi0: bus 1 (GPP2)
acpiprt4 at acpi0: bus 2 (GPP3)
acpiprt5 at acpi0: bus -1 (GPP4)
acpiprt6 at acpi0: bus -1 (GFX0)
acpiprt7 at acpi0: bus -1 (GFX1)
acpiprt8 at acpi0: bus -1 (GFX2)
acpiprt9 at acpi0: bus -1 (GFX3)
acpiprt10 at acpi0: bus -1 (GFX4)
acpiec0 at acpi0
acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS
acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS
acpipwrres0 at acpi0: P0U3, resource for XHC0
acpipwrres1 at acpi0: P3U3, resource for XHC0
acpipwrres2 at acpi0: P0U2, resource for EHC1
acpipwrres3 at acpi0: P3U2, resource for EHC1
acpipwrres4 at acpi0: P0SD
acpipwrres5 at acpi0: P3SD
acpipwrres6 at acpi0: P0ST, resource for SATA
acpipwrres7 at acpi0: P3ST, resource for SATA
acpibtn0 at acpi0: PWRB
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "L16L2PB2" serial  3458 type LiP oem "LGC"
"VPC2004" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpibtn1 at acpi0: LID_
"PNP0C14" at acpi0 not configured
"AMD0030" at acpi0 not configured
"AMD0010" at acpi0 not configured
"ELAN060C" at acpi0 not configured
acpivideo0 at acpi0: VGA_
acpivideo1 at acpi0: VGA_
acpivideo2 at acpi0: VGA_
cpu0: 2994 MHz: speeds: 3000 2700 2400 2100 1800 1400 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 15h Root Complex" rev 0x00
"AMD AMD64 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured
vendor "ATI", unknown product 0x98e4 (class display subclass VGA, rev 0xda) at 
pci0 dev 1 function 0 not configured
azalia0 at pci0 dev 1 function 1 vendor "ATI", unknown product 0x15b3 rev 0x00: 
msi
azalia0: no supported codecs
pchb1 at pci0 dev 2 function 0 "AMD AMD64 15h Host" rev 0x00
ppb0 at pci0 dev 2 function 3 "AMD AMD64 15h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
vendor "Atheros", unknown product 0x0042 (class network 

Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2018/09/26 19:16, Stuart Henderson wrote:
> N.B. "Ports using KERN_CPTIME2 will need to be updated."
> 
> This is likely to cause a bunch of breakage in things reporting CPU stats
> and time is very short to fix them before release.
> 
> If you look after ports that do this, get onto a kernel with this change
> (very new commit so it probably won't be in snaps quite just yet) and
> test ASAP.

Some starting points for investigation,

assorted mozillas
collectd
conky
go
htop
libgtop2
net-snmp
node
pgtop
py-psutil
libuv (+ embedded copies, at least in cmake, maybe more)
zabbix

> 
> 
> 
> - Forwarded message from Scott Soule Cheloha  -
> 
> From: Scott Soule Cheloha 
> Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT)
> To: source-chan...@openbsd.org
> Subject: CVS: cvs.openbsd.org: src
> 
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   chel...@cvs.openbsd.org 2018/09/26 11:23:13
> 
> Modified files:
>   sys/kern   : kern_sched.c kern_sysctl.c 
>   sys/sys: sched.h 
>   usr.bin/systat : cpu.c vmstat.c 
>   usr.bin/top: display.c display.h machine.c machine.h top.c 
> 
> Log message:
> KERN_CPTIME2: set ENODEV if the CPU is offline.
> 
> This lets userspace distinguish between idle CPUs and those that are
> not schedulable because hw.smt=0.
> 
> A subsequent commit probably needs to add documentation for this
> to sysctl.2 (and perhaps elsewhere) after the dust settles.
> 
> Also included here are changes to systat(1) and top(1) that account
> for the ENODEV case and adjust behavior accordingly:
> 
> - systat(1)'s cpu view prints placeholder marks ('-') instead of
> percentages for each state if the given CPU is offline.
> 
> - systat(1)'s vmstat view checks for offline CPUs when computing the
> machine state total and excludes them, so the CPU usage graph
> only represents the states for online CPUs.
> 
> - top(1) does not draw CPU rows for offline CPUs when the view is
> redrawn.  If CPUs "go offline", percentages for each state are
> replaced by placeholder marks ('-'); the view will need to be
> redrawn to remove these rows.  If CPUs "go online" the view will
> need to be redrawn to show these new CPUs.  In "combined CPU" mode,
> the count and the state totals only represent online CPUs.
> 
> Ports using KERN_CPTIME2 will need to be updated.  The changes
> described above to make systat(1) and top(1) aware of the ENODEV
> case *and* gracefully handle a changing HW_NCPUONLINE while the
> application is running are not necessarily appropriate for each
> and every port.
> 
> The changes described above are so extensive in part to demonstrate
> one way a program *might* be made robust to changing CPU availability.
> In particular, changing hw.smt after boot is an extremely rare event,
> and this needs to be weighed when updating ports.
> 
> The logic needed to account for the KERN_CPTIME2 ENODEV case is
> very roughly:
> 
> if (sysctl(...) == -1) {
> if (errno != ENODEV) {
> /* Actual error occurred. */
> } else {
> /* CPU is offline. */
> }
> } else {
> /* CPU is online and CPU states were set by sysctl(2). */
> }
> 
> Prompted by deraadt@.  Basic idea for ENODEV from kettenis@.  Discussed at
> length with kettenis@.  Additional testing by tb@.
> 
> No complaints from hackers@ after a week.
> 
> ok kettenis@, "I think you should commit [now]" deraadt@
> 
> 
> - End forwarded message -
> 

KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

N.B. "Ports using KERN_CPTIME2 will need to be updated."

This is likely to cause a bunch of breakage in things reporting CPU stats
and time is very short to fix them before release.

If you look after ports that do this, get onto a kernel with this change
(very new commit so it probably won't be in snaps quite just yet) and
test ASAP.




- Forwarded message from Scott Soule Cheloha  -

From: Scott Soule Cheloha 
Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT)
To: source-chan...@openbsd.org
Subject: CVS: cvs.openbsd.org: src

CVSROOT:/cvs
Module name:src
Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13

Modified files:
sys/kern   : kern_sched.c kern_sysctl.c 
sys/sys: sched.h 
usr.bin/systat : cpu.c vmstat.c 
usr.bin/top: display.c display.h machine.c machine.h top.c 

Log message:
KERN_CPTIME2: set ENODEV if the CPU is offline.

This lets userspace distinguish between idle CPUs and those that are
not schedulable because hw.smt=0.

A subsequent commit probably needs to add documentation for this
to sysctl.2 (and perhaps elsewhere) after the dust settles.

Also included here are changes to systat(1) and top(1) that account
for the ENODEV case and adjust behavior accordingly:

- systat(1)'s cpu view prints placeholder marks ('-') instead of
percentages for each state if the given CPU is offline.

- systat(1)'s vmstat view checks for offline CPUs when computing the
machine state total and excludes them, so the CPU usage graph
only represents the states for online CPUs.

- top(1) does not draw CPU rows for offline CPUs when the view is
redrawn.  If CPUs "go offline", percentages for each state are
replaced by placeholder marks ('-'); the view will need to be
redrawn to remove these rows.  If CPUs "go online" the view will
need to be redrawn to show these new CPUs.  In "combined CPU" mode,
the count and the state totals only represent online CPUs.

Ports using KERN_CPTIME2 will need to be updated.  The changes
described above to make systat(1) and top(1) aware of the ENODEV
case *and* gracefully handle a changing HW_NCPUONLINE while the
application is running are not necessarily appropriate for each
and every port.

The changes described above are so extensive in part to demonstrate
one way a program *might* be made robust to changing CPU availability.
In particular, changing hw.smt after boot is an extremely rare event,
and this needs to be weighed when updating ports.

The logic needed to account for the KERN_CPTIME2 ENODEV case is
very roughly:

if (sysctl(...) == -1) {
if (errno != ENODEV) {
/* Actual error occurred. */
} else {
/* CPU is offline. */
}
} else {
/* CPU is online and CPU states were set by sysctl(2). */
}

Prompted by deraadt@.  Basic idea for ENODEV from kettenis@.  Discussed at
length with kettenis@.  Additional testing by tb@.

No complaints from hackers@ after a week.

ok kettenis@, "I think you should commit [now]" deraadt@


- End forwarded message -

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

On 2018/05/01 22:00, Vadim Zhukov wrote:
> 2018-04-29 9:48 GMT+03:00 Kirill Bychkov :
> > On Sun, April 29, 2018 00:25, Stuart Henderson wrote:
> >> It needs more of a change than that, the syntax is different.
> >>
> >
> > Hi!
> > It uses /usr/bin/mail so it is safe to drop embedded smtp (see
> > /etc/apcupsd/apccontrol) and I doubt someone tweaked it to use
> > other mailers instead of its default.So no tweaks for MESSAGE
> > are needed, IMO.
> > Thanks for noticing it!
> > OK kirby@
> 
> So there are likely literally 0 users of /usr/local/sbin/smtp on
> OpenBSD. IIUC, this executable is actually needed on Windows, which
> doesn't have an easy to use SMTP mailer bundled.[1] Stuart, the
> maintainer (Kirill) proposes just killing the executable in port, do
> you still think there should be more work done?

When I first looked into this I saw some Linux packaging making
changes relating to the smtp command which is why I thought it might
be more widely used. OK to remove, I'd prefer no MESSAGE, but think a
quick mention in faq/current.html (to add to upgrade64 later) would
make sense.

> [1] Well, there was Outlook Express at some point, and something
> similar nowadays, but that wasn't easy to use, and this is offtopic
> anyway.

PowerShell's Send-MailMessage, but I digress... :-)

Re: CVS: cvs.openbsd.org: src

[Vadim Zhukov]

2018-04-29 9:48 GMT+03:00 Kirill Bychkov :
> On Sun, April 29, 2018 00:25, Stuart Henderson wrote:
>> It needs more of a change than that, the syntax is different.
>>
>
> Hi!
> It uses /usr/bin/mail so it is safe to drop embedded smtp (see
> /etc/apcupsd/apccontrol) and I doubt someone tweaked it to use
> other mailers instead of its default.So no tweaks for MESSAGE
> are needed, IMO.
> Thanks for noticing it!
> OK kirby@

So there are likely literally 0 users of /usr/local/sbin/smtp on
OpenBSD. IIUC, this executable is actually needed on Windows, which
doesn't have an easy to use SMTP mailer bundled.[1] Stuart, the
maintainer (Kirill) proposes just killing the executable in port, do
you still think there should be more work done?

--
  WBR,
  Vadim Zhukov

[1] Well, there was Outlook Express at some point, and something
similar nowadays, but that wasn't easy to use, and this is offtopic
anyway.

Re: CVS: cvs.openbsd.org: src

[Kirill Bychkov]

On Sun, April 29, 2018 00:25, Stuart Henderson wrote:
> It needs more of a change than that, the syntax is different.
>

Hi!
It uses /usr/bin/mail so it is safe to drop embedded smtp (see
/etc/apcupsd/apccontrol) and I doubt someone tweaked it to use
other mailers instead of its default.So no tweaks for MESSAGE
are needed, IMO.
Thanks for noticing it!
OK kirby@

> --
> Sent from a phone, apologies for poor formatting.
> On 28 April 2018 18:30:32 Vadim Zhukov  wrote:
>
>> 2018-04-28 19:54 GMT+03:00 Eric Faurot :
>> > CVSROOT:/cvs
>> > Module name:src
>> > Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11
>> >
>> > Modified files:
>> > usr.sbin/smtpd : Makefile
>> >
>> > Log message:
>> > link smtp(1) to the build
>> >
>> > ok deraadt@
>>
>> Some care would be needed for apcupsd port, which installs
>> /usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp
>> and port could just stop installing it. The existing smtp users could
>> be affected, though, so I propose the following patch. Any better
>> ideas/objections/okays?
>>
>> --
>>  WBR,
>>  Vadim Zhukov
>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v
>> retrieving revision 1.38
>> diff -u -p -r1.38 Makefile
>> --- Makefile12 Jan 2018 14:05:10 -  1.38
>> +++ Makefile28 Apr 2018 17:27:33 -
>> @@ -9,7 +9,7 @@ PKGNAME-main =  ${DISTNAME}
>> PKGNAME-cgi =  ${DISTNAME:S/-/-cgi-/}
>> PKGNAME-x11 =  ${DISTNAME:S/-/-x11-/}
>> REVISION = 1
>> -REVISION-main =2
>> +REVISION-main =3
>>
>> CATEGORIES =   sysutils
>>
>> @@ -108,5 +108,6 @@ post-install:
>>${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/
>>cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd
>>chmod 755 ${PREFIX}/sbin/apcupsctl
>> +   rm -f ${PREFIX}/sbin/smtp
>>
>> .include 
>> Index: pkg/MESSAGE-main
>> ===
>> RCS file: pkg/MESSAGE-main
>> diff -N pkg/MESSAGE-main
>> --- /dev/null   1 Jan 1970 00:00:00 -
>> +++ pkg/MESSAGE-main28 Apr 2018 17:27:33 -
>> @@ -0,0 +1,2 @@
>> +The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4.
>> +Any scripts using it should now use the /usr/bin/smtp instead.
>> Index: pkg/PLIST-main
>> ===
>> RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v
>> retrieving revision 1.9
>> diff -u -p -r1.9 PLIST-main
>> --- pkg/PLIST-main  22 Jan 2015 21:23:30 -  1.9
>> +++ pkg/PLIST-main  28 Apr 2018 17:27:33 -
>> @@ -14,7 +14,6 @@
>> @mode
>> @owner
>> sbin/apcupsctl
>> -@bin sbin/smtp
>> @comment share/applications/
>> @group
>> share/doc/apcupsd/
>
>
>
>

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

It needs more of a change than that, the syntax is different.

--
Sent from a phone, apologies for poor formatting.
On 28 April 2018 18:30:32 Vadim Zhukov  wrote:


2018-04-28 19:54 GMT+03:00 Eric Faurot :
> CVSROOT:/cvs
> Module name:src
> Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11
>
> Modified files:
> usr.sbin/smtpd : Makefile
>
> Log message:
> link smtp(1) to the build
>
> ok deraadt@

Some care would be needed for apcupsd port, which installs
/usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp
and port could just stop installing it. The existing smtp users could
be affected, though, so I propose the following patch. Any better
ideas/objections/okays?

--
 WBR,
 Vadim Zhukov


Index: Makefile
===
RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile12 Jan 2018 14:05:10 -  1.38
+++ Makefile28 Apr 2018 17:27:33 -
@@ -9,7 +9,7 @@ PKGNAME-main =  ${DISTNAME}
PKGNAME-cgi =  ${DISTNAME:S/-/-cgi-/}
PKGNAME-x11 =  ${DISTNAME:S/-/-x11-/}
REVISION = 1
-REVISION-main =2
+REVISION-main =3

CATEGORIES =   sysutils

@@ -108,5 +108,6 @@ post-install:
   ${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/
   cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd
   chmod 755 ${PREFIX}/sbin/apcupsctl
+   rm -f ${PREFIX}/sbin/smtp

.include 
Index: pkg/MESSAGE-main
===
RCS file: pkg/MESSAGE-main
diff -N pkg/MESSAGE-main
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/MESSAGE-main28 Apr 2018 17:27:33 -
@@ -0,0 +1,2 @@
+The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4.
+Any scripts using it should now use the /usr/bin/smtp instead.
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST-main
--- pkg/PLIST-main  22 Jan 2015 21:23:30 -  1.9
+++ pkg/PLIST-main  28 Apr 2018 17:27:33 -
@@ -14,7 +14,6 @@
@mode
@owner
sbin/apcupsctl
-@bin sbin/smtp
@comment share/applications/
@group
share/doc/apcupsd/

Re: CVS: cvs.openbsd.org: src

[Vadim Zhukov]

2018-04-28 19:54 GMT+03:00 Eric Faurot :
> CVSROOT:/cvs
> Module name:src
> Changes by: e...@cvs.openbsd.org2018/04/28 10:54:11
>
> Modified files:
> usr.sbin/smtpd : Makefile
>
> Log message:
> link smtp(1) to the build
>
> ok deraadt@

Some care would be needed for apcupsd port, which installs
/usr/local/sbin/smtp. IIUC, it does the same thing as /usr/bin/smtp
and port could just stop installing it. The existing smtp users could
be affected, though, so I propose the following patch. Any better
ideas/objections/okays?

--
  WBR,
  Vadim Zhukov


Index: Makefile
===
RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile12 Jan 2018 14:05:10 -  1.38
+++ Makefile28 Apr 2018 17:27:33 -
@@ -9,7 +9,7 @@ PKGNAME-main =  ${DISTNAME}
 PKGNAME-cgi =  ${DISTNAME:S/-/-cgi-/}
 PKGNAME-x11 =  ${DISTNAME:S/-/-x11-/}
 REVISION = 1
-REVISION-main =2
+REVISION-main =3

 CATEGORIES =   sysutils

@@ -108,5 +108,6 @@ post-install:
${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/
cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd
chmod 755 ${PREFIX}/sbin/apcupsctl
+   rm -f ${PREFIX}/sbin/smtp

 .include 
Index: pkg/MESSAGE-main
===
RCS file: pkg/MESSAGE-main
diff -N pkg/MESSAGE-main
--- /dev/null   1 Jan 1970 00:00:00 -
+++ pkg/MESSAGE-main28 Apr 2018 17:27:33 -
@@ -0,0 +1,2 @@
+The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4.
+Any scripts using it should now use the /usr/bin/smtp instead.
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST-main
--- pkg/PLIST-main  22 Jan 2015 21:23:30 -  1.9
+++ pkg/PLIST-main  28 Apr 2018 17:27:33 -
@@ -14,7 +14,6 @@
 @mode
 @owner
 sbin/apcupsctl
-@bin sbin/smtp
 @comment share/applications/
 @group
 share/doc/apcupsd/
Index: Makefile
===
RCS file: /cvs/ports/sysutils/apcupsd/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile	12 Jan 2018 14:05:10 -	1.38
+++ Makefile	28 Apr 2018 17:27:33 -
@@ -9,7 +9,7 @@ PKGNAME-main =		${DISTNAME}
 PKGNAME-cgi =		${DISTNAME:S/-/-cgi-/}
 PKGNAME-x11 =		${DISTNAME:S/-/-x11-/}
 REVISION =		1
-REVISION-main =		2
+REVISION-main =		3
 
 CATEGORIES =		sysutils
 
@@ -108,5 +108,6 @@ post-install:
 		${WRKINST}/${WEB_ROOT}/cgi-bin/apcupsd/
 	cd ${PREFIX}/share; chown -R root:wheel doc/apcupsd examples/apcupsd
 	chmod 755 ${PREFIX}/sbin/apcupsctl
+	rm -f ${PREFIX}/sbin/smtp
 
 .include 
Index: pkg/MESSAGE-main
===
RCS file: pkg/MESSAGE-main
diff -N pkg/MESSAGE-main
--- /dev/null	1 Jan 1970 00:00:00 -
+++ pkg/MESSAGE-main	28 Apr 2018 17:27:33 -
@@ -0,0 +1,2 @@
+The ${LOCALBASE}/sbin/smtp from this package is gone since OpenBSD 6.4.
+Any scripts using it should now use the /usr/bin/smtp instead.
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/sysutils/apcupsd/pkg/PLIST-main,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST-main
--- pkg/PLIST-main	22 Jan 2015 21:23:30 -	1.9
+++ pkg/PLIST-main	28 Apr 2018 17:27:33 -
@@ -14,7 +14,6 @@
 @mode
 @owner
 sbin/apcupsctl
-@bin sbin/smtp
 @comment share/applications/
 @group
 share/doc/apcupsd/

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[viq]

On 17-07-30 22:20:59, viq wrote:
> On 17-07-30 22:10:43, viq wrote:
> > On 17-07-30 15:50:44, Ted Unangst wrote:
> > > viq wrote:
> > > > > > anybody know what's going on?
> > > > > 
> > > > > From my running salt with trace logs, it seems that salt initialises
> > > > > everything, opens it's IPC sockets, initiates it's AES auth/handshake
> > > > > with master, and that's when things die.
> > > > 
> > > > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines,
> > > > 4.2MB compressed
> > > 
> > > not especially. i already know *what* it does. somebody has to read the 
> > > code
> > > to figure out why.
> > 
> >  If you tell me what to write, I could create an issue upstream. Or you
> >  could skip the middleman and do it at
> >  https://github.com/saltstack/salt/issues and let them deal with reading
> >  the code ;)
> 
>   https://github.com/saltstack/salt/issues/42634

As per
https://github.com/saltstack/salt/issues/42634#issuecomment-320029538
this is in ZeroMQ, and currently upstream's advice is we default to TCP
transport for Salt on OpenBSD - which would require switching master
such nodes are connected to, and all minions that are connected to same
master.
   
> > > anyway, i turned the check off for now. it's good to know it triggers, but
> > > with clang and other changes now isn't the best time.
> > 
> > Thank you.

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[viq]

On 17-07-30 22:10:43, viq wrote:
> On 17-07-30 15:50:44, Ted Unangst wrote:
> > viq wrote:
> > > > > anybody know what's going on?
> > > > 
> > > > From my running salt with trace logs, it seems that salt initialises
> > > > everything, opens it's IPC sockets, initiates it's AES auth/handshake
> > > > with master, and that's when things die.
> > > 
> > > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines,
> > > 4.2MB compressed
> > 
> > not especially. i already know *what* it does. somebody has to read the code
> > to figure out why.
> 
>  If you tell me what to write, I could create an issue upstream. Or you
>  could skip the middleman and do it at
>  https://github.com/saltstack/salt/issues and let them deal with reading
>  the code ;)

  https://github.com/saltstack/salt/issues/42634
  
> > anyway, i turned the check off for now. it's good to know it triggers, but
> > with clang and other changes now isn't the best time.
> 
> Thank you.

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[viq]

On 17-07-30 15:50:44, Ted Unangst wrote:
> viq wrote:
> > > > anybody know what's going on?
> > > 
> > > From my running salt with trace logs, it seems that salt initialises
> > > everything, opens it's IPC sockets, initiates it's AES auth/handshake
> > > with master, and that's when things die.
> > 
> > Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines,
> > 4.2MB compressed
> 
> not especially. i already know *what* it does. somebody has to read the code
> to figure out why.

 If you tell me what to write, I could create an issue upstream. Or you
 could skip the middleman and do it at
 https://github.com/saltstack/salt/issues and let them deal with reading
 the code ;)
 
> anyway, i turned the check off for now. it's good to know it triggers, but
> with clang and other changes now isn't the best time.

Thank you.

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[Ted Unangst]

viq wrote:
> > > anybody know what's going on?
> > 
> > From my running salt with trace logs, it seems that salt initialises
> > everything, opens it's IPC sockets, initiates it's AES auth/handshake
> > with master, and that's when things die.
> 
> Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines,
> 4.2MB compressed

not especially. i already know *what* it does. somebody has to read the code
to figure out why.

anyway, i turned the check off for now. it's good to know it triggers, but
with clang and other changes now isn't the best time.

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[viq]

On 17-07-28 23:34:29, viq wrote:
> On 17-07-28 16:04:16, Ted Unangst wrote:
> > moving to ports
> > 
> > viq wrote:
> > > On 17-07-27 10:35:08, Ted Unangst wrote:
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: t...@cvs.openbsd.org2017/07/27 10:35:08
> > > > 
> > > > Modified files:
> > > > lib/librthread : rthread.c rthread_fork.c 
> > > > 
> > > > Log message:
> > > > bad things can (and will) happen if a threaded program calls fork() and
> > > > then strays off the path to exec(). one common manifestation of this
> > > > problem occurs in pthread_join(), so we can add a little check there.
> > > > first person to hit this in real life gets to change the error message.
> > > 
> > > So, uh, would that be me?
> > > $ doas salt-minion  
> > > great scott! serious repercussions on future events!
> > > $ echo $?
> > > 250
> > > $ sysctl kern.version
> > > kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT 
> > > 2017
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> > 
> > i'm not sure what salt is doing (or even what it is),
> 
> I can't tell you what it's doing, but it's a remote execution and
> configuration management framework written in python, running (by
> default) over ZeroMQ.
> 
> > but this is probably not
> > good. calling pthread_join() in the child after fork() is not something 
> > you're
> > supposed to do.
> > 
> > anybody know what's going on?
> 
> From my running salt with trace logs, it seems that salt initialises
> everything, opens it's IPC sockets, initiates it's AES auth/handshake
> with master, and that's when things die.

Would output of ktrace/kdump be useful here? FWIW it's 24MB, 240k lines,
4.2MB compressed

Re: salt threads? Re: CVS: cvs.openbsd.org: src

[viq]

On 17-07-28 16:04:16, Ted Unangst wrote:
> moving to ports
> 
> viq wrote:
> > On 17-07-27 10:35:08, Ted Unangst wrote:
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   t...@cvs.openbsd.org2017/07/27 10:35:08
> > > 
> > > Modified files:
> > >   lib/librthread : rthread.c rthread_fork.c 
> > > 
> > > Log message:
> > > bad things can (and will) happen if a threaded program calls fork() and
> > > then strays off the path to exec(). one common manifestation of this
> > > problem occurs in pthread_join(), so we can add a little check there.
> > > first person to hit this in real life gets to change the error message.
> > 
> > So, uh, would that be me?
> > $ doas salt-minion  
> > great scott! serious repercussions on future events!
> > $ echo $?
> > 250
> > $ sysctl kern.version
> > kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT 2017
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
> i'm not sure what salt is doing (or even what it is),

I can't tell you what it's doing, but it's a remote execution and
configuration management framework written in python, running (by
default) over ZeroMQ.

> but this is probably not
> good. calling pthread_join() in the child after fork() is not something you're
> supposed to do.
> 
> anybody know what's going on?

>From my running salt with trace logs, it seems that salt initialises
everything, opens it's IPC sockets, initiates it's AES auth/handshake
with master, and that's when things die.

salt threads? Re: CVS: cvs.openbsd.org: src

[Ted Unangst]

moving to ports

viq wrote:
> On 17-07-27 10:35:08, Ted Unangst wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: t...@cvs.openbsd.org2017/07/27 10:35:08
> > 
> > Modified files:
> > lib/librthread : rthread.c rthread_fork.c 
> > 
> > Log message:
> > bad things can (and will) happen if a threaded program calls fork() and
> > then strays off the path to exec(). one common manifestation of this
> > problem occurs in pthread_join(), so we can add a little check there.
> > first person to hit this in real life gets to change the error message.
> 
> So, uh, would that be me?
> $ doas salt-minion  
> great scott! serious repercussions on future events!
> $ echo $?
> 250
> $ sysctl kern.version
> kern.version=OpenBSD 6.1-current (GENERIC) #13: Thu Jul 27 19:51:38 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

i'm not sure what salt is doing (or even what it is), but this is probably not
good. calling pthread_join() in the child after fork() is not something you're
supposed to do.

anybody know what's going on?

Re: CVS: cvs.openbsd.org: src

[Vadim Zhukov]

Will do. Sorry for inconvenience, I had to think about this first. :(

26 июл. 2017 г. 18:10 пользователь "Stuart Henderson" 
написал:

Please could you leave a bit of a larger gap between changes to base,
and changes to ports which depend on them? 24-48h would be reasonable
unless it's a time when snaps aren't being built.  Thanks!


On 2017/07/23 03:48, Vadim Zhukov wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   z...@cvs.openbsd.org2017/07/23 03:48:53
>
> Modified files:
>   usr.bin/libtool/LT/Mode: Link.pm
>
> Log message:
> Recognize '-weak' in our libtool, helps at least xine-lib to build.
>
> okay aja@
>

On 2017/07/23 03:52, Vadim Zhukov wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   z...@cvs.openbsd.org2017/07/23 03:52:14
>
> Modified files:
>   multimedia/xine-lib: Makefile
>
> Log message:
> xine-lib doesn't need USE_LIBTOOL anymore.
>
> Requires recent libtool from base.
>

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

Please could you leave a bit of a larger gap between changes to base,
and changes to ports which depend on them? 24-48h would be reasonable
unless it's a time when snaps aren't being built.  Thanks!


On 2017/07/23 03:48, Vadim Zhukov wrote:
> CVSROOT:  /cvs
> Module name:  src
> Changes by:   z...@cvs.openbsd.org2017/07/23 03:48:53
> 
> Modified files:
>   usr.bin/libtool/LT/Mode: Link.pm 
> 
> Log message:
> Recognize '-weak' in our libtool, helps at least xine-lib to build.
> 
> okay aja@
> 

On 2017/07/23 03:52, Vadim Zhukov wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   z...@cvs.openbsd.org2017/07/23 03:52:14
> 
> Modified files:
>   multimedia/xine-lib: Makefile 
> 
> Log message:
> xine-lib doesn't need USE_LIBTOOL anymore.
> 
> Requires recent libtool from base.
> 

Re: CVS: cvs.openbsd.org: src

[Antoine Jacoutot]

On Fri, Sep 02, 2016 at 10:44:52AM +0100, Stuart Henderson wrote:
> On 2016/09/02 11:28, Alexandre Ratchov wrote:
> > On Fri, Sep 02, 2016 at 10:08:43AM +0200, Antoine Jacoutot wrote:
> > > On Wed, Aug 31, 2016 at 01:22:43AM -0600, Alexandre Ratchov wrote:
> > > > CVSROOT:/cvs
> > > > Module name:src
> > > > Changes by: ratc...@cvs.openbsd.org 2016/08/31 01:22:43
> > > > 
> > > > Modified files:
> > > > share/man/man4 : audio.4 
> > > > sys/dev: audio.c audio_if.h 
> > > > sys/sys: audioio.h 
> > > > sys/kern   : kern_pledge.c 
> > > > 
> > > > Log message:
> > > > Delete unused ioctls and associated macros. Move macros that are still
> > > > used internally by low-level drivers from sys/audioio.h to
> > > > dev/audio_if.h instead of deleting them.
> > > 
> > > This broke ports/x11/emiclock.
> > > 
> > > error: 'AUDIO_DRAIN' undeclared (first use in this function)
> > > 
> > 
> > According to sources, sound never worked on modern machines.  Given
> > that last update of emiclock was in ~2000, $MASTER_SITES is dead,
> > before I start fixing this, I'd prefer asking what's the most more
> > appropriate:
> >  - fix sound?
> >  - disable sound?
> >  - delete emiclock?
> 
> Since it is marked "PERMIT_PACKAGE_FTP= may not modify/package"
> I think deleting it makes sense.

I agree.




> 
> 
> > Meanwhile, below is a quick fix to keep the current behavior:
> > AUDIO_DRAIN is useless in this case, because close() drains anyway. 
> > So just drop the calls to AUDIO_DRAIN.
> > 
> > OK?
> > 
> > (moving discutions to ports@)
> > 
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/x11/emiclock/Makefile,v
> > retrieving revision 1.26
> > diff -u -p -u -p -r1.26 Makefile
> > --- Makefile11 Oct 2013 21:21:00 -  1.26
> > +++ Makefile2 Sep 2016 09:18:58 -
> > @@ -3,7 +3,7 @@
> >  COMMENT=   hyper-animated face analog clock for X11
> >  
> >  DISTNAME=  emiclock-2.0.2
> > -REVISION=  3
> > +REVISION=  4
> >  CATEGORIES=x11
> >  
> >  MASTER_SITES=  http://download.vector.co.jp/pack/unix/personal/tokei/
> > Index: patches/patch-sys_FreeBSD_audio_c
> > ===
> > RCS file: /cvs/ports/x11/emiclock/patches/patch-sys_FreeBSD_audio_c,v
> > retrieving revision 1.1
> > diff -u -p -u -p -r1.1 patch-sys_FreeBSD_audio_c
> > --- patches/patch-sys_FreeBSD_audio_c   26 Oct 2007 20:44:07 -  
> > 1.1
> > +++ patches/patch-sys_FreeBSD_audio_c   2 Sep 2016 09:18:58 -
> > @@ -1,6 +1,6 @@
> >  $OpenBSD$
> >  --- sys/FreeBSD/audio.c.orig   Thu Sep  2 16:34:34 1999
> > -+++ sys/FreeBSD/audio.cFri Oct 26 22:33:32 2007
> >  sys/FreeBSD/audio.cFri Sep  2 11:13:33 2016
> >  @@ -90,7 +90,9 @@ S_PlaySound(char *soundfile)
> > return (SOUND_DEVICE_ERROR);
> >   }
> > @@ -11,19 +11,17 @@ $OpenBSD$
> >   
> >   fstat(sfile, );
> >   len = sstat.st_size;
> > -@@ -100,7 +102,11 @@ S_PlaySound(char *soundfile)
> > +@@ -100,7 +102,9 @@ S_PlaySound(char *soundfile)
> >   if ( (l = read(sfile, buffer, len)) > 0)
> > write(sdev, buffer, l);
> >   
> >  +#ifdef __FreeBSD__
> >   ioctl(sdev, SNDCTL_DSP_SYNC, 0);
> > -+#elif defined(__OpenBSD__)
> > -+ioctl(sdev, AUDIO_DRAIN, 0);
> >  +#endif
> >   XtFree(buffer);
> >   
> >   close(sdev); 
> > -@@ -159,11 +165,17 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr)
> > +@@ -159,11 +163,15 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr)
> > return(SOUND_DEVICE_ERROR);
> >   }
> >   
> > @@ -35,8 +33,6 @@ $OpenBSD$
> >   
> >  +#ifdef __FreeBSD__
> >   ioctl(sdev, SNDCTL_DSP_SYNC, 0);
> > -+#elif defined(__OpenBSD__)
> > -+ioctl(sdev, AUDIO_DRAIN, 0);
> >  +#endif
> >   close(sdev);
> >   
> > 

-- 
Antoine

Re: CVS: cvs.openbsd.org: src

[Stuart Henderson]

On 2016/09/02 11:28, Alexandre Ratchov wrote:
> On Fri, Sep 02, 2016 at 10:08:43AM +0200, Antoine Jacoutot wrote:
> > On Wed, Aug 31, 2016 at 01:22:43AM -0600, Alexandre Ratchov wrote:
> > > CVSROOT:  /cvs
> > > Module name:  src
> > > Changes by:   ratc...@cvs.openbsd.org 2016/08/31 01:22:43
> > > 
> > > Modified files:
> > >   share/man/man4 : audio.4 
> > >   sys/dev: audio.c audio_if.h 
> > >   sys/sys: audioio.h 
> > >   sys/kern   : kern_pledge.c 
> > > 
> > > Log message:
> > > Delete unused ioctls and associated macros. Move macros that are still
> > > used internally by low-level drivers from sys/audioio.h to
> > > dev/audio_if.h instead of deleting them.
> > 
> > This broke ports/x11/emiclock.
> > 
> > error: 'AUDIO_DRAIN' undeclared (first use in this function)
> > 
> 
> According to sources, sound never worked on modern machines.  Given
> that last update of emiclock was in ~2000, $MASTER_SITES is dead,
> before I start fixing this, I'd prefer asking what's the most more
> appropriate:
>  - fix sound?
>  - disable sound?
>  - delete emiclock?

Since it is marked "PERMIT_PACKAGE_FTP= may not modify/package"
I think deleting it makes sense.


> Meanwhile, below is a quick fix to keep the current behavior:
> AUDIO_DRAIN is useless in this case, because close() drains anyway. 
> So just drop the calls to AUDIO_DRAIN.
> 
> OK?
> 
> (moving discutions to ports@)
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/emiclock/Makefile,v
> retrieving revision 1.26
> diff -u -p -u -p -r1.26 Makefile
> --- Makefile  11 Oct 2013 21:21:00 -  1.26
> +++ Makefile  2 Sep 2016 09:18:58 -
> @@ -3,7 +3,7 @@
>  COMMENT= hyper-animated face analog clock for X11
>  
>  DISTNAME=emiclock-2.0.2
> -REVISION=3
> +REVISION=4
>  CATEGORIES=  x11
>  
>  MASTER_SITES=http://download.vector.co.jp/pack/unix/personal/tokei/
> Index: patches/patch-sys_FreeBSD_audio_c
> ===
> RCS file: /cvs/ports/x11/emiclock/patches/patch-sys_FreeBSD_audio_c,v
> retrieving revision 1.1
> diff -u -p -u -p -r1.1 patch-sys_FreeBSD_audio_c
> --- patches/patch-sys_FreeBSD_audio_c 26 Oct 2007 20:44:07 -  1.1
> +++ patches/patch-sys_FreeBSD_audio_c 2 Sep 2016 09:18:58 -
> @@ -1,6 +1,6 @@
>  $OpenBSD$
>  --- sys/FreeBSD/audio.c.orig Thu Sep  2 16:34:34 1999
> -+++ sys/FreeBSD/audio.c  Fri Oct 26 22:33:32 2007
>  sys/FreeBSD/audio.c  Fri Sep  2 11:13:33 2016
>  @@ -90,7 +90,9 @@ S_PlaySound(char *soundfile)
>   return (SOUND_DEVICE_ERROR);
>   }
> @@ -11,19 +11,17 @@ $OpenBSD$
>   
>   fstat(sfile, );
>   len = sstat.st_size;
> -@@ -100,7 +102,11 @@ S_PlaySound(char *soundfile)
> +@@ -100,7 +102,9 @@ S_PlaySound(char *soundfile)
>   if ( (l = read(sfile, buffer, len)) > 0)
>   write(sdev, buffer, l);
>   
>  +#ifdef __FreeBSD__
>   ioctl(sdev, SNDCTL_DSP_SYNC, 0);
> -+#elif defined(__OpenBSD__)
> -+ioctl(sdev, AUDIO_DRAIN, 0);
>  +#endif
>   XtFree(buffer);
>   
>   close(sdev); 
> -@@ -159,11 +165,17 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr)
> +@@ -159,11 +163,15 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr)
>   return(SOUND_DEVICE_ERROR);
>   }
>   
> @@ -35,8 +33,6 @@ $OpenBSD$
>   
>  +#ifdef __FreeBSD__
>   ioctl(sdev, SNDCTL_DSP_SYNC, 0);
> -+#elif defined(__OpenBSD__)
> -+ioctl(sdev, AUDIO_DRAIN, 0);
>  +#endif
>   close(sdev);
>   
> 

Re: CVS: cvs.openbsd.org: src

[Alexandre Ratchov]

On Fri, Sep 02, 2016 at 10:08:43AM +0200, Antoine Jacoutot wrote:
> On Wed, Aug 31, 2016 at 01:22:43AM -0600, Alexandre Ratchov wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: ratc...@cvs.openbsd.org 2016/08/31 01:22:43
> > 
> > Modified files:
> > share/man/man4 : audio.4 
> > sys/dev: audio.c audio_if.h 
> > sys/sys: audioio.h 
> > sys/kern   : kern_pledge.c 
> > 
> > Log message:
> > Delete unused ioctls and associated macros. Move macros that are still
> > used internally by low-level drivers from sys/audioio.h to
> > dev/audio_if.h instead of deleting them.
> 
> This broke ports/x11/emiclock.
> 
> error: 'AUDIO_DRAIN' undeclared (first use in this function)
> 

According to sources, sound never worked on modern machines.  Given
that last update of emiclock was in ~2000, $MASTER_SITES is dead,
before I start fixing this, I'd prefer asking what's the most more
appropriate:
 - fix sound?
 - disable sound?
 - delete emiclock?

Meanwhile, below is a quick fix to keep the current behavior:
AUDIO_DRAIN is useless in this case, because close() drains anyway. 
So just drop the calls to AUDIO_DRAIN.

OK?

(moving discutions to ports@)

Index: Makefile
===
RCS file: /cvs/ports/x11/emiclock/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile11 Oct 2013 21:21:00 -  1.26
+++ Makefile2 Sep 2016 09:18:58 -
@@ -3,7 +3,7 @@
 COMMENT=   hyper-animated face analog clock for X11
 
 DISTNAME=  emiclock-2.0.2
-REVISION=  3
+REVISION=  4
 CATEGORIES=x11
 
 MASTER_SITES=  http://download.vector.co.jp/pack/unix/personal/tokei/
Index: patches/patch-sys_FreeBSD_audio_c
===
RCS file: /cvs/ports/x11/emiclock/patches/patch-sys_FreeBSD_audio_c,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-sys_FreeBSD_audio_c
--- patches/patch-sys_FreeBSD_audio_c   26 Oct 2007 20:44:07 -  1.1
+++ patches/patch-sys_FreeBSD_audio_c   2 Sep 2016 09:18:58 -
@@ -1,6 +1,6 @@
 $OpenBSD$
 --- sys/FreeBSD/audio.c.orig   Thu Sep  2 16:34:34 1999
-+++ sys/FreeBSD/audio.cFri Oct 26 22:33:32 2007
 sys/FreeBSD/audio.cFri Sep  2 11:13:33 2016
 @@ -90,7 +90,9 @@ S_PlaySound(char *soundfile)
return (SOUND_DEVICE_ERROR);
  }
@@ -11,19 +11,17 @@ $OpenBSD$
  
  fstat(sfile, );
  len = sstat.st_size;
-@@ -100,7 +102,11 @@ S_PlaySound(char *soundfile)
+@@ -100,7 +102,9 @@ S_PlaySound(char *soundfile)
  if ( (l = read(sfile, buffer, len)) > 0)
write(sdev, buffer, l);
  
 +#ifdef __FreeBSD__
  ioctl(sdev, SNDCTL_DSP_SYNC, 0);
-+#elif defined(__OpenBSD__)
-+ioctl(sdev, AUDIO_DRAIN, 0);
 +#endif
  XtFree(buffer);
  
  close(sdev); 
-@@ -159,11 +165,17 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr)
+@@ -159,11 +163,15 @@ S_PlayCacheSound(SoundCacheBuffer *cacheBufferPtr)
return(SOUND_DEVICE_ERROR);
  }
  
@@ -35,8 +33,6 @@ $OpenBSD$
  
 +#ifdef __FreeBSD__
  ioctl(sdev, SNDCTL_DSP_SYNC, 0);
-+#elif defined(__OpenBSD__)
-+ioctl(sdev, AUDIO_DRAIN, 0);
 +#endif
  close(sdev);
  

Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Marc Espie]

On Mon, Mar 23, 2015 at 07:42:02PM -0700, Constantine A. Murenin wrote:
 On 23 March 2015 at 15:59, Stuart Henderson st...@openbsd.org wrote:
  On 2015/03/23 10:14, Constantine A. Murenin wrote:
  May I also ask why is it necessary to remove the timestamp information
  from the tar archives themselves?
 
  To improve rsyncability.
 
 Could you elaborate?
 
 0. Doesn't rsync ignore timestamps by default anyways?
 
 1. Doesn't src/usr.sbin/pkg_add/OpenBSD/ArcCheck.pm#rev1.29 wipe out
 the timestamps only directly from the tar archives, still leaving them
 intact otherwise?
 
 C.

Dude.  Not having timestamps means that when files don't change, the archive
chunk doesn't change.

We do gzip them by chunks as well, so when a big package like texlive gets
updated, a lot of time, most of the actual .tgz package file *doesn't change 
at all*.

Put back timestamps in the tarball, and gzip will compress things differently,
thus destroying rsyncability completely.

Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Stuart Henderson]

On 2015-03-24, Constantine A. Murenin muren...@gmail.com wrote:
 On 23 March 2015 at 15:59, Stuart Henderson st...@openbsd.org wrote:
 On 2015/03/23 10:14, Constantine A. Murenin wrote:
 May I also ask why is it necessary to remove the timestamp information
 from the tar archives themselves?

 To improve rsyncability.

 Could you elaborate?

 0. Doesn't rsync ignore timestamps by default anyways?

 1. Doesn't src/usr.sbin/pkg_add/OpenBSD/ArcCheck.pm#rev1.29 wipe out
 the timestamps only directly from the tar archives, still leaving them
 intact otherwise?

You're thinking of timestamps of the tgz here. This is about something
else: file *contents*.

Packages these days do some smart ordering of files (so that the
transfer can be stopped before downloading everything, in the case of
an update where binaries change but docs/data files stay the same), to
reduce pkg_add time. They also restart the compression stream at various
points (i.e new dictionary) to improve the chance of rsync finding
common parts between package files. Avoiding timestamps in the tar
removes one thing that might change between one build and the next. The
packing list (+CONTENTS file) which has the real timestamps (and the
signature etc) is in a different compression stream than the main files
in the package.
the main files.

Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Constantine A. Murenin]

On 14 March 2015 at 02:28, Marc Espie es...@nerim.net wrote:
 On Fri, Mar 13, 2015 at 01:13:39PM -0700, Constantine A. Murenin wrote:
 Hello,

 The commit below from 2014-09-16 must have broken the snapshot time
 detection on http://ports.su/ , which must have been broken since
 2014-09-21.

 Is there a cross-platform way to best get it back from the package file?
 Yes, parse the +CONTENTS file and restore the associated @ts.

 Any tool that reads files can do so easily. In perl,
 perl -ne '$seen = 1 if m/sqlports-compact/; if ($seen == 1  m/\@ts\s+(.*)/) 
 { system(date -r $1); exit 0; }' /var/db/pkg/sqlports-compact-*/+CONTENTS
 will retrieve and display the timestamp.

May I also ask why is it necessary to remove the timestamp information
from the tar archives themselves?

I can think of at least one other scenario where the files from the
package might be of interest without http://mdoc.su/o/pkg_add.1 --
harvesting the man-pages from the packages.

Perhaps the change of deleting mtime from tar could be undone going
forward?  Especially since mtime already appears to be required as
part of the header of the tar format, http://mdoc.su/f/tar.5, thus not
even occupying any extra space at all, apart from the possible
compression considerations.

What do we gain by losing the ability to use the normal and
interoperable UNIX tools to examine the archive files of the packages?


 Something similar can be easily cobbled using any kind of sed/awk/grep


 I guess the easiest way would be to fix the date with the snippet as
 follows; or is there a better way?

 %sh -c 'touch -d $(env TZ=GMT date -r $(stat -f%m +CONTENTS)
 +%FT%TZ) share/sqlports-compact'

 You assume sqlports-compacts should/can have the snapshots of +CONTENTS... 
 this is not quite true.

Would any difference be material here?  It seems that it's basically
the same date, as far as estimating the time of the snapshot is
concerned, which in reality is more of an undefined period of multiple
hours anyways.

Cheers,
Constantine.

Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Stuart Henderson]

On 2015/03/23 10:14, Constantine A. Murenin wrote:
 May I also ask why is it necessary to remove the timestamp information
 from the tar archives themselves?

To improve rsyncability.

Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Constantine A. Murenin]

On 23 March 2015 at 15:59, Stuart Henderson st...@openbsd.org wrote:
 On 2015/03/23 10:14, Constantine A. Murenin wrote:
 May I also ask why is it necessary to remove the timestamp information
 from the tar archives themselves?

 To improve rsyncability.

Could you elaborate?

0. Doesn't rsync ignore timestamps by default anyways?

1. Doesn't src/usr.sbin/pkg_add/OpenBSD/ArcCheck.pm#rev1.29 wipe out
the timestamps only directly from the tar archives, still leaving them
intact otherwise?

C.

Re: timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Marc Espie]

On Fri, Mar 13, 2015 at 01:13:39PM -0700, Constantine A. Murenin wrote:
 Hello,
 
 The commit below from 2014-09-16 must have broken the snapshot time
 detection on http://ports.su/ , which must have been broken since
 2014-09-21.
 
 Is there a cross-platform way to best get it back from the package file?
Yes, parse the +CONTENTS file and restore the associated @ts.

Any tool that reads files can do so easily. In perl,
perl -ne '$seen = 1 if m/sqlports-compact/; if ($seen == 1  m/\@ts\s+(.*)/) { 
system(date -r $1); exit 0; }' /var/db/pkg/sqlports-compact-*/+CONTENTS
will retrieve and display the timestamp.

Something similar can be easily cobbled using any kind of sed/awk/grep


 I guess the easiest way would be to fix the date with the snippet as
 follows; or is there a better way?
 
 %sh -c 'touch -d $(env TZ=GMT date -r $(stat -f%m +CONTENTS)
 +%FT%TZ) share/sqlports-compact'

You assume sqlports-compacts should/can have the snapshots of +CONTENTS... this 
is not quite true.

timestamps for sqlports-compact (was: Re: CVS: cvs.openbsd.org: src)

[Constantine A. Murenin]

Hello,

The commit below from 2014-09-16 must have broken the snapshot time
detection on http://ports.su/ , which must have been broken since
2014-09-21.

Is there a cross-platform way to best get it back from the package file?

I see that the timestamps are now embedded within +CONTENTS, and
both +CONTENTS and +DESC themselves have the correct timestamps,
too, just not share/sqlports-compact.

From the reversing as per below, it seems like there are 4 sources for
two timestamps:

2014-09-18T08:47Z
+DESC
+CONTENTS /@ts

2014-09-18T12:17Z
+CONTENTS
+CONTENTS /signify:

I guess the easiest way would be to fix the date with the snippet as
follows; or is there a better way?

%sh -c 'touch -d $(env TZ=GMT date -r $(stat -f%m +CONTENTS)
+%FT%TZ) share/sqlports-compact'

Cheers,
Constantine.



  538 Sep 15 12:29 2014-09-20/+CONTENTS
 3936 Sep 14 07:49 2014-09-20/+DESC
  36918272 Sep 14 07:49 2014-09-20/share/sqlports-compact

  553 Sep 19 05:17 2014-09-21/+CONTENTS
 3936 Sep 18 01:47 2014-09-21/+DESC
  37057536 Dec 31  1969 2014-09-21/share/sqlports-compact



--- 2014-09-20/+CONTENTSMon Sep 15 12:29:20 2014
+++ 2014-09-21/+CONTENTSFri Sep 19 05:17:22 2014
@@ -1,7 +1,7 @@
 @comment $OpenBSD: PLIST-compact,v 1.2 2009/12/01 18:27:46 espie Exp $
 @name sqlports-compact-4.2
 @signer openbsd-56-pkg
-@digital-signature
signify:2014-09-15T19:29:20Z:RWSPEf7Vpp2j0NzTldW+gbzVKDKUDBNV8yr4qbGsLA1j4qi41qVwdNxzzy5+d4Z6ocIuxOXLGAZkL1rZzO9bIXt8vpm6ia6vxg8=
+@digital-signature
signify:2014-09-19T12:17:22Z:RWSPEf7Vpp2j0KKBEBZR4Q/ZNEDFC509xrP2LO6eVXgEzctauBidBAZl4/pMWVqfoG9JXABPiI+wlfZobwoZTxZikYLrX5HXRg0=
 @option always-update
 @comment pkgpath=databases/sqlports,-compact cdrom=yes ftp=yes
 @arch amd64
@@ -10,5 +10,6 @@
 @size 3936
 @cwd /usr/local
 share/sqlports-compact
-@sha E+dRAH5CB2qQd2ZPSRUgGL4uUKYd9WiQDjWkt9lpkP8=
-@size 36918272
+@sha QJrtFZ+Kp8m9as8c6iYSqUjytHlIvopDki/vTw7enlE=
+@size 37057536
+@ts 1411030040



% cat 2014-09-21/+CONTENTS
@comment $OpenBSD: PLIST-compact,v 1.2 2009/12/01 18:27:46 espie Exp $
@name sqlports-compact-4.2
@signer openbsd-56-pkg
@digital-signature
signify:2014-09-19T12:17:22Z:RWSPEf7Vpp2j0KKBEBZR4Q/ZNEDFC509xrP2LO6eVXgEzctauBidBAZl4/pMWVqfoG9JXABPiI+wlfZobwoZTxZikYLrX5HXRg0=
@option always-update
@comment pkgpath=databases/sqlports,-compact cdrom=yes ftp=yes
@arch amd64
+DESC
@sha NdJMzcyumfz+I9nbW0P/qfHc1CT7KcZcGIaCiolyRZo=
@size 3936
@cwd /usr/local
share/sqlports-compact
@sha QJrtFZ+Kp8m9as8c6iYSqUjytHlIvopDki/vTw7enlE=
@size 37057536
@ts 1411030040



% date -r 1411030040
Thu Sep 18 01:47:20 PDT 2014

% env TZ=GMT date -r 1411030040
Thu Sep 18 08:47:20 GMT 2014



% sh -c 'touch -d $(env TZ=GMT date -r $(stat -f%m +CONTENTS)
+%FT%TZ) share/sqlports-compact'

% stat share/sqlports-compact
... 37057536 Sep 19 05:17:22 2014 Sep 19 05:17:22 2014 Mar 13
12:49:33 2015 16384 72416 0 share/sqlports-compact



On 16 September 2014 at 01:51, Marc Espie es...@cvs.openbsd.org wrote:
 CVSROOT:/cvs
 Module name:src
 Changes by: es...@cvs.openbsd.org   2014/09/16 02:51:38

 Modified files:
 usr.sbin/pkg_add/OpenBSD: ArcCheck.pm

 Log message:
 if a @ts annotation is detected, wipe tarball timestamp. Archives will
 look as if all files were born in 1970. The useful side-effect is that
 meta-data for content-identical files WILL be identical as well.

syslogd replacements (was: Re: CVS: cvs.openbsd.org: src)

[Christian Weisgerber]

On 2014-07-14, Theo de Raadt dera...@cvs.openbsd.org wrote:

 CVSROOT:  /cvs
 Module name:  src
 Changes by:   dera...@cvs.openbsd.org 2014/07/13 22:02:33

 Modified files:
   usr.sbin/syslogd: syslogd.c 

 Log message:
 Create a socketpair() and tie one end to /dev/klog using ioctl LIOCSFD.
 This allows us to receive messages direct from programs using the
 fd-safe sendsyslog(2), aka. syslog_r(3).  Thanks to guenther for this part
 of the solution.
 ok beck tedu miod guenther

Theo has reminded me that any syslogd replacements we may have in
ports, e.g. sysutils/rsyslog, will require a corresponding change
or they will NOT work as a drop-in replacement.

Should we mark all candidates we can find as BROKEN to prevent
surprises?

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: syslogd replacements (was: Re: CVS: cvs.openbsd.org: src)

[Theo de Raadt]

 On 2014-07-14, Theo de Raadt dera...@cvs.openbsd.org wrote:
 
  CVSROOT:/cvs
  Module name:src
  Changes by: dera...@cvs.openbsd.org 2014/07/13 22:02:33
 
  Modified files:
  usr.sbin/syslogd: syslogd.c 
 
  Log message:
  Create a socketpair() and tie one end to /dev/klog using ioctl LIOCSFD.
  This allows us to receive messages direct from programs using the
  fd-safe sendsyslog(2), aka. syslog_r(3).  Thanks to guenther for this part
  of the solution.
  ok beck tedu miod guenther
 
 Theo has reminded me that any syslogd replacements we may have in
 ports, e.g. sysutils/rsyslog, will require a corresponding change
 or they will NOT work as a drop-in replacement.
 
 Should we mark all candidates we can find as BROKEN to prevent
 surprises?

They are only broken for syslog_r(3).  syslog(3) still works.  But
that does kind of matter...

The change to syslogd is fairly simple; it could be ported to others
daemons.  Based on an #ifdef on the ioctl name.

Re: syslogd replacements (was: Re: CVS: cvs.openbsd.org: src)

[Stuart Henderson]

On 2014/07/14 07:56, Christian Weisgerber wrote:
 On 2014-07-14, Theo de Raadt dera...@cvs.openbsd.org wrote:
 
  CVSROOT:/cvs
  Module name:src
  Changes by: dera...@cvs.openbsd.org 2014/07/13 22:02:33
 
  Modified files:
  usr.sbin/syslogd: syslogd.c 
 
  Log message:
  Create a socketpair() and tie one end to /dev/klog using ioctl LIOCSFD.
  This allows us to receive messages direct from programs using the
  fd-safe sendsyslog(2), aka. syslog_r(3).  Thanks to guenther for this part
  of the solution.
  ok beck tedu miod guenther
 
 Theo has reminded me that any syslogd replacements we may have in
 ports, e.g. sysutils/rsyslog, will require a corresponding change
 or they will NOT work as a drop-in replacement.
 
 Should we mark all candidates we can find as BROKEN to prevent
 surprises?

I think not. Since it's already very difficult to replace base syslogd
with anything from ports (it loads before ldconfig is done), I think
these are usually run as additional daemons binding to a different
UDP port. Perhaps a warning in README might be warranted, I don't know.

devel/py-openbsd broken [Re: CVS: cvs.openbsd.org: src]

[Stuart Henderson]

On 2014/01/23 16:51, Henning Brauer wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   henn...@cvs.openbsd.org 2014/01/23 16:51:29
 
 Modified files:
   sys/net: if_bridge.c pf.c 
   sys/netinet: ip_input.c ip_output.c ip_var.h tcp_input.c 
tcp_var.h udp_usrreq.c udp_var.h 
   sys/netinet6   : ip6_output.c 
 
 Log message:
 since the cksum rewrite the counters for hardware checksummed packets
 are are lie, since the software engine emulates hardware offloading
 and that is later indistinguishable. so kill the hw cksummed counters.
 introduce software checksummed packet counters instead.
 tcp/udp handles ip  ipvshit, ip cksum covered, 6 has no ip layer cksum.
 as before we still have a miscounting bug for inbound with pf on, to be
 fixed in the next step.
 found by, prodding  ok naddy
 

This breaks devel/py-openbsd. Looks like it hasn't been developed
upstream recently anyway (https://github.com/cortesi/pyopenbsd), so I'm
wondering if it's worth fixing or not. Does anyone actually use it?

Re: CVS: cvs.openbsd.org: src

[Jérémie Courrèges-Anglas]

Pascal Stumpf pascal.stu...@cubes.de writes:

 On Fri, 27 Dec 2013 10:41:30 -0700 (MST), Theo de Raadt wrote:
 CVSROOT: /cvs
 Module name: src
 Changes by:  dera...@cvs.openbsd.org 2013/12/27 10:41:30
 
 Modified files:
  etc/mtree  : 4.4BSD.dist 4.4BSD.root 
 
 Log message:
 /stand has not been used in decades
 ok miod
 
 

 That needs a small adaption in sysutils/memtest86+.  I think just
 putting the bootable files in / is ok.

So do I, ok.

 Index: Makefile
 ===
 RCS file: /cvs/ports/sysutils/memtest86+/Makefile,v
 retrieving revision 1.9
 diff -u -p -r1.9 Makefile
 --- Makefile  11 Mar 2013 11:41:31 -  1.9
 +++ Makefile  27 Dec 2013 18:09:19 -
 @@ -7,7 +7,7 @@ COMMENT=  thorough, stand alone memory t
  VERSION= 4.20
  DISTNAME=memtest86+-${VERSION}
  CATEGORIES=  sysutils
 -REVISION=1
 +REVISION=2
  
  HOMEPAGE=http://www.memtest.org/
  
 Index: pkg/PLIST
 ===
 RCS file: /cvs/ports/sysutils/memtest86+/pkg/PLIST,v
 retrieving revision 1.2
 diff -u -p -r1.2 PLIST
 --- pkg/PLIST 7 Nov 2010 18:29:54 -   1.2
 +++ pkg/PLIST 27 Dec 2013 18:09:19 -
 @@ -4,9 +4,9 @@ share/doc/pkg-readmes/${FULLPKGNAME}
  share/memtest86+/
  share/memtest86+/README
  share/memtest86+/memtest
 -@sample /stand/memtest
 +@sample /memtest
  share/memtest86+/memtest-serial
 -@sample /stand/memtest-serial
 +@sample /memtest-serial
  share/memtest86+/memtest-serial.floppy
  share/memtest86+/memtest-serial.iso
  share/memtest86+/memtest.floppy
 Index: pkg/README
 ===
 RCS file: /cvs/ports/sysutils/memtest86+/pkg/README,v
 retrieving revision 1.2
 diff -u -p -r1.2 README
 --- pkg/README2 Jun 2011 13:41:41 -   1.2
 +++ pkg/README27 Dec 2013 18:09:19 -
 @@ -7,7 +7,7 @@ $RuOBSD: README.OpenBSD,v 1.2 2009/02/07
  
  Using Memtest86+ in OpenBSD environment
  
 -o Reboot the machine and boot Memtest86+ using `boot /stand/memtest' command
 +o Reboot the machine and boot Memtest86+ using `boot memtest' command
at the `boot' prompt.  You can also boot Memtest86+ from network using
pxeboot(8).
  


-- 
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
(previous: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494)

Re: CVS: cvs.openbsd.org: src

[Pascal Stumpf]

On Fri, 27 Dec 2013 10:41:30 -0700 (MST), Theo de Raadt wrote:
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   dera...@cvs.openbsd.org 2013/12/27 10:41:30
 
 Modified files:
   etc/mtree  : 4.4BSD.dist 4.4BSD.root 
 
 Log message:
 /stand has not been used in decades
 ok miod
 
 

That needs a small adaption in sysutils/memtest86+.  I think just
putting the bootable files in / is ok.


Index: Makefile
===
RCS file: /cvs/ports/sysutils/memtest86+/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile11 Mar 2013 11:41:31 -  1.9
+++ Makefile27 Dec 2013 18:09:19 -
@@ -7,7 +7,7 @@ COMMENT=thorough, stand alone memory t
 VERSION=   4.20
 DISTNAME=  memtest86+-${VERSION}
 CATEGORIES=sysutils
-REVISION=  1
+REVISION=  2
 
 HOMEPAGE=  http://www.memtest.org/
 
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/memtest86+/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST   7 Nov 2010 18:29:54 -   1.2
+++ pkg/PLIST   27 Dec 2013 18:09:19 -
@@ -4,9 +4,9 @@ share/doc/pkg-readmes/${FULLPKGNAME}
 share/memtest86+/
 share/memtest86+/README
 share/memtest86+/memtest
-@sample /stand/memtest
+@sample /memtest
 share/memtest86+/memtest-serial
-@sample /stand/memtest-serial
+@sample /memtest-serial
 share/memtest86+/memtest-serial.floppy
 share/memtest86+/memtest-serial.iso
 share/memtest86+/memtest.floppy
Index: pkg/README
===
RCS file: /cvs/ports/sysutils/memtest86+/pkg/README,v
retrieving revision 1.2
diff -u -p -r1.2 README
--- pkg/README  2 Jun 2011 13:41:41 -   1.2
+++ pkg/README  27 Dec 2013 18:09:19 -
@@ -7,7 +7,7 @@ $RuOBSD: README.OpenBSD,v 1.2 2009/02/07
 
 Using Memtest86+ in OpenBSD environment
 
-o Reboot the machine and boot Memtest86+ using `boot /stand/memtest' command
+o Reboot the machine and boot Memtest86+ using `boot memtest' command
   at the `boot' prompt.  You can also boot Memtest86+ from network using
   pxeboot(8).
 

FHASLOCK - FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)

[David Coppa]

On Tue, 04 Jun 2013, Philip Guenther wrote:

 CVSROOT:  /cvs
 Module name:  src
 Changes by:   guent...@cvs.openbsd.org2013/06/04 19:26:00
 
 Modified files:
   sys/sys: fcntl.h file.h 
   sys/kern   : kern_descrip.c vfs_syscalls.c vfs_vnops.c 
   usr.sbin/pstat : pstat.c 
 
 Log message:
 Move FHASLOCK from f_flag to f_iflags, freeing up a bit for passing
 O_* flags and eliminating an XXX comment.
 
 ok matthew@ deraadt@

This change broke sysutils/lsof.

cc  -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 
-DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink 
-DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL 
-DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME 
-DLSOF_VSTR=\5.3\ -I/usr/include -I/sys -O2 -pipe   -c dstore.c
dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function)
*** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (sys.mk:87 
'dstore.o')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 
'/usr/ports/pobj/lsof-4.87/.build_done')
*** Error 1 in /usr/ports/sysutils/lsof 
(/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build')

Ciao,
David

Re: FHASLOCK - FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)

[Landry Breuil]

On Fri, Jun 07, 2013 at 04:57:25PM +0200, David Coppa wrote:
 On Tue, 04 Jun 2013, Philip Guenther wrote:
 
  CVSROOT:/cvs
  Module name:src
  Changes by: guent...@cvs.openbsd.org2013/06/04 19:26:00
  
  Modified files:
  sys/sys: fcntl.h file.h 
  sys/kern   : kern_descrip.c vfs_syscalls.c vfs_vnops.c 
  usr.sbin/pstat : pstat.c 
  
  Log message:
  Move FHASLOCK from f_flag to f_iflags, freeing up a bit for passing
  O_* flags and eliminating an XXX comment.
  
  ok matthew@ deraadt@
 
 This change broke sysutils/lsof.
 
 cc  -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 
 -DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink 
 -DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL 
 -DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME 
 -DLSOF_VSTR=\5.3\ -I/usr/include -I/sys -O2 -pipe   -c dstore.c
 dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function)
 *** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (sys.mk:87 
 'dstore.o')
 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 
 '/usr/ports/pobj/lsof-4.87/.build_done')
 *** Error 1 in /usr/ports/sysutils/lsof 
 (/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build')

Cant we whack lsof instead so that it doesnt try to reach non-public
includes in /sys ? Also, do you have an up2date src/sys ?

Landry

Re: FHASLOCK - FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)

[Philip Guenther]

On Fri, 7 Jun 2013, David Coppa wrote:
 This change broke sysutils/lsof.
 
 cc  -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 
 -DHASMSDOSFS=1 -DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink 
 -DHAS_DINODE_U -DHASI_FFS1 -DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL 
 -DHAS_SYS_PIPEH -DHASKVMGETPROC2 -DHASKVMGETPROCS -DHAS_STRFTIME 
 -DLSOF_VSTR=\5.3\ -I/usr/include -I/sys -O2 -pipe   -c dstore.c
 dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function)
 *** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (sys.mk:87 
 'dstore.o')
 *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 
 '/usr/ports/pobj/lsof-4.87/.build_done')
 *** Error 1 in /usr/ports/sysutils/lsof 
 (/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build')

Just delete the
{ (long)FHASLOCK,   FF_HASLOCK  },

line from dstore.c, or maybe wrap it in #if defined(FHASHLOCK) like 
FMARK and FDEFER are.


Philip

Re: FHASLOCK - FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)

[Scott McEachern]

On 06/07/13 12:17, Philip Guenther wrote:

On Fri, 7 Jun 2013, David Coppa wrote:

This change broke sysutils/lsof.

cc  -DOPENBSDV=5000 -DN_UNIXV=/bsd -DHASNFSPROTO -DHASIPv6 -DHAS9660FS=1 -DHASMSDOSFS=1 
-DHASI_E2FS_PTR -DHASEXT2FS=2 -DHASEFFNLINK=i_effnlink -DHAS_DINODE_U -DHASI_FFS1 
-DHAS_UM_UFS -DHASNCVPID -DUVM -DHAS_UVM_INCL -DHAS_SYS_PIPEH -DHASKVMGETPROC2 
-DHASKVMGETPROCS -DHAS_STRFTIME -DLSOF_VSTR=\5.3\ -I/usr/include -I/sys -O2 
-pipe   -c dstore.c
dstore.c:112: error: 'FHASLOCK' undeclared here (not in a function)
*** Error 1 in /usr/ports/pobj/lsof-4.87/lsof_4.87/lsof_4.87_src (sys.mk:87 
'dstore.o')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2643 
'/usr/ports/pobj/lsof-4.87/.build_done')
*** Error 1 in /usr/ports/sysutils/lsof 
(/usr/ports/infrastructure/mk/bsd.port.mk:2372 'build')

Just delete the
 { (long)FHASLOCK,   FF_HASLOCK  },

line from dstore.c, or maybe wrap it in #if defined(FHASHLOCK) like
FMARK and FDEFER are.


Philip



I just deleted it and lsof built.  Something in kde4 (qt4, I believe) 
wants it, so now my make package of kde4 can continue.


BTW, excellent timing with your fix... you sent it within *minutes* of 
my running into that problem.


--
Scott McEachern

https://www.blackstaff.ca

Those who would give up essential liberty to purchase a little temporary safety 
deserve neither liberty nor safety. -- Benjamin Franklin

Re: FHASLOCK - FIF_HASLOCK (Was: CVS: cvs.openbsd.org: src)

[Matthias Kilian]

On Fri, Jun 07, 2013 at 05:08:37PM +0200, Landry Breuil wrote:
 Cant we whack lsof instead so that it doesnt try to reach non-public
 includes in /sys ? Also, do you have an up2date src/sys ?

I had (and still have) a diff back from 2010, but IIRC, pvalchev@
complained (and was right complaining). I'll try to find the mails
from those days.

Ciao,
Kili

rm nawk (was: Re: CVS: cvs.openbsd.org: src)

[Christian Weisgerber]

Theo de Raadt dera...@cvs.openbsd.org wrote:

 CVSROOT:  /cvs
 Module name:  src
 Changes by:   dera...@cvs.openbsd.org 2010/08/25 13:21:04
 
 Modified files:
   usr.bin/awk: Makefile awk.1 
 
 Log message:
 get rid of the nawk hard link
 ok millert guenther

People following -current should remove the nawk files from their
system... and pay attention to possible ports fallout.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: rm nawk (was: Re: CVS: cvs.openbsd.org: src)

[Stuart Henderson]

On 2010/08/25 21:54, Christian Weisgerber wrote:
 Theo de Raadt dera...@cvs.openbsd.org wrote:
 
  CVSROOT:/cvs
  Module name:src
  Changes by: dera...@cvs.openbsd.org 2010/08/25 13:21:04
  
  Modified files:
  usr.bin/awk: Makefile awk.1 
  
  Log message:
  get rid of the nawk hard link
  ok millert guenther
 
 People following -current should remove the nawk files from their
 system... and pay attention to possible ports fallout.

s/possible//. nawk is in our autoconf cache.

Re: erlang [Re: CVS: cvs.openbsd.org: src]

[Jon Olsson]

On Tue, Mar 21, 2006 at 07:45:54PM +0100, steven mestdagh wrote:
[snip]
 in the mean time Mark Kettenis has committed a new asm implementation
 for exp(3). anyway, erlang is still failing. it is trying to multiply
 3.23E+133 by 3.57E+257 and hangs there. no exp(3) involved afaik.

See:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/erlang/patches/patch-ac?rev=1.3content-type=text/x-cvsweb-markup

and

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/erlang/patches/patch-ad?rev=1.1content-type=text/x-cvsweb-markup

For possible workaronds. I have no amd64 system, so I can't test this.

-- 
Jon

Re: CVS: cvs.openbsd.org: src

[Hannah Schroeter]

Hello!

Could this (and the following commit) affect/fix the problem with
erlang's configure stuff on amd64? Alas, I can't test that myself,
because I don't have any amd64 box at my hands.

Kind regards,

Hannah.

- Forwarded message from Otto Moerbeek [EMAIL PROTECTED] -

From: Otto Moerbeek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Tue, 14 Mar 2006 12:27:57 -0700 (MST)
Subject: CVS: cvs.openbsd.org: src

CVSROOT:/cvs
Module name:src
Changes by: [EMAIL PROTECTED]   2006/03/14 12:27:57

Modified files:
lib/libm   : Makefile 
Removed files:
lib/libm/arch/amd64: e_exp.S 

Log message:
amd64 asm code is not correct for exp(+/-Inf), so until somebody
comes up with a correct asm version, use the C version of exp(3).
ok steven@ kettenis@


- End forwarded message -

erlang [Re: CVS: cvs.openbsd.org: src]

[steven mestdagh]

Hannah Schroeter [2006-03-21, 19:18:32]:
 Hello!
 
 Could this (and the following commit) affect/fix the problem with
 erlang's configure stuff on amd64? Alas, I can't test that myself,
 because I don't have any amd64 box at my hands.
 
 Kind regards,
 
 Hannah.
 
 - Forwarded message from Otto Moerbeek [EMAIL PROTECTED] -
 
 From: Otto Moerbeek [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Date: Tue, 14 Mar 2006 12:27:57 -0700 (MST)
 Subject: CVS: cvs.openbsd.org: src
 
 CVSROOT:  /cvs
 Module name:  src
 Changes by:   [EMAIL PROTECTED]   2006/03/14 12:27:57
 
 Modified files:
   lib/libm   : Makefile 
 Removed files:
   lib/libm/arch/amd64: e_exp.S 
 
 Log message:
 amd64 asm code is not correct for exp(+/-Inf), so until somebody
 comes up with a correct asm version, use the C version of exp(3).
 ok steven@ kettenis@
 
 
 - End forwarded message -

in the mean time Mark Kettenis has committed a new asm implementation
for exp(3). anyway, erlang is still failing. it is trying to multiply
3.23E+133 by 3.57E+257 and hangs there. no exp(3) involved afaik.

steven

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm