Fails to compile after script running

Output of install-gtk.sh:
error: failed to run custom build command for `gdk4-sys v0.9.0`

Caused by:
  process didn't exit successfully: `/home/georg/power-options/target/release/build/gdk4-sys-776af50fd9dbd655/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gdk4-sys-0.9.0/Cargo.toml
  cargo:rerun-if-env-changed=GTK4_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr

  pkg-config exited with status code 1
  > PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags gtk4 gtk4 >= 4.12

  The system library `gtk4` required by crate `gdk4-sys` was not found.
  The file `gtk4.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
  The PKG_CONFIG_PATH environment variable is not set.

  HINT: if you have installed the library, try setting PKG_CONFIG_PATH to the directory containing `gtk4.pc`.

warning: build failed, waiting for other jobs to finish...

Rust version 1.81.0 with the changes from issue #6

You need the dev libraries. I’m not sure what distro you’re on, but you need the libadwaita-1-dev and libgtk4-dev libraries to build the gtk frontend.

Hi, I was from the reddit thread: im running Ubuntu 24.04 but thanks for the info! Will mark this as closed once it works

Ok yeah installing the libadwaita-1-dev and the libgtk-4-dev fixed it! Thanks


[WIP] Add a beginning to the introduction.

Should discuss why the project is unique in comparison with other BEPs.

@gfokkema Better?


Add file with Polish translation pl.json

Hello, I have created a translation, but I am not able to test it at the moment and see if everything works. I would appreciate it if you would see the script and check if I messed up anything. :)

Added manually as the PR has some issues :p, thanks for the translation


Mask R-CNN ONNX Export at mmdet 2.7.0, how to without failing?

I installed mmdet 2.7.0 and as of the Changelog https://github.com/open-mmlab/mmdetection/blob/master/docs/changelog.md, Mask R-CNN models shold be able to be exported to ONNX format but I have not been able to get predictions from the exported model
For testing the feature I downloaded the pretrained model mask_rcnn_r101_fpn_2x_coco_bbox_mAP-0.408__segm_mAP-0.366_20200505_071027-14b391c7.pth from https://github.com/open-mmlab/mmdetection/tree/master/configs/mask_rcnn, put inside a folder named "checkpoints" inside ~/mmdetection and there I used
python tools/pytorch2onnx.py configs/mask_rcnn/mask_rcnn_r101_fpn_2x_coco.py checkpoints/mask_rcnn_r101_fpn_2x_coco_bbox_mAP-0.408__segm_mAP-0.366_20200505_071027-14b391c7.pth --input-img demo/demo.jpg --verify --show
When running it it first says "Successfully exported ONNX model: tmp.onnx" but at the end it fails saying
onnxruntime output names: ['boxes', 'labels'],             output shapes: [(62, 5), (62,)]
Traceback (most recent call last):
  File "../mmTools/pytorch2onnx.py", line 193, in <module>
    pytorch2onnx(
  File "../mmTools/pytorch2onnx.py", line 121, in pytorch2onnx
    np.testing.assert_allclose(
  File "/home/ubuntu/.conda/envs/open-mmlab/lib/python3.8/site-packages/numpy/testing/_private/utils.py", line 1527, in assert_allclose
    assert_array_compare(compare, actual, desired, err_msg=str(err_msg),
  File "/home/ubuntu/.conda/envs/open-mmlab/lib/python3.8/site-packages/numpy/testing/_private/utils.py", line 759, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Not equal to tolerance rtol=0.001, atol=1e-05

(shapes (51, 5), (49, 5) mismatch)
 x: array([[1.158027e+03, 2.130080e+02, 1.205723e+03, 2.563616e+02,
        9.916629e-01],
       [9.157939e+02, 2.070513e+02, 9.928231e+02, 2.445640e+02,...
 y: array([[1.158027e+03, 2.130080e+02, 1.205723e+03, 2.563616e+02,
        9.916627e-01],
       [9.157939e+02, 2.070513e+02, 9.928231e+02, 2.445640e+02,...

I thought it could be some minor issue so I went to test the exported model using
import skimage.transform, skimage.io

testIm='./demo/demo.jpg';
im = skimage.io.imread(testIm);

# Preprocess
im = np.rollaxis(im,2,0);
# COCO pretrained models seem to have 3x800x1216 input dimensions as
# shown by running script given by accepted answer at
# https://stackoverflow.com/questions/56734576/find-input-shape-from-onnx-file
im = skimage.transform.resize(im/255, (3,800,1216), anti_aliasing=True)
im = im[np.newaxis,:,:,:]
#print(im.shape); sys.exit();
im = im.astype(np.float32);

sess = rt.InferenceSession("tmp.onnx")
input_name = sess.get_inputs()[0].name
label_name = sess.get_outputs()[0].name
pred = sess.run(None, {input_name: im})[0]

print(pred);

Which also fails saying
2020-12-07 22:30:05.631629881 [E:onnxruntime:, sequential_executor.cc:318 Execute] Non-zero status code returned while running Reshape node. Name:'Reshape_1222' Status Message: /onnxruntime_src/onnxruntime/core/providers/cpu/tensor/reshape_helper.h:42 onnxruntime::ReshapeHelper::ReshapeHelper(const onnxruntime::TensorShape&, std::vector<long int>&) gsl::narrow_cast<int64_t>(input_shape.Size()) == size was false. The input tensor cannot be reshaped to the requested shape. Input shape:{432,2}, requested shape:{470,2}

Traceback (most recent call last):
  File "cocoPredict.py", line 18, in <module>
    pred = sess.run(None, {input_name:im})
  File "/home/ubuntu/.conda/envs/open-mmlab/lib/python3.8/site-packages/onnxruntime/capi/session.py", line 123, in run
    return self._sess.run(output_names, input_feed, run_options)
onnxruntime.capi.onnxruntime_pybind11_state.RuntimeException: [ONNXRuntimeError] : 6 : RUNTIME_EXCEPTION : Non-zero status code returned while running Reshape node. Name:'Reshape_1222' Status Message: /onnxruntime_src/onnxruntime/core/providers/cpu/tensor/reshape_helper.h:42 onnxruntime::ReshapeHelper::ReshapeHelper(const onnxruntime::TensorShape&, std::vector<long int>&) gsl::narrow_cast<int64_t>(input_shape.Size()) == size was false. The input tensor cannot be reshaped to the requested shape. Input shape:{432,2}, requested shape:{470,2}

Does this mean that ONNX is still not fully suported for Mask R-CNN or something else should be done while doing the export to ONNX?

Please @RunningLeon have a check.

@masotrix Hi,
Pytorch2ONNX of Mask-RCNN in MMCV is not fully supported up to now.
Reasons:

F.grid_sample cannot be converted right now;
Minor differences of nms between Pytorch and ONNX Runtime may lead to unmatched results.(as AssertionError says);
Sometimes dynamic shapes may be traced as constant shapes and exported to ONNX(as ONNXRuntimeError suggests: Reshape_1222 were constant shape), which is weird and not fully solved;


refactor(Topology/MetricSpace/PseudoMetric): split out parts requiring compactness or a bornology

Split out the second half of the file, into

one file for the real numbers as metric spaces (requires the order topology)
another file for all other lemmas requiring this and a bornology.

Open questions

what is a better name for PseudoMetricAdvanced?
should Real be folded to PseudoMetricAdvanced? Currently, it's fairly short, but also fairly self-contained.
The second file has barely any module docstring; help welcome. (This is pre-existing.)

Further suggestions for splitting the first half are welcome, the file is still pretty entangled.

Closing this PR as obsolete:

it's rotten so well that I would need to re-do it anyway
Yael's and Ruben's work on splitting the long pole as solved this already.


Spear Quicken on AutoBuff

Spear Quicken (Crusader Skill) is missing after update on auto buff tab.

Hello @junglejf . We noticed that this buff settings was wrong. It was functional ? 😯

Thanks !


How can I disable path evaluation?

Starting with 1.1.2, I am seeing the following error:
Execution default of goal org.jsonschema2pojo:jsonschema2pojo-maven-plugin:1.1.2:generate failed: Path not present: $%7BRFC_NUMBER%7D
Example:
"variables": {
    "${RFC_NUMBER}": "",
}

In this case, the variable ${RFC_NUMBER}" is a literal and there is no need to evaluate it
Configuration

<plugin>
                <groupId>org.jsonschema2pojo</groupId>
                <artifactId>jsonschema2pojo-maven-plugin</artifactId>
                <version>1.1.2</version>
                <configuration>
                    <sourceDirectory>${basedir}/src/main/resources/schema/</sourceDirectory>
                    <targetPackage>com.models</targetPackage>
                    <sourceType>json</sourceType>
                    <annotationStyle>gson</annotationStyle>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

The same code works as is in 1.1.1

This is a duplicate of #1402.


added quickstart and simplified instructions for Jetson setup

Revised NVIDIA Jetson tutorial to be simpler and also added a quickstart guide.

Thanks do you know if tmux is a requirement? (thinking where we can simplify this example)

Thanks for the recommendation, @jmorganca - I've gone ahead and set it up to use a nohup command instead. Thanks again!

Hi @jmorganca - I made a few more tweaks (done now). Thanks and have a great morning!

Hi @jmorganca - I'm super excited about the latest release (v0.1.13). Now that we can set parameters in ollama run, I will revise the setup instructions related to this PR (thanks @BruceMacD for keeping me updated on that). I will post a comment when this PR has been updated accordingly and is ready for review. Thanks, all!

Hi @jmorganca - this PR has been updated. Thanks!


Allow variable key sizes for Blowfish

This fixes https://github.com/gchq/CyberChef/issues/930 by correcting the key size validation. Tests have also been added for key sizes other than 8 bytes.

Any movement on this, its still broken on current release, older versions work as expected


Always get 403

Hi.
When I call API from php using unirest, I always get 403 error.
I have copied and paste the code from API page, including my API key.
Console curl works well.

can you post the example here?

Hi
I run the following code:
$response = \Unirest\Request::post("https://community-neutrino-ip-info.p.mashape.com/ip-info",
          array(
            "X-Mashape-Key" => "...",
            "Content-Type" => "application/x-www-form-urlencoded",
            "Accept" => "application/json"
          ),
          array(
            "ip" => "<IP_ADDRESS>",
            "reverse-lookup" => false
          )
      );

And get 403 error.
I copied the code without changes from API page.
I also tried to use php curl, but got the same error.
But the console curl works.


CFP: Cilium CLI connectivity tests speedup.

In general, any policy whether it's CNP or CCNP can interfere, especially if the workloads that they select are common amongst other policies. It seems like one approach could be to completely separate workloads via namespaces for each "group" of connectivity tests. This way the policies applied only have an effect within the namespaces that they are in, so therefore namespaces would be the separation barrier that allows parallelism.

It would be useful to people like me that the document includes a list, at a high level, of the strategies that have already been explored and why they are falling short.

Yeah, it would be useful for me as well.

I was thinking about PoC plan and realized that Cilium CLI can be used to run multiple tests in parallel (at least for testing).
The --test-namespace and --test parameters were used to validate the idea.
I've selected 46 tests (from EKS CNI conformance test workflow) and used the attached bash script to run the tests in batches/parallel.
You can find results in the table: https://docs.google.com/spreadsheets/d/1csmszEtlohqPpgMV8N_aJUI4yCoW8mPke46k-rG-Uec/edit?usp=sharing
Conclusions:

Cilium CLI has no tests that use CiliumClusterwideNetworkPolicy yet.
At least 46 selected tests can be run in parallel with no interference!!!
Practically, it won't be possible to run each test in a separate namespace due to a lot of pods and IPs allocation.
Ideally, CLI should create and verify all the required test namespaces/deployments only once initially.

Further steps (order might be different):

Rename --test-namespace parameter to --test-namespace-prefix.
Implement a new parameter: --test-parallel-runs with the default value: 1.
Move test namespace/deployments creation and verification logic before the test run function.
Implement tests grouping logic into batches with the --test-parallel-runs size.
Think about how to collect and display output (considering GH runners that might have different behavior than a local terminal).

Also, I was thinking about implementing this as a new CLI command (e.g.: cilium tests ..., maybe even hidden).
So, for some time we can have both old and new approaches with shared test sources and will be able to test and compare them without any impact.
CC: @aanm @christarazi @fgiloux @brlbil @michi-covalent.

That sounds good to me.
Just one thing on

Cilium CLI has no tests that use CiliumClusterwideNetworkPolicy yet.

Soon I imagine https://github.com/cilium/design-cfps/pull/16 will get merged and we'll very likely have tests with CCNP, so it is something that we'll need to consider in this proposal.

Sounds great,

Think about how to collect and display output (considering GH runners that might have different behavior than a local terminal).

One thing might be tricky, printing test logs correctly given the tests would be run concurrently. Also, the JUnit collection should be considered.

Sounds great,

Think about how to collect and display output (considering GH runners that might have different behavior than a local terminal).

One thing might be tricky, printing test logs correctly given the tests would be run concurrently. Also, the JUnit collection should be considered.

Thanks!
I've already tested this: cilium/images/conn-tests-concurrent-output.gif

@viktor-kurchenko we just added statuses for CFPs. Where do you think this one currently falls? https://github.com/cilium/design-cfps#status

@viktor-kurchenko we just added statuses for CFPs. Where do you think this one currently falls? https://github.com/cilium/design-cfps#status

@xmulligan I think the status should be: Released cilium/cilium-cli 0.16


Extension fails to find tsconfig.json when vue file is in a subdirectory.

Extension fails to find tsconfig.json when vue file is in a subdirectory.
Example: src/views/ViewTest.vue
Typescript config is loaded and vscode is providing the correct errors in the code.

Example: src/views/hello/ViewItem.vue
Typescript config is not loaded and vscode is not providing the errors that I am expecting.

Please make sure the tsconfig included vue files in src/views/hello correctly, you can reference https://github.com/johnsoncodehk/volar-starter/blob/master/tsconfig.json#L15.
If you can't make it works please provide a repro case.


Update mdbook

Opened https://github.com/Michael-F-Bryan/mdbook-linkcheck/pull/9 to fix linkcheck incompatibility...

Just dropped caches. This is live now.


Prototyping/16031 toolchain abstraction

This draft is an early show case of an alternative strategy for the toolchain abstraction.
The main purpose of this proposal is to minimize the work needed when implementing support for an additional toolchain.
Currently, when implementing support for a new toolchain in Zephyr or when
implementing downstream support for a custom / vendor specific toolchain
there are several macros to be defined, even if the are empty.
The macro based approach also offers challenges as well as additional
maintenance burden when new macros are introduced, as all downstream users with
custom toolchains must implement those (even if empty).
Furthermore, it also requires additional split of code into cmake files that
simple implements a single macro, in order to allow a toolchain to source
only a subset. (as example: target_base.cmake, target_freestanding.cmake,
target_barmetal.cmake)
This is due to the fact that macros cannot be overwritten, once they are defined.
(In fact CMake allows for this, but let's avoid that path, as it leads to other
risks and complications).
Now, separating parts into dedicated cmake files might always be a good idea, seen from design perspective, but it should be done because it makes sense, and not just splitting because of macro reuse / lack of reusability.
This draft instead propose the use of dedicated targets and properties on those
targets.
The benefits are:

Possibility of defining a default flag (can be cleared / overwritten later)
(currently default is no flag)

Possibility of inheriting a set of flags from other compiler / linker and
overwrite only parts that differs. For example clang can inherit all of gcc
compiler flag and only overload warnings and coverage, and clear
security_fortify and hosted flags. See cmake/compiler/clang/compiler_flags.cmake.
https://github.com/tejlmand/zephyr/blob/prototyping/16031_toolchain_abstraction/cmake/compiler/clang/compiler_flags.cmake

More uniform set and use design

Ability to manually overwrite a flag AFTER it has been used on a compile target.
For example in app CMakeLists.txt and find_package(Zephyr)

Clearer separation:

compiler flags goes to: compiler/<compiler-name>/compiler_flags.cmake
linker flags goes to: linker/<linker-name>/linker_flags.cmake
bintools flags / commands goes to: bintools/<bintools-name> cmake files.

A couple of comments related to approach chosen to questions that might arise:

Why not use normal variables instead of target properties ?
It would be possible to achieves almost similar behavior with variables, but
not completely.
But the split into a target with property ensures:

There will be no name collision with other variables used in the build system
Variables are dependent on process order, target properties are not.
For example, if you do:zephyr_compile_options(${MY_VAR})
set(MY_VAR value)

will not work, but doing:zephyr_compile_options($<TARGET_PROPERTY:compiler,my_property>)
set_property(TARGET compiler PROPERTY my_property value)

will work.

We ensure a more common usage principle.
Current solution has a couple of different ways for the macros,
x_flag vs x_flags as well as parameter handling:

macro(toolchain_cc_warning_base) - Sets flags directly as compile options
macro(toolchain_cc_optimize_for_debug_flag dest_var_name) - Sets the compile flag on dest_var_name, unless already set.
macro(toolchain_cc_cpp_base_flags dest_list_name) - Appends the compile flag dest_var_name, keeping any existing values on the list.
Some macros base the behavior on the parameter.
Some macros set linker options in the compiler macros:

macro(toolchain_cc_asan)
  zephyr_compile_options(-fsanitize=address)
  zephyr_link_libraries(-lasan)
  zephyr_ld_options(-fsanitize=address)
endmacro(toolchain_cc_asan)

bintools macros sometimes set linker flags:
macro(bintools_print_mem_usage)
  ...
  target_link_libraries_ifdef(${check} ${ZEPHYR_PREBUILT_EXECUTABLE} ${option})
endmacro(bintools_print_mem_usage)

@ttornblom FYI

nice to have a template. that will be a good start point to support new toolchains

Hi!
I've run sanitycheck for ARC targets (nsim_em, nsim_hs, nsim_sem, etc..) and I got 100% tests failed with GNU toolchain from zephyr SDK.
Here is log from hello-world sample:

/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/build.log
--------------------
Including boilerplate (Zephyr base): /slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/cmake/app/boilerplate.cmake
-- Application: /slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/samples/hello_world
-- Zephyr version: 2.3.99 (/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr)
-- Found Python3: /global/freeware/Linux/RHEL7/python-3.7.0/bin/python3.7 (found suitable exact version "3.7.0") found components: Interpreter
-- Found west: /global/freeware/Linux/RHEL7/python-3.7.0/bin/west (found suitable version "0.7.2", minimum required is "0.7.1")
-- Board: nsim_hs
-- Cache files will be written to: /u/relauto/.cache/zephyr
-- Found toolchain: zephyr (/u/svc-arcoss_auto/tools/zephyr-sdk/0.11.3)
-- Found dtc: /u/svc-arcoss_auto/tools/zephyr-sdk/0.11.3/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/boards/arc/nsim/nsim_hs.dts
-- Generated zephyr.dts: /slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/zephyr/include/generated/devicetree_unfixed.h
Parsing /slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/Kconfig
Loaded configuration '/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/boards/arc/nsim/nsim_hs_defconfig'
Merged configuration '/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/samples/hello_world/prj.conf'
Configuration saved to '/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/zephyr/.config'
Kconfig header saved to '/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /u/svc-arcoss_auto/tools/zephyr-sdk/0.11.3/arc-zephyr-elf/bin/arc-zephyr-elf-gcc
-- Configuring done
CMake Error in ../../CMakeLists.txt:
  Found relative path while evaluating include directories of
  "linker_pass_final_script_target":

    "-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/includeSTRIP_PREFIX-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/zephyr/include/generatedSTRIP_PREFIX-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/soc/arc/snps_nsimSTRIP_PREFIX-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/lib/libc/minimal/include"

CMake Error in ../../CMakeLists.txt:
  Found relative path while evaluating include directories of
  "linker_script_target":

    "-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/includeSTRIP_PREFIX-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/sanity-out/nsim_hs/samples/hello_world/sample.basic.helloworld/zephyr/include/generatedSTRIP_PREFIX-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/soc/arc/snps_nsimSTRIP_PREFIX-I/slowfs/ru20arcjenkins/de02-arcjenkins2/slaves/ru20-gp-hw-linux109/workspace/arcoss_verification/zephyr_verification/sanity_check-3/zephyr/lib/libc/minimal/include"

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

Other tests (among the ones I've checked) has same build issue.
I run tests from 5d2c3b06eab6f135eac3924365ccf55372572947 commit from your tree.
Toolchain is GNU from zephyr-sdk 0.11.3

I've run sanitycheck for ARC targets (nsim_em, nsim_hs, nsim_sem, etc..) and I got 100% tests failed with GNU toolchain from zephyr SDK.
Here is log from hello-world sample:

Very interresting.
Did you rememeber to run west update after checking out the commit ?
Here is what I get:
$ git rev-parse HEAD
5d2c3b06eab6f135eac3924365ccf55372572947
$ ./scripts/sanitycheck -p nsim_em -p  nsim_hs -p nsim_sem -T samples/hello_world -N
ZEPHYR_BASE unset, using "/projects/github/ncs/zephyr"
Renaming output directory to /projects/github/ncs/zephyr/sanity-out.6
INFO    - JOBS: 4
INFO    - Building initial testcase list...
INFO    - 3 test configurations selected, 0 configurations discarded due to filters.
INFO    - Adding tasks to the queue...
INFO    - Total complete:    3/   3  100%  skipped:    0, failed:    0
INFO    - 3 of 3 tests passed (100.00%), 0 failed, 0 skipped with 0 warnings in 12.62 seconds
INFO    - In total 3 test cases were executed on 3 out of total 280 platforms (1.07%)
INFO    - 0 tests executed on platforms, 3 tests were only built.

which looks as expected.
And the build log for nsim_em board:
> cat sanity-out.5/nsim_em/samples/hello_world/sample.basic.helloworld/build.log
Including boilerplate (Zephyr base): /projects/github/ncs/zephyr/cmake/app/boilerplate.cmake
-- Application: /projects/github/ncs/zephyr/samples/hello_world
-- Zephyr version: 2.3.99 (/projects/github/ncs/zephyr)
-- Found Python3: /usr/bin/python3.7 (found suitable exact version "3.7.5") found components: Interpreter
-- Board: nsim_em
-- Cache files will be written to: /home/tora/.cache/zephyr
-- Found toolchain: zephyr (/opt/zephyr-sdk-0.11.3)
-- Found west: /home/tora/.local/bin/west (found suitable version "0.7.99", minimum required is "0.7.1")
-- Found dtc: /opt/zephyr-sdk-0.11.3/sysroots/x86_64-pokysdk-linux/usr/bin/dtc (found suitable version "1.5.0", minimum required is "1.4.6")
-- Found BOARD.dts: /projects/github/ncs/zephyr/boards/arc/nsim/nsim_em.dts
-- Generated zephyr.dts: /projects/github/ncs/zephyr/sanity-out/nsim_em/samples/hello_world/sample.basic.helloworld/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /projects/github/ncs/zephyr/sanity-out/nsim_em/samples/hello_world/sample.basic.helloworld/zephyr/include/generated/devicetree_unfixed.h
Parsing /projects/github/ncs/zephyr/Kconfig
Loaded configuration '/projects/github/ncs/zephyr/boards/arc/nsim/nsim_em_defconfig'
Merged configuration '/projects/github/ncs/zephyr/samples/hello_world/prj.conf'
Configuration saved to '/projects/github/ncs/zephyr/sanity-out/nsim_em/samples/hello_world/sample.basic.helloworld/zephyr/.config'
Kconfig header saved to '/projects/github/ncs/zephyr/sanity-out/nsim_em/samples/hello_world/sample.basic.helloworld/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /opt/zephyr-sdk-0.11.3/arc-zephyr-elf/bin/arc-zephyr-elf-gcc
-- Configuring done
-- Generating done
-- Build files have been written to: /projects/github/ncs/zephyr/sanity-out/nsim_em/samples/hello_world/sample.basic.helloworld
[1/116] Preparing syscall dependency handling
....
[111/116] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
            ICCM:        9328 B       512 KB      1.78%
            DCCM:        6552 B       512 KB      1.25%
        IDT_LIST:          25 B         2 KB      1.22%
[112/116] Generating linker_pass_final.cmd
[113/116] Generating isr_tables.c
[114/116] Building C object zephyr/CMakeFiles/zephyr_final.dir/misc/empty_file.c.obj
[115/116] Building C object zephyr/CMakeFiles/zephyr_final.dir/isr_tables.c.obj
[116/116] Linking C executable zephyr/zephyr.elf

but I notice this STRIP_PREFIX-I/slowfs which is probably the root cause, but I wonder why you experience this, and not CI or locally at my machine.

@evgeniy-paltsev  I think I might have found the issue. I have forced-push the PR including what I believe should fix the issue.
But as I have not been able to reproduce the error, I would like your feedback when you have time.

@evgeniy-paltsev I think I might have found the issue. I have forced-push the PR including what I believe should fix the issue.
~But as I have not been able to reproduce the error,~
I have verified that a JOIN generator expression would contain an STRIP_PREFIX-I that could lead to invalid behavior in some cases. Still unsure why this issue did not appear locally or on CI.
I would (still) like your feedback when you have time.
(Text edited)

I've launched tests for ARC simulation platforms - everything is OK, thanks.

Note there is a MetaWare PR (add C-lang/llvm based metaware toolchain support in Zephyr #22668) that is ready to go in as well - @evgeniy-paltsev is doing 'final' clean-ups, and @tejlmand started on the change from macro definition to properties for that as well. I expect some further minor cleanups to be required, but great if both can still make it into RC1.

@tejlmand: "cmake: toolchain disable -imacro deduplication" commit from this PR (merged as f109e6839be04f105ede7c2aaecc034b26c0a613) broke "make zephyr_generated_headers" target, specifically creation of Makefile.exports.* (e.g. Makefile.exports.C) files containing CFLAGS, etc. for integration with external build systems. The effect of that can be seen e.g. at https://ci.linaro.org/job/lite-aeolus-micropython/PLATFORM=frdm_k64f,ZEPHYR_TOOLCHAIN_VARIANT=zephyr,label=docker-xenial-amd64-13/1317/console :

00:06:44.936 GEN build/genhdr/qstr.i.last
00:06:44.936 arm-zephyr-eabi-gcc: error: SHELL:: No such file or directory
00:06:44.936 arm-zephyr-eabi-gcc: error: SHELL:: No such file or directory

I.e., these SHELL: moniker leaks into CFLAGS, and of course leads to errors.
I see that there was a similar problem elsewhere, addressed in 9d501f4ba8fa46bd2f4d1f412a8f2bc68c3126dd. I'll try to adapt it to "make zephyr_generated_headers", but not sure if I'll be able to, and may need some help.

@pfalcon The make zephyr_generated_headers target is just a pseudo target for dependencies, but I do see the issue with having CONFIG_MAKEFILE_EXPORTS=y that results in SHELL getting into the Z_CFLAGS file.
Already looking at a fix, so you don't need to spend time on that.

@tejlmand :

Already looking at a fix, so you don't need to spend time on that.

Thanks, appreciate that!

@tejlmand :

Already looking at a fix, so you don't need to spend time on that.

Thanks, appreciate that!

Could you file a medium issue, a brief description is enough, and assign directly to me.
To my knowledge, all PRs in stabilization period must have an issue they fix in order to be merged.

@pfalcon Could you file a medium issue

Done: https://github.com/zephyrproject-rtos/zephyr/issues/28230


🪲 Bug report: Edit-PSReadlineHistoryFile fails to find history file

This is in PowerShell 7.4

Fixed in v1.4.1 release. Thanks for the report!


Grab mode animation cursor position is not always correctly in sync with mouse position

When iteractivity.detect_on property is set to window and grab mode is activated on hover, the canvas listens to mousemove events and updates the "central link point" during the animation. Currently it does this by using clientX and clientY coordinates from the event object but this set of coordinates is only relative to the viewport of the browser and it does not take into account any kind of page scroll offset. Thus, by scrolling down the page, the animation "central link point" is upper than the place where the mouse icon is drawn.
Proposed solutions: Use pageX and pageY instead of clientX and clientY, because they also contain the scroll offset values.

Thank you. It helped me a lot!
Using e.offsetX and e.offsetY instead of e.clientX and clientY has the same effect on my system.

In my case, I use bootstrap and put the particle div inside a section. offsetX and offsetY work while pageX and pageY didn't

How do I do this with elementor on wordpress as I couldn't find this in my particle script
{   "particles": {     "number": {       "value": 125,       "density": {         "enable": true,         "value_area": 800       }     },     "color": {       "value": "#ffffff"     },     "shape": {       "type": "circle",       "stroke": {         "width": 0,         "color": "#000000"       },       "polygon": {         "nb_sides": 10       },       "image": {         "src": "img/github.svg",         "width": 100,         "height": 100       }     },     "opacity": {       "value": 0.5,       "random": false,       "anim": {         "enable": false,         "speed": 1,         "opacity_min": 0.1,         "sync": false       }     },     "size": {       "value": 4.008530152163807,       "random": true,       "anim": {         "enable": false,         "speed": 40,         "size_min": 0.1,         "sync": false       }     },     "line_linked": {       "enable": true,       "distance": 150,       "color": "#ffffff",       "opacity": 0.4,       "width": 1     },     "move": {       "enable": true,       "speed": 6,       "direction": "none",       "random": false,       "straight": false,       "out_mode": "out",       "bounce": false,       "attract": {         "enable": false,         "rotateX": 600,         "rotateY": 1200       }     }   },   "interactivity": {     "detect_on": "window",     "events": {       "onhover": {         "enable": true,         "mode": "grab"       },       "onclick": {         "enable": true,         "mode": "repulse"       },       "resize": true     },     "modes": {       "grab": {         "distance": 400,         "line_linked": {           "opacity": 1         }       },       "bubble": {         "distance": 400,         "size": 40,         "duration": 2,         "opacity": 8,         "speed": 3       },       "repulse": {         "distance": 200,         "duration": 0.4       },       "push": {         "particles_nb": 4       },       "remove": {         "particles_nb": 2       }     }   },   "retina_detect": true }


Potential buffer overflow with semver_render and semver_clean

The semver_render function does not check for buffer bounds on dest. Also, since it cannot be know how big the buffer must be, it is possible to pass a buffer that is too small to accommodate the resulting string.

This also appears to be the case fordest in semver_clean.

Thanks for reporting. Would you be interesting in providing a fix?

It should be quite simple for semver_clean - just do it in-place on str, instead of copying to dest first. It's more complicated for semver_render. I'll see if I can make a fix.

I've got a fix for semver_clean, though not semver_render. Would it be okay for you to make a fix?

Thanks again for the PR! I would not mind providing the fix, hopefully this weekend when if I have some free time.

This should be fixed in v1.0.0. Closing for now.


Roll back team creation if adding members fails

Description
Delete team if adding members fails during creation. We want to delete the team because otherwise, we leave an orphaned team around. The orphaned team will cause a 409 conflict when the user attempts to recreate the team after encountering the error.
Fixes https://github.com/pulumi/pulumi-pulumiservice/issues/73

I believe the "right" way to handle this is the "partial" create failure feature, which allows the provider to indicate that it did create the resource but failed to initialize it. Then in this case the team won't be destroyed, but future changes will be processed as updates to the team which can succeed without a leak.
See for example https://github.com/pulumi/pulumi-pulumistack/blob/f1ab9c1333a19732287a00b776ff6fc535ab69ea/provider/pkg/provider/provider.go#L233.

Very interesting! I wasn't aware of this feature. Will use this approach instead.


docs: Normalizing docker-machine config references to docker-machine env

Fixes #762
Signed-off-by: Dave Henderson<EMAIL_ADDRESS>

LGTM

nice!


Update mc_convergence_plot.jl

P needs to be of the type MarkovChain to go into mc_compute stationary. You mentioned you thought about adding the old method back right? But the MarkovChain constructor would be useful in checking whether the array satisfies the condition sum(P[i,:]) = 1. Or do you want to integrate that into every MarkovChain routine?

@ranjanan thanks for pointing this out -- we should definitely fix it.
I also like the comment you made here about using the MarkovChain as a way to enforce the invariants imposed by the inner constructor. That's probably a good approach to take for all the functions defined in mc_tools -- but making that change would require more work to be done on the website. I'll log an issue there.


Added circle command but i have questions.

I have added the circle command, but this is my first time contributing to something on github, so please if you see that i have done something wrong, done something in a diffrent way than i should have, change it and let me know. I dont know if i should use ellipseMode(center) or not, or if i should use w,h instead of radius.

Thank you for contributing ❤
Don't worry about 'making mistakes' Git and Github makes it easy to change things afterwards, just go for it.
I couldn't find a circle command in the Berkeley Logo Manual but there is an ARK command:
ARC angle radius

	draws an arc of a circle, with the turtle at the center, with the
	specified radius, starting at the turtle's heading and extending
	clockwise through the specified angle.  The turtle does not move.

As the ARC command takes a radius parameter it will be measures from the center as opposed to a corner.


Prompt user when he/she wants to leave a page with unsaved information

I believe that it's good design to have this on every page that has a "Save" or "Submit" button.
For example, go to Facebook and try to edit your profile. Notice how you get a message box asking you if you are sure if you try to leave the page when you have entered some new and unsaved data.
Pages cases where we should do this:

creating/editing an assignment
as a student, adding a new file ( and forgetting to save it ) for a submission in the file_manager
creating/editing a note
creating/editing a mark spreadsheet

I may have missed a few places, but those are the main areas that feel like they need it.

FWIW, we do this on the file_manager page already. Would be a good idea to have it, but it's fairly low priority.

@aimenk could you elaborate on "4. Loaded a file." What do you mean by that?
FYI: On the demo, if I click on the "Add New" button on the "Submissions" tab and try then to move away I get a prompt asking me if I want to leave or stay on the page. Perhaps this is broken in current master? If it is, please fix.

From my observations,
Firefox:
I will get the prompt asking me if I want to leave or stay on the page
Chrome and Chromium:
I will not get the intended prompt.
Interestingly, in chrome/chromium i will get a different and unintended prompt when clicking "open" when browsing for a file. suppose i browsed for a file called "foo.txt," then the prompt will look like this:
After you submit the filename will be changed from
'C:\fakepath\foo.txt' to
'C__fakepath_foo.txt'
Is that OK?
|  Okay | Cancel  |
i'm looking into these issues now.

This file sanitation thing has been a problem in the past. Feel free to make it work with Firefox and Chromium. If in doubt the behaviour when using Firefox is the right one :)


getValue() doesn't always produce the same buffer

I am programming an oscilloscope and in the scope I want to implement an external trigger. I have 2 waveform objects and I get the buffer like so:
        let drawBuffer = drawWave.getValue();
        let dataBuffer = dataWave.getValue();

The intention is to use one as a trigger sync for the other. However, even when the sync is used against itself I run into random visual glitches. I have come to find that even when both waveform sources are being driven by the same input they sometimes are randomly different. It can be consistent for a bit, each buffer being the same but then other times it is randomly different.
I am trying to understand why. It is not timing related, at least not anything I have tried related to getting a timing difference has made any difference. As a testing method I have used this:
        // let point1 = this.trigger(drawBuffer, 0, 'rising');
        // let point2 = this.trigger(dataBuffer, 0, 'rising');
        // let difference = point2 - point1;
        // if(difference != 0){
        //     console.log(difference)
        // }

Which will fix the issue for self triggered waves since this just shifts any difference that occurs. This is not helpful for syncing complex waves since I have no way of determining when this random change will happen. What it does give me is the values I need to some how reproduce to get rid of the glitches. The number of samples will be related to the frequency.
I keep coming back to trying to understand why the getValue() is different sometimes. It's the same 99% of the time, but that last 1% causes this glitch. Any ideas on how I can kill it?
There is a demo live: http://composinggloves.com/app/oscilloscope, the graphExtTrigger is the function I am working on. I have left the log function on, it may take a bit for a log to appear or it may happen right away. Refresh the page and click to start the scope, refreshing a few times can often trigger the bug a bit faster.
If anyone has any insight please let me know!

i would imagine getValue might be susceptible to some floating point errors and not produce the exact same values each time. For your comparison method you could use something like const difference = Math.abs(point2 - point1) > 0.0001) which would ignore values that are very close to each other but might not be exactly the same.


Progress bar with different colors triggers a Sys_blocked_io exception from OCaml Printf

This was fixed in https://github.com/leostera/tty/commit/bf577e0b01edf2aa02d3ce078baabacf96fcc649 – problem was setting the stdin file descriptor to non-blocking. We bumped to tty 0.0.2 on https://github.com/leostera/minttea/commit/7e21ada55b93c7960b411d2c0653482014f087f5 so that closes this issue.


TestCommon: Reuse actions

Description
TestCommon:

Use new action for dotnet setup and tools

Codecov Report

Merging #112 (2a88e07) into main (6ff9f20) will increase coverage by 6.31%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #112      +/-   ##
==========================================
+ Coverage   65.11%   71.42%   +6.31%
==========================================
  Files          87       57      -30
  Lines        1591     1421     -170
  Branches      212      153      -59
==========================================
- Hits         1036     1015      -21
+ Misses        474      354     -120
+ Partials       81       52      -29

Flag
Coverage Δ

messaging
?

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

Impacted Files
Coverage Δ

...ServiceCollection/ServiceCollectionSendProtobuf.cs

...ssaging/source/Messaging/Dispatching/HubCommand.cs

...ource/Messaging/Validation/RuleResultCollection.cs

...source/Messaging/Dispatching/BaseRequestHandler.cs

...ssaging/source/Messaging/FluentHybridRuleEngine.cs

...Messaging/MessageTypes/Common/MarketParticipant.cs

...Collection/ServiceCollectionValidationExtension.cs

...ging/source/Messaging/Validation/PropertyRule`1.cs

