Failed to emerge chromeos-base/chrome-icu-96.0.4664.208_rc-r1 for /build/rpi4/, Log file:

I get the following error when executing./build_packages --board=rpi4 --nowithautotest. Can you help me

11:21:16 Failed to emerge chromeos-base/chrome-icu-96.0.4664.208_rc-r1 for /build/rpi4/, Log file:
11:21:16   /build/rpi4/tmp/portage/logs/chromeos-base:chrome-icu-96.0.4664.208_rc-r1:20230329-032107.log
11:21:16 === Start output for job chrome-icu-96.0.4664.208_rc-r1 ===
chrome-icu-96.0.4664.208_rc-r1:  * Package:    chromeos-base/chrome-icu-96.0.4664.208_rc-r1
chrome-icu-96.0.4664.208_rc-r1:  * Repository: cros-pi
chrome-icu-96.0.4664.208_rc-r1:  * USE:        arm cups elibc_glibc kernel_linux libcxx neon runhooks userland_GNU xkbcommon
chrome-icu-96.0.4664.208_rc-r1:  * FEATURES:   network-sandbox splitdebug userpriv
chrome-icu-96.0.4664.208_rc-r1:  * Running stacked hooks for pre_pkg_setup
chrome-icu-96.0.4664.208_rc-r1:  *    sysroot_build_bin_dir ...
chrome-icu-96.0.4664.208_rc-r1:  [ ok ]
chrome-icu-96.0.4664.208_rc-r1:  * Using python2.7 to build
chrome-icu-96.0.4664.208_rc-r1:  * Running stacked hooks for post_pkg_setup
chrome-icu-96.0.4664.208_rc-r1:  *    python_eclass_hack ...
chrome-icu-96.0.4664.208_rc-r1:  [ ok ]
chrome-icu-96.0.4664.208_rc-r1: 11:21:13 >>> Unpacking source...
chrome-icu-96.0.4664.208_rc-r1:  * CHROME_ORIGIN VALUE is LOCAL_SOURCE
chrome-icu-96.0.4664.208_rc-r1:  * ERROR: chromeos-base/chrome-icu-96.0.4664.208_rc-r1::cros-pi failed (unpack phase):
chrome-icu-96.0.4664.208_rc-r1:  *   /mnt/host/source/fydeos/chromium does not contain a valid chromium checkout!
chrome-icu-96.0.4664.208_rc-r1:  *
chrome-icu-96.0.4664.208_rc-r1:  * Call stack:
chrome-icu-96.0.4664.208_rc-r1:  *               ebuild.sh, line  125:  Called src_unpack
chrome-icu-96.0.4664.208_rc-r1:  *             environment, line 4455:  Called die
chrome-icu-96.0.4664.208_rc-r1:  * The specific snippet of code:
chrome-icu-96.0.4664.208_rc-r1:  *                   die "${CHROME_ROOT} does not contain a valid chromium checkout!";
chrome-icu-96.0.4664.208_rc-r1:  *
chrome-icu-96.0.4664.208_rc-r1:  * Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chrome-icu-96.0.4664.208_rc-r1:20230329-032107.log
chrome-icu-96.0.4664.208_rc-r1:  * Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chrome-icu-96.0.4664.208_rc-r1/temp/build.log
chrome-icu-96.0.4664.208_rc-r1:  * CWD: /build/rpi4/tmp/portage/chromeos-base/chrome-icu-96.0.4664.208_rc-r1/work
chrome-icu-96.0.4664.208_rc-r1:  * S:   /build/rpi4/tmp/portage/chromeos-base/chrome-icu-96.0.4664.208_rc-r1/work/chrome-icu-96.0.4664.208_rc

It looks like you are using the r96-dev branch of the code. Please remove the CHROME_ROOT line from project-cros-pi/make.conf, and then re-run cros_sdk using --chrome-root to point to the directory of the Chromium source code and enter the chroot environment. You may also want to try using the updated r102-dev or r108-dev branches.

It looks like you are using the r96-dev branch of the code.
Please remove the CHROME_ROOT line from project-cros-pi/make.conf, and then re-run cros_sdk using --chrome-root to point to the directory of the Chromium source code and enter the chroot environment.
You may also want to try using the updated r102-dev or r108-dev branches.

thank you very much, let me try

When I changed the make.conf file, I still got the following error，can you help me：

14:16:10 Failed to emerge chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1 for /build/rpi4/, Log file:
14:16:10   /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230331-061607.log
14:16:10 === Start output for job chromeos-chrome-96.0.4664.208_rc-r1 ===
chromeos-chrome-96.0.4664.208_rc-r1:  * Package:    chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1
chromeos-chrome-96.0.4664.208_rc-r1:  * Repository: cros-pi
chromeos-chrome-96.0.4664.208_rc-r1:  * USE:        accessibility afdo_use arm autotest build_tests buildcheck cfi chrome_debug chrome_media chrome_remoting cros-debug debug_fission dwarf5 elibc_glibc fonts highdpi kernel_linux libcxx nacl neon oobe_config opengles orderfile_use ozone_platform_default_gbm ozone_platform_gbm ozone_platform_headless runhooks thinlto userland_GNU xkbcommon
chromeos-chrome-96.0.4664.208_rc-r1:  * FEATURES:   network-sandbox splitdebug userpriv
chromeos-chrome-96.0.4664.208_rc-r1:  * Running stacked hooks for pre_pkg_setup
chromeos-chrome-96.0.4664.208_rc-r1:  *    sysroot_build_bin_dir ...
chromeos-chrome-96.0.4664.208_rc-r1:  [ ok ]
chromeos-chrome-96.0.4664.208_rc-r1:  * Using python2.7 to build
chromeos-chrome-96.0.4664.208_rc-r1:  * Running stacked hooks for post_pkg_setup
chromeos-chrome-96.0.4664.208_rc-r1:  *    python_eclass_hack ...
chromeos-chrome-96.0.4664.208_rc-r1:  [ ok ]
chromeos-chrome-96.0.4664.208_rc-r1: 14:16:09 >>> Unpacking source...
chromeos-chrome-96.0.4664.208_rc-r1:
chromeos-chrome-96.0.4664.208_rc-r1:  * If you want to develop or hack on the browser itself, you should follow the
chromeos-chrome-96.0.4664.208_rc-r1:  * simple chrome workflow instead of using emerge:
chromeos-chrome-96.0.4664.208_rc-r1:  * https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md
chromeos-chrome-96.0.4664.208_rc-r1:
chromeos-chrome-96.0.4664.208_rc-r1:  * Setting up CrOS credentials
chromeos-chrome-96.0.4664.208_rc-r1: '/home/ubuntu/.ssh' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/homedir/.ssh'
chromeos-chrome-96.0.4664.208_rc-r1: '/home/ubuntu/.ssh/config' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/homedir/.ssh/config'
chromeos-chrome-96.0.4664.208_rc-r1: '/home/ubuntu/.ssh/known_hosts' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/homedir/.ssh/known_hosts'
chromeos-chrome-96.0.4664.208_rc-r1: '/home/ubuntu/.ssh/config.orig' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/homedir/.ssh/config.orig'
chromeos-chrome-96.0.4664.208_rc-r1:  * CHROME_ORIGIN VALUE is LOCAL_SOURCE
chromeos-chrome-96.0.4664.208_rc-r1: Building Chromium with additional media codecs and containers.
chromeos-chrome-96.0.4664.208_rc-r1: 14:16:09 >>> Source unpacked in /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work
chromeos-chrome-96.0.4664.208_rc-r1:  * Running stacked hooks for post_src_unpack
chromeos-chrome-96.0.4664.208_rc-r1:  *    asan_init ...
chromeos-chrome-96.0.4664.208_rc-r1:  [ ok ]
chromeos-chrome-96.0.4664.208_rc-r1:  * Running stacked hooks for pre_src_prepare
chromeos-chrome-96.0.4664.208_rc-r1:  *    build_toolchain_catch ...
chromeos-chrome-96.0.4664.208_rc-r1:  [ ok ]
chromeos-chrome-96.0.4664.208_rc-r1:  *    enable_cxx_exceptions ...
chromeos-chrome-96.0.4664.208_rc-r1:  [ ok ]
chromeos-chrome-96.0.4664.208_rc-r1: 14:16:09 >>> Preparing source in /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work/chromeos-chrome-96.0.4664.208_rc ...
chromeos-chrome-96.0.4664.208_rc-r1:  * /home/ubuntu/chrome_root should be set here properly
chromeos-chrome-96.0.4664.208_rc-r1: rm: cannot remove 'c': Read-only file system
chromeos-chrome-96.0.4664.208_rc-r1:  * ERROR: chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1::cros-pi failed (prepare phase):
chromeos-chrome-96.0.4664.208_rc-r1:  *   Could not remove symlink
chromeos-chrome-96.0.4664.208_rc-r1:  *
chromeos-chrome-96.0.4664.208_rc-r1:  * Call stack:
chromeos-chrome-96.0.4664.208_rc-r1:  *               ebuild.sh, line  125:  Called src_prepare
chromeos-chrome-96.0.4664.208_rc-r1:  *             environment, line 5327:  Called die
chromeos-chrome-96.0.4664.208_rc-r1:  * The specific snippet of code:
chromeos-chrome-96.0.4664.208_rc-r1:  *           rm -rf "${BUILD_OUT_SYM}" || die "Could not remove symlink";
chromeos-chrome-96.0.4664.208_rc-r1:  *
chromeos-chrome-96.0.4664.208_rc-r1:  * Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230331-061607.log
chromeos-chrome-96.0.4664.208_rc-r1:  * Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/temp/build.log
chromeos-chrome-96.0.4664.208_rc-r1:  * CWD: /home/ubuntu/chrome_root/src
chromeos-chrome-96.0.4664.208_rc-r1:  * S:   /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work/chromeos-chrome-96.0.4664.208_rc
14:16:12 Installing (1 of 14) chromeos-base/chromeos-ssh-testkeys-0.0.1-r2::chromiumos to /build/rpi4/
14:16:16 Completed (1 of 14) chromeos-base/chromeos-ssh-testkeys-0.0.1-r2::chromiumos to /build/rpi4/
14:16:16 Jobs: 1 of 14 complete, 1 failed                Load avg: 1.81, 2.72, 3.16

Messages for package chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1 merged to /build/rpi4/:

Log file: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230331-061607.log

If you want to develop or hack on the browser itself, you should follow the

simple chrome workflow instead of using emerge:

https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md

CHROME_ORIGIN VALUE is LOCAL_SOURCE

/home/ubuntu/chrome_root should be set here properly

ERROR: chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1::cros-pi failed (prepare phase):

Could not remove symlink

Call stack:

          ebuild.sh, line  125:  Called src_prepare

        environment, line 5327:  Called die

The specific snippet of code:

      rm -rf "${BUILD_OUT_SYM}" || die "Could not remove symlink";

Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230331-061607.log

Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/temp/build.log

CWD: /home/ubuntu/chrome_root/src

S:   /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work/chromeos-chrome-96.0.4664.208_rc

It can be seen that within the chroot environment, the current user is unable to modify any content within the chromium source code directory /home/ubuntu/chrome_root/src, resulting in a compilation failure. Please check the ownership and permissions of the source code directory.

thank you very much

