Re: x11/qt5/qtwebengine on arm64 (was: Re: aarch64 bulk build report)

[Peter Hessler]

On 2024 Aug 04 (Sun) at 21:13:07 +0200 (+0200), Jeremie Courreges-Anglas wrote:
:Still left to fix: x11/qt5/qtwebengine.  Here's a diff that drops the
:sys/auxv.h & getauxval code that breaks on arm64 (already dropped in
:upstream Skia).  Comment snagged from Landry's commit.
:
:ok?
:

OK

:
:Index: patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
:===
:RCS file: 
patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
:diff -N patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
:--- /dev/null  1 Jan 1970 00:00:00 -
:+++ patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
4 Aug 2024 18:56:41 -
:@@ -0,0 +1,88 @@
:+drop cpu features detection, as done in upstream skia in
:+https://github.com/google/skia/commit/571b4cf2e35930f6744181b73b72939ab236f3ea
:+
:+fixes build since elf_aux_info/auxv.h addition
:+
:+Index: src/3rdparty/chromium/third_party/skia/src/core/SkCpu.cpp
:+--- src/3rdparty/chromium/third_party/skia/src/core/SkCpu.cpp.orig
: src/3rdparty/chromium/third_party/skia/src/core/SkCpu.cpp
:+@@ -72,79 +72,6 @@
:+ return features;
:+ }
:+ 
:+-#elif defined(SK_CPU_ARM64) && __has_include()
:+-#include 
:+-
:+-static uint32_t read_cpu_features() {
:+-const uint32_t kHWCAP_CRC32   = (1<< 7),
:+-   kHWCAP_ASIMDHP = (1<<10);
:+-
:+-uint32_t features = 0;
:+-uint32_t hwcaps = getauxval(AT_HWCAP);
:+-if (hwcaps & kHWCAP_CRC32  ) { features |= SkCpu::CRC32; }
:+-if (hwcaps & kHWCAP_ASIMDHP) { features |= SkCpu::ASIMDHP; }
:+-
:+-// The Samsung Mongoose 3 core sets the ASIMDHP bit but doesn't 
support it.
:+-for (int core = 0; features & SkCpu::ASIMDHP; core++) {
:+-// These /sys files contain the core's MIDR_EL1 register, the 
source of
:+-// CPU {implementer, variant, part, revision} you'd see in 
/proc/cpuinfo.
:+-SkString path =
:+-
SkStringPrintf("/sys/devices/system/cpu/cpu%d/regs/identification/midr_el1", 
core);
:+-
:+-// Can't use SkData::MakeFromFileName() here, I think because 
/sys can't be mmap()'d.
:+-SkFILEStream midr_el1(path.c_str());
:+-if (!midr_el1.isValid()) {
:+-// This is our ordinary exit path.
:+-// If we ask for MIDR_EL1 from a core that doesn't exist, 
we've checked all cores.
:+-if (core == 0) {
:+-// On the other hand, if we can't read MIDR_EL1 from any 
core, assume the worst.
:+-features &= ~(SkCpu::ASIMDHP);
:+-}
:+-break;
:+-}
:+-
:+-const char kMongoose3[] = "0x531f0020";  // 53 == 
Samsung.
:+-char buf[SK_ARRAY_COUNT(kMongoose3) - 1];  // No need for the 
terminating \0.
:+-
:+-if (SK_ARRAY_COUNT(buf) != midr_el1.read(buf, 
SK_ARRAY_COUNT(buf))
:+-  || 0 == memcmp(kMongoose3, buf, 
SK_ARRAY_COUNT(buf))) {
:+-features &= ~(SkCpu::ASIMDHP);
:+-}
:+-}
:+-return features;
:+-}
:+-
:+-#elif defined(SK_CPU_ARM32) && __has_include() && \
:+-(!defined(__ANDROID_API__) || __ANDROID_API__ >= 18)
:+-// sys/auxv.h will always be present in the Android NDK due to unified
:+-//headers, but getauxval is only defined for API >= 18.
:+-#include 
:+-
:+-static uint32_t read_cpu_features() {
:+-const uint32_t kHWCAP_NEON  = (1<<12);
:+-const uint32_t kHWCAP_VFPv4 = (1<<16);
:+-
:+-uint32_t features = 0;
:+-uint32_t hwcaps = getauxval(AT_HWCAP);
:+-if (hwcaps & kHWCAP_NEON ) {
:+-features |= SkCpu::NEON;
:+-if (hwcaps & kHWCAP_VFPv4) { features |= 
SkCpu::NEON_FMA|SkCpu::VFP_FP16; }
:+-}
:+-return features;
:+-}
:+-
:+-#elif defined(SK_CPU_ARM32) && __has_include()
:+-#include 
:+-
:+-static uint32_t read_cpu_features() {
:+-uint32_t features = 0;
:+-uint64_t cpu_features = android_getCpuFeatures();
:+-if (cpu_features & ANDROID_CPU_ARM_FEATURE_NEON) { features |= 
SkCpu::NEON; }
:+-if (cpu_features & ANDROID_CPU_ARM_FEATURE_NEON_FMA) { features |= 
SkCpu::NEON_FMA; }
:+-if (cpu_features & ANDROID_CPU_ARM_FEATURE_VFP_FP16) { features |= 
SkCpu::VFP_FP16; }
:+-return features;
:+-}
:+-
:+ #else
:+ static uint32_t read_cpu_features() {
:+ return 0;
:
:
:-- 
:jca

-- 
Calling J-Man Kink.  Calling J-Man Kink.  Hash missile sighted, target
Los Angeles.  Disregard personal feelings about city and intercept.

x11/qt5/qtwebengine on arm64 (was: Re: aarch64 bulk build report)

[Jeremie Courreges-Anglas]

On Mon, Jul 22, 2024 at 12:19:28AM +0200, Jeremie Courreges-Anglas wrote:
> On Sat, Jul 20, 2024 at 10:50:30AM +0200, Landry Breuil wrote:
> > Le Fri, Jul 19, 2024 at 10:45:18AM +0200, Landry Breuil a écrit :
> > > Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit :
> > > > On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org 
> > > > wrote:
> > > > :critical path missing pkgs:  
> > > > http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log
> > > > 
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log
> > > > 
> > > > the above 4 ports fail related to hwcap in the same way:
> > > > 
> > > > /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
> > > > error: use of undeclared identifier 'getauxval'
> > > > uint32_t hwcaps = getauxval(AT_HWCAP);
> > > 
> > > https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76
> > > for the surrounding code, i guess it now finds a sys/auxv.h header ?
> 
> That would make sense.  Looking at the www/mozilla-firefox copy of
> skia, this chunk of code appears to have disappeared from SkCpu.cpp.
> 
>   
> https://github.com/google/skia/commit/571b4cf2e35930f6744181b73b72939ab236f3ea

Still left to fix: x11/qt5/qtwebengine.  Here's a diff that drops the
sys/auxv.h & getauxval code that breaks on arm64 (already dropped in
upstream Skia).  Comment snagged from Landry's commit.

ok?


Index: patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
===
RCS file: 
patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
diff -N patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_3rdparty_chromium_third_party_skia_src_core_SkCpu_cpp 
4 Aug 2024 18:56:41 -
@@ -0,0 +1,88 @@
+drop cpu features detection, as done in upstream skia in
+https://github.com/google/skia/commit/571b4cf2e35930f6744181b73b72939ab236f3ea
+
+fixes build since elf_aux_info/auxv.h addition
+
+Index: src/3rdparty/chromium/third_party/skia/src/core/SkCpu.cpp
+--- src/3rdparty/chromium/third_party/skia/src/core/SkCpu.cpp.orig
 src/3rdparty/chromium/third_party/skia/src/core/SkCpu.cpp
+@@ -72,79 +72,6 @@
+ return features;
+ }
+ 
+-#elif defined(SK_CPU_ARM64) && __has_include()
+-#include 
+-
+-static uint32_t read_cpu_features() {
+-const uint32_t kHWCAP_CRC32   = (1<< 7),
+-   kHWCAP_ASIMDHP = (1<<10);
+-
+-uint32_t features = 0;
+-uint32_t hwcaps = getauxval(AT_HWCAP);
+-if (hwcaps & kHWCAP_CRC32  ) { features |= SkCpu::CRC32; }
+-if (hwcaps & kHWCAP_ASIMDHP) { features |= SkCpu::ASIMDHP; }
+-
+-// The Samsung Mongoose 3 core sets the ASIMDHP bit but doesn't 
support it.
+-for (int core = 0; features & SkCpu::ASIMDHP; core++) {
+-// These /sys files contain the core's MIDR_EL1 register, the 
source of
+-// CPU {implementer, variant, part, revision} you'd see in 
/proc/cpuinfo.
+-SkString path =
+-
SkStringPrintf("/sys/devices/system/cpu/cpu%d/regs/identification/midr_el1", 
core);
+-
+-// Can't use SkData::MakeFromFileName() here, I think because 
/sys can't be mmap()'d.
+-SkFILEStream midr_el1(path.c_str());
+-if (!midr_el1.isValid()) {
+-// This is our ordinary exit path.
+-// If we ask for MIDR_EL1 from a core that doesn't exist, 
we've checked all cores.
+-if (core == 0) {
+-// On the other hand, if we can't read MIDR_EL1 from any 
core, assume the worst.
+-features &= ~(SkCpu::ASIMDHP);
+-}
+-break;
+-}
+-
+-const char kMongoose3[] = "0x531f0020";  // 53 == Samsung.
+-char buf[SK_ARRAY_COUNT(kMongoose3) - 1];  // No need for the 
terminating \0.
+-
+-if (SK_ARRAY_COUNT(buf) != midr_el1.read(buf, SK_ARRAY_COUNT(buf))
+-  || 0 == memcmp(kMongoose3, buf, 
SK_ARRAY_COUNT(buf))) {
+-features &= ~(SkCpu::ASIMDHP);
+-}
+-}
+-return features;
+-}
+-
+-#elif defined(SK_CPU_ARM32) && __has_include() && \
+-(!defined(__ANDROID_API__) || __ANDROID_API__ >= 18)
+-// sys/auxv.h will always be present in the Android NDK due to unified
+-//headers, but getauxval is only defined for API >= 18.
+-#include 
+-
+-static uint32_t read_cpu_features() {
+-const uint32_t kHWCAP_NEON 

Re: aarch64 bulk build report

[Peter Hessler]

On 2024 Jul 26 (Fri) at 05:51:24 +0200 (+0200), Theo Buehler wrote:
:On Fri, Jul 19, 2024 at 10:54:03AM +0100, Stuart Henderson wrote:
:> On 2024/07/19 08:49, Peter Hessler wrote:
:> > 
:http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/py-wxPython,python3.log
:> > 
:> > wx/svg/_nanosvg.pyx:45:8: 'cython.object' is not a valid cython.* module
:> 
:> No time to look right now but I suspect this may be a hidden build dep,
:> i.e. cython picked up and then junked by dpb.
:
:While there is a tiny window where junking could break the _nanosvg build
:this breakage isn't the result of junking. The port simply fails to build
:if cython is installed.
:
:Here's one workaround, but perhaps there are better ideas?
:

Looks good to me, OK


:Index: patches/patch-setup-wxsvg_py
:===
:RCS file: patches/patch-setup-wxsvg_py
:diff -N patches/patch-setup-wxsvg_py
:--- /dev/null  1 Jan 1970 00:00:00 -
:+++ patches/patch-setup-wxsvg_py   26 Jul 2024 03:35:31 -
:@@ -0,0 +1,14 @@
:+Unbreak build if py3-cython is installed
:+
:+Index: setup-wxsvg.py
:+--- setup-wxsvg.py.orig
: setup-wxsvg.py
:+@@ -15,7 +15,7 @@ import textwrap
:+ from setuptools import setup, Extension
:+ try:
:+ from Cython.Build import cythonize
:+-have_cython = True
:++have_cython = False
:+ except ImportError:
:+ have_cython = False
:+ 
:

-- 
Beware of the Turing Tar-pit in which everything is possible but
nothing of interest is easy.

Re: aarch64 bulk build report

[Theo Buehler]

On Fri, Jul 19, 2024 at 10:54:03AM +0100, Stuart Henderson wrote:
> On 2024/07/19 08:49, Peter Hessler wrote:
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/py-wxPython,python3.log
> > 
> > wx/svg/_nanosvg.pyx:45:8: 'cython.object' is not a valid cython.* module
> 
> No time to look right now but I suspect this may be a hidden build dep,
> i.e. cython picked up and then junked by dpb.

While there is a tiny window where junking could break the _nanosvg build
this breakage isn't the result of junking. The port simply fails to build
if cython is installed.

Here's one workaround, but perhaps there are better ideas?

Index: patches/patch-setup-wxsvg_py
===
RCS file: patches/patch-setup-wxsvg_py
diff -N patches/patch-setup-wxsvg_py
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-setup-wxsvg_py26 Jul 2024 03:35:31 -
@@ -0,0 +1,14 @@
+Unbreak build if py3-cython is installed
+
+Index: setup-wxsvg.py
+--- setup-wxsvg.py.orig
 setup-wxsvg.py
+@@ -15,7 +15,7 @@ import textwrap
+ from setuptools import setup, Extension
+ try:
+ from Cython.Build import cythonize
+-have_cython = True
++have_cython = False
+ except ImportError:
+ have_cython = False
+ 

Re: elf_aux_info in the mozillas on arm64 (was: Re: aarch64 bulk build report)

[Theo de Raadt]

Mark Kettenis  wrote:

> In general I'd say shared objects should always be linked against
> libc.  But Theo will probably never agree with me.

Let's be accurate what this means.

It does not mean linking about libc.

It means encoding a specific libc.so.#.# as DT_NEEDED, which will cause
us complete garbage later on

Or maybe it means having /usr/lib/libc.so symbolic links?

All that kinds of stuff makes me just want to give up.  Maybe we
need to head the way of Linux, where ABI changes are not allowed.
Because they would become impossible, as they are in Linux.  (Please
don't tell me what Linux can "still add things to their ABI".  They
actually can't, without hundreds of hours of study, half the time
they try to add something, it shows they need to change something or
remove something else that isn't allowed by their stupid rules)

Locking us to names, or to files, or to symbolic links, is a non-starter.
It was never part of the design.  It's just that some stupid people
made bad unnecessary decisions.





This is a lot like the X va import, btw.  Unintended consequences
were not discovered ahead of time.  I'm not complaining, I'm just
saying 'cloning a compatible interface' often goes wrong.

Re: elf_aux_info in the mozillas on arm64 (was: Re: aarch64 bulk build report)

[Mark Kettenis]

> Date: Mon, 22 Jul 2024 00:19:28 +0200
> From: Jeremie Courreges-Anglas 
> 
> On Sat, Jul 20, 2024 at 10:50:30AM +0200, Landry Breuil wrote:
> > Le Fri, Jul 19, 2024 at 10:45:18AM +0200, Landry Breuil a écrit :
> > > Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit :
> > > > On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org 
> > > > wrote:
> > > > :critical path missing pkgs:  
> > > > http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log
> > > > 
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
> > > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log
> > > > 
> > > > the above 4 ports fail related to hwcap in the same way:
> > > > 
> > > > /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
> > > > error: use of undeclared identifier 'getauxval'
> > > > uint32_t hwcaps = getauxval(AT_HWCAP);
> > > 
> > > https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76
> > > for the surrounding code, i guess it now finds a sys/auxv.h header ?
> 
> That would make sense.  Looking at the www/mozilla-firefox copy of
> skia, this chunk of code appears to have disappeared from SkCpu.cpp.
> 
>   
> https://github.com/google/skia/commit/571b4cf2e35930f6744181b73b72939ab236f3ea
> 
> The addition of elf_aux_info(3) was intended to make it easier for
> external software to use optimizations, but maybe for these ports it
> would be just easier to patch out feature detection?  ;)
> 
> > the below patch goes past this build failure, but libipcclientcerts.so
> > doesn't link with lld:
> > 
> > rm -f libipcclientcerts.so.10.0 
> > 
> >
> > /usr/obj/ports/firefox-esr-115.13.0/bin/cc -std=gnu99 -U_FORTIFY_SOURCE 
> > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wno-backend-plugin -O2 -pipe 
> > -g -fPIC -ffunction-sections -fdata-sections  -fno-math-errno -pthread 
> > -pipe -gdwarf-4 -O2 -pipe -g -fomit-frame-pointer -funwind-tables 
> > -fprofile-use=/usr/obj/ports/firefox-esr-115.13.0/merged.profdata 
> > -Wno-error=backend-plugin -shared -fPIC -Wl,--gc-sections 
> > -Wl,-h,libipcclientcerts.so.10.0 -o libipcclientcerts.so.10.0 stub.o  
> > -flto=thin -Wl,-plugin-opt=-import-instr-limit=10 
> > -Wl,-plugin-opt=-import-hot-multiplier=30 -pthread -Wl,--threads=8 
> > -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc 
> > -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -fstack-protector-strong 
> > -Wl,-rpath-link,/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/dist/bin 
> > -Wl,-rpath-link,/usr/local/lib -Wl,-rpath-link,/usr/X11R6/lib  
> > /usr/obj/ports/firefox-esr-115.13.0/build-aarch64/aarch64-unknown-openbsd/release/libipcclientcerts_static.a
> >   -Wl,--version-script,libipcclientcerts.so.10.0.symbols
> > /usr/obj/ports/firefox-esr-115.13.0/build-aarch64/_virtualenvs/build/bin/python
> >  -m mozbuild.action.check_binary --target libipcclientcerts.so.10.0 
> > BUILDTASK {"argv": 
> > ["/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/python/mozbuild/mozbuild/action/check_binary.py",
> >  "--target", "libipcclientcerts.so.10.0"], "start": 12452.418140014,
> >  "end": 12452.543060385, "context": null}  
> > chmod +x libipcclientcerts.so.10.0 
> > ../../../../../config/nsinstall -R -m 644 'libipcclientcerts.so.10.0' 
> > '../../../../../dist/bin'
> > gmake[3]: Leaving directory 
> > '/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/security/manager/ssl/ipcclientcerts/dynamic-library'
> >  
> > ld.lld: error: undefined hidden symbol: elf_aux_info   
> > >>> referenced by SkCpu.cpp:85 
> > >>> (/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:85)
> > >>> 
> > >>>   lto.tmp:(SkCpu::CacheRuntimeFeatures()) 
> > clang-16: error: linker command failed with exit code 1 (use -v to see 
> > invocation)  i
> > 
> > i dunno which of the -Wl flags triggers this, but the elf_aux_info symbol is
> > present as a weak symbol in libc.so.100.2, but i see that it doesnt 
> > explicitely
> > link with -lc - though maybe it shouldnt be required.
> 
> I think I have already seen this "global vs hidden" mismatch for weak
> symbols previously, but I don't remember the specifics.  Looking at
> the arm64 base sets, llvm-readelf -Wa libc.so.100.2 shows
> elf_aux_info(3) as a weak symbol with default (not hidden) visibility:
> 
>   1410: 0008c80c   224 FUNCWEAK   DEFAULT12 elf_aux_info
> 
> That looks correct to me.

Indeed.  This is no different from other exported symbols in libc that
ar

elf_aux_info in the mozillas on arm64 (was: Re: aarch64 bulk build report)

[Jeremie Courreges-Anglas]

On Sat, Jul 20, 2024 at 10:50:30AM +0200, Landry Breuil wrote:
> Le Fri, Jul 19, 2024 at 10:45:18AM +0200, Landry Breuil a écrit :
> > Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit :
> > > On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org 
> > > wrote:
> > > :critical path missing pkgs:  
> > > http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log
> > > 
> > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
> > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
> > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
> > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log
> > > 
> > > the above 4 ports fail related to hwcap in the same way:
> > > 
> > > /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
> > > error: use of undeclared identifier 'getauxval'
> > > uint32_t hwcaps = getauxval(AT_HWCAP);
> > 
> > https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76
> > for the surrounding code, i guess it now finds a sys/auxv.h header ?

That would make sense.  Looking at the www/mozilla-firefox copy of
skia, this chunk of code appears to have disappeared from SkCpu.cpp.

  https://github.com/google/skia/commit/571b4cf2e35930f6744181b73b72939ab236f3ea

The addition of elf_aux_info(3) was intended to make it easier for
external software to use optimizations, but maybe for these ports it
would be just easier to patch out feature detection?  ;)

> the below patch goes past this build failure, but libipcclientcerts.so
> doesn't link with lld:
> 
> rm -f libipcclientcerts.so.10.0   
>   
>/usr/obj/ports/firefox-esr-115.13.0/bin/cc 
> -std=gnu99 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
> -Wno-backend-plugin -O2 -pipe -g -fPIC -ffunction-sections -fdata-sections  
> -fno-math-errno -pthread -pipe -gdwarf-4 -O2 -pipe -g -fomit-frame-pointer 
> -funwind-tables 
> -fprofile-use=/usr/obj/ports/firefox-esr-115.13.0/merged.profdata 
> -Wno-error=backend-plugin -shared -fPIC -Wl,--gc-sections 
> -Wl,-h,libipcclientcerts.so.10.0 -o libipcclientcerts.so.10.0 stub.o  
> -flto=thin -Wl,-plugin-opt=-import-instr-limit=10 
> -Wl,-plugin-opt=-import-hot-multiplier=30 -pthread -Wl,--threads=8 
> -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc 
> -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -fstack-protector-strong 
> -Wl,-rpath-link,/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/dist/bin 
> -Wl,-rpath-link,/usr/local/lib -Wl,-rpath-link,/usr/X11R6/lib  
> /usr/obj/ports/firefox-esr-115.13.0/build-aarch64/aarch64-unknown-openbsd/release/libipcclientcerts_static.a
>   -Wl,--version-script,libipcclientcerts.so.10.0.symbols
> /usr/obj/ports/firefox-esr-115.13.0/build-aarch64/_virtualenvs/build/bin/python
>  -m mozbuild.action.check_binary --target libipcclientcerts.so.10.0 
> BUILDTASK {"argv": 
> ["/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/python/mozbuild/mozbuild/action/check_binary.py",
>  "--target", "libipcclientcerts.so.10.0"], "start": 12452.418140014,
>  "end": 12452.543060385, "context": null}  
> chmod +x libipcclientcerts.so.10.0 
> ../../../../../config/nsinstall -R -m 644 'libipcclientcerts.so.10.0' 
> '../../../../../dist/bin'
> gmake[3]: Leaving directory 
> '/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/security/manager/ssl/ipcclientcerts/dynamic-library'
>  
> ld.lld: error: undefined hidden symbol: elf_aux_info   
> >>> referenced by SkCpu.cpp:85 
> >>> (/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:85)
> >>> 
> >>>   lto.tmp:(SkCpu::CacheRuntimeFeatures()) 
> clang-16: error: linker command failed with exit code 1 (use -v to see 
> invocation)  i
> 
> i dunno which of the -Wl flags triggers this, but the elf_aux_info symbol is
> present as a weak symbol in libc.so.100.2, but i see that it doesnt 
> explicitely
> link with -lc - though maybe it shouldnt be required.

I think I have already seen this "global vs hidden" mismatch for weak
symbols previously, but I don't remember the specifics.  Looking at
the arm64 base sets, llvm-readelf -Wa libc.so.100.2 shows
elf_aux_info(3) as a weak symbol with default (not hidden) visibility:

  1410: 0008c80c   224 FUNCWEAK   DEFAULT12 elf_aux_info

That looks correct to me.

I suspect the error message means there's another elf_aux_info()
definition in your build, but with hidden visibility; but I couldn't
find one in the firefox-esr tarball and I could very well be mistaken.

cc'ing the usual ELFs, maybe they'll have some clues.

> $cat patches/patch-gfx_skia_skia_src_core_SkCpu_cpp
> Fix bu

Re: aarch64 bulk build report

[Landry Breuil]

Le Fri, Jul 19, 2024 at 10:45:18AM +0200, Landry Breuil a écrit :
> Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit :
> > On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org wrote:
> > :critical path missing pkgs:  
> > http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log
> > 
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log
> > 
> > the above 4 ports fail related to hwcap in the same way:
> > 
> > /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
> > error: use of undeclared identifier 'getauxval'
> > uint32_t hwcaps = getauxval(AT_HWCAP);
> 
> https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76
> for the surrounding code, i guess it now finds a sys/auxv.h header ?

the below patch goes past this build failure, but libipcclientcerts.so
doesn't link with lld:

rm -f libipcclientcerts.so.10.0 

   /usr/obj/ports/firefox-esr-115.13.0/bin/cc 
-std=gnu99 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
-Wno-backend-plugin -O2 -pipe -g -fPIC -ffunction-sections -fdata-sections  
-fno-math-errno -pthread -pipe -gdwarf-4 -O2 -pipe -g -fomit-frame-pointer 
-funwind-tables 
-fprofile-use=/usr/obj/ports/firefox-esr-115.13.0/merged.profdata 
-Wno-error=backend-plugin -shared -fPIC -Wl,--gc-sections 
-Wl,-h,libipcclientcerts.so.10.0 -o libipcclientcerts.so.10.0 stub.o  
-flto=thin -Wl,-plugin-opt=-import-instr-limit=10 
-Wl,-plugin-opt=-import-hot-multiplier=30 -pthread -Wl,--threads=8 
-Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc 
-Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -fstack-protector-strong 
-Wl,-rpath-link,/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/dist/bin 
-Wl,-rpath-link,/usr/local/lib -Wl,-rpath-link,/usr/X11R6/lib  
/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/aarch64-unknown-openbsd/release/libipcclientcerts_static.a
  -Wl,--version-script,libipcclientcerts.so.10.0.symbols