...ssaging/source/Messaging/Dispatching/HubRequest.cs

...viceCollection/ServiceCollectionReceiveProtobuf.cs

... and 38 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Running a task slow via agent in build definition vs running directly on machine.

Agent Version and Platform
Agent 2.160.1 running on Windows Server Server 2016
What's the issue?
I have registered my dev box as an agent in one of our self hosted pool
We have a task which complies typescript files. This is a task invoked in build pipeline.
When i run build definition this task takes 7 minutes to run
If i run this task directly on my local dev box in same repo it takes 4 minutes (There is no caching involved here)
Other info
This is a process intensive task and multiple typescript files are compiled in parallel.

@sunilsurana - I am not sure what action you would like taken on this issue. It seems that your dev box is more optimized for compiling typescript files than the hosted agents we provide. We are consistently working to improve our hosted agent offerings, but you are always welcome to self host agents for improved performance for your work load.

Closing as there is not an actionable issue. If there is something else we should be looking, please open a new issue.

Hi @jtpetty
I am fine with closing of this issue till I am not able to provide reproducible steps.
But again the issue is not running on dev box vs agent. The issue is when i register my dev box as agent in private pool and run a job via agent on my dev box it is very slow compared to running it directly on dev box


Add input_text component

Description:
See also PR for polymer side of this feature : home-assistant/home-assistant-polymer#408
WIP, haven't written any documentation yet, but wanted to get feedback and relevant suggestions.
This implements an input box which can accept strings as well as integers/floats. I need this functionality to implement some features for my Elk M1 security/automation integration, and I figured better to make a generic component that others can use as well.
Client side validation of min/max range on numbers not yet implemented, and it doesn't pass tox yet.
Specifically I have lint failures due to lines that are too long (I'm not sure the preferred way to shorten these, as some are long if .. and .. conditions and one is a really long string literal), as well as 'Anomalous backslash in string' for some regex's being passed into Polymer. I suppose I could move setting those default patterns to the Polymer side of things, but lint suggests turning them into python regex with r prefix, I suspect this is not actually a good idea since I'm not using them as regex in python itself? I may misunderstand the purpose of r prefix though.
There's also no tests implemented yet.
I'm open to suggestions to change the name to something else, if anyone has a preference for it to be named something else.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):
input_box:
  box1:
    name: Box Number Test
    initial: 30
    min: -20
    max: 35
    mode: integer
  box2:
    name: Box String Test
    initial: String Test
  box3:
    name: Box Float Test
    initial: 3.2
    mode: float

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

Regarding the name, perhaps input_text or input_textbox?

I agree, please rename to input_text.
I don't think that this component should support numbers/steps/minimum/maximum at all. People can use the input_slider for that. (which should have been called input_number but it's too late now.)