I have encountered a new problem, can you help me to have a look?
chromeos-chrome-96.0.4664.208_rc-r1: ninja: build stopped: subcommand failed.
chromeos-chrome-96.0.4664.208_rc-r1:  * ERROR: chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1::cros-pi failed (compile phase):
chromeos-chrome-96.0.4664.208_rc-r1:  *   (no error message)
chromeos-chrome-96.0.4664.208_rc-r1:  *
chromeos-chrome-96.0.4664.208_rc-r1:  * Call stack:
chromeos-chrome-96.0.4664.208_rc-r1:  *               ebuild.sh, line  125:  Called src_compile
chromeos-chrome-96.0.4664.208_rc-r1:  *             environment, line 5326:  Called chrome_make 'chrome' 'capture_unittests' 'dawn_end2end_tests' 'dawn_unittests' 'gl_tests' 'jpeg_decode_accelerator_unittest' 'ozone_gl_unittests' 'sandbox_linux_unittests' 'wayland_client_perftests' 'ppapi/examples/video_decode' 'bitmaptools' 'clear_system_cache' 'minidump_stackwalk' 'chromedriver' 'nacl_helper_bootstrap' 'nacl_helper'
chromeos-chrome-96.0.4664.208_rc-r1:  *             environment, line 1815:  Called die
chromeos-chrome-96.0.4664.208_rc-r1:  * The specific snippet of code:
chromeos-chrome-96.0.4664.208_rc-r1:  *       [[ "${ret}" -eq 0 ]] || die;
chromeos-chrome-96.0.4664.208_rc-r1:  *
chromeos-chrome-96.0.4664.208_rc-r1:  * Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230402-144551.log
chromeos-chrome-96.0.4664.208_rc-r1:  * Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/temp/build.log
chromeos-chrome-96.0.4664.208_rc-r1:  * CWD: /home/wwd/chrome_root/src
chromeos-chrome-96.0.4664.208_rc-r1:  * S:   /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work/chromeos-chrome-96.0.4664.208_rc

The common cause of error is forgetting to execute gclient sync in the Chromium source code root directory. Please try executing gclient sync and emerge it again.

Ok, thank you very much. I'll try it

I executed the gclient sync command, but still got the following error：
chromeos-chrome-96.0.4664.208_rc-r1: ninja: build stopped: subcommand failed.
chromeos-chrome-96.0.4664.208_rc-r1:  * ERROR: chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1::cros-pi failed (compile phase):
chromeos-chrome-96.0.4664.208_rc-r1:  *   (no error message)
chromeos-chrome-96.0.4664.208_rc-r1:  *
chromeos-chrome-96.0.4664.208_rc-r1:  * Call stack:
chromeos-chrome-96.0.4664.208_rc-r1:  *               ebuild.sh, line  125:  Called src_compile
chromeos-chrome-96.0.4664.208_rc-r1:  *             environment, line 5326:  Called chrome_make 'chrome' 'capture_unittests' 'dawn_end2end_tests' 'dawn_unittests' 'gl_tests' 'jpeg_decode_accelerator_unittest' 'ozone_gl_unittests' 'sandbox_linux_unittests' 'wayland_client_perftests' 'ppapi/examples/video_decode' 'bitmaptools' 'clear_system_cache' 'minidump_stackwalk' 'chromedriver' 'nacl_helper_bootstrap' 'nacl_helper'
chromeos-chrome-96.0.4664.208_rc-r1:  *             environment, line 1815:  Called die
chromeos-chrome-96.0.4664.208_rc-r1:  * The specific snippet of code:
chromeos-chrome-96.0.4664.208_rc-r1:  *       [[ "${ret}" -eq 0 ]] || die;
chromeos-chrome-96.0.4664.208_rc-r1:  *
chromeos-chrome-96.0.4664.208_rc-r1:  * Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230403-005955.log
chromeos-chrome-96.0.4664.208_rc-r1:  * Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/temp/build.log
chromeos-chrome-96.0.4664.208_rc-r1:  * CWD: /home/wwd/chrome_root/src
chromeos-chrome-96.0.4664.208_rc-r1:  * S:   /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work/chromeos-chrome-96.0.4664.208_rc

09:09:03 Jobs: 1 of 14 complete, 1 failed                Load avg: 14.9, 13.9, 7.1

Messages for package chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1 merged to /build/rpi4/:

Log file: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230403-005955.log

If you want to develop or hack on the browser itself, you should follow the

simple chrome workflow instead of using emerge:

https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md

CHROME_ORIGIN VALUE is LOCAL_SOURCE

/home/wwd/chrome_root should be set here properly

ERROR: chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1::cros-pi failed (compile phase):

(no error message)

Call stack:

          ebuild.sh, line  125:  Called src_compile

        environment, line 5326:  Called chrome_make 'chrome' 'capture_unittests' 'dawn_end2end_tests' 'dawn_unittests' 'gl_tests' 'jpeg_decode_accelerator_unittest' 'ozone_gl_unittests' 'sandbox_linux_unittests' 'wayland_client_perftests' 'ppapi/examples/video_decode' 'bitmaptools' 'clear_system_cache' 'minidump_stackwalk' 'chromedriver' 'nacl_helper_bootstrap' 'nacl_helper'

        environment, line 1815:  Called die

The specific snippet of code:

  [[ "${ret}" -eq 0 ]] || die;

Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-96.0.4664.208_rc-r1:20230403-005955.log

Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/temp/build.log

CWD: /home/wwd/chrome_root/src

S:   /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-96.0.4664.208_rc-r1/work/chromeos-chrome-96.0.4664.208_rc

My build environment is ubuntu18 and the python version is Python 3.8. 0. The python version in cros_sdk is python3.6.12，Is the above error related to the python version?

I have not encountered such a problem before, and I don't think it's related to the python version. Please go back to the previous steps to ensure that each step is correct, maybe you should try to start over again.

I have a question, can you help me to answer it？
In the branch r96-dev, "Git clone https://github.com/fydeos/chromium_os-raspberry_pi.git." whether you need this command to "git clone - b r96-dev https://github.com/fydeos/chromium_os-raspberry_pi.git "?

I have a question, can you help me to answer it？ In the branch r96-dev, "Git clone https://github.com/fydeos/chromium_os-raspberry_pi.git." whether you need this command to "git clone - b r96-dev https://github.com/fydeos/chromium_os-raspberry_pi.git "?

If you want to specify a branch in the git clone command, yes, you do need -b flag to tell git, otherwise it will default to the main branch. This is a basic git usage question, and it is beyond this project's scope. You need to familiarise yourself with the basics before attempting to do advanced stuff, like building Chromium OS.
As @nirocfz mentioned above, you have been using an old branch of this project, which was no longer in maintenance for quite some time. I also suggest you start over with r102-dev or r108-dev, which we released not long ago. Also, your build environment ubuntu 1804 is also quite dated, I would upgrade that as well.

If you want to specify a branch in the git clone command, yes, you do need -b flag to tell git, otherwise it will default to the main branch. This is a basic git usage question, and it is beyond this project's scope. You need to familiarise yourself with the basics before attempting to do advanced stuff, like building Chromium OS.

Thank you very much for your advice
Maybe I have a problem expressing myself，What I mean is that whichever branch corresponds to the README document uses the command "git clone https://github.com/fydeos/chromium_os-raspberry_pi.git .". Does the overlays of the main branch work with all versions of chromium os?

We don't know if the main branch of this project would work on all versions of the Chromium OS platform. At this point in time, the main branch is the bleeding edge branch we are using to submit new code for new features, and we are testing it with Chromium OS r108. If you want to use the main branch, then it's recommended to use Chromium OS repo to match it.

When I switch to the r102-dev branch, the following error still occurs, and I'm sure I executed the gclinet sync command

