Custom libvips, NixOS, require('sharp') taking between 5 and 20 seconds

Possible install-time or require-time problem

[x] I have read the documentation relating to installation.
[x] I have ensured that the architecture and platform of Node.js used for npm install is the same as the architecture and platform of Node.js used at runtime.

Are you using the latest version of sharp?
No, but the issue is unrelated to that.

[ ] I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

I am using 0.30.2.
<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>└─<EMAIL_ADDRESS>
Is this a problem with filesystem permissions?
If you are using npm v6 or earlier and installing as a root or sudo user, have you tried with the npm install --unsafe-perm flag?
If you are using npm v7 or later, does the user running npm install own the directory it is run in?
If you are using the ignore-scripts feature of npm, have you tried with the npm install --ignore-scripts=false flag?
 Thank you in advance!

Is the installation environment running sharp v0.30.2 where the problem occurs using the standard prebuilt binaries (as the log provided for v0.30.7 might suggest) or is it possible you might be using a custom and/or globally-installed libvips?
What is the output of running ldd node_modules/sharp/build/Release/sharp-linux-x64.node in the affected environment?

The output of the request command is the following
$ ldd node_modules/sharp/build/Release/sharp-linux-x64.node
        linux-vdso.so.1 (0x00007ffe5232e000)
        libvips-cpp.so.42 => not found
        libvips.so.42 => not found
        libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fdc2db8a000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fdc2da61000)
        libstdc++.so.6 => /nix/store/x17b1wq871r4ycrxyy1n85ja09dxq3ih-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x00007fdc2d88c000)
        libm.so.6 => /nix/store/saw6nkqqqfx5xm1h5cpk7gxnxmw9wk47-glibc-2.33-62/lib/libm.so.6 (0x00007fdc2d749000)
        libgcc_s.so.1 => /nix/store/saw6nkqqqfx5xm1h5cpk7gxnxmw9wk47-glibc-2.33-62/lib/libgcc_s.so.1 (0x00007fdc2d72f000)
        libpthread.so.0 => /nix/store/saw6nkqqqfx5xm1h5cpk7gxnxmw9wk47-glibc-2.33-62/lib/libpthread.so.0 (0x00007fdc2d70f000)
        libc.so.6 => /nix/store/saw6nkqqqfx5xm1h5cpk7gxnxmw9wk47-glibc-2.33-62/lib/libc.so.6 (0x00007fdc2d54a000)
        libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007fdc2d53e000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fdc2d4cb000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdc2dc31000)

