Re: remove devel/ocaml-configurator

2020-04-23 Thread Christopher Zimmermann

On Tue, Apr 21, 2020 at 10:02:29AM +0100, Anil Madhavapeddy wrote:

Looks good to me. We've pulled this out into its own library now 
(https://github.com/ocaml-dune/dune-configurator 
) since its compatibility 
requirements are stricter than dune. But that new repo is quite different from the 
port below and would effectively be a new one (no dependency on Base, etc).

Anil


I see only "This repository is empty" on 
https://github.com/ocaml-dune/dune-configurator


In case this will get populated I'd rather wait and change the existing 
port.


Christopher


--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2  0DEF 87E2 92A7 13E5 DEE1



Re: Remove devel/py-iniparse ?

2020-04-23 Thread Gleydson Soares
On Thu, Apr 23, 2020 at 11:14:44PM -0400, Kurt Mosiejczuk wrote:
> This was originally imported because tortoisehg needed it. Well,
> tortoisehg is gone. Let it go as well? It hasn't been updated in
> 8 years and has no consumers.

kill it with fire!



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Kurt Mosiejczuk
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/04/23 22:13:02

Modified files:
graphics/colord-gtk: Makefile 

Log message:
Fix build on sparc64 and other ld.bfd arches

ok jca@



Remove devel/py-iniparse ?

2020-04-23 Thread Kurt Mosiejczuk
This was originally imported because tortoisehg needed it. Well,
tortoisehg is gone. Let it go as well? It hasn't been updated in
8 years and has no consumers.

--Kurt



[update] net/wiresep-0.11.2

2020-04-23 Thread Tim Kuijsten
New upstream release that includes patches by Klemens Nanni that
fix an endless loop on platforms where char is unsigned, e.g. macppc.
Index: Makefile
===
RCS file: /cvs/ports/net/wiresep/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile	20 Apr 2020 20:45:12 -	1.6
+++ Makefile	23 Apr 2020 22:14:53 -
@@ -2,8 +2,7 @@
 
 COMMENT =		privilege separated implementation of WireGuard
 
-DISTNAME = 		wiresep-0.11.1
-REVISION =		0
+DISTNAME = 		wiresep-0.11.2
 MASTER_SITES =		https://netsend.nl/wiresep/archive/
 
 CATEGORIES =		net security
Index: distinfo
===
RCS file: /cvs/ports/net/wiresep/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo	7 Apr 2020 17:45:32 -	1.4
+++ distinfo	23 Apr 2020 22:14:53 -
@@ -1,2 +1,2 @@
-SHA256 (wiresep-0.11.1.tar.gz) = CpaX21JT7q5RAteZCy2VDJNtZ/35NzZpBHFqxNCIxEI=
-SIZE (wiresep-0.11.1.tar.gz) = 396242
+SHA256 (wiresep-0.11.2.tar.gz) = 7ajqpCYcrVeH1dZruknNol6WBOGxgSObRqfq1/mSgic=
+SIZE (wiresep-0.11.2.tar.gz) = 396400
Index: patches/patch-master_c
===
RCS file: patches/patch-master_c
diff -N patches/patch-master_c
--- patches/patch-master_c	20 Apr 2020 20:45:12 -	1.1
+++ /dev/null	1 Jan 1970 00:00:00 -
@@ -1,18 +0,0 @@
-$OpenBSD: patch-master_c,v 1.1 2020/04/20 20:45:12 kn Exp $
-
-getopt(3) returns int not char;  fix endless loop on platforms where char
-is unsigned, e.g. macppc.
-
-Index: master.c
 master.c.orig
-+++ master.c
-@@ -133,7 +133,8 @@ main(int argc, char **argv)
- 	int configtest, foreground, stdopen, masterport, stat;
- 	pid_t pid;
- 	const char *errstr;
--	char c, *eargs[4], *eenv[1], *logfacilitystr, *oldprogname;
-+	char *eargs[4], *eenv[1], *logfacilitystr, *oldprogname;
-+	int c;
- 
- 	/* should endup in a configure script */
- 	if (sizeof(struct msgwginit) != 148)
Index: patches/patch-wiresep-keygen_c
===
RCS file: patches/patch-wiresep-keygen_c
diff -N patches/patch-wiresep-keygen_c
--- patches/patch-wiresep-keygen_c	20 Apr 2020 20:45:12 -	1.1
+++ /dev/null	1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-$OpenBSD: patch-wiresep-keygen_c,v 1.1 2020/04/20 20:45:12 kn Exp $
-
-getopt(3) returns int not char;  fix endless loop on platforms where char
-is unsigned, e.g. macppc.
-
-Index: wiresep-keygen.c
 wiresep-keygen.c.orig
-+++ wiresep-keygen.c
-@@ -121,7 +121,7 @@ main(int argc, char **argv)
- 	uint8_t privkey[X25519_KEY_LENGTH], pubkey[X25519_KEY_LENGTH];
- 	char b64privkey[46], b64pubkey[46];
- 	int i, fd, wd, ret;
--	char c;
-+	int c;
- 	char *keypath, *presharedkey, *filename;
- 
- 	presharedkey = NULL;


CVS: cvs.openbsd.org: ports

2020-04-23 Thread Elias M . Mariani
CVSROOT:/cvs
Module name:ports
Changes by: mari...@cvs.openbsd.org 2020/04/23 15:39:05

Modified files:
net/qbittorrent: Makefile.inc 
net/qbittorrent/qbittorrent: distinfo 
net/qbittorrent/qbittorrent-nox: distinfo 

Log message:
net/qbittorrent 4.2.3 to 4.2.4

Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.2.4/Changelog#L1

Mostly small bugfixes, nothing of impact.

Tested on amd64 (mariani@ and solene@).

ok solene@



Re: M. UPDATE: net/qbittorrent 4.2.3 to 4.2.4

2020-04-23 Thread Solene Rapenne
Le Thu, 23 Apr 2020 14:14:23 -0600 (MDT),
Elias M. Mariani  a écrit :