@balloob
I'll change it to input_text since there's two votes for that.
Regarding patterns in frontend vs Python, I can make that work (would just have to pass the mode forward and set it in the frontend), but wanted to allow an end user (or someone extending the component) to specify a custom validation pattern if they had a use for it.
As for removing numbers & etc, I have a use for a numeric input which isn't a slider, because the range will be user-defined and can be from 0..65535 potentially, but more commonly is going to be well under 0..100 generally - however if using a larger range, using a slider to set to a precise number is cumbersome. I initially built this by copying input_slider, so steps are still in there, and I had considered adding an optional slider for numeric input (so you can use the slider or input a direct number) but I haven't taken the time to figure out how to put in two Polymer widgets together like that.
For simplicity, I'm not opposed to removing steps, but the entire reason I'm building this is to use it for primarily numeric input myself (though I have seen requests for generic text inputs / value storage so was enabling all use cases). Min/max for numeric input would be a min/max range just like it is on input_slider, while min/max for non-numeric input would be min/max limitations for text length in characters.

input_slider should be renamed to input_number and should allow an attribute that allows the frontend to switch between a slider and an input type number .
input_text should not do any number specific things. Probably also better to skip validation via patterns.

@balloob Renaming input_slider may be quite the breaking change probably ? ... but enhancing it to allow either being slider or input box could be done without breakage

