Re: [PATCH] Fix Valgrind reports invalid write

2020-05-07 Thread Masato Asou
From: Jeremie Courreges-Anglas 
Date: Thu, 07 May 2020 14:12:08 +0200

> On Thu, May 07 2020, Masato Asou  wrote:
>> hi,
>>
>> Valgrind reports the correct wirte as an invalid write. It is
>> occurring at /usr/libexec/ld.so.
>>
>> I run following program.
>>
>> $ cat main.c
>> #include 
>>
>> int
>> main(int argc, char *argv[])
>> {
>> printf("Hello, world\n");
>> return (0);
>> }
>> $ cc -g main.c
>> $ valgrind ./a.out
>> ==46291== Memcheck, a memory error detector
>> ==46291== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==46291== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
>> ==46291== Command: /home/asou/tmp/a.out
>> ==46291==
>> ==46291== Invalid write of size 1
>> ==46291==at 0x410730C: ???
>> ==46291==by 0x4103CC8: ???
>> ==46291==by 0x41032EE: ???
>> ==46291==by 0x4102605: ???
>> ==46291==  Address 0x40052d0 is not stack'd, malloc'd or (recently) free'd
>> ==46291==
>> ==46291== Invalid write of size 1
>> ==46291==at 0x410730E: ???
>> ==46291==by 0x4103CC8: ???
>> ==46291==by 0x41032EE: ???
>> ==46291==by 0x4102605: ???
>> ==46291==  Address 0x40052d1 is not stack'd, malloc'd or (recently) free'd
>> ==46291==
>>
>> 
>>
>> ==46291== For counts of detected and suppressed errors, rerun with: -v
>> ==46291== Use --track-origins=yes to see where uninitialised values come from
>> ==46291== ERROR SUMMARY: 3209 errors from 357 contexts (suppressed: 0 from 0)
>> $ 
>>
>> I got 3209 errors.
>>
>> However, when the following patch was applied, the error was reduced
>> to four as below:
> 
> Hah, that look much better.
> 
>> $ valgrind ./a.out
>> ==7449== Memcheck, a memory error detector
>> ==7449== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==7449== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
>> ==7449== Command: /home/asou/tmp/a.out
>> ==7449==
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACB969: write (sys/w_write.c:26)
>> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
>> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
>> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
>> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
>> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
>> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
>> ==7449==by 0x109374: main (main.c:6)
>> ==7449==
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACB97A: write (sys/w_write.c:26)
>> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
>> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
>> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
>> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
>> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
>> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
>> ==7449==by 0x109374: main (main.c:6)
>> ==7449==
>> Hello, world
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACB98E: write (sys/w_write.c:28)
>> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
>> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
>> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
>> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
>> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
>> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
>> ==7449==by 0x109374: main (main.c:6)
>> ==7449==
>> ==7449== Use of uninitialised value of size 8
>> ==7449==at 0x4ACC31C: _thread_finalize (stdlib/atexit.c:131)
>> ==7449==by 0x4ACC31C: __cxa_finalize (stdlib/atexit.c:153)
>> ==7449==by 0x4AD13C0: exit (stdlib/exit.c:54)
>> ==7449==by 0x109141: ___start (in /home/asou/tmp/a.out)
>> ==7449==
>> ==7449==
>> ==7449== FILE DESCRIPTORS: 3 open at exit.
>> ==7449== Open file descriptor 2:
>> ==7449==
>> ==7449==
>> ==7449== Open file descriptor 1:
>> ==7449==
>> ==7449==
>> ==7449== Open file descriptor 0:
>> ==7449==
>> ==7449==
>> ==7449==
>> ==7449== HEAP SUMMARY:
>> ==7449== in use at exit: 65,536 bytes in 1 blocks
>> ==7449==   total heap usage: 1 allocs, 0 frees, 65,536 bytes allocated
>> ==7449==
>> ==7449== LEAK SUMMARY:
>> ==7449==definitely lost: 0 bytes in 0 blocks
>> ==7449==indirectly lost: 0 bytes in 0 blocks
>> ==7449==  possibly lost: 0 bytes in 0 blocks
>> ==7449==still reachable: 65,536 bytes in 1 blocks
>> ==7449== suppressed: 0 bytes in 0 blocks
>> ==7449== Rerun with --leak-check=full to see details of leaked memory
>> ==7449==
>> ==7449== For counts of detected and suppressed errors, rerun with: -v
>> ==7449== Use --track-origins=yes to see where uninitialised values come from
>> ==7449== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
>> $ 
>>
>>
>> The patch to Makefile is a temporary. Because, my previous patch
>> https://marc.info/?l=openbsd-ports&m=158624064212984&w=2
>> does not get OK.

