Re: powerpc64/pmap.c trouble report

On Sat, May 25, 2024 at 12:35:16AM -0400, George Koehler wrote: > On Tue, 21 May 2024 03:08:49 +0200 > Jeremie Courreges-Anglas wrote: > > > On Tue, May 21, 2024 at 02:51:39AM +0200, Jeremie Courreges-Anglas wrote: > > > This doesn't look powerpc64-

Re: powerpc64/pmap.c trouble report

On Tue, May 21, 2024 at 02:51:39AM +0200, Jeremie Courreges-Anglas wrote: > On Sat, May 18, 2024 at 01:11:56PM -0700, Eric Grosse wrote: > > The openbsd-ppc64-n2vi Go builder machine is converting over to LUCI > > build infrastructure and the new workload may have stepped on a

Re: powerpc64/pmap.c trouble report

On Sat, May 18, 2024 at 01:11:56PM -0700, Eric Grosse wrote: > The openbsd-ppc64-n2vi Go builder machine is converting over to LUCI > build infrastructure and the new workload may have stepped on a > pagedaemon corner case. While running 7.5-stable I reproducibly get > kernel panics "pmap_enter:

Re: pax/tar: reading extended headers of > 512 bytes fails

On Tue, Apr 16, 2024 at 04:29:32PM -0600, Todd C. Miller wrote: > On Wed, 17 Apr 2024 00:08:30 +0200, Jeremie Courreges-Anglas wrote: > > > Indeed, spotted too late, thanks. But maybe the latter looks, ahem, nicer? > > The name and ln_name buffers are sized using it.

Re: pax/tar: reading extended headers of > 512 bytes fails

On Tue, Apr 16, 2024 at 03:54:41PM -0600, Todd C. Miller wrote: > On Tue, 16 Apr 2024 23:39:50 +0200, Jeremie Courreges-Anglas wrote: > > > Here's a cheap trick. Testing with path=... longer than PATH_MAX > > results in broken behavior. If you want to test this with symbolic

Re: pax/tar: reading extended headers of > 512 bytes fails

On Tue, Apr 16, 2024 at 06:23:18PM +0200, Caspar Schutijser wrote: > Hi, > > While I was testing jca@'s diff to make the pax format the > default for tar(1), I ran into the following bug in the code > that reads extended headers. (To be clear: this has nothing to > do with the code that *writes*

Re: umb(4): splassert: rtable_getsource: want 2 have 0

On Thu, Aug 31 2023, Vitaliy Makkoveev wrote: > On Thu, Aug 31, 2023 at 01:42:45PM +0200, Alexander Bluhm wrote: >> On Thu, Aug 31, 2023 at 01:05:11PM +0300, Vitaliy Makkoveev wrote: >> > On Thu, Aug 31, 2023 at 11:26:42AM +0200, Jeremie Courreges-Anglas wrote: >>

Re: umb(4): splassert: rtable_getsource: want 2 have 0

On Thu, Aug 31 2023, Alexander Bluhm wrote: > On Thu, Aug 31, 2023 at 01:05:11PM +0300, Vitaliy Makkoveev wrote: >> On Thu, Aug 31, 2023 at 11:26:42AM +0200, Jeremie Courreges-Anglas wrote: >> > >> > Looks umb(4) triggers the NET_ASSERT_LOCKED() check in >> &g

umb(4): splassert: rtable_getsource: want 2 have 0

Looks umb(4) triggers the NET_ASSERT_LOCKED() check in rtable_getsource() when the umb(4) interface comes up (here with kern.splassert=2 to get context). Reproduced with GENERIC.MP from Aug 28 as well with cvs HEAD/if_umb.c rev 1.54. Something to worry about? OpenBSD 7.3-current (GENERIC.MP)

riscv64: Fatal page fault at [amap_wiperange_chunk?]

First kernel crash during this ports bulk build, I have rebooted the machine. No idea whether this is the usual memory corruption I see on this hardware. OpenBSD/riscv64 (riscv64-4.ports.openbsd.org) (console) login: t[0] == 0x0033635ab000 t[1] == 0xffc0005ab43e t[2] ==