This is not quite correct @kiloreux, the outout of a similar machine like where the issue arises, is the following
ldd node_modules/sharp/build/Release/sharp-linux-x64.node
	linux-vdso.so.1 (0x00007ffaa5e65000)
	libvips-cpp.so.42 => /nix/store/zfyfmxs99ji4mimyda95b0zdbkmi81mm-vips-8.12.2/lib/libvips-cpp.so.42 (0x00007ffaa5ddb000)
	libvips.so.42 => /nix/store/zfyfmxs99ji4mimyda95b0zdbkmi81mm-vips-8.12.2/lib/libvips.so.42 (0x00007ffaa595b000)
	libgobject-2.0.so.0 => /nix/store/sxzai36pf2sk7dxwpk9hn1gqn94k4646-glib-2.70.2/lib/libgobject-2.0.so.0 (0x00007ffaa5900000)
	libglib-2.0.so.0 => /nix/store/sxzai36pf2sk7dxwpk9hn1gqn94k4646-glib-2.70.2/lib/libglib-2.0.so.0 (0x00007ffaa57c8000)
	libstdc++.so.6 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x00007ffaa55f1000)
	libm.so.6 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/libm.so.6 (0x00007ffaa54b0000)
	libgcc_s.so.1 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/libgcc_s.so.1 (0x00007ffaa5496000)
	libpthread.so.0 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/libpthread.so.0 (0x00007ffaa5476000)
	libc.so.6 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/libc.so.6 (0x00007ffaa52a0000)
	libexpat.so.1 => /nix/store/hwzah8ba3p9pwwv9zwdy5ysw8m7sljjw-expat-2.4.4/lib/libexpat.so.1 (0x00007ffaa526b000)
	libgsf-1.so.114 => /nix/store/vblhyfjfnq8shyi2m218lxvh238l5qa5-libgsf-1.14.48/lib/libgsf-1.so.114 (0x00007ffaa5221000)
	libxml2.so.2 => /nix/store/6apvrxx2qlxjsjg9cc07f2vnx3jg2cvq-libxml2-2.9.12/lib/libxml2.so.2 (0x00007ffaa50b3000)
	libfftw3.so.3 => /nix/store/069nq21mah3gshjyq34wc19siq00va75-fftw-double-3.3.10/lib/libfftw3.so.3 (0x00007ffaa4f0b000)
	liborc-0.4.so.0 => /nix/store/fkarwfgryqpjdkm4jlpscp1kgzbryyf2-orc-0.4.32/lib/liborc-0.4.so.0 (0x00007ffaa4e85000)
	liblcms2.so.2 => /nix/store/0sz652awsb7p1idpl53yvxmr60d17g1m-lcms2-2.12/lib/liblcms2.so.2 (0x00007ffaa4e21000)
	libIlmImf-2_5.so.25 => /nix/store/c1qr8a039il9krvvnn0vac7zgmvfynw3-openexr-2.5.7/lib/libIlmImf-2_5.so.25 (0x00007ffaa4b21000)
	libImath-2_5.so.25 => /nix/store/c1qr8a039il9krvvnn0vac7zgmvfynw3-openexr-2.5.7/lib/libImath-2_5.so.25 (0x00007ffaa4b06000)
	libHalf-2_5.so.25 => /nix/store/c1qr8a039il9krvvnn0vac7zgmvfynw3-openexr-2.5.7/lib/libHalf-2_5.so.25 (0x00007ffaa4ac1000)
	libIex-2_5.so.25 => /nix/store/c1qr8a039il9krvvnn0vac7zgmvfynw3-openexr-2.5.7/lib/libIex-2_5.so.25 (0x00007ffaa4a4c000)
	libIexMath-2_5.so.25 => /nix/store/c1qr8a039il9krvvnn0vac7zgmvfynw3-openexr-2.5.7/lib/libIexMath-2_5.so.25 (0x00007ffaa4a46000)
	libIlmThread-2_5.so.25 => /nix/store/c1qr8a039il9krvvnn0vac7zgmvfynw3-openexr-2.5.7/lib/libIlmThread-2_5.so.25 (0x00007ffaa4a3c000)
	libopenjp2.so.7 => /nix/store/kd73wm0xkfpkbnh31kbjcp4s642f26b1-openjpeg-2.4.0/lib/libopenjp2.so.7 (0x00007ffaa49db000)
	librsvg-2.so.2 => /nix/store/0ccn204v5kds9i08x7plf4x644l6wm87-librsvg-2.52.5/lib/librsvg-2.so.2 (0x00007ffaa3f2d000)
	libgdk_pixbuf-2.0.so.0 => /nix/store/2g610c5xqvikdixylipz01cymp1yb7j4-gdk-pixbuf-2.42.6/lib/libgdk_pixbuf-2.0.so.0 (0x00007ffaa3eff000)
	libmatio.so.11 => /nix/store/7b8vsrk7y80kvp7w81sl7hxxspjyf2dl-matio-1.5.21/lib/libmatio.so.11 (0x00007ffaa3ecf000)
	libcfitsio.so.9 => /nix/store/jn4cqrsa5wfrr67309bgddpmzajkssf4-cfitsio-4.0.0/lib/libcfitsio.so.9 (0x00007ffaa3bbe000)
	libwebpmux.so.3 => /nix/store/lir8r718z4ksjkgi1lawgrgi79z2ap03-libwebp-1.2.1/lib/libwebpmux.so.3 (0x00007ffaa3bb2000)
	libwebpdemux.so.2 => /nix/store/lir8r718z4ksjkgi1lawgrgi79z2ap03-libwebp-1.2.1/lib/libwebpdemux.so.2 (0x00007ffaa3bac000)
	libwebp.so.7 => /nix/store/lir8r718z4ksjkgi1lawgrgi79z2ap03-libwebp-1.2.1/lib/libwebp.so.7 (0x00007ffaa3b3d000)
	libpangocairo-1.0.so.0 => /nix/store/s4agfw48asi7n81ajh12l6ghqr7fm9ph-pango-1.50.3/lib/libpangocairo-1.0.so.0 (0x00007ffaa3b2c000)
	libpango-1.0.so.0 => /nix/store/s4agfw48asi7n81ajh12l6ghqr7fm9ph-pango-1.50.3/lib/libpango-1.0.so.0 (0x00007ffaa3ac2000)
	libharfbuzz.so.0 => /nix/store/nw2gv9l8lzi4scbddbg1vfvivzcpvag3-harfbuzz-3.2.0/lib/libharfbuzz.so.0 (0x00007ffaa39ca000)
	libcairo.so.2 => /nix/store/ybd7ni8vcg02k1w34l77c3axph8zx6yw-cairo-1.16.0/lib/libcairo.so.2 (0x00007ffaa388d000)
	libfontconfig.so.1 => /nix/store/wyf7am3d1xpzx6nagqq1j4ha07vlgrw8-fontconfig-2.13.94-lib/lib/libfontconfig.so.1 (0x00007ffaa3841000)
	libfreetype.so.6 => /nix/store/451fhyz2g9rgk7bd7nxgxjkx015ms0ms-freetype-2.11.1/lib/libfreetype.so.6 (0x00007ffaa377a000)
	libbz2.so.1 => /nix/store/nsgg55q1kh1ala68pas78hzfxsb3bnjk-bzip2-<IP_ADDRESS>.2/lib/libbz2.so.1 (0x00007ffaa3765000)
	libtiff.so.5 => /nix/store/qm6bwqqrzgv2yr9yclg6kjs8cz69ggjp-libtiff-4.3.0/lib/libtiff.so.5 (0x00007ffaa36e2000)
	libpng16.so.16 => /nix/store/vdcdfx068hmwqdd6wvsk5a6djlgrqfw4-libpng-apng-1.6.37/lib/libpng16.so.16 (0x00007ffaa36a8000)
	libz.so.1 => /nix/store/bqjh8dc6m5plswxrmmn9x4cpxrrw94lv-zlib-1.2.11/lib/libz.so.1 (0x00007ffaa368b000)
	libimagequant.so.0 => /nix/store/rrnmbz63cm57yzbb8nbd00zarg15m22r-libimagequant-2.17.0/lib/libimagequant.so.0 (0x00007ffaa3676000)
	libjpeg.so.62 => /nix/store/a6i6c7hkfn5s9bbgc1x6j1cnd5dppzkv-libjpeg-turbo-2.1.2/lib/libjpeg.so.62 (0x00007ffaa35bf000)
	libexif.so.12 => /nix/store/kgqbbhsj7d2km1g8hyrwigadqnfhlj7a-libexif-0.6.24/lib/libexif.so.12 (0x00007ffaa356d000)
	libgmodule-2.0.so.0 => /nix/store/sxzai36pf2sk7dxwpk9hn1gqn94k4646-glib-2.70.2/lib/libgmodule-2.0.so.0 (0x00007ffaa3566000)
	libgio-2.0.so.0 => /nix/store/sxzai36pf2sk7dxwpk9hn1gqn94k4646-glib-2.70.2/lib/libgio-2.0.so.0 (0x00007ffaa338a000)
	libffi.so.8 => /nix/store/5kmd81rnn4i8a9pd0z6hcv5skyd9hxfd-libffi-3.4.2/lib/libffi.so.8 (0x00007ffaa337d000)
	libpcre.so.1 => /nix/store/5w407jwmhxdd24xxzisv5nzmqlmvbxwb-pcre-8.45/lib/libpcre.so.1 (0x00007ffaa3302000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ffaa5e67000)
	libdl.so.2 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/libdl.so.2 (0x00007ffaa32fd000)
	libcairo-gobject.so.2 => /nix/store/ybd7ni8vcg02k1w34l77c3axph8zx6yw-cairo-1.16.0/lib/libcairo-gobject.so.2 (0x00007ffaa32f1000)
	libpangoft2-1.0.so.0 => /nix/store/s4agfw48asi7n81ajh12l6ghqr7fm9ph-pango-1.50.3/lib/libpangoft2-1.0.so.0 (0x00007ffaa32d4000)
	libfribidi.so.0 => /nix/store/ryj406gx09z7qxfyc1ahxy9vbdr9v1hm-fribidi-1.0.11/lib/libfribidi.so.0 (0x00007ffaa32b4000)
	libthai.so.0 => /nix/store/z0b0jqgvszaklfjl3dzdyvnhp2nn4v94-libthai-0.1.29/lib/libthai.so.0 (0x00007ffaa32a8000)
	libgraphite2.so.3 => /nix/store/s9drzb0i5hcqx5xdx6h15rvsk8g2li3q-graphite2-1.3.14/lib/libgraphite2.so.3 (0x00007ffaa327e000)
	libpixman-1.so.0 => /nix/store/c901n9lvwila9q77zwnif901i4l3f8hc-pixman-0.38.4/lib/libpixman-1.so.0 (0x00007ffaa31d2000)
	libEGL.so.1 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libEGL.so.1 (0x00007ffaa31bc000)
	libxcb-shm.so.0 => /nix/store/n1h6395818hn30bi5dk31smjwvhwawax-libxcb-1.14/lib/libxcb-shm.so.0 (0x00007ffaa31b7000)
	libxcb.so.1 => /nix/store/n1h6395818hn30bi5dk31smjwvhwawax-libxcb-1.14/lib/libxcb.so.1 (0x00007ffaa318b000)
	libxcb-render.so.0 => /nix/store/n1h6395818hn30bi5dk31smjwvhwawax-libxcb-1.14/lib/libxcb-render.so.0 (0x00007ffaa3179000)
	libXrender.so.1 => /nix/store/cmnjdi9a0jnsxr1xn74c941j6kk8nldf-libXrender-0.9.10/lib/libXrender.so.1 (0x00007ffaa316c000)
	libX11.so.6 => /nix/store/6pdb0rz2w2hsfsy66kwrbz67jd424wv7-libX11-1.7.2/lib/libX11.so.6 (0x00007ffaa3027000)
	libXext.so.6 => /nix/store/a3yw11i2iskvr1zx2za4mwrj9sawq7hz-libXext-1.3.4/lib/libXext.so.6 (0x00007ffaa3012000)
	libGL.so.1 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGL.so.1 (0x00007ffaa2f84000)
	librt.so.1 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/librt.so.1 (0x00007ffaa2f79000)
	liblzma.so.5 => /nix/store/ar8h49vw49k9w0n86jgvwx9abn527hbw-xz-5.2.5/lib/liblzma.so.5 (0x00007ffaa2f4d000)
	libdeflate.so.0 => /nix/store/ggf5pzjzf742yb24wqykx46jbhcmmbsf-libdeflate-1.8/lib/libdeflate.so.0 (0x00007ffaa2f3e000)
	libmount.so.1 => /nix/store/kx41yd3yyr9bwrsk85fhhx6qhavfwql6-util-linux-2.37.3-lib/lib/libmount.so.1 (0x00007ffaa2ede000)
	libselinux.so.1 => /nix/store/gck1cbz9hfqgw558139vjzmyg9r7bkmx-libselinux-3.3/lib/libselinux.so.1 (0x00007ffaa2eaf000)
	libresolv.so.2 => /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/libresolv.so.2 (0x00007ffaa2e97000)
	libdatrie.so.1 => /nix/store/23jvypciz2yrfj9wd3hzhrqxyxp54mnd-libdatrie-2019-12-20-lib/lib/libdatrie.so.1 (0x00007ffaa2e8d000)
	libGLdispatch.so.0 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGLdispatch.so.0 (0x00007ffaa2dd4000)
	libXau.so.6 => /nix/store/x14h74lzrxk7j05pgqmba8yicb2bms6f-libXau-1.0.9/lib/libXau.so.6 (0x00007ffaa2dcd000)
	libXdmcp.so.6 => /nix/store/3ijd7iqmnwqvfyv4k8l5a8qw33agi1br-libXdmcp-1.1.3/lib/libXdmcp.so.6 (0x00007ffaa2dc5000)
	libGLX.so.0 => /nix/store/5lzlfgrc37wqj400b4qgpaa6kc9d2wr1-libglvnd-1.4.0/lib/libGLX.so.0 (0x00007ffaa2d90000)
	libblkid.so.1 => /nix/store/kx41yd3yyr9bwrsk85fhhx6qhavfwql6-util-linux-2.37.3-lib/lib/libblkid.so.1 (0x00007ffaa2d3a000)

Note, that there is a wrapped yarn script in place to allow us to reference libraries (libvips in this case) from pinned nix packages.
What it basically does, is setting environment variables for yarn to find the pinned native dependencies.
PREFIX_PATH = lib.makeBinPath (with pkgs; [
  pkg-config stdenv.cc nodejs nodejs.python nodePackages.node-gyp
]);

PREFIX_PKG_CONFIG_PATH = lib.makeSearchPathOutput "dev" "lib/pkgconfig" gypDependencies;