Ports tree locked

2020-05-07 Thread Christian Weisgerber
The ports tree is locked for 6.7 now.

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



Re: Xfce: display flicker on recent snaps

2020-05-07 Thread Amit Kulkarni
On Thu, May 7, 2020 at 1:25 AM Landry Breuil  wrote:
>
> On Thu, May 07, 2020 at 08:14:56AM +0200, Landry Breuil wrote:
> > On Wed, May 06, 2020 at 10:43:14PM -0500, Amit Kulkarni wrote:
> > > Hi,
> > >
> > > Since about the last couple of days or so, the firefox display keeps 
> > > flickering every 5-7 seconds on a plain install of Xfce desktop.It looks 
> > > like the title bar of the browser keeps on turning off and then on.
> > >
> > > Is it just me or does it happen with anybody else with xfce ?
> > > This does not happen with firefox in fvwm.
> >
> > probably related to the xfwm4 update in
> > https://marc.info/?l=openbsd-ports-cvs&m=158840312213950&w=2 (see
> > https://mail.xfce.org/pipermail/xfce-announce/2020-May/000856.html),
> > flickering is usually due to xpresent being used or not for vblank_mode.
> > (see /usr/local/share/doc/pkg-readmes/xfce where this is documented).
>
> More specifically for AMD, this is probably related to
> https://gitlab.xfce.org/xfce/xfwm4/commit/7c00911a556c27c57c9f719c12cfda967016dc28
> which stops prefering xpresent on those chips, cf
> https://bugzilla.xfce.org/show_bug.cgi?id=16716
>

Thanks for the confirmation.



Re: [PATCH] Fix Valgrind reports invalid write

2020-05-07 Thread Jeremie Courreges-Anglas
On Thu, May 07 2020, Masato Asou  wrote:
> hi,
>
> Valgrind reports the correct wirte as an invalid write. It is
> occurring at /usr/libexec/ld.so.
>
> I run following program.
>
> $ cat main.c
> #include 
>
> int
> main(int argc, char *argv[])
> {
> printf("Hello, world\n");
> return (0);
> }
> $ cc -g main.c
> $ valgrind ./a.out
> ==46291== Memcheck, a memory error detector
> ==46291== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==46291== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
> ==46291== Command: /home/asou/tmp/a.out
> ==46291==
> ==46291== Invalid write of size 1
> ==46291==at 0x410730C: ???
> ==46291==by 0x4103CC8: ???
> ==46291==by 0x41032EE: ???
> ==46291==by 0x4102605: ???
> ==46291==  Address 0x40052d0 is not stack'd, malloc'd or (recently) free'd
> ==46291==
> ==46291== Invalid write of size 1
> ==46291==at 0x410730E: ???
> ==46291==by 0x4103CC8: ???
> ==46291==by 0x41032EE: ???
> ==46291==by 0x4102605: ???
> ==46291==  Address 0x40052d1 is not stack'd, malloc'd or (recently) free'd
> ==46291==
>
> 
>
> ==46291== For counts of detected and suppressed errors, rerun with: -v
> ==46291== Use --track-origins=yes to see where uninitialised values come from
> ==46291== ERROR SUMMARY: 3209 errors from 357 contexts (suppressed: 0 from 0)
> $ 
>
> I got 3209 errors.
>
> However, when the following patch was applied, the error was reduced
> to four as below:

Hah, that look much better.