> Changelog:
> https://github.com/qbittorrent/qBittorrent/blob/release-4.2.4/Changelog#L1
> 
> Mostly small bugfixes, nothing of impact.
> I don't see why holding for 6.7.
> 
> Tested on amd64.
> 
> OKs?
> 
> Cheers.
> Elias mariani@
> 
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
> retrieving revision 1.10
> diff -u -p -r1.10 Makefile.inc
> --- Makefile.inc  4 Apr 2020 18:19:38 -   1.10
> +++ Makefile.inc  23 Apr 2020 20:09:51 -
> @@ -3,7 +3,7 @@
>  # qmake picks up gcrypt.h even though it's unused
>  DPB_PROPERTIES = nojunk
>  
> -VER =4.2.3
> +VER =4.2.4
>  DISTNAME =   qbittorrent-${VER}
>  
>  DIST_SUBDIR =qbittorrent
> Index: qbittorrent/distinfo
> ===
> RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
> retrieving revision 1.7
> diff -u -p -r1.7 distinfo
> --- qbittorrent/distinfo  4 Apr 2020 18:19:38 -   1.7
> +++ qbittorrent/distinfo  23 Apr 2020 20:09:51 -
> @@ -1,2 +1,2 @@
> -SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
> 0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A= -SIZE
> (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854 +SHA256
> (qbittorrent/qbittorrent-4.2.4.tar.gz) =
> LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs= +SIZE
> (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821 Index:
> qbittorrent-nox/distinfo
> ===
> RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
> retrieving revision 1.7 diff -u -p -r1.7 distinfo ---
> qbittorrent-nox/distinfo  4 Apr 2020 18:19:38 -   1.7
> +++ qbittorrent-nox/distinfo  23 Apr 2020 20:09:51 - @@
> -1,2 +1,2 @@ -SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) =
> 0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A= -SIZE
> (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854 +SHA256
> (qbittorrent/qbittorrent-4.2.4.tar.gz) =
> LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs= +SIZE
> (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821
> 

ok solene@
tested on amd64



M. UPDATE: net/qbittorrent 4.2.3 to 4.2.4

2020-04-23 Thread Elias M . Mariani
Changelog:
https://github.com/qbittorrent/qBittorrent/blob/release-4.2.4/Changelog#L1

Mostly small bugfixes, nothing of impact.
I don't see why holding for 6.7.

Tested on amd64.

OKs?

Cheers.
Elias mariani@

Index: Makefile.inc
===
RCS file: /cvs/ports/net/qbittorrent/Makefile.inc,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile.inc
--- Makefile.inc4 Apr 2020 18:19:38 -   1.10
+++ Makefile.inc23 Apr 2020 20:09:51 -
@@ -3,7 +3,7 @@
 # qmake picks up gcrypt.h even though it's unused
 DPB_PROPERTIES =   nojunk
 
-VER =  4.2.3
+VER =  4.2.4
 DISTNAME = qbittorrent-${VER}
 
 DIST_SUBDIR =  qbittorrent
Index: qbittorrent/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- qbittorrent/distinfo4 Apr 2020 18:19:38 -   1.7
+++ qbittorrent/distinfo23 Apr 2020 20:09:51 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) = 
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
-SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
+SHA256 (qbittorrent/qbittorrent-4.2.4.tar.gz) = 
LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs=
+SIZE (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821
Index: qbittorrent-nox/distinfo
===
RCS file: /cvs/ports/net/qbittorrent/qbittorrent-nox/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- qbittorrent-nox/distinfo4 Apr 2020 18:19:38 -   1.7
+++ qbittorrent-nox/distinfo23 Apr 2020 20:09:51 -
@@ -1,2 +1,2 @@
-SHA256 (qbittorrent/qbittorrent-4.2.3.tar.gz) = 
0cbXNUNKnbPXusHopFK8ghVAhp9yIcBjVKjRkUqHp5A=
-SIZE (qbittorrent/qbittorrent-4.2.3.tar.gz) = 7954854
+SHA256 (qbittorrent/qbittorrent-4.2.4.tar.gz) = 
LUXSIJETlYp/A/HCj9pwnqp+XF2rXjLmpFtHi1aXtNs=
+SIZE (qbittorrent/qbittorrent-4.2.4.tar.gz) = 7985821



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Klemens Nanni
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/04/23 13:00:17

Modified files:
devel/ruby-shims: Makefile 
devel/ruby-shims/pkg: DESCR PLIST 

Log message:
Provide version example, move shim script out of PATH

Without documentation and/or prior Ruby experience, it is not obvious
what /etc/ruby-version should contain.

The shim script itself should not be called directly, move it to
libexec/rubyshim to make this clearer.



new: CrossFire crossword editor

2020-04-23 Thread Ian Darwin
The guys who make many of the New York Times crosswords use
and recommend this crossword-maker.

Since there is an unrelated crossfire-client in games/,
would it be better to keep the camelcased name CrossFire
(at least for the package and directory names, not the startup script)
instead of lowercasing these?

It works fine on jdk-11, should we make that the dep to encourage
ppl to move along?

OKs or cluebats welcome, thanks.


textproc.crossfire.tgz
Description: application/tar-gz


Re: python2, remove MESSAGE?

2020-04-23 Thread Elias M. Mariani
OK mariani@

On Thu, Apr 23, 2020 at 1:23 PM Stuart Henderson  wrote:
>
> I don't think it makes sense to suggest making 2.7 the default system Python
> any more, OK for this? I have left UNMESSAGE* because users who have done this
> previously might want a reminder to remove them later.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/python/2.7/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile23 Apr 2020 07:56:01 -  1.66
> +++ Makefile23 Apr 2020 16:19:49 -
> @@ -10,6 +10,9 @@ PATCHLEVEL =  .18
>  SHARED_LIBS =  python2.7 0.0
>  VERSION_SPEC = >=2.7,<2.8
>
> +REVISION-main =0
> +REVISION-idle =0
> +
>  CONFIGURE_ARGS += --with-ensurepip=no
>  CONFIGURE_ENV += ac_cv_opt_olimit_ok=no
>
> Index: pkg/MESSAGE-idle
> ===
> RCS file: pkg/MESSAGE-idle
> diff -N pkg/MESSAGE-idle
> --- pkg/MESSAGE-idle24 Apr 2011 09:31:46 -  1.1.1.1
> +++ /dev/null   1 Jan 1970 00:00:00 -
> @@ -1,3 +0,0 @@
> -If you want to use this package as your default system idle, as root
> -create symbolic links like so (overwriting any previous default):
> - ln -sf ${PREFIX}/bin/idle2.7 ${PREFIX}/bin/idle
> Index: pkg/MESSAGE-main
> ===
> RCS file: pkg/MESSAGE-main
> diff -N pkg/MESSAGE-main
> --- pkg/MESSAGE-main3 May 2011 17:18:28 -   1.2
> +++ /dev/null   1 Jan 1970 00:00:00 -
> @@ -1,6 +0,0 @@
> -If you want to use this package as your default system python, as root
> -create symbolic links like so (overwriting any previous default):
> - ln -sf ${PREFIX}/bin/python2.7 ${PREFIX}/bin/python
> - ln -sf ${PREFIX}/bin/python2.7-2to3 ${PREFIX}/bin/2to3
> - ln -sf ${PREFIX}/bin/python2.7-config ${PREFIX}/bin/python-config
> - ln -sf ${PREFIX}/bin/pydoc2.7  ${PREFIX}/bin/pydoc
>



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Brian Callahan
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2020/04/23 11:25:31

Modified files:
multimedia/streamlink: Makefile distinfo 
multimedia/streamlink/pkg: PLIST 

Log message:
Update to streamlink-1.4.0
Changelog: https://github.com/streamlink/streamlink/releases/tag/1.4.0



Re: python2, remove MESSAGE?

2020-04-23 Thread Antoine Jacoutot
On Thu, Apr 23, 2020 at 05:21:26PM +0100, Stuart Henderson wrote:
> I don't think it makes sense to suggest making 2.7 the default system Python
> any more, OK for this? I have left UNMESSAGE* because users who have done this
> previously might want a reminder to remove them later.

OK


> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/python/2.7/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile  23 Apr 2020 07:56:01 -  1.66
> +++ Makefile  23 Apr 2020 16:19:49 -
> @@ -10,6 +10,9 @@ PATCHLEVEL =.18
>  SHARED_LIBS =python2.7 0.0
>  VERSION_SPEC =   >=2.7,<2.8
>  
> +REVISION-main =  0
> +REVISION-idle =  0
> +
>  CONFIGURE_ARGS += --with-ensurepip=no
>  CONFIGURE_ENV += ac_cv_opt_olimit_ok=no
>  
> Index: pkg/MESSAGE-idle
> ===
> RCS file: pkg/MESSAGE-idle
> diff -N pkg/MESSAGE-idle
> --- pkg/MESSAGE-idle  24 Apr 2011 09:31:46 -  1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,3 +0,0 @@
> -If you want to use this package as your default system idle, as root
> -create symbolic links like so (overwriting any previous default):
> - ln -sf ${PREFIX}/bin/idle2.7 ${PREFIX}/bin/idle
> Index: pkg/MESSAGE-main
> ===
> RCS file: pkg/MESSAGE-main
> diff -N pkg/MESSAGE-main
> --- pkg/MESSAGE-main  3 May 2011 17:18:28 -   1.2
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,6 +0,0 @@
> -If you want to use this package as your default system python, as root
> -create symbolic links like so (overwriting any previous default):
> - ln -sf ${PREFIX}/bin/python2.7 ${PREFIX}/bin/python
> - ln -sf ${PREFIX}/bin/python2.7-2to3 ${PREFIX}/bin/2to3
> - ln -sf ${PREFIX}/bin/python2.7-config ${PREFIX}/bin/python-config
> - ln -sf ${PREFIX}/bin/pydoc2.7  ${PREFIX}/bin/pydoc
> 

-- 
Antoine



Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Giacomo
You are welcome!

Giacomo

El jue., 23 abr. 2020 a las 17:00, Stefan Sperling ()
escribió:

> On Thu, Apr 23, 2020 at 02:02:46PM +0200, Giacomo wrote:
> > Hello again Stefan.
> > Some good news: I set a fixed channel on the 2.4GHz Access Point (to 6)
> and
> > now I get a stable connection, although not constantly fast. Let's say
> > average around 10mbps.
> > I think those messages are related to channel settings. Every time I
> select
> > a different channel, I get one fatal firmware error on dmesg. But then,
> no
> > more.
>
> Thanks!
>
> So it seems to be related to the AP moving channels. This is indeed
> something I have not yet specifically tested. I will try to reproduce it.
>
> Cheers,
> Stefan
>


-- 
Giacomo S.
http://www.giacomos.it

Sincrotrone Trieste S.C.p.A. di interesse nazionale
Strada Statale 14 - km 163,5 in AREA Science Park
34149 Basovizza, Trieste ITALY
-
040 3758073
328 3237959


python2, remove MESSAGE?

2020-04-23 Thread Stuart Henderson
I don't think it makes sense to suggest making 2.7 the default system Python
any more, OK for this? I have left UNMESSAGE* because users who have done this
previously might want a reminder to remove them later.


Index: Makefile
===
RCS file: /cvs/ports/lang/python/2.7/Makefile,v
retrieving revision 1.66
diff -u -p -r1.66 Makefile
--- Makefile23 Apr 2020 07:56:01 -  1.66
+++ Makefile23 Apr 2020 16:19:49 -
@@ -10,6 +10,9 @@ PATCHLEVEL =  .18
 SHARED_LIBS =  python2.7 0.0
 VERSION_SPEC = >=2.7,<2.8
 
+REVISION-main =0
+REVISION-idle =0
+
 CONFIGURE_ARGS += --with-ensurepip=no
 CONFIGURE_ENV += ac_cv_opt_olimit_ok=no
 
Index: pkg/MESSAGE-idle
===
RCS file: pkg/MESSAGE-idle
diff -N pkg/MESSAGE-idle
--- pkg/MESSAGE-idle24 Apr 2011 09:31:46 -  1.1.1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,3 +0,0 @@
-If you want to use this package as your default system idle, as root
-create symbolic links like so (overwriting any previous default):
- ln -sf ${PREFIX}/bin/idle2.7 ${PREFIX}/bin/idle
Index: pkg/MESSAGE-main
===
RCS file: pkg/MESSAGE-main
diff -N pkg/MESSAGE-main
--- pkg/MESSAGE-main3 May 2011 17:18:28 -   1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,6 +0,0 @@
-If you want to use this package as your default system python, as root
-create symbolic links like so (overwriting any previous default):
- ln -sf ${PREFIX}/bin/python2.7 ${PREFIX}/bin/python
- ln -sf ${PREFIX}/bin/python2.7-2to3 ${PREFIX}/bin/2to3
- ln -sf ${PREFIX}/bin/python2.7-config ${PREFIX}/bin/python-config
- ln -sf ${PREFIX}/bin/pydoc2.7  ${PREFIX}/bin/pydoc



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 10:01:15

Modified files:
net/swirc  : Makefile 
Added files:
net/swirc/patches: patch-configure patch-src_events_cap_c 

Log message:
Forgot about these in previous.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/04/23 09:06:27

Modified files:
sysutils/flashrom: Makefile 
sysutils/flashrom/pkg: README 

Log message:
shift some commas around in pkg-readme



Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Stefan Sperling
On Thu, Apr 23, 2020 at 02:02:46PM +0200, Giacomo wrote:
> Hello again Stefan.
> Some good news: I set a fixed channel on the 2.4GHz Access Point (to 6) and
> now I get a stable connection, although not constantly fast. Let's say
> average around 10mbps.
> I think those messages are related to channel settings. Every time I select
> a different channel, I get one fatal firmware error on dmesg. But then, no
> more.

Thanks!

So it seems to be related to the AP moving channels. This is indeed
something I have not yet specifically tested. I will try to reproduce it.

Cheers,
Stefan



mips64 bulk build report

2020-04-23 Thread visa
bulk build on octeon.ports.openbsd.org
started on  Sat Apr 11 16:33:30 UTC 2020
finished at Wed Apr 22 16:42:45 UTC 2020
lasted 12D00h09m
done with kern.version=OpenBSD 6.7-beta (GENERIC.MP) #23: Sat Apr 11 15:56:56 
UTC 2020

built packages:9503
Apr 11:1621
Apr 12:1146
Apr 13:611
Apr 14:698
Apr 15:468
Apr 16:268
Apr 18:451
Apr 19:566
Apr 20:935
Apr 21:2738


build failures: 62
http://build-failures.rhaalovely.net/mips64/2020-04-11/audio/mscore.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/cad/netgen.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/chinese/libchewing.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/chinese/libpinyin.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/databases/postgresql-pllua.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/devel/cgdb.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/devel/coccinelle.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/devel/libpeas.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/devel/py-unicorn,python3.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/devel/rebar.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/devel/sdcc.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/editors/vim,no_x11,perl,python,ruby.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/emulators/openmsx.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/emulators/retroarch.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/games/astromenace.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/games/eduke32.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/games/hyperrogue.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/games/postal.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/games/stone-soup.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/games/valyriatear.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/geo/gpstk.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/graphics/birdfont.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/graphics/colord-gtk.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/graphics/enblend-enfuse.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/graphics/gimp/stable.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/graphics/openimageio.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/inputmethods/scim-fcitx.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/STk.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/gforth.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/gpc.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/guile2.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/janet.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/parrot.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/pfe.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/lang/squeak/vm.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/mail/dspam,-main.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/mail/kopano/core.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/math/gbc.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/math/mlpack,-main.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/math/ntl.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/misc/dtcltiny.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/multimedia/assimp.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/multimedia/mkvtoolnix,no_x11.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/multimedia/synfigstudio.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/net/utox.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/net/wireshark,-main.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/plan9/drawterm.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/security/botan2.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/shells/ksh93.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/sysutils/u-boot,aarch64.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/telephony/iaxclient.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/textproc/apertium-dicts/crh.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/textproc/apertium-dicts/tur.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/www/mozplugger.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/x11/gnome/libgweather.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/x11/gtk+4,-cloudprint.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/x11/gtk-vnc.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/x11/gtksourceview4.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/x11/kde4/ruby-qt.log
http://build-failures.rhaalovely.net/mips64/2020-04-11/x11/libhandy.log

CVS: cvs.openbsd.org: ports

2020-04-23 Thread Kurt Mosiejczuk
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/04/23 08:39:39

Modified files:
x11/spice-gtk  : Makefile 

Log message:
Fix the build on sparc64 (and presumably other base-gcc arches)
by specifying "-std=gnu99" and patching to remove "-Werror"

Input from aja

ok jca@

(Last commit was mistakenly done from within "patches", thus missing
Makefile)



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Tracey Emery
CVSROOT:/cvs
Module name:ports
Changes by: tra...@cvs.openbsd.org  2020/04/23 08:37:16

Modified files:
devel  : Makefile 

Log message:
Add new ports to Makefile



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Tracey Emery
CVSROOT:/cvs
Module name:ports
Changes by: tra...@cvs.openbsd.org  2020/04/23 08:31:07

Log message:
Import devel/makeesparduino: makefile for ESP8266 and ESP32 Arduino projects

The main intent for this project is to provide a minimalistic yet powerful 
and
easy configurable makefile for projects using the ESP/Arduino framework
available at: https://github.com/esp8266/Arduino and
https://github.com/espressif/arduino-esp32.

Testing paco@

Input jca@ sthen@

Ok paco@ jca@ sthen@

Status:

Vendor Tag: tracey
Release Tags:   tracey_20200423

N ports/devel/makeesparduino/Makefile
N ports/devel/makeesparduino/distinfo
N ports/devel/makeesparduino/patches/patch-makeEspArduino_mk
N ports/devel/makeesparduino/pkg/DESCR
N ports/devel/makeesparduino/pkg/PLIST
N ports/devel/makeesparduino/pkg/MESSAGE

No conflicts created by this import



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Tracey Emery
CVSROOT:/cvs
Module name:ports
Changes by: tra...@cvs.openbsd.org  2020/04/23 08:30:31

Log message:
Import devel/arduino-esp32: esp32 arduino core toolset

Framework to program Espressif ESP32 chipsets via the Arduino environment.

Testing paco@

Input jca@

Ok paco@ jca@ sthen@

Status:

Vendor Tag: tracey
Release Tags:   tracey_20200423

N ports/devel/arduino-esp32/Makefile
N ports/devel/arduino-esp32/distinfo
N ports/devel/arduino-esp32/patches/patch-platform_txt
N ports/devel/arduino-esp32/pkg/DESCR
N ports/devel/arduino-esp32/pkg/PLIST

No conflicts created by this import



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Tracey Emery
CVSROOT:/cvs
Module name:ports
Changes by: tra...@cvs.openbsd.org  2020/04/23 08:28:54

Log message:
Import devel/arduino-esp8266: esp8266 arduino core toolset

Framework to program Espressif ESP8266 chipsets via the Arduino environment.

Testing paco@

Input jca@

Ok paco@ jca@ sthen@

Status:

Vendor Tag: tracey
Release Tags:   tracey_20200423

N ports/devel/arduino-esp8266/Makefile
N ports/devel/arduino-esp8266/distinfo
N 
ports/devel/arduino-esp8266/patches/patch-libraries_LittleFS_lib_littlefs_scripts_corrupt_py
N 
ports/devel/arduino-esp8266/patches/patch-libraries_LittleFS_lib_littlefs_scripts_debug_py
N 
ports/devel/arduino-esp8266/patches/patch-libraries_LittleFS_lib_littlefs_scripts_prefix_py
N 
ports/devel/arduino-esp8266/patches/patch-libraries_LittleFS_lib_littlefs_scripts_results_py
N ports/devel/arduino-esp8266/patches/patch-platform_txt
N ports/devel/arduino-esp8266/pkg/DESCR
N ports/devel/arduino-esp8266/pkg/PLIST

No conflicts created by this import



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Tracey Emery
CVSROOT:/cvs
Module name:ports
Changes by: tra...@cvs.openbsd.org  2020/04/23 08:26:06

Log message:
Import devel/mkspiffs: tool to build and unpack SPIFFS images

Wear-leveled SPI flash file system for embedded devices.

This tool is specifically patched to build and unpack SPIFFS images for
esp32 and esp8266 wifi devices, using SPIFFS as the submodule.

Testing paco@

Input from jca@ and sthen@

Ok benoit@ paco@ kmos@ sthen@ jca@

Status:

Vendor Tag: tracey
Release Tags:   tracey_20200423

N ports/devel/mkspiffs/Makefile
N ports/devel/mkspiffs/distinfo
N ports/devel/mkspiffs/patches/patch-Makefile
N ports/devel/mkspiffs/pkg/DESCR
N ports/devel/mkspiffs/pkg/PLIST

No conflicts created by this import



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Kurt Mosiejczuk
CVSROOT:/cvs
Module name:ports
Changes by: k...@cvs.openbsd.org2020/04/23 08:21:54

Added files:
x11/spice-gtk/patches: 
   patch-subprojects_spice-common_meson_build 

Log message:
Fix the build on sparc64 (and presumably other base-gcc arches)
by specifying "-std=gnu99" and patching to remove "-Werror"

Input from aja

ok jca@



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/04/23 07:49:31

Modified files:
sysutils/reposync: Makefile distinfo 
sysutils/reposync/pkg: PLIST 
Added files:
sysutils/reposync/pkg: README 

Log message:
update to reposync-20200423, including "should work by default for
official mirrors" handling for ssh hostkeys fixing a problem mentioned
by several including most recently solene@. add pkg-readme.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/04/23 07:43:05

Modified files:
textproc/pecl-yaml: Makefile distinfo 
textproc/pecl-yaml/pkg: PLIST 

Log message:
update to pecl-yaml-2.1.0



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/04/23 07:29:12

Modified files:
mail/pecl-mailparse: Makefile distinfo 
mail/pecl-mailparse/pkg: DESCR 

Log message:
update to pecl-mailparse-3.1.0



Re: Slight grafana file permissions improvement

2020-04-23 Thread Eric Elena
On Wed, 22 Apr 2020 14:34:51 +0200 Landry Breuil wrote:
> On Wed, Apr 22, 2020 at 01:34:21PM +0200, Martin Reindl wrote:
> > On Wed, Apr 15, 2020 at 05:44:24PM +0200, Rafael Sadowski wrote:
> > > 
> > > This version works for me. OK rsadowski@
> > 
> > Apologies for the delayed followup. Per Stuart's recommendation the update 
> > to
> > 6.7.2 was commited independently without any changes to permissions.

I thought this change was too intrusive and sent too late to be included in
6.7 :)

> > Attached diff is the essence of Eric's diff with regard to file permissions.
> > Rafael, is your OK still valid?
> 
> im not sure the @owner root dance is necessary (and it doesnt feel
> consistent in the diff ?), but for completeness it might be good. Reads
> good to me.

The documentation doesn't say much about @mode, @owner and @group (or I
looked at the wrong place). Looking at other ports, I applied the
following rule: explicit mode, owner and group for the directories;
explicit mode and group for the files and assuming owner is root.

> for completeness, before:
>6314 drwxr-xr-x3 root wheel 512 Apr 20 09:16 
> /etc/grafana/
>4898 -rw-r--r--1 root wheel2289 Apr 20 09:16 
> /etc/grafana/ldap.toml
>724   28 -rw-r--r--1 root wheel   13088 Jan  4  2018 
> /etc/grafana/config.ini
>  260224 drwxr-xr-x5 root wheel 512 Mar 16 14:32 
> /etc/grafana/provisioning
>  260234 drwxr-xr-x2 root wheel 512 Apr 20 09:16 
> /etc/grafana/provisioning/dashboards
>  260244 -rw-r--r--1 root wheel 185 Apr 20 09:16 
> /etc/grafana/provisioning/dashboards/sample.yaml
>  260254 drwxr-xr-x2 root wheel 512 Apr 20 09:16 
> /etc/grafana/provisioning/datasources
>  260264 -rw-r--r--1 root wheel1638 Apr 20 09:16 
> /etc/grafana/provisioning/datasources/sample.yaml
>  262624 drwxr-xr-x2 root wheel 512 Apr 20 09:16 
> /etc/grafana/provisioning/notifiers
>  262524 -rw-r--r--1 root wheel 555 Apr 20 09:16 
> /etc/grafana/provisioning/notifiers/sample.yaml
> 
> after:
> 
> [14:22] c64:/usr/ports/sysutils/grafana/ $make update
> --- -grafana-6.7.2 ---
> You should also run rm -rf /var/log/grafana/
> You should also run rm -rf /var/grafana/
> You should also check /etc/grafana/config.ini (which was modified)
> [14:32] c64:/usr/ports/sysutils/grafana/ $find /etc/grafana/ -ls
>6314 drwxr-xr-x3 root _grafana  512 Apr 22 14:27 
> /etc/grafana/
>4898 -rw-r-1 root _grafana 2289 Apr 22 14:27 
> /etc/grafana/ldap.toml
>724   28 -rw-r--r--1 root wheel   13088 Jan  4  2018 
> /etc/grafana/config.ini
>  260224 drwxr-xr-x5 root _grafana  512 Mar 16 14:32 
> /etc/grafana/provisioning
>  260234 drwxr-xr-x2 root _grafana  512 Apr 22 14:27 
> /etc/grafana/provisioning/dashboards
>  260244 -rw-r-1 root _grafana  185 Apr 22 14:27 
> /etc/grafana/provisioning/dashboards/sample.yaml
>  260254 drwxr-xr-x2 root _grafana  512 Apr 22 14:27 
> /etc/grafana/provisioning/datasources
>  260264 -rw-r-1 root _grafana 1638 Apr 22 14:27 
> /etc/grafana/provisioning/datasources/sample.yaml
>  262624 drwxr-xr-x2 root _grafana  512 Apr 22 14:27 
> /etc/grafana/provisioning/notifiers
>  262524 -rw-r-1 root _grafana  555 Apr 22 14:27 
> /etc/grafana/provisioning/notifiers/sample.yaml
> 
> so besides config.ini perms which werent fixed because i had a custom config
> (and you cant do much about it i think? have a special quick to update perms 
> for
> @sample files without overwriting their content), the others look fine.

I tested different things for this scenario but in the end I had to fix
the permissions manually. As far as I can tell the same thing happened
when permissions for the elastic stack were modified.

> anyway, ok for me.
> Landry
> 



Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Giacomo
Hello again Stefan.
Some good news: I set a fixed channel on the 2.4GHz Access Point (to 6) and
now I get a stable connection, although not constantly fast. Let's say
average around 10mbps.
I think those messages are related to channel settings. Every time I select
a different channel, I get one fatal firmware error on dmesg. But then, no
more.
Additionally, this brought to my mind that I had to do the same on the 5GHz
channel because on Linux I got continuous disconnections if the channel was
"Auto".

That's good, and I'm glad to share this piece of news.

Now I'll spend some time tweaking gnome desktop to see if it can get a
little bit close to what I'm used to on Linux, because it seems rather slow
in comparison.

If you are aware of some optimization guidelines, that would be great.

Kind regards and thanks again

G


El jue., 23 abr. 2020 a las 12:52, Giacomo ()
escribió:

> One more thing: what about trying tweaking the settings for the 2.4G on
> the Access point? Don't know, fixed channel or something...
> Are there any parameters in the driver that can be set?
>
> Regards
> G.
>
> El jue., 23 abr. 2020 a las 12:50, Giacomo ()
> escribió:
>
>> Hello again
>>
>>
>> El jue., 23 abr. 2020 a las 12:31, Stefan Sperling ()
>> escribió:
>>
>>> On Thu, Apr 23, 2020 at 12:13:09PM +0200, Giacomo wrote:
>>> > Hi Stefan. Thanks for Your prompt response!
>>> > Since I seem to understand firmware is taken from linux iwlwifi, my
>>> idea
>>> > was to understand which one(s) you picked up and how you built the
>>> > package iwx-firmware-20191022p0.
>>> > Maybe worth trying with some other .ucode in there.. don't know, just
>>> > guessing.
>>> > I am not an expert
>>>
>>> Just dropping in another firmware won't magically fix anything.
>>> Firmware and driver need to be in sync for things to work.
>>>
>>>
>> I understand
>>
>>
>>> I picked the lowest FW version (46) the device supports because
>>> this means the least amount of changes had to be made relative
>>> to iwm(4) code (the iwx driver code was derived from iwm).
>>>
>>> > What do you mean by specific environment?
>>> > It is a PCI-E card installed on my desktop. Yesterday I did a fresh
>>> > snapshot of 6.7 installation and configured the card with WPA2.
>>> > Even before configuring it and being able to connect to the network
>>> > (stuttering) dmesg frequently printed that message related to "SCAN".
>>>
>>> Sounds like you have 'ifconfig iwx0 debug' enabled?
>>>
>>
>> Not that I am aware of :-)
>> Never typed any debug on the command line, nor in /etc/hostname.iwx0
>> If in case, how to check it is enabled?
>>
>>
>>> I don't see why SCAN messages would appear otherwise.
>>>
>>
>> Actually, my mistake. SOME OF the dmesg messages ended with a reference
>> to SCAN, probably prior to connect to the wpa.
>> AS you can see from my initial message, in the attached dmesg there is no
>> reference to SCAN.
>>
>>
>>>
>>> Frequent printing to dmesg can interfere with regular operation.
>>> Please only enable 'debug' if really needed.
>>>
>>> > I tried to measure the speed as soon as I got a desktop working, and it
>>> > goes from some hundred to 800/900 Kbits per second.
>>> > Probably this very slow rate has to do with unlucky firmware and
>>> continuous
>>> > connection resets.
>>> > Gmail is not able to load, for example.
>>> >
>>> > What is the speed you get? Is it stable?
>>>
>>> It is working OK for me up with up to somewhere around 20 Mbps.
>>> Linux can of course drive the device to be a lot faster than that but
>>> we don't support full 11n, let alone 11ac, yet.
>>>
>>
>> Yes, I've read it in man page. 20Mbps would be good indeed, and expected
>> for 802.11g.
>> And yes, with linux I reach 60Mbps in 11n, or ac, don't know exactly..
>>
>> Let me know if I can help somehow
>>
>> Kind regards, Giacomo
>>
>>
>>
>> --
>> Giacomo S.
>> http://www.giacomos.it
>>
>> Sincrotrone Trieste S.C.p.A. di interesse nazionale
>> Strada Statale 14 - km 163,5 in AREA Science Park
>> 34149 Basovizza, Trieste ITALY
>> -
>> 040 3758073
>> 328 3237959
>>
>>
>
> --
> Giacomo S.
> http://www.giacomos.it
>
> Sincrotrone Trieste S.C.p.A. di interesse nazionale
> Strada Statale 14 - km 163,5 in AREA Science Park
> 34149 Basovizza, Trieste ITALY
> -
> 040 3758073
> 328 3237959
>
>