I think that we can justify the breaking change, to align all the input_* components.

To summarize, proposed changes are:

input_slider : rename to input_number (breaking change)
input_number (formerly input_slider): add a configuration option to display input box instead of slider for UI (including implementing this functionality in the UI side)
input_box: rename to input_text
input_text (formerly input_box): remove number-related options
input_text (formerly input_box): remove regex pattern validation

I think we could still leave in the pattern validation as an optional thing on input_text, but not set in Python (or rather set to '' as default). Just allow a user to set it in the configuration if desired and then it's passed to the UI to use (otherwise the UI substitutes the empty pattern with [.*] or simply doesn't use validation). I don't have a particular use case off the top of my head, but it's easy to implement this way and I'm sure someone will appreciate it at some point. It would be processed entirely client-side, just passing the pattern setting if any from the configuration through to the UI.

@balloob  Do you want me to make all these changes in this PR including changes to input_slider -> input_number, etc, or do we want to handle that separately?

Please create a separate PR for change of input_slider -> input_number.

Will do. I'll finish up input_text first then, then work on the input_number PR.

Looks like Travis CI failed because Tox took too long to run ? I get various errors on unrelated code locally, but my code isn't currently throwing any tox error locally, I even have tests now...

I restarted the build for you. Glad it passed! We are having a few timeouts lately, and I am not sure what the cause is.

