[plugin:plugin-vue-jsx] Unable to convert tsx correctly when performing server side rendering in SSR mode

Describe the bug
The jsx transpiling fails when using vite-ssr and plugin-vue-jsx at the same time.
I think this is because __default__ is not processed correctly in the following source code.
https://github.com/vitejs/vite/blob/524a0185bbb06fb13e151a37c6e0ae9d6a4ed477/packages/plugin-vue-jsx/index.js#L207-L210
The duplication procedure and my fix (I don't know if it's appropriate) can be replicated in the following repository:
Reproduction
It can be reproduced in the following repository.
https://github.com/dadajam4/vite-plugin-vue-jsx-issue-20210324
System Info
Output of npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers:
  System:
    OS: macOS Mojave 10.14.6
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 1.79 GB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.15.4 - ~/.nodebrew/current/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.10 - ~/.nodebrew/current/bin/npm
  Browsers:
    Chrome: 89.0.4389.90
    Firefox: 86.0
    Safari: 14.0.3
  npmPackages:
    @vitejs/plugin-vue: ^1.1.5 => 1.1.5
    vite: ^2.1.2 => 2.1.2

Used package manager: npm 6.14.10
Logs
9:48:22 [vite] Error when evaluating SSR module /App.tsx:
ReferenceError: __default__ is not defined
    at eval (/App.tsx:20:41)
    at instantiateModule (/Users/dadajam4/projects/develops/vite-drive/node_modules/vite/dist/node/chunks/dep-efe32886.js:68893:166)
ReferenceError: __default__ is not defined
    at eval (/App.tsx:20:41)
    at instantiateModule (/Users/dadajam4/projects/develops/vite-drive/node_modules/vite/dist/node/chunks/dep-efe32886.js:68893:166)
ReferenceError: __default__ is not defined
    at eval (/App.tsx:20:41)
    at instantiateModule (/Users/dadajam4/projects/develops/vite-drive/node_modules/vite/dist/node/chunks/dep-efe32886.js:68893:166)

