powerpc64 system-clang-8 based context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/li

2019-05-23 Thread Mark Millard via freebsd-ports
[I adjusted the Subject line to give more context.] [/usr/local/lib/qt5/bin/qlalr and /usr/local/lib/qt5/libQt5Core.so.5 overall use each of the following (somewhat indirectly) in my system-clang-8-based powerpc64 context: /usr/local/lib/gcc8/libstdc++.so.6 /usr/lib/libc++.so.1 /lib/libcxxrt.so.1

Re: powerpc64 context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/lib/gcc8/libstdc++.

2019-05-23 Thread Mark Millard via freebsd-ports
[Merely adding the extra instruction was not the right idea for what the problem is.] On 2019-May-23, at 20:10, Mark Millard wrote: > [I tried rebuilding things based on a full-bootstrap > build of lang/gcc8 instead. It made no difference.] > > On 2019-May-23, at 14:17, Mark Millard wrote: >

Re: powerpc64 context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/lib/gcc8/libstdc++.

2019-05-23 Thread Mark Millard via freebsd-ports
[I tried rebuilding things based on a full-bootstrap build of lang/gcc8 instead. It made no difference.] On 2019-May-23, at 14:17, Mark Millard wrote: > [It looks like code generation missed a level of indirection > to me.] > >> On 2019-May-23, at 13:46, Mark Millard wrote: >> >> [I should

INDEX build failed for 11.x

2019-05-23 Thread Ports Index build
INDEX build failed with errors: Generating INDEX-11 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- ---

INDEX build failed for 11.x

2019-05-23 Thread Ports Index build
INDEX build failed with errors: Generating INDEX-11 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- ---

Re: powerpc64 context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/lib/gcc8/libstdc++.

2019-05-23 Thread Mark Millard via freebsd-ports
[It looks like code generation missed a level of indirection to me.] > On 2019-May-23, at 13:46, Mark Millard wrote: > > [I should have listed uname -apKU output and such.] > > On 2019-May-23, at 13:21, Mark Millard wrote: > >> The poudriere bulk run that tried to build

INDEX build failed for 11.x

2019-05-23 Thread Ports Index build
INDEX build failed with errors: Generating INDEX-11 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- ---

Re: powerpc64 context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/lib/gcc8/libstdc++.

2019-05-23 Thread Mark Millard via freebsd-ports
[I should have listed uname -apKU output and such.] On 2019-May-23, at 13:21, Mark Millard wrote: > The poudriere bulk run that tried to build x11-toolkits/qt5-declarative > got: > > --- qqmljsgrammar.cpp --- > /usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g > Segmentation fault

powerpc64 context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/local/lib/gcc8/libstdc++.so.6

2019-05-23 Thread Mark Millard via freebsd-ports
The poudriere bulk run that tried to build x11-toolkits/qt5-declarative got: --- qqmljsgrammar.cpp --- /usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g Segmentation fault (core dumped) *** [qqmljsgrammar.cpp] Error code 139 make[3]: stopped in

Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"

2019-05-23 Thread Mark Millard via freebsd-ports
On 2019-May-23, at 11:47, Jan Beich wrote: > Mark Millard writes: > >> Unfortunately poudiere bulk tar archives of failures do not >> catch the /tmp/* material from: >> >> cc: error: unable to execute command: Abort trap (core dumped) >> cc: error: clang frontend command failed due to signal

Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"

2019-05-23 Thread Mark Millard via freebsd-ports
[Just sending to toolchain and powerpc lists as well. Somehow I missed listing them the first time I sent this out.] On 2019-May-23, at 11:20, Mark Millard wrote: > From a poudriere bulk build in a powerpc64 context (old PowerMac) > that was built with and uses system clang 8 and base/binutils

Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"

2019-05-23 Thread Jan Beich
Mark Millard writes: > Unfortunately poudiere bulk tar archives of failures do not > catch the /tmp/* material from: > > cc: error: unable to execute command: Abort trap (core dumped) > cc: error: clang frontend command failed due to signal (use -v to see > invocation) > FreeBSD clang version

powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"

2019-05-23 Thread Mark Millard via freebsd-ports
>From a poudriere bulk build in a powerpc64 context (old PowerMac) that was built with and uses system clang 8 and base/binutils instead of the gcc 4.2.1 toolchain. I got: [09:05:56] [04] [00:14:42] Saved graphics/mesa-dri | mesa-dri-18.3.2_2 wrkdir to:

Re: Dovecot packages

2019-05-23 Thread Larry Rosenman
On 05/23/2019 10:03 am, Doug Hardie wrote: Correct. There is no port tree. Packages are used exclusively pkg(8) doesn't handle the MOVED file. Therefore, the pkg delete/pkg add is the correct answer. Whether it should is out of my control. Larry Rosenman mail/dovecot{,-pigeonhole}

Re: Dovecot packages

2019-05-23 Thread Doug Hardie
Correct. There is no port tree. Packages are used exclusively > On May 23, 2019, at 01:16, @lbutlr wrote: > >> On 22 May 2019, at 16:41, Doug Hardie wrote: >> It appears that the dovecot package is now the one that is maintained and >> dovecot2 package has remained stagnant. > > You

security/gnupg

2019-05-23 Thread
FreeBSD 11.2-RELEASE-p10 libiconv-1.14_11 Character set conversion library is installed. gnupg fails to build: *** *** The system does not provide a working iconv function. Please *** install a suitable library; for example GNU Libiconv which is *** available at: ***

Re: Dovecot packages

2019-05-23 Thread @lbutlr
On 22 May 2019, at 16:41, Doug Hardie wrote: > It appears that the dovecot package is now the one that is maintained and > dovecot2 package has remained stagnant. You didn't replace your port tree when you upgraded to 12.0-RELEASE. I think that portsnap fetch extract ensures your ports tree

FreeBSD ports you maintain which are out of date

2019-05-23 Thread portscout
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated,

Re: problem with bind911 or 914

2019-05-23 Thread Wojciech Puchar
Looks to me like either a firewall or policy issue, not BIND. Back a decade ago, many firewalls defaulted to blocking tcp/53. This was based on the unfortunate decision to list the use of tcp/53 as "SHOULD" in the RFC instead of "MUST", but this should produce a timeout,not a host unreachable.