Re: panic: smashed stack in uvm_fault_lower_lookup

On Tue, Aug 22 2023, Jeremie Courreges-Anglas wrote: > I think I have hit this panic once already. Any hint on how to debug > this further? As far as I can see, there's no obvious offender in > uvm_fault_lower_lookup. > > This is current plus guenther's uvm_fault.c diff

panic: smashed stack in uvm_fault_lower_lookup

I think I have hit this panic once already. Any hint on how to debug this further? As far as I can see, there's no obvious offender in uvm_fault_lower_lookup. This is current plus guenther's uvm_fault.c diff (which affects uvm_fault_lower, not uvm_fault_lower_lookup). ddb{0}> sh panic

Re: cc claims ISO C99 support, but %n printf format specifier calls abort()

On Fri, Dec 16 2022, Vincent Lefevre wrote: > On 2022-12-15 18:56:15 -0700, Theo de Raadt wrote: >> There are almost no %n left in the software ecosystem. If we are able >> to make this crossing, everyone else is also capable, and eventually >> will. Just like with gets(). > > FYI, this breaks

Re: connect(2) failure when initiating multiple connections

On Wed, Nov 30 2022, Christian Weisgerber wrote: > For at least two weeks, I have observed a strange error on OpenBSD/amd64 > -current, across multiple snapshots and rebuilds from source during > that time: > > When several ssh processes are spawned in quick succession, SOMETIMES > one of them

Re: route/ifconfig - non-recoverable failure in name resolution upon boot

On Mon, Nov 14 2022, Kirill Miazine wrote: > The most recent snapshot gives non-recoverable failure in name > resolution upon boot starting with configuration which I had not > touched: > > starting network > route: fe80::: non-recoverable failure in name resolution > route: fec0:::

riscv64-1.p panic: smashed stack in uvm_fault_lower_lookup

Quick report: riscv64-1.p paniced yesterday. I don't remember having hit this kind of crash before and I can't tell whether it's the "usual" memory corruption bug I hit since months. The kernel is OpenBSD 7.2-current (GENERIC.MP) #7: Sun Nov 6 07:49:26 MST 2022

Re: riscv64 OpenBSD 7.2 packages are not found at expected URL (typo?)

On Mon, Oct 31 2022, Miguel Landaeta wrote: >>Synopsis: riscv64 OpenBSD 7.2 packages are not found at expected URL >>Category: riscv64 >>Environment: > System : OpenBSD 7.2 > Details : OpenBSD 7.2 (GENERIC.MP) #188: Wed Sep 28 04:06:11 MDT 2022 >

Re: riscv64 panic

On Sun, Apr 10 2022, Jeremie Courreges-Anglas wrote: > On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: >> riscv64.ports was running dpb(1) with two other members in the build >> cluster. A few minutes ago I found it in ddb(4). The report is short, >> sadly, as the m

Re: free - can only display usage