> $ valgrind ./a.out
> ==7449== Memcheck, a memory error detector
> ==7449== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==7449== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
> ==7449== Command: /home/asou/tmp/a.out
> ==7449==
> ==7449== Use of uninitialised value of size 8
> ==7449==at 0x4ACB969: write (sys/w_write.c:26)
> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
> ==7449==by 0x109374: main (main.c:6)
> ==7449==
> ==7449== Use of uninitialised value of size 8
> ==7449==at 0x4ACB97A: write (sys/w_write.c:26)
> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
> ==7449==by 0x109374: main (main.c:6)
> ==7449==
> Hello, world
> ==7449== Use of uninitialised value of size 8
> ==7449==at 0x4ACB98E: write (sys/w_write.c:28)
> ==7449==by 0x4AB60DF: __sflush (stdio/fflush.c:80)
> ==7449==by 0x4A491F1: __sfvwrite (stdio/fvwrite.c:191)
> ==7449==by 0x4A62F62: __sprint (stdio/vfprintf.c:108)
> ==7449==by 0x4A62F62: __vfprintf (stdio/vfprintf.c:1067)
> ==7449==by 0x4A5F151: vfprintf (stdio/vfprintf.c:263)
> ==7449==by 0x4A43DB0: printf (stdio/printf.c:44)
> ==7449==by 0x109374: main (main.c:6)
> ==7449==
> ==7449== Use of uninitialised value of size 8
> ==7449==at 0x4ACC31C: _thread_finalize (stdlib/atexit.c:131)
> ==7449==by 0x4ACC31C: __cxa_finalize (stdlib/atexit.c:153)
> ==7449==by 0x4AD13C0: exit (stdlib/exit.c:54)
> ==7449==by 0x109141: ___start (in /home/asou/tmp/a.out)
> ==7449==
> ==7449==
> ==7449== FILE DESCRIPTORS: 3 open at exit.
> ==7449== Open file descriptor 2:
> ==7449==
> ==7449==
> ==7449== Open file descriptor 1:
> ==7449==
> ==7449==
> ==7449== Open file descriptor 0:
> ==7449==
> ==7449==
> ==7449==
> ==7449== HEAP SUMMARY:
> ==7449== in use at exit: 65,536 bytes in 1 blocks
> ==7449==   total heap usage: 1 allocs, 0 frees, 65,536 bytes allocated
> ==7449==
> ==7449== LEAK SUMMARY:
> ==7449==definitely lost: 0 bytes in 0 blocks
> ==7449==indirectly lost: 0 bytes in 0 blocks
> ==7449==  possibly lost: 0 bytes in 0 blocks
> ==7449==still reachable: 65,536 bytes in 1 blocks
> ==7449== suppressed: 0 bytes in 0 blocks
> ==7449== Rerun with --leak-check=full to see details of leaked memory
> ==7449==
> ==7449== For counts of detected and suppressed errors, rerun with: -v
> ==7449== Use --track-origins=yes to see where uninitialised values come from
> ==7449== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
> $ 
>
>
> The patch to Makefile is a temporary. Because, my previous patch
> https://marc.info/?l=openbsd-ports&m=158624064212984&w=2
> does not get OK.

I did take a look at that one but got lost in a maze.  Will get back to
it when time permits.

> ok?

Diff looks good, lightly tested with a few base executables.
ok jca@ but please wait for tree unlock.

Re: arm bulk build report

2020-05-07 Thread Peter Hessler
On 2020 May 07 (Thu) at 12:11:13 +0100 (+0100), Stuart Henderson wrote:
:On 2020/05/06 23:15, phess...@openbsd.org wrote:
:> build failures: 58
:
:Looking at the failures we can save ~40h of build time of armv7 if we
:set BROKEN/NOT_FOR_ARCHS on just the slowest ones. Worth at least applying
:locally on armv7 machines for now I think if not actually committing.
:

I think it would be best to actually commit these, so people have the
chance to fix them.  Your call if now or after unlock.

OK