I just made some edits to the OP of PR, with updated yaml config examples and so on.

Don't forget:

input_text (formerly input_box): remove number-related options
input_text (formerly input_box): remove regex pattern validation

@pvizeli There's nothing specifically number related, not even the pattern validation functionality (if the user choses to use a regex pattern that only validates numbers that's on the user), which is just exposing underlying Polymer functionality.
I can remove pattern validation if that's really what everyone wants, but why not leave it in for anyone who wants it? If you don't configure it, it's like it's not even there.
Min/max are for string length not numeric range limits.
There are no number-related configuration options.

Please leave the optional validation and optional min/max length config vars.

Currently default string length min/max are 0/100, could increase default max to something much larger, or allow both to be zero and disable length checking at all in that case (and default both to zero), or just leave as-is.

Added PR for documentation.
Let me know whether the defaults and behavior for min/max length are fine as-is, or if I should change them, and if so I'll update the PRs accordingly. If defaults are fine currently, then I think input_text is complete (PRs for home-assistant itself, Polymer, and documentation repos).

Thanks for your patience with us and great work !  👍  🐬


Update Liuyixin's description page

To change the description page of Liuyixin (Mila) Shao.

Hi @leewujung and @valentina-s, I have completed the PR to revise my self-description, can you review my changes?