[...] makeWrapper "$out/libexec/yarn/bin/yarn.js" "$out/bin/.yarn-wrapped" \
    --prefix PATH : "${PREFIX_PATH}" \
    --prefix PKG_CONFIG_PATH : "${PREFIX_PKG_CONFIG_PATH}" \
    --set PKG_CONFIG pkg-config \
    --set YARN_NODE_LINKER node-modules \
    --set NPM_CONFIG_NODEDIR ${nodejs}

Thanks, it looks like you're using a custom libvips with many dependencies, all of which have been packaged via NixOS.
When you require('sharp') all of these shared libraries will be dlopened, so you'll need to work out which of them is causing the slowdown. You can set the LD_DEBUG=libs environment variable to help with this.

What a great advice, thank you very much. There are even several symbol lookup errors from several vips-modules, that cannot be good either.

Were you able to make any progress with this?

Beside the finding that the cgroup slice this is running in has total io.pressure stalls up to 15s, and that it is possible to speed up by inserting coins to EBS IOPS and throughput, not much unfortunately.

Hey @lovell
We still couldn't get this below 8 seconds, on a c6id.4xlarge Amazon machine, which seems really weird. It should have enough disk power for this to be much faster, even under io.pressure. We do get it down if we add more disk iops and throughput, but that would mean increasing costs a lot.
Though there is still one thing we haven't tried yet and it is compiling all sharp native bindings and node as static libraries/binaries and that is because

Is this possible with sharp?
Would it really speed up things?

Thank you @lovell , this is helpful. <3

@tim-kos Were you able to make any progress with this?

Closing due to inactivity but please feel free to reopen with more details if further help is required.

It's still taking 6-8s here to require sharp on a fresh instance, so still far from ideal I am afraid. :/ Not sure what else we can try, do you have any ideas?

Is this with all (or at least most) dependencies statically built? If so, what is the output of running:
LD_DEBUG=libs node -e "require('sharp')"

You might also be able to pipe the output through something like https://www.npmjs.com/package/gnomon to find out which line takes the longest to appear.


move string and size specific int/uint typedefs into cartographer namespace

move string and size specific int/uint typedefs into cartographer namespace as minimal change necessary to keep global namespace clean
Alternate, more complete pull request forthcoming.

Thanks!

Any desire for a pull request of other option of replacing string  with std::string all over the place, or is this sufficient?

@catskul Removing this using and moving to std::string everywhere is the cleanest approach. A PR would be very welcome.

will.


Ignore install_git_private_https_pat_and_username for now

Summary
Temporarily disabling install_git_private_https_pat_and_username since running this test can break your local Git authentication for other projects. I experienced this today and keep finding myself needing to ignore it locally.
See: https://github.com/astral-sh/uv/issues/1980.

Thanks!


github-subdomains command does not found

The file "github-subdomains" disappeared after this commands "go install" in github-subdomains directory.
Output of "go install" command:
go: downloading github.com/jpillora/go-tld v1.0.0
go: downloading github.com/logrusorgru/aurora v2.0.3+incompatible
go: downloading golang.org/x/net v0.0.0-20200707034311-ab3426394381
While executing command "github-subdomains -d example.com", the error shows that "github-subdomains command not found"

As said in the readme, install steps are:
go install github.com/gwen001/github-subdomains@latest

OR
git clone https://github.com/gwen001/github-subdomains
cd github-subdomains
go install

I cannot predict the result if you do both or different. Also make sure that the bin Go path is in your executable path.
Thank you.

this was the problem "Also make sure that the bin Go path is in your executable path". It worked. Thank you.


Set-up Hello Microverse Project Pull Request

This is the simple Html And Css linters concept

Hi Micronaut
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
Invalid Code Review Request
🔴 Please ensure that you include Linters checks
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.


Improve services API for hub nodes.

Background
Currently services are workers which are started as a part of the hub node supervision tree and exposed via static local routes.
Services may start new workers which will be started in the common worker supervisor.
Services are configured via application configuration (env. variables SERVICES_*)
Tasks

In order to make services discoverable we need an API to list services, their routes, configuration and potentially some additional metadata
In order to make services controllable we need an API to start/stop services and their dependent workers
In order to make services and their dependent workers isolated, we need to rework the supervision structure for the dependent workers so they may be stopped/restarted with the service (optionally) https://github.com/ockam-network/ockam/issues/2145

In order to reason about service API support and current functionality, services should be versioned #2623


Revert "Add toStringTag value on JSG resource types"

Reverts cloudflare/workerd#1607
Breaks downstream trace test

@mikea ... how was the internal repo test broken? Does the test assume a particular output when an object to stringified? e.g. [object Object] vs. [object Foo]? Depending on exactly how that test was broken this change might end up having to go behind a compat flag.

@mikea ... how was the internal repo test broken? Does the test assume a particular output when an object to stringified? e.g. [object Object] vs. [object Foo]? Depending on exactly how that test was broken this change might end up having to go behind a compat flag.

hard for me to say what's wrong: there's so much output in the test. All I know is that Can log JSON edge cases subtest fails with this commit and passes without.

@jasnell It looks like the test does assume a particular output when an object is stringified:
Expected: ["[object Object]"], actual: ["[object Headers]"]

It sounds like the test just needs to be updated, but it's important to merge those downstream updates at the same time as the workerd changes.


Lindalu msft patch 9

Docs Build status updates of commit b397994:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Language/Reference/User-Interface-Help/shell-function.md
:bulb:Suggestion
View
Details

api/Word.Selection.TypeText.md
:bulb:Suggestion
View
Details

Language/Reference/User-Interface-Help/shell-function.md

Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.
Line 50, Column 256: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/office/vba/access/concepts/windows-api/determine-when-a-shelled-process-ends' will be broken in isolated environments. Replace with a relative link.

api/Word.Selection.TypeText.md

Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Update Current Flag Images

The current flag images are slightly blurry. New sources should be found.

Could you please give a list of flags to update? Thanks!

Could you please give a list of flags to update? Thanks!

Hi. Sorry I never replied to this. I haven't made a list yet but all the images come from various sources and have various base resolutions that have been scaled accordingly. Although it isn't that necessary, I would like the images to be consistent. Perhaps a flag generator might work?
If you're still interested, I'll comb through the images and make a full list of the ones that should be re-sourced.
Thanks.


MSYS2 dependencies

