Re: UPDATE: libuv-1.42.0

2021-12-21 Thread Adriano Barbosa
Removing libuv-1.42.0 solved the problem.
cmake installed 1.40.0 as dependency:
openbsd70$ doas pkg_add -a cmake
quirks-4.89 signed on 2021-12-20T17:49:43Z
cmake-3.20.3p0v0:libuv-1.40.0: ok
cmake-3.20.3p0v0: ok

Obrigado.

Em ter., 21 de dez. de 2021 às 11:24, Edd Barrett
 escreveu:
>
> On Tue, Dec 21, 2021 at 10:48:48AM -0400, Adriano Barbosa wrote:
> > I'm running -current on the latest snapshot and update ports tree.
> > Should I wait until another thing to upgrade?
>
> Did you install the updated libuv by hand? Looks like you are installing a
> package from a mirror that links the old libuv, but you have the new one.
>
> If that's the case, you can either wait for new packages, downgrade libuv by
> hand, or build cmake from the ports tree against the new libuv.
>
> --
> Best Regards
> Edd Barrett
>
> https://www.theunixzoo.co.uk



-- 
Adriano Barbosa



Re: UPDATE: libuv-1.42.0

2021-12-21 Thread Edd Barrett
On Tue, Dec 21, 2021 at 10:48:48AM -0400, Adriano Barbosa wrote:
> I'm running -current on the latest snapshot and update ports tree.
> Should I wait until another thing to upgrade?

Did you install the updated libuv by hand? Looks like you are installing a
package from a mirror that links the old libuv, but you have the new one.

If that's the case, you can either wait for new packages, downgrade libuv by
hand, or build cmake from the ports tree against the new libuv.

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk



Re: UPDATE: libuv-1.42.0

2021-12-21 Thread Adriano Barbosa
Hi!
I'm getting the following error:

openbsd70$ doas pkg_add -a cmake
quirks-4.89 signed on 2021-12-20T17:49:43Z
Can't install cmake-3.20.3p0v0 because of libraries
|library uv.3.0 not found
| /usr/local/lib/libuv.so.4.0 (libuv-1.42.0): bad major
Direct dependencies for cmake-3.20.3p0v0 resolve to libarchive-3.5.2
libuv-1.42.0 curl-7.80.0 rhash-1.4.2 jsoncpp-1.9.4
Full dependency tree is lz4-1.9.3p0 nghttp2-1.46.0 xz-5.2.5p0
zstd-1.5.0 libarchive-3.5.2 curl-7.80.0 bzip2-1.0.8p0 jsoncpp-1.9.4
rhash-1.4.2 libb2-0.98.1v0 libiconv-1.16p0 libuv-1.42.0
Couldn't install cmake-3.20.3p0v0

I'm running -current on the latest snapshot and update ports tree.
Should I wait until another thing to upgrade?

Obrigado!

Em seg., 20 de dez. de 2021 às 17:08, Edd Barrett
 escreveu:
>
> On Fri, Dec 17, 2021 at 12:14:06PM +, Klemens Nanni wrote:
> >
> > OK kn
>
> Any other comments or further OKs for this? I'd like to commit it soon so that
> we can update neovim.
>
> Cheers.
>
> --
> Best Regards
> Edd Barrett
>
> https://www.theunixzoo.co.uk
>


-- 
Adriano



Re: UPDATE: libuv-1.42.0

2021-12-21 Thread Paco Esteban
On Mon, 20 Dec 2021, Edd Barrett wrote:

> On Fri, Dec 17, 2021 at 12:14:06PM +, Klemens Nanni wrote:
> > 
> > OK kn
> 
> Any other comments or further OKs for this? I'd like to commit it soon so that
> we can update neovim.

I've been running with this diff since before you posted it to the list,
as you know :-)

That's ok paco@ which I totally forgot to send, sorry.

-- 
Paco Esteban.
0x5818130B8A6DBC03



Re: UPDATE: libuv-1.42.0

2021-12-20 Thread Edd Barrett
On Fri, Dec 17, 2021 at 12:14:06PM +, Klemens Nanni wrote:
> 
> OK kn

Any other comments or further OKs for this? I'd like to commit it soon so that
we can update neovim.

Cheers.

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk



Re: UPDATE: libuv-1.42.0

2021-12-17 Thread Klemens Nanni
On Wed, Dec 15, 2021 at 10:52:53AM +, Edd Barrett wrote:
> Hi,
> 
> Here's an update to libuv, needed for neovim-0.6.0 (requires new functions
> recently introduced in libuv).
> 
> There are three more test failures than before:
> 
> ```
> --- failing-beforeWed Dec 15 09:18:34 2021
> +++ failing-after Wed Dec 15 09:18:46 2021
> @@ -1,4 +1,7 @@
>  fs_lutime
>  get_currentexe
> +tcp_close_while_connecting
> +tcp_connect_timeout
>  udp_connect
>  udp_multicast_join
> +udp_send_hang_loop
> ```
> 
> (Before there were 4 failures, now there are 7).
> 
> I'll report all of the failures upstream shortly, but hopefully they are not
> blockers to the update. The majority of the suite passes.
> 
> I've done a major bump, since diffing the T symbols in old and new shared
> object suggests that public symbols have been removed. The affected symbols 
> are
> not exported in headers, but you never know what code in the wild might be
> doing.

