🚀 Feature Request: Fix the need to have custom builds

Describe the solution
After about a year of developing with Workers, I've found there's 3 things missing from Wrangler's automatic bundling that force me to bundle myself unfortunately. It would be really nice if I didn't need to do that though.

Intercepting wrangler in between bundling and publishing.

Today uploading to Sentry through wrangler is a bit of a mess. To do so safely, I first have to run npx wrangler publish --outdir build/ --dry-run (& boy do I hope I never forget that --dry-run and accidentally publish when I didn't intend to), then I upload the generated bundle / sourcemap, and then I have to run again without the --bundle and hope the entire build process is reliably deterministic.
It would be nice to be able to specify a publish injection script that wrangler invokes after bundling but before upload. That would give me the opportunity to write my code to publish to sentry. The reason I can't publish to Sentry after wrangler is that it introduces a serious risk that the worker gets deployed but Sentry decides to flake at that point and I fail to publish the source map. In a CI environment recovering that sourcemap to publish to Sentry is annoying and usually you end up having to rerun the deployment step in CI (but it's not automatic and someone has to notice the failure).

Global variable injection (esbuild's define property). There are two main uses for doing this:

A) Parameterize version strings (e.g. what's the Sentry release tag to use)
B) Customize dev vs production behavior (i.e. remove code that's being sent to production or add code when running under miniflare).
I would expect different environments to have different build needs to. So there's probably something like:

Default build vars across all environments
Build vars specific to an environment
Command-line flags to override that var above all else.

So something like npx wrangler publish -e dev --outdir build/ --dry-run src/index.js --build-var MY_VAR:bool=true would inject MY_VAR=true even if the dev environment requested MY_VAR=false. Note the :bool aspect. It's important that wrangler inject things with the right type as this can impact esbuild's ability to elide code. E.g. if I had a code like:
if (__ONLY_FOR_DEVELOPMENT__) {
}

having anything more complex than a boolean may impact esbuild's ability to completely remove that code when __ONLY_FOR_DEVELOPMENT__ is false (which may have security implications).

Minification control

Today AFAICT it's impossible to ask wrangler to minify your code. My preferred practice is to minimize code being deployed as the "production" worker. The reason is that the unminified version isn't useful at production scale. I'm not tailing production workers so I never see stack traces and Sentry will automatically map to the source. The minified version helps me keep my bundle size more under control. Ideally the Workers ecosystem would support sourcemaps better (e.g. if I'm inspecting the worker with wrangler tail, the EW runtime could somehow annotate generated stack traces for the Error object so that the client-side display code could resolve it transparently based on the sourcemap).

Debugging what's contributing to bundle size.

The other thing that would be kind of nice, but must less important than #1 is I've used esbuild-visualizer to debug why the resultant build is larger than it should be. It would be nice if wrangler offered something like that for the bundled version.

Safety - explicit bundle entrypoint instead of publish --dry-run.

I really worry about every time I have to do this that I'll end up publishing by accident. It's fine when you're a wrangler dev and are using this as your mechanism to verify that everything up until the network path is correct. It feels a heck of a lot scarier as a wrangler user that I fat-finger something and trigger an actual deployment of code I didn't intend. Obviously I try to hide this behind npm run bundle but it does give me some anxiety for bundle and publish to be one command-line argument away (& the default if I forget to be the "dangerous" action).
The first two are fairly hard blockers. Being able to co-ordinate publishing between Cloudflare and Sentry and parameterizing what get's published are fairly regular things for larger customers. Point 3 is a really nice to have (I'm also OK if this is something like environments named "production" are minified). Point 4 and 5 are more minor developer convenience.

Omg. Missing from the docs but #2 already works?
      --var                                        A key-value pair to be injected into the script as a variable  [array]
      --define                                     A key-value pair to be substituted in the script  [array]

Another way to solve step 1 is to provide out-of-the-box uploads of source maps to Sentry. That would also be even more useful. I can help with that piece if you like (have reusable code that handles support for Cloudflare Access too)

@vlovich what part of the docs were you hoping to find this in (to help us with the information architecture)?
atm you can find --var and --define under publish here: https://developers.cloudflare.com/workers/wrangler/commands/#publish

We have the same problem with uploading sourcemaps to Bugsnag. We use no_bundle = true in our wrangler.toml and handle the bundling and sourcemaps ourselves.
Next to that we would like to set the resolveExtensions esbuild option for this particular issue involving a dual-package hazard: https://github.com/bubblydoo/graphql-worker-subscriptions#bundling-issue (in this case we can't set no_bundle = true because the D1 alpha requires bundling)
We also patch a lot of incompatible packages ourselves using define and inject. See https://github.com/bubblydoo/cloudflare-workers-compat (I made this before node_compat was a thing in wrangler, but I guess it's similar)

I'd also be interested in this to allow us to make some worker meta patches a bit less ugly. Some declarative way to plugin would be nice.

what part of the docs were you hoping to find this in (to help us with the information architecture)?

the minify configuration option (for wrangler.toml) is documented here:

I think the docs could benefit from SEO optimization for sure as Google isn't returning good hits here.
Re 5, yeah that works.

This also applies to Cloudflare Pages with "Advanced mode" functions (_worker.js). I'm using cloudflare/pages-action to deploy a GraphQL gateway, serving the GraphiQL interface and handling the gateway logic.
But the fact that wrangler pages publish minifies my worker and that there's no wrangler pages build command, there's no way for me to get an accurate source map to upload to Sentry.
Could wrangler pages publish respect wrangler.toml or add the --minify option?

I mentioned this here, but I think transitioning wrangler config to a js/ts file would open up the door for a lot of this stuff to be much simpler. You could expose the underlying esbuild instance to add plugins as necessary, and provide a place to register hooks throughout the build and deployment process.
Vite and Astro are great examples of how this could work.


[Question] How can I bundle all dependencies in server build?