Before submitting the issue, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the docs.
[x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[x] Provide a description in this issue that describes the bug.
[x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

Supplement. The fix I tried is the code below.
I think the cause is that const __default__ = defineComponent does not exist.
https://github.com/dadajam4/vite-plugin-vue-jsx-issue-20210324/blob/ae0279e43a0d88c496e811e83dd49a8f6295b1ef/.customs/plugin-vue-jsx/index.js#L208-L218

try like this
import { defineComponent } from 'vue'
import { RouterView } from 'vue-router'

const component = defineComponent({
  name: 'App',
  setup() {
    return () => <RouterView />
  }
})

export default component

@Ttou
Thank you! However, the error still did not improve.
9:48:57 [vite] Error when evaluating SSR module /pages/index.tsx:
ReferenceError: __default__ is not defined
    at eval (/pages/index.tsx:16:41)
    at instantiateModule (/Users/dadajam4/projects/develops/vite-plugin-vue-jsx-issue-20210324/node_modules/vite/dist/node/chunks/dep-efe32886.js:68893:166)
ReferenceError: __default__ is not defined
    at eval (/pages/index.tsx:16:41)
    at instantiateModule (/Users/dadajam4/projects/develops/vite-plugin-vue-jsx-issue-20210324/node_modules/vite/dist/node/chunks/dep-efe32886.js:68893:166)
Error: Couldn't resolve component "default" at "/"
    at /Users/dadajam4/projects/develops/vite-plugin-vue-jsx-issue-20210324/node_modules/vue-router/dist/vue-router.cjs.js:1998:47
(node:46700) UnhandledPromiseRejectionWarning: Error: Couldn't resolve component "default" at "/"
    at /Users/dadajam4/projects/develops/vite-plugin-vue-jsx-issue-20210324/node_modules/vue-router/dist/vue-router.cjs.js:1998:47

@Ttou
sorry. The page view component, which is injected into RouterView, has improved as well with code changes! But, why is this ...?

I have found that this approach can work around the problem.
(Thank you @Ttou !!!!!)
But
export default xxx = defineComponent (

Ideally, there should be no problem with the natural syntax of, so keep checking for problems.

Copying the default export replace block to line 220 fixes it for me
https://github.com/vitejs/vite/blob/fbecf1e5349ea5da8ff6f194efdcb152e2995398/packages/plugin-vue-jsx/index.js#L196-L202
https://github.com/vitejs/vite/blob/fbecf1e5349ea5da8ff6f194efdcb152e2995398/packages/plugin-vue-jsx/index.js#L219-L227
if (ssr) {
  if (hasDefault) {
    result.code =
      result.code.replace(
        /export default defineComponent/g,
        `const __default__ = defineComponent`
      ) + `\nexport default __default__`
  }

  let ssrInjectCode =
    `\nimport { ssrRegisterHelper } from "${ssrRegisterHelperId}"` +
    `\nconst __moduleId = ${JSON.stringify(id)}`
  for (const { local } of hotComponents) {
    ssrInjectCode += `\nssrRegisterHelper(${local}, __moduleId)`
  }
  result.code += ssrInjectCode
}


[Q&A] Do Alexa Smart Screen support Android?

Hi Team,
Do Alexa Smart Screen support Android?
As i guess, Alexa Smart Screen based on HTML rendering, so it will OK for Android, iOS, Windows,... because all of them support Web browser

Hi @AlexTraan,
Android is not officially supported by Alexa Smart Screen SDK. It is officially supported on the following platforms:
https://developer.amazon.com/en-US/docs/alexa/alexa-smart-screen-sdk/overview.html


Xcode 8.3-Swift 3.1

Goals

Realm to work with Xcode 8.3 ad Swift 3.1
Expected Results

Just runs normally
Actual Results
Module compiled with Swift 3.0.2 cannot be imported in Swift 3.1

Steps to Reproduce

Code Sample
import RealmSwift

Version of Realm and Tooling

Realm version: ? 2.4.4
Xcode version: ? 8.3
iOS/OSX version: ? MacOS 10.12.4
Dependency manager + version: ?

Thanks for getting in touch with us. We're currently preparing a new release that will be compatible with Swift 3.1 and hope to release it within the next few days.

This is still happening for me on Xcode 8.3 + RealmSwift 2.5.

@din, that's a different issue than what was originally reported here. Please file a new bug report and provide all of the information listed in the new issue template.


[Feature] Add “Boost without confirm” to the settings

This is to request a “Boost without confirm” option under settings, with its default as disabled.

Would really appreciate this, it's not dirsturbing the minimalist design, I think. Put differently, if I were to self-host this, what part of the code had to be altered? A hint would be great; is it somewhere in .../src/pages?

@LaserStefan you can check the confirm() code in boostStatus function in src/components/status.jsx.
As the web is quite hackable, it's also possible to write a userscript to tamper the confirm function, kinda like this (very rough code):
const nativeConfirm = confirm;
confirm = (t) => /boost/i.test(t) ? true : nativeConfirm(t);

Explanation: it checks if the confirmation text contains boost, if yes returns true, else works like normal confirm prompts.

Awesome, thanks! This little project has it all.

Yesterday I noticed for the first time that "Boost to everyone" gives a little extra notice if there are media without ALT text.
But I was so used to just clicking through that I didn't even have time to read the extra notice. I literally grepped through the code to find what I missed.
I like the intent behind that little extra warning a lot. As a middle ground to adding yet another preference, how about changing the default behavior a bit? Instead of showing the prompt on every boost, we could only show it on boosts where a warning would be displayed. Then it could better serve its purpose as a little extra "nudge".


Check if we do verify the TLS connection

From @sebgoa on November 28, 2016 13:8
so we verify that the server certificate was indeed signed by the certificate authority provided.
We need to be able to provide a certificate authority file, and then use it to check the validity of the cert.
this is separate from the client certificate auth step.
https://github.com/skippbox/cabin-issues/issues/13
Copied from original issue: skippbox/cabin-sw#120

From @kemcake on December 5, 2016 12:28
@sebgoa Ok I've implemented it on iOS, but I need a cluster to test it, can you send me the .cer certificate authority for the cluster <IP_ADDRESS> ? (minikube doesn't seem to use tls connection, I don't receive any challenge)


MDCT-2794 Dashboard Tests

Description
This PR replaces this other PR: https://github.com/Enterprise-CMCS/macpro-mdct-mfp/pull/113
I updated the branch name so that the deployment can successfully create an S3 bucket. My previous branch name was too many characters, causing the deployment to fail
The error from the previous PR:
Deploying uploads to stage mdct-2794-submission-name-tests (***)

CREATE_FAILED: AttachmentsBucket (AWS::S3::Bucket)
Bucket name should be between 3 and 63 characters long

The test results:
 PASS  src/components/pages/Dashboard/DashboardTable.test.tsx
  Test getStatus utility
    ✓ should render the correct status if report has been unlocked (1 ms)
    ✓ should render the correct status if report has been unlocked
    ✓ should render the correct status if report has been archived
    ✓ should render the correct status if report has been unlocked (1 ms)
    ✓ should render the correct status if report has been unlocked
    ✓ should render the correct status for SAR reports
    ✓ should render the correct status for SAR reports

Related ticket(s)

MDCT-2794

How to test

change directories to /services/ui-src
run yarn test
validate that the tests passed
Important updates

Author checklist

[ ] I have performed a self-review of my code
[ ] I have added thorough tests, if necessary
[ ] I have updated relevant documentation, if necessary

convert to a different template: test → val | val → prod

This change has no frontend updates that need validation by product. Merging this code!


Develop/3.3

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.9 out of 10 committers have signed the CLA.:white_check_mark: ViacheslavKlimov:white_check_mark: andreihoncharuk:white_check_mark: vzikratyi-tb:white_check_mark: nickAS21:white_check_mark: ashvayka:white_check_mark: smatvienko-tb:white_check_mark: ikulikov:white_check_mark: Dshcherbyna:white_check_mark: AlexDoanTB:x: AarivYou have signed the CLA already but the status is still pending? Let us recheck it.


Test khiopspydev Docker images before pushing them to the registry

Description
Currently, the khiopspydev-* Docker images are tested after they are pushed to the GitHub container registry. The goal of this issue is to test them before pushing them to the container registry, so that the risk of pushing buggy images is reduced.
Questions/Ideas

The workflow needs to be refactored: currently, the image is built, then pushed on user demand, then (if pushed), pulled and tested.
A potential way forward:

push image with temporary tag to the container registry at first, by adding a specific suffix to the image tag
pull and test this image with a temporary tag
if test is green, then:

push image with the "normal" tag (latest) to the container registry
delete the image with the temporary tag from the container registry

This seems high-priority, because without it, any modification of the Docker images that is done on a feature branch can hinder development of other feature branches if these modified images are pushed to the GitHub registry.


[SPARK-39338][SQL] Remove dynamic pruning subquery if pruningKey's references is empty

What changes were proposed in this pull request?
Remove dynamic pruning subquery if pruningKey's references is empty.
Remove useless dynamic pruning subquery because it can't reduce data.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Unit test.

cc @cloud-fan

Merged to master.


Reconsider vtkOffScreenRenderingFactory due to runtime render window selection in VTK

Since https://gitlab.kitware.com/vtk/vtk/-/merge_requests/11367 has landed, VTK is now able to detect headless operation automatically at runtime and fallback to vtkOSOpenGLRenderWindow. In order for vtkOSOpenGLRenderWindow to render correctly, it needs libOSMesa.so or it's equivalent on windows somewhere in the system library paths at runtime.
I believe Visit can drop the object factory gymnastics in https://github.com/visit-dav/visit/blob/develop/src/visit_vtk/offscreen/vtkOffScreenRenderingFactory.C

Thanks @jspanchu -- looks like a big change. Will this be in VTK 9.4.0?

Will this be in VTK 9.4.0?

Yes.
There are more links in https://discourse.vtk.org/t/status-update-runtime-opengl-render-window-selection-in-vtk/14583 that should help understand the breadth of this change.


Return proper HTTP status codes after inference

Otherwise, the test suite can miss failed tests:
https://github.com/NVIDIA/DIGITS/blob/v3.3.0/digits/model/images/generic/test_views.py#L348

@gheinrich I think this was your code originally. Can you review and merge?
That's assuming it won't interfere with your object detection PRs. If so, this can wait.

This looks good thanks.


Quasar Integration

I really like your Java implementation of Go channel a lot. Thanks for making it! Now, do you think its viable for me to attempt to make it quasar enabled?

Yeah, should be possible to create a quasar enabled channel implementation since it would be another implementation of the interface. Go for it. Don't know If I still have merge permissions to this repo though (I've left the org)


Remove context from test jobs too

In #154, I accidentally missed removing the context from the test jobs in the scheduled workflows 🤦

Looks good! Approving.

Thanks for the review! Merging now. Let's hope the 2nd time is the charm 😁


Explain QC pass / fail reasons

Rather than just binary 0/1 QC pass/fail designation, we could have insight into which component(s) failed QC, like with the beads (#89 )

To close, should enforce properties among these binary columns and the aggregate qcPass column, as well as the columns and config values on which the component columns are based.


Make littlefs magic configurable

Make littlefs superblock magic configurable.
Can be useful, for example, when:

You want to distinguish between 2 or more "visible" storage (For example, when using littlefs-fuse multiple times, and you want to distinguish between the multiple files that are created).

You want to make your storage completely unreadable (For example, in case of using the littlefs-fuse, encrypting the file that is used to manage your storage is not enough to make the file completely unreadable, as simple hd on the file will reveal the "littlefs" string..)

Hi @roykuper13, thanks for creating a PR.
Something to watch out for: The magic number may not be present in block 0.
Why this is:

Like directories, the superblock is a "metadata pair". This means that the superblock is actually a log residing on blocks 0 and 1, and the data alternates between the two blocks. This is so the filesystem can erase the other block as a part of compaction.
The reason the superblock is not entirely static is because it contains a pointer to the root directory. Which, because of copy-on-write operations, changes more often than you'd think. Because of this we actually just store the superblock as a part of the root directory itself and avoid the indirection (as of v2).

There is also an extra mechanism to prevent exhausting the superblock where if littlefs notices excessive superblock compacts (> cfg.block_cycles) it will expand a chain of indirect superblocks. This means the superblock may not even be in the anchor pair {0,1}, but instead further down the chain.
Sidenote: I've wanted to create extra superblock entries on each pair in this chain, since it could help recover a corrupted filesystem. But littlefs currently doesn't do this. It would also create some issues with out-of-date superblocks if you could change the filesystem configuration (https://github.com/ARMmbed/littlefs/issues/279).

Even if you look at the problem generically, we can't keep the magic number in the superblock, since we'd need to eventually erase block 0 before updating the block, and if you lose power, it'd lose the magic number. In theory we could make block 0 only static, but this wouldn't work on very small devices, where it's possible to put littlefs on a small two-block section of internal memory.
This is actually really annoying, it means we can't determine the block_size at mount time, since we need the block_size to read the metadata pairs! Any suggestions on how to solve this are welcome.
So building any tools that rely on the magic-number is risky.

If you're ok determining the filesystem after mount, lfs_setattr/lfs_getattr may be useful. You can assign custom attributes to the root directory, effectively adding custom fields to the filesystem:
#define MY_MAGIC_ATTR 0x6d
#define MY_MAGIC_STRING "magi"

// format
int err = lfs_format(&lfs, &cfg);
if (err) { return err; }
err = lfs_mount(&lfs, &cfg);
if (err) { return err; }
err = lfs_setattr(&lfs, "/", MY_MAGIC_ATTR, MY_MAGIC_STRING, 4);
if (err) { return err; }
err = lfs_unmount(&lfs);
if (err) { return err; }

// mount
int err = lfs_mount(&lfs, &cfg);
if (err) { return err; }
char magic[4];
err = lfs_getattr(&lfs, "/", MY_MAGIC_ATTR, MY_MAGIC_STRING, 4);
if (err != 4 || strcmp(magic, MY_MAGIC_STRING) != 0) {
    lfs_unmount(&lfs, &cfg);
    return LFS_ERR_INVAL;
}

As a sidenote:

You want to make your storage completely unreadable (For example, in case of using the littlefs-fuse, encrypting the file that is used to manage your storage is not enough to make the file completely unreadable, as simple hd on the file will reveal the "littlefs" string..)

I don't think I understand this point. If you want to make your storage completely unreadable, you need to do encryption on the entire block device, at the block level. Shouldn't this encrypt the superblock as well and hide the "littlefs" string?

@geky Thanks for the response.
Actually I didn't try to mess with the superblock magic goal/usage.. I just wanted to make the hardcoded value of "littlefs" configurable.
About the unreadable storage (Correct me if i'm wrong/missing anything) - So I'm currently using the littlefs-fuse project, and wanted to encrypt my files stored in the file created in lfs_fuse_bd_create, and generally make the file completly unreadable. I need to encrypt using AES-ECB.
Now, If i'll encrypt in the "block level", i.e encrypt the buffer that lfs_fuse_bd_prog recieves (correct me if that wasn't what you meant in "block level"), the "littlefs" would be encrypted as well.
But - imo, the better approach would be to encrypt the entire buffer passed to lfs_file_write, because as far as i understand (from reading the code and from actual testing it), lfs_fuse_bd_prog recieves chunks of the buffer that is passed to lfs_file_write. The size of each chunk is prog_size. It means that i'll have to add padding to each chunk (because lfs_fuse_bd_prog is "standalone" prog function, it shouldn't be aware if the chunk that it handles is the final chunk of the file, or the middle chunk. Also prog_size might not be dividable by AES block size.. ) -> and therefore:

the size of the file increases dramatically (With my suggested approach, I'll have to pad the buffer passed to lfs_file_write just once, so the file size only increases by the padded bytes which is up to AES_BLOCK_SIZE bytes).
the off parameter would be incorrect because it doesn't take the padding that we added to the previous chunk into consideration, so i'll have to add code to fix it.

Also from the design standpoint, i don't think that encryption/decryption code should be part ofthe block device functions, and in littlefs functions. In my project for example, I have multiple storage "contexts" (e.g - A file generated by lfs_fuse_bd_create which stores encrypted files AND a file generated by lfs_fuse_bd_create which stores plain text files, also I have a context which stores files in an allocated buffer, etc), and I have a top-level layer which wrapps them all, and it deals with encryption, decryption etc, so these contexts wouldn't have to mess with that (and therefore it'll be easy to add more storage contexts).
So with my suggested approach, the only thing that is left readable is the "littlefs" hardcoded value. Generally I believe that hardcoded values should be configurable.. it doesn't increase the size of the final binary, so i can't see why not doing that..

@geky I've changed every usage of the work "superblock magic" to simply "lfs magic" (in the code, in the commit and in the title of this PR). As far as I know I can't change the name of my branch in github (after PR is opened). Tell me if you want me to open a new PR with an updated src branch name.

@roykuper13,
I'm not sure how the proposed solution solves issue #1. It will require you to build lfs multiple times with your different LFS_MAGIC defined. I think utilizing the attributes as @geky pointed out makes sense to me.
In regard to #2, I've thought about that a bit and am curious why you want to make the WHOLE of external memory encrypted. e.g. directory information and file names. It does make sense to encrypt the file information and at that point I agree with one of your options to encrypt the file data before calling lfs_file_write. One option that I was considering for a file that is "encrypted" is to add an attribute to that file that contains information saying that the file is encrypted.
Similar to #2: Integrity checking. You could add an attribute that holds the integrity CRC for a given file.

@roykuper13,
I'm not sure how the proposed solution solves issue #1. It will require you to build lfs multiple times with your different LFS_MAGIC defined. I think utilizing the attributes as @geky pointed out makes sense to me.
In regard to #2, I've thought about that a bit and am curious why you want to make the WHOLE of external memory encrypted. e.g. directory information and file names. It does make sense to encrypt the file information and at that point I agree with one of your options to encrypt the file data before calling lfs_file_write. One option that I was considering for a file that is "encrypted" is to add an attribute to that file that contains information saying that the file is encrypted.
Similar to #2: Integrity checking. You could add an attribute that holds the integrity CRC for a given file.

Hey,
So yeah I agree with you about the 1st thing.
But this PR originally was created because of the 2nd issue: In my project, I need the entire fs to be unreadable. It doesn't necessarily mean that I need to encrypt everything, I can take other approaches regarding file names (but yeah, I need them to be unreadable as well..). But the main thing that I have no control on is the "littlefs" magic string. It seems wrong to me that a project has hard-coded values (that can't be modified) especially if they can be exposed to the user interface. Most of the times it won't affect anything, but in my specific case, IT IS a problem.
placing this magic as a lfs attribute is an option, even though it seems redundant to me, so I believe that my changes should be merged for now..
@geky @thrasher8390 what do you guys think
About the integrity&encryption attribute flags - seems to be a good idea (i think), but it is out of this PR's scope..

Hi, sorry about the slow response, your PRs deserve better than that.

In regard to #2, I've thought about that a bit and am curious why you want to make the WHOLE of external memory encrypted.

It seems reasonable to me. Encrypting the entire disk offers more security by reducing the amount of information that is available. By only encrypting the file's data, an attacker can still see the file's size, name, and do tricky things like deleting files.
The way I see it, if you're an application developer and you know what files should be there and it won't change from user to user, file-level encryption offers a performant method for securing the user's data.
If you're an OS developer or applications where you don't control the files, only encrypting the file data risks leaking information the user may be sensitive about.
It's also interesting to look at performance. On one hand, file-level encryption is faster for small files, since you encrypt the bare minimum. On the other hand, disk-level encryption (per block) can take advantage of the filesystem to split up large files across multiple encryption blocks. Though I believe file-level encryption will be faster in general.
Both approaches have merits, so littlefs is unopinionated here.

Similar to #2: Integrity checking. You could add an attribute that holds the integrity CRC for a given file.

It's worth noting you can also store an HMAC or CMAC alongside the data to provide integrity for the disk. littlefs doesn't need power-of-two block sizes, so you can slip an HMAC/CMAC in each page.

But the main thing that I have no control on is the "littlefs" magic string. It seems wrong to me that a project has hard-coded values (that can't be modified) especially if they can be exposed to the user interface.

The magic string is more similar to the version number stored next to it. It's used to sanity check that the filesystem is a littlefs filesystem and isn't corrupted. Changing either of these requires a code change because the filesystem no longer adheres to the littlefs specification. It's no longer a "littlefs".
This is what the fs-level user attribute was added for, user-specific attributes at the filesystem level that can be used to store additional info about the filesystem.

placing this magic as a lfs attribute is an option, even though it seems redundant to me, so I believe that my changes should be merged for now..

Unfortunately, as a maintainer, I need to be adverse to new features without a good strong reason. If I merge this change, I need to support it for the foreseeable future, or risk breaking backwards compatibility.
Sorry, but I don't think this should land. It's still possible to use the fs-level attributes to mark the filesystem as needed.

As far as I know I can't change the name of my branch in github

Yeah, this is a limit on GitHub's end. I wouldn't worry about it, I've seen weirder branch names.

Hi, sorry about the slow response, your PRs deserve better than that.

don't worry, it's fine :)

The magic string is more similar to the version number stored next to it. It's used to sanity check that the filesystem is a littlefs filesystem and isn't corrupted. Changing either of these requires a code change because the filesystem no longer adheres to the littlefs specification. It's no longer a "littlefs".

I'm aware that this magic string is used for the corruption check.
I don't understand why is the magic string must be "littlefs" and not a value that is configured at build-time? It does not matter what's the value of the magic string as long as the value doesn't change at run-time.
My changes just make sure that the filesystem uses that configurable magic string, and not a hard-coded value. The corruption check uses the same value, without being aware what's the value. I can't see what's the problem with that..

This is what the fs-level user attribute was added for, user-specific attributes at the filesystem level that can be used to store additional info about the filesystem.

I'm not sure how's that related to my problem.. My goal is to use other magic string instead of "littlefs", using build time configuration (so, without changing the code each time I compile lfs). How can I do that?

Unfortunately, as a maintainer, I need to be adverse to new features without a good strong reason. If I merge this change, I need to support it for the foreseeable future, or risk breaking backwards compatibility.
Sorry, but I don't think this should land. It's still possible to use the fs-level attributes to mark the filesystem as needed.

Oh, I didn't want to force you merge this of course :) I just want to find a good solution to my problem, and as of right now I can't find one..


Added user status endpoint

Codecov Report

Merging #55 into master will increase coverage by 1.04%.
The diff coverage is 81.81%.

@@            Coverage Diff             @@
##           master      #55      +/-   ##
==========================================
+ Coverage    70.4%   71.44%   +1.04%
==========================================
  Files          22       23       +1
  Lines         848      914      +66
  Branches       92       95       +3
==========================================
+ Hits          597      653      +56
- Misses        210      221      +11
+ Partials       41       40       -1

Impacted Files
Coverage Δ

src/main/java/com/authy/api/Instance.java
53.12% <ø> (ø)
:arrow_up:

src/main/java/com/authy/api/UserStatus.java
71.42% <71.42%> (ø)

src/main/java/com/authy/api/Users.java
84.68% <93.54%> (+3.43%)
:arrow_up:

src/main/java/com/authy/api/Resource.java
70.94% <0%> (+1.7%)
:arrow_up:


display alert classes by highest probability

In the explorer page, whenever someone chooses one of the classes in the drop down menu the list should show alerts in decreasing order of probability.
In this case the user would see the most probable candidates first, and build confidence/intuition for subsequent searches.

The problem is that there is no unique single score to sort against. For example, the Early SN candidates are identified using:
# SNN SN Ia
snn1 = snn_snia_vs_nonia.astype(float) > 0.5

# SNN SNe
snn2 = snn_sn_vs_all.astype(float) > 0.5

# Random forest
active_learn = rfscore.astype(float) > 0.5

# number of ZTF trigger @ 3 sigma
low_ndethist = ndethist.astype(int) < 400
early_ndethist = ndethist.astype(int) <= 20

# Real bogus
high_drb = drb.astype(float) > 0.5

# sextractor
high_classtar = classtar.astype(float) > 0.4

# SIMBAD
list_simbad_galaxies = [
    "galaxy",
    "Galaxy",
    "EmG",
    "Seyfert",
    "Seyfert_1",
    "Seyfert_2",
    "BlueCompG",
    "StarburstG",
    "LSB_G",
    "HII_G",
    "High_z_G",
    "GinPair",
    "GinGroup",
    "BClG",
    "GinCl",
    "PartofG",
]
keep_cds = \
    ["Unknown", "Candidate_SN*", "SN", "Transient"] + list_simbad_galaxies

# SN candidate filter
f_sn = (snn1 | snn2) & cdsxmatch.isin(keep_cds) & low_ndethist & high_drb & high_classtar

# Early SN candidate filter
f_sn_early = early_ndethist & active_learn & f_sn

So, in this case, we would need at least the score of the two SuperNNova module, and the score from the Random Forest. Any ideas on how to sort the results?

I would use the Random Forest score as a way of sorting for display. It is the one which is measuring Early SNe, the other ones can be high even if the supernova is already in the declining phase.

alright!

according to #73, now you can add extra columns (e.g. rfscore), and sort against it. Let me know if that solves this issue.


How to connect two robotiq FT sensors?

Hi,
My working platform is:
Ubuntu: 16.04
ROS: Kinetic
URCap 3.8
I have two robotiq ft sensors, one is FT 300 and the other is FT150.
Does this driver support to connect two sensors at the same time?
If so, how to seperate the data? Since it seems that the driver advertises the received date on the same topic "robotiq_ft_sensor" or "robotiq_ft_wrench" ?
Thanks,
Chunting

Hi @Chunting
Unfortunately, the driver currently supports only a single force-torque sensor.
Now, to achieve what you want to do, you should probably look for information about how to run multiple instances of the same node. For example, see this link. As you will see, it's possible to run multiple instances as well as to remap each node's arguments such that, for example, the nodes and their messages won't have the same names.

@jproberge wrote:

Unfortunately, the driver currently supports only a single force-torque sensor.

@jproberge: why do you say "unfortunately" here?
Running multiple instances of a single node to interface with multiple sensors seems like a proper way to implement a driver. And using namespaces and remapping are well-established practices in ROS, so unless a use-case makes it difficult, I personally always prefer to run multiple instances of a driver node that interfaces with a single piece of hw.

@gavanderhoorn , I said "unfortunately" as in "unfortunately [for you], the driver currently doesn't work this way [...]". I didn't imply that we should add a "multi-device functionality" to the driver or any other kind of modifications. I know running multiple instances is the proper way here, sorry if that wasn't clear.
This is a request I often get from customers and, in my experience, they are not all familiar nor comfortable with running multiple instances and remapping (otherwise, they probably wouldn't ask in the first place), even if it's well-established practices, which is why I said "unfortunately". Anyway, I don't think there should be any specific action taken.

Thanks for your reply.
I put the node in two different groups and now it works well.
	<group ns="$(arg right_controller_name)">
		<remap from="joint_states" to="/joint_states"/>
		<node name="ur_hardware_interface" pkg="ur_modern_driver" type="ur_driver" output="log" launch-prefix="$(arg launch_prefix)">
			<param name="robot_ip_address" type="str" value="$(arg right_robot_ip)"/>
			<param name="reverse_port" type="int" value="$(arg right_reverse_port)" />
			<param name="min_payload" type="double" value="$(arg min_payload)"/>
			<param name="max_payload" type="double" value="$(arg max_payload)"/>
			<param name="max_velocity" type="double" value="$(arg max_velocity)"/>
			<param name="use_ros_control" type="bool" value="True"/>
			<param name="servoj_gain" type="double" value="750" />
			<param name="prefix" value="$(arg right_prefix)" />
			<param name="base_frame" type="str" value="$(arg right_base_frame)"/>
			<param name="tool_frame" type="str" value="$(arg right_tool_frame)"/>
			<param name="shutdown_on_disconnect" type="bool" value="$(arg shutdown_on_disconnect)"/>
		</node>
		<rosparam file="$(find dual_arm_robot_driver)/config/right_controllers.yaml" command="load"/>
		<node name="ros_control_controller_spawner" pkg="controller_manager" type="spawner"
				respawn="false" output="screen" args="$(arg right_controllers)" />
		<node name="ros_control_controller_manager" pkg="controller_manager" type="controller_manager" respawn="false" output="screen" args="load $(arg right_stopped_controllers)" />
		<node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher"/>
		<!-- Start force/torque sensor -->
		<node name="ft_sensor" pkg="robotiq_ft_sensor" type="rq_sensor" respawn="true" output="screen">
			<param name="frame_id" type="str" value="$(arg right_controller_name)_robotiq_ft_frame_id" />
			<param name="serial_id" type="str" value="ttyUSB0" />
		</node>
	</group>

Thanks,
Chunting

Thanks for the update @Chunting !
I'm now closing this issue, good to know you were able to make it work :)


Add day wise Class Time

Summary
Add 5 new columns (for each weekday) in courses_csv.csv and assign time according to slot time table attached.
Write the code for this in a new file.
In the JSON of my courses (main.py), add the day wise time fields (fetch them from csv).
the json should look like this:
(The time format must be as given: "08:00 - 08:55 AM")
{
....
class_days: {
monday: "08:00 - 08:55 AM",
tuesday: "11:00 - 11:55 AM",
wednesday: "11:00 - 11:55 AM",
thursday: null,
friday: null
}
}
tt_slot.pdf
Note: Create pull request in 'hacktober' branch

I would like to work on this

@dhaneshragu you have assigned

@dhaneshragu you have assigned

@Hareesh-Nandigrama, done. pls check


multiple search

Hi, I know the single search, but how can I get the Multi ??  i can not make it work.
/* Single invoke */
$("#grid").bootgrid("search", "serach phrase");
/* Multi invoke (chaining) */
$("#grid").bootgrid("destroy").bootgrid("search", "serach phrase");

+1
hope support and or condition search

Do you have some solution?


use os.tmpdir() polyfill for more consistent output

The os.tmpdir() method has changed a lot between Node versions and it would be nice for users if it were consistent between Node versions. This might even prevent hard to track down bugs.
Node 0.10.38: https://github.com/joyent/node/blob/0b5731a63cc40c4fe9275c79158fe0a5dd4d1609/lib/os.js#L44-L49
io.js 2.0.1: https://github.com/iojs/io.js/blob/6c80e38b014b7be570ffafa91032a6d67d7dd4ae/lib/os.js#L25-L40
From io.js changelog:

os.tmpdir() is now cross-platform consistent and will no longer returns a path with a trailling slash on any platform

Updated os.tmpdir on Windows to use the %SystemRoot% or %WINDIR% environment variables instead of the hard-coded value of c:\windows when determining the temporary directory location.

https://github.com/sindresorhus/os-tmpdir

+1. Related https://github.com/sass/node-sass/issues/989.

LGTM

Landed in https://github.com/npm/osenv/commit/7afd6f3de9eac9ee0e8badb70c851130a43ed3ba


Cache async-std and tokio builds separately

No linked issue.
This PR:
Makes just * commands use different directories for async-std and tokio. cargo should now cache these separately, avoiding wiping the cache when switching async executors.
This PR does not:
Key places to review:

@bfish713 I think it's working now. I replaced every target/ with target/${{ matrix.just_variant }}; I think some of these might not have been necessary, but I don't think it hurts.
Since the async_std executor is actually called async-std (hyphen not underscore), I added a just variant async-std as a copy of async_std. The workflow now uses the version with the hyphen. Unfortunately, I don't think there's a way to avoid this without complicated logic either in the just cargo command or the workflow files, but this shouldn't affect anyone's local workflow.


Add callout for allowing sync of policies prior to creating a new one

Per documentation on the "Set-CaseHoldPolicy" cmdlet, there's a callout for full policy sync across an organization. We expect that this also happens during "New-CaseHoldPolicy", as it too needs to sync policies.
Adding a request here to add the "Note" outlined in the top of https://learn.microsoft.com/powershell/module/exchange/set-caseholdpolicy to this document as well.

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

ID: 3ee25f1c-d3bf-82b6-40ce-dbf4acd052dd
Version Independent ID: 46187cd1-47cd-f7c4-4720-e612eb370884
Content: New-CaseHoldPolicy (ExchangePowerShell)
Content Source: exchange/exchange-ps/exchange/New-CaseHoldPolicy.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

@MSFT-SeanG, I copied the Note over from Set to New, with some obviously required edits based on the update of existing vs. the creation of new. Unclear if everything in the update is actually true. Feel free to edit directly in the article as needed.

Note: Running this cmdlet causes a full synchronization across your organization, which is a significant operation. If you need to create multiple policies, wait until the policy distribution is successful before running the cmdlet again for the next policy. For information about the distribution status, see Get-CaseHoldPolicy.

Thanks for the feedback.
Closing


Update zh_cn.json

Pretty happy to see that this addon has been updated

Thank you for your help! It is greatly appreciated!


Add read-only shortcut to pending interrupts?

Currently to be able to see which interrupts are pending, software would have to do a LD instruction to access each clicintip.
Should we add a read-only ip status range with 1 bit per pending interrupt (similar to AIA external interrupt-pending registers eip0-eip63) so software can quickly see the state of interrupt pending bits?

It might also be useful to have a memory map view similar to AIA external interrupt-enable registers (eie0-eie63) where software can quickly enable, disable multiple interrupt enables.   xintthresh kind of allows this kind of ability, but sometimes the set of interrupt enables may be based more on functional mode instead of level priority.

would it make sense to have a software clint compatibility mode option where writes to CSR xIP, xIE is equivalent to writing to these shortcut bits?  AIA directly references CLINT xIP xIDELEG registers.   might be nice to have CLIC compatible with software like riscv-sbi ( https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc )which references xIP, xIE.  AIA compatible software will probably reference xIP, xIE also.  seems like it would be easy for CLIC to support this alternate access method for interrupt pending and interrupt enables.

just pointing out that CLIC already has defined the ability to clear clicintip via CSR:
If the pending interrupt is edge-triggered, hardware will automatically clear the corresponding pending bit when the CSR instruction that accesses xnxti includes a write

Having a compressed bitmap view of the ip and ie bits could be useful, but should be done via a memory-mapped access to the CLIC registers.  This would represent an alternative memory-mapped view of the same bits.
This should provide the needed functionality without requiring new CSRs that perform memory transactions.


Fix: base16 script failed to build with dmenu template

Duplicate of #312, which was merged in https://github.com/auduchinok/base16-builder along with other pull requests.


CMD+backspace on OS X should delete selected boxes

Many Mac keyboards do not have a delete key. CMD+backspace is the OS X standard for 'delete objects'.

This fix was lost when code was re-written to use Qt's QKeySequence predefined shortcuts.


Refactor some of the switch driver code

I think there's some stuff that can be refactored in our driver code to reduce copypasta. At the moment I think modify_port should be pushed to the top. It's almost the same for every switch.
While going through the code, I came across this line. And then there's a note in the brocade where we are unable to do this; and we do some filterting. Can someone tell my why are we doing this in the first place?
As far as I know, we don't use those Port objects anywhere, we always ever use the port name (Port.label). The deployment tests ran just fine without getting those Port objects.

ah, looks like we needed it to get the port ID so that we can remove native vlans in our console based drivers.

Here's a WIP


Cannot resolve '--white' custom property

https://github.com/TryGhost/Casper/blob/aec67d8b5fea8116d9f7baaf32adc51d75118829/assets/css/screen.css#L2168
I think it is a mistake
Technical details

Casper Version: 3.0.5
Ghost Version: N/A
Browser Version: N/A
OS Version: N/A

Fixed with https://github.com/TryGhost/Casper/commit/09d701c4bc387e6e8a44d999c57e773f08c0a571


M3-1202 Fix support ticket ordering

Fix sorting bug in the ticket landing page. Tickets should now be ordered by date updated, with the newest updates at the top.

Tickets were displaying created for both created and updated table fields.
Replaced this with the correct value.
Removed client-side sorting and added X-filtering to order results by
updated date (descending)

Coverage decreased (-0.002%) to 26.188% when pulling 288e5c20feb32c108eb4a424fda74806b005d767 on Jskobos:M3-1202-ticket-sorting into 82e8cb33608d603531e1d38f76e49d31d3c86b18 on linode:develop.


Cherry-pick PRs and release notes for v3.0.2

@lgritz, it looks like the EasyCLA check is tripped up on your commits here, can you take a look?

I would like to recommend that for the cases of cherry-picking multiple commits into release branches, that we be careful to "rebase and merge" rather than "squash and merge". I noticed that 2.4 and 2.5, in preparing for the next tag, now we have one single commit that is a mix of a dozen or more separately reviewed PRs originally from master. If a regression is later discovered, it's going to be very difficult to tease apart which of the cherry-picked patches was responsible and correct it in isolation. You can't easily bisect within a single squashed commit that implements a number of unrelated changes.
Note that this is different from the situation of an original development PR which logically is a single unit, even though it may be broken into multiple commits that were perhaps arbitrary checkpoints while the programmer was working or results from the addition of fixes during the review process -- in that case, I strongly support "squash and merge".

You're right, that's a better strategy, and it will help preserve the correspondence between commits and PR's, so make it easier to keep track of which PR's have gone to the release branch. I'll do that in the future, thanks for the suggestion.


Add autofix.ci to run stub file generation on pull request

Hi! I'm the autofix.ci troubleshooter bot.
It looks like you correctly set up a CI job that uses the autofix.ci GitHub Action, but the autofix.ci GitHub App has not been installed for this repository. This means that autofix.ci unfortunately does not have the permissions to fix this pull request. If you are the repository owner, please install the app and then restart the CI workflow! 😃

@larsoner Could you enable autofix.ci for this repo? I (again) missed the non-updated stubs before the release, adding an autofix on PRs should make it less likely.


Failed to load plugin 'import' [...] intrinsic %Symbol.species% does not exist

When running Eslint (installed locally) on my project via VS, I get the generic error Failed to apply ESLint fixes to the document. Please consider opening an issue with steps to reproduce..
With "eslint.debug" to true, and "eslint.trace.debug.server" to verbose, this is the trace from the output channel :
[Trace - 9:38:45 PM] Sending request 'workspace/executeCommand - (26)'.
Params: {
    "command": "eslint.applyAllFixes",
    "arguments": [
        {
            "uri": "file:///[...PATH...]/hosting/src/App.js",
            "version": 1
        }
    ]
}

[Trace - 9:38:45 PM] Received response 'workspace/executeCommand - (26)' in 29ms. Request failed: Request workspace/executeCommand failed with message: Failed to load plugin 'import' declared in '.eslintrc.json » eslint-config-airbnb » [...PATH...]\hosting\node_modules\eslint-config-airbnb-base\index.js » [...PATH...]\hosting\node_modules\eslint-config-airbnb-base\rules\imports.js': intrinsic %Symbol.species% does not exist! (-32603).

[Trace - 9:47:36 PM] Received request 'workspace/configuration - (261)'.
Params: {
    "items": [
        {
            "scopeUri": "file:///[...PATH...]/hosting/.eslintrc.json",
            "section": ""
        }
    ]
}

[Trace - 9:47:36 PM] Sending response 'workspace/configuration - (261)'. Processing request took 2ms
Result: [
    {
        "validate": "off",
        "packageManager": "npm",
        "codeActionOnSave": {
            "enable": false,
            "mode": "all"
        },
        "format": false,
        "quiet": false,
        "onIgnoredFiles": "off",
        "options": {},
        "run": "onType",
        "nodePath": null,
        "workingDirectory": {
            "mode": "auto"
        },
        "workspaceFolder": {
            "name": "hosting",
            "uri": "file:///[...PATH...]/hosting"
        },
        "codeAction": {
            "disableRuleComment": {
                "enable": true,
                "location": "separateLine"
            },
            "showDocumentation": {
                "enable": true
            }
        }
    }
]

Running it via the terminal does work as expected.
Package.json :
{
  "name": "",
  "version": "2.0.3",
  "private": true,
  "dependencies": {
    "bootstrap": "^4.4.1",
    "prop-types": "^15.7.2",
    "react": "^16.13.0",
    "react-app-polyfill": "^1.0.6",
    "react-bootstrap": "^1.0.0-beta.17",
    "react-dom": "^16.13.0",
    "react-markdown": "^4.3.1",
    "react-redux": "^7.2.0",
    "react-router-dom": "^5.1.2",
    "redux": "^4.0.5"
  },
  "devDependencies": {
    "eslint": "^6.8.0",
    "eslint-plugin-import": "^2.20.1",
    "eslint-config-airbnb": "^18.0.1",
    "eslint-plugin-react": "^7.18.3",
    "react-scripts": "^3.4.0"
  },
  "scripts": {
    "lint": "eslint src/**/*.js --fix",
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": [
    "> 0.01%",
    "not ie <= 8",
    "not op_mini all"
  ]
}

.eslintrc.json :
{
    "env": {
        "browser": true,
        "es6": true
    },
    "extends": [
        "airbnb",
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "globals": {
        "Atomics": "readonly",
        "SharedArrayBuffer": "readonly"
    },
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 2018,
        "sourceType": "module"
    },
    "plugins": [
        "react"
    ],
    "rules": {
        "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],
        "linebreak-style": ["error", "windows"],
        "indent": ["error", 4],
        "react/jsx-indent": ["error", 4],
        "jsx-quotes": ["error", "prefer-single"],
        "react/jsx-indent-props": ["error", 4]
    }
}

@TomKauffeld can you please provide me with a GitHub repository I can clone that demos what you are experiencing. Without the same setup things like this are very hard to track down.


ci: Verify tags before building

- What I did
Guard against a mismatch between version.dart and the GitHub tag for:

dockerhub sshnpd
https://github.com/atsign-foundation/sshnoports/actions/runs/6045156860

multibuild
https://github.com/atsign-foundation/sshnoports/actions/runs/6045158188

Note that I used a different git tag than the version in version.dart on purpose to ensure that these workflows fail when they are supposed to.

- How I did it
- How to verify it
- Description for the changelog
ci: Verify tags before building

Grest check ty


dark mode fixes

#331 and other things I see

update TokenInputAmount.vue to accept a default token logo if a logo prompt is not defined
update your component not to have a ViewToken but ViewModalToken instead
go from [0] to a
const bnt =  vxm.bancor.tokens.find(token => compareString(token.symbol, 'BNT')
if (bnt) {
return the symbol + image
otherwise just return the symbol

update TokenInputAmount.vue to accept a default token logo if a logo prompt is not defined
update your component not to have a ViewToken but ViewModalToken instead
go from [0] to a
const bnt =  vxm.bancor.tokens.find(token => compareString(token.symbol, 'BNT')
if (bnt) {
return the symbol + image
otherwise just return the symbol


System.DllNotFoundException: Unable to load DLL 'PenIMC_cor3.dll during startup

Microsoft PowerToys version
0.63.0
Running as admin

[X] Yes

Area(s) with issue?
General
Steps to reproduce
It automatically trigger when i switch on laptop.
✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
2022-10-15.txt

/bugreport


Set editing polygon border color by basemap type

Overview
This PR adds code to update the editing polygon's border when the basemap is changed. If the basemap is Satellite, the border will be white, otherwise the border is black.
Closes #56
Demo

Notes
Information about the border type could be moved to the basemap components. Then when the basemap components are mounted, they can set the border type in state. The polygon would read this value from state and update accordingly. I didn't do this for this PR because the card asks for the simplest/easiest solution.
Testing Instructions

Go to Draw Page
Add a polygon
Change the basemap
Default and Land and Water basemaps should have the dark border, while satellite should have the light border.

Checklist

[x] fixup! commits have been squashed
[ ] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
[x] README.md updated if necessary to reflect the changes
[ ] CI passes after rebase

Taking a look at this now.


No way to configure metadata IP/port

Felix now expects the metadata address to be in etcd but the plugin isn't writing it there.

A customer hit this and it's blocking them; I've offered them a patch that reinstates the old behaviour (loading from the config file) while we get this sorted.

The customer says that, in their infrastructure, the metadata IP will be different on each node and it's not known by neutron.  I'm wondering whether we need to be flexible about where we get our configuration from in order to support such cases.  How about we use the same key names in the config file, etcd (global and per-host scopes), and our environment variables (for docker support) and inherit missing config from further up the hierarchy:

environment variables trump all (only used in docker or manual execution so feels like these should win)
config file trumps etcd config
per-host etcd config trumps global etcd config
global etcd config has lowest priority.

I can get behind this principle, except that the relationship between per-host ETCD config and the config file seems wooly. There's no obvious stable ordering there. Any reason we shouldn't use something like confd to ensure that the two data sources are forcefully kept in sync?

Some details that I don't understand here...

Firstly, what precisely is the Metadata configuration requirement? In the absence of any configuration, I believe the default is localhost:8775. Is the customer's requirement here to have the metadata API running on just one node, and hence to require a specific IP instead of localhost? Does that IP need to change dynamically during the life of the cluster?

Secondly, I believe the architecture now is (a) for such configuration to be provided, where necessary, via the etcd data model (instead of felix.cfg); (b) to regard the etcd data model as a public API that Calico customers / integrators can write to, in addition to (say) the OpenStack plugin writing to it.

Hence, if a particular deployment requires metadata  and , I thought the architecture for that would be for that deployment to do
etcdctl set /calico/v1/config/MetadataAddr <addr>
etcdctl set /calico/v1/config/MetadataPort <port>

Is there something about that picture that is wrong, or that doesn’t meet the customer requirement?
Certainly we could also add a plugin setting, to get it to set these values, but I don't think that's necessary. And I don't understand at all why it's being discussed to reintroduce felix.cfg settings.

I understand now that the requirement is for the metadata IP to be different on different compute hosts. In that case the architected solution (as I understand it) is for the deployment to set /calico/v1/host//config/MetadataAddr to the desired value, for each .

Sorry, markup glitch. That key should be:
/calico/v1/host/<hostname>/config/MetadataAddr

@Lukasa agree, there's no obviously right ordering between config file and etcd.  My reasoning was that etcd is transient and so writing anything into that is non-trivial; it requires handling the case where etcd needs to be rebuilt.  If etcd overrides the config file then we need to make sure that the most specific corner cases are covered by the code that writes into etcd, whereas if the config file overrides etcd, we can make deployment-specific tweaks more easily.  If we do have the code in place to do the overrides in etcd then there's no need to write anything into the config file so just don't use it.
@neiljerram etcd isn't the master datastore in OpenStack so who writes that data?  If it's the plugin, then it needs a second master database of the relevant IPs (this particular customer is using the local routable IP of the host rather than binding to localhost).  Another customer might use an IP we haven't thought of.

I agree @fasaxc that the etcd data store is not the master data store in many cases.  In OpenStack it is a key part of our architecture that etcd can be blown aware at will and the OpenStack plug-in will repopulated it with Felix and other listeners being robust to that happening (i.e. in networking terms, graceful restart with non-stop forwarding rather than non-stop routing).
I'm also curious whether this is case of Felix having OpenStack specific configuration.  If so that feels wrong to me long term, though I don't think it should hold up the release (and may not even need resolving in 1.0 timeframe so long as we are all clear about any compromises we are therefore making,  what our long term plan is and how we will get there).

Do we really need different metadata IPs on different compute nodes?  That wasn't my understanding of this requirement.

There's an interesting question here - which component owns writing the configuration into etcd? If that's the plugin, fine - but I'm not sure that it actually is. If it isn't, then there's a question of what the process to nuke and rebuild looks like.

I'm pulling this issue out of 0.16 and renaming it.
The original report in this issue, that the metadata address and port could not be configured, is not valid: they can, via etcd. This issue has now turned into allowing multiple configuration sources and composing them together. It's a worthy goal, but not for 0.16.
For the moment I'm punting to 0.17, but if this doesn't get picked off the pile by then I'll punt to 1.0.

Here's my 2 pence worth on this one:  The original report was not invalid.  The customer is an OpenStack based deployment using our plug-in.  In that scenario our design goal was that the use of etcd should be as transparent as possible.  In particular, it is not the master data store so can be blown away at anytime (e.g. the 3am support call), and the customer does not need to manage data in etcd themselves (the plug-in does this behind the scenes).  As I understand it, we recently moved the metadata configuration from a local file to etcd only.  That does not fit with our design goals and I think is a valid bug.
@plwhite - In an OpenStack deployment the plug-in is responsible for populating etcd (except for the bits that Felix updates to report back state of course).
@Lukasa - I'm fine with broadening the issue to address config more holistically (I think that's a good thing).  But I don't want the validity of the original issue to get lost.  At this stage I expect that (even taking into consideration my 2 pence worth of comments above) it's too late to change this back to 0.16, but shout if not.

Just a couple of notes since this discussion started because of me:

The requirement for having a different metadata IP on each node should no longer be necessary.  I dug into why we were doing this, and apparently it's no longer necessary because we're no longer supporting the thing that required it.  Binding to <IP_ADDRESS> should be fine going forward.

In the larger/future picture, I do like being able to make runtime config changes via etcd.  However as mentioned, currently we will be running etcd in a ramdisk and therefore it's volatile.  It would be tricky to get config changes back in after the backing data is destroyed.  I think it's definitely necessary to have some sort of host based config that isn't in etcd.  Right now I'm battling the same issue with the log settings.  The log settings are an interesting case, since they should be applied before any logging would be possible, e.g. before any connection attempts (which generate useful logs) would be made to etcd.

I have a fix for this in branch issue407config - but it breaks a couple of UTs, so I'll have to wrap it up tomorrow.


Problems with matter when running parallel to webpage hosting (CON-1055)

Describe the bug
esp fails to initialize and use advertiser
Environment

ESP-Matter Commit Id:
ESP-IDF Commit Id:
SoC: ESP32C3
Device Logs (Please attach the log file):
Host Machine OS: MacOs

Hi, i have code that hosts a webpage on a network in STA mode (esp is client in network and is hosting a webpage). On this webpage there is a button that if clicked turns matter on and makes the device discoverable and and controllable through matter while keeping the input possibility from the hosted webpage. Now at this point there are two tasks running. One with the webpage stuff with idlestatus priority and another one that starts the matter part that has priority idle + 1.
When i start matter, i get the below added logs. With the chip tool i tried to connect to the esp with onnetwork pairing but it seems the device is not even found (nodeid and passcode are guaranteed correct). When using amazon alexa to discover the device, the device is found but Alexa tells me to enter wifi creds in a loop while never fully connecting. (2nd logs).
The code to start matter i used is err = esp_matter::start(app_event_cb);
Maybe someone here has an idea what exactly is going wrong or what i can change. The matter code is 99% based on the light example from esp-matter.
1.pdf
2.pdf

Hi, the logs show a LwIP error ERR_USE(-8). It means that the mDNS port(5353) of minimal mDNS was used by another pcb. Could you check whether you are using the mdns component https://github.com/espressif/esp-protocols/tree/master/components/mdns? If yes and you are not going to remove it, please disable minimal mDNS and use platform mDNS instead.
CONFIG_USE_MINIMAL_MDNS=n

Perfect thank you. Yes i was using the mdns component for the webpage hosting. Turning off the minimal dns actually got rid of the issue. I'm assuming by platform mdns you are referring to the mentioned component? And how did you connect the error code to mdns? i wasnt able to find a list of the error codes.
However now the esp seems to be impossible to find as a matter device, though there are no more errors. Could this be related to turning off minimal mdns or is it as i suspect unrelated?

I'm assuming by platform mdns you are referring to the mentioned component

Yes, the platform mdns is using the mdns component I mentioned.

And how did you connect the error code to mdns? i wasnt able to find a list of the error codes.

The logs say E (29017) chip[DIS]: Failed to initialize advertiser: 3000008. It is from the minimal mDNS part and the error code is 0x3000008. The range is 0x3 so it's a LwIP error. And the LwIP error code is -8(ERR_USE). Normally it happens when a port is duplicately used. But 5353 is a special port for mDNS. So I guess that you are using mdns component.

However now the esp seems to be impossible to find as a matter device, though there are no more errors. Could this be related to turning off minimal mdns or is it as i suspect unrelated?

Maybe you can try to resolve the operational node service and see whether the service is advertised by your device? Looks like there are some issues on the order of mdns component APIs calling.

Turns out the device was actually visible. Sry my mistake. Thank you for the explanation.
Everything works now but after 2-3 minutes the webserver will suddenly stop answering while the matter interface works just fine. I dont get this issue when i dont start matter and the webserver works indefinitely. Does anybody what the problem could be here? There are no errors given.

So some testing showed that the webserver only stops responding if i don't message it for more than a minute. If i contiously send messages with less time than 1 min between them it will keep responding.

Unfortunately not closed yet. While keeping the connection alive with pings works, once i close the web tab and open a new to connect to the webserver it is unresponsive again. It must have something to do with sessions being closed and unable to be reopened again but unfortunately i cant seem to find out exactly what.

So i found out that there is no way to keep the hostname.


SagaLightBlub highlight not themeable

Describe the bug
I set my code_action config to a nerdfont light bulb icon.
When I specify SagaLightBlub highlight it doesn't get applied to the icon.
Steps to reproduce

set light bulb icon (not emoji)

ui = {
  code_action = "",
}

run :hi SagaLightBlub guifg=#ff0000 guibg=#00ff00
light bulb does not change color

Expected behavior
should be themeable like before the lspsaga update
Neovim version (nvim -v)
NVIM v0.8.3
lspsaga commit
latest (bd55b175a4546334a197821cd4bfc19ba94e1a82)
Terminal name/version
iterm 3.5.0beta10

@glepnir Your recent change only fixed the sign column but not the virtual text. I am only using the virtual text and have sign_column disabled.

fixed


How to get a specific USB camera?

At present, I know that the camera can be obtained by a given name, but I cannot confirm which camera it is. I want to know whether the corresponding USB camera can be obtained by the USB camera similar to the hardware id. I don’t seem to find the corresponding api.

@shichiye
There is no such API in the Webcam Capture project. What we have here is a very basic abstraction over the UVC device. There is no API to get the USB information. Even if we go into the lower level and dive deep into the native C++ code, there is no such thing as well. The operating system abstracts the device and completely decouples it from the USB transport.
One could in theory use some 3rd party library like usb4java to scan the ports and correlate UVC data from Webcam Capture with the hardware device class present in the USB port, but I never tried this and cannot even tell if such thing is possible. This is just a brief idea that came into my mind.

I'm working on publishing as open source a native driver capable of providing actual device ids and very good performance. For the moment it will work on Windows only. Maybe tomorrow it's ready, I will reply back.
We use the driver in a production app and works really well.

Hi,
I just published the driver here: https://github.com/eduramiba/webcam-capture-driver-native
Please let me know if you try it successfully or you have any problem.
To get the device id you will need to cast WebcamDevice to CaptureManagerVideoDevice

@sarxos @eduramiba Thank you both for your answers.
I will try it, and then I will reply to you @eduramiba

Could be possible to know the id device of the USB with the relative istance ?
USB\VID_0C45&PID_6366&MI_00\6&183AF011&0&0000

Could be possible to know the id device of the USB with the relative istance ?
USB\VID_0C45&PID_6366&MI_00\6&183AF011&0&0000

Yes, you can with https://github.com/eduramiba/webcam-capture-driver-native and casting WebcamDevice to WebcamDeviceWithId

Could you help me with an example in pure Java... I tried to follow the tutorial but after loading the dll no output of which webcam is connected to the computer. Without loading dll everything is working well. i tried to contact you on twitter also.

Also dll are loaded in the project Netbeans as in photo.

I also tried to put in same place where opencv read it's own dll. OpenCv could work well without any issue but this driver won't work....

@pacioc193 This library tries to load its DLLs from the natives folder relative to where the program is executed. Adding to netbeans or as jar won't do anything.
Please make sure to run your program in a folder where natives is located. Also I recommend setting up a slf4j backend such as logback for viewing logging messages.

It works. Was a matter of libraries... I'm not using maven project... Standalone application developing here.
Thanks for the support

@pacioc193 Great! 😄

I think the best ways to solve this issue in the future... release a zip file with all the dependency ahah


feat(remote-access): support reading child connection string from stdin

Proposed changes

Support reading the c8y message/connection string from standard input when using the convention  --child -. Typically - refers to standard input (e.g. see gnu coreutil cat)
This improves compatibility with other components such as systemd sockets where the socket data is feed via stdin.
Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue
https://github.com/thin-edge/thin-edge.io/issues/2859
Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[x] I ran cargo fmt as mentioned in CODING_GUIDELINES
[x] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

@jarhodes314 Can you please take over this PR to add some unit tests? We're still working out a way to run some unit tests for the Cumulocity IoT Cloud Remote Access feature but this will be covered in a different PR.


There's a question here

app := iris.New()

app.PartyFunc("/users", func(users iris.Party) {
    users.Use(myAuthMiddlewareHandler)

    // http://localhost:8080/users/42/profile
    users.Get("/{id:int}/profile", userProfileHandler)
    // http://localhost:8080/users/messages/1
    //users.Get("/inbox/{id:int}", userMessageHandler)There's a question here
    users.Get("/messages/{id:int}", userMessageHandler)//Right?
})

You mean the comment and the declaration below don't match, it's fixed now. Thanks a lot. Note that I am preparing a new Iris wiki and an e-book for the upcoming version, stay tuned!


Deadname remover doesn't work with chosen name that doesn't have a middle name

My chosen name does not have a middle name (at least as of yet), but when Deadname Remover removes my full legal deadname, it keeps my former middle name.
Instead of:
(Deadname First) (Deadname Middle) (Deadname Last) > (Chosen First) (Chosen Last),
the result is:
(Deadname First) (Deadname Middle) (Deadname Last) > (Chosen First) (Deadname Middle) (Chosen Last)

@quarlessam
I have no idea if it'll work, but you could use a zero-width unicode character as your chosen middle name until you pick one out to solve this issue.

That's a great suggestion @GITwithWillow , and I'd imagine that will work. I believe this will be solved unintentionally in version 2.0.0 @quarlessam , but I'll keep this bug report on my radar to ensure it's fixed


@does + default kwargs don't work

Short description explaining the high-level reason for the new issue.
Current behavior
It breaks, dependencies marked as optional are not carried over.
Stack Traces
(If applicable)
Screenshots
(If applicable)
Steps to replicate behavior
from hamilton import driver
from hamilton.function_modifiers import does
from hamilton.ad_hoc_utils import create_temporary_module

def _identity(**kwargs) -> int:
    return 1

@does(_identity)
def foo(bar: int=1) -> int:
    pass

h_dr = driver.Driver({}, create_temporary_module(foo))
h_dr.raw_execute(['foo'])

python ./demo-hamilton-bug.py
Traceback (most recent call last):
  File "/Users/elijahbenizzy/dev/hamilton-os/sf_nlp/etls/./demo-hamilton-bug.py", line 14, in <module>
    h_dr.raw_execute(['foo'])
  File "/Users/elijahbenizzy/dev/hamilton-os/hamilton/hamilton/driver.py", line 147, in raw_execute
    self.validate_inputs(user_nodes, inputs)  # TODO -- validate within the function graph itself
  File "/Users/elijahbenizzy/dev/hamilton-os/hamilton/hamilton/driver.py", line 102, in validate_inputs
    raise ValueError(error_str)
ValueError: 1 errors encountered:
  Error: Required input bar not provided for nodes: ['foo'].

Library & System Information
E.g. python version, hamilton library version, linux, etc.
Expected behavior
This should work
Additional context
Add any other context about the problem here.

This is fixed!


Troubles viewing source

Hello,
We had upgraded to angular-jsdoc 1.3.3, when realized that few things become broken on attempt to use 'angular-template' template:

Modules in application using dot to separate name in namespace looking like wkfsfrc.ui.widgets ; generated documentation looking pretty and nice, but all underlying service and directives sources link are wrong.
In name of each service/directive there an # character , like wkfsfrc.ui.widgets#wkfsfrc-auto-height, rendering that source anchor also having it :
source
where correct syntax should be
source

Strangely this does works by using default template.

For some reason all { @link } pointers to services implemented in same module had stopped working.

For example, next {@link wkfsfrc.ui.widgets#AutoHeightService} would expect to create anchor to service implementation, that defined as this:
/**      * @memberof wkfsfrc.ui.widgets      * @ngdoc service      * @name wkfsfrc.ui.widgets#AutoHeightService      * @description      *
      *     Service for calculating automatically the height of a component based on the height of the screen and a specified margin. A margin will specify the number      *     of pixels of the total screen height that the component will not use.      *     Allowed margins can be defined by decorating the wkfsfrc.ui.widgets#AutoHeightMargins provider and returning an object containing properties      *     for each margin.      *     Ex.      *          $provide.decorator('AutoHeightMargins', function($delegate) {      *              return {'default': 300, 'narrow': 150};      *          });      *
      */
This does not work on both templates (default and angular-template)
Will try to debug both issues later on during coming days, but if it sounds familiar or there some bright idea what those could be...

I had modified slightly publish.js of angular-template on line 247:
    if (doclet.meta) {       if (doclet.kind == 'class') {         doclet.sourceUrl = 'source/'+           encodeURIComponent(sourceCodes[doclet.name].longname)+           ".html#line"+doclet.meta.lineno;       } else if ( (doclet.kind == 'function' || doclet.kind == 'member') &&         sourceCodes[doclet.memberof]) {         doclet.sourceUrl = 'source/'+           encodeURIComponent(sourceCodes[doclet.memberof].longname)+           ".html#line"+doclet.meta.lineno;       }     }
By adding encodeURIComponent JS call on longname, and this does the magic for this.
Could this be incorporated in one of next releases ?

This might have been fixed with 1.4.0. If not, please reopen.


[Snyk] Upgrade react-virtualized-auto-sizer from 1.0.3 to 1.0.4

Snyk has created this PR to upgrade react-virtualized-auto-sizer from 1.0.3 to 1.0.4.
As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released a month ago, on 2021-01-15.

Release notes

Package name: react-virtualized-auto-sizer

1.0.4 - 2021-01-15

1.0.3 - 2020-12-19

    from react-virtualized-auto-sizer GitHub release notes

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

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


Cannot login to Google on Linux Mint - Secure storage issue

Just installed electron via Snap on linux mint and when i tried to log into youtube, got the following error. I know on my home pc (using ubuntu with i3) that I can log into Netflix and Youtube.

I don't know what is causing that issue for you. I am able to login to Youtube on my computer. Can you reproduce it on another computer? I am on a Mac could it be due to Linux? (I currently don't have a Linux computer but I will check this issue when I have one).

the problem is two-factor authentication, I also have this error.

I just tried logging in and it is working now. I didn't have 2FA enabled for my google account at the time, so I don't think it is related to 2FA

I tried with 2 accounts, with and without 2FA. the account with 2FA has the problem.

Can you try clicking Learn more (maybe send me the link) because I do not know what is causing this? Possibly it is user agent related but I am not sure.

It redirects you to this page: https://support.google.com/accounts/answer/7675428
Saying

These and other browsers support JavaScript:
Chrome
Safari
Firefox
Opera
Internet Explorer
Edge

yup still an issue.
Same here. Ubunutu. Google. Can we not just fake the User Agent or something?

its work thanks for the tips, add this  in the config file:

"userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0"

no worries. Hacky to help. ;)

@oscartbeaumont any chance of?  I feel a 🔐 coming on. And everyone likes a closed...

I have already fixed the issue in version 3.0.0 but it hasn't been released or pushed to git because it's a complete rewrite of the app and is still missing functionality. I will finish it when I get some time and publish it.

Where do I put the userAgent line? My config.json file looks like this and it does not work:
{ 	"version": "2.0.8", 	"services": [], 	"_do_not_edit___date_":<PHONE_NUMBER>581, 	"userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" }

You can view the example config here which shows it is on a per service basis (specially Youtube TV which changes its user agent). In the next release of the app I think i'm going to default the user agent to be the default for a Chrome installation on your respective OS to prevent issues like these happening and hopefully add a GUI for settings to make it much easier and less confusing like it is now. Currently there is no global user agent modifier.

Same issue on youtube (cannot connect to google)
ubuntu 20.04, ElectronPlayer 2.0.7
config settings:
{
"version": "2.0.7",
"services": [
{
"name": "Netflix",
"logo": "services/netflix.png",
"url": "https://netflix.com/browse",
"color": "#e50914",
"style": {}
},
{
"name": "YouTube",
"logo": "services/youtube.svg",
"url": "https://youtube.com",
"color": "#ff0000",
"userAgent": "Mozilla/5.0 (SMART-TV; Linux; Tizen <IP_ADDRESS>) AppleWebkit/605.1.15 (KHTML, like Gecko)",
"style": {}
},
{
"name": "Twitch",
"logo": "services/twitch.svg",
"url": "https://twitch.tv",
"color": "#6441a5",
"style": {}
},
{
"name": "Floatplane",
"logo": "services/floatplane.svg",
"url": "https://floatplane.com/",
"color": "#00aeef",
"style": {}
},
{
"name": "Hulu",
"logo": "services/hulu.svg",
"url": "https://www.hulu.com/",
"color": "#00aeef",
"style": {}
}
]
}
do you know what is the problem ? Thank you !

@jcsekinger you've put a different userAgent than the one suggested.
xMase suggested
"userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0"
but you put
"userAgent": "Mozilla/5.0 (SMART-TV; Linux; Tizen <IP_ADDRESS>) AppleWebkit/605.1.15 (KHTML, like Gecko)".
Note: you don't need to put the configs for all sites, just the ones where you've made changes are enough, i.e.
"services": [
    {
        "name": "YouTube",
        "logo": "services/youtube.svg",
        "url": "https://youtube.com/",
        "color": "#ff0000",
        "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0",
        "style": {},
        "permissions": []
    }
],

@Syndamia @oscartbeaumont
it doesn’t work either – and I tried several user agents without success
«navigateur non sécurisé»
any idea ?

Maybe try adding the following as a service and open it to login, then you could probably remove it.
{
    name: 'Google Login',
    logo: 'services/youtube.svg',
    url: 'https://accounts.google.com',
    color: '#ff0000',
    style: {},
    userAgent: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84",
    permissions: []
},

Please report back if this works as I have not tested it.

@jcsekinger I also wanna mention that you are on an older version of the app, 2.0.7 (which is more than an year old) as opposed to the newest one, 2.0.8, from a couple of months ago.
I don't know if that makes a difference for this problem though.

@oscartbeaumont
same issue… doesn’t understand
any other idea ? :)
thank you

@oscartbeaumont @Syndamia
Do you have a complete exemple of the settings for the 2.0.8 (I have an appimage) ?
for now, the settings are just :
{
"version": "2.0.8",
"services": [],
"do_not_edit___date":<PHONE_NUMBER>436
}

@oscartbeaumont this is my configuration file (without some other settings I have set up)
{
        "version": "2.0.8",
        "services": [
                {
                        "name": "YouTube",
                        "logo": "services/youtube.svg",
                        "url": "https://youtube.com/",
                        "color": "#ff0000",
                        "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0",
                        "style": {},
                        "permissions": []
                }
        ],
        "_do_not_edit__date":<PHONE_NUMBER>597,
        "options": {},
        "relaunch": {}
}

@oscartbeaumont this is my configuration file (without some other settings I have set up)
{
        "version": "2.0.8",
        "services": [
                {
                        "name": "YouTube",
                        "logo": "services/youtube.svg",
                        "url": "https://youtube.com/",
                        "color": "#ff0000",
                        "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0",
                        "style": {},
                        "permissions": []
                }
        ],
        "_do_not_edit__date":<PHONE_NUMBER>597,
        "options": {},
        "relaunch": {}
}

ça marche !!! (j’en oublie l’anglais) It works ! Thank you !

@oscartbeaumont this is my configuration file (without some other settings I have set up)
{
        "version": "2.0.8",
        "services": [
                {
                        "name": "YouTube",
                        "logo": "services/youtube.svg",
                        "url": "https://youtube.com/",
                        "color": "#ff0000",
                        "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0",
                        "style": {},
                        "permissions": []
                }
        ],
        "_do_not_edit__date":<PHONE_NUMBER>597,
        "options": {},
        "relaunch": {}
}

i cant seam to get this to stay it just reverts back to the defalt config file is thare a way to stop this?


Label quarantined test_id:1202 with sig-network

Signed-off-by: Or Mergi<EMAIL_ADDRESS>
What this PR does / why we need it:
Currently the test id 1202 [test_id:1202][posneg:positive]with working HTTP probe and http server, no ip family is specified
is quarantined.
This PR label this test with [sig-network] label in order to run it as part of sig-network lane
it will help with debugging this test more efficiently and check its stability for moving it out from quarantine.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

/cc @fgimenez @phoracek @EdDev @AlonaKaplan

Why not move the whole probe tests? Aren’t them all network related?

/close
moved to #5268


Website Updating

I'm not exactly sure where the logic is to rescrape the notion source content, but I noticed that it doesn't seem to work anymore UNTIL a redeployment is made (it used to be automatic after a couple of page refreshes.)
Can you investigate @zequez ?

I can give it a shot, see what I find.

@transitive-bullshit if you have the secrets please share 🙏

@Zequez https://github.com/transitive-bullshit/nextjs-notion-starter-kit/issues/129#issuecomment-877979216
I was investigating in the source repo and this looks relevant to focus on

This is considered bad practice because the endpoint to force redeploy is now public and anybody can invoke it. It's fine for the short term but we should not trust any critical information (e.g. smart contract addresses) on the website until this is properly fixed and this hack is removed.
https://vercel.com/docs/concepts/git/deploy-hooks#security

Sir just store the hook url into an env var

Sir just store the hook url into an env var

To be 100% sure just create a new hook url first @pavlovcik

Seems to have fixed itself. Not sure about this seemingly transient error.


Develop

Codecov Report
Attention: Patch coverage is 64.35644% with 36 lines in your changes missing coverage. Please review.

Project coverage is 67.14%. Comparing base (cf18e75) to head (f0847e8).
Report is 31 commits behind head on develop.

Files with missing lines
Patch %
Lines

mediaPlayer/SuperMediaPlayer.cpp
58.22%
33 Missing :warning:

cmdline/cicadaPlayer.cpp
0.00%
2 Missing :warning:

mediaPlayer/MediaPlayer.cpp
75.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #660      +/-   ##
===========================================
+ Coverage    67.07%   67.14%   +0.06%
===========================================
  Files          230      231       +1
  Lines        12921    13032     +111
===========================================
+ Hits          8667     8750      +83
- Misses        4254     4282      +28

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


AsyncHttpClient can no longer pass JSON objects to POST calls (SocketTimeoutException)

My code was working fine for months using latest version 1.4.9.  Now all of the sudden all of my POST calls that pass JSON objects return SocketTimeoutException.  Is this a known issue?  Here is an example of my POST calls.  Note, I have also tried passing Header[] object with "Accept" header equal "application/json".  Same error.  Also, I have client.setTimeout(30*1000) even though response time from all POST calls using restClient and Postman take less than a second.
JSONObject jsonParams = new JSONObject();
try {
        jsonParams.put("variable", value);
        entity = new StringEntity(jsonParams.toString(), "UTF-8");
        entity.setContentType("application/json");
} catch (Exception e) {
        e.printStackTrace();
}
client.post(context, url, entity, "application/json", responseHandler);

Issue resolved, turns out my backend data provider was having issues on their end for the last few days.


Log Information

Hey,
I am not sure If there is a purpose to keep the System behavior in the Log section as well.
But since I save the project, or change the language in the left toolbar, It didn't appear in the logs.
Additionally

It would be better to have white text on the toolbar when you turn on the dark theme. Its nearly not visible

Thank you very much for your feedback. There are some questions in one Issue and I would like to ask you to create for each a new Issue in the future.

Information in the log (will be tracked with this Issue)
I would propose to add saving actions to the log and would not include setting changes.

Coloring issue
Unfortunately there is a bug in the library we are using. We are confident that the bug will be solved in near future. I created a new Issue #80 that you can track.