Describe the pull request
Adds tool-msys metaport to update MSYS2 installation and rebuild the ports using vcpkg_acquire_msys when the latter is changed (it's a maintainer's responsibility to increment the metaport's version when making changes to vcpkg_acquire_msys).
Sets <vcpkg>/downloads directory as an MSYS2 package cache to reuse them after MSYS2 updates.
Additionally introduces PORT_VERSION variable providing access to the version string from port's CONTROL file to CMake scripts.

What does your PR fix?
Fixes #11873

Which triplets are supported/not supported? Have you updated the CI baseline?
Not applicable.

Does your PR follow the maintainer guide?
Yes.

Waiting on #11836 to conclude, as it introduces a dependency metaport for vcpkg_configure_make which itself is dependent on vcpkg_acquire_msys.

isn't it better here and in #11836 to just rework the update mechanism and use not just CONTROL version, but also hashes like in CI to verify if update is necessary?
In this way we can avoid this meta port thing, which might "explode" if applied to all tools and toolchains...

Well, of course it would be better if the update mechanism checked changes in dependency CMake scripts in addition to CONTROL file. To build the dependency list it would most likely need the portfile's abstract syntax tree which afaik is not publicly accessible, although it should be possible to leverage CMake's sources and cmListFile::ParseFile method directly. But that's a whole 'nother story.

This PR is no longer required since vcpkg now has a heuristic which detects script changes.

I think we don't need this PR now.
If you have any concern, please let me know.

AFAICT #12254 doesn't take into account transitive dependencies, such as portfile>vcpkg_configure_make>vcpkg_acquire_msys.


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ashanb sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Merging branch code-workflow to master


-d option is not considered when svg height and width are length in centimeters

Given a SVG file with height and width as real length in centimeters
    <svg height="26cm" version="1.2" viewBox="0 0 500.0 500.0" width="26cm">

Actual behavior
the -d DPI option is silently ignored
Expected behavior
Either

a warning is given stating "-d option ignored because SVG height and width are in centimeters"
the program stops with error message "-d conflicts with SVG height and width in centimeters"

You do not need the DPI in this case as 26cm is ~10in so the SVG has ~50DPI. This reflected in juicy-gcode --help:

I feel like a warning would be appropriate, but also luxurious :D

Actually, there might be a bug in the current implementation:
<svg width="10cm" height="10cm" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg">
  <rect x="1cm" y="1cm" width="10" height="20"/>
</svg>

Not sure in this case what should happen...

Looking at this example:
<svg width="10cm" height="10cm" viewBox="0 0 300 300" xmlns="http://www.w3.org/2000/svg">
  <rect x="1in" y="1in" width="10" height="20"/>
  <rect x="96" y="96" width="10" height="20"/>
</svg>

The two rectangles rendered to the same spot independently of what the viewBox is. Thus, some default DPI is used to do the inner conversion, event though, the document size is in cm. This is exactly how juicy-gcode works, so the DPI setting still required

I confirm that with this example, -d has an effect on the first rectangle.
Now coming back to the use case.
I was changing -d without any effect on the output. After a tedious debug session, I realized that the input SVG had something new: the real length.
What would be the luxurious message to save me precious time?
Maybe "Drawing area {X}cm x {Y}cm onto gcode max_x=100,max_y=100"
Thanks!

But as my previous example suggests, even if the width and height of the SVG is in cm, you might need the DPI to render it.
So I can't give a warning like "-d option ignored because SVG height and width are in centimeters", because it is not true (it might not being used but it is not ignored).
I also can't just dump debug messages to the standard output freely as I might break other people's application.
I could probably add like a debug or info flag...

ack, thanks!


Implement topo generation of more than 1 segment

Implement topology generation of more than 1 segment

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Device ID

When you add a device, the VSCode extensions asks for the device id. Where is this value found?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0cf9b53c-0438-f23c-fd2e-d57481d57e85
Version Independent ID: f01afd66-d093-ac44-2b20-df225530b39e
Content: IoT DevKit to cloud -- Connect IoT DevKit AZ3166 to Azure IoT Hub
Content Source: articles/iot-hub/iot-hub-arduino-iot-devkit-az3166-get-started.md
Service: iot-hub
GitHub Login: @rangv
Microsoft Alias: rangv

Thank you for your feedback @stofte . Can you be more specific on which step you are blocked? Thanks.

Since we have not heard back from you we will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

DPS Failed.
Am I doing something wrong or does the tutorial need an update?
This message is displayed on screen. After the upload complets.
This is the output from VSCODE with the error in it.
Wi-Fi Verizon Moto Z (2) 4597 connected.
Time from pool.ntp.org, now is (UTC): Thu Mar 21 18:08:54 2019
Info:    DPS Version: 1.2.12
Error: Time:Thu Mar 21 18:08:56 2019 File:C:\Users\douga\AppData\Local\Arduino15\packages\AZ3166\hardware\stm32f4\1.6.1\libraries\AzureIoT\src\DevkitDPSClient.cpp Func:DevkitDPSClientStart Line:222 DiceInit failed! Check UDS string provided or set on configuration mode

** MXChip - Microsoft IoT Developer Kit **

Configuration console:

help: Help document.
version: System version.
exit: Exit and reboot.
scan: Scan Wi-Fi AP.
set_wifissid: Set Wi-Fi SSID.
set_wifipwd: Set Wi-Fi password.
set_az_iothub: Set the connection string of Microsoft Azure IoT Hub.
set_dps_uds: Set DPS Unique Device Secret (DPS).
enable_secure: Enable secure channel between AZ3166 and secure chip.

[Done] Closed the serial port
[Starting] Opening the serial port - COM4
[Info] Opened the serial port - COM4

** MXChip - Microsoft IoT Developer Kit **

Configuration console:

help: Help document.
version: System version.
exit: Exit and reboot.
scan: Scan Wi-Fi AP.
set_wifissid: Set Wi-Fi SSID.
set_wifipwd: Set Wi-Fi password.
set_az_iothub: Set the connection string of Microsoft Azure IoT Hub.
set_dps_uds: Set DPS Unique Device Secret (DPS).
enable_secure: Enable secure channel between AZ3166 and secure chip.

[Done] Closed the serial port


Update MD file on new branch 2017-12-10_09-47-37

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


VSTS: SqlServer.FunctionalTests/net461 deadlock on Windows

This occurs on both the release/2.2 branch and master.
It appears something in the VSTS Windows environment causes EF Core tests to deadlock. This happens consistently in the "SqlServer.FunctionalTests/net461" test group
Recent failures:
master: https://dotnet.visualstudio.com/public/_build/results?buildId=9238&view=logs
release/2.2: https://dotnet.visualstudio.com/public/_build/results?buildId=9239&_a=summary&view=logs

@natemcmaster Can you send me a link to the general new-processes-causing-hang issue that we talked about yesterday. Going to hold off on investigating this specifically until that issue is resolved.

There were a category of bugs that appear related. @ryanbrandenburg opened https://dotnet.visualstudio.com/internal/_workitems/edit/56 regarding issues with selenium and backgrounding processes from bash, and the were able to suggest workarounds for the moment. I don't think those workarounds apply for this situation though. It would be really helpful to have a minimal repro to hand off to the VSTS team for more investigation. I haven't taken time to create a minimal repro yet.

I had a conversation with the VSTS guys. As far as we can tell, this is a symptom of tests which create orphan processes. Do you know if the tests launch any kind of long-running background processes?

@natemcmaster We talked about this briefly in triage and @bricelam thinks probably no, except...wait for it...localdb! From what I understand, localdb is kicked of automatically as a child process, and we don't control when it is killed. I would hope that they support localdb, otherwise that seems like a pretty big blocker.

Hmm. Are you able to see locally on your dev box if there is in fact an orphaned localdb process still running after SQL Server tests run? I'll try to grab some diagnostics from the VSTS builds to see if I can spot an orphaned process which may be causing the issue.

This might be the culprit.
https://dotnet.visualstudio.com/public/_build/results?buildId=10032&_a=summary&view=logs
2018-08-02T01:52:05.7929769Z ProcessID       : 788
2018-08-02T01:52:05.7930140Z ParentProcessID : 3916
2018-08-02T01:52:05.7930481Z Description     : sqlservr.exe
2018-08-02T01:52:05.7930742Z Username        : VssAdministrator
2018-08-02T01:52:05.7937245Z CommandLine     : "C:\Program Files\Microsoft SQL Server\130\LocalDB\Binn\\sqlservr.exe"   -c -SMSSQL13E.LOCALDB
2018-08-02T01:52:05.7938204Z                   -sLOCALDB#5EE6FC6E -d"C:\Users\VssAdministrator\AppData\Local\Microsoft\Microsoft SQL Server Local
2018-08-02T01:52:05.7938975Z                   DB\Instances\MSSQLLocalDB\master.mdf" -l"C:\Users\VssAdministrator\AppData\Local\Microsoft\Microsoft
2018-08-02T01:52:05.7939310Z                   SQL Server Local DB\Instances\MSSQLLocalDB\mastlog.ldf"
2018-08-02T01:52:05.7942459Z                   -e"C:\Users\VssAdministrator\AppData\Local\Microsoft\Microsoft SQL Server Local
2018-08-02T01:52:05.7942901Z                   DB\Instances\MSSQLLocalDB\error.log"
2018-08-02T01:52:05.7943054Z

I gathered this by running this setup on VSTS.
https://github.com/aspnet/EntityFrameworkCore/blob/78f04c509fb7d4eeee226d249c19777e1cc37ad4/.vsts-pipelines/builds/ci-public.yml#L7-L22

Can we pro-actively spin up LocalDB in the build script instead?
SqlLocalDB.exe start MSSQLLocalDB

Diagnostics already use such pattern for different reason (localdb was not available when tests ran)
https://github.com/aspnet/Diagnostics/pull/445
Something similar here too

Does the issue with localdb repro with small, non-KoreBuild test projects running in VSTS? Or is there something specific about the way aspnet uses LocalDB? If just using localdb in VSTS causes indefinite test hangs, I'm going to raise the urgency on this.

It might be caused by repeatedly creating and dropping databases and perhaps related to the No process is on the other side of the pipe error we occasionally get.

I tried switching the agent pool and tests pass on the new pool. The tests pass on agents from the "DotNetCore-Windows" pool, which are managed by DDIT. The tests deadlock on agents from the "Hosted VS2017" pool, which are VMs provided by VSTS. The deadlock happens with two different test runners - vstest.console.exe and xunit.console.exe - so I'm led to believe it's in our code or SQL Server, not the test runner. Just a hunch, but I'm guessing this is evidence of resource exhaustion such as thread pool starvation or port exhaustion. Both machines have 2 physical cores, both machines are VMs, but the DDIT machines have hyperthreading enabled. I dig more into machine differences if that helps. I haven't figured out how to gather a memory dump of the deadlocked processes from the hosted VMs, but that's the next step to figure out where the deadlock happens.
Or we could just switch agent pools and call it good.

Process dump of the test process in deadlock:
https://dotnet.visualstudio.com/_apis/resources/Containers/408197?itemPath=logs%2Fxunit.console.exe_180803_161508.dmp
If you want to repeat this, you can trigger new builds of the "namc/vsts-timeout" branch on this build definition. https://dotnet.visualstudio.com/public/public Team/_build?definitionId=51&_a=summary. The tests consistently hang after running for about 5 minutes. I set ProcDump to capture full process memory after 12 minutes.
Here's a suspicious call stack.

Note for triage: other issues that mention query deadlocks: #11848, #12337, #12382

@smitpatel will investigate, possibly just disabling some tests for now to unblock VSTS testing.

I have managed to achieve a single core VM to find out all deadlocking tests.

When we discussed this in triage on Friday, we said we could close this issue because we no longer had net461 runs on master. However I am no sure we can close as the original issue applies to 2.x runs as well, and it is unclear why it would be different on .NET Core. Clearing milestone so we can come to a conclusion on next triage.


How to Scale the model?

How to Scale the model?

Something like mesh.Transform(Scale(V(0.5, 0.5, 0.5)))


Kafka health check is unstable

Description of the bug
We have experienced multiple retries on our notification pods due to failed liveness probes.
The  health check is experienced to be quite unstable and should be stabilized before being re-introduced in the solution.
Steps To Reproduce

Enable kafka health check in program.cs
Monitor restart count and event log in aks cluster

Additional Information
No response

Closing. Intention is covered by #321


CUDA out of memory when Train llama-7b-hf single gpu

Hi, I am trying to train the model llama-7b-hf with single GPU. I tried to reduce some parameters but I don't know if they are better.
 Tried to allocate 774.00 MiB (GPU 0; 11.76 GiB total capacity; 10.58 GiB already allocated; 697.94 MiB free; 10.61 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: 1) local_rank: 0 (pid: 496499) of binary: /usr/bin/python3

I started to take an interest in AI recently, I am grateful in advance for the people who will help me.
Edit : If there is also a way to learn with only the cpu, I am also interested

Hi, did you manage to solve this issue? I'm having the same one with the same GPU card.


HDFS-17396. BootstrapStandby should download rollback image during RollingUpgrade

Description of PR
Due to HDFS-17178, BootstrapStandby can now succeed during a RollingUpgrade. This can lead to an edge case where the bootstrapped NameNode does not have the fsimage_rollback_N file locally so it does not recognize that it is in a RollingUpgrade. This means the bootstrapped NameNode will overwrite the VERSION file during a checkpoint because it does not know that the NameService is in a RollingUpgrade.
BootstrapStandby needs to download the fsimage_rollback_N file in addition to the normal fsimage_N file so that the bootstrapped node correctly recognizes the RollingUpgrade state of the NameService.
How was this patch tested?
Added unit tests to cover the scenario and verify the rollback image is downloaded.
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 34s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
buf
0m  1s

buf was not available.

+0 :ok:
buf
0m  1s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
34m  5s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
36m 33s

trunk passed

+1 :green_heart:
compile
5m 46s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
5m 43s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m 30s

trunk passed

+1 :green_heart:
mvnsite
2m 11s

trunk passed

+1 :green_heart:
javadoc
1m 48s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 10s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
1m 22s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf-warnings.html
hadoop-hdfs-project/hadoop-hdfs-rbf in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
36m 41s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
2m 39s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 50s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
mvninstall
0m 24s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
compile
1m 25s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
cc
1m 25s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
1m 25s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
1m 15s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
cc
1m 15s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
1m 15s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m 18s
/results-checkstyle-hadoop-hdfs-project.txt
hadoop-hdfs-project: The patch generated 2 new + 104 unchanged - 0 fixed = 106 total (was 104)

-1 :x:
mvnsite
0m 53s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
mvnsite
0m 26s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
javadoc
0m 56s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

+1 :green_heart:
javadoc
2m  0s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
0m 50s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
spotbugs
0m 25s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
shadedclient
17m 21s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 53s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
unit
0m 26s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

+1 :green_heart:
asflicense
0m 33s

The patch does not generate ASF License warnings.

161m 16s

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6583

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets cc buflint bufcompat

uname
Linux 2e76b14348f2 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 04a35a21c0727e4cd6e80fbd8f0956a3f284ea68

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/1/testReport/

Max. process+thread count
550 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
8m 16s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 31s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
19m 49s

trunk passed

+1 :green_heart:
compile
2m 54s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
2m 50s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 44s

trunk passed

+1 :green_heart:
mvnsite
1m  7s

trunk passed

+1 :green_heart:
javadoc
1m  5s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 24s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
0m 43s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf-warnings.html
hadoop-hdfs-project/hadoop-hdfs-rbf in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
19m 36s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 29s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
mvninstall
0m 15s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
compile
0m 42s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
cc
0m 42s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
0m 42s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 38s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
cc
0m 38s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
0m 38s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 37s
/results-checkstyle-hadoop-hdfs-project.txt
hadoop-hdfs-project: The patch generated 4 new + 104 unchanged - 0 fixed = 108 total (was 104)

-1 :x:
mvnsite
0m 28s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
mvnsite
0m 15s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
javadoc
0m 30s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

+1 :green_heart:
javadoc
1m 13s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
0m 27s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
spotbugs
0m 15s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
shadedclient
9m 11s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 28s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
unit
0m 17s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

+1 :green_heart:
asflicense
0m 21s

The patch does not generate ASF License warnings.

89m 49s

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6583

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets cc buflint bufcompat

uname
Linux 57cf78107b8e 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d7f6943491645ec44fdca6b7fe9de2f643b1d645

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/2/testReport/

Max. process+thread count
731 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 20s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 26s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m  3s

trunk passed

+1 :green_heart:
compile
2m 54s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
2m 48s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 44s

trunk passed

+1 :green_heart:
mvnsite
1m  8s

trunk passed

+1 :green_heart:
javadoc
1m  3s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 20s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
0m 42s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf-warnings.html
hadoop-hdfs-project/hadoop-hdfs-rbf in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
19m 51s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 19s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m 59s

the patch passed

+1 :green_heart:
compile
2m 50s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
cc
2m 50s

the patch passed

+1 :green_heart:
javac
2m 50s

the patch passed

+1 :green_heart:
compile
2m 45s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
cc
2m 45s

the patch passed

+1 :green_heart:
javac
2m 45s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 37s
/results-checkstyle-hadoop-hdfs-project.txt
hadoop-hdfs-project: The patch generated 4 new + 104 unchanged - 0 fixed = 108 total (was 104)

+1 :green_heart:
mvnsite
0m 57s

the patch passed

-1 :x:
javadoc
0m 32s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

+1 :green_heart:
javadoc
1m 16s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m 38s

the patch passed

+1 :green_heart:
shadedclient
19m 57s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
199m 34s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

-1 :x:
unit
0m 48s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

+1 :green_heart:
asflicense
0m 28s

The patch does not generate ASF License warnings.

304m  7s

Reason
Tests

Failed junit tests
hadoop.hdfs.tools.TestDFSAdmin

hadoop.hdfs.server.datanode.TestLargeBlockReport

hadoop.hdfs.protocol.TestBlockListAsLongs

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6583

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets cc buflint bufcompat

uname
Linux 48b1e7564125 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ed0d884f3b6d63cf35ce826511c3637ffac3d5f9

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/3/testReport/

Max. process+thread count
4646 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 24s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
buf
0m  1s

buf was not available.

+0 :ok:
buf
0m  1s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
0m 18s

Maven dependency ordering for branch

-1 :x:
mvninstall
0m 19s
/branch-mvninstall-root.txt
root in trunk failed.

-1 :x:
compile
0m 22s
/branch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in trunk failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 31s
/branch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in trunk failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-0 :warning:
checkstyle
3m 36s
/buildtool-branch-checkstyle-hadoop-hdfs-project.txt
The patch fails to run checkstyle in hadoop-hdfs-project

-1 :x:
mvnsite
0m 38s
/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in trunk failed.

-1 :x:
mvnsite
1m  3s
/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in trunk failed.

-1 :x:
javadoc
0m 34s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in trunk failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 18s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-rbf-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-rbf in trunk failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 33s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs in trunk failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javadoc
0m 17s
/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-rbf-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-rbf in trunk failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
spotbugs
0m 22s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in trunk failed.

-1 :x:
spotbugs
0m 54s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in trunk failed.

-1 :x:
shadedclient
9m 10s

branch has errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 20s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
mvninstall
0m 28s
/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
compile
0m 13s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
cc
0m 13s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
0m 13s
/patch-compile-hadoop-hdfs-project-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-project in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
0m 20s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
cc
0m 20s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

-1 :x:
javac
0m 20s
/patch-compile-hadoop-hdfs-project-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project in the patch failed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 55s
/results-checkstyle-hadoop-hdfs-project.txt
hadoop-hdfs-project: The patch generated 106 new + 0 unchanged - 0 fixed = 106 total (was 0)

-1 :x:
mvnsite
0m 20s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
mvnsite
0m 20s
/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

-1 :x:
javadoc
0m 20s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
0m 19s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-rbf-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs-rbf in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

-1 :x:
javadoc
1m  8s
/results-javadoc-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08.txt
hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_392-8u392-ga-1~20.04-b08 with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08 generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1 :x:
spotbugs
0m 20s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
spotbugs
0m 22s
/patch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

+1 :green_heart:
shadedclient
9m 29s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 20s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch failed.

-1 :x:
unit
0m 20s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-rbf.txt
hadoop-hdfs-rbf in the patch failed.

+0 :ok:
asflicense
0m 32s

ASF License check generated no output?

23m 53s

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6583

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets cc buflint bufcompat

uname
Linux adc90e998481 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2079744ad58257e7131e9c07a473774ee161f9da

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/4/testReport/

Max. process+thread count
88 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/4/console

versions
git=2.25.1 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 30s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
buf
0m  1s

buf was not available.

+0 :ok:
buf
0m  1s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 49s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
31m 34s

trunk passed

+1 :green_heart:
compile
5m 24s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
5m 13s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m 21s

trunk passed

+1 :green_heart:
mvnsite
2m  5s

trunk passed

+1 :green_heart:
javadoc
1m 42s

trunk passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
2m 12s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
1m 16s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf-warnings.html
hadoop-hdfs-project/hadoop-hdfs-rbf in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
32m 37s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 31s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 41s

the patch passed

+1 :green_heart:
compile
5m 13s

the patch passed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
cc
5m 13s

the patch passed

+1 :green_heart:
javac
5m 13s

the patch passed

+1 :green_heart:
compile
5m  9s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
cc
5m  9s

the patch passed

+1 :green_heart:
javac
5m  9s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
1m 12s
/results-checkstyle-hadoop-hdfs-project.txt
hadoop-hdfs-project: The patch generated 2 new + 105 unchanged - 0 fixed = 107 total (was 105)

+1 :green_heart:
mvnsite
1m 50s

the patch passed

-1 :x:
javadoc
0m 53s
/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.txt
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04.

+1 :green_heart:
javadoc
1m 59s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
4m 37s

the patch passed

+1 :green_heart:
shadedclient
33m  2s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
223m  5s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
unit
14m  2s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

401m 23s

Reason
Tests

Failed junit tests
hadoop.hdfs.protocol.TestBlockListAsLongs

hadoop.hdfs.server.datanode.TestLargeBlockReport

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6583

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets cc buflint bufcompat

uname
Linux 5692fb9a72a0 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2079744ad58257e7131e9c07a473774ee161f9da

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.21+9-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/5/testReport/

Max. process+thread count
3465 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 19s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+0 :ok:
buf
0m  0s

buf was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 59s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
20m 12s

trunk passed

+1 :green_heart:
compile
2m 53s

trunk passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
compile
2m 44s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 43s

trunk passed

+1 :green_heart:
mvnsite
1m  5s

trunk passed

+1 :green_heart:
javadoc
1m  3s

trunk passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
javadoc
1m 21s

trunk passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

-1 :x:
spotbugs
0m 42s
/branch-spotbugs-hadoop-hdfs-project_hadoop-hdfs-rbf-warnings.html
hadoop-hdfs-project/hadoop-hdfs-rbf in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
19m 23s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 21s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
0m 52s

the patch passed

+1 :green_heart:
compile
2m 48s

the patch passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
cc
2m 48s

the patch passed

+1 :green_heart:
javac
2m 48s

the patch passed

+1 :green_heart:
compile
2m 39s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
cc
2m 39s

the patch passed

+1 :green_heart:
javac
2m 39s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 34s

the patch passed

+1 :green_heart:
mvnsite
0m 56s

the patch passed

+1 :green_heart:
javadoc
0m 51s

the patch passed with JDK Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1

+1 :green_heart:
javadoc
1m 16s

the patch passed with JDK Private Build-1.8.0_392-8u392-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m 37s

the patch passed

+1 :green_heart:
shadedclient
19m 44s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
198m 45s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
unit
12m 36s

hadoop-hdfs-rbf in the patch passed.

+1 :green_heart:
asflicense
0m 30s

The patch does not generate ASF License warnings.

314m 41s

Reason
Tests

Failed junit tests
hadoop.hdfs.tools.TestDFSAdmin

hadoop.hdfs.server.datanode.TestLargeBlockReport

hadoop.hdfs.protocol.TestBlockListAsLongs

Subsystem
Report/Notes

Docker
ClientAPI=1.44 ServerAPI=1.44 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6583

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets cc buflint bufcompat

uname
Linux 3f94366f8e4c 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 3bcfed3fa4a42da4bac346702baed458bcb5b72c

Default Java
Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.22+7-post-Ubuntu-0ubuntu220.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_392-8u392-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/7/testReport/

Max. process+thread count
4532 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs hadoop-hdfs-project/hadoop-hdfs-rbf U: hadoop-hdfs-project

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6583/7/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


Format ExecutorError with the executor label rather than full repr

The full repr for an executor is usually very long and includes all
of the configuration information for that exception, so previously
a BadStateException looked like this, which is awkwardly large:
parsl.executors.errors.BadStateException: Executor HighThroughputExecutor(
    address=None,
    address_probe_timeout=None,
    cores_per_worker=1,
    cpu_affinity='none',
    heartbeat_period=30,
    heartbeat_threshold=120,
    interchange_port_range=(55000, 56000),
    label='htex_local',
    launch_cmd='executable_that_hopefully_does_not_exist_1030509.py',
    managed=True,
    max_workers=1,
    mem_per_worker=None,
    poll_period=1,
    prefetch_capacity=0,
    provider=LocalProvider(
        channel=LocalChannel(
            envs={},
            script_dir='/home/runner/work/parsl/parsl/runinfo/030/submit_scripts',
            userhome='/home/runner/work/parsl/parsl'
        ),
        cmd_timeout=30,
        init_blocks=1,
        launcher=SimpleLauncher(debug=True),
        max_blocks=1,
        min_blocks=0,
        move_files=None,
        nodes_per_block=1,
        parallelism=1,
        worker_init=''
    ),
    storage_access=None,
    worker_debug=True,
    worker_logdir_root=None,
    worker_port_range=(54000, 55000),
    worker_ports=None,
    working_dir=None
) failed due to:        STDERR: /home/runner/work/parsl/parsl/runinfo/030/submit_scripts/parsl.localprovider.1642801165.5067718.sh: line 3: executable_that_hopefully_does_not_exist_1030509.py: command not found

After this commit, the exception instead looks like this:
parsl.executors.errors.BadStateException: Executor htex_local failed due to:    STDERR: /home/benc/parsl/src/parsl/runinfo/000/submit_scripts/parsl.localprovider.1643124620.9775066.sh: line 3: executable_that_hopefully_does_not_exist_1030509.py: command not found

Type of change

Code maintentance/cleanup

merged as part of #2205 - closing without explicit merge


Nancy.Authentication.Token - How do we handle sliding/persistent access?

So i'm looking at using [Nancy.Authentication.Token] (https://github.com/NancyFx/Nancy/wiki/Token Authentication) to authenticate users of my Nancy REST API.
I have a SPA web app built in React, and an iOS app. Each app can have many users, and these are essentially the "clients" that I need to give access to, e.g

App
Client

SPA
Bob

SPA
Alice

iOS
Bob

So Bob can only update Bob's info, and not Alice's etc.
My question is, if Bob is on the SPA website, logs in via a web form, gets a token, etc - then Bob closes his browser - wouldn't he have to log the user in again (via the web form?) when he opens his browser again? (or when the token expires). Do i somehow have to persist the token into a cookie/local storage (and is that secure?). Do i have to do silent refresh operations behind the scenes?
Forms Auth handles this via a sliding/persistent cookie - so i'm wondering how i can achieve this using Nancy Token auth?

@jeffdoolittle care to chim in? @RPM1984 did you ever get anywhere with this?

@thecodejunkie nope, never got any further than the convo above. Will probably end up using IdentityServer3

@thecodejunkie Isn't token auth slated to be deprecated in favor of using a JSON Web Token implementation over OWIN? I'd concur with @RPM1984 and recommend going with IdentityServer.

I'm pretty sure JWT is the way forward.

Sounds like JWT is the way to go, so closing this for now.


Remove redundant helper methods on Enumerator

These don't really serve any good purpose—it's easy enough to use the enumeratees or iteratees directly.

Current coverage is 100.00%

Merging #38 into master will not affect coverage as of 3f686c2

@@            master     #38   diff @@
======================================
  Files           17      17
  Stmts          436     425    -11
  Branches        35      34     -1
  Methods          0       0
======================================
- Hit            436     425    -11
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of 3f686c2

Powered by Codecov. Updated on successful CI builds.


Planned upgrade to Lucene 8.9

Currently, we're using Lucene v8.3.0 (release 11/2/2019), which is about two years old. I'm thinking of upgrading to Lucene v8.9.0 (released 6/16/2021) and have a working branch. Regressions all pass.
This will help us better prepare for the Lucene 9.0 release.
Main point of concern: indexes are forward compatible but not backwards. That is, 8.9 can read 8.3 indexes, but not the other way around. So this means that moving forward, we are forcing all dependents (e.g., Pyserini) to upgrade.
Does anyone have comments?

yeah....v8.3.0 seems too old.
It's good to update to a newer version.

8.9 can read 8.3 indexes
I think it's good enough (as we are not breaking current indexes)

Closed by #1687


Add an optional flag to uploader to determine amount of memory allocated to JS by emscripten

Duplicate of #52


Binary Operations Calculator

Title:
Binary Operations Calculator
Description:
Calculates binary operations, like bitwise and, bitwise or, and also adds, subtracts, and multiplies.

Hi @RuanAragao @devxiexie I would like to work on this

Hey @kahenya-anita, I’m working on this issue already :)! If you have an idea for a calculator, you need to make your own issue, like the readme says.