(Moved to ports@, ports-bugs@ isn't widely used or read.) On Tue, Jun 14 2022, Matthew wrote: > Hi, > > The binary package of free-1.1 (sysutils/free) produces only `usage: > free [-m]` no matter what input is given. I can't reproduce here. I suspect that you're passing an unknown option to

Re: riscv64 panic

On Sun, Apr 10 2022, Jeremie Courreges-Anglas wrote: > On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: >> riscv64.ports was running dpb(1) with two other members in the build >> cluster. A few minutes ago I found it in ddb(4). The report is short, >> sadly, as the m

Re: riscv64 panic

On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: > riscv64.ports was running dpb(1) with two other members in the build > cluster. A few minutes ago I found it in ddb(4). The report is short, > sadly, as the machine doesn't return from the 'bt' command. > > The machine

Re: gnutls does not build on arm64, maybe due to llvm

On Mon, Dec 27 2021, Stuart Henderson wrote: > On 2021/12/27 10:11, Yifei Zhan wrote: >> Hi, >> >> gnutls-3.7.2 does not build on my arm64 box (RPi4), it stops the >> following error: > > Known problem since the move to clang 13. mariadb and gcc are broken too. gnutls has been fixed, the

Re: riscv64 panic

On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: > riscv64.ports was running dpb(1) with two other members in the build > cluster. A few minutes ago I found it in ddb(4). The report is short, > sadly, as the machine doesn't return from the 'bt' command. > > The machine

Re: getrrsetbyname() doesn't set RES_USE_DNSSEC, preventing VerifyHostKeyDNS with OpenSSH

On Sat, Nov 20 2021, Florian Obser wrote: > The application can't know if AD is trustworthy or not, I think we > should do this fully in asr(3). > I'll send a diff to tech@ that implements glibc's trust-ad > ( https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/461 ) So is it time to reconsider this

Re: riscv64 panic

On Mon, Nov 01 2021, Jeremie Courreges-Anglas wrote: > On Mon, Nov 01 2021, Jeremie Courreges-Anglas wrote: >> On Mon, Nov 01 2021, Martin Pieuchot wrote: >>> On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote: >>>> On Fri, Oct 08 2021, Jeremie Courreges-Angla

Re: riscv64 panic

On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: > riscv64.ports was running dpb(1) with two other members in the build > cluster. A few minutes ago I found it in ddb(4). The report is short, > sadly, as the machine doesn't return from the 'bt' command. > > The machine

Re: riscv64 panic

On Sun, Oct 31 2021, Jeremie Courreges-Anglas wrote: > On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: >> riscv64.ports was running dpb(1) with two other members in the build >> cluster. A few minutes ago I found it in ddb(4). The report is short, >> sadly, as the m

Re: riscv64 panic

On Mon, Nov 01 2021, Jeremie Courreges-Anglas wrote: > On Mon, Nov 01 2021, Martin Pieuchot wrote: >> On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote: >>> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: >>> > riscv64.ports was running dpb(1) with

Re: riscv64 panic

On Mon, Nov 01 2021, Martin Pieuchot wrote: > On 31/10/21(Sun) 15:57, Jeremie Courreges-Anglas wrote: >> On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: >> > riscv64.ports was running dpb(1) with two other members in the build >> > cluster. A few minu

Re: riscv64 panic

On Fri, Oct 08 2021, Jeremie Courreges-Anglas wrote: > riscv64.ports was running dpb(1) with two other members in the build > cluster. A few minutes ago I found it in ddb(4). The report is short, > sadly, as the machine doesn't return from the 'bt' command. > > The machine

Re: riscv64 panic

On Wed, Oct 20 2021, Jeremie Courreges-Anglas wrote: [...] > The machine is waiting in ddb(4). In the past panics, I didn't get > control back after typing a ddb command, better choose wisely. ;) Here's a nicer looking trace, I lost control after that command. ddb{3}> show panic *cp

Re: riscv64 panic

On Wed, Oct 20 2021, Jeremie Courreges-Anglas wrote: > On Fri, Oct 08 2021, Mark Kettenis wrote: >>> From: Jeremie Courreges-Anglas >>> Date: Fri, 08 Oct 2021 18:19:47 +0200 >>> >>> riscv64.ports was running dpb(1) with two other members in the build

Re: riscv64 panic

On Fri, Oct 08 2021, Mark Kettenis wrote: >> From: Jeremie Courreges-Anglas >> Date: Fri, 08 Oct 2021 18:19:47 +0200 >> >> riscv64.ports was running dpb(1) with two other members in the build >> cluster. A few minutes ago I found it in ddb(4). The report is s

riscv64 panic

riscv64.ports was running dpb(1) with two other members in the build cluster. A few minutes ago I found it in ddb(4). The report is short, sadly, as the machine doesn't return from the 'bt' command. The machine is acting both as an NFS server and and NFS client. OpenBSD/riscv64

Re: [macppc] pixman causes SIGILLs if AltiVec is not supported

On Sun, Jun 13 2021, Matthieu Herrb wrote: > On Sat, Jun 12, 2021 at 11:31:28PM -0600, Theo de Raadt wrote: >> Why not wrap all the ppc_altivec = 1 lines in #ifdef ALTIVEC >> >> Or at the end of cpuattach, #ifndef ALTIVEC, zero the variable. >> >> Obviously the sysctl should indicate 0, if the

Re: firefox vs jitsi: stack exhaustion?

On Fri, Apr 09 2021, Mark Kettenis wrote: >> Date: Fri, 9 Apr 2021 07:09:06 +1000 >> From: Jonathan Matthew >> >> On Thu, Apr 08, 2021 at 10:24:06AM +0200, Martin Pieuchot wrote: >> > firefox often crash when somebody else connects to the jitsi I'm in. >> > The trace looks like a stack

Re: firefox vs jitsi: stack exhaustion?

On Mon, Apr 19 2021, Jeremie Courreges-Anglas wrote: > On Fri, Apr 09 2021, Mark Kettenis wrote: >>> Date: Fri, 9 Apr 2021 07:09:06 +1000 >>> From: Jonathan Matthew >>> >>> On Thu, Apr 08, 2021 at 10:24:06AM +0200, Martin Pieuchot wrote: >>> &

Re: firefox vs jitsi: stack exhaustion?

On Fri, Apr 09 2021, Mark Kettenis wrote: >> Date: Fri, 9 Apr 2021 07:09:06 +1000 >> From: Jonathan Matthew >> >> On Thu, Apr 08, 2021 at 10:24:06AM +0200, Martin Pieuchot wrote: >> > firefox often crash when somebody else connects to the jitsi I'm in. >> > The trace looks like a stack

Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''

On Thu, Oct 29 2020, Damien Miller wrote: > On Wed, 28 Oct 2020, Jeremie Courreges-Anglas wrote: > >> On Wed, Oct 28 2020, Damien Miller wrote: >> > On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote: >> > >> >> On Fri, Oct 23 2020, Damien Miller w

Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''

On Wed, Oct 28 2020, Damien Miller wrote: > On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote: > >> On Fri, Oct 23 2020, Damien Miller wrote: >> > On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote: >> > >> >> >> >> I upgraded my

Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''

On Tue, Oct 27 2020, Jeremie Courreges-Anglas wrote: > On Tue, Oct 27 2020, Damien Miller wrote: >> On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote: >> >>> > I think these were the problems that I fixed around 2020/10/14. If >>> > you remove line

Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''

On Tue, Oct 27 2020, Damien Miller wrote: > On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote: > >> > I think these were the problems that I fixed around 2020/10/14. If >> > you remove line 12 from your known_hosts and reconnect with a ssh >> > built a

Re: endless loop in tcpdump

On Mon, Oct 26 2020, "Peter J. Philipp" wrote: > On Sun, Oct 25, 2020 at 12:15:22AM +0200, Jeremie Courreges-Anglas wrote: >> >> dunno why the strange combination of To/Cc headers so I'll keep bugs@ in Cc: > > My answer is inline below: > >> On

Re: ssh warning: the ED25519 host key for '' differs from the key for the IP address ''

On Fri, Oct 23 2020, Damien Miller wrote: > On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote: > >> >> I upgraded my ports builder from snaps yesterday and I hit this when >> running cvs up: >> >> --8<-- >> russell ~$ ssh anon...@ftp.h

Re: endless loop in tcpdump

dunno why the strange combination of To/Cc headers so I'll keep bugs@ in Cc: On Sat, Oct 24 2020, p...@centroid.eu wrote: >>Synopsis: a specially crafted packet can set tcpdump into an endless loop >>Category: system >>Environment: > System : OpenBSD 6.8 > Details :

ssh warning: the ED25519 host key for '' differs from the key for the IP address ''

I upgraded my ports builder from snaps yesterday and I hit this when running cvs up: --8<-- russell ~$ ssh anon...@ftp.hostserver.de Warning: the ED25519 host key for 'ftp.hostserver.de' differs from the key for the IP address '2a00:15a8:0:100:d91f:5023:0:1' Offending key for IP in

Re: chroot and getting the current user...

On Tue, Sep 08 2020, Richard Bucker wrote: > After reading the refs on submitting bug reports I believe this is the > correct way to present it as it's probably a design issue and may be > subjective as I know I do not know the whole system. So I will generalize > in the hopes that I'm wrong. > >

Re: xterm killed with pledge dns violation

On Mon, Jan 13 2020, Benjamin Baier wrote: > On Mon, 13 Jan 2020 20:45:04 +0100 > Jeremie Courreges-Anglas wrote: > >> ... I think IP_ADDRESS should just go. >> Upstream doesn't seem to care much about it: >> >> https://bugs.freedesktop.org/show_bug.cgi?i

Re: xterm killed with pledge dns violation

On Sun, Jan 12 2020, Matthieu Herrb wrote: > On Sun, Jan 12, 2020 at 02:59:46PM +0100, Benjamin Baier wrote: >> >> Here is my status on this. >> >> Claws-mail 3.17.4p2 has the backout diff so all the testing below was done >> with >> claws-mail 3.17.4p1. >> >> Following the advise from Thomas

Re: ocspcheck fails to load OCSP response from ocsp.sectigo.com

On Sat, Jan 11 2020, Stuart Henderson wrote: > On 2020/01/11 12:48, Kor son of Rynar wrote: >> Hi Stuart, >> >> thank you for your fast reply. >> >> On Fri, Jan 10, 2020 at 7:22 PM Stuart Henderson >> wrote: >> >> > On 2020/01/10 19:13, Kor son of Rynar wrote: >> > > On Fri, Jan 10, 2020 at

Re: [arm64] rcctl start returns (ok) but daemon is not started

On Fri, Dec 20 2019, clematis wrote: > Synopsis: rcctl start returns (ok) but daemon is not started > Category: rcctl / getaddrinfo > Environment: > System : OpenBSD 6.6 > Details : OpenBSD 6.6-current (GENERIC.MP) #386: Wed Dec 18 > 14:42:08 MST 2019 >

IPv4 get ioctls: don't require sa_len

Similar to the recent "dhcpcd: if_learnaddrs: if_addrflags6: Invalid argument" thread[0]. At least ports/net/openvpn is affected, as reported by Landry*. kdump looks like: 88944 openvpn CALL ioctl(4,SIOCGIFNETMASK,0x7f7e8bc0) 88944 openvpn RET ioctl -1 errno 22 Invalid argument

Re: pkg_add ignores TRUSTED_PKG_PATH

On Sat, Mar 02 2019, Bruno Dantas wrote: > I'm running 6.4-stable amd64 on my laptop. I have a repository on my > webserver where I keep custom packages (pardon the "gnuser" in url--the > domain predates my openbsd conversion). Accessing the repository > requires https, username, and password.

Re: ld patch that greatly speeds up linking large programs with debug symbols

On Mon, Feb 25 2019, Jeremie Courreges-Anglas wrote: > +cc sthen since ports/textproc/mupdf is affected by the bug: > > http://build-failures.rhaalovely.net//sparc64/2019-02-03/textproc/mupdf.log > > On Sun, Feb 24 2019, Jeremie Courreges-Anglas wrote: >> On Sat, Feb

Re: ld patch that greatly speeds up linking large programs with debug symbols

+cc sthen since ports/textproc/mupdf is affected by the bug: http://build-failures.rhaalovely.net//sparc64/2019-02-03/textproc/mupdf.log On Sun, Feb 24 2019, Jeremie Courreges-Anglas wrote: > On Sat, Feb 23 2019, Aaron Miller wrote: >> On February 23, 2019 2:50:46 AM PST, Jeremie

Re: ld patch that greatly speeds up linking large programs with debug symbols

On Sat, Feb 23 2019, Aaron Miller wrote: > On February 23, 2019 2:50:46 AM PST, Jeremie Courreges-Anglas > wrote: >>On Sat, May 07 2016, Stefan Kempf wrote: [...] > Hi Jeremie, > > That is concerning. I'm on my phone and haven't had a chance to investigate, > but

Re: ld patch that greatly speeds up linking large programs with debug symbols

On Sat, May 07 2016, Stefan Kempf wrote: > Aaron Miller wrote: >> Hi All, >> >> I was experiencing ~8 minute linking times for a large C++ application >> I have been working on when running -current on amd64. It turns out >> that the decade-old version of ld in the OpenBSD source tree has a bug

Re: switchd unexpectedly exits

On Thu, Sep 06 2018, "Anthony J. Bentley" wrote: > Hi Ayaka, > > Ayaka Koshibe writes: >> On Mon, Sep 3, 2018 at 1:20 PM, Anthony J. Bentley >> wrote: >> > 22881 parent exiting >> > control exiting, pid 20472 >> > ofcconn exiting, pid 93222 >> > # >> >> It looks like switchd died midway through

lock order reversal when starting net/knot

>Synopsis: lock order reversal when starting net/knot >Category: kernel >Environment: System : OpenBSD 6.3 Details : OpenBSD 6.3-current (GENERIC.MP) #125: Wed Jul 11 10:18:39 MDT 2018

Re: Parameter substitution using positional parameters produces unexpected results

On Sun, Jul 08 2018, Anton Lindqvist wrote: > On Sat, Jul 07, 2018 at 10:06:41AM +0200, Andreas Kusalananda Kähäri wrote: >> Hi, >> >> I'm not sure this is a bug or a misunderstanding by me, but it sure >> surprised me: >> >> $ set -- file.txt txt >> >> $ printf 'Two values: %s %s\n'

Re: More potential memory leaks based on not freeing getaddrinfo

On Fri, Jun 15 2018, Thomas Barabosch wrote: > Hi there, > > yesterday I stumbled upon a memory leak in route6d, which got fixed. I > was curious if I could find similar leaks. Please correct me if I am > wrong but I suppose static analysis tools like coverity or clang > analyzer do not detect

Re: More potential memory leaks based on not freeing getaddrinfo

On Sat, Jun 16 2018, Sebastian Benoit wrote: > fix for usr.sbin/ikectl/parser.c > > ok? ok jca@ > diff --git usr.sbin/ikectl/parser.c usr.sbin/ikectl/parser.c > index 52488845fd3..32099bb3b3d 100644 > --- usr.sbin/ikectl/parser.c > +++ usr.sbin/ikectl/parser.c > @@ -273,6 +273,7 @@

Re: curl/w3m https request with torsocks core dump at exit

On Sat, Apr 21 2018, Solene Rapenne wrote: >>Synopsis: >>Category: >>Environment: > System : OpenBSD 6.3 > Details : OpenBSD 6.3-current (GENERIC) #53: Thu Apr 19 11:07:26 > MDT 2018 > >

Re: dig(1) crashes when retrying with tcp.

On Mon, Apr 02 2018, Caspar Schutijser wrote: > Hi, > > On Tue, Jan 24, 2017 at 11:42:37AM +0100, Janne Johansson wrote: >> It was pointed out to me that if you run >> >> dig @h.gtld-servers.net ubuntu.com. se-east-1.clouds.archive.ubuntu.com >> +trace >> >> a few times,

Re: Undefined reference to functions that are a part of amd64 ABI

On Sun, Apr 01 2018, Utkarsh Anand wrote: >> An easier and saner solution would be to use standard Lua instead of >> LuaJIT, as done in the neovim port, passing -DPREFER_LUA=ON to cmake. > "Do you know the definition of insanity?" -- VAAS (Far Cry 3) >

Re: Undefined reference to functions that are a part of amd64 ABI

On Sun, Apr 01 2018, Utkarsh Anand <utkarsh...@yandex.com> wrote: > 01.04.2018, 20:05, "Jeremie Courreges-Anglas" <j...@wxcvbn.org>: >> On Sun, Apr 01 2018, Utkarsh Anand <utkarsh...@yandex.com> wrote: >>>  Thank you all for your inputs. With

Re: Undefined reference to functions that are a part of amd64 ABI

On Sun, Apr 01 2018, Utkarsh Anand wrote: > Thank you all for your inputs. With this, I conclude almost complete > support for OpenBSD: > https://github.com/neovim/neovim/pull/8215/commits/0f65aa585985ad00803d681c85779011c9e9682a This looks very wrong, you should fix the

sparc64 ldom: interrupt_vector: spurious vector 40 at pil 15

Just spotted this, the ldom is currently unresponsive and nothing more appeared on the serial output. fwiw this was spotted after rebooting the domain 50+ times since yesterday. ..>> OpenBSD BOOT 1.9 ERROR: /iscsi-hba: No iscsi-network-bootpath property Trying bsd... Booting

Re: library loading issue? libc.so.92.0

On Sat, Nov 04 2017, jungle boogie wrote: [...] > Killed > mkdir: /tmp/.X11-unix: File exists > mkdir: /tmp/.ICE-unix: File exists > kern.securelevel: 0 -> 1 > ld.so: mktemp: can't load library 'libc.so.92.0' > Killed > creating runtime link editor directory cache. >

Re: bind commands in ENV file cause spurious warnings by security(8)

On Wed, Nov 01 2017, Lari Rasku <lari.ra...@elisanet.fi> wrote: > Jeremie Courreges-Anglas kirjoitti 10/31/17 klo 16:23: >> On Mon, Oct 30 2017, Lari Rasku <lari.ra...@elisanet.fi> wrote: >>> or how it might be worked around. >> >> case $- in *i*) ...;;