13:35:50 Failed to emerge chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1 for /build/rpi4/, Log file:
13:35:50   /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-102.0.5005.179_rc-r1:20230406-052617.log
13:35:50 === Start output for job chromeos-chrome-102.0.5005.179_rc-r1 ===
chromeos-chrome-102.0.5005.179_rc-r1:  * Package:    chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1
chromeos-chrome-102.0.5005.179_rc-r1:  * Repository: cros-pi
chromeos-chrome-102.0.5005.179_rc-r1:  * USE:        accessibility afdo_use arm autotest build_tests buildcheck cfi chrome_debug chrome_media chrome_remoting cros-debug debug_fission dwarf5 elibc_glibc fonts highdpi kernel_linux libcxx nacl neon oobe_config opengles orderfile_use ozone_platform_default_gbm ozone_platform_gbm ozone_platform_headless runhooks thinlto userland_GNU xkbcommon
chromeos-chrome-102.0.5005.179_rc-r1:  * FEATURES:   network-sandbox splitdebug userpriv
chromeos-chrome-102.0.5005.179_rc-r1:  * Running stacked hooks for pre_pkg_setup
chromeos-chrome-102.0.5005.179_rc-r1:  *    sysroot_build_bin_dir ...
chromeos-chrome-102.0.5005.179_rc-r1:  [ ok ]
chromeos-chrome-102.0.5005.179_rc-r1:  * Using python3.6 to build
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:18 >>> Unpacking source...
chromeos-chrome-102.0.5005.179_rc-r1:
chromeos-chrome-102.0.5005.179_rc-r1:  * If you want to develop or hack on the browser itself, you should follow the
chromeos-chrome-102.0.5005.179_rc-r1:  * simple chrome workflow instead of using emerge:
chromeos-chrome-102.0.5005.179_rc-r1:  * https://chromium.googlesource.com/chromiumos/docs/+/HEAD/simple_chrome_workflow.md
chromeos-chrome-102.0.5005.179_rc-r1:  *
chromeos-chrome-102.0.5005.179_rc-r1:  * Otherwise, if you have a Chrome checkout already present on your machine, you can
chromeos-chrome-102.0.5005.179_rc-r1:  * re-enter the cros_sdk with the --chrome-root arg and set CHROME_ORIGIN to
chromeos-chrome-102.0.5005.179_rc-r1:  * LOCAL_SOURCE. This will bypass the lengthy sync_chrome phase here.
chromeos-chrome-102.0.5005.179_rc-r1:  * Note: when using --chrome-root, the ebuild won't update or modify the Chrome checkout.
chromeos-chrome-102.0.5005.179_rc-r1:  * So make sure it's at a compatible Chrome version before proceeding.
chromeos-chrome-102.0.5005.179_rc-r1:
chromeos-chrome-102.0.5005.179_rc-r1:  * Setting up CrOS credentials
chromeos-chrome-102.0.5005.179_rc-r1: '/home/wwd/.ssh' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/homedir/.ssh'
chromeos-chrome-102.0.5005.179_rc-r1: '/home/wwd/.ssh/config' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/homedir/.ssh/config'
chromeos-chrome-102.0.5005.179_rc-r1: '/home/wwd/.ssh/known_hosts' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/homedir/.ssh/known_hosts'
chromeos-chrome-102.0.5005.179_rc-r1: '/home/wwd/.ssh/config.orig' -> '/build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/homedir/.ssh/config.orig'
chromeos-chrome-102.0.5005.179_rc-r1:  * CHROME_ORIGIN VALUE is LOCAL_SOURCE
chromeos-chrome-102.0.5005.179_rc-r1: Building Chromium with additional media codecs and containers.
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:18 >>> Source unpacked in /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/work
chromeos-chrome-102.0.5005.179_rc-r1:  * Running stacked hooks for post_src_unpack
chromeos-chrome-102.0.5005.179_rc-r1:  *    asan_init ...
chromeos-chrome-102.0.5005.179_rc-r1:  [ ok ]
chromeos-chrome-102.0.5005.179_rc-r1:  * Running stacked hooks for pre_src_prepare
chromeos-chrome-102.0.5005.179_rc-r1:  *    build_toolchain_catch ...
chromeos-chrome-102.0.5005.179_rc-r1:  [ ok ]
chromeos-chrome-102.0.5005.179_rc-r1:  *    enable_cxx_exceptions ...
chromeos-chrome-102.0.5005.179_rc-r1:  [ ok ]
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:18 >>> Preparing source in /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/work/chromeos-chrome-102.0.5005.179_rc ...
chromeos-chrome-102.0.5005.179_rc-r1:  * /home/wwd/chrome_root should be set here properly
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:18 >>> Source prepared.
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:18 >>> Configuring source in /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/work/chromeos-chrome-102.0.5005.179_rc ...
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:19  * Appending a library link instruction (-lmmal); libraries to link to should not be passed through LDFLAGS
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:19  * Appending a library link instruction (-lmmal_core); libraries to link to should not be passed through LDFLAGS
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:19  * Appending a library link instruction (-lmmal_util); libraries to link to should not be passed through LDFLAGS
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:19  * Appending a library link instruction (-lmmal_vc_client); libraries to link to should not be passed through LDFLAGS
chromeos-chrome-102.0.5005.179_rc-r1: 13:26:19  * Appending a library link instruction (-lbcm_host); libraries to link to should not be passed through LDFLAGS
chromeos-chrome-102.0.5005.179_rc-r1:  * Building with the compiler settings:
chromeos-chrome-102.0.5005.179_rc-r1:  *   CFLAGS = -pipe -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-split-dwarf-inlining -faddrsig -Wno-unknown-warning-option
chromeos-chrome-102.0.5005.179_rc-r1:  *   CXXFLAGS = -pipe -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-split-dwarf-inlining -D__google_stl_debug_vector=1 -faddrsig -Wno-unknown-warning-option -stdlib=libc++
chromeos-chrome-102.0.5005.179_rc-r1:  *   CPPFLAGS =
chromeos-chrome-102.0.5005.179_rc-r1:  *   LDFLAGS = -Wl,-O2 -Wl,--as-needed -Wl,--gc-sections -Wl,--icf=all -Wl,-mllvm -Wl,-generate-type-units -stdlib=libc++ -lmmal -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host -Wl,--no-fatal-warnings
chromeos-chrome-102.0.5005.179_rc-r1: /mnt/host/depot_tools/gclient.py runhooks --force
chromeos-chrome-102.0.5005.179_rc-r1: Hook 'vpython -vpython-spec src/.vpython -vpython-tool install' took 39.16 secs
Hook 'vpython3 -vpython-spec src/.vpython3 -vpython-tool install' took 53.89 secs
Running hooks: 100% (131/131), done.:
chromeos-chrome-102.0.5005.179_rc-r1:  * GN_ARGS = is_chromeos_device=true is_official_build=true is_debug=false  enable_pseudolocales=true use_arc_protected_media=false use_chromeos_protected_av1=false use_chromeos_protected_media=false use_iioservice=false use_v4l2_codec=false use_v4lplugin=false use_vaapi=false use_xkbcommon=true enable_remoting=true enable_nacl=true enable_hibernate=false is_cfm=false is_asan=false is_msan=false is_ubsan=false is_clang=true use_thin_lto=true use_goma_thin_lto=false is_cfi=true use_dwarf5=true enable_assistant_integration_tests=false clang_emit_debug_info_for_profiling=true use_libinput=false nss_slots_software_fallback=false is_chromeos_with_hw_details=false ozone_auto_platforms=false ozone_platform_gbm=true ozone_platform_headless=true use_system_minigbm=true use_system_libdrm=true subpixel_font_rendering_disabled=true arm_use_neon=true blink_symbol_level=1 proprietary_codecs=true use_debug_fission=true symbol_level=2 dcheck_always_on=false clang_use_default_sample_profile=true target_sysroot="/build/rpi4" system_libdir="lib" pkg_config="/build/rpi4/build/bin/pkg-config" target_os="chromeos" host_pkg_config="x86_64-pc-linux-gnu-pkg-config" clang_diagnostic_dir="/tmp/clang_crash_diagnostics" ozone_platform="gbm" target_cpu="arm" arm_float_abi="hard" arm_arch="armv8-a+crc" ffmpeg_branding="ChromeOS" chromeos_afdo_platform="atom" google_api_key="=" google_default_client_id="=" google_default_client_secret="=" cros_target_ar="llvm-ar" cros_target_cc="armv7a-cros-linux-gnueabihf-clang" cros_target_cxx="armv7a-cros-linux-gnueabihf-clang++" host_toolchain="//build/toolchain/cros:host" custom_toolchain="//build/toolchain/cros:target" v8_snapshot_toolchain="//build/toolchain/cros:v8_snapshot" cros_target_ld="armv7a-cros-linux-gnueabihf-clang++" cros_target_nm="llvm-nm" cros_target_readelf="llvm-readelf" cros_target_extra_cflags="-pipe -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-split-dwarf-inlining -faddrsig -Wno-unknown-warning-option " cros_target_extra_cppflags="" cros_target_extra_cxxflags="-pipe -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-split-dwarf-inlining -D__google_stl_debug_vector=1 -faddrsig -Wno-unknown-warning-option -stdlib=libc++ " cros_target_extra_ldflags="-Wl,-O2 -Wl,--as-needed -Wl,--gc-sections -Wl,--icf=all -Wl,-mllvm -Wl,-generate-type-units -stdlib=libc++ -lmmal -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host -Wl,--no-fatal-warnings " cros_host_cc="x86_64-pc-linux-gnu-clang -B/usr/bin" cros_host_cxx="x86_64-pc-linux-gnu-clang++ -B/usr/bin" cros_host_ar="llvm-ar" cros_host_ld="x86_64-pc-linux-gnu-clang++" cros_host_nm="llvm-nm" cros_host_readelf="llvm-readelf" cros_host_extra_cflags=" -Wno-unknown-warning-option" cros_host_extra_cxxflags=" -Wno-unknown-warning-option" cros_host_extra_cppflags="" cros_host_extra_ldflags=" --unwindlib=libgcc" cros_v8_snapshot_cc="x86_64-pc-linux-gnu-clang -B/usr/bin" cros_v8_snapshot_cxx="x86_64-pc-linux-gnu-clang++ -B/usr/bin" cros_v8_snapshot_ar="llvm-ar" cros_v8_snapshot_ld="x86_64-pc-linux-gnu-clang++" cros_v8_snapshot_nm="llvm-nm" cros_v8_snapshot_readelf="llvm-readelf" cros_v8_snapshot_extra_cflags=" -Wno-unknown-warning-option" cros_v8_snapshot_extra_cxxflags=" -Wno-unknown-warning-option" cros_v8_snapshot_extra_cppflags="" cros_v8_snapshot_extra_ldflags=" --unwindlib=libgcc"
chromeos-chrome-102.0.5005.179_rc-r1: /home/wwd/chrome_root/src/buildtools/linux64/gn gen /home/wwd/chrome_root/src/c/Release --args=is_chromeos_device=true is_official_build=true is_debug=false  enable_pseudolocales=true use_arc_protected_media=false use_chromeos_protected_av1=false use_chromeos_protected_media=false use_iioservice=false use_v4l2_codec=false use_v4lplugin=false use_vaapi=false use_xkbcommon=true enable_remoting=true enable_nacl=true enable_hibernate=false is_cfm=false is_asan=false is_msan=false is_ubsan=false is_clang=true use_thin_lto=true use_goma_thin_lto=false is_cfi=true use_dwarf5=true enable_assistant_integration_tests=false clang_emit_debug_info_for_profiling=true use_libinput=false nss_slots_software_fallback=false is_chromeos_with_hw_details=false ozone_auto_platforms=false ozone_platform_gbm=true ozone_platform_headless=true use_system_minigbm=true use_system_libdrm=true subpixel_font_rendering_disabled=true arm_use_neon=true blink_symbol_level=1 proprietary_codecs=true use_debug_fission=true symbol_level=2 dcheck_always_on=false clang_use_default_sample_profile=true target_sysroot="/build/rpi4" system_libdir="lib" pkg_config="/build/rpi4/build/bin/pkg-config" target_os="chromeos" host_pkg_config="x86_64-pc-linux-gnu-pkg-config" clang_diagnostic_dir="/tmp/clang_crash_diagnostics" ozone_platform="gbm" target_cpu="arm" arm_float_abi="hard" arm_arch="armv8-a+crc" ffmpeg_branding="ChromeOS" chromeos_afdo_platform="atom" google_api_key="=" google_default_client_id="=" google_default_client_secret="=" cros_target_ar="llvm-ar" cros_target_cc="armv7a-cros-linux-gnueabihf-clang" cros_target_cxx="armv7a-cros-linux-gnueabihf-clang++" host_toolchain="//build/toolchain/cros:host" custom_toolchain="//build/toolchain/cros:target" v8_snapshot_toolchain="//build/toolchain/cros:v8_snapshot" cros_target_ld="armv7a-cros-linux-gnueabihf-clang++" cros_target_nm="llvm-nm" cros_target_readelf="llvm-readelf" cros_target_extra_cflags="-pipe -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-split-dwarf-inlining -faddrsig -Wno-unknown-warning-option " cros_target_extra_cppflags="" cros_target_extra_cxxflags="-pipe -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ffunction-sections -fdata-sections -fno-split-dwarf-inlining -D__google_stl_debug_vector=1 -faddrsig -Wno-unknown-warning-option -stdlib=libc++ " cros_target_extra_ldflags="-Wl,-O2 -Wl,--as-needed -Wl,--gc-sections -Wl,--icf=all -Wl,-mllvm -Wl,-generate-type-units -stdlib=libc++ -lmmal -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host -Wl,--no-fatal-warnings " cros_host_cc="x86_64-pc-linux-gnu-clang -B/usr/bin" cros_host_cxx="x86_64-pc-linux-gnu-clang++ -B/usr/bin" cros_host_ar="llvm-ar" cros_host_ld="x86_64-pc-linux-gnu-clang++" cros_host_nm="llvm-nm" cros_host_readelf="llvm-readelf" cros_host_extra_cflags=" -Wno-unknown-warning-option" cros_host_extra_cxxflags=" -Wno-unknown-warning-option" cros_host_extra_cppflags="" cros_host_extra_ldflags=" --unwindlib=libgcc" cros_v8_snapshot_cc="x86_64-pc-linux-gnu-clang -B/usr/bin" cros_v8_snapshot_cxx="x86_64-pc-linux-gnu-clang++ -B/usr/bin" cros_v8_snapshot_ar="llvm-ar" cros_v8_snapshot_ld="x86_64-pc-linux-gnu-clang++" cros_v8_snapshot_nm="llvm-nm" cros_v8_snapshot_readelf="llvm-readelf" cros_v8_snapshot_extra_cflags=" -Wno-unknown-warning-option" cros_v8_snapshot_extra_cxxflags=" -Wno-unknown-warning-option" cros_v8_snapshot_extra_cppflags="" cros_v8_snapshot_extra_ldflags=" --unwindlib=libgcc" --root=/home/wwd/chrome_root/src
chromeos-chrome-102.0.5005.179_rc-r1: Done. Made 24616 targets from 3644 files in 10604ms
chromeos-chrome-102.0.5005.179_rc-r1: 13:28:17 >>> Source configured.
chromeos-chrome-102.0.5005.179_rc-r1: 13:28:18 >>> Compiling source in /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/work/chromeos-chrome-102.0.5005.179_rc ...
chromeos-chrome-102.0.5005.179_rc-r1: ninja: Entering directory `c/Release'
[2/2] LINK ./chrome
chromeos-chrome-102.0.5005.179_rc-r1: FAILED: chrome
chromeos-chrome-102.0.5005.179_rc-r1: python3 "../../../../../../../home/wwd/chrome_root/src/build/toolchain/gcc_link_wrapper.py" --output="./chrome" -- armv7a-cros-linux-gnueabihf-clang++ -L/var/cache/chromeos-chrome/chrome-src/src/out_rpi4/Release -Werror -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,--color-diagnostics -Wl,-mllvm,-instcombine-lower-dbg-declare=0 -flto=thin -Wl,--thinlto-jobs=all -Wl,--thinlto-cache-dir=thinlto-cache -Wl,--thinlto-cache-policy=cache_size=10%:cache_size_bytes=40g:cache_size_files=100000 -Wl,-mllvm,-import-instr-limit=20 -fwhole-program-vtables -march=armv8-a+crc -Wl,--no-call-graph-profile-sort --target=arm-linux-gnueabihf -no-canonical-prefixes -Wl,-O2 -Wl,--gc-sections -gsplit-dwarf -Wl,--gdb-index -Wl,-z,defs -Wl,--as-needed --sysroot=../../../../../../../build/rpi4 --rtlib=compiler-rt --unwindlib=libunwind -fsanitize=cfi-vcall -fsanitize=cfi-derived-cast -fsanitize=cfi-unrelated-cast -pie -Wl,--disable-new-dtags -Wl,--lto-O2 -Wl,--symbol-ordering-file -Wl,../../../../../../../home/wwd/chrome_root/src/chromeos/profiles/chromeos.orderfile.txt -Wl,--no-warn-symbol-ordering -Wl,-rpath=$ORIGIN -L/build/rpi4/usr/lib -Wl,-O2 -Wl,--as-needed -Wl,--gc-sections -Wl,--icf=all -Wl,-mllvm -Wl,-generate-type-units -stdlib=libc++ -lmmal -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host -Wl,--no-fatal-warnings  -o "./chrome" -Wl,--start-group @"./chrome.rsp"  -Wl,--end-group  -ldl -lpthread -lrt -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lcups -lexpat -lfontconfig -ldrm -lsync -lresolv -lxkbcommon -lgbm -levdev-cros -lgestures -lpci -lasound -lcras -lm -lz -ldbus-1 -lffi
chromeos-chrome-102.0.5005.179_rc-r1: clang++: error: unable to execute command: Killed
chromeos-chrome-102.0.5005.179_rc-r1: clang++: error: linker command failed due to signal (use -v to see invocation)
chromeos-chrome-102.0.5005.179_rc-r1: ninja: build stopped: subcommand failed.
chromeos-chrome-102.0.5005.179_rc-r1:  * ERROR: chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1::cros-pi failed (compile phase):
chromeos-chrome-102.0.5005.179_rc-r1:  *   (no error message)
chromeos-chrome-102.0.5005.179_rc-r1:  *
chromeos-chrome-102.0.5005.179_rc-r1:  * Call stack:
chromeos-chrome-102.0.5005.179_rc-r1:  *               ebuild.sh, line  125:  Called src_compile
chromeos-chrome-102.0.5005.179_rc-r1:  *             environment, line 5353:  Called chrome_make 'chrome' 'capture_unittests' 'dawn_end2end_tests' 'dawn_unittests' 'gl_tests' 'jpeg_decode_accelerator_unittest' 'ozone_gl_unittests' 'sandbox_linux_unittests' 'wayland_client_integration_tests' 'wayland_client_perftests' 'ppapi/examples/video_decode' 'bitmaptools' 'clear_system_cache' 'minidump_stackwalk' 'chromedriver' 'nacl_helper_bootstrap' 'nacl_helper'
chromeos-chrome-102.0.5005.179_rc-r1:  *             environment, line 1840:  Called die
chromeos-chrome-102.0.5005.179_rc-r1:  * The specific snippet of code:
chromeos-chrome-102.0.5005.179_rc-r1:  *       [[ "${ret}" -eq 0 ]] || die;
chromeos-chrome-102.0.5005.179_rc-r1:  *
chromeos-chrome-102.0.5005.179_rc-r1:  * Build log: /build/rpi4/tmp/portage/logs/chromeos-base:chromeos-chrome-102.0.5005.179_rc-r1:20230406-052617.log
chromeos-chrome-102.0.5005.179_rc-r1:  * Stable log symlink: /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/temp/build.log
chromeos-chrome-102.0.5005.179_rc-r1:  * CWD: /home/wwd/chrome_root/src
chromeos-chrome-102.0.5005.179_rc-r1:  * S:   /build/rpi4/tmp/portage/chromeos-base/chromeos-chrome-102.0.5005.179_rc-r1/work/chromeos-chrome-102.0.5005.179_rc
13:35:50 Jobs: 4 of 12 complete, 1 failed                Load avg: 2.24, 1.66, 1.40

It is possible that the compilation process was terminated due to insufficient system resources. You can try to find out if there is any relevant information when the error occurs by looking in /var/log/messages (or perhaps /var/log/syslog).

Thank you very much, I tried to give the virtual machine more memory. Another question I would like to ask you is whether you can directly use chromiumos system without chromium compilation

Due to memory problems on my computer, I want not building  copy of Chromium, How to operate, can help me?

thank you very much.


Secondb

What issue is this referencing?

Do these code changes work locally and have you tested that they fix the issue yourself?

[ X] yes!

Does the following command run without warnings or errors?

[ X] yes! npm run pr-checks

Have you taken a look at our contributing guidelines?

[ X] yes!

My node version matches the one suggested when running nvm use?

[ X] yes!

@allcontributors add @sdhinsa11 for code


Improve Makefile compatability (GCC 5.4, Clang 12)

Tested with GCC 5.4 & Clang 12 on Ubuntu 16.04
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang-12 --version
Ubuntu clang version 12.0.0-++20210319082646+4990141a4366-1~exp1~20210319193401.61
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Tested with:
$ make clean
$ make -j4 rebuild
$ make clean
$ make CC=clang-12 -j4 rebuild

Overall these were some small changes I had made locally, I thought I was just a weirdo running such an old Ubuntu version, but it sounds like I'm not alone! I think these changes are pretty small, so I don't think they'll cause issues with other platforms (but I'm happy to wait to check before merging).

This old version of GCC requires that static_assert(...) take a second message parameter, whereas it is optional in proper C++17.
Only pass linker flags during the linking steps, not when compiling .os. (I don't think it's harmful, but it produces warnings on clang)
Explicitly link against -libstdc++ and -lm (needed by clang, which doesn't implicitly link against them)
Removed -rdynamic, which is equivalent to -Wl,-export-dynamic but is not supported by clang. (Can we just remove this entirely? I couldn't find why this was needed... -g3 -ggdb should be enough to help with backtraces?)

This PR has a conflict!

Thanks for the reminder! Merged & tested on my Linux machine with gcc 5.4 & clang 12.


It's not working big file.

It's not working big files.(bigger than 1226 Byte)

That could be a heap issue. Are you using httpDL or http.lua?
When using httpDL, could you put in a print(node.heap()) on line 26?

no it isn't heap issue. i am using httpDL.lua and here is log. i am trying download dht11.lua and file size is 7.5kb
> 15560
16696
16824
16824
16696
19432
downloadComplete..
>for k,v in pairs(file.list()) do print(k.."   "..v.." bytes") end
init.lua   29 bytes
example.lua   433 bytes
dht11.lua   1226 bytes
>

Interesting. What does it do? Is the file just to small? Or does it crash?
On what point in the file does it stop? Can you dump the dht11.lua from the chip?

donwloaded file to small for ex: i tried wrote test.lua it have 450 lines and per line has just node.heap().
i tried download and i says finished. i saw 102 lines when i look in esp file system.

I'm still not 100% sure what the .flush Command does, as it is not properly documented in the wiki.
		if (payloadFound == true) then
			file.write(payload)
		else
			if (string.find(payload,"\r\n\r\n") ~= nil) then
				file.write(string.sub(payload,string.find(payload,"\r\n\r\n") + 4))
				payloadFound = true
			end
		end

		payload = nil
		collectgarbage()
	end)
	conn:on("disconnection", function(conn)
		conn = nil
		file.flush()
		file.close()
		callback("ok")

Could you try this?

nothing changed

Hmm, the current changelog from nodemcu-firmware says something about "fix file.read() api, take 0xFF as a regular byte, not EOF.".
 Thanks for reporting it, it's now fixed :)

Really? Did you update last code on github?

axelkoehler sent a pull request: https://github.com/Manawyrm/ESP8266-HTTP/commit/be4909ed3170acb1e294719007b47ac25ae2a7c4
Have a look at it.

Just one wrong line :)


M3-1696: configure permissions for editing linode

Type of Change

add permissions error for editing Linode

Notes
Many changes but they are similar in many ways - passing disabled state to forms

Closing in favor of #4746


Support for Allure Reporter

Hi @ASaiAnudeep,
We are using allure reporter across our org. We were exploring API test tools and found this awesome tool which seems to be quite feature-rich compared to supertest.
We need your help in using allure reporting for our POC

Hi @ASaiAnudeep
I was able to solve in following way.May be you can correct me or make it better
`const allure_reporter = {
afterSpec(spec) {
allure.attachment(
"Request :",
JSON.stringify(spec.request, null, 2),
ContentType.JSON
);
allure.attachment(
"Response :",
JSON.stringify(spec.response, null, 2),
ContentType.JSON
);
},
};
describe("AUDIT LOG", function () {
let _spec = spec();
before(async () => {
await request.setBaseUrl(process.env.QA_BASE_URI_V1);
await reporter.add(allure_reporter);
});`

Hello @SamuelVinay91 ,
The example you have provided looks good to me. Can you raise a PR to add allure example similar to https://github.com/pactumjs/pactum-examples/tree/main/reporter-mochawesome?

@SamuelVinay91 You even try this npm package from allure framework. If you are using mocha/jest/cucumberjs it can be used via cli parameter or api
https://github.com/allure-framework/allure-js

Hello @SamuelVinay91 ,
The example you have provided looks good to me. Can you raise a PR to add allure example similar to https://github.com/pactumjs/pactum-examples/tree/main/reporter-mochawesome?

Sure @ASaiAnudeep - I am happy to.

@ASaiAnudeep - Implemented the Allure report in PR #13. Please assigned the issue to me to close it.


Add a config similar to realtime.segment.flush.threshold.rows but independent of partitions consumed by server

This is a followup on the discussion in #10137
When realtime.segment.flush.threshold.rows is used, the flush threshold for the new CONSUMING segment is determined by both this value and the max partitions consumed by any server. This is not very straight forward, and rebalancing a table could cause new consuming segment size to change.
In order to tackle this problem, we may add a new config (proposing realtime.segment.flush.threshold.segment.rows) which works independent of partitions consumed.

@Jackie-Jiang Can you please assign this to me? Thanks!

@suyashpatel98  are you still working on this task? if not, I would like to take up this issue.

@karthi07 Please take up the issue. I am slightly busy - I will find something else to do when I find time.


Comptability with DuckDB

[ ] Add option when generating the directory tree, to add names : id=<...>, var=<...> (see Hive Partitioning )

See #41


HTML parser does not preserve case of node attributes

When a node gets parsed by lona.html.HTML all node attributes get converted to lower-case.
>>> HTML('<svg preserveAspectRatio=1></svg>')
<svg data-lona-node-id="4" preserveaspectratio="1"></svg>

For HTML, this is fine, but becomes a problem when case-sensitivity is important, for example when rendering SVG nodes.
This issue was uncovered by @markusgritsch in #382

Fixed with PR https://github.com/lona-web-org/lona/pull/380


Single Module Demo Cannot Run

java.lang.IllegalStateException: Could not create domain object 'maven' (MavenPublication)

when I apply plugin to other project, same error occurs
plugins {
    signing
    id("maven-publish")
    id("org.jetbrains.kotlin.jvm") version "1.9.23"
    id("com.tddworks.central-portal-publisher") version "0.0.4"
}

sonatypePortalPublisher {
    authentication {
        username = "xxx"
        password = "xxx"
    }
    settings {
        autoPublish = false
        aggregation = true
    }
}

Fixed and please update to latest version. 0.0.5


Hive MetaStore cannot be replaced successfully

Hive MetaStore cannot be replaced successfully

thanks for your issue, we have updated the install.sh to adapt more envs and now it is ok you can try it now

This issue has been fixed


Version number confusion

Is this project versioned along with the compiler, the SDK, the runtime, the muxer, the CLI tools, or the Linux kernel? It's very confusing—there should be additional documentation about the versioning.
Also we should switch it all over to semantic versioning because reasons.

No, it's not.

😂

IhartSEMVERftwHashtagAlldaybabyAF


Split log output into groups for better readability

Context
Currently, the logs coming from v2.0-alpha versions of the action are borderline unreadable -- there's just too much information. This makes it very difficult to trace down build errors.
Suggested solution
GHA supports line grouping: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#grouping-log-lines
Instead of printing 7000 unseparated lines, they could be separated into logical groups, perhaps one for each step of the process. That way you can more easily inspect different sections of the log.
Considered alternatives
Additional details

Hi @Tyrrrz and thank you for your suggestion.
I agree the logs are a hard to read. They can also still be useful, as most of the time you'd be searching for "error" in the log as a whole. I would consider this a potential blocker for splitting up the logs too much.
That said; ideally we could definitely split between activate, build and return license steps. This would mean that we have 6900 lines in the build step, which is not helping your cause.
What would you suggest we do to split the output from unity editor itself? Do you have any experience utilising the line grouping effectively? Would love to hear some more ideas on how to implement this well.
Maybe there are also alternatives to consider, like creating a better summary at the end somehow.

Hey @webbertakken
I haven't had the experience of utilizing line grouping myself. Looking at the log, I'm thinking maybe the following separation would make sense:

Pull Docker image
Activate license
Restore packages
Import assets (this one spans thousands of lines)
Compile scripts (for some reason after this it starts importing assets all over again)
Build artifacts (this yet again starts importing assets)

The biggest issue currently is that it's very hard to tell where one logical step ends and another one starts. Also, some steps like "importing assets" produce a lot of logs, which by themselves are not useful in any way, so it would really be nice if they were collapsible. All of this makes it difficult to find errors, as they are often somewhere in the middle, requiring you to sift through a sea of unrelated information.

Yea we need to call in the smart people. 👩🔬👨🔬
@GabLeRoux, @mob-sakai any ideas how we could implement this?

We can easily create a group for the first step by wrapping the Docker build in index.js:
    core.startGroup('Preparing Docker image....');
    const builtImage = await Docker.build({ path: actionFolder, dockerfile, baseImage });
    core.endGroup()
    await Docker.run(builtImage, { workspace, ...buildParameters });

Then I think we could add the echo "::group::my title" echo "::endgroup::" at the start and end of each of the activate.sh, build.sh, and return_license.sh.
The problem is that steps 3-6 are all internal to the unity editor, so I don't know how we could split that up into groups. Hopefully the others may have some more ideas.

Hmm, I didn't realize they were internal to the editor, my bad.
I don't suppose Unity's CLI has some sort of "verbosity" parameter?
Another (wild) idea: reroute Unity's logs to a file (using -logFile option) and when/if the build fails, print only the last 100 lines to the console.

There are some other flags we might be able to use for better readability.
We could add the -stackTraceLogType full flag and argument.
There's an undocumented -cleanedLogFile flag, which can be used together with -logFile. The former used to support only files (and not stdout), but it might have been fixed since.

For more refined controls of stackTraceLogType you can use this in your project :
#if UNITY_EDITOR
using UnityEditor;
using UnityEditor.Build;
using UnityEditor.Build.Reporting;
using UnityEngine;

class OnBuild : IPreprocessBuildWithReport
{
    public void OnPreprocessBuild(BuildReport report) {
        // EditorUserBuildSettings.androidCreateSymbolsZip = true;
        Application.SetStackTraceLogType(LogType.Log, StackTraceLogType.None);
        Application.SetStackTraceLogType(LogType.Warning, StackTraceLogType.ScriptOnly);
        Application.SetStackTraceLogType(LogType.Error, StackTraceLogType.ScriptOnly);
    }
}
#endif

It will then remove stacktraces from Debug.Log but keep shorter ones for other types.

This should become part of the CLI (nice to have).
I'm adding this to the Roadmap to v3.0.0.


Django-Oscar 1.5

I forked this and got it working on Django-Oscar 1.5.

@mykljohn Ok, I want help you if you will work wit it.

@mykljohn We need very work in this, because is not working now, and many things was deprecated.

I haven't tested it completely, but I have it working on Django 1.8.18 and Python 2.7

It doesn't works with django 1.11 and oscar 1.6, i can't get the option in dashboard menu.

Sorry, I should have specified the version of Django.  I don't have time to play with 1.11 right now.  I had trouble upgrading some others to 1.10.  :(

which one?

@mykljohn Thank you!

@SalahAdDin Hey sorry, just saw your post.  I had trouble with django-oscar-stores, django-oscar-approval, django-oscar-accounts, django-oscar-blog and django-oscar-news.  I got stores working in oscar 1.5 (along with bundles, accounts, paypal, portation)  but only with django 1.8/python 2.7.   I've had no luck getting approval working.  And I haven't had time to try Blog or News.  I'm testing the Support changes you made in django 1.11/Python 3.4 right now.

If you have all tracebacks you can send to me.

@SalahAdDin I've got Approval just about finished.  I'll send you the changes when I have it done.  I would like to get blog/News working but they're not a priority.  I got stores working well and integrated it with Partners.  Here's what the screens look like.

I have an issue maybe you can help me with/point in the right direction.  I want to replace the Bootstrap datetimepicker with bootstrap datepicker.  The main reason for this is because with bs datepicker I can disable certain dates and days of week.  Oscar calls ui.js to handle the ajax calls and I can't get it working :(

@mykljohn I think will be better change these dates and weeks in the forms validation and rendering.
Replace datepicker could be hard, you have to change it in the oscar staticfiles.

@SalahAdDin Does your fork work with Django 1.11 and Oscar 1.5?

@alexphelps, yes, test it

@SalahAdDin got your fork up and running. getting missing file_ argument in get_thumbnail() errors on the console each time I try to view a ticket though the ticket still loads.
As for how it fits into our needs...
It's a good start, the ticket model probably covers all we need. However, I think we'll want to:

Add a tickets list view with search (something like orders list view). How can tickets be searched today?
Add a "my assigned tickets" list view, the left column tickets seems overly complicated and not useful if there are a few hundred tickets flying around.
Add email notifications for new tickets, ticket assignments, and public replies
Add inbound email support, use something like Spark Post Relay

Do you think any of this is applicable to the public project?

If you want help us with these, please, all PR are welcome.

@SalahAdDin At this point we've decided to not move forward with the original django-oscar-support module. We've decided to start over with a fresh approach and a much simpler frontend (less js magic) . Here are some frontend mockups for what we are working on implementing on the backend - http://prime-dashboard-mockup.s3-website-us-east-1.amazonaws.com/support/tickets-detail.html
I'm also unsure if we will ever publish this as a stand alone package.

@alexphelps Man?


Failing building the kernel

Hey,
I'm having the following problem when I try to execute make qemu:
RUSTFLAGS="-C link-arg=-Tsrc/bsp/raspberrypi/link.ld -C target-cpu=cortex-a53 -D warnings -D missing_docs" cargo rustc --target=aarch64-unknown-none-softfloat --features bsp_rpi3 --release
    Finished release [optimized] target(s) in 0.07s
Failed to execute tool: objcopy
No such file or directory (os error 2)
Makefile:62: recipe for target 'kernel8.img' failed
make: *** [kernel8.img] Error 101

I have no clue of what is wrong, I tried looking it up but can't find a fix. The objcopy command also works fine in the terminal. I'm running the following configuration by the way:
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/aurelien/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-2019-12-20-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

installed targets for active toolchain
--------------------------------------

aarch64-unknown-linux-gnu
aarch64-unknown-none-softfloat
x86_64-unknown-linux-gnu

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.45.0-nightly (4bd32c980 2020-05-29)

Do I need to do something with the docker files? Thanks in advance :)

From the error message I can at the moment not conclude what exactly is missing.
If it is the rust-objcopy you may have missed this step:
cargo install cargo-binutils

I have already installed the cargo-binutils:
    Updating crates.io index
     Ignored package `cargo-binutils v0.3.0` is already installed, use --force to override

The strange thing is that the rust-objcopy commands gives me this error in the terminal:
Failed to execute tool: objcopy
No such file or directory (os error 2)

But objcopy works just fine.

Hmm maybe just  something with your rustup state went bogus.
Can you try a rm -rf ~/.rustup ~/.cargo and install from scratch?

I have the same problem.
rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/alex/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-2020-05-04-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

installed targets for active toolchain
--------------------------------------

aarch64-unknown-none-softfloat
x86_64-unknown-linux-gnu

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.45.0-nightly (4bd32c980 2020-05-29)

I did a --force with my install.
cargo install cargo-binutils --force

The make qemu target in 01_wait_forever fails for me:
make qemu
RUSTFLAGS="-C link-arg=-Tsrc/bsp/raspberrypi/link.ld -C target-cpu=cortex-a53 -D warnings -D missing_docs" cargo rustc --target=aarch64-unknown-none-softfloat --features bsp_rpi3 --release
    Finished release [optimized] target(s) in 0.00s
Failed to execute tool: objcopy
No such file or directory (os error 2)
make: *** [Makefile:62: kernel8.img] Error 101

Found the source of my problem.
I went to the cargo-binutils README, and they have an added step for install:
$ cargo install cargo-binutils

$ rustup component add llvm-tools-preview

I ran rustup component add llvm-tools-preview and it works for me now.  Does this solve your problem @aurelien-m ?

I think the llvm-tools-preview component is added during this command:
curl https://sh.rustup.rs -sSf | sh -s --  \
    --default-toolchain nightly-2020-05-04 \
    --component llvm-tools-preview rustfmt

However, I did a full reinstall with rustup self uninstall, did all of the commands and now I get this:
RUSTFLAGS="-C link-arg=-Tsrc/bsp/raspberrypi/link.ld -C target-cpu=cortex-a53 -D warnings -D missing_docs" cargo rustc --target=aarch64-unknown-none-softfloat --features bsp_rpi3 --release
/bin/sh: 1: cargo: not found
Makefile:59: recipe for target 'target/aarch64-unknown-none-softfloat/release/kernel' failed
make: *** [target/aarch64-unknown-none-softfloat/release/kernel] Error 127

The kernel8.img has still been built though.

Well, I did not read the instructions carefully enough, whoops!
This error: /bin/sh: 1: cargo: not found looks like it is not in the path, did you run source $HOME/.cargo/env after the reinstall?

Yep, I've done that, I can launch the cargo command perfectly fine in my terminal.

I’ll try a from-scratch install later tonight with the Instructions I’ve put on the main repo readme and see if I hit this too.
I didn’t expect any regressions since the CI nightlys build fine.

Hi,
these steps worked for me:

Open Terminal.
rm -rf ~/.rustup ~/.cargo
Close and open Terminal again.
curl https://sh.rustup.rs -sSf | sh -s --  --default-toolchain nightly-2020-05-04 --component llvm-tools-preview rustfmt
Close and open Terminal again.
rustup target add aarch64-unknown-none-softfloat
cargo install cargo-binutils

01_wait_forever [master] $ make
RUSTFLAGS="-C link-arg=-Tsrc/bsp/raspberrypi/link.ld -C target-cpu=cortex-a53 -D warnings -D missing_docs" cargo rustc --target=aarch64-unknown-none-softfloat --features bsp_rpi3 --release
    Finished release [optimized] target(s) in 0.10s

This is basically the top level README with some additional terminal close/open mumbo jumbo to be extra sure the ENV is in correct state.
In summary, it works for me and @newAM locally, and it works on the CI nightly builds. Strong indications that it is something local on your machine.

Thanks for the help, I did exactly that, and the make works perfectly. However when I do a make qemu I get this:
RUSTFLAGS="-C link-arg=-Tsrc/bsp/raspberrypi/link.ld -C target-cpu=cortex-a53 -D warnings -D missing_docs" cargo rustc --target=aarch64-unknown-none-softfloat --features bsp_rpi3 --release
    Finished release [optimized] target(s) in 0.06s
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
Makefile:72: recipe for target 'qemu' failed
make: *** [qemu] Error 126

What I tried is sudo make qemu which brings me to the error I had before:
RUSTFLAGS="-C link-arg=-Tsrc/bsp/raspberrypi/link.ld -C target-cpu=cortex-a53 -D warnings -D missing_docs" cargo rustc --target=aarch64-unknown-none-softfloat --features bsp_rpi3 --release
/bin/sh: 1: cargo: not found
Makefile:59: recipe for target 'target/aarch64-unknown-none-softfloat/release/kernel' failed
make: *** [target/aarch64-unknown-none-softfloat/release/kernel] Error 127

Finally, what works for me is changing the Makefile and adding sudo right here and launching it with make qemu:
DOCKER_CMD           = sudo docker run -it --rm -v $(shell pwd):/work/tutorial -w /work/tutorial

This is kind of strange, if you have time to check, what version of docker do you use? Hope this will maybe also help others.

Maybe your user is not in the docker group: https://docs.docker.com/engine/install/linux-postinstall/

Found the source of my problem.
I went to the cargo-binutils README, and they have an added step for install:
$ cargo install cargo-binutils

$ rustup component add llvm-tools-preview

I ran rustup component add llvm-tools-preview and it works for me now. Does this solve your problem @aurelien-m ?

thank you. I have same problem. fixed with this solution.

Just commenting.
I also ran into this issue, and also solved it via the same hack Aurelien used, adding a sudo to the Makefile.
me@pop-os:~/projects/rust-raspberrypi-OS-tutorials/01_wait_forever$ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Unless I'm completely wrong, I'm fairly sure I've added the docker usergroup correctly, and applied it to my Linux user.
Very perplexed about the root cause of this issue.


Emergency downtime popup

We need something that pops up and tell people our data wont work whenever theres a universalis outage.

Little confused about the implementation here.
Where are the messages stored?
Do we need an api to hit every time we open the app?


[Feature Request] track file movement thru folders to prevent needless reuploading

I propose that rclone track files as they move in and out of folders rather than deleting the file and then reuploading.
An illustrative example.
/main/Directory-1/Large-File.mp4
From whatever OS interface you prefer, move Large-File.mp4 to Directory-2/
$ mv /main/Directory-1/Large-File.mp4 /main/Directory-2/
$ rclone sync /main/ gdrive:/main/ (or something like that)

Currently this causes rclone to delete the file from gdrive:/main/Directory-1 and then reupload the same file (unchanged) to gdrive:/main/Directory-2 when really all that needs to happen is to simply "move" it.  The result is quite a bit of extra wasted upload bandwidth.
How could this be done?
When a sync command is initiated, rclone should firstly determine which files are changing and then determine if any of the files are simply moving rather than completely missing. A file match can be determined either by filename and/or md5 hash, etc, or I'm sure some better more briliant method to be listed below. If the set criteria matches, then instead of deleting/reuploading, rclone just issues a move command within the service in play.

Nice idea!

+1 Sounds like a solid improvement.

I've been trying to figure out how to do this. I'm not a coder by trade but I have coded in the past - php, C++, java. Can anyone give me a point of reference to start? I'd like to try to contribute but doesn't seem like this might be a great first "let's code in go" foray.

@jschwalbe This would involve tweaking the sync engine in fs/sync.go.  I'd control this with an additional flag - --track-renames say.
If this flag was set, in run() I'd make sure both source and destination were traversed first (like the deleteBefore option).  Once traversed I'd do a separate phase doing the renames, adjusting the destination map on successful rename, then carry on doing the sync as usual.  This would need a unit test or two as I try to keep the core syncing routines fully covered.
Not the easiest first project, but it is of relatively narrow scope so not too bad.
Note: not all the remotes can do a server side rename (or a server side copy + delete) so you probably would want to ignore this option on those remotes as the move primitive would download and upload the file which would be less efficient than just uploading the new one.
If you want to spend a bit of time studying go then the go tour is an excellent place to start.

@ncw thanks for the guidance (and the great app)! What seemed like what would be a fairly simple task has become quite complicated for a newbie. I've spent probably 3-4 hours just trying to wrap my head around this project and I think it's safe to say that this is out of my league. :)
Here's the logic I can come up with:

add a --track-renames flag handler
within sync, run() will need to generate a list of src files and hash them
then we'd need to generate a list of files that are flagged to be deleted and get the hash for those
compare the two lists and if a hash/filesize/etc matches, then add it to a pair list
for each pair, skip the delete for that file and skip the upload for the matching file, and instead issue a move command

That's about as far as I can take this though. Happy to provide debugging support in the process though.

@jschwalbe no worries!  There are some easier issues if you want to help with something else.  Take a look through https://github.com/ncw/rclone/milestone/22 and see if anything catches your eye - or any other issue!

nice. looking forward to this.

I can take a stab on implementing a PR for this.
I have just uploaded my Lightroom RAW files collection to Google Drive, and I notice that most of the files badly needs better names ...

@bep that would be great!
This will involve adjusting fs/sync.go which is quite intricate, but it is fully tested.
What I'd do is make sure that the source map and dest map get loaded into memory in the run method (which will make it incompatible with --no-traverse - you want to follow the --delete-before code path).  When both maps are loaded then do the rename detection in a separate pass, removing things from the src and dst map when you do a successful rename.  Then fall through into the sync/copy/move proper.
The actual moves you want to do with the Move function.  This will fall back to download/upload if the remote doesn't implement Move or Copy which isn't ideal so if the remote doesn't support Move or Copy you probably want to ignore the --track-rename flag completely.

Thanks for the tips -- I think I now understand the implementation, I may have some challenges writing tests for this, but I think I will just get it working first.

@bep let me know if you need any more pointers. Nick

https://github.com/ncw/rclone/pull/963

Please find a beta with this in here: http://beta.rclone.org/v1.35-07-gf1221b5/ (uploaded in 15-30 mins)

Did a working version of this feature make it into 1.36? I'm getting ignoring --track-renames as the source and destination do not have a common hash, and with a -v I see that it's reuploading and deleting instead of doing a move. Source system is Windows Server 2016 on a REFS volume. Remote is either of ACD or Google Drive run through crypt. According to the table, both ACD and Google Drive support Move and DirMove.

@Techrocket9 yes this made it into the release.  Unfortunately crypt doesn't support hashes :-(

@ncw Could you elaborate on this? Does --track-renames not work with encrypted remotes? If so, what is the limitation with hash support?
Thanks!

@olanmatt yes that is correct, --track-renames doesn't work with encrypted remotes :-(

So Dropbox has encrypted remotes right? Sorry for not knowing.. but it seems track-rename isn't working on Dropbox so I assume it does

Hi, any chance to make --track-renames work with encrypted remotes?

Hi, any chance to make --track-renames work with encrypted remotes?

This could be done using the same mechanism that cryptcheck uses, so using the hash(encrypted_file).  To calculate this for a local file rclone has to download the nonce from the remote file, then encrypt the local file with the nonce and hash it on the fly.  This would work for --track-renames purpose.
If you please make a new issue on github about this then I'll take a look!

Done, thx

@Bazzu85 Linking to issues is harddd... #2721.

@Bazzu85 Linking to issues is harddd... #2721.

??


Java: Implement API changes necessary for 03-SimpleRag V1 sample to execute as expected

Implement the necessary changes in the Semantic Kernel for Java API to allow the 03-SimpleRag sample to run as expected.
This is preliminary implementation and can be either a "hack" placed in the SK V1 Proposal repo itself or can be part of our work on the Semantic Kernel for Java - V1 branch, whichever makes the most sense.
Our intention is to get all of the samples (01..06) working, then reassess the state of the Semantic Kernel for Java API to build out a production-worthy v1.

Not implementing these for V1


Create example page for team content and add dummy profiles

Purpose

To create a template page to display a set of profiles

Goals

This can be used on page sections where we need to show a team/profiles
Ex: Team page, Alumni page,IRC Researchers etc.

Approach

Created dummy data file using JSON.
Used Mustache.js to load content to the template.

Security checks

Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? YES

Related PRs
PR #256
Test environment

Ubuntu 19.04, Google Chrome

Learning

N/A

Thanks @Piumal1999 !

#273


Module not found in Next13

Node v18.12.1
Next v13.3.0
pnpm v 8.1.1
segment.ts is poisoned with client-only
Segment.tsx is a client component
warn  -<EMAIL_ADDRESS>Module not found: Can't resolve 'encoding' in<EMAIL_ADDRESS>
Import trace for requested module:
<EMAIL_ADDRESS>./node_modules/.pnpm/@segment+analytics-next<EMAIL_ADDRESS>./node_modules/.pnpm/@segment+analytics-next<EMAIL_ADDRESS>./node_modules/.pnpm/@segment+analytics-next<EMAIL_ADDRESS>./utils/segment.ts
./app/Segment.tsx

Can you show me your code. What module are you trying to import?

Sorry, dunno why I didn't include it to begin with.
// segment.ts
import { AnalyticsBrowser } from '@segment/analytics-next'

import 'client-only'

const segment = AnalyticsBrowser.load({
  writeKey: process.env.NEXT_PUBLIC_SEGMENT_WRITE_KEY as string,
})

export default segment

// Segment.tsx
'use client'

import '@/utils/segment'

export default function Segment() {
  return null
}

FYI: all these node dependencies are  getting deleted from this package in around a month.

Has this been fixed?


Rust 2018

Addresses #36

Pull Request Test Coverage Report for Build 68

0 of 4 (0.0%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage remained the same at 46.39%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/config.rs
0
1
0.0%

src/ssh.rs
0
3
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/main.rs
3
0.0%

Totals

Change from base Build 66:
0.0%

Covered Lines:
257

Relevant Lines:
554

💛  - Coveralls


System Configuration

Is there a plan for adding system configurations like backups to the terraform module?
I want to be able to setup my fleet of artifactory clusters using terraform.
I was not able to find how can I achieve configs like backups.
I know I can do that through PATCH calls as described in Artifactory YAML Configurations, but using terraform is the standard way in my case.

I would very much appreciate that as well.
We solved it for now by the use of the shell provider by scott winkler and simple parameterizable shell scripts which patch the config. It's not perfect but everything is in Code so good enough until it's officially supported.

Good idea - I will pass this along


removing local airflow from sidebar and adding a warning at the top

Checklist

[x] Links to related issues (if applicable)
[x] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.

relevant community slack post:
https://datahubspace.slack.com/archives/C029A3M079U/p1674826074412909
Hiding doc from sidebar, adding warning at top

One minor nit - Please change sidebar name to be Airflow instead of Airflow Integration


Challenge http://www.freecodecamp.com/challenges/waypoint-line-up-form-elements-responsively-with-bootstrap has an issue

Now let's get your form input and your submission button on the same line. We'll do this the same way we have previously: by using a "row" element with "col-xs-*" elements withing it.
"withing" should be corrected to "within"

I can not find this, not on the website nor in the staging branch. I think it'd be safe to close this issue.

@LumenTeun Thanks!


Error 102 on model entry  405 not allowed

Describe your problem
I am adding a model per instructions at https://ragflow.io/docs/v0.12.0/ and getting an error.

didn't add port in settings.


BUG: remove array item inside object seems buggy

Problem:

When inside an object, array item can't be removed.
Clicking on item index will create new array item.

Could not be reproduced, possible fixed by removing the input next to the add item button

@beyond2void did you manage to reproduce it?

@beyond2void did you manage to reproduce it?

I tested, this issue doesn't exit any more.
I think we can close this issue.


Add VirtualBox 5 support

Some improvements to make boot2docker more compatible with VirtualBox 5.
There's still some issues, e.g. that you have to create the exact expected host-only network yourself to make boot2docker-cli pick it up without issues.
But at least this allowed me to bootstrap a boot2docker VM on Windows 10 with VirtualBox 5 (VBox4 doesn't work very well on Windows 10, specifically no host-only networks).
I don't think this a PR ready for merging right away. I've never wrote any go before and didn't set up a proper dev environment either. I just did the minimum steps to get a boot2docker VM up and running. But I figured I might still submit this, maybe there's something useful for you in here.
PS: I know you consider boot2docker-cli deprecated, but docker-machine has the same issues with VirtualBox 5 and its dev environment requires to have docker already running, which was a hen and egg problem for me.

Note that the VM this currently creates has 8 CPUs and 2048 MiB base memory, both of which are probably a bit excessive.
It also only allocates 8 MiB of video memory, while VirtualBox complains that it needs at least 12.

This fixed VBox 5 issues for me. Thanks for this PR!

See GH comments
Squash commits and sign it off see this

I've added some notes.

Did it also create a VM with the maximum available CPUs and huge memory requirements for you?

Something's not right yet. I regularly have VMs which error out during boot and right now, I can't manage to have the docker client connect into the VM anymore.
An error occurred trying to connect: Get https://<IP_ADDRESS>:2376/v1.19/containers/json: dial tcp <IP_ADDRESS>:2376: ConnectEx tcp: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

It stopped mounting the user directory as a shared folder (even though there's no error and it's not aborting when running boot2docker-cli). I suspect that's part of the problem. I'm getting lots of errors during boot now, for example:
sysctl: cannot stat /proc/sys/net/ipv6/conf/all/forwarding: No such file or directory
sysctl: setting key "cannot stat %s": No such file or directory
sysctl: "cannot stat %s" is an unknown key
sysctl: setting key "cannot stat %s": No such file or directory
Segmentation fault

and
Calling ioctl() to re-read partition table
partprobe: error while loading shared libraries: libdevmapper.so.1.02: cannot open shared object file: No such file or directory

and
[[1;32mSetting hostname to [[1;35mboot2docker[[0;39m [[1;32mDone.[[0;39m
mv: can't rename '/usr/local/etc/ssh/ssh_config.example': No such file or directory
mv: can't rename '/usr/local/etc/ssh/sshd_config.example': No such file or directory
grep: /usr/local/etc/ssh/sshd_config: No such file or directory

The cause of my connection problems was local routes and is now fixed.
The above errors (including the segfault) do still occur in the boot2docker VM. Not sure if that's VBox5-specific or if they are normal to occur in 1.7.0 (but segfaulting always feels wrong).

I'll give it another go to try - sorry for the delay!

Now I'm having my shared folders syncing incompletely (symptom: a simple text file opens fine with vi inside the boot2docker VM, but the last 20 characters are missing when reading the same file with cat), so this is definitely not ready for primetime yet.


Helm configuration->version data type is Integer

Hi,
A couple of remarks:

At the moment the plugin requires mandatory parameter <version> to be of Integer type.
This makes it infeasible to use project's version ${project.version} which, in the majority of cases, is not an Integer.
Would it be possible to change the required type to String?

            <plugin>
                <groupId>org.microbean</groupId>
                <artifactId>helm-maven-plugin</artifactId>
                <configuration>
                    <version>1</version>
                    <releaseName>${project.artifactId}</releaseName>
                    <chartUrl>file:${project.basedir}/src/helm</chartUrl>
                </configuration>
            </plugin>

Helm-maven parameter <releaseName> is mandatory whereas for helm install it is optional.
Seems that the namespace parameter is not respected and the project gets deployed to the default namespace when I run helm:install:

            <plugin>
                <groupId>org.microbean</groupId>
                <artifactId>helm-maven-plugin</artifactId>
                <configuration>
                    <version>1</version>
                    <releaseName>${project.artifactId}</releaseName>
                    <chartUrl>file:${project.basedir}/src/helm</chartUrl>
                    <namespace>lalala</namespace>
                </configuration>
            </plugin>

Hi; thanks for your input.
Regarding point number one, I can't change version to string, because the generated gRPC code accepts only an integer: https://microbean.github.io/microbean-helm/apidocs/hapi/services/tiller/Tiller.GetReleaseStatusRequestOrBuilder.html#getVersion--
Regarding point number two, I'm not sure I understand what you're saying.  Indeed, releaseName is an optional parameter for the install mojo, just as it is for helm install.  That's by design.  There are other mojos for which it is required.  For example, the status mojo needs a release name so it knows what release you want a status for: https://microbean.github.io/helm-maven-plugin/status-mojo.html#releaseName
Regarding point number three, there's no namespace parameter for the install mojo: https://microbean.github.io/helm-maven-plugin/install-mojo.html  You probably want releaseNamespace.

Thanks for the response. You made the things much clearer to me. I will play with the plugin for the next couple of days. I think my confusion is caused by the lack of general knowledge of how a maven (plugin) configuration works.
The user guide demonstrates how to attach a Helm goal-specific configuration to a specific maven phase. For this, the configuration tag is nested within an execution tag. Since this is a goal-specific configuration, releaseName can be left out for specific operations, e.g. install.
I would like to use helm:* goals on their own. For that, I configure the plugin outside the executions tag. I believe the configuration then becomes 'global'.
For example, the configuration then requires releaseName parameter. Presumably, because while the tag is optional for install, it is mandatory for status.  But when I specify releaseName to satisfy the requirement for the status goal, then I can no longer 'unset' the value for the install goal and let it generate its own release name.

I see.  While a full Maven tutorial is beyond the scope of this issue 😄 I can say that there are certain helm-maven-plugin goals that do need a releaseName and others that don't.
With Maven plugin configuration, you can, of course, add any element you want (like <fred>barney</fred>) and things won't break.  So when you do something like, say, helm list (or the matching goal), any <releaseName> element is simply ignored.
To do what you're trying to do for all possible helm-maven-plugin goals is probably more difficult than simply including the proper Maven plugin configuration in each submodule.  That is, you would have to include enough configuration gunk to supply values for not just the install mojo, but the update, list, test, status, etc. mojos, and they all take slightly different parameters.
I highly recommend looking at Maven's guide to configuring plugins, bearing in mind that each "verb" in my plugin (in any Maven plugin) is a "mojo", and fundamentally a Java object that gets created and then has its "setters" called on it with values supplied from the XML configuration.  Finally, the documentation for the helm-maven-plugin can be found here: https://microbean.github.io/helm-maven-plugin/plugin-info.html  Good luck.

Thanks. Well, it just didn't feel 'right' from my maven experience that those few parameters we mandatory in the configuration even though they are required only by a subset of the goals.

They're…not.  That is, they're mandatory for the goals for which they…have to be mandatory.
Let's take an example.  helm list doesn't need a release name or a version, because you're listing releases.  Consequently the list mojo doesn't require a release name or a version.
Here's another example.  helm update doesn't need a, because you're updating the latest version of a release by definition, but it does need a release name because otherwise how would you know what release to update?  The same things are true of the update mojo.
Another one.  helm install can't take a version and doesn't need a release name.  If you do supply a release name, that's fine, but otherwise one is generated for you.  The install mojo follows suit.
Do you see how each goal (and matching helm command) has a different permitted configuration, and how some of those items are required, and some are not?
To my eyes, only the content, rollback and status mojos require both a release name and a version (which makes sense, since they need to know specifically what they should be looking at).

Thank you, I understand and agree with you that this is the case when the configuration is nested under the execution tag as per your documentation. The configuration is then specific to the specified goal(s).
    <plugin>
        <groupId>org.microbean</groupId>
        <artifactId>helm-maven-plugin</artifactId>
        <version><IP_ADDRESS>.0.25</version>
        <executions>
            <execution>
                <phase>package</phase>
                <goals>
                    <goal>status</goal>
                </goals>
                <configuration>
                    <releaseName>mandatory</releaseName>
                    <version>1</version>
                </configuration>
            </execution>
        </executions>
    </plugin>

However, I do not want to associate this configuration with a specific goal. I want to be it a 'global' default. For this, I leave out execution tags and declare configuration 'just like that':
            <plugin>
                <groupId>org.microbean</groupId>
                <artifactId>helm-maven-plugin</artifactId>
                <version>${helm.maven.plugin.version}</version>
                <configuration>
                    <version>1</version>
                    <releaseName>${project.artifactId}</releaseName>
                </configuration>
            </plugin>

However, in this use-case version and releaseName are always mandatory prior knowing what goals are going to be invoked. Please have a look at the root pom.xml of this demo project.

I've cloned your demo project, and one of the other issues you have is that if you invoke a helm-maven-plugin goal from the root level, it will attempt to run the goal from that root level as well.  So if you try to run, say, the install mojo from the root, it will fail before it even starts to process your subprojects.
Here's a snippet showing that:
mvn org.microbean:helm-maven-plugin:install
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Detecting the operating system and CPU architecture
[INFO] ------------------------------------------------------------------------
[INFO] os.detected.name: osx
[INFO] os.detected.arch: x86_64
[INFO] os.detected.version: 10.13
[INFO] os.detected.version.major: 10
[INFO] os.detected.version.minor: 13
[INFO] os.detected.classifier: osx-x86_64
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] demo
[INFO] sub_demo_1
[INFO] sub_demo_2
[INFO] sub_demo_3
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building demo 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- helm-maven-plugin:<IP_ADDRESS>.0.33:install (default-cli) @ demo ---
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] demo ............................................... FAILURE [  0.591 s]
[INFO] sub_demo_1 ......................................... SKIPPED
[INFO] sub_demo_2 ......................................... SKIPPED
[INFO] sub_demo_3 ......................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.069 s
[INFO] Finished at: 2018-02-20T12:14:37-08:00
[INFO] Final Memory: 11M/309M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.microbean:helm-maven-plugin:<IP_ADDRESS>.0.33:install (default-cli) on project demo: /Users/LANELSON/Projects/github/gintautassulskus/demo/target/generated-sources/helm/charts/demo (No such file or directory) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Do you see how the failure here is because there's no target directory under demo (it doesn't even get to any of the sub_demo projects)?
So even if I put in a lenient mode you will still end up running your helm-maven-plugin goal against the parent project, which is almost certainly not what you want.
I also see that you're specifying the plugin version in both <pluginManagement> and <plugins>, which suggests to me that maybe you aren't fully aware of how <pluginManagement> works.  Its primary purpose is to centralize duplicate information.  If you make use of it properly, you could move your <configuration> in there and then have actual plugin invocations in your subprojects.  I'll file a pull request against your demo project to show you what I mean.  In short, you're still running up against a Maven misunderstanding more than you're running up against a limitation of the helm-maven-plugin.
Regarding this issue, what I'm going to do is close this bug, open a new enhancement for a silent skip if various source directories don't exist, and leave it at that; I think that plus a good understanding on your part of <pluginManagement> will allow you to do whatever you want to do here.

See https://github.com/gintautassulskus/demo/pull/1.


Add testcases for tab character in string

Regarding #126

I think this should probably be added to the string-multiline/raw-multiline.toml test.
The big advantage of grouping tests like this is that people can do things like implementing the regular non-multiline strings first in their encoder, and ignore all multiline string tests for the time being with just -skip valid/string-multiline.


PowerShell command

Please provide the PowerShell command used to configure this file blocklist in an Office365 tenant

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

ID: a3a0cebd-7e82-6631-bdee-031b3b84f74d
Version Independent ID: ee04db29-a6db-2874-2573-d80f0b415308
Content: Block syncing of specific file types
Content Source: OneDrive/block-file-types.md
Service: one-drive
GitHub Login: @kaarins
Microsoft Alias: kaarins

@SwiftOnSecurity , thanks for this feedback. I'm adding the link to the PowerShell documentation now!


Move ansible python module installation from post script to a standalone rpm

Since python module versions for ansible venv are hardcoded in post script, we should move this to a standalone RPM to avoid going through install process on every build.
This will eliminate a need to install a few development packages too.

can we somehow name it such that we know it's for embedded ansible?

Based on comments in https://github.com/ManageIQ/manageiq-appliance-build/pull/392, I assume we do want to continue providing python modules, but with reduced module list?
I don't know exactly how/where those are used and how to determine which module is needed.  @Fryguy @carbonin can you help?

@NickLaMuro wondering if you can help me figuring this out.

@simaishi sure, though I think I am going to have a counter opinion to what both @Fryguy and Carboni had.
Simply put, I think it is simpler for us to just copy what AWX/Tower does because I don't really want to get into the business of trying to figure out what to support and not support out of Ansible, and they have a dedicated team for that where we basically have... me.
That way, we can simply just point to the ansible/Tower documentation as a source of truth instead of trying to figure it out for ourselves.
For comments like this:
https://github.com/ManageIQ/manageiq-appliance-build/pull/392#discussion_r393285731
I honestly think "who cares", it is one module.  This isn't loaded unless it is needed, and unless it is conflicting with something else we have (which, since these are python modules and not other RPM packages, I don't think we are), I don't see the problem.
The alternative to trying comb through each module with every update and try and determine what is needed and not from us (and there doesn't seem to be a definitive source in upstream for this), instead of just doing a couple commands (aka:  pip3 freeze -l) and including everything.  It is slightly wasteful, but I think from a performance and RPM/appliance side perspective, I think it is almost negligible.

@NickLaMuro Thank you. So I think we have 2 things to discuss and come to a conclusion.

What modules to include.  Same as AWX/Tower or only what we need?
When to update

There is no rpm upstream, which is why we're running pip install during appliance build. Regardless of what we decide for the first question, we also need to think about when to update. "ansible" rpm comes from upstream and will be kept up-to-date. There is a compatibility matrix for Tower/Ansible. So if we don't update our venv, that might not cover all modules needed with a newer version of Ansible.  But, that might not matter, if we only really care about handful of modules...

I assume my opinion was obvious one the above, but I figured I should still weigh in:

What modules to include. Same as AWX/Tower or only what we need?

As mentioned above, I am in the "Same as AWX/Tower".

When to update

I guess this one is maybe less obvious, but I would say no more than once a release, but probably I would shoot for once a year to stay up to date, and only earlier if asked.
However, I am just throwing out suggestions that I just came up with, so I don't have a strong opinion on this one.


Provider string in npm documentation is depricated

Describe the bug
The example configurations provider string in the npm documentation is still strapi-provider-upload-google-cloud-storage while it should be @strapi-community/strapi-provider-upload-google-cloud-storage.
To Reproduce
Steps to reproduce the behavior:

Open https://www.npmjs.com/package/@strapi-community/strapi-provider-upload-google-cloud-storage
Go to "Setting up the configuration file"

Expected behavior
The documentation should have the correct provider string in its example.

Hello @MartinSchwarzmaier
I've forgot to publish new NPM release with latest update of this repository.
This is fixed now with release 4.2.3
Thanks,


(Try to) upgrade our Python versions.

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

bors r+

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

bors r+


Fix asserts

In ClickHouse such query led to assert in debug server:
select * from hdfs('hdfs://localhost:9000/data.csv', 'CSV', 'x UInt32')

Ok (I hope sock.read and sock.readFully support zero size)

I hoped it too, but decided to check and it has the same assert...
Ok, then I will use another way to fix it.


Customize specific properties

Hello,
I was wondering if there is a way to customize only specific properties instead of having to define them all in the form section.
In my example below, I'd like to append an event handler on the zipcode element:
br_address = {
    zipcode: {type: 'string',title: 'CEP',},
    street: {type: 'string',title: 'Logradouro'},
    number: {type: 'string',title: 'Número'},
    district: {type: 'string',title: 'Bairro',},
    cityname: {type: 'string',title: 'Cidade'},
    state: {type: 'string',title: 'Unidade Federativa'},
    complement: {type: 'string',title: 'Complemento'},
    country: {type: 'string',title: 'País'}
}
local_schema = {
    local: {
        type: 'object',
        properties: {
            name: {type: 'string',title: 'Name',required: true},
            age: {type: 'number',title: 'Age'}
        }
    },
    address: {
        type: 'object',
        properties: br_address
    }
}

$('form').jsonForm({
    schema: local_schema,
    form: [
        'local',
        'address'
    ],
});

Having to list all the fields of an object just to change the behavior of one of them is painful.
Any tips ?

Do you mean to use the * specific value ? See https://github.com/jsonform/jsonform/wiki#a-list-of-fields

Not really, * is all, I want to be able to bring all fields but to customize one of them, adding for example an event handler. If I put *, I dont have fine grained settings, and in the opposite, having to declare every field is not friendly.

I understand. We need another specific value (like "@" for instance) that would act as "*" but which would be overriden by subsequent items in the form section.
On your specific case, you could define your event handler outside of JSONForm maybe ?

Is there a way (an API) to access the jsonform object once it is created without messing with its internals ?

Not really, but you could programmatically create the JSON object beforehand, maybe, iterating over your fields ?

@tchapi Thank you for the suggestion ! I've been able to test it here, but I'm still unable to set the value of the form element, I don't know which method to apply to get it updated or displayed. I tried setting object.el.value property but it is not updating. See example below:
<!DOCTYPE html>

    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>

specifically, line                   field.el.value = data[k];
Any comments if this is the best solution ? Any ideas on how to update the field ?

It is really weird. The element seems like a ghost. I can see it with Developer tools > Inspect, I see the input text is present and has an ID (example: #jsonform-1-elt-address.cityname). But if I try to bind it with jquery (example: elm = $('#jsonform-1-elt-address.cityname'); console.log(elm);) I see this:
test_jsonform.html:89 jQuery.fn.init [prevObject: jQuery.fn.init(1)]
... and when I try to change it's value, it does nothing.

@tchapi nevermind, I found the error: jquery doesnt accept dots into ID's. I used iddot property and it worked !

Glad you made it work (and sorry for not being very responsive on this thread)


Update development documentation

Update development documentation in README to include conda env create  --file environment.yml

Done


Implemented UINavigationController-based transitions

It was really tough to keep both working the same way. @naru-jpn Take a look and let me know what you think.

@naru-jpn so when do you plan to merge your changes?

@kronik Soon! I'm checking behavior of example.

@kronik merged. 😃


Add Wikimedia Commons results

TBD whether we should use Wikidata's (newer, more abstract) API or WMC's (older, but more concrete) API

First pass of this deployed.


Whether you will still actively develop this library

I was intrigued by the idea of this library, as well as a code editor that would take advantage of the webview implementation, and have been looking into this recently

I was intrigued by the idea of this library, as well as a code editor that would take advantage of the webview implementation, and have been looking into this recently

Hey! Yes, I am still maintaining Freya and this editor as well. But just so you know, I am not using webview anywhere, Freya (and thus freya-editor) use Skia 😄

I apologize for my understanding, but still feel a lot of interest in this library and wonder what your plans are after that. I've run it before and found a lot of the structure unsatisfying, want to introduce similar features like plugins for example and would like to rebuild it a bit based on what you have now, and have been experimenting with that aspect in the recent past as well.


All loadServiceWorker options are required

I use a custom workerName in remix.config.ts (because this app has had a service worker prior to using Remix PWA and I'm under the impression I should keep the same name). As far as I can tell, this means I also need to configure the serviceWorkerUrl option when calling loadServiceWorker. The JSDoc comment for loadServiceWorker says "All parameters are optional." and I see they all have default values, but TypeScript is currently treating the options object as all-or-nothing and requiring I provide all the options rather than just serviceWorkerUrl.
I'm assuming the fields of the LoadServiceWorkerOptions type just need changed to be optional?

Yes you are right, those should be optional as they will use default values in any case,
Do you what to raise a PR for it?

Merged PR. Awaiting release (in a few hours, hopefully)

https://github.com/remix-pwa/monorepo/actions/runs/6408452460
Released


added bootstrap to base.njk

👷 Deploy Preview for johare-cv processing.

Name
Link

🔨 Latest commit
dc91b7b6bd141a340d1e1c292977e5a98d0abcae

🔍 Latest deploy log
https://app.netlify.com/sites/johare-cv/deploys/65dd27e1e94e0c00081460a9


"Set Module" button does not work

I have 4 custom modules deployed. I want to change/update a module. When i push the button "Set Module" nothing happen. Is it a bug?
thanks.

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

ID: 3808c67c-7c20-c275-efaa-d3724ccd88fc
Version Independent ID: 4d86b419-25f4-d08f-e939-8c87000f5aa2
Content: Deploy modules from Azure portal - Azure IoT Edge
Content Source: articles/iot-edge/how-to-deploy-modules-portal.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

@sergaz-msft thanks. I think that has nothing to do with my issue. I just want to change a module and that button does not work.

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