:Index: textproc/podofo/Makefile
:===
:RCS file: /cvs/ports/textproc/podofo/Makefile,v
:retrieving revision 1.13
:diff -u -p -r1.13 Makefile
:--- textproc/podofo/Makefile   3 Feb 2020 20:40:41 -   1.13
:+++ textproc/podofo/Makefile   7 May 2020 11:09:14 -
:@@ -1,5 +1,7 @@
: # $OpenBSD: Makefile,v 1.13 2020/02/03 20:40:41 sthen Exp $
: 
:+BROKEN-arm=   build stuck in main.cpp
:+
: COMMENT=  library and tools to modify and parse PDF documents
: 
: DISTNAME= podofo-0.9.5
:Index: math/mlpack/Makefile
:===
:RCS file: /cvs/ports/math/mlpack/Makefile,v
:retrieving revision 1.14
:diff -u -p -r1.14 Makefile
:--- math/mlpack/Makefile   27 Feb 2020 18:15:25 -  1.14
:+++ math/mlpack/Makefile   7 May 2020 11:09:14 -
:@@ -1,5 +1,6 @@
: # $OpenBSD: Makefile,v 1.14 2020/02/27 18:15:25 bket Exp $
: 
:+BROKEN-arm =  llvm out of memory
: BROKEN-powerpc = virtual memory exhausted, even with -O1
: 
: COMMENT-main = C++ machine learning library
:Index: devel/arm-none-eabi/gcc-linaro/Makefile
:===
:RCS file: /cvs/ports/devel/arm-none-eabi/gcc-linaro/Makefile,v
:retrieving revision 1.16
:diff -u -p -r1.16 Makefile
:--- devel/arm-none-eabi/gcc-linaro/Makefile28 Sep 2019 00:29:11 -  
1.16
:+++ devel/arm-none-eabi/gcc-linaro/Makefile7 May 2020 11:09:14 -
:@@ -1,5 +1,6 @@
: # $OpenBSD: Makefile,v 1.16 2019/09/28 00:29:11 jsg Exp $
: 
:+BROKEN-arm=   ICE: Bus error in unwind-dw2.c
: BROKEN-powerpc=   libgcc/libgcc2.c:1999:1: internal compiler error: in 
create_edge, at cgraph.c:850
: 
: COMMENT=  gcc for ${CONFIG} cross-development, Linaro version
:Index: www/webkitgtk4/Makefile
:===
:RCS file: /cvs/ports/www/webkitgtk4/Makefile,v
:retrieving revision 1.120
:diff -u -p -r1.120 Makefile
:--- www/webkitgtk4/Makefile25 Apr 2020 20:04:50 -  1.120
:+++ www/webkitgtk4/Makefile7 May 2020 11:09:14 -
:@@ -7,6 +7,7 @@ USE_WXNEEDED = Yes
: 
: BROKEN-alpha =GCC 5.0.0 is required to build WebKitGTK+, use 
a newer GCC version or clang
: BROKEN-hppa = GCC 5.0.0 is required to build WebKitGTK+, use a newer 
GCC version or clang
:+BROKEN-arm =  JavaScriptCore/runtime/MachineContext.h, various 
sigcontext-related
: 
: PORTROACH =   limitw:1,even
: 
:Index: devel/xtensa-lx106-elf/gdb/Makefile
:===
:RCS file: /cvs/ports/devel/xtensa-lx106-elf/gdb/Makefile,v
:retrieving revision 1.3
:diff -u -p -r1.3 Makefile
:--- devel/xtensa-lx106-elf/gdb/Makefile23 Mar 2020 14:12:31 -  
1.3
:+++ devel/xtensa-lx106-elf/gdb/Makefile7 May 2020 11:09:14 -
:@@ -1,5 +1,7 @@
: # $OpenBSD: Makefile,v 1.3 2020/03/23 14:12:31 tracey Exp $
: 
:+BROKEN-arm =  can't create dynamic relocation R_ARM_ABS32 against local 
symbol in readonly segment
:+
: COMMENT = gdb for ${CONFIG} cross-development
: 
: VERSION = 8.2.1
:Index: geo/geos/Makefile
:===
:RCS file: /cvs/ports/geo/geos/Makefile,v
:retrieving revision 1.30
:diff -u -p -r1.30 Makefile
:--- geo/geos/Makefile  11 Mar 2020 15:35:58 -  1.30
:+++ geo/geos/Makefile  7 May 2020 11:09:14 -
:@@ -1,6 +1,8 @@
: # $OpenBSD: Makefile,v 1.30 2020/03/11 15:35:58 landry Exp $
: 
: BROKEN-hppa = undefined reference to 
'std::auto_ptr::~auto_ptr()'
:+BROKEN-arm =  ld: error: duplicate symbol: typeinfo for 
geos::noding::BasicSegmentString
:+
: COMMENT=  2d geometry and topology engine
: DISTNAME= geos-3.8.1
: CATEGORIES=   geo
:Index: sysutils/telegraf/Makefile
:===
:RCS file: /cvs/ports/sysutils/telegraf/Makefile,v
:retrieving revision 1.7
:diff -u -p -r1.7 Makefile
:--- sysutils/telegraf/Makefile 12 Nov 2019 22:31:23 -  1.7
:+++ sysutils/telegraf/Makefile 7 May 2020 11:09:14 -
:@@ -3,6 +3,7 @@
: COMMENT = plugin-driven server agent for collecting metrics
: 
: BROKEN-i386 = build fails, no error message
:+BROKEN-arm =  build fails, no error message
: 
: GH_ACCOUNT =  influxdata
: GH_PROJECT =  telegraf
:Index: devel/srecord/Makefile
:===
:RC

Re: lang/rust: datasize limit is too low