Re: bind commands in ENV file cause spurious warnings by security(8)

On Mon, Oct 30 2017, Lari Rasku wrote: > Oct 27 snapshot, amd64. > > I have the following binds in /etc/ksh.bindings: > > bind'^[[7~'=beginning-of-line > bind'^[[8~'=end-of-line > bind'^[[2~'=no-op # insert > bind

Re: inetd(8) pledge error

On Wed, Oct 04 2017, Sebastian Benoit wrote: > i'm not sure that pledge there is correct. > > spawn() gets calles from gettcp() which gets called from the main event > loop, and directly from the event loop. > > The pledge here might be a convenient place to reduce pledges

Re: Memory leak in dhclient(8) on OpenBSD-current

On Wed, Aug 30 2017, Kamil Shakirov wrote: > Hello, > >> Synopsis:Memory leak in dhclient(8) on OpenBSD-current >> Category:system >> Environment: >System : OpenBSD 6.2 >Details : OpenBSD 6.2-beta (GENERIC.MP) #59: Tue Aug 29 15:56:07 MDT > 2017 >

Re: -pg broken with clang

On Thu, Aug 10 2017, Mike Belopuhov wrote: > On Thu, Aug 10, 2017 at 12:27 -0400, Martin Pieuchot wrote: >> On 10/08/17(Thu) 18:21, Mark Kettenis wrote: >> > > Date: Thu, 10 Aug 2017 12:10:27 -0400 >> > > From: Martin Pieuchot >> > > >> > > Building a