-- 
Giacomo S.
http://www.giacomos.it

Sincrotrone Trieste S.C.p.A. di interesse nazionale
Strada Statale 14 - km 163,5 in AREA Science Park
34149 Basovizza, Trieste ITALY
-
040 3758073
328 3237959


CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/04/23 05:13:38

Modified files:
www/squid  : Tag: OPENBSD_6_6 Makefile distinfo 
www/squid/patches: Tag: OPENBSD_6_6 patch-bootstrap_sh 
   patch-src_squid_8_in 

Log message:
update -stable to squid-4.11

SQUID-2019:12 - Due to incorrect buffer handling Squid is vulnerable to
cache poisoning, remote execution, and denial of service attacks when
processing ESI responses.

SQUID-2020:4 - Due to an integer overflow bug Squid is vulnerable to
credential replay and remote code execution attacks against HTTP Digest
Authentication tokens.



Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Giacomo
One more thing: what about trying tweaking the settings for the 2.4G on the
Access point? Don't know, fixed channel or something...
Are there any parameters in the driver that can be set?

Regards
G.

El jue., 23 abr. 2020 a las 12:50, Giacomo ()
escribió:

> Hello again
>
>
> El jue., 23 abr. 2020 a las 12:31, Stefan Sperling ()
> escribió:
>
>> On Thu, Apr 23, 2020 at 12:13:09PM +0200, Giacomo wrote:
>> > Hi Stefan. Thanks for Your prompt response!
>> > Since I seem to understand firmware is taken from linux iwlwifi, my idea
>> > was to understand which one(s) you picked up and how you built the
>> > package iwx-firmware-20191022p0.
>> > Maybe worth trying with some other .ucode in there.. don't know, just
>> > guessing.
>> > I am not an expert
>>
>> Just dropping in another firmware won't magically fix anything.
>> Firmware and driver need to be in sync for things to work.
>>
>>
> I understand
>
>
>> I picked the lowest FW version (46) the device supports because
>> this means the least amount of changes had to be made relative
>> to iwm(4) code (the iwx driver code was derived from iwm).
>>
>> > What do you mean by specific environment?
>> > It is a PCI-E card installed on my desktop. Yesterday I did a fresh
>> > snapshot of 6.7 installation and configured the card with WPA2.
>> > Even before configuring it and being able to connect to the network
>> > (stuttering) dmesg frequently printed that message related to "SCAN".
>>
>> Sounds like you have 'ifconfig iwx0 debug' enabled?
>>
>
> Not that I am aware of :-)
> Never typed any debug on the command line, nor in /etc/hostname.iwx0
> If in case, how to check it is enabled?
>
>
>> I don't see why SCAN messages would appear otherwise.
>>
>
> Actually, my mistake. SOME OF the dmesg messages ended with a reference to
> SCAN, probably prior to connect to the wpa.
> AS you can see from my initial message, in the attached dmesg there is no
> reference to SCAN.
>
>
>>
>> Frequent printing to dmesg can interfere with regular operation.
>> Please only enable 'debug' if really needed.
>>
>> > I tried to measure the speed as soon as I got a desktop working, and it
>> > goes from some hundred to 800/900 Kbits per second.
>> > Probably this very slow rate has to do with unlucky firmware and
>> continuous
>> > connection resets.
>> > Gmail is not able to load, for example.
>> >
>> > What is the speed you get? Is it stable?
>>
>> It is working OK for me up with up to somewhere around 20 Mbps.
>> Linux can of course drive the device to be a lot faster than that but
>> we don't support full 11n, let alone 11ac, yet.
>>
>
> Yes, I've read it in man page. 20Mbps would be good indeed, and expected
> for 802.11g.
> And yes, with linux I reach 60Mbps in 11n, or ac, don't know exactly..
>
> Let me know if I can help somehow
>
> Kind regards, Giacomo
>
>
>
> --
> Giacomo S.
> http://www.giacomos.it
>
> Sincrotrone Trieste S.C.p.A. di interesse nazionale
> Strada Statale 14 - km 163,5 in AREA Science Park
> 34149 Basovizza, Trieste ITALY
> -
> 040 3758073
> 328 3237959
>
>