Is it possible to bundle (or specific) dependencies in server build? I tried with some rollup plugins "commonjs, resolve" etc. but nothing works :(

Try with ssr.noExternal: true. It will fail if you are importing Node built-ins, though.

thanks - this works....


Resize homepage logo

The Stock Sales brand logo on the homepage should be smaller. Some specs:
Height of the logo image = 78 px (currently 123 px)
Height of the blue header = 128 px

I think this needs to be thought through.

Making the logo that small in full screen mode means it only spans a third of the page width, which doesn't seem right.
Is this supposed to change with different screen widths?
If we make the blue header shorter, how does the italicized text to the right respond? Does it get a smaller margin? Smaller text? Smaller line spacing?

If anything needs to change here, we need to tweak the html in the inspector and make sure the end result is good in all widths.

What is the size now?  Is it possible to reduce it 2 points? (e.g. if it's 24 can we go down to 22?)
Alison


error while loading shared libraries: libjsoncpp.so.19:

polybar: error while loading shared libraries: libjsoncpp.so.19: cannot open shared object file: No such file or directory
Seems to be a recurrent problem?

ok, syslinked libjsoncpp.so.20 to libjsoncpp.so.19. Now it works.

Or recompile polybar. The jsoncpp project seems to be changing the SONAME on every patch release, which means you have to recompile polybar basically everytime you update jsoncpp


Getting the DOMNode from the refs to pass to Highstock.

The previous code was not working with React 0.14.3

Thanks a lot for the PR, can you please take a look why the tests got broken?
Also a link to description of the change in React which causes this fix would be helpful.

I think I actually found the reason to why it did not work for me the first time, I will try around some more, but it seems like the Highcharts works a bit differently now so the "require" with globals and such have changed a bit. Will update PR when ready.

The problem was basically that the new highcharts did not only wanted to load the HC-adapter from global but you actually have to inject the adapter into highcharts for it to work properly. And then expose the result on the global context.

O btw, as noted in one of the commits, I did not manage to get the highcharts-more example to work, and I don't really know why. Atleast the tests are working.

I didn't realize the build was broken because of Highcharts-release update, and not something you did, so thanks a lot for the research. I am going to take a look at more.js some time next week, and merge it in.

I found out how to the get the HC-More stuff worked.

Would it be backwards compatible with react 0.14.1?

I do not know, know of any breaking changes that you have conformed with?
I have not tried any other version than defined here.

Hm, so I tried it earlier this week, and the demo worked well, now I'm getting an error saying Highcharts is not a function.

OK, I'll merge it in, and then will figure out the rest

Thanks a lot for your work!


Pattern Detection Bug: Error: Unknown feature DEPRECATION_WARNINGS_ENABLED.

I'm trying to run a pattern detection code:
    const prices = [];
    for (let i = 0; i < 1000; i += 1) {
      prices.push(i);
    }

    const isTrendingUp = require(`technicalindicators`).isTrendingUp;
    const result = await isTrendingUp({ values: prices });
    console.log(result);

Getting the following error:
Nodejs Environment detected
cpu backend was already registered. Reusing existing backend
2019-07-24 21:47:37.271092: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX FMA

Error: Unknown feature DEPRECATION_WARNINGS_ENABLED.
      at Environment.evaluateFeature (node_modules/@tensorflow/tfjs-core/src/environment.ts:367:11)
      at Environment.get (node_modules/@tensorflow/tfjs-core/src/environment.ts:271:35)
      at deprecationWarn (node_modules/@tensorflow/tfjs-node/node_modules/@tensorflow/tfjs-core/src/environment.ts:503:11)
      at Tensor.get (node_modules/@tensorflow/tfjs-node/node_modules/@tensorflow/tfjs-core/src/tensor.ts:555:5)
      at /home/bloed/github/channel/node_modules/technicalindicators/lib/patterndetection/patterndetection.js:116:42
      at Generator.next (<anonymous>)
      at fulfilled (node_modules/technicalindicators/lib/patterndetection/patterndetection.js:3:58)

Node Version: v10.16.0
Ubuntu 16.01
technicalindicators Version: 2.0.9

+1

Update:
Downgraded to technicalindicators Version: 2.0.8, and worked.
I think the issue was introduced because of https://github.com/anandanand84/technicalindicators/pull/182 ?

Tensorflow removed in 3.0


WIP: Add DSSE Envelope

Fixes: #370
Description of the changes being introduced by the pull request:
Pull Request for DSSE Envelope.

Created a container class named Envelope having attributes payload, payloadType, and signatures.
Built several methods including functions to load and dump the class into JSON/dict.
Add a method to generate Pre-Auth-Encoding for the envelope.
Add tests cases to test the metadata.py or Envelope

Please verify and check that the pull request fulfils the following requirements:

[x] The code follows the Code Style Guidelines
[x] Tests have been added for the bug fix or new feature
[x] Docs have been added for the bug fix or new feature

@lukpueh, I guess the indent size is 2 as almost all files follow it except signer.py which uses 4 space of indent. Do I have to change the indent size in metadata.py that I have created.

Do I have to change the indent size in metadata.py that I have created.

No, it's okay to use 4 in metadata.py, which is new, but 2 in util.py, which already uses 2.

I am not sure about GitHub actions can work in forks, please check if they can enable in this repository.

I just enabled them for the fork. Not sure how to trigger the workflow for the existing PR. Maybe pushing a new commit does it?

Maybe pushing a new commit does it?

I think reopening this PR would work, let me try.


Click event on child element

A button with @click.stop=$emit('your-event') inside a draggable element never captures the click event, so you can't have clickable elements inside a draggable container. Tried all kinds of options and can't figure out how to emit a custom event from a child element of a draggable element. Any help greatly appreciated.

My bad, got this working with filter and preventOnFilter options. I just hadn't configured it correctly

@quantumwebco  hello,I also encountered this problem, can you share the solution in detail? thank you

@XiaoBaiClassmate I completely changed that code now but I was trying to have a button to move the element from one list to another, by looking at the commits on that date I added a class swapLists to the button that emits the event in the child element and on the draggable instance added attributes filter=".swapLists" and preventOnFilter="true"
Something like
<draggable
      filter=".swapLists"
      preventOnFilter="true"
      class="w-full h-full h-min-6 border border-slate-300 p-4"
      handle=".cursor-grab"
      v-model="email.body"
      group="emailElements"
      v-bind="{animation: 250}"
      item-key="index">
  <template #item="{element, index}">
      <EmailElement :element="element" list="email" @swapLists="swapLists"></EmailElement>
  </template>
</draggable>

and in the EmailElement component

        {{ element.name }} : {{ element.content }}

        <button class="p-2 swapLists" @click.stop="$emit('swapLists',  {item: element.item, list: list})">
            <Icon icon="akar-icons:arrow-right-left"/>
        </button>

I found most of this info by carefully reading the docs and previous issues, so if you're still stuck the answers are definitely there, keep looking!


docs: add a SECURITY.md file

TL;DR
Added a SECURITY.md file to establish security policies and vulnerability reporting procedures.
What changed?

Created a new SECURITY.md file with version support information
Defined vulnerability reporting process and contact information
Established timeline commitments for addressing security issues
Added version support table indicating v1.x is supported while v0.x is not

How to test?

Verify SECURITY.md is accessible in the repository root
Confirm email link<EMAIL_ADDRESS>is properly formatted
Check that version support table renders correctly with emoji indicators

Why make this change?
To provide clear guidelines for security-related matters and establish a formal process for reporting vulnerabilities. This helps maintain project security and gives users a standard procedure to follow when discovering potential security issues.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#211
#210
#209
#208
#207  👈 (View in Graphite)
#206
#205
#204
next

This stack of pull requests is managed by Graphite. Learn more about stacking.

Merge activity

Dec 3, 12:04 AM EST: A user started a stack merge that includes this pull request via Graphite.


Getting assets issue with modules

Hi i m getting below error
AssetConverter command 'lessc '/var/www/html/dev/web/assets/2b7f18ca/notifications.less' '/var/www/html/dev/web/assets/2b7f18ca/notifications.css' --no-color --source-map' failed with exit code 127:
STDOUT:

STDERR:
sh: 1: lessc: not found

fixed
deleted all assets folder and run again


Components cannot reference another layer

Maybe that's working as intended, but I was just thinking that perhaps one may always want components to reference the default layer.
Right now if you add a component to a background layer it will reference the glyph of that layer.

That's actually in the UFO spec. Anyway, closing for now.


Fix applog values

This fixes #2864, but unfortunately it requires DB resynchronization. But if we're resynchronizing anyway, then we can make some additional adjustments as well.

I can't comment on the implementation, but I can say that with this PR I no longer have issues with what I was using neo-go for.

This certainly solves the issue, I've tested it with testnet dump as well, but if there are any other problem, please let us know. This fix deserves a release, so we'll be making one soon.


enchancement #68

upgrade karma and all karma dep
#68

exact dependencies please.
better commit message:
chore(test upgrade): upgrade karma and jasmine

resolves issue #68

For libraries, it's nice to have flexible dependencies so you don't force every consumer to a single version.

interesting. these are all devDependencies, so it shouldn't matter for this, right?
on that point, I do worry about breaking changes with dependency upgrades when we don't specify an exact version, but if it's best practice for libraries to be more flexible, then we can do that with the other dependencies.

Ideally everything but major releases should be backwards compatible but I'm not saying everyone npm contributor follows that guideline :smile_cat:

:ship: :it:

@adampickeral @j00k Consumers of any library should always use npm shrinkwrap to lock their entire dependency tree.

@adampickeral Dev dependencies matter because I'm pretty sure npm install installs them by default.

@adampickeral @j00k One other thing: npm3 supports flattening the dependency tree, so you don't end up with multiple versions of the same library in use. This is great for server-side, but it is very important for client-side builds to make sure you don't unnecessarily bloat your builds. When flattening dependency trees, it's very important to allow flexible versioning because the likelihood of a conflict is much higher.

i'm pretty sure devDependencies don't work that way (what would be the point?). they only get installed if you run npm install from the root of that library package.
i tested this out by requiring canon-react as a dependency, running npm install, and ensuring that none of its devDependencies were installed (not alongside canon-react in node_modules nor in node_modules within canon-react)

@adampickeral :ok_hand:

:+1:


JSDoc: function declarations are not type checked

TypeScript Version:  2.3.4
Code
{
  /** @type {function(number): number} */
  const foo = (x) => x
  foo('f') // error, good!

  /** @type {function(number): number} */
  function foo2(x) { return x }
  foo2('f') // expected error, but got none
}

In my opinion, function declarations can't use the @types tag, since functions can only be function type, just like:
declare const foo: (x: number) => number;
declare function foo2(x: number): number;

You can't use type declaration for function declaration, you have to use @param, @return.
{
  /** @type {function (number): number} */
  const foo = (x) => x
  foo('f') // error, good!

  /**
   * @param {number} x
   * @return {number}
   */
  function foo2(x) { return x }
  foo2('f') // expected error, but got none
}

@ikatyang Interesting, how would you add a property to a function declaration? I've tried using @property, to no avail:
  /**
   * @param {number} x
   * @property {number} bar
   * @return {number}
   */
  function foo2(x) { return x }
  foo2('f') // error, as expected
  foo2.bar = 1; // unexpected error

Ah, it works fine for me even without @property {number} bar.

@ikatyang I think what you're seeing is related to a different bug with JSDoc: https://github.com/Microsoft/TypeScript/issues/16239#issuecomment-306038032
If you wrap that code in a block, it will give you the unexpected error:
{
  /**
   * @param {number} x
   * @return {number}
   */
  function foo2(x) { return x }
  foo2('f') // error, as expected
  foo2.bar = 1; // unexpected error
}

{
  /**
   * @param {number} x
   * @property {number} bar
   * @return {number}
   */
  function foo2(x) { return x }
  foo2('f') // error, as expected
  foo2.bar = 1; // unexpected error
}

I think the only way to add a property to a function is using variable declaration, since you can't define a function type mixin with something else.
/**
 * @type {{ (x: number): string, bar: number }}
 * @param {number} x
 * @return {number}
 **/
var foo2 = function (x) { return x };
foo2.bar = 1;

And for the @property tag, it seems TS only support with Object|object, see wiki.
@type: variable/property declaration
@property: @typedef {object or Object}
@param ,@return: function/method declaration

Thanks. I think your original conclusion was right. I can't find of any way to do this in .ts files with function declarations, other than converting to a function expression, so it makes sense that you can't do it with JSDoc too.


Unit tests for the Console

Write all unittests for console.py, all features!
For testing the console, you should “intercept” STDOUT of it, it's highly recommend you use:
with patch('sys.stdout', new=StringIO()) as f:
    HBNBCommand().onecmd("help show")

Otherwise, you will have to re-write the console by replacing precmd by default

Done with the tests for the console.py


307 Redirect to S3

Hi There,
Thanks for this effort. I was reviewing your code and had a question. We have a client that has very strict network rules, as in they can only reach one Public IP address.
We have an ECR set up with an nginx proxy in front. We were thinking about using your solution in front of our "master" ECR so all of the restricted environments can get to it (client -> proxy -> api gateway -> ecr). At this point, we are able to proxy to ECR to log in, but when we pull, we see these 307's to S3. Our client systems can get the S3 URL. When we direct the traffic to our proxy, we get an SSL Cert error (as expected).
So we want to intercept these S3 requests, or I guess rewrite them on the way out so the client system doesn't try to hit S3, and tries to pull the blob from our domain (which we ca then proxy). I wanted to see if your solution is making the assumption that the calling system has access to any URL, and that you are just masking the overall domain.
Thanks again.

I'm not sure I 100% understand your setup but I can tell I tried to make this with as few assumptions as possible. Let me walk through an example to see if that clears things up:
Assumptions I am making:

ecr.private.io is the custom DNS name we will use to reference our ECR registry
Our real ECR registry host is<PHONE_NUMBER>12.dkr.ecr.us-east-1.amazonaws.com

Example workflow:

I execute docker pull ecr.private.io/my-image on my machine
My local docker client translates this command into a series of HTTP requests to https://ecr.private.io/v2/* (eg, https://ecr.private.io/v2/my-image/manifests/latest)
Each of these requests is received by AWS (Route53 -> API Gateway -> Lambda), which returns an AWS proxy response JSON: {"statusCode":307,"headers":{"location":"https://123456789012.dkr.ecr.us-east-1.amazonaws.com/*"}} where * in the location header is whatever the original request path is.
If I have access to whatever this redirect location is then the request should succeed, if I don't then the request fails.

Does that clear things up at all?

It does, and thanks for putting it together.
My issue is #4, where the client can't access anything else but the IP address to which ecr.private.io resolves. I need to perform a rewrite on the return content, in this case, using ngx_http_sub_module, and manage the additional traffic.
Thanks again.

ah ok, yes this project assumes the end-user has access to both the DNS alias (ecr.private.io) and the raw ECR endpoint<PHONE_NUMBER>12.dkr.ecr.us-east-1.amazonaws.com) via AWS keys + docker credential helper


Bold characters appearing next to text due to additional space

Repro steps:

Go to https://msdn.microsoft.com/en-us/VBA/Access-VBA/articles/form-keypress-event-access
See the "** KeyAscii**" text under the "Syntax Header"

Actual results:
Text is shown as ** KeyAscii** instead of a bold text
Expected results:
Text should be shown as bold
GH article:
https://github.com/OfficeDev/VBA-content/blob/live/VBA/Access-VBA/articles/form-keypress-event-access.md
Proposed fix:
Remove the additional space at the beginning so that the text will apear bold.

Fixed issue but am not seeing changes on stage or live yet.

The fix is now live: https://msdn.microsoft.com/en-us/VBA/Access-VBA/articles/form-keypress-event-access


[bmrg-auth-proxy] Authentication fails when using basic-auth mode

Describe the bug
Authentication fails when auth.displayHtpasswdForm is set to true
To Reproduce

Install bmrg-auth-proxy chart using basic-auth
Install bmrg-bosun chart
Access bmrg-bosun's launchpad
Login using the configured basic-auth credentials

Actual result: authentication fails
Expected behavior
Authentication is successful when using basic-auth mode.
Screenshots

Additional context
deployment.yaml file contains an extra - (dash) at the end of the if statement line, thus, when the pod is created it will inherit the value inline (as seen in the screenshot above) and not as an auth.args list item.

Closed by #4


Stokes drift for constant winds

This PR adds a new type of AbstractStokesDrift for use with Oceananigans that's appropriate for constant winds over an infinite or isolated patch of ocean. See https://github.com/CliMA/Oceananigans.jl/issues/2290. for preliminary discussion. I've decided to implement this feature in LESbrary.jl because I think it's currently experimental nature means it's not yet appropriate for Oceananigans.jl.
The basic idea is that our idealized cases in IdealizedExperiments/three_layer_constant_fluxes.jl are meant to represent a scenario in which either infinite or large-scale winds or cooling associated with constant air-sea fluxes act "instantaneously" on a quiescent patch of ocean.
The surface wave field that's consistent with this scenario is one that develops in time in response to atmospheric winds that impose constant momentum fluxes into the ocean.
We have to make a choice about the initial sea state because there are many plausible sea states consistent with an initially quiescent ocean interior. This reflects the fact that the surface wave field is, in reality, partly non-local due to distant swell generation and propagation. Here I think we are best served by choosing a "near-quiescent" (not entirely quiescent, since this is a singularity of our model as we will see below) initial sea state as well. This biases our cases towards "calm before storm" physical scenarios, rather than "train of storm" physical scenarios. My initial hunch is that moving towards more complex forcing / sea states is better served with "realistic" cases, rather than attempting to describe all possible ocean conditions with an idealized setup.
Note that we can't really comment about whether atmospheric wind is constant, because air-sea momentum fluxes depend on both the surface wave field and the atmospheric wind, in general (despite the current state-of-the-art in bulk formulae). Yet we don't need to comment on this, because the only thing that matters for ocean dynamics (and boundary layer parameterization) is the momentum flux into the ocean. This is important because it means that our results are independent of how the air-sea momentum flux is parameterized, and thus a bit more robust to future developments and improvements in air-sea momentum flux parameterization.
The ConstantFluxStokesDrift model
It has two components:

A Stokes drift profile that depends on (i) the peak wavenumber of the surface wave spectrum and (ii) the local wind stress (specifically, air friction velocity) based on Lenain and Pizzo 2020.
A model for the time-dependence of the peak wavenumber appropriate for "infinite constant fluxes" based on Lenain and Melville 2017.

The Stokes drift profile
Some preliminary results are here:

which compare to a profile proposed by Breivik et al., 2016.
The main difference between Lenain and Pizzo 2020's parameterization and Breivik et al., 2016's is stronger shear near the surface.
This plot shows the dependence of the surface Stokes drift for different peak wavelengths:

It's being compared to a model proposed by Li et al. 2017 that assumes a constant peak wavenumber for a given momentum flux / atmospheric wind speed.
Evolution of the peak wavenumber
By manipulating the fetch relationships in Lenain and Melville 2017 we come up with a formula for how the peak wavenumber decreases in time:

We should comment on how this compares to, say, a 0D simulation using wave watch III or something similar.

cc @qingli411

Some results for the one day suite:

and the two day suite:


fixed header name that wasn't using the right color

css didn't apply the --light color properly for text inside the header

gitlab haha

Thank you a lot for contributing! :tada:


Deprecate sources in favour of origins

Problem
Maintaining both sources and origins is cumbersome. Migrating all sources to origins would allow us to deprecate a significant amount of code in both ETL and Grapher, potentially speeding up the process. We've already migrated the most critical datasets to origins and are currently migrating the rest as needed. However, a one-time full migration might be more efficient.
Solution
Full migration to origins in snapshots
This would involve migrating all sources in snapshots to origins. We’d need to devise an automatic source-to-origin transformation and modify all steps to use Table instead of DataFrame to ensure proper origin propagation.
Adding origins to YAML files
For all garden and grapher datasets, we could extract sources, automatically migrate them to origins, and add them to the metadata YAML files (potentially as *.meta.override.yml).
TODO

[ ] How many (unarchived) datasets still use sources?

It would be good to understand the size of the migration needed to work out if it's worthwhile now.

Searching for sources: in YAML files returned 193 results in 121 files (for active steps). This would entail rewrite of snapshots, metadata, etc... totally not worth it, given that sources haven't been causing problems recently.


feat: Add onSessionUpdate prop to get client instance

Run npm update
Update all dependencies
feat: Add onInit to SeamProvider

@xplato Any other ideas for the prop name? I stared with onInit and then moved to onSessionUpdate. I don't hate this name but would entertain some alternatives.

@razor-x I think both are good. Does the client only update once after init? You could do onSessionInit to make it clear that it should only change ~once (unless, of course, it's expected to update several times).

@razor-x I think both are good. Does the client only update once after init? You could do onSessionInit to make it clear that it should only change ~once (unless, of course, it's expected to update several times).

@xplato No, that's why I changed the name. The method will be called whenever the client session is refreshed or changed, say if the token expires, or the user identifier key prop changes (then a new client would be created)


PR for issue #2214

Added the defaultText parameter to the notifier text dialogue, gave this parameter an empty string as its default value.
@ewpatton

Can one of the admins verify this patch?

Hi! Technically I'm not supposed to review PRs, but I noticed that you had some IDE files in your PR. Before you try adding them to the .gitignore I'd recommend looking into the git exclude file which is used for excluding local files.

Definitely remove the .metadata directory from the commit (use git rm --cached .metadata to remove it from git without actually deleting it). You should also reset lib/blockly since you likely haven't made changes to it. If mit-cml is set as a remote called upstream, you should be able to do git checkout upstream/master lib/blockly; git submodule update; git add lib/blockly to bring it to where master is.

@BeksOmega You're welcome to review PRs, but an MIT staff member needs to actually merge it.


Trying to subscript globals or locals directly

$ python -m friendly_traceback

Friendly Console version 0.2.19. [Python version: 3.9.0]

>>> x = 1
>>> globals['x']

Traceback (most recent call last):
  File "<friendly-console:2>", line 1, in <module>
    globals['x']
TypeError: 'builtin_function_or_method' object is not subscriptable

Did you mean globals('x')?
>>> globals('x')

Traceback (most recent call last):
  File "<friendly-console:3>", line 1, in <module>
    globals('x')
TypeError: globals() takes no arguments (1 given)

Most likely the expectation was that globals is the dict and hence the intention was to do globals()['x'].

As mentioned in another comment, TypeError are not included.

As mentioned in another comment, TypeError are not included.

No problem, I thought it might be useful to special case locals and globals in this case.

No problem, I thought it might be useful to special case locals and globals in this case.

Moved to TypeError cases issue.


Add function to check if service can be started

Based on 2 facts:

service exists
all required services are exist as well

What's the use case for these changes? Why do we care if required services exist?

Some requirements could not be met, even for Plesk services. We identified an issue with the plesk-ext-monitoring-hcd service, which cannot be started without the Grafana extension installed. Therefore, we need to verify if the Grafana service at least exists. Ideally can be started.

The check seems to be very limited. It checks only first-order required services existence, but doesn't check if they are startable. Also, a service could be unstartable even if required services exist.

Yes, checking if all of the services could be started might be a good idea.

Some requirements could not be met, even for Plesk services. We identified an issue with the plesk-ext-monitoring-hcd service, which cannot be started without the Grafana extension installed.

And what happens then?

And what happens then?

Because we are using mass operations for systemctl, it will be seen as failed. At least on CentOS 7 and possibly on older versions of Ubuntu as well, but I am not certain. As a result, we will not be able to continue process (reversion process in this case).

If someone disabled the service before us, why should we enable it?

Ideally, we wouldn't do this, but in this situation, we have to store a list of the services we have been working with. I suggest creating an issue to address this.


Add k8s adminer

What do these changes do?
These changes introduce traefik, adminer and cert-manager (SSL certs) charts
FYI: @matusdrobuliak66 @sanderegg @pcrespov
Related issue/s

https://github.com/ITISFoundation/osparc-ops-environments/issues/669

Related PR/s

https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/merge_requests/630

Checklist

[ ] I tested and it works

cool! I guess at some point we should do a workshop...

This is a good idea. It will be also helpful for me to revise / increase further my knowledge of kubernetes


passing directions-options

see https://github.com/mapzen/lrm-mapzen/issues/38

closing with c9de3d3a0e05418b4e29e64594c3668811838872


Style/ConcatArrayLiterals documentation mismatch

In the Style/ConcatArrayLiterals documentation section it says that cop is unsafe, but the header says it is safe. Who is lying? 😄

https://docs.rubocop.org/rubocop/1.41/cops_style.html#styleconcatarrayliterals

The doc "Safety" description is correct and fixed by https://github.com/rubocop/rubocop/commit/8bb0c47e7a654a72dcfb7024083cbb4898cae03d. Thank you!

Thank you!

By the way, its autocorrection is not working (not even with -A flag) 🙂


WIP: Classification and Clustering Project

@pttzty @MengfeiJiang
I initiated the pull request, let's start code review and see what we need to improve.
Issue #125

Like I suspected... lots of style errors. Please fix first @pttzty @MengfeiJiang
Don't forget to pull from my fork first, since I've done some updates since your last pull.

@changsiyao Sure, will look at it and fix style errors.

Coverage increased (+10.6%) to 52.451% when pulling d6be9adbf4b120c88c78177c688893e5698cd062 on changsiyao:classification into 7f1027ca36f1bd947c4525efed3f155dea9c0cc3 on berkeley-stat222:master.

Coverage increased (+6.3%) to 52.451% when pulling 49e0f28410206065d99f8d4193b1bbf26219bf3e on changsiyao:classification into 4a83e2dddbb63750d5fda889e2b8306ddbb4275c on berkeley-stat222:master.

Also, the plot functions should be moved to the visualization directory.

Coverage increased (+9.2%) to 55.331% when pulling 757390a20566979cbbc0c65b4177fa177bd8e35d on changsiyao:classification into 4a83e2dddbb63750d5fda889e2b8306ddbb4275c on berkeley-stat222:master.

Coverage increased (+8.06%) to 58.011% when pulling 4ab6e746b83aee1f337c5ea7e835ea7f4e9c1270 on changsiyao:classification into 19116d4bdb0dea4f7ad02f0e8d09bfdc7cb5409a on berkeley-stat222:master.

Coverage increased (+8.06%) to 58.011% when pulling 6ec140f883a9e60adf69f002caa1aebcbd75a72b on changsiyao:classification into d55d7135dafc137ed2bc4609d57579afedc74c82 on berkeley-stat222:master.

Coverage increased (+7.7%) to 58.976% when pulling 248f221841edb9f9b84c0317336c3faa43f7868e on changsiyao:classification into 38b3bf968f302ad6677de11e1a12590a5628f135 on berkeley-stat222:master.

Coverage increased (+7.7%) to 58.976% when pulling c8be682d3dccc3655ae79bee6423c504c4b74254 on changsiyao:classification into 38b3bf968f302ad6677de11e1a12590a5628f135 on berkeley-stat222:master.

Coverage increased (+6.7%) to 59.879% when pulling e27551fc48578e0fc7ae2ad9e8c77e7d51eda24c on changsiyao:classification into 987dbe31b1152d348f4282feb7aef8549bdef16d on berkeley-stat222:master.

Coverage increased (+9.3%) to 62.476% when pulling 88c05929458e9dc4f7209ec0be717eab5ca7ea98 on changsiyao:classification into 987dbe31b1152d348f4282feb7aef8549bdef16d on berkeley-stat222:master.

Coverage increased (+6.8%) to 62.476% when pulling 272cc063d87cddadb825dd5cfa503aeda5ad58c4 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+6.8%) to 62.476% when pulling 7bbeae1f592710dc2ed2ca201990e103f29e3562 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+11.0%) to 66.634% when pulling acbc17948a1d29e26a662c1cf8347710796c5116 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

I thought about it, I still think we should take user input for possible parameters to train. We can keep some default values, so that if users don't define these parameters themselves, our function can still run and find the best model. @lichenzhi @lizhua @ye-zhi
I recommend two options:

In your current function, take train and test separately as input, return model method, model parameters, and prediction for test set.
Write a separate function that takes in train_x, train_y, test_x, model method, model parameters and return a list of predictions.

Coverage increased (+11.9%) to 67.546% when pulling 49dfb9deeae32a93bca81c7433d6da126005f766 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+11.9%) to 67.577% when pulling c3b1d7b95558b77bcb63156faab222208f890d50 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+11.9%) to 67.577% when pulling c3b1d7b95558b77bcb63156faab222208f890d50 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+12.0%) to 67.67% when pulling 4d264af2f03a62b1f9fb029201ff7d37667f7564 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+12.0%) to 67.67% when pulling 4d264af2f03a62b1f9fb029201ff7d37667f7564 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+12.0%) to 67.67% when pulling fa1d80ecaf2818632a8db205a3c708c969b8842a on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+12.03%) to 67.7% when pulling b75847c13ea161b940670be610fc098932762b12 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

@changsiyao You are right! I made some changes based on your recommendations.

@lichenzhi @ye-zhi I made some changes to our model and summary. Also, I think we might add more models, like SVM.

@lizhua @lichenzhi I think we should allow the users to tune the parameters by passing in a list of integers instead of one integer so that they can use the CV grid search more efficiently. And, we should also check the input validation of the function. For example, n_estimators should contain positive integers.

@jarrodmillman I am not sure why our travis is not initiating either.

@ye-zhi @lizhua I fixed the type of tuning parameters and added the input validation. I will add the input validation for SVM as well. Also, I think it might help to output the top 10 important features of RF model and use those most important features to fit the model again to see if there is any improvement in performance.

Coverage increased (+18.9%) to 74.6% when pulling bb672ca5eba081ded6b9ad7b3e042acfc0128210 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+19.0%) to 74.668% when pulling c5b664ce4d8de22da02315c4b59cf3fb02e62981 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+19.0%) to 74.668% when pulling 03afc9d0eef0c4db7e425e88be8ecdef51c5aeaf on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.08%) to 73.753% when pulling 03afc9d0eef0c4db7e425e88be8ecdef51c5aeaf on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+19.0%) to 74.668% when pulling 03afc9d0eef0c4db7e425e88be8ecdef51c5aeaf on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.08%) to 73.753% when pulling 635d1d1e548c6684110339bc6e8080be5f4b9321 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+17.7%) to 73.368% when pulling 8b380632f440702ed4d637f755d69c41f952162f on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+17.7%) to 73.368% when pulling 5b8df5eaf4d423c4f384464b94316d1df483d733 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+17.7%) to 73.368% when pulling 75306a91b407d9fd88ece7936605bc10fbe0eb51 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+17.7%) to 73.368% when pulling c2650c942f10264f841a48630d67552ac9d00e2e on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+17.7%) to 73.368% when pulling c2650c942f10264f841a48630d67552ac9d00e2e on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+17.7%) to 73.368% when pulling 79ec8d59e092157945fb430451703c37616f1bc1 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.4%) to 74.068% when pulling cf18f7a2cd6f3ba4f48e66973aa1b8080f5c6fba on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.4%) to 74.068% when pulling cf18f7a2cd6f3ba4f48e66973aa1b8080f5c6fba on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.4%) to 74.068% when pulling 19d1c1e3463fff42db188df15773f8fa7d648945 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.4%) to 74.068% when pulling 3a11e21847ae1c7b8e2f7c93a6facaaafad9dd94 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

So I'm gonna rebase now to check whether the data loader change or other changes have impact on our work.

Coverage increased (+18.4%) to 74.068% when pulling 3a11e21847ae1c7b8e2f7c93a6facaaafad9dd94 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+18.4%) to 74.068% when pulling 3a11e21847ae1c7b8e2f7c93a6facaaafad9dd94 on changsiyao:classification into 9c279b162585d3e7bbd5fa8b65af5135543083d4 on berkeley-stat222:master.

Coverage increased (+0.8%) to 74.068% when pulling 410e726d810858602e4db1728467b8c1a8bb66a7 on changsiyao:classification into d9bdf4f899c2c123be16ec97e768a070994e917a on berkeley-stat222:master.

Coverage increased (+0.8%) to 74.079% when pulling 2aa94d91b7e4a3a34bd40823b30b0fcd1599f0ce on changsiyao:classification into d9bdf4f899c2c123be16ec97e768a070994e917a on berkeley-stat222:master.

Coverage increased (+0.8%) to 74.079% when pulling ca9931b9b98e7cc425dde6d890b5214314f6a797 on changsiyao:classification into 6191a571a5a9595bf512ba3eb7383dd570fff366 on berkeley-stat222:master.

Coverage increased (+0.8%) to 74.079% when pulling d4d344687f29118cd943107f195de57be2e7e00f on changsiyao:classification into 6191a571a5a9595bf512ba3eb7383dd570fff366 on berkeley-stat222:master.

Coverage increased (+0.8%) to 74.079% when pulling d4d344687f29118cd943107f195de57be2e7e00f on changsiyao:classification into 6191a571a5a9595bf512ba3eb7383dd570fff366 on berkeley-stat222:master.

Coverage increased (+0.8%) to 74.079% when pulling d4d344687f29118cd943107f195de57be2e7e00f on changsiyao:classification into 6191a571a5a9595bf512ba3eb7383dd570fff366 on berkeley-stat222:master.

Coverage increased (+0.7%) to 74.299% when pulling 53f7a41451e772ac0de3b3cbd203835a3e075536 on changsiyao:classification into 6a3fa7319baf871e52945000e7b2f09968191525 on berkeley-stat222:master.

Coverage increased (+0.7%) to 74.299% when pulling 53f7a41451e772ac0de3b3cbd203835a3e075536 on changsiyao:classification into 6a3fa7319baf871e52945000e7b2f09968191525 on berkeley-stat222:master.

Coverage increased (+0.7%) to 74.299% when pulling 905daa5f57603abef3ead8cbf22c3c96b0873b25 on changsiyao:classification into 3373372e5601ad523053de25b10290e0882e7258 on berkeley-stat222:master.


Program's code is wrong

I wanted to create my own key counter for stream with nice design etc, and to test it I took 2 other key counters. First I tested my own by clicking on 2 keys with this one and mine. My key counter gave me less keys per seconds than this one, and so I downloaded another one, that gave me same result of mine. If developer want to upgrade this program - rework the code.

(or maybe only this one works correctly)

oh well I tried


Logs support using FluentBit

I have researched the possibility of using a common Fluent Bit Helm Chart for log collection on K8s (as a DaemonSet), passing them through OpenTelemetry Collector and getting K8s metadata tagged.
The details are available in this document: https://docs.google.com/document/d/1QlFbXz0eQUaKXK1WrnEs3VqRkcPD2RAdXJdJMjnOSd8/edit#
There are several issues that need to be solved first, before metadata tagging will be available: https://github.com/open-telemetry/opentelemetry-collector/issues/1884,  https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/1146 and https://github.com/open-telemetry/opentelemetry-collector/issues/1652
Also, the fields such as pod_uid need to be separately converted into semantic-conventions compatible one, like k8s.pod.uid (it's not possible to use such capture group name, but another process can change the attribute name).
Having said of all that, it's plausible to setup an optional pipeline for log collection as part of the Helm Chart. Either taking the Fluent Bit Helm Chart as a dependency or via a similar approach
Fluent Bit config for retrieving logs using the CRI log path format (as suggested by @dashpole) and exporting to OpenTelemetry Collector:
    [INPUT]
        Name tail
        Path /var/log/pods/*/*/*.log
        Parser docker
        Tag kube.*
        Mem_Buf_Limit 5MB
        Skip_Long_Lines On

    [OUTPUT]
        Name forward
        Match kube.*
        Host <OPENTELEMETRY_COLLECTOR_HOST>
        Port <OPENTELEMETRY_COLLECTOR_FLUENT_FORWARDER_PORT>

The attribute extraction from Fluent Bit tag can be done using following processor:
    processors:
      attributes:
        actions:
          - key: fluent.tag
            action: extract
            pattern: ^kube\.var\.log\.pods\.(?P<namespace_name>[^_]+)_(?P<pod_name>[a-z0-9](?:[-a-z0-9]*[a-z0-9])?(?:[a-z0-9](?:[-a-z0-9]*[a-z0-9])?)*)_(?P<pod_uid>[-a-z0-9]+).(?P<container_name>.+)\.(?P<restarts>[0-9]+)\.log$

It seems reasonable to enable logs pipeline in the helm chart with fluentforward receiver by default, or keep it disabled but make it easy to enable with one telemetry.logs.enabled option. Actually it's already possible to enable logs pipeline with the current chart,  just requires a bit more configuration.
But I don't think we should bring fluentbit chart as dependency to the core helm chart. Instead we could have a another chart (probably in charts-contrib directory) which would leverage both opentelemetry-collector and fluenbit helm charts as dependancies and install them both.
cc @open-telemetry/helm-approvers

To reiterate what we discussed in Log SIG: we would want to make sure logs/FluentBit is an optional component so that users who only need traces and metrics don't pay the cost.
If in the future we add direct log collection support to the Collector we may not need FluentBit in this chart anymore.


Update images, dataplotter class

Update for images.
Restored the instance of the Data_plotter class. This resolves the problem of the images not being displayed next to each other.

Updated in pull request: https://github.com/QuTech-Delft/quantuminspire/pull/61


SWF import still working for you?

Hello,
It seems promising, congrats!
I watched your video and you import SWF file content.
I'm working on linux (ubuntu 22.04) and tried https://tool.next2d.app/ but cannot import any swf
See enclosed swf
custom.bg.bedroom_bg.swf.zip

@j2l
Hello,
Thank you for contacting me.
Only Shape and Bitmap are supported now.
We may support text and video in the future, but we have no plans to support ActionScript.
Is this the answer to your question?


New GPT custody: C#

Howdy. Sent you an invite and set up a c# branch. When your bot is in a good place, update the c# file and post a link to it.


Staff chat is is only working one way

the discordsrv staff chat is showing discord to minecraft messages but not vice versa please help fix it i'm not sure if its on my end or the plugin itself please help

Are you still experiencing this issue? What version of DiscordSRV and DiscordSRV-Staff-Chat are you using?


Using optimizeCss with tailwind breaking css in sveltekit.

After using optimizeCss, CSS size is decreased but tailwind styles are not working ( but some are applying ) when running yarn preview. Especially md:flex, md:pt-4 and lg:mb-3 etc styles are not working.
Then removed optimizeCss and after build CSS size is not decreased but tailwind all styles are applying.

This error is from purgecss so i am closing it. And i have fixed this error in a vague way.
optimizeCss({       safelist: {         // TODO: need improvement on regex         // standard: [/[A-Za-z0-9-_:\/]+/g]         standard: [           /sm/g,           /md/g,           /lg/g,           /xl/g,           /2xl/g,           /auto/g,           /py/g,           /hidden/g,           /m/g,           /p/g,           /[A-Za-z0-9]\\:/g         ]       }     })


Setup Sendgrid account for emails

Since our application needs to send emails like password reset and welcome email, we need email client. SendGrid is a free one, if you have another one let me know. We want someone to setup an account in sendgrid and send the login information to me over Whatsapp.

i can do this Duraan.

I would like to work on this issue.


fix legacy group all finish state for manually instance profiling

It's already very late at night! Take your time :)
I think it's fine to improve it later, as this is pure UX improvements.

submit the new PR for this issue: https://github.com/pingcap/tidb-dashboard/pull/1039


Cannot install with Kernel 6.6

Hi, I have quite an edge case here, being on a RPi4 and using minimal Manjaro. I have done a system update and am now on Kernel 6.6.31-1-MANJARO-RPI4. I tried to use the pivccu-modules-dkms package on the AUR (I know you are not the maintainer) and edited the PKGBUILD to point to the latest commit (and added some arbitrary version number). That solved some problems. But when the package is build I get the following output
DKMS make.log for pivccu-modules-1.0.99 for kernel 6.6.31-1-MANJARO-RPI4 (aarch64)
Mon 27 May 17:55:22 CEST 2024
make: Entering directory '/usr/lib/modules/6.6.31-1-MANJARO-RPI4/build'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: gcc (GCC) 14.1.1 20240507
  You are using:           gcc (GCC) 12.1.0
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/plat_eq3ccu2.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/generic_raw_uart.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/pl011_raw_uart.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/dw_apb_raw_uart.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/meson_raw_uart.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/fake_hmrf.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/rpi_rf_mod_led.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/dummy_rx8130.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/led_trigger_timer.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/hb_rf_usb.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/hb_rf_usb_2.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/hb_rf_eth.o
  CC [M]  /var/lib/dkms/pivccu-modules/1.0.99/build/rtc-rx8130.o
  MODPOST /var/lib/dkms/pivccu-modules/1.0.99/build/Module.symvers
scripts/mod/modpost: /usr/lib/libc.so.6: version `GLIBC_2.38' not found (required by scripts/mod/modpost)
make[2]: *** [scripts/Makefile.modpost:145: /var/lib/dkms/pivccu-modules/1.0.99/build/Module.symvers] Error 1
make[1]: *** [/usr/lib/modules/6.6.31-1-MANJARO-RPI4/build/Makefile:1865: modpost] Error 2
make: *** [Makefile:234: __sub-make] Error 2
make: Leaving directory '/usr/lib/modules/6.6.31-1-MANJARO-RPI4/build'

Is this an issue you have come across using Debian and Kernel 6.6?
My issue is I can't update gcc or glibc, as the latest versions from the Manjaro Repo are 12 and 2.35 respectively.

Thank you anyway. That was also my guess. Will try to get in contact with the Manjaro devs and hopefully get a solution there. Otherwise I will change my host system to Raspbian or something similar.


COPY cache not invalidating correctly with recursive copy

my dockerfile has
...
COPY code/ /src/code/
...

where code is a directory containing code files (including sub directories).
Making changes to these files is not invalidating the cache, and docker build is showing:
Step 11 : COPY code/ /src/code/
 ---> Using cache
 ---> 638bbc8d86ff

This problem is contrary to all the other issues in this area which complain invalidation is too agressive. IMHO this is much more serious as the resultant image is objectively wrong: it contains old versions of the code.
I've tried both COPY and ADD with the same problem, I'm on Docker version 1.9.0, build 76d6bc9, Ubuntu 15.10.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

more details system information as requested:
$ || docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:54:53 UTC 2015
 OS/Arch:      linux/amd64
$ || docker info
Containers: 10
Images: 258
Server Version: 1.9.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 278
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-18-generic
Operating System: Ubuntu 15.10
CPUs: 8
Total Memory: 15.63 GiB
Name: XXX
ID: GYIK:CCVB:LLSG:WZ2D:G5MG:A7WA:RVN3:SYEF:F2N4:UZAH:476G:BZPC
WARNING: No swap limit support
$ || uname -a
Linux X 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Could this be the same issue as https://github.com/docker/docker/issues/17290 (which was resolved by https://github.com/docker/docker/pull/17710) if it is, this will be fixed in 1.9.1

could be related but there are no symlinks anywhere in my project.

ping @tonistiigi could you have a look?

This is a regression in 1.9.0, 1.8.3 works fine
1.8.3
$ cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1 >  deps/dna/dna/util.py
$ /usr/local/Cellar/docker/1.8.3/bin/docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.5.1
 Git commit:   f4bf5c7
 Built:        Thu Oct 15 09:34:18 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:        Mon Oct 12 18:01:15 UTC 2015
 OS/Arch:      linux/amd64
$ /usr/local/Cellar/docker/1.8.3/bin/docker build .
Sending build context to Docker daemon 7.865 MB
Step 0 : FROM debian
 ---> 91bac885982d
...
Step 8 : COPY deps/dna/scripts /usr/local/bin/
 ---> Using cache
 ---> 00603962a3ed
Step 9 : COPY deps/dna/boto $PYTHON_DIR/boto
 ---> Using cache
 ---> ca8d6ec59c5e
Step 10 : COPY deps/dna/django $PYTHON_DIR/django
 ---> Using cache
 ---> b322ca396597
Step 11 : COPY deps/dna/dna $PYTHON_DIR/dna
 ---> ccea3794d7a5
Removing intermediate container 48ed471c5fed
Step 12 : COPY deps/something/scripts /usr/local/bin/
 ---> ba76e1784f18
Removing intermediate container 61b640046157
Step 13 : COPY deps/something/argcomplete $PYTHON_DIR/argcomplete
 ---> 72ba7b855022
Removing intermediate container 23dfae81b0b2
Step 14 : COPY deps/something/jce $PYTHON_DIR/jce
 ---> 684776e00b92
Removing intermediate container d3a2cbf46257
Step 15 : COPY deps/something-templates /usr/local/share/something/setup-templates
 ---> bbcb82978943
Removing intermediate container 1d9cba627118
Step 16 : COPY deps/something-tests /usr/local/share/something/tests
 ---> 26ca4c16a775
Removing intermediate container 78aaea53afe7
Step 17 : COPY deps/something/VERSIONS /usr/local/share/something/VERSIONS
 ---> 9209919ac844
Removing intermediate container 7c4590265901
Step 18 : WORKDIR /var/something
 ---> Running in 866570a48917
 ---> aca36196b118
Removing intermediate container 866570a48917
Step 19 : ENTRYPOINT /usr/local/bin/something
 ---> Running in 065fbb08f7cc
 ---> e7d2d1eaf0b0
Removing intermediate container 065fbb08f7cc
Successfully built e7d2d1eaf0b0

1.9.0
$ cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1 >  deps/dna/dna/util.py
$ docker version
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.5.1
 Git commit:   76d6bc9
 Built:        Tue Nov  3 21:18:00 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   76d6bc9
 Built:        Tue Nov  3 19:20:09 UTC 2015
 OS/Arch:      linux/amd64
$ docker build .
Sending build context to Docker daemon 7.865 MB
Step 1 : FROM debian
 ---> 91bac885982d
...
Step 9 : COPY deps/dna/scripts /usr/local/bin/
 ---> Using cache
 ---> d3cf4d92d2cc
Step 10 : COPY deps/dna/boto $PYTHON_DIR/boto
 ---> Using cache
 ---> 65fed087a369
Step 11 : COPY deps/dna/django $PYTHON_DIR/django
 ---> Using cache
 ---> 970f3420d75f
Step 12 : COPY deps/dna/dna $PYTHON_DIR/dna
 ---> Using cache
 ---> 9d1c58f0b5a1
Step 13 : COPY deps/something/scripts /usr/local/bin/
 ---> Using cache
 ---> f35167d5abea
Step 14 : COPY deps/something/argcomplete $PYTHON_DIR/argcomplete
 ---> Using cache
 ---> 6a3bc642f467
Step 15 : COPY deps/something/jce $PYTHON_DIR/jce
 ---> Using cache
 ---> 31f4f66a3edf
Step 16 : COPY deps/something-templates /usr/local/share/something/setup-templates
 ---> Using cache
 ---> 531358f8aaac
Step 17 : COPY deps/something-tests /usr/local/share/something/tests
 ---> Using cache
 ---> 8f078d0ce4f7
Step 18 : COPY deps/something/VERSIONS /usr/local/share/something/VERSIONS
 ---> Using cache
 ---> 27636396d336
Step 19 : WORKDIR /var/something
 ---> Using cache
 ---> b9b76ebc27a5
Step 20 : ENTRYPOINT /usr/local/bin/something
 ---> Using cache
 ---> bf3faa309566
Successfully built bf3faa309566

@samuelcolvin @carlossg is there a small reproducible case we could use to test?

Not sure this helps much, I've created a small example that should demonstrate the problem:
https://github.com/samuelcolvin/docker-copy-bug
However it's working correctly and copying the directory each time.
I've tried everything I can think of to reproduce the bug but with no luck.
I thought it might be something to do with starting building the image using 1.6 then updating to 1.9, but I've tried switching between the two version without being able to reproduce the issue.
Let me know if there's any more details you need about the original project where the problem occurred? I've tried duplicating as much of it as I can in the test but to no avail.

Ok, at last I've managed to replicate the issue. Two things had to be changed for it to occur:

the env directory had to exist next to Dockerfile it didn't have an effect if it was empty, i didn't check what needed to be in it, i just ran virtualenv env
the directory being copied needed to be called gen this seems odd and makes me think the problem is that somehow docker's cache on my machine has got messed up, so gen (the original name of the code directory in the first project where the problem occurred) is significant.

Output of ./test.sh:
cat gen/file.py: date = '18:56:37.756251477'
Sending build context to Docker daemon 23.63 MB
Step 1 : FROM ubuntu:15.10
 ---> 337d0fd75c93
Step 2 : COPY gen/ /src/gen/
 ---> Using cache
 ---> 1f87d344deea
Successfully built 1f87d344deea

-------------------------
updating gen/file.py
-------------------------

cat gen/file.py: date = '18:56:38.642704571'
Sending build context to Docker daemon 23.63 MB
Step 1 : FROM ubuntu:15.10
 ---> 337d0fd75c93
Step 2 : COPY gen/ /src/gen/
 ---> Using cache
 ---> 1f87d344deea
Successfully built 1f87d344deea

ok, I realized that I had a broken symlink in a subdir of my workdir, not the subdir being copied though, another one.
So it might be #17290

Yep I think it is. @carlossg Any chance you can try from master? https://master.dockerproject.org

I tested this with 1.9.1-rc1 and it is fixed by #17710


make it possible to have one color per glyph

I would like clearer logic, or does that tie into the attribute refactor idea?

To separate the concerns a bit, I would leave this for the attribute refactor PR, as long as this PR doesn't introduce any regressions


Setup automated unit test coverage metrics

e.g. Code Climate with Travis-ci

Can we do this with ChefSpec and Travis?

Not really possible with ChefSpec


Invoice templates reconsideration

I don't think we actually need invoice templates, or at least not year. This is because the differences across currencies only really change the incoming bank details, but not the layout or content of the invoice itself. Therefore, we can delete the template column.

[x] Delete Invoice.template and Invoice.INVOICE_TEMPLATES.

The incoming bank account details will change based on the currency. Therefore, the invoice context can't hard-code these values. Instead of default_payment_details, we need a dictionary:
ACCOUNTS = {
    "USD": """
Account holder: Départ de Sentier
ACH and Wire routing number: 026073150
Account number:<PHONE_NUMBER>
Account type: Checking
Bank address:
    Wise
    30 W. 26th Street, Sixth Floor
    New York NY 10010
    United States
""",
    "CAD": """
Account holder: Départ de Sentier
Institution number: 621
Account number:<PHONE_NUMBER>07
Transit number: 16001
Bank address:
    Wise
    99 Bank Street, Suite 1420
    Ottawa ON K1P 1H4
    Canada
""",
    "EUR": """
Account holder: Départ de Sentier
BIC: TRWIBEB1XXX
IBAN: BE31 9673 6729 9455
Bank address:
    Wise
    Rue du Trône 100, 3rd floor
    Brussels
    1050
    Belgium
""",
    "CHF": """
Account holder: Départ de Sentier
IID (BC-Nr.): 80808
SWIFT-BIC: RAIFCH22
IBAN: CH14 8080 8009 3231 6387 3
Bank address:
    Raiffeisen
    Reusswehrstrasse 1
    5412 Gebenstorf
    Switzerland
""",
}

[x] Change invoice logic to insert bank details depending on currency

Fixed in commit #0da70e9  (as part of #65 -- can't cherry-pick it to a separated main-based branch to review independently due to conflicts).
A view of currency selection in the billing form:

A stripe payment form with currency value, provided to the API:

A fragment of a pdf with correct payment details and currency:

Just realized that we, probably, have to use different stripe products for registrations and memberships. It'd be nice to have it as an issue (if it's necessary).


CFTs to S3

When the CFTs are available in this repo they should be placed on S3.  We should make this scripted so that they can be updated as needed for product releases.
Details
Scenario 1, public cloudformation templates
When a release is created in any of these repos:

https://github.com/Senzing/aws-cloudformation-database-cluster
https://github.com/Senzing/aws-cloudformation-ecs-poc-simple
https://github.com/Senzing/aws-cloudformation-ecs-senzing-stack-basic
https://github.com/Senzing/aws-cloudformation-ecs-senzing-stack-choices

The cloudformation.yaml from the main branch of the repo needs to copied to
the public-read-access S3 bucket.  This S3 bucket has directory named for each repo:

public-read-access/aws-cloudformation-database-cluster/
public-read-access/aws-cloudformation-ecs-poc-simple/
public-read-access/aws-cloudformation-ecs-senzing-stack-basic/
public-read-access/aws-cloudformation-ecs-senzing-stack-choices/

The cloudformation.yaml should be copied into each S3 bucket twice, once as
cloudformation.yaml and again as cloudformation-<release tag> (EG cloudformation-1.0.9.yaml)
Scenario 2, Marketplace cloudformation templates
When a release is created in the marketplace repo:

https://github.com/Senzing/aws-marketplace-evaluation

Both cloudformation templates:

cloudformation-senzing-basic.yaml
cloudformation-senzing-database.yaml

need to be copied to the senzing-aws-marketplace S3 bucket.  This S3 bucket
has directories named for the specific cloudformation template:

senzing-aws-marketplace/basic <-- cloudformation-senzing-basic.yaml
senzing-aws-marketplace/database <-- cloudformation-senzing-database.yaml

Again each cloudformation template should be copied twice using the same pattern
as the previous Scenario.  EG cloudformation-senzing-basic.yaml is copied into
senzing-aws-marketplace/basic as both cloudformation-senzing-basic.yaml and
cloudformation-senzing-basic-<release tag>.yaml

This was completed some time ago.


feature: Support loading file for Consul Token

Proposal
I use vault as a secret storage solution and I think it could be useful to support loading the consul token from a file like the bearer_token_file. For exemple, the Marathon SD already support it.
What do you think ?
If you like it, I could start working on a PR.
Thanks

I love the idea!

We went through this issue in our bug scrub and this might be possible by switching to a httpTransport passed to the consul client.
@roidelapluie Could you investigate the issue further, and tag it appropriately? As you've looked at this last.

Closing this as it is now superseded by #8551

This is being worked on as part of #8924


Data harmonizer templates

Test data harmonizer as a tool for curating data

@turbomam can we close this issue?  Maybe with a link to the latest templates/repo?

Here are the templates: https://github.com/turbomam/DataHarmonizer/tree/master/template
From this repo: https://github.com/turbomam/DataHarmonizer
Based on this code: https://github.com/microbiomedata/nmdc-metadata/blob/issue-375/notebooks/build_dh_mixs_templates.ipynb

Remaining to do:

add columns based on input from @mslarae13.

Set analysis results at https://github.com/microbiomedata/nmdc-metadata/blob/issue-398/notebooks/soil_slot_column_analysis_curated.json.
Resolving this may require requesting new terms or requesting new package/slot associations from MIxS.

move this work into a https://github.com/microbiomedata repo

I will close this one then and create a new issue for October related to adding columns based on input from Montana.


Attack Simulator Brute Force Attacks No Longer Functioning

We are using the brute force simulator to find out which users who are not yet on MFA have basic passwords.
Previously we were able to confirm that this works for users not on MFA. However, I noticed no users failed my last attempt. To confirm that it was working correctly we tested this with user accounts that we reset the passwords for, and it didn't work when entered manually and when put on a .csv. We know the passwords were the same as were entered, yet we saw 0 compromised users.
What is extra strange is that on the mentioned user accounts we actually saw this log on as successful.

@thequesarito - May we know which Microsoft document link you used in reference to this issue?
Please share it with us so we can investigate further. Thank you.

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/attack-simulator#brute-force-password-attack

@thequesarito -  Thank you for submitting feedback.
I think the best way forward is if you can open a service ticket in your tenant so this can get resolved ASAP. Based on outcome, let me know if it is something that can be called out in the docs.
If you don't mind please keep us posted here on the resolution and I really want to get this information you are discovering back into the docs.


added git, fixed clone location, fixed import of modules

Added git to the requirements
Fixed clone location (as further is referenced to c:\ )
Fixed import of modules (current command gives error! )
Description
New tool, Bug fixing, or Improvement?
Please include a summary of the change and which issue is fixed. Also include relevant motivation and context.
For new tools, please provide total size and installation time.

Related issue:
Check list

[ ] Related issue / work item is attached
[ ] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

Hi @al-cheb or @AlenaSviridenko,
I see this pull request is still open 😊


Upload XML file requires XML declaration

See https://github.com/OpenDataServices/cove/issues/1206
I uploaded an XML file with no declaration:

<?xml version="1.0"?>

or
<?xml version='1.0' encoding='utf-8'?>

Aidstream does not accept this XML file
@bjwebb notes:

Including the XML declaration is a SHOULD (not a MUST) in the XML spec https://www.w3.org/TR/xml/#sec-prolog-dtd. Aidstream should accept files without it, so we should report a bug.

Therefore, it might be an idea for Aidstream to not be so strict for XML fie import
(We will however adjust our XML files to include this!)

Hello Steven,
We looked into the issue you stated and yeah we will work on this one very soon. Many thanks for pointing this out.
On behalf of AidStream team,
Sonika

Hi Steven,
The issue has been fixed now.
Thank you
On behalf of AidStream team,
Mani


Order GC marker labels

Adds zero-width spaces to the marker labels to manipulate ordering. This makes the GC state flow easier to follow. Thread marker label ordering isn't really changing here since the alphabetical ordering currently happens to match the state ordering.

Before
After

I tried to find where the sorting happens, and I think it's here.

Ah I can set the bucket to be the index and that should do it, much better solution imo.

I don't like this, I think it'll be better to prefix the labels. We can't hard code the prefix cause not all marker types will have a matching sample, so we can do it when structuring the output.


Update MathML feature

Followup to https://github.com/web-platform-dx/web-features/pull/1940
I should have checked the draft folder and also search for "math" in BCD keys. Did that now.

hm, as I see it mspace is in the mathml.yml feature. I added that in https://github.com/web-platform-dx/web-features/pull/1940.


Windows: failed IPC communication with playwright smoke tests from preload script

1) VSCode Smoke Tests (Electron)
       Quick Open
         "before all" hook for "quick open search produces correct result":
     locator.waitFor: Timeout 40000ms exceeded.
=========================== logs ===========================
waiting for selector ".monaco-workbench" to be visible
============================================================
      at Application.checkWindowReady (D:\a\_work\1\s\test\automation\src\application.ts:149:56)
      at Application._start (D:\a\_work\1\s\test\automation\src\application.ts:98:4)
      at Application.start (D:\a\_work\1\s\test\automation\src\application.ts:75:3)
      at Context.<anonymous> (src\utils.ts:92:3)

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=165034&view=logs&j=672276a2-8d3a-5fab-615d-090c51352f92&t=9302e8c4-de85-5274-34fa-935ce79d4e8d

Yes this is from the new smoke tests with playwright, they are marked to not fail the build though.

This is our master issue for tracking the Windows issues for using playwright.
/cc @pavelfeldman

More logging reveals that the window awaits a IPC reply from the main process to continue loading the workbench. Here is the flow:

electron main process opens a ipcMain.handle (from here before the window loadUrl is called)
window loads preload.js first which will immediately call on the ipcRenderer.invoke (from here)
we await the config object to be resolved
Now we seem to time out on this call, a warning is printed after 10s that we still await the call.

Mitigated by doing a window reload after timeout of 10 seconds. This change only impacts smoke tests, I am hesitant to change something in our preload or bootstrap files until real users report this.
Still would be interesting to figure out if this is a Electron regressions.

@deepak1556 while I can mitigate the hang in the renderer by doing a window reload, I cannot mitigate it for the shared process where this is also happening and is most likely the cause of https://github.com/microsoft/vscode/issues/146800
Would it be possible to do an internal build where https://github.com/electron/electron/pull/33323 is reverted to see if that is the cause?

@bpasero turns out the above change and https://github.com/electron/electron/commit/3001b69f58c0bcd6fec9de3b007e8966b85e8a75 was reverted internally by Teams since it caused a regression on their end for their custom ipc implementations and never made it into our product builds. This could also explain why it was only seen with CI. I am currently creating newer builds with those changes added back in. Pretty sure this is very likely related to the root issue sharing the cause sender.url being an empty string when using playwright for testing in https://github.com/microsoft/vscode/issues/147301. Playwright is causing some sort of frame swap on initial load causing the empty url as well as https://github.com/electron/electron/blob/31c2b5703a75a5ff2bf0e68f472d9002fe866bfb/shell/browser/electron_browser_client.cc#L1558-L1559 condition to fail. I will look into this further once we have newer builds.

Thanks ❤ , I forgot that we use different builds in our CI for smoke tests, so that is a good thing to keep in mind going forward.
Curious what kind of issue Teams folks saw with IPC, maybe we can connect the dots with our issue.

Optimistically closing, will reopen when this happens again, I have removed all our workarounds.


adding notes to grafana

Also possible with grafana_plugins, via the role we use https://github.com/cloudalchemy/ansible-grafana#role-variables, but I failed to include that in infra-playbook. It also doesn't look like it will update, only install new.


Error 401 on Webscocket connection (noob...)

Hi,
I'm a beginner and just installed your package. My goal is to output each action that is happening on my Bybit account. So when a trade is placed and closed I want to see it in my code. Not sure if this is possible or not.
Now my first test is failing already. I'm trying this:
const {WebsocketClient} = require('@pxtrn/bybit-api');

const API_KEY = 'JIsxxxxxxxqfck';
const PRIVATE_KEY = '1DZ7DiBxxxxxxxxxviDqvZ0sdnLnsr';

const ws = new WebsocketClient({key: API_KEY, secret: PRIVATE_KEY});

My API keys are new and are having full access (so not a read only key).
The output i get is:
[Arguments] {
  '0': 'Starting authenticated websocket client.',
  '1': { category: 'bybit-ws' }
}
[Arguments] {
  '0': 'Websocket error',
  '1': {
    category: 'bybit-ws',
    err: Error: Unexpected server response: 401
        at ClientRequest.<anonymous> (/home/xxx/node_modules/ws/lib/websocket.js:580:7)
        at ClientRequest.emit (events.js:310:20)
        at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:603:27)
        at HTTPParser.parserOnHeadersComplete (_http_common.js:119:17)
        at TLSSocket.socketOnData (_http_client.js:476:22)
        at TLSSocket.emit (events.js:310:20)
        at addChunk (_stream_readable.js:286:12)
        at readableAddChunk (_stream_readable.js:268:9)
        at TLSSocket.Readable.push (_stream_readable.js:209:10)
        at TLSWrap.onStreamRead (internal/stream_base_commons.js:186:23)
  }
}

Anyone that can give me a hint?
Thanks !

401 means your not authenticated. Check those two:

Did you create the API key and secret for the testnet (https://testnet.bybit.com/) or the livenet (https://bybit.com/)? If you created them for the livenet, add livenet: true to the options:
const ws = new WebsocketClient({key: API_KEY, secret: PRIVATE_KEY, livenet: true});

Is your IP from which you try to access the websocket whitelisted for the key you use?