Re: link fix in help.1

Andras Farkas writes: > Evening! Noticed the link in help.1 to the FAQ was missing a slash at the > end. > diff is also attached in case it gets mangled Committed, thanks. > --- help.1 Thu Jul 13 03:56:58 2017 > +++ fixdhelp.1 Thu Jul 13 03:57:31 2017 > @@

Re: SSH ~& command crash with a coredump

Grégoire Jadi writes: > n 06/21/17 12:16, Ricardo Mestre wrote: >> Hi, >> >> I can confirm this issue, and the diff below seems to solve it for me. >> >> Could you please test it and let us know if it works on your side? > > It does fix the issue. Thanks you. > >> >>

Re: mandoc -Tlint and Mdocdate

"Ted Unangst" writes: > Ingo Schwarze wrote: >> As there is no fully satisfactory option, i propose the patch below. >> It add the "-W portable" command line option, which is a variant of >> "-W style" hiding messages that only apply to base system manuals. > > I'm not fond

Re: mandoc -Tlint and Mdocdate

Jason McIntyre <j...@kerhand.co.uk> writes: > On Wed, Jun 21, 2017 at 05:22:12PM +0200, Ingo Schwarze wrote: >> Hi Sebastien and Jeremie, >> >> Sebastien Marie wrote on Wed, Jun 21, 2017 at 12:26:14PM +0200: >> > On Wed, Jun 21, 2017 at 11:39:53AM +