-- 
Giacomo S.
http://www.giacomos.it

Sincrotrone Trieste S.C.p.A. di interesse nazionale
Strada Statale 14 - km 163,5 in AREA Science Park
34149 Basovizza, Trieste ITALY
-
040 3758073
328 3237959


Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Giacomo
Hello again


El jue., 23 abr. 2020 a las 12:31, Stefan Sperling ()
escribió:

> On Thu, Apr 23, 2020 at 12:13:09PM +0200, Giacomo wrote:
> > Hi Stefan. Thanks for Your prompt response!
> > Since I seem to understand firmware is taken from linux iwlwifi, my idea
> > was to understand which one(s) you picked up and how you built the
> > package iwx-firmware-20191022p0.
> > Maybe worth trying with some other .ucode in there.. don't know, just
> > guessing.
> > I am not an expert
>
> Just dropping in another firmware won't magically fix anything.
> Firmware and driver need to be in sync for things to work.
>
>
I understand


> I picked the lowest FW version (46) the device supports because
> this means the least amount of changes had to be made relative
> to iwm(4) code (the iwx driver code was derived from iwm).
>
> > What do you mean by specific environment?
> > It is a PCI-E card installed on my desktop. Yesterday I did a fresh
> > snapshot of 6.7 installation and configured the card with WPA2.
> > Even before configuring it and being able to connect to the network
> > (stuttering) dmesg frequently printed that message related to "SCAN".
>
> Sounds like you have 'ifconfig iwx0 debug' enabled?
>