@valentina-s I cannot push it from my side. Can you push it? Thank you!

Ah right you don't have push permission. I'll merge it now. Thanks!


PostCSS-Import is not correctly forwarding to Webpack via addDepencyTo

Does anyone understand why PostCSS-Import isn't letting letting Webpack process all the @imports in my document instead of processing them itself? I thought my .scss files could import .less as long as my definitions were as such:
/* Webpack config PostCSS configuration section */
  postcss: function plugins(bundler) {
    return {
      import: [
	require('postcss-import')({
          addDependencyTo: bundler,
          transform: contents => contents.replace(
	      /\/\*[^~]*?\*\/|\/\/(.*)/g,
	    '/*$1*/'
          ),
	}),
      ],
      compile: [
        require('precss')(),
        require('autoprefixer')({ browsers: AUTOPREFIXER_BROWSERS }),
      ]
    };
  }

/* loader section...*/
{
        test: /\.scss$/,
        loaders: [
          'isomorphic-style-loader',
          'css-loader?' + (DEBUG ? 'sourceMap&' : 'minimize&') +
          'modules&localIdentName=[name]_[local]_[hash:base64:3]',
          'postcss-loader?parser=postcss-scss&pack=compile',
          'postcss-loader?pack=import',
        ],
      }, {
        test: /\.less$/,
        loaders: [
	  'less-loader',
        ],
      }

Why then do I get an error message about the PostCSS-SCSS trying to load my less files??
ERROR in ./~/css-loader?sourceMap&modules&localIdentName=[name]_[local]_[hash:base64:3]!./~/postcss-loader?parser=postcss-scss&pack=compile!./~/postcss-loader?pack=import!./src/components/ContentPage/ContentPage.scss
postcss-import: C:\path\to\project\node_modules\bootstrap\less\scaffolding.less:12:3: Unknown word
* {
  .box-sizing(border-box);
  ^
}

IT's as though PostCSS-Import is loading scaffolding.less, even though I'm using addDependencyTo: bundler in the first section to forward it to Webpack.

/cc @MoOx

For now postcss-import does not handle scss parser. This should be fixed soon. Please track https://github.com/postcss/postcss-import/issues/96


remove dup instructions

dotnet tool install --global dotnet-ef
Didn't you do that in a previous page?

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

ID: 6719f08e-3bd7-dc1a-71df-f2ef9fbca9d8
Version Independent ID: 7096fdb3-612e-9e00-bd0b-8ea4886a09ce
Content: Part 2, add a model
Content Source: aspnetcore/tutorials/razor-pages/model.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

This doesn't appear to be an issue with all the more recent updates. The instruction on this page seems to be the first to call out dotnet tool install --global dotnet-ef in the series.


Reverse a String in Swift

Congrats on taking the first step to contributing to the Sample Programs in Every Language repository!
For simplicity, please make sure that your pull request includes one and only one sample program and language.
Please Complete the Following

[ ] I would NOT like credit for my contribution in the article (credit will be included otherwise)
[x] I named the pull request using <Sample Program> in <Language> format
[x] I created/updated the language README

[x] I added the sample program name to the README
[ ] I added fun facts (i.e. debut, developer, typing, etc.)
[x] I added reference link(s) to the README

Notes
Feel free to put whatever you want here.
Note that Foundation is imported simply so we can exit early...

Forget what I said! I found an online editor that runs everything properly (and even lets me use the command line).

Re CommandLine picking up the file name -- I had a similar issue when running Swift for Windows. It seems like a very odd bug


Update method replaced with different methods

dev
GitHub Project

Main GitHub Project ticket

Code reviewers

[ ] @iuriikhrystiuk

Second Level Review

[ ] @sand0

Summary of issue
Update method is too big for our needs
Summary of change
Divided it to three different methods
Testing approach
Written unit tests
CHECK LIST

[ ]  PR is reviewed manually again (to make sure you have 100% ready code)
[ ]  I've checked new feature as logged in and logged out user if needed
[ ]  PR meets all conventions

/AzurePipelines run eventsexpress


The orbclient::Color returned by Image::data() isn't really the same as orbclient's Color?

I got this really weird issue, where the compiler, what I think means: orbimage's orbclient::Color isn't the same thing as orbclient's orbclient::Color,
Here's my code and the error
/*
src/texture/mod.rs:8:5: 8:35 error: mismatched types [E0308]
src/texture/mod.rs:8     data[(x + y * width) as usize]
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/texture/mod.rs:8:5: 8:35 help: run `rustc --explain E0308` to see a detailed explanation
src/texture/mod.rs:8:5: 8:35 note: expected type `orbclient::Color`
src/texture/mod.rs:8:5: 8:35 note:    found type `orbclient::color::Color`
*/

fn get_by_coord(texture: &orbimage::Image, x: u32, y: u32) -> orbclient::color::Color {
    let data  =  texture.data();
    let width = texture.width();

    data[(x + y * width) as usize]
}

However, when I turn the returned value to orbclient::Color, like this
fn get_by_coord(texture: &orbimage::Image, x: u32, y: u32) -> orbclient::Color {
    let data  =  texture.data();
    let width = texture.width();

    data[(x + y * width) as usize]
}

I still get the same error. Is it the compiler confusing something?
In my Cargo.lock, orbimage depends on the version of orbclient that I'm using,
[[package]]
name = "orbclient"
version = "0.1.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "sdl2 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)",
]

[[package]]
name = "orbimage"
version = "0.1.0"
source = "git+https://github.com/redox-os/orbimage.git#bbe01ece496f9d67681d07541554a874ed3791d4"
dependencies = [
 "orbclient 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)",
 "png 0.1.0 (git+https://github.com/servo/rust-png.git)",
]

In Cargo.toml I have this:
[dependencies]
orbclient = { git = "https://github.com/redox-os/orbclient" }
orbimage = { git = "https://github.com/redox-os/orbimage.git" }

Well, that is weird. Try using orbclient = "0.1" in the Cargo.toml

That makes it build, thanks.
Still that's an issue should be resolved, shouldn't the git repo behave the same as the library version from crates.io?

This is expected behaviour because orbimage relies on orbclient too. If the orbclient used in orbimage is a different version, the structs may be incompatible

This is expected behaviour

Well then.


BOM not removed when file contains "global"