Should study flairs take into account the setting to see user flairs?

I don't see the point. You can already control all of it from the LT preferences. And not even Lichess native took this into account.


Feature image use exif

depends on #547
This PR adds exif support to Image. It is a work in progress, but i wanted to open this PR to get some initial feedback on the approach.
In short, i've added an ImageOrientation property to ImageSource. Its value is set when the various image loaders receive image data.
The value of this ImageOrientation is then used to calculate a transformation matrix which is applied to the texture coordinates when drawing the image.
The imageloader stuff will get cleaned / removed since Kusma has already done some work there.
This PR contains:

[x] Changelog
[ ] Documentation
[x] Tests

@kristianhasselknippe: I'd prefer if we could do the Buffer vs byte[] as a preparatory step. But since cleaning that up is a bunch of work, I went ahead and did it for you. Do you mind if inject these patches into your series?

@kusma : About the other cases like ImageFill and effects that use images. Could those be handled by a separate PR? The changelog only claims that Image now respects Exif. What do you think?

@kristianhasselknippe: I think that would be OK, as long as we don't end up breaking anything. And I don't think we currently do!

Oh, wait. We might actually break something. Non-square ImageFills with non-identity Exif orientation will probably get squished by this, because they will report a Exif-corrected size, but does not take it into account while rendering...
I mean, it was already rendering incorrectly, so I'm not sure if having a "different incorrect rendering" is the worst thing imaginable...