Re: mandoc -Tlint and Mdocdate

Sebastien Marie writes: > Hi, > > With latest commits on mandoc (particulary mdoc_validate.c r1.252), I > have a problem with mandoc -Tlint regarding Dd macro. > > Some days ago, I started to validate the man page of sysclean using > mandoc -Tlint. > > sysclean is a tool

Re: netstat reports per-cpu tcp stats instead of system aggregate

Andrei-Marius Radu writes: > Hello, > > This behavior can be seen fairly easy by running netstat multiple times > in quick succession. The values reported seem to depend on the CPU on > which netstat is scheduled to run. > > I have seems this in multiple machines, both

Re: "ioctl VIDIOC_STREAMON: Invalid argument" with Logitech C170

Paul de Weerd writes: > Hi all, > > I'm trying to use a pretty simple (and cheap) webcam, a Logitech C170: > > uvideo1 at uhub1 port 4 configuration 1 interface 0 "vendor 0x046d Webcam > C170" rev 2.00/28.25 addr 2 Looks like this problem comes from the lack of isochronous

Re: panic when mounting 8To ntfs partition

Jeremie Courreges-Anglas <j...@wxcvbn.org> writes: > Landry Breuil <lan...@openbsd.org> writes: > >> Hi, >> >> i know we don't really have an ntfs maintainer, and that nobody should >> use ntfs, but interoperability... >> >> i have a 8