Impact
BOM doesn't get removed when a file uses the variable global resulting in an exception in the browser when attempting to use the script.
This is probably also the cause of #1095.
Repro Steps

Download repro.zip from http://1drv.ms/1RCmzWb and unzip it
Run npm install
Run browserify index.js -o bundle.js
Open index.html in Chrome

Unexpected result: The Chrome console shows this error: Uncaught SyntaxError: Unexpected token ILLEGAL due to a BOM
Expected: "Success" is printed in the console.

@rigdern Can you publish the repro case as a public repo? I don't have a microsoft account.

@zertosh You should be able to use that link to download the file without signing in. Once the page is fully loaded, It'll show you the file and you can right-click on it and choose "Download". If that still doesn't work for you, I'll publish it as a git repo later today.

In the future please try to create repos for issues - it's much easier to just clone than to go through the download process, unzipping, etc. – anyway, yeah, I see the issue and it's because the globals wrapper is added before the BOM stripping, so when it's time to remove the BOM, it's no longer the first char.
@jmm @substack I think it makes sense to move the BOM stripping into module-deps, as soon as the file is read - before any transforms or anything. thoughts?

@zertosh

I think it makes sense to move the BOM stripping into module-deps, as soon as the file is read - before any transforms or anything. thoughts?

I should probably think it through more, but my initial reaction is that something like that sounds good. I actually ran into that on #1151 -- I added BOM detection to the pragma detection. Whereas if it worked the way you propose, that wouldn't have been necessary. Also, is there such a thing as a valid JSON file with a BOM? If so, that would currently also be borked because json comes before unbom. Is there any good use case for pushing a row or setting row.source to something that may contain a BOM between module-deps and unbom (that would outweigh having to strip BOMs yourself when doing so)?
Does everything go through the global transform? I wonder if module-deps should be responsible for changing the source in any way directly. Since unbom'ing currently takes place in browserify, maybe it makes sense to keep it there. If everything goes through the global transform it could happen there, right? (That wouldn't have helped me in the pragma situation though, but I guess that's a pretty special case.)
Is the BOM sequence valid or meaningful anywhere other than the start of a file? Could occurences of it anywhere in row.source just be stripped?
(I'm somewhat thinking out loud here.)

Also, is there such a thing as a valid JSON file with a BOM? If so, that would currently also be borked because json comes before unbom.

wow yeah, good call!

Is there any good use case for pushing a row or setting row.source to something that may contain a BOM between module-deps and unbom (that would outweigh having to strip BOMs yourself when doing so)?

None that I can think of. In fact, acorn marks them as skippable nonASCIIWhitespace.

Does everything go through the global transform? I wonder if module-deps should be responsible for changing the source in any way directly. Since unbom'ing currently takes place in browserify, maybe it makes sense to keep it there. If everything goes through the global transform it could happen there, right?

Yeah, unless you use noParse or detectGlobals: false. I think it makes sense strip it here and somewhere around here. That way it's been stripped before any transform sees it, and it covers the cases where a row has an existing source or if module-deps read the source itself.

None that I can think of. In fact, acorn marks them as skippable nonASCIIWhitespace.

Ok, thanks. So I think this comment was more in reference to this question, right?:

Is the BOM sequence valid or meaningful anywhere other than the start of a file? Could occurences of it anywhere in row.source just be stripped?

My other question was asking if there are any good use cases we know of for pushing a new row following module-deps, say by a plugin that pushes a stream that comes after module-deps but before unbom, where that row.source could contain BOM.

Yeah, unless you use noParse or detectGlobals: false. I think it makes sense strip it here and somewhere around here. That way it's been stripped before any transform sees it, and it covers the cases where a row has an existing source or if module-deps read the source itself.

Ok, thanks. Can you think of a situation where it would matter to a transform? If not then I think it can be handled by just moving unbom after deps and stripping them from source anywhere and everywhere. I'm basing that on Q: What should I do with U+FEFF in the middle of a file? and what the ES6 draft has to say about it (search for FEFF). I don't know of any good reason for that character to be included literally for any other reason than as a BOM.

My other question was asking if there are any good use cases we know of for pushing a new row following module-deps, say by a plugin that pushes a stream that comes after module-deps but before unbom, where that row.source could contain BOM.

Not that I can think of.

Can you think of a situation where it would matter to a transform? If not then I think it can be handled by just moving unbom after deps and stripping them from source anywhere and everywhere.

hmm, what if it's part of a string literal? maybe you want that there? The safest thing to do is to switch up the order of "json" and "unbom", and tweak insert-module-deps to also unbom. It already does its own unshebang, so unboming is not without some precedent. Sound good?

@zertosh

hmm, what if it's part of a string literal? maybe you want that there?

I considered that, and ordinarily I'm very conservative about that sort of thing, but I think BOM is a very special case where I'd feel comfortable saying there's no "valid" reason to have that literal character in the source anywhere / for any reason other than as a BOM. And if it were, would that not just cause the problem reported in this issue?

The safest thing to do is to switch up the order of "json" and "unbom"

Yes, this should happen if unbom continues to exist.

and tweak insert-module-deps to also unbom. It already does its own unshebang, so unboming is not without some precedent. Sound good?

insert-module-globals right? I just took a quick look at that. I think if the logic would be duplicated in more than one place maybe there should just be a module, let's call it unprefix , that strips BOM and shebang and is called from both places (insert-module-globals and unprefix phase). But I think it'd be even better if it could only happen one time in one place. I don't think it's a good idea for module-deps to alter source directly, but maybe something should be added to it that browserify (or whatever consumer) can use to apply an unequivocal source transformation before the regular transforms. Or should a regular transform be able to tell that the file had a shebang line?

A regular transform should be able to tell. Babel removes them for example. I don't mind if insert-module-globals does its own thing since it's a transform.
I also just noticed that insert-module-deps replaces the shebang with a \n, which makes sense to preserve the line numbers. This is specially important if your file already has a source map. But the unshebang step does not leave a \n behind, so if the file has a sourcemap and a shebang, there goes the line ordering.

I also just noticed that insert-module-deps replaces the shebang with a \n, which makes sense to preserve the line numbers.

Yeah, that makes sense to propagate to unshebang.
So the pipeline may as well go unbom > unshebang > json I would think. Accompanied by a new major version.

@rigdern If you update your browserify, it'll pull in<EMAIL_ADDRESS>which fixes the bug.
@jmm I'll :+1: that PR :smile:

@zertosh Awesome, it worked. Thanks for fixing this so quickly!


Create header and main for mobile view

Create and design header and main sections of the portfolio mobile version

Hi @MaganaAsiati
I do not seem to understand what changes is required of me. Please do well to help my understanding.

I called you on Zoom but you are not available

@MaganaAsiati  How do I join the zoom call? From Dashboard?


Gateway/Sidecar rejects the auto mTLS config when key cert is not ready

Bug description
TLDR, Pilot agent's readiness probe should mark the sidecar not ready util the first mTLS key cert is loaded from Citadel or other sources to avoid config push rejection.
This is more obvious w.r.t auto mTLS because key/cert is referenced in the CDS push right away...
Solution
Pilot agent its own readiness health check respect the key cert on its pod file system... Return failure if the key/cert is not ready.
we probably need to consider SDS as well somehow...

Details
When trying to turn on mTLS by default, many tests starts to fail. And interestingly they fall into some similar pattern.

This test many involves some ingress/egress gateway.
Adding some timeout retry will mitigate the test.

Let's take make e2e_dashboard as an example. The test set up some internal app echosrv and the go test program send request to <INGRESS_IP> and then with test provided virtual service route, send traffic to echosrv  app, expect request succeed or fails due to mixer policy check.
However, with mTLS enabled, we have to wait for about 30 seconds before the gateway becomes useful. Requests before that is always 503 NR (no route, per envoy doc).
So what causes the delay?
Look closely, we find in Pilot log
2019-10-21T02:35:25.915472Z     warn    ads     ADS:CDS: ACK ERROR <IP_ADDRESS>:44082 router~<IP_ADDRESS>~istio-ingressgateway-5959dfd8c-r5tjj.istio-system~istio-system.svc.cluster.local-2 (istio-ingressgateway-5959dfd8c-r5tjj.istio-system) Internal:Error adding/updating cluster(s) outbound|80||default-http-backend.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|80||heapster.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|53||kube-dns.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||metrics-server.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|10250||kubelet.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||kubernetes.default.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|8000||httpbin.default.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|80||istio-egressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-egressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15443||istio-egressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-galley.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-galley.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|9901||istio-galley.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15020||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|80||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|31400||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15029||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15030||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15031||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15032||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15010||istio-pilot.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15011||istio-pilot.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|8080||istio-pilot.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-pilot.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15004||istio-policy.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-policy.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15004||istio-telemetry.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-telemetry.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|42422||istio-telemetry.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|9090||prometheus.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|8060||istio-citadel.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-citadel.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-sidecar-injector.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-sidecar-injector.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|8080||echosrv.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|44444||netcat-srv.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|9999||netcat-client.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem
2019-10-21T02:35:31.292950Z     info    ads     Push Status: {
    "ProxyStatus": {
        "pilot_eds_no_instances": {
            "outbound_.8000_._.httpbin.default.svc.cluster.local": {},
            "outbound|8000||httpbin.default.svc.cluster.local": {}
        }
    },
    "Version": "ck4II20H7bg="
}
2019-10-21T02:35:45.333501Z     info    ads     ADS:CDS: REQ <IP_ADDRESS>:38090 router~<IP_ADDRESS>~istio-egressgateway-5cf588b56b-d8456.istio-system~istio-system.svc.cluster.local-6 715.637µs version:
2019-10-21T02:35:45.335487Z     info    ads     CDS: PUSH for node:istio-egressgateway-5cf588b56b-d8456.istio-system clusters:83 services:19 version:2019-10-21T02:35:25Z/17
2019-10-21T02:35:46.351374Z     info    ads     EDS: PUSH for node:istio-egressgateway-5cf588b56b-d8456.istio-system clusters:82 endpoints:126 empty:[outbound_.8000_._.httpbin.default.svc.cluster.local outbound|8000||httpbin.default.svc.cluster.local]
2019-10-21T02:35:46.447328Z     info    ads     LDS: PUSH for node:istio-egressgateway-5cf588b56b-d8456.istio-system listeners:0
2019-10-21T02:35:49.454685Z     info    transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2019-10-21T02:35:49.454947Z     error   ads     ADS: "<IP_ADDRESS>:37964" router~<IP_ADDRESS>~istio-egressgateway-5cf588b56b-d8456.istio-system~istio-system.svc.cluster.local-1 terminated with stream closed
2019-10-21T02:35:49.456563Z     warn    ads     EDS: Send failure router~<IP_ADDRESS>~istio-egressgateway-5cf588b56b-d8456.istio-system~istio-system.svc.cluster.local-1: rpc error: code = Unavailable desc = transport is closing
2019-10-21T02:35:51.742167Z     info    ads     ADS:CDS: REQ <IP_ADDRESS>:44300 router~<IP_ADDRESS>~istio-ingressgateway-5959dfd8c-r5tjj.istio-system~istio-system.svc.cluster.local-7 614.572µs version:
2019-10-21T02:35:51.743909Z     info    ads     CDS: PUSH for node:istio-ingressgateway-5959dfd8c-r5tjj.istio-system clusters:83 services:19 version:2019-10-21T02:35:25Z/17
2019-10-21T02:35:52.815877Z     info    ads     EDS: PUSH for node:istio-ingressgateway-5959dfd8c-r5tjj.istio-system clusters:82 endpoints:126 empty:[outbound_.8000_._.httpbin.default.svc.cluster.local outbound|8000||httpbin.default.svc.cluster.local]
2019-10-21T02:35:52.913664Z     info    ads     LDS: PUSH for node:istio-ingressgateway-5959dfd8c-r5tjj.istio-system listeners:1
2019-10-21T02:35:53.013309Z     info    ads     RDS: PUSH for node:istio-ingressgateway-5959dfd8c-r5tjj.istio-system routes:1
2019-10-21T02:35:56.114561Z     info    transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2019-10-21T02:35:56.114619Z     error   ads     ADS: "<IP_ADDRESS>:44082" router~<IP_ADDRESS>~istio-ingressgateway-5959dfd8c-r5tjj.istio-system~istio-system.svc.cluster.local-2 terminated with stream closed
2019-10-21T02:35:56.114649Z     warn    ads     EDS: Send failure router~<IP_ADDRESS>~istio-ingressgateway-5959dfd8c-r5tjj.istio-system~istio-system.svc.cluster.local-2: rpc error: code = Unavailable desc = transport is closing

In gateway log
[2019-10-21 02:35:13.167][20][warning][config] [external/envoy/source/common/config/grpc_mux_subscription_impl.cc:82] gRPC config for type.googleapis.com/envoy.api.v2.Cluster rejected: Error adding/updating cluster(s) ou
tbound|80||default-http-backend.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|80||heapster.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|53||kube-dns.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||metrics-server.kube-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|10250||kubelet.kube-system.svc.cluster.local: Invalid path: /etc/certs/cer
t-chain.pem, outbound|443||kubernetes.default.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|8000||httpbin.default.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|80||istio-egressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-egressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15443||istio-egressgateway.istio-system.svc.cluster.local
: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-galley.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15014||istio-galley.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|9901||istio-galley.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|15020||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|80||istio-i
ngressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem, outbound|443||istio-ingressgateway.istio-system.svc.cluster.local: Invalid path: /etc/certs/cert-chain.pem,

2019-10-21T02:35:40.074719Z     info    watchFileEvents: "/etc/certs/..2019_10_21_02_35_40.074588345": CREATE
2019-10-21T02:35:40.074899Z     info    watchFileEvents: "/etc/certs/..2019_10_21_02_35_40.074588345": MODIFY|ATTRIB
2019-10-21T02:35:40.074969Z     info    watchFileEvents: "/etc/certs/key.pem": CREATE
2019-10-21T02:35:40.074975Z     info    watchFileEvents: "/etc/certs/root-cert.pem": CREATE
2019-10-21T02:35:40.074980Z     info    watchFileEvents: "/etc/certs/cert-chain.pem": CREATE
2019-10-21T02:35:40.074996Z     info    watchFileEvents: "/etc/certs/..data_tmp": RENAME
2019-10-21T02:35:40.075001Z     info    watchFileEvents: "/etc/certs/..data": CREATE
2019-10-21T02:35:40.075016Z     info    watchFileEvents: "/etc/certs/..2019_10_21_02_34_29.329176922": DELETE
[2019-10-21T02:35:44.292Z] "GET / HTTP/1.1" 503 NR "-" "-" 0 0 4 - "<IP_ADDRESS>" "Go-http-client/1.1" "0a3b74b9-dcf2-468d-ba80-6a8db358d4af" "<IP_ADDRESS>" "-" - - <IP_ADDRESS>:80 <IP_ADDRESS>:46282 - -
2019-10-21T02:35:50.074985Z     info    watchFileEvents: notifying
2019-10-21T02:35:50.075180Z     info    Received new config, creating new Envoy epoch 1
2019-10-21T02:35:50.075233Z     info    waiting for epoch 0 to go live before performing a hot restart
2019-10-21T02:35:50.076077Z     info    Epoch 1 starting

So the auto mTLS CDS config is delivered as expected, but the gateway Envoy can't accept it because the referenced key/cert is not present in Envoy file system (Good job Envoy's sanity check :)
After Citadel deliver the file mount to the gateway, we find the config push is accepted, request starts to succeed as before... in a sequence.
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[X ] Security
[ X] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version)
How was Istio installed?
Environment where bug was observed (cloud vendor, OS, etc)
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