The Size correction currently happens in Image.Visual, so it shouldn't affect anything related to ImageFill.

@kristianhasselknippe: Right. In the long term, I think it's better if ImageSource does this bit, because it's used by more parts of our system. But for now, I think that's fine.

not sure why router tests fail :S

@kristianhasselknippe: Probably a spurious failure, we should really file a bug and disable tests like that... But it'll get a new run now.

@kristianhasselknippe: Whups. Would you mind squashing that last one into 1098625f541197a660b3692aff35fc8a35d59519?


Stack is broken

stack is broken on all platforms
Normally I wouldn't mind. But it was also listed as a required job for darwin + ofBorg CI, and had to disable in https://github.com/NixOS/nixpkgs/pull/81334.
cc @peti

Keeping stack compiling successfully is such a nightmare that I have essentially given up on maintaining that build. Removing it from release.nix was the right choice IMHO.

I got stack building again in https://github.com/NixOS/nixpkgs/pull/81373 (although it was a pain).

This should be fixed in #81373.


Support the half socket close

Just a copy from:
https://issues.jboss.org/browse/NETTY-236
This feature request seems to be ignored for a long time.

Is that the same as #107 ?

Yes, same. Closing as a duplicate.  BTW It's not been ignored - it was scheduled to be part of v4 and v4 was not released yet.


