[rapids]add image2.1 support for spark-rapids init script

This pr is to add image-v2.1 support for spark-rapids init script.
The update is following this guide
fix #1043
Signed-off-by: liyuan<EMAIL_ADDRESS>

Hi @jayadeep-jayaraman, could you help review?
FYI @viadea

verified in local

/gcbrun

@cjac could you help share the log?

/gcbrun

I received the same error this time.  Not sure what might be causing the problem.

kubectl logs -f presubmit-1-5-rocky8-31dcbd99-2ac8-4a6e-af05-3ea83d52db19 --since-time=2023-02-09T02:14:52+00:00 --timestamps=true
Error from server: Get "https://<IP_ADDRESS>:10250/containerLogs/default/presubmit-1-5-rocky8-31dcbd99-2ac8-4a6e-af05-3ea83d52db19/presubmit-1-5-rocky8-31dcbd99-2ac8-4a6e-af05-3ea83d52db19?follow=true&sinceTime=2023-02-09T02%3A14%3A52Z&timestamps=true": tunnel closed

no, the first one was ubuntu and the second one was rocky.  Maybe it's happening for both, but it's a race to see which fails first?

/gcbrun

@cjac I just revert all changes, could you help build again to see if we still have errors?

/gcbrun

do we still hit the same error?

seems the test failed with image1.5, the script drop the support for image1.5 because spark-rapids cannot work with spark2.*, skip the test

@cjac could you help build again?

