[mapnik] build failure

Operating system
Manjaro Linux 22.1.0 Talos (6.1.31-1 kernel)
Compiler
gcc, clang
Steps to reproduce the behavior
vcpkg install mapnik
vcpkg install

Failure logs
I tried to build with x64-linux-dynamic and x64-linux both same result.
at first i thought It's my systems problem so i tried to build it in a docker and i got the same error.

 console output
-- Running vcpkg install
Detecting compiler hash for triplet x64-linux...
Detecting compiler hash for triplet x64-linux-dynamic...
The following packages will be rebuilt:
  * boost-algorithm[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-align[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-any[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-array[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-assert[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-assign[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-atomic[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-bimap[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-bind[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-build[core]:x64-linux -> 1.82.0#1
  * boost-chrono[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-circular-buffer[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-concept-check[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-config[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-container[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-container-hash[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-conversion[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-core[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-date-time[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-describe[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-detail[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-dynamic-bitset[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-endian[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-exception[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-filesystem[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-format[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-function[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-function-types[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-functional[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-fusion[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-geometry[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-gil[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-integer[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-interprocess[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-intrusive[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-io[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-iterator[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-lambda[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-lexical-cast[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-locale[core,icu]:x64-linux-dynamic -> 1.82.0#1
  * boost-math[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-modular-build-helper[core]:x64-linux -> 1.82.0#1
  * boost-move[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-mp11[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-mpl[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-msm[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-multi-index[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-multiprecision[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-numeric-conversion[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-optional[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-parameter[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-phoenix[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-polygon[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-pool[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-predef[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-preprocessor[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-program-options[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-property-tree[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-proto[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-ptr-container[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-qvm[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-random[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-range[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-ratio[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-rational[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-regex[core,icu]:x64-linux-dynamic -> 1.82.0#1
  * boost-serialization[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-smart-ptr[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-spirit[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-static-assert[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-system[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-thread[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-throw-exception[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-tokenizer[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-tuple[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-type-index[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-type-traits[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-typeof[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-uninstall[core]:x64-linux -> 1.82.0#1
  * boost-uninstall[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-unordered[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-utility[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-variant[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-variant2[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-vcpkg-helpers[core]:x64-linux-dynamic -> 1.82.0#1
  * boost-winapi[core]:x64-linux-dynamic -> 1.82.0#1
  * brotli[core]:x64-linux-dynamic -> 1.0.9#5
  * bzip2[core,tool]:x64-linux-dynamic -> 1.0.8#4
  * curl[core,non-http,openssl,ssl]:x64-linux-dynamic -> 8.1.2
  * freetype[brotli,bzip2,core,png,zlib]:x64-linux-dynamic -> 2.12.1#3
  * harfbuzz[core,icu]:x64-linux-dynamic -> 7.2.0
  * icu[core]:x64-linux-dynamic -> 72.1#5
  * icu[core,tools]:x64-linux -> 72.1#5
  * libiconv[core]:x64-linux-dynamic -> 1.17#1
  * libjpeg-turbo[core]:x64-linux-dynamic -> <IP_ADDRESS>#1
  * liblzma[core]:x64-linux-dynamic -> 5.4.1#1
  * libpng[core]:x64-linux-dynamic -> 1.6.39#1
  * libwebp[core,libwebpmux,nearlossless,simd]:x64-linux-dynamic -> 1.3.0
  * libxml2[core,iconv,lzma,zlib]:x64-linux-dynamic -> 2.10.3#1
  * mapbox-geometry[core]:x64-linux-dynamic -> 2.0.3
  * mapbox-polylabel[core]:x64-linux-dynamic -> 1.1.0
  * mapbox-variant[core]:x64-linux-dynamic -> 1.2.0#2
    mapnik[core,grid-renderer,input-geojson,input-shape,jpeg,libxml2,png,proj,svg-renderer,tiff,utility-mapnik-index,utility-mapnik-render,utility-shapeindex,webp]:x64-linux-dynamic -> 2023-01-17#1
  * nlohmann-json[core]:x64-linux-dynamic -> 3.11.2
  * openssl[core]:x64-linux-dynamic -> 3.1.1
  * proj[core,net,tiff]:x64-linux-dynamic -> 9.2.0
  * protobuf[core]:x64-linux-dynamic -> 3.21.12
  * protobuf[core]:x64-linux -> 3.21.12
  * protozero[core]:x64-linux-dynamic -> 1.7.1
  * sqlite3[core]:x64-linux-dynamic -> 3.40.1#3
  * sqlite3[core,tool]:x64-linux -> 3.40.1#3
  * tiff[core,jpeg,lzma,zip]:x64-linux-dynamic -> 4.5.0#3
  * vcpkg-cmake[core]:x64-linux -> 2022-12-22
  * vcpkg-cmake-config[core]:x64-linux -> 2022-02-06#1
  * vcpkg-cmake-get-vars[core]:x64-linux -> 2023-03-02
  * vcpkg-tool-meson[core]:x64-linux -> 0.63
  * zlib[core]:x64-linux-dynamic -> 1.2.13
Additional packages (*) will be modified to complete this operation.
Removing 1/234 mapnik:x64-linux-dynamic
Elapsed time to handle mapnik:x64-linux-dynamic: 55.6 ms
Removing 2/234 boost-assign:x64-linux-dynamic
Elapsed time to handle boost-assign:x64-linux-dynamic: 7.29 ms
Removing 3/234 boost-ptr-container:x64-linux-dynamic
Elapsed time to handle boost-ptr-container:x64-linux-dynamic: 5.44 ms
Removing 4/234 boost-bimap:x64-linux-dynamic
Elapsed time to handle boost-bimap:x64-linux-dynamic: 24.6 ms
Removing 5/234 boost-lambda:x64-linux-dynamic
Elapsed time to handle boost-lambda:x64-linux-dynamic: 7.74 ms
Removing 6/234 boost-filesystem:x64-linux-dynamic
Elapsed time to handle boost-filesystem:x64-linux-dynamic: 8.78 ms
Removing 7/234 boost-geometry:x64-linux-dynamic
Elapsed time to handle boost-geometry:x64-linux-dynamic: 237 ms
Removing 8/234 boost-multiprecision:x64-linux-dynamic
Elapsed time to handle boost-multiprecision:x64-linux-dynamic: 22.3 ms
Removing 9/234 boost-math:x64-linux-dynamic
Elapsed time to handle boost-math:x64-linux-dynamic: 75.6 ms
Removing 10/234 boost-random:x64-linux-dynamic
Elapsed time to handle boost-random:x64-linux-dynamic: 24.9 ms
Removing 11/234 boost-dynamic-bitset:x64-linux-dynamic
Elapsed time to handle boost-dynamic-bitset:x64-linux-dynamic: 4.22 ms
Removing 12/234 boost-polygon:x64-linux-dynamic
Elapsed time to handle boost-polygon:x64-linux-dynamic: 10.7 ms
Removing 13/234 boost-qvm:x64-linux-dynamic
Elapsed time to handle boost-qvm:x64-linux-dynamic: 17.2 ms
Removing 14/234 boost-gil:x64-linux-dynamic
Elapsed time to handle boost-gil:x64-linux-dynamic: 49.2 ms
Removing 15/234 boost-interprocess:x64-linux-dynamic
Elapsed time to handle boost-interprocess:x64-linux-dynamic: 29.9 ms
Removing 16/234 boost-locale:x64-linux-dynamic
Elapsed time to handle boost-locale:x64-linux-dynamic: 23.6 ms
Removing 17/234 boost-msm:x64-linux-dynamic
Elapsed time to handle boost-msm:x64-linux-dynamic: 7.66 ms
Removing 18/234 boost-circular-buffer:x64-linux-dynamic
Elapsed time to handle boost-circular-buffer:x64-linux-dynamic: 12.2 ms
Removing 19/234 boost-parameter:x64-linux-dynamic
Elapsed time to handle boost-parameter:x64-linux-dynamic: 21.2 ms
Removing 20/234 boost-property-tree:x64-linux-dynamic
Elapsed time to handle boost-property-tree:x64-linux-dynamic: 23.5 ms
Removing 21/234 boost-format:x64-linux-dynamic
Elapsed time to handle boost-format:x64-linux-dynamic: 4.57 ms
Removing 22/234 boost-multi-index:x64-linux-dynamic
Elapsed time to handle boost-multi-index:x64-linux-dynamic: 12.5 ms
Removing 23/234 boost-serialization:x64-linux-dynamic
Elapsed time to handle boost-serialization:x64-linux-dynamic: 53.4 ms
Removing 24/234 boost-spirit:x64-linux-dynamic
Elapsed time to handle boost-spirit:x64-linux-dynamic: 196 ms
Removing 25/234 boost-endian:x64-linux-dynamic
Elapsed time to handle boost-endian:x64-linux-dynamic: 11.5 ms
Removing 26/234 boost-phoenix:x64-linux-dynamic
Elapsed time to handle boost-phoenix:x64-linux-dynamic: 92 ms
Removing 27/234 boost-pool:x64-linux-dynamic
Elapsed time to handle boost-pool:x64-linux-dynamic: 4.16 ms
Removing 28/234 boost-proto:x64-linux-dynamic
Elapsed time to handle boost-proto:x64-linux-dynamic: 25.1 ms
Removing 29/234 boost-thread:x64-linux-dynamic
Elapsed time to handle boost-thread:x64-linux-dynamic: 40.1 ms
Removing 30/234 boost-atomic:x64-linux-dynamic
Elapsed time to handle boost-atomic:x64-linux-dynamic: 19.4 ms
Removing 31/234 boost-align:x64-linux-dynamic
Elapsed time to handle boost-align:x64-linux-dynamic: 11.6 ms
Removing 32/234 boost-chrono:x64-linux-dynamic
Elapsed time to handle boost-chrono:x64-linux-dynamic: 38.4 ms
Removing 33/234 boost-ratio:x64-linux-dynamic
Elapsed time to handle boost-ratio:x64-linux-dynamic: 9.16 ms
Removing 34/234 boost-rational:x64-linux-dynamic
Elapsed time to handle boost-rational:x64-linux-dynamic: 2.47 ms
Removing 35/234 boost-date-time:x64-linux-dynamic
Elapsed time to handle boost-date-time:x64-linux-dynamic: 24.5 ms
Removing 36/234 boost-algorithm:x64-linux-dynamic
Elapsed time to handle boost-algorithm:x64-linux-dynamic: 21.5 ms
Removing 37/234 boost-exception:x64-linux-dynamic
Elapsed time to handle boost-exception:x64-linux-dynamic: 7.88 ms
Removing 38/234 boost-unordered:x64-linux-dynamic
Elapsed time to handle boost-unordered:x64-linux-dynamic: 15.4 ms
Removing 39/234 boost-variant:x64-linux-dynamic
Elapsed time to handle boost-variant:x64-linux-dynamic: 5.38 ms
Removing 40/234 boost-system:x64-linux-dynamic
Elapsed time to handle boost-system:x64-linux-dynamic: 19.3 ms
Removing 41/234 boost-variant2:x64-linux-dynamic
Elapsed time to handle boost-variant2:x64-linux-dynamic: 2.58 ms
Removing 42/234 boost-winapi:x64-linux-dynamic
Elapsed time to handle boost-winapi:x64-linux-dynamic: 22.8 ms
Removing 43/234 harfbuzz:x64-linux-dynamic
Elapsed time to handle harfbuzz:x64-linux-dynamic: 18.6 ms
Removing 44/234 freetype:x64-linux-dynamic
Elapsed time to handle freetype:x64-linux-dynamic: 13.9 ms
Removing 45/234 brotli:x64-linux-dynamic
Elapsed time to handle brotli:x64-linux-dynamic: 10.5 ms
Removing 46/234 bzip2:x64-linux-dynamic
Elapsed time to handle bzip2:x64-linux-dynamic: 5.73 ms
Removing 47/234 vcpkg-tool-meson:x64-linux
Elapsed time to handle vcpkg-tool-meson:x64-linux: 103 ms
Removing 48/234 mapbox-polylabel:x64-linux-dynamic
Elapsed time to handle mapbox-polylabel:x64-linux-dynamic: 2.28 ms
Removing 49/234 mapbox-geometry:x64-linux-dynamic
Elapsed time to handle mapbox-geometry:x64-linux-dynamic: 4.89 ms
Removing 50/234 mapbox-variant:x64-linux-dynamic
Elapsed time to handle mapbox-variant:x64-linux-dynamic: 6.25 ms
Removing 51/234 protozero:x64-linux-dynamic
Elapsed time to handle protozero:x64-linux-dynamic: 3.49 ms
Removing 52/234 protobuf:x64-linux-dynamic
Elapsed time to handle protobuf:x64-linux-dynamic: 49.2 ms
Removing 53/234 protobuf:x64-linux
Elapsed time to handle protobuf:x64-linux: 28.8 ms
Removing 54/234 libxml2:x64-linux-dynamic
Elapsed time to handle libxml2:x64-linux-dynamic: 5.15 ms
Removing 55/234 libiconv:x64-linux-dynamic
Elapsed time to handle libiconv:x64-linux-dynamic: 2.84 ms
Removing 56/234 libpng:x64-linux-dynamic
Elapsed time to handle libpng:x64-linux-dynamic: 9.82 ms
Removing 57/234 proj:x64-linux-dynamic
Elapsed time to handle proj:x64-linux-dynamic: 19.4 ms
Removing 58/234 nlohmann-json:x64-linux-dynamic
Elapsed time to handle nlohmann-json:x64-linux-dynamic: 12.3 ms
Removing 59/234 sqlite3:x64-linux-dynamic
Elapsed time to handle sqlite3:x64-linux-dynamic: 12.7 ms
Removing 60/234 sqlite3:x64-linux
Elapsed time to handle sqlite3:x64-linux: 4.53 ms
Removing 61/234 curl:x64-linux-dynamic
Elapsed time to handle curl:x64-linux-dynamic: 7.35 ms
Removing 62/234 openssl:x64-linux-dynamic
Elapsed time to handle openssl:x64-linux-dynamic: 51.1 ms
Removing 63/234 tiff:x64-linux-dynamic
Elapsed time to handle tiff:x64-linux-dynamic: 8.12 ms
Removing 64/234 libjpeg-turbo:x64-linux-dynamic
Elapsed time to handle libjpeg-turbo:x64-linux-dynamic: 8.29 ms
Removing 65/234 liblzma:x64-linux-dynamic
Elapsed time to handle liblzma:x64-linux-dynamic: 4.93 ms
Removing 66/234 zlib:x64-linux-dynamic
Elapsed time to handle zlib:x64-linux-dynamic: 9.9 ms
Removing 67/234 boost-program-options:x64-linux-dynamic
Elapsed time to handle boost-program-options:x64-linux-dynamic: 12.1 ms
Removing 68/234 boost-any:x64-linux-dynamic
Elapsed time to handle boost-any:x64-linux-dynamic: 3.08 ms
Removing 69/234 boost-type-index:x64-linux-dynamic
Elapsed time to handle boost-type-index:x64-linux-dynamic: 4.59 ms
Removing 70/234 boost-lexical-cast:x64-linux-dynamic
Elapsed time to handle boost-lexical-cast:x64-linux-dynamic: 8.87 ms
Removing 71/234 boost-container:x64-linux-dynamic
Elapsed time to handle boost-container:x64-linux-dynamic: 16.8 ms
Removing 72/234 boost-intrusive:x64-linux-dynamic
Elapsed time to handle boost-intrusive:x64-linux-dynamic: 32.6 ms
Removing 73/234 boost-numeric-conversion:x64-linux-dynamic
Elapsed time to handle boost-numeric-conversion:x64-linux-dynamic: 15.2 ms
Removing 74/234 boost-range:x64-linux-dynamic
Elapsed time to handle boost-range:x64-linux-dynamic: 25.7 ms
Removing 75/234 boost-array:x64-linux-dynamic
Elapsed time to handle boost-array:x64-linux-dynamic: 7.28 ms
Removing 76/234 boost-regex:x64-linux-dynamic
Elapsed time to handle boost-regex:x64-linux-dynamic: 22.9 ms
Removing 77/234 boost-build:x64-linux
Elapsed time to handle boost-build:x64-linux: 149 ms
Removing 78/234 boost-integer:x64-linux-dynamic
Elapsed time to handle boost-integer:x64-linux-dynamic: 9.06 ms
Removing 79/234 icu:x64-linux-dynamic
Elapsed time to handle icu:x64-linux-dynamic: 33.7 ms
Removing 80/234 icu:x64-linux
Elapsed time to handle icu:x64-linux: 49.2 ms
Removing 81/234 boost-modular-build-helper:x64-linux
Elapsed time to handle boost-modular-build-helper:x64-linux: 4.9 ms
Removing 82/234 boost-uninstall:x64-linux
Elapsed time to handle boost-uninstall:x64-linux: 9.83 ms
Removing 83/234 vcpkg-cmake-get-vars:x64-linux
Elapsed time to handle vcpkg-cmake-get-vars:x64-linux: 2.8 ms
Removing 84/234 boost-tokenizer:x64-linux-dynamic
Elapsed time to handle boost-tokenizer:x64-linux-dynamic: 3.5 ms
Removing 85/234 boost-iterator:x64-linux-dynamic
Elapsed time to handle boost-iterator:x64-linux-dynamic: 14.4 ms
Removing 86/234 boost-concept-check:x64-linux-dynamic
Elapsed time to handle boost-concept-check:x64-linux-dynamic: 4.19 ms
Removing 87/234 boost-conversion:x64-linux-dynamic
Elapsed time to handle boost-conversion:x64-linux-dynamic: 2.54 ms
Removing 88/234 boost-fusion:x64-linux-dynamic
Elapsed time to handle boost-fusion:x64-linux-dynamic: 175 ms
Removing 89/234 boost-container-hash:x64-linux-dynamic
Elapsed time to handle boost-container-hash:x64-linux-dynamic: 29 ms
Removing 90/234 boost-describe:x64-linux-dynamic
Elapsed time to handle boost-describe:x64-linux-dynamic: 8.73 ms
Removing 91/234 boost-mp11:x64-linux-dynamic
Elapsed time to handle boost-mp11:x64-linux-dynamic: 13.2 ms
Removing 92/234 boost-functional:x64-linux-dynamic
Elapsed time to handle boost-functional:x64-linux-dynamic: 3.66 ms
Removing 93/234 boost-function:x64-linux-dynamic
Elapsed time to handle boost-function:x64-linux-dynamic: 12.9 ms
Removing 94/234 boost-bind:x64-linux-dynamic
Elapsed time to handle boost-bind:x64-linux-dynamic: 25.6 ms
Removing 95/234 boost-function-types:x64-linux-dynamic
Elapsed time to handle boost-function-types:x64-linux-dynamic: 13.9 ms
Removing 96/234 boost-tuple:x64-linux-dynamic
Elapsed time to handle boost-tuple:x64-linux-dynamic: 6.29 ms
Removing 97/234 boost-typeof:x64-linux-dynamic
Elapsed time to handle boost-typeof:x64-linux-dynamic: 11.7 ms
Removing 98/234 boost-mpl:x64-linux-dynamic
Elapsed time to handle boost-mpl:x64-linux-dynamic: 144 ms
Removing 99/234 boost-optional:x64-linux-dynamic
Elapsed time to handle boost-optional:x64-linux-dynamic: 19.8 ms
Removing 100/234 boost-detail:x64-linux-dynamic
Elapsed time to handle boost-detail:x64-linux-dynamic: 5.82 ms
Removing 101/234 boost-predef:x64-linux-dynamic
Elapsed time to handle boost-predef:x64-linux-dynamic: 33.3 ms
Removing 102/234 boost-smart-ptr:x64-linux-dynamic
Elapsed time to handle boost-smart-ptr:x64-linux-dynamic: 20.1 ms
Removing 103/234 boost-move:x64-linux-dynamic
Elapsed time to handle boost-move:x64-linux-dynamic: 26.2 ms
Removing 104/234 boost-utility:x64-linux-dynamic
Elapsed time to handle boost-utility:x64-linux-dynamic: 12.3 ms
Removing 105/234 boost-core:x64-linux-dynamic
Elapsed time to handle boost-core:x64-linux-dynamic: 14.7 ms
Removing 106/234 boost-io:x64-linux-dynamic
Elapsed time to handle boost-io:x64-linux-dynamic: 10.5 ms
Removing 107/234 boost-preprocessor:x64-linux-dynamic
Elapsed time to handle boost-preprocessor:x64-linux-dynamic: 95 ms
Removing 108/234 boost-throw-exception:x64-linux-dynamic
Elapsed time to handle boost-throw-exception:x64-linux-dynamic: 9.02 ms
Removing 109/234 boost-assert:x64-linux-dynamic
Elapsed time to handle boost-assert:x64-linux-dynamic: 2.82 ms
Removing 110/234 boost-type-traits:x64-linux-dynamic
Elapsed time to handle boost-type-traits:x64-linux-dynamic: 34.8 ms
Removing 111/234 boost-static-assert:x64-linux-dynamic
Elapsed time to handle boost-static-assert:x64-linux-dynamic: 15.8 ms
Removing 112/234 boost-config:x64-linux-dynamic
Elapsed time to handle boost-config:x64-linux-dynamic: 45.6 ms
Removing 113/234 boost-vcpkg-helpers:x64-linux-dynamic
Elapsed time to handle boost-vcpkg-helpers:x64-linux-dynamic: 6.06 ms
Removing 114/234 boost-uninstall:x64-linux-dynamic
Elapsed time to handle boost-uninstall:x64-linux-dynamic: 3.6 ms
Removing 115/234 libwebp:x64-linux-dynamic
Elapsed time to handle libwebp:x64-linux-dynamic: 17.7 ms
Removing 116/234 vcpkg-cmake:x64-linux
Elapsed time to handle vcpkg-cmake:x64-linux: 2.09 ms
Removing 117/234 vcpkg-cmake-config:x64-linux
Elapsed time to handle vcpkg-cmake-config:x64-linux: 1.76 ms
Restored 116 package(s) from /home/kian/.cache/vcpkg/archives in 7.6 s. Use --debug to see more details.
Installing 118/234 vcpkg-cmake-config:x64-linux...
Elapsed time to handle vcpkg-cmake-config:x64-linux: 1.74 ms
Installing 119/234 vcpkg-cmake:x64-linux...
Elapsed time to handle vcpkg-cmake:x64-linux: 1.56 ms
Installing 120/234 libwebp:x64-linux-dynamic...
Elapsed time to handle libwebp:x64-linux-dynamic: 19.7 ms
Installing 121/234 boost-uninstall:x64-linux-dynamic...
Elapsed time to handle boost-uninstall:x64-linux-dynamic: 1.34 ms
Installing 122/234 boost-vcpkg-helpers:x64-linux-dynamic...
Elapsed time to handle boost-vcpkg-helpers:x64-linux-dynamic: 5.73 ms
Installing 123/234 boost-config:x64-linux-dynamic...
Elapsed time to handle boost-config:x64-linux-dynamic: 32.9 ms
Installing 124/234 boost-static-assert:x64-linux-dynamic...
Elapsed time to handle boost-static-assert:x64-linux-dynamic: 1.8 ms
Installing 125/234 boost-type-traits:x64-linux-dynamic...
Elapsed time to handle boost-type-traits:x64-linux-dynamic: 22.7 ms
Installing 126/234 boost-assert:x64-linux-dynamic...
Elapsed time to handle boost-assert:x64-linux-dynamic: 2.66 ms
Installing 127/234 boost-throw-exception:x64-linux-dynamic...
Elapsed time to handle boost-throw-exception:x64-linux-dynamic: 2.47 ms
Installing 128/234 boost-preprocessor:x64-linux-dynamic...
Elapsed time to handle boost-preprocessor:x64-linux-dynamic: 60.9 ms
Installing 129/234 boost-io:x64-linux-dynamic...
Elapsed time to handle boost-io:x64-linux-dynamic: 5.08 ms
Installing 130/234 boost-core:x64-linux-dynamic...
Elapsed time to handle boost-core:x64-linux-dynamic: 9.54 ms
Installing 131/234 boost-utility:x64-linux-dynamic...
Elapsed time to handle boost-utility:x64-linux-dynamic: 5.84 ms
Installing 132/234 boost-move:x64-linux-dynamic...
Elapsed time to handle boost-move:x64-linux-dynamic: 8.09 ms
Installing 133/234 boost-smart-ptr:x64-linux-dynamic...
Elapsed time to handle boost-smart-ptr:x64-linux-dynamic: 13.7 ms
Installing 134/234 boost-predef:x64-linux-dynamic...
Elapsed time to handle boost-predef:x64-linux-dynamic: 20.4 ms
Installing 135/234 boost-detail:x64-linux-dynamic...
Elapsed time to handle boost-detail:x64-linux-dynamic: 5.64 ms
Installing 136/234 boost-optional:x64-linux-dynamic...
Elapsed time to handle boost-optional:x64-linux-dynamic: 5.36 ms
Installing 137/234 boost-mpl:x64-linux-dynamic...
Elapsed time to handle boost-mpl:x64-linux-dynamic: 130 ms
Installing 138/234 boost-typeof:x64-linux-dynamic...
Elapsed time to handle boost-typeof:x64-linux-dynamic: 22 ms
Installing 139/234 boost-tuple:x64-linux-dynamic...
Elapsed time to handle boost-tuple:x64-linux-dynamic: 4.14 ms
Installing 140/234 boost-function-types:x64-linux-dynamic...
Elapsed time to handle boost-function-types:x64-linux-dynamic: 13.8 ms
Installing 141/234 boost-bind:x64-linux-dynamic...
Elapsed time to handle boost-bind:x64-linux-dynamic: 7.13 ms
Installing 142/234 boost-function:x64-linux-dynamic...
Elapsed time to handle boost-function:x64-linux-dynamic: 7.68 ms
Installing 143/234 boost-functional:x64-linux-dynamic...
Elapsed time to handle boost-functional:x64-linux-dynamic: 6.43 ms
Installing 144/234 boost-mp11:x64-linux-dynamic...
Elapsed time to handle boost-mp11:x64-linux-dynamic: 8.4 ms
Installing 145/234 boost-describe:x64-linux-dynamic...
Elapsed time to handle boost-describe:x64-linux-dynamic: 9.38 ms
Installing 146/234 boost-container-hash:x64-linux-dynamic...
Elapsed time to handle boost-container-hash:x64-linux-dynamic: 7.48 ms
Installing 147/234 boost-fusion:x64-linux-dynamic...
Elapsed time to handle boost-fusion:x64-linux-dynamic: 161 ms
Installing 148/234 boost-conversion:x64-linux-dynamic...
Elapsed time to handle boost-conversion:x64-linux-dynamic: 7.21 ms
Installing 149/234 boost-concept-check:x64-linux-dynamic...
Elapsed time to handle boost-concept-check:x64-linux-dynamic: 7.42 ms
Installing 150/234 boost-iterator:x64-linux-dynamic...
Elapsed time to handle boost-iterator:x64-linux-dynamic: 11.8 ms
Installing 151/234 boost-tokenizer:x64-linux-dynamic...
Elapsed time to handle boost-tokenizer:x64-linux-dynamic: 6.77 ms
Installing 152/234 vcpkg-cmake-get-vars:x64-linux...
Elapsed time to handle vcpkg-cmake-get-vars:x64-linux: 4.02 ms
Installing 153/234 boost-uninstall:x64-linux...
Elapsed time to handle boost-uninstall:x64-linux: 3.04 ms
Installing 154/234 boost-modular-build-helper:x64-linux...
Elapsed time to handle boost-modular-build-helper:x64-linux: 4.93 ms
Installing 155/234 icu:x64-linux...
Elapsed time to handle icu:x64-linux: 549 ms
Installing 156/234 icu:x64-linux-dynamic...
Elapsed time to handle icu:x64-linux-dynamic: 148 ms
Installing 157/234 boost-integer:x64-linux-dynamic...
Elapsed time to handle boost-integer:x64-linux-dynamic: 8.81 ms
Installing 158/234 boost-build:x64-linux...
Elapsed time to handle boost-build:x64-linux: 132 ms
Installing 159/234 boost-regex:x64-linux-dynamic...
Elapsed time to handle boost-regex:x64-linux-dynamic: 42.9 ms
Installing 160/234 boost-array:x64-linux-dynamic...
Elapsed time to handle boost-array:x64-linux-dynamic: 7.74 ms
Installing 161/234 boost-range:x64-linux-dynamic...
Elapsed time to handle boost-range:x64-linux-dynamic: 26.3 ms
Installing 162/234 boost-numeric-conversion:x64-linux-dynamic...
Elapsed time to handle boost-numeric-conversion:x64-linux-dynamic: 11.3 ms
Installing 163/234 boost-intrusive:x64-linux-dynamic...
Elapsed time to handle boost-intrusive:x64-linux-dynamic: 19.1 ms
Installing 164/234 boost-container:x64-linux-dynamic...
Elapsed time to handle boost-container:x64-linux-dynamic: 26.1 ms
Installing 165/234 boost-lexical-cast:x64-linux-dynamic...
Elapsed time to handle boost-lexical-cast:x64-linux-dynamic: 9.9 ms
Installing 166/234 boost-type-index:x64-linux-dynamic...
Elapsed time to handle boost-type-index:x64-linux-dynamic: 10.4 ms
Installing 167/234 boost-any:x64-linux-dynamic...
Elapsed time to handle boost-any:x64-linux-dynamic: 9.18 ms
Installing 168/234 boost-program-options:x64-linux-dynamic...
Elapsed time to handle boost-program-options:x64-linux-dynamic: 46.6 ms
Installing 169/234 zlib:x64-linux-dynamic...
Elapsed time to handle zlib:x64-linux-dynamic: 10.4 ms
Installing 170/234 liblzma:x64-linux-dynamic...
Elapsed time to handle liblzma:x64-linux-dynamic: 13.5 ms
Installing 171/234 libjpeg-turbo:x64-linux-dynamic...
Elapsed time to handle libjpeg-turbo:x64-linux-dynamic: 21.8 ms
Installing 172/234 tiff:x64-linux-dynamic...
Elapsed time to handle tiff:x64-linux-dynamic: 13.7 ms
Installing 173/234 openssl:x64-linux-dynamic...
Elapsed time to handle openssl:x64-linux-dynamic: 94.8 ms
Installing 174/234 curl:x64-linux-dynamic...
Elapsed time to handle curl:x64-linux-dynamic: 23.9 ms
Installing 175/234 sqlite3:x64-linux...
Elapsed time to handle sqlite3:x64-linux: 25.3 ms
Installing 176/234 sqlite3:x64-linux-dynamic...
Elapsed time to handle sqlite3:x64-linux-dynamic: 23 ms
Installing 177/234 nlohmann-json:x64-linux-dynamic...
Elapsed time to handle nlohmann-json:x64-linux-dynamic: 15.8 ms
Installing 178/234 proj:x64-linux-dynamic...
Elapsed time to handle proj:x64-linux-dynamic: 203 ms
Installing 179/234 libpng:x64-linux-dynamic...
Elapsed time to handle libpng:x64-linux-dynamic: 15.3 ms
Installing 180/234 libiconv:x64-linux-dynamic...
Elapsed time to handle libiconv:x64-linux-dynamic: 8.49 ms
Installing 181/234 libxml2:x64-linux-dynamic...
Elapsed time to handle libxml2:x64-linux-dynamic: 41.1 ms
Installing 182/234 protobuf:x64-linux...
Elapsed time to handle protobuf:x64-linux: 575 ms
Installing 183/234 protobuf:x64-linux-dynamic...
Elapsed time to handle protobuf:x64-linux-dynamic: 365 ms
Installing 184/234 protozero:x64-linux-dynamic...
Elapsed time to handle protozero:x64-linux-dynamic: 24.2 ms
Installing 185/234 mapbox-variant:x64-linux-dynamic...
Elapsed time to handle mapbox-variant:x64-linux-dynamic: 19.1 ms
Installing 186/234 mapbox-geometry:x64-linux-dynamic...
Elapsed time to handle mapbox-geometry:x64-linux-dynamic: 13.6 ms
Installing 187/234 mapbox-polylabel:x64-linux-dynamic...
Elapsed time to handle mapbox-polylabel:x64-linux-dynamic: 12 ms
Installing 188/234 vcpkg-tool-meson:x64-linux...
Elapsed time to handle vcpkg-tool-meson:x64-linux: 228 ms
Installing 189/234 bzip2:x64-linux-dynamic...
Elapsed time to handle bzip2:x64-linux-dynamic: 30.3 ms
Installing 190/234 brotli:x64-linux-dynamic...
Elapsed time to handle brotli:x64-linux-dynamic: 55.4 ms
Installing 191/234 freetype:x64-linux-dynamic...
Elapsed time to handle freetype:x64-linux-dynamic: 39 ms
Installing 192/234 harfbuzz:x64-linux-dynamic...
Elapsed time to handle harfbuzz:x64-linux-dynamic: 224 ms
Installing 193/234 boost-winapi:x64-linux-dynamic...
Elapsed time to handle boost-winapi:x64-linux-dynamic: 26.5 ms
Installing 194/234 boost-variant2:x64-linux-dynamic...
Elapsed time to handle boost-variant2:x64-linux-dynamic: 16.7 ms
Installing 195/234 boost-system:x64-linux-dynamic...
Elapsed time to handle boost-system:x64-linux-dynamic: 25.4 ms
Installing 196/234 boost-variant:x64-linux-dynamic...
Elapsed time to handle boost-variant:x64-linux-dynamic: 23.5 ms
Installing 197/234 boost-unordered:x64-linux-dynamic...
Elapsed time to handle boost-unordered:x64-linux-dynamic: 14.4 ms
Installing 198/234 boost-exception:x64-linux-dynamic...
Elapsed time to handle boost-exception:x64-linux-dynamic: 13.9 ms
Installing 199/234 boost-algorithm:x64-linux-dynamic...
Elapsed time to handle boost-algorithm:x64-linux-dynamic: 22.9 ms
Installing 200/234 boost-date-time:x64-linux-dynamic...
Elapsed time to handle boost-date-time:x64-linux-dynamic: 23.8 ms
Installing 201/234 boost-rational:x64-linux-dynamic...
Elapsed time to handle boost-rational:x64-linux-dynamic: 11.3 ms
Installing 202/234 boost-ratio:x64-linux-dynamic...
Elapsed time to handle boost-ratio:x64-linux-dynamic: 15.3 ms
Installing 203/234 boost-chrono:x64-linux-dynamic...
Elapsed time to handle boost-chrono:x64-linux-dynamic: 24.4 ms
Installing 204/234 boost-align:x64-linux-dynamic...
Elapsed time to handle boost-align:x64-linux-dynamic: 16.9 ms
Installing 205/234 boost-atomic:x64-linux-dynamic...
Elapsed time to handle boost-atomic:x64-linux-dynamic: 30.6 ms
Installing 206/234 boost-thread:x64-linux-dynamic...
Elapsed time to handle boost-thread:x64-linux-dynamic: 65.4 ms
Installing 207/234 boost-proto:x64-linux-dynamic...
Elapsed time to handle boost-proto:x64-linux-dynamic: 33.3 ms
Installing 208/234 boost-pool:x64-linux-dynamic...
Elapsed time to handle boost-pool:x64-linux-dynamic: 14.4 ms
Installing 209/234 boost-phoenix:x64-linux-dynamic...
Elapsed time to handle boost-phoenix:x64-linux-dynamic: 134 ms
Installing 210/234 boost-endian:x64-linux-dynamic...
Elapsed time to handle boost-endian:x64-linux-dynamic: 21.3 ms
Installing 211/234 boost-spirit:x64-linux-dynamic...
Elapsed time to handle boost-spirit:x64-linux-dynamic: 137 ms
Installing 212/234 boost-serialization:x64-linux-dynamic...
Elapsed time to handle boost-serialization:x64-linux-dynamic: 125 ms
Installing 213/234 boost-multi-index:x64-linux-dynamic...
Elapsed time to handle boost-multi-index:x64-linux-dynamic: 41.9 ms
Installing 214/234 boost-format:x64-linux-dynamic...
Elapsed time to handle boost-format:x64-linux-dynamic: 19.2 ms
Installing 215/234 boost-property-tree:x64-linux-dynamic...
Elapsed time to handle boost-property-tree:x64-linux-dynamic: 26.6 ms
Installing 216/234 boost-parameter:x64-linux-dynamic...
Elapsed time to handle boost-parameter:x64-linux-dynamic: 30.3 ms
Installing 217/234 boost-circular-buffer:x64-linux-dynamic...
Elapsed time to handle boost-circular-buffer:x64-linux-dynamic: 14.5 ms
Installing 218/234 boost-msm:x64-linux-dynamic...
Elapsed time to handle boost-msm:x64-linux-dynamic: 30.3 ms
Installing 219/234 boost-locale:x64-linux-dynamic...
Elapsed time to handle boost-locale:x64-linux-dynamic: 87.9 ms
Installing 220/234 boost-interprocess:x64-linux-dynamic...
Elapsed time to handle boost-interprocess:x64-linux-dynamic: 52.9 ms
Installing 221/234 boost-gil:x64-linux-dynamic...
Elapsed time to handle boost-gil:x64-linux-dynamic: 45.5 ms
Installing 222/234 boost-qvm:x64-linux-dynamic...
Elapsed time to handle boost-qvm:x64-linux-dynamic: 34.6 ms
Installing 223/234 boost-polygon:x64-linux-dynamic...
Elapsed time to handle boost-polygon:x64-linux-dynamic: 31.7 ms
Installing 224/234 boost-dynamic-bitset:x64-linux-dynamic...
Elapsed time to handle boost-dynamic-bitset:x64-linux-dynamic: 19 ms
Installing 225/234 boost-random:x64-linux-dynamic...
Elapsed time to handle boost-random:x64-linux-dynamic: 29.8 ms
Installing 226/234 boost-math:x64-linux-dynamic...
Elapsed time to handle boost-math:x64-linux-dynamic: 155 ms
Installing 227/234 boost-multiprecision:x64-linux-dynamic...
Elapsed time to handle boost-multiprecision:x64-linux-dynamic: 29.8 ms
Installing 228/234 boost-geometry:x64-linux-dynamic...
Elapsed time to handle boost-geometry:x64-linux-dynamic: 208 ms
Installing 229/234 boost-filesystem:x64-linux-dynamic...
Elapsed time to handle boost-filesystem:x64-linux-dynamic: 33.9 ms
Installing 230/234 boost-lambda:x64-linux-dynamic...
Elapsed time to handle boost-lambda:x64-linux-dynamic: 26 ms
Installing 231/234 boost-bimap:x64-linux-dynamic...
Elapsed time to handle boost-bimap:x64-linux-dynamic: 30.8 ms
Installing 232/234 boost-ptr-container:x64-linux-dynamic...
Elapsed time to handle boost-ptr-container:x64-linux-dynamic: 24.5 ms
Installing 233/234 boost-assign:x64-linux-dynamic...
Elapsed time to handle boost-assign:x64-linux-dynamic: 19.8 ms
Installing 234/234 mapnik:x64-linux-dynamic...
Building mapnik[core,grid-renderer,input-geojson,input-shape,jpeg,libxml2,png,proj,svg-renderer,tiff,utility-mapnik-index,utility-mapnik-render,utility-shapeindex,webp]:x64-linux-dynamic...
warning: -- Using community triplet x64-linux-dynamic. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: /home/kian/.local/vcpkg/triplets/community/x64-linux-dynamic.cmake
-- Using cached mapnik-mapnik-4e064b8b8e324c4df7f2ae21dd72ccb85e1d4140.tar.gz.
-- Cleaning sources at /home/kian/.local/vcpkg/buildtrees/mapnik/src/b85e1d4140-f08377e940.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/kian/.local/vcpkg/downloads/mapnik-mapnik-4e064b8b8e324c4df7f2ae21dd72ccb85e1d4140.tar.gz
-- Using source at /home/kian/.local/vcpkg/buildtrees/mapnik/src/b85e1d4140-f08377e940.clean
-- Found external ninja('1.11.1').
-- Configuring x64-linux-dynamic
-- Building x64-linux-dynamic-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: /usr/bin/cmake --build . --config Debug --target install -- -v -j5
    Working Directory: /home/kian/.local/vcpkg/buildtrees/mapnik/x64-linux-dynamic-dbg
    See logs for more information:
      /home/kian/.local/vcpkg/buildtrees/mapnik/install-x64-linux-dynamic-dbg-out.log

Call Stack (most recent call first):
  /home/kian/projects/mapnik_test/cmake-build-release/vcpkg_installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
  /home/kian/projects/mapnik_test/cmake-build-release/vcpkg_installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
  ports/mapnik/portfile.cmake:70 (vcpkg_cmake_install)
  scripts/ports.cmake:147 (include)

error: building mapnik:x64-linux-dynamic failed with: BUILD_FAILED
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+mapnik
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?title=[mapnik]+Build+error&body=Copy+issue+body+from+%2Fhome%2Fkian%2Fprojects%2Fmapnik_test%2Fcmake-build-release%2Fvcpkg_installed%2Fvcpkg%2Fissue_body.md

-- Running vcpkg install - failed
CMake Error at /home/kian/.local/vcpkg/scripts/buildsystems/vcpkg.cmake:893 (message):
  vcpkg install failed.  See logs for more information:
  /home/kian/projects/mapnik_test/cmake-build-release/vcpkg-manifest-install.log
Call Stack (most recent call first):
  cmake-build-release/CMakeFiles/3.25.2/CMakeSystem.cmake:6 (include)
  CMakeLists.txt:2 (project)

-- Configuring incomplete, errors occurred!
See also "/home/kian/projects/mapnik_test/cmake-build-release/CMakeFiles/CMakeOutput.log".

[Failed to reload]

install-x64-linux-dynamic-dbg-out.log
Additional context
No response

I guess that's the popular issue with gcc 13 now strictly requiring #include <cstdint>. Should be solved by a port update which includes
https://github.com/mapnik/mapnik/pull/4378

thanks comrade @dg0yt.
after updating port i got another error of same issue in mapnik so i created #4389 for mapnik.
now i want to create a PR updating mapnik's port but it will get failed build in gcc13, what should i do update the port regularly or add a patch for above changes or whait for PR to approve and then update port?

I don't know if an update needs more work. Adding trivial patches for extra includes is okay IMO, but YMMV when it comes to official reviewers.
CC @mathisloge

thanks comrade @dg0yt. after updating port i got another error of same issue in mapnik so i created #4389 for mapnik. now i want to create a PR updating mapnik's port but it will get failed build in gcc13, what should i do update the port regularly or add a patch for above changes or wait for PR to approve and then update port?

I will make a patch so that you can directly use mapnik in vcpkg, and when the latest version of mapnik contains the patch code, I will update the latest version and remove the patch.

There is no need for a patch, my pr in mapnik that I mentioned in above have been merged in master branch, now it just need a port update.

There is no need for a patch. My pr in mapnik that I mentioned above have been merged in master branch. Now, it just needs a port update.

Ok, if you don't want to use it now, then I can wait for the upstream to release a new version and update the version to fix this issue.

Mapnik Port has a date version. So you can update the port every time.

Mapnik Port has a date version. So you can update the port every time.

OK, thank you, I'll create a PR ASAP and close this issue.


packaging test in CI hangs more than 20 minutes in docker build

The packages in CI are build using a dockerfile the dockerfile takes more than 20 minutes in a single installation step. We need to find out the rootcause why is takaing a long time and re-enable tests.

I tried locally and it is working. The problem seems that only happen in the CI VMs.
It is when the Dockerfile to install osc tries to pull metadata from suse servers.
It even hangs running:
RUN zypper -v -n ref
Here the output:
Step 5/15 : RUN zypper -v -n ref
 ---> Running in 6eb08e539120
Verbosity: 1
Entering non-interactive mode.
Initializing Target
Specified repositories:
Checking whether to refresh metadata for NON OSS
Retrieving repository 'NON OSS' metadata [.Retrieving: media [not found]
Retrieving: repomd.xml.asc [..done]

Hmm. My gut instinct shouts 'proxy' something, but I wonder if this might be to do with the http/https re-direction - that was on SuSe was it @jodh-intel ?


Implement asset serialisation in the new format

This PR contains the following:

Reverted the previous commit where the assets key and source and resolved are introduced.
Serialisation of asset in AST in the new format.
Introduced Element::Role for the new format.

This PR does not contain the following:

Change the Payload structure and PayloadParser to be up to date with the latest spec.
Serialisation of asset source maps.

For @zdne to review and merge.

Please move the Role from Element to Asset – it is specific to the asset element and should not have any semantic amongst the element attributes. Other than that it is good to merge.

Can you address this? Thanks.

Can you address this? Thanks.

@pksunkara done, I think we should really move to Asset to make it less general (at least for now).

Updated.


SuiteSparse: enable vc-14-2015-win64

I have a Problem with my Windows and linux tests
https://github.com/NeroBurner/hunter/commits/test.suitesparse
I based the branch test.suitesparse on pkg.suitesparse. Then I merged pkg.template (and fixed some merge conflicts). As last step I added the toolchain vc-14-2015-win64
on Appveyor the filenames are too long https://ci.appveyor.com/project/NeroBurner/hunter/build/1.0.3/job/3k13cifuvsqj8hhh#L5785
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(312,5): error MSB3491: Could not write lines to file "suitesparseconfig.dir\Release\suitespa.0C0D54C4.tlog\suitesparseconfig.lastbuildstate". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. [C:\projects\hunter\_testing\Hunter\_Base\984c9fc\13789f3\3bc7309\Build\SuiteSparse\Build\SuiteSparse-Release-prefix\src\SuiteSparse-Release-build\SuiteSparse\SuiteSparse_config\suitesparseconfig.vcxproj] [C:\projects\hunter\_testing\Hunter\_Base\984c9fc\13789f3\3bc7309\Build\SuiteSparse\Build\SuiteSparse-Release.vcxproj]

On linux the builds fail because pip3 is not found
https://travis-ci.org/NeroBurner/hunter/jobs/278090299#L419
Have I made a mistake while merging? Or do I need to do some special configuration on appveyor and travis-ci websites?

Then I merged pkg.template

Currently there is no such step in documentation, I'm doing it myself. Need to think what to do if pkg.<name> is not up-to-date.

on Appveyor the filenames are too long

You can try HUNTER_BINARY_DIR but this feature is not well designed:

https://github.com/ruslo/hunter/wiki/error.external.build.failed

On linux the builds fail because pip3 is not found

I guess it's an old .travis.yml, I've pushed updates to pkg.suitesparse.

Linux Builds are still failing with same error after rebase

https://github.com/NeroBurner/hunter/commits/test.suitesparse
https://travis-ci.org/NeroBurner/hunter/builds/278105056?utm_source=github_status&utm_medium=notification

I've pushed fix:

https://github.com/ingenue/hunter/commit/9c71c0bc3ec99bedf4757f6630109b39eb084c52

Should be good now:

https://travis-ci.org/ingenue/hunter/builds/278106205

yes, looks very good :+1:

https://ci.appveyor.com/project/NeroBurner/hunter/build/1.0.7
https://travis-ci.org/NeroBurner/hunter/builds/278112983?utm_source=github_status&utm_medium=notification


p7zip fails to cross-compile to mingw

Steps To Reproduce
Steps to reproduce the behavior:

nix-shell -p pkgsCross.mingwW64.p7zip

Build log
gist
Additional context
This can be useful to bundle cross-compiled executables into self-extracting archives, entirely within the Nix environment.
Notify maintainers

@7c6f434c @06kellyjac
Metadata

system: "x86_64-linux"
host os: Linux 5.19.10-arch1-1, Arch Atomic, noversion, rolling
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.10.3
channels(karim): "git-goodies, nixgl, nixos-22.05, nixpkgs, sops"
channels(root): "nixpkgs"
nixpkgs: /home/karim/.nix-defexpr/channels/nixpkgs

mingw isn't a marked as a supported target within nixpkgs so we wouldn't expect this to work & this is a request to support it.
As a note does https://github.com/jinfeihan57/p7zip actually support cross compiling to mingw? I'm not seeing many mentions there
The only mention I've found is a closed PR that says it adds "Can build mingw edition on Linux"
https://github.com/jinfeihan57/p7zip/pull/172
I'm thinking this requires upstream changes first

@Thesola10 Would 7zz work for you instead? It seems easier to get to cross-compile with mingw: #217472

@AtnNn can 7zz build self-extracting archive executables like 7z? If so then that's fine by me


Extend Transifex developer notes for label and name about locationSet.include countries

With this PR, it becomes easier for translators to skip local presets. It adds notes on local presets to the Transifex developer notes.
It is based on the field locationSet: ['de'] which exists for fields and presets. However, we only look at locationSet.includes for those notes. We skip locationSet.excludes because that would suggest that a translation is not needed, which can be wrong in cases, where the keys are reused / referenced in another preset. The translation is only done once but have multiple references with different locationSets.
Related

https://github.com/openstreetmap/id-tagging-schema/pull/331#discussion_r779251632
https://github.com/ideditor/schema-builder/issues/27

Closes https://github.com/ideditor/schema-builder/issues/27

FYI I created https://github.com/openstreetmap/id-tagging-schema/pull/825 as a follow up for this to explain how this new feature can be used.


Increase code coverage

Is your feature request related to a problem? Please describe.
Currently, codecov reports the following coverage percentage for ReactiveUI.Validation:

Describe the solution you'd like
Let's increase coverage to ensure further pull requests won't break existing API etc.
Probably ~40-50% will be fine enough, but higher coverage is better.
Describe suggestions on how to achieve the feature
Let's write more tests!

Totally agree!

Now we have more than 50% of lines covered, so closing this issue for now. Worth reopening if a regression occurs. In fact, the percentage of the covered lines is even higher, we just aren't testing the autogenerated stuff that isn't used anywhere now https://github.com/reactiveui/ReactiveUI.Validation/tree/main/src/ReactiveUI.Validation/TemplateGenerators and also the ResolveFor overloads that aren't used anywhere as well https://github.com/reactiveui/ReactiveUI.Validation/blob/main/src/ReactiveUI.Validation/Extensions/ValidationContextExtensions.cs (not sure what to do with that code)


Segmentation Fault after running migrations

Hello!
I'm using flyway to run migrations. After running it and start inserting into stream, the postgres client return successfuly (1 row(s) fetched - 17ms) but I'm getting the following error in  postgres.log :
2018-10-09 13:58:08.838 UTC [21634]: [9-1] user=,db=,app=,client= LOG:  worker process: worker0 [payment-aggregator] (PID 22805) exited with exit code 1
Segmentation fault (PID 22804)
version: PipelineDB 0.9.9 at revision 72e10a5fe9f7fe4cecb2610543c63d7a2616f7d3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
query: (null)
backtrace:
pipelinedb: bgworker: combiner0 [payment-aggregator]   (debug_segfault+0x15)[0x60ab15]
/lib64/libpthread.so.0(+0xf6d0)[0x7f1c42a5e6d0]
/lib64/libc.so.6(+0x16eff1)[0x7f1c41bc5ff1]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (hashname+0xd)[0x499edd]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (DirectFunctionCall1Coll+0x4a)[0x7b110a]
pipelinedb: bgworker: combiner0 [payment-aggregator]   [0x797350]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (SearchCatCache+0x66)[0x798316]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (GetSysCacheOid+0x6)[0x7a3f06]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (RelnameGetRelid+0x3b)[0x4f6a6b]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (RangeVarGetRelidExtended+0x269)[0x4f7b59]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (relation_openrv_extended+0x18)[0x49f898]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (heap_openrv_extended+0x9)[0x49fa39]
pipelinedb: bgworker: combiner0 [payment-aggregator]   [0x6572ab]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (ContExecutorStartNextQuery+0x196)[0x65a4b6]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (ContinuousQueryCombinerMain+0xdd)[0x657bcd]
pipelinedb: bgworker: combiner0 [payment-aggregator]   [0x654413]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (StartBackgroundWorker+0x17d)[0x660fbd]
pipelinedb: bgworker: combiner0 [payment-aggregator]   [0x66cd95]
pipelinedb: bgworker: combiner0 [payment-aggregator]   [0x473e6a]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (PostmasterMain+0xe92)[0x66ea42]
pipelinedb: bgworker: combiner0 [payment-aggregator]   (main+0x3e0)[0x474880]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f1c41a79445]
pipelinedb: bgworker: combiner0 [payment-aggregator]   [0x474907]

If I create a new stream, it works fine but the one I created via flyway  throw the above error and does not update the continuous views linked to it. Any thoughts?

I found out that the statement which was causing it was drop stream orders cascade;. It seems that using cascade to drop continuous view or streams cause this problem. Is this something expected?

The following script reproduce it:
create stream a_stream(x int);
begin;
create continuous view a_view as select x from a_stream;
drop continuous view a_view;
create continuous view a_view as select x from a_stream;
commit;

insert into a_stream values (10);

Postgres log:
Segmentation fault (PID 1254)
version: PipelineDB 0.9.9 at revision 72e10a5fe9f7fe4cecb2610543c63d7a2616f7d3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
query: (null)
backtrace:
pipelinedb: bgworker: worker0 [payment-aggregator]   (debug_segfault+0x15)[0x60ab15]
/lib64/libpthread.so.0(+0xf6d0)[0x7fe8b4ad46d0]
/lib64/libc.so.6(+0x16eff1)[0x7fe8b3c3bff1]
pipelinedb: bgworker: worker0 [payment-aggregator]   (CreateCombinerReceiver+0x4f)[0x64766f]
pipelinedb: bgworker: worker0 [payment-aggregator]   [0x6547e8]
pipelinedb: bgworker: worker0 [payment-aggregator]   (ContExecutorStartNextQuery+0x196)[0x65a4b6]
pipelinedb: bgworker: worker0 [payment-aggregator]   (ContinuousQueryWorkerMain+0x74)[0x654d64]
pipelinedb: bgworker: worker0 [payment-aggregator]   [0x654413]
pipelinedb: bgworker: worker0 [payment-aggregator]   (StartBackgroundWorker+0x17d)[0x660fbd]
pipelinedb: bgworker: worker0 [payment-aggregator]   [0x66cd95]
pipelinedb: bgworker: worker0 [payment-aggregator]   [0x473e6a]
pipelinedb: bgworker: worker0 [payment-aggregator]   (PostmasterMain+0xe92)[0x66ea42]
pipelinedb: bgworker: worker0 [payment-aggregator]   (main+0x3e0)[0x474880]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fe8b3aef445]
pipelinedb: bgworker: worker0 [payment-aggregator]   [0x474907]
2018-10-09 16:28:22.058 UTC [28491]: [26-1] user=,db=,app=,client= LOG:  worker process: worker0 [payment-aggregator] (PID 1254) exited with exit code 1

@samnegri thank you for the detailed writeup!  Is it a problem to drop continuous views or streams while receiving messages?

@samnegri no it shouldn't be a problem, that scenario is pretty well tested and handled. We're trying to figure out precisely how to reproduce this, as we haven't been able to from this alone:
create stream a_stream(x int);
begin;
create continuous view a_view as select x from a_stream;
drop continuous view a_view;
create continuous view a_view as select x from a_stream;
commit;

insert into a_stream values (10);

Is there anything else that may have been running besides the above statements?

Minimal repro case from @samnegri:
create user test;
create database testdb owner test;
\c testdb
set role test;  -- if I dont set role to test, everything works fine
create stream mystream(x int);
create continuous view mycv with (sw = '1 month') as select count(distinct x) from mystream; --if I remove the with (sw = '1 month'), and create a normal CV, it works fine
drop continuous view mycv;

Now that we can repro reliably we'll publish a release update asap that fixes the issue. Thank you @samnegri!

@samnegri this should has been fixed and a release update (0.9.9u3) will be published soon.

@derekjn thanks for the quickl follow up! I'll try this new version then I'll let you know the results.

Just for the record, the fix solved the Segmentation fault but there was still some logs reporting ERROR:  relation with OID 40506 does not exist. Like we've discussed I believe this is a permission issue, since it only happens when I delete a continuous view with a non super user.
Anyway, this does not seems to happen in version 1.0.0 since I can grant usage on pipelinedb foreign server to my user. Thank you for the support @derekjn


Fix [object object] display on theme setting input

This PR aims to Fix issue #22.

Thank you @jihdeh for the PR! This seems to fix the bug and the code looks good, so merging in.
Thank you!

@jihdeh Would you be interested to take this particular thing further? It would be awesome to render the theme values as a select box input field instead of a text field, so that the user can more easily change the theme. Let me know if this is something you'd be willing to tackle!

@haadcode Yes sure, I'd look into that.


No Latex support

The title is pretty descriptive.
When latex is inserted in the notebook, the app is unable to render it.

I have overviewed the project and this issue is probably related to the nbv.js script, which comes from this repo https://github.com/kokes/nbviewer.js/issues right?
I looked around and the template.html file seems to be rendered similarly as they do in this repo:
https://github.com/jsvine/notebookjs
In the repo they say that to render latex you need 3 links, and template.html is missing one of them:
OK -->   https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.12.0/katex.min.js.
OK -->   https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.12.0/katex.min.css
MISSING -->   https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.12.0/contrib/auto-render.min.js
Could that be the issue?
I tried to clone the repo to check if this solution would work, but I couldn't compile it because the file nbs.js was missing.

There is basic LaTeX support in version 0.1.4. The support was added in https://github.com/tuxu/ipynb-quicklook/pull/7 (issue #12 in this repo), which updated the nbviewer.js code.
Could you please provide an example notebook where LaTeX rendering does not work?

There is basic LaTeX support in version 0.1.4. The support was added in tuxu/ipynb-quicklook#7 (issue #12 in this repo), which updated the nbviewer.js code.
Could you please provide an example notebook where LaTeX rendering does not work?

Hey @tuxu,
Sure. I am taking a class in ML where the teacher put some LaTeX that doesn't render with the this app.
Here is a sample of the notebook with LaTeX code that doesn't render.
Here is a pdf of what the rendered version looks like.

Is the issue solved yet ? Because it is 2024 and it still can't render LaTeX.


Pefromance issues for satoru

https://github.com/keep-starknet-strange/satoru/issues
Test execution takes more time than it should. Verify if the reason is execution or compilation.

It might be because of high cost of repeated class hash calculation

We should consider caching the calculated class hash across the tests and see if it improves performance

Most of the time is spent collecting tests https://github.com/foundry-rs/starknet-foundry/blob/e8b0c545d2a75cdfff83bc2e0a010220b3257cb4/crates/forge/src/lib.rs#L77  in particular in the check method https://github.com/foundry-rs/starknet-foundry/blob/e8b0c545d2a75cdfff83bc2e0a010220b3257cb4/crates/test-collector/src/lib.rs#L325-L327
This https://github.com/foundry-rs/starknet-foundry/issues/647 should improve the situation

https://github.com/foundry-rs/starknet-foundry/issues/624#issuecomment-1715784724

I think if this task resulted in some issues for performance being created, it can be closed @abulenok


Add PlacementGroup subclass to IbmCic

Fix for https://github.com/ManageIQ/manageiq-providers-ibm_cic/actions/runs/3266871704/jobs/5371242276#step:7:105
Required after: https://github.com/ManageIQ/manageiq-providers-openstack/pull/806

@Fryguy just had to update the VCRs, please take another look


Docker image won't start

Trying to start Dockerfile. Get an error:
`node:internal/modules/cjs/loader:1078
throw err;
^
Error: Cannot find module './dist/server'
Require stack:

/home/node/index.js
at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
at Module._load (node:internal/modules/cjs/loader:920:27)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18)
at Object. (/home/node/index.js:17:18)
at Module._compile (node:internal/modules/cjs/loader:1254:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
at Module.load (node:internal/modules/cjs/loader:1117:32)
at Module._load (node:internal/modules/cjs/loader:958:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/home/node/index.js' ]
}

Node.js v18.15.0
node:internal/modules/cjs/loader:1078
throw err;
^
Error: Cannot find module './dist/server'
Require stack:

/home/node/index.js
at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
at Module._load (node:internal/modules/cjs/loader:920:27)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18)
at Object. (/home/node/index.js:17:18)
at Module._compile (node:internal/modules/cjs/loader:1254:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
at Module.load (node:internal/modules/cjs/loader:1117:32)
at Module._load (node:internal/modules/cjs/loader:958:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/home/node/index.js' ]
}

Node.js v18.15.0
`

With docker command: RUN nmp run tsc get an error:
#0 3.643 error TS2688: Cannot find type definition file for 'jest'.#0 3.643   The file is in the program because:
#0 3.643     Entry point of type library 'jest' specified in compilerOptions

To run q-server in docker do the following:

Compile source files

npm install
npm run tsc

Build docker image

docker build . -t qserver

Q-server requires ArangoDB to run on HTTP port 8901.
The easiest way to start ArangoDB is as written in the README:

$ everdev se start
$ everdev se set --db-port 8901

Wait a bit (sometimes it takes up to 2 minutes) and check if the ArangoDB web interface is available at http://localhost:8901.

Create and run a new container )(change <IP_ADDRESS> to your IP address)

docker run --rm -d \
    -p 4000:4000 \
    -e Q_REQUESTS_MODE=rest \
    -e Q_REQUESTS_SERVER=<IP_ADDRESS> \
    -e Q_DATA_MUT=http://<IP_ADDRESS>:8901 \
    -e Q_DATA_HOT=http://<IP_ADDRESS>:8901 \
  qserver

GraphQL playground must be available on http://localhost:4000/graphql

It works now.
You have to change documentation: typing npm install  is not enough to start q-server, because it won't create the dist directory. So we need both commands:

npm install
npm run tsc ( for regenerating the dist folder https://github.com/tonlabs/ton-q-server#for-developers)

Also docker template should be changed to something like this:
FROM node:18-buster
RUN mkdir -p /q-server
WORKDIR /q-server
ADD ton-q-server .
RUN npm install
RUN npm run tsc
EXPOSE 4000
ENTRYPOINT ["node", "index.js"]


Feature request: Specify range for query on a specific file

I'm working on a Neovim plugin where you can select results of a dry-run to apply to a project.
At the moment, if a user selects a result to be applied, it's only possible to run the apply command across the whole file which would update other results in the same file too.
My request is for us have an option to specify a range of lines/columns to apply onto.
As an example
# Specify a range of lines
grit apply "`const` => `let`" my-file.js --range 12-13

# Specify a range of lines and columns
grit apply "`const` => `let`" my-file.js --range 12:7-13:6

# Specify a specific point
# Only 1 match will be applied to the first match after the specified point
grit apply "`const` => `let`" my-file.js --range 12:7

This should be doable already with the --only-in-json parameter: https://github.com/getgrit/gritql/blob/05803744ea1d73986512412d913f1dc2a97e0a13/crates/cli/src/commands/apply.rs#L21

It follows the same format as eslint's output. On a shell, you don't really need a file since you can pipe a file handler directly.
Here's an example:
grit apply --dry-run fix.grit --only-in-json <( echo '[{"filePath":"file.js", "messages": [{ "line": 4, "column": 1, "endLine": 4, "endColumn": 50}]}]' )

I don't think people are likely to directly generate this (it's useful for automation), so I'm inclined to stick to JSON.

I'm dropping the file requirement, so you can just do this:
grit apply --dry-run fix.grit --only-in-json '[{"filePath":"file.js", "messages": [{ "line": 4, "column": 1, "endLine": 4, "endColumn": 50}]}]'

@morgante I was depending on just the lines of the compact output. But using jsonl has been fairly straightforward to use in the end, so happy for this issue to be closed.


rename C6100 platform name to Intel IPU Platform F2000X-PL

rename C6100 platform name to  in opae.cfg

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 65.535%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
13141

Relevant Lines:
20052

💛  - Coveralls


little refactor

Hi!
Does that change any behavior or fix something?
Does the async keyword breaks version compatibility?

The fix is this:
https://github.com/Alex-D/check-disk-space/blob/c160ab82677bcb81464f7d551252bf8f8823eb83/index.js#L67
Reject without return.
The async keyword is available from node 7.6, so if you care about compatibility, you can upgrade a major/minor version, so users will need to explicitly upgrade.


[MRG] Try to resolve an image name to determine registry health

A docker registry doesn't have an explicit health endpoint. The recommendation I could find in the docker registry repo was to use the root end point and if it returns a 200 or 401 the registry is healthy. However for the OVH registry we frequently have the problem that we think the registry is healthy but we can't resolve images.

Self merge to see this in action.


Upstream extensions

Describe why this should be added
Hi.
Why upstream close extensions repository with description - Extensions are no longer available out-of-the-box?
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I have updated the app to version 0.15.1.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

https://tachiyomi.org/news/2024-01-09-extensions-removal

Sorry but i little miss understand. What alternative to removed extensions? Setup local custom tachidesk/lanraragi/komga/kavita server and write (reimplement what lose tachiyomi) for them plugins for grabbing manga?

I don't know if I understand you, this is the alternative. You are literally in the repository. Everything is here.

Ahhh, legal troubles, classic  [https://www.reddit.com/r/Tachiyomi/comments/18zh6gg/comment/kgz15po/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button](reddit post)  :(


More main window cleanup, ignore qtconsole leaks

Description
Following on #2215, this PR tidies up the main_window and cleanup events a bit more.
I'm adding two more "allowed" leaks to the widget leaks test.  After spending quite a while trying to do this the "right way"... I've run into number of little upstream bugs in the implementation of the qtconsole widget.  We've got a lot of hacky little things in our code at the moment just to prevent a couple stray widgets from qtconsole.  By just ignoring those we can significantly clean up our close chain (could probably go even farther, but this is a start).
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

actually, I just found a bug introduced in #2215.  If you create a napari.viewer in an ipython %gui qt app, then using "File > Quit" in the napari application no longer does anything (doesn't close napari as it used to).  This is because of the event.ignore() that was added in #2215.  I've updated this PR to accept the closeEvent, and made sure that closing still works in all the "usual" contexts (i.e. napari on the CLI, napari starting the app from within a script or ipython, and running napari with an IPython %gui qt context).  @goanpeca, let me know if there is another reason that I need to be ignoring that event in MainWindow.closeEvent

actually, I just found a bug introduced in #2215. If you create a napari.viewer in an ipython %gui qt app, then using "File > Quit" in the napari application no longer does anything (doesn't close napari as it used to). This is because of the event.ignore() that was added in #2215. I've updated this PR to accept the closeEvent, and made sure that closing still works in all the "usual" contexts (i.e. napari on the CLI, napari starting the app from within a script or ipython, and running napari with an IPython %gui qt context). @goanpeca, let me know if there is another reason that I need to be ignoring that event in MainWindow.closeEvent

Yeah I was a bit scared of making those changes in the first place. Now I think it is ok to accept the event, and if that fixes it then we are good (I left that there when using the signals cauise it was triggering a double close). Thanks for cleaning after my mess :)

thanks!

Thanks for cleaning after my mess :)

that's generous.  we both know it wasn't your mess until I encouraged you to mess with it :)

that's generous. we both know it wasn't your mess until I encouraged you to mess with it :)

True story 🍷


color game

Color  Game
Enter the color of the text to win points
note
Enter the color of the words displayed below. And Keep in mind not to enter the word text itself and to move for next text press the enter button
summiting for hacktoberfest

@kishanrajput23 have a look


Stringcolumn aggregation

Should fix https://github.com/Caleydo/taggle/issues/311

Great Work Martin!

Thanks!


Any best practices regarding multi languages blog?

I'd like to have 2 versions of my website en and fr.
Creating a fr directory in _posts will work but how about the search functionality? is there a way to restrict it to a subset of the site (search restricted to all pages in a given langage).

Probably but you'll have to build that logic into the search. The way it's working now is a JSON file is created by looping over every post and then some Javascript reads that to build the results.
Maybe look into some of the other Jekyll search options (just Google around) and they might offer more ways to filter.
Another option would be to create two search pages (English & Francais) and two JSON files (en and fr). In the JSON files you'd simply modify the Liquid for loop to include only the appropriate posts. Not sure how you're flagging en and fr posts but if you did it in their YAML you could use something like:
{% assign english_posts = (site.posts | where: "language" , "en") %}
{% for post in english_posts %}
  {% if post.title != null and post.title != empty and post.search_omit != true %}
    {% if forloop.index > 1 %},{% endif %}{
      "title"			: {{ post.title | jsonify }},
      "link"			: "{{ site.url }}{{ post.url }}",
      "excerpt"		: "{{ post.excerpt }}"
    }
  {% endif %}
{% endfor %}

Also this is a very good blog post by Development Seed about how they handle multilingual sites in Jekyll. I personally haven't done this type of site with Jekyll yet so can't offer much assistance, but hopefully the post will lead you in the right direction.

thks the blog post is gold


Package upgrade: app_settings 4.1.0 --> 4.1.1

Summary
Package upgrade: app_settings 4.1.0 --> 4.1.1
Changelog
[General] [Change] - Upgrade app_settings from 4.1.0 to 4.1.1 (changelog)
Test Plan
Regression test the following areas:
./lib/ui/wayfinding/wayfinding_permissions.dart

Deferred


Permit Father-son check chain

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
New Notification, UI Feature
🔖 Feature description
Some time you monitor more than one service in the same server. But if the server is down, all services comes down too, and many notifications happens.
✔ Solution
So if I declare that Service A and Service B is on the Server Y, and the Server Y is Down, it only sends the notifications for The Server Y.
❓ Alternatives
No response
📝 Additional Context
No response

To further expand this.. rather than limiting it to just a server containing services.. if i'm monitoring my router (from a remote source) and it's down.. then i'd like to be able to not get notifications for everything else too..

Closing as duplicate of https://github.com/louislam/uptime-kuma/issues/1089


dotnet pack failed

To reproduce:
dotnet pack
Actual:
Microsoft (R) Build Engine version 17.0.0+c9eb9d
Copyright (C) Microsoft Corporation. All rights

  Determining projects to restore...
  All projects are up-to-date for restore.
  ExtLauncher -> /home/aloisdg/Source/extLauncheetcoreapp3.1/ExtLauncher.dll
  ExtLauncher -> /home/aloisdg/Source/extLauncheet6.0/ExtLauncher.dll
/usr/share/dotnet/sdk/6.0.102/Sdks/Microsoft.NETT.Publish.targets(102,5): error NETSDK1097: It ih an application to a single-file without specif You must either specify a RuntimeIdentifier or false. [/home/aloisdg/Source/extLauncher/ExtLauncher]

Expected:
no error :+1:

Needed for #8


[Playground] flexDirection is missing in the generated code for ReactNative

Report

[x] I have searched existing issues and this is not a duplicate

Issues and Steps to Reproduce

Go to https://goo.gl/2VvJQy
Get code > React Native

Expected Behavior
Elements that have Flex Direction: row must have flexDirection: 'row' in the generated code for react native.
Actual Behavior
flexDirection: 'row' is missing for all elements that have this property set (e.g. element 3)

Confirmed this is an issue. Generated code does not match Playground when used in real projects.

Duplicate of #807


fix(cli): event reporting

there's something very off with the events task, for some reason it's not woken up.
at least the interval should take care of waking up the task periodically, however, this does not happen.
only if manually woken up this works.
currently this new future is a busy loop which is not acceptable, but haven't found the root cause for this yet.
could be an issue with tokio because this happened suddenly
this seems to be related to the execution stage, but not sure how

Codecov Report

Merging #2273 (bcc6357) into main (1680630) will decrease coverage by 53.68%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main    #2273       +/-   ##
===========================================
- Coverage   72.05%   18.37%   -53.68%
===========================================
  Files         472      472
  Lines       56734    56754       +20
===========================================
- Hits        40878    10431    -30447
- Misses      15856    46323    +30467

Flag
Coverage Δ

integration-tests
18.37% <0.00%> (+<0.01%)
:arrow_up:

unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

bin/reth/src/node/events.rs
0.00% <0.00%> (ø)

bin/reth/src/node/mod.rs
0.00% <0.00%> (-11.90%)
:arrow_down:

... and 325 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Fetching multiple new assignments from tests generates a single assignment

Three separate assignment.yml files were added to a tests repository.
These had the deprecated assignmentid field. As a consequence, no assignments were generated by QuickFeed.
When a fix was pushed, only one of the three assignments was generated by QuickFeed.
DAT240/tests
|__ Lab1
|   |_ assignment.yml
|
|__ Lab2
|   |_ assignment.yml
|
|__ Lab3
|   |_ assignment.yml

Lab1 was added when the push event with the fix was received.
Lab 2 and 3 were added when I invoked UpdateAssignments two times, once for each assignment.
I expected all three to be added when the push event was received.
Additional information:
Logs from first commit to tests:
"added": [
      ...
      "Lab1/assignment.yml",
      ...
      "Lab2/assignment.yml",
      ...
      "Lab3/assignment.yml",
      ...
    ]

...

2023-08-20T21:04:11.202+0200    DEBUG   hooks/push.go:36        For course(1)=Advanced Programming
2023-08-20T21:04:11.202+0200    DEBUG   assignments/assignments.go:36   Updating DAT240 from 'tests' repository
2023-08-20T21:04:11.445+0200    DEBUG   scm/fetcher.go:50       Clone(https://github.com/dat240-2023/tests.git)
2023-08-20T21:04:11.915+0200    DEBUG   scm/fetcher.go:63       CloneDir = /home/quickfeed/courses/dat240-2023/tests
2023-08-20T21:04:11.915+0200    DEBUG   assignments/assignments.go:49   Successfully cloned tests repository to: /home/quickfeed/courses/dat240-2023/tests
2023-08-20T21:04:11.916+0200    DEBUG   assignments/assignments.go:74   Failed to update database for: CourseID:1  name:"Lab1"  deadline:{seconds:1694131140}  scoreLimit:90
2023-08-20T21:04:11.916+0200    DEBUG   assignments/assignments.go:74   Failed to update database for: CourseID:1  name:"Lab2"  deadline:{seconds:1695945540}  scoreLimit:100
2023-08-20T21:04:11.916+0200    DEBUG   assignments/assignments.go:74   Failed to update database for: CourseID:1  name:"Lab3"  deadline:{seconds:1697759940}  scoreLimit:100
2023-08-20T21:04:11.916+0200    ERROR   assignments/assignments.go:76   Failed to update assignments in database: record not found

Logs from when a fix was pushed & UpdateAssignments invoked:
    "modified": [
      "Lab1/assignment.yml",
      "Lab2/assignment.yml",
      "Lab3/assignment.yml"
    ]

2023-08-23T00:00:57.767+0200    DEBUG   hooks/push.go:36        For course(1)=Advanced Programming
2023-08-23T00:00:57.767+0200    DEBUG   assignments/assignments.go:36   Updating DAT240 from 'tests' repository
2023-08-23T00:00:58.007+0200    DEBUG   scm/fetcher.go:33       Pulling(https://github.com/dat240-2023/tests.git)
2023-08-23T00:00:58.492+0200    DEBUG   assignments/assignments.go:49   Successfully cloned tests repository to: /home/quickfeed/courses/dat240-2023/tests
2023-08-23T00:00:58.506+0200    DEBUG   assignments/assignments.go:79   Assignments for DAT240 successfully updated from 'tests' repo
2023-08-23T00:01:07.069+0200    DEBUG   web/quickfeed_service.go:354    GetSubmissions: &{CourseID:1  UserID:1 {0 /qf.QuickFeedService/GetSubmissions false} map[Accept:[*/*] Accept-Encoding:[gzip, deflate, br>
2023-08-23T00:01:07.071+0200    DEBUG   web/quickfeed_service.go:354    GetSubmissions: &{CourseID:2  UserID:1 {0 /qf.QuickFeedService/GetSubmissions false} map[Accept:[*/*] Accept-Encoding:[gzip, deflate, br>
2023-08-23T00:01:07.073+0200    DEBUG   web/access_control.go:26        (user=1, course=1) has enrollment status TEACHER
2023-08-23T00:01:07.074+0200    DEBUG   web/access_control.go:26        (user=1, course=2) has enrollment status TEACHER
2023-08-23T00:01:09.759+0200    DEBUG   web/quickfeed_service.go:373    GetSubmissionsByCourse: &{CourseID:1  Type:USER {0 /qf.QuickFeedService/GetSubmissionsByCourse false} map[Accept:[*/*] Accept-Encoding:[>
2023-08-23T00:01:09.788+0200    DEBUG   web/quickfeed_service.go:373    GetSubmissionsByCourse: &{CourseID:1  Type:GROUP {0 /qf.QuickFeedService/GetSubmissionsByCourse false} map[Accept:[*/*] Accept-Encoding:>
2023-08-23T00:09:20.948+0200    DEBUG   assignments/assignments.go:36   Updating DAT320 from 'tests' repository
2023-08-23T00:09:21.216+0200    DEBUG   scm/fetcher.go:33       Pulling(https://github.com/dat320-2023/tests.git)
2023-08-23T00:09:21.470+0200    DEBUG   assignments/assignments.go:49   Successfully cloned tests repository to: /home/quickfeed/courses/dat320-2023/tests
2023-08-23T00:09:21.482+0200    DEBUG   assignments/assignments.go:79   Assignments for DAT320 successfully updated from 'tests' repo
2023-08-23T00:09:21.643+0200    DEBUG   scm/fetcher.go:33       Pulling(https://github.com/dat320-2023/assignments.git)
2023-08-23T00:09:21.849+0200    DEBUG   web/quickfeed_service.go:533    Successfully cloned assignments repository to: /home/quickfeed/courses/dat320-2023/assignments
2023-08-23T00:09:51.874+0200    DEBUG   assignments/assignments.go:36   Updating DAT240 from 'tests' repository
2023-08-23T00:09:52.073+0200    DEBUG   scm/fetcher.go:33       Pulling(https://github.com/dat240-2023/tests.git)
2023-08-23T00:09:52.291+0200    DEBUG   assignments/assignments.go:49   Successfully cloned tests repository to: /home/quickfeed/courses/dat240-2023/tests
2023-08-23T00:09:52.301+0200    DEBUG   assignments/assignments.go:79   Assignments for DAT240 successfully updated from 'tests' repo

@JosteinLindhom To debug this, you will want to look in assignments/assignments_parser.go. Suggest to add the problematic assignment.yml example as a test case to figure out why it isn't providing parse error in the log, ref. Line 30:
err := yaml.Unmarshal(contents, &newAssignment)

(I think my recollection is that this function doesn't return an error for a yaml field (assignmentid) that is missing a corresponding field in the struct. Which is should according to the documentation.)

If my recollection mentioned above is correct, then this is really annoying. Would be great if you can confirm this. Moreover, if that is the case, then readTestsRepositoryContent will return partially initialized assignments ([]*qf.Assignment), which may be written to the database. We should prevent "partially" filled assignments from being written to the database.
Regarding the particular issue of having to invoke UpdateAssignments; the database code for this method has always been a bit problematic I think. I suggest to add some more test cases to try to trigger the particular scenario with "partial" assignments, and see if there is a problem with the implementation of said method. It looks like we have only a simple test TestUpdateAssignment for this in gormdb_assignment_test.go.

Jotting down my findings after taking a cursory look:
Seems like yaml.Unmarshal(...) returns an error if the field has the incorrect type, e.g. order: "hello".
yaml.UnmarshalStrict(...) will return an error if an included yaml field does not correspond to any struct fields.
However, we include fields such as title and effort for other tooling to generate README.md
As for the issue with UpdateAssignments, I've found these issues with db.UpdateAssignments:

If any one assignment does not have Order > 0, the entire transaction is rolled back.

This explains the issue where no assignments were added when assignmentid was used instead of order
return db.conn.Transaction(func(tx *gorm.DB) error {
	for _, v := range assignments {
		if err := check(tx, v); err != nil {
			return err // if any assignment fails the check, rollback and stops processing assignments
		}
		...
	}
}

If any one assignment does not already exist, that assignment is created and the function returns.

This explains why I had to invoke the method three times:
return db.conn.Transaction(func(tx *gorm.DB) error {
	for _, v := range assignments {
	        ...
		var assignment qf.Assignment
		if tx.Model(&qf.Assignment{}).FirstOrInit(&assignment,
			&qf.Assignment{
				CourseID: v.CourseID,
				Order:    v.Order,
			},
		).RowsAffected == 0 {
			// Zero rows affected indicates that the assignment does not exist
			return tx.Model(&qf.Assignment{}).Create(v).Error // commits or rolls back transaction. no further assignments processed
		}
		...
	}
}

PR #1002 makes the most trivial fix for a bad assignment.yml file, which is the main thing we want to fix here, so that we can more easily discover why and which assignment.yml file failed to parse correctly. We can also avoid multiple assignments in a single transaction, avoiding the other problem.
@JosteinLindhom Can you please add some tests for this stuff. Just commit to the same PR.
PS: Seems like something doesn't like that I used go 1.20 for GitHub workflows... (didn't have time to debug why...


Oracle api DEV deployment failing inconsistently

Success: https://github.com/bcgov/nr-spar/actions/runs/4931422697/jobs/8813438290
Fail: https://github.com/bcgov/nr-spar/actions/runs/4931720417/jobs/8814129572?pr=91

Closing as fixed!


Use the best match for better accuracy in examples

I was using the example codes and got a very low accuracy recognizing faces. Interestingly, many people in the photo are being recognized as the same person, who is also the first person in the known arrays.

Thanks!


Feature git

As requested, PR to merge directly on master.

Awesome, thanks again @equelin!

My pleasure @RamblingCookieMonster !


how to set 'nonempty' mount option

hi man,i am so appreciate you project,but when i use it,i get the following warn:
starting FUSE filesystem unreliablefs
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
could you tell me how to use ?

@JaneEyreliu Hi! If I get it right, you want to keep option -basedir=STRING empty, right?

Hi,that‘s not true.
here is the command line,and the output
[root@master build]# ./unreliablefs /usr/local/hadoop-3.3.1/dfs/name/current -basedir=/usr/local/hadoop-3.3.1/dfs/name -seed=1618680646
random seed =<PHONE_NUMBER>
read configuration /usr/local/hadoop-3.3.1/dfs/name/unreliablefs.conf
starting FUSE filesystem unreliablefs
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option

the question is how to keep the 'nonempty' mount option

sergeyb@pony:~/sources/unreliablefs$ mkdir base_dir
sergeyb@pony:~/sources/unreliablefs$ mkdir mount_dir
sergeyb@pony:~/sources/unreliablefs$ ./unreliablefs $(pwd)/mount_dir -basedir=$(pwd)/base_dir -seed=1618680646
random seed =<PHONE_NUMBER>
read configuration /home/sergeyb/sources/unreliablefs/base_dir/unreliablefs.conf
starting FUSE filesystem unreliablefs
sergeyb@pony:~/sources/unreliablefs$ ./unreliablefs --version
unreliablefs version 0.1
FUSE library version: 2.9.9
fusermount version: 2.9.9
using FUSE kernel interface version 7.19
$

Please, share unreliablefs version and OS version.
It is worth to run unreliablefs under strace (let me know if you need assistance).


PeekMessageA documentation for PM_NOYIELD incomplete

Describe the bug
The only feedback link on the page I could see was a "site feedback" link that led me here.  If that is not correct, please advise.
The documentation for PeekMessageA (and PeekMessageW) documents the PM_NOYIELD value as follows:

Prevents the system from releasing any thread that is waiting for the caller to go idle (see WaitForInputIdle).
Combine this value with either PM_NOREMOVE or PM_REMOVE.

However, inspection and experimentation shows it has other effects (it affects dispatching of messages from GetMessage/PeekMessage).  Please expand the definition to include the other effects.
To Reproduce
Steps to reproduce the behavior:

Go to https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-peekmessagea or https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-peekmessagew
Scroll down to 'PM_NOYIELD'
See described problem

Expected behavior
Documentation should document full effects of PM_NOYIELD.

@binarycrusader Its probably best to talk over the problem in a developer forum. No win32 developers watch this list of issues unfortunately.
https://social.msdn.microsoft.com/Forums/en-US/home?forum=vcgeneral


guilt: init at 0.37-rc1

Description of changes
guilt lets you manage patches like quilt, on top of a git repository.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)

Yes

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@ofborg build guilt

@matthiasbeyer I think I have addressed all the comments. Can you have another look?

@matthiasbeyer What else do I have to do to get this merged?