Not that I am aware of :-)
Never typed any debug on the command line, nor in /etc/hostname.iwx0
If in case, how to check it is enabled?


> I don't see why SCAN messages would appear otherwise.
>

Actually, my mistake. SOME OF the dmesg messages ended with a reference to
SCAN, probably prior to connect to the wpa.
AS you can see from my initial message, in the attached dmesg there is no
reference to SCAN.


>
> Frequent printing to dmesg can interfere with regular operation.
> Please only enable 'debug' if really needed.
>
> > I tried to measure the speed as soon as I got a desktop working, and it
> > goes from some hundred to 800/900 Kbits per second.
> > Probably this very slow rate has to do with unlucky firmware and
> continuous
> > connection resets.
> > Gmail is not able to load, for example.
> >
> > What is the speed you get? Is it stable?
>
> It is working OK for me up with up to somewhere around 20 Mbps.
> Linux can of course drive the device to be a lot faster than that but
> we don't support full 11n, let alone 11ac, yet.
>

Yes, I've read it in man page. 20Mbps would be good indeed, and expected
for 802.11g.
And yes, with linux I reach 60Mbps in 11n, or ac, don't know exactly..

Let me know if I can help somehow

Kind regards, Giacomo



-- 
Giacomo S.
http://www.giacomos.it