2020-05-07 Thread Stuart Henderson
On 2020/05/07 10:50, Groot wrote:
> I tried installing rust through ports, but couldn't
> 
> ===>  Configuring for rust-1.42.0
> Using /usr/portsdir/pobj/rust-1.42.0/config.site (generated)
> datasize limit is too low - amd64 build takes approx 4GB
> *** Error 1 in /usr/ports/lang/rust (Makefile:152 'pre-configure': @if [
> `ulimit -d` -lt 3145728 ]; then  echo datasize limit is too low - a...)
> 
> I should mention that I tried setting `ulimit -d unlimited` as 
> root user, but seems that it's doesn't affect the defaults of normal
> user much. Since I set PORTS_PRIVSEP in `mk.conf`, _pbuild in my opinion
> is the user we are talking about.
> 
> After setting `ulimit -d unlimited` as root, the unprivileged user 
> gets a hard limit of 786433. As root user of course there is more than
> enough memory. So is there a way out?
> 

If you are using sudo rather than doas, set "Defaults use_loginclass" in 
sudoers.



Re: arm bulk build report

2020-05-07 Thread Stuart Henderson
On 2020/05/06 23:15, phess...@openbsd.org wrote:
> build failures: 58

Looking at the failures we can save ~40h of build time of armv7 if we
set BROKEN/NOT_FOR_ARCHS on just the slowest ones. Worth at least applying
locally on armv7 machines for now I think if not actually committing.

Index: textproc/podofo/Makefile
===
RCS file: /cvs/ports/textproc/podofo/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- textproc/podofo/Makefile3 Feb 2020 20:40:41 -   1.13
+++ textproc/podofo/Makefile7 May 2020 11:09:14 -
@@ -1,5 +1,7 @@
 # $OpenBSD: Makefile,v 1.13 2020/02/03 20:40:41 sthen Exp $
 
+BROKEN-arm=build stuck in main.cpp
+
 COMMENT=   library and tools to modify and parse PDF documents
 
 DISTNAME=  podofo-0.9.5
Index: math/mlpack/Makefile
===
RCS file: /cvs/ports/math/mlpack/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- math/mlpack/Makefile27 Feb 2020 18:15:25 -  1.14
+++ math/mlpack/Makefile7 May 2020 11:09:14 -
@@ -1,5 +1,6 @@
 # $OpenBSD: Makefile,v 1.14 2020/02/27 18:15:25 bket Exp $
 
+BROKEN-arm =   llvm out of memory
 BROKEN-powerpc = virtual memory exhausted, even with -O1
 
 COMMENT-main =  C++ machine learning library
Index: devel/arm-none-eabi/gcc-linaro/Makefile
===
RCS file: /cvs/ports/devel/arm-none-eabi/gcc-linaro/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- devel/arm-none-eabi/gcc-linaro/Makefile 28 Sep 2019 00:29:11 -  
1.16
+++ devel/arm-none-eabi/gcc-linaro/Makefile 7 May 2020 11:09:14 -
@@ -1,5 +1,6 @@
 # $OpenBSD: Makefile,v 1.16 2019/09/28 00:29:11 jsg Exp $
 
+BROKEN-arm=ICE: Bus error in unwind-dw2.c
 BROKEN-powerpc=libgcc/libgcc2.c:1999:1: internal compiler error: in 
create_edge, at cgraph.c:850
 
 COMMENT=   gcc for ${CONFIG} cross-development, Linaro version
Index: www/webkitgtk4/Makefile
===
RCS file: /cvs/ports/www/webkitgtk4/Makefile,v
retrieving revision 1.120
diff -u -p -r1.120 Makefile
--- www/webkitgtk4/Makefile 25 Apr 2020 20:04:50 -  1.120
+++ www/webkitgtk4/Makefile 7 May 2020 11:09:14 -
@@ -7,6 +7,7 @@ USE_WXNEEDED =  Yes
 
 BROKEN-alpha = GCC 5.0.0 is required to build WebKitGTK+, use a newer 
GCC version or clang
 BROKEN-hppa =  GCC 5.0.0 is required to build WebKitGTK+, use a newer 
GCC version or clang
+BROKEN-arm =   JavaScriptCore/runtime/MachineContext.h, various 
sigcontext-related
 
 PORTROACH =limitw:1,even
 