@howardjohn @rshriram @diemtvu @GregHanson
Let me know what you think. I think we can add some changes in pilot agent code to fix this...

I have seen this in real world deployment as well.
So the logic would be if mtls && !sds { wait for certs }, is that right?
I think we do have some notion of waiting for certs but apparently it's not fully effective

I think that logic is correct.  Maybe we can use sdsPath existence as the indicator to see whether SDS is enabled or not
And pass this to the readiness prober library code in pilot agent.
I feel this is a little hacky, but can't think of other better ways.

Hmm apparently we have installation option to not worry about mTLS at all.
not sds != always have a key/cert...
Users can install Istio without Citadel just for traffic management...  simpleTestsMinProfile is failing due to this.
This means our Helm needs to be further complicated as if security.enabled == false, ignore auto mTLS in globa.mtls.auto (otherwise Pilot will configure sidecar wrong...)
And also, if the security.enabled == false, pass an explicit env var or flag to the sidecar container to not have this probing check...

I dont think we need to make pilot aware of security.enabled == false. We simply need to fix the helm charts. Essentially, if security.enabled == false, [we also dont know if we would be installing citadel at a later date], we can generate the global authN policy with mtls disabled. this should take care of things on Pilot side.

The solution is to propose some changes in pilot agent for readiness check of the key/cert. We don't change Pilot implementation.