Error Handling and Retry Mechanism for API Timeouts

While using pyPowerwall to poll data from the Tesla Powerwall Gateway, I encountered frequent timeouts, especially when polling the /api/meters/aggregates and /api/system_status/soe endpoints. The current implementation does not handle these timeouts effectively, leading to failed API calls and incomplete data retrieval.

This isn't the repo for that library.


disable button jump when tooltip

Purpose
Solve the button jump when using tooltip. See gif below:

Change
Add the body as container, then it will not be influenced by other.

Popovers in button groups and input groups require special setting
When using popovers on elements within a .btn-group or an .input-group, you'll have to specify the option container: 'body' (documented below) to avoid unwanted side effects (such as the element growing wider and/or losing its rounded corners when the popover is triggered).

More details see a github discussion -- link
After adding data-container="body" to the button with tooltip, see the gif below:

Side effects.
None. It only sets the container of the tooltip button. I already tested it in four major browsers. It works well.
Lesson
When using bootstrap group button with tooltip, remember to add data-container="body".

No issues at all, and easy to merge. :airplane:


Revert "OCPBUGS-11885: For debug only for bond XDP issue"

Reverts openshift/ingress-node-firewall#339 was added to get an ART image build for debug only

/jira refresh

/test ingress-node-firewall-e2e-metal-ipi


Documenting users and their requirements for website

Personas of possible audience who would visit the website :

IITB Employees/teams
IT employees from other departments
etv. etc.

https://docs.google.com/document/d/1l7PezFuxKlRGV4fXQMjFO_6EeVPZiLzddWq-MtmSPa8/edit?usp=sharing


Removing single split assertion

If there are multiple splits, are you sure we combine them before kfold?


 This fixes a problem initially reported in #1227 and widely examined in #1239 and reported again in #1294 and #1455 (all these should be closed upon acceptance of this PR). Can someone eg @mattiarighi test the quantilebias recipe with this pinning please :beer:
To my part, the bit that was previously failing now works a-OK:
(esmvaltool_cdo) valeriu@valeriu-PORTEGE-Z30-C:~/esmvaltool_workshop_21Jan2019$ cdo remapcon t2.nc out.nc
cdo    remapcon  : Enter grid description file or name > t2.nc
cdo    remapcon: YAC first order conservative weights from lonlat (144x96) to lonlat (144x96) grid
cdo    remapcon: Processed 1 variable over 1857 timesteps [10.99s 33MB].

(esmvaltool_cdo) valeriu@valeriu-PORTEGE-Z30-C:~/ESMValTool$ conda list cdo && conda list proj4 && conda list hdf5
# packages in environment at /home/valeriu/anaconda3R/envs/esmvaltool_cdo:
#
# Name                    Version                   Build  Channel
cdo                       <IP_ADDRESS>              h7d1db5e_2    conda-forge
# packages in environment at /home/valeriu/anaconda3R/envs/esmvaltool_cdo:
#
# Name                    Version                   Build  Channel
proj4                     6.1.1                hc80f0dc_1    conda-forge
# packages in environment at /home/valeriu/anaconda3R/envs/esmvaltool_cdo:
#
# Name                    Version                   Build  Channel
hdf5                      1.10.5          nompi_h3c11f04_1104    conda-forge

@valeriupredoi great, thanks for this! I am testing it but right now cannot complete the installation when running pip install .
Collecting esmvalcore<2.1,>=2.0.0b3 (from ESMValTool==2.0.0b1)   ERROR: Could not find a version that satisfies the requirement esmvalcore<2.1,>=2.0.0b3 (from ESMValTool==2.0.0b1) (from versions: none) ERROR: No matching distribution found for esmvalcore<2.1,>=2.0.0b3 (from ESMValTool==2.0.0b1)
Working on it.

@earnone since the dependency requirement has changed, you will have to recreate the environment via conda env create -n esmvaltool -f environment.yml - in any case you will have had to do that since your env looks to be old (both the core and the tool ones) :beer:

muchos gracias for testing @earnone :beer: I'll see why it says b1, think it's hardcoded in setup.py - @bouweandela would you want to have a look before merge? Good weekend guys :beer:

@earnone the actual noarch version is indeed 2.0.0b1 https://anaconda.org/ESMValGroup/esmvaltool/files


1 test failure for release 3.4.0 on Fedora 37 and 36.

Code Sample, a copy-pastable example if possible
Yesterdays 3.4.0 release builds and tests just fine in Fedora rawhide (future fedora 38).
However, the test suite produces one test failure when run with: py.test-3 -m "not network" for fedora 37 and 36.
I can suppress this test by using "not network and not grid", but if possible, I think it would be better to understand what is going on and to fix it if possible
The output for the failing test is:
__________________ test_transformer_group__get_transform_crs ___________________
    @pytest.mark.grid
    def test_transformer_group__get_transform_crs():
        tg = TransformerGroup("epsg:4258", "epsg:7415")
        if not grids_available("nl_nsgi_rdtrans2018.tif"):