Index: devel/xtensa-lx106-elf/gdb/Makefile
===
RCS file: /cvs/ports/devel/xtensa-lx106-elf/gdb/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- devel/xtensa-lx106-elf/gdb/Makefile 23 Mar 2020 14:12:31 -  1.3
+++ devel/xtensa-lx106-elf/gdb/Makefile 7 May 2020 11:09:14 -
@@ -1,5 +1,7 @@
 # $OpenBSD: Makefile,v 1.3 2020/03/23 14:12:31 tracey Exp $
 
+BROKEN-arm =   can't create dynamic relocation R_ARM_ABS32 against local 
symbol in readonly segment
+
 COMMENT =  gdb for ${CONFIG} cross-development
 
 VERSION =  8.2.1
Index: geo/geos/Makefile
===
RCS file: /cvs/ports/geo/geos/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- geo/geos/Makefile   11 Mar 2020 15:35:58 -  1.30
+++ geo/geos/Makefile   7 May 2020 11:09:14 -
@@ -1,6 +1,8 @@
 # $OpenBSD: Makefile,v 1.30 2020/03/11 15:35:58 landry Exp $
 
 BROKEN-hppa =  undefined reference to 
'std::auto_ptr::~auto_ptr()'
+BROKEN-arm =   ld: error: duplicate symbol: typeinfo for 
geos::noding::BasicSegmentString
+
 COMMENT=   2d geometry and topology engine
 DISTNAME=  geos-3.8.1
 CATEGORIES=geo
Index: sysutils/telegraf/Makefile
===
RCS file: /cvs/ports/sysutils/telegraf/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- sysutils/telegraf/Makefile  12 Nov 2019 22:31:23 -  1.7
+++ sysutils/telegraf/Makefile  7 May 2020 11:09:14 -
@@ -3,6 +3,7 @@
 COMMENT =  plugin-driven server agent for collecting metrics
 
 BROKEN-i386 =  build fails, no error message
+BROKEN-arm =   build fails, no error message
 
 GH_ACCOUNT =   influxdata
 GH_PROJECT =   telegraf
Index: devel/srecord/Makefile
===
RCS file: /cvs/ports/devel/srecord/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- devel/srecord/Makefile  12 Jul 2019 20:46:02 -  1.15
+++ devel/srecord/Makefile  7 May 2020 11:09:14 -
@@ -1,5 +1,7 @@
 # $OpenBSD: Makefile,v 1.15 2019/07/12 20:46:02 sthen Exp $
 
+BROKEN-a

sparc64 bulk build report

2020-05-07 Thread kmos
Bulk build on sparc64-0.ports.openbsd.org

Started : Mon May  4 12:27:11 MDT 2020
Finished: Thu May  7 01:08:16 MDT 2020
Duration: 2 Days 12 hours 41 minutes

Built using OpenBSD 6.7-beta (GENERIC.MP) #305: Sun May  3 17:18:21 MDT 2020

Built 9923 packages

Number of packages built each day:
May 4: 6908
May 5: 2154
May 6: 857
May 7: 4



Critical path missing pkgs:
http://build-failures.rhaalovely.net/sparc64/2020-05-04/summary.log

Build failures: 6
http://build-failures.rhaalovely.net/sparc64/2020-05-04/graphics/birdfont.log
http://build-failures.rhaalovely.net/sparc64/2020-05-04/graphics/libavif.log
http://build-failures.rhaalovely.net/sparc64/2020-05-04/lang/hashlink.log
http://build-failures.rhaalovely.net/sparc64/2020-05-04/productivity/gnucash.log
http://build-failures.rhaalovely.net/sparc64/2020-05-04/x11/gnome/builder.log
http://build-failures.rhaalovely.net/sparc64/2020-05-04/x11/gtk+4,-cloudprint.log

Recurrent failures:
 failures/x11/gnome/builder.log
 failures/x11/gtk+4,-cloudprint.log

New failures:

Resolved failures:
-failures/x11/py-qt5,python3.log

Packages newly built:
+audio/picard
+benchmarks/netperf-wrapper,-gui
+devel/git-cola
+devel/spyder/spyder,python3
+editors/py-qscintilla
+editors/py-qscintilla,-common
+editors/py-qscintilla,-main
+editors/py-qscintilla,python3
+editors/py-qscintilla,python3,-common
+editors/py-qscintilla,python3,-main
+math/veusz
+net/onionshare,-gui
+print/hplip,-gui
+shells/py-qtconsole,python3
+textproc/calibre
+x11/kde-applications/kajongg
+x11/nagstamon
+x11/py-qt5
+x11/py-qt5,python3

Packages not built this time: