An error occurs when viewing your site from the Brave browser.

Hello, your portfolio is very cool and I'm learning a lot from it.
However, I'm having trouble viewing your site (https://hamishw.com/) on the Brave browser, as it seems to result in an error that prevents the site from displaying.
This issue also arises while I'm studying your site. When I checked the console, it seems like the error is being caused by THREE.WebGLRenderer.
I would appreciate your help. Thank you.

You probably need to enable hardware acceleration from your web browser for it to display.

"Thank you for your reply.
Upon checking the settings of the Brave browser, hardware acceleration was enabled. This is quite perplexing.
By the way, not only does (https://hamishw.com/) occasionally encounter an error stating "Application error: a client-side exception has occurred (see the browser console for more information)," but other sites do as well, preventing me from browsing them.
I appreciate your help."

I have been looking into this for a while and it seems like the majority of the problem is either the GPU blacklist of chromium or the latest browser update, causing errors even if you enable hardware acceleration. For reference, those three.js and chromium issues have more details.
Digging deeper, I used an online VM to test it on different environments via checking out the WebGL support through https://get.webgl.org website, it says browser supports WebGL. Some of the components that use threejs works as intended, but Carousel for instance, causes client side errors. Haven't checked the shaders yet and the threejs code, but maybe new threejs versions already have a workaround for such cases?
Here is the log of Smart Sparrow project on a virtual machine using chrome:
https://www.browserling.com/browse/win/10/chrome/115/https%3A%2F%2Fhamishw.com%2Fprojects%2Fsmart-sparrow%2F
For convenience, here is the full output:
Render
Application error: a client-side exception has occurred (see the browser console for more information).
Console Log
fb7d5399.9395eac7f8e7d509.js:1 THREE.WebGLRenderer: A WebGL context could not be created. Reason:  Could not create a WebGL context, VENDOR = 0x1414, DEVICE = 0x008c, GL_VENDOR = Google Inc. (Google), GL_RENDERER = ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader driver-5.0.0), GL_VERSION = 10.0.19041.2788, Sandboxed = yes, Optimus = no, AMD switchable = no, Reset notification strategy = 0x8252, ErrorMessage = BindToCurrentSequence failed: .

fb7d5399.9395eac7f8e7d509.js:1 THREE.WebGLRenderer: A WebGL context could not be created. Reason:  Failed to create a WebGL2 context.

2fb7d5399.9395eac7f8e7d509.js:1 THREE.WebGLRenderer: A WebGL context could not be created. Reason:  Could not create a WebGL context, VENDOR = 0x1414, DEVICE = 0x008c, GL_VENDOR = Google Inc. (Google), GL_RENDERER = ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader driver-5.0.0), GL_VERSION = 10.0.19041.2788, Sandboxed = yes, Optimus = no, AMD switchable = no, Reset notification strategy = 0x8252, ErrorMessage = BindToCurrentSequence failed: .

fb7d5399.9395eac7f8e7d509.js:1 THREE.WebGLRenderer: Error creating WebGL context with your selected attributes.

framework-4556c45dd113b893.js:1 Error: Error creating WebGL context with your selected attributes.
    at new Ia (fb7d5399.9395eac7f8e7d509.js:1:384824)
    at 93.e02243c67f7e341f.js:1:2861
    at ri (framework-4556c45dd113b893.js:1:93730)
    at Ss (framework-4556c45dd113b893.js:1:113957)
    at is (framework-4556c45dd113b893.js:1:106214)
    at jl (framework-4556c45dd113b893.js:1:46913)
    at framework-4556c45dd113b893.js:1:112753
    at ws (framework-4556c45dd113b893.js:1:112758)
    at ls (framework-4556c45dd113b893.js:1:105216)
    at S (framework-4556c45dd113b893.js:1:138450)
du @ framework-4556c45dd113b893.js:1
main-1a5ef2ee6643c975.js:1 Error: Error creating WebGL context with your selected attributes.
    at new Ia (fb7d5399.9395eac7f8e7d509.js:1:384824)
    at 93.e02243c67f7e341f.js:1:2861
    at ri (framework-4556c45dd113b893.js:1:93730)
    at Ss (framework-4556c45dd113b893.js:1:113957)
    at is (framework-4556c45dd113b893.js:1:106214)
    at jl (framework-4556c45dd113b893.js:1:46913)
    at framework-4556c45dd113b893.js:1:112753
    at ws (framework-4556c45dd113b893.js:1:112758)
    at ls (framework-4556c45dd113b893.js:1:105216)
    at S (framework-4556c45dd113b893.js:1:138450)
ee @ main-1a5ef2ee6643c975.js:1
main-1a5ef2ee6643c975.js:1 A client-side exception has occurred, see here for more info: https://nextjs.org/docs/messages/client-side-exception-occurred
ee @ main-1a5ef2ee6643c975.js:1
_app-06d93892feb03865.js:1

First and foremost, I deeply appreciate you detailing the thought process behind the error.
Windows 11 Home (22H2)
Brave version: 1.56.20 Chromium: 115.0.5790.171 (Official Build) (64 bit)
nvidia geforce rtx 3050 laptop GPU
I accessed https://cancellek.com/projects/spider-bot under the above environment, but I encountered an error just as before.
I have almost finished my portfolio. However, I can't exclude the three.js content as it leaves a good impression on the viewers and is one of my favorites.
I plan to patiently wait for the correction.
In the meantime, I can only hope that visitors to the site aren't using the Brave browser.
I truly appreciate your thorough explanation.
Lastly, the 3D object in @excalith
's portfolio was really cool.

Hey @NyNaNr thanks for the kind words! I have found a SketchFab documentation for resolving such issues as clients: https://help.sketchfab.com/hc/en-us/articles/203059088-Compatibility
I think the fastest and best way for now is to make an error handling for client issues that checks if it is threejs related and inform users with such steps.
@HamishMW do you think it is viable? React ErrorBoundaries could further improve user experience who fails to see the content with possible solutions.

Thank you for your reply!
I sincerely apologize, but due to my limited understanding, I wasn't able to fully grasp your explanation.
As of now, my understanding of the issue at hand is:

Users utilizing specific browsers or GPUs might encounter difficulties accessing sites that use WebGL.

The cause of this is that they are registered on 'the GPU blacklist of chromium'.

Is my understanding correct?
Also, the solution proposed by @excalith suggests that by making code additions or similar adjustments on the server-side, users on the client-side can view the site smoothly without encountering errors, correct?
I'm sorry for my shortcomings. I'd appreciate any further guidance you can provide.

Hey @NyNaNr no problem at all mate! My research about the issue seems to be caused by SwiftShader, which is used by chromium. This issue prevents the components to render on the client side, resulting in blocking the whole page render due to some extensive and beautiful webgl usage of most components.
Normally, this issue should be fixed by the owners of that project (swiftshader, chromium etc) since it is more low-level  stuff. Trying to find a workaround generally causes more issues than fixing it in most cases.
Since it is a low-level issue and haven't checked their code, I can only assume that chromium with swiftshader tries to send GPU a command (a draw call) but fails to render it.
Such issues can be caused by the GPU, engine (firefox / chromium etc), framework (threejs etc), and/or shader you wrote (ie. the gallery with displacement).
However, at least we could prevent whole site to crash using React ErrorBoundary to catch the error and display another page. With this, we can show the navigation bar and such components with a friendly warning that says "Hey, your browser seems to be having issues rendering this awesome page. You can try these steps to catch up eith the new technologies" instead of locking visitor out of the website. They still won't be able to view content of your project, but at least they will know that your website is working and it is an issue caused by the browser.
I personally do not like using that, kind of running the whole site within try / catch so I had to ask project owner first for his insight on this.

Thank you for your response.
I've come to understand that we can prevent the entire site from crashing by utilizing React's ErrorBoundary to catch errors and display an alternative page.
It seems like I might be able to handle it using React's ErrorBoundary.
This was my first time posting a question on a GitHub issue. I'm truly grateful to have a professional like you provide a thorough answer.

Hey @NyNaNr,
Was about to give Error Boundary a try, but realized something. Can you please search your project for failIfMajorPerformanceCaveat and set those to false?
Carousel and Model components both have that. If you are trying to work it out with this repository without changes, there might be other pages that use it as well. I think if a performance issue occurs, it fails and causes the crash. I believe we can prevent crashes by setting that to false, and try to find balance changing powerPreference and fiddling with precision which is not on the components.
Sorry to ask you to try it out since I cannot reproduce it on my end. Please refer to those settings for more information if it works https://threejs.org/docs/#api/en/renderers/WebGLRenderer

Thank you for introducing me to the wonderful culture of open source.
I set 'failIfMajorPerformanceCaveat' to false, but in my environment, the same error continues to appear.
I recently accessed your portfolio site (https://cancellek.com/projects/spider-bot/), and the same error keeps occurring there as well.

Hmmm, it seems like your browser / specs not even supports mediump, asks for lowp instead. It is indeed challenging!
On your fork, the home page threw that error from DisplacementSphere component.
On DisplacementSphere.js file, can you change the WebGLRenderer as follows?
    renderer.current = new WebGLRenderer({
      canvas: canvasRef.current,
      antialias: false,
      alpha: true,
      powerPreference: 'high-performance',
      precision: 'lowp',
      failIfMajorPerformanceCaveat: false,
    });

I set the precision to lowp there but different power preference settings might help such as low-power to force CPU to step in instead, I don`t know it is wise but might be a solution nonetheless since shader is making math computations which should be quite simple even on CPU - more info about that is here https://registry.khronos.org/webgl/specs/latest/1.0/#5.2

I must apologize to you.
The problem has been resolved. When I tried to change it to [precision: 'lowp'] based on your advice, I thought there might be a chance and reset the settings of the Brave browser and deleted the cookies. Then, I was able to access both [https://cancellek.com/projects/spider-bot/] and my portfolio site [https://yur-portfolio.vercel.app/] without any issues.
Even when I reverted the setting to [failIfMajorPerformanceCaveat: true], I was still able to access my sites without any problems.
I have no idea what the problem was.
I deeply appreciate the considerable amount of time you devoted to trying to solve the issue.

No problem at all mate, I'm just glad that we have found a solution together! Cheers!


ERC721 full implementation

Fixes #640
Fixes #809
Continues the work of @facuspagnuolo in #682
Current status:

ERC721 implementation is complete

Pending discussions:

exists was added to the interface here, though will not be part of the standard
The 50K gas stipend for the onERC721Received call was removed (see here)

I am giving a cursory review and everything looks good so far.

Congrats on the awesome job! The implementation and tests seem correct. I have only two comments on it.
doMint/addToken and doBurn/removeToken
Consider a contract that is ERC721BasicToken and that implements a public method that calls doMint without any further requirements. Like this, virtually anyone could mint a token to their own account.
My suggestion is to make contract ERC721BasicToken is Ownable and add the modifier onlyOwner to  doMint.
In the same line of thought, I'd make addToken a private method so that tokens cannot be added without being minted, ie only via doMint so that the totalTokens count is correctly updated and that the event Transfer is always transmitted.
The same logic applies for the pair doBurn/removeToken.
Practical way of initial massive mint
Consider the following contract:
contract MyERC721 is ERC721BasicToken {
    function MyERC721(uint256 _initialSupply) public {
        for (uint256 i = 0; i < _initialSupply; i++)
            doMint(msg.sender, i);
    }
}

Or even this if we want to save some gas:
contract MyERC721 is ERC721BasicToken {
    function MyERC721(uint256 _initialSupply) public {
        for (uint256 i = 0; i < _initialSupply; i++) {
            tokenOwner[i] = msg.sender;
        }
        ownedTokensCount[msg.sender] = _initialSupply;
        totalTokens = _initialSupply;
    }
}

Both are forbiddingly expensive and limited when it comes to _initialSupply. The maximum number I could assign it in the migrations was 263 (for the second one): deployer.deploy(MyERC721, 263) spent ~0.7 ETH.
My final goal is to make a refundable, capped crowdsale of a ERC721BasicToken. Probably my strategy is wrong. If you guys have a better idea, I'd appreciate your insights.

@carloschida thanks for the comments! Our goal is to provide a base implementation here, without forcing a particular ownership model for minting (that's why the methods are internal). We'll probably be providing a Mintable extension (similar to ERC20's) after this is merged. Stay tuned!

@spalladino Thanks for the prompt response. I see. It does make sense to stay agnostic on that matter.
Nevertheless, I'd still consider it dangerous that a token can be added or burnt without changing adequately the total supply and without transmitting the corresponding events (here I mean only the internal -> private changes on those methods).

@spalladino is this PR also going to define the ERC165 interface?

@dekz that'll be discussed in https://github.com/OpenZeppelin/zeppelin-solidity/issues/754

I've been thinking a bit more about the gas stipend for the call to onERC721Received. Either no stipend (as in this implementation) or a 50K stipend (as proposed by the standard) could allow for reentrancy attacks on any contract that uses safeTransfer. This would be similar to what happens when ETH is sent via send in Solidity, and why transfer was later introduced.
However, forcing a 2300 gas limit here would (1) go against the standard, that expects to have at least 50K gas available, and (2) prevent any useful operations to be performed on the call, limiting the usage of this method as a transferAndCall alternative.
I'd like to hear some thoughts here before merging cc @maraoz @frangio @eordano @fulldecent

Please provide a concrete example of a reentrancy attack against a correctly implemented standards-compliant ERC-721 contract.
I do not think one exists and this discussion has not convinced me otherwise.

Regarding send versus transfer, I do not understand this analogy. We throw on failure, this follows the safer transfer model that Solidity now recommends.

This implementation makes it extremely difficult to find the list of all owned tokens of a particular address. Why do you choose to map the id to an address instead of an address mapped to an array of ids.

I get this warning in Remix: "Warning: Invoking events without "emit" prefix is deprecated.".   Should "emit" be added to the events?

@mudgen that occurs on the new 0.4.21 Solidity release. We'll update OZ to that version in one fell swoop later on.

Please note, we slipped in one documentation fix into the standard:
https://github.com/ethereum/EIPs/commit/812f414d261ce04329938c36e3e4c60f1cfbeb01

Please provide a concrete example of a reentrancy attack against a correctly implemented standards-compliant ERC-721 contract.
I do not think one exists and this discussion has not convinced me otherwise.

@fulldecent  the attack would not be against an ERC721, but against a contract that uses 721, which triggers a reentrancy by using safeTransfer. I was thinking something along the lines of the following (may not even compile, it's just for an example).
contract BuyERC721 {
  ERC721 asset;
  ERC20 currency;
  uint256 costPerAsset;

  function buy(uint256 tokenId) {
    if (currency.allowance(msg.sender, this) > costPerAsset) {
      asset.safeTransferFrom(this, msg.sender, tokenid);
      currency.transferFrom(msg.sender, this, costPerAsset);
    }
  }
}

Though the fix is straightforward (swap the two transfer lines to decrement allowance before transferring the asset), the attack is made possible because an attacker can call buy again from the safeTransferFrom call. Solidity works around this by adding the transfer keyword to perform sends with little gas, so no new calls can be issued.
Let me know if the example is clear!

@spalladino So as long as the "transfer" function is used instead of "send" then the above reentry attack won't work, correct?  Because there won't be enough gas for the reentry attach to work, correct?
@spalladino Are you proposing that something in the standard should be changed or giving notice of an issue to steer clear of?

@spalladino Thank you for sharing, this makes very clear what you are talking about.
We both agree that the "Checks-Effects-Interactions" pattern is best practice and that this contract does not follow the pattern. Now we want to know if that would cause an actual problem and if we should prevent it.
Sorry, I am not the most familiar with zeppelin-solidity. But I think that if SafeERC20 is used and safeTransferFrom is used then the attack vector against BuyERC721 is greatly limited.
The classic reentrancy attack usually requires idempotency and safeTransferFrom does not have it.
So I think the problem with this contract is the ERC-20 part, not the ERC-721 part. But I might be biased :-).

Also, I think it is on-topic to consider the same thing with a draft ERC-777 token (including a callback before send and after receive). Again, a full attack is not obvious to me.

Warning: contract ERC721BasicToken defines ownedTokensCount as internal. ERC721Token extends this class and overrides all the setters for ownedTokensCount.
Therefore a contract that extends ERC721Token will have access to the ownedTokensCount however the data will be incorrect.
Solution: make ownedTokensCount private for now.

Why does the implementation specify "solidity ^0.4.18" and not the latest release of solidity, "^0.4.21" ?

Why does the implementation define name_ and symbol_ as internal and then explicitly make name and symbol getter functions?  Why not just declare name and symbol as public? Just want to understand the reasoning for this. Is there a reason for this or is it just a style choice?

Why does the implementation define name_ and symbol_ as internal and then explicitly make name and symbol getter functions? Why not just declare name and symbol as public? Just want to understand the reasoning for this. Is there a reason for this or is it just a style choice?

@mudgen because Solidity does not support overriding an autogenerated public getter. If, for some reason, you want to override the name/symbol getters to return some calculated value, you wouldn't be able to do so. Name and symbol may not be the best examples, but we did notice some folks were struggling with totalSupply in ERC20 for instance.

@spalladino I see! Makes sense. Thanks for the explanation.

@mudgen

Why does the implementation specify "solidity ^0.4.18" and not the latest release of solidity, "^0.4.21" ?

OpenZeppelin is pinned to ^0.4.18 for now. We'll upgrade all of the contracts at once in a future PR that's created after 0.4.21 has been found to have no critical issues.

Correct, the ownerOf and balanceOf calls for 0x0 should throw according to spec. Let's add that.
I'll spend some time later today going through the spec line-by-line and making sure this implementation conforms.

I've pushed several fixes, and the way I see it there are only two pending issues:

Whether to allow transfers to self as a no-op, and whether it clears approvals or not
Whether to enforce a very low gas stipend to prevent reentrancy attacks, use 50K to be compliant with the standard (even though that number had no particular reason), or do not enforce a stipend at all

Please chime in @facuspagnuolo @frangio @Shrugs, so we can ship this version in the upcoming release!

re: transfer to self; I don't really have an opinion on whether or not it should no-op; the spec also doesn't specify. My only opinion is that if we do decide to no-op, it should clear approvals, according to spec (at least, as I've interpreted it).

At the time of any transfer, the approved address for that NFT (if any) is reset to none.

re: gas; If 50k is arbitrary, I'd prefer no limit at all. Who made the original decision on 50k, and what's their rationale?

re: gas; If 50k is arbitrary, I'd prefer no limit at all. Who made the original decision on 50k, and what's their rationale?

@Shrugs here is a short discussion on gitter regarding gas, which ends on @eordano agreeing on removing it.

I found a couple small issues in this function:
  function removeTokenFrom(address _from, uint256 _tokenId) internal {
    super.removeTokenFrom(_from, _tokenId);

    uint256 tokenIndex = ownedTokensIndex[_tokenId];
    uint256 lastTokenIndex = ownedTokens[_from].length.sub(1);
    uint256 lastToken = ownedTokens[_from][lastTokenIndex];

    ownedTokens[_from][tokenIndex] = lastToken;
    ownedTokens[_from][lastTokenIndex] = 0;
    // Note that this will handle single-element arrays. In that case, both tokenIndex and lastTokenIndex are going to
    // be zero. Then we can make sure that we will remove _tokenId from the ownedTokens list since we are first swapping
    // the lastToken to the first position, and then dropping the element placed in the last position of the list

    ownedTokens[_from].length--;
    ownedTokensIndex[_tokenId] = 0;
    ownedTokensIndex[lastToken] = tokenIndex;
  }

First issue:   If there is only one element in ownedTokens[_from] then _tokenId and lastToken will be the same. Therefore the last two lines of the function should be switched so that the removed token is not assigned an index in ownedTokensIndex[lastToken].
It should be like this:
    ownedTokensIndex[lastToken] = tokenIndex;
    ownedTokensIndex[_tokenId] = 0;

Second issue: I think it is clearer, more explicit to use the delete keyword when deleting things.  Like this:
    ownedTokensIndex[_tokenId] = 0;
Third issue: I think "lastToken" should be renamed to "lastTokenId" to be consistent with using "_tokenId".
Cheers

Thanks for the review @mudgen! Regarding the first issue:

First issue: If there is only one element in ownedTokens[_from] then _tokenId and lastToken will be the same. Therefore the last two lines of the function should be switched so that the removed token is not assigned an index in ownedTokensIndex.

If there is only one element in ownedTokens[_from], then not only _tokenId and lastToken will be equal, but also tokenIndex will be zero. So the last two lines are doing the same thing, and switching them should change anything. Let me know if I'm missing something though.

@spalladino I looked at it and you are correct and you are not missing anything. tokenIndex will be zero so my earlier statement was incorrect and the current implementation is correct as is.  Thanks for pointing that out.

@spalladino what if ownedTokens[_from] is greater than one and lastTokenId and _tokenId are the same because _tokenId is the last one in ownedTokens[_from]. In that case tokenIndex will be greater than 0.

@mudgen let's see a run in that scenario:
// Initial state
_tokenId = 30;
ownedTokens[_from] = [10, 20, 30];
ownedTokensIndex = { 10: 0, 20: 1, 30: 2};

uint256 tokenIndex = ownedTokensIndex[_tokenId]; // tokenIndex = 2
uint256 lastTokenIndex = ownedTokens[_from].length.sub(1); // lastTokenIndex = 2
uint256 lastToken = ownedTokens[_from][lastTokenIndex]; // lastToken = 30

ownedTokens[_from][tokenIndex] = lastToken; // ownedTokens[_from] = [10, 20, 30]
ownedTokens[_from][lastTokenIndex] = 0; // ownedTokens[_from] = [10, 20, 0]

ownedTokens[_from].length--; // ownedTokens[_from] = [10, 20]
ownedTokensIndex[_tokenId] = 0; // ownedTokensIndex = { 10: 0, 20: 1 };
ownedTokensIndex[lastToken] = tokenIndex; // ownedTokensIndex = { 10: 0, 20: 1, 30: 2}

It seems that ownedTokensIndex is not properly cleared. This should not be a major issue, since the token is currently "removed" from its owner, and the index will be corrected on the next "add" call; however, it's not very clean. I'll set up an issue to fix this and add the corresponding tests. Thanks!

@spalladino In https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md the approve/transfer functions are external payable, while in this implementation are public. Is there an easy way to extend this implementation to get payable functions? Thanks

@falox I'm afraid that if you extend and change it to be payable you'll get a Overriding function changes state mutability from "nonpayable" to "payable" error. I'm reluctant to make the transfer functions payable in the implementation though.

@spalladino as I guessed, thanks. May I ask you why you are preferring "nonpayable" to "payable" functions?
I'm asking this because I'm thinking at the use case where a token takes a fee on all transfers, including over-the-counter trades (i.e. in generic ERC721 exchanges and not via specific contract "buy" functions).

@falox it's a tradeoff: though on one hand we are making things more difficult for people who want to add payable functionality to their ERC721s, on the other we are securing all the people who use regular ERC721s, to make sure they don't accidentally send ETH to the token contracts, which would otherwise be lost.

Locking this conversation. Please open new issues for any further doubts or problems!


operator kubecost (2.2.4)

Signed-off-by: chipzoller<EMAIL_ADDRESS>Thanks for submitting your Operator. Please check the below list before you create your Pull Request.
New Submissions

[x] Are you familiar with our contribution guidelines?
[x] Are you familiar with our operator pipeline?

[x] Have you considered whether you want to use semantic versioning order?
[x] Is your submission signed?
[x] Is operator icon set?

Your submission should not

[x] Add more than one operator bundle per PR
[x] Modify any operator
[x] Rename an operator
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description of the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/pipeline restart operator-hosted-pipeline

/pipeline restart operator-hosted-pipeline

/pipeline restart operator-release-pipeline


Set custom alias for aggregation methods

Hi, there
In RedisSearch, you can set arbitrary alias for aggregation methods like AVG, SUM, ..., but in Redis.OM we can't change the name on the pipeline. Can we have this feature in Redis.OM?
Thanks.

Hi @imansafari1991 - do you mean the results from reductions (e.g. Sales_SUM)?

Sounds good. Thanks for the explanations.

np - closing


[PROPOSAL] Inject Kubernetes Control Plane users into Falco syscalls logs for kubectl exec activities

Disclaimer: We will use the term “k8s user” to refer to the Kubernetes control plane “user” (human or serviceaccount) who makes API calls. This user is different from the traditional Linux users and shall not be confused with the uids Falco logs today (e.g. user.uid, user.name or user.loginuid, see definitions on the Supported Fields for Conditions and Outputs page).
Motivation
When a user runs an interactive kubectl exec session like the following within a Kubernetes cluster:
$ kubectl exec -it nginx2-78848c9dcb-4ptf8 -- /bin/bash
root@nginx2-78848c9dcb-4ptf8:/# sleep 123123
^C
root@nginx2-78848c9dcb-4ptf8:/# exit

The built-in k8s audit controller will log an audit event with the command captured as follows:
{
    "kind": "Event",
    "apiVersion": "audit.k8s.io/v1",
    "level": "RequestResponse",
    "auditID": "7b36f2ea-2e64-4b4a-a946-f387c75b7d72",
    "stage": "ResponseStarted",
    "requestURI": "/api/v1/namespaces/default/pods/nginx2-78848c9dcb-4ptf8/exec?command=%2Fbin%2Fbash&container=nginx&stdin=true&stdout=true&tty=true",
    "verb": "create",
    "user": {
        "username": "kubernetes-admin",
        "uid": "[user-id]",
        "groups": [
            "A",
            "B"
        ]
    },
    <...> # removed other parts not relevent
    "requestReceivedTimestamp": "2023-10-30T18:57:12.826789Z",
    "stageTimestamp": "2023-10-30T18:57:12.899734Z",
    "annotations": {
        "authorization.k8s.io/decision": "allow",
        "authorization.k8s.io/reason": ""
    }
}

If you see from the exec session above, the user ran sleep command on the k8s pod, but only /bin/bash is captured as part of the audit log entry, which creates a gap in k8s auditing solution where any other commands run in the interactive session won't be logged by the Kubernetes audit controller.
Note this auditing gap is called out and is out of scope by design for Kubernetes Auditing controller, k8s maintainers discussion here: https://github.com/kubernetes/kubernetes/pull/29443#discussion_r72612301
This is where tools like Falco come in as they monitor syscalls. However, looking back to the new interactive shell that was spawned from the container entrypoint -- in Falco we won't see the Kubernetes control plane user (which can be a person or a serviceaccount), but the k8s audit log event does contain the user who made the API call (see the user.username or user.uid k8s fields from the Kubernetes Audit Logs). This is mainly because the Linux kernel does not know about anything that happens at layers above the kernel such as the Kubernetes control plane.
Knowing the user who made the k8s API calls is crucial for Incident Response and it would be nice to have the k8s user as part of each Falco log even though the Linux kernel does not know about it. This would enable us to do the following:

Disable specific user credentials as a response to an agent alert

e.g. If there’s an agent alert about accessing a secrets file on pod, having correct k8s user will allow admins to quickly disable the credentials to stop an attack

Look up all commands executed by specific k8s user, this will allow for more accurate and complete forensics analysis in case of suspected compromised user credentials

e.g. If a specific user or machine is suspected to have installed malicious software, having the ability to query all commands they have executed is very critical in understanding possible damage done.

Feature
One solution that can address the gap above is to provide the k8s user to the security agent running on the respective k8s cluster node. If the agent is able to correctly and securely fetch the k8s user of the user running the exec command at the time of when the new interactive shell is created from the container entrypoint, the agent can keep track of the k8s user and automatically attribute all sub-processes that the user runs in the interactive session with the same k8s user.
[1] The proposed solution involves modifying the k8s cluster, else there is nothing we can do.
We could take advantage of the mutation webhook functionality of k8s that would mutate the PodExecOptions request payload to modify the command parameter to include the k8s user extracted from the userInfo object that the API server includes in mutation AdmissionReview request.
Yes we would tamper with the container entrypoint command that will be run (drawbacks and alternatives to be discussed later).
For example:
Normally the PodExecOptions object looks like the following
        "object": {
            "kind": "PodExecOptions",
            "apiVersion": "v1",
            "stdin": true,
            "stdout": true,
            "tty": true,
            "container": "my-pod",
            "command": [
                "/bin/bash" # this is user controlled through `kubectl`
            ]
        }

After adding the mutation logic the new mutated object from API server will look like the following
        "object": {
            "kind": "PodExecOptions",
            "apiVersion": "v1",
            "stdin": true,
            "stdout": true,
            "tty": true,
            "container": "my-pod",
            "command": [
                "/bin/sh",
                "-c",
                "export SEC_USER_ID=12345;",
                "/bin/bash" # user provided command appended at end of list
            ]
        }

Note mutation above assumes that /bin/sh will always be available on target container, which is not always the case. There might be a way to remove this dependency by using the following pattern instead /usr/bin/env SEC_USER_ID=12345 /bin/bash which would rely on the env binary instead which is typically available on all POSIX systems.
[2] In Falco's event processing loop, we can parse the command line (proc.args) of execve* system calls to find special tokens that provide the Kubernetes user (e.g., SEC_USER_ID). Falco will then cache the k8s user using the regular threadtable caching mechanisms. This will allow all subsequent processes in the kubectl exec session to find the k8s user by traversing the parent process lineage, and as a result, include this information in Falco's output logs.

Thanks a bunch @osagga ❤ ! Very supportive, having such capabilities would be a tremendous win! Excited to hear what the community thinks!
CC @Andreagit97 @alacuku @LucaGuerra @Issif

To clarify a few details, I am adding some more bullet points:

Re the parts that would modify the Kubernetes cluster via the mutating webhook, this could be a random app not even part of the Falco deployment. It would be completely independent of anything Falco. Additionally, since it would only mutate exec activities, the impact on the Kubernetes cluster should be very small and acceptable. Ultimately, the adopter would need to decide if they are okay with this. It would also be good to communicate that this likely requires a higher level of effort from the adoption point of view.
As an extension to what I mentioned above, Falco will not interact in any way with Kubernetes in this regard (no API calls, no responses needing to be received, no interference from Falco at all). This is because the mutating webhook modifies the command arguments that Falco already logs via the kernel syscall hooks. All Falco now has to do is parse out our injected token and make it available as a new, clean field. Therefore, it is a separate use case from the Falco k8s client functionality, but it is semantically related.
Re the ability to attribute each subsequent command or other syscall for that matter, we do not need a new extra cache. This is because all processes will be child processes of the initial process at the container entrypoint as a result of the kubectl exec, and that process has the Kubernetes user information injected. Therefore, for all subsequent processes, we can simply traverse the parent process lineage until we find the Kubernetes user information, similar to how Falco implements proc.aname and other capabilities today.

Other better ideas are of course very welcome!

@osagga we just had the core maintainers meeting and @gnosek also prefers an approach that manipulates env somehow. I also need to dig into this more after KubeCon. I'll then share an assessment of the Falco libs changes that are needed and that have broader benefits beyond this use case.

@sgaist thank you for chiming in :heart: .
As far as I understand the Kubernetes issue you are referencing seeks to add ObjectMetadata to resources so that for example the pod uid is accessible.
For our use case the control plane user data is already available
"user": {
        "username": "kubernetes-admin",
        "uid": "[user-id]",
        "groups": [
            "A",
            "B"
        ]
    },

By the way @osagga someone else also requested modifications to how we can access proc.env in Falco. Opened a PR. With those changes injecting the user.username and user.uid into env variables (named however you want) as part of the command should be accessible by Falco as we can now search for those envs values in the parent process lineage.
@sgaist this is a great find as addressing this Kubernetes issue will enhance Falco's k8saudit logs plugin. Currently, in the exec Kubernetes audit logs data, although you have the namespace and pod name, the absence of the pod ID or pod UID can cause collisions if you try to correlate them with Falco syscalls logs. Therefore, supporting this issue will benefit Falco and improve security monitoring for everyone beyond Falco.

Regardless of those updates we would still need to use the mutating webhook to modify the exec command so that the control plane user data is "injected into the Linux kernel". This means the data is now available in fields we parse and log in the kernel when a new process gets spawned.
Open to more new ideas :upside_down_face: .

@sgaist we were discussing a bit more and someone brought the distroless container edge cases up where there is no shell and env binary really, e.g. kubectl exec <pod-name> -- ping <IP_ADDRESS>.
With that in mind @osagga was wondering if the Kubernetes issue you referenced could be extended to env in ObjectMeta. I'll let Omar or others elaborate more.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale
No updates yet unfortunately.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale


Consider using QUIC instead of TCP in IPFS/libp2p

related: https://github.com/tendermint/spec/issues/198

not relevant in this repo anymore


Better minimum steering speed alert

something like https://github.com/commaai/openpilot/pull/26267

Hi @sshane
Is this issue still active?


Propose stackoverflow badges project alternative

Hey @rzashakeri 👋 Thanks for the work put into this project.
I came across this one by chance and saw that you were proposing to use the stackoverflow-badge which is really nice.
I had also done a project of this kind called  stackoverflow-readme-profile which offers more customisation, animations and the display of the person's avatar just like:

So I suggest you generate your own using the generator at https://johannchopin.github.io/stackoverflow-readme-profile and if you like the project would it be possible to mention it as a badge idea for stackoverflow?

Hey @rzashakeri 👋 Thanks for the work put into this project.
I came across this one by chance and saw that you were proposing to use the stackoverflow-badge which is really nice.
I had also done a project of this kind called stackoverflow-readme-profile which offers more customisation, animations and the display of the person's avatar just like:

So I suggest you generate your own using the generator at https://johannchopin.github.io/stackoverflow-readme-profile and if you like the project would it be possible to mention it as a badge idea for stackoverflow?

Hello my friend @johannchopin 🖐
Thanks for sharing this tool 🙏
The tool is great and I added it to the list 💙


clustermesh: Always use uint32 as ClusterID type

Please see the commit message for more details.
Always use uint32 as ClusterID type.

/test

Travis CI was failing because I didn't update the cmdref documents. I pushed the fixes.

/test

/test-runtime

Tests are passing and reviews are in. Let me mark as ready-to-merge.


Adds delay to flappy spec.

closes #1848
Why was this change made?
So we can stop hitting the Circle re-run button.
How was this change tested?
Which documentation and/or configurations were updated?

I've run this numerous times locally and in Circle, so undrafting.


Crash from "Detected over-release of a CFTypeRef"

There's another crash that's been appearing in our app. So far it's only happened a handful of times but they've all been iOS >= 14.4, but the majority of our user base is on those versions so it might not be relevant.
Detected over-release of a CFTypeRef 0x10b015a00 (325 / SecCertificate) > hashSubjectPublicKeyInfoFromCertificate: > SecCertificate

I looked through the code and it appears that the returned OSStatus from calling SecTrustCreateWithCertificates is not checked. If it fails for any reasons, it still tries to release the trust variable which may not have been set. I also noticed the the following call to SecTrustEvaluate doesn't check the result or the returned OSStatus either which is probably an issue as well.
I'd be willing to try fixing it but I'm not sure what kind of affect returning nil from copyPublicKeyFromCertificate: would have on the other places calling it.
OS Version: iOS 14.4.2 (18D70)
Report Version: 104

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Crashed Thread: 1

Application Specific Information:
Detected over-release of a CFTypeRef 0x129023400 (325 / SecCertificate) > hashSubjectPublicKeyInfoFromCertificate: > SecCertificate

Thread 1 Crashed:
0   CoreFoundation                  0x3128973d8         _CFRelease.cold.3
1   CoreFoundation                  0x3128973cc         _CFRelease.cold.3
2   CoreFoundation                  0x3127a356c         _CFRelease
3   CoreFoundation                  0x312706284         -[__NSSingleObjectArrayI dealloc]
4   Security                        0x3214a2420         SecTrustDestroy
5   CoreFoundation                  0x3127a3100         _CFRelease
6   TrustKit                        0x1050d0738         -[TSKSPKIHashCache copyPublicKeyFromCertificate:] (TSKSPKIHashCache.m:267)
7   TrustKit                        0x1050cfd50         -[TSKSPKIHashCache hashSubjectPublicKeyInfoFromCertificate:] (TSKSPKIHashCache.m:175)
8   TrustKit                        0x1050cf9f0         verifyPublicKeyPin (ssl_pin_verifier.m:71)
9   TrustKit                        0x1050d6d10         -[TSKPinningValidator evaluateTrust:forHostname:] (TSKPinningValidator.m:126)
10  TrustKit                        0x1050d70e0         -[TSKPinningValidator handleChallenge:completionHandler:] (TSKPinningValidator.m:202)
...

Hello and thanks for the bug report!
The copyPublicKeyFromCertificate function is only called by hashSubjectPublicKeyInfoFromCertificate, which can already return nil if something went wrong.
Hence, one option would be to return nil in copyPublicKeyFromCertificate and then nil again in hashSubjectPublicKeyInfoFromCertificate, which would cause TrustKit's validation to fail and reject the connection.
Hence, the app still wouldn't work, but it wouldn't crash.


Iqiyi shows HTTP 404

Source information
Iqiyi 1.4.2
Source language
Chinese
Steps to reproduce
the extension doesn't work.Browsing with webview reveals that the domain automatically jumps to the https://manhua.iqiyi.com/

Expected behavior
Can read manga normally.
Actual behavior
http 404
Mihon/Tachiyomi version
0.16.3
Android version
Android 14
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[ ] I have admitted that I am a clown by having checked this box, as I have not read these acknowledgements.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

Duplicate of #1474


Adding support for non linux/x86_64 platforms

The README.md has the details. This allows building/running on other platforms with minor hackery.

@nmittler: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

test_ztunnel
151efec8785dd6bdff012d83bbc0c76cbcff9956
link
true
/test test

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Faster refresh and shutdown

Currently we're using sleep for busy waiting, including polling for changes and waiting for the server to shut itself down. It could feel snappier if we use nanosleep with a sane interval. (HFS+ certainly doesn't help in this regard, unfortunately, but APFS will.)

Fixed in a44fc32e88474a7e70f020cd80ca14facb18c3ab.


Improve failover robustness

PR Description
Covered following cases:

switchToFailoverEventStreamIfAvailable() is not always fired when currently used api fails, it could be fired by connection error fallback for example and switch endpoint (not considering primary, when it could be the best) when not needed
there could be a case when BeaconNodeReadinessManager is switched to primary as ready, sent event once and will not repeat it, but by some reason this event slipped in EventSourceBeaconChainEventAdapter (say callback switchToFailoverEventStreamIfAvailable() fired just after it). Repeated events guarantee that we will switch to primary in this case sooner or later and price is nothing.

Wanted to add some tests, but it doesn't look it could be tested easily. Maybe you could provide some suggestion?
Fixed Issue(s)

Fixes #8180 (not 100% on this)
Documentation

[x] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[x] I thought about adding a changelog entry, and added one if I deemed necessary.

Regarding the tests, It would be great to add a test that covers the EventSourceBeaconChainEventAdapter not switching when the current BN is READY. We normally can mock the beaconNodeReadinessManager.getReadinessStatus(currentBeaconNodeUsedForEventStreaming) call to make it return READY and then check that the findReadyFailoverAndSwitch hasn't been called (check that the currentBeaconNodeUsedForEventStreaming is still the same for example)


Support calling plot_airmass with an empty target list

It will still set up the axes, add the brightness shading if requested, and return the axes.
This is helpful for my application because I want to start from an empty airmass chart and add my own plot elements, like this probabilistic airmass chart for a LIGO event.

Thanks for the PR, and beautiful plot! The test failures here are unrelated to the PR, so I'm merging.

When are you planning to do your next release?

Soon, I suppose. Would you like one soon?

It's not time-critical. I have a workaround for this change that I can use in the meantime (add a dummy target and then remove it).


This project is really nice, I hope to support StatefulSet injection as soon as possible

This project is really nice, I hope to support StatefulSet injection as soon as possible.

Hi @1121437613, i am happy to hear!
you can look at how Deployment is implemented, the StatefulSet should be pretty close to that: https://github.com/k8tz/k8tz/blob/50729bd0e68659a1df91fcf390948bc243d9c7b5/pkg/inject/inject.go#L87-L91


support non-Latin languages like araibc and direction from right-to-left

Describe the feature
When trying to write in Arabic, the letters appear as in the picture, I think that the Arabic language is not supported.

Relevant code
No response

This is a duplicate of #568, which we will work on relatively soon.


update changelog for v0.8.0-rc.1

Signed-off-by: Steve Kriss<EMAIL_ADDRESS>

I was thinking we wouldn't leave the RC section around -- just update the whole thing to v0.8.0 once we're through the RCs

That could work. What do you recommend, @Bradamant3?

addressed other comments

Agree, let's update the whole thing after we're done with the RCs


Add LICENSE

Hello,
Under what license is this project in? MIT?

Thanks for that! Really.
I never thought about it because I didn't know licenses very well since now.
After reading some of them I like the MIT - very simple and everyone can do what he wants.
The next major version will have the MIT license.

Done and will be in 3.0.0 !
Permanent checked / reminded via CodeSniffer from now on :)


feat(MapMarkerClusterer): Add options input parameter

Feature Description
Several components including GoogleMap and MapMarker have a options input parameter that allow to pass a complete options object. The wrapped APIs already support such an options object. The MarkerClusterer constructor is no exception.
For the sake of consistency, MapMarkerClusterer should also expose an options input.
Use Case
Currently:
<map-marker-clusterer
  [gridSize]="markerClustererOptions.gridSize"
  [maxZoom]="markerClustererOptions.maxZoom"
  [zoomOnClick]="markerClustererOptions.zoomOnClick"
  ...
>
  <map-marker
    *ngFor="let markerOptions of markerOptions"
    [options]="markerOptions.options"
  ></map-marker>
</map-marker-clusterer>

Instead, it would be more useful:
<map-marker-clusterer
  [options]="markerClustererOptions"
>
  <map-marker
    *ngFor="let markerOptions of markerOptions"
    [options]="markerOptions.options"
  ></map-marker>
</map-marker-clusterer>

Sounds reasonable, but should wait on https://github.com/angular/components/pull/21753 which moves some code around in the clusterer.


Bump parent pom to 3.54

Same issue as jenkinsci/workflow-cps-plugin#345. Tests finish with builds still running and JMH fails to properly shut it down. It is better to fix tests so that they do not leave builds running.

LockStepHardKillTest is a different story, it suffers from jenkinsci/workflow-support-plugin#99.

Answered you in jenkinsci/jenkins-test-harness#166. I haven't given up on this PR, need some more time for investigation.

@slonopotamus Sorry for trampling over this pull request in master :sweat_smile: - Do you still want to get this merged? The updates to test cases look interesting at least...

I actually forgot why I touched so many dependencies. Possibly this was an effort to fix LockStepHardKillTest.
Need to restart it from scratch.


RACSignal: implement a dedicated map operator.

Since -map: is such a common operator, this specialization over the
default -flattenMap: implementation of RACStream increases the
overall performance of RAC.

Historically we've resisted these sorts of things because it means more code with very little performance benefit.
I think any patch like this needs to be accompanied by some sort of benchmark to measure the performance gain.

I'd argue the "very little performance benefit" claim, since as I wrote, this operator is widely used and every gain, even minor, may dramatically affect the system's performance. I find it weird that the current implementation is using flattenMap: to implement this operator, just to spare the trivial 5 lines of straightforward implementation that you'd expect to find.
I originally wrote all of the optimizations I've sent more than 6 months ago, so I've lost my benchmarks, but I have no problem recreating them. Do you want me to run them on a specific device or simulator?

Do you want me to run them on a specific device or simulator?

No, but a mix of macOS and iOS is probably a good idea.

I wrote a simple benchmark that creates a subject and maps an NSString, then sent 100K values through it.
Results (in Release configuration):
Simulator: 0.103595 sec vs. 0.570456 sec (x5.7 improvement)
iPhone 6S: 0.158515 sec vs. 0.844598 sec (x5.6 improvement)

I guess that we have a clear winner 🏅
Not very surprising given the amount of operations that is done right now for -map:.

If this is still of interest to anyone, our fork contains this change and additional bug fixes and performance optimizations.


CircleCI Cache

Address #561

Is there a way to force a full build if there is a problem with the cache? This can sometimes be necessary

Is there a way to force a full build if there is a problem with the cache? This can sometimes be necessary

The simplest way might be using a key to specify the cache

Codecov Report

Merging #573 (698f32d) into master (1f550b1) will increase coverage by 0.25%.
The diff coverage is 100.00%.

:exclamation: Current head 698f32d differs from pull request most recent head da1d7a8. Consider uploading reports for the commit da1d7a8 to get more accurate results

@@            Coverage Diff             @@
##           master     #573      +/-   ##
==========================================
+ Coverage   91.69%   91.95%   +0.25%
==========================================
  Files          21       22       +1
  Lines        4204     4237      +33
==========================================
+ Hits         3855     3896      +41
+ Misses        349      341       -8

Impacted Files
Coverage Δ

hnn_core/dipole.py
92.50% <ø> (ø)

hnn_core/gui/gui.py
96.46% <ø> (+0.70%)
:arrow_up:

hnn_core/gui/_viz_manager.py
88.44% <100.00%> (+0.99%)
:arrow_up:

hnn_core/viz.py
89.19% <100.00%> (+0.35%)
:arrow_up:

hnn_core/__init__.py
100.00% <0.00%> (ø)

hnn_core/parallel_backends.py
83.05% <0.00%> (+0.83%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Is there a way to force a full build if there is a problem with the cache? This can sometimes be necessary

The simplest way might be using a key to specify the cache

Or we can hash the source code folder

see: https://github.com/mne-tools/mne-python/blob/3b29980d22becbf8bfa1c535f6e5680ad4bc749a/tools/circleci_download.sh#L5
would be nice if you can add "[circleci full] commit message" and it does the full build ... or "[circleci gui] commit message" and it just rebuilds the GUI stuff ...

Ah I see, this is better

see: https://github.com/mne-tools/mne-python/blob/3b29980d22becbf8bfa1c535f6e5680ad4bc749a/tools/circleci_download.sh#L5
would be nice if you can add "[circleci full] commit message" and it does the full build ... or "[circleci gui] commit message" and it just rebuilds the GUI stuff ...

Ah I see, this is better

I found using environment variables might be even easier compared with this one... We just need to change the value of CACHE_VERSION in CircleCI project settings before re-run

But with cache-version, we'll have to go inside circleci and change it. And also, it can be done only by the owners of this repository. Personally, I prefer if you can just specify in commit message. Not sure how complicated it is though ...

But with cache-version, we'll have to go inside circleci and change it. And also, it can be done only by the owners of this repository. Personally, I prefer if you can just specify in commit message. Not sure how complicated it is to set up though ...

I prefer using commit messages too. But it seems CircleCI does not allow overwriting or clearing caches. If you try to just save_cache with an existing key, the output will be:

So it seems the only plausible way is to update the key name. Commit messages are stateless in this sense. If we want to manually update the cache without entering circle, we can use some key version file. Not sure if this is too ad-hoc...
Or we can export the git log file, to trace the last commit message in the current branch that contains full-build and use the corresponding hash as the key.

how is MNE doing this? did you take a look?

But with cache-version, we'll have to go inside circleci and change it. And also, it can be done only by the owners of this repository. Personally, I prefer if you can just specify in commit message. Not sure how complicated it is to set up though ...

I prefer using commit messages too. But it seems CircleCI does not allow overwriting or clearing caches. If you try to just save_cache with an existing key, the output will be:

So it seems the only plausible way is to update the key name. Commit messages are stateless in this sense. If we want to manually update the cache without entering circle, we can use some key version file. Not sure if this is too ad-hoc...
Or we can export the git log file, to trace the last commit message in the current branch that contains full-build and use the corresponding hash as the key.

wait it seems that CircleCI does not respect the environment variable exported in the command for saving cache...

Thanks for your patience @chenghuzi ! It's merged now :)


run vscode with black window in ubuntu14

Hi, everyone.
When I start VS Code I get the freeze screen(not working and responding, but showing the welccome page). I try the one of solutions is to run VS code by "code --disable-gpu".
it can't solve question by  https://github.com/Microsoft/vscode/issues/6379 or removing root authority by "cd ~/.config" & "sudo rm -rf ./Code/" as well.
i have found duplicates similar question but some don't solve yet(https://github.com/microsoft/vscode/issues/122201). some question aren't same ubuntu version.
this is my ubuntu & vscode version
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.6 LTS
Release:	14.04
Codename:	trusty
vscode version 1.55.2
i post the info as many as possible. if it is necessary for more pls tell me ORZ.
---------INFO1---------

INFO1: code --verbose
[main 2021-05-05T09:21:51.210Z] [uncaught exception in main]: Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node) [main 2021-05-05T09:21:51.210Z] Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1812)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1250:18)
at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2039)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at v (/usr/share/code/resources/app/out/vs/loader.js:4:694)
at Object. (/usr/share/code/resources/app/node_modules.asar/vscode-sqlite3/lib/sqlite3.js:1:77)
at Module.u._compile (/usr/share/code/resources/app/out/vs/loader.js:4:1248)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at require (internal/modules/cjs/helpers.js:72:18)
at t (/usr/share/code/resources/app/out/vs/loader.js:5:101)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1656)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at Object.errorback (/usr/share/code/resources/app/out/vs/loader.js:5:10435)
at r.triggerErrorback (/usr/share/code/resources/app/out/vs/loader.js:3:10626)
at /usr/share/code/resources/app/out/vs/loader.js:3:10332
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1673)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at r._loadModule (/usr/share/code/resources/app/out/vs/loader.js:5:10444)
at r._resolve (/usr/share/code/resources/app/out/vs/loader.js:6:452)
at r.defineModule (/usr/share/code/resources/app/out/vs/loader.js:5:6145)
at r._relativeRequire (/usr/share/code/resources/app/out/vs/loader.js:5:6831)
at n (/usr/share/code/resources/app/out/vs/loader.js:5:9420)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31711
at new Promise ()
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31691
at new Promise ()
at y.doConnect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31671)
at y.connect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31117)
at new y (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:28457)
at m.doCreate (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:9829)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:8715
at m.init (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:9057)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:12529
[main 2021-05-05T09:21:51.210Z] [uncaught exception in main]: Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node) [main 2021-05-05T09:21:51.210Z] Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1812)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1250:18)
at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2039)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at v (/usr/share/code/resources/app/out/vs/loader.js:4:694)
at Object. (/usr/share/code/resources/app/node_modules.asar/vscode-sqlite3/lib/sqlite3.js:1:77)
at Module.u._compile (/usr/share/code/resources/app/out/vs/loader.js:4:1248)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at require (internal/modules/cjs/helpers.js:72:18)
at t (/usr/share/code/resources/app/out/vs/loader.js:5:101)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1656)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at Object.errorback (/usr/share/code/resources/app/out/vs/loader.js:5:10435)
at r.triggerErrorback (/usr/share/code/resources/app/out/vs/loader.js:3:10626)
at /usr/share/code/resources/app/out/vs/loader.js:3:10332
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1673)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at r._loadModule (/usr/share/code/resources/app/out/vs/loader.js:5:10444)
at r._resolve (/usr/share/code/resources/app/out/vs/loader.js:6:452)
at r.defineModule (/usr/share/code/resources/app/out/vs/loader.js:5:6145)
at r._relativeRequire (/usr/share/code/resources/app/out/vs/loader.js:5:6831)
at n (/usr/share/code/resources/app/out/vs/loader.js:5:9420)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31711
at new Promise ()
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31691
at new Promise ()
at y.doConnect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31671)
at y.connect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31117)
at new y (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:28457)
at m.doCreate (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:9829)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:8715
at m.init (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:9057)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:12529
[main 2021-05-05T09:21:51.266Z] SharedProcess: IPC ready
[26232:0505/172151.275594:INFO:CONSOLE(26)] "Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (26) [main 2021-05-05T09:21:51.276Z] Main->SharedProcess#connect: connection established /usr/share/code/code: /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0: no version information available (required by /usr/share/code/code) [26232:0505/172151.299262:INFO:CONSOLE(26)] "Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (26)
[26232:0505/172151.300748:INFO:CONSOLE(25)] "%cTRACE color: #888 sharedProcess configuration {"machineId":"697c19e2b96e3bd412decf8f5e12b9313864b03a9bb2e4f62499f17ef6671adc","windowId":2,"appRoot":"/usr/share/code/resources/app","nodeCachedDataDir":"/home/vivi/.config/Code/CachedData/3c4e3df9e89829dce27b7b5c24508306b151f30d","backupWorkspacesPath":"/home/vivi/.config/Code/Backups/workspaces.json","userEnv":{"VSCODE_IPC_HOOK":"/run/user/1000/vscode-10f03b6b-1.55.2-main.sock","VSCODE_NLS_CONFIG":"{"locale":"en-us","availableLanguages":{},"languagePackSupport":true}"},"args":{"":[],"diff":false,"add":false,"goto":false,"new-window":false,"reuse-window":false,"wait":false,"help":false,"list-extensions":false,"show-versions":false,"version":false,"verbose":true,"status":false,"prof-startup":false,"prof-v8-extensions":false,"disable-extensions":false,"disable-gpu":true,"telemetry":false,"debugRenderer":false,"logExtensionHostCommunication":false,"skip-release-notes":false,"disable-telemetry":false,"disable-updates":false,"disable-keytar":false,"disable-crash-reporter":false,"crash-reporter-id":"da42a552-ec4b-4fa2-8b4c-cfe2de23baec","skip-add-to-recently-opened":false,"unity-launch":false,"open-url":false,"file-write":false,"file-chmod":false,"driver-verbose":false,"force":false,"do-not-sync":false,"trace":false,"force-user-env":false,"force-disable-user-env":false,"open-devtools":false,"__sandbox":false,"no-proxy-server":false,"nolazy":false,"force-renderer-accessibility":false,"ignore-certificate-errors":false,"allow-insecure-localhost":false,"logsPath":"/home/vivi/.config/Code/logs/20210505T172150"},"logLevel":0}", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25)
[26232:0505/172151.303815:INFO:CONSOLE(25)] "%cTRACE color: #888 Started scanning user extensions", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25)
[26232:0505/172151.314600:INFO:CONSOLE(626)] "%cTRACE color: #888 Settings Sync: Initializing accounts", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (626)
[26232:0505/172151.315095:INFO:CONSOLE(626)] "%cTRACE color: #888 Settings Sync: Getting accounts for microsoft", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (626)
[main 2021-05-05T09:21:51.315Z] RequestService#request https://update.code.visualstudio.com/api/update/linux-x64/stable/3c4e3df9e89829dce27b7b5c24508306b151f30d
[main 2021-05-05T09:21:51.316Z] resolveShellEnv(): skipped (VSCODE_CLI is set)
[26232:0505/172151.325358:INFO:CONSOLE(25)] "%cTRACE color: #888 Started scanning system extensions", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25)
[26232:0505/172151.325463:INFO:CONSOLE(25)] "%cTRACE color: #888 Started scanning user extensions", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25)
[26232:0505/172151.325516:INFO:CONSOLE(26)] "Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (26) [main 2021-05-05T09:21:51.325Z] SharedProcess: Overall ready [26232:0505/172151.327039:INFO:CONSOLE(25)] "%cTRACE color: #888 Extension VSIX downlads cache dir does not exist", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25) [26232:0505/172151.334820:INFO:CONSOLE(626)] "%cTRACE color: #888 StartupGettingStarted: undefined", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (626) [26232:0505/172151.385640:INFO:CONSOLE(2786)] "Extension Host", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (2786) [26232:0505/172151.386022:INFO:CONSOLE(25)] "%cTRACE color: #888 Scanned user extensions: 0", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25) [26232:0505/172151.386325:INFO:CONSOLE(2786)] "%c/usr/share/code/code: /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0: no version information available (required by /usr/share/code/code)  color: red", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (2786) [26232:0505/172151.386499:INFO:CONSOLE(25)] "%cTRACE color: #888 Scanned user extensions: 0", source: file:///usr/share/code/resources/app/out/vs/code/electron-browser/sharedProcess/sharedProcessMain.js (25) [26232:0505/172151.386745:INFO:CONSOLE(2786)] "console.groupEnd", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (2786) [26232:0505/172151.387942:INFO:CONSOLE(626)] "%cTRACE color: #888 [File Watcher (node.js)] [ADDED] /home/vivi/.config/Code/logs/20210505T172150/output_1_20210505T172150", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (626) Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1812)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1250:18)
at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2039)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at v (/usr/share/code/resources/app/out/vs/loader.js:4:694)
at bindings (/usr/share/code/resources/app/node_modules.asar/bindings/bindings.js:112:48)
at Object. (/usr/share/code/resources/app/node_modules.asar/spdlog/index.js:3:35)
at Module.u._compile (/usr/share/code/resources/app/out/vs/loader.js:4:1248)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at require (internal/modules/cjs/helpers.js:72:18)
at t (/usr/share/code/resources/app/out/vs/loader.js:5:101)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1656)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at Object.errorback (/usr/share/code/resources/app/out/vs/loader.js:5:10435)
at r.triggerErrorback (/usr/share/code/resources/app/out/vs/loader.js:3:10626)
at /usr/share/code/resources/app/out/vs/loader.js:3:10332
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1673)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at r._loadModule (/usr/share/code/resources/app/out/vs/loader.js:5:10444)
at r._resolve (/usr/share/code/resources/app/out/vs/loader.js:6:452)
at r.defineModule (/usr/share/code/resources/app/out/vs/loader.js:5:6145)
at r._relativeRequire (/usr/share/code/resources/app/out/vs/loader.js:5:6831)
at n (/usr/share/code/resources/app/out/vs/loader.js:5:9420)
at D.E (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:4705)
at new Promise ()
at D (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:4685)
at n._createSpdLogLogger (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:5618)
at new n (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:5434)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:58:2009
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async K.startup (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:58:1819) {
phase: 'loading',
moduleId: 'spdlog',
neededBy: [ '===anonymous3===' ]
}
---------INFO2---------

INFO2 : code --verbose --use-gl=swiftshade:
[main 2021-05-05T09:16:27.380Z] [uncaught exception in main]: Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node) [main 2021-05-05T09:16:27.380Z] Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1812)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1250:18)
at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2039)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at v (/usr/share/code/resources/app/out/vs/loader.js:4:694)
at Object. (/usr/share/code/resources/app/node_modules.asar/vscode-sqlite3/lib/sqlite3.js:1:77)
at Module.u._compile (/usr/share/code/resources/app/out/vs/loader.js:4:1248)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at require (internal/modules/cjs/helpers.js:72:18)
at t (/usr/share/code/resources/app/out/vs/loader.js:5:101)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1656)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at Object.errorback (/usr/share/code/resources/app/out/vs/loader.js:5:10435)
at r.triggerErrorback (/usr/share/code/resources/app/out/vs/loader.js:3:10626)
at /usr/share/code/resources/app/out/vs/loader.js:3:10332
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1673)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at r._loadModule (/usr/share/code/resources/app/out/vs/loader.js:5:10444)
at r._resolve (/usr/share/code/resources/app/out/vs/loader.js:6:452)
at r.defineModule (/usr/share/code/resources/app/out/vs/loader.js:5:6145)
at r._relativeRequire (/usr/share/code/resources/app/out/vs/loader.js:5:6831)
at n (/usr/share/code/resources/app/out/vs/loader.js:5:9420)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31711
at new Promise ()
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31691
at new Promise ()
at y.doConnect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31671)
at y.connect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31117)
at new y (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:28457)
at m.doCreate (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:9829)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:8715
at m.init (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:9057)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:50:12529
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/spdlog/build/Release/spdlog.node)
at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1812)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1250:18)
at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2039)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at v (/usr/share/code/resources/app/out/vs/loader.js:4:694)
at bindings (/usr/share/code/resources/app/node_modules.asar/bindings/bindings.js:112:48)
at Object. (/usr/share/code/resources/app/node_modules.asar/spdlog/index.js:3:35)
at Module.u._compile (/usr/share/code/resources/app/out/vs/loader.js:4:1248)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
at Module.load (internal/modules/cjs/loader.js:1039:32)
at Module._load (internal/modules/cjs/loader.js:932:14)
at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
at Module.require (internal/modules/cjs/loader.js:1079:19)
at require (internal/modules/cjs/helpers.js:72:18)
at t (/usr/share/code/resources/app/out/vs/loader.js:5:101)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1656)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at Object.errorback (/usr/share/code/resources/app/out/vs/loader.js:5:10435)
at r.triggerErrorback (/usr/share/code/resources/app/out/vs/loader.js:3:10626)
at /usr/share/code/resources/app/out/vs/loader.js:3:10332
at r.load (/usr/share/code/resources/app/out/vs/loader.js:4:1673)
at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
at l (/usr/share/code/resources/app/out/vs/loader.js:5:10314)
at r._loadModule (/usr/share/code/resources/app/out/vs/loader.js:5:10444)
at r._resolve (/usr/share/code/resources/app/out/vs/loader.js:6:452)
at r.defineModule (/usr/share/code/resources/app/out/vs/loader.js:5:6145)
at r._relativeRequire (/usr/share/code/resources/app/out/vs/loader.js:5:6831)
at n (/usr/share/code/resources/app/out/vs/loader.js:5:9420)
at D.E (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:4705)
at new Promise ()
at D (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:4685)
at n._createSpdLogLogger (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:5618)
at new n (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:5434)
at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:58:2009
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async K.startup (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:58:1819) {
phase: 'loading',
moduleId: 'spdlog',
neededBy: [ '===anonymous3===' ]
}

/duplicate https://github.com/microsoft/vscode/issues/115784
Please install gcc-5 or higher toolchain to fix the issue.


Help creating a user with "Admin" role

Hello @amamenko
I need help:

setting up/creating a user with the "Admin"

A user with admin roles as previlges:

Add new staff members.
Delete clients and staff members.
Update all clients' and staff members' profile photos.
View and manage all staff members' calendars.
as explained here:  https://github.com/amamenko/GlowLabs/blob/master/README.md
Looking forward to your feedback
much thanks,
Naftali Murgor

To get started with the very first admin account, create a new employee in MongoDB with the attributes firstName, lastName, email, password, phoneNumber, employeeRole, and permanentPasswordSet attribute set to true. The employeeRole should be an array that contains, at minimum, the string “Admin” to allow additional admin privileges like creating additional staff members. You can add other roles but the "Admin" grants that specific employee the most privileges.
After you create that first admin account in MongoDB, you can log in on the admin page with the email and password you entered above, which will trigger a GraphQL admin login query that returns an admin dummy cookie, access cookie, and refresh cookie on the client side. You will then be redirected to the admin dashboard page.


remove extra case not needed anymore

@keybase/react-hackers 1 liner

@keybase/react-hackers bump 1 liner


Settings Report page is broken

Sometime in the past week or two, the "Settings Report" page of our docs appears to have broken. It no longer renders the big table of all the settings. This is what I see when I go to the page:

I guess we need to find the commit that broke this.  Damn.


simplify covers by replacing ebok with pdoc

fix #765

fix #685

fix #508

builds off #764

Test builds:
~~https://github.com/axu2/kcc/releases/tag/v6.2.1-pdoc~~
~~https://github.com/axu2/kcc/releases/tag/v6.2.1-comicrack-pdoc~~
https://github.com/axu2/kcc/releases/tag/v6.3.0
The Kindle Colorsoft has been reported to not expose the system/thumbnails folder for covers, so here's a workaround and pre-built exe.
It just replaces EBOK tag with PDOC, so Kindle reads the cover directly from the file. Please test and tell me if it has issues.
Also, should I remove the ASIN tag?
And does anyone remember when pdoc covers started being read by Kindles? @Zappy86

Please research this topic before blindly messing with headers. This affect a lot of things other than covers.

@AcidWeb Is there a list anywhere of differences?

No. It was never properly documented but it impact how e-reader and kindlegen handle such file.

I see. I'll continue testing the files generated with this change and asking for feedback from testers. All I know is that EBOK was required in the past for covers but that isn't true now.

If plan to switch to PDOC then you in general can drop entire code that modify headers and send cover thumbnails .

Will need to leave that code in for older kindles that can only get covers for EBOK. On mobile read a user confirmed it's  still needed for kindle voyage on latest firmware.

Will tentatively force pdoc for these models:
    ProfilesKindlePDOC = {
        'KO': ("Kindle Oasis 2/3/Paperwhite 12/Colorsoft 12", (1264, 1680), Palette16, 1.8),
        'K11': ("Kindle 11", (1072, 1448), Palette16, 1.8),
        'KPW5': ("Kindle Paperwhite 5/Signature Edition", (1236, 1648), Palette16, 1.8),
        'KS': ("Kindle Scribe", (1860, 2480), Palette16, 1.8),
    }

Kindle 11th gen (2022) does not use MTP, its just 11th gen (2024). Will there be an option to distinguish between the two?

@asilentdreamer is there any reason to distinguish? It should still be able to read cover from PDOC.

I see. In that case there doesn't seem to be one.


Workflow for version increment automation.

Description
Central workflow to auto raise the version increment PR's.
Example: https://github.com/prudhvigodithi/job-scheduler/pull/1, https://github.com/prudhvigodithi/common-utils/pull/1
Issues Resolved
Related Issue: https://github.com/opensearch-project/opensearch-build/issues/2223
Part of: https://github.com/opensearch-project/opensearch-build/issues/1375
From solution: https://github.com/opensearch-project/opensearch-build/issues/1375#issuecomment-1159476686
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Pushing with workflow_dispatch, to allow the workflow to be called (multiple times if required )manually from Gh UI, once confident with the workflow jobs execution, this will be modified to go with tag creation.
on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: Log level
        required: true
        default: warning
        type: choice
        options:
          - info
          - warning
          - debug

Codecov Report

Merging #2291 (5302edd) into main (a2c2d3a) will increase coverage by 5.42%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #2291      +/-   ##
=============================================
+ Coverage     94.57%   100.00%   +5.42%
=============================================
  Files           206         6     -200
  Lines          4255       105    -4150
  Branches         29        19      -10
=============================================
- Hits           4024       105    -3919
+ Misses          225         0     -225
+ Partials          6         0       -6

Impacted Files
Coverage Δ

...est_workflow/perf_test/perf_single_node_cluster.py

src/test_workflow/test_recorder/test_recorder.py

...workflow/opensearch/build_artifact_check_plugin.py

src/test_workflow/test_recorder/log_recorder.py

src/build_workflow/build_args.py

src/ci_workflow/ci_check_list_source_ref.py

src/manifests/build/build_manifest_1_1.py

src/paths/output_dir.py

src/test_workflow/perf_test/perf_test_runner.py

tests/jenkins/jobs/PromoteArtifacts_Jenkinsfile

... and 190 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a2c2d3a...5302edd. Read the comment docs.

Hey @dblock I have pushed with the changes you have suggested, please check the test execution link
https://github.com/prudhvigodithi/opensearch-build/actions/runs/2665344917
Only thing I need more info in on your suggestion to use GITHUB_TOKEN, so you want to use GITHUB_TOKEN from the existing organization GitHub App?

@dblock
I mean this is going to be run as a cron, so why isn't this token: ${{ secrets.GITHUB_TOKEN }}. Who maintains CIBOTAUTOPR, is it something new?

We need a secret a create a PR cross repo, from build repo to plugin repo, hence we need token as secret that has the required permission,  do you recommend to go with GITHUB_TOKEN from the existing organization GitHub App?

@dblock
I mean this is going to be run as a cron, so why isn't this token: ${{ secrets.GITHUB_TOKEN }}. Who maintains CIBOTAUTOPR, is it something new?

We need a secret a create a PR cross repo, from build repo to plugin repo, hence we need token as secret that has the required permission, do you recommend to go with GITHUB_TOKEN from the existing organization GitHub App?

Ok, understood.

Could you squash the 42 commits in this PR on your side and force push and update please?

Could you please squash the 42 commits in this PR on your side and force push and update please?

Sure @dblock just did.

Instead of personal access token modified the PR to use GH app specific token as they are short lived and more secure compared to personal access token, I have tested to raise a cross repo PR using a test GH app.
Test Action: https://github.com/prudhvigodithi/opensearch-build/actions/runs/2683706846
@dblock @bbarani

👍


All columns are retrieved as null except the id column in cosmos java sdk

Query/Question
Is there any case limitation on the column names in a document in cosmos DB SQL API? Below is how the columns names are for a document in my container:
"id"
"LAST_NM"
"FIRST_NM"
"MIDDLE_NM" and some other columns.
But when we query the container with id using azure-cosmos APIs for SQL we are getting these columns as null only Id columns is populated. Please let us know if there is any limitation on the naming convention.
Why is this not a Bug or a feature Request?
Not sure maybe a bug.
Setup (please complete the following information if applicable):

OS: Window/Linux
IDE: Eclipse
Library/Libraries: com.azure:azure-cosmos:4.4.0

Information Checklist
Query: SELECT * FROM <CONTAINER_NAME> WHERE <CONTAINER_NAME>.id = '12345678'
Same query when running on portal its giving the results correctly.
But if I change the column name in cosmos document to like last_NM, first_NM then data is coming fine.

[ *] Query Added
[ *] Setup information Added

Hi Team, any update on this issue?

@rhyashu - azure-cosmos 4.4.0 is quite old, can you please try to reproduce this issue on the latest version of azure-cosmos V4 SDK - 4.27.0 ?
We can then investigate if the issue persists.

Hi @kushagraThapar , we just took the sample project that gets created from the quick start tab from cosmos Db resource in azure portal. After that you can create a container with name of the columns in all CAPS. Please let me know if you need any other details from our side. Thanks.

@rhyashu - I did a quick test, and I am able to retrieve all the columns as it is -
Response is : {"id":"9bb79050-b830-48b0-8004-7fefee064442","mypk":"9bb79050-b830-48b0-8004-7fefee064442","sgmts":[[6519456,1471916863],[2498434,1455671440]],"FIRST_NM":"firstName","LAST_NM":"lastName","_rid":"jHUIAOjElY8BAAAAAAAAAA==","_self":"dbs/jHUIAA==/colls/jHUIAOjElY8=/docs/jHUIAOjElY8BAAAAAAAAAA==/","_etag":"\"6900a8a5-0000-0800-0000-6231114a0000\"","_attachments":"attachments/","_ts":1647382858}

This is how I am creating the object ->
private ObjectNode getDocumentDefinition(String documentId, String pkId) throws JsonProcessingException {

        String json = String.format("{ "
                + "\"id\": \"%s\", "
                + "\"mypk\": \"%s\", "
                + "\"sgmts\": [[6519456,<PHONE_NUMBER>], [2498434,<PHONE_NUMBER>]], "
                + "\"FIRST_NM\": \"firstName\", "
                + "\"LAST_NM\": \"lastName\""
                + "}"
            , documentId, pkId);
        return
            OBJECT_MAPPER.readValue(json, ObjectNode.class);
    }

And this is how I am querying the data ->
String query = String.format("SELECT * from c where c.id = '%s'", id);
        CosmosQueryRequestOptions cosmosQueryRequestOptions = new CosmosQueryRequestOptions();

        CosmosPagedIterable<ObjectNode> feedResponseIterator1 =
                container.queryItems(query, cosmosQueryRequestOptions, ObjectNode.class);

feedResponseIterator1.forEach(response -> {
            logger.info("Response is : {}", response);
        });

Thanks @kushagraThapar , even I am getting the values when using the ObjectNode as response type but when I use the custom java bean class then getting these columns as null.
This is my document and bean class:
{
"PATIENT_ID": "00446373",
"CLIENT_ID": "12345"
"LAST_NM": "YlEytrw",
"FIRST_NM": "KlservkrJ1",
"MIDDLE_NM": "c",
"COV_EFFECTIVE_DT": "2018-10-18T00:00:00",
"COV_TERMINATION_DT": "2018-11-01T00:00:00",
"DOB": "1853-04-04T00:00:00",
"DOB_YRMNTH": "185304",
"id": "91a46f31-85c1-45e0-845f-944a9d7b6f44",
"_rid": "XcEIAJi-RGsBAAAAAAAACA==",
"_self": "dbs/XcEIAA==/colls/XcEIAJi-RGs=/docs/XcEIAJi-RGsBAAAAAAAACA==/",
"_etag": ""0000fb00-0000-0200-0000-61bb12450000"",
"_attachments": "attachments/",
"_ts":<PHONE_NUMBER>
}
private String ID;
private String CLIENT_ID;
private String FIRST_NM;
private String LAST_NM;
private String COV_EFFECTIVE_DT;
private String COV_TERMINATION_DT;
private String DOB;

corPatList {}[CorPatient [ID=91a46f31-85c1-45e0-845f-944a9d7b6f44,CLIENT_ID=null, DOB=null, FIRST_NM=null, LAST_NM=null]]

Could be an issue with Jackson deserialization, and not related to cosmos SDK. Please check if jackson deserialization is happening correctly when the response is converted to your custom Pojo class.


Add support for flutter version manager

When using flutter version manager (fvm.app) the build_runner extension doesn't work since flutter executable is not in the path and command 'fvm flutter' should be used instead of 'flutter.
Please consider allowing 'fvm flutter' in the list of available commands or allowing to edit the command in settings.json with arbitrary values

Closing since it was a PATH issue on my end

This seems to be resolved, feel free to reopen it if you need.

我fvm工作，通过加fvm文件夹中的位置的设置。json

  "build-runner.flutterPath": ".fvm/flutter_sdk/bin/flutter",

'.fvm' �����ڲ����ⲿ���Ҳ���ǿ����еĳ���
���������ļ���


Don't generate Debian 10 or 11 armhf packages for .NET 9 or later

These configurations crash on launch due to glibc (libc6) being too old:

.NET ≥ 9, Debian 10, armhf
.NET ≥ 9, Debian 11, armhf

Everything else works fine with .NET 9.0 RC2, including Debian 10 and 11 on arm64, and Debian 12 on either armhf or arm64.
.NET 8 still works fine on armhf and arm64 on Debian 10-12.
See #27 for more testing data.

Also make sure the metapackages (-latest and -latest-lts) point to the correct .NET 8 versions on Debian 10-11 arm32.

Done, tested on Bookworm arm64, Bookworm arm32, and Bullseye arm32.


[bug] handle remove_waiter that is not there

I'm seeing this in logs sometimes:
CancelledError: null
  File "emcache/connection_pool.py", line 367, in __aenter__
    self._connection = await self._waiter

ValueError: deque.remove(x): x not in deque
...

  File "emcache/client.py", line 319, in set
    result = await self._storage_command(b"set", key, value, flags, exptime, noreply)
  File "emcache/client.py", line 114, in _storage_command
    async with node.connection() as connection:
  File "emcache/connection_pool.py", line 369, in __aenter__
    self._connection_pool.remove_waiter(self._waiter)
  File "emcache/connection_pool.py", line 309, in remove_waiter
    self._waiters.remove(waiter)

Seems that this is a serious bug, TBH I do not know how you ended up by not having a connection leaking problem here. Unless this is happening but happens not to much frequently and connections are purged or eventually closed by the server, while there is still room for new connections.
The bug could be related to the fact that a task that has been resumed or asked to be resumed in the next loop iteration, can be still be canceled within the same loop iteration, take a look to this [1] and this [2].
As an example of what could be happening
import asyncio

async def task(future):
    try:
        result = await future
    except asyncio.CancelledError:
        print("*"*30)
        print(future.result())
        raise

async def main():
    future = asyncio.get_running_loop().create_future()
    t = asyncio.ensure_future(task(future))
    await asyncio.sleep(0)
    future.set_result("fooooooooooooooo")
    t.cancel()
    await t

asyncio.run(main())

Now replace fooooooooooo by a connection instance, the result would be a connection leak. With the waiter being already removed initially during the first attempt for waking up the task.
This needs to be fixed. I'll make some comments to your PR https://github.com/pfreixes/emcache/pull/49 about what are my thoughts
[1] https://github.com/python/cpython/blob/master/Lib/asyncio/tasks.py#L234
[2] https://github.com/python/cpython/blob/master/Lib/asyncio/tasks.py#L243