/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/_virtualenvs/build/bin/python 
-m mozbuild.action.check_binary --target libipcclientcerts.so.10.0 
BUILDTASK {"argv": 
["/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/python/mozbuild/mozbuild/action/check_binary.py",
 "--target", "libipcclientcerts.so.10.0"], "start": 12452.418140014,
 "end": 12452.543060385, "context": null}  
chmod +x libipcclientcerts.so.10.0 
../../../../../config/nsinstall -R -m 644 'libipcclientcerts.so.10.0' 
'../../../../../dist/bin'
gmake[3]: Leaving directory 
'/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/security/manager/ssl/ipcclientcerts/dynamic-library'
 
ld.lld: error: undefined hidden symbol: elf_aux_info   
>>> referenced by SkCpu.cpp:85 
>>> (/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:85)
>>> 
>>>   lto.tmp:(SkCpu::CacheRuntimeFeatures()) 
clang-16: error: linker command failed with exit code 1 (use -v to see 
invocation)  i

i dunno which of the -Wl flags triggers this, but the elf_aux_info symbol is
present as a weak symbol in libc.so.100.2, but i see that it doesnt explicitely
link with -lc - though maybe it shouldnt be required.

$cat patches/patch-gfx_skia_skia_src_core_SkCpu_cpp
Fix build with auxv.h addition

Index: gfx/skia/skia/src/core/SkCpu.cpp
--- gfx/skia/skia/src/core/SkCpu.cpp.orig
+++ gfx/skia/skia/src/core/SkCpu.cpp
@@ -81,7 +81,8 @@
kHWCAP_ASIMDHP = (1<<10);
 
 uint32_t features = 0;
-uint32_t hwcaps = getauxval(AT_HWCAP);
+uint32_t hwcaps = 0;
+elf_aux_info(AT_HWCAP, &hwcaps, sizeof(hwcaps));
 if (hwcaps & kHWCAP_CRC32  ) { features |= SkCpu::CRC32; }
 if (hwcaps & kHWCAP_ASIMDHP) { features |= SkCpu::ASIMDHP; }

> 
> Landry
> 

Re: aarch64 bulk build report

[Stuart Henderson]

On 2024/07/19 08:49, Peter Hessler wrote:
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/py-wxPython,python3.log
> 
> wx/svg/_nanosvg.pyx:45:8: 'cython.object' is not a valid cython.* module

No time to look right now but I suspect this may be a hidden build dep,
i.e. cython picked up and then junked by dpb.

Re: aarch64 bulk build report

[Landry Breuil]

Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit :
> On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org wrote:
> :critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log
> 
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log
> 
> the above 4 ports fail related to hwcap in the same way:
> 
> /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
> error: use of undeclared identifier 'getauxval'
> uint32_t hwcaps = getauxval(AT_HWCAP);

https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76
for the surrounding code, i guess it now finds a sys/auxv.h header ?

Landry

Re: aarch64 bulk build report

[Theo Buehler]

> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/math/labplot.log
> 
> CMake Error at
> /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:233 
> (message):
>   Could NOT find KF6 (missing: NewStuffCore NewStuff) (found suitable version
>   "6.4.0", minimum required is "5.240.0")

rsadowski fixed this with the latest update

> 
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/plan9/plan9port.log
> 
> this port is wildly unstable on arm64, now it's just random errors?

I think it's about time to mark it broken.

> 
> 
> :http://build-failures.rhaalovely.net/aarch64/2024-07-16/security/stunnel.log
> 
> /usr/obj/ports/stunnel-5.64/stunnel-5.64/src/ctx.c:1578:31: error: use
> of undeclared identifier 'SSL23_ST_SR_CLNT_HELLO_A'

already  fixed.

Re: aarch64 bulk build report

[Peter Hessler]

On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log

:http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
:http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
:http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
:http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log

the above 4 ports fail related to hwcap in the same way:

/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
error: use of undeclared identifier 'getauxval'
uint32_t hwcaps = getauxval(AT_HWCAP);
  ^

:http://build-failures.rhaalovely.net/aarch64/2024-07-16/news/py-sabctools,python3.log

src/yencode/platform.cc:32:9: error: use of undeclared identifier 'getauxval'
return getauxval(AT_HWCAP) & HWCAP_ASIMD;


:http://build-failures.rhaalovely.net/aarch64/2024-07-16/security/aircrack-ng.log

also fallout from hwcap

lib/libac/cpu/simd_cpuid.c:38:10: fatal error: 'asm/hwcap.h' file not found
#include 


:http://build-failures.rhaalovely.net/aarch64/2024-07-16/math/labplot.log

CMake Error at
/usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:233 
(message):
  Could NOT find KF6 (missing: NewStuffCore NewStuff) (found suitable version
  "6.4.0", minimum required is "5.240.0")



:http://build-failures.rhaalovely.net/aarch64/2024-07-16/plan9/plan9port.log

this port is wildly unstable on arm64, now it's just random errors?


:http://build-failures.rhaalovely.net/aarch64/2024-07-16/security/stunnel.log

/usr/obj/ports/stunnel-5.64/stunnel-5.64/src/ctx.c:1578:31: error: use
of undeclared identifier 'SSL23_ST_SR_CLNT_HELLO_A'


:http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/py-wxPython,python3.log

wx/svg/_nanosvg.pyx:45:8: 'cython.object' is not a valid cython.* module



-- 
You are only young once, but you can stay immature indefinitely.

Re: aarch64 bulk build report

[Brian Callahan]

On 6/28/2024 12:32 PM, Jeremie Courreges-Anglas wrote:
> On Fri, Jun 28, 2024 at 04:04:44PM +, Brian Callahan wrote:
>> On 6/28/2024 8:35 AM, phess...@openbsd.org wrote:
>>> http://build-failures.rhaalovely.net/aarch64/2024-06-25/games/openrct2.log
>>
>> This one is probably because -Werror is turned on and it probably
>> shouldn't be. Diff attached.
>>
>> OK?
> 
> I consider -Werror as harmful in ports, ok jca@
> 

Thanks.

> That being said, it would be nice for someone who cares about this
> port to test it on arm64.
> 

Agreed. I'd do it myself, but I don't have any arm64 hardware at the
moment...

~Brian

Re: aarch64 bulk build report

[Jeremie Courreges-Anglas]

On Fri, Jun 28, 2024 at 04:04:44PM +, Brian Callahan wrote:
> On 6/28/2024 8:35 AM, phess...@openbsd.org wrote:
> > http://build-failures.rhaalovely.net/aarch64/2024-06-25/games/openrct2.log
> 
> This one is probably because -Werror is turned on and it probably
> shouldn't be. Diff attached.
> 
> OK?

I consider -Werror as harmful in ports, ok jca@

That being said, it would be nice for someone who cares about this
port to test it on arm64.

-- 
jca

Re: aarch64 bulk build report

[Brian Callahan]

On 6/28/2024 8:35 AM, phess...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/aarch64/2024-06-25/games/openrct2.log

This one is probably because -Werror is turned on and it probably
shouldn't be. Diff attached.

OK?