>           assert len(tg.transformers) == 1
E           assert 2 == 1
E            +  where 2 = len([<Concatenated Operation Transformer: pipeline>\nDescription: Inverse of Transformation from NAP height to ETRS89 (ball...geographic offset from Amersfoort to ETRS89 + RD New\nArea of Use:\n- name: World\n- bounds: (-180.0, -90.0, 180.0, 90.0)])
E            +    where [<Concatenated Operation Transformer: pipeline>\nDescription: Inverse of Transformation from NAP height to ETRS89 (ball...geographic offset from Amersfoort to ETRS89 + RD New\nArea of Use:\n- name: World\n- bounds: (-180.0, -90.0, 180.0, 90.0)] = <TransformerGroup: best_available=False>\n- transformers: 2\n- unavailable_operations: 4.transformers
test/test_transformer.py:699: AssertionError

Version details for fedora 37 are:
pyproj release 3.4.0
proj version 9.0.1
python3 version 3.11.0~rc1
gcc version  12.2.1
python3-Cython version 0.29.32
Version details for fedora rawhide/38 are:
pyproj release 3.4.0
proj version 9.1.0
python3 version 3.11.0~rc1
gcc version  12.2.1
python3-Cython version  0.29.32
The only difference seems to be the version of the proj library.
For more details see:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2061414 (rawhide build)
https://koji.fedoraproject.org/koji/taskinfo?taskID=91901918 (fedora 37 build)

Possibly related: #1083

I am currently thinking the tests need to be updated to match #1139

@jdkloe, I don't think there is a bug with PROJ. Just a behavior change.


docs: update AudioCache explanation, migration guide, replace package READMEs

Description

update AudioCache explanation (closes #1256)
replace package README.md symlinks with files, and switched main README file to audioplayers package (#1433, https://github.com/dart-lang/pub/issues/2699)
update migration guide to use Changlog

Copying Symlink targets for release should not be necessary anymore.
Checklist

[x] The title of my PR starts with a [Conventional Commit] prefix (fix:, feat:, docs:, chore: etc).
[x] I have read the [Contributor Guide] and followed the process outlined for submitting PRs.
[ ] I have updated/added tests for ALL new/updated/fixed functionality.
[x] I have updated/added relevant documentation and added dartdoc comments with ///, where necessary.
[ ] I have updated/added relevant examples in [example].

Breaking Change

[ ] Yes, this is a breaking change.
[x] No, this is not a breaking change.

@luanpotter @spydon I also now updated some of the contributing stuff (regarding the lack docs for setting up Melos, which is quite important I think). I know that there could be updated much more, like in flame. But I also think every new passage needs to be maintained. So I'd rather keep it simple and leave out the redundant stuff.


Put management tasks outside of individual repos

Keep one standard Makefile for all repositories.
Maybe we can reuse tools by people who know how the magic of Makefile (hi, @osterman and @cloudposse team)?
See build-harness and this Makefile, as a good example.
Each terraform-aws-modules repo should contain a list of required targets to do all management tasks, for example:

[ ] Validate code
[ ] Run examples
[ ] Update changelog
[ ] Create release
[ ] Update README
[ ] etc...

PS: The ultimate goal is to keep as little as possible duplication in each Terraform module repositories.
Feedback from everyone, especially @barryib @bryantbiggs @max-rocket-internet is appreciated.

here's one example to start I just threw together https://gist.github.com/bryantbiggs/ab576e5718b4581083885e030b4b0765


Web based configuration wizard?

A significant portion of the workbox-cli codebase supports the "wizard" feature, which examines the local filesystem and asks a few questions, and then generates a configuration file based on those responses.
Before I start porting workbox-cli to v3, I wanted to get opinions on whether this wizard functionality should move over as-is, or whether we should explore other options for providing similar functionality.
One of the things that I had in mind in terms of alternatives is a hosted web app that would ask a similar series of questions, as well as asking whether the developer planned on using Webpack, the CLI, or the Node module directly. The last state of this web app could produce a similar configuration to what you previous got from the workbox-cli wizard, ready to be either copy-and-pasted or downloaded.
The advantages are that it could serve as a nice onboarding experience for developers regardless of which build environment they're in. It could also serve as an example PWA that uses Workbox under the hood. The disadvantages are that we'd lose some context about the local filesystem (knowing the names of the directories, knowing the file types that are in the source directory, etc.)

😍 😍 😍 😍  for web based wizard, it'd serve as a perfect thing to onboard people starting to use workbox.
Also it might be too much, but may be saving the final settings as a template/json so that it can be shared would be 💯 (e.g. here's the configuration for company X/project Y's service worker generation).

Consensus seems to be:

Carry over the workbox-cli wizard as-is for v3.
The web app idea has value, but not something that would take priority for anyone currently tasked with v3 work.

The web based builder idea reminded me of http://www.manifoldjs.com/generator, which exposes a UI for generating SW (in addition to manifests). For Workbox, I think there's value in thinking about this problem space and whether there's a particular type of user we think is going to benefit from this (prototypers? beginners?) before we build it. This might make for a good Q4 or Q1 exercise.

Hey @jeffposnick
I recently stumbled upon this issue while building webdash.xyz
Do you think it makes sense for me to build an open source plugin for webdash that's a UI on top of workbox wizard?
here's some technical analysis:

webdash-workbox would have workbox as a dev dependency
you'll be presented with a start wizard button that spawns npx workbox wizard in the end-user's project directory
the choices that you'd typically see in the console, will be displayed in webdash dashboard, as paper-checkbox or paper-radio-button
this means we don't lose context about the filesystem since the wizard is running in the end-user directory
after the workbox-config has been initialized, the plugin will serve as stats for your generated service-worker: for example, latest version of service worker (cache name), version of workbox running, and the ability to re-run the wizard and override the configuration

If you'd like a quick demo of how webdash works, you can checkout demo.webdash.xyz (P.S.: it's slow as it's hosted on a free EC2 machine and it's not on HTTPS due to some complications with cloudflare + EC2)

That certainly sounds like it could be useful if you've got the appetite to build it!
I'd say that you wouldn't have to limit yourself to what the current workbox wizard behavior is, since that's tailored to the workbox-cli use case. If you could infer from the existing project whether they're already using webpack or a node-based build script, then producing a configuration that will work for the workbox-webpack-plugin or workbox-build as a final output could be really useful.

Sounds great!
Webdash doesn't have any additional insights out of the box, I feel like if something was missing, it probably makes sense to include it as part of workbox wizard for all users to enjoy
I'll take a look soon at the source code for wizard and will ping you as soon as I have a working prototype

I think these are the approaches that will possibly work:
The main problem is that there's no api for workbox-cli's wizard
1. Build my own wizard (as you suggested)
However this sounds like I'll be reinventing most of the logic that you already have in runWizard and what ever fixes I merge, won't benefit workbox-cli (and vice versa)
2. Mock inquirer
const runWizard = require('./node_modules/workbox-cli/build/lib/run-wizard');

const mockInquirer = require('mock-inquirer')

mockInquirer([{
  swSrc: './src/',
  globPattern: '*.js',
  //...
}]);

runWizard();

with this approach I'll need to pass in all the answers before running runWizard (which seems to be working).
Do you think that's a good idea?
If yes, can I send a PR to add a main file for workbox-wizard, in order to require it properly?
3. Make it possible to use the code behind Workbox wizard as a node API
This will probably take a lot of time (even if I sent PRs) and would probably require waiting for the next major release
I'm personally included towards approach number 2, but would love to have your opinion as well
Thanks!

Quick update: I just published v1, and I'd love to get your feedback on it (what needs to be fixed/changed, ideas for the future, etc..), you can open issues on the plugin repo if you want
Here are some screenshots
I'll record a proper video soon and upload it on webdash.xyz
it can be tested by simply installing webdash & webdash-workbox:
npm install webdash webdash-workbox --save-dev
npx webdash

Thanks!

Great work, @jadjoubran!
(And webdash seems like a useful project in general!)

With https://github.com/jadjoubran/webdash-workbox out there, I don't think that we need to take this on as part of the formal Workbox project. Thanks again!


Adding new NavState for NavEnd

Would be very useful if we can have a new internal NavState for NavEngine that indicates NavEnd when on the last waypoint.
This addition would lead to on_nav_end() callback on VehicleMotionInterface. This would also be used to easily differentiate Nav end on error and normal end.

Yeap, it's in my list :-)
In particular, some on the top:

[ ] Actually mark waypoints as reached when really reached, and make progress to the next non-skipable one when done.
[ ] Emit events.

To be discussed later on (clarify scope / docs / handling on user side):

virtual void on_path_seems_blocked()

virtual void on_cannot_get_closer_to_blocked_target()

virtual void on_apparent_collision()

Was going to suggest the same regarding enqueued_motiom_timeout.