Sincrotrone Trieste S.C.p.A. di interesse nazionale
Strada Statale 14 - km 163,5 in AREA Science Park
34149 Basovizza, Trieste ITALY
-
040 3758073
328 3237959


Re: CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
On 2020/04/23 04:54, Stuart Henderson wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   st...@cvs.openbsd.org   2020/04/23 04:54:48
> 
> Modified files:
>   www/squid  : Makefile distinfo 
> 
> Log message:
> update to squid-4.11
> 
> SQUID-2020:3 - Due to incorrect buffer handling Squid is vulnerable to
> cache poisoning, remote execution, and denial of service attacks when
> processing ESI responses.

oops, this one was actually SQUID-2019:12

> SQUID-2020:4 - Due to an integer overflow bug Squid is vulnerable to
> credential replay and remote code execution attacks against HTTP Digest
> Authentication tokens.
> 



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org   2020/04/23 04:54:48

Modified files:
www/squid  : Makefile distinfo 

Log message:
update to squid-4.11

SQUID-2020:3 - Due to incorrect buffer handling Squid is vulnerable to
cache poisoning, remote execution, and denial of service attacks when
processing ESI responses.

SQUID-2020:4 - Due to an integer overflow bug Squid is vulnerable to
credential replay and remote code execution attacks against HTTP Digest
Authentication tokens.



Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Stefan Sperling
On Thu, Apr 23, 2020 at 12:13:09PM +0200, Giacomo wrote:
> Hi Stefan. Thanks for Your prompt response!
> Since I seem to understand firmware is taken from linux iwlwifi, my idea
> was to understand which one(s) you picked up and how you built the
> package iwx-firmware-20191022p0.
> Maybe worth trying with some other .ucode in there.. don't know, just
> guessing.
> I am not an expert

Just dropping in another firmware won't magically fix anything.
Firmware and driver need to be in sync for things to work.

I picked the lowest FW version (46) the device supports because
this means the least amount of changes had to be made relative
to iwm(4) code (the iwx driver code was derived from iwm).

> What do you mean by specific environment?
> It is a PCI-E card installed on my desktop. Yesterday I did a fresh
> snapshot of 6.7 installation and configured the card with WPA2.
> Even before configuring it and being able to connect to the network
> (stuttering) dmesg frequently printed that message related to "SCAN".

Sounds like you have 'ifconfig iwx0 debug' enabled?
I don't see why SCAN messages would appear otherwise.

Frequent printing to dmesg can interfere with regular operation.
Please only enable 'debug' if really needed.

> I tried to measure the speed as soon as I got a desktop working, and it
> goes from some hundred to 800/900 Kbits per second.
> Probably this very slow rate has to do with unlucky firmware and continuous
> connection resets.
> Gmail is not able to load, for example.
> 
> What is the speed you get? Is it stable?

It is working OK for me up with up to somewhere around 20 Mbps.
Linux can of course drive the device to be a lot faster than that but
we don't support full 11n, let alone 11ac, yet.



Re: UPDATE: i2pd 2.26.0 -> 2.30.0

2020-04-23 Thread satmeir
On 2020-04-22 21:23, Stuart Henderson wrote:
> On 2020/04/22 20:52, satmeir wrote:
>> On 2020-04-21 16:08, clematis wrote:
>>> On Thu, Apr 16, 2020 at 06:57:52PM +0200, clematis wrote:
 - *but* it won't run out of the box. (2.26.0 was good to go). Got
   straight a /var/lib/i2pd/i2pd.core which I haven't looked at yet. I
   might be able to have another look at this and re-do the process 
 tomorrow. 

 But you might want to double check this in the meantime. (removing user,
 group and /var/lib/i2pd each time and clean all)