~Brian
Index: Makefile
===
RCS file: /cvs/ports/games/openrct2/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile29 May 2024 09:56:15 -  1.23
+++ Makefile28 Jun 2024 16:02:00 -
@@ -15,6 +15,7 @@ DISTFILES.c = opensfx-${OPENSFX_V}{open
 DISTFILES.d =  openmsx-${OPENMSX_V}{openmusic}.zip
 DISTFILES.e =  replays-${REPLAYS_V}{replays}.zip
 PKGNAME =  openrct2-${V}
+REVISION = 0
 CATEGORIES =   games x11
 
 HOMEPAGE = https://openrct2.org/
Index: patches/patch-CMakeLists_txt
===
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-CMakeLists_txt28 Jun 2024 16:02:00 -
@@ -0,0 +1,12 @@
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
 CMakeLists.txt
+@@ -332,7 +332,7 @@ else ()
+ 
+ # Compiler flags
+ set(DEBUG_LEVEL 0 CACHE STRING "Select debug level for compilation. Use 
value in range 0–3.")
+-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fstrict-aliasing -Werror -Wundef 
-Wmissing-declarations -Winit-self -Wall -Wextra -Wshadow")
++set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fstrict-aliasing -Wundef 
-Wmissing-declarations -Winit-self -Wall -Wextra -Wshadow")
+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unknown-pragmas 
-Wno-missing-braces -Wno-comment -Wnonnull -Wno-unused-parameter 
-Wno-attributes")
+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DDEBUG=${DEBUG_LEVEL}")
+ 
Index: patches/patch-src_openrct2_core_String_cpp
===
RCS file: /cvs/ports/games/openrct2/patches/patch-src_openrct2_core_String_cpp,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_openrct2_core_String_cpp
--- patches/patch-src_openrct2_core_String_cpp  31 May 2024 07:38:36 -  
1.1
+++ patches/patch-src_openrct2_core_String_cpp  28 Jun 2024 16:02:00 -
@@ -1,7 +1,7 @@
 Index: src/openrct2/core/String.cpp
 --- src/openrct2/core/String.cpp.orig
 +++ src/openrct2/core/String.cpp
-@@ -15,7 +15,7 @@
+@@ -14,7 +14,7 @@
  #include 
  #include 
  #ifndef _WIN32

Re: aarch64 bulk build report

[Peter Hessler]

On 2024 Jun 19 (Wed) at 23:28:51 -0600 (-0600), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2024-06-17/summary.log
:
:build failures: 3
:http://build-failures.rhaalovely.net/aarch64/2024-06-17/games/openrct2.log

In file included from 
/usr/obj/ports/openrct2-0.4.11/OpenRCT2-0.4.11/src/openrct2/Cheats.cpp:12:
In file included from 
/usr/obj/ports/openrct2-0.4.11/OpenRCT2-0.4.11/src/openrct2/GameState.h:20:
In file included from 
/usr/obj/ports/openrct2-0.4.11/OpenRCT2-0.4.11/src/openrct2/ride/Ride.h:19:
In file included from 
/usr/obj/ports/openrct2-0.4.11/OpenRCT2-0.4.11/src/openrct2/management/../ride/../world/Map.h:14:
/usr/obj/ports/openrct2-0.4.11/OpenRCT2-0.4.11/src/openrct2/object/../drawing/../world/TileElement.h:472:19:
error: field BannerIndex within 'LargeSceneryElement' is less aligned
than '::BannerIndex' (aka 'TIdentifier::max(), BannerIndexTag>') and is usually
due to 'LargeSceneryElement' being packed, which can lead to unaligned
accesses [-Werror,-Wunaligned-access]
::BannerIndex BannerIndex;
  ^


:http://build-failures.rhaalovely.net/aarch64/2024-06-17/misc/openbabel.log


In file included from 
/usr/obj/ports/openbabel-3.1.1/openbabel-3.1.1/src/formats/json/chemdoodlejsonformat.cpp:19:
/usr/obj/ports/openbabel-3.1.1/openbabel-3.1.1/include/openbabel/json.h:22:10:
fatal error: 'rapidjson/document.h' file not found
#include 
 ^~


:http://build-failures.rhaalovely.net/aarch64/2024-06-17/plan9/plan9port.log

cd 
/usr/obj/ports/plan9port-20240109/plan9port-be7c68f6954f7dcaa53403e0f600716f65a13d32
&& sed -i 's#/usr/local#/usr/local#'  `cat lib/moveplan9.files`
sed: bin/": No such file or directory

bin/" and bin/"" don't seem to exist.  These binaries are built on amd64
and other arches I try.


-- 
A journey of a thousand miles begins with a cash advance.

Re: aarch64 bulk build report

[Stuart Henderson]

On 2024/04/26 15:44, Rafael Sadowski wrote:
> > http://build-failures.rhaalovely.net/aarch64/2024-04-23/x11/qt5/qt3d.log
> > http://build-failures.rhaalovely.net/aarch64/2024-04-23/x11/qt5/qtwebchannel.log
> > 
> Fixed by naddy. Looks like removing folders also needs a bump.

Ah I missed the lack of bump. Any PLIST change (or change to a variable
which is substed in the PLIST) requires a REVISION bump, but not a
@conflict for directory +/-

Re: aarch64 bulk build report

[Rafael Sadowski]

> http://build-failures.rhaalovely.net/aarch64/2024-04-23/x11/qt5/qt3d.log
> http://build-failures.rhaalovely.net/aarch64/2024-04-23/x11/qt5/qtwebchannel.log
> 
Fixed by naddy. Looks like removing folders also needs a bump.

Re: aarch64 bulk build report

[Peter Hessler]

On 2024 Mar 05 (Tue) at 07:32:59 -0700 (-0700), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Sun Mar 3 00:56:04 MST 2024
:finished at Tue Mar 5 07:32:46 MST 2024
:lasted 2D06h36m
:done with kern.version=OpenBSD 7.5 (GENERIC.MP) #118: Sat Mar  2 21:06:51 MST 
2024
:
:built packages:12226
:Mar 3:4474
:Mar 4:3373
:Mar 5:4378
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2024-03-03/summary.log
:
:build failures: 7
:http://build-failures.rhaalovely.net/aarch64/2024-03-03/devel/py-jupyter_server,python3.log

 npm ERR! network request to https://registry.npmjs.org/bootstrap failed, 
reason: getaddrinfo ENOTFOUND registry.npmjs.org

presumably already fixed


:http://build-failures.rhaalovely.net/aarch64/2024-03-03/editors/libreoffice.log

 configure: error: Unsupported host_cpu aarch64 for host_os openbsd7.5


:http://build-failures.rhaalovely.net/aarch64/2024-03-03/telephony/resiprocate,.log

it built?


:http://build-failures.rhaalovely.net/aarch64/2024-03-03/www/chromium.log
:http://build-failures.rhaalovely.net/aarch64/2024-03-03/www/ungoogled-chromium.log

 ../../base/allocator/partition_allocator/src/partition_alloc/tagging.cc:16:10: 
fatal error: 'asm/hwcap.h' file not found


:http://build-failures.rhaalovely.net/aarch64/2024-03-03/x11/gnustep/libobjc2.log

 error: could not find git for clone of robinmap-populate

presumably already fixed


:http://build-failures.rhaalovely.net/aarch64/2024-03-03/x11/qt5/qtwebengine.log

 Only Linux X64 MSAN is supported

should be fixed by the i386 fix



-- 
I have made mistakes but I have never made the
mistake of claiming that I have never made one.
-- James Gordon Bennett

Re: aarch64 bulk build report

[Rafael Sadowski]

On Tue Feb 13, 2024 at 02:34:03PM +, Stuart Henderson wrote:
> On 2024/02/12 14:34, Stuart Henderson wrote:
> > On 2024/02/11 14:25, Rafael Sadowski wrote:
> > > On Sat Feb 10, 2024 at 05:39:19PM -0700, phess...@openbsd.org wrote:
> > > > bulk build on arm64.ports.openbsd.org
> > > > started on  Thu Feb 8 00:00:49 MST 2024
> > > > finished at Sat Feb 10 17:37:41 MST 2024
> > > > lasted 2D17h36m
> > > > done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #76: Wed Feb  7 
> > > > 17:33:52 MST 2024
> > > > 
> > > > built packages:12278
> > > > Feb 8:4373
> > > > Feb 9:1234
> > > > Feb 10:6670
> > > > 
> > > > 
> > > > critical path missing pkgs:  
> > > > http://build-failures.rhaalovely.net/aarch64/2024-02-08/summary.log
> > > > 
> > > > build failures: 2
> > > > http://build-failures.rhaalovely.net/aarch64/2024-02-08/graphics/pdfsandwich.log
> > > > http://build-failures.rhaalovely.net/aarch64/2024-02-08/x11/qt6/qt3d.log
> > > > 
> > > 
> > > The following diff works fine both amd64 and aarch64. Does it makes
> > > sense for i386 too?
> > > 
> > > diff --git a/x11/qt6/qt3d/Makefile b/x11/qt6/qt3d/Makefile
> > > index 76da86df196..e8249a2d05a 100644
> > > --- a/x11/qt6/qt3d/Makefile
> > > +++ b/x11/qt6/qt3d/Makefile
> > > @@ -1,6 +1,7 @@
> > >  QT6NAME =Qt3D
> > >  COMMENT =Qt6 components for 3D graphics
> > >  PKGSPEC =qt6-qt3d-${QT6_PKGSPEC}
> > > +REVISION =   0
> > >  
> > >  SHARED_LIBS +=  Qt63DAnimation1.0 # 6.6
> > >  SHARED_LIBS +=  Qt63DCore 1.1 # 6.6
> > > @@ -27,7 +28,4 @@ LIB_DEPENDS =   multimedia/assimp \
> > >   x11/qt6/qtdeclarative \
> > >   x11/xkbcommon
> > >  
> > > -CONFIGURE_ARGS = -DQT_FEATURE_qt3d_simd_sse2=OFF \
> > > - -DQT_FEATURE_qt3d_simd_avx2=OFF
> > > -
> > 
> > It looks like the port was trying to disable the SSE2/AVX2 stuff -
> > depending on how the software works that might be necessary (i.e.
> > if it enables AVX2 if the build machine supports it, and uses it
> > unconditionally, then it does need disabling - but if it has a
> > runtime check then it doesn't)
> > 
> > >  .include 
> > > diff --git a/x11/qt6/qt3d/pkg/PFRAG.amd64 b/x11/qt6/qt3d/pkg/PFRAG.amd64
> > > new file mode 100644
> > > index 000..4c3913cce2e
> > > --- /dev/null
> > > +++ b/x11/qt6/qt3d/pkg/PFRAG.amd64
> > 
> > These extra PFRAG files are not used unless you set variables via
> > PKG_ARGS to have them pulled in, and reference them via %%varname%% in
> > PLIST.
> > 
> > I'm not sure if it tries to builds these files on i386 or not yet (the
> > machine has been running out of memory and crashing in my current bulk,
> > and the previous one had the old version of qt3d).
> > 
> > If they are amd64-only then I'd use the PKG_ARGS variable "amd64" and do
> > 
> > .if ${MACHINE_ARCH} == "amd64"
> > PKG_ARGS+=  -Damd64=1
> > .else
> > PKG_ARGS+=  -Damd64=0
> > .endif
> > 
> > otherwise
> > 
> > .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
> > PKG_ARGS+=  -Dx86=1
> > .else
> > PKG_ARGS+=  -Dx86=0
> > .endif
> > 
> > I'll let you know when my build finished whether they are produced on
> > i386, it will be at least a day or two away. Looks like qt6/qt3d is only
> > depended on by meta/qt6 so I guess this is not a big rush?
> 
> Those files are built on i386 too. So use the second of those and
> name the file PFRAG.x86 (and add %%x86%% to PLIST).
> 

Thanks for your guidance. OK for the following diff?

diff --git a/x11/qt6/qt3d/Makefile b/x11/qt6/qt3d/Makefile
index 76da86df196..af0097092c7 100644
--- a/x11/qt6/qt3d/Makefile
+++ b/x11/qt6/qt3d/Makefile
@@ -1,6 +1,7 @@
 QT6NAME =  Qt3D
 COMMENT =  Qt6 components for 3D graphics
 PKGSPEC =  qt6-qt3d-${QT6_PKGSPEC}
+REVISION = 0
 
 SHARED_LIBS +=  Qt63DAnimation1.0 # 6.6
 SHARED_LIBS +=  Qt63DCore 1.1 # 6.6
@@ -19,6 +20,12 @@ WANTLIB += ${COMPILER_LIBCXX} GL Qt6Concurrent Qt6Core Qt6Gui
 WANTLIB += Qt6Network Qt6OpenGL Qt6Qml Qt6QmlModels Qt6Quick Qt6ShaderTools
 WANTLIB += assimp c m xkbcommon z
 
+.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
+PKG_ARGS+=  -Dx86=1
+.else
+PKG_ARGS+=  -Dx86=0
+.endif
+
 BUILD_DEPENDS =x11/qt6/qtmultimedia \
graphics/vulkan-loader
 
@@ -27,7 +34,4 @@ LIB_DEPENDS = multimedia/assimp \
x11/qt6/qtdeclarative \
x11/xkbcommon
 
-CONFIGURE_ARGS =   -DQT_FEATURE_qt3d_simd_sse2=OFF \
-   -DQT_FEATURE_qt3d_simd_avx2=OFF
-
 .include 
diff --git a/x11/qt6/qt3d/pkg/PFRAG.x86 b/x11/qt6/qt3d/pkg/PFRAG.x86
new file mode 100644
index 000..4c3913cce2e
--- /dev/null
+++ b/x11/qt6/qt3d/pkg/PFRAG.x86
@@ -0,0 +1,4 @@
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3D

Re: aarch64 bulk build report

[Stuart Henderson]

On 2024/02/12 14:34, Stuart Henderson wrote:
> On 2024/02/11 14:25, Rafael Sadowski wrote:
> > On Sat Feb 10, 2024 at 05:39:19PM -0700, phess...@openbsd.org wrote:
> > > bulk build on arm64.ports.openbsd.org
> > > started on  Thu Feb 8 00:00:49 MST 2024
> > > finished at Sat Feb 10 17:37:41 MST 2024
> > > lasted 2D17h36m
> > > done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #76: Wed Feb  7 
> > > 17:33:52 MST 2024
> > > 
> > > built packages:12278
> > > Feb 8:4373
> > > Feb 9:1234
> > > Feb 10:6670
> > > 
> > > 
> > > critical path missing pkgs:  
> > > http://build-failures.rhaalovely.net/aarch64/2024-02-08/summary.log
> > > 
> > > build failures: 2
> > > http://build-failures.rhaalovely.net/aarch64/2024-02-08/graphics/pdfsandwich.log
> > > http://build-failures.rhaalovely.net/aarch64/2024-02-08/x11/qt6/qt3d.log
> > > 
> > 
> > The following diff works fine both amd64 and aarch64. Does it makes
> > sense for i386 too?
> > 
> > diff --git a/x11/qt6/qt3d/Makefile b/x11/qt6/qt3d/Makefile
> > index 76da86df196..e8249a2d05a 100644
> > --- a/x11/qt6/qt3d/Makefile
> > +++ b/x11/qt6/qt3d/Makefile
> > @@ -1,6 +1,7 @@
> >  QT6NAME =  Qt3D
> >  COMMENT =  Qt6 components for 3D graphics
> >  PKGSPEC =  qt6-qt3d-${QT6_PKGSPEC}
> > +REVISION = 0
> >  
> >  SHARED_LIBS +=  Qt63DAnimation1.0 # 6.6
> >  SHARED_LIBS +=  Qt63DCore 1.1 # 6.6
> > @@ -27,7 +28,4 @@ LIB_DEPENDS = multimedia/assimp \
> > x11/qt6/qtdeclarative \
> > x11/xkbcommon
> >  
> > -CONFIGURE_ARGS =   -DQT_FEATURE_qt3d_simd_sse2=OFF \
> > -   -DQT_FEATURE_qt3d_simd_avx2=OFF
> > -
> 
> It looks like the port was trying to disable the SSE2/AVX2 stuff -
> depending on how the software works that might be necessary (i.e.
> if it enables AVX2 if the build machine supports it, and uses it
> unconditionally, then it does need disabling - but if it has a
> runtime check then it doesn't)
> 
> >  .include 
> > diff --git a/x11/qt6/qt3d/pkg/PFRAG.amd64 b/x11/qt6/qt3d/pkg/PFRAG.amd64
> > new file mode 100644
> > index 000..4c3913cce2e
> > --- /dev/null
> > +++ b/x11/qt6/qt3d/pkg/PFRAG.amd64
> 
> These extra PFRAG files are not used unless you set variables via
> PKG_ARGS to have them pulled in, and reference them via %%varname%% in
> PLIST.
> 
> I'm not sure if it tries to builds these files on i386 or not yet (the
> machine has been running out of memory and crashing in my current bulk,
> and the previous one had the old version of qt3d).
> 
> If they are amd64-only then I'd use the PKG_ARGS variable "amd64" and do
> 
> .if ${MACHINE_ARCH} == "amd64"
> PKG_ARGS+=  -Damd64=1
> .else
> PKG_ARGS+=  -Damd64=0
> .endif
> 
> otherwise
> 
> .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
> PKG_ARGS+=  -Dx86=1
> .else
> PKG_ARGS+=  -Dx86=0
> .endif
> 
> I'll let you know when my build finished whether they are produced on
> i386, it will be at least a day or two away. Looks like qt6/qt3d is only
> depended on by meta/qt6 so I guess this is not a big rush?

Those files are built on i386 too. So use the second of those and
name the file PFRAG.x86 (and add %%x86%% to PLIST).

Re: aarch64 bulk build report

[Stuart Henderson]

On 2024/02/11 14:25, Rafael Sadowski wrote:
> On Sat Feb 10, 2024 at 05:39:19PM -0700, phess...@openbsd.org wrote:
> > bulk build on arm64.ports.openbsd.org
> > started on  Thu Feb 8 00:00:49 MST 2024
> > finished at Sat Feb 10 17:37:41 MST 2024
> > lasted 2D17h36m
> > done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #76: Wed Feb  7 
> > 17:33:52 MST 2024
> > 
> > built packages:12278
> > Feb 8:4373
> > Feb 9:1234
> > Feb 10:6670
> > 
> > 
> > critical path missing pkgs:  
> > http://build-failures.rhaalovely.net/aarch64/2024-02-08/summary.log
> > 
> > build failures: 2
> > http://build-failures.rhaalovely.net/aarch64/2024-02-08/graphics/pdfsandwich.log
> > http://build-failures.rhaalovely.net/aarch64/2024-02-08/x11/qt6/qt3d.log
> > 
> 
> The following diff works fine both amd64 and aarch64. Does it makes
> sense for i386 too?
> 
> diff --git a/x11/qt6/qt3d/Makefile b/x11/qt6/qt3d/Makefile
> index 76da86df196..e8249a2d05a 100644
> --- a/x11/qt6/qt3d/Makefile
> +++ b/x11/qt6/qt3d/Makefile
> @@ -1,6 +1,7 @@
>  QT6NAME =Qt3D
>  COMMENT =Qt6 components for 3D graphics
>  PKGSPEC =qt6-qt3d-${QT6_PKGSPEC}
> +REVISION =   0
>  
>  SHARED_LIBS +=  Qt63DAnimation1.0 # 6.6
>  SHARED_LIBS +=  Qt63DCore 1.1 # 6.6
> @@ -27,7 +28,4 @@ LIB_DEPENDS =   multimedia/assimp \
>   x11/qt6/qtdeclarative \
>   x11/xkbcommon
>  
> -CONFIGURE_ARGS = -DQT_FEATURE_qt3d_simd_sse2=OFF \
> - -DQT_FEATURE_qt3d_simd_avx2=OFF
> -

It looks like the port was trying to disable the SSE2/AVX2 stuff -
depending on how the software works that might be necessary (i.e.
if it enables AVX2 if the build machine supports it, and uses it
unconditionally, then it does need disabling - but if it has a
runtime check then it doesn't)

>  .include 
> diff --git a/x11/qt6/qt3d/pkg/PFRAG.amd64 b/x11/qt6/qt3d/pkg/PFRAG.amd64
> new file mode 100644
> index 000..4c3913cce2e
> --- /dev/null
> +++ b/x11/qt6/qt3d/pkg/PFRAG.amd64

These extra PFRAG files are not used unless you set variables via
PKG_ARGS to have them pulled in, and reference them via %%varname%% in
PLIST.

I'm not sure if it tries to builds these files on i386 or not yet (the
machine has been running out of memory and crashing in my current bulk,
and the previous one had the old version of qt3d).

If they are amd64-only then I'd use the PKG_ARGS variable "amd64" and do

.if ${MACHINE_ARCH} == "amd64"
PKG_ARGS+=  -Damd64=1
.else
PKG_ARGS+=  -Damd64=0
.endif

otherwise

.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
PKG_ARGS+=  -Dx86=1
.else
PKG_ARGS+=  -Dx86=0
.endif

I'll let you know when my build finished whether they are produced on
i386, it will be at least a day or two away. Looks like qt6/qt3d is only
depended on by meta/qt6 so I guess this is not a big rush?

> @@ -0,0 +1,4 @@
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector4d_sse_p.h
> diff --git a/x11/qt6/qt3d/pkg/PFRAG.x86 b/x11/qt6/qt3d/pkg/PFRAG.x86
> new file mode 100644
> index 000..4c3913cce2e
> --- /dev/null
> +++ b/x11/qt6/qt3d/pkg/PFRAG.x86
> @@ -0,0 +1,4 @@
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
> +include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector4d_sse_p.h
> diff --git a/x11/qt6/qt3d/pkg/PLIST b/x11/qt6/qt3d/pkg/PLIST
> index 9ca5b38ff0f..43846b8ca22 100644
> --- a/x11/qt6/qt3d/pkg/PLIST
> +++ b/x11/qt6/qt3d/pkg/PLIST
> @@ -133,9 +133,7 @@ 
> include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/calcboundingvolumejob_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/corelogging_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/coresettings_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/job_common_p.h
> -include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_p.h
> -include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/nullservices_p.h
>  
> include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/propertychangehandler_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/qabstractaspect_p.h
> @@ -195,9 +193,7 @@ 
> include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/qurlhelper_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/sqt_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/task_p.h
>  include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_p.h
> -include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
>  include/X11/qt6/Qt3DCore/${VERS

Re: aarch64 bulk build report

[Rafael Sadowski]

On Sat Feb 10, 2024 at 05:39:19PM -0700, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Thu Feb 8 00:00:49 MST 2024
> finished at Sat Feb 10 17:37:41 MST 2024
> lasted 2D17h36m
> done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #76: Wed Feb  7 
> 17:33:52 MST 2024
> 
> built packages:12278
> Feb 8:4373
> Feb 9:1234
> Feb 10:6670
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2024-02-08/summary.log
> 
> build failures: 2
> http://build-failures.rhaalovely.net/aarch64/2024-02-08/graphics/pdfsandwich.log
> http://build-failures.rhaalovely.net/aarch64/2024-02-08/x11/qt6/qt3d.log
> 

The following diff works fine both amd64 and aarch64. Does it makes
sense for i386 too?

diff --git a/x11/qt6/qt3d/Makefile b/x11/qt6/qt3d/Makefile
index 76da86df196..e8249a2d05a 100644
--- a/x11/qt6/qt3d/Makefile
+++ b/x11/qt6/qt3d/Makefile
@@ -1,6 +1,7 @@
 QT6NAME =  Qt3D
 COMMENT =  Qt6 components for 3D graphics
 PKGSPEC =  qt6-qt3d-${QT6_PKGSPEC}
+REVISION = 0
 
 SHARED_LIBS +=  Qt63DAnimation1.0 # 6.6
 SHARED_LIBS +=  Qt63DCore 1.1 # 6.6
@@ -27,7 +28,4 @@ LIB_DEPENDS = multimedia/assimp \
x11/qt6/qtdeclarative \
x11/xkbcommon
 
-CONFIGURE_ARGS =   -DQT_FEATURE_qt3d_simd_sse2=OFF \
-   -DQT_FEATURE_qt3d_simd_avx2=OFF
-
 .include 
diff --git a/x11/qt6/qt3d/pkg/PFRAG.amd64 b/x11/qt6/qt3d/pkg/PFRAG.amd64
new file mode 100644
index 000..4c3913cce2e
--- /dev/null
+++ b/x11/qt6/qt3d/pkg/PFRAG.amd64
@@ -0,0 +1,4 @@
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector4d_sse_p.h
diff --git a/x11/qt6/qt3d/pkg/PFRAG.x86 b/x11/qt6/qt3d/pkg/PFRAG.x86
new file mode 100644
index 000..4c3913cce2e
--- /dev/null
+++ b/x11/qt6/qt3d/pkg/PFRAG.x86
@@ -0,0 +1,4 @@
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
+include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector4d_sse_p.h
diff --git a/x11/qt6/qt3d/pkg/PLIST b/x11/qt6/qt3d/pkg/PLIST
index 9ca5b38ff0f..43846b8ca22 100644
--- a/x11/qt6/qt3d/pkg/PLIST
+++ b/x11/qt6/qt3d/pkg/PLIST
@@ -133,9 +133,7 @@ 
include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/calcboundingvolumejob_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/corelogging_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/coresettings_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/job_common_p.h
-include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_avx2_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_p.h
-include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/matrix4x4_sse_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/nullservices_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/propertychangehandler_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/qabstractaspect_p.h
@@ -195,9 +193,7 @@ 
include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/qurlhelper_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/sqt_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/task_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_p.h
-include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector3d_sse_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector4d_p.h
-include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector4d_sse_p.h
 include/X11/qt6/Qt3DCore/${VERSION}/Qt3DCore/private/vector_helper_p.h
 include/X11/qt6/Qt3DCore/QAbstractAspect
 include/X11/qt6/Qt3DCore/QAbstractFunctor

Re: aarch64 bulk build report

[Peter Hessler]

On 2024 Jan 17 (Wed) at 19:53:18 -0700 (-0700), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2024-01-15/summary.log
:
:build failures: 5
:http://build-failures.rhaalovely.net/aarch64/2024-01-15/databases/updatedb.log

missing REVISION, fixed


:http://build-failures.rhaalovely.net/aarch64/2024-01-15/meta/gnome.log

transient failure, asked it to rebuild and it built fine


:http://build-failures.rhaalovely.net/aarch64/2024-01-15/sysutils/ugrep.log

cpu feature detection problems

cc -DHAVE_CONFIG_H -I. -I../..  -DZ7_PPMD_SUPPORT -DZ7_EXTRACT_ONLY -DNDEBUG 
-D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/local/include 
-I/usr/local/include -I/usr/include -I/usr/include -I/usr/local/include 
-I/usr/local/include -I/usr/local/include -I/usr/local/include 
-I/usr/local/include -I/usr/local/include -I/usr/local/include 
-I/usr/local/include -I/usr/local/include -I/usr/local/include -I../lzma/C  -O2 
-pipe -MT libviiz_a-CpuArch.o -MD -MP -MF .deps/libviiz_a-CpuArch.Tpo -c -o 
libviiz_a-CpuArch.o `test -f 'CpuArch.c' || echo './'`CpuArch.c
CpuArch.c:763:10: fatal error: 'sys/auxv.h' file not found
#include 
 ^~~~

:http://build-failures.rhaalovely.net/aarch64/2024-01-15/www/sogo.log

===>   Failed patches: 
patch-SoObjects_SOGo_SOGoGCSFolder_m


:http://build-failures.rhaalovely.net/aarch64/2024-01-15/x11/kde-plasma/kwin.log

missing dep on multimedia/pipewire/pipewire,-libs ?

/usr/obj/ports/kwin-5.27.10/kwin-5.27.10/src/plugins/screencast/screencastsource.h:10:10:
 fatal error: 'spa/buffer/buffer.h' file not found
#include 
 ^
1 error generated.


-- 
Life may have no meaning -- or even worse,
it may have a meaning of which I disapprove.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Dec 30 (Sat) at 13:33:16 -0800 (-0800), Jeremy Evans wrote:
:On Sat, Dec 30, 2023 at 10:17 AM Peter Hessler  wrote:
:
:> :http://build-failures.rhaalovely.net/aarch64/2023-12-28/lang/ruby/3.3.log
:>
:> ./miniruby -I./lib -I. -I.ext/common  -n  -e
:> 'BEGIN{version=ARGV.shift;mis=ARGV.dup}'  -e 'END{abort "UNICODE version
:> mismatch: #{mis}" unless mis.empty?}'  -e '(mis.delete(ARGF.path);
:> ARGF.close) if /ONIG_UNICODE_VERSION_STRING
:> +"#{Regexp.quote(version)}"/o'  15.0.0 ./enc/unicode/15.0.0/casefold.h
:> ./enc/unicode/15.0.0/name2ctype.h
:> Segmentation fault (core dumped)
:> *** Error 139 in /usr/obj/ports/ruby-3.3.0/ruby-3.3.0 (Makefile:1626
:> '.rbconfig.time')
:>
:
:Maybe this could be fixed by
:https://github.com/ruby/ruby/commit/02973b78f499acc28c714a082c82a846314a911f,
:but that's just a guess without seeing the backtrace.
:
:Thanks,
:Jeremy

That patch doesn't seem to help.  Here's a backtrace from gdb-9.2.


phess...@jane.theapt.org:/usr/obj/ports/ruby-3.3.0/ruby-3.3.0> egdb --core min>
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-unknown-openbsd7.4".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./miniruby...
Dwarf Error: could not find abbrev number 135 [in module 
/usr/obj/ports/ruby-3.3.0/ruby-3.3.0/miniruby]
(No debugging symbols found in ./miniruby)
[New process 109035]
Core was generated by `miniruby'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00187992ab7c in rb_yjit_constant_state_changed ()
(gdb) bt
#0  0x00187992ab7c in rb_yjit_constant_state_changed ()
#1  0x001879801df4 [PAC] in rb_clear_constant_cache_for_id ()
#2  0x0018797f4758 [PAC] in const_set ()
#3  0x0018797f45ec [PAC] in rb_const_set ()
#4  0x0018795dcf50 [PAC] in boot_defclass ()
#5  0x0018795dccb0 [PAC] in Init_class_hierarchy ()
#6  0x0018796e74b4 [PAC] in InitVM_Object ()
#7  0x001879688f04 [PAC] in rb_call_inits ()
#8  0x001879653e70 [PAC] in ruby_setup ()
#9  0x001879653fa0 [PAC] in ruby_init ()
#10 0x0018795ae0c4 [PAC] in main ()





-- 
If you're right 90% of the time, why quibble about the remaining 3%?

Re: aarch64 bulk build report

[Jeremy Evans]

On Sat, Dec 30, 2023 at 10:17 AM Peter Hessler  wrote:

> :http://build-failures.rhaalovely.net/aarch64/2023-12-28/lang/ruby/3.3.log
>
> ./miniruby -I./lib -I. -I.ext/common  -n  -e
> 'BEGIN{version=ARGV.shift;mis=ARGV.dup}'  -e 'END{abort "UNICODE version
> mismatch: #{mis}" unless mis.empty?}'  -e '(mis.delete(ARGF.path);
> ARGF.close) if /ONIG_UNICODE_VERSION_STRING
> +"#{Regexp.quote(version)}"/o'  15.0.0 ./enc/unicode/15.0.0/casefold.h
> ./enc/unicode/15.0.0/name2ctype.h
> Segmentation fault (core dumped)
> *** Error 139 in /usr/obj/ports/ruby-3.3.0/ruby-3.3.0 (Makefile:1626
> '.rbconfig.time')
>

Maybe this could be fixed by
https://github.com/ruby/ruby/commit/02973b78f499acc28c714a082c82a846314a911f,
but that's just a guess without seeing the backtrace.

Thanks,
Jeremy

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Dec 30 (Sat) at 11:11:11 -0700 (-0700), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-12-28/summary.log


:http://build-failures.rhaalovely.net/aarch64/2023-12-28/games/godot4,-editor.log

===>  Faking installation for godot4-4.1.3
/usr/obj/ports/godot4-4.1.3/bin/install -c  -m 755
/usr/obj/ports/godot4-4.1.3/godot-4.1.3-stable/bin/godot.linuxbsd.template_release.x86_64
  /usr/obj/ports/godot4-4.1.3/fake-aarch64/usr/local/bin/godot4
install: 
/usr/obj/ports/godot4-4.1.3/godot-4.1.3-stable/bin/godot.linuxbsd.template_release.x86_64:
 No such file or directory

but 
/usr/obj/ports/godot4-4.1.3/godot-4.1.3-stable/bin/godot.linuxbsd.template_release.arm64
does exist


:http://build-failures.rhaalovely.net/aarch64/2023-12-28/graphics/darktable.log

cd /usr/obj/ports/darktable-4.4.2/darktable-4.4.2/data && 
/usr/local/bin/jsonschema -i 
/usr/obj/ports/darktable-4.4.2/darktable-4.4.2/data/noiseprofiles.json 
/usr/obj/ports/darktable-4.4.2/darktable-4.4.2/data/noiseprofiles.schema
Traceback (most recent call last):
  File "/usr/local/bin/jsonschema", line 5, in 
from jsonschema.cli import main
  File "/usr/local/lib/python3.10/site-packages/jsonschema/__init__.py", line 
13, in 
from jsonschema._format import FormatChecker
  File "/usr/local/lib/python3.10/site-packages/jsonschema/_format.py", line 
287, in 
raises=(idna.IDNAError, UnicodeError),
AttributeError: module 'idna' has no attribute 'IDNAError'
ninja: build stopped: subcommand failed.


:http://build-failures.rhaalovely.net/aarch64/2023-12-28/lang/ruby/3.3.log

./miniruby -I./lib -I. -I.ext/common  -n  -e 
'BEGIN{version=ARGV.shift;mis=ARGV.dup}'  -e 'END{abort "UNICODE version 
mismatch: #{mis}" unless mis.empty?}'  -e '(mis.delete(ARGF.path); ARGF.close) 
if /ONIG_UNICODE_VERSION_STRING  +"#{Regexp.quote(version)}"/o'  15.0.0 
./enc/unicode/15.0.0/casefold.h ./enc/unicode/15.0.0/name2ctype.h  
Segmentation fault (core dumped) 
*** Error 139 in /usr/obj/ports/ruby-3.3.0/ruby-3.3.0 (Makefile:1626 
'.rbconfig.time')


:http://build-failures.rhaalovely.net/aarch64/2023-12-28/x11/kde-plasma/kwayland-integration.log
:http://build-failures.rhaalovely.net/aarch64/2023-12-28/x11/kde-plasma/plasma-nano.log
:http://build-failures.rhaalovely.net/aarch64/2023-12-28/x11/kde-plasma/plasma-pa.log
:http://build-failures.rhaalovely.net/aarch64/2023-12-28/x11/kde-plasma/xdg-desktop-portal-kde.log
:

already fixed


-- 
A bird in the hand makes it awfully hard to blow your nose.

Re: aarch64 bulk build report

[Peter Hessler]

good news, all of the java build errors are gone.  brief look at the
logs inline.

On 2023 Nov 24 (Fri) at 04:48:34 -0700 (-0700), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-11-21/summary.log
:
:build failures: 6
:http://build-failures.rhaalovely.net/aarch64/2023-11-21/audio/audacious/plugins.log

likely a missing dep:

 if c++ -fPIC -DPIC -O2 -pipe -ffast-math -Wall -pipe -std=gnu++17 
-Wtype-limits -Woverloaded-virtual -fvisibility=hidden -fPIC -DPIC 
-I/usr/X11R6/include -I/usr/local/include -include config.h 
-I/usr/local/include  -I/usr/local/include -I../..   -MD -MF ${out%.o}.dep -c 
-o mpt.plugin.o mpt.cc; then \
printf "Successfully compiled %s (plugin).\n" "mpt.cc"; \
 else \
err=$?; printf "Failed to compile %s (plugin)!\n" "mpt.cc"; exit $err; \
 fi
 In file included from mpt.cc:32:
 ./mptwrap.h:34:10: fatal error: 'libopenmpt/libopenmpt.h' file not found
 #include 
  ^
 1 error generated.

:http://build-failures.rhaalovely.net/aarch64/2023-11-21/sysutils/cdrtools.log

hangs running avoffset.  seems there is a 3.01 update available that addresses 
that program.


:http://build-failures.rhaalovely.net/aarch64/2023-11-21/sysutils/telegraf.log

 /usr/obj/ports/telegraf-1.28.3/go/bin/telegraf config > 
/usr/obj/ports/telegraf-1.28.3/github.com/influxdata/telegraf@v1.28.3/etc/telegraf.conf
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x3116358]

 goroutine 1 [running]:
 modernc.org/libc.(*TLS).setErrno(0xb6636c0?, {0x58dfd20?, 0x76db6e0?})
modernc.org/libc@v1.22.5/etc.go:189 +0x108
 modernc.org/libc.Xmalloc(0x4001d3feb0?, 0x77178c0?)
modernc.org/libc@v1.22.5/mem.go:34 +0xf4
 modernc.org/libc.init()
modernc.org/libc@v1.22.5/libc_openbsd.go:49 +0x204

:http://build-failures.rhaalovely.net/aarch64/2023-11-21/www/hiawatha.log

 /usr/obj/ports/hiawatha-11.4/bin/cc  
-I/usr/obj/ports/hiawatha-11.4/hiawatha-11.4/mbedtls/include 
-I/usr/obj/ports/hiawatha-11.4/hiawatha-11.4/mbedtls/library -O2 -Wall -Wextra 
-O2 -pipe -g -Wall -Wextra -Wwrite-strings -Wpointer-arith 
-Wimplicit-fallthrough -Wshadow -Wvla -Wformat=2 -Wno-format-nonliteral 
-Wmissing-declarations -Wmissing-prototypes -Wdocumentation 
-Wno-documentation-deprecated-sync -Wunreachable-code -g -DNDEBUG -std=c99 -MD 
-MT mbedtls/library/CMakeFiles/mbedcrypto.dir/aesce.c.o -MF 
mbedtls/library/CMakeFiles/mbedcrypto.dir/aesce.c.o.d -o 
mbedtls/library/CMakeFiles/mbedcrypto.dir/aesce.c.o -c 
/usr/obj/ports/hiawatha-11.4/hiawatha-11.4/mbedtls/library/aesce.c
 In file included from 
/usr/obj/ports/hiawatha-11.4/hiawatha-11.4/mbedtls/library/aesce.c:70:
 /usr/lib/clang/16/include/arm_neon.h:62829:32: error: always_inline function 
'vget_high_p64' requires target feature 'crypto', but would be inlined into 
function 'vmull_high_p64' that is compiled without support for 'crypto'
   __ret = vmull_p64((poly64_t)(vget_high_p64(__p0)), 
(poly64_t)(vget_high_p64(__p1)));
^
 /usr/lib/clang/16/include/arm_neon.h:62829:65: error: always_inline function 
'vget_high_p64' requires target feature 'crypto', but would be inlined into 
function 'vmull_high_p64' that is compiled without support for 'crypto'
   __ret = vmull_p64((poly64_t)(vget_high_p64(__p0)), 
(poly64_t)(vget_high_p64(__p1)));
 ^

probably needs some compiler attributes shuffled around.

:http://build-failures.rhaalovely.net/aarch64/2023-11-21/net/nheko.log

 FAILED: CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o 
 /usr/obj/ports/nheko-0.11.3/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE 
-DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB 
-DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB 
-DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB 
-DSPDLOG_COMPILED_LIB -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE 
-I/usr/obj/ports/nheko-0.11.3/build-aarch64 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3 
-I/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/include 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/src 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/includes 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/cpp-httplib-0.5.12 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/blurhash 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/SingleApplication-3.3.2 
-isystem /usr/local/include/X11/qt5 -isystem /usr/local/include/X11/qt5/QtDBus 
-isystem /usr/local/include/X11/qt5/QtCore -isystem 
/usr/local/lib/qt5/./mkspecs/openbsd-clang -isystem /usr/local/include -isystem 
/usr/local/include/X11/qt5/QtWidgets -isystem /usr/local/include/X11/qt5/QtGui 
-isystem /usr/X11R6/include -isystem /usr/local/include/X11/qt5/QtSvg -isystem 
/usr/local/i

Re: aarch64 bulk build report

[Peter Hessler]

I removed the entries that are either already fixed, or a fix is incoming.

On 2023 Nov 20 (Mon) at 22:58:51 -0700 (-0700), phess...@openbsd.org wrote:
:http://build-failures.rhaalovely.net/aarch64/2023-11-18/net/nheko.log

 FAILED: CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o 
 /usr/obj/ports/nheko-0.11.3/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE 
-DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB 
-DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB 
-DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB 
-DSPDLOG_COMPILED_LIB -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE 
-I/usr/obj/ports/nheko-0.11.3/build-aarch64 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3 
-I/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/include 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/src 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/includes 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/cpp-httplib-0.5.12 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/blurhash 
-I/usr/obj/ports/nheko-0.11.3/nheko-0.11.3/third_party/SingleApplication-3.3.2 
-isystem /usr/local/include/X11/qt5 -isystem /usr/local/include/X11/qt5/QtDBus 
-isystem /usr/local/include/X11/qt5/QtCore -isystem 
/usr/local/lib/qt5/./mkspecs/openbsd-clang -isystem /usr/local/include -isystem 
/usr/local/include/X11/qt5/QtWidgets -isystem /usr/local/include/X11/qt5/QtGui 
-isystem /usr/X11R6/include -isystem /usr/local/include/X11/qt5/QtSvg -isystem 
/usr/local/include/X11/qt5/QtConcurrent -isystem 
/usr/local/include/X11/qt5/QtMultimedia -isystem 
/usr/local/include/X11/qt5/QtNetwork -isystem /usr/local/include/X11/qt5/QtQml 
-isystem /usr/local/include/X11/qt5/QtQuickControls2 -isystem 
/usr/local/include/X11/qt5/QtQuick -isystem 
/usr/local/include/X11/qt5/QtQmlModels -isystem 
/usr/local/include/X11/qt5/QtQuickWidgets -isystem 
/usr/local/include/gstreamer-1.0 -isystem /usr/local/include/orc-0.4 -isystem 
/usr/local/include/glib-2.0 -isystem /usr/local/lib/glib-2.0/include -O2 -pipe  
  -Wall   -Wextra -pedantic   
-fsized-deallocation-fdiagnostics-color=always  
-Wunreachable-code  -Wno-attributes -Wshadow -DNDEBUG -std=gnu++20 
-fPIE -fPIC -pthread -Winvalid-pch -Xclang -include-pch -Xclang 
/usr/obj/ports/nheko-0.11.3/build-aarch64/CMakeFiles/nheko.dir/cmake_pch.hxx.pch
 -Xclang -include -Xclang 
/usr/obj/ports/nheko-0.11.3/build-aarch64/CMakeFiles/nheko.dir/cmake_pch.hxx 
-MD -MT CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o -MF 
CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o.d -o 
CMakeFiles/nheko.dir/nheko_autogen/mocs_compilation.cpp.o -c 
/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/mocs_compilation.cpp
 In file included from 
/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/mocs_compilation.cpp:2:
 In file included from 
/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/UVLADIE3JM/moc_AliasEditModel.cpp:10:
 In file included from 
/usr/obj/ports/nheko-0.11.3/build-aarch64/nheko_autogen/UVLADIE3JM/../../../nheko-0.11.3/src/AliasEditModel.h:8:
 In file included from /usr/local/include/X11/qt5/QtCore/QAbstractListModel:1:
 In file included from 
/usr/local/include/X11/qt5/QtCore/qabstractitemmodel.h:43:
 In file included from /usr/local/include/X11/qt5/QtCore/qvariant.h:44:
 In file included from /usr/local/include/X11/qt5/QtCore/qbytearray.h:50:
 /usr/include/stdarg.h:27:9: error: reference to '__builtin_va_list' is 
ambiguous
 typedef __builtin_va_list __gnuc_va_list;
 ^
 note: candidate found by name lookup is '__builtin_va_list'
 note: candidate found by name lookup is '__builtin_va_list'


:http://build-failures.rhaalovely.net/aarch64/2023-11-18/sysutils/cdrtools.log

Hung for more than 9 hours while building
 cc -o OBJ/aarch64-openbsd-cc/avoffset OBJ/aarch64-openbsd-cc/avoffset.o
 -L../libs/aarch64-openbsd-cc -L../libs/aarch64-openbsd-cc  -L/opt/schily/lib   
==> GENERATING include file "../incs/aarch64-openbsd-cc/avoffset.h"

The hang did not happen before clang16.




-- 
The only way to get rid of a temptation is to yield to it.
-- Oscar Wilde

Re: multimedia/assimp error Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Nov 19 (Sun) at 22:25:14 + (+), Brian Callahan wrote:
:On 11/19/2023 5:17 PM, Theo Buehler wrote:
:> On Sun, Nov 19, 2023 at 10:52:35PM +0100, Peter Hessler wrote:
:>> On 2023 Nov 18 (Sat) at 00:36:16 -0700 (-0700), phess...@openbsd.org wrote:
:>> 
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/assimp.log
:>>
:>> Not a java-related error and doesn't seem to happen on amd64, but does on 
arm64:
:> 
:>> error: field  within 'Assimp::MDL::Vertex_MDL7' is less aligned than 
'Assimp::MDL::Vertex_MDL7::(anonymous union at 
/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLFileData.h:603:5)'
:>> and is usually due to 'Assimp::MDL::Vertex_MDL7' being packed, which can 
lead to unaligned accesses [-Werror,-Wunaligned-access]
:>> union {
:>> ^
:>> 1 error generated.
:>> ninja: build stopped: subcommand failed.
:> 
:> -Werror strikes again. Given that this packed struct is part of a file
:> format, I doubt there's much we can do.
:> 
:> Index: Makefile
:> ===
:> RCS file: /cvs/ports/multimedia/assimp/Makefile,v
:> diff -u -p -r1.9 Makefile
:> --- Makefile 29 Aug 2023 10:46:34 -  1.9
:> +++ Makefile 19 Nov 2023 22:02:12 -
:> @@ -21,6 +21,8 @@ COMPILER = base-clang ports-gcc
:>  
:>  # make sure we dont pickup minizip from ports as its not the same
:>  CONFIGURE_ARGS+=-DASSIMP_BUILD_MINIZIP:bool=true
:> +# arm64 emits a warning about unaligned access
:> +CONFIGURE_ARGS+=-DASSIMP_WARNINGS_AS_ERRORS:bool=false
:>  MODULES =   devel/cmake
:>  
:>  BUILD_DEPENDS = devel/boost
:> 
:
:Yup; this makes the most sense to me.
:
:~Brian

Makes sense, and works for me in the current bulk.  OK


-- 
Nature is by and large to be found out of doors, a location where, it
cannot be argued, there are never enough comfortable chairs.
-- Fran Leibowitz

Re: multimedia/assimp error Re: aarch64 bulk build report

[Brian Callahan]

On 11/19/2023 5:17 PM, Theo Buehler wrote:
> On Sun, Nov 19, 2023 at 10:52:35PM +0100, Peter Hessler wrote:
>> On 2023 Nov 18 (Sat) at 00:36:16 -0700 (-0700), phess...@openbsd.org wrote:
>> :http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/assimp.log
>>
>> Not a java-related error and doesn't seem to happen on amd64, but does on 
>> arm64:
> 
>> error: field  within 'Assimp::MDL::Vertex_MDL7' is less aligned than 
>> 'Assimp::MDL::Vertex_MDL7::(anonymous union at 
>> /usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLFileData.h:603:5)'
>> and is usually due to 'Assimp::MDL::Vertex_MDL7' being packed, which can 
>> lead to unaligned accesses [-Werror,-Wunaligned-access]
>> union {
>> ^
>> 1 error generated.
>> ninja: build stopped: subcommand failed.
> 
> -Werror strikes again. Given that this packed struct is part of a file
> format, I doubt there's much we can do.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/assimp/Makefile,v
> diff -u -p -r1.9 Makefile
> --- Makefile  29 Aug 2023 10:46:34 -  1.9
> +++ Makefile  19 Nov 2023 22:02:12 -
> @@ -21,6 +21,8 @@ COMPILER =  base-clang ports-gcc
>  
>  # make sure we dont pickup minizip from ports as its not the same
>  CONFIGURE_ARGS+=-DASSIMP_BUILD_MINIZIP:bool=true
> +# arm64 emits a warning about unaligned access
> +CONFIGURE_ARGS+=-DASSIMP_WARNINGS_AS_ERRORS:bool=false
>  MODULES =devel/cmake
>  
>  BUILD_DEPENDS =  devel/boost
> 

Yup; this makes the most sense to me.

~Brian

Re: multimedia/assimp error Re: aarch64 bulk build report

[Theo Buehler]

On Sun, Nov 19, 2023 at 10:52:35PM +0100, Peter Hessler wrote:
> On 2023 Nov 18 (Sat) at 00:36:16 -0700 (-0700), phess...@openbsd.org wrote:
> :http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/assimp.log
> 
> Not a java-related error and doesn't seem to happen on amd64, but does on 
> arm64:

> error: field  within 'Assimp::MDL::Vertex_MDL7' is less aligned than 
> 'Assimp::MDL::Vertex_MDL7::(anonymous union at 
> /usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLFileData.h:603:5)'
> and is usually due to 'Assimp::MDL::Vertex_MDL7' being packed, which can lead 
> to unaligned accesses [-Werror,-Wunaligned-access]
> union {
> ^
> 1 error generated.
> ninja: build stopped: subcommand failed.

-Werror strikes again. Given that this packed struct is part of a file
format, I doubt there's much we can do.

Index: Makefile
===
RCS file: /cvs/ports/multimedia/assimp/Makefile,v
diff -u -p -r1.9 Makefile
--- Makefile29 Aug 2023 10:46:34 -  1.9
+++ Makefile19 Nov 2023 22:02:12 -
@@ -21,6 +21,8 @@ COMPILER =base-clang ports-gcc
 
 # make sure we dont pickup minizip from ports as its not the same
 CONFIGURE_ARGS+=-DASSIMP_BUILD_MINIZIP:bool=true
+# arm64 emits a warning about unaligned access
+CONFIGURE_ARGS+=-DASSIMP_WARNINGS_AS_ERRORS:bool=false
 MODULES =  devel/cmake
 
 BUILD_DEPENDS =devel/boost

multimedia/assimp error Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Nov 18 (Sat) at 00:36:16 -0700 (-0700), phess...@openbsd.org wrote:
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/assimp.log

Not a java-related error and doesn't seem to happen on amd64, but does on arm64:

/usr/obj/ports/assimp-5.2.5/bin/c++ -DASSIMP_BUILD_DLL_EXPORT 
-DASSIMP_BUILD_NO_C4D_IMPORTER -DASSIMP_BUILD_NO_M3D_EXPORTER
 -DASSIMP_BUILD_NO_M3D_IMPORTER -DASSIMP_BUILD_NO_OWN_ZLIB 
-DMINIZ_USE_UNALIGNED_LOADS_AND_STORES=0 -DOPENDDLPARSER_BUILD
 -DRAPIDJSON_HAS_STDSTRING=1 -DRAPIDJSON_NOMEMBERITERATORCLASS -Dassimp_EXPORTS 
-I/usr/obj/ports/assimp-5.2.5/build-aarch64/include
 -I/usr/obj/ports/assimp-5.2.5/build-aarch64 
-I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/include
 -I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code 
-I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/.
 -I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/../contrib/pugixml/src 
-I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/../contrib/rapidjson/include
 -I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/../contrib 
-I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/../contrib/unzip
 
-I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/../contrib/openddlparser/include
 -I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/../include 
 -I/usr/obj/ports/assimp-5.2.5/build-aarch64/code/../include 
-I/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/.. -fvisibility=hidden
 -fno-strict-aliasing -Wall -Wno-long-long -O2 -pipe -DNDEBUG -std=gnu++17 
-fPIC -Wall -Werror -MD -MT
 code/CMakeFiles/assimp.dir/AssetLib/MDL/MDLLoader.cpp.o -MF 
code/CMakeFiles/assimp.dir/AssetLib/MDL/MDLLoader.cpp.o.d -o
 code/CMakeFiles/assimp.dir/AssetLib/MDL/MDLLoader.cpp.o -c 
/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLLoader.cpp
In file included from 
/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLLoader.cpp:51:
In file included from 
/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLLoader.h:51:
/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLFileData.h:603:5:
error: field  within 'Assimp::MDL::Vertex_MDL7' is less aligned than 
'Assimp::MDL::Vertex_MDL7::(anonymous union at 
/usr/obj/ports/assimp-5.2.5/assimp-5.2.5/code/AssetLib/MDL/MDLFileData.h:603:5)'
and is usually due to 'Assimp::MDL::Vertex_MDL7' being packed, which can lead 
to unaligned accesses [-Werror,-Wunaligned-access]
union {
^
1 error generated.
ninja: build stopped: subcommand failed.


-- 
Ask not for whom the  tolls.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Nov 18 (Sat) at 00:36:16 -0700 (-0700), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Wed Nov 15 14:44:29 MST 2023
:finished at Sat Nov 18 00:34:25 MST 2023
:lasted 2D09h49m
:done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #18: Wed Nov 15 
10:54:45 MST 2023
:
:built packages:11765
:Nov 15:3724
:Nov 16:2705
:Nov 17:5334
:Nov 18:1
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-11-15/summary.log
:

A lot of these are the usual clang-16 fallout, some already fixed.  I
did notice some aarch64-specific failures and got a few of those in-tree
already.


However, I've nocticed a lot of java apps are failing with this:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (assembler_aarch64.hpp:237), pid=45730, tid=0x000541a28400
#  guarantee(val < (1U << nbits)) failed: Field too big for insn
#
# JRE version:  (8.0_392-b08) (build )
# Java VM: OpenJDK 64-Bit Server VM (25.392-b08 mixed mode bsd-aarch64 
compressed oops)
# Core dump written. Default location: 
/usr/obj/ports/lwjgl-2.9.3/lwjgl-lwjgl2.9.3/java.core
#
# An error report file with more information is saved as:
# /usr/obj/ports/lwjgl-2.9.3/lwjgl-lwjgl2.9.3/hs_err_pid45730.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

Kurt, do you have any ideas about these?


:build failures: 45
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/cad/prusaslicer.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/devel/atlas.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/devel/avr32/newlib.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/devel/kyua-cli.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/devel/quirks.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/amoebax.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/bastet.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/boswars.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/eliot.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/goldberg_emulator.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/jbrickshooter.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/libgdx/1.9.11.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/libgdx/1.9.9.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/lwjgl.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/games/mars.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/geo/postgis.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/graphics/opencv.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/japanese/onew,canna.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/java/jBCrypt.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/java/tanukiwrapper.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/lang/kawa.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/lang/librep.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/assimp.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/ogmtools.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/multimedia/synfig.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/bro.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/gnugk.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/i2p.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/kea,mysql.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/minbif.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/nheko.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/net/xprobe.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/security/pivy.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/security/web-eid-app,-chrome.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/sysutils/cdrtools.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/sysutils/rundeck.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/textproc/pdftk.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/www/hiawatha.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/www/icedtea-web.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/x11/kde-applications/kleopatra.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/x11/kde-applications/krfb.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/x11/libquotient.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/x11/ogre.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/x11/qt6/qtwebengine.log
:http://build-failures.rhaalovely.net/aarch64/2023-11-15/x11/xruskb.log
:
:recurrent failures
:new failures
:+++ ls-failuresSat Nov 18 00:36:15 2023
:+failures/cad/prusa

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Oct 14 (Sat) at 20:40:01 -0600 (-0600), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Thu Oct 12 00:11:33 MDT 2023
:finished at Sat Oct 14 20:39:48 MDT 2023
:lasted 2D20h28m
:done with kern.version=OpenBSD 7.4-current (GENERIC.MP) #2274: Wed Oct 11 
14:26:46 MDT 2023
:
:built packages:11593
:Oct 12:4011
:Oct 13:1166
:Oct 14:6415
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-10-12/summary.log
:
:build failures: 4
:http://build-failures.rhaalovely.net/aarch64/2023-10-12/games/stone-soup.log

===>  Faking installation for stone-soup-0.27.1p1
which: advpng: Command not found.
gmake: git: No such file or directory


:http://build-failures.rhaalovely.net/aarch64/2023-10-12/games/ufoai/base,-editor.log

not immediately clear to me.


:http://build-failures.rhaalovely.net/aarch64/2023-10-12/net/neochat.log

fixed in qtbase


:http://build-failures.rhaalovely.net/aarch64/2023-10-12/x11/qt6/qtwebengine.log
:

../../../../../qtwebengine-everywhere-src-6.5.2/src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h:1030:19:
 error: functional-style cast from 'neon::F' (aka 'V') to '__fp16'
is not allowed
__fp16 fp16 = __fp16(f);
  ^~~~

needs the fix from x11/qt5/qtwebengine


-- 
While most peoples' opinions change,
the conviction of their correctness never does.

Re: aarch64 bulk build report

[Christian Weisgerber]

Omar Polo:

> on non-apple arm devices it assumes there is sys/auxv.h and
> asm/hwcap.h and uses getauxval(AT_HWCAP) to see if some features
> (CRC32, SHA1, SHA2 and AES) are supported by the CPU.
> 
> What can we use to detect the availability of these instructions?

sysctl machdep.id_aa64isar0

See for instance security/libgcrypt/patches/patch-src_hwf-arm_c.
(Or grep the ports tree for patches that contain "AA64ISAR0".)

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

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Sep 28 (Thu) at 17:25:57 +0200 (+0200), Omar Polo wrote:
:On 2023/09/28 09:04:02 -0600, phess...@openbsd.org wrote:
:> http://build-failures.rhaalovely.net/aarch64/2023-09-26/archivers/unarr.log
:
:on non-apple arm devices it assumes there is sys/auxv.h and
:asm/hwcap.h and uses getauxval(AT_HWCAP) to see if some features
:(CRC32, SHA1, SHA2 and AES) are supported by the CPU.
:
:This is probably the smallest fix, but it unconditionally disables the
:use of the cpu instructions.  I don't have an aarch64 machine atm and
:can't test.
:

This works for me on my Thinkpad X13s.  OK


:What can we use to detect the availability of these instructions?
:
:Index: patches/patch-lzmasdk_CpuArch_c
:===
:RCS file: patches/patch-lzmasdk_CpuArch_c
:diff -N patches/patch-lzmasdk_CpuArch_c
:--- /dev/null  1 Jan 1970 00:00:00 -
:+++ patches/patch-lzmasdk_CpuArch_c28 Sep 2023 15:21:40 -
:@@ -0,0 +1,14 @@
:+Index: lzmasdk/CpuArch.c
:+--- lzmasdk/CpuArch.c.orig
: lzmasdk/CpuArch.c
:+@@ -760,10 +760,6 @@ BoolInt CPU_IsSupported_AES (void) { return APPLE_CRYP
:+ 
:+ #else // __APPLE__
:+ 
:+-#include 
:+-
:+-#define USE_HWCAP
:+-
:+ #ifdef USE_HWCAP
:+ 
:+ #include 

-- 
It's easier to fight for one's principles than to live up to them.

Re: aarch64 bulk build report

[Omar Polo]

On 2023/09/28 09:04:02 -0600, phess...@openbsd.org wrote:
> http://build-failures.rhaalovely.net/aarch64/2023-09-26/archivers/unarr.log

on non-apple arm devices it assumes there is sys/auxv.h and
asm/hwcap.h and uses getauxval(AT_HWCAP) to see if some features
(CRC32, SHA1, SHA2 and AES) are supported by the CPU.

This is probably the smallest fix, but it unconditionally disables the
use of the cpu instructions.  I don't have an aarch64 machine atm and
can't test.

What can we use to detect the availability of these instructions?

Index: patches/patch-lzmasdk_CpuArch_c
===
RCS file: patches/patch-lzmasdk_CpuArch_c
diff -N patches/patch-lzmasdk_CpuArch_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lzmasdk_CpuArch_c 28 Sep 2023 15:21:40 -
@@ -0,0 +1,14 @@
+Index: lzmasdk/CpuArch.c
+--- lzmasdk/CpuArch.c.orig
 lzmasdk/CpuArch.c
+@@ -760,10 +760,6 @@ BoolInt CPU_IsSupported_AES (void) { return APPLE_CRYP
+ 
+ #else // __APPLE__
+ 
+-#include 
+-
+-#define USE_HWCAP
+-
+ #ifdef USE_HWCAP
+ 
+ #include 

Re: aarch64 bulk build report

[Stuart Henderson]

On 2023/09/14 21:38, Volker Schlecht wrote:
> On 9/14/23 19:58, Peter Hessler wrote:
> > On 2023 Sep 14 (Thu) at 11:37:57 -0600 (-0600), phess...@openbsd.org wrote:
> > :critical path missing pkgs:  
> > http://build-failures.rhaalovely.net/aarch64/2023-09-12/summary.log
> > :
> > :http://build-failures.rhaalovely.net/aarch64/2023-09-12/cad/prusaslicer.log
> > 
> > new port, new failure:
> > 
> [...]
> >   
> > /usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/libslic3r/pchheader.hpp:107:10:
> >  fatal error: 'Eigen/Dense' file not found
> >   #include 
> >^
> >   1 error generated.
> > 
> > Guessing it is a missing dep?
> 
> Seems that configure picks up eigen in your build environment:
> 
> [...]
> -- Found ZLIB: /usr/lib/libz.so.7.0 (found version "1.3")
> -- Found Eigen3: /usr/local/include/eigen3 (Required is at least version
> "3.3")
> -- Could NOT find EXPAT (missing: EXPAT_DIR)
> -- Falling back to MODULE search for EXPAT...
> [...]
> 
> On amd64 I get a clean build both with and without eigen3 - is it
> possible that eigen3 was around during confgure and then removed mid-build?

It's very likely. This is totally normal in a bulk build.
Ports must either list dependencies for everything which they might
pick up, or disable them. It's usually necessary to at least look
through configure output to pick these up (and sometimes things are
picked up which aren't printed by configure).

There are some other issues,

- some libraries used directly by the port are only listed in WANTLIB but
should really be in LIB_DEPENDS so that someone updating those libraries
knows that it might affect prusaslicer: graphics/png, net/curl

- LIB_DEPENDS on devel/gmp is missing (gmp,-cxx is still needed as a
BUILD_DEPENDS because it picks up the headers for something, but doesn't
seem to actually link the library so no WANTLIB/LIB_DEPENDS)

- cmake picks up archivers/blosc if present, though it's not clear what
it does with it... may also need a BUILD_DEPENDS
"-- Found Blosc: /usr/local/lib/libblosc.so.2.0 (found version "1.21.4")"

(and, unless there's a particular reason, e.g. to keep in sync with
ordering used upstream in a configure script or similar to assist in
checking for changed deps after a version update, we generally keep
LIB_DEPENDS in alphabetic order)

Re: aarch64 bulk build report

[Volker Schlecht]

On 9/14/23 19:58, Peter Hessler wrote:

On 2023 Sep 14 (Thu) at 11:37:57 -0600 (-0600), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-09-12/summary.log
:
:http://build-failures.rhaalovely.net/aarch64/2023-09-12/cad/prusaslicer.log

new port, new failure:


[...]

  
/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/libslic3r/pchheader.hpp:107:10:
 fatal error: 'Eigen/Dense' file not found
  #include 
   ^
  1 error generated.

Guessing it is a missing dep?


Seems that configure picks up eigen in your build environment:

[...]
-- Found ZLIB: /usr/lib/libz.so.7.0 (found version "1.3")
-- Found Eigen3: /usr/local/include/eigen3 (Required is at least version 
"3.3")

-- Could NOT find EXPAT (missing: EXPAT_DIR)
-- Falling back to MODULE search for EXPAT...
[...]

On amd64 I get a clean build both with and without eigen3 - is it
possible that eigen3 was around during confgure and then removed mid-build?

Anyhow, it also builds and portchecks fine with the attached diff... I 
have nothing to slice, though.




Index: Makefile
===
RCS file: /cvs/ports/cad/prusaslicer/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile	12 Sep 2023 00:46:55 -	1.1.1.1
+++ Makefile	14 Sep 2023 19:36:26 -
@@ -6,6 +6,7 @@ PKGNAME =	prusaslicer-${V}
 GH_ACCOUNT =	prusa3d
 GH_PROJECT =	PrusaSlicer
 GH_TAGNAME =	version_${V}
+REVISION =	0
 
 CATEGORIES =	cad
 
@@ -39,7 +40,8 @@ MODULES =		devel/cmake \
 MODGNOME_TOOLS =	desktop-file-utils gtk-update-icon-cache
 
 BUILD_DEPENDS =		devel/cereal \
-			devel/gmp,-cxx
+			devel/gmp,-cxx \
+			math/eigen3
 
 LIB_DEPENDS =		devel/tbb \
 			math/nlopt \

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Sep 14 (Thu) at 11:37:57 -0600 (-0600), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-09-12/summary.log
:
:http://build-failures.rhaalovely.net/aarch64/2023-09-12/cad/prusaslicer.log

new port, new failure:

 /usr/obj/ports/prusaslicer-2.5.2/bin/c++ -DBOOST_LOG_DYN_LINK 
-DLIBNEST2D_GEOMETRIES_libslic3r -DLIBNEST2D_OPTIMIZER_nlopt -DLIBNEST2D_STATIC 
-DLIBNEST2D_THREADING_tbb -DOPENVDB_ABI_VERSION_NUMBER=10 
-DOPENVDB_USE_DELAYED_LOADING -DSLIC3R_GUI -DTBB_USE_CAPTURED_EXCEPTION=0 
-DUNICODE -DUSE_TBB -DWXINTL_NO_GETTEXT_MACRO -D_UNICODE 
-DwxNO_UNSAFE_WXSTRING_CONV -DwxUSE_UNICODE -I/usr/local/include/dbus-1.0 
-I/usr/local/lib/dbus-1.0/include 
-I/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src 
-I/usr/obj/ports/prusaslicer-2.5.2/build-aarch64/src/platform 
-I/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/libslic3r 
-I/usr/obj/ports/prusaslicer-2.5.2/build-aarch64/src/libslic3r 
-I/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/libnest2d/include
 -I/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/miniz 
-I/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/glu-libtess/include
 -isystem /usr/local/include/eigen3 -isystem /usr/local/include -isystem 
/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/libigl -O2 -pipe 
-Wall -Wno-reorder -DNDEBUG -std=gnu++17 -fPIC -fsigned-char 
-Werror=return-type -Wno-ignored-attributes -Wno-deprecated-declarations 
-pthread -Winvalid-pch -fpch-instantiate-templates -Xclang -emit-pch -Xclang 
-include -Xclang 
/usr/obj/ports/prusaslicer-2.5.2/build-aarch64/src/libslic3r/CMakeFiles/libslic3r.dir/cmake_pch.hxx
 -x c++-header -MD -MT src/libslic3r/CMakeFiles/libslic3r.dir/cmake_pch.hxx.pch 
-MF src/libslic3r/CMakeFiles/libslic3r.dir/cmake_pch.hxx.pch.d -o 
src/libslic3r/CMakeFiles/libslic3r.dir/cmake_pch.hxx.pch -c 
/usr/obj/ports/prusaslicer-2.5.2/build-aarch64/src/libslic3r/CMakeFiles/libslic3r.dir/cmake_pch.hxx.cxx
 In file included from :1:
 In file included from 
/usr/obj/ports/prusaslicer-2.5.2/build-aarch64/src/libslic3r/CMakeFiles/libslic3r.dir/cmake_pch.hxx:5:
 
/usr/obj/ports/prusaslicer-2.5.2/PrusaSlicer-version_2.5.2/src/libslic3r/pchheader.hpp:107:10:
 fatal error: 'Eigen/Dense' file not found
 #include 
  ^
 1 error generated.

Guessing it is a missing dep?


:http://build-failures.rhaalovely.net/aarch64/2023-09-12/emulators/mame.log

same as it ever was

:http://build-failures.rhaalovely.net/aarch64/2023-09-12/graphics/evince,light.log

sporadic failure, didn't catch it in time.


:http://build-failures.rhaalovely.net/aarch64/2023-09-12/x11/gnustep/base.log
same as it ever was


-- 
Horse sense is the thing a horse has which keeps it from betting on
people.
-- W. C. Fields

Re: aarch64 bulk build report

[Christian Weisgerber]

Peter Hessler:

> :http://build-failures.rhaalovely.net/aarch64/2023-08-25/emulators/mame.log
> 
> fatal error: error in backend: Cannot select: intrinsic %llvm.aarch64.crc32b

I looked at this error when it first appeared.  The underlying
problem is this:

#define ATTRIB_CRC __attribute__((__target__("arch=armv8-a+crc")))
 ^
../../../../../3rdparty/lzma/C/7zCrc.c:160:1: warning: unknown architecture 
'armv8-a+crc' in the 'target' attribute string; 'target' attribute ignored 
[-Wignored-attributes]

MAME has imported a new revision of the LZMA SDK, which tries to
use special CRC instructions on aarch64 as an optimization.  Apparently,
this doesn't work with clang.

FreeBSD has patches to fix the build on aarch64 and armv7, but after
looking them over, I was not convinced that they were correct or
even that the upstream LZMA code does what it is intended to do.
The idea seems to be to build alternative code paths with and without
CRC extensions and pick the right one at runtime, depending on
what's available on the CPU.  The logic didn't look right to me,
though.  Then again, I may have misunderstood it.

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

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Aug 27 (Sun) at 05:41:56 -0600 (-0600), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-08-25/summary.log

:http://build-failures.rhaalovely.net/aarch64/2023-08-25/editors/libreoffice.log

fixed


:http://build-failures.rhaalovely.net/aarch64/2023-08-25/emulators/mame.log

fatal error: error in backend: Cannot select: intrinsic %llvm.aarch64.crc32b


:http://build-failures.rhaalovely.net/aarch64/2023-08-25/x11/gnustep/base.log

NSRegularExpression.m:685:6: warning: Your compiler does not support blocks.  
NSRegularExpression will deviate from the documented behaviour when subclassing 
and any code that subclasses NSRegularExpression may break in unexpected ways.  
If you must subclass NSRegularExpression, you may want to use a compiler with 
blocks support. [-W#warnings]
#warning Your compiler does not support blocks.  NSRegularExpression will 
deviate from the documented behaviour when subclassing and any code that 
subclasses NSRegularExpression may break in unexpected ways.  If you must 
subclass NSRegularExpression, you may want to use a compiler with blocks 
support.
 ^
NSRegularExpression.m:686:6: warning: Your compiler would support blocks if you 
added -fblocks to your OBJCFLAGS [-W#warnings]
#warning Your compiler would support blocks if you added -fblocks to your 
OBJCFLAGS
 ^
2 warnings generated.
...
cc GSEasyHandle.m -c \
  -MMD -MP -I/usr/local/include/gnustep -DGNUSTEP_TARGET_DIR=\".\" 
-DGNUSTEP_TARGET_CPU=\"aarch64\" -DGNUSTEP_TARGET_OS=\"openbsd7.3\" 
-DGNUSTEP_IS_FLATTENED=\"yes\" -DLIBRARY_COMBO=\"gnu-gnu-gnu\" 
-DGNUSTEP_BASE_INTERNAL=1 -Wall -Wdeclaration-after-statement -Wcast-align 
-DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 
-fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS 
-pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -O2 -pipe 
-fobjc-runtime=gcc -fobjc-runtime=gcc -fconstant-string-class=NSConstantString 
-I../Headers -I./. -I. 
-I/gnustep-base-1.29.0_writes_to_HOME/GNUstep/Library/Headers 
-I/usr/local/include -I/usr/local/include -I/usr/local/include/gnustep 
-I/usr/local/include -I/usr/local/include -I/usr/local/include 
-I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include 
-I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include 
-I/usr/local/include/p11-kit-1 \
   -o obj/libgnustep-base.obj/GSEasyHandle.m.o
In file included from GSEasyHandle.m:2:
././GSEasyHandle.h:48:40: error: blocks support disabled - compile with 
-fblocks or pick a deployment target that supports them
result: (void (^)(GSEasyHandleWriteBufferResult result, 
NSInteger length, NSData *data))result;
   ^
In file included from GSEasyHandle.m:3:



-- 
Every morning, I get up and look through the "Forbes" list of the
richest people in America.  If I'm not there, I go to work.
-- Robert Orben

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jul 24 (Mon) at 15:25:14 -0600 (-0600), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Sat Jul 22 07:47:34 MDT 2023
:finished at Mon Jul 24 15:25:01 MDT 2023
:lasted 2D07h37m
:done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2203: Sat Jul 22 
00:42:20 MDT 2023
:
:built packages:11641
:Jul 22:3801
:Jul 23:1725
:Jul 24:6114
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-07-22/summary.log
:
:build failures: 3
:http://build-failures.rhaalovely.net/aarch64/2023-07-22/games/lwjgl3.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-22/graphics/evince,light.log

[231/310] /usr/local/bin/gi-docgen generate --quiet --fatal-warnings 
--config=help/reference/libdocument/libevdocument.toml 
--output-dir=help/reference/libdocument/libevdocument --no-namespace-dir 
--content-dir=/usr/obj/ports/evince-44.3-light/evince-44.3/help/reference/libdocument
 libdocument/EvinceDocument-3.0.gir
FAILED: help/reference/libdocument/libevdocument 
/usr/local/bin/gi-docgen generate --quiet --fatal-warnings 
--config=help/reference/libdocument/libevdocument.toml 
--output-dir=help/reference/libdocument/libevdocument --no-namespace-dir 
--content-dir=/usr/obj/ports/evince-44.3-light/evince-44.3/help/reference/libdocument
 libdocument/EvinceDocument-3.0.gir
WARNING: Unable to process dot data: [Errno 2] No such file or directory: 'dot'

missing BDEP on math/graphviz ?


:http://build-failures.rhaalovely.net/aarch64/2023-07-22/x11/qt5/qtwebengine.log
:
:recurrent failures
: failures/games/lwjgl3.log
: failures/x11/qt5/qtwebengine.log
:new failures
:+++ ls-failuresMon Jul 24 15:25:13 2023
:+failures/graphics/evince,light.log

-- 
We can predict everything, except the future.

Re: aarch64 bulk build report

[Thomas Frohwein]

On Fri, Jul 21, 2023 at 08:36:06AM +0200, Peter Hessler wrote:
> Huge amount of fallout from the SDL update.

from looking through the logs with:
ld: error: unable to find library -lSDL2-2.0

and seeing that everything now built on amd64, it looks to me like your
bulk probably ran before jca@ kindly fixing the patch file in sdl2 [1].

[1] https://marc.info/?l=openbsd-ports-cvs&m=168981461422750&w=2

> A noticable non-sdl related fallout:
[...]

Re: aarch64 bulk build report

[Peter Hessler]

Huge amount of fallout from the SDL update.

A noticable non-sdl related fallout:

:http://build-failures.rhaalovely.net/aarch64/2023-07-19/x11/qt5/qtwebengine.log
FAILED: gen/v8/embedded.S gen/v8/snapshot.cc 
/usr/obj/ports/qtwebengine-5.15.10/bin/python
../../../../src/3rdparty/chromium/v8/tools/run.py ./mksnapshot 
--turbo_instruction_scheduling --target_os=openbsd --target_arch=arm64 
--embedded_src gen/v8/embedded.S --embedded_variant Default --random-seed 
314159265 --startup_src gen/v8/snapshot.cc --no-native-code-counters
#
# Fatal error in , line 0
# Fatal process out of memory: Failed to reserve memory for new V8 Isolate




On 2023 Jul 21 (Fri) at 00:22:58 -0600 (-0600), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Wed Jul 19 03:58:46 MDT 2023
:finished at Fri Jul 21 00:22:42 MDT 2023
:lasted 1D20h23m
:done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2199: Tue Jul 18 
13:14:41 MDT 2023
:
:built packages:10957
:Jul 19:4217
:Jul 20:4940
:Jul 21:1799
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-07-19/summary.log
:
:build failures: 54
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/archivers/zziplib.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/audio/adplay.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/audio/audiality2.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/audio/schismtracker.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/codeblocks.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/sdl2-gfx.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/sdl2-image.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/sdl2-mixer.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/sdl2-net.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/sdl2-pango.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/sdl2-ttf.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/devel/smpeg2.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/advancemame.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/emulationstation.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/fs-uae.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/fuse.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/mednafen.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/mupen64plus/ui-console.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/mupen64plus/video-glide64mk2.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/nestopia.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/qemu,-ga.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/sameboy,-libretro.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/snes9x.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/stella.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/emulators/vbam.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/bzflag.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/eduke32.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/endless-sky.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/ezquake.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/freeorion.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/love/0.10.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/love/11.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/lugaru.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/lwjgl3.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/nblood.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/openrct2.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/postal.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/quakespasm.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/scummvm.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/sdl-jstest.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/teeworlds.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/tic80.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/uqm/uqm.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/vkquake.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/wrath.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/games/zelda3.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/geo/spatialite/gui.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/graphics/ffmpeg.log
:http://build-failures.rhaalovely.net/aarch64/2023-07-19/graphics/libqrencode.log
:http://build-failures.rhaalove

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jul 15 (Sat) at 07:14:08 +0200 (+0200), Rafael Sadowski wrote:
:On Fri Jul 14, 2023 at 07:01:43AM -0600, phess...@openbsd.org wrote:
:> bulk build on arm64.ports.openbsd.org
:> started on  Wed Jul 12 00:15:28 MDT 2023
:> finished at Fri Jul 14 07:01:29 MDT 2023
:> lasted 2D06h46m
:> done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2188: Mon Jul 10 
14:25:11 MDT 2023
:> 
:> built packages:11632
:> Jul 12:4144
:> Jul 13:3045
:> Jul 14:4442
:> 
:> 
:> critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-07-12/summary.log
:> 
:> build failures: 3
:> 
http://build-failures.rhaalovely.net/aarch64/2023-07-12/emulators/qemu,-ga.log
:> http://build-failures.rhaalovely.net/aarch64/2023-07-12/games/lwjgl3.log
:> 
http://build-failures.rhaalovely.net/aarch64/2023-07-12/x11/qt5/qtwebengine.log
:
:
:I think I have forgotten something here...
:https://github.com/openbsd/ports/commit/c5e352c5ad13660f0f776ff76dd50938d3fc780d#diff-8f2b3d2c3c34018653754a138bfea6016d6ea85f3f0f5c86f53a9e011fd37eb8
:
:Lets bring it back. Could you give it a spin?
:

This allows the build to progress farther, so OK



:diff --git 
a/x11/qt5/qtwebengine/patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRasterPipeline_opts_h
 
b/x11/qt5/qtwebengine/patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRasterPipeline_opts_h
:new file mode 100644
:index 000..332804ac499
:--- /dev/null
:+++ 
b/x11/qt5/qtwebengine/patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRasterPipeline_opts_h
:@@ -0,0 +1,22 @@
:+Revert b2de8e8046dc1c558465f74b4afe11d57cbc6cf3 (with new defined check)
:+Index: src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h
:+--- 
src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h.orig
: src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h
:+@@ -980,7 +980,7 @@ SI F approx_powf(F x, F y) {
:+ SI F from_half(U16 h) {
:+ #if defined(JUMPER_IS_NEON) && defined(SK_CPU_ARM64) \
:+ && !defined(SK_BUILD_FOR_GOOGLE3)  // Temporary workaround for some 
Google3 builds.
:+-#if defined(SK_BUILD_FOR_MAC)
:++#if defined(SK_BUILD_FOR_MAC) || defined(__OpenBSD__)
:+ return vcvt_f32_f16(h);
:+ #else
:+ __fp16 fp16;
:+@@ -1006,7 +1006,7 @@ SI F from_half(U16 h) {
:+ SI U16 to_half(F f) {
:+ #if defined(JUMPER_IS_NEON) && defined(SK_CPU_ARM64) \
:+ && !defined(SK_BUILD_FOR_GOOGLE3)  // Temporary workaround for some 
Google3 builds.
:+-#if defined(SK_BUILD_FOR_MAC)
:++#if defined(SK_BUILD_FOR_MAC) || defined(__OpenBSD__)
:+ return vcvt_f16_f32(f);
:+ #else
:+ __fp16 fp16 = __fp16(f);
:

-- 
Outside of a dog, a book is a man's best friend: and inside a dog,
it's too dark to read.
-- Groucho Marx

Re: aarch64 bulk build report

[Rafael Sadowski]

On Fri Jul 14, 2023 at 07:01:43AM -0600, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Wed Jul 12 00:15:28 MDT 2023
> finished at Fri Jul 14 07:01:29 MDT 2023
> lasted 2D06h46m
> done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2188: Mon Jul 10 
> 14:25:11 MDT 2023
> 
> built packages:11632
> Jul 12:4144
> Jul 13:3045
> Jul 14:4442
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2023-07-12/summary.log
> 
> build failures: 3
> http://build-failures.rhaalovely.net/aarch64/2023-07-12/emulators/qemu,-ga.log
> http://build-failures.rhaalovely.net/aarch64/2023-07-12/games/lwjgl3.log
> http://build-failures.rhaalovely.net/aarch64/2023-07-12/x11/qt5/qtwebengine.log


I think I have forgotten something here...
https://github.com/openbsd/ports/commit/c5e352c5ad13660f0f776ff76dd50938d3fc780d#diff-8f2b3d2c3c34018653754a138bfea6016d6ea85f3f0f5c86f53a9e011fd37eb8

Lets bring it back. Could you give it a spin?

diff --git 
a/x11/qt5/qtwebengine/patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRasterPipeline_opts_h
 
b/x11/qt5/qtwebengine/patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRasterPipeline_opts_h
new file mode 100644
index 000..332804ac499
--- /dev/null
+++ 
b/x11/qt5/qtwebengine/patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRasterPipeline_opts_h
@@ -0,0 +1,22 @@
+Revert b2de8e8046dc1c558465f74b4afe11d57cbc6cf3 (with new defined check)
+Index: src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h
+--- 
src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h.orig
 src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h
+@@ -980,7 +980,7 @@ SI F approx_powf(F x, F y) {
+ SI F from_half(U16 h) {
+ #if defined(JUMPER_IS_NEON) && defined(SK_CPU_ARM64) \
+ && !defined(SK_BUILD_FOR_GOOGLE3)  // Temporary workaround for some 
Google3 builds.
+-#if defined(SK_BUILD_FOR_MAC)
++#if defined(SK_BUILD_FOR_MAC) || defined(__OpenBSD__)
+ return vcvt_f32_f16(h);
+ #else
+ __fp16 fp16;
+@@ -1006,7 +1006,7 @@ SI F from_half(U16 h) {
+ SI U16 to_half(F f) {
+ #if defined(JUMPER_IS_NEON) && defined(SK_CPU_ARM64) \
+ && !defined(SK_BUILD_FOR_GOOGLE3)  // Temporary workaround for some 
Google3 builds.
+-#if defined(SK_BUILD_FOR_MAC)
++#if defined(SK_BUILD_FOR_MAC) || defined(__OpenBSD__)
+ return vcvt_f16_f32(f);
+ #else
+ __fp16 fp16 = __fp16(f);

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jul 14 (Fri) at 07:01:43 -0600 (-0600), phess...@openbsd.org wrote:
:http://build-failures.rhaalovely.net/aarch64/2023-07-12/emulators/qemu,-ga.log

Program sphinx-build found: YES (/usr/local/bin/sphinx-build)
../qemu-8.0.0/docs/meson.build:25: WARNING: /usr/local/bin/sphinx-build: 
Extension error:
Could not import extension sphinxcontrib.jquery (exception: No module
named 'sphinxcontrib.jquery')
...
  Configurable features
Documentation: NO
...
Error: /usr/obj/ports/qemu-8.0.0/fake-aarch64/usr/local/man/man1/qemu-img.1 
does not exist
Error: 
/usr/obj/ports/qemu-8.0.0/fake-aarch64/usr/local/man/man1/qemu-storage-daemon.1 
does not exist
Error: /usr/obj/ports/qemu-8.0.0/fake-aarch64/usr/local/man/man1/qemu.1 does 
not exist
etc etc etc

:http://build-failures.rhaalovely.net/aarch64/2023-07-12/games/lwjgl3.log

known problem


:http://build-failures.rhaalovely.net/aarch64/2023-07-12/x11/qt5/qtwebengine.log

FAILED: obj/skia/skia_core_and_effects/SkOpts.o 
...
../../../../src/3rdparty/chromium/third_party/skia/src/opts/SkRasterPipeline_opts.h:1012:19:
error: functional-style cast from 'neon::F' (aka 'V') to '__fp16' is not 
allowed
__fp16 fp16 = __fp16(f);
  ^~~~



-- 
A transistor protected by a fast-acting fuse will protect the fuse by
blowing first.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jul 09 (Sun) at 10:46:24 -0600 (-0600), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Fri Jul 7 00:50:21 MDT 2023
:finished at Sun Jul 9 10:46:12 MDT 2023
:lasted 2D09h55m
:done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2182: Thu Jul  6 
15:02:37 MDT 2023
:
:built packages:11683
:Jul 7:3439
:Jul 8:2750
:Jul 9:5493
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-07-07/summary.log
:
:build failures: 4
:http://build-failures.rhaalovely.net/aarch64/2023-07-07/cad/pcb2gcode.log

already fixed


:http://build-failures.rhaalovely.net/aarch64/2023-07-07/games/lwjgl3.log

assumes arm64 is a variant of x86


:http://build-failures.rhaalovely.net/aarch64/2023-07-07/x11/gnome/seahorse-nautilus.log

already fixed


:http://build-failures.rhaalovely.net/aarch64/2023-07-07/x11/mate/utils.log

blows up ?semi? randomly


:
:recurrent failures
: failures/games/lwjgl3.log
:new failures
:+++ ls-failuresSun Jul  9 10:46:24 2023
:+failures/cad/pcb2gcode.log
:+failures/x11/gnome/seahorse-nautilus.log
:+failures/x11/mate/utils.log
:resolved failures
:--- ../old/aarch64/last//ls-failures   Wed Jul  5 12:30:43 2023
:

-- 
A banker is a fellow who lends you his umbrella when the sun is shining
and wants it back the minute it begins to rain.
-- Mark Twain

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 May 13 (Sat) at 18:08:52 +0200 (+0200), Theo Buehler wrote:
:On Sat, May 13, 2023 at 05:37:01PM +0200, Peter Hessler wrote:
:> On 2023 May 13 (Sat) at 17:22:55 +0200 (+0200), Theo Buehler wrote:
:> :> 
http://build-failures.rhaalovely.net/aarch64/2023-05-11/net/unison,no_x11.log
:> :
:> :As already mentioned elsewhere, this is the strange USE_NOEXECONLY
:> :thing that affects some ocaml ports on aarch64. I think it should be
:> :marked as such on aarch64 until someone figures out why this is needed
:> :for aarch64 and not amd64.
:> 
:> I tried that, but it doesn't make a difference when building on my X13s.
:
:This builds and packages both flavors on my m1. I use llvm15 on it, so
:it could be a difference in code generation. If that doesn't work for
:you, I guess we have to mark it BROKEN-aarch64 until we update to llvm15
:

Could be code generation, it doesn't build for me with in-tree llvm13.

OK for this, and we can probably also add BROKEN-aarch64 at the same
time.


:Index: Makefile
:===
:RCS file: /cvs/ports/net/unison/Makefile,v
:retrieving revision 1.22
:diff -u -p -r1.22 Makefile
:--- Makefile   28 Apr 2023 06:01:41 -  1.22
:+++ Makefile   13 May 2023 16:06:53 -
:@@ -1,3 +1,7 @@
:+.if ${MACHINE_ARCH} == aarch64
:+USE_NOEXECONLY = yes
:+.endif
:+
: COMMENT = multi-platform file synchronization tool
: 
: GH_ACCOUNT =  bcpierce00

-- 
The goal of science is to build better mousetraps.
The goal of nature is to build better mice.

Re: aarch64 bulk build report

[Theo Buehler]

On Sat, May 13, 2023 at 05:37:01PM +0200, Peter Hessler wrote:
> On 2023 May 13 (Sat) at 17:22:55 +0200 (+0200), Theo Buehler wrote:
> :> 
> http://build-failures.rhaalovely.net/aarch64/2023-05-11/net/unison,no_x11.log
> :
> :As already mentioned elsewhere, this is the strange USE_NOEXECONLY
> :thing that affects some ocaml ports on aarch64. I think it should be
> :marked as such on aarch64 until someone figures out why this is needed
> :for aarch64 and not amd64.
> 
> I tried that, but it doesn't make a difference when building on my X13s.

This builds and packages both flavors on my m1. I use llvm15 on it, so
it could be a difference in code generation. If that doesn't work for
you, I guess we have to mark it BROKEN-aarch64 until we update to llvm15

Index: Makefile
===
RCS file: /cvs/ports/net/unison/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile28 Apr 2023 06:01:41 -  1.22
+++ Makefile13 May 2023 16:06:53 -
@@ -1,3 +1,7 @@
+.if ${MACHINE_ARCH} == aarch64
+USE_NOEXECONLY = yes
+.endif
+
 COMMENT =  multi-platform file synchronization tool
 
 GH_ACCOUNT =   bcpierce00

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 May 13 (Sat) at 17:22:55 +0200 (+0200), Theo Buehler wrote:
:> http://build-failures.rhaalovely.net/aarch64/2023-05-11/net/unison,no_x11.log
:
:As already mentioned elsewhere, this is the strange USE_NOEXECONLY
:thing that affects some ocaml ports on aarch64. I think it should be
:marked as such on aarch64 until someone figures out why this is needed
:for aarch64 and not amd64.

I tried that, but it doesn't make a difference when building on my X13s.


-- 
For three days after death hair and fingernails continue to grow but
phone calls taper off.
-- Johnny Carson

Re: aarch64 bulk build report

[Theo Buehler]

> http://build-failures.rhaalovely.net/aarch64/2023-05-11/net/unison,no_x11.log

As already mentioned elsewhere, this is the strange USE_NOEXECONLY
thing that affects some ocaml ports on aarch64. I think it should be
marked as such on aarch64 until someone figures out why this is needed
for aarch64 and not amd64.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Apr 14 (Fri) at 07:46:48 -0600 (-0600), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-04-11/summary.log
:
:build failures: 2
:http://build-failures.rhaalovely.net/aarch64/2023-04-11/editors/poke.log

Missing build (+possibly run?) dep on emacs.


:http://build-failures.rhaalovely.net/aarch64/2023-04-11/x11/qt6/qt3d.log
:

Error:
/usr/obj/ports/qt6-qt3d-6.5.0/fake-aarch64/usr/local/include/X11/qt6/Qt3DCore/6.5.0/Qt3DCore/private/matrix4x4_sse_p.h
does not exist
Error:
/usr/obj/ports/qt6-qt3d-6.5.0/fake-aarch64/usr/local/include/X11/qt6/Qt3DCore/6.5.0/Qt3DCore/private/vector3d_sse_p.h
does not exist
Error:
/usr/obj/ports/qt6-qt3d-6.5.0/fake-aarch64/usr/local/include/X11/qt6/Qt3DCore/6.5.0/Qt3DCore/private/vector4d_sse_p.h
does not exist

arch specific files fell in, and aren't available on this arch


-- 
All the passions make us commit faults; love makes us commit the most
ridiculous ones.
-- La Rochefoucauld

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Mar 08 (Wed) at 13:47:06 -0700 (-0700), phess...@openbsd.org wrote:
:
:build failures: 3
:http://build-failures.rhaalovely.net/aarch64/2023-03-06/audio/p5-Music-Audioscrobbler-MPD.log
:http://build-failures.rhaalovely.net/aarch64/2023-03-06/productivity/thinkingrock.log

fallout from changing PATCHORIG, already fixed


:http://build-failures.rhaalovely.net/aarch64/2023-03-06/textproc/sp.log
:

packaged and built fine, was in H= when dpb exited.


-- 
Nobody wants constructive criticism.
It's all we can do to put up with constructive praise.

Re: aarch64 bulk build report

[Kevin Lo]

On Sat, Feb 25, 2023 at 04:11:52PM +0100, Theo Buehler wrote:
> 
> > http://build-failures.rhaalovely.net/aarch64/2023-02-22/devel/riscv-elf/gcc.log
> 
> This fails to build if lang/gcc/8 is installed because it picks up the
> old ansidecl.h which misses a few #defines.
> 
> One option is to define the missing ones away. Defining them to the
> right thing is harder since they are passed through several shells, so
> getting the quoting right is tricky.
> 
> Hopefully someone else has a better idea.

Today I tried to install devel/riscv-elf/gcc on amd64 and encountered the same
error.  I confirm that your diff fixes the problem, thanks.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Feb 25 (Sat) at 16:11:52 +0100 (+0100), Theo Buehler wrote:
:> 
http://build-failures.rhaalovely.net/aarch64/2023-02-22/devel/riscv-elf/gcc.log
:
:This fails to build if lang/gcc/8 is installed because it picks up the
:old ansidecl.h which misses a few #defines.
:
:One option is to define the missing ones away. Defining them to the
:right thing is harder since they are passed through several shells, so
:getting the quoting right is tricky.
:
:Hopefully someone else has a better idea.
:

with this patch, on arm64 I can build riscv-elf-gcc and that can build
riscv-elf-newlib.

OK


:Index: gcc/Makefile
:===
:RCS file: /cvs/ports/devel/riscv-elf/gcc/Makefile,v
:retrieving revision 1.9
:diff -u -p -r1.9 Makefile
:--- gcc/Makefile   19 Feb 2023 13:55:04 -  1.9
:+++ gcc/Makefile   25 Feb 2023 15:00:30 -
:@@ -3,7 +3,7 @@ COMMENT=   gcc for riscv-elf cross-develop
: VERSION=  12.2.0
: DISTNAME= gcc-${VERSION}
: PKGNAME=  riscv-elf-gcc-${VERSION}
:-REVISION= 0
:+REVISION= 1
: 
: SUBST_VARS+=  VERSION
: 
:@@ -37,8 +37,13 @@ CONFIGURE_ARGS+=--enable-languages=${LAN
:   --enable-cpp\
:   --without-isl   \
:   --without-zstd
:-CONFIGURE_ENV=CPPFLAGS="-I${LOCALBASE}/include" \
:+CONFIGURE_ENV=CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include" \
:   LDFLAGS="-L${LOCALBASE}/lib"
:+
:+# Avoid build failure when lang/gcc/8 is installed whose ansidecl.h misses 
these
:+CPPFLAGS +=   -DATTRIBUTE_NONSTRING= -DATTRIBUTE_RESULT_SIZE_1=
:+CPPFLAGS +=   -DATTRIBUTE_RESULT_SIZE_2= -DATTRIBUTE_RESULT_SIZE_1_2=
:+CPPFLAGS +=   -DATTRIBUTE_WARN_UNUSED_RESULT=
: 
: SEPARATE_BUILD=   Yes
: USE_GMAKE=Yes

-- 
One can't proceed from the informal to the formal by formal means.

Re: aarch64 bulk build report

[Theo Buehler]

> http://build-failures.rhaalovely.net/aarch64/2023-02-22/devel/riscv-elf/gcc.log

This fails to build if lang/gcc/8 is installed because it picks up the
old ansidecl.h which misses a few #defines.

One option is to define the missing ones away. Defining them to the
right thing is harder since they are passed through several shells, so
getting the quoting right is tricky.

Hopefully someone else has a better idea.

Index: gcc/Makefile
===
RCS file: /cvs/ports/devel/riscv-elf/gcc/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- gcc/Makefile19 Feb 2023 13:55:04 -  1.9
+++ gcc/Makefile25 Feb 2023 15:00:30 -
@@ -3,7 +3,7 @@ COMMENT=gcc for riscv-elf cross-develop
 VERSION=   12.2.0
 DISTNAME=  gcc-${VERSION}
 PKGNAME=   riscv-elf-gcc-${VERSION}
-REVISION=  0
+REVISION=  1
 
 SUBST_VARS+=   VERSION
 
@@ -37,8 +37,13 @@ CONFIGURE_ARGS+=--enable-languages=${LAN
--enable-cpp\
--without-isl   \
--without-zstd
-CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
+CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS} -I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
+
+# Avoid build failure when lang/gcc/8 is installed whose ansidecl.h misses 
these
+CPPFLAGS +=-DATTRIBUTE_NONSTRING= -DATTRIBUTE_RESULT_SIZE_1=
+CPPFLAGS +=-DATTRIBUTE_RESULT_SIZE_2= -DATTRIBUTE_RESULT_SIZE_1_2=
+CPPFLAGS +=-DATTRIBUTE_WARN_UNUSED_RESULT=
 
 SEPARATE_BUILD=Yes
 USE_GMAKE= Yes

Re: aarch64 bulk build report

[Pascal Stumpf]

On Thu, 16 Feb 2023 09:49:17 +0100, Peter Hessler wrote:
> On 2023 Feb 15 (Wed) at 22:09:05 +0100 (+0100), Theo Buehler wrote:
> :> 
> http://build-failures.rhaalovely.net/aarch64/2023-02-13/graphics/openscenegraph.log
> :
> :This is a hidden dep on cad/oce. Not sure if it is desirable to add this
> :relatively heavy dependency or if it's better to neuter it.
> :
> :It seems that there are various other hidden deps. For instance, my logs
> :suggest that the curl module may or may not be picked up. It would be
> :nice if someone who likes dealing with cmake could fix this.
> :
> 
> Here's a patch to disable the hidden dep on cad/oce, OK?

OK.

> curl is already listed in the port as a lib depends, so I don't think I
> should change anything there.

Yep, and that dep is there on purpose.

> Index: Makefile
> ===
> RCS file: /cvs/openbsd/ports/graphics/openscenegraph/Makefile,v
> retrieving revision 1.30
> diff -u -p -u -p -r1.30 Makefile
> --- Makefile  30 Dec 2022 00:13:29 -  1.30
> +++ Makefile  16 Feb 2023 08:44:30 -
> @@ -10,7 +10,7 @@ GH_ACCOUNT =openscenegraph
>  GH_PROJECT = OpenSceneGraph
>  GH_TAGNAME = OpenSceneGraph-$V
>  DISTNAME =   openscenegraph-${V}
> -REVISION =   3
> +REVISION =   4
>  
>  SUBST_VARS +=V
>  
> @@ -64,6 +64,8 @@ LIB_DEPENDS =   devel/sdl \
>   x11/gnome/librsvg
>  
>  NO_TEST =Yes
> +
> +CONFIGURE_ARGS +=-DCMAKE_DISABLE_FIND_PACKAGE_OpenCascade:Bool=Yes
>  
>  # Fix build with OpenEXR>=3 (Imath split)
>  CXXFLAGS +=  -I${LOCALBASE}/include/Imath
> 
> 

Re: aarch64 bulk build report

[Theo Buehler]

On Thu, Feb 16, 2023 at 09:49:17AM +0100, Peter Hessler wrote:
> On 2023 Feb 15 (Wed) at 22:09:05 +0100 (+0100), Theo Buehler wrote:
> :> 
> http://build-failures.rhaalovely.net/aarch64/2023-02-13/graphics/openscenegraph.log
> :
> :This is a hidden dep on cad/oce. Not sure if it is desirable to add this
> :relatively heavy dependency or if it's better to neuter it.
> :
> :It seems that there are various other hidden deps. For instance, my logs
> :suggest that the curl module may or may not be picked up. It would be
> :nice if someone who likes dealing with cmake could fix this.
> :
> 
> Here's a patch to disable the hidden dep on cad/oce, OK?

Thanks. Certainly makes more sense than adding the dep.

ok

> +CONFIGURE_ARGS += -DCMAKE_DISABLE_FIND_PACKAGE_OpenCascade:Bool=Yes

Remind me... What's not to like about cmake?

> curl is already listed in the port as a lib depends, so I don't think I
> should change anything there.

Right. I was confused by

-- Could NOT find CURL (missing: CURL_DIR)

in the log.

Taking another look, it seems that all other optional deps that exist in
the ports tree are hidden away from the usual include paths, so they
should not be picked up.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Feb 15 (Wed) at 22:09:05 +0100 (+0100), Theo Buehler wrote:
:> 
http://build-failures.rhaalovely.net/aarch64/2023-02-13/graphics/openscenegraph.log
:
:This is a hidden dep on cad/oce. Not sure if it is desirable to add this
:relatively heavy dependency or if it's better to neuter it.
:
:It seems that there are various other hidden deps. For instance, my logs
:suggest that the curl module may or may not be picked up. It would be
:nice if someone who likes dealing with cmake could fix this.
:

Here's a patch to disable the hidden dep on cad/oce, OK?

curl is already listed in the port as a lib depends, so I don't think I
should change anything there.


Index: Makefile
===
RCS file: /cvs/openbsd/ports/graphics/openscenegraph/Makefile,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 Makefile
--- Makefile30 Dec 2022 00:13:29 -  1.30
+++ Makefile16 Feb 2023 08:44:30 -
@@ -10,7 +10,7 @@ GH_ACCOUNT =  openscenegraph
 GH_PROJECT =   OpenSceneGraph
 GH_TAGNAME =   OpenSceneGraph-$V
 DISTNAME = openscenegraph-${V}
-REVISION = 3
+REVISION = 4
 
 SUBST_VARS +=  V
 
@@ -64,6 +64,8 @@ LIB_DEPENDS = devel/sdl \
x11/gnome/librsvg
 
 NO_TEST =  Yes
+
+CONFIGURE_ARGS +=  -DCMAKE_DISABLE_FIND_PACKAGE_OpenCascade:Bool=Yes
 
 # Fix build with OpenEXR>=3 (Imath split)
 CXXFLAGS +=-I${LOCALBASE}/include/Imath

Re: aarch64 bulk build report

[Theo Buehler]

> http://build-failures.rhaalovely.net/aarch64/2023-02-13/graphics/openscenegraph.log

This is a hidden dep on cad/oce. Not sure if it is desirable to add this
relatively heavy dependency or if it's better to neuter it.

It seems that there are various other hidden deps. For instance, my logs
suggest that the curl module may or may not be picked up. It would be
nice if someone who likes dealing with cmake could fix this.

Re: aarch64 bulk build report

[Klemens Nanni]

31.01.2023 21:05, phess...@openbsd.org пишет:
> http://build-failures.rhaalovely.net/aarch64/2023-01-29/net/qbittorrent/qbittorrent.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-29/net/qbittorrent/qbittorrent-nox.log

Already fixed by adding a missing build dependency.

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jan 18 (Wed) at 21:58:12 +0100 (+0100), Theo Buehler wrote:
:> :http://build-failures.rhaalovely.net/aarch64/2023-01-16/security/sslscan.log
:> 
:> ld: error: chacha-armv8.S:(function ChaCha20_ctr32: .text+0x4): relocation 
R_AARCH64_ADR_PREL_LO21 out of range: -1633764 is not in [-1048576, 1048575]
:
:Patch below fixes this. I missed an adr that should be computed with
:adrp + add :lo12: (like the remaining ones in the same file). Also move
:the .rodata down to match the file in 3.0 more closely.
:
:Regress still passes.
:

I don't understand assembly, but this looks good and still passing
regress is excellent.  OK


:I'll of course also bump sslscan.
:

Sure thing!


:Index: 1.1/Makefile
:===
:RCS file: /cvs/ports/security/openssl/1.1/Makefile,v
:retrieving revision 1.48
:diff -u -p -r1.48 Makefile
:--- 1.1/Makefile   17 Jan 2023 16:14:42 -  1.48
:+++ 1.1/Makefile   18 Jan 2023 19:54:43 -
:@@ -8,7 +8,7 @@ PORTROACH= limit:^1\.1\.[0-9][a-z] skipb
: V=1.1.1s
: PKGSPEC=  openssl->=1.1.0v0,<1.2v0
: EPOCH=0
:-REVISION= 3
:+REVISION= 4
: 
: SHLIBVER= 11.6
: SHARED_LIBS=  crypto ${SHLIBVER} \
:Index: 1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl
:===
:RCS file: 
/cvs/ports/security/openssl/1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl,v
:retrieving revision 1.1
:diff -u -p -r1.1 patch-crypto_chacha_asm_chacha-armv8_pl
:--- 1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl14 Jan 2023 
17:09:56 -  1.1
:+++ 1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl18 Jan 2023 
20:31:04 -
:@@ -1,16 +1,15 @@
: Index: crypto/chacha/asm/chacha-armv8.pl
: --- crypto/chacha/asm/chacha-armv8.pl.orig
: +++ crypto/chacha/asm/chacha-armv8.pl
:-@@ -122,7 +122,7 @@ my ($a3,$b3,$c3,$d3)=map(($_&~3)+(($_+1)&3),($a2,$b2,$
:- $code.=<<___;
:- #include "arm_arch.h"
:- 
:--.text
:-+.rodata
:- 
:+@@ -127,6 +127,7 @@ $code.=<<___;
:  .extern  OPENSSL_armcap_P
:  .hidden  OPENSSL_armcap_P
:-@@ -140,6 +140,8 @@ $code.=<<___;
:+ 
:++.rodata
:+ .align   5
:+ .Lsigma:
:+ .quad0x3320646e61707865,0x6b20657479622d32   // 
endian-neutral
:+@@ -140,12 +141,15 @@ $code.=<<___;
:  #endif
:  .asciz   "ChaCha20 for ARMv8, CRYPTOGAMS by "
:  
:@@ -19,7 +18,15 @@ Index: crypto/chacha/asm/chacha-armv8.pl
:  .globl   ChaCha20_ctr32
:  .typeChaCha20_ctr32,%function
:  .align   5
:-@@ -162,7 +164,8 @@ ChaCha20_ctr32:
:+ ChaCha20_ctr32:
:+  cbz $len,.Labort
:+- adr @x[0],.LOPENSSL_armcap_P
:++ adrp@x[0],.LOPENSSL_armcap_P
:++ add @x[0],@x[0],:lo12:.LOPENSSL_armcap_P
:+  cmp $len,#192
:+  b.lo.Lshort
:+ #ifdef   __ILP32__
:+@@ -162,7 +166,8 @@ ChaCha20_ctr32:
:   stp x29,x30,[sp,#-96]!
:   add x29,sp,#0
:  
:@@ -29,7 +36,7 @@ Index: crypto/chacha/asm/chacha-armv8.pl
:   stp x19,x20,[sp,#16]
:   stp x21,x22,[sp,#32]
:   stp x23,x24,[sp,#48]
:-@@ -385,7 +388,8 @@ ChaCha20_neon:
:+@@ -385,7 +390,8 @@ ChaCha20_neon:
:   stp x29,x30,[sp,#-96]!
:   add x29,sp,#0
:  
:@@ -39,7 +46,7 @@ Index: crypto/chacha/asm/chacha-armv8.pl
:   stp x19,x20,[sp,#16]
:   stp x21,x22,[sp,#32]
:   stp x23,x24,[sp,#48]
:-@@ -707,7 +711,8 @@ ChaCha20_512_neon:
:+@@ -707,7 +713,8 @@ ChaCha20_512_neon:
:   stp x29,x30,[sp,#-96]!
:   add x29,sp,#0
:  

-- 
Outside of a dog, a book is a man's best friend: and inside a dog,
it's too dark to read.
-- Groucho Marx

Re: aarch64 bulk build report

[Theo Buehler]

> :http://build-failures.rhaalovely.net/aarch64/2023-01-16/security/sslscan.log
> 
> ld: error: chacha-armv8.S:(function ChaCha20_ctr32: .text+0x4): relocation 
> R_AARCH64_ADR_PREL_LO21 out of range: -1633764 is not in [-1048576, 1048575]

Patch below fixes this. I missed an adr that should be computed with
adrp + add :lo12: (like the remaining ones in the same file). Also move
the .rodata down to match the file in 3.0 more closely.

Regress still passes.

I'll of course also bump sslscan.

Index: 1.1/Makefile
===
RCS file: /cvs/ports/security/openssl/1.1/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- 1.1/Makefile17 Jan 2023 16:14:42 -  1.48
+++ 1.1/Makefile18 Jan 2023 19:54:43 -
@@ -8,7 +8,7 @@ PORTROACH=  limit:^1\.1\.[0-9][a-z] skipb
 V= 1.1.1s
 PKGSPEC=   openssl->=1.1.0v0,<1.2v0
 EPOCH= 0
-REVISION=  3
+REVISION=  4
 
 SHLIBVER=  11.6
 SHARED_LIBS=   crypto ${SHLIBVER} \
Index: 1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl
===
RCS file: 
/cvs/ports/security/openssl/1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl,v
retrieving revision 1.1
diff -u -p -r1.1 patch-crypto_chacha_asm_chacha-armv8_pl
--- 1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl 14 Jan 2023 17:09:56 
-  1.1
+++ 1.1/patches/patch-crypto_chacha_asm_chacha-armv8_pl 18 Jan 2023 20:31:04 
-
@@ -1,16 +1,15 @@
 Index: crypto/chacha/asm/chacha-armv8.pl
 --- crypto/chacha/asm/chacha-armv8.pl.orig
 +++ crypto/chacha/asm/chacha-armv8.pl
-@@ -122,7 +122,7 @@ my ($a3,$b3,$c3,$d3)=map(($_&~3)+(($_+1)&3),($a2,$b2,$
- $code.=<<___;
- #include "arm_arch.h"
- 
--.text
-+.rodata
- 
+@@ -127,6 +127,7 @@ $code.=<<___;
  .extern   OPENSSL_armcap_P
  .hidden   OPENSSL_armcap_P
-@@ -140,6 +140,8 @@ $code.=<<___;
+ 
++.rodata
+ .align5
+ .Lsigma:
+ .quad 0x3320646e61707865,0x6b20657479622d32   // endian-neutral
+@@ -140,12 +141,15 @@ $code.=<<___;
  #endif
  .asciz"ChaCha20 for ARMv8, CRYPTOGAMS by "
  
@@ -19,7 +18,15 @@ Index: crypto/chacha/asm/chacha-armv8.pl
  .globlChaCha20_ctr32
  .type ChaCha20_ctr32,%function
  .align5
-@@ -162,7 +164,8 @@ ChaCha20_ctr32:
+ ChaCha20_ctr32:
+   cbz $len,.Labort
+-  adr @x[0],.LOPENSSL_armcap_P
++  adrp@x[0],.LOPENSSL_armcap_P
++  add @x[0],@x[0],:lo12:.LOPENSSL_armcap_P
+   cmp $len,#192
+   b.lo.Lshort
+ #ifdef__ILP32__
+@@ -162,7 +166,8 @@ ChaCha20_ctr32:
stp x29,x30,[sp,#-96]!
add x29,sp,#0
  
@@ -29,7 +36,7 @@ Index: crypto/chacha/asm/chacha-armv8.pl
stp x19,x20,[sp,#16]
stp x21,x22,[sp,#32]
stp x23,x24,[sp,#48]
-@@ -385,7 +388,8 @@ ChaCha20_neon:
+@@ -385,7 +390,8 @@ ChaCha20_neon:
stp x29,x30,[sp,#-96]!
add x29,sp,#0
  
@@ -39,7 +46,7 @@ Index: crypto/chacha/asm/chacha-armv8.pl
stp x19,x20,[sp,#16]
stp x21,x22,[sp,#32]
stp x23,x24,[sp,#48]
-@@ -707,7 +711,8 @@ ChaCha20_512_neon:
+@@ -707,7 +713,8 @@ ChaCha20_512_neon:
stp x29,x30,[sp,#-96]!
add x29,sp,#0
  

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jan 18 (Wed) at 12:43:27 -0700 (-0700), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-01-16/summary.log
:
:build failures: 5
:http://build-failures.rhaalovely.net/aarch64/2023-01-16/devel/quirks.log

Last package built, was in flux when dpb finished and exited.  Not a
real failure.


:http://build-failures.rhaalovely.net/aarch64/2023-01-16/graphics/opencv.log

/usr/obj/ports/opencv-4.7.0/opencv-4.7.0/modules/core/src/system.cpp:574:13:
error: unknown type name 'Elf64_auxv_t'
Elf64_auxv_t auxv;
^
/usr/obj/ports/opencv-4.7.0/opencv-4.7.0/modules/core/src/system.cpp:579:36:
error: use of undeclared identifier 'AT_HWCAP'
if (auxv.a_type == AT_HWCAP)
   ^

it's some cpu feature detection that fails for OpenBSD/arm64


:http://build-failures.rhaalovely.net/aarch64/2023-01-16/security/sslscan.log

ld: error: chacha-armv8.S:(function ChaCha20_ctr32: .text+0x4): relocation 
R_AARCH64_ADR_PREL_LO21 out of range: -1633764 is not in [-1048576, 1048575]


:http://build-failures.rhaalovely.net/aarch64/2023-01-16/devel/coccinelle.log
:http://build-failures.rhaalovely.net/aarch64/2023-01-16/textproc/bibtex2html.log
:

problem was in textproc/hevea, already fixed.


-- 
If you only have a hammer, you tend to see every problem as a nail.
-- Maslow

execute-only (Re: aarch64 bulk build report)

[Stuart Henderson]

On 2023/01/09 02:26, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Sat Jan 7 11:35:36 MST 2023
> finished at Mon Jan 9 02:25:42 MST 2023
> lasted 1D14h50m
> done with kern.version=OpenBSD 7.2-current (GENERIC.MP) #1955: Thu Jan  5 
> 18:56:38 MST 2023
> 
> built packages:10538

Before default execute-only: 11540

Previous build before workarounds were added for libgcrypt/openssl
(go was fixed at this point) and the java subpackage of DB was knocked
out: 9812

(Notably openssl is required for node.js, which is a build-dependency
of the main web browsers. libgcrypt used by many ports).

The biggest remaining build failures are gcc (in particular needed for
gfortran, which is needed for numpy, which is a dependency of a bunch
of ports; some directly, some via boost) and the JDKs.

(I am currently doing a test build of a slightly patched JDK 1.8 on
aarch64).

> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/summary.log

^^ This shows the ports which are knocked out from the build due to
missing deps, and the dependency chain involved.

> build failures: 28
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/converters/recode.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/arm-none-eabi/gcc-linaro.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/avr/gcc.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/coccinelle.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/jdk/11.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/jdk/17.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/ti-msp430gcc.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/xtensa-elf/gcc.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/xtensa-esp32-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/xtensa-esp32s2-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/xtensa-esp32s3-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/devel/xtensa-lx106-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/games/jbrickshooter.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/games/libgdx/1.9.11.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/games/libgdx/1.9.9.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/games/lwjgl.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/java/jBCrypt.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/java/tanukiwrapper.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/lang/gcc/11,-c++.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/lang/gcc/8.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/lang/kawa.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/math/coq.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/net/i2p.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/net/openfire.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/sysutils/rundeck.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/textproc/bibtex2html.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/textproc/pdftk.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-07/www/icedtea-web.log
> 
> recurrent failures
>  failures/devel/arm-none-eabi/gcc-linaro.log
>  failures/devel/avr/gcc.log
>  failures/devel/coccinelle.log
>  failures/games/lwjgl.log
>  failures/java/jBCrypt.log
>  failures/java/tanukiwrapper.log
>  failures/lang/gcc/8.log
>  failures/lang/kawa.log
>  failures/math/coq.log
>  failures/net/i2p.log
>  failures/net/openfire.log
>  failures/sysutils/rundeck.log
>  failures/textproc/bibtex2html.log
>  failures/textproc/pdftk.log
>  failures/www/icedtea-web.log
> new failures
> +++ ls-failures   Mon Jan  9 02:26:13 2023
> +failures/converters/recode.log
> +failures/lang/gcc/11,-c++.log
> resolved failures
> --- ../old/aarch64/last//ls-failures  Sat Jan  7 02:55:07 2023
> -failures/audio/hydrogen.log
> -failures/databases/db/v4.log
> -failures/lang/gcc/11,-ada.log
> -failures/lang/node.log
> -failures/security/gpgme.log
> -failures/security/keepassxc,browser.log
> -failures/x11/gnome/gcr.log
> 

Re: aarch64 bulk build report

[Stuart Henderson]

On 2023/01/07 02:55, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Fri Jan 6 00:27:36 MST 2023
> finished at Sat Jan 7 02:54:37 MST 2023
> lasted 1D02h27m
> done with kern.version=OpenBSD 7.2-current (GENERIC.MP) #1955: Thu Jan  5 
> 18:56:38 MST 2023
> 
> built packages:9812

11540 previously, so there's a lot of fallout from execute-only.

Key problems:

- gpgme (uses gnupg at runtime during build) and x11/gnome/gcr both
failing suggest a problem with libgcrypt -> knocks out 600+ ports

- gcc -> everything that touches fortran

- node -> build dep of firefox/chromium etc

- jdk -> db (java subpackage) -> 350-odd ports
|
+--> most of the other individual ports which showed as failing here

And there's also something up with ocaml -> hevea causing the coccinelle
failure (fair chance that other ocaml ports may have problems at run
time)

> Jan 6:9810
> Jan 7:1
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/summary.log
> 
> build failures: 34
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/audio/hydrogen.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/databases/db/v4.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/arm-none-eabi/gcc-linaro.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/avr/gcc.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/coccinelle.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/jdk/11.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/jdk/17.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/ti-msp430gcc.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/xtensa-elf/gcc.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/xtensa-esp32-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/xtensa-esp32s2-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/xtensa-esp32s3-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/devel/xtensa-lx106-elf/newlib.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/games/jbrickshooter.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/games/libgdx/1.9.11.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/games/libgdx/1.9.9.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/games/lwjgl.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/java/jBCrypt.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/java/tanukiwrapper.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/lang/gcc/11,-ada.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/lang/gcc/8.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/lang/kawa.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/lang/node.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/math/coq.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/net/i2p.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/net/openfire.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/security/gpgme.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/security/keepassxc,browser.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/sysutils/rundeck.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/textproc/bibtex2html.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/textproc/pdftk.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/www/icedtea-web.log
> http://build-failures.rhaalovely.net/aarch64/2023-01-06/x11/gnome/gcr.log
> 
> recurrent failures
> new failures
> +++ ls-failures   Sat Jan  7 02:55:07 2023
> +failures/audio/hydrogen.log
> +failures/databases/db/v4.log
> +failures/devel/arm-none-eabi/gcc-linaro.log
> +failures/devel/avr/gcc.log
> +failures/devel/coccinelle.log
> +failures/devel/jdk/11.log
> +failures/devel/jdk/17.log
> +failures/devel/ti-msp430gcc.log
> +failures/devel/xtensa-elf/gcc.log
> +failures/devel/xtensa-esp32-elf/newlib.log
> +failures/devel/xtensa-esp32s2-elf/newlib.log
> +failures/devel/xtensa-esp32s3-elf/newlib.log
> +failures/devel/xtensa-lx106-elf/newlib.log
> +failures/games/jbrickshooter.log
> +failures/games/libgdx/1.9.11.log
> +failures/games/libgdx/1.9.9.log
> +failures/games/lwjgl.log
> +failures/java/jBCrypt.log
> +failures/java/tanukiwrapper.log
> +failures/lang/gcc/11,-ada.log
> +failures/lang/gcc/8.log
> +failures/lang/kawa.log
> +failures/lang/node.log
> +failures/math/coq.log
> +failures/net/i2p.log
> +failures/net/openfire.log
> +failures/security/gpgme.log
> +failures/security/keepassxc,browser.log
> +failures/sysutils/rundeck.log
> +failures/textproc/bibtex2html.log
> +failures/textproc/pdftk.log
> +failures/www/icedtea-web.log
> +failures/x11/gnome/gcr.log
> resolved failures
> --- ../old/aarch64/last//ls-failures  Thu Jan  5 10:52:33 2023
> -failures/graphics/opens

Re: aarch64 bulk build report

[Peter Hessler]

On 2023 Jan 05 (Thu) at 10:52:33 -0700 (-0700), phess...@openbsd.org wrote:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2023-01-02/summary.log
:
:build failures: 2
:http://build-failures.rhaalovely.net/aarch64/2023-01-02/graphics/openscenegraph.log

In file included from 
/usr/obj/ports/openscenegraph-3.6.5/OpenSceneGraph-OpenSceneGraph-3.6.5/src/osgPlugins/OpenCASCADE/ReaderWriterOpenCASCADE.cpp:22:
/usr/obj/ports/openscenegraph-3.6.5/OpenSceneGraph-OpenSceneGraph-3.6.5/src/osgPlugins/OpenCASCADE/ReaderWriterOpenCASCADE.h:33:10:
fatal error: 'TDF_LabelSequence.hxx' file not found
#include 
 ^~~
1 error generated.

$ pkglocate TDF_LabelSequence.hxx
oce-7.6.0p0:cad/oce:/usr/local/include/opencascade/TDF_LabelSequence.hxx

Should we just add a lib dependency for cad/oce?  Or is a build dep good enough?


:http://build-failures.rhaalovely.net/aarch64/2023-01-02/x11/xfce4/xfce4-taskmanager.log

Should already be fixed.



-- 
Zymurgy's Law of Volunteer Labor:
People are always available for work in the past tense.

Re: aarch64 bulk build report

[Peter Hessler]

On 2022 Dec 31 (Sat) at 14:22:24 -0700 (-0700), phess...@openbsd.org wrote:
:http://build-failures.rhaalovely.net/aarch64/2022-12-29/devel/quirks.log

actually built, not a real error


:http://build-failures.rhaalovely.net/aarch64/2022-12-29/games/naev,-data.log

Run-time dependency libenet found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency libenet

../../../obj/ports/naev-0.10.0/naev-0.10.0/meson.build:95:3: ERROR: Automatic 
wrap-based subproject downloading is disabled

A full log can be found at 
/usr/obj/ports/naev-0.10.0/build-aarch64/meson-logs/meson-log.txt
WARNING: Running the setup command as `meson [options]` instead of `meson setup 
[options]` is ambiguous and deprecated.


seems to be a missing dependency


:http://build-failures.rhaalovely.net/aarch64/2022-12-29/sysutils/py-filelock,python3.log

* Getting build dependencies for wheel...

ERROR Missing dependencies:
hatch-vcs>=0.3


missing dependency


:http://build-failures.rhaalovely.net/aarch64/2022-12-29/textproc/catfish.log

===>  Faking installation for catfish-4.16.4p3
Traceback (most recent call last):
  File "/usr/obj/ports/catfish-4.16.4/catfish-4.16.4/./setup.py", line 260, in 

DistUtilsExtra.auto.setup(
  File "/usr/local/lib/python3.10/site-packages/DistUtilsExtra/auto.py", line 
98, in setup
__requires(attrs, src_all)
  File "/usr/local/lib/python3.10/site-packages/DistUtilsExtra/auto.py", line 
471, in __requires
__add_imports(imports, s, attrs)
  File "/usr/local/lib/python3.10/site-packages/DistUtilsExtra/auto.py", line 
405, in __add_imports
if alias.name and __external_mod(cur_module, alias.name, attrs):
  File "/usr/local/lib/python3.10/site-packages/DistUtilsExtra/auto.py", line 
377, in __external_mod
return 'dist-packages' in mod.__file__ or 'site-packages' in mod.__file__ 
or \
TypeError: argument of type 'NoneType' is not iterable


:
:recurrent failures
:new failures
:+++ ls-failuresSat Dec 31 14:22:24 2022
:+failures/devel/quirks.log
:+failures/games/naev,-data.log
:+failures/sysutils/py-filelock,python3.log
:+failures/textproc/catfish.log
:resolved failures
:--- ../old/aarch64/last//ls-failures   Tue Dec 27 09:44:25 2022
:

-- 
Pity the meek, for they shall inherit the earth.
-- Don Marquis

Re: aarch64 bulk build report

[Stuart Henderson]

On 2022/11/26 06:52, phess...@openbsd.org wrote:
> build failures: 0
> grep: /usr/ports/logs/aarch64/locks/*: No such file or directory
> find: failures: No such file or directory
> cp: failures/: No such file or directory
> 
> recurrent failures
> new failures
> +++ ls-failures   Sat Nov 26 06:52:08 2022
> resolved failures
> --- ../old/aarch64/last//ls-failures  Mon Nov 21 07:46:07 2022
> -failures/astro/xephem.log
> -failures/productivity/xinvest.log
> -failures/productivity/xquote.log
> tar: Unable to access aarch64/failures: No such file or directory
> tar: WARNING! These file names were not selected:
> aarch64/failures

heh, lack of failures is an error :)

Re: aarch64 bulk build report

[Peter Hessler]

On 2022 Nov 22 (Tue) at 22:32:06 +0100 (+0100), Christian Weisgerber wrote:
:Theo Buehler:
:
:> These three imake ports were broken by the makedepend 1.0.7 update:
:> 
:> > http://build-failures.rhaalovely.net/aarch64/2022-11-14/astro/xephem.log
:> > 
http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xinvest.log
:> > 
http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xquote.log
:
:Specifically, this upstream commit:
:https://gitlab.freedesktop.org/xorg/util/makedepend/-/commit/3dc64b0b0a7d4e14ccea6b9d1d11bf871c47a7e0
:
:If you compare makedepend's output before and after, some header
:files are now listed several times, growing the output and overflowing
:the internal MAXFILES limit (which is just an arbitrary internal
:array size and not a system resource).  So I think that change is
:buggy.
:

I see someone else has already filed a report upstream, so hopefully
that gets fixed by the next release.


:However, as far as the OpenBSD ports tree is concerned, the actual
:issue should be this:
:
:> Of note: amd64 uses gccmakedep instead of makedepend for some reason I
:> have not tried to track down.
:
:It's our imake configuration.  This has never been updated, so new
:architectures like aarch64 or riscv64 fall back to a catch all.
:Configurations for older archs like amd64 and sparc64 include a
:section for building an X11 server, which includes , which
:happens to set UseGccMakeDepend.
:
:So I think the correct fix is to unify our imake configuration and
:simply use gccmakedep(1) everywhere.
:
:OK?
:

OK



:Index: Makefile
:===
:RCS file: /cvs/ports/devel/imake-cf/Makefile,v
:retrieving revision 1.16
:diff -u -p -r1.16 Makefile
:--- Makefile   17 Nov 2022 09:12:22 -  1.16
:+++ Makefile   22 Nov 2022 21:13:20 -
:@@ -4,6 +4,7 @@ CATEGORIES =   devel x11
: V =   1.0.7
: DISTNAME =xorg-cf-files-${V}
: PKGNAME = imake-cf-${V}
:+REVISION =0
: MASTER_SITES =${MASTER_SITE_XORG:=util/}
: 
: PERMIT_PACKAGE =  Yes
:Index: patches/patch-OpenBSD_cf
:===
:RCS file: /cvs/ports/devel/imake-cf/patches/patch-OpenBSD_cf,v
:retrieving revision 1.9
:diff -u -p -r1.9 patch-OpenBSD_cf
:--- patches/patch-OpenBSD_cf   11 Mar 2022 18:50:12 -  1.9
:+++ patches/patch-OpenBSD_cf   22 Nov 2022 21:13:20 -
:@@ -33,7 +33,15 @@ Index: OpenBSD.cf
:  #define BuildHtmlManPagesNO
:  
:  #endif
:-@@ -172,6 +174,9 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:+@@ -150,6 +152,7 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:+ #define GccUsesGas   YES
:+ #define UseGas   YES
:+ #define GnuCpp   YES
:++#define UseGccMakeDepend YES
:+ 
:+ #define UseGnuMalloc NO
:+ 
:+@@ -172,6 +175,9 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:  #ifndef CcCmd
:  #define CcCmdcc
:  #endif
:@@ -43,7 +51,7 @@ Index: OpenBSD.cf
:  #ifndef AsCmd
:  #define AsCmdcc -c -x assembler
:  #endif
:-@@ -244,9 +249,22 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:+@@ -244,9 +250,22 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:  /*
:   * Documentation formatting
:   */
:@@ -69,7 +77,7 @@ Index: OpenBSD.cf
:  #define HasGroff YES
:  
:  #ifndef HasCookieMaker
:-@@ -262,77 +280,15 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:+@@ -262,77 +281,15 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
:   */
:  #define ManSuffix1
:  #define FileManSuffix5
:@@ -153,7 +161,7 @@ Index: OpenBSD.cf
:   done
:  
:  #define InstallManPageAliases(file,destdir,aliases)  @@\
:-@@ -436,8 +392,6 @@ install:: fonts.alias 
@@\
:+@@ -436,8 +393,6 @@ install:: fonts.alias 
@@\
:  #ifdef AMD64Architecture
:  
:  # define HasWeakSymbols  YES
:@@ -162,7 +170,7 @@ Index: OpenBSD.cf
:  
:  # define XorgServer  YES
:  
:-@@ -666,51 +620,26 @@ install:: fonts.alias   
@@\
:+@@ -666,51 +621,26 @@ install:: fonts.alias   
@@\
:  
:  
:  /*
:-- 
:Christian "naddy" Weisgerber  na...@mips.inka.de
:

Re: aarch64 bulk build report

[Theo Buehler]

> So I think the correct fix is to unify our imake configuration and
> simply use gccmakedep(1) everywhere.

Makes sense to me. All three ports in question build with this diff
on aarch64 since they now use gccmakedep.

ok tb

Re: aarch64 bulk build report

[Christian Weisgerber]

Theo Buehler:

> These three imake ports were broken by the makedepend 1.0.7 update:
> 
> > http://build-failures.rhaalovely.net/aarch64/2022-11-14/astro/xephem.log
> > http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xinvest.log
> > http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xquote.log

Specifically, this upstream commit:
https://gitlab.freedesktop.org/xorg/util/makedepend/-/commit/3dc64b0b0a7d4e14ccea6b9d1d11bf871c47a7e0

If you compare makedepend's output before and after, some header
files are now listed several times, growing the output and overflowing
the internal MAXFILES limit (which is just an arbitrary internal
array size and not a system resource).  So I think that change is
buggy.

However, as far as the OpenBSD ports tree is concerned, the actual
issue should be this:

> Of note: amd64 uses gccmakedep instead of makedepend for some reason I
> have not tried to track down.

It's our imake configuration.  This has never been updated, so new
architectures like aarch64 or riscv64 fall back to a catch all.
Configurations for older archs like amd64 and sparc64 include a
section for building an X11 server, which includes , which
happens to set UseGccMakeDepend.

So I think the correct fix is to unify our imake configuration and
simply use gccmakedep(1) everywhere.

OK?

Index: Makefile
===
RCS file: /cvs/ports/devel/imake-cf/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile17 Nov 2022 09:12:22 -  1.16
+++ Makefile22 Nov 2022 21:13:20 -
@@ -4,6 +4,7 @@ CATEGORIES =devel x11
 V =1.0.7
 DISTNAME = xorg-cf-files-${V}
 PKGNAME =  imake-cf-${V}
+REVISION = 0
 MASTER_SITES = ${MASTER_SITE_XORG:=util/}
 
 PERMIT_PACKAGE =   Yes
Index: patches/patch-OpenBSD_cf
===
RCS file: /cvs/ports/devel/imake-cf/patches/patch-OpenBSD_cf,v
retrieving revision 1.9
diff -u -p -r1.9 patch-OpenBSD_cf
--- patches/patch-OpenBSD_cf11 Mar 2022 18:50:12 -  1.9
+++ patches/patch-OpenBSD_cf22 Nov 2022 21:13:20 -
@@ -33,7 +33,15 @@ Index: OpenBSD.cf
  #define BuildHtmlManPages NO
  
  #endif
-@@ -172,6 +174,9 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
+@@ -150,6 +152,7 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
+ #define GccUsesGasYES
+ #define UseGasYES
+ #define GnuCppYES
++#define UseGccMakeDepend  YES
+ 
+ #define UseGnuMalloc  NO
+ 
+@@ -172,6 +175,9 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
  #ifndef CcCmd
  #define CcCmd cc
  #endif
@@ -43,7 +51,7 @@ Index: OpenBSD.cf
  #ifndef AsCmd
  #define AsCmd cc -c -x assembler
  #endif
-@@ -244,9 +249,22 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
+@@ -244,9 +250,22 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
  /*
   * Documentation formatting
   */
@@ -69,7 +77,7 @@ Index: OpenBSD.cf
  #define HasGroff  YES
  
  #ifndef HasCookieMaker
-@@ -262,77 +280,15 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
+@@ -262,77 +281,15 @@ XCOMM operating system:  OSName (OSMajorVersion./**/OS
   */
  #define ManSuffix 1
  #define FileManSuffix 5
@@ -153,7 +161,7 @@ Index: OpenBSD.cf
done
  
  #define InstallManPageAliases(file,destdir,aliases)   @@\
-@@ -436,8 +392,6 @@ install:: fonts.alias  
@@\
+@@ -436,8 +393,6 @@ install:: fonts.alias  
@@\
  #ifdef AMD64Architecture
  
  # define HasWeakSymbols   YES
@@ -162,7 +170,7 @@ Index: OpenBSD.cf
  
  # define XorgServer   YES
  
-@@ -666,51 +620,26 @@ install:: fonts.alias
@@\
+@@ -666,51 +621,26 @@ install:: fonts.alias
@@\
  
  
  /*
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: aarch64 bulk build report

[Theo de Raadt]

> makedepend: error:  out of space: increase MAXFILES

Software that demands infinite resources and will not accept and cope
with failure -- including transient and temporary failure -- on
shared-resource machines, is utterly offensive.  Go back to your
one-program-at-time VIC-20 please.

Re: aarch64 bulk build report

[Theo Buehler]

These three imake ports were broken by the makedepend 1.0.7 update:

> http://build-failures.rhaalovely.net/aarch64/2022-11-14/astro/xephem.log
> http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xinvest.log
> http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xquote.log

Specifically, this part of the makedepend diff

https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/util/makedepend/include.c.diff?r1=1.5&r2=1.6

results in an order of magnitude more headers being stored in
'inclistp', so that the MAXFILES limit is hit.

Of note: amd64 uses gccmakedep instead of makedepend for some reason I
have not tried to track down.


> http://build-failures.rhaalovely.net/aarch64/2022-11-14/astro/xephem.log

makedepend -f-  --  -I../../libastro -I/usr/local/include -I/usr/X11R6/include  
 -DCSRG_BASED  -DFUNCPROTO=15 -DNARROWPROTO -DUSE_MAKEDEPEND -- atlas.c 
bdl.c broadcast.c calmenu.c closemenu.c compiler.c constel.c datamenu.c db.c 
dbmenu.c earthmap.c earthmenu.c explodegif.c fallbacks.c fits.c formats.c 
fsmenu.c gsc.c gscnet.c helpmenu.c homeio.c jupmenu.c listmenu.c mainmenu.c 
marsmenu.c marsmmenu.c moonmenu.c moonnf.c msgmenu.c netmenu.c objmenu.c 
patchlevel.c plot_aux.c plotmenu.c ppm.c preferences.c progress.c ps.c query.c 
rotated.c satmenu.c sites.c skyfiltmenu.c skyfits.c skyhist.c skylist.c 
skyviewmenu.c solsysmenu.c srchmenu.c time.c tips.c trailmenu.c uranusmenu.c 
usno.c versionmenu.c wcs.c xephem.c xmisc.c > .depend
makedepend: error:  out of space: increase MAXFILES

> http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xinvest.log

makedepend -f-  -- -I/usr/local/include/X11  -I/usr/local/include 
-I/usr/X11R6/include   -DCSRG_BASED  -DFUNCPROTO=15 -DNARROWPROTO   -DSHAPE  
-DUSE_MAKEDEPEND -- account.c askuser.c calendar.c color.c drawing.c edit.c 
fileXi.c functions.c graph.c help.c nav.c pixmap.c portfolio.c   pref.c rate.c 
remoteXi.c report.c resource.c session.c sessionXi.c status.c 
tooltips.c trans.c util.c xinvest.c xutil.c > .depend
makedepend: error:  out of space: increase MAXFILES

> http://build-failures.rhaalovely.net/aarch64/2022-11-14/productivity/xquote.log

makedepend -f-  -- -I/usr/local/include/X11  -I/usr/local/include 
-I/usr/X11R6/include   -DCSRG_BASED  -DFUNCPROTO=15 -DNARROWPROTO   -DSHAPE 
-DXQUOTE  -DUSE_MAKEDEPEND -- about.c color.c fileXq.c help.c optdetail.c 
option.c optnet.c   opttick.c optupdate.c parse.c pixmap.c remoteXq.c 
server.c session.csessionXi.c status.c tape.c util.c view.c xquote.c 
xutil.c > .depend
makedepend: error:  out of space: increase MAXFILES

Re: aarch64 bulk build report

[Theo Buehler]

On Fri, Oct 28, 2022 at 07:16:35AM +0200, Rafael Sadowski wrote:
> > http://build-failures.rhaalovely.net/aarch64/2022-10-25/x11/kde-plasma/breeze-gtk.log
> 
> graphics/py-cairo${MODPY_FLAVOR} is in BUILD_DEPENDS. No idea what's
> wrong here.

Ran out of time and patience building 20 million dependencies for this,
but I'm pretty sure it's because cmake picks up the wrong Python. It
should be using 3.9, not 3.10:

-- Found Python3: /usr/local/bin/python3.10 (found version "3.10.8")
found components: Interpreter 
Traceback (most recent call last):
  File "", line 1, in 
  ModuleNotFoundError: No module named 'cairo'
  Installing in /usr/local. Run
  /usr/obj/ports/breeze-gtk-5.25.5/build-aarch64/prefix.sh to set the
  environment for breeze-gtk.


devel/kf5/breeze-icons has a similar issue and doesn't build if
Python 3.10 is installed.

Re: aarch64 bulk build report

[Rafael Sadowski]

On Thu Oct 27, 2022 at 03:15:52PM -0600, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Tue Oct 25 07:35:15 MDT 2022
> finished at Thu Oct 27 15:14:20 MDT 2022
> lasted 2D07h39m
> done with kern.version=OpenBSD 7.2-current (GENERIC.MP) #1870: Tue Oct 25 
> 01:33:11 MDT 2022
> 
> built packages:11403
> Oct 25:3185
> Oct 26:2016
> Oct 27:6201
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2022-10-25/summary.log
> 
> build failures: 2
> http://build-failures.rhaalovely.net/aarch64/2022-10-25/devel/quirks.log
> http://build-failures.rhaalovely.net/aarch64/2022-10-25/x11/kde-plasma/breeze-gtk.log

graphics/py-cairo${MODPY_FLAVOR} is in BUILD_DEPENDS. No idea what's
wrong here.

> 
> recurrent failures
> new failures
> +++ ls-failures   Thu Oct 27 15:15:51 2022
> +failures/devel/quirks.log
> +failures/x11/kde-plasma/breeze-gtk.log
> resolved failures
> --- ../old/aarch64/last//ls-failures  Mon Oct 24 14:39:24 2022
> -failures/x11/gnustep/base.log
> 

Re: aarch64 bulk build report

[Klemens Nanni]

On Mon, Oct 24, 2022 at 11:15:36PM +0200, Theo Buehler wrote:
> > http://build-failures.rhaalovely.net/aarch64/2022-10-18/x11/gnustep/base.log
> 
> ././GSEasyHandle.h:48:40: error: blocks support disabled - compile with 
> -fblocks or pick a deployment target that supports them
> result: (void (^)(GSEasyHandleWriteBufferResult 
> result, NSInteger length, NSData *data))result;
>^
> In file included from GSEasyHandle.m:3:
> In file included from ././GSTimeoutSource.h:5:
> ././GSDispatch.h:128:9: warning: 'DISPATCH_QUEUE_SERIAL' macro redefined 
> [-Wmacro-redefined]
> #define DISPATCH_QUEUE_SERIAL 0
> 
> This happens if devel/libdispatch is present during build. I suggest we
> neuter this, see diff below.

devel/libdispatch is relatively new and can always be enabled explicitly
later in gnustep, if desired.

OK kn

Re: aarch64 bulk build report

[Theo Buehler]

> http://build-failures.rhaalovely.net/aarch64/2022-10-18/x11/gnustep/base.log

././GSEasyHandle.h:48:40: error: blocks support disabled - compile with 
-fblocks or pick a deployment target that supports them
result: (void (^)(GSEasyHandleWriteBufferResult result, 
NSInteger length, NSData *data))result;
   ^
In file included from GSEasyHandle.m:3:
In file included from ././GSTimeoutSource.h:5:
././GSDispatch.h:128:9: warning: 'DISPATCH_QUEUE_SERIAL' macro redefined 
[-Wmacro-redefined]
#define DISPATCH_QUEUE_SERIAL 0

This happens if devel/libdispatch is present during build. I suggest we
neuter this, see diff below.


I also noticed that bfd.h usability in cofigure output depends on
devel/gdb being present or not. I haven't looked into this, but that
should probably also be neutered one way or the other.


I have no idea what causes the latest build failure starting with:

checking whether objc really works... no

http://build-failures.rhaalovely.net/aarch64/2022-10-22/x11/gnustep/base.log


Index: Makefile
===
RCS file: /cvs/ports/x11/gnustep/base/Makefile,v
retrieving revision 1.84
diff -u -p -r1.84 Makefile
--- Makefile11 Mar 2022 20:15:52 -  1.84
+++ Makefile24 Oct 2022 21:07:41 -
@@ -1,7 +1,7 @@
 COMMENT=   GNUstep base library
 
 DISTNAME=  gnustep-base-1.28.0
-REVISION=  3
+REVISION=  4
 
 SHARED_LIBS=   gnustep-base 10.5
 CATEGORIES=devel
@@ -37,7 +37,8 @@ LIB_DEPENDS +=converters/libiconv \
 
 CONFIGURE_STYLE=gnu
 CONFIGURE_ENV= ac_cv_header_execinfo_h=false
-CONFIGURE_ARGS +=  --disable-procfs \
+CONFIGURE_ARGS +=  --disable-libdispatch \
+   --disable-procfs \
--disable-procfs-psinfo
 MAKE_FLAGS +=  
libgnustep-base_INTERFACE_VERSION=${LIBgnustep-base_VERSION}
 

Re: aarch64 bulk build report

[Theo Buehler]

> :http://build-failures.rhaalovely.net/aarch64/2022-09-10/devel/riscv-elf/newlib.log
> 
>   Entering directory 
> '/usr/obj/ports/riscv-elf-newlib-3.0.0/newlib-3.0.0/riscv64-unknown-elf/rv32imafc/ilp32f/newlib/libm'
>   ...
>   riscv64-unknown-elf-ar: ../math/lib.a: No such file or directory

This looks like a random gmake failure a bit further up:

gmake[8]: *** [Makefile:490: lib_a-k_cos.o] Error 127
gmake[8]: Leaving directory 
'/usr/obj/ports/riscv-elf-newlib-3.0.0/newlib-3.0.0/riscv64-unknown-elf/rv32imafc/ilp32f/newlib/libm/math'

I was unable to reproduce.

Re: aarch64 bulk build report

[Peter Hessler]

On 2022 Sep 12 (Mon) at 12:07:04 -0600 (-0600), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Sat Sep 10 09:34:26 MDT 2022
:finished at Mon Sep 12 12:06:52 MDT 2022
:lasted 2D02h32m
:done with kern.version=OpenBSD 7.2-beta (GENERIC.MP) #1816: Fri Sep  9 
18:30:23 MDT 2022
:
:built packages:11326
:Sep 10:2166
:Sep 11:3160
:Sep 12:5999
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2022-09-10/summary.log
:
:build failures: 3
:http://build-failures.rhaalovely.net/aarch64/2022-09-10/audio/py-eyed3.log

dpb false positive failure, it built fine


:http://build-failures.rhaalovely.net/aarch64/2022-09-10/devel/riscv-elf/newlib.log

  Entering directory 
'/usr/obj/ports/riscv-elf-newlib-3.0.0/newlib-3.0.0/riscv64-unknown-elf/rv32imafc/ilp32f/newlib/libm'
  ...
  riscv64-unknown-elf-ar: ../math/lib.a: No such file or directory

:http://build-failures.rhaalovely.net/aarch64/2022-09-10/security/step-ca.log

already fixed

:
:recurrent failures
: failures/security/step-ca.log
:new failures
:+++ ls-failuresMon Sep 12 12:07:04 2022
:+failures/audio/py-eyed3.log
:+failures/devel/riscv-elf/newlib.log
:resolved failures
:--- ../old/aarch64/last//ls-failures   Thu Sep  8 16:15:02 2022
:-failures/www/py-autobahn,python3.log
:

-- 
Lie, n.:
A very poor substitute for the truth, but the only one
discovered to date.

Re: aarch64 bulk build report

[Jeremie Courreges-Anglas]

On Mon, Aug 15 2022, Theo Buehler  wrote:
>> :+failures/security/pivy.log
>> 
>>   ./config.status: gawk: not found
>
> I looked at this before. Just adding gawk is probably not the right fix
> since this runs a configure script as part of its build without using
> the ports autoconf framework. It would be great if someone who
> understands this well could take a look at this.

With this gawk isn't picked up.  ok?

Index: Makefile
===
RCS file: /cvs/ports/security/pivy/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile18 May 2022 04:16:41 -  1.8
+++ Makefile15 Aug 2022 13:15:27 -
@@ -17,6 +17,12 @@ PERMIT_PACKAGE = Yes
 
 WANTLIB =  c edit crypto pcsclite z
 
+MODULES =  gnu
+MODGNU_CONFIG_GUESS_DIRS = \
+   openssh/ \
+   libressl/ \
+   libressl/scripts/
+
 LIB_DEPENDS =  security/pcsc-lite
 RUN_DEPENDS =  security/ccid
 
@@ -31,6 +37,5 @@ MAKE_FLAGS =  CC="${CC}" \
 post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/pivy
${INSTALL_DATA} ${WRKSRC}/README.adoc ${PREFIX}/share/doc/pivy
-   
 
 .include 


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: aarch64 bulk build report

[Theo Buehler]

> :+failures/security/pivy.log
> 
>   ./config.status: gawk: not found

I looked at this before. Just adding gawk is probably not the right fix
since this runs a configure script as part of its build without using
the ports autoconf framework. It would be great if someone who
understands this well could take a look at this.

Re: aarch64 bulk build report

[Peter Hessler]

On 2022 Aug 15 (Mon) at 06:08:03 -0600 (-0600), phess...@openbsd.org wrote:
:bulk build on arm64.ports.openbsd.org
:started on  Sat Aug 13 00:54:31 MDT 2022
:finished at Mon Aug 15 06:07:52 MDT 2022
:lasted 2D05h13m
:done with kern.version=OpenBSD 7.2-beta (GENERIC.MP) #1784: Fri Aug 12 
20:57:14 MDT 2022
:
:built packages:11261
:Aug 13:4143
:Aug 14:2935
:Aug 15:4182
:
:
:critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2022-08-13/summary.log
:
:build failures: 2
:http://build-failures.rhaalovely.net/aarch64/2022-08-13/devel/rizin.log
:http://build-failures.rhaalovely.net/aarch64/2022-08-13/security/pivy.log
:
:recurrent failures
:new failures
:+++ ls-failuresMon Aug 15 06:08:03 2022
:+failures/devel/rizin.log

  #error "Unsupported BSD architecture"

probably needs ONLY_FOR_ARCHS and/or local patches to fix up all of our arches

:+failures/security/pivy.log

  ./config.status: gawk: not found


-- 
Speed is subsittute fo accurancy.

Re: aarch64 bulk build report

[Stuart Henderson]

Ok. That problem is very unlikely to be arm64-specific.

--
 Sent from a phone, apologies for poor formatting.

On 11 July 2022 13:34:46 Klemens Nanni  wrote:


On Mon, Jul 11, 2022 at 01:15:09PM +0100, Stuart Henderson wrote:

On 2022/07/11 10:41, Klemens Nanni wrote:
> On Mon, Jul 11, 2022 at 04:31:13AM -0600, Peter Hessler wrote:
> > bulk build on arm64.ports.openbsd.org
> > started on  Sat Jul 9 05:33:35 MDT 2022
> > finished at Mon Jul 11 04:31:02 MDT 2022
> > lasted 1D22h57m
> > done with kern.version=OpenBSD 7.1-current (GENERIC.MP) #1721: Fri Jul  
8 12:28:55 MDT 2022

> >
> > built packages:11237
> > Jul 9:3998
> > Jul 10:3208
> > Jul 11:4030
> >
> >
> > critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2022-07-09/summary.log

> >
> > build failures: 3
> > 
http://build-failures.rhaalovely.net/aarch64/2022-07-09/net/bitlbee,libpurple.log

> > http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/varnish.log
>
> This looks like a fluke in this build, given that the last arm64 bulks
> had no problems with varnish 7.0.2 and nothing changed in this port.
>
> It fails to package because the files got lost?

gmake[3]: Entering directory 
'/usr/obj/ports/varnish-7.0.2/build-aarch64/bin/varnishadm'
 /usr/obj/ports/varnish-7.0.2/varnish-7.0.2/build-aux/install-sh -c -d 
 '/usr/obj/ports/varnish-7.0.2/fake-aarch64/usr/local/bin'

/bin/sh: gawk: not found


Oops.

Diff below makes it use base awk, grep, etc.

Still builds and passes tests on amd64, I can't test arm64 at the moment.

Feedback? OK?

Index: Makefile
===
RCS file: /cvs/ports/www/varnish/Makefile,v
retrieving revision 1.71
diff -u -p -r1.71 Makefile
--- Makefile11 Mar 2022 20:11:06 -  1.71
+++ Makefile11 Jul 2022 12:32:24 -
@@ -1,7 +1,7 @@
COMMENT =   high-performance HTTP accelerator

DISTNAME =  varnish-7.0.2
-REVISION = 0
+REVISION = 1

CATEGORIES =www

@@ -30,7 +30,7 @@ LIB_DEPENDS = devel/pcre2

USE_GMAKE = Yes
SEPARATE_BUILD =Yes
-CONFIGURE_STYLE =  simple
+CONFIGURE_STYLE =  gnu
CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib ${LDFLAGS}" \
PYTHON="${MODPY_BIN}"

Re: aarch64 bulk build report

[Klemens Nanni]

On Mon, Jul 11, 2022 at 01:15:09PM +0100, Stuart Henderson wrote:
> On 2022/07/11 10:41, Klemens Nanni wrote:
> > On Mon, Jul 11, 2022 at 04:31:13AM -0600, Peter Hessler wrote:
> > > bulk build on arm64.ports.openbsd.org
> > > started on  Sat Jul 9 05:33:35 MDT 2022
> > > finished at Mon Jul 11 04:31:02 MDT 2022
> > > lasted 1D22h57m
> > > done with kern.version=OpenBSD 7.1-current (GENERIC.MP) #1721: Fri Jul  8 
> > > 12:28:55 MDT 2022
> > > 
> > > built packages:11237
> > > Jul 9:3998
> > > Jul 10:3208
> > > Jul 11:4030
> > > 
> > > 
> > > critical path missing pkgs:  
> > > http://build-failures.rhaalovely.net/aarch64/2022-07-09/summary.log
> > > 
> > > build failures: 3
> > > http://build-failures.rhaalovely.net/aarch64/2022-07-09/net/bitlbee,libpurple.log
> > > http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/varnish.log
> > 
> > This looks like a fluke in this build, given that the last arm64 bulks
> > had no problems with varnish 7.0.2 and nothing changed in this port.
> > 
> > It fails to package because the files got lost?
> 
> gmake[3]: Entering directory 
> '/usr/obj/ports/varnish-7.0.2/build-aarch64/bin/varnishadm'
>  /usr/obj/ports/varnish-7.0.2/varnish-7.0.2/build-aux/install-sh -c -d 
> '/usr/obj/ports/varnish-7.0.2/fake-aarch64/usr/local/bin'
> /bin/sh: gawk: not found

Oops.

Diff below makes it use base awk, grep, etc.

Still builds and passes tests on amd64, I can't test arm64 at the moment.

Feedback? OK?

Index: Makefile
===
RCS file: /cvs/ports/www/varnish/Makefile,v
retrieving revision 1.71
diff -u -p -r1.71 Makefile
--- Makefile11 Mar 2022 20:11:06 -  1.71
+++ Makefile11 Jul 2022 12:32:24 -
@@ -1,7 +1,7 @@
 COMMENT =  high-performance HTTP accelerator
 
 DISTNAME = varnish-7.0.2
-REVISION = 0
+REVISION = 1
 
 CATEGORIES =   www
 
@@ -30,7 +30,7 @@ LIB_DEPENDS = devel/pcre2
 
 USE_GMAKE =Yes
 SEPARATE_BUILD =   Yes
-CONFIGURE_STYLE =  simple
+CONFIGURE_STYLE =  gnu
 CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib ${LDFLAGS}" \
PYTHON="${MODPY_BIN}"

Re: aarch64 bulk build report

[Stuart Henderson]

On 2022/07/11 10:41, Klemens Nanni wrote:
> On Mon, Jul 11, 2022 at 04:31:13AM -0600, Peter Hessler wrote:
> > bulk build on arm64.ports.openbsd.org
> > started on  Sat Jul 9 05:33:35 MDT 2022
> > finished at Mon Jul 11 04:31:02 MDT 2022
> > lasted 1D22h57m
> > done with kern.version=OpenBSD 7.1-current (GENERIC.MP) #1721: Fri Jul  8 
> > 12:28:55 MDT 2022
> > 
> > built packages:11237
> > Jul 9:3998
> > Jul 10:3208
> > Jul 11:4030
> > 
> > 
> > critical path missing pkgs:  
> > http://build-failures.rhaalovely.net/aarch64/2022-07-09/summary.log
> > 
> > build failures: 3
> > http://build-failures.rhaalovely.net/aarch64/2022-07-09/net/bitlbee,libpurple.log
> > http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/varnish.log
> 
> This looks like a fluke in this build, given that the last arm64 bulks
> had no problems with varnish 7.0.2 and nothing changed in this port.
> 
> It fails to package because the files got lost?

gmake[3]: Entering directory 
'/usr/obj/ports/varnish-7.0.2/build-aarch64/bin/varnishadm'
 /usr/obj/ports/varnish-7.0.2/varnish-7.0.2/build-aux/install-sh -c -d 
'/usr/obj/ports/varnish-7.0.2/fake-aarch64/usr/local/bin'
/bin/sh: gawk: not found



> 
> > Error: /usr/obj/ports/varnish-7.0.2/fake-aarch64/usr/local/bin/varnishadm 
> > does not exist
> > [... same error for (almost?) all other files]
> 
> > http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/xapian-omega.log
> > 
> > recurrent failures
> > new failures
> > +++ ls-failures Mon Jul 11 04:31:19 2022
> > +failures/net/bitlbee,libpurple.log
> > +failures/www/varnish.log
> > +failures/www/xapian-omega.log
> > resolved failures
> > --- ../old/aarch64/last//ls-failuresThu Jul  7 22:23:54 2022
> > -failures/games/stepmania.log
> > -failures/x11/gnome/books.log
> > 
> 

Re: aarch64 bulk build report

[Klemens Nanni]

On Mon, Jul 11, 2022 at 04:31:13AM -0600, Peter Hessler wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Sat Jul 9 05:33:35 MDT 2022
> finished at Mon Jul 11 04:31:02 MDT 2022
> lasted 1D22h57m
> done with kern.version=OpenBSD 7.1-current (GENERIC.MP) #1721: Fri Jul  8 
> 12:28:55 MDT 2022
> 
> built packages:11237
> Jul 9:3998
> Jul 10:3208
> Jul 11:4030
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2022-07-09/summary.log
> 
> build failures: 3
> http://build-failures.rhaalovely.net/aarch64/2022-07-09/net/bitlbee,libpurple.log
> http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/varnish.log

This looks like a fluke in this build, given that the last arm64 bulks
had no problems with varnish 7.0.2 and nothing changed in this port.

It fails to package because the files got lost?

> Error: /usr/obj/ports/varnish-7.0.2/fake-aarch64/usr/local/bin/varnishadm 
> does not exist
> [... same error for (almost?) all other files]

> http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/xapian-omega.log
> 
> recurrent failures
> new failures
> +++ ls-failures   Mon Jul 11 04:31:19 2022
> +failures/net/bitlbee,libpurple.log
> +failures/www/varnish.log
> +failures/www/xapian-omega.log
> resolved failures
> --- ../old/aarch64/last//ls-failures  Thu Jul  7 22:23:54 2022
> -failures/games/stepmania.log
> -failures/x11/gnome/books.log
> 

Re: aarch64 bulk build report

[Peter Hessler]

On 2022 Mar 19 (Sat) at 15:54:51 -0600 (-0600), phess...@openbsd.org wrote:
:build failures: 6
:http://build-failures.rhaalovely.net/aarch64/2022-03-17/editors/calligra.log

c++, might be wonky includes?


:http://build-failures.rhaalovely.net/aarch64/2022-03-17/games/irrlamb.log

hardcodes sse in CMakeLists.txt

without patches, this can only build on i386 or amd64


:http://build-failures.rhaalovely.net/aarch64/2022-03-17/sysutils/gitlab-runner.log

as per usual, go is stupid:

# gitlab.com/gitlab-org/gitlab-runner/vendor/github.com/kr/pty
vendor/github.com/kr/pty/pty_openbsd.go:24:10: undefined: ptmget
vendor/github.com/kr/pty/pty_openbsd.go:25:34: undefined: ioctl_PTMGET

If no-one fixes this in a few days, we might as well mark it as BROKEN-aarch64


:http://build-failures.rhaalovely.net/aarch64/2022-03-17/textproc/p5-SWISH-API.log

Creating index...'/usr/local/bin/swish-e -c t/test.conf -f t/index.swish-e -v 0'
 crashes on aarch64


:http://build-failures.rhaalovely.net/aarch64/2022-03-17/www/mozilla-firefox.log

fails to compile an intel-arch-only file
/usr/obj/ports/firefox-98.0.1/firefox-98.0.1/third_party/libwebrtc/common_audio/fir_filter_avx2.cc

first guess is BUILD.gn thinks aarch64 is x86 or x64 at this point?


:http://build-failures.rhaalovely.net/aarch64/2022-03-17/www/seamonkey,-lightning.log
:

   Compiling libc v0.2.24
error[E0412]: cannot find type `c_long` in this scope
   --> 
/usr/obj/ports/seamonkey-2.53.11/seamonkey-2.53.11/third_party/rust/libc/src/lib.rs:192:45



-- 
Every solution breeds new problems.

Re: mariadb on aarch64 after the llvm 13 update (Re: aarch64 bulk build report)

[Peter Hessler]

On 2021 Dec 27 (Mon) at 23:32:31 +0100 (+0100), Jeremie Courreges-Anglas wrote:
:On Mon, Dec 20 2021, phess...@openbsd.org wrote:
:> bulk build on arm64.ports.openbsd.org
:> started on  Mon Dec 20 03:38:26 MST 2021
:> finished at Mon Dec 20 22:29:47 MST 2021
:> lasted 0D18h51m
:> done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1455: Sun Dec 19 
14:58:17 MST 2021
:>
:> built packages:8238
:> Dec 20:8237
:>
:>
:> critical path missing pkgs:  
http://build-failures.rhaalovely.net/aarch64/2021-12-20/summary.log
:>
:> build failures: 10
:> http://build-failures.rhaalovely.net/aarch64/2021-12-20/databases/mariadb.log
:
:[...]
:
:mariadb tries to use "out-of-line atomics" as implemented here:
:
:  https://reviews.llvm.org/D91157
:
:The summary mentions implementations in libgcc and libcompiler-rt, and
:a quick diff between compiler-rt-11.1.0 and compiler-rt-13.0.0 indeed
:lists changes that seem relevant.
:
:To work around this problem until a solution is found in base, the
:untested patch below may help.  If testing goes well, ok?
:

this builds and packages on arm64, OK


:
:Index: patches/patch-configure_cmake
:===
:RCS file: patches/patch-configure_cmake
:diff -N patches/patch-configure_cmake
:--- /dev/null  1 Jan 1970 00:00:00 -
:+++ patches/patch-configure_cmake  27 Dec 2021 22:29:08 -
:@@ -0,0 +1,17 @@
:+$OpenBSD$
:+
:+libcompiler-rt from base doesn't provide support for out-of-line atomics
:+llvm commit: https://reviews.llvm.org/D91157
:+
:+Index: configure.cmake
:+--- configure.cmake.orig
: configure.cmake
:+@@ -70,7 +70,7 @@ IF(CMAKE_SYSTEM_PROCESSOR STREQUAL "i686" AND CMAKE_CO
:+ ENDIF()
:+ 
:+ # use runtime atomic-support detection in aarch64
:+-IF(CMAKE_SYSTEM_PROCESSOR MATCHES "aarch64")
:++IF(FALSE)
:+   MY_CHECK_AND_SET_COMPILER_FLAG("-moutline-atomics")
:+ ENDIF()
:+ 
:
:
:-- 
:jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

-- 
It is impossible to make anything foolproof because fools are so
ingenious.

mariadb on aarch64 after the llvm 13 update (Re: aarch64 bulk build report)

[Jeremie Courreges-Anglas]

On Mon, Dec 20 2021, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Mon Dec 20 03:38:26 MST 2021
> finished at Mon Dec 20 22:29:47 MST 2021
> lasted 0D18h51m
> done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1455: Sun Dec 19 
> 14:58:17 MST 2021
>
> built packages:8238
> Dec 20:8237
>
>
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-12-20/summary.log
>
> build failures: 10
> http://build-failures.rhaalovely.net/aarch64/2021-12-20/databases/mariadb.log

[...]

mariadb tries to use "out-of-line atomics" as implemented here:

  https://reviews.llvm.org/D91157

The summary mentions implementations in libgcc and libcompiler-rt, and
a quick diff between compiler-rt-11.1.0 and compiler-rt-13.0.0 indeed
lists changes that seem relevant.

To work around this problem until a solution is found in base, the
untested patch below may help.  If testing goes well, ok?


Index: patches/patch-configure_cmake
===
RCS file: patches/patch-configure_cmake
diff -N patches/patch-configure_cmake
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-configure_cmake   27 Dec 2021 22:29:08 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+libcompiler-rt from base doesn't provide support for out-of-line atomics
+llvm commit: https://reviews.llvm.org/D91157
+
+Index: configure.cmake
+--- configure.cmake.orig
 configure.cmake
+@@ -70,7 +70,7 @@ IF(CMAKE_SYSTEM_PROCESSOR STREQUAL "i686" AND CMAKE_CO
+ ENDIF()
+ 
+ # use runtime atomic-support detection in aarch64
+-IF(CMAKE_SYSTEM_PROCESSOR MATCHES "aarch64")
++IF(FALSE)
+   MY_CHECK_AND_SET_COMPILER_FLAG("-moutline-atomics")
+ ENDIF()
+ 


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Fix gnutls on aarch64 after the llvm 13 update (was: Re: aarch64 bulk build report)

[Jeremie Courreges-Anglas]

On Mon, Dec 20 2021, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Mon Dec 20 03:38:26 MST 2021
> finished at Mon Dec 20 22:29:47 MST 2021
> lasted 0D18h51m
> done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1455: Sun Dec 19 
> 14:58:17 MST 2021
>
> built packages:8238
> Dec 20:8237
>
>
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-12-20/summary.log

[...]

> http://build-failures.rhaalovely.net/aarch64/2021-12-20/security/gnutls.log

This crash has already been hit by the FreeBSD folks;
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260078

-march=all seems unsupported by clang, this diff fixes the crash but
doesn't add support for -march=all
https://reviews.llvm.org/D114677

The untested diff below removes the use of -march=all to fix the build
on aarch64.  Tests and ok welcome.


Index: Makefile
===
RCS file: /cvs/ports/security/gnutls/Makefile,v
retrieving revision 1.169
diff -u -p -r1.169 Makefile
--- Makefile29 May 2021 22:43:09 -  1.169
+++ Makefile27 Dec 2021 16:03:05 -
@@ -3,6 +3,7 @@
 COMMENT=   GNU Transport Layer Security library
 
 V= 3.7.2
+REVISION=  0
 DISTNAME=  gnutls-${V}
 EXTRACT_SUFX=  .tar.xz
 
Index: patches/patch-lib_accelerated_aarch64_Makefile_in
===
RCS file: patches/patch-lib_accelerated_aarch64_Makefile_in
diff -N patches/patch-lib_accelerated_aarch64_Makefile_in
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_accelerated_aarch64_Makefile_in   27 Dec 2021 16:03:05 
-
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Avoid -march=all, unsupported by clang.
+Clang commit that fixes the crash but doesn't add support for -march=all:
+https://reviews.llvm.org/D114677
+
+Index: lib/accelerated/aarch64/Makefile.in
+--- lib/accelerated/aarch64/Makefile.in.orig
 lib/accelerated/aarch64/Makefile.in
+@@ -2104,7 +2104,7 @@ AM_CPPFLAGS = -I$(srcdir)/../../../gl -I$(builddir)/..
+   -I$(srcdir)/../../ -I$(srcdir)/../ $(am__append_1)
+ 
+ #ensure that we have all aarch64 instruction sets enabled for the assembler
+-AM_CCASFLAGS = -Wa,-march=all
++#AM_CCASFLAGS = -Wa,-march=all
+ EXTRA_DIST = README
+ noinst_LTLIBRARIES = libaarch64.la
+ libaarch64_la_SOURCES = aarch64-common.c aarch64-common.h \


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

graphics/babl [Re: aarch64 bulk build report]

[Peter Hessler]

On 2021 Nov 28 (Sun) at 20:40:52 -0700 (-0700), phess...@openbsd.org wrote:
:http://build-failures.rhaalovely.net/aarch64/2021-11-26/graphics/babl.log

this looks like a transient failure, detected w3m during configure and
then it was removed during the build:

...
Program w3m found: YES (/usr/local/bin/w3m)
...
[122/194] /usr/local/bin/meson --internal exe --capture README --
/usr/local/bin/w3m -cols 72 -dump docs/index.html
FAILED: README 
/usr/local/bin/meson --internal exe --capture README --
/usr/local/bin/w3m -cols 72 -dump docs/index.html
Traceback (most recent call last):
  File "/usr/local/bin/meson", line 33, in 
sys.exit(load_entry_point('meson==0.60.2', 'console_scripts', 'meson')())
  File "/usr/local/lib/python3.9/site-packages/mesonbuild/mesonmain.py",
line 235, in main
return run(sys.argv[1:], launcher)
  File "/usr/local/lib/python3.9/site-packages/mesonbuild/mesonmain.py",
line 224, in run
return run_script_command(args[1], args[2:])
  File "/usr/local/lib/python3.9/site-packages/mesonbuild/mesonmain.py",
line 172, in run_script_command
return module.run(script_args)
  File
"/usr/local/lib/python3.9/site-packages/mesonbuild/scripts/meson_exe.py",
line 122, in run
return run_exe(exe)
  File
"/usr/local/lib/python3.9/site-packages/mesonbuild/scripts/meson_exe.py",
line 66, in run_exe
p = subprocess.Popen(cmd_args, env=child_env, cwd=exe.workdir,
  File "/usr/local/lib/python3.9/subprocess.py", line 951, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.9/subprocess.py", line 1821, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/usr/local/bin/w3m'




-- 
A day for firm decisions!  Or is it?

Re: aarch64 bulk build report

[Jonathan Gray]

On Sun, Nov 28, 2021 at 08:40:52PM -0700, phess...@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on  Fri Nov 26 11:53:41 MST 2021
> finished at Sun Nov 28 20:40:41 MST 2021
> lasted 2D08h47m
> done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1414: Thu Nov 25 
> 20:48:57 MST 2021
> 
> built packages:10826
> Nov 26:3718
> Nov 27:948
> Nov 28:6159
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/summary.log
> 
> build failures: 6
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/devel/mono-addins.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/graphics/babl.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/graphics/openbsd-backgrounds.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-26/sysutils/arm-trusted-firmware.log

ld.so: cc1: can't load library 'libisl.so.0.0'
aarch64-none-elf-gcc: internal compiler error: Killed (program cc1)

I've changed devel/arm-none-eabi/gcc-linaro to build with --without-isl

other gcc ports that do not yet have --without-isl/--with-isl

devel/avr32/gcc
devel/avr32/gcc-bootstrap
devel/msp430/gcc
devel/ti-msp430gcc
devel/xtensa-elf/gcc

Re: aarch64 bulk build report

[Omar Polo]

> http://build-failures.rhaalovely.net/aarch64/2021-11-18/comms/pterm.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/databases/pgadmin3.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/devel/codeblocks.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/devel/luarocks,lua53.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/emulators/nono.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/games/golly.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/games/scorched3d.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/games/scummvm-tools.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/geo/spatialite/gui.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/graphics/delaboratory.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/misc/rocrail,-gui.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/x11/py-wxPython.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/x11/wxSVG.log
> http://build-failures.rhaalovely.net/aarch64/2021-11-18/x11/xchm.log

These are my fault, sorry.  I forgot a BDEP on luarocks (thanks aja@ for
fixing it) and then there's the wxwidgets fallout (also fixed.)

Re: aarch64 bulk build report

[Kevin Lo]

On Tue, Nov 09, 2021 at 01:14:48AM -0700, phess...@openbsd.org wrote:
> 
> bulk build on arm64.ports.openbsd.org
> started on  Sat Nov 6 15:38:08 MDT 2021
> finished at Tue Nov 9 01:14:38 MST 2021
> lasted 2D10h36m
> done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1378: Sat Nov  6 
> 12:18:34 MDT 2021
> 
> built packages:10972
> Nov 6:3159
> Nov 7:1385
> Nov 8:3889
> Nov 9:2538
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-11-06/summary.log
> 
> build failures: 5
> http://build-failures.rhaalovely.net/aarch64/2021-11-06/devel/arm-compute-library.log

Fix fallout from scons update, thanks.

Re: aarch64 bulk build report

[Thomas Frohwein]

On Sun, Oct 17, 2021 at 11:44:51AM -0600, phess...@openbsd.org wrote:
[...]
> http://build-failures.rhaalovely.net/aarch64/2021-10-15/games/shockolate.log

This update that I just committed *should* fix the build on aarch64:
https://marc.info/?l=openbsd-ports-cvs&m=163456434527694&w=2

Re: aarch64 bulk build report

[Patrick Wildt]

Am Sun, Apr 11, 2021 at 10:59:02PM -0600 schrieb phess...@openbsd.org:
> bulk build on arm64.ports.openbsd.org
> started on  Fri Apr 9 13:05:37 MDT 2021
> finished at Sun Apr 11 22:58:23 MDT 2021
> lasted 2D09h52m
> done with kern.version=OpenBSD 6.9 (GENERIC.MP) #1119: Fri Apr  9 03:23:43 
> MDT 2021
> 
> built packages:8798
> Apr 9:3480
> Apr 10:1279
> Apr 11:4038
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-04-09/summary.log
> 
> build failures: 1723

Oh, lots of No space left on device?