Fetched 104 MB in 56s (1863 kB/s)
E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/libv/libvorbis/libvorbis0a_1.3.6-2ubuntu1_amd64.deb  Connection failed [IP: <IP_ADDRESS> 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
The command '/bin/sh -c apt-get update && apt-get install -y openjdk-8-jdk python3-setuptools bazel' returned a non-zero code: 100

/gcbrun

@cjac could you help share the log?

kubectl logs -f presubmit-2-0-debian10-8b375948-d759-457e-8c5c-1f3e0326de8c --since-time=2023-02-09T04:33:18+00:00 --timestamps=true
Error from server (NotFound): pods "presubmit-2-0-debian10-8b375948-d759-457e-8c5c-1f3e0326de8c" not found
[[ 1 != 0 ]]
kubectl describe pod/presubmit-2-0-debian10-8b375948-d759-457e-8c5c-1f3e0326de8c
Error from server (NotFound): pods "presubmit-2-0-debian10-8b375948-d759-457e-8c5c-1f3e0326de8c" not found

/gcbrun

I'm going to call it a night.  I've handed off to engineers in APAC

I'm going to call it a night. I've handed off to engineers in APAC

Thanks @cjac, just revert to add the updates.

/gcbrun

LGTM. Have we tested the MIG support as well on DP 2.1?

all OS (Debian11 Rocky8 Ubuntu20) works well;
but MIG does not work, I can manually make it work, I am checking what is wrong with the script...

@jayadeep-jayaraman updated and make MIG work again, could you help build again?
FYI @viadea

Hi @cjac @jayadeep-jayaraman , could you help /gcbrun to see if we could pass the tests?

/gcbrun

Hi @jayadeep-jayaraman , could you help share the error log?

Hi @nvliyuan - there is an issue with the init scripts and I have raised a PR here. Once it is merged I will re-trigger the tests

Hi @jayadeep-jayaraman, I just fond the pr is merged, could you help trigger the tests?

/gcbrun

Hi @cjac , could you help share the log?

Sorry, I'm away from my laptop right now.  I'll be doing some development
in a few hours, though.  I'm in Thailand for a few weeks, so maybe our
schedules will overlap a bit more while I'm here.
On Mon, Feb 20, 2023, 09:37 liyuan @.***> wrote:

Hi @cjac https://github.com/cjac , could you help share the log?
—
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudDataproc/initialization-actions/pull/1046#issuecomment-1436222700,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAM6UUCJ2KGJLGPQEUWC2DWYLKFHANCNFSM6AAAAAAUT2VKTA
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

Hi @nvliyuan - only a portion of the PR (support for 2.1) is merged. The changes to handle K8S 1.24 is still in progress and I will raise a separate PR for it, once that change is done then I will trigger the test for this. Currently, all tests will fail with the below error
Step #7 - "dataproc-2.0-ubuntu18-tests": + kubectl run presubmit-2-0-ubuntu18-c604a348-3124-4995-9747-c1794de718ce --image=gcr.io/cloud-dataproc-ci/init-actions-image:c604a348-3124-4995-9747-c1794de718ce --requests=cpu=750m,memory=2Gi,ephemeral-storage=2Gi --restart=Never --env=COMMIT_SHA=fc4060dfdb2373b2d27894eb14314003917f9e7c --env=IMAGE_VERSION=2.0-ubuntu18 --command -- bash /init-actions/cloudbuild/presubmit.sh
Step #4 - "dataproc-1.5-ubuntu18-tests": Error: unknown flag: --requests
Step #4 - "dataproc-1.5-ubuntu18-tests": See 'kubectl run --help' for usage.
Step #6 - "dataproc-2.0-rocky8-tests": Error: unknown flag: --requests
Step #6 - "dataproc-2.0-rocky8-tests": See 'kubectl run --help' for usage.
Step #2 - "dataproc-1.5-debian10-tests": Error: unknown flag: --requests
Step #2 - "dataproc-1.5-debian10-tests": See 'kubectl run --help' for usage.
Step #7 - "dataproc-2.0-ubuntu18-tests": Error: unknown flag: --requests
Step #7 - "dataproc-2.0-ubuntu18-tests": See 'kubectl run --help' for usage.
Step #5 - "dataproc-2.0-debian10-tests": Error: unknown flag: --requests
Step #5 - "dataproc-2.0-debian10-tests": See 'kubectl run --help' for usage.
Step #3 - "dataproc-1.5-rocky8-tests": Error: unknown flag: --requests
Step #3 - "dataproc-1.5-rocky8-tests": See 'kubectl run --help' for usage.

Hi @jayadeep-jayaraman, sure, thanks for the updates. Please help trigger the test if the PRs (support for 2.1) are merged.

Without the k8s changes we will not be able to test the 2.1 image. As soon as I am done with those changes, I will trigger this test.

/gcbrun

Hi @cjac @nvliyuan - I have triggered the run to test the GPU related changes after the temporary change has been put in place. Will work on the permanent fix next week

Can you please resync your workspace and push the changes back so that I can trigger the test?

Can you please resync your workspace and push the changes back so that I can trigger the test?

Hi @jayadeep-jayaraman , do I need to push another commit?

It is still picking up the old vesion of the code kubectl run presubmit-2-0-rocky8-53a6f1a7-ab1c-45d9-837f-48a87c470c5d --image=gcr.io/cloud-dataproc-ci/init-actions-image:53a6f1a7-ab1c-45d9-837f-48a87c470c5d --requests=cpu=750m,memory=2Gi,ephemeral-storage=2Gi. Can you pls check

@jayadeep-jayaraman merged the changes from master, could you help gbcrun again?

Thanks, I have triggered the tests and it is running now.

Here are some of the errors that I found, I also saw errors related to Debian 11. Can you please test the scripts once locally before we run the tests again ?
Rocky 8 , Dataproc 2.0
+ list kernel-headers-4.18.0-425.10.1.el8_7.x86_64
/etc/google-dataproc/startup-scripts/dataproc-initialization-script-0: line 570: list: command not found
+ upgrade_kernel
+ [[ rocky == \d\e\b\i\a\n ]]
+ [[ rocky == \u\b\u\n\t\u ]]
+ [[ rocky == rocky ]]
++ yum info --installed kernel
++ awk '/^Version/ {print $3}'
+ KERN_VER=4.18.0
++ yum info --installed kernel
++ awk '/^Release/ {print $3}'
+ KERN_REL=425.10.1.el8_7
+ CURRENT_KERNEL_VERSION=4.18.0-425.10.1.el8_7
+ [[ rocky == \d\e\b\i\a\n ]]
+ [[ rocky == \u\b\u\n\t\u ]]
+ [[ rocky == \r\o\c\k\y ]]
+ yum info --available kernel
Last metadata expiration check: 0:00:03 ago on Wed 22 Feb 2023 04:46:43 AM UTC.
Available Packages
Name         : kernel
Version      : 4.18.0
Release      : 425.13.1.el8_7
Architecture : x86_64
Size         : 8.8 M
Source       : kernel-4.18.0-425.13.1.el8_7.src.rpm
Repository   : baseos
Summary      : The Linux kernel, based on version 4.18.0, heavily modified with backports
URL          : http://www.kernel.org/
License      : GPLv2 and Redistributable, no modification permitted
Description  : This is the package which provides the Linux kernel for Rocky
             : Linux. It is based on upstream Linux at version 4.18.0 and maintains kABI
             : compatibility of a set of approved symbols, however it is heavily modified with
             : backports and fixes pulled from newer upstream Linux kernel releases. This means
             : this is not a 4.18.0 kernel anymore: it includes several components which come
             : from newer upstream linux versions, while maintaining a well tested and stable
             : core. Some of the components/backports that may be pulled in are: changes like
             : updates to the core kernel (eg.: scheduler, cgroups, memory management, security
             : fixes and features), updates to block layer, supported filesystems, major driver
             : updates for supported hardware in Rocky Linux, enhancements for
             : enterprise customers, etc.

++ yum info --available kernel
++ awk '/^Version/ {print $3}'
+ KERN_VER=4.18.0
++ yum info --available kernel
++ awk '/^Release/ {print $3}'
Error: No matching Packages to list
+ KERN_REL=

It is weird, the PR does not change anything with Rocky8-image2.0, I also double check again with debian11-image2.1 & Rocky8-image2.0 and the script works well.

Just find that I test with --no-shielded-secure-boot \ with Deibain11-img2.1, since there is no way to install GPU driver in Debian/Rocky with secure-boot, let me disable it in the script.
For Rocky8-image2.0 error, still need to investigate.

Oh, sorry that just find my Rocky test script actually tests Debian, there is indeed an error to starting rocky cluster.

/gcbrun

Hi @jayadeep-jayaraman @cjac , just fix the rocky8 issue, the root cause is that we miss a dnf command in a if clause, see this link
for debian11-image2.1 issue and rocky8-image2.1 issue, can we test with no-secure-boot cluster in presubmit job? since we cannot disable it in scripts.

I believe the test will still fail if the presubmit job test with debian/rocky OS with secure-boot enabled.

Hi @nvliyuan - In the test scripts that are part of spark-rapids you can disable secure boot when you create debian and rocky clusters. I have executed the tests and will let you know if all versions pass except 2.1 debian and rocky

Hi @nvliyuan - for Debian 2.0 I am seeing the below errors, in addition can you fix the test script to disable secure boot if it is 2.1 image and os is rocky or debian. Once the changes are made I will rerun the tests.
2023-02-24T04:05:32.520246911Z FAIL: //:test_spark_rapids (shard 1 of 3) (see /home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/testlogs/test_spark_rapids/shard_1_of_3/test_attempts/attempt_1.log)
2023-02-24T04:18:41.755757811Z FAIL: //:test_spark_rapids (shard 1 of 3) (see /home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/testlogs/test_spark_rapids/shard_1_of_3/test_attempts/attempt_2.log)
2023-02-24T04:31:49.424686260Z FAIL: //:test_spark_rapids (shard 1 of 3) (see /home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/testlogs/test_spark_rapids/shard_1_of_3/test.log)
2023-02-24T04:31:49.430601724Z
2023-02-24T04:31:49.430669921Z FAILED: //:test_spark_rapids (Summary)
2023-02-24T04:31:49.430687159Z       /home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/testlogs/test_spark_rapids/shard_1_of_3/test.log
2023-02-24T04:31:49.430699788Z       /home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/testlogs/test_spark_rapids/shard_1_of_3/test_attempts/attempt_1.log
2023-02-24T04:31:49.430708537Z       /home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/testlogs/test_spark_rapids/shard_1_of_3/test_attempts/attempt_2.log
2023-02-24T04:31:49.451258846Z INFO: From Testing //:test_spark_rapids (shard 1 of 3):
2023-02-24T04:31:49.657027749Z ==================== Test output for //:test_spark_rapids (shard 1 of 3):
2023-02-24T04:31:49.657090578Z Running tests under Python 3.8.10: /usr/bin/python3
2023-02-24T04:31:49.657106123Z [ RUN      ] SparkRapidsTestCase.test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b')
2023-02-24T04:31:49.657119552Z [  FAILED  ] SparkRapidsTestCase.test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b')
2023-02-24T04:31:49.657128352Z [ RUN      ] SparkRapidsTestCase.test_spark_rapids('STANDARD', ['w-0'], 'type=nvidia-tesla-t4')
2023-02-24T04:31:49.657135632Z [       OK ] SparkRapidsTestCase.test_spark_rapids('STANDARD', ['w-0'], 'type=nvidia-tesla-t4')
2023-02-24T04:31:49.657142734Z ======================================================================
2023-02-24T04:31:49.657149910Z FAIL: test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b') (__main__.SparkRapidsTestCase)
2023-02-24T04:31:49.657157284Z test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b') (__main__.SparkRapidsTestCase)
2023-02-24T04:31:49.657165543Z test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b')
2023-02-24T04:31:49.657172943Z ----------------------------------------------------------------------
2023-02-24T04:31:49.657180583Z Traceback (most recent call last):
2023-02-24T04:31:49.657190247Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/io_abseil_py/absl/testing/parameterized.py", line 265, in bound_param_test
2023-02-24T04:31:49.657197690Z     test_method(self, *testcase_params)
2023-02-24T04:31:49.657205073Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 115, in test_install_gpu_with_mig
2023-02-24T04:31:49.657212563Z     self.verify_mig_instance("{}-{}".format(self.getClusterName(),
2023-02-24T04:31:49.657219680Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 23, in verify_mig_instance
2023-02-24T04:31:49.657247304Z     self.assert_instance_command(name,
2023-02-24T04:31:49.657256197Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 270, in assert_instance_command
2023-02-24T04:31:49.657263735Z     ret_code, stdout, stderr = self.assert_command(
2023-02-24T04:31:49.657271057Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 322, in assert_command
2023-02-24T04:31:49.657279732Z     self.assertEqual(
2023-02-24T04:31:49.657287211Z AssertionError: 123 != 0 : Failed to execute command:
2023-02-24T04:31:49.657308176Z gcloud compute ssh test-rapids-standard-2-0-20230224-035249-u58m-w-0 --zone=us-central1-b --command="/usr/bin/nvidia-smi --query-gpu=mig.mode.current --format=csv,noheader | uniq | xargs -I % test % = 'Enabled'"
2023-02-24T04:31:49.657316269Z STDOUT:
2023-02-24T04:31:49.657323326Z
2023-02-24T04:31:49.657330920Z STDERR:
2023-02-24T04:31:49.657338150Z
2023-02-24T04:31:49.657344687Z
2023-02-24T04:31:49.657351815Z ----------------------------------------------------------------------
2023-02-24T04:31:49.657358881Z Ran 2 tests in 841.875s
2023-02-24T04:31:49.657365794Z
2023-02-24T04:31:49.657372680Z FAILED (failures=1)
2023-02-24T04:31:49.657379703Z ================================================================================
2023-02-24T04:31:49.657387154Z ==================== Test output for //:test_spark_rapids (shard 1 of 3):
2023-02-24T04:31:49.657394358Z Running tests under Python 3.8.10: /usr/bin/python3
2023-02-24T04:31:49.657402162Z [ RUN      ] SparkRapidsTestCase.test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b')
2023-02-24T04:31:49.657409643Z [  FAILED  ] SparkRapidsTestCase.test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b')
2023-02-24T04:31:49.657417067Z [ RUN      ] SparkRapidsTestCase.test_spark_rapids('STANDARD', ['w-0'], 'type=nvidia-tesla-t4')
2023-02-24T04:31:49.657424298Z [       OK ] SparkRapidsTestCase.test_spark_rapids('STANDARD', ['w-0'], 'type=nvidia-tesla-t4')
2023-02-24T04:31:49.657431506Z ======================================================================
2023-02-24T04:31:49.657438722Z FAIL: test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b') (__main__.SparkRapidsTestCase)
2023-02-24T04:31:49.657453866Z test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b') (__main__.SparkRapidsTestCase)
2023-02-24T04:31:49.657461509Z test_install_gpu_with_mig('STANDARD', ['m', 'w-0', 'w-1'], None, 'type=nvidia-tesla-a100', 'NVIDIA', 'us-central1-b')
2023-02-24T04:31:49.657468711Z ----------------------------------------------------------------------
2023-02-24T04:31:49.657476066Z Traceback (most recent call last):
2023-02-24T04:31:49.657482812Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/io_abseil_py/absl/testing/parameterized.py", line 265, in bound_param_test
2023-02-24T04:31:49.657489541Z     test_method(self, *testcase_params)
2023-02-24T04:31:49.657496450Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 115, in test_install_gpu_with_mig
2023-02-24T04:31:49.657513739Z     self.verify_mig_instance("{}-{}".format(self.getClusterName(),
2023-02-24T04:31:49.657537958Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 23, in verify_mig_instance
2023-02-24T04:31:49.657548424Z     self.assert_instance_command(name,
2023-02-24T04:31:49.657555981Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 270, in assert_instance_command
2023-02-24T04:31:49.657562911Z     ret_code, stdout, stderr = self.assert_command(
2023-02-24T04:31:49.657570167Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 322, in assert_command
2023-02-24T04:31:49.657578755Z     self.assertEqual(
2023-02-24T04:31:49.657586719Z AssertionError: 123 != 0 : Failed to execute command:
2023-02-24T04:31:49.657594228Z gcloud compute ssh test-rapids-standard-2-0-20230224-040554-e2ac-w-0 --zone=us-central1-b --command="/usr/bin/nvidia-smi --query-gpu=mig.mode.current --format=csv,noheader | uniq | xargs -I % test % = 'Enabled'"
2023-02-24T04:31:49.657601520Z STDOUT:

Hi @jayadeep-jayaraman @cjac ,just fix the mig script issue, and bazel tests passed in my local. But I don't know how to disable secure-boot in my test script, I try some config but none of them works. How can I disable it?

Hi @jayadeep-jayaraman , just update the test script to disable secure boot when OS is rocky and debian, it works in my local bazel test, could you help gcbrun?

/gcbrun

Hi @nvliyuan - due to changes in integration_tests/dataproc_test_case.py all the test cases are failing. For the time being can you revert the change made to this file and in the rapids test case can you bypass the 2.1 test for Debian and Rocky so that we can test the GPU related changes only. Once the tests are successful we can test for 2.1 debian and rocky separately. I will raise a separate request for fixing the other test scripts

Hi @jayadeep-jayaraman , sure, revert the changes and skip the tests for image2.1-debian and rocky.

The test is failing for mig. Can you pls check

Hi @jayadeep-jayaraman , I verified the MIG script works in my tests, I hit this issue if I did not set up the MIG script in startup-script-url, I am not sure whether the MIG script exists in self.INIT_ACTIONS_REPO, could you help verify?

Yes, you are right the mig.sh file is not present. I found one more interesting thing, in the gpu folder there is a BUILD but it is not present inside spark-rapids folder. Can you add this ?

add the BUILD script

The job is failing with the error
2023-03-01T13:54:42.374674679Z ERROR: /init-actions/BUILD:113:8: Label '//:spark-rapids/verify_xgboost_spark_rapids.scala' is invalid because 'spark-rapids' is a subpackage; perhaps you meant to put the colon here: '//spark-rapids:verify_xgboost_spark_rapids.scala'?
2023-03-01T13:54:42.471516443Z ERROR: /init-actions/BUILD:113:8: Label '//:spark-rapids/spark-rapids.sh' is invalid because 'spark-rapids' is a subpackage; perhaps you meant to put the colon here: '//spark-rapids:spark-rapids.sh'?
2023-03-01T13:54:42.471657517Z ERROR: /init-actions/BUILD:113:8: Label '//:spark-rapids/test_spark_rapids.py' is invalid because 'spark-rapids' is a subpackage; perhaps you meant to put the colon here: '//spark-rapids:test_spark_rapids.py'?
2023-03-01T13:54:42.571549028Z ERROR: Error evaluating ':test_spark_rapids': error loading package '': Package '' contains errors
2023-03-01T13:54:42.774154598Z INFO: Elapsed time: 26.779s

which looks like is coming from this piece of code. I checked for gpu and this logic is not present in this BUILD file, therefore can we remove this from here as we have a separate build file
In addition can we change :test_spark_rapids to //spark-rapids:test_spark_rapids present here

Hi @jayadeep-jayaraman , just updated the BUILD scripts

Hi @nvliyuan apologies for going back and forth on this but the builds are failing because the folder has a dash in its name "spark-rapids" as per the logic defined here and below is the log:-
2023-03-01T16:46:41.921597834Z Starting local Bazel server and connecting to it...
2023-03-01T16:46:59.172345959Z ERROR: no such target '//:test_spark_rapids': target 'test_spark_rapids' not declared in package '' defined by /init-actions/BUILD (Tip: use `query "//:*"` to see all the targets in that package)
2023-03-01T16:46:59.409600905Z INFO: Elapsed time: 24.237s

I believe we will have to keep the tests in the top level BUILD file like it was there originally and remove BUILD file from spark-rapids folder. In the original BUILD file can you add mig.sh in the data variable inside py_tests. From the documentation all the files needed at runtime needs to be specified here

Hi @jayadeep-jayaraman , just updated the BUILD scripts as suggested, thanks for the document, will read it tomorrow

With the latest changes 1.5 all version, 2.0 debian, 2.0 ubuntu and 2.1 debian and 2.0 rocky are passing the tests.
2.1 Ubuntu and 2.0 Rocky tests are failing with the below errors
2.0 Rocky Errors
+ grep -q NVIDIA
+ /usr/bin/nvidia-smi --query-gpu=mig.mode.current --format=csv,noheader
/etc/google-dataproc/startup-scripts/dataproc-initialization-script-0: line 450: /usr/bin/nvidia-smi: No such file or directory
+ uniq
+ wc -l

+ return 0
+ modprobe nvidia
modprobe: FATAL: Module nvidia not found in directory /lib/modules/4.18.0-425.10.1.el8_7.x86_64

2.1 Ubuntu Errors
2023-03-02T01:22:07.430622044Z ================================================================================
2023-03-02T01:22:07.430629365Z ==================== Test output for //:test_spark_rapids (shard 3 of 3):
2023-03-02T01:22:07.430636546Z Running tests under Python 3.8.10: /usr/bin/python3
2023-03-02T01:22:07.430643280Z [ RUN      ] SparkRapidsTestCase.test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430650150Z [  FAILED  ] SparkRapidsTestCase.test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430673695Z ======================================================================
2023-03-02T01:22:07.430683490Z FAIL: test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4') (__main__.SparkRapidsTestCase)
2023-03-02T01:22:07.430690221Z test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4') (__main__.SparkRapidsTestCase)
2023-03-02T01:22:07.430696545Z test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430703008Z ----------------------------------------------------------------------
2023-03-02T01:22:07.430709852Z Traceback (most recent call last):
2023-03-02T01:22:07.430719756Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/io_abseil_py/absl/testing/parameterized.py", line 265, in bound_param_test
2023-03-02T01:22:07.430728165Z     test_method(self, *testcase_params)
2023-03-02T01:22:07.430735299Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 54, in test_spark_rapids
2023-03-02T01:22:07.431272227Z     self.createCluster(
2023-03-02T01:22:07.431383383Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 170, in createCluster
2023-03-02T01:22:07.431398478Z     _, stdout, _ = self.assert_command(
2023-03-02T01:22:07.431421886Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 322, in assert_command
2023-03-02T01:22:07.431429181Z     self.assertEqual(
2023-03-02T01:22:07.431440290Z AssertionError: 1 != 0 : Failed to execute command:
2023-03-02T01:22:07.431448974Z gcloud dataproc clusters create test-rapids-single-2-1-20230302-011509-c9da --single-node --image-version=2.1-ubuntu20 --initialization-actions='gs://dataproc-init-actions-test-cloud-dataproc-ci/20230302-011459-jdpw/spark-rapids/spark-rapids.sh' --initialization-action-timeout=30m --metadata=gpu-driver-provider=NVIDIA,rapids-runtime=SPARK --master-accelerator=type=nvidia-tesla-t4 --worker-accelerator=type=nvidia-tesla-t4 --master-machine-type=n1-standard-4 --worker-machine-type=n1-standard-4 --master-boot-disk-size=1024GB --worker-boot-disk-size=1024GB --format=json --region=us-central1 --max-age=2h
2023-03-02T01:22:07.431469664Z STDOUT:
2023-03-02T01:22:07.431476283Z
2023-03-02T01:22:07.431483031Z STDERR:
2023-03-02T01:22:07.431507604Z Waiting on operation [projects/cloud-dataproc-ci/regions/us-central1/operations/57c2b140-af85-3ec5-a85c-c66e17d71daa].
2023-03-02T01:22:07.431516544Z Waiting for cluster creation operation...
2023-03-02T01:22:07.434144284Z WARNING: Permissions are missing for the default service account<EMAIL_ADDRESS>missing permissions: [storage.objects.get, storage.objects.update] on the staging_bucket 'projects/_/buckets/dataproc-108de5de-43c2-4a4b-979a-adebc15a58a8-us-central1'. This usually happens when a custom resource (ex: custom staging bucket) or a user-managed VM Service account has been provided and the default/user-managed service account hasn't been granted enough permissions on the resource. See https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/service-accounts#VM_service_account.
2023-03-02T01:22:07.434177968Z WARNING: Permissions are missing for the default service account<EMAIL_ADDRESS>missing permissions: [storage.objects.get, storage.objects.update] on the temp_bucket 'projects/_/buckets/dataproc-temp-us-central1-786080889824-65know3v'. This usually happens when a custom resource (ex: custom staging bucket) or a user-managed VM Service account has been provided and the default/user-managed service account hasn't been granted enough permissions on the resource. See https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/service-accounts#VM_service_account.
2023-03-02T01:22:07.434191277Z ...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
2023-03-02T01:22:07.434200065Z ERROR: (gcloud.dataproc.clusters.create) Operation [projects/cloud-dataproc-ci/regions/us-central1/operations/57c2b140-af85-3ec5-a85c-c66e17d71daa] failed: Initialization action failed. Failed action 'gs://dataproc-init-actions-test-cloud-dataproc-ci/20230302-011459-jdpw/spark-rapids/spark-rapids.sh', see output in: gs://dataproc-108de5de-43c2-4a4b-979a-adebc15a58a8-us-central1/google-cloud-dataproc-metainfo/12c7fb12-07bc-4364-9e0a-d7c2013bd994/test-rapids-single-2-1-20230302-011509-c9da-m/dataproc-initialization-script-0_output.
2023-03-02T01:22:07.434264584Z
2023-03-02T01:22:07.430622044Z ================================================================================
2023-03-02T01:22:07.430629365Z ==================== Test output for //:test_spark_rapids (shard 3 of 3):
2023-03-02T01:22:07.430636546Z Running tests under Python 3.8.10: /usr/bin/python3
2023-03-02T01:22:07.430643280Z [ RUN      ] SparkRapidsTestCase.test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430650150Z [  FAILED  ] SparkRapidsTestCase.test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430673695Z ======================================================================
2023-03-02T01:22:07.430683490Z FAIL: test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4') (__main__.SparkRapidsTestCase)
2023-03-02T01:22:07.430690221Z test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4') (__main__.SparkRapidsTestCase)
2023-03-02T01:22:07.430696545Z test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430703008Z ----------------------------------------------------------------------
2023-03-02T01:22:07.430709852Z Traceback (most recent call last):
2023-03-02T01:22:07.430719756Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/io_abseil_py/absl/testing/parameterized.py", line 265, in bound_param_test
2023-03-02T01:22:07.430728165Z     test_method(self, *testcase_params)
2023-03-02T01:22:07.430735299Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 54, in test_spark_rapids
2023-03-02T01:22:07.431272227Z     self.createCluster(
2023-03-02T01:22:07.431383383Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 170, in createCluster
2023-03-02T01:22:07.431398478Z     _, stdout, _ = self.assert_command(
2023-03-02T01:22:07.431421886Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 322, in assert_command
2023-03-02T01:22:07.431429181Z     self.assertEqual(
2023-03-02T01:22:07.431440290Z AssertionError: 1 != 0 : Failed to execute command:
2023-03-02T01:22:07.431448974Z gcloud dataproc clusters create test-rapids-single-2-1-20230302-011509-c9da --single-node --image-version=2.1-ubuntu20 --initialization-actions='gs://dataproc-init-actions-test-cloud-dataproc-ci/20230302-011459-jdpw/spark-rapids/spark-rapids.sh' --initialization-action-timeout=30m --metadata=gpu-driver-provider=NVIDIA,rapids-runtime=SPARK --master-accelerator=type=nvidia-tesla-t4 --worker-accelerator=type=nvidia-tesla-t4 --master-machine-type=n1-standard-4 --worker-machine-type=n1-standard-4 --master-boot-disk-size=1024GB --worker-boot-disk-size=1024GB --format=json --region=us-central1 --max-age=2h
2023-03-02T01:22:07.431469664Z STDOUT:
2023-03-02T01:22:07.431476283Z
2023-03-02T01:22:07.431483031Z STDERR:
2023-03-02T01:22:07.431507604Z Waiting on operation [projects/cloud-dataproc-ci/regions/us-central1/operations/57c2b140-af85-3ec5-a85c-c66e17d71daa].
2023-03-02T01:22:07.431516544Z Waiting for cluster creation operation...
2023-03-02T01:22:07.434144284Z WARNING: Permissions are missing for the default service account<EMAIL_ADDRESS>missing permissions: [storage.objects.get, storage.objects.update] on the staging_bucket 'projects/_/buckets/dataproc-108de5de-43c2-4a4b-979a-adebc15a58a8-us-central1'. This usually happens when a custom resource (ex: custom staging bucket) or a user-managed VM Service account has been provided and the default/user-managed service account hasn't been granted enough permissions on the resource. See https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/service-accounts#VM_service_account.
2023-03-02T01:22:07.434177968Z WARNING: Permissions are missing for the default service account<EMAIL_ADDRESS>missing permissions: [storage.objects.get, storage.objects.update] on the temp_bucket 'projects/_/buckets/dataproc-temp-us-central1-786080889824-65know3v'. This usually happens when a custom resource (ex: custom staging bucket) or a user-managed VM Service account has been provided and the default/user-managed service account hasn't been granted enough permissions on the resource. See https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/service-accounts#VM_service_account.
2023-03-02T01:22:07.434191277Z ...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
2023-03-02T01:22:07.434200065Z ERROR: (gcloud.dataproc.clusters.create) Operation [projects/cloud-dataproc-ci/regions/us-central1/operations/57c2b140-af85-3ec5-a85c-c66e17d71daa] failed: Initialization action failed. Failed action 'gs://dataproc-init-actions-test-cloud-dataproc-ci/20230302-011459-jdpw/spark-rapids/spark-rapids.sh', see output in: gs://dataproc-108de5de-43c2-4a4b-979a-adebc15a58a8-us-central1/google-cloud-dataproc-metainfo/12c7fb12-07bc-4364-9e0a-d7c2013bd994/test-rapids-single-2-1-20230302-011509-c9da-m/dataproc-initialization-script-0_output.
2023-03-02T01:22:07.434264584Z 2023-03-02T01:22:07.430622044Z ================================================================================
2023-03-02T01:22:07.430629365Z ==================== Test output for //:test_spark_rapids (shard 3 of 3):
2023-03-02T01:22:07.430636546Z Running tests under Python 3.8.10: /usr/bin/python3
2023-03-02T01:22:07.430643280Z [ RUN      ] SparkRapidsTestCase.test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430650150Z [  FAILED  ] SparkRapidsTestCase.test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430673695Z ======================================================================
2023-03-02T01:22:07.430683490Z FAIL: test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4') (__main__.SparkRapidsTestCase)
2023-03-02T01:22:07.430690221Z test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4') (__main__.SparkRapidsTestCase)
2023-03-02T01:22:07.430696545Z test_spark_rapids('SINGLE', ['m'], 'type=nvidia-tesla-t4')
2023-03-02T01:22:07.430703008Z ----------------------------------------------------------------------
2023-03-02T01:22:07.430709852Z Traceback (most recent call last):
2023-03-02T01:22:07.430719756Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/io_abseil_py/absl/testing/parameterized.py", line 265, in bound_param_test
2023-03-02T01:22:07.430728165Z     test_method(self, *testcase_params)
2023-03-02T01:22:07.430735299Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/spark-rapids/test_spark_rapids.py", line 54, in test_spark_rapids
2023-03-02T01:22:07.431272227Z     self.createCluster(
2023-03-02T01:22:07.431383383Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 170, in createCluster
2023-03-02T01:22:07.431398478Z     _, stdout, _ = self.assert_command(
2023-03-02T01:22:07.431421886Z   File "/home/ia-tests/.cache/bazel/_bazel_ia-tests/83b1ae36bb04ea5432b9efccee83c25f/execroot/__main__/bazel-out/k8-fastbuild/bin/test_spark_rapids.runfiles/__main__/integration_tests/dataproc_test_case.py", line 322, in assert_command
2023-03-02T01:22:07.431429181Z     self.assertEqual(
2023-03-02T01:22:07.431440290Z AssertionError: 1 != 0 : Failed to execute command:
2023-03-02T01:22:07.431448974Z gcloud dataproc clusters create test-rapids-single-2-1-20230302-011509-c9da --single-node --image-version=2.1-ubuntu20 --initialization-actions='gs://dataproc-init-actions-test-cloud-dataproc-ci/20230302-011459-jdpw/spark-rapids/spark-rapids.sh' --initialization-action-timeout=30m --metadata=gpu-driver-provider=NVIDIA,rapids-runtime=SPARK --master-accelerator=type=nvidia-tesla-t4 --worker-accelerator=type=nvidia-tesla-t4 --master-machine-type=n1-standard-4 --worker-machine-type=n1-standard-4 --master-boot-disk-size=1024GB --worker-boot-disk-size=1024GB --format=json --region=us-central1 --max-age=2h
2023-03-02T01:22:07.431469664Z STDOUT:
2023-03-02T01:22:07.431476283Z
2023-03-02T01:22:07.431483031Z STDERR:
2023-03-02T01:22:07.431507604Z Waiting on operation [projects/cloud-dataproc-ci/regions/us-central1/operations/57c2b140-af85-3ec5-a85c-c66e17d71daa].
2023-03-02T01:22:07.431516544Z Waiting for cluster creation operation...
2023-03-02T01:22:07.434144284Z WARNING: Permissions are missing for the default service account<EMAIL_ADDRESS>missing permissions: [storage.objects.get, storage.objects.update] on the staging_bucket 'projects/_/buckets/dataproc-108de5de-43c2-4a4b-979a-adebc15a58a8-us-central1'. This usually happens when a custom resource (ex: custom staging bucket) or a user-managed VM Service account has been provided and the default/user-managed service account hasn't been granted enough permissions on the resource. See https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/service-accounts#VM_service_account.
2023-03-02T01:22:07.434177968Z WARNING: Permissions are missing for the default service account<EMAIL_ADDRESS>missing permissions: [storage.objects.get, storage.objects.update] on the temp_bucket 'projects/_/buckets/dataproc-temp-us-central1-786080889824-65know3v'. This usually happens when a custom resource (ex: custom staging bucket) or a user-managed VM Service account has been provided and the default/user-managed service account hasn't been granted enough permissions on the resource. See https://cloud.google.com/dataproc/docs/concepts/configuring-clusters/service-accounts#VM_service_account.
2023-03-02T01:22:07.434191277Z  done.
2023-03-02T01:22:07.434200065Z ERROR: (gcloud.dataproc.clusters.create) Operation [projects/cloud-dataproc-ci/regions/us-central1/operations/57c2b140-af85-3ec5-a85c-c66e17d71daa] failed: Initialization action failed. Failed action 'gs://dataproc-init-actions-test-cloud-dataproc-ci/20230302-011459-jdpw/spark-rapids/spark-rapids.sh', see output in: gs://dataproc-108de5de-43c2-4a4b-979a-adebc15a58a8-us-central1/google-cloud-dataproc-metainfo/12c7fb12-07bc-4364-9e0a-d7c2013bd994/test-rapids-single-2-1-20230302-011509-c9da-m/dataproc-initialization-script-0_output.
2023-03-02T01:22:07.434264584Z

I looked at the log file and found the below as the last 10 lines
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  python3-software-properties
The following packages will be upgraded:
  python3-software-properties software-properties-common
2 upgraded, 0 newly installed, 0 to remove and 35 not upgraded.
Need to get 32.0 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Abort.

Also found this in the 2.1 ubuntu logs, not sure if this is helpful
+ bdconfig set_property --configuration_file /etc/hadoop/conf/yarn-site.xml --name yarn.resource-types --value yarn.io/gpu --clobber
+ lspci
+ grep -q NVIDIA
+ /usr/bin/nvidia-smi --query-gpu=mig.mode.current --format=csv,noheader
+ uniq
/etc/google-dataproc/startup-scripts/dataproc-initialization-script-0: line 450: /usr/bin/nvidia-smi: No such file or directory
+ wc -l
0
+ [[ ubuntu == debian ]]
+ [[ ubuntu == ubuntu ]]
++ uname -r
+ execute_with_retries 'apt-get install -y -q '\''linux-headers-5.15.0-1027-gcp'\'''
+ local -r 'cmd=apt-get install -y -q '\''linux-headers-5.15.0-1027-gcp'\'''
+ (( i = 0 ))
+ (( i < 10 ))
+ eval 'apt-get install -y -q '\''linux-headers-5.15.0-1027-gcp'\'''
++ apt-get install -y -q linux-headers-5.15.0-1027-gcp

Hi @nvliyuan - apologies for the delay, unfortunately there is no option today to stop and start a cluster in an init script. Therefore I think we can ignore the tests for images which need this feature. In addition, it would be good to break out the scripts if in actual production environment users need to stop and start clusters midway, such that they can run the startup script , restart the cluster and if you add the ability of the script to run during reboot then the second part of the script can run.

Hi @nvliyuan - apologies for the delay, unfortunately there is no option today to stop and start a cluster in an init script. Therefore I think we can ignore the tests for images which need this feature. In addition, it would be good to break out the scripts if in actual production environment users need to stop and start clusters midway, such that they can run the startup script , restart the cluster and if you add the ability of the script to run during reboot then the second part of the script can run.

I skipped the test for the image which require reboot for this pr as a workaround. I will draft another pr to address the reboot issues and other comments.

/gcbrun

Merged changes as tests have passed


snippet(latex): Add (texmathp) condition to certain snippets

[ X] I searched the issue tracker and this hasn't been PRed before.
[ X] My changes are not on the do-not-PR list for this project.
[X ] My commits conform to the git conventions.

LGTM. Thanks for your help!

Hi, sorry for the nuances, but in the last commit, I have overlooked a
small mistake (due to my editor config) that certain snippets (to be
precise int, prod and sum) are ending with newline characters. Can you
please undo those changes.
Thanks
On Mon, Feb 12, 2024 at 4:52 PM Henrik Lissner @.***>
wrote:

LGTM. Thanks for your help!
—
Reply to this email directly, view it on GitHub
https://github.com/doomemacs/snippets/pull/103#issuecomment-1938488921,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALDIJ5KJ24BRHBHOSQG5F7TYTH3OLAVCNFSM6AAAAABDEJVMO2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZYGQ4DQOJSGE
.
You are receiving this because you authored the thread.Message ID:
@.***>


Netty crash

What version of ViaVersion are you using? Type /ver viaversion
[20:40:07 INFO]: ViaVersion version 0.8.3
[20:40:07 INFO]: Author: _MylesC
What version of Spigot are you using? Type /ver
[20:40:17 INFO]: This server is running CraftBukkit version git-Spigot-8a048fe-a022dd2 (MC: 1.9.4) (Implementing API version 1.9.4-R0.1-SNAPSHOT)
[20:40:17 INFO]: Checking version, please wait...
[20:40:18 INFO]: You are running the latest version
What plugins are you using? Type /plugins
https://i.gyazo.com/92ac29f02570209812836d4dd9974a40.png
Are you using any additional software like BungeeCord? If so, what software and version? (Please list your plugins as well)
Waterfall, https://i.gyazo.com/e400fbd01df6da3bfe6ee4150cb7edeb.png
How does this error happen? login? Using an item?
Login
Is there an error in the console? Use pastebin.com. Is there a kick message?
http://pastebin.com/Un0K6mdw , http://pastebin.com/XxEz810m
Only this plugin use netty.

Could you enabled debug=true in server.properties and post the console log?

Also try without SkinRestorer. ^^

http://pastebin.com/1bh5e7Px

Does it happen without ViaVersion?

I dont can test it. I have 2 servers with 200+ online. 60% players dont use 1.9.3/4.
And i had this error in version 1.9.2.

I don't think this is ViaVersion related. Unless you can test otherwise we can't help you.

SkinsRestorer error


Adding multiple outputs to custom layer leads to malloc craches

When I add a custom op with multiple outputs, I get a malloc error while the model is being read in CoreML/ios.
Has anyone observed anything similar?
 # get the value of k
coreml_nn_builder.add_custom(name=tf_op.name,
                             input_names=[tf_op.inputs[0].name],
#                            output_names=[tf_op.outputs[0].name, tf_op.outputs[1].name],
                              output_names=[tf_op.outputs[0].name],
                              custom_proto_spec=params)

Please file a bug at https://developer.apple.com/bug-reporting/
with the code to reproduce the malloc crash.

@scm-ns could you please provide us with more information or have you submitted a bug for this? Thanks!


[Bug] Login issues mangadex breach

Device information

Tachiyomi version: ?
Android phone & version: A51, android 11

Steps to reproduce

First step

uninstall

Second step
login

Expected behavior
logging in with the correct password and name should log you in, clicking on manga panels should open them and display chapters.
Actual behavior
App says unknown error when you check it after leaving it claims you are logged in, app says "MangaDex error from Mangadex Response code 404"
Other details
This happened after the breach, the app was failing to update most manga and I figured that uninstalling it might help. Unfortunately, logging in seems to be broken and manga seems to not load. I imagine that this isn't the fault of the Neko devs but the chaos and and update with the API, I'd just like some confirmation.

Me too, I can't read manga

Try going into Advance > Clear Cookies, restart the app, and re-login.

What gold said.  I don't know if its region specific or not (i have no issues logging out and logging in).

Make sure you are able to login through chrome on your phone
Make sure you are using 2FA if you have it enabled
Make sure you are typing in your password correctly

What is 2fa

?

Two Factor Authentication


Feature: Add Country to Advanced Search and Filter

As a Scribe, I know that David Crockett Graham did A Lot of collecting in China / Tibet regions. In the agent strings interface, I can search for strings (example David C Graham) and then sort by country. The ones from China are likely ALL this particular person.
In Help Attribute, using the Advanced Search and Filter, if Country is added as a Filter, I could then attribute these all more easily.
Well, perhaps I just download the CSV and do the sort and attribute there. So, just an idea David.

That agent filter/sort is comparatively easy to implement because there's very little going on in the backend: two tables, one join. In the Help Attribute (or Profile) pages, there's a lot more logic going on (aliases, uses of search in realtime, joins to three+ tables) such that sort is much trickier to implement. I know it's a nuisance to use "Advanced Search" but I can add filtering for country there without much effort so this is a good suggestion. In fact, Country was not even listed in the table as it is with Agents so that should be added as a column too. If I don't add that column, filtering by country would be rather unsatisfactory.


Update media state via telnet interface

This PR enabled the telnet interface to update the media state. It still polls the state, but it sends and receives just a couple of characters over the existing connection and should be more efficient than using the HTTP interface.
Additionally, it updates the list of input functions when a potential change is discovered (like enabling/disabling and renaming sources).
@dcmeglio @bdraco @starkillerOG feel free to test it 😄

Testing now

Testing looks good. Only one issue in the log
2023-03-05 00:20:22.363 WARNING (MainThread) [denonavr.soundmode] Not able to match sound mode: 'DOLBY AUDIO-DSUR', assuming 'DOLBY DIGITAL'.

Thanks for your feedback. I adapted a few things.

Testing looks good. Only one issue in the log
2023-03-05 00:20:22.363 WARNING (MainThread) [denonavr.soundmode] Not able to match sound mode: 'DOLBY AUDIO-DSUR', assuming 'DOLBY DIGITAL'.

Which soundmode was active on your receiver when this message appeared? I'm not entirely sure where it belongs to.

I see you already merged it but I am out of town this week. I'll test it out this weekend

I should be by my system this weekend so I can check the sound mode if you don't get it fixed before than.

Did some more testing.  I'm able to get
2023-03-19 02:25:32.219 WARNING (MainThread) [denonavr.soundmode] Not able to match sound mode: 'DOLBY AUDIO-DSUR', assuming 'DOLBY DIGITAL'.
I'm also able to get
2023-03-19 02:28:51.478 WARNING (MainThread) [denonavr.soundmode] Not able to match sound mode: 'DOLBY AUDIO-DD+DSUR', assuming 'DOLBY DIGITAL'.
DOLBY AUDIO-DD+DSUR audio state is when the screen on the receiver says DD + DSur The requested mode is Auto

https://www.reddit.com/r/hometheater/comments/b7ftd5/what_does_dsur_on_my_receiver_actually_mean/
https://www.reddit.com/r/hometheater/comments/me9e1t/dolby_digital_vs_dolby_surround_51/
https://www.reddit.com/r/hometheater/comments/11j1myo/question_about_51_setup_versus_71_setup/
https://www.reddit.com/r/hometheater/comments/ruev63/512_sorround_dd_or_dsur/

https://github.com/ol-iver/denonavr/pull/249


Update commands.md to include task.uploadlog

Documenting the additional task logging command available with M101.

Hi @shashban, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@shashban, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSBOT;

@shashban What agent version was the command introduced?

Nevermind, I see 101. I'll fix the last column.


"Păgubeni" is listed in the drop-down menu

Description:
"Păgubeni" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Păgubeni" in the search bar.
Expected results
The location is listed in the drop-down menu as "Păgubeni, Bacău (Dărmănești)".


Added additional JSON tests,

Validate encoding/decoding of arrays, empty arrays, null (nil), true (bool), empty strings on the go client.

Coverage decreased (-0.1%) to 95.013% when pulling 83ef52c2dbeda46eed52b3a15332348b7c6cbf21 on additional-json-tests into 247b2a84d8d0ff15cbc6faafc77ef15ea4317011 on master.


Backport fixes to 2.0.x branch

This essentially prepares the final 2.0.0 release by:

Backporting all relevant fixes
Bumping the version numbers
Adding a Cargo.lock file as this hopefully allows us to checkout this branch at any later point in time and it will continue to build. This should not affect the release to crates.io in any way.

@diesel-rs/core  I propose to do a final stable diesel 2.0 release next week. Please leave a comment here if you have any objections. I will fill a PR against the web repository next week so that we also update the webpage to diesel 2.0 + include the migration guide, the changelog and a small release post there.

I propose to do a final stable diesel 2.0 release next week. Please leave a comment here if you have any objections.

The two things I have in mind that slightly scare me with regards to backwards compatibility upon solving are the following two comments:

https://github.com/diesel-rs/diesel/issues/1612#issuecomment-1096987553

https://github.com/diesel-rs/diesel/pull/2799#pullrequestreview-708943633
I'm not super confident with the current approach of https://github.com/diesel-rs/diesel/pull/2799#issuecomment-903161724 because that introduces:
a. Unnecessary lifetime bounds on the deserialization part
b. A somewhat-global config at the connection level, whereas whether you want to use one or the other would more typically depend on the amount of data you're querying and what you're doing with it afterwards (unless row-by-row is always ~faster) - which appears to be fundamentally more fine-grained than connection-level.
If however row-by-row is always ~faster, having just that version is always ideal and consistent across all backends so we could probably keep just that.

Unfortunately I have been very busy with other topics and couldn't work on these yet.

I've commented at 1. on this topic.
Would you agree it would be useful to have the benchmark suggested in 2's comment and the decision would depend on it?
If so, what do you think would be a reasonable timing to attempt implementation?

Return a iterator from Connection::load #2799 (review)
I'm not super confident with the current approach of
Return a iterator from Connection::load #2799 (comment) because that introduces:
a. Unnecessary lifetime bounds on the deserialization part
b. A somewhat-global config at the connection level, whereas whether you want to use one or the other would more typically depend on the amount of data you're querying and what you're doing with it afterwards (unless row-by-row is always ~faster) - which appears to be fundamentally more fine-grained than connection-level.
If however row-by-row is always ~faster, having just that version is always ideal and consistent across all backends so we could probably keep just that.

I remember that I've done some experimentation back then but I cannot find the corresponding code anymore. Will try to have another look in the next days.
What I remember is that the row by row mode was significantly slower for all of our benchmarks. I think the main issue there was that it allocates things per row again and again, where the "normal" mode reuses buffers and other things.
To address the concrete points:

a. Unnecessary lifetime bounds on the deserialization part

Yes the lifetime for Cursor is not optimal right now, but Cursor is not part of the public API. That means we can remove the lifetime if it turns out that we do not need it. That wouldn't work the other way around.

b. A somewhat-global config at the connection level, whereas whether you want to use one or the other would more typically depend on the amount of data you're querying and what you're doing with it afterwards (unless row-by-row is always ~faster) - which appears to be fundamentally more fine-grained than connection-level.

The point is there is not really an other place to configure this than the connection, because as soon as you call load_iter() or whatever the query is already executed. What we could do is to provide the connection level configuration with some documentation that basically says: Do not use this if you don't call Connection::load directly. Then we could modify RunQueryDsl to do "runtime type checking" to see if the connection is a PgConnection and just enable that mode there transparently. That would be hacky but would result in that behaviour most people would expect.

The point is there is not really an other place to configure this than the connection, because as soon as you call load_iter() or whatever the query is already executed

I was thinking about the design described in that comment : https://github.com/diesel-rs/diesel/pull/2799#pullrequestreview-708943633

I've put up a WIP PR for row by row mode in #3213 so that we could quickly check the performance implication of enabling it generally.
That written: I would really prefer not to have backend specific methods there, but instead a way to enable it only for specific queries. Maybe even by wrapping the corresponding query into an "option" struct that signals this should be loaded via row-by-row mode. The WIP-PR contains some parts to just enable the row by row mode only for load_iter().

Closed in favor of #3237


cross-compilation support

This is punted on in the current version, pending some evaluation of the options. There are three options I know:

cross-rs (established, based on docker)
cargo-zigbuild (new kid on the block, has some blocking issues)
Do It Our Dang Selves With Rustup (please god no)

This is a blocker for musl and aarch64 (arm64) support.
Note that taiki-e/upload-rust-binary-action does handle this and in my experiments whatever it does Just Works (great work from taiki-e as always).

One of my big concerns about cross-compilation is to what extent certain Fancy Things cannot be cross-compiled.
Apple certainly does not want you cross-compiling from linux to macos. I'm not sure if support for code signing (#21) or certain installers is necessarily non-crossable. Certainly some are harder to cross. Certainly there are... Ways Around The Rules. But I don't want to get people in trouble or have them ship busted things!

Just some of my recent experience/pain regarding cross compiling for Linux arm* and x86_64 targets for an open source project that I'm involved with.
Basically we have to build for linux environments on arm >= v6, arm64 and x86_64, for both gnu and musl releases. We were using cargo-cross however still had some issues to build for all the targets and the output was dependant on your build machine.
Then I saw a great blog post about cargo-zigbuild and was amazed with how effort it was to cross compile for all of our targets, especially since the other developers have a mix between Windows (using WSL2) and MacOS (M1/arm64 and amd64) setups.
Below details some of the details with the projects:
Experience cargo-cross

Slow builds as building on MacOS M1 (arm64/aarch64) and the current default is to use amd64 images by default (though there are unofficial arm64 available...there is also a "zigbuild" variant, from what I found digging around)
Building for musl on some targets just didn't work (mostly because of our project's dependency to the common ring...the number of times that dependency has caused me build headaches is just astounding)

Experience with cargo-zigbuild

Builds are quick
Does not rely on docker
Feels more like rust, as you just use cargo target add xxx, then cargo zigbuild --target xxx
Dependencies are included (ok, still had to install ziglang via pip first but that was it)

Overall I was finally able to get the following targets built using cargo-zigbuild running both natively on MacOS M1 and inside a linux (dev) container.

x86_64-unknown-linux-musl
aarch64-unknown-linux-musl
armv7-unknown-linux-musleabihf
arm-unknown-linux-musleabihf
x86_64-unknown-linux-gnu
aarch64-unknown-linux-gnu
armv7-unknown-linux-gnueabihf (yes, this does actually work...I think notice in the project's README.md is out of date)
arm-unknown-linux-gnueabihf

Though like you said, I don't think it will work for absolutely everything, so it might be worthwhile allowing some "composability" when it comes to building for different targets. And the targets are above are not so exotic compared to the other more lower level embedded targets, e.g. risc etc.
I created a gist to detail my experience, including the references to sources etc.
I hope my experience can at least help someone else, as this had caused me countless hours fluffy around with various dependencies/build machines.

armv7-unknown-linux-gnueabihf (yes, this does actually work...I think notice in the project's README.md is out of date)

To clarify, I have implemented some workarounds for these caveats in cargo-zigbuild and updated the readme: https://github.com/rust-cross/cargo-zigbuild#caveats

Is there any work being done on this and/or is there any way to help on this? Cross compiling to Linux ARM and Linux Aarch64 is an absolute must for me.

@reubenmiller I found the opposite. Zigbuild is great when it works, but:

It fails when trying to for example cross compile and link OpenSSL (openssl-sys crate). You can either enabled the vendored feature of openssl-sys to build OpenSSL from source or with cross install the relevant -dev package for cross compiling in a pre-build step in the docker container.Installing OpenSSL as a pre-build step is much faster than building it from scratch every time, easily negating the general speed improvement of zigbuild over cross. (And no, rustls/ring is not an option for several of the platforms I'm targeting.)
Cross supports running the tests using user mode qemu, zigbuild doesn't as far as I have been able to find. While this is not important for release, it is important for CI in general. And I'd rather not have to maintain two separate cross compilation systems.
Cross compiling to Windows (x86_64-pc-windows-gnu) from Linux just doesn't seem to work at at all with zigbuild, works out of the box with cross.

Thus I think cross is the better and more mature option to go with.

👋 Hey! I also wanted to chime in and see if cross compilation for cost reduction purposes was on the roadmap? Spinning up separate machines (especially expensive Mac machines, almost 10x an equivalent Linux machine) for every release seems like it could blow past the free tier on Github actions. While it's still cheap in the grand scheme of things, it would be cool to use the cheapest Github actions instance to compile for all platforms where possible.

Unfortunately, mac machines are probably the most difficult to replace because, unlike with MinGW, there's no libre equivalent to some of the parts of Apple's toolchain. (I believe the binary-signing tool is one such example, but that may be outdated information.)
The solutions I've run into which work without mac hardware have involved using parts of Apple's toolchain on top of non-mac hardware in violation of its license.

Will this issue be prioritized any time soon? It seems that a number of projects would love to see it happen:

https://github.com/kaspar030/laze/pull/303
https://github.com/probe-rs/probe-rs/issues/1892
https://github.com/stchris/aleph-tui/issues/3
I have 3+ CLIs that would also benefit from it:

https://github.com/near/near-cli-rs
https://github.com/near/cargo-near
https://github.com/bos-cli-rs/bos-cli-rs

For MacOS there are decent hosted runner options available in gitlab and github it's only windows that due to DRM is hard to get. But there cross compiling works very well with ubuntu runners and native packages and the gnome msitools. I opened #821 for integration of the later.

For MacOS there are decent hosted runner options available in gitlab and github it's only windows that due to DRM is hard to get. But there cross compiling works very well with ubuntu runners and native packages and the gnome msitools. I opened #821 for integration of the later.

No I don't believe this is true. Github Actions offers free (for open source) Ubuntu, Windows and MacOS x86 runners. There are no free MacOS ARM64 runners. Thus you need cross compilation if you want to create native MacOS-ARM64 binaries (cross testing seems impossible, rosetta only goes the other direction as far as I understand).
As far as I know most non-github options cost money, which is not an option for small open source hobby projects.
Windows can also be trivially cross compiled from Linux with the -gnu toolchain. The -msvc one cannot. There are no license-abiding ways to cross compile to MacOS at all as far as I know.

Hi, @VorpalBlade I was talking about Gitlab exclusively as we cannot use GitHub due to corporate requirements. GitLab has ARM64 runners. https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner.html#machine-types-available-for-macos

Hi, @VorpalBlade I was talking about Gitlab exclusively as we cannot use GitHub due to corporate requirements. GitLab has ARM64 runners. https://docs.gitlab.com/ee/ci/runners/saas/macos_saas_runner.html#machine-types-available-for-macos

You said "gitlab and github" in your original text so that is what I responded to. However it seems that the MacOS runners on gitlab are only available on "Tier: Premium, Ultimate", so that is irrelevant for open source projects. At least the windows runners there are available on the free tier.

Oh, sorry. I noticed that now. Anyway, in the text I was looking at it said

SaaS runners on macOS are in Beta for open-source programs and customers in Premium and Ultimate plans.

So I took it for a spin on my free account. https://gitlab.com/Toasterson/rust-cross-testing/-/pipelines but it looks like this feature does indeed need a Subscription...

I've been able to cross compile aarch64 from standard x86 GitHub Actions runners with a fairly small amount of configuration:

Manually add the relevant targets to Cargo.toml (this is necessary as they're not offered as options by cargo dist init).
E.g.
# Target platforms to build apps for (Rust target-triple syntax)
targets = ["aarch64-apple-darwin", "aarch64-unknown-linux-gnu", "aarch64-unknown-linux-musl", "x86_64-apple-darwin", "x86_64-unknown-linux-gnu", "x86_64-unknown-linux-musl"]

Add gcc-aarch64-linux-gnu to cargo-dist's dependencies.apt table. This installs a cross-compilation toolchain which can be invoked as aarch64-linux-gnu-gcc.
E.g.
[workspace.metadata.dist.dependencies.apt]
gcc-aarch64-linux-gnu = { version = '*', targets = ["aarch64-unknown-linux-gnu", "aarch64-unknown-linux-musl"] }

Create a .config/cargo.toml with the following overrides. cargo will automagically use aarch64-linux-gnu-gcc as the cc for aarch64-unknown-linux-gnu, but needs to be told to use it also for -musl and for linking of both targets.
E.g.
[env]
CC_aarch64_unknown_linux_musl = "aarch64-linux-gnu-gcc"

[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-gnu-gcc"

YMMV – I have minimal system dependencies in the projects where I've used this and I'm sure it would require more fiddling if you depend on additional system libraries (openssl etc). I've also not thoroughly tested the results (though I've tested that they execute, at least).

@connec Thanks for sharing! I tried to follow your steps, but system dependencies are blocking me (openssl and libudev): https://github.com/near/near-cli-rs/pull/319

Then you will need a sysroot with copies of those libs and headers and use the --sysroot flag when compiling. Add it to the .cargo/config.toml CC lines worked for me when I needed to cross compile. Checkout the cross project for sysroot tarballs and OCI images in the wild.

Well, I used cross before and it worked great, so I would love to see cargo-dist support it or any other solution.
I am getting more and more reports these days from people trying to use my CLIs on:

Docker on macOS ARM64 (M1/M2/...) which runs Linux ARM64 images
Raspberry Pi

@Gankra What is your vision/priority regarding cross-compilation? As a temporary solution, I am thinking about creating a separate workflow to build extra binary releases (I'll play with https://github.com/taiki-e/upload-rust-binary-action or build completely from scratch), and I expect that the installer will see those binary-release archives

YMMV – I have minimal system dependencies in the projects where I've used this and I'm sure it would require more fiddling if you depend on additional system libraries (openssl etc). I've also not thoroughly tested the results (though I've tested that they execute, at least).

It compiled every target except aarch64-unknown-linux-gnu, because of libudev:
error: failed to run custom build command for `libudev-sys v0.1.4`

Caused by:
  process didn't exit successfully: `/home/runner/work/modbus-mqtt/modbus-mqtt/target/dist/build/libudev-sys-289bc33b2b5e4d83/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=LIBUDEV_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libudev-sys-0.1.4/build.rs:38:41:
  called `Result::unwrap()` on an `Err` value: "pkg-config has not been configured to support cross-compilation.\n\nInstall a sysroot for the target platform and configure it via\nPKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a\ncross-compiling wrapper for pkg-config and set it via\nPKG_CONFIG environment variable."
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Based on reading the pkg-config-rs readme, in theory this could be overcome by setting the following in .cargo/config.toml:
[env]
PKG_CONFIG_SYSROOT_DIR_aarch64_unknown_linux_gnu = "/usr/aarch64-linux-gnu"

However, I'm not really sure how one goes about building a sysroot, nor how one would do this in a way that was harmonious with cargo-dist. I did find https://github.com/windelbouwman/sysroot-creator which looks interesting and could possibly be used by setting a wrapper script for the broken target which creates the sysroot with needed deps and exports the right PKG_CONFIG_* variables, but it does seem like an experiment from years ago that hasn't seen much usage or attention since.
Fortunately, in my case, libudev is a transitive dependency of serialport and I can live without it -- for now --, so can use serialport = { ..., default-features = false } to unblock some cross-compilation.
TL;DR: cross compilation out of the box seems advantageous. cargo-dist has a lot of secondary upsides in how it works, but https://github.com/taiki-e/upload-rust-binary-action supports cross-compilation and might be something to try for those who require cross-compilation beyond what can be worked around today here.

A Sysroot is simply a Target OS/Arch version of your Root filesystem layout. Simplest trick is to expand a VM image (Say ubuntu aarch64) into a directory and point pkgdev to it. Sysroot is at the end of the day a LLVM/GCC Linker feature all other utilities pass the sysroot to the linker.

cross not on your list?
From my experience (responding to comment about cross compiling directly from x86 host), that can work in many cases - but then you come across a crate that is a wrapper to a complex C/C++ build, and you run into header file and sysroot problems and it becomes very difficult.
So far, we have only have real (relatively straightforward) success building for aarch64, and arm7 using cross.
cargo-zigbuild looks amazing but we ran into a few blocker issues that prevented us from moving to it, so we stuck with cross and are happy.
IMO, no need to cross-compile macOS, if GH Actions has macOS runners (x86 and aarch64).


Remove mangle from uglifyjs' options.

The output should be consistent now.
@jmervine: can you run the lint.sh script in develop and see if you confirm bootlint.min.js is different for you too? That is what led me to this change.

👍 We'll need to coordinate releasing this to ensure that changes are pushed to s3.

@jmervine: feel free to merge this when you are ready to upload the files.

Updated SRI, which is going to make specs fail. Once I push these files, I'll need to release ASAP, as SRI will be broken in production.

Why do you have different files?

@jmervine: feel free to merge when you are ready.

Yeah, uploading the files and then going to merge and release.


Message acknowledgement

Hi,
Is there a method to acknowledge a received message?
With acknowledgement i can ensure a message is completely processed without errors.

We currently don't have anything to confirm the receipt of a message, would you be interested in implementing this functionality?

I'm thinking of changing the implementation (or creating a new one) using topic exchange instead of fanout, to allow precise routing and avoid broadcasting. I will try this next days.

Sounds good,  It might be good to add options that control the exchange behavior via our options class we pass in to the ctor?

I'm investigating some solutions, and the problem seems to be the different method used to route messages. For example, with Topic exchange type, you cannot use the same parameters (the same topic/routing/queue to send and receive messages, due to different behaviors of RabbitMQ routing. For this reason we have to implement different calls for different exchange types. I will start implementing a new MessageBus class using Topic exchange instead of Fanout starting from your code. In this manner we can eventually merge the different methods and use options to control the behavior.

@totalprogrammi were you able to find a good solution?


#182 Want to sort the connector config info when executing the describe command

https://github.com/kcctl/kcctl/issues/182

Applied, thx!


deprecate PkgConfig

motivation: PkgConfig was moved from SwiftPM into TSC, but really is closer to SwiftPM (not generic enough) and would be easier to maintain within SwiftPM itself
changes: mark PkgConfig and related utilities as deprecated

@swift-ci test


Can't find buffer/file name in modeline

This is a cross post from doom-modeline, as suggested by its maintainer: https://github.com/seagle0128/doom-modeline/issues/415#issue-808099809.
What did you expect to happen?
I expected to find the buffer/file name when files are open / being edited.
What actually happened?
I can't find the buffer/file name in my modeline when viewing .el, .py, .org and probably any other file.  Interestingly, the file name displays fine on the Doom splash screen.
Additional details:
As the issue persist even after a fresh install of doom-emacs (new clone of the repo and new ~/.doom.d), the default config files are also causing me this error.

No error messages except that 'cl' is deprecated.

Steps to reproduce:

Opened doom, saw ~/doom.d/ displaying fine on the modeline.

Opened my doom config.el file but don't see file name in the modeline.

Launched doom emacs in a sandbox Doom + modules - your private config (M-x doom/sandbox C-c C-p) and then opened config.el as above -- was able to see file name in the modeline. At this point, I thought this issue has something do with my my private config files, so I sought to obtain a fresh install of doom.

Fresh install of doom (I followed instructions for using Doom emacs alongside other distributions: https://github.com/hlissner/doom-emacs/blob/develop/docs/faq.org#how-do-i-use-doom-alongside-other-emacs-configs). At this point, I have fresh emacs-doom directory and default .doom.d config.el, packages.el and init.el files.

Opened config.el and still was not able to find file name in the modeline.

Once again, tried to launch doom emacs in sandbox and was able to once again find file name in the modeline.

Comparison of (left) fresh install of doom and (right) sandbox:

I did notice that the red debug spider is also missing...
System information:

 - OS and version: Windows 10 running Ubuntu 20.04 on WSL 1
 - Emacs Version: 27.1
 - doom ui/modeline v2.0.9
M-x doom/info: https://pastebin.com/T1sgUus6

Open the sandbox: M-x doom/sandbox
Type the following in the sandbox buffer:

(require 'doom-modeline)
(doom-modeline-mode +1)

Press C-c C-c to launch vanilla Emacs (no Doom, no private config).
Can you reproduce the issue?

This is the result -- I was able to see the buffer/file name:


Potential different accelerometer library

https://github.com/rickkas7/LIS3DH

Accel wake issue fixed; just have to init GPS before accel


Error upon calling ExecuteNextAsync in Azure App Services

Create a simple vertex query:
 var vertexQuery = ((DocumentClient)_client).CreateGremlinQuery<Vertex>(docCollection,
                    $"g.V('{memberId}')" +
                    $".outE('posts')" +
                    $".inV()");

 while (vertexQuery.HasMoreResults)
                {
                    foreach (var result in await vertexQuery.ExecuteNextAsync<Vertex>())  //crashes on this line in azure app service
                    {
                        benefits.Add(await _groupservice.GetBenefitAsync(groupId, new Guid(result.Id.ToString())));
                    }
                }

it crashes on  executenextassync when running in azure app service but runs fine locally using the same data connections.
The exception in application insights is:
An unhandled exception has occurred: Unexpected character encountered while parsing value: }. Path '[0].properties.Modified[0].value', line 1, position 714.

Can you provide the following information:

Version of Microsoft.Azure.Graphs
Version of Newtonsoft.Json
Stack trace for the error if available.

It seems unusual that it would work locally but fail when running remotely.
Are there any differences in the web.config between what is published and what is local?

.net core 2.0 backend (webapi) with angular 5 front end.
Microsoft.Azure.Graphs 0.3.1-preview
Newtonsoft.Json 10.0.3
An unhandled exception has occurred: Unexpected character encountered while parsing value: }. Path '[0].properties.Modified[0].value', line 1, position 493.
happens when this line is executed:
 var planVertex = (await ((DocumentClient)_client).CreateGremlinQuery<Vertex>(docCollection,
                   $"g.V('{edges.FirstOrDefault().InVertexId.ToString()}')" +
                   $".outE('plan')" +
                   $".inV()").ExecuteNextAsync<Vertex>()).FirstOrDefault();

running in release mode locally works fine. I should also point out that when running locally or in azure, the same connections are used (cosmosdb, storage etc..) the only difference is the environment. Other gremlin queries run just fine in azure, but some just don't work.
web.config is the same, appsettings pretty much the same except for this setting which is not there locally? WEBSITE_NODE_DEFAULT_VERSION but I don't think this should affect the .net core environment.
this has happened before apparantly: https://github.com/Azure/azure-documentdb-dotnet/issues/259
it looks very similar to what i'm experiencing.

I haven't had an opportunity to setup a repro, but here are some things you can try in the interim:

Upgrade Microsoft.Azure.DocumentDB package to latest version (1.19.1 as of today)
Downgrade Newtonsoft.Json to 9.0.1.

@olivertowers  We are running into a similar issue both locally and when published. We did not notice any such exceptions before, but the issues started to repro as soon as we updated the documentdb version from 1.13.2 to 1.22.0. Please let me know if we are missing anything.


fix bug: AiMessage text content is not copied when toolCalls are pres…

Issue
https://github.com/langchain4j/langchain4j/issues/986
Change
When OpenAI returns both content and tool_calls, keep them all instead of just keeping the tool_calls.
General checklist

[x] There are no breaking changes
[x] I have added unit and integration tests for my change
[x] I have manually run all the unit and integration tests in the module I have added/changed, and they are all green
[x] I have manually run all the unit and integration tests in the core and main modules, and they are all green
[x] I have added/updated the [documentation

HI @hrhrng, thank you! I wil ltry to review it asap

@Wadimz Hi, this is my first pull request, I wonder is there anything else I should do to make this request merged?

Hi @hrhrng! Congratulations on your first pull request!
You'll need workflow approval for the pipeline run and a review from one of the repository owners for this pull request. Getting a review from other contributors can help speed up the process. Typically, @langchain4j reviews the changes and merges them once they've been approved. Don't worry if it takes some time. I suggest keeping your pull request up to date with the main repository to be ready for merge when reviewed.

from

Thanks for your answer🙏.

Hi @hrhrng! Congratulations on your first pull request! You'll need workflow approval for the pipeline run and a review from one of the repository owners for this pull request. Getting a review from other contributors can help speed up the process. Typically, @langchain4j reviews the changes and merges them once they've been approved. Don't worry if it takes some time. I suggest keeping your pull request up to date with the main repository to be ready for merge when reviewed.

Thanks for your answer🙏. @Wadimz

@hrhrng thanks a lot, good job!
The same change can be applied to InternalAzureOpenAiHelper, would you like to open a PR for this? 🙏

@langchain4j 👌，I‘d like to fix it.

@hrhrng thanks a lot, good job!
The same change can be applied to InternalAzureOpenAiHelper, would you like to open a PR for this? 🙏

@langchain4j Hi, I've pull request for this issue in https://github.com/langchain4j/langchain4j/pull/1576, please have a check.


When Uploading, I experienced a crash

Loading...
(0/7) Loading siad...
(1/7) Loading gateway...
(2/7) Loading consensus...
(3/7) Loading transaction pool...
(4/7) Loading wallet...
(5/7) Loading miner...
(6/7) Loading host...
(7/7) Loading renter...
Finished loading in 32.5733132 seconds
goroutine 952 [running]:
runtime/debug.Stack(0x44433e, 0x0, 0xc042475c28)
/usr/local/go/src/runtime/debug/stack.go:24 +0x80
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x29
github.com/NebulousLabs/Sia/build.Critical(0xc042475d80, 0x2, 0x2)
/home/luke/go/src/github.com/NebulousLabs/Sia/build/critical.go:15 +0xae
github.com/NebulousLabs/Sia/persist.(*Logger).Critical(0xc0427f4100, 0xc042475d80, 0x2, 0x2)
/home/luke/go/src/github.com/NebulousLabs/Sia/persist/log.go:37 +0xe7
github.com/NebulousLabs/Sia/modules/renter.(*Renter).managedDownloadIteration(0xc0428ef440, 0xc042475f20)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/renter/download.go:320 +0x5c5
github.com/NebulousLabs/Sia/modules/renter.(*Renter).threadedDownloadLoop(0xc0428ef440)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/renter/download.go:585 +0x385
created by github.com/NebulousLabs/Sia/modules/renter.newRenter
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/renter/renter.go:208 +0x3b5
Critical error: ERROR: the renter is idle , but tracking active pieces: 2
Please submit a bug report here: https://github.com/NebulousLabs/Sia/issues
goroutine 34 [running]:
runtime/debug.Stack(0x4442be, 0x0, 0xc042469a68)
/usr/local/go/src/runtime/debug/stack.go:24 +0x80
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x29
github.com/NebulousLabs/Sia/build.Severe(0xc042469bf0, 0x2, 0x2)
/home/luke/go/src/github.com/NebulousLabs/Sia/build/critical.go:29 +0x99
github.com/NebulousLabs/Sia/persist.(*Logger).Severe(0xc0421f9160, 0xc042469bf0, 0x2, 0x2)
/home/luke/go/src/github.com/NebulousLabs/Sia/persist/log.go:71 +0xe7
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).syncResources(0xc04205a668)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:108 +0x73b
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit(0xc04205a668)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:146 +0x47
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).threadedSyncLoop(0xc04205a668, 0xc0421aade0, 0xc0421aae40)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:269 +0x149
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).spawnSyncLoop
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:216 +0x103
Severe error: ERROR: could not rename temporary write-ahead-log in contract manager: rename C:\Users\Brian\AppData\Roaming\Sia-UI\sia\host\contractmanager\contractmanager.wal_temp C:\Users\Brian\AppData\Roaming\Sia-UI\sia\host\contractmanager\contractmanager.wal: Access is denied.
panic: unable to copy-on-write the WAL temporary file, crashing to prevent data corruption
goroutine 34 [running]:
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).syncResources(0xc04205a668)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:109 +0x78b
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).commit(0xc04205a668)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:146 +0x47
github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).threadedSyncLoop(0xc04205a668, 0xc0421aade0, 0xc0421aae40)
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:269 +0x149
created by github.com/NebulousLabs/Sia/modules/host/contractmanager.(*writeAheadLog).spawnSyncLoop
/home/luke/go/src/github.com/NebulousLabs/Sia/modules/host/contractmanager/writeaheadlogsync.go:216 +0x103

This is actually the same error as #1651, should be fixed in the master branch. (RC3, which also has the fix, will be released in the next few hours).

Sweet.  Thanks David
On Tue, Apr 11, 2017 at 12:01 PM, David Vorick<EMAIL_ADDRESS>wrote:

This is actually the same error as #1651
https://github.com/NebulousLabs/Sia/issues/1651, should be fixed in the
master branch. (RC3, which also has the fix, will be released in the next
few hours).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NebulousLabs/Sia/issues/1683#issuecomment-293311010,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZrYYmeVG-DTYiAP9JQ6xIgNcOXoXoB_ks5ru6PxgaJpZM4M6S3b
.

should be fixed in v1.3.0


Fix a couple typos in the Apple module

Found them while doing reviews for cargo-crev.

r? @JohnTitor
(rust-highfive has picked a reviewer for you, use r? to override)

:pushpin: Commit 9b2808c4ea796f8767015611bdf92f6ee6bc047f has been approved by JohnTitor

:hourglass: Testing commit 9b2808c4ea796f8767015611bdf92f6ee6bc047f with merge a1d629881edb608c10c3fc07223de1377b0ee262...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing a1d629881edb608c10c3fc07223de1377b0ee262 to master...


[bounty] Add "BCHN lead maintainer report 2020-03-14" article

#66

Thanks for fixing the spacing issue.


YouTube Compliance Issues & Help

Hi there,
I got an email from YouTube stating that this is not in compliance with them due to the fact that we store data for 12 months. Can you please help me find the code so I can change it from 12 months to 30 days? The report is pasted below. I have 15 days to fix the issue or they won't remove the IP ban.
July 27, 2020
ToS Violations Report V.1 YouTube API Services-Developer Policies
Violations that require immediate resolution:
E. Handling YouTube Data and Content (l ink)
Policy #: III.E.4.a-g (Refreshing, Storing, and Displaying API Data) (link)
● Violation: API Client is storing data for more than 30 days.
Proposed Solution: Regarding data storage, we only allow the API Clients to store the public data temporarily, but not more than 30 days and the stored data must either be refreshed or deleted after 30 days
Screenshot of Youtube Email?: https://user-images.githubusercontent.com/55116398/88565399-89490f00-d002-11ea-8c5f-71ce39675cec.jpeg

I don't think this can be caused by the package. Because AFAIK for them to contact you, you require an API key from the Google API Console (I could be wrong though).
Are you using any other YouTube API packages in your app?


[BUG] Dataset is under wrong category on datasets page.

Describe your problem in detail.
This request refers to page: https://bids-website.readthedocs.io/en/latest/datasets/index.html.
The dataset  eeg_ds003645s_hed_demo is currently listed in the Microscopy category, but it doesn't have any meaningful microscopy data.
Describe what you expected.
Could we please have a category called HED --- as this dataset demonstrates the use of HED across a bids dataset including annotation of files such as participants.tsv?

good catch: I have a PR in progress to better organize the listing from the BIDS example will add this fix + feature in and will ping you for a review.

The eeg_ds003645s_hed_demo dataset does contain what appears to be microscopy and motion data so it will in any case also appear in those 2 categories:
https://github.com/bids-standard/bids-examples/tree/master/eeg_ds003645s_hed_demo/sub-004/ses-1/micr
https://github.com/bids-standard/bids-examples/tree/master/eeg_ds003645s_hed_demo/sub-004/ses-2/motion

PR #507 fixes this:

see https://bids-website--507.org.readthedocs.build/en/507/datasets/examples.html#hed


How to Write Backup Files to a Local Mount Point

Background:
Machine A: Linux, deployed Milvus instance in STANDALONE mode.
Machine A: Mounted a Windows shared directory, mount point: /mnt/win_share, with read/write access.
How to achieve: Directly write the backup files to /mnt/win_share during the backup?
What does backupStorageType="local" mean in the configuration file?
Can it be used to achieve the above requirement?

Yes, just set the backup storage type to "local". Was the backup successful? Did you encounter any other issues?

The backup of the small table (51 rows) was successful. However, backing up the entire database (several million rows) resulted in an error.
Refer to #487


Discogs - Cart

possible support cart page too ?

thanks alot!

also if there could be a Create Request that could fill in release details <3

also if there could be a Create Request that could fill in release details <3

What this means?

and also if possible to Search Artist or album name or Label , when clicking on each

I've no idea what this means too.

also if there could be a Create Request that could fill in release details <3

What this means?

Create Request on RED,

and also if possible to Search Artist or album name or Label , when clicking on each

I've no idea what this means too.

Clicking on Artist or album or Label  on discogs to take me straight to RED search instead

This script is for Discogs, not for RED.

You don't need "Cart" page support anymore?

i need , if possible, thanks!!

I don't have "these items got away" section, I added bunch of stuff to cart so maybe after month or two I'll start seeing it. :)
But maybe it's better to add support for "sell" url instead, that were it leads if you press links on those albums, and those pages looks similar to the already supported pages.

you mean here ?

Also have been coming across more :

Also is possible add option skip check if  Rating = (option to select how many stars )  or Note = ..........
just to make it a little faster when checking 250 rels per page on wantlist view
(i am using rating system to mark what exists / owned / non exist )

you mean here ?

I meant your second screen in the first post.

Also have been coming across more :

I've no idea what this means.

Also is possible add option skip check if Rating = (option to select how many stars ) or Note = .......... just to make it a little faster when checking 250 rels per page on wantlist view (i am using rating system to mark what exists / owned / non exist )

This is not related to this issue/request, open a new one.
Probably possible, dunno when I'll check it.

On discogs release has EP on site it doesnt ... maybe just dont add "EP" on search ... or add option for words not to use

Also have been coming across more :

I've no idea what this means.

hi, any progress ? :)

It's not ready for me to looked at it, yet:

I don't have "these items got away" section, I added bunch of stuff to cart so maybe after month or two I'll start seeing it.

Didn't looked at it, waiting till I can see all stuff on that page.


Add a generate random password option when creating a new user, as a replacement to putting a password in

When creating a new user,  add a "send password over email"  option

Better to send them a password reset link. that will force them to set there own password before they can use the account. And it avoid having passwords send in plain text.

Why do we have to add a password at all when creating a new user? I don't want to set or see the password. I want to create a new user, not be asked or required to put in a password, and have it send them the password reset (or ideally a create password for new account) email.

@frjo Looks like the issue is about creating users from Wagtail admin. Is it?

@Parbhat Yes it is.


Add Vocabulary as a featured project.

Problem

According to new mockups, there are three featured projects on the home page. Here's the link.
Implementation

[x] I would be interested in implementing this feature.

Made changes in PR-528

Vocabulary is now a featured project: https://opensource.creativecommons.org/contributing-code/projects/


For supporting 1.2.28,you have to change some code.

As Angular below version 1.3 doesn't support Promise
When I use Toastr in my Angular project whose angular version is 1.2.28 , I have to change some codes. I display some of them, it may help.
at line 59
   $animate.leave(toast.el, function() {
          if (toast.scope.options.onHidden) {
            toast.scope.options.onHidden(wasClicked);
          }
         ....

at line 124
$animate.enter(container, body, '', function() {
        containerDefer.resolve();
      });

at line 145
if (options.newestOnTop) {
            $animate.enter(newToast.el, container, '', function() {
              newToast.scope.init();
            });
          } else {
            $animate.enter(newToast.el, container, container[0].lastChild,function() {
              newToast.scope.init();
            });
          }

###at line

format content.

Hello, The last supported version for 1.2.x is the version 0.4.x. Since that I don't support it anymore because there are some breaking changes.
Since there is no reason to stay on 1.2.x (1.3.x doesn't have any big BC) I don't feel like I want to support two codebases at the same time.


Updating folder name to avoid duplication and confusion

Earlier there was an src folder inside an src folder. Changing name of first src folder.

LGTM.


Code made my PC instantaneously combust

My house is gone help I'm homeless

Imagine using the original version of this, your computer would become a nuke.