>>>
>>> Hi Satmeir,
>>> Sorry I didn't have time to look at this sooner. Is that working on
>>> your machine? Still crash on mine as soon as I try to start it (rcctl
>>> start i2pd) 
>>>
>>> Loaded symbols for /usr/lib/libc.so.96.0
>>> Reading symbols from /usr/libexec/ld.so...Error while reading shared
>>> library symbols:
>>> Dwarf Error: wrong version in compilation unit header (is 4, should be
>>> 2) [in module /usr/libexec/ld.so]
>>> #0  BN_num_bits (a=0x696e97f6f80) at
>>> /usr/src/lib/libcrypto/bn/bn_lib.c:182
>>> 182 return ((i * BN_BITS2) + BN_num_bits_word(a->d[i]));
>>>
>>>
>>> For the record: -- Found OpenSSL: /usr/lib/libcrypto.so.46.1 (found version 
>>> "2.0.0")  
>>>
>>> Cheers,
>>>
>> I think I fixed the issues by recreating and manually editing the
>> pkg/PLIST. I've also added the "if needed", good point. I've attached
>> the latest diff.
>>
>> Please check that the pkg/PLIST is in the right format.
>>
>> -- 
>> satmeir
>> use pgp
>> 92E1 AF2A D62E 7B46 00EE DE82 C3C3 BBA2 91DD DB9F
> 
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/net/i2pd/Makefile,v
>> retrieving revision 1.1.1.1
>> diff -u -p -r1.1.1.1 Makefile
>> --- Makefile 16 Jun 2019 22:13:55 -  1.1.1.1
>> +++ Makefile 22 Apr 2020 18:48:18 -
>> @@ -4,7 +4,7 @@ COMMENT =client for the I2P anonymous n
>>  
>>  GH_ACCOUNT =PurpleI2P
>>  GH_PROJECT =i2pd
>> -GH_TAGNAME =2.26.0
>> +GH_TAGNAME =2.31.0
>>  
>>  CATEGORIES =net
>>  HOMEPAGE =  https://i2pd.website
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/net/i2pd/distinfo,v
>> retrieving revision 1.1.1.1
>> diff -u -p -r1.1.1.1 distinfo
>> --- distinfo 16 Jun 2019 22:13:55 -  1.1.1.1
>> +++ distinfo 22 Apr 2020 18:48:18 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (i2pd-2.26.0.tar.gz) = KuGJeMh5a7a0W8jP5OHyU3fgz8n8+fRgVLCdwzhO72M=
>> -SIZE (i2pd-2.26.0.tar.gz) = 1073024
>> +SHA256 (i2pd-2.31.0.tar.gz) = fjerz0np9Z72k5Bp9NdPxr8psJ3uwRG9NWECH8E0lSg=
>> +SIZE (i2pd-2.31.0.tar.gz) = 1092238
>> Index: patches/patch-build_CMakeLists_txt
>> ===
>> RCS file: /cvs/ports/net/i2pd/patches/patch-build_CMakeLists_txt,v
>> retrieving revision 1.1.1.1
>> diff -u -p -r1.1.1.1 patch-build_CMakeLists_txt
>> --- patches/patch-build_CMakeLists_txt   16 Jun 2019 22:13:55 -  
>> 1.1.1.1
>> +++ patches/patch-build_CMakeLists_txt   22 Apr 2020 18:48:18 -
>> @@ -3,7 +3,7 @@ $OpenBSD: patch-build_CMakeLists_txt,v 1
>>  Index: build/CMakeLists.txt
>>  --- build/CMakeLists.txt.orig
>>  +++ build/CMakeLists.txt
>> -@@ -473,7 +473,7 @@ if (WITH_BINARY)
>> +@@ -456,7 +456,7 @@ if (WITH_BINARY)
>> target_link_libraries(libi2pd ${Boost_LIBRARIES} ${ZLIB_LIBRARY})
>> target_link_libraries( "${PROJECT_NAME}" libi2pd libi2pdclient ${DL_LIB} 
>> ${Boost_LIBRARIES} ${OPENSSL_LIBRARIES} ${ZLIB_LIBRARY} 
>> ${CMAKE_THREAD_LIBS_INIT} ${MINGW_EXTRA} ${DL_LIB} 
>> ${CMAKE_REQUIRED_LIBRARIES})
>>   
>> @@ -12,7 +12,7 @@ Index: build/CMakeLists.txt
>> set (APPS 
>> "\${CMAKE_INSTALL_PREFIX}/bin/${PROJECT_NAME}${CMAKE_EXECUTABLE_SUFFIX}")
>> set (DIRS 
>> "${Boost_LIBRARY_DIR};${OPENSSL_INCLUDE_DIR}/../bin;${ZLIB_INCLUDE_DIR}/../bin;/mingw32/bin")
>> if (MSVC)
>> -@@ -487,7 +487,7 @@ if (WITH_BINARY)
>> +@@ -470,7 +470,7 @@ if (WITH_BINARY)
>>   endif ()
>>   
>>   install(FILES ../LICENSE
>> @@ -21,7 +21,7 @@ Index: build/CMakeLists.txt
>> COMPONENT Runtime
>> )
>>   # Take a copy on Appveyor
>> -@@ -498,8 +498,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
>> +@@ -481,8 +481,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
>> OPTIONAL  # for local builds only!
>> )
>>   
>> @@ -32,7 +32,7 @@ Index: build/CMakeLists.txt
>>   # install(DIRECTORY ../ DESTINATION src/
>>   #   # OPTIONAL
>>   #   COMPONENT Source FILES_MATCHING
>> -@@ -508,7 +508,7 @@ install(FILES ${I2PD_SOURCES} DESTINATION src/ COMPONE
>> +@@ -491,7 +491,7 @@ install(FILES ${I2PD_SOURCES} DESTINATION src/ COMPONE
>>   #   )
>>   
>>   file(GLOB I2PD_HEADERS "../libi2pd/*.h" "../libi2pd_client/*.h" 
>> "../daemon/*.h")
>> Index: patches/patch-tests_Makefile
>> ===
>> RCS file: 

Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Giacomo
Hi Stefan. Thanks for Your prompt response!
Since I seem to understand firmware is taken from linux iwlwifi, my idea
was to understand which one(s) you picked up and how you built the
package iwx-firmware-20191022p0.
Maybe worth trying with some other .ucode in there.. don't know, just
guessing.
I am not an expert

What do you mean by specific environment?
It is a PCI-E card installed on my desktop. Yesterday I did a fresh
snapshot of 6.7 installation and configured the card with WPA2.
Even before configuring it and being able to connect to the network
(stuttering) dmesg frequently printed that message related to "SCAN".

I tried to measure the speed as soon as I got a desktop working, and it
goes from some hundred to 800/900 Kbits per second.
Probably this very slow rate has to do with unlucky firmware and continuous
connection resets.
Gmail is not able to load, for example.

What is the speed you get? Is it stable?

I wish I could help You more.

Giacomo.



El jue., 23 abr. 2020 a las 11:58, Stefan Sperling ()
escribió:

> On Thu, Apr 23, 2020 at 11:05:51AM +0200, Giacomo wrote:
> > Hello everyone.
> >
> > pcidump -v:
> >
> > 2:0:0: Intel Wi-Fi 6 AX200
> > 0x: Vendor ID: 8086, Product ID: 2723
> > 0x0004: Command: 0006, Status: 0010
> > 0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
> > Interface: 00, Revision: 1a
> > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> > Cache Line Size: 10
> > 0x0010: BAR mem 64bit addr: 0xf7c0/0x4000
> > 0x0018: BAR empty ()
> > 0x001c: BAR empty ()
> > 0x0020: BAR empty ()
> > 0x0024: BAR empty ()
> > 0x0028: Cardbus CIS: 
> > 0x002c: Subsystem Vendor ID: 8086 Product ID: 0084
> > 0x0030: Expansion ROM Base Address: 
> > 0x0038: 
> > 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
> > 0x00c8: Capability 0x01: Power Management
> > State: D0
> > 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
> > Enabled: no
> > 0x0040: Capability 0x10: PCI Express
> > Link Speed: 5.0 / 5.0 GT/s, Link Width: x1 / x1
> > 0x0100: Enhanced Capability 0x01: Advanced Error Reporting
> > 0x014c: Enhanced Capability 0x18: Latency Tolerance Reporting
> > 0x0154: Enhanced Capability 0x1e: L1 PM
> > 0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
> > Enabled: yes; table size 16 (BAR 0:8192)
>
> This is a new driver and the hardware isn't very widespread yet.
> So problems like this are unfortunate but somewhat expected.
>
> The device iwx(4) was developed with is the one shown below.
> Note that the Subsystem Product ID differs (0080 vs 0084).
> Whether or not this difference matters is something we cannot know without
> doing tedious research since Intel provides no documentation.
>
> My device sees only very occasional firmware errors which don't prevent
> regular usage. It's still unclear why these occur.
>
> Unless there is a way for me to reproduce frequent error conditions
> locally there is nothing I could do to help.
> Are these errors happening in a specific environment or everywhere?
>
>  4:0:0: Intel Wi-Fi 6 AX200
> 0x: Vendor ID: 8086, Product ID: 2723
> 0x0004: Command: 0006, Status: 0010
> 0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
> Interface: 00, Revision: 1a
> 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> Cache Line Size: 10
> 0x0010: BAR mem 64bit addr: 0xf7c0/0x4000
> 0x0018: BAR empty ()
> 0x001c: BAR empty ()
> 0x0020: BAR empty ()
> 0x0024: BAR empty ()
> 0x0028: Cardbus CIS: 
> 0x002c: Subsystem Vendor ID: 8086 Product ID: 0080
> 0x0030: Expansion ROM Base Address: 
> 0x0038: 
> 0x003c: Interrupt Pin: 01 Line: 03 Min Gnt: 00 Max Lat: 00
> 0x00c8: Capability 0x01: Power Management
> State: D0
> 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
> Enabled: no
> 0x0040: Capability 0x10: PCI Express
> Link Speed: 5.0 / 5.0 GT/s, Link Width: x1 / x1
> 0x0100: Enhanced Capability 0x01: Advanced Error Reporting
> 0x014c: Enhanced Capability 0x18: Latency Tolerance Reporting
> 0x0154: Enhanced Capability 0x1e: L1 PM
> 0x0080: Capability 0x11: Extended Message Signalled Interrupts
> (MSI-X)
> Enabled: yes; table size 16 (BAR 0:8192)
>


-- 
Giacomo S.
http://www.giacomos.it

Sincrotrone Trieste S.C.p.A. di interesse nazionale
Strada Statale 14 - km 163,5 in AREA Science Park
34149 Basovizza, Trieste ITALY
-
040 3758073
328 3237959


Re: iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Stefan Sperling
On Thu, Apr 23, 2020 at 11:05:51AM +0200, Giacomo wrote:
> Hello everyone.
> 
> pcidump -v:
> 
> 2:0:0: Intel Wi-Fi 6 AX200
> 0x: Vendor ID: 8086, Product ID: 2723
> 0x0004: Command: 0006, Status: 0010
> 0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
> Interface: 00, Revision: 1a
> 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> Cache Line Size: 10
> 0x0010: BAR mem 64bit addr: 0xf7c0/0x4000
> 0x0018: BAR empty ()
> 0x001c: BAR empty ()
> 0x0020: BAR empty ()
> 0x0024: BAR empty ()
> 0x0028: Cardbus CIS: 
> 0x002c: Subsystem Vendor ID: 8086 Product ID: 0084
> 0x0030: Expansion ROM Base Address: 
> 0x0038: 
> 0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
> 0x00c8: Capability 0x01: Power Management
> State: D0
> 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
> Enabled: no
> 0x0040: Capability 0x10: PCI Express
> Link Speed: 5.0 / 5.0 GT/s, Link Width: x1 / x1
> 0x0100: Enhanced Capability 0x01: Advanced Error Reporting
> 0x014c: Enhanced Capability 0x18: Latency Tolerance Reporting
> 0x0154: Enhanced Capability 0x1e: L1 PM
> 0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
> Enabled: yes; table size 16 (BAR 0:8192)

This is a new driver and the hardware isn't very widespread yet.
So problems like this are unfortunate but somewhat expected.

The device iwx(4) was developed with is the one shown below.
Note that the Subsystem Product ID differs (0080 vs 0084).
Whether or not this difference matters is something we cannot know without
doing tedious research since Intel provides no documentation.

My device sees only very occasional firmware errors which don't prevent
regular usage. It's still unclear why these occur.

Unless there is a way for me to reproduce frequent error conditions
locally there is nothing I could do to help.
Are these errors happening in a specific environment or everywhere?

 4:0:0: Intel Wi-Fi 6 AX200
0x: Vendor ID: 8086, Product ID: 2723
0x0004: Command: 0006, Status: 0010
0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
Interface: 00, Revision: 1a
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xf7c0/0x4000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 8086 Product ID: 0080
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 03 Min Gnt: 00 Max Lat: 00
0x00c8: Capability 0x01: Power Management
State: D0
0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: no
0x0040: Capability 0x10: PCI Express
Link Speed: 5.0 / 5.0 GT/s, Link Width: x1 / x1
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x014c: Enhanced Capability 0x18: Latency Tolerance Reporting
0x0154: Enhanced Capability 0x1e: L1 PM
0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
Enabled: yes; table size 16 (BAR 0:8192)



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/04/23 03:31:28

Modified files:
lang/vala  : Makefile distinfo 

Log message:
update to vala-0.46.9



iwx fatal firmware error on Intel Wi-Fi 6 AX200

2020-04-23 Thread Giacomo
Hello everyone.

pcidump -v:

2:0:0: Intel Wi-Fi 6 AX200
0x: Vendor ID: 8086, Product ID: 2723
0x0004: Command: 0006, Status: 0010
0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
Interface: 00, Revision: 1a
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xf7c0/0x4000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 8086 Product ID: 0084
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
0x00c8: Capability 0x01: Power Management
State: D0
0x00d0: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: no
0x0040: Capability 0x10: PCI Express
Link Speed: 5.0 / 5.0 GT/s, Link Width: x1 / x1
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x014c: Enhanced Capability 0x18: Latency Tolerance Reporting
0x0154: Enhanced Capability 0x1e: L1 PM
0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
Enabled: yes; table size 16 (BAR 0:8192)


FIRMWARE

 fw_update -i

Installed: inteldrm-firmware-20181218 vmm-firmware-1.11.0p2
iwx-firmware-20191022p0 intel-firmware-20191115p0v0


DMESG

iwx0: dumping device error log
iwx0: Start Error Log Dump:
iwx0: Status: 0x1, count: 6
iwx0: 0x0071 | NMI_INTERRUPT_UMAC_FATAL
iwx0: 002022F0 | trm_hw_status0
iwx0:  | trm_hw_status1
iwx0: 004FC308 | branchlink2
iwx0: 00016E5A | interruptlink1
iwx0: 00016E5A | interruptlink2
iwx0: 004F9F62 | data1
iwx0: 1000 | data2
iwx0: F008 | data3
iwx0:  | beacon time
iwx0: 00010996 | tsf low
iwx0:  | tsf hi
iwx0:  | time gp1
iwx0: 00010997 | time gp2
iwx0: 0001 | uCode revision type
iwx0: 002E | uCode version major
iwx0: 177B3E46 | uCode version minor
iwx0: 0340 | hw version
iwx0: 18889000 | board version
iwx0: 800AFD0C | hcmd
iwx0: 0002 | isr0
iwx0:  | isr1
iwx0: 18F2 | isr2
iwx0: 00CC | isr3
iwx0:  | isr4
iwx0:  | last cmd Id
iwx0: 004F9F62 | wait_event
iwx0:  | l2p_control
iwx0: 0020 | l2p_duration
iwx0:  | l2p_mhvalid
iwx0:  | l2p_addr_match
iwx0: 0009 | lmpm_pmg_sel
iwx0: 19071335 | timestamp
iwx0: 0828 | flow_handler
iwx0: Start UMAC Error Log Dump:
iwx0: Status: 0x1, count: 7
iwx0: 0x201010A3 | ADVANCED_SYSASSERT
iwx0: 0x | umac branchlink1
iwx0: 0xC008B1C0 | umac branchlink2
iwx0: 0xC0084E04 | umac interruptlink1
iwx0: 0x | umac interruptlink2
iwx0: 0x0002 | umac data1
iwx0: 0x0001 | umac data2
iwx0: 0xDEADBEEF | umac data3
iwx0: 0x002E | umac major
iwx0: 0x177B3E46 | umac minor
iwx0: 0x00010987 | frame pointer
iwx0: 0xC0886C6C | stack pointer
iwx0: 0x00050C00 | last host cmd
iwx0: 0x | isr status reg
driver status:
  tx ring  0: qid=0  cur=6   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=0   queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  tx ring 20: qid=20 cur=0   queued=0
  tx ring 21: qid=21 cur=0   queued=0
  tx ring 22: qid=22 cur=0   queued=0
  tx ring 23: qid=23 cur=0   queued=0
  tx ring 24: qid=24 cur=0   queued=0
  tx ring 25: qid=25 cur=0   queued=0
  tx ring 26: qid=26 cur=0   queued=0
  tx ring 27: qid=27 cur=0   queued=0
  tx ring 28: qid=28 cur=0   queued=0
  tx ring 29: qid=29 cur=0   queued=0
  tx ring 30: qid=30 cur=0   queued=0
  rx ring: cur=265
  802.11 state INIT
iwx0: fatal firmware error
iwx0: hw rev 0x340, fw ver 46.393952838.0, address 84:c5:a6:00:10:ef



This error appears continuously making the network unusable


openbsd# uname -ar
OpenBSD openbsd.home 6.7 GENERIC.MP#149 amd64

cat /etc/hostname.iwx0

nwid SetTheControls wpakey mykey
dhcp

openbsd# ifconfig iwx0

iwx0: flags=808843 mtu
1500
lladdr 84:c5:a6:00:10:ef
index 2 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS5 mode 11n)
status: active
ieee80211: nwid SetTheControls chan 1 bssid 5c:e2:8c:7d:cd:28 56% wpakey
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.159 netmask 0xff00 broadcast 192.168.1.255


I have checked whether on http://firmware.openbsd.org/firmware/  there are
other available versions but could not find any.


If this can help, on Linux the device works properly with iwlwifi firmware

Re: CVS: cvs.openbsd.org: ports

2020-04-23 Thread Stuart Henderson
On 2020/04/23 01:56, Remi Pointel wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   rpoin...@cvs.openbsd.org2020/04/23 01:56:01
> 
> Modified files:
>   lang/python/2.7: Makefile distinfo 
>   lang/python/2.7/pkg: PLIST-bsddb PLIST-gdbm PLIST-idle 
>PLIST-main PLIST-tests PLIST-tkinter 
>PLIST-tools 
> 
> Log message:
> update python to 2.7.18: the last release of Python 2.
> tested in a bulk build by naddy@, thanks.
> 

And me!



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/04/23 02:59:12

Modified files:
graphics/gthumb: Makefile distinfo 
graphics/gthumb/pkg: PLIST 

Log message:
update to gthumb-3.10.0



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Marc Espie
CVSROOT:/cvs
Module name:ports
Changes by: es...@cvs.openbsd.org   2020/04/23 02:53:38

Modified files:
graphics/unwebp: Makefile distinfo 

Log message:
small bug-fix release



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Jasper Lievisse Adriaanse
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org  2020/04/23 02:36:11

Modified files:
lang/arena : Makefile 
Added files:
lang/arena/patches: patch-libparser_expr_dump_c 

Log message:
Add missing specifier in format string



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Remi Pointel
CVSROOT:/cvs
Module name:ports
Changes by: rpoin...@cvs.openbsd.org2020/04/23 01:56:01

Modified files:
lang/python/2.7: Makefile distinfo 
lang/python/2.7/pkg: PLIST-bsddb PLIST-gdbm PLIST-idle 
 PLIST-main PLIST-tests PLIST-tkinter 
 PLIST-tools 

Log message:
update python to 2.7.18: the last release of Python 2.
tested in a bulk build by naddy@, thanks.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Landry Breuil
CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org  2020/04/23 00:48:47

Modified files:
x11/xfce4/xfce4-whiskermenu: Makefile distinfo 

Log message:
Update to xfce4-whiskermenu 2.4.4



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:42:08

Modified files:
graphics/libavif: Makefile distinfo 
graphics/libavif/pkg: PLIST 
Added files:
graphics/libavif/patches: patch-apps_avifdump_c 
  patch-apps_avifenc_c 
  patch-src_codec_aom_c 
Removed files:
graphics/libavif/patches: patch-src_reformat_c 

Log message:
Update to libavif 0.7.1.
- Enable the encoding/decoding apps.
- Add support for JPEG and PNG to the encoding/decoding apps.

from Brad (maintainer)



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:33:13

Modified files:
textproc/icu4c : Makefile distinfo 
textproc/icu4c/patches: patch-source_common_Makefile_in 
patch-source_common_putil_cpp 
patch-source_config_icu-config-bottom 
patch-source_i18n_Makefile_in 
patch-source_io_Makefile_in 
patch-source_layoutex_Makefile_in 
patch-source_stubdata_Makefile_in 
patch-source_tools_ctestfw_Makefile_in 
patch-source_tools_toolutil_Makefile_in 
Removed files:
textproc/icu4c/patches: patch-source_data_Makefile_in 

Log message:
Update to icu4c-67.1.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:32:08

Modified files:
sysutils/awscli: Makefile distinfo 

Log message:
Update to awscli-1.18.44.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:31:54

Modified files:
net/py-boto3   : Makefile distinfo 

Log message:
Update to py3-boto3-1.12.44.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:31:41

Modified files:
net/py-botocore: Makefile distinfo 

Log message:
Update to py3-botocore-1.15.44.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:23:54

Modified files:
sysutils/google-cloud-sdk: Makefile distinfo 
sysutils/google-cloud-sdk/patches: 
   
patch-lib_googlecloudsdk_core_config_json 
sysutils/google-cloud-sdk/pkg: PLIST 

Log message:
Update to google-cloud-sdk-290.0.0.



CVS: cvs.openbsd.org: ports

2020-04-23 Thread Antoine Jacoutot
CVSROOT:/cvs
Module name:ports
Changes by: ajacou...@cvs.openbsd.org   2020/04/23 00:09:32

Modified files:
sysutils/nomad : Makefile distinfo 

Log message:
Update to nomad-0.11.1.