Re: ospf6d exits after ospf6ctl reload

Remi Locherer writes: > Hi, Hi, > ospf6d does not like beeing reloaded and exits. > > Below an example on -current running in VMM. I first noticed it > on an OpenBSD 6.0 amd64 router on real hardware. The issue has already been reported, it's not really new. The code

Re: panic when mounting 8To ntfs partition

Landry Breuil writes: > Hi, > > i know we don't really have an ntfs maintainer, and that nobody should > use ntfs, but interoperability... > > i have a 8Tb 'seagate backup plus hub' appearing as: > > uhub8 at uhub1 port 5 configuration 1 interface 0 "Seagate Backup+ Hub" rev

Re: accept4 w/ SOCK_NONBLOCK, blocks in 6.0...

Luke Small writes: > It says "got here1", doesn't say "got here2", and the process doesn't die. > Since it isn't reading anything from sockfd which is "listen"ing, I expect > it to fail. Is it too much to ask it to fail? SOCK_NONBLOCK doesn't do what you think it does.

Re: accept4 w/ SOCK_NONBLOCK, blocks in 6.0...

Your report is lacking, you're forcing people to guess what your problem actually is. IOW, show the code, what it does on your machine, and what you expect it to do. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: tcpdump segfault in armv7 snapshots

Jeremie Courreges-Anglas <j...@wxcvbn.org> writes: [...] I've committed the fix below. Thanks again for the report. > Index: addrtoname.c > === > RCS file: /d/cvs/src/usr.sbin/tcpdump/addrtoname.c,v > retrie

Re: tcpdump segfault in armv7 snapshots

Jeremie Courreges-Anglas <j...@wxcvbn.org> writes: > Lars Nooden <lars.noo...@gmail.com> writes: > >> On 12/13/16, Stuart Henderson wrote: >>> On 2016/12/13 12:23, Lars Nooden wrote: >>>> On a BeagleBone Black (one that has not been used for GPIO), I

Re: vnconfig path limitation

bhar...@chaosweb.us writes: >>Synopsis: vnconfig does not allow for long (80+ character) path names >>Category: system >>Environment: > System : OpenBSD 5.9 > Details : OpenBSD 5.9 (GENERIC.MP) #6: Wed Aug 3 13:55:15 CEST > 2016 > >

Re: WPA passphrase 63 character with ampersand fails in OpenBSD 6

Marcos Mazoti writes: > Hi! > > A changed my wireless passphrase with a simple "" and it worked. With a > stronger wpakey 63 character with one ampersand (&) it fails. Your report is lacking. There's a hard limit on how many bytes you can use in a passphrase, see IEEE