Agreed.

> I've done a build test of all ports which build depend on libuv on amd64 
> (using
> dpb):
> 
> ```
> sqlite> select fullpkgpath from ports where lib_depends like '%%libuv%%';
> devel/cmake
> x11/mruby-zest
> devel/radare2/main
> devel/py-uv,python3
> editors/neovim
> lang/hashlink
> lang/moarvm
> www/h2o
> net/isc-bind
> net/isc-bind,geoip
> net/usockets
> www/h2o,mruby
> ```
> 
> Nothing failed to build.
> 
> I'm definitely looking for OKs for this, as I don't want to be responsible for
> breaking cmake!

I have only built neovim after the update diff.

OK kn

> Any comments or OKs?

You can bump autoconf to 2.71 and pass SPHINXOPTS=--no-color in
MAKE_FLAGS to disable coloured output when building manuals.

Feel free to commit those with it, otherwise I'll do it after the update.
All independent of the update, your choice.

SEPARATE_BULD=yes also works, although manuals are still created in
WRKSRC not WRKBUILD -- that needs fixing, but I'd ignore it for now.

> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/libuv/Makefile,v
> retrieving revision 1.16
> diff -u -p -r1.16 Makefile
> --- Makefile  25 Feb 2021 16:31:15 -  1.16
> +++ Makefile  14 Dec 2021 09:55:43 -
> @@ -2,12 +2,12 @@
>  
>  COMMENT =multi-platform library for asynchronous I/O
>  
> -VER =1.40.0
> +VER =1.42.0
>  DISTNAME =   libuv-v${VER}
>  PKGNAME =libuv-${VER}
>  CATEGORIES = devel
>  
> -SHARED_LIBS =uv 3.0  # 1.0
> +SHARED_LIBS =uv 4.0  # 1.0
>  
>  HOMEPAGE =   https://libuv.org/
>  
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/libuv/distinfo,v
> retrieving revision 1.5
> diff -u -p -r1.5 distinfo
> --- distinfo  14 Jan 2021 22:42:10 -  1.5
> +++ distinfo  14 Dec 2021 09:52:17 -
> @@ -1,2 +1,2 @@
> -SHA256 (libuv-v1.40.0.tar.gz) = YakNuVusAK3sHMXdx2frvKq8cCQr0RNKemsfsdSYoZQ=
> -SIZE (libuv-v1.40.0.tar.gz) = 1264008
> +SHA256 (libuv-v1.42.0.tar.gz) = QxKWJRVaiu15br6QuNTJkKc5hexxfeKy1dOiPP5N63I=
> +SIZE (libuv-v1.42.0.tar.gz) = 1284534
> 
> -- 
> Best Regards
> Edd Barrett
> 
> https://www.theunixzoo.co.uk
> 



Re: UPDATE: libuv-1.42.0

2021-12-15 Thread Evan Fiddes

On 15.12.2021 10:52, Edd Barrett wrote:

Hi,

Here's an update to libuv, needed for neovim-0.6.0 (requires new functions
recently introduced in libuv).

There are three more test failures than before:

```
--- failing-before  Wed Dec 15 09:18:34 2021
+++ failing-after   Wed Dec 15 09:18:46 2021
@@ -1,4 +1,7 @@
fs_lutime
get_currentexe
+tcp_close_while_connecting
+tcp_connect_timeout
udp_connect
udp_multicast_join
+udp_send_hang_loop
```

(Before there were 4 failures, now there are 7).

I'll report all of the failures upstream shortly, but hopefully they are not
blockers to the update. The majority of the suite passes.

I've done a major bump, since diffing the T symbols in old and new shared
object suggests that public symbols have been removed. The affected symbols are
not exported in headers, but you never know what code in the wild might be
doing.

I've done a build test of all ports which build depend on libuv on amd64 (using
dpb):

```
sqlite> select fullpkgpath from ports where lib_depends like '%%libuv%%';
devel/cmake
x11/mruby-zest
devel/radare2/main
devel/py-uv,python3
editors/neovim
lang/hashlink
lang/moarvm
www/h2o
net/isc-bind
net/isc-bind,geoip
net/usockets
www/h2o,mruby
```

Nothing failed to build.

I'm definitely looking for OKs for this, as I don't want to be responsible for
breaking cmake!

Any comments or OKs?

--
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk


Edd,

Thanks for this! I heard there were hackers at work... delivered so
quick! Now neovim is building with diff from paco@

Diff applied, make, make install. amd64. OK here.

I've built devel/cmake, devel/radare2, and editors/neovim as I work with
all three of them often enough. I will put them through paces. Not sure
I have bandwidth to look into what specifics may apply to the bump.

Thanks!

--
Evan